68P02901W36

BSS Implementation
Technical Description
GSR9
68P02901W36-S
2008 Motorola, Inc. All Rights Reserved.

Accuracy
While reasonable efforts have been made to assure the accuracy of this document, Motorola, Inc. assumes no
liability resulting from any inaccuracies or omissions in this document, or from use of the information obtained
herein. Motorola, Inc. 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, Inc. does not assume any liability
arising out of the application or use of any product, software, or circuit described herein; neither does it convey
license under its patent rights or the rights of others. It is possible that this publication may contain references to, or
information about Motorola products (machines and programs), programming, or services that are not announced
in your country. Such references or information must not be construed to mean that Motorola intends to announce
such Motorola products, programming, or services in your country.
Copyrights
This document, Motorola products, and 3rd Party Software products described in this document may include
or describe copyrighted Motorola and other 3rd Party supplied computer programs stored in semiconductor
memories or other media. Laws in the United States and other countries preserve for Motorola, its licensors, and
other 3rd Party supplied software certain exclusive rights for copyrighted material, including the exclusive right
to copy, reproduce in any form, distribute and make derivative works of the copyrighted material. Accordingly,
any copyrighted material of Motorola, its licensors, or the 3rd Party software supplied material contained in the
Motorola products described in this document may not be copied, reproduced, reverse engineered, distributed,
merged or modified 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 or other 3rd Party supplied software,
except for the normal non-exclusive, royalty free license to use that arises by operation of law in the sale of a
product.
A list of 3rd Party supplied software copyrights are contained in the Supplemental information section of this
document.
Restrictions
Software and documentation are copyrighted 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, Inc.
License Agreements
The software described in this document is the property of Motorola, Inc and its licensors. It is furnished by express
license agreement only and may be used only in accordance with the terms of such an agreement.
High Risk Materials
Components, units, or 3rd Party products used in the product described herein are NOT fault-tolerant and are NOT
designed, manufactured, or intended for use as on-line control equipment in the following hazardous environments
requiring fail-safe controls: the operation of Nuclear Facilities, Aircraft Navigation or Aircraft Communication
Systems, Air Traffic Control, Life Support, or Weapons Systems (High Risk Activities). Motorola and its supplier(s)
specifically disclaim any expressed or implied warranty of fitness for such High Risk Activities.
Trademarks
Motorola and the Stylized M Logo are registered in the US Patent & Trademark Office. All other product or service
names are the property of their respective owners.
The CE mark confirms Motorola, Inc. statement of compliance with EU directives applicable to this product. Copies
of the Declaration of Compliance and installation information in accordance with the requirements of EN50385 can
be obtained from the local Motorola representative or by contacting the Customer Network Resolution Center
(CNRC). The 24 hour telephone numbers are listed at https://mynetworksupport.motorola.com. Select Customer
Network Resolution Center contact information. Alternatively if you do not have access to CNRC or the
internet, contact the Local Motorola Office.
Jul 2008
Table
of
Contents
Contents

Technical Description: BSS Implementation

Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Version information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Resolution of Service Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Incorporation of Change Notices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
General information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Cross references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Text conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Contacting Motorola . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
24hour support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Questions and comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Security advice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Warnings, cautions, and notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Warnings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Cautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
General safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Electromagnetic energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Caring for the environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
In EU countries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
In non-EU countries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
CMM labeling and disclosure table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Motorola document set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Ordering documents and CD-ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Document banner definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Chapter 1: BSS Functional Description

Introduction to BSS Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
General description of the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Manual content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
BSS functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
BSC functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
BTS functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Speech transcoder functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
BSS serial data transmission links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
E1 links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
68P02901W36-S i
Jul 2008
Contents
Transmission systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9

Primary multiplex system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
Coded transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Air interface properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
Frequency band characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
Radio channel multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Physical channel structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Logical channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Logical channel groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Logical channel combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
Logical channel summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
GPRS traffic and control channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
Time division multiple access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
Modulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23
Multipath fading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
Optimized power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
Receiver channel equalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25
Channel coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
Full rate speech coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-27
Full rate interleaving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
Half rate interleaving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
Frequency hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
Adaptive Multi-Rate radio interface and timeslot allocation . . . . . . . . . . . . . . . . . 1-31
Adaptive Multi-Rate link adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-36
EGPRS air interface timeslot configurations . . . . . . . . . . . . . . . . . . . . . . . . . 1-40
EGPRS link adaptation and Incremental Redundancy (IR) . . . . . . . . . . . . . . . . . . 1-41
Call processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-43
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-43
Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-43
Call processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-44
Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-44
Call processing: MS to BSS to MSC signaling link . . . . . . . . . . . . . . . . . . . . . . . . 1-45
Signaling link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-45
Call processing: MS originated call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-46
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-46
Call set up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-46
MS originated call connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-47
MS idle time reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-49
Uplink traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-49
Downlink traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-49
Call processing: MS terminated call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-51
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-51
Call set up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-51
MS terminated call flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-53
MS idle time reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-55
Call processing: inter-BSS handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-56
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-56
Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-56
Inter-BSS handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-57
Call processing: intra-BSS handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-59
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-59
Intra-BSS handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-59
Intra-BSS handover process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-61
Call processing: intra-BTS handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-62
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-62
Non-synchronized handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-62
Synchronized handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-62
ii 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Contents
Synchronized intra-BTS handover process . . . . . . . . . . . . . . . . . . . . . . . . . . 1-63

Call processing: enhanced call trace management. . . . . . . . . . . . . . . . . . . . . . . . 1-64
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-64
Enhanced call trace management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-65
Call processing: GPRS Trace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-67
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-67
Performance impacts analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-68
GPRS Trace characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-70
Call processing: Carrier prioritization for SDCCH . . . . . . . . . . . . . . . . . . . . . . . . 1-74
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-74
Carrier prioritization for SDCCH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-74
Resource information messaging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-75
Resource messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-75
Location Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-76
BSS Location Services support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-76
Location Services positioning mechanisms. . . . . . . . . . . . . . . . . . . . . . . . . . 1-76
Timing Advance positioning (TA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-77
Network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-77
Gateway Mobile Location Center (GMLC) . . . . . . . . . . . . . . . . . . . . . . . . . . 1-78
Serving Mobile Location Center (SMLC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-78
Location Measurement Unit (LMU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-78
Location Services protocol usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-79
Location Services protocol stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-79
Transcoding function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-82
Location overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-82
Transcoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-82
Sample line reductions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-82
RXCDR interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-82
RXCDR description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-83
RXU shelf modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-83
Interface redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-83
RXCDR links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-84
Traffic and signal flow through the RXCDR . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-85
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-85
Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-85
Downlink traffic flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-85
Uplink traffic flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-85
8 kbps switching operational requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-86
Switching operational requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-86
EGPRS user interface requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-89
User interface requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-89
Interleaving of GPRS and EGPRS mobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-92
Interleaving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-92
GSM Half-Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-93
Dual band . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-94
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-94
BSC reset management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-95
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-95
CBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-95
RXCDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-95
OMC-R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-96
MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-96
BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-96
GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-96
Availability and limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-96
Cell OOS enhancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-97
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-97
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-97
68P02901W36-S iii
Jul 2008
Contents
Related commands and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-97

Support of RESUME at intra-BSC level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-98
Chapter 2: BSS Devices and Functions

Devices and functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Device and function equipage and maintenance . . . . . . . . . . . . . . . . . . . . . . . 2-3
Base Station Controller (BSC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
BSC description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
BSC types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Equipping and unequipping a BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Monitoring a BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
BSC alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
BSC 8 kbps switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Base Transceiver Station (BTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
BTS description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
BTS types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Equipping and unequipping a BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
Monitoring a BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
BTS alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
Adaptive Multi-Rate (AMR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
Cabinet (CAB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Equipping and unequipping a cabinet at the BSC . . . . . . . . . . . . . . . . . . . . . . 2-14
Unequipping of TCU/CTU cabinets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
CAGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Equipping and unequipping a CAGE at the BSC . . . . . . . . . . . . . . . . . . . . . . . 2-15
Transcoder and Remote transcoder (XCDR and RXCDR) . . . . . . . . . . . . . . . . . . . . . 2-16
Transcoder description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Transcoder function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Transcoder placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Remote transcoder placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Optional XBL usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
MSC, RXCDR, BSC interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
Quiet tone on the E1 link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
Impact of online transcoder expansion on site severity . . . . . . . . . . . . . . . . . . . 2-20
Enhanced Full-Rate speech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21
Handovers in EFR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
Enhanced Generic DSP Processor (GDP) provisioning . . . . . . . . . . . . . . . . . . . . 2-23
GDP function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
Equipping and unequipping an RXCDR . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25
After equipage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26
Add circuit and add channel relationship . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27
Ater interface in Enhanced Auto Connect (EAC) mode . . . . . . . . . . . . . . . . . . . 2-27
Associated BSS (ABSS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
Associated BSS function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
Equipping and unequipping an ABSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
Disabling CIC validation for an ABSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
Associated Transcoder (AXCDR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
Associated transcoder function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
Equipping and unequipping an AXCDR . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
Disabling CIC validation for an AXCDR . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
AXCDR and ABSS connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-31
Setting connectivity between AXCDR and ABSS . . . . . . . . . . . . . . . . . . . . . . . 2-31
Displaying the connectivity between AXCDR and ABSS . . . . . . . . . . . . . . . . . . . 2-31
CELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32
Cell specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32
Digital Radio Interface (DRI). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-33
iv 68P02901W36-S
Jul 2008
DRI pairing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-33

DRI and combiner relationship. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-33
Equipping and unequipping a DRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-34
Monitoring a DRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-35
DRI alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-35
Receive Transmit Functions (RTF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-36
Equipping and unequipping an RTF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-36
RTF mapping limitation on DD CTU2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37
Equipping and unequipping an RTF with GSM Half-Rate . . . . . . . . . . . . . . . . . . 2-37
Fully equipped RTF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37
Sub-equipped RTF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39
Equipped RTF configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39
LAPD protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-40
Redundant RTF path deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41
RTF monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41
RTF alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41
EGPRS RTF functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-48
EGPRS terrestrial timeslot allocation with 64 kbps TRAU enabled . . . . . . . . . . . . . . . . 2-50
TRAU format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-50
Kiloport or Double Kiloport switch and extension . . . . . . . . . . . . . . . . . . . . . . . . 2-53
KSW functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-53
KSWX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-54
Equipping and unequipping a KSW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-56
KSW monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-56
Locking and unlocking a KSW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-56
Changing KSW TDM highway mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-56
KSW alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-57
DSW or DSWX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-57
Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-57
Double Kiloport Switch (DSW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-58
DSW operational requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-58
DSW double rate 2048 timeslot capability . . . . . . . . . . . . . . . . . . . . . . . . . . 2-58
Generic Clock (GCLK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-61
GCLK synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-61
Synchronization features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-61
How GCLK synchronization works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-63
GCLK modes of operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-64
Set frequency mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-64
Phase lock mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-64
Phase locking option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-66
Equipping and unequipping a GCLK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-67
Monitoring a GCLK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-67
Changing characteristics of a GCLK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-68
GCLK alarms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-68
Generic Processors (GPROC, GPROC2 and GPROC3) . . . . . . . . . . . . . . . . . . . . . . 2-69
GPROC functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-69
GPROC fast reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-70
Equipping and unequipping a GPROC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-70
Changing GPROC specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-70
Monitoring a GPROC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-71
GPROC alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-71
GPROC function preemption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-71
GPROC3 dual boot functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-75
Base Site Processor (BSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-76
BSP functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-76
Equipping and unequipping a BSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-76
Monitoring a BSP GPROC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-76
68P02901W36-S v
Jul 2008
Contents
Base Transceiver Processor (BTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-77

BTP functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-77
Equipping and unequipping a BTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-77
Monitoring a BTP GPROC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-77
BSP or BTP redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-79
Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-79
GPROC specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-79
Modified BSP or BTP Redundancy rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-80
CSFP interworking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-80
Requirements for a potential master slot . . . . . . . . . . . . . . . . . . . . . . . . . . 2-80
Code Storage Facility Processor (CSFP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-81
CSFP functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-81
Equipping and unequipping a CSFP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-81
Changing CSFP characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-82
Monitoring a CSFP GPROC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-82
Digital radio Host Processor (DHP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-83
DHP functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-83
Equipping and unequipping a DHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-83
Monitoring a DHP GPROC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-83
Link Control Processor (LCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-84
LCP functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-84
Multiple Serial Interface boards (MSI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-85
MSI function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-85
Equipping and unequipping an MSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-86
Monitoring MSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-87
Locking and unlocking MSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-88
Changing MSI settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-88
MSI alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-88
GDP2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-89
GDP2 operational requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-89
TDM timeslot allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-90
Installation and configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-92
External Alarm System (EAS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-93
EAS function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-93
Equipping and unequipping an EAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-93
EAS alarm text string . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-94
Monitoring an EAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-94
EAS alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-94
Battery conservation in mains power failure . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-95
EAS use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-95
Extending backup battery life . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-95
Base Transceiver Function (BTF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-96
BTF functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-96
Equipping and unequipping a BTF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-96
Monitoring a BTF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-96
Link control function (LCF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-97
LCF function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-97
Equipping and unequipping an LCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-97
Monitoring an LCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-98
Changing LCF specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-98
LCF alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-98
GPROC channel allocation (GPROC2/GPROC3) . . . . . . . . . . . . . . . . . . . . . . . 2-99
LCF assignment to GPROCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-99
Operations and maintenance function (OMF) . . . . . . . . . . . . . . . . . . . . . . . . . . 2-100
OMF function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-100
Equipping and unequipping an OMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-100
Monitoring an OMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-100
OMF alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-100
vi 68P02901W36-S
Jul 2008
GPRS Packet Control Unit (PCU). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-101

PCU description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-101
GPRS (BSC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-102
GPRS (PCU site) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-103
PCU site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-103
Equipping GPRS devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-105
PCU site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-105
PCU as a device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-106
CABinet in a GPRS system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-107
CAGE in a GPRS system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-108
PCU System Processor board (PSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-108
Data Processor board (DPROC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-110
Multiple Serial Interface boards (MSIs) on DPROCs . . . . . . . . . . . . . . . . . . . . . 2-113
Resetting MSIs on a DPROC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-114
Multiple Serial Interface link (MMSs) on DPROCs . . . . . . . . . . . . . . . . . . . . . . 2-114
WebMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-115
UDPROC-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-119
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-119
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-119
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-119
High Bandwidth inter-connection between BSC and PCU (PSI) . . . . . . . . . . . . . . . . . 2-120
Feature overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-120
Feature interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-120
Related parameters and statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-120
Increase throughput of PRP with PCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-122
Related Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-122
PCU hardware backwards compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-123
Feature Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-123
Feature Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-123
Huge BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-124
Feature Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-124
Increased Network Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-125
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-125
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-125
High Speed MTL (HSP MTL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-126
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-126
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-126
Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-127
Related statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-127
BSP CPU utilization reduction for higher call handling capacity . . . . . . . . . . . . . . . . . 2-128
BSC overload protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-129
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-129
Related commands, parameters and statistics . . . . . . . . . . . . . . . . . . . . . . . . 2-129
Alarm information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-130
TDM Availability Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-131
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-131
Enhanced BSC Capacity using DSW2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-132
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-132
Chapter 3: BSS Links

Message Transfer Link (MTL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
MTL function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Message transfer part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Signaling point codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
68P02901W36-S vii
Jul 2008
Contents
Improved load-sharing of traffic on MTLs . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4

Cell Broadcast Link (CBL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
CBL function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
Equipping and unequipping a CBL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Monitoring a CBL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Changing CBL characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
CBL alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Terrestrial circuit device management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Circuit identity code device and function management . . . . . . . . . . . . . . . . . . . 3-8
Equipping and unequipping a CIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Monitoring a CIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Locking and unlocking a CIC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Enhanced terrestrial circuit management . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
CIC alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
Enhanced CIC validation for Adaptive Multi-Rate (AMR) half-rate . . . . . . . . . . . . . . 3-11
Adaptive Multi-Rate (AMR) in-call modification . . . . . . . . . . . . . . . . . . . . . . . 3-11
AMR general call requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Dynamic allocation of RXCDR-BSC circuits (DARBC) . . . . . . . . . . . . . . . . . . . . . . 3-14
DARBC function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
Effect on BSC and RXCDR roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
DARBC operator equipage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
Auto-connect mode and backwards compatibility mode . . . . . . . . . . . . . . . . . . . 3-16
Dynamic network of BTSs (DYNET) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
Dynamic network (DYNET) function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
Network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
Star connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
Daisy chain connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20
E1 links between BTSs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
Nailed paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
Call handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22
16 kbps RSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23
Allocating and freeing terrestrial backhaul resources . . . . . . . . . . . . . . . . . . . . 3-23
Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25
Equipping and unequipping a DYNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26
Monitoring a DYNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27
Changing DYNET specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27
Performance issues and timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28
Adaptive Multi-Rate (AMR) dynamic allocation of BSC-BTS circuits . . . . . . . . . . . . . 3-28
EGPRS terrestrial backhaul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29
VersaTRAU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30
VersaTRAU function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30
PDTCH to Backhaul Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30
Frame omission in the uplink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30
Performance statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31
Alarm information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31
Configuration management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31
Diagnostics and debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32
High bit-rate Digital Subscriber Link (HDSL) . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33
HDSL function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33
M-Cell or Horizon HDSL interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33
NIU daisy chain equipping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35
HDSL requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37
Equipping and unequipping an HDSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37
Monitoring an HDSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-39
Changing HDSL specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-39
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-40
viii 68P02901W36-S
Jul 2008
PATH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41
PATH function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41
Equipping and unequipping a PATH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41
Monitoring a PATH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-42
PATH alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-42
Timeslot reservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-43
Timeslot reservation function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-43
Reserved timeslots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-43
Add nail connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44
Nail path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44
Disabling timeslot usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-45
Displaying timeslot usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-45
EGPRS TRAU format and TRAU format audit . . . . . . . . . . . . . . . . . . . . . . . . 3-46
AMR TDM timeslot portion labeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-46
Radio Signaling Link (RSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48
RSL function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48
Equipping and unequipping an RSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49
Monitoring RSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49
Locking and unlocking RSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49
RSL alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49
Transcoder to BSS Link (XBL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50
XBL function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50
CIC blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51
Link control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51
BSC or RXCDR validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51
DARBC deliverable validation requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3-52
Invalid BSC or RXCDR configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53
Call downgrade on CIC capability mismatch . . . . . . . . . . . . . . . . . . . . . . . . 3-53
BSC or RXCDR operator interface verification . . . . . . . . . . . . . . . . . . . . . . . . 3-54
Equipping and unequipping an XBL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-56
Monitoring an XBL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-56
Locking and unlocking XBL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-56
XBL alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57
Alarms requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57
E1 link management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-59
E1 link management function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-59
Synchronization alarm thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-59
Remote loss alarms flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-59
Slip loss alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-59
Bit error rate monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-60
N Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-60
Related command and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-60
Aggregate Abis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-62
Aggregate Abis function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-62
Equipping and unequipping an aggregate Abis site . . . . . . . . . . . . . . . . . . . . . 3-62
Changing a site to aggregate Abis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-62
Monitoring aggregate Abis at a site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-62
Setting up the PCU (GPRS) links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-63
The GBL interface (frame relay permanent virtual connection) . . . . . . . . . . . . . . . 3-63
GSL state change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-63
Carrier state change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-63
Timeslot state change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-64
Carrier in service at initial configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . 3-64
PCU to BTS interface (modified for EGPRS) . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-65
GPRS Gb interface to Air interface Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 3-66
GPRS Gb signaling messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-66
68P02901W36-S ix
Jul 2008
Contents
BVC and MS flow control mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-66

Gb paging over the PCCCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-68
Gb paging over the CCCH for a single cell . . . . . . . . . . . . . . . . . . . . . . . . . . 3-68
Gb flush PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-69
Radio status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-69
Gb status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-69
Gb link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-70
Gb Link function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-70
Equipping and unequipping a GBL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-70
Taking GBLs in and out of service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-70
GBL states and reason codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-71
Resetting a GBL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-71
Monitoring GBLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-71
GBL alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-71
GPRS data stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-73
GPRS data stream function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-73
Equipping and unequipping a GDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-73
Taking a GDS in and out of service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-74
Resetting a GDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-75
Monitoring a GDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-75
GPRS Signaling Link (GSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-76
GPRS signaling link function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-76
GPRS PCU recovery on last GSL failure . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-76
Equipping and Unequipping a GSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-77
Taking a GSL in and out of service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-77
GSL states and reason codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-78
Resetting a GSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-79
Monitoring a GSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-79
GSL alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-80
GSL link control function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-81
Link control function management of GSLs . . . . . . . . . . . . . . . . . . . . . . . . . 3-81
Equipping and unequipping an LCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-81
Taking GSLs in and out of service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-82
Monitoring a GSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-82
GPRS PCCCH and PBCCH configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-83
Improved Timeslot Sharing (ITS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-86
ITS feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-86
Feature operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-86
SD placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-88
PD configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-88
Alarm Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-88
CTU2D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-89
Related parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-89
CTU2D Asymmetric Edge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-90
Feature interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-90
Chapter 4: BSS Software Processes

BSS software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
BSS and PCU processes and objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
BSS software processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
BSS software processes by function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Architecture-BSS code objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Central authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Fault management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Call processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
x 68P02901W36-S
Jul 2008
Statistics generation and reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6

SYSGEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
BSS reset and clear database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Time functions (time stamping) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Software and ROM checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Standard GSM and optional functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Link utilization improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
PCU software processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
PCU software processes by function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Software functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
PCU central authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
PCU switch manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Cell balancer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Fault management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
PCU configuration management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Configuration management database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Configuration management functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Configuration management database content . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Enhanced BSC capacity phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Increased Network Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
CM database distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Radio Subsystem (RSS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
Radio Subsystem functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
Layer 1 interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
Layer 2 interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
Layer 3 interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
Abis interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17
Handover detection and power control . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17
RSS component relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18
Preserve transceiver calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20
Preserve radio channel unit calibration function . . . . . . . . . . . . . . . . . . . . . . . 4-20
Database load management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
Changing databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
Database change level numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
Alarm processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
Alarm display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
Alarm blacklisting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
Comment field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
Alarm consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27
Context sensitive help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27
Paging list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27
Resync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28
Save alarm context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29
Throttling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29
Alarm types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30
Untagged and tagged alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30
Untagged . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30
Tagged . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30
Alarm states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32
Alarm categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33
Alarm severity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
Clearing types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
Enhanced Circuit Error Rate Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-36
Enhanced Circuit Error Rate Monitor function. . . . . . . . . . . . . . . . . . . . . . . . 4-36
Enhanced Circuit Error Rate Monitor points . . . . . . . . . . . . . . . . . . . . . . . . . 4-36
Circuit error rate message flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-39
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42
GPRS Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-43
68P02901W36-S xi
Jul 2008
Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-43
PFC-bit negotiation with the SGSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-43
GPRS QoS Traffic classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-43
Traffic Handling Priority (THP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44
Minimum Throughput Budget Requirement (MTBR) . . . . . . . . . . . . . . . . . . . . . 4-44
Admission control and retention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44
Pre-admission PFCs (PAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-46
Short-Term Non-Negotiated Traffic (STNNT) . . . . . . . . . . . . . . . . . . . . . . . . 4-46
QoS Profile; Aggregate BSS QoS Profile (ABQP) . . . . . . . . . . . . . . . . . . . . . . . 4-46
Packet Flow Context (PFC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-47
Scheduler Beta (b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-48
Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-49
MTBR Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-49
Quality of Service (QoS) Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-52
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-52
QoS Phase 2 Traffic classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-52
Traffic Handling Priority (THP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-53
Guaranteed Bit Rate (GBR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-53
Transfer delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-53
Admission control and retention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-54
QoS Profile; Aggregate BSS QoS Profile (ABQP) . . . . . . . . . . . . . . . . . . . . . . . 4-54
Packet Flow Context (PFC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-55
Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-55
MTBR Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-55
Audio volume control at the GDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-58
Volume increase or decrease. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-58
Software patching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-59
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-59
PCU upgrade without BSC outage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-61
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-61
Chapter 5: Cells
GSM cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
About this chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Cell elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
GSM Cell ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Online add, copy and delete cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
Online add, copy or delete cell functions . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Frequency types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Differences between GSM frequency types . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
GSM 850 frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
GSM 900 frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Extended GSM (EGSM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
DCS 1800 frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
High power DCS 1800 with increased sensitivity receiver matrix . . . . . . . . . . . . . . 5-9
PCS 1900 frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
PCS 1900 system impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
Base station Identity Code (BSIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
BSIC function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
Changing the training sequence code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
GSM control channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
GSM control channel groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
Broadcast control channel group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
xii 68P02901W36-S
Jul 2008
Common control channel group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17

Dedicated control channel group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
Fast associated control channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19
Channel combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20
Control channel mapping to timeslots . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20
Overview of single BCCH for dual band cells . . . . . . . . . . . . . . . . . . . . . . . . 5-21
Configuration of single BCCH dual band cells . . . . . . . . . . . . . . . . . . . . . . . . 5-22
Dual band inner zone algorithms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23
Channel selection algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25
Single BCCH dual band cell handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30
Single BCCH dual band cell related commands and parameters . . . . . . . . . . . . . . . 5-30
GPRS traffic and control channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33
Packet control channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33
Packet random access channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33
Packet paging channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33
Packet access grant channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34
Packet notification channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34
Packet data traffic channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34
Mapping packet data channels on to physical channels . . . . . . . . . . . . . . . . . . . . . 5-35
Timeslot usage by GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35
GPRS reserved and switchable timeslots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-36
GPRS switchable timeslots function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-36
Switchable PDTCH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37
Channel allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39
Channel requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39
Channel reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-42
Second assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-44
Queue management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-45
GPRS resource queuing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-47
Channel release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-48
Channel release function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-48
MS originated call clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-48
MSC originated call clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-49
GSM flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-51
BSS initiated flow control function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-51
TCH flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-51
BSS flow control operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-51
RACH flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-53
SSM flow control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-53
MSC initiated flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-54
AGCH flow control management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-57
Related statistic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-58
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-58
Adaptive Multi-Rate (AMR) TCH flow control . . . . . . . . . . . . . . . . . . . . . . . . 5-59
GPRS flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-60
Description of GPRS flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-60
Mobile System (MS) control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-61
MS paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-61
Extended paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-62
Preferred number of SDCCH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-62
Cell barring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-63
Cell barring function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-63
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-65
Call re-establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-66
Call re-establishment function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-66
68P02901W36-S xiii
Jul 2008
Contents

Cease transmission when cell goes Out-Of-Service. . . . . . . . . . . . . . . . . . . . . . . . 5-67
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-67
CELL transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-67
DRI transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-67
PCHN transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-68
COMB communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-68
Feature enabling and disabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-69
Concentric cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-70
Purpose of concentric cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-70
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-73
Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-77
GSM encryption function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-77
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-78
Discontinuous transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-79
Purpose of discontinuous transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-79
Description of DTX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-79
Uplink DTX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-79
Downlink DTX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-79
Downlink DTX for speech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-80
Downlink DTX for non-transparent data . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-80
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-81
Extended range cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-82
Extended range cell function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-82
Extended/normal range handover in isolated areas . . . . . . . . . . . . . . . . . . . . . 5-83
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-85
Short message service (cell broadcast) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-86
Short message service function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-86
Short message service cell broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-86
Point to point SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-88
Backward 3GPP compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-88
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-90
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-90
Cell selection/reselection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-91
Cell selection and reselection function . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-91
Related commands/fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-92
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-93
Network Assisted Cell Change (NACC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-94
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-94
Network Assisted Cell Change procedures. . . . . . . . . . . . . . . . . . . . . . . . . . 5-95
Type-5 microcellular algorithm for GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . 5-100
LLC boundary detection algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-101
Idle mode cell reselection enhancement algorithm. . . . . . . . . . . . . . . . . . . . . . 5-102
Active mode congestion relief algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-102
Network controlled cell reselection (packet data) . . . . . . . . . . . . . . . . . . . . . . . . 5-103
Network Controlled (NC1 and NC2) cell reselection . . . . . . . . . . . . . . . . . . . . . 5-103
Network controlled cell reselection enhancements . . . . . . . . . . . . . . . . . . . . . 5-104
BA (GPRS) list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-105
Related database commands and parameters . . . . . . . . . . . . . . . . . . . . . . . . 5-106
xiv 68P02901W36-S
Jul 2008
Chapter 6: Call Processing

Call processing function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
MTP L3/SCCP preprocessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Connectionless manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
SCCP state machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
Switch manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
Cell resource manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
Allocation manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
Radio resource state machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
Radio channel interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
Adaptive Multi-Rate (AMR) call processing . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
Call setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
Connection establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
Assignment to TCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Assignment of new calls as Adaptive Multi-Rate (AMR) Half rate . . . . . . . . . . . . . . 6-14
Adaptive Multi-Rate (AMR) TCH/H immediate assignment. . . . . . . . . . . . . . . . . . 6-14
GSM encryption (ciphering) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
Use of ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18
Call clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22
Introduction to call clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22
MS originated call clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22
MSC originated call clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25
GPRS data transfer processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26
MS states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26
GPRS two-phase access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26
Two-phase attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27
MS originated packet transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29
MS terminated packet transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-31
GPRS one-phase access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32
Enhanced GPRS one-phase access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-33
EGPRS one-phase access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-35
Delayed release of downlink TBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-37
Overview of delayed release of downlink TBF . . . . . . . . . . . . . . . . . . . . . . . . 6-37
Basic operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-37
Activating GPRS timeslots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-38
New MS in the cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-38
Changes in statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-38
Coding scheme CS1 forced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-38
Enhanced two uplink timeslots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-40
Enhanced 2UL Timeslot Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-40
Advanced uplink/downlink bias detection . . . . . . . . . . . . . . . . . . . . . . . . . . 6-40
Enhanced scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-43
Dynamic allocation of reserved PRR blocks . . . . . . . . . . . . . . . . . . . . . . . . . 6-43
Priority dynamic allocation scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-44
Escalation method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-45
Increase number of MSs serviced by each PRP . . . . . . . . . . . . . . . . . . . . . . . 6-47
GPRS sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-47
Performance enhancements under load . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-48
Percentage of RSL bandwidth reserved for circuit switched traffic . . . . . . . . . . . . . 6-48
Extended Dynamic Allocation Medium Access (EDMAC) Mode . . . . . . . . . . . . . . . . . 6-49
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-49
Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-49
Related parameters and statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-49
GPRS timeslot allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-51
68P02901W36-S xv
Jul 2008
Contents
GPRS switchable timeslot function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-51

Configuring switchable timeslots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-51
Reconfiguring switchable timeslots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-52
Dynamic switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-53
Reconfiguration of GPRS in a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-54
PBCCH or PCCCH timeslot allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-56
PBCCH or PCCCH air interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-58
EGPRS terrestrial resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-65
64 kbps terrestrial channels (BSC-BTS & PCU-BSC) . . . . . . . . . . . . . . . . . . . . . 6-65
Air interface packet data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-68
Air interface transmission layers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-68
Radio link control layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-68
Acknowledged/unacknowledged modes . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-73
Medium access control layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-73
EGPRS RLC or MAC signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-75
Physical layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-77
Coding schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-80
EGPRS coding schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-83
Call quality monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-85
Bit error rate and quality band . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-85
Bit error rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-85
Quality band . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-86
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-86
Bit error rate loss alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-87
GPRS block error rate monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-87
Adaptive Multi-Rate (AMR) Optimization Link and Intelligent Optimization System . . . . . . . 6-88
Optimization Link (OPL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-88
Intelligent Optimization System (IOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-88
Timing advance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-89
Circuit switched timing advance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-89
Packet switched timing advance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-89
BTS Concentration Call Priority Handling (BCCPH) . . . . . . . . . . . . . . . . . . . . . . . 6-92
BCCPH function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-92
Call processing: location services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-93
Early classmark procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-93
Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-93
BSSAP messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-93
MSC-SMLC perform location messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-94
SMLC-SMLC messaging (BSS-based SMLC only) . . . . . . . . . . . . . . . . . . . . . . 6-94
DTAP and DTAP-LE messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-95
Segmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-95
Connectionless procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-96
Global reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-96
Bearer signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-98
Signaling point inaccessible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-98
NSS-based SMLC positioning scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-100
Timing advance based positioning scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 6-100
BSS-based SMLC positioning scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-101
Handling issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-102
Preemption, overloading and early provision of TA. . . . . . . . . . . . . . . . . . . . . . 6-103
EGPRS incremental redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-105
Incremental redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-105
Adaptive Multi-Rate (AMR) Abis-interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-106
Traffic channel communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-106
Emergency call preemption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-107
Reservation of full-rate TCH for emergency calls . . . . . . . . . . . . . . . . . . . . . . 6-107
AMR channel allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-110
xvi 68P02901W36-S
Jul 2008
Channel information elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-110

EGPRS system information messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-122
System information messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-122
GPRS R4 compliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-123
Supported functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-123
Related statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-124
Enhanced Multi-Level Precedence and Preemption service (eMLPP) . . . . . . . . . . . . . . 6-125
Preemption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-126
Ater preemption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-128
Queuing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-129
Optional eMLPP Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-130
Related commands and Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-131
Call setup time improvement in a GSM network . . . . . . . . . . . . . . . . . . . . . . . . . 6-132
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-132
Fast Call Setup behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-133
Related commands, parameters and statistics . . . . . . . . . . . . . . . . . . . . . . . . 6-134
Chapter 7: Tracing Calls and Connectivity

Trace call functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Forwarding trace call data to the NMC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Preserving BSS resources for MSC initiated traces . . . . . . . . . . . . . . . . . . . . . 7-3
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
Trace call suggestions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
Available trace call criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
Specifying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
Trace call triggering and sending data to the OMC . . . . . . . . . . . . . . . . . . . . . . . 7-10
Trace instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
Trigger events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
Call selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
Record types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
Trace tailoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12
Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12
Cell level trace call events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
The trace call event messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14
Benefits of using trace call events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15
Defining the data sent in a trace event . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15
BSS level RF failure trace call events . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17
OMC graphical user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18
Expansion function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18
Trace view window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18
Trace criteria setup window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19
Invoked trace list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20
Trace record view window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20
OML functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-21
OML Out-of-Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-21
Flow control by OML buffer availability . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-21
OMC initiated flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-23
BSS internal flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-23
Multiple trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-24
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-24
Information contained in call traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-25
68P02901W36-S xvii
Jul 2008
Contents
Call trace product utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-26

CTP GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-26
Timeslot connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27
Related command and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27
Chapter 8: Power and Handover Control

Power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Power control description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Optimized power control enhancement function . . . . . . . . . . . . . . . . . . . . . . . 8-8
GPRS power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10
Related features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10
All channels at full power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11
All channels at full power function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12
Fast initial MS power down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
Fast initial MS power down function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
Quality measurement reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16
Receive quality measurement reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16
Missing report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-18
Missing report function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-18
Handover decision process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19
Handover decision process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19
Directed retry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-33
Congestion relief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-35
Enhanced congestion relief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-35
Multiband MS subscriber redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-36
Handover criteria for directed retry and congestion relief . . . . . . . . . . . . . . . . . 8-36
Pointing averaging mechanisms to decision processes . . . . . . . . . . . . . . . . . . . 8-36
Extended Range Cell (ERC) prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . 8-38
Worst quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-38
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-41
BA lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-43
Reason for BA lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-43
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-44
RXQUAL handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-45
RXQUAL handover function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-45
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-46
Inter-BSS handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-48
Message sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-48
Successful handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-48
EFR in inter-BSS handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-55
Inter-BTS handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-56
Handover successful . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-56
xviii 68P02901W36-S
Jul 2008
Intra-Cell handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-60

Handover successful . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-60
BSS forced handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-63
Adaptive power handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-66
Purpose of adaptive power handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-66
Description of power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-66
Handovers in single BCCH dual band cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-68
Overview of dual bands handover types . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-68
Statistics useful with single BCCH for dual band cells . . . . . . . . . . . . . . . . . . . . 8-71
Adaptive Multi-Rate dual band cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-75
Multiband inter-cell handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-76
Multiband inter-cell handover function . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-76
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-78
Adaptive Multi-Rate (AMR) multiband handover . . . . . . . . . . . . . . . . . . . . . . . . . 8-79
Coincident multiband handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-80
Coincident multiband handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-80
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-85
Advanced load management for EGSM carriers . . . . . . . . . . . . . . . . . . . . . . . . . 8-86
EGSM to EGSM handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-86
Related parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-87
Intelligent Multi-Layer Resource Management (IMRM) . . . . . . . . . . . . . . . . . . . . . 8-88
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-88
Flexible neighbor cell processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-92
Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-92
Microcellular handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-95
Microcellular handover function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-95
Handover candidates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-95
Micro-macro handover algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-96
Handover decision procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-102
Setting the candidate list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-103
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-105
SDCCH handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-106
Purpose of SDCCH handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-106
Description of SDCCH handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-106
SDCCH to TCH assignment for multiband MSs . . . . . . . . . . . . . . . . . . . . . . . 8-106
System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-107
MS handover power level based on path loss calculations . . . . . . . . . . . . . . . . . . . . 8-109
MS handover power level based on path loss calculations . . . . . . . . . . . . . . . . . . 8-109
Path loss calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-109
Description of handover power calculation . . . . . . . . . . . . . . . . . . . . . . . . . 8-110
Example of handover power level path loss calculation . . . . . . . . . . . . . . . . . . . 8-111
Congestion relief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-113
Congestion relief processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-113
68P02901W36-S xix
Jul 2008
Contents
Half Rate congestion relief procedure interaction . . . . . . . . . . . . . . . . . . . . . . 8-115

Adaptive Multi-Rate (AMR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-122
Handover Decision and Power Correction (HDPC) . . . . . . . . . . . . . . . . . . . . . . 8-122
Ater assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-124
Ping-pong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-126
Chapter 9: EGPRS and GPRS Power Control

EGPRS and GPRS power control and coding schemes . . . . . . . . . . . . . . . . . . . . . . 9-2
Overview of (E)GPRS power control and coding schemes . . . . . . . . . . . . . . . . . . 9-2
Types of (E)GPRS power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Coding schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Measurement reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
Methods of GPRS power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4
MS signal level measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5
Types of signal level measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5
Channel interference measurement reports . . . . . . . . . . . . . . . . . . . . . . . . . 9-8
BSS received signal level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
BSS received interference level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
GPRS uplink power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
Uplink algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
Closed loop uplink power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
Open loop uplink power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
Combined uplink power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16
Signaling uplink power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16
GPRS downlink power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18
Phases of downlink power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18
Downlink power control modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
Phases 1, 2 and 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-21
Phase 4 packet control Ack received from the MS . . . . . . . . . . . . . . . . . . . . . . 9-21
Phase 4 threshold comparisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-22
Phase 5 closed loop power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25
Phase 5 threshold comparisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-27
Phase 5 threshold comparison decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-27
Phase 5 PBLER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29
PBLER thresholds and decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29
Phase 5 algorithm selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-30
GPRS coding scheme selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-32
Coding scheme selection methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-32
Downlink coding decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-32
Uplink coding scheme selection and decisions . . . . . . . . . . . . . . . . . . . . . . . . 9-36
EGPRS power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-38
Power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-38
EGPRS uplink power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-39
EGPRS downlink power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-40
Phases 1, 2 and 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-40
Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-41
Phase 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-43
EGPRS coding scheme selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-46
Initial coding scheme selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-46
TLLI block coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-46
EGPRS downlink modulation coding scheme selection . . . . . . . . . . . . . . . . . . . . 9-46
EGPRS uplink modulation coding scheme selection . . . . . . . . . . . . . . . . . . . . . 9-54
Chapter 10: Frequency Hopping

Frequency hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Purpose of frequency hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
xx 68P02901W36-S
Jul 2008
Contents
Synthesizer Frequency Hopping (SFH) . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2

SFH example not through BCCH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
SFH example hopping through BCCH carrier . . . . . . . . . . . . . . . . . . . . . . . . 10-4
Baseband Frequency Hopping (BBH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4
BBH example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4
Implementing BBH restriction for DDEGPRS . . . . . . . . . . . . . . . . . . . . . . . . 10-6
Frequency hopping without site reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8
Adaptive Multi-Rate (AMR) frequency redefinition . . . . . . . . . . . . . . . . . . . . . . 10-10
Chapter 11: BSS Inter-Radio Access Technology Handover

BSS Inter-Radio access technology handover . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
GSM and UMTS handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
Effect on GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
System considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5
New neighbor attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6
Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6
Enhanced 2G/3G handover and cell reselection . . . . . . . . . . . . . . . . . . . . . . . . . 11-7
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7
Blind search by a multi-RAT MS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7
Measurement reporting and handover from 2G to 3G . . . . . . . . . . . . . . . . . . . . 11-7
TD-SCDMA and GSM interworking feature . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-15
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-15
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-15
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-16
68P02901W36-S xxi
Jul 2008
Contents
xxii 68P02901W36-S
Jul 2008
List
of
Figures
List of Figures

Figure 1-1: BSS with BSC transcoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

Figure 1-2: BSS with remote transcoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Figure 1-3: PCM channel format for E1 primary multiplexed signal . . . . . . . . . . . . . . . 1-10
Figure 1-4: E1 subrate multiplexed link channel format . . . . . . . . . . . . . . . . . . . . . 1-12
Figure 1-5: Logical channels, channel groups, and combinations . . . . . . . . . . . . . . . . 1-18
Figure 1-6: TDMA timeslot information burst . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
Figure 1-7: Logical channel timeslot format and timeslot/frame/multiframe structure . . . . . . 1-21
Figure 1-8: Burst structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
Figure 1-9: Channel protection and encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
Figure 1-10: Interleaving scheme for speech . . . . . . . . . . . . . . . . . . . . . . . . . . 1-29
Figure 1-11: Full rate traffic multiframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-34
Figure 1-12: Half rate traffic multiframe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35
Figure 1-13: C/I adaptation thresholds and the Active Codec Set (ACS) (uplink example) . . . . 1-37
Figure 1-14: MS originated call establishment. . . . . . . . . . . . . . . . . . . . . . . . . . 1-48
Figure 1-15: MS call termination set up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-54
Figure 1-16: Inter-BSS handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-58
Figure 1-17: Intra-BSS handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-61
Figure 1-18: Intra-BTS handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-63
Figure 1-19: GPRS Trace and Call Trace signal paths . . . . . . . . . . . . . . . . . . . . . . 1-69
Figure 1-20: GPRS UL data transfer establishment showing GPRS Trace IMSI trace selector
triggering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-71
Figure 1-21: GPRS DL data transfer establishment showing GPRS Trace IMSI trace selector
triggering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-72
Figure 1-22: GPRS data transfer one-phase UL TBF establishment showing GPRS Trace TLLI
trace selector triggering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-73
Figure 1-23: Location Services Network Architecture . . . . . . . . . . . . . . . . . . . . . . 1-77
Figure 1-24: BSS-SMLC protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-80
Figure 1-25: BSS-MS protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-80
Figure 1-26: BSS-LMU protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-81
Figure 1-27: BSS-MSC protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-81
Figure 1-28: 8 kbps half-rate for remote transcoding . . . . . . . . . . . . . . . . . . . . . . 1-87
Figure 1-29: 8 kbps HR for local transcoding . . . . . . . . . . . . . . . . . . . . . . . . . . 1-88
Figure 2-1: The BSC within the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Figure 2-2: BSC type 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Figure 2-3: BSC type 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Figure 2-4: BTSs within the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Figure 2-5: BTS type 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Figure 2-6: BTS type 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Figure 2-7: The Transcoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Figure 2-8: Enhanced full-rate speech signaling . . . . . . . . . . . . . . . . . . . . . . . . . 2-22
Figure 2-9: GDP pairing at an RXCDR or BSC . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24
Figure 2-10: GDP replacing an MSI board . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25
Figure 2-11: DRI and combiner relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-34
Figure 2-12: Fully equipped RTF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-38
Figure 2-13: Sub-equipped RTF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39
68P02901W36-S xxiii
Jul 2008
List of Figures
Figure 2-14: Kiloport switch data layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-54

Figure 2-15: Double KSWX extension or expansion configuration . . . . . . . . . . . . . . . . 2-55
Figure 2-16: Maximum DSW extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-60
Figure 2-17: Locking two sites showing clock synchronization. . . . . . . . . . . . . . . . . . 2-62
Figure 2-18: Block diagram of GCLK M-Cell or Horizon synchronization . . . . . . . . . . . . 2-63
Figure 2-19: Function priority example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-72
Figure 2-20: Function preemption algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 2-73
Figure 2-21: MSI connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-86
Figure 2-22: TDM allocation and overlay clash resolution . . . . . . . . . . . . . . . . . . . . 2-91
Figure 2-23: PCU in GSM/GPRS network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-102
Figure 2-24: Device and equipment hierarchy for the PCU device . . . . . . . . . . . . . . . . 2-104
Figure 2-25: WebMMI interface with the PCU . . . . . . . . . . . . . . . . . . . . . . . . . . 2-116
Figure 2-26: Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-118
Figure 3-1: MTP layer 3 on A interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Figure 3-2: Cell broadcast link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
Figure 3-3: Possible network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
Figure 3-4: Star connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20
Figure 3-5: Closed loop and open ended daisy chains . . . . . . . . . . . . . . . . . . . . . . 3-21
Figure 3-6: Extra path definition for nailed connections . . . . . . . . . . . . . . . . . . . . . 3-22
Figure 3-7: Terrestrial backhaul resource nailed connection before a call . . . . . . . . . . . . 3-24
Figure 3-8: Terrestrial backhaul resource connections during a call . . . . . . . . . . . . . . . 3-24
Figure 3-9: Closed loop daisy chain configuration with 1 BTS . . . . . . . . . . . . . . . . . . 3-25
Figure 3-10: Using redundancy for extra capacity before failure . . . . . . . . . . . . . . . . 3-25
Figure 3-11: Using redundancy for extra capacity after failure . . . . . . . . . . . . . . . . . 3-26
Figure 3-12: VersaTRAU terrestrial timeslot mapping . . . . . . . . . . . . . . . . . . . . . . 3-30
Figure 3-13: External modem at a BSC connected to an integrated HDSL NIU . . . . . . . . . 3-34
Figure 3-14: External modem at a BTS connected to an integrated HDSL NIU . . . . . . . . . 3-34
Figure 3-15: HDSL interface between integrated HDSL NIUs . . . . . . . . . . . . . . . . . . 3-34
Figure 3-16: NIU Daisy chaining correct configuration . . . . . . . . . . . . . . . . . . . . . 3-35
Figure 3-17: NIU daisy chaining incorrect configuration. . . . . . . . . . . . . . . . . . . . . 3-36
Figure 3-18: Nail path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-45
Figure 3-19: BCCH or CCCH configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-83
Figure 3-20: PBCCH or PCCCH configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 3-84
Figure 3-21: Link usage by GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-84
Figure 3-22: DD CTU2 configuration with EGPRS on Carrier A . . . . . . . . . . . . . . . . . 3-87
Figure 3-23: X timeslot on Carrier B back to TCH idle when PDs lost on A . . . . . . . . . . . 3-87
Figure 4-1: CM database distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
Figure 4-2: Database level numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
Figure 4-3: RSS component relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
Figure 4-4: PCU and local transcoding system showing CERM monitor point links . . . . . . . 4-37
Figure 4-5: Remote XCDR and BTS system showing CERM monitor point links . . . . . . . . . 4-38
Figure 4-6: CIC and RCI alarm activation message flow for remote BTS . . . . . . . . . . . . . 4-40
Figure 4-7: Circuit error rate monitor alarm clearing message flow . . . . . . . . . . . . . . . 4-41
Figure 4-8: Circuit error rate monitor alarm resync with OMC . . . . . . . . . . . . . . . . . 4-41
Figure 5-1: Online add/copy/delete cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
Figure 5-2: BSIC structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
Figure 5-3: 52 multiframe structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35
Figure 5-4: GPRS timeslot selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-36
Figure 5-5: Repeated channel request messages. . . . . . . . . . . . . . . . . . . . . . . . . 5-40
Figure 5-6: Successful connection establishment between GSM elements . . . . . . . . . . . . 5-41
Figure 5-7: Call clearing initiated by MS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-48
Figure 5-8: Call clearing initiated by MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-49
Figure 5-9: Operation of flow_control_t1 and flow_control t2 . . . . . . . . . . . . . . . . . . 5-52
Figure 5-10: Single overload message received . . . . . . . . . . . . . . . . . . . . . . . . . 5-55
Figure 5-11: Two overload messages received . . . . . . . . . . . . . . . . . . . . . . . . . . 5-55
Figure 5-12: Three overload messages received . . . . . . . . . . . . . . . . . . . . . . . . . 5-56
Figure 5-13: Example AGCH positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-62
Figure 5-14: Concentric cells-power based . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-71
xxiv 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation List of Figures
Figure 5-15: Interference based algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-72

Figure 5-16: Mapping of extended range timeslots to air timeslots . . . . . . . . . . . . . . . 5-83
Figure 5-17: Normal range cells (isolated, boundary) within extended range cells. . . . . . . . 5-84
Figure 5-18: Network agrees with the MS target cell selection . . . . . . . . . . . . . . . . . 5-96
Figure 5-19: Network has no target cell information before sending PCCC . . . . . . . . . . . 5-97
Figure 5-20: Network evaluates a new target cell for the MS . . . . . . . . . . . . . . . . . . 5-98
Figure 5-21: Network has no target cell information before sending PCCO . . . . . . . . . . . 5-99
Figure 5-22: Network evaluates that cell reselection is not required for the MS . . . . . . . . . 5-100
Figure 5-23: BA (GPRS) list monitoring before optimization . . . . . . . . . . . . . . . . . . . 5-105
Figure 5-24: BA (GPRS) list monitoring after NC2 optimization . . . . . . . . . . . . . . . . . 5-106
Figure 6-1: Call processing and the RSS relationship . . . . . . . . . . . . . . . . . . . . . . 6-6
Figure 6-2: Successful connection establishment between GSM elements . . . . . . . . . . . . 6-8
Figure 6-3: Successful connection within and between BSC and BTS (Part 1) . . . . . . . . . . 6-9
Figure 6-4: Successful connection within and between BSC and BTS (Part 2) . . . . . . . . . . 6-10
Figure 6-5: Successful TCH assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Figure 6-6: Assignment sequence within and between BSC and BTS (Part 1) . . . . . . . . . . 6-12
Figure 6-7: Assignment sequence within and between BSC and BTS (Part 2) . . . . . . . . . . 6-13
Figure 6-8: Ciphering commands between GSM elements . . . . . . . . . . . . . . . . . . . . 6-17
Figure 6-9: Successful signal sequence in ciphering specification . . . . . . . . . . . . . . . . 6-17
Figure 6-10: Call clearing initiated by MS (Part 1) . . . . . . . . . . . . . . . . . . . . . . . . 6-23
Figure 6-11: Call clearing initiated by MS (Part 2) . . . . . . . . . . . . . . . . . . . . . . . . 6-24
Figure 6-12: Call clearing initiated by MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25
Figure 6-13: GPRS attach messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27
Figure 6-14: Two-phase TBF access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28
Figure 6-15: MS originated packet transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29
Figure 6-16: Uplink packet data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-30
Figure 6-17: MS terminated packet transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-31
Figure 6-18: Downlink packet data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32
Figure 6-19: GPRS two-phase and one-phase access . . . . . . . . . . . . . . . . . . . . . . . 6-33
Figure 6-20: Enhanced GPRS one-phase access showing timeslot USF state . . . . . . . . . . 6-34
Figure 6-21: Multi-slot class 6 uplink/downlink bias timeslot allocation . . . . . . . . . . . . . 6-41
Figure 6-22: Multi-slot class 10 uplink/downlink bias timeslot allocation . . . . . . . . . . . . 6-41
Figure 6-23: Two-phase access procedure without reserved blocks . . . . . . . . . . . . . . . 6-43
Figure 6-24: Two-phase access procedure with reserved blocks . . . . . . . . . . . . . . . . . 6-44
Figure 6-25: Number of PRR reserved blocks as a function of RACH arrival rate . . . . . . . . 6-45
Figure 6-26: Enhanced one-phase access procedure . . . . . . . . . . . . . . . . . . . . . . . 6-46
Figure 6-27: One-phase access procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-46
Figure 6-28: GPRS session-WAP transfer example . . . . . . . . . . . . . . . . . . . . . . . . 6-47
Figure 6-29: Uplink RLC data block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-69
Figure 6-30: Downlink RLC data block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-70
Figure 6-31: Uplink RLC data block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-71
Figure 6-32: Downlink RLC data block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-72
Figure 6-33: RLC or MAC block structures . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-74
Figure 6-34: Packet transmission sequence (two timeslots) . . . . . . . . . . . . . . . . . . . 6-77
Figure 6-35: Packet transmission sequence (three timeslots) . . . . . . . . . . . . . . . . . . 6-78
Figure 6-36: Example of interleaving DL TBFs. . . . . . . . . . . . . . . . . . . . . . . . . . 6-79
Figure 6-37: Structure of the 456 bit CS-1 block. . . . . . . . . . . . . . . . . . . . . . . . . 6-80
Figure 6-38: Coding scheme CS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-81
Figure 6-41: Timing advance illustration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-89
Figure 6-42: Packet switched timing advance . . . . . . . . . . . . . . . . . . . . . . . . . . 6-91
Figure 6-43: Abstract view of packet SI/PSI status procedures . . . . . . . . . . . . . . . . . 6-124
Figure 6-44: New call preemption without queuing . . . . . . . . . . . . . . . . . . . . . . . 6-128
Figure 6-45: New call preemption with queuing . . . . . . . . . . . . . . . . . . . . . . . . . 6-130
Figure 6-46: Fast call setup call flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-133
Figure 7-1: Trace call expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Figure 7-2: Cell level trace call events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14
68P02901W36-S xxv
Jul 2008
List of Figures
Figure 7-3: BSS level RF failure trace call events . . . . . . . . . . . . . . . . . . . . . . . . 7-17

Figure 8-1: Desired RXLEV window, uplink or downlink . . . . . . . . . . . . . . . . . . . . . 8-3
Figure 8-2: MS power control oscillation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
Figure 8-3: MS power control RXLEV median levels . . . . . . . . . . . . . . . . . . . . . . . 8-6
Figure 8-4: Power change interval example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6
Figure 8-5: Setting full power mode for an MS . . . . . . . . . . . . . . . . . . . . . . . . . 8-11
Figure 8-6: BSS detects MS power level too high . . . . . . . . . . . . . . . . . . . . . . . . 8-13
Figure 8-7: Example of uplink SACCH measurement reports for one neighbor . . . . . . . . . 8-20
Figure 8-8: Example of uplink SACCH measurement reports for dl_rxlev . . . . . . . . . . . . 8-21
Figure 8-9: Downlink measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22
Figure 8-10: Flow chart of handover decision procedure-quality. . . . . . . . . . . . . . . . . 8-24
Figure 8-11: Flow chart of handover decision procedure-signal strength/distance . . . . . . . . 8-25
Figure 8-12: Uplink/downlink quality handover procedure. . . . . . . . . . . . . . . . . . . . 8-29
Figure 8-13: Downlink level handover procedure . . . . . . . . . . . . . . . . . . . . . . . . 8-30
Figure 8-14: Distance handover procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-31
Figure 8-15: Power budget handover procedure . . . . . . . . . . . . . . . . . . . . . . . . . 8-32
Figure 8-16: Handovers based on assignment requests or number of candidates . . . . . . . . 8-34
Figure 8-17: Successful inter-BSS handover between GSM elements . . . . . . . . . . . . . . 8-49
Figure 8-18: Successful inter-BSS handover sequence. . . . . . . . . . . . . . . . . . . . . . 8-50
Figure 8-21: Successful inter-BTS handover between GSM elements . . . . . . . . . . . . . . 8-56
Figure 8-22: Successful inter-BTS handover (Part 1). . . . . . . . . . . . . . . . . . . . . . . 8-58
Figure 8-23: Successful inter-BTS handover (Part 2). . . . . . . . . . . . . . . . . . . . . . . 8-59
Figure 8-24: Successful intra-cell handover . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-60
Figure 8-25: Successful intra-cell handover between source and target cells (Part 1) . . . . . . 8-62
Figure 8-26: Successful intra-cell handover between source and target cells (Part 2) . . . . . . 8-63
Figure 8-27: Multiband inter-cell handover . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-77
Figure 8-28: Relationship of coincident and neighbor cells . . . . . . . . . . . . . . . . . . . 8-81
Figure 8-29: Defined neighbor relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-82
Figure 8-30: Measurement reports used to make a handover . . . . . . . . . . . . . . . . . . 8-83
Figure 8-31: Handing over to an unreported neighbor . . . . . . . . . . . . . . . . . . . . . . 8-83
Figure 8-32: Inter BSC handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-84
Figure 8-33: Example EGSM handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-86
Figure 8-34: Microcellular handover to neighbor (numbered) cells . . . . . . . . . . . . . . . 8-95
Figure 8-35: Micro-macro handover types of algorithm . . . . . . . . . . . . . . . . . . . . . 8-96
Figure 8-36: Type 7 algorithm example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-101
Figure 8-37: Microcell algorithm type 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-102
Figure 8-38: Example of handover power level path loss calculation. . . . . . . . . . . . . . . 8-111
Figure 9-1: Normalized C value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6
Figure 9-2: Signal variance PDTCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
Figure 9-3: RLC data block reporting periods A and B . . . . . . . . . . . . . . . . . . . . . . 9-8
Figure 9-4: Channel interference measurements . . . . . . . . . . . . . . . . . . . . . . . . 9-9
Figure 9-5: BSS received signal level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Figure 9-6: BSS received interference level measurements . . . . . . . . . . . . . . . . . . . 9-12
Figure 9-7: Uplink power control window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
Figure 9-8: Phases of downlink TBF power control . . . . . . . . . . . . . . . . . . . . . . . 9-19
Figure 9-9: Mode A and Mode B downlink power control . . . . . . . . . . . . . . . . . . . . 9-20
Figure 9-10: Phase 4 threshold comparisons. . . . . . . . . . . . . . . . . . . . . . . . . . . 9-23
Figure 9-11: Phase 5 PCvalue calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-26
Figure 9-12: Phase 5 threshold comparisons and decisions . . . . . . . . . . . . . . . . . . . 9-28
Figure 9-13: BLER bitmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29
Figure 9-14: PBLER threshold decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-30
Figure 9-15: Phase 5 algorithm selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-31
Figure 9-16: BLER bitmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-33
Figure 9-17: pifPenalty degradation over time . . . . . . . . . . . . . . . . . . . . . . . . . . 9-34
Figure 9-18: DL Phase 5 Score based CS selection/UL BLER based CS selection . . . . . . . . 9-35
Figure 9-19: Example array window size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-36
xxvi 68P02901W36-S
Jul 2008
List of Figures
Figure 9-20: Uplink C/I based coding scheme selection . . . . . . . . . . . . . . . . . . . . . 9-37

Figure 10-1: Minimum SFH requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
Figure 10-2: Diagram of BBH example using three CTUs . . . . . . . . . . . . . . . . . . . . 10-5
Figure 10-3: Schematic of BBH example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6
Figure 11-1: GSM and UMTS system nodes and interfaces . . . . . . . . . . . . . . . . . . . 11-4
Figure 11-2: GSM to UTRAN handover signaling . . . . . . . . . . . . . . . . . . . . . . . . 11-11
68P02901W36-S xxvii
Jul 2008
List of Figures
xxviii 68P02901W36-S
Jul 2008
List
of
Tables
List of Tables

Table 1-1: Coding and transmission system comparison . . . . . . . . . . . . . . . . . . . . . 1-4

Table 1-2: PCM frame channel structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Table 1-3: BSS E1 links used for subrate multiplexing . . . . . . . . . . . . . . . . . . . . . . 1-12
Table 1-4: BTS radio channel characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
Table 1-5: Logical channel groups and channels . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Table 1-6: Logical channel combinations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
Table 1-7: Burst types and uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23
Table 1-8: Channel coder processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
Table 1-9: Supported Codec modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-37
Table 1-10: Identification of the codec modes within the Active Codec Set . . . . . . . . . . . 1-38
Table 1-11: EGPRS Coding Schemes and Throughput . . . . . . . . . . . . . . . . . . . . . . 1-41
Table 1-12: LMU radio measurement types . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-79
Table 2-1: RTF-DRI mapping on DD CTU2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37
Table 2-2: RTF configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-40
Table 2-3: CCU TRAU timeslot group to air interface timeslot sub channel mapping (CS3/4
allowed, 8 kbps TRAU allowed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-44
Table 2-4: CCU TRAU timeslot group to air interface timeslot sub channel mapping (CS3/4
allowed, 8 kbps TRAU allowed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-45
Table 2-5: CCU TRAU timeslot group to air interface timeslot sub channel mapping (8 kbps TRAU
allowed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-46
allowed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-47
allowed, sub-equipped) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-47
allowed, sub-equipped) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-48
Table 2-9: Attribute Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-49
Table 2-10: 16 kbps TRAU format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-51
Table 2-13: Cage and TDM timeslot bank allocations for a double rate expanded RXCDR . . . . 2-59
Table 2-14: Cage and TDM timeslot bank allocations for an expanded BSC . . . . . . . . . . . 2-59
Table 2-15: GPROC functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-74
Table 2-16: equipage of CIC per 64 kbps connection. . . . . . . . . . . . . . . . . . . . . . . 2-89
Table 2-17: TDM timeslot allocation priorities . . . . . . . . . . . . . . . . . . . . . . . . . . 2-92
Table 2-18: PRP capacity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-122
Table 3-1: Number of BSC to RXCDR signaling links. . . . . . . . . . . . . . . . . . . . . . . 3-17
Table 3-2: Coding Scheme Terrestrial Backing Needs . . . . . . . . . . . . . . . . . . . . . . 3-29
Table 3-3: M-Cell or Horizon (one board frame, one NIU, one H/W T43 board) . . . . . . . . . 3-38
Table 3-4: TDM Timeslot configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-46
Table 3-5: 8 kbps idle tone bit patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-47
Table 3-6: PBCCH or PCCCH Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-83
Table 4-1: Software process stage descriptions . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Table 4-2: OMC-R CONSOLIDATION environmental . . . . . . . . . . . . . . . . . . . . . . . 4-31
Table 4-3: ARP mobile selection (ARP Rank) order. . . . . . . . . . . . . . . . . . . . . . . . 4-45
68P02901W36-S xxix
Jul 2008
List of Tables
Table 4-4: Packet Flow contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-47

Table 4-5: BSS ARP configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 4-54
Table 5-1: GSM 850 frequency blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Table 5-2: PCS 1900 frequency blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
Table 5-3: Base Station Identity Code-Hexadecimal Values . . . . . . . . . . . . . . . . . . . 5-14
Table 5-4: Base Station Identity Code-Decimal Values . . . . . . . . . . . . . . . . . . . . . . 5-14
Table 5-5: Channel/timeslot mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20
Table 5-6: Dual band inner zone algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24
Table 5-7: Dual band parameter effect on assignments and handovers . . . . . . . . . . . . . 5-27
Table 5-8: NC cell reselection modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-103
Table 5-9: Related database commands and parameters . . . . . . . . . . . . . . . . . . . . . 5-106
Table 6-1: MS multi-slot class mapping for all GPRS multi-slot classes . . . . . . . . . . . . . 6-40
Table 6-2: Multiple GPRS carriers with default option specified . . . . . . . . . . . . . . . . . 6-51
Table 6-3: GPRS timeslots distributed over cell carriers . . . . . . . . . . . . . . . . . . . . . 6-52
Table 6-4: Timeslot stealing order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-53
Table 6-5: Carrier cell configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-54
Table 6-6: Second non-BCCH carrier OOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-55
Table 6-7: Ratio of INS carriers to PDCHs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-55
Table 6-8: PBCCH or PCCCH and ccch_conf parameter . . . . . . . . . . . . . . . . . . . . . 6-57
Table 6-9: PSI1 message parameter restrictions . . . . . . . . . . . . . . . . . . . . . . . . . 6-59
Table 6-10: PSI2 message parameter restrictions . . . . . . . . . . . . . . . . . . . . . . . . 6-59
Table 6-11: PSI3 message parameter restrictions . . . . . . . . . . . . . . . . . . . . . . . . 6-60
Table 6-12: PSI3bis message parameter restrictions . . . . . . . . . . . . . . . . . . . . . . . 6-60
Table 6-13: bs_prach_blks PRACH mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-62
Table 6-14: Packet Uplink Assignment (PUA) access types . . . . . . . . . . . . . . . . . . . . 6-63
Table 6-15: Paging in GPRS Operation Modes I and III (BCCH or CCCH) . . . . . . . . . . . . 6-64
Table 6-16: Paging in GPRS Operation Modes I and III (PBCCH or PCCCH) . . . . . . . . . . . 6-64
Table 6-17: RLC or MAC Header Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-75
Table 6-18: RXQUAL reported bands and assumed BER . . . . . . . . . . . . . . . . . . . . . 6-85
Table 6-19: Bearer channel signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-98
Table 6-20: BSS resource allocation matrix-SDCCH/full/half-rate channel specified . . . . . . . 6-116
Table 6-21: BSS resource allocation matrix-full/half-rate channel specified . . . . . . . . . . . 6-118
Table 6-22: Resource selection preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-120
Table 6-23: eMLPP preemption capability mapping . . . . . . . . . . . . . . . . . . . . . . . 6-126
Table 6-24: Comparison of throughput between SDCCH and TCH HR/FR . . . . . . . . . . . . 6-132
Table 7-1: The CTP GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-26
Table 8-1: Actions resulting from RXLEV_xx and RXQUAL_xx . . . . . . . . . . . . . . . . . . 8-4
Table 8-2: RXQUAL reported bands and assumed BER. . . . . . . . . . . . . . . . . . . . . . 8-16
Table 8-3: Index parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-37
Table 8-4: Decision process algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-38
Table 8-5: Bins used for each handover type . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-72
Table 8-6: Bins used for each successful handover type . . . . . . . . . . . . . . . . . . . . . 8-72
Table 8-7: Bins used for each MS bandwidth capability . . . . . . . . . . . . . . . . . . . . . 8-73
Table 8-8: Bins used for causes per handover reason . . . . . . . . . . . . . . . . . . . . . . 8-74
Table 8-9: Bins, Causes and the target band types . . . . . . . . . . . . . . . . . . . . . . . . 8-75
Table 8-10: Coincident multiband handover . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-80
Table 8-11: Default Band Weightings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-88
Table 8-12: Handover trigger and preference . . . . . . . . . . . . . . . . . . . . . . . . . . 8-104
Table 9-1: Range and values for SSB L_RXLEV_UL_P and U_RXLEV_UL_P . . . . . . . . . . . . 9-14
Table 9-2: EGPRS Phase 4 look up table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-42
Table 9-3: Selecting coding scheme selection table . . . . . . . . . . . . . . . . . . . . . . . 9-47
Table 9-4: EGPRS MCS selection based on 8PSK reports (for 8PSK Power Differential of 1.5dB or
lesser) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-48
Table 9-5: EGPRS MCS selection based on 8PSK reports (for 8PSK Power Differential of 1.6 to
3.6dB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-49
Table 9-6: EGPRS MCS selection based on 8PSK reports (for 8PSK Power Differential of 3.7dB or
greater) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-50
xxx 68P02901W36-S
Jul 2008
List of Tables
Table 9-7: EGPRS MCS selection based upon GMSK reports (for 8PSK Power Differential of
1.5dB or lesser) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-51
Table 9-8: EGPRS MCS selection based upon GMSK reports (for 8PSK Power Differential of 1.6
to 3.6dB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-52
Table 9-9: EGPRS MCS selection based upon GMSK reports (for 8PSK Power Differential of
3.7dB or greater) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-53
Table 9-10: EGPRS MCS selection based on GMSK reports (CTU2D Asymmetric mode) . . . . . 9-55
Table 10-1: BBH sequence example (EGSM 900) . . . . . . . . . . . . . . . . . . . . . . . . 10-5
Table 10-2: Initialization and pairing configuration . . . . . . . . . . . . . . . . . . . . . . . 10-7
Table 10-3: Mapping to idle Carrier A where Carrier B is already supported . . . . . . . . . . 10-7
Table 10-4: Mapping to idle Carrier B where Carrier A is already supported . . . . . . . . . . 10-8
Table 11-1: RAT configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5
Table 11-2: Attributes for UTRAN neighbor cells . . . . . . . . . . . . . . . . . . . . . . . . 11-6
Table 11-3: Changed commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6
Table 11-4: Summary of lists used by the MS . . . . . . . . . . . . . . . . . . . . . . . . . . 11-8
68P02901W36-S xxxi
Jul 2008
List of Tables
xxxii 68P02901W36-S
Jul 2008
About
This
Manual
Technical Description: BSS Implementation

What is covered in this manual?
This manual contains descriptions of the Motorola implementation of the main GSM BSS
functions with an explanation of how each function is implemented and how it affects the system.
Functions of the GSM Packet Radio Service (GPRS) and Enhanced GPRS (EGPRS) are included.
Functions in this manual are updated at each Motorola GSM Software Release (GSRn). The
manual does not include a list of these features at each release.
The manual provides a functional description of the BSS and the specific operations that are
controlled by the BSS. Information is provided on implementation and equipping the devices,
functions, and links required to facilitate BSS operations. The chapters in this manual are:
Chapter 1 BSS Functional Description.
Chapter 2 BSS Devices and Functions.
Chapter 3 BSS Links.
Chapter 4 BSS Software Processes.
Chapter 5 Cells.
Chapter 6 Call Processing.
Chapter 7 Tracing Calls and Connectivity.
Chapter 8 Power and Handover Control.
Chapter 9 EGPRS and GPRS Power Control.
Chapter 10 Frequency Hopping.
Chapter 11 BSS Inter-Radio Access Technology Handover.
68P02901W36-S 1
Jul 2008
Revision history
Revision history

The following sections show the revision status of this document.
Version information
The following table lists the supported versions of this manual in order of issue:
Issue Date of issue Remarks

Q Sep 2004 Issue Q-GSM Software Release 7 Half-Rate
R Nov 2006 Issue R-GSM Software Release 8 GMR02
S Apr 2008 Issue S-GSM Software Release 9
S Jul 2008 Issue S-GSM Software Release 9 FP1
Resolution of Service Requests
The following Service Requests are resolved in this document:
Service Request CMBP Number Remarks

SR 2204161 Modified the content in the section GPROC functions
on page 2-69.
SR 2218366 Description for parameter conincident_mb 3 is updated.
SR 2224961 Modified the section Type 3 algorithm on page 8-97 in
Chapter 8 Power and Handover Control.
Incorporation of Change Notices
The following Change Notices (CN) are incorporated in this document:
CN Date CN Number Title

N/A N/A N/A
2 68P02901W36-S
Jul 2008
General information
General information

Purpose
Motorola documents are intended to instruct and assist personnel in the operation, installation,
and maintenance of the Motorola equipment and ancillary devices. It is recommended that all
personnel engaged in such activities be properly trained by Motorola.
Motorola disclaims all liability whatsoever, implied or expressed, for any risk of damage, loss or
reduction in system performance arising directly or indirectly out of the failure of the customer,
or anyone acting on the customer's behalf, to abide by the instructions, system parameters,
or recommendations made in this document.
These documents are not intended to replace the system and equipment training offered by
Motorola. They can be used to supplement and enhance the knowledge gained through such
training.
NOTE
If this document was obtained when attending a Motorola training course, it is not
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 Motorola automatically supplies corrections and posts on the Motorola
customer website.
Cross references
References made to external publications are shown in italics. Other cross references,
emphasized in blue text in electronic versions, are active links to the references.
This document is divided into numbered chapters that 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.
68P02901W36-S 3
Jul 2008
Text conventions
Text conventions
The following conventions are used in the Motorola documents to represent keyboard input
text, screen output text, and special key sequences.
Input
Characters typed in at the keyboard are shown like this sentence.

Items of interest within a command appear like this sentence.
Output
Messages, prompts, file listings, directories, utilities, and environmental

variables that appear on the screen are shown like this sentence.
Items of interest within a screen display appear like this sentence.
Special key sequences
Special key sequences are represented as follows:
CTRL-c or CTRL+C Press the Ctrl and C keys at the same time.
CTRL-SHIFT-c or Press the Ctrl, Shift, and C keys at the same time.
CTRL+SHIFT+C
ALT-f or ALT+F Press the Alt and F keys at the same time.
ALT+SHIFT+F11 Press the Alt, Shift and F11 keys at the same time.
Press the pipe symbol key.
RETURN or ENTER Press the Return or Enter key.
4 68P02901W36-S
Jul 2008
Contacting Motorola
Contacting Motorola

Motorola appreciates feedback from the users of our documents.
24hour support
If you have problems regarding the operation of your equipment, contact the Customer Network
Resolution Center (CNRC) for immediate assistance. The 24hour telephone numbers are listed
at https://mynetworksupport.motorola.com. Select Customer Network Resolution Center
contact information. Alternatively if you do not have access to CNRC or the internet, contact
the Local Motorola Office.
Questions and comments
Send questions and comments regarding user documentation to the email address:
mydocs@motorola.com.
Errors
To report a documentation error, call the CNRC (Customer Network Resolution Center) and
provide the following information to enable CNRC to open an SR (Service Request):
The document type
The document title, part number, and revision character
The page number with the error
A detailed description of the error and if possible the proposed solution
68P02901W36-S 5
Jul 2008
Security advice
Security advice

Motorola systems and equipment provide security parameters that the operator configures
based on their particular operating environment. Motorola recommends setting and using
these parameters following industry recognized security practices. Consider protecting the
confidentiality, integrity, and availability of information and assets. Assets include the ability
to communicate, information about the nature of the communications, and information about
the parties involved.
In certain instances, Motorola makes specific recommendations regarding security practices.

The implementation of these recommendations and final responsibility for the security of the
system lies with the operator of the system.
Contact the Customer Network Resolution Center (CNRC) for assistance. The 24hour
telephone numbers are listed at https://mynetworksupport.motorola.com. Select Customer
Network Resolution Center contact information, from the menu located to the left of the
Login box. Alternatively if you do not have access to CNRC or the internet, contact the Local
Motorola Office.
6 68P02901W36-S
Jul 2008
Warnings, cautions, and notes
Warnings, cautions, and notes

The following describes how warnings and cautions are used in this document and in all
documents of this Motorola document set.
Warnings
Warnings precede instructions that contain potentially hazardous situations. Warnings are
used to alert the reader to possible hazards that could cause loss of life or physical injury. A
warning has the following format:
WARNING
Warning text and consequence for not following the instructions in the warning.
Cautions
Cautions precede instructions and are used when there is a possibility of damage to systems,
software, or individual items of equipment within a system. However, this damage presents
no danger to personnel. A caution has the following format:
CAUTION
Caution text and consequence for not following the instructions in the caution.
Notes
A note means that there is a possibility of an undesirable situation or provides additional

information to help the reader understand a topic or concept. A note has the following format:
NOTE
Note text.
68P02901W36-S 7
Jul 2008
Safety
Safety

General safety
The following general safety guidelines apply to Motorola equipment:

The power jack and mating plug of the power cable must meet International
Electrotechnical Commission (IEC) safety standards.
NOTE
Refer to Grounding Guideline for Cellular Radio Installations 68P81150E62.
Power down or unplug the equipment before servicing.
Using non-Motorola parts for repair could damage the equipment or void warranty.
Contact Motorola Warranty and Repair for service and repair instructions.
Portions of Motorola equipment may be damaged from exposure to electrostatic discharge.

Use precautions to prevent damage.
Electromagnetic energy
Relevant standards (USA and EC) applicable when working with RF equipment are:
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.
Council recommendation of 12 July 1999 on the limitation of exposure of the general

public to electromagnetic fields (0 Hz to 300 GHz) (1999/519/EC) and respective national
regulations.
Directive 2004/40/EC of the European Parliament and of the Council of 29 April 2004 on
the minimum health and safety requirements regarding the exposure of workers to the
risks arising from physical agents (electromagnetic fields) (18th individual Directive within
the meaning of Article 16(1) of Directive 89/391/EEC).
8 68P02901W36-S
Jul 2008
Caring for the environment
Caring for the environment

The following information describes national or regional requirements for the disposal of
Motorola supplied equipment and for the approved disposal of surplus packaging.
Contact the Customer Network Resolution Center (CNRC) for assistance. The 24hour
telephone numbers are listed at https://mynetworksupport.motorola.com. Select Customer
Network Resolution Center contact information. Alternatively if you do not have access
to CNRC or the internet, contact the Local Motorola Office.
In EU countries
The following information is provided to enable regulatory compliance with the European
Union (EU) directives and any amendments to these directives when using Motorola equipment
in EU countries.
Disposal of Motorola equipment
European Union (EU) Directive 2002/96/EC Waste Electrical and Electronic Equipment (WEEE)
Do not dispose of Motorola equipment in landfill sites. In the EU, Motorola in conjunction
with a recycling partner ensures that equipment is collected and recycled according to the
requirements of EU environmental law.
Disposal of surplus packaging
European Parliament and Council Directive 94/62/EC Packaging and Packaging Waste
Do not dispose of surplus packaging in landfill sites. In the EU, it is the individual recipients
responsibility to ensure that packaging materials are collected and recycled according to the
requirements of EU environmental law.
In non-EU countries
In non-EU countries, dispose of Motorola equipment and all surplus packaging in accordance
with national and regional regulations.
68P02901W36-S 9
Jul 2008
CMM labeling and disclosure table
CMM labeling and disclosure table

The Peoples Republic of China requires that our products comply with China Management
Methods (CMM) environmental regulations. (China Management Methods refers to the
regulation Management Methods for Controlling Pollution by Electronic Information Products.)
Two items are used to demonstrate compliance; the label and the disclosure table.
The label is placed in a customer visible position on the product.

Logo 1 means the product contains no substances in excess of the maximum concentration
value for materials identified in the China Management Methods regulation.
Logo 2 means that the product may contain substances in excess of the maximum
concentration value for materials identified in the China Management Methods regulation,
and has an Environmental Friendly Use Period (EFUP) in years. The example shown
uses 50 years.
Logo 1 Logo 2
The Environmental Friendly Use Period (EFUP) is the period (in years) during which the Toxic
and Hazardous Substances (T&HS) contained in the Electronic Information Product (EIP)
will not leak or mutate causing environmental pollution or bodily injury from the use of the
EIP. The EFUP indicated by the Logo 2 label applies to a product and all its parts. Certain
field-replaceable parts, such as battery modules, can have a different EFUP and are marked
separately.
The Disclosure table is intended only to communicate compliance with China requirements.
It is not intended to communicate compliance with EU RoHS or any other environmental
requirements.
10 68P02901W36-S
Jul 2008
Motorola document set
Motorola document set

The Motorola document sets provide the information to operate, install, and maintain the
Motorola equipment.
Ordering documents and CD-ROMs
With internet access available, to view, download, or order documents (original or revised), visit
the Motorola Lifecycles Customer web page at https://mynetworksupport.motorola.com, or
contact your Motorola account representative.
Without internet access available, order hard-copy documents or CD-ROMs from your Motorola
Local Office or Representative.
If Motorola changes the content of a document after the original printing date, Motorola
publishes a new version with the same part number but a different revision character.
Document banner definitions
A banner indicates that some information contained in the document is not yet approved for
general customer use. A banner is oversized text on the bottom of the page, for example,
PRELIMINARY UNDER DEVELOPMENT.
Data encryption
In order to avoid electronic eavesdropping, data passing between certain elements in the
network is encrypted. In order to comply with the export and import requirements of particular
countries, this encryption occurs at different levels. The encryption may be individually
standardized or may not be present at all in some parts of the network in which it is normally
implemented. The document set covers encryption as if fully implemented. Limitations on the
encryption included in the particular software being delivered, are covered in the Release Notes
that accompany the individual software release.
68P02901W36-S 11
Jul 2008
Data encryption
12 68P02901W36-S
Jul 2008
Chapter
BSS Functional Description

This chapter provides a description of the function and operation of the Base Station System
(BSS) components that process signaling data and route traffic data between the Mobile Station
(MS) and the Mobile Switching Center (MSC).
All information provided is valid for GSM 850, GSM 900, EGSM 900, DCS 1800 and PCS 1900
systems unless otherwise indicated.
The following topics are described in this chapter:

Introduction to BSS Implementation on page 1-2.
BSS functions on page 1-3.
BSS serial data transmission links on page 1-9.
Air interface properties on page 1-13.
Call processing on page 1-43.
Location Services on page 1-76.
Transcoding function on page 1-82.
Traffic and signal flow through the RXCDR on page 1-85.
8 kbps switching operational requirements on page 1-86.
EGPRS user interface requirements on page 1-89.
Interleaving of GPRS and EGPRS mobiles on page 1-92.
GSM Half-Rate on page 1-93.
Dual band on page 1-94.
BSC reset management on page 1-95.
{32340} Cell OOS enhancement on page 1-97.
{27717} Support of RESUME at intra-BSC level on page 1-98.
68P02901W36-S 1-1
Jul 2008
Introduction to BSS Implementation Chapter 1: BSS Functional Description
Introduction to BSS Implementation

General description of the BSS
The BSS is the interface between the Mobile Station (MS) and the Mobile services Switching
Center (MSC) elements of the network. The BSS performs a variety of functions. The following
are the functions provided by a BSS:
Radio coverage areas and control functions for one or more cells.
Radio coverage areas and control functions for the MSs in the cells.
Signaling data processing and routing of the traffic data exchanged between MS and MSC.
A complete general description of the BSS is given in System Information: GSM Overview
(68P02901W01).
Manual content
The following chapters detail the general function of the BSS and its control over specific
operations. Information is provided on implementation and equipping of the devices, functions,
and links required to facilitate BSS operation.
Comprehensive explanations of the following areas are also provided:

Cell functions, construction, and implementation.
Call processing functions and implementation.
Call trace and connectivity.
Power and handover control criteria.
Frequency hopping functions.
1-2 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BSS functions
BSS functions

Overview
The BSS is the interface between the Mobile Station (MS) and the Mobile Switching Center
(MSC) elements of the digital cellular system. The BSS processes signaling data and routes
traffic data between an MS and the MSC.
Signaling data includes:
Control messages required between an MS and BSS.
Signaling messages passed on to the MSC.
Traffic data is any type of user communication through the BSS (digitized voice, data
or both).
BSC functions
The BSC performs the following functions:

Controls the BTS and RXCDR components.
Performs call processing, operations, and maintenance.
Provides the interface between the RXCDR and the BTSs.
The BSC receives signaling and traffic data from the MSC through the RXCDR (if used). The
BSCs then provide the opportunity for remote switching, distributed control, and traffic
concentration.
Each BSC can support a mix of GSM 850, GSM 900, EGSM 900 and DCS 1800 BTS sites
simultaneously.
BTS functions
The BTS performs the following functions:

Manages the radio channels.
Transfers signaling information to and from Mobile Stations.
Each BTS network component provides radio channels (RF carriers) for a specific RF coverage
area.
The RF channel is the communications link between MS within an RF coverage area and the BSC.
All BTS network components that provide RF channels for the same geographic area are located
at a single BTS.
68P02901W36-S 1-3
Jul 2008
Speech transcoder functions Chapter 1: BSS Functional Description
Speech transcoder functions
The XCDR or RXCDR converts data between two different transmission systems to permit
communication between an MS and the MSC.
Transmission and coding systems
Table 1-1 compares the two different coding and transmission systems.
Table 1-1 Coding and transmission system comparison
Land network Cellular system air interface

Uses 64 kbps PCM channels for Uses 16 kbps GSM coded channels for routing
routing signaling and traffic data traffic data between the BSS and MSs.
between the MSC and BSS. The 13 kbps de-interleaved vocoder traffic data
from the Air Interface is combined with 3 kbps of
remote control protocol to make one 16 kbps GSM
coded channel (timeslot).
The RXCDR converts between the 64 kbps PCM data format and the 13 kbps remote transcoder
data format, allowing communication between the MSC and an MS. The following figures show
how the XCDR function fits into the call process.
Transcoding at the BSC
The BTS multiplexes four 16 kbps or eight 8 kbps speech channels into a single 64 kbps channel
(timeslot) on the BTS-to-BSC interface. The 16 kbps and 8 kbps rates are adapted from the
13 kbps vocoder channel (actually 22.8 kbps after interleaving) used on the Air Interface.
In the uplink direction, from MS-to-BSS, the transcoder at the BSC takes the following actions:
Demultiplexes each 64 kbps channel (timeslot) on the BTS-to-BSC interface into four
16 kbps or eight 8 kbps speech channels.
Converts each of the four 16 kbps or eight 8 kbps speech channels into a 64 kbps PCM
channel (timeslot) on the BSC-to-MSC interface.
In the downlink direction, from BSS-to-MS, the transcoder reverses these actions.
1-4 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Speech transcoder functions
Figure 1-1 shows the BSS with transcoding at the BSC.
Figure 1-1 BSS with BSC transcoding
Remote transcoding
The BTS multiplexes four 16 kbps or eight 8 kbps speech channels into a single 64 kbps channel
(timeslot) on the BTS-to-BSC interface. The 16 kbps and 8 kbps rates are adapted from the
13 kbps vocoder channel used on the Air Interface.
The BSC routes each 16 kbps or eight 8 kbps speech channel within the 64 kbps timeslot to the
correct 64 kbps timeslot for transmission to the Remote transcoder (RXCDR).
In the uplink direction (from BSS-to-MS), the transcoder at the MSC:

Demultiplexes each 64 kbps channel (timeslot) on the BSC-to-RXCDR interface.
Converts each of the four 16 kbps speech channels into a 64 kbps PCM channel (timeslot)
on the RXCDR-to-MSC interface.
In the downlink direction (from MS-to-BSS), the transcoder performs these actions in the
reverse order.
Figure 1-2 shows the BSS with remote transcoding. The RXCDR site is normally located close
to, or at, the MSC.
68P02901W36-S 1-5
Jul 2008
Figure 1-2 BSS with remote transcoding
CCDSP control information
The 3 kbps remote transcoder control protocol in the Air Interface contains information that the
RXCDR digital signal processors (DSPs) and Channel Code Digital Signal Processors (CCDSPs)
require.
The CCDSP is a part of each Transceiver Control Unit (TCU) located in the BTS. The CCDSP
control information is sent directly between the CCDSPs and XCDR DSPs.
The 3 kbps channel contains different information on the uplink (Rx) and (Tx) downlink
directions.
In the uplink, the 3 kbps of control contains the following information required by the XCDR:
Frame type used or ordered (speech or data).
Channel type used or ordered (full-rate).
Coded speech or user data.
Discontinuous Transmission (DTx) information.
Transparent and non-transparent bearer service notification.
Framing and ordered time alignment information to synchronize the transcoder with
the channel codec.
1-6 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Speech transcoder functions
In the downlink, the 3 kbps of control data contains the following information generated
by the RXCDR:
Frame type used or ordered (speech or data).
Channel type used or ordered (full-rate).
Coded speech or data.
Discontinuous transmission (DTx) information.
Transparent and non-transparent bearer service notification.
Framing information.
Time alignment used.
AMR control information
For AMR with 8 kbps backhaul, the exact bit rate used for the control stream varies according
to the codec mode in use. The control stream bit rate also varies slightly according to the
information that is to be passed.
The nominal bit rates are:

7.4 kbps codec 0.6 kbps control stream.
6.7 kbps codec 1.3 kbps control stream.
All other modes 2.1 kbps control stream.
The information transmitted in the control stream is like the information transmitted in 16 kbps
backhaul. However, since data services are not supported with 8 kbps backhaul, information
relating to data services are not included in the control stream.
The control stream contains information that the RXCDR digital signal processors (DSP) and
channel code digital signal processors require.
The CCDSP is part of each TCU located at the BTS. The CCDSP control information is sent
directly between the CCDSPs and XCDR DSPs.
The control stream contains different information on the uplink (Rx) and (Tx) downlink
directions.
In the uplink, the RXCDR requires the following information:

Frame type used or ordered (speech mode and codec rate).
Coded speech.
Framing and ordered time alignment information to synchronize the transcoder with
the channel codec.
68P02901W36-S 1-7
Jul 2008
In the downlink, the RXCDR requires the following information:

Used frame type (speech mode).
Coded speech or data.
Framing information.
Used time alignment.
This also applies when transcoding is local to the BSC.
1-8 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BSS serial data transmission links
BSS serial data transmission links

Overview
The BSS provides digital signal interfaces and transmission links to the land circuits linking
the BSS and the MSC.
E1 links
The digital signal interface circuits that run between the BSS network components and the
MSC are E1 links.
Each E1 link is a four-wire circuit that provides two-way communications.

One pair of wires for the uplink (Rx) direction.
One pair of wires for the downlink (Tx) direction.
Each wire pair carries a time division multiplexed E1 serial data stream.
The BSS multiplexes signaling or traffic data from the MS on the uplink data streams for routing
to the MSC. The MSC multiplexes mobile-terminated subscriber signaling and traffic data on the
downlink data stream for routing through the BSS to the MSs.
{22169} When the MSIs are increased from 56 to 96, 192 E1 links can be supported between
the BSC and BTSs, RXCDRs and PCU.
Transmission systems
E1 links use the following transmission systems:

ITU-TSS primary digital multiplex system with 64 kbps PCM channels up to the transcoder.
16 kbps or 8 kbps GSM coded channels from the transcoder.
Primary multiplex system
The primary multiplex system is used on the A Interface which is the standardized interface
between the BSS and the MSC.
The BSS Application Part (BSSAP) of the ITU-TSS Signaling System 7 (C7) protocols specifies
the control portion of the A interface.
68P02901W36-S 1-9
Jul 2008
Primary multiplex system Chapter 1: BSS Functional Description
C7 signaling
The C7 signaling information is sent at 64 kbps and provides:

Flow control.
Error detection and correction.
Ordered transmission.
Link management.
Link error monitoring.
Channels
The digital multiplexed signal carries 32 (E1) channels (timeslots):
E1 channels are:
30 voice frequency circuits of digitized PCM data.
One channel for timing data (CH0).
One channel for signaling data (normally CH16).
PCM channel format primary multiplex signal
Figure 1-3 shows the PCM channel format for the E1 primary multiplexed signal, where the
32 channels equal one frame.
Figure 1-3 PCM channel format for E1 primary multiplexed signal
1-10 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Coded transmission
A interface frame channel structure
Table 1-2 shows the channel structure of the frame.
Table 1-2 PCM frame channel structure
Channel number(s) Channel function

Ch0 (E1 only) Synchronization information for frame timing.
Ch1-Ch15 Traffic channels.
Ch16 (E1 only) Signaling channel, containing all signaling information for the 30 traffic
channels.
Ch17-Ch31 (E1) Traffic channels.
Coded transmission
In the coded transmission system, the transcoder:

Compresses each 64 kbps PCM data channel.
Encodes channel data into a GSM defined format.
Subrate multiplexes the compressed channels.
64 kbps compression
The transcoder compresses each 64 kbps channel into a 16 kbps or 8 kbps channel.
Coding
The scheme used is Linear Predictive Coding (LPC).
Subrate multiplexing
After the 64 kbps channels are compressed into 16 kbps or 8 kbps channels, subrate multiplexing
enables a single E1 link to carry four times the number of traffic channels provided by the PCM.
After transcoding, each E1 frame contains:

One 64 kbps synchronization (timing) channel.
One 64 kbps control (signaling) channel.
120 x 16 kbps traffic channels (that is, 4 x 30 x 16 kbps traffic channels) or 240 x 8 kbps
AMR traffic channels (that is, 8 x 30 x 8 kbps traffic channels).
68P02901W36-S 1-11
Jul 2008
Coded transmission Chapter 1: BSS Functional Description
Subrate multiplexed links
Table 1-3 shows the BSS E1 links used in subrate multiplexing.

Table 1-3 BSS E1 links used for subrate multiplexing
If transcoding is performed at Then subrate multiplexing is used on

BSC BSC to BTS E1 link.
RXCDR RXCDR to BSC E1 link.
BSC to BTS E1 link.
Channel format subrate multiplexed signal
Figure 1-4 shows the channel format of the subrate multiplexed E1 link:
Figure 1-4 E1 subrate multiplexed link channel format
1 FRAME
32 CHANNELS
CH1 CH2 CH15 CH16 CH17 CH18 CH19 CH31/23

PRIMARY
16 kbits 8 kbits
Half Rate
Subchannels channels
SUBRATE CH0 CH1 CH2 CH3

CH0 CH7
ti-GSM-E1T1 subrate multiplexedl ink channel format-00102-ai-sw
NOTE
The coded channels are not PCM. Also, there is no dedicated signaling channel like
timeslot 16 in the standard ITU-TSS system.
1-12 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Air interface properties
Air interface properties

Overview
This section describes the technical characteristics of the GSM 900, Extended GSM (EGSM
900), DCS 1800 and PCS 1900 digital cellular Air Interfaces.
The GSM Air Interface is a noise-robust transmission medium. The speed of a radio channel used
in GSM is 270.833 kbps. The modulation is 0.3 BT Gaussian Minimum Shift Keying (GMSK).
Frequency band characteristics
BTS radio channels (RF carriers) are full-duplex (transmit and receive) with the characteristics
listed in Table 1-4.
Table 1-4 BTS radio channel characteristics
Parameter GSM 850 GSM 900 EGSM 900 DCS 1800 PCS 1900
Transmit 824 to 849 935 to 960 925 to 960 1805 to 1880 1930 to 1990
frequency
band (MHz)
Receive 869 to 894 890 to 915 880 to 915 1710 to 1785 1850 to 1910
frequency
band (MHz)
Transmit 45 45 45 95 80
or receive
duplex
separation
(MHz)
Channel 200 200 200 200 200
width (kHz)
Number of 118 124 174 374 299
channels
Transmit 824.0 to 935.0 to 925.0 to 1805.0 to 1850.0 to
frequency 824.1 935.1 925.1 1805.1 1850.1
guard bands 848.1 to 849 959.9 to 959.9 to 1879.9 to 1909.9 to
(MHz) 960.0 960.0 1880.0 1910.0
Receive 869 to 869.1 890.0 to 880.0 to 1710.0 to 1930.0 to
frequency 893.9 to 894 890.1 880.1 1710.1 1930.1
guard bands 914.9 to 914.9 to 1784.9 to 1989.9 to
(MHz) 915.0 915.0 1785.0 1990.0
Continued
68P02901W36-S 1-13
Jul 2008
Radio channel multiplexing Chapter 1: BSS Functional Description
Table 1-4 BTS radio channel characteristics (Continued)

Parameter GSM 850 GSM 900 EGSM 900 DCS 1800 PCS 1900
Transmit Even 10ths Even 10ths Even 10ths Even 10ths Even 10ths
channel of a MHz of a MHz of a MHz of a MHz of a MHz
center from 824.2 from 935.2 from 925.2 from 1805.2 from 1930.2
frequency to 848.8 to 959.8 to 959.8 to 1879.8 to 1989.8
(MHz)
Receive Even 10ths Even 10ths Even 10ths Even 10ths Even 10ths
channel of a MHz of a MHz of a MHz of a MHz of a MHz
center from 869.2 from 890.2 from 880.2 from 1710.2 from 1850.2
frequency to 893.8 to 914.8 to 914.8 to 1784.8 to 1909.8
(MHz)
Radio channel multiplexing
Each BTS radio coverage area is allocated several RF carriers. Each RF carrier shares time
between MSs operating in the RF coverage area.
Each RF carrier consists of eight physical channels (or timeslots) used for MS
communications.
Each MS is assigned to a timeslot or part of a timeslot for AMR half-rate.
Each timeslot duration is 577 sec and contains logical channel data, which is part of
the overall data message.
The data in one timeslot is transmitted as a 546 sec data burst. Each of the eight timeslot data
bursts is transmitted in sequence over the same RF carrier TDM. This group of eight timeslot
data bursts make up a frame. The overall data message is structured in a multiframe format.
Physical channel structure
The time over the air is divided into frames, each frame being subdivided into eight timeslots,
conventionally numbered from 0 to 7. Information from a single call is sent in bursts in the same
timeslot in successive frames or in AMR half-rate mode two calls per timeslot in successive
frames. Therefore, within the duration of a frame (4.615 ms), bursts of information from eight
separate calls (up to 16 in AMR HR) can occupy the carrier. On the Air Interface, the repetitive
use of the same timeslot over a series of frames constitutes the physical channel for a call.
Logical channels
There are two types of logical channels:

Control (or signaling) channels.
Traffic channels full-rate (FR) and half-rate (HR).
Data can be transmitted on uplink (MS-to-BTS) or downlink (BTS-to-MS) logical channels.
1-14 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Logical channel groups
Control (signaling) channels
Control channels exchange control messages between the BTS and MS. There are various types
of logical control channels, each tailored for a specific purpose.
Types of logical control channels include:

Broadcast.
Common.
Dedicated (both stand alone and/or associated with user traffic).
Traffic channels
Traffic channels exchange speech or user data between the BTS and MS. The full-rate speech
transcoder operates at a vocoder rate of 13 kbps. Before radio channel transmission, the speech
data bit stream is coded with error correction or detection, giving a rate of up to 22.8 kbps.
The timeslot for a full-rate traffic channel is dedicated to a particular MS. Each of the two
half-rate subchannels per timeslot are dedicated to a particular MS. Each traffic channel has an
associated control channel on the same timeslot.
Logical channel groups
Table 1-5 shows the logical channel groups and their channels.
Table 1-5 Logical channel groups and channels
Logical channel group Channels in group Information

TCH: Traffic Channel group TCH/FS: Full rate speech or Full-Rate speech or data.
Speech or data. TCH/EFS Enhanced Half-Rate speech only.
full-rate speech
CH/AMR Adaptive Multi-Rate
speech
TCH/AFS: TCH/F with AMR
TCH/AHS: TCH/H
with AMRTCH/9.6:
Data at 9.6 kbps or
TCH/4.8: Data at 4.8 kbps or
TCH/2.4: Data at 2.4 kbps
DCCH: Dedicated Control SDCCH: Stand Information supporting call
Channel. Assigned to a single alone Dedicated setup, measurement, and
MS connection. Control Channel handover. Also dedicated
information such as
point-to-point Short Message
Service.
Continued
68P02901W36-S 1-15
Jul 2008
Logical channel groups Chapter 1: BSS Functional Description
Table 1-5 Logical channel groups and channels (Continued)

Logical channel group Channels in group Information
ACCH: Associated Control SACCH: Slow Associated Power control, timing
Channel. Control information Control Channel and neighbor information
associated with TCH or SACCH/TF: Full-Rate downlink to the MS and
DCCH. SACCH/TH: Half-Rate Receive Signal Strength
Indicator (RSSI) and
measurement reports uplink
to the BTS.
FACCH: Fast Associated Information for user
Control Channel authentication and
FACCH/F: Full-Rate handovers.
FACCH/H: Half-Rate
BCCH: Broadcast Control BCCH: Broadcast Control Cell-specific information
Channel. Control information Channel such as cell Id and list of
continually sent downlink to frequencies used.
all mobiles in the cell.
FCCH: Frequency Correction Information that allows the
Channel MS to synchronize with the
time base used in the cell.
SCH: Synchronization After using the FCCH, the
Channel MS uses the SCH for fine
synchronization with the
TDMA frame structure.
CCCH: Common Control RACH: Random Access The MS transmits a channel
Channel. Control information Control Channel request on a RACH to gain
sent between MS and BTS access to the system, that is,
for call origination and call when making a call.
paging.
PCH: Paging Channel Transmitted by the BTS to
contact a specific MS.
AGCH: Access Grant Channel Transmitted by the BTS
to assign dedicated
resources for a call.
NCH: Notification Channel Transmitted by the BTS to

inform MSs within cells.
The NCH shares resources
with the AGCH. Capacity is
affected if the NCH is heavily
utilized.
NOTE
Do not confuse the names of the channel groups with the channels themselves. Two
of the channel groups are named after the most important channel in the group: the
Traffic Channel group (TCH) takes its name from the Traffic Channel (TCH). Similarly,
the Broadcast Control Channel group (BCCH) takes its name from the Broadcast
Control Channel (BCCH).
1-16 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Logical channel combinations
Logical channel combinations
Table 1-6 shows that four channel combinations are defined, each combination identifying the
groups of logical channels that share a physical channel. One channel combination is for traffic,
that is, speech or data, with some control information. The other three channel combinations
are for control information only.
Table 1-6 Logical channel combinations
This channel combination Can contain these channel groups

Traffic Channel combination TCH, ACCH
Dedicated Control Channel combination DCCH, ACCH
Broadcast Control Channel combination BCCH, CCCH
Combined Control Channel combination BCCH, CCCH, DCCH
Physical channel allocation
Within each channel combination, the individual channels require their fair share of the physical
channel. Each channel takes its turn according to a cyclically repeated pattern of frames.
For example, in the Traffic Channel combination, SACCH is intermixed with traffic (TCH).
Multiframe, a repeated pattern of 26 frames defines the intervals between SACCH bursts.
Within this, the SACCH is sent in every 12th frame in AMR half-rate mode the SACCH/TH is
sent on the frame 12 for subchannel 0 and on frame 26 for subchannel 1. The control channel
combinations use a 51-multiframe.
The hierarchy extends to repeat patterns of multiframes, called superframes, which define when
the frames are realigned and repeat patterns of superframes, called hyperframes, which are
used to restart ciphering and other algorithms.
FACCH
The FACCH channel is an exception in that it does not use multiframes. It intermittently steals
time in Traffic Channel bursts.
CBCH
Another channel type, called the Cell Broadcast Channel (CBCH), is not shown in the table.
Like the FACCH, the CBCH does not use multiframes, but steals time from the SDCCH. It is
used to broadcast information to all MSs within a cell (for example, broadcast Short Message
Service information).
Logical channel summary
Figure 1-5 shows a summary of logical channels, channel groups, and combinations.
68P02901W36-S 1-17
Jul 2008
GPRS traffic and control channels Chapter 1: BSS Functional Description
Figure 1-5 Logical channels, channel groups, and combinations
GPRS traffic and control channels
Packet control channels
Like GSM circuit switched channels, there are two main groups of packet logical channels:
traffic channels and control channels.
Packet Common Control Channel (PCCCH)-a set of logical channels used for common
signaling:
Packet Random Access Channel (PRACH)-uplink only, mapped on a PDCH or the
RACH.
Packet Paging Channel (PPCH)-downlink only, mapped on a PDCH or the PCH.
Packet Access Grant Channel (PAGCH)-downlink only, mapped on a PDCH or AGCH.
Packet Notification Channel (PNCH)-downlink only.
Packet Broadcast Control Channel (PBCCH)-a logical channel used to broadcast packet
data-specific system information. If not allocated, the packet data-specific information is
broadcast on the BCCH. The PBCCH is downlink only.
Details of processing of the PBCCH and PCCCH during calls are described in Chapter 6 Call
Processing of this manual.
Packet Random Access Channel (PRACH)
This channel is used in the uplink direction only to initiate uplink transfer of data, or to respond
to a paging message. The PRACH also contains timing advance information.
1-18 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GPRS traffic and control channels
Packet Paging Channel (PPCH)
This channel is used in the downlink direction only to page GPRS MSs, when packet data is
to be sent. PPCH uses paging groups to allow DRX (Discontinuous Reception). The PPCH can
be used for paging MSs in circuit switched or packet switched modes but only for class A MSs
(simultaneous circuit switched and packet switched capability) or class B MSs (sequential, but
not simultaneous, circuit switched and packet switched capability).
NOTE
Additionally, an MS that is currently engaged in packet transfer can be paged for
circuit switched services on a PACCH.
Packet Access Grant Channel (PAGCH)
This channel is used in the establishment phase of a packet transfer to send resource assignment
messages to an MS before transferring packet.
NOTE
If the MS is currently involved in a packet transfer, additional resource management
messages can be sent on the PACCH.
Packet Notification Channel (PNCH)
This channel is used to send a Point-To-Multipoint Multicast (PTM-M) notification (downlink) to

a group of MSs prior to a PTM-M packet transfer. The notification takes the form of a resource
assignment for packet transfer.
Packet Data Traffic Channel (PDTCH)
This channel is used for packet data transfer, uplink, and downlink. It is dedicated to one MS or
a group of MSs in the PTM-M case. In multislot operation, one MS can use multiple PDTCHs
in parallel for an individual packet transfer.
Packet Access Control Channels (PACCHs) are logically mapped on to the PDTCH to convey
signaling information related to a specific MS in uplink and downlink. This information can
include ACKnowledegments and/or No-ACKnowledgments, power control information, and
resource reassignments. One PACCH is associated with one or several PDTCHs that are
currently assigned to one MS.
68P02901W36-S 1-19
Jul 2008
Time division multiple access Chapter 1: BSS Functional Description
Time division multiple access
MS accesses an RF carrier on a Time Division Multiple Access (TDMA) timeslot basis.
While it is sending on the uplink, the entire data rate capacity (22.8 kbps) of the BTS site
transceiver is available to the MS. Then, the MS must stop sending for a short time to give
other MSs access to the transceiver.
The information flows to the BTS site in frames. Each frame contains one TDMA burst of
information from each MS given access to the single transceiver.
Figure 1-6 shows a burst of information in frame 1, being sent over a channel using timeslot
6. The next burst using that channel is transmitted in timeslot 6 of the next frame, and so on.
The use of a frame structure in this way is known as TDMA.
Figure 1-6 TDMA timeslot information burst
5 7
The BTS sends to the mobile station on the downlink in a similar manner and broadcasts
information that allows the MSs to synchronize with the timing of the TDMA frame structure
within the cell.
1-20 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Time division multiple access
Timeslot characteristics
Figure 1-7 shows the logical channel timeslot format and the timeslot/frame/multiframe
structure.
Figure 1-7 Logical channel timeslot format and timeslot/frame/multiframe structure
The sum of the individual burst durations is less than the frame time to give some guard time
between bursts.
68P02901W36-S 1-21
Jul 2008
Time division multiple access Chapter 1: BSS Functional Description
Burst structure
Figure 1-8 shows the structure of different types of bursts that are used to send information.
The most common type is the normal burst. The receiver uses this training sequence for
equalizing the incoming signal, as described in Receiver channel equalization on page 1-25 of
this chapter. Each stealing flag indicates if half of the traffic channel block has been stolen by a
FACCH or, in the case of a Dedicated Channel Combination, by a CBCH. The tail bits denote the
beginning and end of the block of information.
Figure 1-8 Burst structures
T T
B B
T T
B B
T T
B GP
B
T T GP
B B
57 26 57
T
T B
B 41
1-22 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Modulation
Guard period
The information in the burst is always of a shorter duration than the timeslot. A normal burst,
for example, takes 0.546 ms to transmit, while the timeslot in which it is transmitted is
0.577 ms long. The difference between them is known as a guard period and gives a normal
burst a latitude of 31s for hitting the timeslot. Except for the access burst, all bursts are the
same length. An access burst is much shorter because the MS uses it to make contact with the
BTS when initiating a call. The MS is at an unknown distance from the BTS, so the guard period
allows time for the signal to reach the BTS.
Uses of burst types
Table 1-7 shows the uses for the different types of bursts.
Table 1-7 Burst types and uses
Burst type Use Direction Channels carried

Normal burst Carries traffic Uplink and downlink TCH, SDCCH,
channels and all FACCH, SACCH
control channels,
Downlink PCH, AGCH, CBCH,
except those
BCCH
described below.
Frequency Correction Carries FCCH Downlink FCCH
burst downlink to correct
the frequency of the
MS, locking it to the
BTS frequency.
Synchronization burst Carries SCH downlink Downlink SCH
to synchronize the
timing of the MS to
the BTS timing.
Dummy burst Used when there is Downlink BCCH
no information to be
carried on the unused
timeslots of the BCCH
carrier.
Access burst Carries RACH uplink Uplink RACH
from the MS to the
BTS to start a call,
that is, it is used by
the MS to access the
BTS.
Modulation
Manchester-encoded Non-Return to Zero (NRZ) data is applied to the Gaussian Minimum Shift
Keying (GMSK) modulator, which generates a digital representation of the modulated carrier.
This digital representation is converted to an analog waveform.
68P02901W36-S 1-23
Jul 2008
Multipath fading Chapter 1: BSS Functional Description
The analog waveform is up-converted and frequency multiplied to yield a GMSK modulated RF
carrier signal in the GSM 900, EGSM 900, DCS 1800 or DCS 1900 transmit frequency range.
The radio channel uses a gross bit rate of 270.833 kbps.
GMSK modulation is a form of phase modulation that allows the high-speed data to be sent
within an optimized bandwidth. This technique also provides improved modulation sensitivity
and carrier to interference robustness, with lower adjacent channel interference than similar
modulation techniques.
Multipath fading
GSM provides features to overcome multipath fading. The signal between the transmitter and
the receiver travels by multiple paths. Multipaths are produced by signal reflections caused by
the terrain in which the equipment is being used and the prevailing atmospheric conditions.
The received signal is the sum of the different copies of the transmitted signal, each copy
reaching its destination at a different time.
The difference between the multiple times of reception of a given bit symbol (the time
dispersion) is often longer than the 3.70 s duration of the bit symbol itself when it was
originally transmitted. A GSM system must be able to distinguish one bit from the next despite
these problems, so sophisticated equalization techniques are employed to eliminate the effects
of inter-symbol interference.
Optimized power control
Flexible power steps
The flexibility in defining power steps is added by allowing uplink and downlink power step sizes
to be controlled separately. This is done by creating two increment and decrement step size
elements, one pair each for uplink and downlink directions.
Extended range for increment step size
The range of the power control steps for increments is extended, to allow for a range of 2, 4,
6, 8, 10, 12 dB and 14 dB in both uplink and downlink directions. This allows the power to
be brought back into the power box (the acceptable power range) quickly if it suddenly falls
below the acceptable range.
Dynamic step adjust procedures
Power increment and reduction step sizes are allowed to change dynamically (if the algorithm is
enabled), based on the current power level and proximity to lower and upper power level and
quality thresholds. This allows the power to be brought up or down at a faster rate when it has
strayed out of the power box or quality box.
1-24 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Receiver channel equalization
Downlink oscillation control
Power oscillation occurs when a decision to reduce power due to good quality is immediately
followed by a decision to increase power due to a low-power level. To prevent unnecessary
power changes, oscillation must be detected and controlled. Oscillation prevention exists for
uplink power control, but the Optimized Power Control feature extends this to downlink power
control using a different algorithm (from the uplink oscillation control algorithm).
Receiver channel equalization
The effects of more than one RF path are present in many of the typical RF coverage areas.
More than one path occurs when an MS is sending a TDMA burst to the BTS site. The delay time
between the different path signals causes them to be slightly out of phase. Some cancellation
of the out-of-phase signals causes the composite received signal strength to be weak and the
recovered data is distorted. Distortion of the recovered data causes data errors.
Receiver channel equalization uses a training sequence, embedded in every transmitted TDMA
burst. The receiver synchronizes to this sequence and uses it to estimate the effects of multipath
fading, the received signal strength and data timing error. As part of the equalization process,
the receiver is able to select the best of the multiple signal paths and this ability to choose
reduces the likelihood of total signal loss.
Adjustments
The equalizer uses this estimate to adjust the receiver signal gain and data timing. These
adjustments minimize the effects of distortion and allow proper recovery of data.
The equalizer can compensate for up to 16 sec of excess multipath delay.
Channel equalization is performed on each TDMA burst.
Using receiver diversity combining can improve channel equalization performance.
Receiver diversity
Receiver diversity reduces the detrimental effects of multipath fading by having two physically
separated receiver antennas and taking advantage of the fact that their received signals are
uncorrelated. In this way, reliable reception can be maintained, even during conditions of
deep fading.
{27236} The 4 branch receive diversity feature enables the CTU2 to receive inputs from four
antennas and route those signals to independent receiver inputs.
Receiver performance
The GSM recommendations specify four dynamic models against which the performance of a
GSM receiver can be measured. Each model consists of a set of weighted and differentially
delayed signal paths. The models are:
TU3 (Typical urban, with the MS traveling at 3 kph).
TU50 (Typical urban, with the MS traveling at 50 kph).
68P02901W36-S 1-25
Jul 2008
Channel coding Chapter 1: BSS Functional Description
HT100 (Hilly terrain, with the MS traveling at 100 kph).
RA250 (Rural area, with the MS traveling at 250 kph).
The signal delay spread of these models range from 0.1 s to 5 s with maximum excess delays
varying from 0.5 s to 20 s. In addition to these models, a static model is defined and also a
model called EQ50 which is for testing the performance of the equalizer to extremes.
Channel coding
Channel coding optimizes logical channel traffic and signaling data for proper communications
over the radio channel.
Channel coding incorporates:

Block coding to provide error detection and correction.
Convolution coding to provide protection. The underlying principle of convolutional coding

is that of multiplying the original information so that the receiver has a better chance of
filling in any gaps that can result from transmission problems. The 1/2 convolutional code
generates two bits of information from each original bit.
Data interleaving to maximize the effectiveness of coding in the burst noise and
interference radio environment.
Channel coding also maps the logical traffic or signaling channel to the physical channel
(timeslot). The exact channel coding is slightly different for speech traffic, data traffic, and
signaling channel data.
Speech traffic channel data coding
This section describes channel coding for speech traffic channel data. Data traffic and control
signaling channel data are coded in a similar manner.
There are eight logical channel coders for every radio channel, one logical channel coder per
timeslot. Table 1-8 shows how the channel coders work.
Table 1-8 Channel coder processes
Stage Action
1 Each channel coder receives a 260-bit speech frame from the transcoder
every 20 ms (for logical channel).
See Full rate speech coding on page 1-27 for more information on speech frames.
2 The speech frame's 260 bits are coded using block and convolution coding for error
detection and redundancy. Each coded block contains 456 bits.
3 The block of 456 coded speech bits is partitioned into eight groups.
4 Four groups are interleaved with information from the preceding coded speech block.
Continued
1-26 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Full rate speech coding
Table 1-8 Channel coder processes (Continued)

Stage Action
5 The interleaved data is sent over the radio channel in four TDMA bursts (timeslots)
for four consecutive frames. Encryption can be applied to the individual information
bursts.
6 The remaining four groups are interleaved with information from the succeeding
coded speech block and are sent during the succeeding blocks.
Although interleaving data introduces some audio delay, it spreads the information of a single
20 ms speech segment over 40 ms of actual radio channel transmission. This enhances the
performance of the error correction decoding and frequency hopping.
Full rate speech coding
In existing GSM systems, speech is digitally encoded using a speech coding scheme called
Regular Pulse Excitation Linear Predictive Coding incorporating Long Term Prediction (RPE-LPC
or LTP). It operates at an uncoded rate of 13 kbps and, before radio channel transmission, is
coded up to 22.8 kbps (including error detection and correction).
The 64 kbps PCM channels from the land network are applied to the speech transcoder. The
speech transcoder accumulates a 20 ms block of speech data (64 kbps) consisting of 1280 bits
(160 PCM samples). The 20 ms speech block is coded using the RPE-LPC or LTP encoding
process, to produce a speech block of 260 bits. The 260 bits are routed to and processed by the
appropriate channel coder.
Bit protection
Of these 260 bits, some represent information that is critical for speech intelligibility, while
others are less important (representing, for instance, the extremes of amplitude of the signal).
The encoder identifies three classes of bits in the 260-bit block and protects the most important
ones, as follows:
50 Class 1a bits. These are critical for speech intelligibility, so the encoder creates three
parity bits from them and adds these to the block. If a parity error is detected, the whole
block is ignored.
132 Class 1b bits. These bits are of intermediate importance. The receiver uses four tail
bits which are added to set the registers to a known state for decoding purposes. Class
1b bits are not parity checked.
78 Class 2 bits. These are the least sensitive bits and are not protected in any way.
Redundancy
Redundancy is added to the Class 1a and 1b bits with a rate 1/2 convolutional code.
68P02901W36-S 1-27
Jul 2008
Full rate interleaving Chapter 1: BSS Functional Description
Speech channel protection and encoding
Figure 1-9 shows protection and encoding on the speech channel.
Figure 1-9 Channel protection and encoding
3 4
Full rate interleaving
Digital encoding results in blocks of 456 bits. The information from these blocks is then divided
and spread over a series of bursts to make it more resistant to transmission errors. This process
is called interleaving. The 456 bits from each block are partitioned into eight groups of 57 bits
each. Separation of the odd from the even bits destroys the proximity of successive bits: four of
the 57-bit groups hold even bits while the other four hold odd bits.
Four 57-bit groups are interleaved with information from the preceding speech block and
sent in four TDMA timeslots for four consecutive frames over the channel. The remaining
four groups are interleaved with information from the succeeding speech block and sent over
the subsequent four TDMA frames.
This is illustrated in Figure 1-10, where the information from speech block 5 is transmitted in
eight bursts and is interleaved with information from speech blocks 4 and 6 (The arrows identify
the bursts in which the information is sent, but not where the bits are put in the burst). The
bursts are transmitted in a traffic channel that is using timeslot 4 of the TDMA frame structure.
1-28 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Full rate interleaving
Figure 1-10 shows in simplified form the interleaving scheme for full-rate speech. Other types of
interleaving are used for the other types of information transmitted across the Air Interface.
Figure 1-10 Interleaving scheme for speech
Information spreading
The interleaving, although introducing some audio delay, spreads the information of a single 20
ms speech segment over less than 40 ms of actual radio channel transmission. This enhances
the performance of the error correction decoding. The information can then be encrypted.
Interleaving depth
The number of bursts across which a 456-bit block of information is spread is called the
interleaving depth. The greater this figure, the easier it is for the receiver to perform error
correction. Speech data has an interleaving depth of 8. Data transmitted on a 9.6 kbps channel
has an interleaving depth of 22. That is, the 456-bit block is spread across 22 bursts. The
interleaving depth is restricted only by the delay it introduces. The delay must be restricted for
speech traffic, otherwise it becomes unacceptable to the user. A greater delay can be tolerated
on channels carrying data.
68P02901W36-S 1-29
Jul 2008
Half rate interleaving Chapter 1: BSS Functional Description
Half rate interleaving
Digital encoding results in blocks of 228 bits. The information from these blocks is then divided
and spread over a series of bursts to make it more resistant to transmission errors. This process
is called interleaving. The 228 bits from each block are partitioned into four groups of 57 bits
each. The proximity of successive bits is overcome by separation of the odd from the even bits:
two of the 57-bit groups hold even bits while the other two hold odd bits.
Two 57-bit groups are interleaved with information from the preceding speech block and sent in
two TDMA timeslots for two consecutive frames over the channel. The remaining two groups
are interleaved with information from the succeeding speech block and sent over a subsequent
two TDMA frames.
This is illustrated in the figure below, where the information from speech block 5 is transmitted
in four bursts and is interleaved with information from speech blocks 4 and 6 (The arrows
identify which bursts the information is sent in, not where, in the burst, the bits are put). The
bursts are transmitted in a traffic channel that is using timeslot 4 of the TDMA frame structure.
Information spreading
The interleaving, although introducing some audio delay, spreads the information of a single 20
ms speech segment over just under 40 ms of actual radio channel transmission. This enhances
the performance of the error correction decoding. The information can then be encrypted.
Interleaving depth
The number of bursts across which a 228-bit block of information is spread is called the
interleaving depth. The greater this figure, the easier it is for the receiver to perform error
correction. HR speech data has an interleaving depth of 4. The interleaving depth is restricted
only by the delay it introduces. The delay must be restricted for speech traffic, otherwise it
becomes unacceptable to the user. A greater delay can be tolerated on channels carrying data.
Frequency hopping
Every burst transmitted over the Air Interface can be sent on a different RF carrier frequency.
This is called frequency hopping.
Frequency hopping lets the RF channel frequency, used for traffic channel data, change every
frame (or 4.615 ms). This capability provides a high degree of immunity to interference and
fading.
Both the BTS and the MS retune to a new frequency according to a predefined frequency
hopping algorithm.
A BTS uses the following methods for frequency hopping:

Synthesizer hopping, in which the transceiver involved changes frequency. The MS just
uses synthesizer hopping. All MSs can hop frequencies under the control of the BSS.
Baseband hopping, in which each transceiver at the base station is tuned to a different
frequency and the signal is switched to a different transceiver for each burst.
To implement this feature, the BSS must be equipped with the frequency hopping option.
Network operators can select cyclic or pseudo random frequency hopping patterns.
1-30 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Adaptive Multi-Rate radio interface and timeslot allocation
Interference
Most interference is caused by the cellular system itself, in the form of co-channel interference
and adjacent channel interference. If the RF channel changes frequency every frame due to
hopping then the source and type of interference is also changed every frame, so that the
interference is not high for every frame. Therefore, the average interference experienced by
each channel is minimized. If two MSs are interfering with each other, by hopping differently,
their effect upon each other is minimized.
Fading
Fading is frequency-selective. That is, different frequencies are affected to different degrees by
multipath fading. Since each carrier has a different frequency, the presence of fading on one
carrier has a smaller impact on other carriers.
Adaptive Multi-Rate radio interface and timeslot allocation
Adaptive Multi-Rate (AMR) link adaptation provides a mechanism for the BSS to adapt between
speech codec modes in an AMR codec on the uplink and downlink of an AMR full or half-rate
call. This mechanism, working in conjunction with other congestion or speech quality decision
and error correction features, provides the most suitable level of error correction for the RF
environment. Speech quality is improved by reducing the speech rate and increasing the level
of error correction in poor RF environments. Uplink and downlink codec modes are considered
separately and can be adapted separately.
Timeslot configuration
Implementation of the AMR HR channel mode introduces the concept of a generic timeslot. A
generic timeslot can be assigned one FR (FR, EFR, or AFS) call or up to two AMR HR calls
(AHS). The HR capable timeslot is only known as a generic traffic timeslot when it is not in use.
When the BSS brings an AMR HR carrier into service, all traffic timeslots on that carrier are
considered generic traffic timeslots. The traffic timeslots are placed into a list for allocation
of AMR HR (or FR) calls. Call assignments for the carrier are performed on the basis of idle
interference measurements. These measurements are reported on an FR timeslot basis, until
either an FR or HR call is assigned. The term AMR HR carrier refers to an AMR HR enabled RTF.
When the BSS brings an air interface timeslot into service, a physical timeslot configuration
message is sent to the CCU. This message allows the CCU to set up the appropriate TRAU
mappings and logical channel configuration. When physically configuring a generic timeslot,
the BSS indicates to the CCU that the timeslot is FR capable (indicating that idle interference
measurements are performed on a full timeslot basis).
When physically configuring a generic timeslot during initialization, BSS indicates that idle
interference measurements must be reported on a full timeslot basis to the CCU. When
assigning an HR call to a timeslot, the timeslot is configured for reporting idle interference
measurements on a sub channel basis. As stated, an HR capable timeslot can be used to carry
an FR call (if there are no calls already assigned to that timeslot). An HR capable timeslot is
known as an FR traffic timeslot when it is assigned an FR call. When an FR call is released from
an HR capable timeslot, that timeslot is no longer be in use and as such is again known as
a generic traffic timeslot.
68P02901W36-S 1-31
Jul 2008
Adaptive Multi-Rate radio interface and timeslot allocation Chapter 1: BSS Functional Description
The BSS only assigns an FR call to a generic timeslot when there are no sub channels already
active on that timeslot. The BSS considers an HR capable timeslot as a generic traffic timeslot
after releasing an FR call from that timeslot. An HR capable timeslot can also be used to carry
up to two AMR HR calls (when there is no FR call assigned to that timeslot). An HR capable
timeslot is known as an HR traffic timeslot when it is assigned one or more AMR HR calls. The
HR traffic timeslot remains an HR traffic timeslot until there are no AMR HR calls assigned to it.
The timeslot is then no longer in use and so known as a generic traffic timeslot.
The BSS only assigns an AMR HR call to a generic timeslot or a timeslot in use by one HR
call. The BSS considers a generic timeslot as one idle and one in-use HR traffic channel after
assigning an AMR HR call to that timeslot.
NOTE
When assigning an AMR HR call to a timeslot that already has an AMR HR call
assigned, the timeslot is configured as an HR traffic timeslot.
The BSS considers an HR timeslot as a generic traffic timeslot after releasing an AMR HR
call from that timeslot, if the call was the only call assigned to that timeslot. An FR traffic
channel is the logical channel implemented upon an FR traffic timeslot. FR traffic channels on
an in-service carrier are classified as either free, in use, or unavailable. A free FR traffic channel
is an idle FR traffic channel that is usable and has no call assigned to it. An in-use FR traffic
channel is an FR traffic channel that has a call assigned to it. An unavailable FR traffic channel
is an idle FR traffic channel that is not usable.
An idle FR traffic channel is regarded as unavailable if the FR traffic timeslot upon which
it is implemented is:
On a BCCH carrier that is configured to perform synthesizer hopping.
An unused timeslot of a sub-equipped carrier.
Undergoing frequency hopping reconfiguration.
Undergoing reconfiguration to or from an SDCCH timeslot.
Undergoing reconfiguration to or from a GPRS switchable timeslot.
An HR traffic channel is the logical channel implemented on an HR traffic timeslot sub channel.
Classification of HR traffic channels in terms of the free, in use and unavailable categories
is like that of FR traffic channels.
A free HR traffic channel is an HR traffic channel that is usable and has no call assigned to it. An
in use HR traffic channel is an HR traffic channel that has a call assigned to it. An unavailable
HR traffic channel is an HR traffic channel that is not usable.
HR traffic channels only exist on HR traffic timeslots. HR traffic timeslots always have one or
more HR calls assigned to them by definition. Since idle HR traffic channels only exist upon
traffic timeslots that have a single AMR HR call assigned to them, an HR traffic channel can
never be unavailable due to the reasons stated above, except during frequency hopping. If
frequency hopping is in progress on one HR traffic channel, the other channel on the timeslot
must be in use and undergoing frequency hopping redefinition.
Generic traffic timeslots are regarded as unavailable due to the reasons stated above.
1-32 68P02901W36-S
Jul 2008
NOTE
AMR HR carriers cannot be sub-equipped.
Resource selection criteria-idle interference measurements
The BSS monitors interference levels on all idle FR traffic timeslots. Each idle timeslot is placed
into an interference band class. There are six interference band classes; a timeslot that does not
fall into any of the first five classes is placed into the sixth class. The boundaries of the first five
interference band classes are defined by the operator in the BSS database.
When selecting a channel to allocate to a call, the BSS is chosen as an idle traffic timeslot from a
lower interference band class in preference to a channel from a higher interference band class.
The BSS does not allocate an idle timeslot from the sixth interference band class. Generic
timeslots are initially configured as FR channels at the CCU, in order that idle interference
measurements be reported on a full timeslot basis. A generic traffic timeslot can be logically
configured at the CCU as an HR traffic timeslot if an HR call is to be assigned or remain
as an FR traffic timeslot in the case of an FR call. The CCU reports the interference on idle
measurements to the BSS based upon the previous channel configuration.
If the previous channel configuration was as an HR capable timeslot and the BSS now considers
the timeslot as a generic timeslot the CCU reports the interference on idle measurements on a
sub channel basis. If the previous channel configuration was as FR capable, the CCU reports
the interference on idle measurements on a timeslot basis. In either case, the BSS reports the
interference on idle measurements of a generic timeslot on a timeslot basis to the operator.
A free generic traffic timeslot is considered an FR traffic timeslot for the purposes of determining
the interference band class for the timeslot. With AMR HR, each idle HR traffic channel is also
placed into one of six interference band classes. The boundaries of the interference band classes
for idle HR traffic channels are the same as those for idle FR traffic timeslots.
The BSS uses sub channel based idle interference measurements received from the CCU to
determine the interference band class to place idle HR traffic channels. As for FR traffic channel
selection, the BSS does not select HR traffic channels from the sixth interference band.
The BSS does not allocate an idle HR traffic channel from the sixth interference band class for
an AMR HR call. Prior to the BSS reporting the first idle interference band measurement for
the channel, the channel is not placed in an interference band, it is identified as having an
unknown interference band.
Channels with unknown interference bands are available for selection. Based on the range of
interference bands allowed by the MSC, unknown interference bands are considered after the
worst interference band within the specified range.
Full rate configuration
The AMR full-rate channel is a full-rate channel that employs an AMR speech codec to provide
higher speech quality in areas of poor RF conditions.
AMR FR channel mode is available only if the AMR FR channel mode is enabled at the BSS
level. If so, the BSS also provides a cell level AMR FR switch to allow the operator to control
AMR FR channel mode usage at the cell level.
68P02901W36-S 1-33
Jul 2008
Adaptive Multi-Rate radio interface and timeslot allocation Chapter 1: BSS Functional Description
Half rate configuration
The AMR half-rate channel is a half-rate channel that employs an AMR speech codec to provide
higher speech quality in areas of poor RF conditions.
AMR Half-Rate (HR) channel mode is available only if the AMR feature is unrestricted. If so, the
BSS provides a BSS level AMR HR switch to allow the operator to control AMR HR channel
mode enable or disable.
AMR HR channel mode is available only if the AMR HR channel mode is enabled at the BSS
level. If so, the BSS also provides a cell level AMR HR switch to allow the operator to control
AMR HR channel mode usage at the cell level on a per cell basis.
Full rate channel configuration
Full-Rate (FR) calls are supported through the TCH/F + FACCH/F + SACCH/TF logical channel
configuration. Figure 1-11 illustrates how a full-rate channel uses frames 0 to 11 and 13 to 24 of
the traffic multiframe (26 frame, multiframe) for TCH bursts and frame 12 for SACCH bursts.
A SACCH multiframe has four 26 multiframes, which are needed to send a message through
SACCH. Since each 26 multiframe is 120 ms in duration, the SACCH multiframe is 480 ms in
duration. The uplink SACCH is primarily used for sending measurement reports to the BSS and
so, the SACCH measurement report period is 480 ms.
Figure 1-11 Full rate traffic multiframe
0 1 2 3 4 5 6 7 8 9
0 1 2 3 4 5 6 7 8 9
Half rate channel allocation
Half-Rate (HR) calls are supported by the TCH/H(0,1) + FACCH/H(0,1) + SACCH/TH(0,1).

Figure 1-12 illustrates that, for HR channels, the same frames of the 26-multiframe are used for
TCH bursts. However, alternate TCH bursts correspond to alternate HR channels. The SACCH
measurement report period for HR channels is not different from that of FR channels. Frame 12
of the 26 multiframe is used for SACCH bursts for the HR channel on air timeslot sub channel 0
and the previously unused frame 25 of the 26-multiframe is used for SACCH bursts for the HR
channel on air interface timeslot sub channel 1.
1-34 68P02901W36-S
Jul 2008
Figure 1-12 Half rate traffic multiframe
BSS support
In order for the BSS to support the AMR HR channel mode, the BSS must support the TCH/H(0,1)
+ FACCH/H(0,1) + SACCH/TH(0,1) logical channel configuration. HR calls are supported on
both sub channels of the channels combinations. SACCH measurements, generated by the CCU
every 480 ms, are processed by the BSS for each AMR HR call on an AMR HR carrier.
In order to allow idle HR traffic channels to be placed in interference band classes, idle
interference measurements are reported on a per sub channel basis for air interface timeslots
that are configured as AMR HR traffic timeslots (where the other half of the timeslot is in use).
Idle interference measurement reports, generated by the CCU every 480 ms, are processed by
the BSS for each idle AMR HR channel on an AMR HR carrier.
Traffic channel related communication between the BSS and the CCU is modified so that,
for AMR HR channels, both the BSS and the CCU can identify the air interface timeslot sub
channel that is communicating.
The assignment command, handover command, and channel mode modify layer-3 radio resource
management messages containing information elements that need to be coded to identify the
assigned channel as an AMR HR traffic channel as follows:
Channel mode and TDMA offsets (all messages), indicates a TCH/AHS.
Multi-rate configuration (assignment command message only), if the channel mode of the
first channel information element indicates a TCHAS.
68P02901W36-S 1-35
Jul 2008
Adaptive Multi-Rate link adaptation Chapter 1: BSS Functional Description
The multi-rate configuration information sent to the MS within the assignment command
message contains the downlink multi-rate configuration for the channel.
NOTE
The multi-rate configuration information element is still sent within the assignment
command even though the link adaptation functionality is disabled.
The multi-rate configuration information element is only included in the assignment or handover
command message if the BSS detects that the multi-rate configuration is different from the
multi-rate configuration used for the current channel. This statement is true, unless an intra-cell
handover (FR or HR) is in progress.
The multi-rate configuration information element is included in the Handover Command

message if the channel mode of the first channel information element indicates a TCH/AHS. The
multi-rate configuration information sent to the MS within the Handover Command message
contains the downlink multi-rate configuration for the channel.
NOTE
The multi-rate configuration information element will still be sent within the handover
command even though the link adaptation functionality is disabled.
Codec modes
The codec modes, as specified in the ACS, the ICM and downlink codec mode adaptation
thresholds and hysteresis values specified in the database of FR and HR AMR calls, are signaled
to the mobile in the assignment command, channel mode modify and the handover command.
Adaptive Multi-Rate link adaptation
AMR link adaptation provides the mechanism for the BSS to adapt between speech codec modes
in an AMR codec on the uplink and downlink of an AMR full or half-rate call. This mechanism,
working in conjunction with other congestion or speech quality decision and error correction
features, provides the most suitable level of error correction for the RF environment. Speech
quality is improved by reducing the speech rate and increasing the level of error correction
when in poor RF environments. Uplink and downlink codec modes are considered separately
and can be adapted separately.
Codec modes
Up to four codec modes can be placed in the per cell full or half-rate Active Codec Set (ACS).
In UL, the call is adapted over this active codec set, according to the Carrier to Interference
(C/I) ratio calculated from the quality of the link between the MS and the BSS and speech
quality based on FER measurement.
Table 1-9 gives the codec modes supported for both full and half-rate.
1-36 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Adaptive Multi-Rate link adaptation
Table 1-9 Supported Codec modes
Adaptive Speech (kbps)

Full rate (AFS) Half rate (AHS)
12.20 7.95
10.20 7.40
7.40 6.70
6.70 5.90
5.15 5.15
The higher the bit rate of the codec mode indicated the higher the speech rate and the lower the
error correction capacity. Up to four of these codec modes can be included in the ACS.
Link adaptation on the AMR channel is applied across the AMR ACS. Figure 1-13 illustrates
the four codec modes and their associated threshold and hysteresis. For each pair of codec
modes there is an associated threshold and hysteresis value. The sum of the 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 C/I values. Table 1-10 identifies the meanings of the codec modes specified
in Figure 1-13.
Threshold levels vary between full and half-rate adaptation and frequency hopping.
Figure 1-13 C/I adaptation thresholds and the Active Codec Set (ACS) (uplink
example)
68P02901W36-S 1-37
Jul 2008
Adaptive Multi-Rate link adaptation Chapter 1: BSS Functional Description
Table 1-10 Identification of the codec modes within the Active Codec Set
Codec Mode Identifier Description

CODEC_MODE_1 Represents the lowest codec mode (lowest speech bit rate, highest
error correction bit rate) of the ACS.
CODEC_MODE_2 Represents the second lowest codec mode, if the ACS contains
more than one codec modes.
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 ACS, initial codec mode, and the associated codec mode adaptation threshold and hysteresis
values to be used are communicated to the MS and the channel coder on call initialization
and handover.
NOTE
The higher the codec mode the lower the assigned parameter.
Error correction levels
AMR codecs provide different levels of error correction and allow different channel bit error
rates for acceptable quality of service. At the lowest codec mode (low speech rate, high error
correction) a larger channel BER can be acceptable as more of the errors are corrected,
whereas in a higher codec mode a larger channel BER would be unacceptable as less errors are
corrected. The differences in AMR channel characteristics prompt the introduction for a new
set of Handover Decision Power Control (HDPC) RXQUAL algorithm thresholds.
The new HDPC parameters are specific to AMR full-rate calls and utilize the existing GSM
handover and power control algorithms. The new HDPC parameters allow an AMR full-rate
capable cell to be tailored for AMR full-rate capable MSs with the following effects:
Increased the range of cells and improved service in poor coverage areas.
Minimized interference levels to improve speech quality.
Increased capacity (through tighter reuse of frequencies).
Increased service quality by lowering the number of handovers for AMR full-rate.
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.
The new half-rate AMR handover and power control rxqual thresholds are different from the
full-rate AMR handover and power control thresholds because the half-rate channel has fewer
bits than a full-rate AMR channel. For these reasons, handover and power control algorithms
are configured in a different manner to cater to the half-rate AMR channel.
1-38 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Adaptive Multi-Rate link adaptation
MS monitoring
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
they are using.
The threshold and hysteresis values supplied for AMR calls by the network at call initialization
can 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 an MS during a call and detecting conditions that indicate
that the downlink codec mode adaptation thresholds need adjusting. The MS monitor decreases
the thresholds at the MS if they are deemed to be too high and increases the thresholds if
they appear to be too low.
NOTE
Calculate the average value of rxqual reported by the MS and record the CMRs
received over the Monitor Period. Adjustment of the MS monitor arithmetic is
triggered under the following conditions:
If... Then...
the percentage value of the Monitor Period is MS monitor adjustment arithmetic is
at least equal to amr_ms_high_cmr when the triggered at the end of the monitor
mobile has requested the Highest Codec Rate period.
and the average reported rxqual over the Monitor
Period is greater than amr_ms_high_rxqual.
the percentage value of the Monitor Period is MS monitor adjustment arithmetic is
at least equal to amr_ms_low_cmr when the triggered at the end of the monitor
mobile has requested the Lowest Codec Rate and period.
the average reported rxqual over the Monitor
Period is less than amr_ms_low_rxqual.
If thresholds of an MS are too low, that is the range of C/I values that the MS is measuring is
below the lowest threshold in the ACS then the MS requests the lowest codec mode while
simultaneously indicating to the network that the call is in good RF quality conditions. The MS
can operate 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 are modified in the MS. Similarly, the MS
monitor increases the thresholds at the MS if the network sees that the MS is requesting the
highest codec mode, while indicating that the call is in poor RF quality conditions. This would
indicate that the range of C/I values measured by the MS were above the highest threshold in
the ACS.
68P02901W36-S 1-39
Jul 2008
EGPRS air interface timeslot configurations Chapter 1: BSS Functional Description
EGPRS air interface timeslot configurations
All features that are able to preempt switchable and reserved air timeslots are able to preempt
air timeslots that are allocated 64 kbps terrestrial channels.
The directed retry, congestion relief, multiband, dynamic reconfiguration, and emergency call
preemption procedures are able to preempt air timeslots that are allocated 64 kbps terrestrial
timeslots in the same manner as preempting air timeslots that are allocated 16 kbps or 32
kbps terrestrial channels.
When configuring the reserved timeslots in a cell, the BSS configures PBCCH timeslots first,
then 64 kbps timeslots followed by 32 kbps timeslots and then 16 kbps. After configuring
all reserved timeslots the BSS configures 64 kbps switchable timeslots before configuring
32 kbps and then 16 kbps.
The BSS configures PBCCH timeslots before 64 kbps timeslots in the event that the PBCCH is
enabled and the BCCH carrier is not a 64 kbps carrier.
If the PBCCH or PCCCH feature is enabled, the BSS overrides the database parameter
pkt_radio_type = 0 (TCH only, no PDCH) for the BCCH RTF when configuring the PBCCH
timeslot on the BCCH RTF.
The BSS reclaims timeslots for circuit-switched calls in the following order:
16 kbps switchable timeslot.
32 kbps switchable timeslot.
64 kbps switchable timeslot on DD CTU2 Carrier A.
64 kbps switchable timeslot on SD CTU2.
The BSS reclaims reserved timeslots in the following order in the event of an emergency call
when emergency call preemption is enabled and no switchable timeslots are available:
16 kbps reserved.
32 kbps reserved.
64 kbps on DD CTU2 Carrier A reserved.
64 kbps on SD CTU2 reserved.
PBCCH.
NOTE
The stealing sequence reverses PD placement ranking, and takes both pkt_radio_type
and rtf_ds0_count into account.
When GPRS mode TBFs and EGPRS mode TBFs are interleaved, the BSS transmits at least one
radio block every 360 ms using GMSK on every timeslots that has a GPRS TBF assigned.
For MS synchronization reasons, if standard GPRS MS are multiplexed on the PDCH, at least
one Radio Block every 360 ms on the downlink must use GMSK modulation (that is standard
GPRS or MCS1 to MCS4).
The BSS schedules at most 30 uplink and 30 downlink EGPRS and GPRS timeslots per block
period per PRP DPROC.
1-40 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation EGPRS link adaptation and Incremental Redundancy (IR)
The BSS only considers RTFs that have pkt_radio_type set to non-zero values when determining
the maximum number of EGPRS or GPRS timeslots that can be equipped in the cell.
When there are multiple carriers for GPRS in-service in a cell, how the GPRS timeslots scale
when carriers go out-of-service depends on how many carriers have gone out-of-service. The
carriers that have the packet radio capability set to None should not be considered in this
algorithm.
If the PBCCH or PCCCH feature is enabled, the BSS overrides the database parameter
If pkt_radio_type for the BCCH RTF is a non-zero value then BCCH carrier is the most
preferred carrier for PDCH configuration within its TRAU type.
The BSS maps the cells with the most GDS resources per PRP air timeslot resource ratio
requested, according to the database, taking into account the packet radio capability parameters
of the various, equipped RTFs, with a weighted distribution onto the PRP DPROCs with the
most equipped TRAU GDSs.
EGPRS link adaptation and Incremental Redundancy (IR)
The features included in the physical layer and RLC or MAC layer of EGPRS are more advanced
than GPRS. In particular, EGPRS includes two types of enhanced link quality control (LQC)
mechanisms: Hybrid Type I ARQ that allows retransmitting an explicitly NACKED RLC
data block by splitting it into separate radio blocks and Hybrid Type II ARQ that includes
Incremental Redundancy (IR). This feature does not support Hybrid Type I ARQ mode. In
GPRS the quality of a link is controlled through adapting the operating coding scheme to the
prevailing radio condition. This process is known as Link Adaptation (LA). In LA mode, each
packet is transmitted with the same puncturing scheme until received correctly. Thus, the link
performance is dependent on the independent performance of each packet.
The gain in Incremental Redundancy (IR) mode is realized from using more than one puncturing
pattern per coding scheme and the subsequent code combining of erroneous data packets. The
user data for each coding scheme is punctured at the output of the convolution encoder (various
puncturing schemes result in different code rates). The number of puncturing schemes per
coding scheme varies between 2 and 3. For MCS 1, MCS 2, MCS 5 and MCS 6, there are two
classes of puncturing pattern: P1 and P2, whereas for the remaining coding schemes, there are
three classes of puncturing pattern: P1, P2, and P3. The gain achieved through IR is highly
dependent on successful decoding of the RLC or MAC header.
There are three header types each having a different level of protection as seen from the
following table. For MCS-1 and MCS-5, the header code rate is comparable with the user
data code rate.
Table 1-11 EGPRS Coding Schemes and Throughput
Channel RLC data

Code rate Header Family Data rate
Coding Modulation unit size
[05.03] Code rate [04.60] kbps
Scheme [04.60]
MCS1 0.53 0.53 GMSK 22 C 8.8
MCS2 0.66 0.53 28 B 11.2
Continued
68P02901W36-S 1-41
Jul 2008
EGPRS link adaptation and Incremental Redundancy (IR) Chapter 1: BSS Functional Description
Table 1-11 EGPRS Coding Schemes and Throughput (Continued)

Channel RLC data
Code rate Header Family Data rate
Coding Modulation unit size
[05.03] Code rate [04.60] kbps
Scheme [04.60]
MCS3 0.80 0.53 37 A 14.8 13.6
(pad)
MCS4 1.0 0.53 44 C 17.6
MCS5 0.37 1/3 8PSK 56 B 22.4
MCS6 0.49 1/3 74 A 29.6 27.2
(pad)
MCS7 0.76 0.36 2x56 B 44.8
MCS8 0.92 0.36 2x68 A 54.4
MCS9 1.0 0.36 2x74 A 59.2
In IR mode, the first transmitted RLC data block can contain some or no redundant information.
If the data block is not recovered correctly, more redundant information is sent by the next
re-transmission using a different puncturing scheme of the same RLC data block. The erroneous
blocks are stored (unlike in LA where the block is discarded) and combined with each new
re-transmission until the RLC data block is decoded successfully. For example, in MCS 9, a data
block that is formed according to puncturing scheme P1 is transmitted first. If this block is
received with an error, the transmitter transmits the next block with puncturing scheme P2. The
receiver does not throw away the previously received data block, but uses it jointly to decode
the current data block, resulting in an effective lower code rate.
1-42 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Call processing
Call processing

Overview
The primary purpose of the BSS is to interconnect MSs, operating in the GSM Air Interface
environment, with the MSC.
Definitions
Generic Processor
NOTE
The original GPROC board was superseded by the GPROC2, which in turn was
replaced by the GPROC3. {28337} The GPROC3 board is replaced by GPROC32 to
increase the Message Transfer Link (MTL) capacity. The GPROC3 is fully functionally
backward compatible with the GPROC and GPROC2.
The GPROC2 and GPROC3 Generic Processor module performs a variety of different processing
functions. These functions can be spread among several GPROC2 and/or GPROC3s in a BSC.
References to the GPROC2 or GPROC3 as part of Call Processing (CP) can include any of
the GPROC2 or GPROC3 at a site, depending on the GPROC2 or GPROC3(s) performing the
required functions.
Transparency
When a message is transparent to the BSS, the GPROC2 or GPROC3 processes the message
only far enough to determine that the message is not intended for it. The GPROC2 or GPROC3
then routes the message forward.
68P02901W36-S 1-43
Jul 2008
Call processes Chapter 1: BSS Functional Description
Call processes
These call processing scenarios are described in the following sections:

Call processing: MS to BSS to MSC signaling link on page 1-45.
Call processing: MS originated call on page 1-46.
Call processing: MS terminated call on page 1-51.
Call processing: inter-BSS handover on page 1-56.
Call processing: intra-BSS handover on page 1-59.
Call processing: intra-BTS handover on page 1-62.
Call processing: GPRS Trace on page 1-67.
Call processing: Carrier prioritization for SDCCH on page 1-74.
Resource information messaging on page 1-75.
Assumptions
The descriptions for the call processing scenarios assume that transcoding is performed
remotely at the MSC site.
1-44 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Call processing: MS to BSS to MSC signaling link
Call processing: MS to BSS to MSC signaling link

Signaling link
When a BSS is initialized, a signaling link is established between the BSS and the MSC. This
signaling link is used for all signaling call set ups.
The land signaling link is semi-permanent and is changed only as necessary. This signaling
link is a timeslot on a E1 line.
The air signaling link, between the BSS and the MS, is set up on a call by call basis.
68P02901W36-S 1-45
Jul 2008
Call processing: MS originated call Chapter 1: BSS Functional Description
Call processing: MS originated call

Overview
The following highlights the actions required as well as the actions being performed by the BSS
as part the MS originated call. The events required for an MS originated call are shown in
a diagram in this section.
Call set up
MS channel request
After the dailed digits are entered, the MS transmits a Channel Request on the RACH. After
receiving this request, the BTS decodes the message. The BSS software immediately assigns
the MS to an SDCCH with an Immediate Assignment message sent on the AGCH channel.
MS response
The MS responds to the immediate assignment message and switches to the assigned SDCCH.
Once on the SDCCH, the MS transmits the Set Asynchronous Balanced Mode (SABM). The
network responds to SABM with UA to establish the Layer 2 radio link. Within the SABM, the
MS transmits a Service Request indicating to the BSS what type of service, for example, a call
or location update is required. This service request is processed by the BSS and then passed to
the MSC through the A interface signaling link.
Authentication request
After receiving the service request, the MSC sends an Authentication request to the MS. This
service request is passed through the BSS through the signaling link. The BTS transmits the
request to the MS on the SDCCH. Since no action is required by the BSS on the Authentication
request, it is passed through the BSS and is considered transparent to the BSS.
MS authentication response
The MS responds to the authentication request with an authentication response. The

authentication response from the MS is received by the BTS and is passed through the BSS
on the signaling link, as with the authentication request no action is required by the BSS and
as such is transparent to the BSS.
1-46 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation MS originated call connection
Cipher mode command
After receiving the correct authentication response, the MSC sends a Cipher Mode Command.
The network must start the cipher mode because the setup message contains sensitive
information such as dailed digits. The use of encryption is optional and is controlled by the
MSC on a call-by-call basis.
MS cipher mode complete
The MS responds to the set cipher command by transmitting a Ciphering Mode Complete
message indicating to the BSS that the MS is now communicating encrypted with the previously
assigned cipher key.
MS set up
The MS sends a setup message on the SDCCH, which indicates to the MSC the bearer service,
called party or both.
Assignment request
After the MSC receives and processes the setup message, the MSC transmits an
Assignment Request. The assignment request is used by the MSC to indicate what type of traffic
channel is required, that is, half or full-rate speech, or data. The BTS then allocates and assigns
an MS to a free TCH by sending an Assignment Command through the SDCCH.
MS assignment complete
In response to the assignment command, the MS switches to the assigned TCH and transmits an
Assignment Complete message on a FACCH (the main signaling channel on a TCH).
Alert message
The MSC sends an Alerting message to the MS. The alert message informs the MS the called
phone is ringing, which initiates the MS generated ring-back tone. This message is transparent
to the BSS.
Connect message
When the called party answers the phone (goes off-hook), a Connect message is sent to the MS.
This signal is transparent to the BSS and is switched through in the same manner as the alerting
message. The connect message is transmitted through the FACCH. In response to the connect
signal, the MS opens the audio path and transmits, through the FACCH, a Connect Acknowledge
message to the MSC. Conversation can now take place.
MS originated call connection
Figure 1-14 shows an MS originated connection establishment.
68P02901W36-S 1-47
Jul 2008
MS originated call connection Chapter 1: BSS Functional Description
Figure 1-14 MS originated call establishment
1-48 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation MS idle time reporting
MS idle time reporting
During the conversation, the MS only transmits and receives for one-eighth of the time, that is
during one timeslot in each frame.
During its idle time (the remaining seven timeslots), the MS switches to the BCCH of the
surrounding cells and measures its signal strength.
The signal strength measurements of the surrounding cells and the signal strength and quality
measurements of the serving cell, are reported back to the serving cell through the SACCH
once in every SACCH multiframe.
This information is evaluated by the BSS for use in deciding when the MS should be handed
over to another traffic channel.
This reporting is the basis for MS assisted handovers.
Uplink traffic
This is the conversation from an MS to a land line telephone.
BTS uplink path
The MS converts speech to digital voice information (traffic), which is transmitted by the MS in
bursts on its assigned timeslot and carrier.
This traffic is received by the BTS, which converts the traffic down to baseband and passes it to
the channel coders which decode the traffic. The TDM interface converts the traffic to a TDM
format for output onto a timeslot on the switch-bound TDM bus.
The BTS switches the traffic to another outbound TDM timeslot.
The BTS converts the traffic from TDM format and outputs the traffic data in a traffic channel
timeslot on the E1 line going to the MSC through the BSC.
BSC uplink path
Traffic data from the BTS on an E1 timeslot is converted to a TDM format by an MSI for output
on to a timeslot on the switch-bound TDM bus.
The KSW switches the traffic to another outbound TDM timeslot for input to the MSI.
Within the MSI the traffic is converted from TDM format to traffic data in a traffic channel
timeslot on the E1 line to the MSC.
Downlink traffic
This is the conversation from a land line telephone to an MS.
68P02901W36-S 1-49
Jul 2008
Downlink traffic Chapter 1: BSS Functional Description
BSC downlink path
The MSI receives a timeslot of traffic from the MSC from the E1 line and converts it into TDM
format for output onto the switch-bound TDM bus.
The KSW switches the traffic to another outbound TDM timeslot for input to the outbound MSI.
At the MSI the traffic is converted from TDM format to traffic data in a traffic channel timeslot
on the E1 line to the BTS.
BTS downlink path
The NIU receives a timeslot of traffic from the E1 line and converts it into TDM format for
output onto the switch-bound TDM bus.
The MCU switches the traffic to another outbound TDM timeslot.
The TDM interface in the BTS converts the traffic into a format that complies with GSM
recommendations for the channel coders, encodes it and the traffic is transmitted on the correct
timeslot and carrier.
The MS converts the received bursts to analog audio.
1-50 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Call processing: MS terminated call
Call processing: MS terminated call

Overview
The following highlights the events required to terminate (receive) a call as well as the actions
being performed by the BSS to set up the MS terminated call. The events required for an MS
terminated call are shown in a diagram in this section.
Call set up
Paging request
After dailed digits are received from the PSTN or ISDN, the MSC sends a Paging Request
to the BSS through the E1 line. The BSS processes the paging request and schedules it for
transmission on the PCH at the appropriate time.
MS response
Upon receiving the paging request, the MS responds by transmitting a Channel Request
on the RACH.
SDCCH assignment
After receiving the channel request, the BSS processes it and immediately assigns the MS an
SDCCH. This assignment is encoded as an Immediate Assignment and transmitted on the AGCH.
MS paging response
After receiving the immediate assignment command, the MS switches to the assigned SDCCH
and transmits within SABM a Paging Response. The network responds to SABM with UA to
establish the Layer 2 radio link. This paging response is received by the BSS for processing.
The paging response is then sent to the MSC through the E1 line.
Authentication request
After receiving the paging response, the MSC sends an authentication request to the MS. This
request is sent on the E1 line to the BSS. The authentication request is routed through the BSS
on the signaling link. The authentication request requires no processing by the BSS and is
considered transparent to the BSS.
68P02901W36-S 1-51
Jul 2008
Call set up Chapter 1: BSS Functional Description
MS authentication response
In response to the authentication request, the MS transmits its authentication response on

the SDCCH. The authentication response is transparent to the BSS and is passed through
the BSS to the MSC.
Cipher mode command
After receiving the correct authentication response from the MS, the MSC sends a Ciphering
Mode Command message. The BSS processes the ciphering mode command and transmits
the command to the MS.
MS cipher mode complete
In response to the ciphering mode command, the MS transmits a Ciphering Mode Complete
message to the BSS. From this point onwards, all radio transmissions by the BSS and the MS
are encrypted using the appropriate algorithm.
Set up message
The MSC sends a Set up message to the MS indicating the bearer service and/or called party.
The BSS sends the setup message through the SDCCH. This set up message is transparent
to the BSS.
MS call confirmation
After receiving the setup information, the MS transmits a Call Confirmation message. This
message confirms that the MS is capable of receiving the call type identified in the setup
message. The MS transmits this message on the SDCCH. The BSS receives the call confirmation
and passes to the MSC through the A interface.
Assignment request
After receiving the call confirmation, the MSC sends an Assignment Request message. The BSS
takes the assignment request, allocates, and assigns the MS to a free TCH. Then, it transmits
the assignment request to the MS on the SDCCH.
MS assignment complete
The MS then switches to the assigned TCH and transmits an Assignment Complete message
on FACCH (which is a logical channel on a TCH). This assignment complete is received and
sent to the MSC.
Alert message
The MS sends an Alert message to the MSC on the FACCH, which informs the MSC that the
called MS is ringing and causes the MSC to send a ring-back tone to the calling phone. This
message is transparent to the BSS.
1-52 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation MS terminated call flowchart
MS connect acknowledge
When the MS subscriber answers, the MS transmits a Connect message on the FACCH and
opens the audio path to the user. The connect message is transparent to the BSS and is passed
to the MSC through the signaling link.
The Connect Acknowledge message is passed from the MSC to the PSTN or ISTN, which in turn
stops the ring-back tone and opens the audio path.
Set up complete
The connection is now established and a conversation can now take place.
MS terminated call flowchart
Figure 1-15 shows an MS terminated call set up sequence.
68P02901W36-S 1-53
Jul 2008
MS terminated call flowchart Chapter 1: BSS Functional Description
Figure 1-15 MS call termination set up
1-54 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation MS idle time reporting
MS idle time reporting
During the conversation, the MS only transmits and receives for one-eighth of the time, that is
during one timeslot in each frame.
During its idle time (the remaining seven timeslots), the MS switches to the BCCH of the
surrounding cells and measures its signal strength.
The signal strength measurements of the surrounding cells and the signal strength and quality
measurements of the serving cell, are reported back to the serving cell through the SACCH
once in every SACCH multiframe.
This information is evaluated by the BSS for use in deciding when the MS should be handed
over to another traffic channel.
This reporting is the basis for MS assisted handovers.
68P02901W36-S 1-55
Jul 2008
Call processing: inter-BSS handover Chapter 1: BSS Functional Description
Call processing: inter-BSS handover

Overview
The following highlights the actions required to complete an inter-BSS (from one BSS to
another) handover in chronological order. The events required for an inter-BSS handover are
shown in a diagram in this section.
During a conversation, the MS measures the BCCH signal strength of surrounding cells, the
TCH signal strength and signal quality of the serving cell. This information is reported to the
serving cell through the SACCH.
The BSS also continually measures the signal strength and signal quality of the MS transmission.
Handover
Handover decision
Every SACCH multiframe, when new measurement information is received from the MS, the
BTS performs handover decision and power control processing. The MS measurements are
combined with measurements made at the BTS and are averaged according to a specified
averaging algorithm. The current and previous averaged measurements are then processed
by further control algorithms. As a result, the BTS can order a power control change (BTS Tx
power or MS Tx power) and also determine if a handover is required.
Handover required
When the received measurement information indicates that a handover is required, the BTS
generates a Handover Required message. This handover required message includes the ID
number of the chosen candidate cell or cells and the required traffic channel type. If the chosen
candidate cell is not within the current BSS then this message is sent to the MSC through
an established signaling link on the 2.048 Mbps line. If the call is in AMR mode (full-rate or
half-rate) multi-rate information is passed to the target BSS.
Handover request
The MSC in turn, routes a Handover Request to the new BSS. The new BSS receives the
Handover Request through its A interface. The new BSS assigns a radio channel for the handover
and generates a Handover Request Acknowledge message back to the MSC. This message
contains a handover reference number, details of the allocated radio channel and radio interface
HO command (to determine later if the proper MS has gained access to the correct channel).
1-56 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Inter-BSS handover
Handover Command
The MSC converts the received handover request acknowledge into a Handover Command
and sends it to the serving BSS. This Handover Command is processed by the BSS and the
corresponding radio interface Handover Command message is transmitted to the MS through
the air signaling link.
MS handover access
When the MS receives the Handover Command, the MS switches to the assigned TCH on the
new BSS. Then, the MS continuously transmits a Handover Access message on the FACCH. This
special signal message contains the HO reference number. Next, the new BSS transmits a
Physical Information message. This physical information contains timing advance information.
MS transmits SABM
After the MS receives the physical information, the MS stops sending Handover Access
messages and then transmits the SABM. The network responds to SABM with UA to establish
the Layer 2 radio link.
MS Handover Complete
Next, the MS transmits a Handover Complete message. The BSS processes this and then sends
a Handover Complete message to the MSC.
Clear command
In response to the Handover Complete, the MSC sends a Clear Command message to the old
BSS. This causes the old BSS to release the resources previously assigned to that MS. After
releasing the resources, the old BSS sends a Clear Complete message indicating to the MSC
that the released resources are now available for further use.
MS transmit and receive
Conversation now continues uninterrupted between an MS and the new BSS. During the
conversation, the MS only transmits and receives one-eighth of the time, that is, one timeslot of
a frame. During its idle time (the remaining seven timeslots of the frame), the MS is switching to
the BCCH of surrounding cells in its lookup table and measuring the signal strength and quality
of the BCCH signal. Then every SACCH multiframe, the measurements of the surrounding cells
and the serving cell are reported on the SACCH back to the serving cell. This information is
evaluated by the BSS for deciding when the MS should be handed over to another cell. This
reporting results in MS assisted handovers.
Inter-BSS handover
Figure 1-16 shows an inter-BSS handover.
68P02901W36-S 1-57
Jul 2008
Inter-BSS handover Chapter 1: BSS Functional Description
Figure 1-16 Inter-BSS handover
1-58 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Call processing: intra-BSS handover
Call processing: intra-BSS handover

Overview
The following section describes the actions required to perform an intra-BSS handover.
The handover could occur between BTSs (intra-BSS), or between cells covered by the same
BTS (intra-BTS), all within a single BSS. Intra-BTS handovers can be either synchronized or
non-synchronized.
During a conversation, the MS measures the signal strength of the BCCH of surrounding cells
and the signal strength and quality of the TCH on the serving cell. This information is reported
to the serving cell through the SACCH and forms the basis of the handover process.
The BSS also continuously measures the signal strength and signal quality of the MS
transmission.
Handovers into a particular cell can be barred by a database parameter.
Intra-BSS handover
The diagram on the next page shows the intra-BSS handover process for a non-synchronized
handover.
Hand over decision
When the received signal strength information indicates that a handover to a new TCH channel
(normally in a new cell) within the same BSS is required, the BSS generates a Handover
Command if it is a different cell in the same BSS.
MS SABM message
The MS then switches to the assigned TCH and sends a SABM message. The network responds
to SABM with UA to establish the Layer 2 radio link. This SABM message is transmitted
through the FACCH.
MS assignment or handover complete
The MS transmits a Handover Complete message on FACCH (which is a logical channel on

a TCH). This Handover Complete is received through the established signaling link and is
processed by the BSS MCU. A Handover Performed is sent to the MSC through the A interface.
Conversation and measurement reports continue as before.
68P02901W36-S 1-59
Jul 2008
Intra-BSS handover Chapter 1: BSS Functional Description
Inter-cell handovers
When the BSS determines that an inter-cell handover is needed, a handover required message is
sent to the MSC. For intra-BSS, inter-cell handovers this is only true when internal intra-BSS,
inter-cell handovers are disabled in the BSS database. The handover required message
contains a used speech version information element and a current channel type 1 information
element to indicate to the MSC the current speech version and channel rate of the call. The
used speech version information element within the handover required message is coded to
indicate a TCH/AHS.
If the current channel type 1 information element within the handover required message
indicates a TCH/AHS is in use, the current BSS informs the target BSS of the current multi-rate
configuration. This is achieved by including the multi-rate configuration in the old BSS to new
BSS information element in the handover required message. The multi-rate configuration
information sent within the handover required message contains the downlink multi-rate
configuration for the channel. The current channel type 1 information element within the
handover required message is coded to indicate a TCH/AHS.
1-60 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Intra-BSS handover process
Intra-BSS handover process
Figure 1-17 shows an intra-BSS handover.
Figure 1-17 Intra-BSS handover
68P02901W36-S 1-61
Jul 2008
Call processing: intra-BTS handover Chapter 1: BSS Functional Description
Call processing: intra-BTS handover

Overview
There are two intra-BTS handovers, non-synchronized and synchronized.
Non-synchronized handovers
Non-synchronized handovers require the MS to move to the target cell and continuously send
handover access messages which the BTS uses to calculate the timing advance and power
control required. The BTS then sends this value to the mobile (in the Physical Information
message) which uses it to set up communications on the new air channel.
The process for a non-synchronized intra-BTS handover is like that for the intra-BSS handover
previously described.
Synchronized handovers
The synchronized intra-BTS handover feature provides a faster method for an MS to establish
communications with a target cell during handover and thus provides a more unobtrusive
handover. It also increases throughput by releasing system resources sooner.
If the mobile unit knows that the two cells are synchronized, it has enough information to
calculate the required timing advance for the target cell.
In synchronized cells, bit 0 of timeslot 0 is transmitted over the air at the same time from both
cells. This is always the case for cells within the same BTS.
The capability for synchronized handover is stored as a flag in the database in the source
list for each cell.
If synchronized handover is to be used, the MS is notified in the Handover Command.
Message flow
The message flow for synchronized intra-BTS handover is shown in the following diagram. The
diagram does not show the entire message sequence for handover, but is intended to show the
difference between synchronous and asynchronous handovers.
When a handover request is received, the target BTS checks its source list to determine if it
is synchronized with the source cell. If it is then the BSS constructs a Handover Command
indicating that the synchronized handover is to be performed. On receiving the synchronized
HO command, the MS switches to the new channel and sends only four Handover Access
messages to establish the signaling link by sending SABM and receiving UA messages.
1-62 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Synchronized intra-BTS handover process
Synchronized intra-BTS handover process
Figure 1-18 shows the synchronized intra-BTS handover process.
Figure 1-18 Intra-BTS handover
68P02901W36-S 1-63
Jul 2008
Call processing: enhanced call trace management Chapter 1: BSS Functional Description
Call processing: enhanced call trace management

Overview
The call trace facility in GSM enables a PLMN operator to trace the activities of various
network elements for events associated with a particular subscriber or equipment. With a
single command, the operator at the OMC-R, MSC or BSS can activate a trace. Each trace has
certain criteria associated with it. The operator is required to specify the criteria to activate
a trace. When a call in the BSS meets the criteria, a trace is invoked by the BSS. The BSS
collects various data as specified in the trace criteria and sends it to the OMC-R in the form
of trace records. The BSS sends these trace records in ASN.1 format. The OMC-R converts
the records into GSM 12.08 format and saves the data as log files. The operator has the
option of forwarding the records to the NMC. When all the conditions of a trace are met, the
BSS deactivates the trace and informs the OMC-R. The operator can also request that the
BSS deactivates a trace prematurely.
Previously, the OMC-R operator could not activate a trace from the OMC-R GUI, although it was
possible through MMI commands. The BSS notifies the OMC-R on activation or deactivation of
a trace at the MSC or MMI. When a trace is invoked, the BSS sends the trace records to the
OMC-R. System changes now provide a GUI for the call trace feature. The operator can activate
or deactivate a trace from the OMC-R GUI. The operator is able to see the trace records (in
text format) associated with each trace invoked in the BSS.
When an operator (at the OMC-R, MSC, or BSS) activates or deactivates a set of trace criteria,
the BSS notifies the OMC-R and a trace criterion is created or deleted at both the BSS and the
OMC-R. The trace criteria are consistent over the OMC-R-BSS interface. This means that, if
a trace criterion object is present in the BSS, it is also present in the OMC-R (and the other
way round).
When a call meets all the conditions of an activated criterion, the BSS invokes a trace on that
call. The BSS starts collecting the trace data and sends it to the OMC-R in the form of trace
records. The first trace record has a special field called Start Time and the last trace record
has a field End Time. From this timing information, the OMC-R knows about the invocation
and termination of the trace in the BSS and performs the appropriate initialization and clean up
operations. An invoked truce traces a call until the call ends, leaves the scope of the trace, or
the operator chooses to stop tracing that call.
1-64 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Enhanced call trace management
Enhanced call trace management
Trace invocation details
At the OMC-R GUI, the call trace feature has some windows available. These help the user to
view the trace criterion, view trace records, delete traces, and so on. The following windows
are available at the OMC-R GUI:
Trace View.
Trace Criteria Setup.
Invoked Trace List.
Trace Record View.
The content and purpose of these windows are explained in the following sections.
Trace view
This is the first window which appears when the user invokes Call Trace from the OMC-R
desktop. This window shows the user all traces, on the defined trace scope. The status field of
this window shows one of the values:
Active.
Active traces are those which can still invoke new instances.
Deactivated.
Deactivated traces are still tracing calls and/or are not within the daily triggering interval.
Completed.
Completed traces cannot invoke new instances and do not have current traces. They are
not on the BSS any more.
Trace criteria setup
This window helps the user to specify the criterion for a new trace. The user must first specify
the Trace Selector and the Selector Value. The Trace Selector appears as a menu of options,
as follows:
Nth Call: selector value is the nth call.
IMSI: selector value is the IMSI number.
TMSI: selector value is the TMSI number.
IMEI: selector value is the IMEI number.
IMEISV: selector value is the IMEISV number.
SCCP #: selector value is the SCCP number.
68P02901W36-S 1-65
Jul 2008
Enhanced call trace management Chapter 1: BSS Functional Description
The user then needs to decide on what the triggering event would be, that is, what should
trigger the trace. This could be either:
Call setup.
Hand in.
Any origin.
The user then needs to decide on the type of trace data that the BSS should send to the OMC-R.
By default, the BSS only sends basic trace records. The user can choose from basic, handover,
or radio record types. Additionally, the user can opt for one or more message types; BSSMAP,
DTAP, Motorola Abis, Radio Resources, RSS, or MS_power.
NOTE
The user has the option of having trace records go to MMI, OMC or both, when
creating a criterion from the MMI. Radio and HO traces cannot be selected at MMI
explicitly, but are implicitly selected at the collect during HO only prompt.
The next step is to specify the scope of the trace. The scope identifies the BSS, Site, Cell, or RTF
under which the trace is active. The user has to enter values for the BSS-Site-Cell in the case
where the trace is active below a Cell and values for BSS-Site in the case where the trace is
active below a Site. The trace can be continued beyond the specified scope in the case where
it originates at either the Site, Cell, or RTF.
The user also has the option of specifying the duration in which the trace is active. In the case
where such a duration is specified, traces are only invoked if all other criteria are met and the
time is within the daily trace duration window specified, that is, between the daily enable and
disable times.
Finally, the user can specify that this trace should not trace more than a certain total number of
calls. In the case where the trace selector is the Nth Call, the maximum number of simultaneous
calls traced can also be specified.
Once all the criteria are set up, the user can activate the trace by clicking the Create button.
Invoked trace list
Once the criteria have been specified and the trace has been activated, various instances of
this trace are invoked. Each invoked instance is actually for a call, which has a unique SCCP
number associated with it. Therefore, a combination of BSS ID, trace reference number and
SCCP number identify a particular invoked instance for a particular trace. The user is able to
view either all calls, completed calls, or calls in progress from the view menu option on the
trace view window.
Trace record view
This window is used to display trace records to the user in ASCII format. Trace records can be
shown for a particular SCCP number for a particular set of trace criteria.
1-66 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Call processing: GPRS Trace
Call processing: GPRS Trace

Overview
GPRS Trace is an extension of the Call Trace feature. It provides similar functionality for GPRS
and reuse of the user interface where applicable. There are some differences due to the
characteristics of GPRS data transfers compared to circuit switched calls. For example, more
frequent GPRS signaling due to the bursty packet nature of GPRS data transfers, the absence
of guaranteed BSS coordinated handover decisions in GPRS.
GPRS Trace
The GPRS Trace feature is used for the same purpose as the Call Trace:
GPRS network optimization.
Troubleshooting individual GPRS mobiles.
GPRS Trace criteria parameters
When selecting the GPRS Trace criteria, the following decisions must be made:
GPRS Trace scope.
GPRS Trace selector.
GPRS Trace Record type.
Optionally the following can be selected for the GPRS Radio Record.
LLC information.
BSSGP messages.
RLC or MAC messages (without PDAK/PUAK/PMR).
GPRS Power Control and Coding Scheme.
Packet Measurement Reports.
Every RLC or MAC PDAK (with every PDAK or PUAK).
The GPRS Power Control and Coding Scheme provides periodic Uplink and Downlink
measurement data including sampled PDAKs. The RLC or MAC PDAK option produces large
amounts of data due to the frequency of the PDAK messages (PDAK messages can occur as
often as 40 milliseconds).
68P02901W36-S 1-67
Jul 2008
Performance impacts analysis Chapter 1: BSS Functional Description
Additionally, the GPRS Trace criteria can contain the following trace tailoring options:
Start and stop time for the GPRS Trace criteria to be active.
Total number of GPRS mobiles to trace for that GPRS Trace criteria instance.
Interval of reported UL or DL measurement data and Packet Measurement Reports.
Number of simultaneous nth GPRS mobiles per PRP.
GPRS Trace Record collection
Once the conditions for the GPRS Trace criteria have been met, the BSS sends the specified
GPRS Trace Record type with the selected information captured to the OMC-R. The GPRS Trace
Records are stored at the OMC-R.
{27717}
NOTE
GPRS call trace does not support RESUME at intra-BSC level because CS (or SMS,
LAC, LCS and so on) calls are GSM call trace records only. See Support of RESUME
at intra-BSC level on page 1-98.
Suspend or RESUME status can be obtained through the GPRS call trace, when:
An MS initiates a Suspend procedure, and the result is successful or not.

The BSS initiates a RESUME procedure, and the result is successful or not.
Performance impacts analysis
GPRS Trace impacts
As the GPRS data transfers are short and bursty by nature as compared to GSM call durations,
the GPRS data transfer signaling rate is higher than the GSM call signaling rate. After GPRS
Trace Records are larger than the ones for Call Trace.
Call Trace and GPRS Trace signal paths
Figure 1-19 shows the Call Trace and GPRS Trace signal paths in the BSS system. Call Trace
and GPRS Trace share the OML with all the other signaling to the OMC. This OML signaling
includes statistics uploads, database changes, remote logins from the OMC to the BSS, device
notifications and alarms. The combined load on the OML has to be considered when the Call
Trace and/or the GPRS Trace criteria are active at the same time.
1-68 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Performance impacts analysis
Figure 1-19 GPRS Trace and Call Trace signal paths
The reporting of the Call Trace records adds load to the RSLs, reporting of GPRS Trace records
adds load to the GSL and OML. GPRS Trace does not add load to the RSLs because GPRS
signaling occurs on the data path, that is, TRAU Data path in Figure 1-19. For example, GPRS
Trace criteria with trace scope of BTS, results in the cells of that BTS being traced at the PCU
managing the cells of that BTS. There are no impacts to the BTS for GPRS Trace.
Trace flow control
A flow control mechanism is triggered when the volume of OML signaling described previously
causes the OML to become congested. Call Trace and GPRS Trace Records are of lowest priority
and are not buffered at the BSC if the OML is busy or under a flow control condition when
the records are reported.
GPRS Trace flow control
When the OML flow control becomes active, the PCU buffers GPRS Trace Records until
notification that flow control is no longer active. Depending on the amount of data buffered and
the length of the OML unavailability, the PCU can drop GPRS Trace Record data. The value of N
is doubled and the value of the number of simultaneous GPRS MSs to trace is halved for all
the active nth GPRS MS trace criteria. To prevent the OML from returning to a flow control
condition, the original trace criteria values are not restored when trace flow control is inactive.
68P02901W36-S 1-69
Jul 2008
GPRS Trace characteristics Chapter 1: BSS Functional Description
GPRS Trace characteristics
GPRS Trace criteria triggering during GPRS Trace establishment
The point at which the GPRS Trace record begins depends on the GPRS Trace selector chosen
and the type of GPRS TBF establishment that meets the GPRS Trace criteria. For example,
the nth GPRS MS meets the GPRS Trace criteria from the moment that the new GPRS MS
establishes a GPRS data transfer regardless of direction.
GPRS IMSI Trace selector
Uplink GPRS data transfer establishment for IMSI selector
For the case of GPRS IMSI Trace selector, the GPRS Trace criteria is met when the IMSI becomes
known to the PCU for a new GPRS mobile establishing a data transfer. In the case of an uplink
TBF establishment, the TLLI becomes known with the arrival of the first UL RLC data block.
The arrival of the TLLI in the uplink allows the PCU to send the RA Capability Update message
to the SGSN. The RA Capability Update Ack message from the SGSN contains the IMSI as
long as that TLLI is known to the SGSN. As soon as the IMSI arrives at the PCU, the GPRS Trace
criteria are met. The GPRS Trace triggers upon receipt of the RA Capability Ack message.
The PCU sends the RA Capability Update message to the SGSN in the following uplink TBF
establishment scenarios when the RA Capability of the mobile is not already known:
EGPRS Packet Channel Request (EPCR).
PRACH when PBCCH enabled.
One-phase access on the CCCH.
Enhanced one-phase access.
In case of a two-phase access, the PRR contains the RA Capability of the MS, so the PCU does
not send the RA Capability Update message to the SGSN. In two-phase access, the GPRS
Trace IMSI criteria is not met on the uplink TBF establishment unless the IMSI is ready.
1-70 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GPRS Trace characteristics
Figure 1-20 GPRS UL data transfer establishment showing GPRS Trace IMSI trace
selector triggering
Downlink GPRS data transfer establishment for IMSI selector
For the downlink TBF establishment case, the new GPRS MS becomes known to the PCU at the
same point that the IMSI becomes known if the DL UNITDATA contains the IMSI. So the GPRS
Trace criteria are met right away. The DL UNITDATA contains the IMSI except in the cases of
GPRS attach or routing area update procedures.
68P02901W36-S 1-71
Jul 2008
GPRS Trace characteristics Chapter 1: BSS Functional Description
Figure 1-21 GPRS DL data transfer establishment showing GPRS Trace IMSI trace
selector triggering
0 0
GPRS TLLI selector
The SGSN can change the TLLI at any point in the GPRS TBF data transfer. At the point that
the PCU detects that the TLLI has changed, the TLLI GPRS Trace criteria is no longer met and
the GPRS Trace records stop for that criteria.
Uplink GPRS data transfer establishment for TLLI selector
For the case of GPRS TLLI Trace selector, the GPRS Trace criteria is met when the TLLI
becomes known to the PCU for a new GPRS MS establishing a data transfer. In the case of an
uplink one-phase TBF establishment, the TLLI becomes known with the arrival of the first UL
RLC data block. The GPRS Trace triggers when the first UL RLC data block arrives at the PCU.
1-72 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GPRS Trace characteristics
Figure 1-22 GPRS data transfer one-phase UL TBF establishment showing GPRS
Trace TLLI trace selector triggering
Downlink GPRS data transfer establishment for TLLI selector
For the downlink TBF establishment case, the new GPRS MS becomes known to the PCU at
the same point that the TLLI becomes known with the arrival of the DL UNITDATA. The GPRS
Trace triggers at the receipt of the DL UNITDATA at the PCU.
Nth GPRS Mobile selector
For Nth GPRS MS selector, the GPRS criterion is met when the specific TLLI is known at the PCU
and satisfies the specific criterion. During UL TBF establishment, the GPRS criterion is met until
mobile sends first PRR in two-phase or first UL data in one phase. During DL TBF establishment,
the GPRS criterion is met when PCU initials first assignment message with TLLI to MS.
68P02901W36-S 1-73
Jul 2008
Call processing: Carrier prioritization for SDCCH Chapter 1: BSS Functional Description
Call processing: Carrier prioritization for SDCCH

Overview
This feature implements a radio channel (SDCCH or TCH) allocation algorithm based on the
operator assigned per-carrier priority.
Carrier prioritization for SDCCH
The interference band allocated to a channel is still the first criterion in the channel allocation
algorithms. A channel from the highest priority carrier matching the requested interference
band is allocated to a channel request. Moreover, the channel allocation priority is also a
secondary criterion after the existing criteria of channel selection in a multiband, concentric cell
and extended range cell environment. Also the channel allocation priority cannot be followed
for an emergency call if a channel is allocated from the emergency reserved channel pool.
For interference-based intra-cell handovers, the channel selection algorithm for a non-hopping
cell has been modified to consider the channel allocation priority as follows:
Compile a list A with any channels in the best interference band.
From list A, select any channels on a carrier other than the current carrier and compile a
list B. If none are available, select the best channel from list A.
From list B, select a channel with the best available channel allocation priority.
NOTE
The previous criterion of preferring BCCH over non-BCCH has been replaced by
the channel allocation priority.
1-74 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Resource information messaging
Resource information messaging

Resource messaging
The MSC can send resource request messages to the BSS. Resource request messages request
information on the available resources in a given cell. The BSS responds with resource
indication messages to the MSC. The resource request message specifies one of four ways in
which the BSS sends resource indication messages:
Spontaneous resource information expected-the BSS sends resource indication messages
when certain internal traffic level criteria are met (the BSS acknowledges the request with
an empty resource indication message in this case).
One single resource information expected-the BSS sends one resource indication message
in response to the resource request message.
Periodic resource information expected-the BSS sends resource indication messages

periodically (the BSS acknowledges the request with an empty resource indication
message in this case).
No resource information expected-the BSS sends no resource indication messages until

another resource request message has been received (the BSS acknowledges the request
with an empty resource indication message in this case).
Certain fields in the resource available information element of the resource indication message
to the MSC are coded to indicate the number of half-rate channels that are available in each
interference band (1 to 5).
An idle generic traffic timeslot (which can be used as a full-rate or half-rate resource) is
counted as one available full-rate channel and two available half-rate channels within the
resource available information element of the resource indication message. The total number of
accessible half-rate channels octets within the total resource accessible information element are
coded to indicate how many half-rate channels are accessible at the specified cell. The number
of accessible half-rate channels includes those that are in use.
The total number of accessible half-rate channels octets within the total resource accessible
information element of the resource indication message are coded to indicate accessible
half-rate channel resources.
Any idle generic traffic timeslots (which can be used as a full-rate or half-rate resource) are
counted as one accessible full-rate channel and two accessible half-rate channels within the
total resource accessible information element of the resource indication message. When the
AMR half-rate functionality is disabled, through the BSS or cell enable or disable switches, the
AMR half-rate resources available within the cell are restricted. An idle generic timeslot only
increments the count of the available or accessible full-rate channels by one.
Any idle or busy AMR half-rate channels are still reported as available or accessible within
the resource indication message until both the subchannels on the half-rate timeslot become
idle and the timeslot becomes an idle generic timeslot. This can occur as the disabling of
AMR half-rate does not affect existing calls.
68P02901W36-S 1-75
Jul 2008
Location Services Chapter 1: BSS Functional Description
Location Services

BSS Location Services support
Location Services (LCS) implements emergency services functionality in GSM systems

(compliant with the Federal Communications Commission (FCC) 911 requirements) in two
phases:
Phase 1
To transmit the originating number of an emergency call (911 in the United States) and the
location of the serving site to the Public Safety Answering Point (PSAP).
Phase 2
To transmit the estimated position of the emergency caller, expressed in latitude and
longitude coordinates within specified limits of accuracy.
Applications that request location estimates from location services can be located in the MS, the
network, or externally to the PLMN.
Location Services positioning mechanisms
Location services currently specify three positioning mechanisms in order to determine the
location of a Mobile Station. These positioning processes involve two main steps: signal
measurement and position computation based on the measured signals. The standard SMG
(Special Mobile Group) positioning mechanisms are:
Network-based uplink Time of Arrival (TOA)-not implemented by Motorola.
Enhanced Observed Time Difference (E-OTD).
Assisted GPS (A-GPS).
Conventional GSM Timing Advance (TA) measurements can also be used in conjunction with
Cell ID determination to provide a coarser, lower quality location estimate.
Examples of applications to which location services MS position determination can be applied

are to deliver tailored content to MSs in a physical locality (location specific advertising),
or to determine the routing of voice traffic (location sensitive routing). Motorola supports
Timing Advance (TA), Enhanced Observed Time Difference (E-OTD) and Assisted GPS (A-GPS)
positioning mechanisms.
1-76 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Timing Advance positioning (TA)
Timing Advance positioning (TA)
The Timing Advance positioning mechanism is based on the existing GSM timing advance
measurements, the frequency of sending of which is specified by the timing_advance_period
parameter. The timing advance value is known for the serving BTS and when returned to
the requesting location services client, with the cell ID, provides the approximate physical
position of the MS.
Network architecture
Location services require three specific network elements to support it, as follows:
Gateway Mobile Location Center (GMLC).
Serving Mobile Location Center (SMLC).
Location Measurement Unit (LMU).
Figure 1-23 shows a minimal network to support location services and includes the additional
interfaces to support the location services network entities. The interface that most impacts
the BSS is the Lb interface.
Figure 1-23 Location Services Network Architecture
68P02901W36-S 1-77
Jul 2008
Gateway Mobile Location Center (GMLC) Chapter 1: BSS Functional Description
Gateway Mobile Location Center (GMLC)
The Gateway Mobile Location Center (GMLC) is the element that connects an external LCS
Client to the GSM network and links to the Gateway Mobile Location Center (GMLC) through
the Le interface. The GMLC requests routing information from the HLR through the Lh
interface. After performing registration authorization, it sends positioning requests to and
receives final location estimates from the MSC (and VLR) through the Lg interface. The GMLC
performs the following functions:
Manages external interface to location services.
Authorizes LCS clients that request location services information.
Collects LCS-related client and subscriber charging and billing data.
Translates location estimates into local geographic systems understood by the client.
Serving Mobile Location Center (SMLC)
The Serving Mobile Location Center (SMLC) manages the overall coordination and scheduling
of resources required for MS positioning. It also calculates the final location estimate and
accuracy. As shown in Figure 1-23, the two signal interfaces, Ls and Lb, transport messages
to and from the SMLC. The Ls interface associates the SMLC with the MSC (and VLR) and
routes signals to the SMLC through the Ls interface in this configuration. Similarly, the Lb
interface associates the SMLC with the BSC and routes BSC messages to the SMLC. The SMLC
performs the following functions:
Registers and maintains the operational status of LMUs.
Manages the positioning of an MS through the coordination and scheduling of resources.
Calculates the positioning of the MS.
The phrase BSS based SMLC refers to an SMLC communicating with the BSS through the
Lb interface. The phrase NSS based SMLC refers to an SMLC communicating with the MSC
through the Ls interface. In this manual, the SMLC is assumed to be communicating with the
BSS only, that is BSS based SMLC and is referred to as SMLC, unless an NSS based SMLC is
mentioned. If the SMLC is NSS based, all SMLC transactions appear to be to and from the MSC
only (the MSC then routes the messages to and from the NSS based SMLC).
Location Measurement Unit (LMU)
A Location Measurement Unit (LMU) makes radio measurements to support one or more
positioning methods.
All location and assistance measurements obtained by an LMU are supplied to a particular
SMLC associated with the LMU. Instructions concerning the timing, the nature, and regularity
of these measurements are either provided by the SMLC or preset in the LMU. Table 1-12
shows the LMU types.
1-78 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Location Services protocol usage
Table 1-12 LMU radio measurement types
LMU Type Description

A This type of LMU is seen as an MS by the BSS. Type A has no
bearing on what measurements the LMU obtains.
B This type of LMU is seen as a BTS by the BSS. Type B has no
bearing on what measurements the LMU obtains.
Attributes of the type A LMU are as follows:

Accessed exclusively over the GSM air interface (Um interface); there is no wired
connection to any other network element.
Have a serving BTS and BSC that provide signaling access to a controlling SMLC.
With an NSS based SMLC, has a serving MSC and VLR and a subscription profile in an HLR.
Always has a unique IMSI.
Functions of the type A LMU are:

Supports all radio resource and mobility management functions of the GSM air interface as
necessary to support signaling using an SDCCH to the SMLC.
Supports those connection management functions necessary to support location services

signaling transactions with the SMLC.
Location Services protocol usage
The BSS interfaces with the MSC and the MS are modified for location services. The Lb
interface is specific to location services for BSS and SMLC communication.
Location Services protocol stacks
The protocol stacks are shown in Figure 1-24, Figure 1-25, Figure 1-26 and Figure 1-27.
68P02901W36-S 1-79
Jul 2008
Location Services protocol stacks Chapter 1: BSS Functional Description
BSS-SMLC protocol stack
The BSS-SMLC protocol stack is modified from the existing A-interface, as shown in Figure 1-24.
The MTP and SCCP layers are standard SS7.
Figure 1-24 BSS-SMLC protocol stack
--
BSS-MS protocol stack
For the location services BSS-MS interface, shown in Figure 1-25, RR is modified for a new
message which can carry specific application protocol data. The Radio Resource Location
Protocol (RRLP) carries the location services signaling.
Figure 1-25 BSS-MS protocol stack
RRLP
Key
New
RR
Modified
R2
Unchanged
R1
1-80 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Location Services protocol stacks
BSS-LMU protocol stack
The location services BSS-LMU interface is technically new, as shown in Figure 1-26. Because
LMUs act mostly as MSs do, the only difference for LMUs compared with MSs is that the new
application protocol is LMU specific-the LMU Location Protocol (LLP).
Figure 1-26 BSS-LMU protocol stack
BSS-MSC Protocol Stack
The BSS-MSC interface (A-interface) is enhanced for location services to carry SMLC-BSS
signaling for NSS based SMLC, as well as MSC-SMLC signaling for BSS based SMLC, as shown
in Figure 1-27.
Figure 1-27 BSS-MSC protocol stack
68P02901W36-S 1-81
Jul 2008
Transcoding function Chapter 1: BSS Functional Description
Transcoding function

Location overview
When the BSS components are located remotely from each other, the E1 lines are leased from
the PSTN.
By locating transcoding equipment at either a stand alone BSC or an RXCDR, subrate

multiplexing can increase the number of channels an E1 line can carry. This reduces the number
of leased E1 lines and saves lease costs.
Transcoding
To achieve the greatest cost reduction, transcoding is located at the remote end of the BSS (the
end farthest from the BTS site Air Interface).
However, the XCDR can reside at either:

A BSC.
A Remote XCDR (RXCDR) site located at the MSC.
Transcoding occurs at the XCDR, which can be located anywhere between the MSC and BSS,
but is normally located at the MSC site.
Sample line reductions
In this application, one E1 line (120 x 16 kbps or 240 x 8 kbps channels) connecting the XCDR
and BSC can carry the traffic data information of four E1 lines (4 x 30 x 64 kbps channels)
connecting the MSC and the BSC. The 120 x 16 kbps or 240 x 8 kbps channels route through the
BSC to other E1 lines connected to the BTSs.
RXCDR interfaces
The RXCDR has interface ports to the MSC and BSC. Each port provides a four-wire E1 digital
carrier transmission. Each E1 line consists of one Tx wire pair and one Rx wire pair.
The E1 digital carrier is time division multiplexed and has timeslot channels.
The basic differences between the RXCDR-to-MSC (A interface) and the RXCDR-to-BSC
interfaces are:
The format of the information in the timeslots.
The number of trunks, due to the different rates (16 kbps and 64 kbps).
1-82 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation RXCDR description
Each timeslot can contain user traffic in different formats, different types of signaling or control
information or both. When a format is assigned to a timeslot, it is classified as a channel.
RXCDR description
The RXCDR is housed in a standard BSSC2 cabinet. The RXCDR consists of four major
components:
Interconnect panel.
Power Distribution Unit (PDU).
Remote XCDR Unit (RXU) shelves.
Equipment cooling system.
RXU shelf modules
The RXU shelf house the digital modules that the RXCDR requires. The modules related to
traffic flow and traffic control are:
KSW, DSW.
GPROC/GPROC2/GPROC3.
XCDR, GDP, GDP2.
MSI, MSI-2.
GCLK.
KSWX, DSWX.
LANX.
CLKX.
All the devices valid in an RXU shelf are valid in a ngRXU shelf.
Interface redundancy
Each RXCDR site uses an E1 line as a digital carrier to connect to the BSC and MSC. Therefore,
the site requires at least one line interface module, either an MSI or XCDR.
Use an MSI or MSI-2 module to connect to the BSC.
Use an XCDR, GDP, or GDP2 module to connect to the MSC.
68P02901W36-S 1-83
Jul 2008
RXCDR links Chapter 1: BSS Functional Description
Each line interface module provides an interface for two E1 circuits. To provide interface
redundancy, the following are required:
An additional E1 line.
An additional XCDR or GDP module.
RXCDR links
The Remote XCDR links are:

XCDR signaling Link (XBL).
Operations and Maintenance Link (OML).
XBL
This is an optional link for control and communications between the RXCDR and BSC. Signaling
data is communicated between the BSC and RXCDR. The XBL provides two-way communication
between the GPROC2, GPROC3, or GPROC3-2 in the BSC and RXCDR. A dedicated 64 kbps
timeslot or 16 kbps group of a timeslot is used on the E1 line between the RXCDR and the BSC.
The XBL enables the RXCDR to report failed traffic circuits at the RXCDR to the BSC. The BSC
performs different functions depending on the type of fault the RXCDR reports:
If RXCDR traffic circuits fail, the BSC disables the circuits by sending blocking messages
to the MSC.
If there are internal RXCDR circuit faults, or faults that do not cause the loss of the
serial communications link, the BSC blocks the affected traffic circuits. For example, if
an XCDR or GDP board fails, the BSC blocks the 30 traffic channels associated with that
XCDR or GDP board.
OML
This link is for control and communications between the BSS and OMC.
The RXCDR can provide an OML for each BSC connected to it. OML links from BSCs are nailed
through the RXCDR and OML links from the RXCDR are direct to the OMC-R. The OML uses the
X.25 protocol.
This link allows data communications between the OMC-R and the BSS. The OMC-R uses the
OML to:
Load software.
Load configuration parameters.
Send messages to and receive messages from the BSS.
1-84 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Traffic and signal flow through the RXCDR
Traffic and signal flow through the RXCDR

Overview
This section outlines the flow of downlink and uplink traffic through the transcoder.
Definitions
Port
A TDM bus timeslot is referred to as a port.
Nailed connection
There is a fixed relationship between the ports on the inbound TDM highway and the ports on
the outbound TDM highway. This fixed relationship is called a nailed connection.
Downlink traffic flow
Downlink traffic flows from the MSC to the RXCDR through a E1 circuit in standard format.
Each timeslot contains one 64 kbps traffic channel.
Uplink traffic flow
Uplink traffic flows from the MS to the BTS in 8 kbps (HR) and 16 kbps (FR) GSM channels.
Each channel contains 13 kbps vocoder channel used on the Air Interface, plus 3 kbps of control
information into a single 64 kbps timeslot.
68P02901W36-S 1-85
Jul 2008
8 kbps switching operational requirements Chapter 1: BSS Functional Description
8 kbps switching operational requirements

Switching operational requirements
For a call to use 8 kbps backhaul, the BSC site and CIC assigned for the call must have DSWs
installed to be 8 kbps capable. If one or more of the switches in the site are KSWs, 8 kbps
switching is not enabled. Also, the RTF to which the call is assigned must be configured for 8
kbps (through the allow_8k_trau parameter). Additionally, for 8 kbps backhaul between the
RXCDR and BSC, the RXCDR must have the appropriate hardware.
A remote or local transcoding BSC is 8 kbps capable if only DSWs (not KSWs) are physically
present in the site and it is running 8 kbps capable software load. The same constraints are
applicable to an RXCDR.
BTS sites which support Half-Rate (AMR or GSM) employ statically switched Abis backhaul, that
is 64 kbps connections, made in the switching hardware when the RTF comes in service and
connections are not made per call. The channel coder processor is capable of generating either
16 kbps or 8 kbps TRAU format in the 64 kbps timeslots as determined by the allow_8K_trau
parameter and the capability of the call.
A CIC is 8 kbps capable if supported by a GDP, EGDP, or GDP2 running 8 kbps capable software
load. An in use Ater channel is 8 kbps capable if the RTF uses 8 k packed TRAU for Half-Rate
(HR) backhaul, in addition to the RXCDR and BSC being managed by DSWs.
An RTF specified for HR can use two timeslots for backhaul if the HR ACS does not include the
7.95 kbps codec mode and the carrier is not used for EGPRS or GPRS CS3/4.
When using remote transcoding, calls are 8 kbps half-rate capable if they use 8 kbps between
the BSC-BTS and BSC-RXCDR. Calls are also considered 8 kbps HR capable if they use 8 kbps
sub channels between the BSC and BTS and 16 kbps sub channels between the BSC and RXCDR
(half of the 16 kbps sub channel being unused).
1-86 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Switching operational requirements
The two configurations for 8 kbps half-rate capable calls with remote transcoding can be seen
in Figure 1-28.
Figure 1-28 8 kbps half-rate for remote transcoding
(E)GDP/GDP2 (E)GDP/GDP2
16 kbps 16 kbps
Ater-CIC Ater-CIC
connection connection
8 kbps idle tone
8 kbps 8 kbps
Ater-RCI Ater-RCI
connection connection
8 kbps 8 kbps
RCI-RTF RCI-RTF
allocation allocation
68P02901W36-S 1-87
Jul 2008
Switching operational requirements Chapter 1: BSS Functional Description
For local transcoding, a call is 8 kbps HR capable if 8 kbps can be used between the BSC
and BTS as shown in Figure 1-29.
Figure 1-29 8 kbps HR for local transcoding
(E)GDP/GDP2
8 kbps
RCI-CIC
connection
BSC switch
8 kbps
RCI-RTF
connection
BTS switch
The BSC is capable of connecting to a mixture of 8 kbps capable and non capable RXCDRs and a
mixture of RXCDRs with and without Enhanced Auto Connect (EAC) mode operator enabled. A
reciprocal arrangement is implemented for the RXCDR.
If EAC mode is enabled for an AXCDR, the RXCDR notifies the BSC of its 8 kbps capability
during initialization. If the RXCDR and BSC are both capable of 8 kbps switching and EAC mode
is enabled and 8 kbps switching is used on the BSC-RXCDR interface as required.
The AXCDR state is changed to busy-unlocked EAC state when EAC mode is enabled and the
BSC-RXCDR is capable of 8 kbps switching.
In EAC mode (using 16 kbps backhaul), if the CIC used for a call is changed through an
assignment request from an enhanced transcoding CIC to a basic GDP or XCDR a 16 kbps Ater
is used. If, in EAC mode during a call, the CIC is changed by a CIC remap from an EGDP or
GDP2 to a GDP or XCDR, the new CIC uses a 16 kbps Ater. In addition, 16 kbps Abis backing is
used between the BSC and BTS. A change in the rate of the call is only required if 8 kbps HR is
being used by the call when the remap request is received.
1-88 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation EGPRS user interface requirements
EGPRS user interface requirements

User interface requirements
For EGPRS, the following user interface requirements must be noted:
The BSS allows the operator to specify the terrestrial resource capacity of an RTF; the mutually
exclusive options are 16 kbps, 32 kbps, or 64 kbps.
The BSS allows an RTF to be configured as an EGPRS-capable RTF using the RTF parameter
pkt_radio_type and no longer use the parameter allow_32k_trau. The allow_32K_trau
parameter is not supported and the operator is not allowed to modify or display this parameter.
If the PBCCH/PCCCH feature is enabled, the BSS overrides the database parameter
The dependencies between allow_32k_trau, init_ul_cs and init_dl_cs parameters are not
extended to pkt_radio_type.
{26481} The BSS does not allow the equipage of an RTF that supports 64 kbps terrestrial
timeslots at a site that does not contain any Horizon macro, Horizon macro extension, Horizon
II macro, Horizon II macro extension, Horizon II mini, Horizon II mini extension, Horizon II
micro, or Horizon II micro extension cabinets.
{26481} To equip an RTF with 64 kbps terrestrial backing, at least one cabinet type at the
site must be a Horizon macro or Horizon macro extension, or Horizon II macro or Horizon II
macro extension cabinet or Horizon II micro, or Horizon II micro extension cabinet, Horizon II
mini, or Horizon II mini extension.
The BSS allows EGPRS RTFs and GPRS RTFs to be equipped in the same cell but does not allow
equipage of EGPRS RTFs with associated RSLs or sub-equipped EGPRS RTFs.
The BSS displays the 64 kbps terrestrial timeslots allocated for an EGPRS air timeslot using
the disp_mms_ts_usage command which displays all E1 terrestrial timeslots allocated to a
single RTF.
The BSS displays the following EGPRS-related information using the disp_cell_status command
when EGPRS is not restricted:
Support of EGPRS Packet Channel Request.
EGPRS cell status.
Number of EGPRS timeslots currently configured.
Number of blanked air timeslots on carrier B when an EGPRS RTF is mapped to carrier A
of a DD CTU2.
68P02901W36-S 1-89
Jul 2008
User interface requirements Chapter 1: BSS Functional Description
The BSS displays the air timeslots configured for EGPRS using the disp_rtf_channel command.
This command also shows any air timeslots configured as 64 kbps PDTCHs. Additionally, the
disp_rtf_channel command conditionally indicates the air timeslots currently capable of
supporting EGPRS. For example, if a 64 bps RTF is assigned to a non-single density CTU2,
the MMI would indicate that the RTF is not currently capable of supporting EGPRS. The BSS
displays OOS using the disp_rtf_channel command for air timeslots blanked out on carrier B
when an EGPRS RTF is mapped to carrier A of a DD CTU2.
The BSS supports the configuration of the Bit Error Probability (BEP) filter averaging period
used for filtering channel quality measurements by the mobile in EGPRS cells.
This is defined by the parameter bep_period, which is further defined in GSM 05.08. The
bep_period is broadcast either in the GPRS cell options of the System Information Type 13
message on the BCCH as defined in 04.18 or the Packet System Information Type 1 and 13
on the PBCCH as defined in 04.60.
The BSS supports the configuration of an optional second bit error probability (BEP)
filter-averaging period used for filtering channel quality measurements by the mobile in EGPRS
cells.
This is defined by the parameter bep_period2, which is further defined in GSM 05.08. The
bep_period2 can be sent in the Packet Uplink Assignment and Packet Downlink Assignment
messages as defined in 04.60. The bep_period2 can also be sent in the Immediate Assignment
message on the CCCH as defined in 04.18. The Motorola BSS does not send the mobile
station the bep_period2 value and instead the mobile station uses the broadcast parameter
bep_period to perform the bit error probability filter averaging.
The BSS supports the configuration of the tlli_block_channel_coding information element

to allow the mobile to send contention resolution blocks (blocks containing the TLLI) in the
commanded coding scheme for the TBF, CS1-4, or MCS1-9.
The disp_cell_map command is updated to indicate EGPRS status when EGPRS is not restricted.
The min_gprs_ts_per_carrier parameter is no longer supported; the operator is not allowed

to modify or display this element.
The BSS supports the ability to operator-configure two GDSs for TRAU on an MSI in the PCU.
The BSS implements changes to the pkt_radio_type parameter using modify_val in the RTF.
Changing this parameter results in the RTF going out and back into service.
The pk_radio_type parameter currently does not require that the carrier be reset to configure
the new backhaul. This is because the current 16 kbps backhaul simply uses a subset of the
32 kbps backhaul. With the addition of 64 kbps backing, the TRAU interface is completely
rearranged and it is not possible to change between 16 kbps and 64 kbps TRAU or 32 kbps and
64 kbps TRAU. Since this parameter is only changed occasionally, the RTF is unequipped and
re-equipped when changed.
The BSS does not restrict the number of switchable and reserved PDCHs in cells due to TRAU
GDS bandwidth.
The BSS allows over-provisioning of the GDS resources when modifying the pkt_radio_type
of an RTF.
The BSS prevents the equipage of an RTF with Packet Radio Capability set to 64 k and a hopping
system which is shared with any other RTF that is not a 64 k RTF outside of sysgen. Sysgen fails
if the BSS attempts this function.
The BSS only allows equipage of an RTF with Packet Radio Capability set to 64 k and base band
hopping if the master cabinet at the site is a Horizon II macro cabinet. Sysgen fails if the
master cabinet is not a Horizon II macro cabinet.
1-90 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation User interface requirements
The operator is able to configure an initial downlink MCS parameter for EGPRS mobiles that
has the range of 0-8 and is able to configure an initial uplink MCS parameter for EGPRS mobiles
that has the range of 0-8.
The BSS does not restrict setting the init_dl_cs and init_ul_cs to CS3 or CS4 based on RTF
equipage.
68P02901W36-S 1-91
Jul 2008
Interleaving of GPRS and EGPRS mobiles Chapter 1: BSS Functional Description
Interleaving of GPRS and EGPRS mobiles

Interleaving
For EGPRS, the BSS has the following functionality:

Supports interleaving both GPRS TBFs and EGPRS TBFs on the same EGPRS timeslot.
EGPRS mobiles can use MCS5-9 provided the PCU does not require to send a USF to a
GPRS mobile. If the PCU requires to send the USF to a GPRS mobile, the downlink coding
scheme is downgraded to MCS 4.
The BSS preferentially allocates EGPRS-capable MSs to EGPRS timeslots and when an
EGPRS MS is assigned to a timeslot(s), preference is given to EGPRS timeslots.
The BSS preferentially allocates GPRS-only MSs to GPRS timeslots and when an MS which
is only capable of GPRS coding schemes is assigned to a timeslot(s), preference is given
to GPRS timeslots.
The BSS segregates GPRS and EGPRS TBFs when the timeslots to which predominantly
GPRS TBFs are assigned are less loaded than the timeslots to which predominantly EGPRS
TBFs are assigned to attain highest possible cell throughputs and balance the load.
The BSS interleaves GPRS and EGPRS TBFs to attain high cell throughput and balance
the load.
The uplink and downlink TBFs associated with a given MS have the same EGPRS or GPRS
TBF mode.
The BSS biases the downlink timeslot when block scheduling towards a GPRS TBF when
interleaving GPRS and EGPRS TBFs on a timeslot and the uplink TBF on the timeslot
is a GPRS TBF.
The BSS assigns GPRS-mode TBFs in response to EGPRS channel requests when there are
no EGPRS resources available.
1-92 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GSM Half-Rate
GSM Half-Rate

GSM Half-Rate (GSM-HR) provides enhanced capacity over the air interface, corresponding to
the proportion of mobiles within a coverage area that supports HR. An air timeslot is split into
two sub channels, each containing an HR channel.
The backhaul between the BTS and BSC can be either 8 k or 16 k. Where 8 k backhaul is utilized
between the BSC and BTS the operator can configure 8 k backhaul between the BSC and RXCDR
and efficiencies can be gained in not matching the number of 16 kbps Aters to configured CICs.
68P02901W36-S 1-93
Jul 2008
Dual band Chapter 1: BSS Functional Description
Dual band

Overview
In dual band operation a single Horizon II macro, Horizon II macro extension, Horizon II mini,
Horizon II mini extension, Horizon II micro or Horizon II micro extension cabinet can contain
CTU2s operating in both 900 MHz and 1800 MHz bands; a maximum of three CTU2s operating
in the 900 MHz band and a maximum of three CTU2s operating in the 1800 MHz band. When
not in dual band operation the cabinet can contain a maximum of six CTU2s operating in the
900 MHz band or a maximum of six CTU2s operating in the 1800 MHz band.
Equip all 900 MHz radios in slots 0 to 2 or slots 3 to 5. Also, equip the 1800 MHz radios in the
slots that are not occupied by the 900 MHz radios.
1-94 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BSC reset management
BSC reset management

Overview
BSC reset management introduces the capability of swapping between active and standby
BSPs when master BSP GPROC fails. In addition, the BSP recovers most useful information
automatically instead of manual restoration and more diagnostic data is collected for analysis by
development and customer support teams.
Deploying this feature:

Decreases BSC outage time from about 10-20 minutes to about 2 minutes.
Provides more BSC diagnostic data (such as timing, time-outs, measurements of common
factors, system utilization) for greater error handling control and fault diagnostics.
Provides the capability of preserving device and function unit states in advance to BSP
switchover.
Preserves the alarm history in advance to the BSP switchover.
Following switchover, the BSC initiates a BSSMAP global reset to ensure the
MSC/RXCDR/BSC/BTS to synchronize status. For PCU, the BSC synchronizes status by disabling
and re-enabling all the GSLs in service. This leads to all the established data and voice calls
being dropped.
The impacts on the BSS system are given in the following sections.
CBC
An LCP (GPROC with LCF function) manages the CBL and this CBL stays INS during BSP
switchover. However, the BSC does not send any service request to the CBC during the BSP
switchover.
RXCDR
The BSP manages Type 1 BSCs XBL links and these links go OOS when the master BSP fails.
The RXCDR connected with this BSC experiences loss of XBL links to the BSC during the BSP
switchover. After the BSC switchover, the XBL links recover at the RXCDR and a BSSMAP global
reset is performed at the RXCDR along with the BSC and BTSs.
OMP (GPROC with OMF) manages Type 2 BSCs XBL links and keep them INS during switchover.
After BSP switchover, the RXCDR performs a BSSMAP global reset along with the BSC and BTSs.
68P02901W36-S 1-95
Jul 2008
OMC-R Chapter 1: BSS Functional Description
OMC-R
The master BSP manages Type 1 BSC OML links, these links go OOS when the master BSP fails.
The OMC-R connected to the BSC experiences loss of OML links to the BSC during the BSP
switchover. After the BSC switchover, the OML links are recovered at the OMC-R.
OMP (GPROC with OMF) manages Type 2 BSCs OML links and these links stay INS during
switchover. The OMC-R is not impacted.
MSC
An LCP (GPROC with LCF function) manages the MTLs and these MTLs stay INS during BSP
switchover. After BSP switchover, the associated MSC is requested to perform a BSSMAP global
reset to release the affected calls and put the associated circuits into idle state.
BTS
An LCP manages the RSLs and keep them during BSP switchover. After BSP switchover, all
the associated BTSs are requested to perform a BSSMAP global reset to clear calls and release
the related resources.
GPRS
The BSC disables the GSLs in service and then re-enables them to clear the data calls
established in advance to the BSP switchover and release related resources.
Availability and limitations
The BSC Reset Management feature is based on the assumptions that:

BSP Redundancy is available in the BSC.
If NVM board is available, it provides 50 K space for the BSC Reset Management Feature
use.
The BSC Reset Management feature has following limitations:
If the NVM board is not available and the site has undergone a powering down, the
collected diagnostic data is lost.
If the NVM board is not available and the site does not undergo a powering down, the
collected diagnostic data is restored from DRAM.
1-96 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Cell OOS enhancement
Cell OOS enhancement

{32340}
Overview
A configurable cell OOS timer allows users to delay the cell OOS message sent by the BSC to a
MS for a short period. This delay provides the BSC an opportunity to recover call processing
during BSC reset management, enabling roaming MSs to remain on the network during the BSC
reset until the timer expires and the cell OOS message is received.
Dependencies
This feature is applicable only for the reset caused due to BSC reset management.
Related commands and parameters
Related parameter
The cell_barred_delay time parameter specifies the duration for which the BSS delays sending
the SystemInformationUpdate message to the MS during global reset procedure.
It has a range of 0-250 seconds, the default value is 0. See 68P02901W23 Technical Description:
BSS Command Reference for more information.
68P02901W36-S 1-97
Jul 2008
Support of RESUME at intra-BSC level Chapter 1: BSS Functional Description
Support of RESUME at intra-BSC level

{27717}
The Support of RESUME at intra-BSC level feature provides BSS system, the flexibility to
suspend or resume GPRS services. The MS requests the network for suspension of GPRS
services by sending Suspend message to the network when:
A GPRS-attached MS enters dedicated mode and the support of Class A mode of operation
is not possible.
An MS in class A mode of operation is handed over to a cell where the support of Class A
mode of operation is not possible.
The BSC tracks the MS status as Suspended when receiving Suspend Ack message from
the SGSN. If the BSS detects that the conditions for the GPRS suspension have disappeared
for an MS in suspended state and there is no RA change, it sends a Resume message to the
SGSN to resume GPRS services. If Resume Ack is received from the SGSN, the BSS sends
Channel Release message with GPRS Resumption bit to the MS for notifying the MS to
resume GPRS service.
The MS resumes GPRS services by sending a Routing Area Update Request message to
the SGSN in the following cases:
If the BSS fails to request the SGSN to resume GPRS services.
If the RR Channel Release message was not received before the MS left the dedicated
mode.
If the MS locally determines that the conditions for the GPRS suspension have disappeared.
The bssgp_t4_timer starts when the BSS sends either Suspend or Resume requests to the
SGSN. After the timer expires, the BSS restarts the timer and resends the message. The BSS
aborts the Suspend or Resume requests after three attempts.
When the lower level calls are preempted, the BSS-initiated resume procedure is not initiated
due to the performance of eMLPP.
1-98 68P02901W36-S
Jul 2008
Chapter
BSS Devices and Functions

This chapter provides a description of the function and operation of the physical devices that
make up the BSS and the software functions that run on those devices. The descriptions are
provided in the order that the device or function would be equipped in the system.

Devices and functions on page 2-3.
Base Station Controller (BSC) on page 2-5.
Base Transceiver Station (BTS) on page 2-10.
Cabinet (CAB) on page 2-14.
CAGE on page 2-15.
Transcoder and Remote transcoder (XCDR and RXCDR) on page 2-16.
Associated BSS (ABSS) on page 2-29.
Associated Transcoder (AXCDR) on page 2-30.
AXCDR and ABSS connectivity on page 2-31.
CELL on page 2-32.
Digital Radio Interface (DRI) on page 2-33.
Receive Transmit Functions (RTF) on page 2-36.
EGPRS terrestrial timeslot allocation with 64 kbps TRAU enabled on page 2-50.
Kiloport or Double Kiloport switch and extension on page 2-53.
Double Kiloport Switch (DSW) on page 2-58.
Generic Clock (GCLK) on page 2-61.
Generic Processors (GPROC, GPROC2 and GPROC3) on page 2-69.
Base Site Processor (BSP) on page 2-76.
Base Transceiver Processor (BTP) on page 2-77.
Code Storage Facility Processor (CSFP) on page 2-81.
Digital radio Host Processor (DHP) on page 2-83.
Link Control Processor (LCP) on page 2-84.
68P02901W36-S 2-1
Jul 2008
Support of RESUME at intra-BSC level Chapter 2: BSS Devices and Functions
Multiple Serial Interface boards (MSI) on page 2-85.
GDP2 on page 2-89.
External Alarm System (EAS) on page 2-93.
Battery conservation in mains power failure on page 2-95.
Base Transceiver Function (BTF) on page 2-96.
Link control function (LCF) on page 2-97.
Operations and maintenance function (OMF) on page 2-100.
GPRS Packet Control Unit (PCU) on page 2-101.
Equipping GPRS devices on page 2-105.
{23306} BSC overload protection on page 2-129.
{25002} TDM Availability Enhancements on page 2-131.
{22168} Enhanced BSC Capacity using DSW2 on page 2-132.
2-2 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Devices and functions
Devices and functions

Device and function equipage and maintenance
The devices and functions that must be equipped and maintained at BSS sites are described
in this section.
Base Station Controller (BSC).
Cabinet (CAB).
Base Station Transceiver (BTS).
GPRS Packet Control Unit (PCU).
Transcoder and remote transcoder (XCDR and RXCDR).
Associated BSS (ABSS).
Associated transcoder (AXCDR).
CELL.
CAGE.
Digital Radio Interface (DRI).
Kiloport SWitch (KSW) and Kiloport SWitch Expander (KSWX).
Generic Clock (GCLK).
Generic Processors (GPROC and GPROC2).

Base Station Processor (BSP).
Base Transceiver Processor (BTP).
Code Storage Facility Processor (CSFP).
Digital radio Host Processor (DHP).
Link Control Processor (LCP).
Multiple Serial Interface boards (MSI).
External Alarm System (EAS).

Battery conservation in mains power failure.
Base Transceiver Function (BTF).
Link Control Function (LCF).
Operating and Maintenance Function (OMF).
68P02901W36-S 2-3
Jul 2008
Device and function equipage and maintenance Chapter 2: BSS Devices and Functions
Timeslot Reservation.
E1 Link Management.
Aggregate Abis.
Receive Transmit Functions (RTF).
PSP-PCU System Processor.
DPROC-Data Processor.
2-4 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Base Station Controller (BSC)
Base Station Controller (BSC)

BSC description
The BSC controls one or more Base Transceiver Stations (BTSs) and acts as the digital
processing interface between the BTS and the MSC. Additional information regarding the BSC
can be found in Chapter 3 of the System Information: GSM Overview (68P02901W01) manual.
Each Base Station System (BSS) site consists of one Base Station Controller (BSC) and several
Base Transceiver Stations (BTSs), Transcoder (XCDR)/Remote Transcoder (XCDR) and up to
three Packet Control Units (PCU) if the General Packet Radio Service (GPRS) is available.
Figure 2-1 shows the BSC within the BSS and its relationship to other network elements.
Figure 2-1 The BSC within the BSS

GSM EQUIPMENT GSN EQUIPMENT
MSC HLR RADIUS SERVER PDN

(NON-TRANSPARENT
MODE)
RXCDR OMC-G
(Including Shelf
Manager)
OMC-R
BSC PCU ISS SGSN GGSN
BSSn
GSN
BTSs BSS2 COMMHUB GSNn
BSS1 GSN1
OPERAT OR SER VER

COMPLEX
- RADIUS SERVER
BILLING (OPERAT OR IS ISP,
SYSTEM TRANSPARENT MODE)
- DHCP SERVER
- DNS SERVER
ti-GSM-BSC BSS-00128-ai-sw
68P02901W36-S 2-5
Jul 2008
BSC types Chapter 2: BSS Devices and Functions
NOTE
The term site is used in GSM to represent the BSS in total (by inference the BSC)
and individual BTSs.
Software functions
The software functions are:

Allocation Manager (AM).
Connection Less Manager (CLM).
Switch Manager (SM).
Operation and Maintenance System (OMS).
Message Transfer Part (MTP).
Signaling State Machine (SSM).
BSC types
There are two types of BSC:

Type 1.
Type 2.
Type 1 BSC
As the loading on the BSC within a BSS increases, more processing is required to support the
signaling coming into and going out of the BSC. The software processes that support these are
the Message Transfer Part (MTP) and the Signaling Connection Control Part State Machine
(SSM). These two processes are removed from the BSP and placed onto a new device type called
a Link Control Function (LCF). This is a BSC Type 1 as shown in Figure 2-2.
2-6 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BSC types
Figure 2-2 BSC type 1
If the incorrect site type is entered in the database, problems arise during the initialization
process. The site is downloaded as normal, but on configuration, discrepancies arise in the
database.
Type 2 BSC
The largest type of BSC is a type 2 as shown in Figure 2-3. As the amount of signaling is
increased this can be catered for by adding additional LCFs. The bottle neck is the BSP.
To reduce the load on the BSP the Operations and Maintenance System is placed on its own
processor type, the Operations and Maintenance Processor (OMP).
Figure 2-3 BSC type 2
BSP OMP LCF LCF
CLM MTP MTP

OMS SSM SSM
SM
ti-GSM-BSC type 2-00130-ai-sw
If the incorrect site type is entered in the database, problems arise during the initialization
process. The site is downloaded as normal, but on configuration, discrepancies arise in the
database.
If for example a BSC site was configured as a type 2 instead of 1, on configuration it expects
to find a GPROC to become Operations and Maintenance Processor (OMP), which cannot
physically be either there or equipped in the database. Therefore, configuration of the site
does not take place.
68P02901W36-S 2-7
Jul 2008
Equipping and unequipping a BSC Chapter 2: BSS Devices and Functions
Equipping and unequipping a BSC
The following MMI commands are used to equip and unequip a BSC and are followed by the
equivalent OMC-R facility:
equip (Add a BSS to a network at the OMC-R Navigation Tree).
unequip (Delete a BSS from a network at the OMC-R Navigation Tree).
Equivalent facilities are provided at the OMC-R for performing these functions, as described in
the Installation and Configuration: GSM System Configuration (68P02901W17) manual.
Monitoring a BSC
The following MMI command is used to monitor a BSC and is followed by the equivalent
OMC-R facility:
disp_equipment (Detailed View at the OMC-R)-Displays software and hardware information.
BSC alarms
BSC alarms are of two types: Fault management and Performance management. BSS alarms are
described in full in Maintenance Information: Alarm Handling at the OMC-R (68P02901W26).
BSC 8 kbps switching
BSC 8 kbps switching is enabled when the site is populated with DSW (Double Key Switch)
boards. A BSC changes from operating in 16 kbps to 8 kbps switching when the last Kiloport
SWitch (KSW) board is disabled.
AMR Half-Rate (HR) is disabled for RTFs that have 8 kbps TRAU allowed, if the system is forced
to operate with 16 kbps switching.
Unlock/ins/reset of a KSW device is disabled if the detected hardware contains a KSW, not a
DSW and one or more of the AXCDR devices are in Enhanced Auto Connect (EAC) mode.
A DSW is able to process any given TDM timeslot as one 64 kbps channel, two 32 kbps channels,
four 16 kbps channels, eight 8 kbps channels, or a combination of 32, 16 kbps and 8 kbps
channels.
NOTE
The KSW currently allows 32 kbps channels but the BSS SW does not support it
as there are no current applications for 32 kbps channels. This is maintained with
the introduction of support for the DSW.
2-8 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BSC 8 kbps switching
An alarm is raised if the BSC cannot perform 8 kbps switching and this feature is requested
by the BTS.
68P02901W36-S 2-9
Jul 2008
Base Transceiver Station (BTS) Chapter 2: BSS Devices and Functions
Base Transceiver Station (BTS)

BTS description
The BTS contains the radio components that provide the interface to Mobile Stations for one or
more coverage areas or cells. Detailed information regarding the BTS can be found in Chapter 3
of the System Information: GSM Overview (68P02901W01) manual.
Figure 2-4 shows some BTSs within the BSS and their relationship to the other network
elements.
Figure 2-4 BTSs within the BSS

GSM EQUIPMENT GSN EQUIPMENT
MSC HLR RADIUS SERVER PDN

(NON-TRANSPARENT
MODE)
RXCDR OMC-G
(Including Shelf
Manager)
OMC-R
BSC PCU ISS SGSN GGSN
BSSn
GSN
BTSs BSS2 COMMHUB GSNn
BSS1 GSN1
OPERAT OR SER VER

COMPLEX
- RADIUS SERVER
BILLING (OPERAT OR IS ISP,
SYSTEM TRANSPARENT MODE)
- DHCP SERVER
- DNS SERVER
ti-GSM-BTS BSS-00131-ai-sw
2-10 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BTS types
BTS types
There are two types of BTS:

Type 0.
Type 1.
Type 0 BTS
The smallest is a type 0 where all of the software processes required to support the BTS are
resident on one GPROC called the Base Transceiver Processor (BTP), as shown in Figure 2-5.
Figure 2-5 BTS type 0
Type 1 BTS
As the BTS grows, the RF equipment requires more processing so the relevant software process,
the Radio Subsystem (RSS), is moved from the BTP and placed on a new processor type, the
Digital Radio Host Processor (DHP). This is a BTS type 1, as shown in Figure 2-6.
Figure 2-6 BTS type 1
ti-GS M-BTS type 1-00133-a i-s w
68P02901W36-S 2-11
Jul 2008
Equipping and unequipping a BTS Chapter 2: BSS Devices and Functions
Incorrect type of BTS selected
If the incorrect site type is entered in the database, an alarm is raised and the site is not
downloaded.
Equipping and unequipping a BTS
The following MMI commands are used to equip and unequip a BTS and followed by the
equip (Add a BTS to a network at the OMC-R Navigation Tree).
unequip (Delete a BTS from a network at the OMC-R Navigation Tree).
Monitoring a BTS
The following MMI command is used to monitor a BTS and is followed by the equivalent
OMC-R facility:
BTS alarms
BTS alarms are of two types: Fault management and Performance management. BTS alarms are
described in full in Maintenance Information: Alarm Handling at the OMC-R (68P02901W26)
manual.
Adaptive Multi-Rate (AMR)
Radio platform operational requirements
The BSS only supports 16 kbps sub rate switching at In-cell BTS platforms. A DSW can be
deployed but operates as a 16 kbps, single rate mode switch in an In-cell BTS.
The BSS supports AMR on the following BTSs:

M-Cell 2 BTS with the TCU-B radio platform.
M-Cell 2 BTS with the TCU-A radio platform.
M-Cell 6 BTS with the TCU-B radio platform.
2-12 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Adaptive Multi-Rate (AMR)
M-Cell 6 BTS with the TCU-A radio platform.
Horizon macro with the CTU radio platform.
Horizon macro with the CTU2 radio platform.
Horizon II macro with the CTU2 radio platform.
Horizon II mini with CTU2 radio platform.
{26481} Horizon II micro with the CTU2 radio platform.
The AMR half-rate HR and full-rate FR channel modes are only supported on the CTU, TCU-A,
and TCU-B radio platforms. Therefore, the operator is only allowed to enable the AMR half-rate
and full-rate channel modes at BTS sites that could have CTU, TCU-A or TCU-B radios present.
However, AMR support on TCU-A and TCU-B is a restricted optional feature. CTU AMR support
is covered by the AMR restricted optional feature.
The BSS supports the enabling of the AMR channel modes on a per RTF basis in order to enable
AMR channel modes in cells spanning both Horizon macro and M-Cell 2/6 cabinets.
68P02901W36-S 2-13
Jul 2008
Cabinet (CAB) Chapter 2: BSS Devices and Functions
Cabinet (CAB)

Equipping and unequipping a cabinet at the BSC
Each Base Station Controller (BSC) and Base Transceiver Station (BTS) site must have a cabinet
equipped. Detailed cabinet information for the BSC and BTS can be found in the Service
Manual: BSC/RXCDR (68P02901W38) and Service Manual: BTS (68P02901W37).
{28938}
NOTE
The use of Incell BTS sites within a network can be restricted with the IncellOpt
parameter.
The following MMI commands are used to equip and unequip a cabinet at the BSC and are
followed by the equivalent OMC-R facility:
equip
unequip
the Installation and Configuration:GSM System Configuration (68P02901W17) manual.
Unequipping of TCU/CTU cabinets
{26481} Extension cabinets type TCU_2, TCU_6, Horizon mini2_ext, Horizon micro2_ext and
Horizon macro_ext at M-Cell, Horizonmacro and sites, can be unequipped without having to
unequip the site, provided that the cabinet is locked and there are no DRIs or EASs equipped
to the cabinet.
2-14 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation CAGE
CAGE

Equipping and unequipping a CAGE at the BSC
Each Base Station Controller (BSC) and Base Transceiver Station (BTS) site needs to have a
CAGE equipped.
The appropriate MMI commands are listed, followed by the equivalent OMC-R facility.
equip (Add a cage to a network at the OMC-R navigation tree).
unequip (Delete a cage from a network at the OMC-R navigation tree).
68P02901W36-S 2-15
Jul 2008
Transcoder and Remote transcoder (XCDR and RXCDR) Chapter 2: BSS Devices and Functions
Transcoder and Remote transcoder (XCDR and RXCDR)

Transcoder description
The Full rate Transcoder (XCDR, GDP, or GDP2 boards) is the digital signal processing
equipment required to perform GSM-defined speech encoding and decoding. In terms of data
transmission, the speech transcoder interfaces the 64 kbps PCM in the land network to the 13
kbps (or 8 kbps) vocoder format used on the Air Interface.
The Remote Transcoder (RXCDR) is used when the transcoding is performed at a site away from
the BSC, which is at or near the MSC. Additional information regarding the XCDR and RXCDR
can be found in Chapter 3 of the System Information: GSM Overview (68P02901W01) manual.
Figure 2-7 shows the transcoder and its relationship to other network elements.
Figure 2-7 The Transcoder
2-16 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Transcoder function
Transcoder function
A transcoder is required to merge the input of four E1 64 kbps links into one link.
This transcoder can be included in the BSC cabinet or contained in a separate Remote
Transcoder cabinet (RXCDR). When transcoding is performed at the BSC, the need for an
RXCDR is removed, as the BSC connects directly to the MSC and the OMC.
Remote transcoding at the MSC allows 4:1 multiplexing (8:1 for half-rate) so that the transcoded
data for four logical channels is combined onto one 64 kbps link, so reducing the number of
links required for interconnection to the BSCs.
CICs, OMLs, MTLs, and CBLs can be added to or removed from an in-service XCDR, GDP, or
GDP2 outside of SYSGEN mode, without cycling the board and without affecting the operation
of other devices on the board.
The number of 64 kbps links per XCDR board is limited to six, due to the way the 64 kbps links
are routed through an XCDR board. This limit is enforced when the command to add a link is
executed. Attempts to exceed the limit results in rejection of the command.
Transcoder placement
Transcoder placement at the BSC allows OMLs, MTLs, CBLs, and CICs to be added or removed
outside of SYSGEN mode. The links must be in the locked state before removal. The links are
placed in the locked state when added. CICs can be removed even when involved in a call. If the
CIC is involved in a call, the call is terminated.
The OML, MTL, and CBL links are equipped and unequipped using the following MMI commands
(or specified in a network from the OMC-R Navigation Tree).
equip
unequip
The MMI add_circuit command specifies CIC placement on the XCDR board.
The del_circuit command removes a CIC from the XCDR board.
When a CIC is added, the state of the XCDR board MMS is checked. If the MMS is out-of-service,
the CIC is blocked from use. The blockage is reported to the MSC. If the MMS is in-service,
the CIC is made available for use by the BSC. When the CIC is removed, its state is checked. If
the CIC is blocked, it is unblocked during removal. The unblocking of the CIC is reported to
the MSC. This event occurs to ensure that the present state of CICs, as indicated to the MSC,
matches the state the BSC would send if a reset event occurred.
Remote transcoder placement
When the transcoder is remote from the BSC, equipage is required at the BSC side and at
the RXCDR side.
68P02901W36-S 2-17
Jul 2008
Remote transcoder placement Chapter 2: BSS Devices and Functions
BSC side
Equipage at the BSC for an RXCDR is like that described for transcoder placement at the BSC.
The main difference is that devices must be equipped on the MSI board, because the XCDR
board is not allowed at the BSC when transcoding placement is at the RXCDR.
The OML, MTL, and CBL links are equipped and unequipped using the following MMI commands
(or specified in a network from the OMC-R Navigation Tree). These links can be placed on E1
links destined for the RXCDR or on links destined elsewhere, as required. CICs are equipped on
the MSI board. CICs are equipped on E1 links destined for the RXCDR.
equip
unequip
The MMI add_circuit command specifies CIC placement on the XCDR board as previously
described but additionally requires the group number. The group number indicates the
placement of the CIC within a 64 kbps timeslot on the link.
The del_circuit command removes a CIC from the XCDR board.
Thus, add_circuit can result in an indication to the MSC of a blocked CIC. The del_circuit
command can result in an indication to the MSC of a CIC becoming unblocked or in a call,
being killed.
RXCDR side
The add_rxcdr_link command is used to route 64 kbps links, the OML, MTL and CBL, from the
BSC through an XCDR board at the RXCDR. This command is allowed outside SYSGEN mode.
The chg_ts_usage command cannot be used to nail a connection to an E1 link on an XCDR

board. At an RXCDR, if a nailed connection between an MSI E1 link and an XCDR E1 link is
required, use the add_rxcdr_link command.
The del_link command deletes such a routing. This command is allowed outside SYSGEN mode.
The add_channel command is used to set up the XCDR board to handle transcoding or rate
adaptation for the CIC and to route a CIC to an XCDR board. The command indicates the
location of the CIC on a E1 link on an MSI board. It also indicates the placement of the CIC on
the E1 link on the XCDR board. This command is allowed outside SYSGEN mode.
The del_channel command removes XCDR routing for a CIC. This command is allowed outside
SYSGEN mode.
When an add_channel command is entered, the state of both MMS links (the MSC side MMS
and the BSC side) are checked. The XBL connectivity information is checked for the identity of
the BSC and the link in the BSC that corresponds to the BSC side link. If such information is
found, the state of the two E1 links is stored for transmission to the BSC (the information is
transmitted when an XBL to the BSC is in service). The BSC uses this information to determine
if a CIC should be blocked or should remain blocked. A CIC is blocked or remains blocked if its
BSC link, RXCDR-BSC link, or RXCDR-MSC link is out-of-service.
2-18 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Optional XBL usage
Since the use of XBLs remains optional, XBL connectivity information can be missing. If so,
blocking of the CIC due to RXCDR E1 link state cannot be performed. Any required blocking
is handled when XBL connectivity is added.
The del_channel command also checks XBL connectivity. If connectivity is found, an attempt
is made to report in-service information to the BSC (MSC-side MMS and BSC-side MMS)
regardless of the real state of the MMS. This removes the dependency of the CIC at the BSC on
RXCDR link state. The received information can cause the CIC to be unblocked. The information
is lost if an XBL to the BSC is not in-service.
The del_circuit command in the BSC handles the unblocking of the CIC no matter why the CIC
was blocked. If a CIC is not unblocked when the del_channel command occurs, it is unblocked
when the del_circuit command occurs.
Optional XBL usage
Previously, changing Transcoder to BSS Link (XBL) configurations did not affect the information
transmitted by the RXCDR to the BSC about the BSC-side MMS state and the MSC-side MMS
state of a CIC. State information about CICs affected by the add_xbl_conn command is not
sent to the BSC. Information relating to affected CICs is not deleted when the del_xbl_conn
command was entered.
With online transcoder expansion, when using the add_xbl_conn command, the BSC-side
MMS state and the MSC-side MMS state for the CICs on the BSC side MMS are determined
and stored. If any XBL to the BSC is in service, the BSC is updated with this information. If
such an XBL is not in service, the BSC is updated when the XBL does come into service. For the
del_xbl_conn command, all CICs on the BSC-side MMS are removed from the tables at the
RXCDR. The removal of CIC information generates transmission of the setting of the BSC-side
MMS and MSC-side MMS states to in-service for the CIC to the BSC. This information is not
propagated to the BSC if the last XBL to the BSC is failing or has failed.
Executing the del_xbl_conn can leave a CIC in the blocked state at the BSC due to RXCDR
reported problems. Such a CIC is not unblocked until the BSC is reset. The effect is also seen if
the del_channel command is executed at the RXCDR, but the del_circuit is not executed at the
BSC. Because of this effect, use the del_xbl_conn command with extreme caution. Deleting all
CICs from the BSC-side MMS at both the BSC and the RXCDR is recommendedbefore executing
the command.
MSC, RXCDR, BSC interaction
A CIC must be configured at the MSC and at the BSC before it can be used. The recommended
way to add a CIC, is to first add it to the BSC and only to the MSC when the CIC has been added
to an in-service E1 link. If the CIC is configured only at the MSC, the BSC terminates any call
attempting to use the CIC and reports an alarm. If the CIC is configured only at the BSC, the
BSC can attempt to block a CIC not known by the MSC. The effect on the MSC of such an
action is dependent upon the MSC vendor.
Removal of a CIC can cause similar problems as addition of a CIC for the MSC and the BSC. A
CIC can be safely removed, first from the MSC and then the BSC, if the E1 links used by the CIC
are in service. If they are not, the BSC can try to unblock a CIC which the MSC is unaware.
68P02901W36-S 2-19
Jul 2008
Quiet tone on the E1 link Chapter 2: BSS Devices and Functions
The RXCDR reports E1 link states to the BSC as E1 links in the RXCDR change state based upon
XBL connectivity information and based upon add_channel information. If the information from
the RXCDR does not relate to a known CIC, the BSC ignores the information from the RXCDR.
Hence, add a CIC to the BSC before the add_channel command is entered at the RXCDR, if
either of the E1 links involved in the command are out-of-service in the RXCDR. Until the RXCDR
handles the add_channel command, any calls using the CIC associated with that particular
add_channel command lacks voice or data, even though the calls are successfully placed.
If the BSC has no corresponding CIC, the BSC ignores RXCDR E1 link information. Hence, the
del_channel command should be entered at the RXCDR after the del_circuit command at the
BSC. If the command is entered before the del_circuit command, any calls involving the call
will lack voice or data, even though the calls are successfully placed.
XBL connectivity information depends upon E1 link existence. Enter XBL connectivity
information before devices are placed upon an XCDR if an XBL is configured (it is optional).
Quiet tone on the E1 link
During call setup or handover the MSC-RXCDR circuit is idle. The bit pattern that the MSC
transmits and expects to receive for this condition is called MSC quiet tone. MSC quiet tone
sets the background noise level when both speakers are not talking.
All timeslots on an XCDR board E1 link that do not have a CIC or link contain quiet tone from
the TDM highway. The KSW device is used to generate the tone as set by the msc_qt database
parameter of the chg_element command. The tone is taken from the TDM highway and placed
on the E1 link by the XCDR board. The quiet tone can still only be set in SYSGEN mode. The
msc_qt parameter can only be set at the SITE where transcoding occurs. The quiet tone can
only be set in SYSGEN mode.
NOTE
The msc_qt parameter replaced the xcdr_msc_qtone command.
Impact of online transcoder expansion on site severity
The add_channel, del_channel, add_circuit and del_circuit commands can affect the site
functional unit severity calculations, as these commands change the number of CICs available
at the site. Since these commands modify an internal non reported device, no device state
change occurs. BEGIN and END reconfiguration indications are withheld when no device state
change occurs. online transcoder expansion eliminates this problem by forcing a BEGIN and
an END reconfiguration indication to be generated, even though no state change is reported.
The BEGIN reconfiguration indicates that the MPRT device is affected. The change in the site
severity, if any, is reported in the END reconfiguration indication.
2-20 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Enhanced Full-Rate speech
Enhanced Full-Rate speech
The Enhanced Full-Rate (EFR) speech function can optionally provide calls involving phase 2
(and above) MSs with superior voice quality. This is achieved by using a modified transcoding
algorithm on Generic DSP Processor (GDP) boards instead of the XCDR boards. Call setup
is handled in the usual way, except that the MSC must know the MS capability before the
assignment request is sent to the BSC. The MS provides this information while on its SDCCH
in the Call Setup DTAP message. The MSC then indicates in the assignment request message
that the BSS provides an EFR, or full-rate channel. The RXCDR is not involved in any call setup
signaling and cannot anticipate whether the speech is EFR or full-rate until it reaches the GDP.
The first speech of any call is always in the uplink direction, so the GDP detects the first TRAU
and uses EFR or full-rate as appropriate from then on in the call (AMR is only supported on
EGDP and GDP2). Figure 2-8 shows the signaling sequence when EFR is unrestricted.
EFR must be unrestricted (enabled) at the BSC and RXCDR, using the efr_enabled parameter.
Equip the GDP boards to handle all transcoding associated with EFR traffic circuits. To
accommodate this a new msi_type value of 2 (or GDP) is now acceptable in the equip 0 MSI
command.
68P02901W36-S 2-21
Jul 2008
Enhanced Full-Rate speech Chapter 2: BSS Devices and Functions
Figure 2-8 illustrates enhanced full-rate speech signaling.
Figure 2-8 Enhanced full-rate speech signaling
2-22 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Handovers in EFR
Handovers in EFR
When a handover occurs, the behavior of the BSS in terms of EFR depends upon whether
the handover is internal or external.
Internal handovers
As EFR is enabled on a per BSS basis, the target cell provides a channel of the same type (EFR
or full-rate) as was being used in the source cell.
External handovers
External handovers, in the target cell, use whichever algorithm is enabled in the target BSS,
chosen as described in the call setup (efr_enabled). It is important to ensure that the speech
version in use in the source cell is indicated in the HANDOVER REQUIRED message. This is so
that the source and target speech version can be compared in order to inform the MS, in the
Handover Command, of the type of transcoding to be used in the new cell if that is different
from the source cell. This is set by the handover_required_sp_ver_used parameter. Failure
to set this can result in garbled or no speech, as it is assumed that the source cell was using
full-rate; if the target cell chooses full-rate but the source was in reality using EFR, the MS is
not told to change mode in the Handover Command. This enables EFR speech to be transmitted
by the MS into a full-rate only BSS.
Enhanced Generic DSP Processor (GDP) provisioning
GDP function
In order to enhance transcoding features, MSI boards which currently terminate Abis E1 links,
can be replaced by GDPs. A GDP pair provides 30 enhanced transcoding circuits, with each DSP
connected to the MSC MMS timeslot for the related CIC. Connection of the subrate TRAU data
from the DSPs towards the BTS can be static (at the RXCDR) or dynamic, that is, connected on a
per call basis (at the RXCDR or BSC) as shown in Figure 2-9 and Figure 2-10. GDPs can only be
paired with other GDPs; pairing with XCDRs is not supported.
68P02901W36-S 2-23
Jul 2008
GDP function Chapter 2: BSS Devices and Functions
Figure 2-9 GDP pairing at an RXCDR or BSC
E1 link to link
MSC
2-24 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Equipping and unequipping an RXCDR
Figure 2-10 GDP replacing an MSI board
The enhanced GDP provisioning function requires two specific BSS parameters:
msc_mms_id is used in enhanced GDP provisioning to specify the E1 link to be used to
route data for the transcoding circuits from a GDP towards the MSC.
transcoding_capability specifies the functionality provided by a GDP board.
Equipping and unequipping an RXCDR
When an RXCDR is used, the links between it and the BSC and MSC (usually at the same
site) needs the following equipage:
SITE.
CAB.
CAGE.
AXCDR.
KSW.
BSPs.
GCLK.
MSIs.
OML 64 kbps X.25 link between the RXCDR, BSC, and the OMC.
CIC (Circuit Identity Code) Terrestrial Circuit 64 kbps link to the MSC used for a call.
68P02901W36-S 2-25
Jul 2008
After equipage Chapter 2: BSS Devices and Functions
MTL 64 kbps CCITT C7 or ANSI SS7 link between the BSC and the MSC.
CBL 64 kbps X.25 link between the BSC and the Service Center.
XBL.
DSP.
The CIC is received from the TDM highway at the XCDR board in 16 kbps (or 8 kbps) GSM
TRAU format. It is transcoded to a 64 kbps format for the MSC. For voice calls, the TRAU
format is converted into 64 kbps A-law or -law format. For data calls, the 16 kbps TRAU
format is rate adapted to 64 kbps. The XCDR board doesnot modify the OML, MTL, and CBL.
The XCDR board places 64 kbps timeslots from the TDM highway onto 64 kbps timeslots on the
E1 link to the MSC and vice versa.
The devices and links above are equipped and unequipped using the following MMI commands
(or specify the devices in a network from the OMC-R Navigation Tree).
equip
unequip
After equipage
After the site is equipped, the chg_element command is used to set the fm_site_type and after
the CAGE is equipped, the gproc_slots and the BSC type.
In addition the following must be configured:
MMS thresholds (modify_value command) with the following parameters:

phase_lock_duration
mms_priority
OML and MTL descriptions (chg_element command) with the following parameters:
stat_interval
ber_loss
remote_loss
remote_time
slip_loss
sync_loss
sync_time
phase_lock_gclk
wait_for_reselection
lta_alarm_range
2-26 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Add circuit and add channel relationship
The above groups of parameters specify hourly and daily settings. These can also be set from
the OML and MTL link detailed views on the OMC-R Navigation Tree.
The channels and links also must be established:
RXCDR link - add_rxcdr_link command (or in a network from the OMC-R Navigation Tree).
BSS link - add_bss_conn command (or in a network from the OMC-R Navigation Tree).
Channels - add_channel command.
Add circuit and add channel relationship
It is important that the circuit identifier in the MSC physically matches the circuit identifier
in the BSC, because the MSC uses some circuit numbering conventions. Otherwise dynamic
switching in the BSC is seriously impaired. The numbering conventions used by the MSC
are as follows:
Circuit identifier 0 is never used.
Circuit identifier 16 and multiples of 16 are never used.
This numbering scheme is illustrated below:

1st link circuit identifiers 1 to 31, Timeslots 1 to 31 (16 omitted).
2nd link circuit identifiers 33 to 63, Timeslots 1 to 31 (16 omitted).
3rd link circuit identifiers 65 to 95, Timeslots 1 to 31 (16 omitted)
and so on.
The idea of this from the MSC perspective is that circuit identifiers match timeslot numbers
in a set pattern.
Ater interface in Enhanced Auto Connect (EAC) mode
The connection and disconnection messages sent from the BSC to RXCDR contain the CIC, the
rate and the Ater resources. The BSC and RXCDR are able to queue XBL messages to prevent
loss during periods of heavy traffic. If, at site initialization or during normal operation, in
EAC mode there are no XBLs in service for an RXCDR the BSC blocks all CICs associated
with the RXCDR.
Messages sent from the BSC to RXCDR in EAC must be acknowledged. If acknowledgment is
not received for a message sent from the BSC to RXCDR a retry is attempted by the BSS. If
acknowledgment is still not received for a retry from the BSC to RXCDR then the call is aborted
and the associated resources blocked. If 8 kbps Aters were contained in the original message
the BSS blocks the other associated 8 kbps Aters due to validation failure.
The validation failure state is cleared for these resources by the next successful audit on these
resources. The successful audit is by the existing CIC or Ater audit depending on the resource
affected. The BSS includes an audit of the CIC-Ater assignments as part of the periodic AXCDR
audit, configured using the MMI command chg_audit_schedule.
When the first XBL comes into service for an AXCDR, the BSC initiates an audit of the CIC-Ater
assignments with the RXCDR.
68P02901W36-S 2-27
Jul 2008
Adaptive Multi-Rate (AMR) Chapter 2: BSS Devices and Functions
The BSS audits the CIC-Ater connections to check for mismatches between the BSC and RXCDR.
This audit occurs periodically with the AXCDR audits which are configured using the MMI
command chg_audit_schedule and is triggered by the following events:
The first INS XBL for an AXCDR.
When the BSS starts EAC mode.
The audit is only applied to CICs and Aters that are connected at the BSC.
Following the completion of a periodic audit the BSS makes CIC-Ater connections on a 16 kbps
basis, using the same algorithm as Auto Connect mode. If the RXCDR detects a mismatch in the
CIC-Ater connection as part of an audit, the RXCDR sends a mismatch to the BSC. When the
BSC receives a status of mismatch from the RXCDR the BSC initiates a clean up mechanism
to correct the faults found.
When an MSC initiates global reset the BSC will break all the call connections and notify all its
connected AXCDRs that are operating in EAC mode to clean up all operations associated with
the BSC. The operations are cleaned up at the RXCDR to ensure that the BSC does not receive
any unexpected messages due to outstanding operations after the global reset has completed.
Once the global reset has completed a full audit will occur and any differences in the CIC-Ater
connections will be identified and corrected.
Ater switchover
An Ater switchover usually occurs because of a faulty Multiple Serial Inteface (MSI) board, span
line (MMS). An Ater switchover is initiated to transfer all the CICs and calls currently connected
to Aters on the failed MMS or timeslot to a fully functioning MMS.
When an Ater switchover is initiated for a full-rate call, or half-rate call using a 16 kbps Ater,
in Enhanced Auto Connect (EAC) mode, a new Ater resource is allocated using the following
priorities:
Allocate a new 16 kbps resource.
Allocate two contiguous 8 kbps resources on the same timeslot and group.
When an Ater Switchover is initiated for a half-rate call using an 8 kbps Ater in EAC mode a
new Ater resource is allocated using the following priorities:
Allocate an 8 kbps Ater while the other 8 kbps is already in use.
Allocate 8 kbps of an idle 16 kbps Ater.
NOTE
A half-rate call can require 16 kbps Ater resource backing in EAC mode because
8 kbps switching is not being performed or because the 7.95 kbps codec mode
is in the ACS.
2-28 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Associated BSS (ABSS)
Associated BSS (ABSS)

Associated BSS function
The Associated Base Station System (ABSS) is equipped at a Remote Transcoder (RXCDR) to
provide the robust communication between the RXCDR and BSC offered by the Enhanced XBL
function. Corresponding AXCDRs must be equipped at the BSC.
Equipping and unequipping an ABSS
An ABSS device can be equipped only at an RXCDR site.
ABSSs can be equipped with the system in SYSGEN ON mode.
This device can also be equipped when the system is outside the SYSGEN ON mode and it is
to be the standby device.
An ABSS device can not be unequipped if it is specifically referenced in the BSS-RXCDR

connectivity table.
The operator is prompted for the ABSS number, whether Enhanced Full-Rate (EFR) is enabled,
the volume control type and the downlink and uplink audio level offsets.
Disabling CIC validation for an ABSS
To change between Auto connect and Backwards Compatible mode, the operator must enable
or disable CIC validation. When changing CIC validation for an ABSS, the operator uses the
modify_value command with the cic_validation parameter.
WARNING
CIC validation must only be enabled or disabled when in sysgen mode or after the
modify_value command is executed. Cycle the BSC after changing the CIC validation
parameter state to reinitialize all BSC mapping.
68P02901W36-S 2-29
Jul 2008
Associated Transcoder (AXCDR) Chapter 2: BSS Devices and Functions
Associated Transcoder (AXCDR)

Associated transcoder function
Associated transcoders (AXCDRs) are transcoders (XCDRs or RXCDRs) which can be used for
dynamic allocation of RXCDR to BSC Circuits (DARBCs). Such RXCDRs must also be equipped
as AXCDRs.
Equipping and unequipping an AXCDR
The equipage of an AXCDR, only at a BSC that is set to remote transcoding, is by use of the MMI
equip command (or specifying the devices in a network from the OMC-R Navigation Tree).
The Associated RXCDR (AXCDR)can be equipped with the system in SYSGEN ON mode.
The AXCDR can not be unequipped if it is specifically referenced in the BSS-RXCDR connectivity
table.
The operator is prompted for the RXCDR number and whether CIC validation is to be performed.
For the command to be accepted, Yes must be entered. The entry No results in the following
message:
COMMAND REJECTED: CIC Validation must be turned on for dynamic allocation site.
Disabling CIC validation for an AXCDR
To disable CIC validation for an AXCDR while dynamic allocation mode is disabled, the operator
uses the modify_value command with the cic_validation parameter. An attempt to disable
CIC validation for an AXCDR while dynamic allocation mode is enabled, results in the following
message:
COMMAND REJECTED: Cannot disable CIC Validation while in dynamic allocation mode.
The AXCDR device must be cycled when disabling cic_validation to ensure all calls to the
RXCDR are dropped. All calls must be dropped when disabling cic_validation as the RXCDR
will make different switch connections when cic_validation is off to those made at the
instruction of the BSC when cic_validation is enabled. If calls are not disconnected by the BSC,
existing calls could be re routed to incorrect destinations.
2-30 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation AXCDR and ABSS connectivity
AXCDR and ABSS connectivity

Setting connectivity between AXCDR and ABSS
The MMI command add_conn is used to set up the connections between the AXCDR and the
ABSS. Likewise, the MMI command mod_conn is used to change the connections between the
AXCDR and the ABSS and the MMI command del_conn is used to delete connections between
the AXCDR and the ABSS.
Displaying the connectivity between AXCDR and ABSS
The MMI command disp_conn is used to display the connections between the AXCDR and
the ABSS.
68P02901W36-S 2-31
Jul 2008
CELL Chapter 2: BSS Devices and Functions
CELL

Cell specification
Cells are added by use of the add_cell MMI command, although they can be specified using
the OMC-R navigation tree. Cells are specified by a cell identifier in many commands and
parameters. Details of these are contained in the Technical Description: BSS Command
Reference (68P02901W23) manual.
2-32 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Digital Radio Interface (DRI)
Digital Radio Interface (DRI)

Digital Radio Interfaces (DRIs) can be equipped at BSC or BTS sites.
NOTE
The acronym DRI in some command syntax specifies other radio interfaces such as
for TCU, TCU-B and SCU.
There is no order dependency when equipping DRIs and RTFs. However, an equipped RTF
with no DRI assigned to it cannot carry traffic.
The DRI attribute tcu_port checks for the following configurations when equipping or modifying
a DRI device in a dual band Horizon II macro, Horizon II macro extension, Horizon II mini,
Horizon II mini extension, Horizon II micro and Horizon II micro extension cabinet:
All 900 MHz radios must be equipped in slots 0 to 2 or slots 3 to 5.
1800 MHz radios can be equipped in the slots not occupied by the 900 MHz radios.
DRI pairing
12 DRIs can be used within Horizon macro and Horizon II macro cabinets fully populated with
CTU2s in dual carrier mode. Four DRI devices can be equipped within a Horizon II mini and
Horizon II mini_ext cabinets. {26481} Two DRIs can be equipped within a Horizon II micro
and Horizon II micro_ext cabinets.
DRI pairing is utilized to support double density mode. In a DRI pairing, each CTU2 has a pair
of associated DRI devices, where both DRI devices are closely linked and their configuration
is kept synchronized by the BSS.
In double density mode, certain operations applied to one of the DRI devices in the DRI pair are
not required to be performed on the other. Because the CTU2 has a single Tx output, the device
identity for both DRIs must be from the same cell.
Dual band cells can have multiple zones, where each of the zones supports a different frequency
band and are managed as a separate DRI group. As the CTU2 can only support a single
frequency band, DRI devices from different zones cannot be equipped onto the same CTU2.
Concentric cells support multiple zones, but as they only support a single frequency band all of
the DRI devices are within the same DRI group. DRIs associated with the INNER and OUTER
cell are supported by DRIs in a DRI pair on a double density CTU2.
DRI and combiner relationship
The DRI-Combiner hierarchy follows a parent-child relationship and indirect control of each
combiner processor is provided by applying operational commands to the respective controlling
DRI. The DRI role in system combining is specified during the equip of the DRI.
68P02901W36-S 2-33
Jul 2008
Equipping and unequipping a DRI Chapter 2: BSS Devices and Functions
All display commands provide a complete set of combiner device information, including address
and cavity assignments.
Figure 2-11 DRI and combiner relationship
ti-GSM-DRI co mb ine r re la tions hip-00138-a i-sw
Equipping and unequipping a DRI
The following MMI commands are used to equip and unequip a DRI and are followed by the
equip (Specify a DRI in a network from the OMC-R Navigation Tree).
unequip (Delete a DRI from a network at the OMC-R Navigation Tree).
With the introduction of GPRS, all BTS configurations were changed to provide at least one
carrier unit capable of GPRS service, because there is a large volume of DRCU1 carriers in the
field that cannot carry GPRS data. In the event of a single GPRS carrier failure, it is essential to
be able to allocate another GPRS carrier. To provide this facility to operators, the parameter
pref_rtf_id is available with the modify_value command.
NOTE
Certain commands affect both carriers of a DRI within a DRI pair, for example,
reset_device will reset both DRIs in the pair (because it is a hard reset).
2-34 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Monitoring a DRI
Monitoring a DRI
The following MMI command is used to monitor a DRI and is followed by the equivalent OMC-R
facility:
DRI alarms
DRI alarms are described in full in Maintenance Information: Alarm Handling at the OMC-R
(68P02901W26) manual.
NOTE
Certain alarms affect both carriers of a DRI within a DRI pair.
68P02901W36-S 2-35
Jul 2008
Receive Transmit Functions (RTF) Chapter 2: BSS Devices and Functions
Receive Transmit Functions (RTF)

Equipping and unequipping an RTF
Receive Transmit Functions (RTFs) can be equipped only at BTS sites. There is no order
dependency when equipping DRIs and RTFs. However, an equipped RTF with no DRI assigned
to it, cannot carry traffic.
When the DRI mapped to 64k BCCH RTF becomes OOS, the CA preferentially reassigns a free
DRI or borrows a DRI of SD CTU2 preceded by DD CTU2 Carrier A. When the DRI mapped to
non-64k BCCH RTF becomes OOS, the CA preferentially reassigns a free DRI or borrows a DRI
of DD CTU2 Carrier A preceded by SD CTU2.
The following MMI commands are used to equip and unequip an RTF and are followed by the
The BSS allows an RTF to be configured as an EGPRS-capable RTF using the RTF parameter
pkt_radio_type and no longer uses the parameter allow_32k_trau. The allow_32K_trau
parameter is not supported and the operator is not allowed to modify or display this parameter.
It is not possible to sub equip 32 kbps or 64 kbps RTFs in an EGPRS system.
Parameter pkt_radio_type must be set to a non-zero value (using modify_value) if (E)GPRS

data transfer is required.
The 16 kbps LAPD RSL and RTF sub equipping functions are applicable to E1 links and to
BSU-based, M-Cell 6 and M-Cell and Horizon micro type BTS sites. Because the 64 kbps TSW
and KSW do not support subrate multiplexing, any BSU-BTS site must be equipped with a
KSW to support the 16 kbps LAPD function.
For a 64 kbps RTF to provide EGPRS service, a single density CTU2 must be available.
Double density carrier support
For CTU2s in double density mode, there is still a one to one relationship between the DRI and
RTF and the majority of the functionality related to the RTF is unchanged.
The BSS is, however, required to support a mixture of carrier capabilities on the CTU2 and the
RTF frequency can be changed after equipage. Frequency alteration (using chg_rtf_freq) of an
in-service RTF is performed by changing the state of the supporting DRI. This change does not
affect the other DRI in the DRI pair.
The CA preferentially maps an 64K RTFs onto SD CTU2 followed by DD CTU2 Carrier A. The CA
preferentially maps a non-64K BCCH RTFs onto DD CTU2 Carrier A followed by SD CTU2.
2-36 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation RTF mapping limitation on DD CTU2
RTF mapping limitation on DD CTU2
Table 2-1 depicts the RTFs DRI pair mapping on DD CTU2 to enable EPGRS support on DD
CTU2 Carrier A.
Table 2-1 RTF-DRI mapping on DD CTU2
RTF on Carrier A
64k BCCH Non 64k 64k Non-64k
BCCH non-BCCH non-BCCH
64k BCCH Not Not No No
applicable applicable
RTF on
Non-64k Not Not No Yes, existing
Carrier
BCCH applicable applicable configuration
B
64k No No No No
non-BCCH
Non-64k Yes, new Yes, existing Yes, new Yes, existing
non-BCCH requirement configuration requirement configuration
As SD CTU2 and DD CTU2 carrier A are the only radios with EGPRS capability, the 64K RTFs
should always be mapped to these DRIs with higher priority.
Equipping and unequipping an RTF with GSM Half-Rate
GSM Half-Rate is supported on sub-equipped RTFs where 8 kbps TRAU support is configured.
Fully equipped RTF
A single carrier BTS normally requires three E1 64 kbps timeslots; one for the 64 kbps RSL and
two for the 16 kbps traffic channels. The two 64 kbps timeslots dedicated to the traffic channels
can accommodate eight traffic channels. Figure 2-12 shows the layout of a fully equipped RTF.
68P02901W36-S 2-37
Jul 2008
Fully equipped RTF Chapter 2: BSS Devices and Functions
Figure 2-12 Fully equipped RTF
1 2 3 4
x x
In the case of a single carrier site, it is not possible to use all eight traffic channels of the
two 64 kbps timeslots. The reason is that, in the case of a single carrier site, the carrier will
be the BCCH carrier and the air interface timeslot zero of the BCCH carrier is reserved for
BCCH information. This information is generated at the BTS and not the BSC. The TSW at the
BTS routes the traffic channels from the two specified timeslots on the Abis interface to the
dedicated radio for transmission.
2-38 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Sub-equipped RTF
Sub-equipped RTF
A sub-equipped RTF uses only one 64 kbps timeslot on an E1 link. Figure 2-13 shows the layout
of a sub-equipped RTF using the 16 kbps RSL.
Figure 2-13 Sub-equipped RTF
With the introduction of the 16 kbps RSL it is possible to place the timeslot 0 BCCH information
on the unused sub channel because the RSL is not transmitting on the air interface. This then
frees one 64 kbps timeslot on the Abis interface and reduces the requirement to only two 64
kbps timeslots. This operates with M-Cell BTSs and In-Cell BTSs using KSW switching.
Equipped RTF configurations
Table 2-2 lists the types of RTF equipped as shown in Figure 2-12 and Figure 2-13.
68P02901W36-S 2-39
Jul 2008
LAPD protocol Chapter 2: BSS Devices and Functions
Table 2-2 RTF configurations
Number Configuration
1 Fully equipped BCCH RTF with an associated 16 kbps RSL.
2 Fully equipped BCCH RTF with no associated 16 kbps RSL.
3 Fully equipped non-BCCH RTF with an associated 16 kbps RSL.
4 Fully equipped non-BCCH RTF with no associated 16 kbps RSL.
5 Sub-equipped BCCH RTF with an associated 16 kbps RSL.
6 Sub-equipped BCCH RTF with no associated 16 kbps RSL.
7 Sub-equipped non-BCCH RTF with an associated 16 kbps RSL.
8 Sub-equipped non-BCCH RTF with no associated 16 kbps RSL.
The use of 16 kbps LAPD RSLs permits the implementation of more traffic channels or nailed
connections on a BTS daisy chain, since fewer timeslots are used for signaling. Increasing the
traffic channel capacity of each E1 link reduces the number of links required. The operator can
also reduce operating costs if links are leased on a per timeslot basis.
RTF sub equipping also reduces the number of timeslots required to support a site by permitting
the operator to configure an RTF so that it utilizes a single timeslot. Since the sub-equipped
RTF supports a maximum of four TCHs, this setting should only be used when the resulting
air interface TCH capacity supports the desired grade of service. The air interface timeslots
on a sub-equipped RTF that are not used as TCHs can be configured as BCCH or SDCCH
channels within the limits imposed by the configuration parameters and by the GSM Technical
Specifications.
It is possible to equip a non-redundant, sub-equipped BCCH and NON_BCCH RTF to a 64

kbps site.
The CA downgrades the unmatched DRI to only support 16k data if 64 kbps RTF is mapped to
other carriers except for SD CTU2 and DD CTU2 Carrier A. When non-64 kbps BCCH RTF is
assigned to DD CTU2 Carrier B but corresponding Carrier A has been already assigned to 64
kbps non-BCCH RTF, the CA downgrades Carrier A to support 16 kbps data only.
LAPD protocol
LAPD is the signaling protocol that is used to convey signaling and control information between
the BSC and the BTS over the RSL. Currently, each RSL is 64 kbps and occupies one timeslot
between the BSC and the BTS. However, the two timeslots used for traffic channels for the
BCCH RTF have 16 kbps of spare capacity since the RTF supports only seven traffic channels;
the eighth channel corresponds to the BCCH. The 16 kbps LAPD RSL function utilizes the 16
kbps of unused capacity for the RSL, thus reducing the number of timeslots required for the cell
by one. A 16 kbps LAPD RSL can also be implemented on a non-BCCH RTF by blocking an air
interface timeslot on the RTF from use as a TCH.
The 16 kbps LAPD RSL and RTF sub equipping settings can be utilized together to support three
TCHs and a 16 kbps LAPD RSL on a single TS.
Although the introduction of the 16 kbps LAPD RSL and RTF sub equipping could be used
to extend the maximum length of a daisy chain beyond 10 sites, a limit of 10 sites is being
maintained to limit both transmission and initialization delays and to avoid added complexity
in daisy chain maintenance and administration. However, the maximum number of sites on
a E1 daisy chain is extended from 8 to 10.
2-40 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Redundant RTF path deletion
The 16 kbps LAPD RSL and RTF sub equipping settings are applicable to E1 links and to
BSU-based, M-Cell 6 and M-Cell and Horizon micro type BTS sites. Because the TSW and KSW
to 64 kbps do not support subrate multiplexing, any BSU-BTS site that is to support the 16 kbps
LAPD function must be equipped with a KSW.
Redundant RTF path deletion
The following MMI command is used to delete a redundant RTF path and is followed by the
del_rtf_path - Deletes a redundant PATH device from an equipped RTF function in the
Configuration Management (CM) database.
NOTE
Attempts to modify paths used by RTFs at sites using dynamic allocation (DYNET
sites) are rejected. Paths for DYNET sites are defined in the equip DYNET command.
The BSS command database does not reuse carrier identification for the RTF. If a carrier ID
is deleted from the database, that database slot must remain unused for as long as the RTF is
equipped for the software load. For example, if the RTF is equipped with carrier ID 0, 1, 2, 3
and 4 and then 2 is unequipped, any subsequent RTF carriers cannot be equipped with carrier
ID 2 ID 5 to ID 9 should be used.
RTF monitoring
The following MMI command is used to monitor an RTF and is followed by the equivalent
OMC-R facility:
disp_equipment-Displays software and hardware information.
Deleting the RTF PATH removes the RSL and PATH identification from the disp_equipment
command output.
disp_mms_ts_usage-Can be used to ensure that the RTF is equipped on one or more MMS
timeslots, or the RTF is multiplexed to the RSL timeslot.
RTF alarms
RTF alarms are described in full in Maintenance Information: Alarm Handling at the OMC-R
(68P02901W26) manual.
The BSS is able to support a Non-BCCH RTF on each DRI on a CTU2 in DD mode within
a Horizon macro cabinet.
68P02901W36-S 2-41
Jul 2008
The BSS is able to support a Non-BCCH RTF and BCCH RTF on DRI devices on a CTU2 in
DD mode within a Horizon macro cabinet.
The BSS is able to support a Non-BCCH RTF on each DRI on a CTU2 in DD mode within a
Horizon II macro cabinet.
DD mode within a Horizon II macro cabinet.
Horizon II micro cabinet.
DD mode within a Horizon II micro cabinet.
Horizon II micro cabinet.
The BSS is able to support a Non-BCCH RTF and BCCH RTF on DRI devices on a CTU2 in DD
mode within a Horizon II micro extension cabinet.
AMR half-rate carrier configuration
7.95 kbps HR codec mode is too high a data rate to be carried in 8 kbps TRAU format. For 7.95
capable carriers, AMR HR channel mode speech frames in that cell must still be carried in 16
kbps TRAU format between the CCU and the relevant enhanced GDP pair DSP or GDP2 DSP.
This means that such RTFs cannot have allow 8 kbps TRAU set. Extra backhaul will still need
to be provisioned when the per RTF flag allow 8 kbps TRAU is not set.
There are two situations where extra backhaul is needed:

7.95 kbps HR AMR
C3/C4 GPRS
So that including 7.95 kbps in the HR ACS for a cell that has CS3/4 and AMR HR capable
carriers means that extra backhaul is already allocated.
The speech frames travel between the CCU and the relevant enhanced GDP pair DSP or GDP2
DSP for HR calls on HR capable RTFs that have allowed 8 kbps TRAU set.
The allocated Ater resource for a call can be an 8 kbps or a 16 kbps channel. If a 16 kbps Ater is
allocated the non TRAU half of the Ater is padded with the 8 kbps idle pattern.
Sub-equipped carriers are used to reduce backhaul capacity requirements in areas with spare
air interface capacity. An AMR HR sub-equipped carrier provides additional air interface,
except if 8 kbps TRAU is not allowed.
2-42 68P02901W36-S
Jul 2008
An AMR HR carrier supports up to 16 AMR HR channels, each requiring an 8 kbps E1 timeslot

group or a 16 kbps E1 timeslot group to route TRAU data from the BTS to the BSC. An AMR
HR RTF will thus require:
16x8 kbps E1 bandwidth, that is two associated 64 kbps E1 timeslots if 8 kbps TRAU
is allowed, or
16x16 kbps E1 bandwidth, that is four associated 64 kbps E1 timeslots if 8 kbps TRAU
is not allowed.
Each of the AMR HR RTFs air interface traffic timeslots are to support either one Full-Rate
(FR), Enhanced FR (EFR) or AMR FR channel or up to two AMR HR channels.
The BSS provisions two 64 kbps E1 timeslots for an AMR HR enabled RTF with 8 kbps TRAU
allowed. The BSS provisions four 64 kbps E1 timeslots for an AMR HR enabled RTF if 8 kbps
TRAU is not allowed. The BSS provisions four 64 kbps E1 timeslots for GPRS CS3/4 capable
RTF regardless of whether or not the carrier is AMR HR capable.
The BSS can configure each air interface timeslot of an AMR HR RTF for either one FR channel
or up to two AMR HR channels.
AMR and GSM Half-Rate carrier configuration
7.95 kbps HR codec mode is too high a data rate to be carried in 8 kbps TRAU format. For 7.95
capable carriers, AMR HR channel mode speech frames in that cell must still be carried in 16
kbps TRAU format between the CCU and the relevant enhanced GDP pair DSP or GDP2 DSP.
This means that such RTFs cannot have allow 8 kbps TRAU set. Extra backhaul will still need
to be provisioned when the per RTF flag allow 8 kbps TRAU is not set.
There are two situations where extra backhaul is needed:
7.95 kbps HR AMR
C3/C4 GPRS
So that including 7.95 kbps in the HR ACS for a cell that has CS3/4 and AMR HR capable
carriers means that extra backhaul is already allocated.
The speech frames travel between the CCU and the relevant enhanced GDP pair DSP or GDP2
DSP for HR calls (both AMR and GPRS-HR) on HR capable RTFs that have allowed 8 kbps
TRAU set in 8 kbps TRAU format.
The allocated Ater resource for a call can be an 8 kbps or a 16 kbps channel. If a 16 kbps Ater is
allocated the non TRAU half of the Ater is padded with the 8 kbps idle pattern.
Sub-equipped carriers are used to reduce backhaul capacity requirements in areas with spare
air interface capacity. An AMR or GSM HR sub-equipped carrier provides additional air interface
capacity, except if 8 kbps TRAU is not allowed.
An AMR or GSM HR carrier supports up to 16 HR channels, each requiring an 8 kbps E1

timeslot group or a 16 kbps E1 timeslot group to route TRAU data from the BTS to the BSC.
An HR RTF will thus require one of the following bandwidths:
16x8 kbps E1 bandwidth, that is two associated 64 kbps E1 timeslots if 8 kbps TRAU is
allowed.
16x16 kbps E1 bandwidth, that is four associated 64 kbps E1 timeslots if 8 kbps TRAU
is not allowed.
68P02901W36-S 2-43
Jul 2008
Each of the HR RTFs air interface traffic timeslots are to support either one Full-Rate (FR),
Enhanced FR (EFR) or AMR FR channel or up to two AMR or GSM HR channels.
The BSS provisions two 64 kbps E1 timeslots for an HR enabled RTF with 8 kbps TRAU allowed.
The BSS provisions four 64 kbps E1 timeslots for an HR enabled RTF if 8 kbps TRAU is not
allowed. The BSS provisions four 64 kbps E1 timeslots for GPRS CS3/4 capable RTF regardless
of whether or not the carrier is AMR or GSM HR capable.
The BSS can configure each air interface timeslot of an HR RTF for either one FR channel or up
to two AMR or GSM HR channels.
AMR half-rate capable, GPRS CS3/4 capable carrier 8 kbps BSC-BTS

backhaul mappings
For a carrier where 8 kbps TRAU is allowed at the same time as GPRS CS3/4 is allowed the
mapping scheme is based on that employed in AMR, but is slightly different when AMR HR
connections are required. This solution uses 8 kbps TRAU on the Abis interface. This mapping
is illustrated in Table 2-3.
Table 2-3 CCU TRAU timeslot group to air interface timeslot sub channel mapping
(CS3/4 allowed, 8 kbps TRAU allowed)
Timeslot Group 8 kbps backhaul AMR HR RTF

TCH0 0 FR Timeslot 0 AMR HR ts 0 sub channel 0
AMR HR ts 0 sub channel 1
1 FR Timeslot 1 AMR HR ts 1 sub channel 0
1 FR Timeslot 5 AMR HR ts 5 sub-channel 0
TCH2 0-3 Unused by AMR, but used for GPRS CS3/CS4
TCH3 0-3 Unused by AMR, but used for GPRS CS3/CS4
2-44 68P02901W36-S
Jul 2008
AMR and GSM Half-Rate capable, GPRS CS3/4 capable carrier 8 kbps
BSC-BTS backhaul mappings
For a carrier where 8 kbps TRAU is allowed at the same time as GPRS CS3/4 is allowed the
mapping scheme is based on that employed in AMR, but is slightly different when AMR or GSM
HR connections are required. This solution uses 8 kbps TRAU on the Abis interface. This
mapping is illustrated in Table 2-4.
(CS3/4 allowed, 8 kbps TRAU allowed)

TCH0 0 FR Timeslot HR ts 0 sub channel 0
0
HR ts 0 sub channel 1
1 FR Timeslot HR ts 1 sub channel 0
1
2
3
TCH1 0 FR Timeslot HR ts 4 sub channel 0
4
5
6
7
TCH2 0-3 Unused by HR, but used for GPRS CS3/CS4
TCH3 0-3 Unused by HR, but used for GPRS CS3/CS4
AMR HR capable carrier 8 kbps BSC-BTS backhaul mappings
For an AMR HR carrier when 8 kbps TRAU is allowed, the mapping of TCH0 and TCH1 groups
to air interface timeslots will be the same as the mapping currently employed for non-AMR HR
carriers (not including GPRS CS3/4 or sub-equipped carriers). This is the mapping scheme
utilized in order to take advantage of the Abis backhaul savings gained by using 8 kbps
switching.
TCH0 and TCH1 groups will either map to an FR channel on the relevant air interface timeslot,
or an AMR HR channel on sub channel 0 or sub channel 1 of that timeslot. This mapping
68P02901W36-S 2-45
Jul 2008
(8 kbps TRAU allowed)

AMR and GSM HR capable carrier 8 kbps BSC-BTS backhaul mappings
For an HR carrier when 8 kbps TRAU is allowed, the mapping of TCH0 and TCH1 groups to air
interface timeslots will be the same as the mapping currently employed for non-HR carriers (not
including GPRS CS3/4 or sub-equipped carriers). This is the mapping scheme utilized in order
to take advantage of the Abis backhaul savings gained by using 8 kbps switching.
TCH0 and TCH1 groups will either map to an FR channel on the relevant air interface timeslot,
or an HR channel on sub channel 0 or sub channel 1 of that timeslot. This mapping is illustrated
in Table 2-6.
2-46 68P02901W36-S
Jul 2008
(8 kbps TRAU allowed)
Timeslot Group 8 kbps backhaul AMR and GSM HR RTF

TCH0 0 FR Timeslot 0 HR ts 0 sub channel 0
1 FR Timeslot 1 HR ts 1sub channel 0
2 FR Timeslot 2 HR ts 2 sub channel 0
3 FR Timeslot 3 HR ts 3sub channel 0
AMR HR capable sub-equipped carrier backhaul mappings
For a sub-equipped AMR HR carrier when 8 kbps TRAU is allowed, TCH1 groups will either
map to an FR channel on the relevant air interface timeslot. Alternatively, carriers will map
to an AMR HR channel on sub channel 0 or sub channel 1 of that timeslot. This mapping
(8 kbps TRAU allowed, sub-equipped)
Timeslot Group Sub-equipped AMR HR RTF

68P02901W36-S 2-47
Jul 2008
EGPRS RTF functions Chapter 2: BSS Devices and Functions
The BSS ensures that the relevant RTF timeslot group is switch connected to the appropriate
CIC at the BSC at call setup time.
The BSC makes this switch connection based upon the CIC selected for the call, the RCI selected
for the call and the mapping given in Table 2-5 and Table 2-8. If the RCI selected for a call is part
of an RTF that has 8 kbps TRAU not allowed, the appropriate switch connection will be made.
AMR and GSM HR capable sub-equipped carrier backhaul mappings
For a sub-equipped HR carrier when 8 kbps TRAU is allowed, TCH1 groups will either map to an
FR channel on the relevant air interface timeslot. Alternatively, carriers will map to an AMR
HR channel on sub channel 0 or sub channel 1 of that timeslot. This mapping is illustrated in
Table 2-8.
(8 kbps TRAU allowed, sub-equipped)
Timeslot Group Sub-equipped AMR and GSM HR RTF

The BSS ensures that the relevant RTF timeslot group is switch connected to the appropriate
CIC at the BSC at call setup time.
The BSC makes this switch connection based upon the CIC selected for the call, the RCI selected
for the call. If the RCI selected for a call is part of an RTF that has 8 kbps TRAU not allowed,
then the appropriate switch connection will be made.
EGPRS RTF functions
For EGPRS, the BSS implements the following conditions:

The BSS allows the operator to specify the terrestrial resource capacity of an RTF; the
mutually exclusive options are GSM voice only, 16 kbps, 32 kbps or 64 kbps.
For a 64 kbps RTF to provide EGPRS service, a single density CTU2 must be available.
The BSS will reject the equipage of an RTF if the number of terrestrial timeslots required
by the RTF between the BSC and the BTS exceeds the number of free terrestrial timeslots
between the BSC and the BTS.
The allow_32K_trau parameter is no longer supported and the BSS allows an RTF to be
configured as an EGPRS-capable RTF using the RTF parameter pkt_radio_type.
2-48 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation EGPRS RTF functions
The pkt_radio_type parameter is not prompted for during the equipage of an inner zone
RTF.
{26481} The BSS does not allow the equipage of an RTF that supports 64 kbps terrestrial
timeslots at a site that does not contain any Horizon macro, Horizon macro extension,
Horizon II mini, Horizon II mini extension, Horizon II macro, Horizon II macro extension,
Horizon II micro or Horizon II micro extension cabinets.
The BSS allows EGPRS RTFs and GPRS RTFs to be equipped in the same cell.
The BSS prevents the equipage of an RTF with Packet Radio Capability set to 64 k and a
hopping system which is shared with any other RTF that is not a 64 k RTF outside of sysgen.
The BSS configures 64 kbps terrestrial resources for seven air timeslots from the BTS to
the BSC when 64 kbps TRAU is enabled on a BCCH RTF.
The BSS does not allow equipage of EGPRS RTFs with associated RSLs.
The BSS does not allow equipage of sub-equipped EGPRS RTFs.
The BSS implements changes to the pkt_radio_type parameter using modify_val in the
RTF. Changing this parameter will result in the RTF going out and back into service.
If an RTF equipped with 64 kbps backhaul is mapped to a DRI unable to support EGPRS,
the carrier will be configured to support GSM voice only. A new interface is being added
between the BTS CA and the BSC SM to communicate the TRAU format being used by
a carrier. The existing interface between BTS CA and BTS SM for connecting RCI to
TRAU timeslots will be updated to include the TRAU format for each RCI. FM-CA is the
controller for the TRAU format interface.
Table 2-9 Attribute Values
Parameter Min Max Value Definition

pkt_radio_type 0, none 3, 64 k 0 = None
1 = 16 k
2 = 32 k
3 = 64 k This value can be set to 3 only
if there is at least one Horizon macro
or Horizon II macro cabinet equipped
at the site.
allow_32k_trau N/A N/A This parameter will no longer be used.
Dependencies
The pkt_radio_type parameter replaces the allow_32k_trau parameter and the

use_bcch_for_gprs parameter with enhanced functionality.
68P02901W36-S 2-49
Jul 2008
EGPRS terrestrial timeslot allocation with 64 kbps TRAU enabled Chapter 2: BSS Devices and Functions
EGPRS terrestrial timeslot allocation with 64 kbps

TRAU enabled

When 64 kbps TRAU is enabled on a non-BCCH RTF, the BSS configures 64 kbps terrestrial
resources for all eight air timeslots from the BTS to the BSC but when 64 kbps TRAU is enabled
on a BCCH RTF, the BSS configures only seven air timeslots from the BTS to the BSC.
All other 64 k RTF types will have backhaul allocated for all 8 air timeslots.
TRAU format
Three TRAU formats are possible with the introduction of the 64 kbps backhaul. The 16 kbps
and 32 kbps formats are legacy formats. The 64 kbps TRAU format is introduced with the
EGPRS feature. All three formats are allocated on a single E1 span, the BSS does not allow a
carrier to split the TRAU frame over multiple E1 spans.
Radio carriers send voice and data to the RXCDR and PCU in TRAU frames. The TRAU frames
include data and signaling information used for synchronizing the air timeslots to the RXCDR or
PCU. Terrestrial backhaul is allocated for each air timeslot based on the packet data rate and
AMR half-rate capability. The following tables show how the backhaul allocated for each air
timeslot are laid out on the E1 DS0 timeslots. The text that follows describes how the backhaul
are used for voice, half-rate voice and data.
The rows in the tables represent the DS0s on the E1 terrestrial backhaul. A DS0 is a timeslot on
an E1 span that supports 64 kbps data bandwidth. Each DS0 is represented with eight bits. The
columns in the tables represent the 8 bits that make up a DS0 timeslot.
The assignment of DS0 bits to air timeslots are represented by the letters A-H with a subscript.
The letters A-H correspond to the eight air timeslots on a carrier. The subscript is the bit number
for the particular air timeslot. For example, in the 16 kbps table, A0 is the first bit allocated on
the backhaul for air timeslot A and A1 is the second bit allocated on the backhaul for air timeslot
A. A DS0 supports 64 kbps bandwidth, so a single bit of a DS0 supports 8 kbps of bandwidth.
16 kbps TRAU format
The 16 kbps TRAU format is the original format designed to support eight 16 kbps circuit
switched voice timeslots. Each air timeslot is allocated two bits for 16 K bandwidth per air
timeslot. For example, air timeslot B would be assigned bits B0 and B1.
GPRS uses the two bits assigned to the air timeslot as a 16 kbps packet data channel. For
example, air timeslot B would be assigned bits B0 and B1. AMR half-rate, with 8 kbps allowed,
packs two 8 kbps voice channels into one air timeslot. The first bit assigned to the air timeslot
is used for the first half-rate voice channel and the second bit is used for the second half-rate
voice channel. For example, the first half-rate on air timeslot B is assigned B0 and the second
half-rate is assigned B1.
2-50 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation TRAU format
Table 2-10 16 kbps TRAU format
DS0 DS0 DS0 DS0 DS0 DS0 DS0 DS0

Bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7
DS0 0 A0 A1 B0 B1 C0 C1 D0 D1
DS0 1 E0 E1 F0 F1 G0 G1 H0 H1
32 kbps TRAU format
The 32 kbps TRAU format was introduced with the GPRS CS3/4 feature and is also used for
half-rate voice when 8 kbps switching is not allowed. Each air timeslot is allocated two 16 kbps
groups. The group layout is dictated by the legacy DRI hardware and cannot be changed.
For full-rate voice, the first two bits are used and the second two bits are idled. For example, air
timeslot B is assigned bits B0 and B1. Bits B2 and B3 are idle.
AMR and GSM Half-Rate with no 8 kbps switching spreads the two half-rate voice channels over
the two 16 kbps groups allocated for the air timeslot. The first half-rate voice channel is in the
first 16 kbps group with bits 0 and 1 allocated for the voice channel. The second half-rate voice
channel is in the second 16 kbps group with bits 2 and 3 allocated for the voice channel. For
example, air timeslot B has the first half-rate channel assigned to B0 and the second half-rate
channel assigned to B3. Bits B1 and B3 are idle.
AMR and GSM Half-Rate with 8 kbps switching packs the two half-rate voice channels into the
first 16 kbps group allocated for the air timeslot. The first half-rate voice channel is allocated bit
0 and the second half-rate voice channel is allocated bit 1. The second 16 kbps group is idle. For
example, air timeslot B has the first half-rate channel assigned to B0 and the second half-rate
channel assigned to B1. Bits B2 and B3 are idle.
GPRS uses both 16 kbps groups to form a 32 kbps packet data channel. Since the two 16 kbps
groups are on different DS0s they can have different delay characteristics due to timeslot
switching equipment used by the customer in the backhaul network. The PCU must synchronize
both 16 kbps groups independently. The CS3/4 feature terms these as the left and right channels
for an air timeslot. For example, air timeslot B uses bits B0, B1, B2 and B3.

DS0 0 A0 A1 B0 B1 C0 C1 D0 D1
DS0 1 E0 E1 F0 F1 G0 G1 H0 H1
DS0 2 A2 A3 B2 B3 C2 C3 D2 D3
DS0 3 E2 E3 F2 F3 G2 G3 H2 H3
68P02901W36-S 2-51
Jul 2008
TRAU format Chapter 2: BSS Devices and Functions
64 kbps TRAU format
The 64 kbps TRAU format introduced with the EGPRS feature is not compatible with all radio
types. For full-rate voice, the first two bits are used and the last 6 bits are idle. For example,
voice on air timeslot B would be assigned bits B0 and B1. Bits B2 to B7 are idle.
AMR and GSM Half-Rate without 8 kbps switching spreads the two half-rate voice channels over
the first two 16 kbps groups allocated for the air timeslot. The first half-rate voice channel is
allocated bits 0 and 1. The second half-rate voice channel is allocated bits 2 and 3. For example,
air timeslot B has the first half-rate channel assigned to B0 and B1 and the second half-rate
channel assigned to B2 and B3. Bits B4, B5, B6 and B7 are idle.
AMR and GSM Half-Rate with 8 kbps switching assigns the two half-rate voice channels to the
first 16 kbps subrate channel. The first half-rate voice channel is allocated bit 0. The second
half-rate voice channel is allocated bit 1. For example, air timeslot B has the first half-rate
channel assigned to B0 and the second half-rate channel assigned to B1. Bits B4, B5, B6 and
B7 are idle.
EGPRS uses all four 16 kbps groups to form a 64 kbps packet data channel. For each air
timeslot, all four 16 kbps groups are required to be in the same DS0 on the backhaul. Assuming
the customer does not implement subrate switching on their backhaul network, placing the
16 kbps groups in the same DS0 ensures they have the same delay characteristics. The PCU can
synchronize the 64 K data channel based on sync bits in the first 16 K group. For example, air
timeslot B uses bits B0, B1, B2, B3, B4, B5, B6 and B7.

DS0 0 A0 A1 A2 A3 A4 A5 A6 A7
DS0 1 B0 B1 B0 B1 B0 B1 B0 B1
DS0 2 C0 C1 C2 C3 C4 C5 C6 C7
DS0 3 D0 D1 D2 D3 D4 D5 D6 D7
DS0 4 E0 E1 E2 E3 E4 E5 E6 E7
DS0 5 F0 F1 F2 F3 F4 F5 F6 F7
DS0 6 G0 G1 G2 G3 G4 G5 G6 G7
DS0 7 H0 H1 H2 H3 H4 H5 H6 H7
2-52 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Kiloport or Double Kiloport switch and extension
Kiloport or Double Kiloport switch and extension

KSW functions
The KSW is a time division access digital switch whose primary function is to support a large
non-blocking switching fabric.
Each KSW is associated with a dedicated TDM highway, a 9-bit parallel bus (8 bit data plus 1
parity), which provides the means for voice and data routing within the BSS cabinets. The
TDM highway has fixed bandwidth of 65 Mbps partitioned into a 1024 timeslots each having a
cumulative bandwidth of 64 kbps.
All full size digital boards with the exception of GCLK, are allocated groups of timeslots for
transmitting and receiving data through the TDM highway. The number of timeslots allocated
is dependent upon the board type and database field values.
All data received from or transmitted on the E1 links will be routed through a BSS site on the
TDM highway. This will include the OML, RSL, C7 and TCH data.
68P02901W36-S 2-53
Jul 2008
KSWX Chapter 2: BSS Devices and Functions
The data layout of the KSW is shown in Figure 2-14.
Figure 2-14 Kiloport switch data layout
KSWX
As the TDM Highway function uses timeslot allocation, depending on the size of the site, one
TDM Highway can not be sufficient to support the digital boards or can not be sufficient to
support a number of cages. A KSW can be extended or expanded (both terms are used) by
a KSWX.
One KSW (one TDM Highway) can be extended to five digital cages, although extension does
not increase the TDM Highway capacity. It is simply the sharing of the available timeslots over
a number of digital cages.
In a large site, one TDM Highway can not be sufficient to meet the timeslot allocation
requirement of the digital boards. To overcome this, the TDM Highway can be expanded by
interconnecting up to four KSWs. This increases the number of timeslots from 1024 to 4096,
which is the maximum expansion configuration. When expanded, each KSW has access to any of
the input ports of interconnected KSWs but can only output to its own 1024 ports.
2-54 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation KSWX
Extension and expansion is achieved by the use of KSW Expander (KSWX) boards. An additional
KSW can be equipped for redundancy, giving four KSW pairs when maximum expansion is
implemented.
The TDM has to be modified to accept multiple KSWs in a system.
The redundant KSW supports new calls while enabling new standby TDMs. The KSW cannot
support new calls when enabling new active TDMs.
Figure 2-15 shows a KSWX configuration with extension or expansion for two KSWs.
Figure 2-15 Double KSWX extension or expansion configuration
R R R E L L L L L
R
K
S
W
1 2 3 4 5
R R R R E L L L L L
K
S
W
6 6 6 6 6
68P02901W36-S 2-55
Jul 2008
Equipping and unequipping a KSW Chapter 2: BSS Devices and Functions
Equipping and unequipping a KSW
The following MMI commands are used to equip and unequip a KSW and are followed by the
equip KSW (Specify a KSW in a network from the OMC-R Navigation Tree).
equip CAGE (Specify a CAGE in a network from the OMC-R Navigation Tree): equips the
system with a new KSW.
unequip KSW (Delete a KSW from a network at the OMC-R Navigation Tree).
KSW monitoring
The following MMI command is used to monitor a KSW and is followed by the equivalent
OMC-R facility:
disp_equipment - Displays software and hardware information.
Locking and unlocking a KSW
The following MMI commands are used to lock and unlock a KSW and are followed by the
lock_device - Locks the KSW.
unlock_device - Unlocks the KSW.
Changing KSW TDM highway mapping
The following MMI command changes the mapping of the TDM highway to the specified KSWX
pair and is followed by the equivalent OMC-R facility:
chg_ksw_config - Indicates how KSWs are physically connected when two or more KSW pairs
are equipped at the site.
2-56 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation KSW alarms
KSW alarms
KSW alarms are described in full in Maintenance Information: Alarm Handling at the OMC-R
(68P02901W26) manual.
DSW or DSWX
The DSW or DSWX are replacements to the KSW or KSWX and are completely backwards
compatible with the KSW or KSWX. The DSW or DSWX can therefore be deployed into an
existing site without any configuration changes.
The DSWX board is an enhanced version of the KSWX board that allows expansion and extension
to other cages. The existing KSW device can be equipped and either KSW hardware or DSW
hardware can be deployed.
The DSW can be used as a replacement to the KSW and upgrades to DSW hardware will be
gradual so a mixture of KSW and DSW is supported to allow easy migration. A KSW board and
DSW board can co-exist within one cage, one acting as the slave and the other as primary
switch. This will allow the operator to change the slave KSWs that make up the redundant TDM
highway to DSWs, swap the primary and redundant highways allowing the DSW features and
then replacing the KSWs that make up the now redundant TDM highway. Mixing KSWXs and
DSWXs can occur in the same cage as the DSWX will be acting as a KSWX and will operate
in single rate mode.
The DSW is described in the next section of this document.
NOTE
Pairing a KSWX and DSWX together through fiber is not possible since the TDM fiber
data streams are incompatible.
Alarms
All existing KSW alarms are been supported by the DSW device.
KSW or DSW alarms are described in full in Maintenance Information: Alarm Handling at
the OMC-R (68P02901W26) manual.
68P02901W36-S 2-57
Jul 2008
Double Kiloport Switch (DSW) Chapter 2: BSS Devices and Functions
Double Kiloport Switch (DSW)

DSW operational requirements
The DSW is an enhanced version of the Kiloport Switch (KSW) that supports double the number
of ports (2048) as well as extended subrate switching capability down to 1-bit (8 kbps). DSW
and GDP2 boards are needed to support the AMR Half-Rate (HR) feature (8 kbps switching)
and ease the slot capacity impact due to pairing GDP boards.
The TDM highway can be extended to other cages, one switch controlling a TDM highway
shared between multiple cages. The highway can also be expanded to other cages with a set of
parallel switches each controlling a TDM highway portion. The DSWX board is an enhanced
version of the KSWX board that allows expansion and extension to other cages.
The DSW can be deployed into an existing site without any configuration changes. It is not
necessary to specify the difference between a KSW and the DSW device. The existing KSW
device can be equipped and either KSW hardware or DSW hardware can be deployed. The DSW
is a replacement to and is completely backwards compatible with the KSW.
A KSW board and DSW board can co-exist within one cage, one acting as the slave and the other
as primary switch. This allows the slave KSWs that make up the redundant TDM highway to be
changed to DSWs. Then, the primary and redundant highways can be swapped, allowing the
DSW features and replacing the KSWs that make up the now redundant TDM highway.
Mixing KSWXs and DSWXs can occur in the same cage as the DSWX will be acting as a KSWX
and will operate in single rate mode. Pairing a KSWX and DSWX together through fiber is not
possible since the TDM fiber data streams are incompatible. Outside sysgen mode, the BSS
detects the board type of switching hardware to determine whether a board is a KSW or DSW.
The BSS labels a disabled KSW device by setting its state to disabled-unlocked-DSW required.
DSW double rate 2048 timeslot capability
The 2048 timeslot provided by the DSW2/DSWX are distributed between 2 banks:
Bank 0: timeslots 0-1023
Bank 1: timeslots 1024-2047
The DSWX supports three different implementations of the 2048 timeslot ability:
Standard rate - DSWX provides standard capacity extension of a DSW or KSW to a standard
rate non-switch cage. Mixing DSWX and KSWX can occur as the DSWX will be functioning
as if it were a KSWX. Pairing a KSWX and DSWX together is not possible as the TDM fiber
data streams are incompatible.
Bank 0/1 extension - The DSWX provides extension of a DSW to a standard rate non-switch
cage. Mixing DSWXs and KSWXs is not permitted.
Double rate - The DSWX provides double capacity extension of a DSW to a double rate or
mixed rate non-switch cage. Mixing DSWXs and KSWXs not permitted.
2-58 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation DSW double rate 2048 timeslot capability
The BSS supports the DSW(X) mode of operation called Bank 1 extension. This involves the
parent switch cage only being able to see bank 0 timeslots and child non-switch cages being
able to see bank 1 timeslots. The bank of timeslots that is allocated for a cage is filtered by the
remote DSWX board within the switch cage in the path to that extension cage.
Full double rate mode of operation is not supported because there are currently no TDM
peripheral cards other than the GDP2 that are able to interface with the double rate timeslot
pattern on the TDM bus. Future system enhancements will change the TDM timeslot numbering
to allow for the extra TDM timeslots provided by the DSW board.
Bank 0 is now used to refer to the only timeslots available within a KSW. In a four cage, TDM
expansion configuration is shown in Table 2-13 and Table 2-14.
Table 2-13 Cage and TDM timeslot bank allocations for a double rate expanded
RXCDR
Highway
TDM timeslot range Switch cage Bank
number
0 to 1023 0 0 0
1024 to 2047 0 1 0
2048 to 3071 1 0 1
3072 to 4095 1 1 1
4096 to 5119 2 0 2
5120 to 6143 2 1 2
6144 to 7167 3 0 3
7168 to 8191 3 1 3
{22168}
Table 2-14 Cage and TDM timeslot bank allocations for an expanded BSC
Highway
TDM timeslot range Switch cage Bank
number
0 to 1023 0 0 0
1024 to 2047 0 1 0
2048 to 3071 1 0 1
3072 to 4095 1 1 1
4096 to 5119 2 0 2
5120 to 6143 2 1 2
6144 to 7167 3 0 3
7168 to 8191 3 1 3
The highway numbering for the TDM timeslot is dependent on the cage, an extension cage can
only see the timeslots provided by the parent cage. The mapping transformation function is
carried out by the remote DSWX board for the child cage within the parent switch cage. The BSS
supports DSW/DSW2 boards in enhanced capacity mode. Backwards-compatibility is provided
in single rate mode, where only bank 0 is available throughout RXCDR and BSC configuration.
68P02901W36-S 2-59
Jul 2008
DSW double rate 2048 timeslot capability Chapter 2: BSS Devices and Functions
Site upgrade
Enhanced capacity mode is available automatically when DSW/DSW2 and DSWX boards are
detected during site initialization. DSW/DSW2 boards are configured for enhanced capacity
mode (use of 2048 timeslots) outside sysgen mode using the reset_device TDM MMI command.
Enhanced capacity mode cannot be implemented outside sysgen if DSW redundancy is not
implemented.
KSW and KSWX boards can be replaced with DSW/DSW2 and DSWX boards during a site
outage or sequentially, by swapping the TDM highways and resetting the DSW boards. If the
RXCDR or the BSC initializes in single rate mode and a gradual upgrade of all KSW and KSWX
boards to DSW and DSWX occurs, the reset_device TDM command is used to enable enhanced
capacity mode.
During site sysgen, timeslots for the second E1 for a GDP2 are allocated when sysgen is off.
These timeslots are given lowest priority and are available if a KSW or KSWX is used instead
of a DSW/DSW2 or DSWX.
If the 1024 TDM timeslot limitation of one bank is surpassed, a selective disabling criterion is
employed so that devices allocated in TDM timeslots in one bank, that clash with TDM timeslots
in the other bank, will be disabled. This method allows the RXCDR and the BSC to step up from
single rate to enhanced capacity mode easily and with minimal disruption.
Site expansion
If the BSS contains all DSW/DSW2 switches and DSWX extension boards, a switching capacity
of 2048 timeslots and 8 kbps switching can be achieved.
A local DSWX converts between the double rate (2048) from a remote DSW2/DSWX, and the
1024 timeslots used in a cage. The TDM highway switched by one DSW can be extended to one
more cage as shown in Figure 2-16.
Figure 2-16 Maximum DSW extension
Each parent switch cage holds a DSWX board, operating in expansion mode (EXP) to export
2048 timeslots to each of the other switch cages. A mirror TDM bus for redundancy can also be
connected. A minimum of six cages is required for supporting 4800 CICs.
2-60 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Generic Clock (GCLK)
Generic Clock (GCLK)

GCLK synchronization
The Generic Clock (GCLK) provides the frequency synchronization timing pulses using an
assigned E1 link as a reference source, in order to phase lock.
GCLKs are equipped on a site basis and their functionality can be extended to other cages
through clock extender boards. One GCLK must be equipped per site and two if redundancy
is to be implemented. This device can not be explicitly equipped at M-Cell or Horizon sites, it
is automatically equipped with the first BTP.
GCLK synchronization enables a site to lock its GCLK to a good clock source (the master). The
GCLK will only lock to the supplied clock if that clock is of suitable quality. Synchronization can
have a number of positive effects on system performance and system maintenance, but these
can be outweighed by negative effects if the master source is poor. This is why the GCLK is only
locked if the clock source is good.
The function of the GCLK is to provide RF carrier frequencies within +/- 50 ppb, as per the GSM
specifications. When this is achieved, adjacent base stations will not interfere with each other.
In a GSM network, synchronization can be used to ensure that the internal frequency source
at each base station site produces the correct output frequency. It is important that the radio
transmissions of a GSM base station are at the correct frequency for the following reasons:
To avoid interference with other base stations.
To avoid interference with other radio transmitting sources.
Ensure handovers between base stations.
Synchronization features
Minimized frame slips
If the clocks at both end of a link carrying framed data are synchronized, the data is transmitted
at the same rate as it is consumed by the receiving process.
In Figure 2-17, Config 1 shows a synchronized, directly connected clock, in which frame slips do
not occur. Unfortunately, E1 links are often multiplexed and their clocks retimed. This means
that the site will be trying to lock to the master clock for the multiplexed equipment and not the
clock used to transmit the data, as shown in Config 2.
68P02901W36-S 2-61
Jul 2008
Synchronization features Chapter 2: BSS Devices and Functions
Figure 2-17 Locking two sites showing clock synchronization
Automatic calibration
When the GCLK is locked, it is able to evaluate the difference between its calibrated value and
the clock it is locked too automatically. It can therefore update the calibrated value periodically
and so recalibrate the GCLK automatically.
NOTE
For InCell GCLKs, this does not remove the need for manual calibration completely,
but significantly reduces it.
Early detection of poor quality links
The GCLK will generate alarms if the standard of the supplied link is outside specification. This
helps operators identify poor links, which can cause performance problems.
More alarms generated due to synchronization failure
When the clock output from the GCLK follows any changes that occur in the master clock it
is less stable than if it were locked. The instability has no negative effect, unless it causes
the GCLK to stray outside 50 ppb of its stated frequency. When the GCLK drifts beyond this
threshold, it reports loss of lock. This will cause an alarm at the OMC-R.
Unstable clock while trying to lock
While the GCLK is establishing if the supplied reference is suitable to track the GCLK
clock can fall outside the 50 ppb limit. A GCLK clock outside 50 ppb accuracy can affect
system performance. This time period is controlled by the user definable parameter
lock_duration_period.
2-62 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation How GCLK synchronization works
How GCLK synchronization works
The GCLK must have an E1 link assigned as a reference source in order to phase-lock. Database
parameters are used to specify priorities for each link at a site. These priorities then determine
the order of selection of the E1 links as a reference source. The source is selected by the
MMS priority parameters.
An extracted clock is derived from digital transitions on the selected E1 reference source and
forwarded as one input to a phase detector. Here, it is compared with the output of an Oven
Controlled Crystal Oscillator (OCXO) as shown in Figure 2-18 and the resulting difference
produces a raw error value.
The phase detector compares the output from the OCXO with the extracted clock from the
selected E1 link and outputs a raw error value. This error value is filtered to remove high
frequency variation and the output is passed to a Phase Lock Loop (PLL). The PLL adjusts its
output to the DAC try to maintain the filtered error value at zero. This in turn maintains the
output of the OCXO close to the filtered clock to which it is locked or trying to lock.
The low pass filter removes high frequency noise and tracks low frequency noise. The DAC is
8-bit for the InCell GCLK and 24-bit for M-Cell or Horizon SYNC.
Figure 2-18 Block diagram of GCLK M-Cell or Horizon synchronization
The GCLK is considered phase locked while the output is held within the limits currently set
at +/- 50 ppb (GSM Specification worst case value). This is known as the lock threshold. This
means that if the GCLK or SYNC, which has been instructed to lock, cannot maintain its clock
within these limits, it will fail to lock and will report the GCLK Phase Lock Failed alarm.
The time period in which it has to gain lock is controlled by the Phase Lock Duration database
parameter. If the GCLK or SYNC is locked and for some reason is unable to keep the clock
within those limits, it will report the Phase Lock Lost alarm, it will retry to obtain a lock.
On a stable E1 link, the GCLK is able to produce accurate Long Term Average (LTA) timings and
therefore does not require periodic recalibration.
68P02901W36-S 2-63
Jul 2008
GCLK modes of operation Chapter 2: BSS Devices and Functions
GCLK modes of operation
A base station can either run in Set frequency mode or Phase lock mode.
Set frequency mode
In Set frequency mode the GCLK sets the DAC to a value established during the last calibration
or automatic calibration. The frequency that this generates is dependent on the accuracy of the
last calibration and the degree of crystal ageing. This mode is also known as free run mode.
The GCLK requires manual calibration to account for the effects of crystal ageing while the
GCLK is in Set frequency mode.
For M-Cell or Horizon SYNC, a worst case estimate of a crystal ageing of one ppb or week is
used. On this assumption, the M-Cell or Horizon SYNC will issue a Request for Calibration
(GCLK alarm 230) after one year. An internal counter in the M-Cell SYNC keeps track of when it
was last calibrated.
The InCell GCLK does not have this facility. It generates a Mate GCLK alarm if the two GCLKs
in an InCell cabinet differ beyond a certain threshold.
Phase lock mode
Phase lock mode is the GCLK mode used when the GCLK synchronization is enabled by the
operator for that site.
In this mode, the GCLK controls its output based on the clock extracted from the selected
reference. The GCLK moves through some the states described below, until it is either locked or
has failed to lock. The time the GCLK spends in each state is determined by the quality of the
selected reference, database parameter, and the version of the GCLK.
Fast tune state (M-Cell and Horizon only)
Transition to fast tune state occurs when output has not changed by more than the lock
threshold for period = 2x1/Cutoff Frequency. Typically, on a good link, the M-Cell or Horizon
SYNC will take 6 minutes to 8 minutes to transit to fast tune.
NOTE
Output frequency can vary by more than 50 ppb while in the fast tune state.
2-64 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Phase lock mode
When trying to synchronize to an external 2 Mbps, the M-Cell or Horizon SYNC will stay in fast
tune state for a maximum time of 10xPhase Lock Duration Period. Therefore, with the value set
to 255 (seconds) the maximum time to phase lock is 42.5 minutes.
If, for whatever reason, the M-Cell or Horizon SYNC cannot phase lock within 10 x Phase Lock
Duration Period, it will issue a Phase Lock Failed alarm.
Fine tune state (M-Cell and Horizon only)
When the output is stable and does not change by more than the lock threshold, the M-Cell or
Horizon SYNC enters the Fine Tune state.
The M-Cell or Horizon SYNC enters the Phase Locked state after a period = 1 x Phase Lock
Duration Period.
While in this state, the M-Cell SYNC will revert to the Fast Tune state if the output varies by
more than the phase lock threshold.
Phase locking (InCell only)
Transition to Phase Locked state occurs when the output is held within 50 ppb for a period
determined by (GCLK hardware version + phase lock duration period).
NOTE
Output frequency can vary by more than 50 ppb while in the phase locking state.
Transition to Phase Lock Failed occurs if the InCell GCLK has been unable to achieve lock within
a period which is dependent on the version of the GCLK hardware.
Phase locked (InCell GCLK and M-Cell or Horizon SYNC)
The output is stable and does not change by more than the lock threshold. This removes the
need for manual calibration as a set of LTA values is generated which enable the GCLK output to
remain stable.
If the 2 Mbps synchronize source goes out of specification (more than +/ 50 ppb) while the
GCLK is phase locked, the M-Cell SYNC will revert to fast tune state and the InCell GCLK will
revert to phase locking and will attempt to re synchronize.
If the MMS providing the clock source goes Disabled-Unlocked then the GCLK will issue a
Phase Lock Failed alarm and go into Set frequency mode.
NOTE
This can be created by instructing the site to put in service the MMS that is providing
the clock source. A warning is displayed stating that resetting the MMS will cause
the GCLK to drop into Set frequency mode.
68P02901W36-S 2-65
Jul 2008
Phase locking option Chapter 2: BSS Devices and Functions
Phase lock failed (InCell GCLK and M-Cell or Horizon SYNC)
The GCLK operates as if in Set Frequency mode while in Phase Lock Failed state.
If the operator issues a STATE GCLK command, the GCLK will be shown to be in Set Frequency
mode and providing a valid clock reference. However, if a disp_site <num> command (which
shows all site details) is entered, the GCLK will be marked as Phase Lock Failed, confirming
that the MMS was providing the clock source.
NOTE
If the GCLK becomes Phase Lock Failed state for any reason, MMI intervention is
necessary to force the GCLK to reattempt synchronization (that is, turn off phase
locking to the site and then turn it on again.
This mode maintains a specific clock frequency in the event that the 2 Mbps reference should fail.
Phase locking option
It is possible for the operator to specify phase locking of a GCLK. The chg_element
phase_lock_gclk command is used to enable or disable phase locking at a site.
Should the chosen E1 link subsequently go out-of-service, a GCLK reference fail alarm is
initiated. The chg_element wait_for_reselection timer controls the time the system waits
before selecting another E1 link for extraction. If the current E1 link returns to INS (IN Service)
before the timer expires, it will remain the clock extraction source.
To enable the GCLK to synchronize to an E1 link, a suitable source must exist. The priority for
source selection is:
MMS INS (IN Service).
Priority of MMS (database parameter).
Number of times the MMS has gone out-of-service in a given period.
If priority and MMS out-of-service are equal, the order of selection of sources is on a
rotation basis.
The priority of each MMS can be individually set using the modify_value mms_priority
command. A count of the number of times the MMS goes out-of-service is kept to
enable the prioritizing algorithm to function. A reset period set by the chg_element
clk_src_fail_reset_period command is used to delimit the time for which an out-of-service
count is held. At the end of each reset period the out-of-service count is reset to zero and the
count begins again.
After initialization of the site the GCLK attempts to synchronize to the chosen MMS. The time
taken for this synchronization varies depending on the hardware revision level of the board.
If the synchronization has been maintained for phase_lock_duration the CA declares the
GCLK as phase locked.
2-66 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Equipping and unequipping a GCLK
For InCell sites, the phase lock duration is the time set by the phase_lock_duration parameter
added to the time duration determined by the GCLK revision level. The default value for this
variable is 0, which indicates that there is no change from the minimum period defined for the
revision level of the GCLK. The variable can be set on an MMS basis to account for different
transmission media.
For M-Cell and Horizon sites, the phase_lock_duration parameter sets the duration explicitly.
The default for M-Cell or Horizon sites is 50 seconds.
Equipping and unequipping a GCLK
The following MMI commands are used to equip and unequip a GCLK and are followed by the
equip (Specify a GCLK in a network from the OMC-R Navigation Tree).
unequip (Delete a GCLK from a network at the OMC-R Navigation Tree).
The equip command for a GCLK prompts the following:

Unique identifier for the GCLK, the board identified as 0 must be fitted in slot 5 and
identifier 1 must be fitted in slot 3.
Cage in which the GCLK is fitted.
Three CLKX prompts are used to indicate whether GCLK extension is used at this site
and if so which CLKXs support it. This is important, as slots U5, U6 and U7 can support
either CLKX or KSWX boards and if the same slot is specified for two boards then the CM
must reject the equipage.
Monitoring a GCLK
The following MMI commands are used to monitor a GCLK and are followed by the equivalent
OMC-R facility:
disp_gclk_cal - Displays the contents of the clock frequency register when the GCLK is
in the phase-lock mode.
disp_gclk_avgs - Displays the long-term average values for a specific GCLK.
68P02901W36-S 2-67
Jul 2008
Changing characteristics of a GCLK Chapter 2: BSS Devices and Functions
Changing characteristics of a GCLK
The following MMI command is used to change the characteristics of a GCLK and is followed
by the equivalent facility:
gclk_cal_mode - Initiates calibration of the GCLK.
The following MMI commands are used to change GCLK characteristics using the chg_element
and modify_value commands and are followed by the equivalent OMC-R facility:
clk_src_fail_reset_period - Sets reset period for an out-of-service GCLK.
phase_lock_duration - Synchronize-Cells the MMS and GCLK.
mms_priority - Sets MMS priority.
lta_alarm_range - Specifies DAC value variance range.
GCLK alarms
GCLK alarms are described in full in Maintenance Information: Alarm Handling at the OMC-R
(68P02901W26) manual.
2-68 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Generic Processors (GPROC, GPROC2 and GPROC3)
Generic Processors (GPROC, GPROC2 and GPROC3)

GPROC functions
NOTE
The generic term GPROC is used where the same information applies to the GPROC,
GPROC2, GPROC3 and GPROC3-2 in this manual.
The GPROC, GPROC2, GPROC3 and GPROC3-2 processor boards are equipped within GSM
network elements to support several different functions: BSP, BTP, CSFP, DHP, LCF, OMF and
BTP. GPROCs are equipped in the BSS CM database before the function is equipped.
The GPROC primary processor is addressed by a CPU ID depending on the cage ID and slot
number where the board is installed.
CPU ID = (Cage ID + 1) | (Slot number + 1) represented as a hexadecimal number.
For example, a GPROC installed in cage 1, slot 22 has the CPU ID 0217 (hex).
GPROC3-2 boards have a secondary processor which specifically supports HDLC link
termination and the full MTL SS7 protocols. The CPU ID for the GPROC3-2 secondary processor
is defined as:
CPU ID = 4xyz (hex), where xyz is the last 3 digits of the primary processor CPU ID.
A GPROC3-2 deployed in slot 20 of cage 0 has the following CPU IDs:

Primary CPU ID = 0115h
Secondary CPU ID = 4115h
GPROC2/GPROC3 call capacity
The scalable BSC offers migration of the processing boards within the Motorola BSC to use
the GPROC2/GPROC3 board throughout. System advancements require the use of GPROC2
or GPROC3s. For maximum capacities of BSCs equipped with GPROC2/GPROC3s, refer to the
System Information: BSS Equipment Planning (68P02901W21) manual.
The number of calls in progress that can be supported by the GPROC2/GPROC3 located at the
BSC is increased from 400 to 800. Calls in progress include calls that are being set up, being
torn down, being handed over and that are active.
68P02901W36-S 2-69
Jul 2008
GPROC fast reset Chapter 2: BSS Devices and Functions
GPROC fast reset
The Fast Reset (Soft Reset) function enables a GPROC to come back into service quicker, when
recovering from a fatal Software Fault Management (SWFM). If the GPROC is functioning as
the master BSP/BTP then the fast reset function has the effect of bringing the site into service
sooner. This function reduces the outage time for the involved GPROC(s) and increases the
total availability of the site.
The fast reset function decreases the recovery time for a reset by having the GPROCs transition
software from RAM back to RAM during a reset, without going through the ROM process. The
differences between a RAM-RAM software transition versus a RAM-ROM software transition is
that the RAM-RAM procedure does not execute the functionality in ROM, as it is passed over.
During a RAM-RAM software transition, the GPROC that incurred the fatal SWFM is taken off
the LAN and all TDM connections for that GPROC are cleared. Then, instead of performing
a software transition to ROM, the GPROC comes back on the LAN in RAM and performs the
RAM initialization procedure.
The theory behind the fast reset function is that a process executing in RAM, which encounters
a bus fault or any other fatal SWFM event, does not need to go through the ROM transition
to restore the GPROC. By halting all processes on that GPROC and reinitializing it, the fault
generating condition should no longer exist. If the fatal SWFM condition still exists, an
escalation mechanism eventually transitions the GPROC software into ROM.
Equipping and unequipping a GPROC
The following MMI commands are used to equip and unequip a GPROC and are followed by the
equip (Specify a GPROC in a network from the OMC-R Navigation Tree).
unequip (Delete a GPROC from a network at the OMC-R Navigation Tree).
The equip command for a GPROC prompts the following:

Unique identifier for the GPROC.
Cage in which the GPROC is fitted.
The slot location of the GPROC board within the cage.
Changing GPROC specifications
The following database parameter can be used with the chg_element command to alter the slot
location of the GPROC board within the cage.
gproc_slots - Specifies the number of timeslots to be allocated to all GPROCs for the TDM
highway.
2-70 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Monitoring a GPROC
Monitoring a GPROC
The following MMI command is used to monitor a GPROC and is followed by the equivalent
OMC-R facility:
disp_processor - Displays the status of all processor boards at a specific site or all sites.
Equivalent facilities are provided at the OMC-R for performing these functions as described in
At InCell sites, this command also displays the related devices and functions associated with the
processors. The Off LAN value is displayed if a GPROC is not detected on the LAN in InCell sites.
GPROC alarms
GPROC alarms are described in full in Maintenance Information: Alarm Handling at the OMC-R
(68P02901W26).
GPROC function preemption
GPROC function preemption searches for a Busy-Unlocked (B-U) GPROC running a lower
priority function when a GPROC hosting a higher priority function goes out-of-service and there
are no Enabled-Unlocked (E-U) GPROCs to host the higher priority function. If such a GPROC
is found, the lower priority function will be preempted by the higher priority function. The
operator is able to configure the preemption algorithm using a database element.
The implementation of the dynamic allocation of RXCDR-BSC Circuits (DARBC) function

increases the memory and processor utilization of the GPROC performing the allocation of
Ater channels. To reduce the load on the master BSP, Ater channel allocation at a type 2 BSC
will be transferred from the BSP to the OMF. If the OMF goes out-of-service, calls cannot be
processed. XBLs also terminate on the OMF. If the XBLs go out-of-service, the circuits are
blocked and calls cannot be processed. Thus, the OMF will be the highest priority function and
of critical importance to the system.
Function priority
The BSS software uses the function type and function ID to determine the order in which
functions are brought into service. The ordering of function type is OMF first, LCF second, and
BTF third. Functions with lower IDs are brought into service before functions with higher
IDs. This priority scheme allows the operator to arrange functions in order of importance.
When a pool GPROC comes into service, it selects the Enabled-Equipped (E-E) function with
the highest priority.
For example, there are six functions defined for a particular site: OMF 0, LCF 0, LCF 1, LCF
2, LCF 3 and BTF 0. OMF 0 is the highest priority function and BTF 0 is the lowest priority
function. LCF 1 has higher priority than LCF 2 and LCF 3, but has lower priority than LCF
0. Figure 2-19 represents this configuration.
68P02901W36-S 2-71
Jul 2008
GPROC function preemption Chapter 2: BSS Devices and Functions
Figure 2-19 Function priority example
0 0 0
{28337} The HSP MTL feature gives HSP LCF (2MB MTL LCF) the highest LCF priority to
preempt the GPROC3-2 over the following GPROC functions:
DS0 MTL LCF
LMTL LCF
RSL LCF
CBL LCF
GSL LCF
If the GPROC to be preempted is the MCAP Controller, the GPROC cannot be preempted unless
the MCAP controller can be transferred to another GPROC.
NOTE
The OMF has higher priority over the HSP LCF.
GPROC OOS
When a GPROC goes out-of-service, the device pool is searched for an E-U GPROC. If an E-U
GPROC is found, the GPROC is enabled and implements the highest priority E-E function
available. Without function preemption, if there are no E-U GPROCs, the dropped function
remains out-of-service. At a type 2 BSC, call processing would stop if the dropped function
were the OMF.
GPROC function preemption solves the problem by ensuring that the highest priority function
is implemented by a pool GPROC, as shown in Figure 2-20. If an E-U GPROC is not available,
function preemption searches for a lower priority B-E function. If a lower priority function is
found, its host GPROC is reset. When the GPROC comes back into service, it will implement
the highest priority E-E function.
2-72 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GPROC function preemption
GPROC reset
If a busy GPROC is reset for preemption, it will transition from the Busy-Unlocked state with
No Reason to the Disabled-Unlocked state with reason Function preemption.The GPROC
will then transition to the Disabled-Unlocked state with No Reason and be brought back into
service. Figure 2-20 illustrates the function preemption algorithm.
Figure 2-20 Function preemption algorithm
68P02901W36-S 2-73
Jul 2008
GPROC function preemption Chapter 2: BSS Devices and Functions
Last active GPROC in cage
The last active GPROC in a cage is the Motorola Cellular Advanced Processor (MCAP) master
for that cage. Preempting a function on the last GPROC will reset the GPROC and cause the
parent cage to be disabled. Disabling a cage will result in a SITE reset.
The OMF can preempt a function on the last active GPROC in a cage. Since the SITE cannot
perform call processing without the OMF, resetting the SITE to get the OMF back into service is
reasonable. OMF preemption first searches for the lowest priority B-E function which is not
hosted by the last active GPROC in a cage. If no such function is found, OMF preemption then
searches for the lowest priority B-E function that is hosted by an active GPROC.
LCFs and BTFs will not preempt a function if it is hosted by the last active GPROC in a cage.
LCF and BTF preemption searches for the lowest priority B-E function which is not hosted by
the last active GPROC in a cage. If no such function is found, preemption is aborted.
Related parameter
The operator can set the database element pool_gproc_preemption to the chg_element
command to indicate the level of preemption. The settings are:
0: No preemption.
1: Function level preemption
If a function of lower priority is running on a GPROC, that function will be preempted. In

the case of a preempted LCF, the LCF with the highest function id will be preempted.
2: Intra function level preemption
If a function of lower priority is running on a GPROC, that function will be preempted. If a

GPROC running an LCF goes out-of-service and there is no lower priority function type
(for example BTF) running on a pool GPROC, the function tables will be searched for a
lower priority LCF to preempt.
Example of GPROC preemption
Suppose the functions at a BSC were distributed among pool GPROCs as depicted in Table 2-15.
Table 2-15 GPROC functions
GPROC Function
GPROC 0 OMF 0
GPROC 1 LCF 2
GPROC 2 LCF 0
GPROC 3 LCF 3
GPROC 4 OMF 0
GPROC 5 LCF 1
2-74 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GPROC3 dual boot functionality
Assume there are no available pool GPROCs.
If GPROC 0 goes out-of-service:

LCF 2 running on GPROC 1 would be preempted and would be reset.
OMF 0 would be hosted by GPROC 1 when the GPROC comes back into service.
Subsequently, if GPROC 5 goes out-of-service and the preemption level has been set to 1
(function level only), no preemption would take place.
However, if the preemption level has been set to 2 (intra function level):
LCF 3 running on GPROC 3 would be preempted and GPROC 3 would be reset.
LCF 1 would be hosted by GPROC 3 when the GPROC comes back into service.
GPROC3 dual boot functionality
The GPROC3 has dual boot functionality to provide additional protection in the event of
hardware, software, or flash failure. For example, it protects against:
Corruption in the flash memory.
Power failure during Flash.
Corrupt download from the OMC-R.
Two banks of Flash memory are held on the GPROC3 board, Normal, and Backup.
CSFP dual boot functionality
The software in the Normal and Backup banks of a GPROC3 used as a CSFP will always match.
NOTE
Following a CSFP swap, if the boot ROM changes it will flash to both banks and two
resets will occur.
In all other applications, it is not unusual for the software in the Normal and Backup banks to be
different and match only after being tested.
68P02901W36-S 2-75
Jul 2008
Base Site Processor (BSP) Chapter 2: BSS Devices and Functions
Base Site Processor (BSP)

BSP functions
The Base Site Processor (BSP) is the master processor at a BSC and also at an RXCDR. At a
small BSC, it can carry out all the processing required, but in larger BSSs, some software is
migrated to other types of processor.
Before these functions can be equipped, the actual GPROC that constitutes the BSP must
have been equipped.
The BSC validates that a GPROC3 or GPROC3-2 is equipped as the BSP. If a GPROC or GPROC2
is used, the BSC does not come into service and an alarm will be raised.
Equipping and unequipping a BSP
The following MMI commands are used to equip and unequip a BSP and are followed by the
equip (Specify a BSP in a network from the OMC-R Navigation Tree).
unequip (Delete a BSP from a network at the OMC-R Navigation Tree).
The equip command for a BSP prompts the following:

Unique identifier for the BSP. A maximum number of two can be equipped per site, one
being used as redundant.
Cage in which the BSP is fitted.
The slot location of the BSP GPROC board within the cage, (20 to 24 for a BSU cage, 25
or 26 for an RXU cage).
Monitoring a BSP GPROC
The following MMI command is used to monitor a BSP GPROC and is followed by the equivalent
OMC-R facility:
disp_processor - Command displays the status of all BSP processor boards at a specific site
or all sites.
At InCell sites, this command will also display the related devices and functions associated
with the processors.
2-76 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Base Transceiver Processor (BTP)
Base Transceiver Processor (BTP)

BTP functions
The Base Transceiver Processor (BTP) is the master processor at a BTS. At a small BTS, it
can carry out all the processing required, but in larger BSSs, some software is migrated to
other types of processor.
Before these functions can be equipped, the actual GPROC that constitutes the BTP must be
equipped.
A BSP is required to control the switch manager for the KSW but there is no RF functionality. A
BTF is therefore created.
NOTE
M-Cell and Horizon sites cannot be co-located.
Equipping and unequipping a BTP
The following MMI commands are used to equip and unequip a BTP and are followed by the
equip (Specify a BTP in a network from the OMC-R Navigation Tree).
unequip (Delete a BTP from a network at the OMC-R Navigation Tree).
The equip command for a BTP prompts the following:

Unique identifier for the BTP. A maximum number of two can be equipped per site, one
being used as redundant. In M-Cell BTSs, this is the digital frame in which the MCU is
being equipped. For M-Cell and Horizon BTSs, this must be 0.
Cage in which the BTP is fitted.
The slot location of the BTP GPROC board within the cage, (20 to 24 for cage 15, 20 for
cage 14). Not prompted for M-Cell or Horizon products.
Monitoring a BTP GPROC
The MMI command is used to monitor a BTP GPROC and is followed by the equivalent OMC-R
facility.
68P02901W36-S 2-77
Jul 2008
Monitoring a BTP GPROC Chapter 2: BSS Devices and Functions
disp_processor-Command displays the status of all BTP processor boards at a specific site
or all sites.
At InCell sites, this command also displays the related devices and functions associated with
the processors.
2-78 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BSP or BTP redundancy
BSP or BTP redundancy

Applications
The BSP or BTP redundancy rules allow the BSS software to take advantage of the redundant
BSP or BTP in case of any BSP or BTP failure (hard reset) resulting in an enhancement to
redundancy which, in turn, increases the robustness of the software.
GPROC specifications
For BSCs and InCell BTSs, there are three positions that a master GPROC can occupy. The BSP
or BTP are assigned to these slots in the following priority:
Slot 20 (0115) in CAGE0 (BSC)/CAGE15 (BTS), Slot 24 (0119) in CAGE0 (BSC)/CAGE15 (BTS)
and Slot 20 (0215) in CAGE1 (BSC)/CAGE14 (BTS).
0215 has the lowest priority to be chosen as the master BSP. ROM initialization process chooses
master BSP according to ON LAN GPROC's slot, and not according to the DB configuration.
If 0115 is configured as BSP and 0119 is configured as LCF in the DB, then the initialization
process chooses 0119 as master BSP. The CM can then change the configuration to 0115 as LCF,
0119 as BSP. CM swaps the devices only when the initialization process has not chosen the same
GPROC as Master with the configuration of DB.
For RXCDRs also, there are three positions that a master GPROC can occupy. The BSP or BTP
are assigned to these slots in the following priority:
Slot 25 in CAGE0, Slot 26 in CAGE0 and Slot 25 in CAGE1.
With the above prioritization, many failure conditions can be experienced when the BSP or BTP
fails and the system re-initializes on the same processor. If the reset does not clear the problem,
this leads to a BSC/RXCDR/BTS continuously resetting.
NOTE
If the boards in potential master slot are not configured in the database(DB), it
causes the site reset when that board is chosen as master BSP.
Do not place the boards where the DB does not reflect the deployment to avoid
constant reset.
68P02901W36-S 2-79
Jul 2008
Modified BSP or BTP Redundancy rules Chapter 2: BSS Devices and Functions
Modified BSP or BTP Redundancy rules
The enhancement ensures that at each hard reset, a new master is chosen according to the
rules listed below:
If there are two potential masters in CAGE0 (BSC or RXCDR) or CAGE15 (BTS), the new
master will be the one that was not the master last time.
If none of the boards in CAGE0 or CAGE15 has been a master, the default master will be
slot 20 (BSC or BTS) and slot 25 (RXCDR).
If there is only one potential master GPROC in CAGE0 (BSC or RXCDR) or CAGE15 (BTS),
this board will be chosen each time.
If there are no potential master GPROCs in CAGE0 (BSC or RXCDR) or CAGE15 (BTS) then
the potential master will be the GPROC in CAGE1 (BSC or RXCDR) or CAGE14 (BTS).
NOTE
Soft resets of the master GPROC are not affected by this new functionality.
CSFP interworking
If a potential master GPROC slot has a CSFP equipped then it cannot be chosen as the master
GPROC.
NOTE
Equipping a CSFP in a potential master GPROC slot limits BSP redundancy.
If a potential master slot has a GPROC configured as an LCF or OMF, and is chosen as the master
GPROC, the function will be automatically transferred to another GPROC (if it is available).
Requirements for a potential master slot
If CAGE1 (BSC or RXCDR) or CAGE14 (BTS) is an extended CAGE (KSW extension

configuration), the master GPROC in CAGE1 (BSC or RXCDR) or CAGE14 (BTS) is not supported.
If CAGE1 (BSC or RXCDR) or CAGE14 (BTS) is an expanded cage (KSW expansion

configuration), the master GPROC in CAGE1 (BSC or RXCDR) or CAGE14 (BTS) is supported as
long as there is still a B-U GCLK in the system.
2-80 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Code Storage Facility Processor (CSFP)
Code Storage Facility Processor (CSFP)

CSFP functions
The CSFP is a GPROC or PCMCIA board device which facilitates the propagation of new
software instances with reduced system downtime. A software instance is a complete set of
software and firmware objects, including the database object.
New software loads can be downloaded from OMC to BSC and BSC to BTS, without a CSFP.
This download results in system downtime while the BSC or BTS is in ROM utilizing the IP. This
system downtime is dependent on link throughput (number of OMLs) and system topology
(number and connection of BTSs). The CSFP reduces this system down time since the download
takes place to the BSC or BTS while the system is online and processing calls.
{25423}
NOTE
The respective PCU code objects that are different from CSFP load are loaded onto
the PCU also.
The CSFP can also provide optional CSFP fallback to the old software load. After the software
has been downloaded to all entities in the BSS, a BSS reset is performed to activate the new
software instance. After the reset, the old software load can be retained on the designated
fallback CSFP.
This function can require that an additional GPROC is installed at InCell sites.
{27962} The total size of GSR9 load is estimated to exceed GPROC2 maximum available
memory. Hence, the CSFP must be GPROC3 in GSR9 or in GSR8 while upgrading to GSR9. A
GPROC can be the controlling source for only one download session at a time.
Equipping and unequipping a CSFP
The following MMI commands are used to equip and unequip a CSFP and are followed by the
equip (Specify a DHP in a network from the OMC-R Navigation Tree).
unequip (Delete a DHP from a network at the OMC-R Navigation Tree).
{25424}
NOTE
The equip and unequip commands are not applicable for PCU CSFP.
68P02901W36-S 2-81
Jul 2008
Changing CSFP characteristics Chapter 2: BSS Devices and Functions
Changing CSFP characteristics
The following MMI command can be used to change the CSFP characteristics.
chg_csfp - Change the CSFP algorithm or flow control values.
Monitoring a CSFP GPROC
The following MMI command is used to monitor a CSFP GPROC and is followed by the
disp_processor - Displays the status of all CSFP processor boards at a specific site or all sites.
2-82 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Digital radio Host Processor (DHP)
Digital radio Host Processor (DHP)

DHP functions
A Digital radio Host Processor (DHP) is required to support each instance of RSS function at a
type 1 BTS. This device cannot be equipped at M-Cell or Horizon sites.
Before these functions can be equipped, the actual GPROC that constitutes the DHP must
have been equipped.
Equipping and unequipping a DHP
The following MMI commands are used to equip and unequip a DHP and are followed by the
equip (Specify a DHP in a network from the OMC-R Navigation Tree).
unequip (Delete a DHP from a network at the OMC-R Navigation Tree).
The equip command for a DHP prompts the following:

First identifier for the DHP. The maximum number of GPROC2 or GPROC3s are eight
(slots 18 through to slot 25).
Unique identifier of the DHP in the specified cage in which the GPROC is fitted.
The slot location of the DHP GPROC board within the cage (18 to 25).
This prompt specifies the maximum number of DRIMs that the Central Authority (CA)
software allows the DHP to support.
Monitoring a DHP GPROC
The following MMI command is used to monitor a DHP GPROC and is followed by the equivalent
OMC-R facility:
disp_processor - Command displays the status of all DHP processor boards at a specific site
or all sites.
Equivalent facilities are provided at the OMC-R for performing these functions, as described
in the Installation and Configuration: GSM System Configuration (68P02901W17) manual. At
InCell sites, this command also displays the related devices and functions associated with
the processors.
68P02901W36-S 2-83
Jul 2008
Link Control Processor (LCP) Chapter 2: BSS Devices and Functions
Link Control Processor (LCP)

LCP functions
The Link Control Processor (LCP) is a GPROC or PCMCIA board device which supplies the Link
Control Function (LCF). Once the Link Control Function (LCF) has been equipped and assuming
GPROCs have been equipped, processors are allocated by the software. See Installation &
Configuration: GSM System Configuration (68P02901W17) manual and Link control function
(LCF) on page 2-97.
2-84 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Multiple Serial Interface boards (MSI)
Multiple Serial Interface boards (MSI)

MSI function
Multiple Serial Interface (MSI) or Multiple Serial Interface 2 (MSI-2) boards are supplied with
E1 interconnections and are equipped in the BSC, BTS, and the XCDR.
{22169} A maximum capacity of 96 MSIs enable up to 192 E1 links between the BSC and the
BTSs, RXCDR(s), and PCU.
The equip command associated with an MSI can equip some 2 Mb termination modules namely
the MSI, XCDR, MSI-2, and the NIU.
The MSI and NIU modules are capable of terminating two 2 Mb links.
The integrated NIU2 device on the H2SC card in Horizon II macro cabinets supports
up to six E1 links.
The XCDR performs the GSM TRAU function and can only terminate one E1 link.
The MSI2 module is capable of terminating two E1 links, configured by a database

parameter. For E1 link, timeslots 0 to 31 are provided. The MSI board and NIU is capable
of terminating two E1 links.
The GDP module supports the transcoding functions for full-rate, enhanced full-rate (EFR)
and half-rate. The GDP board is one of the required components of the EFR feature, which
provides better overall speech quality than full-rate.
The GDP2 module is capable of terminating two 2 Mb links when used in a ngRXU. It is,
however, possible for the GDP2 to operate as a 30-channel, one span line transcoder
card as a replacement to the GDP board and will be capable of processing AMR calls if
the feature is unrestricted. It can therefore be positioned in a regular RXU cage within
a regular BSSC cabinet.
E-GDP Enhanced GDP Provisioning supports GDPs that are capable of enhanced
transcoding, particularly AMR speech coding, in addition to supporting current transcoding
services and allows GDPs to provide additional enhanced transcoding resources only
without making use of the E1 line interfaces.
The NE can use database element, having CRC encoding ON or OFF for (E1 signaling).
68P02901W36-S 2-85
Jul 2008
Equipping and unequipping an MSI Chapter 2: BSS Devices and Functions
Figure 2-21 shows E1 MSI board connections.
Figure 2-21 MSI connections
MSC MSC
E1 T1 E1
XCDR MSI-2 XCDR R
1 255 1 X
C
0 0 D
R
MSI MSI-2
E1 T1
MSI MSI-2
0 B 0 B
S S
C C
land_layer1_mode=0 land_layer1_mode=1
ti-GSM- MSI connections E1T1-00149-ai-sw
Equipping and unequipping an MSI
The following MMI commands are used to equip and unequip an MSI and are followed by the
The prompts associated with the equip MSI command are dependent upon the type of site,
InCell, M-Cell, or Horizon.
InCell or Horizon
Unique identifier on a site basis.
Cage in which the termination board is fitted.
Slot in which the module is fitted, restrictions exist depending upon default positions and
cage type (BSU and RXU).
Module type fitted, MSI, XCDR, GDP, msi_ext_hdsl or MSI-2 converter.
Protocol type for MMS0-Displayed only if the integrated M-Cell HDSL is enabled and the
msi_type is msi_ext_hdsl.
2-86 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Monitoring MSI
Timeslots on MMS0-Displayed only if the integrated M-Cell HDSL is enabled and the msi_type
is msi_ext_hdsl and the protocol type is HDSL.
M-Cell or Horizon
Unique identifier dependent on site type: either M-Cell6 or M-Cellmicro. Only identifier 0
is valid at an M-Cellmicro.
Board frame identifiers, 0 or 1 (only identifier 0 is valid at an M-Cellmicro).
Slot in which the NIU is fitted, 0 or 1 (0 is the only possible value for M-Cellmicro).
Type of module in use: NIU, NIU with integrated HDSL modem, NIU with external HDSL modem.
Protocol type for MMS0- Displayed only if the integrated HDSL is enabled and the msi_type is
niu_hdsl or niu_ext_hdsl.
Timeslot supported on MMS0 - Displayed only if the integrated HDSL is enabled and the
msi_type is niu_hdsl or niu_ext_hdsl.
Modem setting on MMS0 - Displayed only if the integrated HDSL is enabled and the msi_type
is niu_hdsl and the protocol type is HDSL.
Protocol type for MMS1 - Displayed only if the integrated HDSL is enabled and the msi_type is
niu_hdsl or niu_ext_hdsl.
Timeslot supported on MMS1 - Displayed only if the integrated HDSL is enabled and the
msi_type is niu_hdsl or niu_ext_hdsl and the protocol type is HDSL.
Modem setting on MMS1 - Displayed only if the integrated HDSL is enabled and the msi_type
is niu_hdsl and the protocol type is HDSL.
Horizon II macro
The NIU2 MSI on a H2SC is auto-equipped with the equipage of the primary BTP device.
Where two H2SC are fitted for redundancy, although there is a NIU2 on each H2SC only one is
available for use, hence, there is only a single MSI with six MMS at a Horizon II macro BTS site.
HDSL is not supported at a Horizon II macro BTS site.
The MSI at a Horizon II macro site cannot be equipped or unequipped without equip or unequip
of the BTP.
Monitoring MSI
The following MMI command is used to monitor an MSI and is followed by the equivalent
OMC-R facility:
The Event and Alarm display windows on the OMC-R display the associated alarms.
68P02901W36-S 2-87
Jul 2008
Locking and unlocking MSI Chapter 2: BSS Devices and Functions
The MSI board can now be equipped from the OMC (SMASE-NMASE support). The
land_layer1_mode and mms_config_type BSS parameters are supported from the SITE and
MMS Detailed views.
Locking and unlocking MSI
The following MMI commands are used to lock and unlock an MSI and are followed by the
lock_device - Locks the MSI.
shutdown_device - Non-intrusively locks on MSI from further use.
unlock_device - Unlocks the MSI.
Changing MSI settings
The following MMI parameters with the chg_element command change the settings of the
MSIs as listed:
land_layer_1_mode - Determines that the NE supports E1 signaling.
land_layer1_mode, is set for E1 operation, the mms_config_type parameter setting

determines whether CRC encoding is ON or OFF.
When SYSGEN is turned off successfully, the settings of the land_layer1_mode and
mms_config_type parameters are written to NVRAM.
The land_layer1_mode and mms_config_type parameters are set when the NE or Site is
equipped and thereafter cannot be changed.
MSI alarms
MSI alarms are described in full in Maintenance Information: Alarm Handling at the OMC-R
(68P02901W26) manual.
The BSS supports six additional alarm threshold parameters for T1 red alarms for the MSI-2
board. These alarms are equivalent to the sync alarms reported in E1 systems.
2-88 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GDP2
GDP2

GDP2 operational requirements
A GDP2 supports 60 transcoding circuits capable of AMR Full-Rate (FR) and Half-Rate (HR), as
well as performing existing transcoding algorithms. Each GDP2 transcoding circuit interfaces
to 16 kbps or 8 kbps TRAU frame format. For an 8 kbps frame format, the remaining half of
the 16 kbps channel contains an idle pattern. Each GDP2 transcoding circuit is capable of
EFR, FR speech, and phase 2 data services.
The GDP2 can operate in two modes:

Basic:
Supports one E1 link; behaves as a GDP, but supports HR.
Enhanced mode:
Supports two E1 links and requires a ngRXU.
If the transcoding capability for a GDP2 is specified as basic, the configuration is a single
E1 (timeslot configuration per basic GDP) link. The basic GDP or GDP2 is assigned 16 TDM
timeslots and supports up to six 64 kbps links. A GDP_2E1 configuration allows up to six
64 kbps connections for MTL or OML or nailed connections through the first E1 link (MMS X,
0, 0).
Table 2-16 shows the relationship between the number of 64 kbps connections and the number
of CIC that can be equipped.
Table 2-16 equipage of CIC per 64 kbps connection
Number of
Maximum CIC
64 kbps
number
connections
0 30
1 30
2 29
3 28
4 27
5 26
6 25
7 24
8 23
68P02901W36-S 2-89
Jul 2008
TDM timeslot allocation Chapter 2: BSS Devices and Functions
The first MMS is equipped with 16 TDM timeslots. The second MMS is equipped with eight TDM
timeslots. The links on the second MMS are available for test or other purposes if CICs are first
unequipped to make TDM space available for the 64 kbps links.
It is not possible to equip a GDS, XBL, RSL, or PATH on a GDP2.
The CIC capabilities for a GDP2 are AMR FR, AMR HR, EFR, GSM FR, if the AMR capacity
feature option is included in the options object.
The GDP2 defaults to using one E1 and the state of the second span link (MMS) of a GDP2 is
changed to disabled-unlocked-BSSC2 or RXU2 in the following conditions:
If the cabinet at an RXCDR in which the GDP2 exists is not a ngBSSC and the GDP2 card is
in an XCDR or GDP slot.
If the cage in which the GDP2 exists is an RXU and the GDP2 card is in an XCDR or GDP
slot.
If the BSS SW detects an XCDR or GDP board in a slot where the MSI type is specified as
GDP2, the MSI device state changes to Disabled-Unlocked-Non-GDP2 Card Detected. If an
error occurs in reading the card type inserted in the slot, a GDP2 MSI device state changes to
Disabled-Unlocked reason bad or missing GDP2 board.
The BSS supports 30 transcoding circuits capable of AMR FR or HR for a GDP2 MSI type
where the transcoding capability is specified as basic (that is single E1 configuration). If the
transcoding capability is specified as enhanced then the BSS supports 15 transcoding circuits
capable of AMR FR or HR.
On DSP failure, the state of the affected CICs changes to Disable-Unlocked-XCDR or GDP fault.
TDM timeslot allocation
A new method of TDM timeslot allocation is applied so that stepping up from single rate mode
to enhanced capacity mode is possible, with minimal loss of service. This allocation method is
applied to devices provided at the extension cages equipped at RXCDR to employ the enhanced
capacity mode.
Devices equipped to the extension cages have an extra bank of timeslots to be allocated from,
which reduces TDM timeslot allocation congestion. However, if KSW or KSWX hardware is
deployed there are only the same 1024 timeslots available to be shared between a switch cage
and its child extension cage. In this situation, TDM timeslots that are offset by 1024 (that is
are the same timeslot but in different banks) can only be used by one of the two devices to
which it could be allocated.
To resolve this situation a new method for allocating TDM timeslots to devices is employed. This
method takes into account the other bank's TDM timeslot in the same position of each TDM
timeslot as shown in Figure 2-22.
2-90 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation TDM timeslot allocation
Figure 2-22 TDM allocation and overlay clash resolution
NOTE
Time slots shown allocated sequentially for clarity.
Table 2-17 shows how, when operating in single rate mode, the BSS evaluates the priorities of
CICs with allocated TDM timeslots that clash with devices in the other bank and will disable
those with the lower priority. Timeslots are allocated in enhanced capacity mode range, that
is 2048 timeslots per DSW for peripheral boards. Priority is given to assigning timeslots that
do not overlap ones in the opposite bank, that is if the two banks overlap because only one
range of 1024 (KSW) is available.
68P02901W36-S 2-91
Jul 2008
Installation and configuration Chapter 2: BSS Devices and Functions
Table 2-17 TDM timeslot allocation priorities
Bank 0 TDM timeslot Bank 1

Device in cage 0 N N+1024 *GDP2 span 1 timeslot x
*GDP2 span 1 timeslot x N+1 N+1025 Device in cage 1
Device in cage 0 N+2 N+1026 *GDP2 span 1 timeslot
x +1
*GDP2 span 1 timeslot N+3 N+1027 Device in cage 1
x + 1
.. .. .. ..
* Lower priority devices
During sysgen, TDM timeslots for the second MMS of a GDP2 are allocated last, that is given
highest priority for overlapping timeslots in the adjacent cage using the same KSW. The
timeslots for the second MMS is assigned when the sysgen off command is used to exit sysgen.
Switch connections are made on the DSW using 2048 timeslots per DSW if the site is running in
enhanced capacity mode (all DSW or DSWXs) or 1024 timeslots per switch in single rate mode.
The 1024 timeslot range is obtained from the 2048 timeslot numbering by dividing modulo 1024.
These requirements ensure that TDM timeslots are allocated in one bank and always take into
consideration the device utilization of the corresponding TDM timeslot in the other bank.
Speech and Data Services
The GDP2 does not support Phase 2 data services, when using the 8 kbps TRAU format, or the
14.5 kbps data rate service.
Installation and configuration
GDP2 configuration
The GDP2 can be configured as one of: a basic, enhanced primary, enhanced secondary or
twoE1 mode GDP board depending upon a request for the associated GPROC. Support for
the enhanced modes ensures that the GDP2 can be used in backwards compatible mode
as a GDP. If a GDP2 is configured as basic then it must support up to 30 traffic channels of
AMR/EFR/FR/data. If a GDP2 is configured as enhanced then it only has to support 15 traffic
channels of AMR/EFR/FR/data. A GDP 2E1 configuration allows support for up to 60 traffic
channels.
2-92 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation External Alarm System (EAS)
External Alarm System (EAS)

EAS function
The required customer site alarms can be connected through the parallel Interface extension
boards, fitted in the digital cage of InCell, upper slots 15 and 16 or the digital frame in M-Cell.
These PIX boards each have eight opto inputs and four dry contact relay outputs. In the
database up to eight boards can be specified per BTS for InCell. Although each PIX board must
be configured separately for M-Cell or Horizon, one board can be configured per cabinet to a
maximum of four per site. The functionality resides on an AB6 at an M-Cell or Horizon site.
{26481} Horizon II mini can utilize PIX inputs 1-6 only. Any attempt to equip 7-16 will be
aborted.
Equipping and unequipping an EAS
The following MMI commands are used to equip and unequip an EAS and are followed by the
equip (Specify an EAS in a network from the OMC-R Navigation Tree).
unequip (Delete an EAS from a network at the OMC-R Navigation Tree).
The equip command for an EAS prompts the following:
The Identity of the PIX board within the site, for In-cell sites and it is the cabinet id for M-Cell
sites.
The cage identity where the PIX is fitted. (Not prompted at M-Cell sites).
Backplane slot number; though this field has a valid range of 0-31 slots, the PIX board can only
be fitted into slots 15 and 16 in an RXU and slots 15-18 in a BSU, depending on its age. (Not
prompted at M-Cell sites).
Each output relay can be initially set to the open (1) or closed (0) position. Four outputs must be
set, regardless if they are being used or not.
The no alarm condition has to be specified for each of 8 or 16 opto alarm inputs, open (1) and
closed (0). Eight conditions must be set, regardless if they are being used or not.
Reported opto state changes, the master GPROC will only report on a change of state of an
opto input if specified in this list.
Alarm index as a text string which will appear in a resulting alarm condition can be specified for
each of the 8 or 16 opto inputs. Eight alarm indexes must be specified regardless of whether
they are being used or not. The text string mpf is used in place of one of the integers to indicate
which opto input is used for the EAS mains power failure alarm.
68P02901W36-S 2-93
Jul 2008
EAS alarm text string Chapter 2: BSS Devices and Functions
EAS alarm text string
As mentioned on the previous page, a text string, which will appear in any resulting alarm
condition, can be specified for each of the eight opto inputs. 34 text string messages can be
entered per BSS (0-33) each with a unique identifier.
The EAS alarm is specified using the command chg_eas_alarm (Detailed view of EAS at the
OMC).
There are three parameters:

alarm_table_index - This value corresponds to the number entered as the last parameter
in the equip_device EAS.
alarm_severity_level - The severity level of an alarm.
text string - The user name for the alarmed entity.
NOTE
If an EAS is equipped at an RXCDR this command must also be entered as the
RXCDR has its own OML.
Monitoring an EAS
The following MMI command is used to monitor an EAS and is followed by the equivalent
OMC-R facility:
EAS alarms
EAS alarms are described in full in Maintenance Information: Alarm Handling at the OMC-R
(68P02901W26) manual.
2-94 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Battery conservation in mains power failure
Battery conservation in mains power failure

EAS use
Mains failure is detected by one of the input sensors on the PIX board. The input to be used can
be specified in the database command equip EAS. The text string associated with such an alarm
cannot be specified by the customer and is preset as EAS has detected main Power Failure.
If an external battery backup supply is available in the case of mains failure, battery life can
be extended by deactivating a specified number of carriers.
Extending backup battery life
Two parameters are available to the chg_element command to control the extension of battery
life:
carrier_disable_time - When the mains power failure has occurred the EAS will inform
the Central Authority software element, which then waits this period before disabling the
first carrier. The CA also waits this period between disabling subsequent carriers.
carriers_ins_pwr_fail - This number of carriers always remain in service in a mains

power failure.
This option does not apply to an M-Cellmicro site.
68P02901W36-S 2-95
Jul 2008
Base Transceiver Function (BTF) Chapter 2: BSS Devices and Functions
Base Transceiver Function (BTF)

BTF functions
A BSP is required to control the switch manager for the KSW, but there is no RF functionality. A
BTF is therefore created.
The BTF function floats in that it is allocated to an available GPROC. Before the function can be
equipped, therefore, an actual GPROC must have been equipped.
Equipping and unequipping a BTF
The following MMI commands are used to equip and unequip a BTF and are followed by the
equip (Specify a BTF in a network from the OMC-R Navigation Tree).
unequip (Delete a BTF from a network at the OMC-R Navigation Tree).
The equip command for a DHP prompts for the maximum number of DRIMs that the Central
Authority (CA) software allows the BTF to support.
Monitoring a BTF
The following MMI command is used to monitor a BTF and is followed by the equivalent
OMC-R facility:
disp_processor - Displays the status of software and hardware information.
The disp_processor command displays the status of all the BTFs and their GPROCs at a specific
site or all sites.
2-96 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Link control function (LCF)
Link control function (LCF)

LCF function
In a small BSS (BSC type 0), all the signaling between the MSC and BTS sites can be processed
by the BSP but as the size of the BSS increases, more processing is required than can be
performed by one processor. Link Control Processors (LCPs) are then necessary to take the
load. LCFs can only be equipped at BSC site types 1 or 2.
NOTE
It is the function (LCF) that is equipped in the database and not the processor (LCP).
Like the BTF, a particular GPROC is not assigned to the LCF. A GPROC has to be
equipped at the site and functionality is distributed on initialization.
The link device capacity of an LCF is limited by the number of channels assigned to its GPROC.
Use of a GPROC2/GPROC3 increases the capacity of an LCF.
With GPROC2/GPROC3 as an LCP, the LCP can support more signaling links and BTSs.
Each MTL assigned to an LCF can have up to 31 channels, each RSL requires one channel
(regardless of the RSL rate) and each CBL assigned to an LCF requires one channel. Sites are
not link devices and therefore do not use channels.
Use of a GPROC2/GPROC3 requires a new database parameter indicating the number of links
supported on a GPROC2/GPROC3.
Equipping and unequipping an LCF
The following MMI commands are used to equip and unequip an LCF and are followed by the
equip (Specify an LCF in a network from the OMC-R Navigation Tree).
unequip (Delete an LCF from a network at the OMC-R Navigation Tree).
The equip command for a GCLK prompts the following:

LCF identification (0-24).
Maximum number of MTLs that the LCF can manage. The value 2 can only be entered
for a GPROC2.
Maximum number of Cell Broadcast Links (CBLs) that the LCF can manage.
68P02901W36-S 2-97
Jul 2008
Monitoring an LCF Chapter 2: BSS Devices and Functions
Monitoring an LCF
The following MMI command is used to monitor an LCF and is followed by the equivalent
OMC-R facility:
Changing LCF specifications
The following database parameter can be specified in the chg_element command for an LCF:
max_mtls - Used to specify the maximum number of DS0 channels the LCF can manage
as MTLs.
max_gsls - Used to specify the maximum number of GSLs the LCF can manage.
{28337}
NOTE
max_mtls can be set to 31 if the Increase Network Capacity feature is

enabled.
Change the security level to 4 to modify the parameters, max_mtls and
max_gsls.
LCF alarms
There are no LCF-specific alarms. GPROC alarms are described in full in Maintenance
Information: Alarm Handling at the OMC (68P02901W26) manual.
This option increases the LCF capacity on a GPROC2/GPROC3. The MTL limit has
been increased from a maximum of one MTL, on an original GPROC, to two MTLs on a
GPROC2/GPROC3 and one HSP MTL on a GPROC3-2. The number of BTS sites is also increased
from a maximum of eight BTS sites (15 RSLs), on an original GPROC, to 15 BTS sites (29 RSLs)
on a GPROC2/GPROC3/GPROC3-2.
2-98 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GPROC channel allocation (GPROC2/GPROC3)
GPROC channel allocation (GPROC2/GPROC3)
When an LCF is assigned to a GPROC2, or a HSP LCF on a GPROC3-2, any link devices
in excess of the GPROC channel limit cannot be brought into service. Channels on the
GPROC2/GPROC3/GPROC3-2 are allocated according to the following scheme:
Allocate one channel for each MTL in a GPROC2/GPROC3 or HSP MTL in a GPROC3-2
allowed on the LCF.
If the LCF allows a CBL, allocate one channel for the CBL.
Allocate the remaining GPROC channels for RSLs.
NOTE
Some GPROC channels can be used for GSLs, up to the value set in the max_gsls
parameter.
LCF assignment to GPROCs
LCF assignment to GPROCs is based on LCF identifier. LCFs are assigned in order from the
smallest LCF identifier to the largest LCF identifier. During site initialization, all of the GPROC
devices are allowed to transition to the Enabled-Unlocked state before functionality is assigned.
LCFs are assigned first to GPROC2/GPROC3s. If the GPROC2/GPROC3 device pool is exhausted,
the LCFs are assigned to GPROCs.
An LCF requires a GPROC2/GPROC3 to operate at full capacity if it uses more than 16 channels
or if it has more than one MTL or one HSP MTL. Assigning such an LCF to a GPROC can
result in fewer MTLs and sites coming into service and could cause the LCF to be outside of
the planning guidelines. An LCF assigned to a GPROC is not automatically reassigned to a
GPROC2/GPROC3 even if it becomes available.
Physical configurations
GPROC, GPROC2, and GPROC3s come into service when the element gproc_slots is set to 8, 16
or 24. GPROC2/GPROC3s come into service when the element gproc_slots is set to 32, GPROCs,
however, remain out-of-service in this situation with the reason GPROC_SLOTS exceeds 24.
68P02901W36-S 2-99
Jul 2008
Operations and maintenance function (OMF) Chapter 2: BSS Devices and Functions
Operations and maintenance function (OMF)

OMF function
This GPROC based function can be equipped only at a type 2 BSC. When a type 2 BSC is
specified, the software that controls the XBL and the OML, is migrated automatically to the
OMF GPROC.
Equipping and unequipping an OMF
The following MMI commands are used to equip and unequip an OMF and are followed by the
equip (Specify an OMF in a network from the OMC-R Navigation Tree).
unequip (Delete an OMF from a network at the OMC-R Navigation Tree).
The equip command for an OMF does not generate any prompts.
Monitoring an OMF
The following MMI command is used to monitor an OMF and is followed by the equivalent
OMC-R facility:
disp_processor - Displays software and hardware information.
OMF alarms
There are no LCF-specific alarms. GPROC alarms are described in full in Maintenance
Information: Alarm Handling at the OMC-R (68P02901W26) manual.
2-100 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GPRS Packet Control Unit (PCU)
GPRS Packet Control Unit (PCU)

PCU description
{27955A}
The PCU is an interface adaptor handler unit that permits the Motorola GSM facility access to
the packet network. The PCU manages the packet radio interface and also enables the interface
from the BSS to the SGSN. The PCU itself is managed by the existing OMC-R.
NOTE
The 3xPCU feature is disabled.
68P02901W36-S 2-101
Jul 2008
GPRS (BSC) Chapter 2: BSS Devices and Functions
GPRS network
Figure 2-23 shows the PCU in the BSS and its relationship to the other elements of the
GSM/GPRS network.
Figure 2-23 PCU in GSM/GPRS network
G SM EQ U IPM EN T G SN EQ U IPM EN T
M SC H LR RAD IU S SERVER PD N
(N O N -TR AN SPAREN T
M O D E)
RXCDR O M C-G
(Including Shelf
M anager)
O M C-R
BSC ISS SG SN G G SN
PCU
BSSn
G SN
BTSs BSS2 CO M M H U B G SN n
BSS1 G SN 1
O PERATO R SERVER
CO M PLEX
- RAD IU S SERVER
BILLIN G (O PERATO R IS ISP,
SYSTEM TR AN SPAREN T M O D E)
- D H CP SERVER
- D N S SERVER
ti-GSM-PCU GSM GPRS network-00151-ai-sw
GPRS (BSC)
PCU (at site level).
A GSL can be equipped at the MSI and the PSI.
2-102 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GPRS (PCU site)
GPRS (PCU site)
CABinet and CAGE are automatically equipped when a PCU is equipped.
Per CAGE a PCU System Processor (PSP).
Data PROCessor boards (DPROCs) - They can be configured as:

Packet Interface Control Processor (PICP).
Packet Resource Processor (PRP).
Processor with PRP and PICP function (PXP).
A PCU is able to support the BSS maximum number of cells.
PCU site
GPRS is implemented at a BSC by the addition of a PCU site. A PCU manages its own devices
(DPROC, PSP) independently. Two PSPs are automatically equipped at a PCU site.
68P02901W36-S 2-103
Jul 2008
PCU site Chapter 2: BSS Devices and Functions
Figure 2-24 shows the device and equipment hierarchy for the PCU device used by the GPRS
system.
Figure 2-24 Device and equipment hierarchy for the PCU device
BSC
PCU
CAB 1
CAGE 1
PSP 4 DPROC DPROC

(PICP) (PRP)
MSI
MSI
MMS
(TRAU)
MMS 2
GDS
GBL (LAPD)
GDS
GSL
NOTES:
1 indicates automatically equipped devices, when a PCU is equipped.
2 indicates automatically equipped device, when an MSI is equipped.
4 indicates that two PSPs are automatically equipped, when a PCU is equipped
ti-GSM-PCU device and equipment hierarchy-00152-ai-sw
2-104 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Equipping GPRS devices
Equipping GPRS devices

{27955A}
PCU site
The PCU device is identified in the text string pcu_0.
The location string pcu_0 is supported in all the relevant commands.
The commands and parameters are described in the Technical Description: BSS Command
Resetting the PCU site
The command reset_site supports only the location string pcu_0. Resetting the PCU site hard
resets the PSP at the PCU. Additionally, the PCU in addition to all BTS sites and the BSC is reset
when the command reset_site all is entered for a BSS.
NOTE
The MMI command location field is updated to support a maximum of one PCU site.
The strings pcu and pcu_0 are the only valid location strings to identify the PCU site.
Resetting the PCU site time
The command chg_time updates the real time at the PCU site.
In order to keep the system times in synchronization between the BSS and the PCU, time
updates are sent from the BSS to the PCU once during the first 2 minute interval after the PCU
device transitions to Busy-Unlocked and then after every 2 minutes.
Monitoring the PCU site
All devices equipped at the PCU site can be displayed by the command disp_equipment pcu.
The state of all full sized boards and their related devices at the PCU site can be displayed by
the command disp_processor pcu. Boards physically present but not equipped in the database
are also reported, as unrecognized or unsupported boards.
In DPROC displays, all MSIs equipped to the DPROC as related devices are listed. Each DPROC
type (PICP or PRP), which detects a PMC module that was not equipped in the database,
indicates the existence of an unexpected PMC module.
The command disp_bss includes PCU information in its display.
Timeslot usage for PCU MMSs can be shown by the command disp_mms_ts_usage pcu.
68P02901W36-S 2-105
Jul 2008
PCU as a device Chapter 2: BSS Devices and Functions
Timed device auditing of the PCU site is available using the chg_audit_sched and query_audits
commands. The assess command is also available for the PCU site to display severity or end
reconfiguration information for PCU devices.
The state of all devices equipped at a PCU site can be displayed by the state pcu all command.
The command status_mode pcu enables status notification for the PCU site.
A request to the PCU site audits all hardware that are auditable within the PCU, which includes
the PSP and all DPROC boards. The site_audit command can also be used to resume and
suspend site audits.
PCU site alarms
PCU site alarms can be displayed, deleted, enabled, and disabled by using the relevant alarm
commands.
PCU as a device
The PCU is considered to be a BSC device, which represents the overall state of the PCU site.
The PSP, CAB, and CAGE devices are automatically equipped at the PCU when the PCU is
equipped. The PCU contains a 16 slot Compact PCI bus.
The PCU device is considered in-service when BSC and PCU communication is established
through the GPRS Signaling Link (GSL) and the correct software processes are executed on the
PCU System Processor master board.
Monitoring a PCU
The command disp_equipment PCU displays the information entered during PCU equipage.
The full option is not supported for the PCU device.
Equipping and unequipping a PCU
The device state for a PCU equipped outside SYSGEN mode is Disabled-Locked. The PCU must
be manually unlocked to come into service. The state of a PCU found equipped during BSC
initialization time is set to Disabled-Unlocked with No Reason.
Unlocking the PCU device attempts to bring the PCU into service.
To come into service, the PCU device must first bring its child GSL devices into service. Prior
to having any GSLs in service, the PCU state is Disabled-Unlocked with the reason: No Link.
After communication is established with the PCU site, the BSC verifies that the PCU site is in
the expected state.
Once the PCU site is in the expected state and the code objects at the PCU site are compared
for validity, the PCU device state transitions to Disabled-Unlocked with one of the following
reason codes:
Code Load Required - indicates code loading is in progress.
Code Load Not Required - indicates that the PCU code is already validated.
2-106 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation CABinet in a GPRS system
Any objects out of date, missing or corrupt, are loaded from the BSC. After all the objects are
loaded and found valid, GSLs are torn down and restarted. The PCU site then proceeds with its
initialization process. When complete, the PCU site indicates to the PCU device at the BSC that
initialization is complete and the PCU device transitions to Busy-Unlocked.
The command unequip PCU removes all child devices that are local to the PCU site.
Specifically, the CAB, CAGE, PSP, DPROC, GBL, MSI, and MMS devices are automatically
unequipped and the Gb mapping information is removed. Because the GDS and GSL devices
depend upon BSC devices, they must be unequipped before the PCU is unequipped. Outside
SYSGEN mode, the PCU must be locked before it can be unequipped.
Taking a PCU in and out of service
Locking of the PCU hard resets all hardware on the Compact PCI bus at the PCU and results in
the GPRS service being unavailable. The PCU state transitions to Disabled-Locked and takes
its child GSL devices out-of-service. When the PCU device is locked, all GSL devices at the
BSC remain in the Disabled state until the PCU device is unlocked. The PCU device does not
support the Enabled-Locked state.
When the last connection to the BSC goes out-of-service, the BSC generates an alarm Last GSL
Failed. The PCU device state transitions to Disabled-Unlocked with the reason: No Reason.
If the PCU goes out-of-service for any reason, the BSC site is not reset except when the
reset_site all command is used.
Valid PCU out-of-service state reason codes
Valid PCU out-of-service state reason codes are given in the Maintenance Information: Device
State Transitions (68P02901W57) manual.
PCU alarms
For OMC Functional Unit alarm reporting purposes, a PCU FU severity is assigned to all device
reconfiguration. Loss of the PCU is Critical as it is a loss of data service.
Resynchronization for alarms and device state changes at the OMC is supported.
CABinet in a GPRS system
Equipping and unequipping a CABinet in a GPRS system
A CABinet in a GPRS system is automatically equipped when a PCU is equipped as CAB 0 0 0.
The PCU CABinet is automatically unequipped when the PCU is unequipped.
The PCU CABinet state is initially set to Busy-Unlocked.
68P02901W36-S 2-107
Jul 2008
CAGE in a GPRS system Chapter 2: BSS Devices and Functions
CAGE in a GPRS system
Equipping and unequipping a CAGE in a GPRS system
A CAGE is automatically equipped when a PCU is equipped as CAGE 0 0 0.
The PCU CAGE is automatically unequipped when the PCU is unequipped.
The PCU CAGE state is initially set to Busy-Unlocked.
Monitoring a CAGE in a GPRS system
The cage_audit command functionality is the same as that of the site_audit pcu command.
The cage_audit command can also be used to resume and suspend cage audits.
PCU System Processor board (PSP)
The PSP is a Master Processor (MPROC) board. It controls Compact PCI bus synchronization
and arbitration. The board also performs centralized configuration and fault handling for the
PCU site. The PSP board cannot come into service without its paired PCI to PCI Bridge (PPB)
board. (PCI is a Peripheral Component Interconnect board). The PSP continually resets until
its paired PPB is available.
The device_audit command can also be used to suspend and resume audits on the PSP device.
The BSS does not support the lock command on the PSP device.
Messages can be routed between any processor based at the BSC or BTS and any PSP or
DPROC board at the PCU, in either direction.
Prior to the introduction of MPROC redundancy, the only visible PSP state was Busy-Unlocked.
Now, the active PSP can only be Busy-Unlocked, but the redundant PSP can be Enabled-Unlocked
or Disabled-Unlocked.
Equipping and unequipping a PSP
Two PSPs are automatically equipped at a PCU. MPROC redundancy enables two PSPs to be
equipped in slot 7 and slot 9. A PCU can remain in-service with one PSP out-of-service.
The format for the equip command is given in Technical Description: BSS Command Reference
(68P02901W23) manual. The PCU controls all peripheral boards from its PSP.
The PSP devices are automatically unequipped when the PCU is unequipped. The PSP cannot be
locked. Hence, it can be unequipped only by unequipping the PCU.
2-108 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation PCU System Processor board (PSP)
Taking PSPs in and out of service
When the PSP is out-of-service, communication with the BSC is lost. The PCU will be considered
OOS until either the redundant PSP takes over or the active comes back into service. A PSP can
be in a state of Enabled-Unlocked or Disabled-Unlocked when it is the redundant PSP.
The underlying PSP device is reported for device-specific alarms.
The PSP stores all code objects in flash memory. Code objects are crossloaded from the PSP
through the Compact PCI bus to other processor boards upon initialization and when necessary
upon processor board resets. The BSC downloads PCU software objects to the PSP. When
communication is established with the BSC, the PSP sends its object version numbers to the
BSC and any mismatched objects are code loaded from a BSC GPROC.
Resetting a PSP
The BSS supports hard reset of the PSP board. If a hard reset is issued due to front panel reset
or an alarm condition (such as power failure or level 2 watchdog), or a Process Safe Test Audit
Failure due to a major software problem, the PSP board starts the following process:
Resets all on-board circuitry (including the processor).
Resets PPB circuitry.
Resets all on-board peripherals.
Resets all PPB peripherals.
Resets the local PCI bus.
Hard resets all boards found on the Compact PCI bus.
Performs a hardware self test. The board fails to come in service if the self test fails.
Performs the initialization sequence.
NOTE
Since the PSP stores all code objects in flash memory, a hard reset on a PSP with valid
code objects does not require a code download from the BSC.
PSP alarms
Audit failure of the PSP causes the Process Safe Test Audit Failure alarm to be activated.
The Process Safe Test Audit Failure alarm has additional Fail_Reason and Fail PID data.
If the fail reason is either Infinite Loop or Unknown Process Not Busy, the MPROC will
reset. In the second case Unknown Process Not Busy the process had a chance to run,
but failed the audit anyway.
68P02901W36-S 2-109
Jul 2008
Data Processor board (DPROC) Chapter 2: BSS Devices and Functions
Data Processor board (DPROC)
DPROC boards are processor boards which are not system slot specific. They can be configured
as a Packet Interface Control Processor (PICP) or as a Packet Resource Processor (PRP).
{28351} When U-DPROC2 replaces legacy DPROC boards, the GPRS capacity is increased by
combining the PRP and PICP functions into PXP functionality. The U-DPROC2 board can be
configured as PRP and PICP also.
Refer to PCU hardware backwards compatibility on page 2-123 and UDPROC-2 on page 2-119
for more details. The format for the equip command is given in Technical Description: BSS
Command Reference (68P02901W23) manual.
When configured as a PRP, the DPROC manages the packet resources at the PCU and is
the processor where all the radio-related processing occurs. GPRS channels are routed to
PRPs which perform all of the RLC/MAC processing, air interface scheduling, and frame
synchronization of the channels. The packets are framed in a TRAU-like structure and are
transferred to/from a GDS, for transport through the BSC to/from the BTS.
If configured as a PICP, the DPROC provides one or two E1 interfaces. If configured as a PRP,
the DPROC provides up to two E1 interfaces. These are provided by PCI Mezzanine Cards
(PMC modules) which are managed as MSI devices. Refer to Multiple Serial Interface boards
(MSIs) on DPROCs on page 2-113. {26740} A PSI can replace two MSI devices and the freed
slot can be used for 2 downstream or upstream span lines. The PSI provides an Ethernet link
between the PCU and the BSC.
Valid DPROC out-of-service state reason codes are given in the Maintenance Information:
Device State Transitions (68P02901W57) manual.
Equipping and unequipping a DPROC
The total number of PICP DPROCs and PRP DPROCs equipped in a PCU cannot exceed 12. A
maximum of 6 PICP type DPROC boards can be equipped at a PCU. A maximum of 10 PRP type
DPROC boards can be equipped at a PCU.
Two PICP DPROCs can be equipped in slot 1, slot 2 or slot 11 to provide connectivity to the BSC
(only one PICP DPROC is required, but two allow for redundancy). The preferred option is for
PICPs to be equipped to both slot 1 and slot 11, providing redundancy, so that if one side fails
the system can continue to function. This then leaves slot 2 for the PRP DPROC.
NOTE
The DPROC type PICP in slot 1 or slot 11 is connected to the BSC through an E1 link
to support upgrade or rollback to earlier releases.
With the introduction of EDGE, both MMS devices on a PMC can be used for TRAU GDSs.
There is no added capacity possible for systems without EDGE carriers available, but equipping
two TRAU GDS devices on a PMC in a system with EDGE carriers available allows for added
capacity. The following formula is used to determine what a PMC can support:
Number of 16 K channels + 2*Number of 32 K channels + 2*Number of 64 K channels <= 124
2-110 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Data Processor board (DPROC)
PRP DPROC redundancy is provided by the equipage of additional PRP DPROCs in excess of the
capacity needed. No substitution of a PRP DPROC occurs in the event of PRP DPROC failure.
PRP DPROCs share packet data service load across all available PRP DPROCs, if timeslot
capacity is available. If a PRP DPROC goes out-of-service, the remaining PRP DPROCs attempt
to take over the packet load of the out-of-service board. If no GDS TRAU is equipped, PRP
DPROCs will be Disabled-Unlocked. {22415} The BSC issues a warning regarding the total PRP
timeslot resources available at the PCU during a DRPOC unequipage.
PICP DPROC redundancy is provided by additional E1 links terminating on additional PICP

DPROCs.
DPROC boards physically present but not equipped in the database remain unused on the
Compact PCI bus.
Statistics are provided to monitor loading information for PRP DPROCs. These indicate and
predict PRP DPROC usage and capacity.
The device state for a newly equipped DPROC outside SYSGEN mode is Disabled-Locked. The
DPROC must be manually unlocked in order to come into service. The states of all equipped
DPROCs found during PCU initialization time are set to Disabled-Unlocked and attempts are
made to bring them into service.
A DPROC cannot be unequipped until all its child devices are unequipped. Outside SYSGEN
mode, the DPROC must be locked before it can be unequipped.
Taking DPROCs in and out of service
Locking the DPROC turns off the power to that DPROC slot and takes all DPROC child devices
out-of-service. A confirmation prompt is displayed when locking a DPROC that supports a GSL.
It is not possible to lock a PICP DPROC linked with the last in-service GSL. The unlocking of a
DPROC causes an attempt to bring the DPROC and all child devices into service.
The ins_device command used on a DPROC is equivalent to a lock and unlock of the DPROC
and used on PRP DPROCs causes rebalancing of the packet load twice. When the PRP DPROC is
locked, all data service for the PRP DPROC is moved to other in-service PRP DPROCs, if there
is additional timeslot capacity. When the PRP DPROC is unlocked and comes in service, data
service for lost cells is re-established on the PRP DPROC. Used on a PICP DPROC linked with
the last in-service GSL, the ins_device command causes the PCU to reset.
Any in-service PICP or PRP DPROC boards going out-of-service constitute a Major event and
loss of capacity. If the last available PICP or PRP DPROC goes out-of-service, this is a Critical
event and means the loss of GPRS functions altogether.
When a DPROC board is brought into service, the PSP verifies the software objects for the
DPROC. If the code objects are invalid, or no response is received from the board, the DPROC is
hard reset. One retry is attempted before transitioning the DPROC to an out-of-service state.
Resetting a DPROC
The reset_device command for the DPROC initiates a hard reset and is managed in the same
way as a lock and unlock of the DPROC. The same load balancing condition of bringing a DPROC
into service is used for resetting the DPROC. Used on a PICP DPROC linked with the last
in-service GSL, the reset_device command causes the PCU to reset.
DPROC initialization includes a self test and code load from the PSP. All equipped DPROC
boards found on the Compact PCI bus are initialized simultaneously during PCU initialization.
68P02901W36-S 2-111
Jul 2008
Data Processor board (DPROC) Chapter 2: BSS Devices and Functions
Code loading over the Compact PCI bus does not adversely affect the packet data service
also on the bus.
The DPROC device does not code load its child MSI devices. The PMC modules are code loaded
from the PSP as part of MSI initialization.
Monitoring DPROCs
The disp_equipment command on the DPROC device displays the information entered during
DPROC equipage.
A DPROC device_audit verifies software processes executing at the DPROC. The audit timing
interval is user configurable. If the audit fails, a Process Safe Test Audit Failure alarm
is generated and the DPROC is cycled out-of-service and then back in to service, if a major
software problem is detected. The device_audit command can also be used to suspend and
resume audits on the DPROC device.
Removal of a DPROC board that is in the Disabled-Locked state from a live PCU does not affect
other boards on the PCI bus. Insertion of a DPROC board requires the operator to initiate
commands to equip and/or bring the DPROC into service.
A DPROC board can be hard reset. If a hard reset is issued due to front panel reset or an alarm
condition (such as power failure or level 3 watchdog), or a Process Safe Test Audit Failure
due to a major software problem, the DPROC board starts the following process:
Resets all processors on the DPROC.
Performs a self test on the DPROC.
Re-establishes a communication with the Compact PCI bus.
Performs a code load from the PSP to the DPROC.
Restarts all processes on the DPROC.
Hard resets all PMCs.
Performs a built-in self test on the PMCs.
Performs a code load of the PMCs.
Any non-DPROC boards found in slots defined as DPROCs in the database remain disabled
with reason Bad or Missing DPROC. Insertion or removal of unsupported boards does not
affect other boards on the PCI bus.
DPROC alarms
If the processor on the board fails, a Processor Communication Failure alarm is generated
and the DPROC transitions to the Out-Of-Service state with a reason code of Processor Failure.
All resources supported by the board are then removed from service before an attempt is made
to bring the board back into service. One attempt is made to bring the board back into service.
Resources are reassigned to the board if it successfully comes into service.
If a valid PMC module does not exist on a PICP DPROC, the DPROC is unable to provide PICP
functionality and is unusable by the system. If no TRAU GDS is equipped on the DPROC, it does
not come into service (DU No GDS Equipped). If PRP GDS devices are OOS, the PRP is BU No
GDS in service and not in control of any GPRS cells.
2-112 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Multiple Serial Interface boards (MSIs) on DPROCs
{28000} The maximum number of GPRS timeslots that can be specified in a PRP is 120 when
the prp_fanout_mode is set to 1. When the prp_fanout_mode is set to 2, the maximum
number of GPRS timeslots that can be specified is 48.
When the DPROC is U-DPROC2, the maximum number of GPRS timeslots that can be specified
is 280 when the prp_fanout_mode is set to 1. When the prp_fanout_mode is set to 2, the
maximum number of GPRS timeslots that can be specified is 140.
Multiple Serial Interface boards (MSIs) on DPROCs
Whether configured as a PICP, or as a PRP, the E1 interfaces are provided by PCI Mezzanine
Cards (PMC modules) which are managed as MSI devices. T1 PMC modules are not supported.
MSIs at the PCU are managed exactly as any other MSIs.
If configured as a PICP, the DPROC should contain one or two PMC modules which provide E1
interfaces. If configured as a PRP, the DPROC can contain 1 or 2 PMC modules which provide
E1 interfaces. The PMC modules are managed as MSI devices. The MSIs are child devices of
the DPROC which are equipped and managed separate from the DPROC device. The PCU MSI
devices have identical functionality to existing MSI devices.
Equipping and unequipping an MSI on a DPROC
Two MMS devices are automatically equipped with each PCU MSI equip command for a
DPROC. Both of the MMSs equipped on an MSI can be used for a TRAU-type GDS.
One PICP DPROC must be equipped in either slot 1, 2, or 11 in order to provide default
connectivity between the BSC and PCU. An MSI must also be equipped in PMC socket 1
of one of these DPROCs.
Taking MSIs on a DPROC in and out of service
An MSI device cannot come into service if its associated PMC module is not recognized as a
supported device. If an unrecognizable PMC module is found on a DPROC, the associated MSI
device is brought to the state Disabled-Unlocked with a reason code of Bad or Missing MSI.
Because PCU MSIs are not removable without removing the DPROC board, the lock command
brings the MSI and its child devices out-of-service. Replacing a PMC module requires locking
and removing the parent DPROC.
A PCU MSI device cannot be in an in-service state unless its parent DPROC is in-service. If the
DPROC is not in service, the MSI is disabled with a reason code of Parent Not In-Service.
However, if the MSI is locked, its state is Disabled-Locked with a reason code of No Reason.
When a PCU MSI is brought into service, the PSP verifies the software objects for the MSI. If
the code objects are invalid, the PSP code loads the MSI. If no response is received from the
board, the MSI is hard reset. One retry attempt is made before transitioning the MSI to an
out-of-service state.
If the PCU MSI fails to code load in 30 seconds, the MSI is hard reset and one retry attempt
is made. Failure on the second attempt causes the PCU MSI to transition to an out-of-service
state with the reason code, Code Load Failure.
68P02901W36-S 2-113
Jul 2008
Resetting MSIs on a DPROC Chapter 2: BSS Devices and Functions
Resetting MSIs on a DPROC
A PCU MSI hard reset can only be initiated by the lock/unlock, ins_device, or reset_device
commands. Hard resetting the PMC module does not affect the state or functionality of the
parent DPROC or any other PMC module on the parent DPROC. All parts of the PMC undergo
resetting. The parent DPROC is unaffected.
The DPROC device does not code load its child MSI devices. The PMC modules are code loaded
from the PSP as part of MSI initialization.
Monitoring MSIs on a DPROC
The disp_equipment full command displays the PMC module information for MSIs equipped to
the PCU, even if the underlying PMC module is not supported.
The command device_audit verifies software processes executing at the PCU MSI. The audit
timing interval is user configurable. If the audit fails, the MSI state is cycled from out-of-service
and in-service.
The device_audit command can also be used to suspend and resume audits on the PCU MSI
device.
MSI alarms on a DPROC
The underlying MSI device is reported for PCU MSI device-specific alarms.
Multiple Serial Interface link (MMSs) on DPROCs
Whether configured as a PICP, or as a PRP, the E1 interfaces are provided by PCI Mezzanine
Cards (PMC modules) which are managed as MSI devices. Each MSI device has two child
MMS devices. T1 PMC modules are not supported. MMSs at the PCU are managed exactly
as any other MMSs.
BSC MMSs which are equipped to GDS devices cannot be selected as clock sources.
Equipping and unequipping an MMS on a DPROC
Two MMS devices are automatically equipped with each PCU MSI equip command for a
DPROC. Both the MMSs equipped on an MSI can be used for a TRAU-type GDS.
PCU MMSs must use the same CRC value in order to establish communication. This is enforced
by not allowing the parameter mms_config_type to be changed using the modify_value
command.
All MMSs on the same MSI must be configured for the same destination, either the BSC or
the SGSN.
Operators can choose to connect to the SGSN through MMS connections from the BSC to the
RXCDR, rather than directly from the PCU.
2-114 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation WebMMI
NOTE
If such a connection is made, the BSC MMS must not be used as a clock source. No
validation is performed by software to protect against this condition.
To equip an MMS to the SGSN, a GBL must be equipped. To equip an MMS to the BSC, a
GDS must be equipped.
MMS alarms on a DPROC
The underlying MMS device is reported for PCU MMS device-specific alarms.
Only selected alarms currently supported for the MMS device are supported for the PCU MMS.
WebMMI
The WebMMI option provides remote BSS service capability to users who have access to the
network where a PCU resides. The user has the ability to monitor and maintain a GSM BSS
from any part of the world through the operator's intranet and the availability of the PCU cage
and its Ethernet capability.
WebMMI is enabled by setting the PSP IP address, subnet mask, and router address at the
PCU. This is achieved by using the equip command at the BSC or the OMC-R. Use of the
disp_equipment command displays the values entered for the IP address, mask, and router
address and use of the modify value command allows these values to be changed. Details
of how these commands and settings are used can be found in manuals Installation and
Configuration: System Configuration (68P02901W17) and Technical Description: Command
Reference (68P02901W23).
Operation
WebMMI provides simultaneous output from both the customer Operation and Maintenance
(O and M) MMI and the Executive MONitor (EMON) through the Ethernet port on the PCU.
The information is displayed using a Java applet, downloaded from the web using a standard
web browser. The PCU, when initialized and in RAM, starts a web server that allows users
to download the Java applet, known as the WebMMI GUI. The applet is downloaded using
a standard web browser and navigating to website http://a.b.c.d/index.html, where a.b.c.d is
the static IP address assigned to the PCU MPROC. Loading this web page will run the Java
applet automatically.
While access to the MMI is always available, access to the EMON is available only when the
correct passwords are provided through the MMI prompt, using the change_level command.
Separate browser windows are opened for MMI and EMON. Commands can then be entered
in the same way as in a telnet session. The results of commands entered at the WebMMI GUI
will be seen there, as well as at the OMC-R rlogon and vice versa. The WebMMI output is also
duplicated at the MMI of the BSP.
Only one connection to the MMI and EMON can be made for each PCU. When the WebMMI
GUI is closed (by pressing exit, entering another web address, or closing the browser) all
WebMMI GUI windows and the connections will close and the PCU will be free for another
user to access the WebMMI GUI.
68P02901W36-S 2-115
Jul 2008
WebMMI Chapter 2: BSS Devices and Functions
Figure 2-25 shows a high-level representation of the WebMMI interface with the PCU.
Figure 2-25 WebMMI interface with the PCU
BSS requirements
The following items detail the BSS requirements for use of the WebMMI option:
PCU connected to the BSS.
Ethernet cable connecting the PCU MPROC to either:
The customer intranet directly through an ethernet hub.
A local dial-in server located next to the PCU. In this case the network would consist
of the PCU and anyone who dials in.
If MPROC redundancy is in use then a cable must also be connected to the redundant MPROC.
PC requirements
The following items detail the PC requirements for use of the WebMMI option:
Windows or Unix operating system suitable for running the necessary web browser.
Web browser, Microsoft Internet Explorer, or Netscape Navigator (v4 minimum).
Java run-time environment 1.3 minimum. If this is not already installed, the web browser
will prompt the user to do so before the WebMMI GUI can run.
2-116 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation WebMMI
The user must also create, or update, a file named java.policy in the home directory to include
permissions so that the WebMMI GUI can access the hard drive to save logs, load scripts and
create socket connections. The specific permissions required will be displayed on initialization
of the WebMMI GUI. If the required permissions are not contained in file.java.policy the
necessary additions to the text of that file will be displayed and further access through the
WebMMI GUI halted. After changing the java.policy file web browser must be restarted to
initialize the new permissions.
Interfaces
Figure 2-26 is a representation of the Web MMI and its interfaces. A new process called the BSS
Management Server (BMS) is developed to reside on the PCU. The BMS contains three servers
(MMI, EMON, and HTTP) each designated with a specific task serving the Web MMI. An HTTP
server will reside on the BMS. The Web MMI will use port 80 to establish a connection and to
download the subsequent applet.
The BMS sends a message to the TTY DLSP process, on behalf of the MMI server, to register the
existence or non-existence of an MMI socket connection. Likewise, the BMS sends a message to
the TTY DLSP process, on behalf of the EMON server, to register the existence or non-existence
of an EMON socket connection. The MMI server, using port 4000, manages the MMI. MMI
strings are sent to this server which in turn forwards the MMI commands to the TTY DLSP
process on the BSC. The TTY DLSP forwards the MMI string to the MMI process. The MMI
responses are sent, through the TTY DLSP, back to the BMS and onward to the browser.
The EMON server, using port 4001, manages EMON services. EMON strings are sent to this
server which in turn forwards the EMON commands to the TTY DLSP process on the BSC. The
TTY DLSP forwards the EMON string to the monitor process. The EMON responses are sent,
through TTY DLSP, back to the BMS and onward to the browser.
68P02901W36-S 2-117
Jul 2008
WebMMI Chapter 2: BSS Devices and Functions
Figure 2-26 Interfaces
2-118 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation UDPROC-2
UDPROC-2

{28351}
Overview
The Universal DPROC2 (U-DPROC2) replaces all the legacy DPROCs, to increase GPRS capacity.
It creates the PXP functionality with combined PRP and PICP functionality on the same board.
The boards are connected with the PSI board in BSC through a Gigabit Ethernet link (GbE).
NOTE
E1 GDS connectivity is supported on the PRP/PICP, but not on the PXP. The PRP part
of PXP functionality is lost if the Ethernet link goes OOS.
When the UDPROC2 is used as PXP, the PRP capacity/throughput is 280/70 in mode 1 and
140/140 in mode 2.
This feature reduces the PCU maintenance requirements and configuration complexity. The
PCU must be controlled by a single BSC.
Requirements
Each U-DPROC2 must be connected with a U-DPROC2 RTM (Rear Transition Module). Pairing
a U-DPROC2 board with a legacy RTM module or pairing a legacy DPROC board with a
U-DPROC2 RTM module is not supported.
Dependencies
This feature is dependent on the following features:

High Bandwidth inter-connection between BSC and PCU (PSI) on page 2-120.
Increase the PCU database capacity.
Packet/Coaxial Interface Module.
Air Flow Improvements for the PCU Cabinet.
68P02901W36-S 2-119
Jul 2008
High Bandwidth inter-connection between BSC and PCU (PSI) Chapter 2: BSS Devices and Functions
High Bandwidth inter-connection between BSC and

PCU (PSI)

{26740}
Feature overview
The PSI (Packet Subrate Interface) reduces the number of cables needed between BSC and PCU,
enabling the BSC to handle higher capacity configurations. The PSI provides an Ethernet link
from the BSC to the PCU.
Instead of using two MSIs to allow up to 120 timeslots of EDGE data, one slot is occupied by a
PSI to allow up to 320 timeslots of EGPRS data. A PSI can process 480 timeslots of EDGE data
but is restricted by the TDM highway timeslot allocation. The freed MSI slot can be used for 2
downstream or upstream span lines.
Feature interactions
This feature provides support to UDPROC2.
Related parameters and statistics
This feature introduces the following new parameters and statistics:
Parameters
This feature introduces the following new parameters:

eth_rx_errors_threshold
eth_tx_errors_threshold
psi_trau_fill_frames_threshold
dsp_error_inc
dsp_error_gen_thresh
dsp_error_clr_thresh
2-120 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Related parameters and statistics
Statistics
ETH_RX_ERROR - Tracks the number of times erroneous Ethernet LLC layer packets are
received on the Ethernet Link.
ETH_TX_ERROR - Tracks the number of packets transmitted that undergo excessive collisions
and are aborted on the Ethernet Link.
ETH_RX_BYTE - Tracks the total number of Ethernet LLC layer data bytes received on the
Ethernet Link.
ETH_TX_BYTE - Tracks the total number of Ethernet LLC layer data bytes transmitted on the
Ethernet Link.
ETH_RX_PKT - Tracks the total number of Ethernet LLC layer packets received on the Ethernet
Link.
ETH_TX_PKT - Tracks the total number of Ethernet LLC layer packets transmitted on the
Ethernet Link.
PSI_TRAU_FILL_TX_FRAMES - Indicates the percentage of TRAU fill frames on PSI.
68P02901W36-S 2-121
Jul 2008
Increase throughput of PRP with PCU Chapter 2: BSS Devices and Functions
Increase throughput of PRP with PCU

{28000}
Feature overview
The current PRP processor has a fanout of 120 PDCHs but only has a throughput of 30 PDCHs.
A rolling blackout mechanism is used to choose which 30 of the 120 PDCHs is serviced in a 20
ms block period. The Increase throughput of PRP with PCU is an optional feature that
provides an option to disable the rolling blackout mechanism on the PCU so that the throughput
of the PRP processor is the same as the fanout of the PRP. It provides two options, mode 1 and
mode 2. The capacity available in each option is described in Table 2-18. This feature resides
on the BSC and PCU.
When the rolling blackout mechanism is enabled, a maximum of X timeslots in a PRP are
allowed to perform data transfers in each direction (uplink and downlink) during every block
period. The other in service timeslots can transfer control messages. Without rolling blackout
mechanism, all timeslots configured in a PRP are allowed to perform data transfers in both
uplink and downlink directions.
A PXP configured by the UDPROC2 board has higher capacity and throughput. The increased
throughput of the PRP offers improved support for high throughput services such as HTTP,
PoC, and video streaming.
Table 2-18 PRP capacity
Total Fanout/Throughput/Number of mobiles

DPROC configuration
Mode 1 Mode 2
DPROC/PRP or U-DPROC2/PRP 120/30/120 48/48/72
U-DPROC2/PXP 280/70/280 140/140/280
The PRP capacity is different depending on the hardware configuration introduced by the Add
new PCU hardware to increase GPRS capacity feature and the PCU hardware backwards
compatibility feature.
Related Parameter
The following new parameter is introduced by this feature:
prp_fanout_mode - Supports two types of PRP fanout mode.

When prp_fanout_mode = 1, the rolling blackout mechanism is enabled on PCU.
When prp_fanout_mode =2, the rolling blackout mechanism is disabled on PCU.
2-122 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation PCU hardware backwards compatibility
PCU hardware backwards compatibility

{27955A}
Feature Overview
Backwards compatibility in the GSR9 software release enables existing DPROC hardware to be
reused in the PCU. It allows the following modes of deployment:
U-DPROC2 to be used as legacy DPROC (DD1).
Mix deployment, that is, old DPROCs work with new U-DPROC2 boards (DD3).
The U-DPROC2 board is used as PXP, that is, both the PRP and PICP functions combined into a
single DPROC board.
Legacy deployment (DD1)
For DD1, the U-DPROC2 serves as a PRP or PICP. It maintains legacy PRP capacity/throughput
(120/30) in mode 1 (with rolling blackout mechanism) but increases throughput (48/48) in mode
2 (without rolling blackout mechanism). All connectivity between BSC and PCU are E1s.
Mix deployment (DD3)
For DD3, the PCU allows DPROC (PICP), DPROC (PRP) and U-DPROC2 (PXP) to coexist in
the same PCU cage. Up to 11 PXPs with one PRP or PICP can be configured in the PCU. The
connectivity between BSC can be E1s (between MSI in BSC and PRP/PICP in PCU) and Ethernet
(between PSI in BSC and PXP in PCU).
Feature Interactions
The 3XPCU feature is disabled to reduce configuration complexity and improve availability.
68P02901W36-S 2-123
Jul 2008
Huge BSC Chapter 2: BSS Devices and Functions
Huge BSC

{28398}/{28340}/{23306}/{28337}/{22168}
Feature Overview
The Huge BSC feature enables the BSC to support a call load of 180k BHCA (90s call duration),
and to a maximum of 250k BHCA (64.8s call duration). It includes the following features:
Increased Network Capacity on page 2-125
High Speed MTL (HSP MTL) on page 2-126
BSP CPU utilization reduction for higher call handling capacity on page 2-128
BSC overload protection on page 2-129
Enhanced BSC Capacity using DSW2 on page 2-132
2-124 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Increased Network Capacity
Increased Network Capacity

{28398}
Overview
The Increased Network Capacity feature is an optional feature which supports up to 8 MB

database on the BSC. When the RAN capacity is increased with this feature, the network can
have maximum configurations of up to 750 carriers, 140 sites and 4800 circuits per BSC. The
existing RXCDR is capable of supporting 4800 CICs. The BSS supports 42 connections between
the RXCDR and the BSC.
System impact
The increase in the number of managed objects has an impact on the collection and dispatch of
the additional statistics. The collection and upload of the statistics to the OMC takes place at 30
minute or 60 minute intervals and is completed in 20 minutes.
68P02901W36-S 2-125
Jul 2008
High Speed MTL (HSP MTL) Chapter 2: BSS Devices and Functions
High Speed MTL (HSP MTL)

{28337}
Overview
To enable the BSC LAN to support 180k BHCA (90s call duration), and to a maximum of 250k
BHCA (64.8s call duration), the capacity of the MTLs is increased from 64 kbps to 2 Mbps.
MTPL2 and MTPL3 are started only on PQ2. The SCCP preprocessing functionality is removed
from MTPL3 and is started on 68k.
The PQ2 CPU on board GPROC3-2 (the legacy 680x0 CPU being the primary CPU) is a
replacement for the T71XX chipset which performed the HDLC link termination on that board.
PQ2 provides the full SS7 (MTL) stack and MTPL2 and MTPL3 processes are moved to the
GPROC3-2.
The CPU has to support an executive operating system so that the new application processes
can interface to executive operating systems features like messaging and mailboxes, IIRs,
SWFMs, buffer space.
The CPU requires a CPU id which can be used to address messages to the processes residing
on it PQ2 CPU has its CPU id in the format 4xyzh, where xyzh is the CPU id of the parent
68k CPU on the GPROC3-2.
Example 1
If a GPROC3-2 is deployed in slot 20 of cage 0, the 68k CPU has CPU id 0x0115 as we are all
familiar with, but the PQ2 CPU id is 0x4115.
Example 2
If a GPROC3-2 is deployed in slot 24 of cage 1, the 68k CPU has CPU id 0x0219, but the PQ2
CPU id is 0x4219.
Requirements
This feature requires the GPROC3-2 hardware to increase the MTL capacity. Since the PQ2 is
located at the GPROC3-2, at least one GPROC3-2 is required for hosting the HSP LCF in the BSC.
NOTE
Only one HSP MTL can be supported per GPROC3-2.
2-126 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Dependency
Dependency
This feature is dependent on the Increased Network Capacity feature.
Related statistics
The following new statistic is supported by this feature:
MTP_SL_ERROR_RATE_HSP - Used to track the number of times that a Signaling Link (SL) is
lost when the Error internal monitoring threshold (TE) is exceeded during the monitoring period.
68P02901W36-S 2-127
Jul 2008
BSP CPU utilization reduction for higher call handling capacity Chapter 2: BSS Devices and Functions
BSP CPU utilization reduction for higher call handling

capacity

{28340}
With the memory restriction being removed, the CPU efficiency can be improved at the cost of
higher memory usage. A list-based Ater search algorithm is used to allocate resources when a
new call (mobile originated, mobile terminated, external handover from MSC), CIC remap or
Ater switchover is initiated or for existing calls with rate change. The Aters are allocated from
the top of the available lists to minimize the search. This enables the BSC to assure that the
mean BSP CPU utilization does not exceed 70%.
2-128 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BSC overload protection
BSC overload protection

{23306}
Overview
This feature provides overload protection for the BSP CPU utilization when the BSS is working
under high load of call processing. It monitors the BSP CPU utilization in real time. When the
CPU utilization exceeds the overload threshold, it brings the CPU utilization to a safe level by
controlling the number of calls and handovers.
This feature interacts with the RSL congestion control feature in sending overload message to
the MSC. Only when both RSL congestion and BSP overload conditions are removed, the BSC
stops sending overload message.
Related commands, parameters and statistics
Parameters
The following new BSS parameter is introduced by this feature:
bsp_overload_protection - Specifies whether the BSP CPU overload protection is enabled.
Commands
The commands related to this feature are listed below:

disp_element - Displays the value of bsp_overload_protection.
chg_element - Changes the value of bsp_overload_protection.
68P02901W36-S 2-129
Jul 2008
Alarm information Chapter 2: BSS Devices and Functions
Statistics
This feature introduces the following new statistics:

PROCESSOR_SAFE_OVERLOAD - Provides a measurement of total time of active BSP
working in safe-overload state.
PROCESSOR_CRITICAL_OVERLOAD - Provides a measurement of total time of active

BSP working in critical-overload state.
HO_BLKD_BSP_OVERLOAD - Provides a measurement for the number of non-imperative

handover recognized messages dropped by LCF due to BSP CPU overload.
The existing statistic, MA_CMD_TO_MS_BLKD is modified to counter array type. It includes

a new bin BSP Overload for the total number of times an assignment request from the MSC
could not be processed due to BSP overload.
NOTE
In the safe-overload state, the CPU utilization is above 70% and below 95%.
In the critical-overload state, the CPU utilization is above 95%.
Alarm information
The following new alarms are introduced by this feature:

BSP CPU safe overload - Indicates that the BSP is in safe-overload state.
BSP CPU critical overload - Indicates that the BSP is in critical-overload state.
2-130 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation TDM Availability Enhancements
TDM Availability Enhancements

{25002}
Overview
This feature enhances the existing fault recovery and detection mechanism of the TDM buses
in the BSC and the RXCDR. This feature is supported only by configurations with expansion
TDM sites.
On detecting a fault in the active KSW/DSW2 expansion matrix, the system swaps to the
redundant TDM highway without waiting for the OMC to initiate the swap. The primary TDM
highway changes to EU state.
This feature also allows the automatic swap to the redundant TDM highway at a specified time
on a daily basis. If no fault is detected, the redundant TDM highway is continued to be used.
When the redundant highway fails, the system swaps back to the primary highway.
NOTE
Avoid swapping to the redundant highway when audit on the current TDM and/or
KSW is scheduled to occur.
68P02901W36-S 2-131
Jul 2008
Enhanced BSC Capacity using DSW2 Chapter 2: BSS Devices and Functions
Enhanced BSC Capacity using DSW2

{22168}
Overview
This feature enables the Huge BSC feature to be implemented by providing more TDM capacity.
This allows more traffic and more devices such as MSI, PSI, and so on, to be supported.
This feature requires that only DSW2s and DSWXs are used to enable extension of the TDM
highway for providing 8192 TDM timeslots. Each DSW2 can support 2048 timeslots and each
cage can support 1024 timelsots.
NOTE
This capability is like the enhanced capacity mode.
The CM regards the PSI, as an overlaid device. Hence, the PSI is not brought up when the BSC
with extension cage is in single rate mode.
2-132 68P02901W36-S
Jul 2008
Chapter
BSS Links

This chapter provides a description of the function and operation of the signaling and traffic
links to and from and within the BSS.

Message Transfer Link (MTL) on page 3-3.
Cell Broadcast Link (CBL) on page 3-6.
Terrestrial circuit device management on page 3-8.
Dynamic allocation of RXCDR-BSC circuits (DARBC) on page 3-14.
Dynamic network of BTSs (DYNET) on page 3-18.
EGPRS terrestrial backhaul on page 3-29.
VersaTRAU on page 3-30.
High bit-rate Digital Subscriber Link (HDSL) on page 3-33.
PATH on page 3-41.
Timeslot reservation on page 3-43.
Radio Signaling Link (RSL) on page 3-48.
Transcoder to BSS Link (XBL) on page 3-50.
E1 link management on page 3-59.
Aggregate Abis on page 3-62.
Setting up the PCU (GPRS) links on page 3-63.
PCU to BTS interface (modified for EGPRS) on page 3-65.
GPRS Gb interface to Air interface Mapping on page 3-66.
Gb link on page 3-70.
GPRS data stream on page 3-73.
GPRS Signaling Link (GSL) on page 3-76.
GSL link control function on page 3-81.
68P02901W36-S 3-1
Jul 2008
Feature interactions Chapter 3: BSS Links
GPRS PCCCH and PBCCH configuration on page 3-83.
Improved Timeslot Sharing (ITS) on page 3-86.
{30828} CTU2D on page 3-89.
{30830} CTU2D Asymmetric Edge on page 3-90.
3-2 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Message Transfer Link (MTL)
Message Transfer Link (MTL)

MTL function
{28337} The Message Transfer Link (MTL) is used to convey signaling information on the A
interface between the MSC and the BSC. It is a set of up to 16 links with bandwidth of 64
kbps per link or 2048 kbps per link.
Message transfer part
The first three layers of this protocol are constructed using Message Transfer Part (MTP) layer
1, 2 and 3. Layer 3, in a true SS7 network, is responsible for routing messages to particular
signaling points.
Signaling point codes
To enable routing of messages, each signaling point is allocated a Signaling Point Code (SPC).
This SPC can then be included, within MTP layer 3, in any message directed at that signaling
point.
This wider use of signaling point codes is not implemented on the A interface, as network
addressing is further processed by the MSC. Signaling point codes still have to be entered but
only for each end of the A interface.
A Network Indicator (NI) also has to be specified for each message. The parameter ni is used
with the chg_element command to specify national or international usage. Again this has a
much wider use in a true SS7 network. As far as the MTP layer 3 on the A interface is concerned
each message terminates at the MSC. Therefore, the value used for the ni parameter is set to
National Network (2).
Figure 3-1 MTP layer 3 on A interface
68P02901W36-S 3-3
Jul 2008
Improved load-sharing of traffic on MTLs Chapter 3: BSS Links
Improved load-sharing of traffic on MTLs
The load-sharing of traffic on Message Transfer Links (MTLs) in the uplink direction from the
BSS to the MSC is improved. Load-sharing in the downlink direction from the MSC to the BSC is
based on the routing function implemented at the MSC and is beyond the scope of this manual.
The granularity of the load distribution is increased from 16 to 64. The increase in granularity
results in a more even distribution of traffic across the MTLs.
The implementation of test traffic generation at the BSS for Message Transfer Part (MTP)
Layer 3 testing is modified to support the new load-sharing mechanism. A new MTP Layer 3
test message is added which allows the remote side to determine how the virtual circuits are
distributed over the active MTLs. A database element is added for setting the loadshare
granularity to either 16 or 64.
BSS routing function
Before the load sharing was enhanced, the BSS software distributed call signaling traffic across
16 virtual circuits are evenly spread over active MTLs. The message routing label consists of
the Originating Point Code field (OPC), the Destination Point Code field (DPC) and the Signaling
Link Selection field (SLS). A signaling point is required to route all message traffic based on the
three fields in the routing label. The SLS is a 4-bit field used for load-sharing between multiple
links in the same linkset. The typical signaling point always routes messages with the same
routing label over the same physical link. Routing messages in this fashion ensures that the
messages are delivered in order. For a given OPC and DPC, the SLS field is the equivalent of
a virtual circuit identifier.
The load-sharing enhancement distributes signaling traffic originating at the BSS across 64
virtual circuits. A router index in the range of 0 to 63 is randomly assigned to each call block
when a call is established. Random assignment results in even distribution of routing indices to
call blocks. The router index identifies the virtual circuit for all signaling messages associated
with the call block. The BSS MTP Layer 3 routing function evenly distributes the 64 virtual
circuits over the active MTLs. This routing function is compliant with the SS7 protocol, because
the BSS still routes all the messages associated with a given call over the same physical MTL.
SLS field information
Although the SLS is not used to perform routing at the BSS, the SLS field is filled in. The SLS
can be used for message routing by the MSC or some other signaling point in the SS7 network.
The CCITT implementation fills in the SLS field of the routing label with the lower 4 bits of
the router index. This technique guarantees that all messages associated with a call block
has the same SLS field and it results in an even distribution of SLS values to routing labels.
Connectionless messages are assigned a randomly generated router index. The SLS field is
filled by using the same technique described for connection oriented messages described above.
Implementation
The MTL device management software in the Central Authority (CA) process changes the
current SLS to Signaling Link Code (SLC) loadshare map to a router index to SLC loadshare
map. Router updates for the MTP_L3_SCCP and MTP_L3_SCCP_PEER functions are modified to
support the new router index to SLC loadshare map.
3-4 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Improved load-sharing of traffic on MTLs
The messaging between the CA and the message transfer part (MTP) Layer 3 is modified to
support the new load-sharing. The CA now sends the router index to SLC loadshare mapping
instead of the current SLC to SLS mapping to MTP Layer 3.
The Connectionless Manager (CLM), the SCCP State Machine (SSM) and the Cell Resource
Manager (CRM) also reuse the 6-bit BSC-BTS Link_Id field, which is currently used for
load-sharing traffic across RSLs, as the router index.
The MTP Layer 3 interfaces are changed to support the passing of router index with messages
to/from MTP Layer 2, SSM, CLM and CRM. The router index is passed to the MTP Layer 2 in
case the link fails and messages have to be retrieved. The MTP Layer 3 is updated to use the
logical routing with the MTP_L3_SCCP and MTP_L3_SCCP_PEER functions to support the
new instance range.
The MTP Layer 2 modifies the message passing interface to MTP Layer 3 for message signaling
units (MSUs) to support passing the router index.
The MTP Layer 2 transmit queue increases in size to support storing of the router index with a
message.
The SLS field for all MSU messages originating at the BSS is filled in, based on the router index.
The MTP Layer 3 process modifies the routing of test traffic messages and a new MTP Layer 3
test message is supported by the BSS for testing the load-sharing.
A new database element, only accessible from the BSS man machine interface (MMI), is added
for setting the loadshare granularity to 16 or 64. The database element can be changed at
any time, but the change does not take effect until all the MTLs are locked. If the element is
changed in SYSGEN mode, the change immediately takes effect. This element probably never
needs to be changed. The element is added to insure BSS/MSC backward compatibility.
68P02901W36-S 3-5
Jul 2008
Cell Broadcast Link (CBL) Chapter 3: BSS Links
Cell Broadcast Link (CBL)

CBL function
The Cell Broadcast Link (CBL) is a bi-directional data link which allows communications
between the BSS and the Cell Broadcast Center (CBC). A CBC must be provided in the network.
CBL is optional and must be purchased. It supports only a single 64 kbps, non-redundant
link using LAPB as the layer 2 protocol. DTE addresses must be configured through MMI in
order for the X.121 connection to be made. Operator names must also be specified. These are
included in the N-connect message used to establish the SVC and must be consistent at both
ends. The device resides on the LCF for type 1 and type 2 BSC sites. The link is not supported
at a type 0 BSC site.
The CBL can be connected directly from the X.25 network into the BSC through a E1 link as
shown in Figure 3-2. Alternatively, it can be directly connected (nailed) through a 64 kbps
link in the RXCDR.
Figure 3-2 Cell broadcast link
CBC X.25 BSC
CBC X.25 RXCDR
BSC
3-6 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Equipping and unequipping a CBL
Equipping and unequipping a CBL
The following MMI commands are used to equip and unequip a CBL and are followed by the
equip (Specify a CBL in a network from the OMC-R Navigation Tree).
unequip (Delete a CBL from a network at the OMC-R Navigation Tree).
The equip command for a CBL can be entered only at a BSC and prompts for:
Unique link device identifier.
First and second MMS identifiers.
Timeslot on the MMS on which this CBL appears.
BSS and Cell Broadcast Center (CBC) operators (20-character strings).
Monitoring a CBL
The following MMI command is used to monitor a CBL and is followed by the equivalent
OMC-R facility:
disp_equipment-Displays the status of software and hardware information.
Changing CBL characteristics
The following MMI parameters of the chg_element command changes the characteristics of
the CBLs. The MMI command is followed by the equivalent OMC-R facility.
cbc_fast_select - Type of X.25 network to be used. If this attribute is enabled, the BSS and
CBC attempt to exchange user data in the network connection and network connection
release phase of X. 25. If this attribute is disabled, the BSS and CBC will not exchange
user data in the network connection and network connection release phases of X. 25.
Changing this attribute causes the CBL device to be cycled.
max_cbls - Number of CBL devices which the LCF can manage. Increasing this value can
reduce link capacity of the LCF.
CBL alarms
CBL alarms are described in full in Maintenance Information: Alarm Handling at the OMC-R
(68P02901W26) manual.
68P02901W36-S 3-7
Jul 2008
Terrestrial circuit device management Chapter 3: BSS Links
Terrestrial circuit device management

Circuit identity code device and function management
Terrestrial circuit device management enables the Circuit Identity Code (CIC) devices to
be managed at CIC level, rather than at MMS level, thus providing greater diagnostic and
maintenance capability.
CIC devices are identified in three ways:

By CIC number.
On an MMS basis.
On an MMS basis providing timeslot and, if appropriate, group within a timeslot.
The group management capabilities mentioned refer to the ability of a command to be

applicable to multiple CICs. When using any of the related commands a range of CICs to be
affected can be specified.
Appropriate error messages are generated if any of the commands fail, for example by
attempting to lock a CIC which is already locked, or is not equipped. These messages are
generated whether the CIC in question is specified individually or as part of a group or range. A
command will, however, be accepted if any CIC in the specified range can successfully complete
the command.
When using the group management capabilities, all CICs change states independently.
Therefore, the command itself is active until all CICs have been affected. For example, if the
shutdown_device command is used, the command is active until all the CICs have changed
to the locked state.
CIC devices do not support status mode, so the MS cannot report when calls are set up or
finished.
In-service control information for the DSP, MSC and BSC side MMS to the BSC can cause the
CIC to be unblocked. The information will be lost if an XBL to the BSC is not in service (XBL is
optional).
Equipping and unequipping a CIC
The following MMI commands are used to equip and unequip a CIC and are followed by the
equip (Specify a CIC in a network from the OMC-R Navigation Tree).
unequip (Delete a CIC from a network at the OMC-R Navigation Tree).
3-8 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Equipping and unequipping a CIC
A particular CIC cannot be equipped more than once per BSC. When a range of CICs are
equipped, all CICs within the range are tested for uniqueness. If an attempt has been made to
reuse a CIC number, the command is accepted and an appropriate warning is issued identifying
the CIC which could not be equipped. If a timeslot in a range of CICs happens to have another
device equipped then that timeslot is ignored and an appropriate warning message is generated
identifying the timeslot for which the command has failed.
When a CIC is equipped on an XCDR or GDP, the state of the DSP on which the CIC is equipped
is assessed outside of SYSGEN mode. The state of DSPs is also assessed by periodic audits
and when the board is brought in-service. If the CIC is equipped on a known bad DSP, the
CIC is blocked.
The unequip command at the BSC handles the unblocking of the CIC regardless of the reason
the CIC was blocked. Hence, if a CIC is not unblocked when the del_channel command occurs,
it will be unblocked when the unequip CIC command is used.
NOTE
There is no static correlation between timeslots and DSPs. Therefore when equipping
CICs, there is no way of knowing on which DSP the CIC will be equipped.
CICs for use with dynamic allocation of RXCDR to BSC Circuits (DARBC)
When equipping a CIC for dynamic allocation of RXCDR to BSC Circuits (DARBC) use at a
remote transcoding BSC, the operator is always prompted for a static MMS timeslot assignment
(that is, a nailed Ater channel) to the AXCDR. The operator is not required to specify such an
assignment. If no such assignment is made, the CIC is blocked when the BSC is operating
in backwards compatibility mode. A CIC can not be equipped if the specified MMS has not
been added as part of the connectivity to the specified AXCDR. This static channel can not be
modified by the operator.
The operator can equip a single CIC device or a group of CICs at the RXCDR. No device
management can be performed for CICs at the RXCDR.
NOTE
The ability to equip CICs at an RXCDR replaces the need for add_channel and
del_channel commands.
The OMCcan create CICs as well as read or display their information at any time. The local
maintenance flag does not prevent the equipage, unequipage or any other management of the
CIC device from the MMI.
CICs equipped at the BSC are children of their associated AXCDR; CICs equipped at the RXCDR
are children of their ABSS.
When equipping a CIC for dynamic allocation of RXCDR to BSC Circuits (DARBC) use at a
remote transcoding BSC, the operator is prompted for the assoc_num parameter:
68P02901W36-S 3-9
Jul 2008
Monitoring a CIC Chapter 3: BSS Links
Enter the AXCDR which provides the TRAU resource(s):
This identifies the AXCDR providing the TRAU resource for that CIC.
At an RXCDR, the operator can use the same CIC number for multiple ABSSs.
Enter the ABSS which manages the CIC(s):
This identifies the Associated BSS that is managing that CIC.
The operator can unequip a CIC device at the RXCDR.
Monitoring a CIC
The MMI command is used to monitor a CIC and is followed by the equivalent OMC-R facility.
disp_equipment - Displays the status of software and hardware information, including if
terrestrial circuit management is restricted or unrestricted.
Locking and unlocking a CIC
In the following list the MMI command is listed followed by the equivalent OMC-R facility.
lock_device: Blocks CIC devices immediately. The CIC is locked and any traffic on that
CIC is terminated when the command is issued. The lock_device command also has
group management capabilities.
shutdown_device: Unobtrusively blocks a CIC. When the command is issued, the CIC is
not blocked until either the CIC is no longer carrying traffic, or a specified time limit
expires. This command also has group management capabilities.
unlock_device: The only means, other than using the ins_device or reset_device
commands, by which an operator can unblock any CIC, provided the circuit was blocked
using the lock_device or shutdown_device command. The unlock_device cannot
override system conditions; if a circuit is blocked due to an MMS or DSP outage, the
unlock_device command does not unblock that circuit. In addition, if an MMS or MSI has
locked CIC devices in it, unlocking the MMS or MSI with the unlock_device command
does not unlock the CIC devices. This command also has group management capabilities.
add_channel: Routes a CIC to an XCDR card. The command indicates the location of the
CIC on a E1 link on an MSI card. It also indicates the placement of the CIC on the E1 link
on the XCDR card. The command is used to set up the XCDR card to handle transcoding,
or rate adaption, for the CIC.
del_channel: Checks XBL connectivity. If connectivity is found, an attempt is made to

report in-service information to the BSC for the DSP, MSC and BSC side MMSs, regardless
of the real states of the MMSs and DSP. This attempts to clear the dependency of the
CIC at the BSC on RXCDR E1 link state.
ins_device and reset_device: These commands are treated as though they

were a lock_device command (immediately terminating all traffic on the
circuit) followed by a unlock_device command (unblocking the circuit).
3-10 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Enhanced terrestrial circuit management
Both of these commands can override circuit locks, that is, if a terrestrial circuit is locked
and a ins_device or reset_device command is used, the device transitions to a unlocked
state. The difference between the two commands is, in local transcoding, the reset_device
command audits any DSPs associated with the CIC being reset. Both commands have
group management capabilities.
Enhanced terrestrial circuit management
This database parameter enables enhanced terrestrial circuit management at a BSS:
enh_cic_mgt - Used with the chg_element command to specify the ability of a BSS to support
the enhanced terrestrial circuit management. It is stored only at the RXCDR and can be set
per BSS.
CIC alarms
CIC alarms are described in full in Maintenance Information: Alarm Handling at the OMC-R
(68P02901W26) manual.
Enhanced CIC validation for Adaptive Multi-Rate (AMR)

half-rate
With the introduction of half-rate speech version 3 to the BSS, existing functionality related to
call downgrade is enhanced. Half rate speech version 3 is added to the capability list of CICs
that are transcoded by an enhanced GDP pair.
ECERM
Enhanced Circuit Error Monitor (ECERM) counts faults on the RCIs, PICs, Aters and CICs (and
GCIs). If a problem occurs on a circuit, the fault count for the RCI/Ater/PIC/CIC is incremented.
The AMR half-rate channel mode introduces extra RCIs and PICs for an AMR half-rate carrier.
Adaptive Multi-Rate (AMR) in-call modification
Call capabilities can alter such that the BSS must perform an in-call modification procedure
as follows:
The CIC supporting an EFR call is changed.
The new CIC allocated for the call does not support the EFR speech codec.
The speech codec of the call is changed to a supported codec. For AMR half-rate
channel mode, the mechanism to perform the in-call modification is altered.
This happens because the BSS cannot dynamically switch between the full-
rate and half-rate channel mode while staying on the same radio resource.
68P02901W36-S 3-11
Jul 2008
Adaptive Multi-Rate (AMR) Chapter 3: BSS Links
If the channel mode of the call must change, the BSS performs an intra-cell handover to a
resource supporting the correct channel mode. In the following situations:
FR to AMR HR.
EFR to AMR HR.
AMR FR to AMR HR.
AMR HR to FR.
AMR HR to EFR.
AMR HR to AMR FR.
If the assignment is from an AMR HR speech version to an AMR FR speech version, or vice
versa, the MS is notified of the FR ACS, FR ICM and FR downlink codec mode adaptation
thresholds and hysteresis within the multi-rate configuration element in assignment command
message. The FR ACS, ICM and downlink codec mode adaptation thresholds and hysteresis
included in the multi-rate configuration element are specified in the database.
The BSS only performs a re-assignment to another resource if the request from the MSC cannot
be satisfied in any way by the current channel.
If the in-call modification is being performed to an AMR FR speech version from another
FR speech version, the MS is notified of the FR ACS, FR ICM and FR downlink codec mode
adaptation thresholds and hysteresis within the multi-rate configuration element in channel
mode modify message. The FR ACS, FR ICM and FR downlink codec mode adaptation thresholds
and hysteresis included in the multi-rate configuration element are as specified in the database.
Blocking or unblocking thresholds
In order to manage the blocking probabilities across multiple RXCDRs better, a mechanism will
be provided that will block idle CICs when an operator configurable threshold is reached. This
threshold will be on a BSC-RXCDR logical interface level and will include hysteresis.
In Enhanced Auto Connect (EAC) mode any idle, or equipped CICs associated with an AXCDR
are blocked when the blocking threshold is reached. A low Ater resources message is defined as
the reason for blocking a CIC. When the unblocking threshold is reached the low Ater resources
message is removed from the blocked CICs. If low Ater resources are the only reason set for
the CIC then the CIC is unblocked.
Ater resources are constantly monitored against the blocking or unblocking thresholds to
ensure that CICs are blocked or unblocked in accordance with system requirements. If the
blocking and unblocking thresholds are disabled for an AXCDR by setting the values to zero,
CIC blocking due to the thresholds for the AXCDR is not possible unless the number of available
16 kbps Aters for the RXCDR becomes zero. The low Ater resource message is not used as
a reason to block CICs until the number of available 16 kbps Aters reaches zero. When the
thresholds are set to zero and there are more available 16 kbps Aters, any existing low Ater
resource messages are cleared from blocked CIC.
3-12 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation AMR general call requirements
AMR general call requirements
In EAC mode, the BSS can need to allocate a new Ater to a CIC to support a call, either because
it has no Ater assigned or because the Ater is of the incorrect rate. When the BSS has to allocate
an Ater to a CIC to support a call it will first try to find an available Ater that is not connected
to a CIC. If all the Aters are assigned to CICs, the BSS will try to allocate an idle Ater that is
currently assigned to an AMR capable CIC. If there are no idle Aters connected to AMR capable
CICs, the BSS will allocate an idle Ater connected to a non AMR capable CIC.
The BSC uses a maximum of eight messages to the RXCDR to switchover a fully loaded MMS
(that is with 248 active calls). MMS failure could result in up to 248 calls requiring Ater
switchovers. To keep BSC-RXCDR messaging to a minimum, the switchovers are handled in
bulk and a maximum of eight messages will be used to switchover all the calls. These eight
messages do not include any messages needed to steal Aters from idle CICs or to preempt
non-emergency calls.
In EAC mode, when a call completes due to a termination or an external handover there is no
change to the CIC-Ater assignment. During times of congestion, there should be increased
Half-Rate (HR) usage and XBL messaging can be reduced if, when 8 kbps HR calls complete,
there is no change to the CIC-Ater assignment.
A full or half-rate non-emergency call in EAC mode is rejected if an Ater is not available in the
following circumstances:
Call initiation, FR or HR.
CIC remapping, FR or HR.
Internal handover, FR or HR.
External handover, FR or HR.
Ater switchover, FR or HR.
NOTE
Emergency calls also use preemption.
68P02901W36-S 3-13
Jul 2008
Dynamic allocation of RXCDR-BSC circuits (DARBC) Chapter 3: BSS Links
Dynamic allocation of RXCDR-BSC circuits (DARBC)

DARBC function
The auto-connect allocation of Remote Transcoder (RXCDR) to Base Station Controller (BSC)
circuits introduces fault management for call traffic on the BSC to RXCDR interface (referred
to as the Ater interface) by managing the individual 16 kbps channels (called Ater channels)
on this interface. In addition, this option provides for validation of the Circuit Identity Code
(CIC) and Ater channel provisioning between the BSC and RXCDR to ensure that calls are
placed on the correct circuit between the BSC and the MSC. Without this option in place, no
fault management of the Ater channels would be possible and all Ater and CIC information must
be manually verified by the operator, resulting in a higher Operation and Maintenance (O
and M) cost for the Motorola BSS.
The DARBC function provides the following benefits:

Simplified network provisioning, there is no need to manually map CICs to Ater channels at
both the BSC and RXCDR.
Simplified network debugging through automatic and manual audits of CIC and Ater
channel information between a BSC and RXCDR.
Better fault tolerance for call traffic as calls do not necessarily need to be terminated due
to a single failure on the linkset between an RXCDR-BSC.
Better utilization of network resources.
DARBC is consistent with Terrestrial Circuit Device Management, with respect to how the
operator is permitted to manage the CIC devices.
Ideally, all operators would use RXCDR to BSC links known as XBLs and all BSCs and RXCDRs
operate in auto-connect mode. However, since XBLs are not required to date for non-dynamic
operation and the current systems are all static, this option provides a mechanism to bridge
between static allocations and auto-connect allocations. If all operators decide to use XBLs and
if all BSCs and RXCDRs use auto-connect mode, the static-mode (backwards compatibility
mode) terminology, requirements, code and test cases created for this option will no longer be
necessary.
Effect on BSC and RXCDR roles
The DARBC function significantly redefines the roles of both the BSC and RXCDR within the
BSS network. Such changes, however, are transparent to other GSM network entities such as
BTSs and MSCs. In redefining these roles, a client or server approach is utilized in which the
BSC is the client to the RXCDR server. In other words, the RXCDR has the resources (CICs) that
the BSC wants to access, but the BSC technology selects which CIC to use.
3-14 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation DARBC operator equipage
BSC roles
The BSC roles are as follows:

Track CIC utilization.
Track Ater channel utilization.
Allocate or deallocate Ater channels as necessary.
Instruct the RXCDR to make switch connections between the Ater channel and Transcoder
and Rate Adaptor Unit (TRAU).
Initiate and execute audits of the CIC and Ater information.
RXCDR roles
The RXCDR roles are as follows:

Inform the BSC when activity (due to faults or operator actions) at the RXCDR affects
the usability of Ater channels and/or CICs.
Make switch connections between the Ater channels and TRAU resource when instructed
by the BSC.
Ensure that Ater channels and CICs are switch-connected to the proper idle tone at the
proper times.
Make additional switch connects, through necessary hardware, between the Ater channel
and the CIC.
Provide the BSC with the necessary CIC and Ater information for auditing.
Handle the error case where the BSC does not initiate the audit procedure.
DARBC operator equipage
Switching from a static allocation system to a dynamic allocation system presents some issues
that the operator should consider when planning and provisioning the BSC or RXCDR network.
The most important issue is that of equipping CICs at the BSC. When in auto-connect mode, a
CIC no longer has a fixed position on the Ater interface. CICs can be thought of as belonging to
a pool of CICs where a separate pool is maintained for each RXCDR connected to the BSC.
When a call is assigned to a CIC, the BSC allocates an Ater channel that goes to the same
RXCDR as the assigned CIC. One implication of such pooling is that the number of CICs
equipped through a particular RXCDR is not the same as the number of Ater channels from the
BSC to the RXCDR. In other words, the static system situation in which the number of CICs
equaling the number of Ater channels, because every CIC is nailed to one Ater channel, does not
apply in a dynamic system. In a dynamic system, the number of CICs can be more than, equal
to or less than the number of Ater channels.
If the operator chooses to equip more CICs than there are Ater channels to handle them, the call
assignment fails if there are insufficient Ater channels for all the CICs. Any CICs without Ater
channels will be blocked.
68P02901W36-S 3-15
Jul 2008
Auto-connect mode and backwards compatibility mode Chapter 3: BSS Links
Auto-connect mode and backwards compatibility mode
The operator can choose if a BSC and RXCDR operates in the auto-connect or backwards
compatibility modes.
Whichever operational mode to select is dictated by the cic_validation parameter on the

appropriate Associated Transcoder (AXCDR) device at the BSC. Consequently, the BSC decides
the mode of operation. Also, the mode is controlled on a per-AXCDR basis. If there are six
RXCDRs connected to the BSC then cic_validation must be turned on for all six corresponding
AXCDR devices at that BSC.
Auto-connect mode
This is an operator-selectable mode which refers to a BSC in which Ater channels are allocated
and released dynamically as resources are provisioned, un-provisioned or during handling of
fault condition. Auto-connect mode provides fault tolerance along with the call processing
efficiency of backwards compatibility mode. This is the recommended mode of operation for
the BSC.
Prior to the introduction of auto-connect mode, all Ater channels were statically assigned and
the use of XBL links was not mandatory. When using auto-connect mode, it becomes imperative
to equip XBL links on the RXCDR and BSC.
Backwards compatibility mode
This is an operator-selectable mode which refers to a BSC and/or RXCDR in which the Ater
channels and CICs are statically switch connected. This mode does not provide any fault
tolerance and CIC validations and is intended only to provide an upgrade path.
NOTE
If the BSC is to be upgraded, though there is no requirement at this stage for the
RXCDR to be upgraded, it is mandatory that the BSC use backwards compatibility
mode for the corresponding AXCDR. Otherwise all the associated CICs with the
AXCDR are blocked.
Network provisioning issues for dynamic allocation
Moving from a static allocation system to a dynamic allocation system (auto-connect mode)
presents some issues that operators should consider when planning and provisioning the BSC
or RXCDR network.
When auto-connect mode is on (that is to say, cic_validation is set to enabled) then

RXCDR connects Aters to CICs during initialization and when resources are provisioned or
unprovisioned. In other words, the connections are made before calls are set up and the system
behaves like backwards compatibility mode. However, if a fault occurs with the Aters or
Connectivity then the CIC-Ater connection can be switched over and the calls are not dropped.
So the auto-connect provides fault handling and does away with the excessive messaging of
the previous dynamic Mode.
3-16 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Auto-connect mode and backwards compatibility mode
Determining the number of XBLs required
XBLs carry the signaling traffic between BSC and RXCDR. The number of XBL links required
depends upon the number of CICs and/or the number of Ater interface channels.
Planning considerations
The following factors need to be considered when planning the number of XBL links from
BSC to RXCDR:
Determine the traffic requirements of the BSC and/or the number of trunks (CICs) used
between the BSC and RXCDR.
Determine the mode (backwards compatibility or auto-connect) in which the BSC and
RXCDR operate.
A maximum of 20 XBLs (64 kbps or 16 kbps) can be configured for a BSC or RXCDR.
A BSC can connect to a maximum of 10 RXCDRs and vice versa.
Provisioning
The number of XBL links depends on the number of trunks on the BSC-RXCDR interface and
whether or not the auto-connect mode is enabled at the RXCDR or BSC. Table 3-1 details the
minimum number of XBLs required to support the given number of trunks between the BSC and
RXCDR, with auto-connect mode.
Table 3-1 Number of BSC to RXCDR signaling links
N = number of MSC
No redundancy With redundancy
to BSC trunks
Number of 64 Number of 16 Number of 64 Number of 16
kbps XBLs kbps XBLs kbps XBLs kbps XBLs
N < 1200 1 4 2 8
1200 < N <2400 2 8 4 16
NOTE
The figures in Table 3-1 only apply to auto-connect mode. The redundancy
values are twice the non-redundancy values.
When using backwards compatibility mode (cic_validation is off for the
corresponding AXCDR device), technically there is no requirement to equip any
XBLs, but it is good practice to equip at least two 16 kbps XBLs for each AXCDR.
In backwards compatibility mode, the only traffic on the XBL is CIC block or
unblock information, which is very minimal; although one XBL link is sufficient,
built in redundancy should also be considered.
68P02901W36-S 3-17
Jul 2008
Dynamic network of BTSs (DYNET) Chapter 3: BSS Links
Dynamic network of BTSs (DYNET)

Dynamic network (DYNET) function
The number of resources reserved for all the cells in a BTS network cannot exceed the terrestrial
backhaul resources specified for the BTS network. The reserved number can exceed the number
of terrestrial backhaul resources available at any given time due to link or hardware failures.
The number of TCHs in a cell fluctuates on MS usage, transceivers equipped and hardware
availability. For simplicity and to minimize BSC-BTS interaction, the reserved cell capacity is
not compared against the number of TCHs available to a cell at any given point in time. The
reserved cell capacity can be greater than that actually available in the cell. In addition, there is
no comparison between the maximum number of TCHs possible in a cell and the reserved cell
capacity. The lack of this comparison allows the reserved cell capacity to remain unchanged
because RTFs can be unequipped from a cell.
BSC-BTS dynamic allocation (DYNET) provides terrestrial backhaul for radio resources for
TRAU on demand. When a call is placed on a TCH, the terrestrial backhaul resource is allocated.
When the call leaves a TCH, the terrestrial backhaul resource is freed. The terrestrial backhaul
resource is a 16 kbps portion of a timeslot on a E1 link and is allocated from a pool of available
resources by the BSC. This pool is shared by every BTS chosen to use dynamic allocation and
which are within the same network configuration.
Dynamic allocation allows greater air capacity to be equipped than there are terrestrial
resources, whether at a BTS site, or within a BTS network. This allows RTF equipage for
coverage purposes, not capacity purposes. Additionally, it allows capacity to move dynamically
between transceivers in the same network based upon traffic considerations.
Network topology
The user can specify what traffic is to use a specific path. Any direct route between any two
adjacent sites in a network can consist of one or more E1 circuits. Figure 3-3 shows a possible
network topology.
An alternative path can be reserved for voice or data traffic in the case of path failure. This
is known as a redundant path and is used to provide voice or data redundancy, that is loop
redundancy. The presence of multiple paths does not imply redundancy.
Each signaling link has a single path. When redundant paths exist, redundant signal links
are required and the signaling is load shared over these links. In the case of a path failure,
the traffic can be rerouted, but the signaling link(s) go out-of-service and the load is carried
on the redundant link(s).
3-18 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Star connection
Figure 3-3 Possible network topology
The maximum restrictions that each BTS site in the network must obey, together with other
equipment planning considerations, are described in the System Information: BSS Equipment
Planning (68P02901W21) manual.
Star connection
A star connection is defined by installing E1 circuits between each BTS site and the BSC, as
shown in Figure 3-4.
A star connection can require more MSI cards at the BSC than daisy chaining for the same
number of BTS sites. The star connection will allow for a greater number of carrier units per
BTS site.
An E1 circuit provides for 15 carriers plus one signaling link.
68P02901W36-S 3-19
Jul 2008
Daisy chain connection Chapter 3: BSS Links
Figure 3-4 Star connection
Daisy chain connection
Daisy chaining multiple BTS sites together can better utilize the 64 kbps timeslots of one E1
circuit from the BSC. Daisy chaining the sites together provides for the efficient utilization of
the E1 circuit for interconnecting smaller sites back to the BSC.
The daisy chain can be open ended or closed looped back to the BSC as shown in Figure 3-5.
The closed loop version provides for redundancy while the open ended does not.
NOTE
Longer daisy chains (five or more sites) can not meet the suggested round-trip delay.
3-20 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation E1 links between BTSs
Figure 3-5 Closed loop and open ended daisy chains
E1 links between BTSs
Even with dynamic allocation, greater bandwidth than that provided by a single E1 link is
required. To provide this, networks following the configurations shown in Figure 3-4 and
Figure 3-5 can have one to three E1 links between each BTS in the configuration. The same
number of E1 links must be specified between each BTS to maintain the simplicity needed to
provide dynamic allocation.
Dynamic allocation allows BTSs within a configuration to use the existing allocation mechanism.
Such BTSs continue to reserve terrestrial backhaul resources when RTFs are equipped.
Capacity in a network configuration is reserved for use for dynamic allocation by the BTSs
that use dynamic allocation. This capacity forms the pool from which terrestrial backhaul
resources are allocated.
Nailed paths
It can be required to declare additional paths to a BTS that uses dynamic allocation for nail
connection purposes. Dynamic allocation supports this functionality.
68P02901W36-S 3-21
Jul 2008
Call handling Chapter 3: BSS Links
Figure 3-6 shows a closed loop daisy chain with an additional path (shown as a dashed line) to
BTS 2. BSS managed resources cannot be placed in the additional path. It exists solely as a
convenience for defining nailed connections.
Figure 3-6 Extra path definition for nailed connections
Additional functionality introduced now allows the RTF to be used for non-TCH channels
when the path(s) for the RTF is not available, leaving the cell for the RTF in service. The cell
is still taken out-of-service when all RTFs in the cell lose their paths to the BSC. However,
a dynamic allocation site can use any of the path(s) to the site that appear in the dynamic
allocation network definition. If all of these path(s) are out-of-service, a dynamic allocation site
cannot be allocated any terrestrial backhaul resources. Hence, the cell(s) at this site is taken
out-of-service under these conditions.
Additional paths to dynamic allocation sites, as described previously, can be declared as a

convenience. Since these paths are not used for terrestrial backhaul resources, their state does
not influence the state of the cells at a dynamic allocation site.
Call handling
The existing functionality for call congestion handling, priority call handling and emergency call
handling deals with radio resources as dynamically allocated resources, but treats the terrestrial
backhaul resources as statically allocated. Hence, this functionality clashes with dynamic
allocation of terrestrial backhaul resources. Dynamic allocation limits call congestion handling
and priority call handling to radio resource considerations. Failure to allocate terrestrial
backhaul resources only affects emergency calls. Non-emergency calls are lost if terrestrial
backhaul resources cannot be allocated. Emergency calls take precedence over non-emergency
calls. If no terrestrial backhaul resources are available when an emergency call requests a
resource, an existing non-emergency call is terminated to provide the resource needed.
In addition, emergency calls take precedence over reserve resources for specific cells.
Emergency calls use whatever free terrestrial backhaul resources become available first.
Emergency calls take precedence over non-emergency calls in the same cell, at the same site
and from other sites in the same DYNET. If all available terrestrial backhaul resources are in
use by emergency calls or no terrestrial backhaul resources are available, the new emergency
call is lost.
3-22 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation 16 kbps RSL
16 kbps RSL
The 16 kbps RSL functionality is available to BTSs using dynamic allocation. The 16 kbps RSL
functionality uses a 64 kbps RSL to contact a BTS site when the site is suspected to need a
code load. The 64 kbps RSL is formed by combining the 16 kbps RSL with terrestrial backhaul
resources for carrying TRAU for the site. This stealing is allowed as the BTS is out-of-service
and hence is assumed not to need the terrestrial backhaul resources for carrying TRAU.
With dynamic allocation, no specific terrestrial backhaul resources are reserved for a site.
Forming a 64 kbps RSL can not be possible without affecting terrestrial backhaul resources that
can be allocated to other BTSs in the BTS network. To overcome this problem, the resources
that share the timeslot with a 16 kbps RSL are reserved for use by the 16 kbps RSL BTS site.
Hence, the resources are known to be not in use when the 64 kbps RSL needs to be formed.
The BTS site reserved resources sharing the 64 kbps timeslot with 16 kbps RSLs are the first
terrestrial backhaul resources allocated to the site. These resources can be allocated to the
site even if insufficient terrestrial backhaul resources remain for the unused reserved cell
capacity. These resources are not allocated if the cell at the BTS site has no unused reserved
cell capacity, another cell at the BTS site has unused reserved cell capacity and insufficient
terrestrial backhaul resources remain for the unused reserved cell capacity in the BTS network.
Otherwise, these resources are allocated.
RSLs do not share the terrestrial backhaul resources reserved to carry TRAU. RSLs are assumed
to always need terrestrial backhaul resources. RSLs are equipped to the network that is defined
for the BTSs that support dynamic allocation. RSLs are equipped at the rate, either 16 kbps
or 64 kbps, specified for the site.
Allocating and freeing terrestrial backhaul resources
Dynamic allocation attempts to minimize the BTS interaction needed to allocate or free a
terrestrial backhaul resource. The terrestrial backhaul resources are initially a set of nailed
connections throughout a BTS network as shown in Figure 3-7. When a resource is allocated to
a BTS, that BTS breaks its nailed connection. A connection to the TCH is made in place of the
nailed connection. When the resource is freed, the BTS re-establishes the nailed connection. No
change in connections is required at any other BTS in the BTS network.
68P02901W36-S 3-23
Jul 2008
Allocating and freeing terrestrial backhaul resources Chapter 3: BSS Links
Figure 3-7 Terrestrial backhaul resource nailed connection before a call
BSC
BTS 1 BTS 2 BTS 3
ti-GSM-Terrestrial backhaul resource nailed conn ection before call-00162-ai-sw
Figure 3-8 shows a resource allocated to BTS 2. BTS 2 connects the resource to the TCH using
one of the two possible paths to the BSC. BTS 2 changes the connection if the path being used
fails during the call. BTS 2 connects the unused path to the Abis idle tone.
Figure 3-8 Terrestrial backhaul resource connections during a call
3-24 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Redundancy
For the purposes of dynamic allocation, the configuration shown in Figure 3-9 is considered a
closed loop daisy chain configuration.
Figure 3-9 Closed loop daisy chain configuration with 1 BTS
The closed loop daisy chain has the potential to use the same resource in both portions of the
loop. For example, in Figure 3-9, both BTS 1 and BTS 3 could be using the same resource.
BTS 1 could use the resource on the E1 link between the BSC and BTS 1. BTS 3 could use the
resource on the E1 link between the BSC and BTS 3. If either E1 link failed, one of the calls
would no longer be able to use the resource.
Redundancy
Dynamic allocation does not support the use of closed loop daisy chains for additional capacity
when all E1 links are available. Dynamic allocation treats the closed loop nature of the closed
loop daisy chain as existing for purposes of redundancy. Such a design ensures that no calls are
dropped when a E1 link becomes unavailable in a closed loop configuration. This design also
simplifies the tracking of terrestrial backhaul resources (refer to Figure 3-10 and Figure 3-11).
Figure 3-10 Using redundancy for extra capacity before failure
68P02901W36-S 3-25
Jul 2008
Equipping and unequipping a DYNET Chapter 3: BSS Links
Figure 3-11 Using redundancy for extra capacity after failure
Equipping and unequipping a DYNET
If the dynamic network of BTSs option is to be made available, one DYNET must be equipped
per BSS site.
The DYNET device represents a dynamic network of BTSs that share terrestrial backing
resources. The network can include:
BTSs that do not support dynamic allocation.
Timeslot switching sites.
All DYNETs that share the same first identifier must have exactly the same BTSs or timeslot
switching sites in the same order. In addition, these DYNETs must have different E1 links used
by the BTSs within the BTS network. These limitations allow definition of multiple E1 link BTS
networks for sharing purposes, while limiting the configuration to simplify sharing.
The system does not verify whether dynamic allocation is available when a DYNET is equipped.
DYNETs must include at least one BTS that supports dynamic allocation. Such a BTS cannot
exist if dynamic allocation is not available to the operator.
The following MMI commands are used to equip and unequip a DYNET and are followed by the
equip (Specify a DYNET in a network from the OMC-R Navigation Tree)-equips PATHs for
the BTSs that support dynamic allocation automatically.
unequip (Delete a DYNET from a network at the OMC-R Navigation Tree).
3-26 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Monitoring a DYNET
Monitoring a DYNET
The following MMI command is used to monitor a DYNET and is followed by the equivalent
OMC-R facility:
disp_element - Displays software and hardware information.
Changing DYNET specifications
The following database parameters can be used with the chg_element command:
dynet_retry_time - Time (in milliseconds) that the BTS waits for a response from the BSC
when requesting a terrestrial backhaul resource.
dynet_tchs_reserved - Terrestrial backhaul resources that are reserved for a specific cell
when dynamic allocation is enabled for the site containing the cell.
The following database parameters can be used with the modify_value command:
rsl_rate - Information or control rate (16 kbps or 64 kbps) for the RSL.
shared_timeslots - Number of timeslots reserved for dynamic allocation on the MMS

defined by a DYNET device. (Can also be set in the equip DRI command).
System impact
The allocation of 16 kbps terrestrial backhaul resources requires 16 kbps switching at the
BTS site. M-Cell BTSs do not support 16 kbps switching. InCell BTSs support 16 kbps when
equipped with a KSW, not a TSW. In-building picocellular systems also support 16 kbps. Hence,
dynamic allocation is limited in the type of BTSs that can use the feature.
Moving capacity dynamically between BTSs or radios could result in some BTSs or radios, or
some cells in a BTS or radio, receiving no terrestrial backhaul resources when all resources
are in use. This situation is likely to be undesirable to an operator. To ensure that some
capacity exists for a particular cell, dynamic allocation provides the operator with the ability
to reserve terrestrial backhaul resources on a cell basis. Reserved cell capacity is stated in
the number of TCHs. Reserved cell capacity does not actually reserve terrestrial backhaul
resources. Instead, the reserve cell capacity limits the ability of cells to be allocated terrestrial
backhaul resources once the cell has been allocated its reserve amount. A terrestrial backhaul
resource will not be allocated to a cell when that cell has exceeded its reserved amount and
insufficient terrestrial backhaul resources exist in the unused reserved capacity for the other
cells in the network configuration.
The following example illustrates this point. Consider a network that:

Contains two cells, A and B.
Has two E1 link timeslots available for eight terrestrial backhaul resources.
Has the cell reserve capacity set at three TCHs for both of its cells.
68P02901W36-S 3-27
Jul 2008
Performance issues and timing Chapter 3: BSS Links
Assume that cell A has five calls occupying TCHs and cell B has one call occupying a TCH. At
this point, there are only sufficient terrestrial backhaul resources for two more TCHs. Cell A has
already reached its reserve cell capacity of three. Cell B requires two more TCHs to reach its cell
reserve capacity which is the total number of terrestrial backhaul resources left. Subsequently, if
cell A requests a terrestrial backhaul resource, its request is rejected due to the lack of capacity.
Dynamic allocation removes the non-blocking design of the existing allocation mechanism. Calls
can not move to a TCH at a BTS due to the lack of terrestrial backhaul resources.
Performance issues and timing
Using satellites to carry E1 links introduces an additional 600 millisecond one-way delay to
messages sent on links on the E1 links. Dynamic allocation requires a BTS to BSC request
and a BSC to BTS response. These messages incur a 1.2 second delay beyond the normal
transmit and queuing delay times. These times affect call setup and handover times, especially
if retransmission of the request or reply scenario is necessary due to message loss. Dynamic
allocation addresses this problem by adding an operator specified parameter that provides the
retry time for dynamic allocation requests. For non-satellite systems, the retry time should be
set to its minimum value. For satellite systems, the retry should be set to 1.2 seconds plus
the minimum retry value. The minimum retry time chosen is 150 milliseconds to account for
transmit and queuing delay times.
Adaptive Multi-Rate (AMR) dynamic allocation of BSC-BTS

circuits
The BSS regards an AMR half-rate BTS site that is part of a DYNET as a static site. The term
AMR half-rate BTS site refers to any BTS site where there is one or more AMR half-rate enabled
cells equipped. This requirement is satisfied automatically for this implementation of AMR
half-rate. This is because AMR half-rate can only be enabled at the cell level if the site to
which that cell is equipped is comprised solely of Horizon macro and M-Cell 2/6 cabinets. Sites
comprising such cabinet types are already always regarded as static by dynamic allocation of
BSC-BTS circuits feature functionality.
3-28 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation EGPRS terrestrial backhaul
EGPRS terrestrial backhaul

GPRS has increased the user data packet throughput to 59.2 kbps per air timeslot. Since the
backhaul is statically allocated to a timeslot a 64 kbps terrestrial timeslot (full DS0) is required
to support the maximum possible data rate of 59.2 kbps on one air timeslot. The PCU and the
CCU each require control information to be sent along with the data in the uplink and the
downlink respectively for each air timeslot. The control information overhead includes frame
synchronization information and control signaling.
To be able to fit the MCS9 block in a single 64 k DS0 it is necessary to define and reformat the
TRAU frame for MCS1 through MCS9. The following table describes the terrestrial channel
sizes needed for the control overhead and data for each MCS coding scheme.
Table 3-2 Coding Scheme Terrestrial Backing Needs
Channel Coding Schemes Terrestrial Resources Needed (per air timeslot)

CS1-CS2 16 k
CS1-CS4 32 k
CS1-CS4, 64 k
MCS1-MCS9
The initial release of EGPRS does not support dynamic allocation of the 64 kbps terrestrial
channels. Terrestrial channels are statically assigned as needed when an EGPRS carrier is
provisioned. The carrier configurations will be limited to the following combinations:
All air timeslots on a carrier allocated 16 kbps terrestrial channels
A cell configuration can be a mix of 16 kbps, 32 kbps and 64 kbps carriers.
Allocating a 64 kbps terrestrial timeslot for each air timeslot can significantly increase the
backhaul requirements between the BSC and the BTS. When the BCCH RTF is configured
with 64 kbps backhaul it is not necessary to provide 64 kbps backhaul for the timeslot which
is to be used as the BCCH, so when equipping 64 kbps BCCH RTFs, only seven timeslots of
backing will be allocated.
To be able to support the increase in user data, it is necessary to increase the total number of
TRAU GDSs that the PCU supports. As the 64 kbps channels are DS0 aligned and there is no
digit insertion or extraction necessary in the PMC module, the PMC has enough CPU processing
power available to be able to handle two full TRAU GDSs of 64 kbps TRAU. The increase in
overall GDS capacity in the PCU can also require the addition of a T43-interconnect panel if
the number of E1s terminating in the PCU is greater than 24.
68P02901W36-S 3-29
Jul 2008
VersaTRAU Chapter 3: BSS Links
VersaTRAU

VersaTRAU function
The VersaTRAU feature provides dynamic TRAU capability to EGPRS Carriers to optimize
backhaul usage.
Statistical multiplexing is utilized to pack radio blocks of variable sizes sent over PDCHs on a
carrier, into one large TRAU frame.
The Improved Timeslot Feature (ITS) feature requires VersaTRAU and EGPRS to be enabled on
Carrier A of a DD CTU2.
PDTCH to Backhaul Mapping
The VersaTRAU feature eliminates the static mapping between a PDCH and backhaul resources.
All the PDCHs on a 64 kbps carrier share a group of DS0s defined by a VersaTRAU channel.
Figure 3-12 VersaTRAU terrestrial timeslot mapping
Non -BCCH Carrier with 4

TCHs and 4 PDTCHs
CS1 --4, MCS 1-9,
PRACH, Idle A VT RTF with 4 DS0s
TS 0 TS 1 TS 2 TS 3 TS 4 TS 5 TS 6 TS 7
TCH TCH TCH TCH PDTCH PDTCH PDTCH PDTCH
16 K 16 K 16 K 16 K 1 K- 64 K 1 K- 64 K 1 K- 64 K 1 K- 64 K
VersaTRAU Channel
DS0 DS0 DS0 DS0
Frame omission in the uplink
The backhaul available for a 64 kbps PDCH in the uplink direction for a block period depends
on all the following factors:
The number of DS0s currently allocated for the RTF backhaul.
The number of PDCHs currently configured on the carrier.
3-30 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Performance statistics
The user data (CS1-4, MCS1-9) or signaling (CS1 or PRACH) traffic scheduled on each
PDCH on the carrier for a block period.
If the backhaul available for a PDCH on a 64 kbps carrier is not enough to carry the user data or
signaling received on the PDCH for a block period, the CCU omits the uplink RLC or MAC radio
block and sends the omission frame to the PCU.
Performance statistics
The following statistics are generated in the VersaTRAU feature:

UL_EGPRS_BACKHAUL_USED
UL_EGPRS_BACKHAUL_DEMAND
DL_ EGPRS_BACKHAUL_USED
DL_ EGPRS_BACKHAUL_DEMAND
EGPRS_64 K_CHANNEL_WIDTH
For further details, refer to Maintenance Information: GSM Statistics Application

(68P02901W56) manual.
Alarm information
The following existing alarms are modified by the VersaTRAU feature:

CERM
GDS OOS
For further information, refer to Maintenance Information: Alarm Handling at the OMC-R
(68P02901W26) manual.
Configuration management
The VersaTRAU feature requires the following RTF element:
rtf_ds0_count
This element specifies the number of RTF backhaul timeslots allocated for a 64 kbps carrier.
For further information, refer to 68P02901W36 Technical Description: BSS Command Reference
manual.
68P02901W36-S 3-31
Jul 2008
Diagnostics and debugging Chapter 3: BSS Links
Diagnostics and debugging
The VersaTRAU feature extends the PCU debug functionality as follows:
Additionally, users can:

Issue disp_rtf_channel on a 64 kbps RTF to display the current VersaTRAU configuration.
TSN-TRAU/PTRAU log.
Captures and displays uplink/downlink VersaTRAU frames on a VersaTRAU
channel.
PRM-Carrier log.
Displays all the uplink/downlink PTRAU frames on a VersaTRAU channel.
The possible DS0 statuses are listed below:

GSM ACTIVE - The DS0 is reserved for circuit switch traffic and at least
one air timeslot associated with the DS0 is hosting an active GSM call.
GSM IDLE - The DS0 is reserved for circuit switch traffic but none of the
air timeslots are hosting an active GSM call.
N/A UNUSED - The DS0 is not being used for GSM or GPRS.
GPRS ACTIVE - The DS0 has been configured for GPRS and is in sync.
GPRS INTRANS - The DS0 has been configured for GPRS but is not
in sync or the DS0 is in the process of being configured for GPRS or
de-configured from GPRS.
N/A ERROR - Generic error.
N/A MISMATCH - There is a disagreement between the relevant entities

as to the status of the DS0.
GPRS ERROR_PCU_CONFIG - The DS0 is supposed to be used for GPRS

but the PCU has not responded to the configuration request.
GPRS ERROR_CCU_CONFIG - The DS0 is supposed to be used for GPRS

but the radio has not responded to the configuration request or the radio
responded indicating an error.
GPRS ERROR_CCU_QUERY - The DS0 is supposed to be used for GPRS

but an error has occurred when the radio is queried for status of the DS0.
Use PRM per-carrier internal statistics to monitor the uplink omission information.
Use the five per-carrier statistics to monitor the backhaul usage and demand on a
64 kbps carrier.
Use the extra information carried in UL/DL Sync frames to debug problems related to the
Time Alignment procedure for each VT sub channel.
3-32 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation High bit-rate Digital Subscriber Link (HDSL)
High bit-rate Digital Subscriber Link (HDSL)

HDSL function
The HDSL option replaces the conventional E1 link with a twisted pair High bit-rate Digital
Subscriber Line (HDSL) link. It applies only to the M-Cell, Horizon micro, Horizon compact
and Horizon macro BTSs. Each interface is implemented as either E1 or HDSL, dependent on
specification during installation of the BTS.
Using HDSL improves the efficiency of installing and operating high speed links by using
unshielded twisted pair to carry high speed data. The connections supported by the HDSL
interface are best applied in microcellular applications where a relatively large number of sites
that are to be interconnected are located in a small area.
An HDSL interface, supporting 31 user 64 kbps timeslots, replaces E1 networks by attaching

a pair of external HDSL modems to the MSIs of a BSU-BTS or BSC or to the NIU, while still
providing existing alarm and operations support.
HDSL modems operate either as a Master or as a Slave. Each HDSL link requires one Master at
one end and a Slave at the other end. External Remote HDSL Modems can provide an HDSL to
E1 conversion for connecting the HDSL to other network equipment. These External Remote
Modems are controlled using the HDSL link from the NIU and are required to be Slave modems.
Internal HDSL modems default as Master on MMS0 and Slave on MMS1, enabling daisy chain
BTS configurations to be realized.
The NIU implements the type of interface, either E1 or HDSL, dependent on which interface
has been specified.
Initialization data required to configure the HDSL NIU interface at site initialization is stored in
MCU flash memory. If a redundant MCU is present, the HDSL settings stored on the master
MCU are used.
M-Cell or Horizon HDSL interface
Configurations
The HDSL interface introduced is supported on 16 (one twisted pair/loop) and 32 (two twisted
pair/loops) 64 kbps timeslots and can be configured in the following ways:
By attaching external HDSL modems to the MSI of a BSC, where the site is connected to an
integrated HDSL NIU, as shown in Figure 3-13.
By attaching external HDSL modems to the NIU of an M-Cell or Horizon site where the site is
connected to an integrated HDSL NIU, as shown in Figure 3-14.
Between integrated HDSL NIUs at M-Cell or Horizon sites, as shown in Figure 3-15.
68P02901W36-S 3-33
Jul 2008
M-Cell or Horizon HDSL interface Chapter 3: BSS Links
Figure 3-13 External modem at a BSC connected to an integrated HDSL NIU
M
M
Figure 3-14 External modem at a BTS connected to an integrated HDSL NIU
M
M
Figure 3-15 HDSL interface between integrated HDSL NIUs
3-34 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation NIU daisy chain equipping
NIU daisy chain equipping
Moving down a daisy chain all MMS 0 0 (NIU slot 0 link 0) must point in the same direction
(upstream or downstream) to avoid timeslot clashes between BTS sites and similarly all MMS 0
1 (NIU slot 0 link 1) must point in the same (opposite) direction (upstream or downstream). For
a closed loop daisy chain the terminology clockwise and anti-clockwise can be used instead of
upstream and downstream.
Correct configuration
With all sites in service the RSLs will be found on the following timeslots, between the BSC
& SITE 1 as shown in Figure 3-16:
RSL for site 1 on timeslot 1.
Between SITE 1 & SITE 2:
Figure 3-16 NIU Daisy chaining correct configuration
68P02901W36-S 3-35
Jul 2008
NIU daisy chain equipping Chapter 3: BSS Links
When site 1 resets, the path from site 2 to the BSC is lost and the RSL for site 2 goes
out-of-service. When site 1 boots back, it looks for the BSC on timeslot 1 on MMS 0 0 and also
on timeslot 2 on MMS 0 1.
Meanwhile, SITE 2 is still in service and looking to recover its RSL on timeslot 1 between sites 1
and 2. There are no timeslot clashes between sites 1 and 2 and the RSL for site 2 will come
into service successfully.
Incorrect configuration
With all sites in service the RSLs will be found on the following timeslots, between the BSC
& SITE 1 as shown in Figure 3-17:
Between SITE 1 and SITE 2:
RSL for site 2 on timeslot 1
Figure 3-17 NIU daisy chaining incorrect configuration
3-36 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation HDSL requirements
When site 1 resets, the path from site 2 to the BSC is lost and the RSL for site 2 goes
out-of-service. When site 1 boots back, it looks for the BSC on timeslot 2 on MMS 0 1 and also
on timeslot 1 on MMS 0 0.
Meanwhile, SITE 2 is still in service and looking to recover its RSL on timeslot 1 between sites
1 and 2. There is a timeslot clash on timeslot 1 between sites 1 and 2 and the RSL for site 2
will not come into service.
An NIU hard reset of MMS 0 0 at site 1 is needed to clear the problem.
HDSL requirements
An integrated HDSL NIU is able to contain up to a maximum of two HDSL modems, one
per E1 link. HDSL modem is required at both ends of the HDSL interface; one end must be
designated the master, the other the slave.
NOTE
Any external HDSL modem that is external to an MSI (EXT_MSI_HDSL) or external
HDSL modem that is external to a NIU (EXT_NIU_HDSL_MSI) must be configured
as a slave. This is because there is no software control of an external HDSL that
allows it to be set as a master.
The following constraints are applicable:

An HDSL NIU is only valid in slot 0 of a board frame. If a board frame supports an HDSL
NIU, an additional HDSL NIU cannot be equipped in slot 1.
An HDSL link can be considered as a transport mechanism for the E1 link, thus supporting
all E1 alarms and configuration parameters.
Daisy chaining between an M-Cell or Horizon BTS supporting HDSL NIUs and a BSC, or M-Cell
or Horizon BTSs with remote modems is also supported.
The configuration of an HDSL interface using external HDSL modems is not supported.
Equipping and unequipping an HDSL
The following physical interface conditions and restrictions apply:

The HDSL interface is supported on a minimum of one or a maximum of two unshielded
twisted pair carriers. Horizon micro BTSs support a maximum of two HDSL interfaces on a
single HDSL NIU.
The HDSL NIU can be unequipped and re-equipped to change the number of 64 kbps
timeslots supported on a E1 link.
An HDSL interface supports a minimum of 16 64 kbps timeslots, bearing in mind that only
15 of these timeslots are available for use. Timeslot 0 is the E1 synchronization timeslot
and is unavailable for traffic.
68P02901W36-S 3-37
Jul 2008
Equipping and unequipping an HDSL Chapter 3: BSS Links
An HDSL interface supports a maximum of 32 64 kbps timeslots, bearing in mind that only
31 of these timeslots are available for use. Timeslot 0 is the E1 synchronization timeslot
and is unavailable for traffic.
MMS clock extraction is supported on HDSL links.
The default status of the local HDSL NIU is set to:

HDSL (master) on MMS0, HDSL (slave) on MMS1.
The BSS software expects all external modems connected to internal modems at the
HDSL NIU to be slaves.
On links that support two external modems, there must be one master and one slave
modem. Configurations consisting of two external modems, although supported by
this option, do not provide any HDSL link management or alarm notification.
Configuration data required by the HDSL NIU interface is provided by the M-Cell or
Horizon BTS at the master end of the interface. Configuration data required by the external
HDSL modem is provided by the M-Cell or Horizon BTS at the master end of the interface.
NOTE
The slave configuration data is stored at the master modem.
The following MMI commands are used to equip and unequip an HDSL and are followed by the
equip (Specify a NIU in a network from the OMC-R Navigation Tree)-equips PATHs for
the BTSs that support dynamic allocation automatically.
unequip (Delete a NIU from a network at the OMC-R Navigation Tree).
Table 3-3 shows the E1 and HDSL conditions and restrictions apply:
Table 3-3 M-Cell or Horizon (one board frame, one NIU, one H/W T43 board)
E1 links HDSL links

0 2
Up to 1 1
Up to 2 0
NOTE
One HW T43 board (CIM equivalent) allows up to 2 HDSL links and up to 4 E1 links.
HDSL NIU utilizing HDSL is restricted to being equipped in slot 0 of board frame 0
for an M-Cell or Horizon system.
3-38 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Monitoring an HDSL
Monitoring an HDSL
The following MMI commands are used to monitor an HDSL and are followed by the equivalent
OMC-R facility:
disp_element - Displays software information.
disp_hdsl_settings - Displays software and hardware HDSL settings.
Changing HDSL specifications
The following command can be used
chg_hdsl_settings - Sets the HDSL settings stored on MCU FLASH memory or GPROC NVRAM
memory. Can be used only at a BTS and the site must be reset to take effect.
The following database parameters can be used with the chg_element command:
hdsl_losw_oos - Time (in seconds) the HDSL Loss Of Sync Word (LOSW) out-of-service
alarm period.
hdsl_losw_restore - Time (in seconds) the HDSL Loss Of Sync Word (LOSW) restoration
period.
hdsl_snr_daily - HDSL Signal to Noise Ratio (SNR) daily alarm level.
hdsl_snr_daily_mon_period - HDSL Signal to Noise Ratio (SNR) daily threshold period.
hdsl_snr_hourly - HDSL Signal to Noise Ratio (SNR) hourly alarm level.
hdsl_snr_hourly_mon_period - HDSL Signal to Noise Ratio (SNR) hourly threshold

period.
hdsl_snr_oos - Threshold (in dBs) that the HDSL SNR is below before going out-of-service.
hdsl_snr_restore - Threshold (in dBs) the HDSL SNR is above before being brought
back in service.
The following database parameters can be used with the modify_value command:
hdsl_modem_setting - Changes the setting of an integrated HDSL modem (master or
slave).
hdsl_oos_mon_period - Time (in seconds) the HDSL SNR is below the threshold before
going out-of-service.
hdsl_restore_mon_period - Time (in seconds) the HDSL SNR is above the threshold
before being brought back in service.
68P02901W36-S 3-39
Jul 2008
System impact Chapter 3: BSS Links
System impact
The HDSL has the following dependencies:

Requires appropriate Internal HDSL hardware kit options for M-Cellcity or Horizonmicro
and any External remote HDSL modems if required.
The HDSL supports E1 networks only.
When either the HDSL and E1 fail (are out-of-service), the BSS generates an alarm.
3-40 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation PATH
PATH

PATH function
The specific transmission route which traffic and signaling will take from a BTS, possibly
through intermediate BTSs, to the BSC is largely determined by the software. These routes,
or PATHs, must be specified using the available MSI boards and port numbers through each
BTS, starting from the BSC.
Equipping and unequipping a PATH
The following MMI commands are used to equip and unequip a PATH and are followed by the
equip (Specify a PATH in a network from the OMC-R Navigation Tree).
unequip (Delete a PATH from a network at the OMC-R Navigation Tree).
The equip command for a PATH can be entered only at a BSC and prompts for:
Identity of the BTS site terminating the path. Each BTS site can have up to 10 unique
paths, conventionally, numbering of paths start at 0.
Identity of the terminating MSI board and MMS port at the BSC. This is the identity of the
next BTS site in the chain. If aggregate Abis is enabled, the system will accept ts_switch
as the site Id. If ts_switch is used, the system will not prompt for upstream MSI, upstream
MMS, downstream MSI and downstream MMS identifiers.
Identity of the MSI board and MMS port at the first BTS in the chain, facing upstream
towards the BSC.
Identity of the MSI board and MMS port at the first BTS in the chain, facing downstream
towards the terminating site. A path can proceed through a number of BTS sites before
reaching its terminating BTS. The last three parameters are therefore repeated for each
intermediate site.
68P02901W36-S 3-41
Jul 2008
Monitoring a PATH Chapter 3: BSS Links
Monitoring a PATH
The following MMI command is used to monitor a PATH and is followed by the equivalent
OMC-R facility:
disp_equipment - Displays the status of software and hardware information.
PATH alarms
PATH alarms are described in full in Maintenance Information: Alarm Handling at the OMC-R
(68P02901W26) manual.
3-42 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Timeslot reservation
Timeslot reservation

Timeslot reservation function
Timeslots can be reserved and/or nailed for redistribution and patching throughout the
terrestrial BSS network.
Timeslot usage is described in this section as follows:

Reserved timeslots.
Add nail connection.
Nail path.
Reserved timeslots can be disabled and the status of timeslots at any time can be displayed.
Reserved timeslots
Timeslots can be reserved so that they are not available to be configured as RTF or RSL
timeslots by the software. Reservation bars their use as specified by the user. Reservation can
be singly or as a contiguous set. The usage status of timeslots can be displayed.
Reserving a single timeslot
The chg_ts_usage command is used to reserve a single timeslot. When reserving a single
timeslot, both the start_ts and end_ts arguments of the chg_ts_usage command must be equal
to the timeslot being reserved. The status of the timeslot to be reserved must be UNUSED.
Reserving contiguous timeslots
More than one timeslot can be reserved at the same time by reserving contiguous timeslots
using the chg_ts_usage command. Contiguous timeslots are specified by a start timeslot and
an end timeslot. All of the timeslots to be reserved must be UNUSED. If any of the contiguous
timeslots are in any state other than UNUSED, the command will fail.
Displaying MMS timeslot status
The current timeslot usage of a multiple serial interface link (MMS) at a site is displayed by
using the disp_mms_ts_usage command. Current usage should be checked before reserving
timeslots to verify current timeslot status.
Usage information is listed as General Timeslot Usage for individual timeslots not used as part
of a nailed path or an RXCDR. The usages associated with this function are RESERVED and
UNUSED. A timeslot must be UNUSED to be reserved.
68P02901W36-S 3-43
Jul 2008
Add nail connection Chapter 3: BSS Links
NOTE
The Add nail connection option is a purchasable option. If not purchased and
unrestricted, NAILED timeslots will not be present.
Add nail connection
The nailing of timeslots through a site enables third party non-GSM connections to be nailed
directly through the GSM terrestrial network. Nailing is the direct physical connection of the
incoming timeslot directly to an outgoing timeslot. The connection is provided by the switch
boards at the site.
Add nail connection allows the nailing of a single MMS (E1 link) timeslot or a range of
contiguous MMS timeslots. This capability is supported at BSC, RXCDR and BTS sites.
When a timeslot is nailed, it is barred from use by the BSS. It can be nailed from the unused or
reserved states. The database command for nailing a timeslot is chg_ts_usage.
When the operation field is set to nail, specified incoming timeslots are nailed to specified
outgoing timeslots. These timeslots can be specified in multiples, provided they are contiguous
on both incoming and outgoing legs. The ts_range defines the number of contiguous timeslots
to be nailed.
This option must be purchased and unrestricted.
Nail path
It is possible to nail single or multiple timeslots for the length of a path. For intermediate
BTSs the actual timeslots to be used are decided by FM software but are always initially
in the unused state.
The chg_ts_usage command is used to specify the path details in the database.
In the example shown in Figure 3-18, the operation field is set to nail_path. The parameter
ts_range defines the number of contiguous timeslots to be nailed through the path. BTS 12 has
one path, path 0. Timeslots 5, 6 and 7 incoming on MMS 2 0 on the BSC are nailed through path
0 of BTS 12 to MMS 3 1, timeslots 7, 8 and 9.
3-44 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Disabling timeslot usage
Figure 3-18 Nail path
Disabling timeslot usage
The reserved timeslots, nailed timeslots and nailed paths can be disabled by specifying FREE or
FREE_PATH in the chg_ts_usage command. The specified timeslots then become usable by
normal connections.
Contiguous timeslots are specified by a start timeslot and an end timeslot. If any of the
contiguous timeslots are in any state other than RESERVED or NAILED, the command fails.
Displaying timeslot usage
Timeslot status is displayed using the disp_mms_ts_usage command. If the timeslot is in any
state other than RESERVED or NAILED, the command will fail.
Refer to Technical Description: BSS Command Reference (68P02901W23) manual for a full
description of commands and parameters.
The following commands exist for use with the timeslot reservation function:
chg_ts_usage - Disables the reserved timeslots, nailed timeslots and nailed paths by
specifying FREE or FREE_PATH.
disp_mms_ts_usage - Displays timeslot status.
68P02901W36-S 3-45
Jul 2008
EGPRS TRAU format and TRAU format audit Chapter 3: BSS Links
EGPRS TRAU format and TRAU format audit
An RTF configured with 64 K packet radio capability has two sets of port formats configured in
the CM/DB, a 32 K set of ports and a 64 K set of ports. The 32 K ports are a subset of the 64 K
ports. Two port configurations are needed because only a subset of radios can support the 64 K
TRAU format. If the RTF is assigned to a radio that does not support the 64 k TRAU format,
the RTF falls back to the 32 K TRAU format.
BTS CA selects the TRAU formats for an RTF based on the capability of the carrier to which the
RTF is assigned. BSC SM and BTS SM are notified of the TRAU format selected and make the
switch connects based on the assigned format.
BTS CA implements an audit procedure to verify that both the BTS SM and BSC SM have the
same values for the TRAU format as BTS CA. BTS CA sends an audit request to both the BTS
SM and the BSC SM for the TRAU format of each RCI on a carrier. BTS SM and BSC SM
send back the format stored in the SM tables. Fault management correlates the data and
determines if the audit is successful or fails. If the audit fails, Fault management is responsible
for correcting the TRAU formats.
The BSC SM TRAU notification and audit procedures are new message sequence across the
MOBIS interface.
AMR TDM timeslot portion labeling
In the existing 16 kbps switching system, quarter divisions of TDM timeslots are referred to
as a sub-group or group of a timeslot, where group 0 corresponds to bits 0 and 1 switched
together. As it is now possible to have more rate combinations within a timeslot, re-labeling
has become necessary. Portions of a TDM timeslot are referred to by their bit starting position
and require a rate to be specified.
Table 3-4 shows how the group labeling is applied.
Table 3-4 TDM Timeslot configurations
DSW bit Port size

position 8 bit 4 bit* 2 bit 1 bit
7 Bit 6/16 k (group 3) Bit 7/8 k
6 Bit 6/8 k
Bit 4/32 k
4 Bit 4/8 k
Bit 0/64 k
2 Bit 2/8 k
Bit 0/32 k
0 Bit 0/8 k
* 32 kbps connections are supported by DSWs but have no current application.
3-46 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation AMR TDM timeslot portion labeling
8 kbps idle pattern
The CCU and transcoding board detect TRAU frame synchronization patterns during a voice call
or data transfer. If the synchronization is lost, the DSPs wait for an idle pattern to detect whether
or not the TRAU path has actually been broken and the call or data transfer has finished.
The 8 kbps idle tone on the DSW is set up at initialization. The existing 16 kbps idle tone when
expanded over 8 bits is 01010101. This pattern is programmed in a register in the switch
that is then set up to appear on a TDM timeslot. This is the source for any 16 kbps portion
of any timeslot.
The 8 kbps idle tone is defined to be consecutive ones or zeros according to the corresponding
idle pattern bit of a 16 kbps channel. Effectively the 8 kbps idle tone is therefore the same as
the 16 kbps idle tone and the 16 kbps idle tone will be reused as shown in Table 3-5.
Table 3-5 8 kbps idle tone bit patterns
DSW bit position Idle pattern Pattern over 8 TDM frames

7 1 11111111
6 0 00000000
5 1 11111111
4 0 00000000
3 1 11111111
2 0 00000000
1 1 11111111
0 0 00000000
8 kbps TRAU format frames are connected in the upper bit and the 8 kbps idle tone in the
lower bit, as the input into the EGDP or GDP2.
The enhanced GDP pair DSP or GDP2 DSP requires 16 kbps input regardless of whether being
used for half-rate or full-rate channels. When used for half-rate channels the lower 8 kbps half
of the 16 kbps inputs padded with the 8 kbps idle tone. Since the 8 kbps idle tone is the same as
the 16 kbps idle tone, the lower bit of a 16 kbps channel is always 0.
If, in a remote transcoding system, an 8 kbps Ater is allocated for a half-rate call on an RTF
using 8 kbps BSC-BTS backhaul, the idle tone is inserted by the RXCDR switch. If, a 16 kbps
Ater is allocated for a half-rate call on an RTF using 8 kbps BSC-BTS backhaul, the idle tone is
inserted by the BSC switch. This allows a simple 16 kbps connection to be made (or reused)
across the RXCDR.
The BSS ensures that if an 8 kbps connection is made where a 16 kbps connection previously
existed then the other half of the connection is always cleaned up.
68P02901W36-S 3-47
Jul 2008
Radio Signaling Link (RSL) Chapter 3: BSS Links
Radio Signaling Link (RSL)

RSL function
Signaling between the BSC and BTSs is by an interface which uses a 64 kbps timeslot with a
LAPD protocol.
Each BTS site in a GSM network requires at least one RSL for signaling and control purposes.
However, the occupancy of the RSL is relatively low-of the order of a few percent-most of the
time. Operations such as statistics file uploads increase the occupancy, but for relatively short
periods of time. Paging messages can cause congestion on the RSL. In this case paging traffic is
discarded until the congestion has abated.
The CELL can be configured to stop transmitting when the last RSL stays out-of-service (OOS)
for a specified period of time. Transmission resumes when the CELL returns to service (INS).
This functionality can be enabled or disabled per BSS in SYSGEN mode.
Because the BCCH RTF has seven traffic channels that occupy 16 kbps of bandwidth each on
the E1 links-four traffic channels on one timeslot and three on a second, each BTS has 16 kbps
of bandwidth on the E1 links that is not utilized for each BCCH carrier configured for the site.
The 16 kbps LAPD RSL option implements the RSL on the unused 16 kbps sub-timeslot, thus
eliminating the need for a 64 kbps timeslot for the RSL. A 16 kbps LAPD RSL can also be
configured on a non-BCCH RTF by blocking an air interface timeslot on the RTF from use
as a TCH.
In a 64 kbps RSL implementation, a full timeslot is utilized for each RSL configured at a BTS
site. With the 16 kbps LAPD option, the RSL is configured in one 16 kbps subchannel of the
two timeslots supporting an RTF. As a result, the 16 kbps LAPD option reduces the number of
timeslots required to support each site utilizing the option.
To reduce non-CSFP download time, the BTS sites use the full 64 kbps bandwidth of the timeslot
used for the RSL. This is possible since, while executing a non-CSFP download, the TCHs at the
BTS are not in use. Downloading to the CSFP must be performed at 16 kbps since the TCHs
can be utilizing the other E1 bandwidth allocated to the site.
RTF subequipping also reduces the number of timeslots required to support a BTS site by
permitting the operator to configure an RTF to utilize a single timeslot. This is achieved by
blocking four air interface timeslots on the RTF for use as TCHs. These timeslots can be utilized
to support BCCH or SDCCH channels within the limits imposed by the configuration parameters
and by the GSM Technical Specifications.
A BTS site can be either a 16 kbps or 64 kbps site. RSL devices terminate at a BTS at the same
rate. There cannot be a mixture of 16 and 64 kbps RSL devices terminating at the same BTS.
Horizonmacro and M-Cell6 cabinets support a maximum of six E1 links and six RSLs with
a maximum of two RSL devices allowed per E1 link. The integrated NIU2 on the H2SC in
Horizon II macro cabinets supports up to six E1 links and six RSLs with a maximum of four
RSL devices per E1 link.
3-48 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Equipping and unequipping an RSL
Equipping and unequipping an RSL
The following MMI commands are used to equip and unequip an RSL and are followed by the
equip (Specify an RSL in a network from the OMC-R Navigation Tree).
unequip (Delete an RSL from a network at the OMC-R Navigation Tree).
The BSC can support a mix of 64 kbps and 16 kbps RSL devices.
Monitoring RSL
The following MMI command is used to monitor an RSL and is followed by the equivalent
OMC-R facility:
disp_equipment - Displays the status of software and hardware information.
Locking and unlocking RSL
The following MMI commands are used to lock and unlock an RSL and are followed by the
lock (Specify an RSL in a network from the OMC-R Navigation Tree).
shutdown (Delete an RSL from a network at the OMC-R Navigation Tree).
unlock (Specify an RSL in a network from the OMC-R Navigation Tree).
The remote site goes out-of-service when the last RSL to the site is locked.
When 16 kbps RSL devices are taken out-of-service, the capacity load on each E1 link increases.
RSL alarms
RSL alarms are described in full in Maintenance Information: Alarm Handling at the
(68P02901W26) manual.
68P02901W36-S 3-49
Jul 2008
Transcoder to BSS Link (XBL) Chapter 3: BSS Links
Transcoder to BSS Link (XBL)

XBL function
The BSS supports optional 16 kbps channels for the XBL. This provides six more traffic
channels between the BSS and the RXCDR when duplex XBL devices are employed and reduces
the interconnect costs between an RXCDR and a BSC. A full E1 timeslot for each XBL is not
required, leaving more resources available for use as CICs or control links.
The two 64 kbps XBL devices occupy one 64 kbps timeslot each on the E1 interface. Up to four
CICs could occupy a single 64 kbps timeslot on the RXCDR-BSC E1 link. The reduction in
XBL bandwidth from 64 kbps to 16 kbps enables one or more XBL devices to be multiplexed
on a single E1 timeslot with up to three CICs. No restrictions are placed on which groups
of a timeslot the XBL can occupy.
A data rate of either 16 kbps or 64 kbps can be selected on a per XBL basis. For each XBL, the
16 kbps group of a 64 kbps timeslot to put the XBL can also be selected.
Certain extra operational requirements are necessary when configuring a 16 kbps XBL. Firstly,
a 16 kbps XBL must always be equipped on the same group and with the same data rate at
either end of the RXCDR-BSC E1 link. Secondly, to alter the data rate of an XBL or the group
on which a 16 kbps XBL resides, the XBL at both ends of the RXCDR-BSC E1 link must be
unequipped and then re-equipped.
The RXCDR supports up to two 16 kbps LAPD XBL devices to a BSC. The BSC supports up to
two 16 kbps LAPD XBL devices to an RXCDR. The RXCDR and BSC support a mixture of 16 kbps
and 64 kbps XBL devices.
No more than two XBL devices can be enabled between an RXCDR and a BSC. The multiplexing
of a single 16 kbps XBL with up to three CICs on a single 64 kbps E1 timeslot is supported
between a BSC and an RXCDR. The multiplexing of two 16 kbps XBL devices with up to two
CICs on a single 64 kbps E1 timeslot is supported between a BSC and an RXCDR.
The BSC and the RXCDR support the configuration of a single 16 kbps XBL on any group of a
single 64 kbps E1 timeslot multiplexed with up to three CICs, or the configuration of two 16 kbps
XBL devices on any two groups of a single 64 kbps E1 timeslot multiplexed with up to two CICs.
Enhanced XBL
Enhanced XBL (EXBL) improves the robustness of communication between the BSC and the
RXCDR. The basis of this improvement is to provide a generic messaging system, between
the BSC and the RXCDR, that meets current operator needs and the needs of future BSS
enhancements. This improvement is obtained by the storing of all connectivity information for
all RXCDRs and BSCs connected.
Operator-visible aspects of the EXBL feature are that runtime checks of database consistency
and connectivity are performed between the BSC and RXCDR to ensure that traffic pathways are
properly configured and that every E1 link to an RXCDR device, at the BSC has a corresponding
link configured at the appropriate RXCDR. Operators are notified of any failure of these
connectivity checks so that they can take the appropriate action.
In the event of a verification failure, the BSS automatically disables the relevant CIC devices
to ensure that they are not used.
3-50 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation CIC blocking
CIC blocking
To ensure that the BSS Software is always using valid traffic circuit identity codes (CIC) to carry
calls, the BSS Software blocks any CIC at the BSC which cannot be verified to be in good
working order and notifies the MSC that the CIC should not be selected.
When using remote transcoding, the only way to determine if a CIC is in good working order
is to actually attempt to communicate with the RXCDR. If nothing is wrong at the RXCDR
which would affect the CIC, the BSC will allow the CIC to remain in operation provided no
other blocking condition exists. If the RXCDR indicates that something has gone wrong, the
BSC will block the CIC from use.
If the BSC cannot communicate with the RXCDR, the BSC has no way to determine the validity
of any CIC connected through that particular RXCDR. If this is the case, the BSC will block all
the CICs connected to that RXCDR to ensure no phone calls use possibly corrupt CICs.
The blocking of CICs due to RXCDR or BSC communication failure only occurs provided the
operator has enabled the CIC validation option.
Link control
Previously control links that originated at the BSC and routed through the RXCDR remained
in-service even though the RXCDR E1 link was locked in use.
With the introduction of a more robust (enhanced) link, the RXCDR software now informs the
BSC that a E1 device, through which a control link is routed, has been taken out-of-service.
The BSC then removes the related control link from service.
For details of the new states of the OML, MTL, CBL managed devices and the new states of
the RXCDR MMS through which the control links are nailed, see the Maintenance Information:
Device State Transition (68P02901W57) manual.
BSC or RXCDR validation
The connectivity information between a BSC and an RXCDR is stored in the BSS and RXCDR
databases. This connectivity information can be entered incorrectly. In order to ensure
the validity of the connectivity information at each NE, the BSS Software will validate the
information when the XBL link set comes in-service. The BSS Software will take the appropriate
action to notify the operator if inconsistent connectivity information is discovered.
CIC validation support
When the first XBL comes into service an RXCDR, CIC validation support is enabled if the XBL is
an enhanced type (provided CIC validation is enabled at the BSC for that RXCDR). If the BSC
determines that an RXCDR does not support CIC validation an alarm will be raised.
The BSS software enables the operator to control whether CIC validation is enabled or disabled
at the BSC on a per RXCDR basis.
When the first XBL at a BSC to an RXCDR comes into service, the BSC initiates the procedure
to validate E1 connectivity information provided CIC validation is enabled at the BSC.
68P02901W36-S 3-51
Jul 2008
DARBC deliverable validation requirements Chapter 3: BSS Links
If the RXCDR fails to respond to 3 attempts by the BSC to participate in the CIC validation
procedure, the BSC triggers an alarm at the OMC-R and blocks all CICs associated with that
RXCDR with the reason BSC Detecting CIC Validation Failure. The RXCDR triggers an alarm
RXCDR Detecting CIC Validation Failure.
DARBC deliverable validation requirements
DARBC deliverable validation is at the following three levels:
Level 1: E1 validation
E1 connectivity validation is considered successful when the following conditions are satisfied:
An Associated BSS (ABSS) is configured at the RXCDR with an identifier matching that at
the BSS network entity to which it is connected.
An Associated Transcoder (AXCDR) is configured at the BSS with an identifier matching

that at the RXCDR network entity to which it is connected.
For every AXCDR connectivity entry at the BSS, there is a corresponding entry for the
ABSS device at the RXCDR, that is, the E1 identifiers match in the RXCDR and BSS
connectivity tables).
In order to increase connectivity capacity without causing the validation procedure to

fail, the operator should add connectivity entries at the RXCDR first and then add the
corresponding connectivity entries at the BSS.
In order to decrease connectivity capacity without causing the validation procedure to

fail, the operator should delete connectivity entries at the BSS first and then delete the
corresponding connectivity entries at the RXCDR.
If the above ordering is not followed, blocking of all CICs in the BSS Database associated
with the particular E1 link will occur.
Level 2: General CIC validation
For every validated E1 connection, the BSC and RXCDR validate CIC-related data and
connectivity for every CIC in the BSC database that is associated with the E1 link.
Validation of CIC-related data and connectivity is considered successful if the quarter timeslot
associated with the CIC in the BSC database is connected to a TRAU resource in the RXCDR.
Successful validation of CIC-related data and connectivity result in the CIC being, or remaining,
unblocked provided all other criteria for unblocking the CIC are satisfied, for example state of
associated devices.
Failure to successfully validate CIC-related data and connectivity results in blocking of the CIC.
The operator can be informed about the blocking of the CIC through existing CIC blocked
alarms. This depends upon the value of an operator configurable threshold in the database and
the total number of CICs blocked.
3-52 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Invalid BSC or RXCDR configurations
Level 3: CIC and RXCDR channel provisioning validation
When the operator provisions a new CIC in the BSC database and CIC validation is enabled
for the particular RXCDR, the BSS Software takes the necessary precautions before allowing
the CIC to be available for use, as follows:
When a traffic circuit (CIC) is provisioned in the BSC and the XBL linkset to the RXCDR
is not in-service, the BSC blocks the CIC.
When a traffic circuit (CIC) is provisioned in the BSC and the XBL linkset to the RXCDR is
in-service, the BSC blocks the CIC, unless the quarter timeslot associated with the CIC in
the BSC database is connected to a TRAU resource in the RXCDR. However, when a traffic
channel is provisioned in the RXCDR and the XBL linkset to the BSC is in-service and the
quarter-timeslot of the BSC-RXCDR interface is associated to a CIC in the BSC database,
the BSC unblocks the CIC, provided all other criteria for unblocking the CIC are satisfied
(for example, state of associated devices).
Blocking of the CIC can be avoided if the CIC is provisioned in the BSC after the channel is
provisioned in the RXCDR. If this order is not followed, it will cause the CIC to be blocked.
When a traffic circuit (CIC) is unprovisioned in the RXCDR and the XBL linkset to the
RXCDR is in-service and the quarter timeslot of the BSC-RXCDR interface is associated to
a CIC in the BSC database, the BSC blocks the CIC.
Blocking of the CIC can be avoided if the CIC is unprovisioned in the BSC before the
channel is unprovisioned in the RXCDR.
Invalid BSC or RXCDR configurations
If the operator has cross-connected E1 links, the BSC or RXCDR configuration cannot be
validated by the BSS software and the operator will be warned of this proviso.
For example, if the operator were to physically connect BSC MMS 0 0 to RXCDR MMS 1 0 and
BSC MMS 1 0 to RXCDR MMS 0 0 and the Connectivity Table at both the BSC and RXCDR
has BSC MMS 0 0 connected to RXCDR MMS 0 0 and BSC MMS 1 0 connected to RXCDR
MMS 1 0, the BSS software would not be able to detect this invalid configuration. Due to this
configuration calls can not have audio, crosstalk between calls can occur and the wrong traffic
circuits (CICs) are blocked if a failure happens at the RXCDR.
Call downgrade on CIC capability mismatch
The call downgrade facility effectively extends the level 2 validation functionality to include the
exchange of Codec capabilities for the associated CICs. Where validation is not available, for
example CIC validation at RXCDR disabled, a default FR or EFR capability is assumed.
XCDR and GDP
With the introduction of Enhanced Full-Rate (EFR) speech a new transcoding

device, the Generic DSP Processor board (GDP), was introduced into GSM BSSs
and RXCDRs. The previous transcoder, the XCDR, is not re-programmable
and is resource limited, in that it cannot support services other than Full-Rate
speech (3GPP defined Speech Version 1) and 3GPP Phase 2 Data Services.
68P02901W36-S 3-53
Jul 2008
BSC or RXCDR operator interface verification Chapter 3: BSS Links
The system verification to support a mixture of XCDR and GDP platforms requires an Enhanced
XBL link between the RXCDR and BSC which has subsequently become available. Operators
wishing to provide EFR (3GPP defined Speech Version 2 do not necessarily swap out all of their
existing XCDR capacity for GDPs. It is therefore possible for XCDRs and GDPs to co-exist
within the same transcoding site.
This co-existence of the XCDR and GDP necessitated pooled transcoding resources within the
BSS: Full-Rate (FR) capable CICs terminating on XCDR boards and FR and EFR capable CICs
terminating on GDP boards, both types supporting existing GSM data services.
The pooling concept is supported by Mobile Switching Center (MSC) manufacturers, offering
partial support of the 3GPP defined Circuit Pooling, whereby the operator is able to manually
group CICs into pools capable of particular transcoding types. FR only and EFR or FR support
are examples of particular interest. Without full Circuit Pooling support in the MSC, there is no
support in the Motorola BSS. The system does not perform cross verification between the MSC
and the BSS and EFR calls can be routed to XCDR cards, resulting in no speech.
Call downgrade on CIC capability mismatch prevents this problem, as follows:
Multi-platform Support: Support of transcoding platforms with different capabilities within the
BSS, that is to allow the XCDR and GDP boards to co-exist within the same BSC (in the case of
local transcoding) or RXCDR (in the case of remote transcoding).
Enhanced CIC Management: Detection of CIC speech version capabilities by the BSS
based on the supporting transcoding platform.
Enhanced Call Management: Validation of MSC Call Setup, In-call modification and
Handover requests to ensure that the speech version(s) included are supported by the
specified CIC.
BSC or RXCDR operator interface verification
CIC connectivity verification
The BSS Software rejects any attempt to add a CIC device if the MMS specified is not in the
BSC to RXCDR Connectivity Table. The CIC device can only be equipped if the MMS device
on which it resides has already been entered into the BSS CM database; this rule does not
apply for local transcoding BSCs.
BSC connectivity verification
The BSS Software rejects any attempt to add RXCDR connectivity if the AXCDR device specified
in the request does not exist in the BSS database.
The BSS Software rejects any attempt to modify the AXCDR device in an entry of the BSC to
RXCDR Connectivity Table if the new AXCDR device specified does not exist in the BSS database.
The BSS Software rejects any attempt to delete an entry from the BSC to RXCDR Connectivity
Table if there are CICs or XBLs equipped on the MMS specified in the delete command.
The BSS Software rejects any attempt to remove an AXCDR device from the BSS database if
specifically referenced in the BSC to RXCDR Connectivity Table.
3-54 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BSC or RXCDR operator interface verification
RXCDR connectivity verification
The RXCDR rejects any attempt to add BSC connectivity if the ABSS device specified in the
request does not exist in the BSS database.
The RXCDR rejects any attempt to modify the ABSS device in an entry of the RXCDR to BSC
Connectivity Table if the new ABSS device specified does not exist in the BSS database.
The RXCDR rejects any attempt to delete an entry from the RXCDR to BSC Connectivity Table if
there are XBLs equipped on the MMS specified in the delete command.
The RXCDR rejects any attempt to remove an ABSS device from the BSS database if the ABSS
device is specifically referenced in the RXCDR to BSC Connectivity Table.
BSS or RXCDR connectivity verification
The BSS Software rejects any attempt to remove an MSI device from the BSS database if the
MSI device is specifically referenced in the BSS to XCDR Connectivity Table.
XBL verification
The BSS Software rejects any attempt to provision an XBL device at the BSC if the MMS
identifier specified is not in the BSC to RXCDR Connectivity Table.
The BSS Software rejects any attempt to provision an XBL device at the RXCDR if the MMS
identifier specified is not in the RXCDR to BSC Connectivity Table.
The BSS Software rejects an attempt to provision an XBL device if the first identifier of the XBL
device does not match the AXCDR or ABSS device specified in the BSS-RXCDR Connectivity
Table for the XBL MMS.
When the BSS to RXCDR connectivity table is not specified correctly for the XBL MMSs at
both the RXCDR and the BSC, the BSS software transitions the XBL device to an appropriate
reason code as follows:
Remote MMS ID mismatch
Local MMS ID mismatch
Remote NE ID mismatch
Local NE ID mismatch
NOTE
Before the robust link was implemented, if the BSS to RXCDR connectivity table
was incorrectly specified, the BSC transitioned the XBL device to a DU state with
the reason Bad connectivity.
68P02901W36-S 3-55
Jul 2008
Equipping and unequipping an XBL Chapter 3: BSS Links
Equipping and unequipping an XBL
The following MMI commands are used to equip and unequip an XBL and are followed by the
equip (Specify an XBL in a network from the OMC-R Navigation Tree).
unequip (Delete an XBL from a network at the OMC-R Navigation Tree).
Determines whether the XBL operates at 16 kbps or 64 kbps. It is possible to equip up to eight
64 kbps RSL devices to a BSU-BTS, M-Cell 2 BTS, M-Cell 6 BTS, or M-Cellmicro. The BSC can
support a mix of 64 kbps and 16 kbps RSL devices.
To implement standard XBL functionality, in a configuration where one RXCDR is connected

to one or more BSCs, each BSC connected to that RXCDR must be given a unique number.
This can be any number, but must be unique. A table must be added to the RXCDR database
that specifies for each BSC bound RXCDR MMS, exactly to which BSC and to which MMS at
that BSC it is connected.
Monitoring an XBL
The following MMI commands are used to monitor an XBL and are followed by the equivalent
OMC-R facility:
disp_mms_ts_usage - Displays the XBL device data rate. If the data rate of the XBL
device is 16 kbps then the 16 kbps subtimeslot (group) of the 64 kbps E1 timeslot on
which the XBL resides on is also displayed.
disp_options - Includes the 16 kbps XBL device.
state - A Busy-Unlocked XBL will have reason 16 kbps Link or 64 kbps Link, depending on
whether the XBL is operating at 16 kbps or 64 kbps, respectively.
Locking and unlocking XBL
The following MMI commands are used to lock and unlock an XBL and are followed by the
lock (Specify an XBL in a network from the OMC-R Navigation Tree).
shutdown (Delete an XBL from a network at the OMC-R Navigation Tree).
unlock (Specify an XBL in a network from the OMC-R Navigation Tree).
The remote site goes out-of-service when the last XBL to the site is locked.
3-56 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation XBL alarms
When 16 kbps XBL devices are taken out-of-service, the capacity load on each E1 link increases.
XBL alarms
XBL alarms are described in full in Maintenance Information: Alarm Handling at the OMC-R
(68P02901W26) manual.
Alarms requirements
BSC detecting CIC validation failure
The BSC Detecting CIC validation failure alarm is generated when the RXCDR fails to respond
to repeated attempts by the BSC to initiate the CIC validation procedure. The alarm is raised
against the specific AXCDR device in the BSC database, which failed to respond.
Customer Alarm Code: AXCDR F_RXCDR_VALIDATION_FAIL
BSC detecting BSC or RXCDR CIC database mismatch
The BSC Detecting BSC or RXCDR CIC Database Mismatch alarm is generated when the
cic_validation parameter is enabled for a particular AXCDR device and a database mismatch
between the BSC and RXCDR is detected. The alarm is raised against the BSC MMS device on
which the mismatched CIC is equipped. One MMS alarm is raised to contain all mismatched
CICs for that MMS.
Customer Alarm Code: MMS F_RXCDR_VALIDATION_MISMATCH
Renamed commands
The following MMI commands have been renamed:

add_bss_conn to add_conn
mod_bss_conn to mod_conn
del_bss_conn to del_conn
disp_bss_conn to disp_conn
68P02901W36-S 3-57
Jul 2008
Related commands and parameters Chapter 3: BSS Links
Commands
add_conn - Adds MMS connectivity between the RXCDR and the BSS.
mod_conn - Modifies MMS activity. This command supports moving connectivity from
one MMS at a BSC and an MMS at an RXCDR to another MMS at a BSC at the same
MMS at the RXCDR.
del_conn - Deletes a particular MMS connectivity between the RXCDR and the BSS.
disp_conn - Displays the connectivity between the BSC and the MSC.
Parameters
The enhanced XBL function introduces two new device parameters for use with the device
commands:
ABSS
AXCDR
3-58 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation E1 link management
E1 link management

E1 link management function
Management of transmission links between network entities is required at all Network Element
sites to maintain link quality.
For site synchronization each site has two Generic Clock (GCLK) modules. All terrestrial circuits
interface to a site on standard E1 PCM links and the GCLK derives its reference from these links
or, in case of reference failure, can free run. The GCLK enables the site to synchronize to the E1
links so that frame and multiframe alignment is more stable.
Synchronization alarm thresholds
Synchronization loss thresholds can be set on both an hourly and daily basis so that when these
thresholds are reached, an alarm message is generated by the MSI or XCDR board to the FM.
Both of these periods are chronological, that is, if an alarm condition has been reached in the
first 10 minutes of an hour, that alarm is then locked out until the next chronological hour begins.
The parameter sync_loss_oos provides an upper limit of synchronization loss alarms; on reading
this threshold, the XCDR or MSI notifies the FM which in turn takes the MMS out-of-service.
This threshold works on a daily basis.
If an MMS has been taken out-of-service as a result of reaching the sync_loss_oos threshold, the
FM does not put it back in service until the sync_loss_restore time has expired. For this timer to
activate, no synchronization loss alarms must occur; a single synchronization alarm will reset it.
Remote loss alarms flag
The MSI or XCDR is able to track synchronization alarms from its own transmit by receipt of the
Remote flag from the distant end.
This flag allows the monitoring of restore synchronization losses in much the same way as the
synchronization loss parameters.
Slip loss alarms
The MSI or XCDR contains an elastic 2-frame buffer to account for slip loss; if this loss exceeds
the size of the buffer, or leaves the buffer empty, requiring a frame to be repeated, a TDM frame
is lost as the buffer resets. Each time the buffer resets, a slip loss alarm is generated. Each slip
loss alarm is counted and subject to thresholds similar to those mentioned above.
68P02901W36-S 3-59
Jul 2008
Bit error rate monitoring Chapter 3: BSS Links
Bit error rate monitoring
The MSI or XCDR board monitors the bit error rate (BER) of the incoming E1 link. The BER
can be determined using the fixed bits of the Frame Alignment word and Frame Data Word.
These bits do not alter and are therefore ideal to calculate BER.
The ber_oos_mon_period is the period that an in-service MMS must exceed the set BER,
ber_loss_hourly or ber_loss_daily, before it is taken out-of-service. If the rate is exceeded
in this period, notification is sent to FM which in turn takes the MMS out-of-service.
The ber_restore_mon_period is the amount of time an out-of-service MMS must be better

than the set BER before it can be put back in service.
Both these monitoring periods can be set in database using the modify_value command. The
location for both of these periods can be set individually for each site, but is usually set to
all to include every site in the BSS.
An alarm will be generated when the daily and hourly thresholds for BER are exceeded.
N Bit
It is possible to set an extra remote alarm bit, the N bit; bit 4 of the frame data word is used
for this purpose. The actual use of this bit is specified by the customer but the bit must be
enabled using the modify_value command. This bit can be enabled for all sites using the all
location index.
Related command and parameters
The following parameters exist for use with the chg_element command:
Synchronization alarm monitoring
sync_time_oos - Field indicates the permitted time that the receive leg of the E1 link can
have a prolonged synchronization alarm. When this time is exceeded, the MSI or XCDR
board informs the FM. The FM initiates the MMS into a state of unlocked or disabled.
sync_time_restore - Field indicates the length of time that the receive leg of a E1 link
must maintain synchronization before the MSI or XCDR board informs the FM. The FM
activates the MMS to a state of unlocked or enabled.
remote_time_oos - Immediately a synchronization alarm occurs on the receive leg of a E1

link, the MSI or XCDR board sets the remote alarm flag (timeslot 0) on the transmit leg.
At the distant end, on receipt of this alarm condition, the remote timer starts. If no clear
indication is received before the remote_time_oos expires then the MSI or XCDR informs
the FM. The FM initiates a state of unlocked or disabled for the MMS.
3-60 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Related command and parameters
remote_time_restore - Field sets the time that a remote alarm flag must be in a clear
condition before the MSI or XCDR notifies the FM. The FM activates the MMS to a state of
unlock or enabled.
sync_loss_daily - Specifies the threshold for the synchronization loss daily alarm level
count.
sync_loss_hourly - Specifies the threshold for the synchronization loss hourly alarm
level count.
sync_loss_oos - Specifies the threshold for the synchronization loss, out-of-service daily
alarm level count.
sync_loss_restore - Specifies the synchronization loss restorable time period for a

sync_loss_oos_alarm.
Bit Error Rate (BER) alarm monitoring
ber_loss_daily - Specifies the daily BER alarm threshold.
ber_loss_hourly - Specifies the hourly BER alarm threshold.
Remote alarm monitoring
remote_loss_daily - Specifies the threshold for the daily count of remote alarms.
remote_loss_hourly - Specifies the threshold for the hourly count of remote alarms.
remote_loss_oos - Specifies the out-of-service threshold for the remote alarm.
remote_loss_restore - Specifies the wait time for restoring the 2 Mbps circuit to service.
Slip loss alarm monitoring
slip_loss_daily - Specifies the threshold for the frame slip daily alarm count.
slip_loss_hourly - Specifies the threshold for the frame slip hourly alarm count.
slip_loss_oos - Specifies the threshold for the frame slip out-of-service alarm level count.
slip_loss_restore - Specifies the frame slip restorable time period.
The following bit error rate parameters exist for use with the modify_value command:
ber_oos_mon_period - Specifies the length of time that an in-service MMS must be above
a specified BER before it is taken out-of-service.
ber_restore_mon_period - Specifies the length of time that an in-service MMS must be

above a specified BER before it is taken out-of-service.
68P02901W36-S 3-61
Jul 2008
Aggregate Abis Chapter 3: BSS Links
Aggregate Abis

Aggregate Abis function
Aggregate Abis allows reduction of the E1 links required to provide interconnection between
network entities such as BSCs and BTSs. This is achieved by providing support for third-party
switching equipment (a direct connection or a network service) between a BSC and BTSs.
The Aggregate Abis function also adds flexibility in the allocation of E1 timeslots at the BSC and
BTSs to support the use of a switching network to groom the timeslots from several low-capacity
BTSs onto a single E1 link to the BSC.
Aggregate Abis is a restricted option that the operator can enable on each BSS.
Equipping and unequipping an aggregate Abis site
A switching network can now be specified within the equipage of a PATH device.
equip (Specify a PATH in a network from the OMC-R Navigation Tree).
unequip (Delete a PATH from a network at the OMC-R Navigation Tree).
The Aggregate Abis algorithm allocates timeslots sequentially as devices are equipped. The
timeslots which are allocated are dependent on the order in which the affected device PATHs
are equipped. Only RSL and RTF device timeslot allocations are affected by Aggregate Abis.
Changing a site to aggregate Abis
The timeslot allocation algorithm used in E1 links, connected to a switching network, can be
selected using the ts_alloc_flag parameter in the chg_element command. It selects either the
current algorithm or the Aggregate Abis algorithm. The ts_alloc_flag parameter is available
on a per site basis. Therefore, a different timeslot allocation algorithm can be used upstream
and downstream for the switching network.
Monitoring aggregate Abis at a site
In the following list the MMI command is listed followed by the equivalent OMC-R facility.
disp_element - Displays the status of software and hardware information including whether a
switching network is in use.
3-62 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Setting up the PCU (GPRS) links
Setting up the PCU (GPRS) links

The GBL interface (frame relay permanent virtual connection)
At the GBL interface, the transmit and receive buffers and timer resources in the PICP, are
initialized for layer 2 buffering of uplink and downlink data on the Gb interface. The sizes
of these buffers will be calculated by the frame relay functional unit based on the data
rate, the CIR, the size of the maximum frame size and the amount of injection management
queues required. The maximum size of the frame relay information field on the Gb interface
is 1600 octets. The addressing information in the frame relay functional unit has only local
significance. A local DLCI mapping on both ends (BSS and SGSN), together with the routing
path, constitutes a frame relay Permanent Virtual Connection (PVC). Since frame relay is a
permanent connection-oriented protocol: a static connection between a BSS and an SGSN is
established at the time of system initialization of the BSS. Each PSST is able to connect to only
one SGSN at a time. The frame relay functional unit at the BSS, attempts to set up one DLCI per
PVC configured towards the SGSN over a single bearer channel. This PVC is mapped to the
local DLCI 0, on both ends and is used for signaling. The first frame sent to the SGSN consists
of the message type call establishment. The SGSN responds with an acknowledgment (ack)
upon receipt of the call establishment message. The BSS frame relay functional unit then
synchronizes up to the maximum of 318 DLCIs. The total number of PVCs at system initialization
is configurable. The frame relay functional unit notifies the GBM that the Gb link is in service.
GSL state change
When a GSL comes into service or goes out-of-service, the PCU updates its tables. The tables
provide information on the current GSLs available. Whenever a GSL goes out-of-service an alarm
is reported. When the last GSL goes out-of-service the BSC generates a last GSL failed alarm
against the PCU. The PCU initiates clean up procedures and initiates a link disconnect at the
GB. The BSC declares the PCU disabled. The BSC and PCU then initiate GSL resynchronization
procedures on both sides to start up the link. If resynchronization procedures are unsuccessful,
within an internal LAPD time period, the PCU is disabled and GPRS resources (air timeslots and
switchable terrestrial backing) are made available for circuit switch use.
All messages going over the GSL contain a message header of the type used by the GPROC Exec.
Carrier state change
When a GPRS carrier goes out-of-service, the respective packet scheduler receives a carrier
state change message from the CRM. The PSP notifies the SGSN of the unavailability of GPRS
for a cell through the GBM. For a cell using a PBCCH, new system information cannot be
sent. For a cell using a BCCH, new system Information is sent through the CRM if the GPRS
carrier is not the BCCH carrier.
68P02901W36-S 3-63
Jul 2008
Timeslot state change Chapter 3: BSS Links
Timeslot state change
If a timeslot goes out-of-service, the packet scheduler receives a Timeslot State Change-OOS
message from the CRM. The respective packet scheduler responds with an acknowledgment
of receipt of the message and does not allocate the specified timeslot if the timeslot goes
out-of-service. If the timeslot going out-of-service is the PBCCH, the GBM blocks the BVC
with the SGSN and CRM is informed GPRS is unavailable. New system Information over the
BCCH is generated.
Carrier in service at initial configuration
At startup of the BSC, all GPRS timeslots are configured with the RSS and the channel coders to
PDCHs. Once the timeslots are configured, they are activated with RSS and channel coders.
The PCU requests radio timeslots set up to the appropriate MMS timeslot over the BSC-PCU
interface, known as the GPRS Data Stream (GDS) interface.
Once the connections are set up, the PRP initiates synchronization procedures with the channel
coders. At cell, carrier and timeslot in service, in a PBCCH configuration, the PBCCH system
information is sent over the PBCCH to gradually unbar the cell. In a CCCH configuration,
the normal site initialization occurs at the CRM with the help of the PRP and BCCH system
information is sent over the BCCH to gradually unbar the cell, indicating GPRS is available.
MSs are now able to access the cell through the RACH in a CCCH configuration or PRACH
in a PCCCH configuration.
If synchronization with the CCU fails, the PCU initiates procedures for resynchronization. If the
CCU detects the timeslot is out-of-service, it generates an alarm and initiates time alignment
procedures indefinitely. If the CCU loses synchronization for a PBCCH timeslot residing on a
non-BCCH carrier, the CCU key down on the transmitter. If the PBCCH were on a BCCH carrier,
the CCU transmits NULL RLC frames.
3-64 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation PCU to BTS interface (modified for EGPRS)
PCU to BTS interface (modified for EGPRS)

The PCU to BTS interface is modified extensively to support EGPRS. The higher bandwidth
afforded by EGPRS requires additional throughput than can be provided by 32 kbps GPRS
TRAU-like channels. As a result, a new type of GPRS TRAU-like channel is introduced, namely
64 kbps GPRS TRAU, which allows the PCU and BTS to communicate on a per-timeslot basis
with a DS0 (integral E1 timeslot). To enable this new GPRS TRAU-like channel it is necessary
to modify the frame structure on the link and also the synchronization procedure between
the channel coder in the BTS and the PCU.
In order to fit the MCS9 data blocks into 64 k channels it is necessary to reduce the framing
information contained in the frames. This will result in a higher number of frames with bit
errors going undetected on the PCU CCU interface. The data on the RLC or MAC layer is
integrity protected as are the upper layers, so the frames containing bit errors will be detected
and handled at the upper layers.
Since the GPRS TRAU-like channels are synchronously serial in nature, lost frames can easily
be detected. When missing frames are detected by either the channel coder in the BTS or
the NIB PMC module in the PCU not detecting the synchronization header, the receiver will
compensate for the missing frame.
When a frame has been detected with known bit errors (due to the framing bits present) the
receiver of the frame is responsible for updating the block-to-block information, (such as uplink
block number and AFN).
68P02901W36-S 3-65
Jul 2008
GPRS Gb interface to Air interface Mapping Chapter 3: BSS Links
GPRS Gb interface to Air interface Mapping

GPRS Gb signaling messages
The following are the signaling messages associated with the user data transfer over the Gb
interface between the SGSN and the PCU and the air interface at the BSS.
BVC and MS flow control mechanism.
Gb paging.
Gb paging over PCCCH and PACCH.
Gb paging over CCCH for a single cell.
Gb flush PDUs.
Gb BVC block or unblock.
Status.
Radio.
Gb.
BVC and MS flow control mechanism
The BSS complies with the flow control mechanism detailed in specification 3GPP TS 08.18.
In line with that specification, the primary responsibility to implement the flow control
algorithm lies with the SGSN. The BSS, however, aides the SGSN in implementing this
algorithm by providing operational values for correct runtime behavior by the SGSN. These
values are exchanged between the BSS and the SGSN through FLOW-CONTROL-BVC and the
FLOW-CONTROL-MS messages, as detailed in Specification 3GPP TS 08.18.
For detailed information on implementation of commands and parameters described in the

following text refer to Technical Description: BSS Command Reference (68P02901W23) manual.
Flow control messaging frequency
The BSS complies with the requirements in specification 08.18 for frequency of sending
flow control messages towards the SGSN. This mechanism avoids overwhelming SGSN with
flow control messages. As stated in 08.18, the timer is set through BSS database element
bssgp_fc_period_c. The default value of this element (C) is 1 second and it has a range
of 1-10 seconds.
The BSS utilizes this value to space out the flow control messages for a given cell or MS by at
least this much time. Each cell and MS has an individual C frequency timer that is independent
of the other.
3-66 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BVC and MS flow control mechanism
BVC flow control
An initial cell flow control message is sent out to the SGSN for each cell that is brought
in-service (INS) for GPRS on the BSS. All cell flow control messages have the following
information elements, as in specification 08.18:
BVC (cell) bucket size - This is the internal BSS buffer for each cell.
BVC bucket leak rate - This is the effective rate with which data flows out of the cell's buffer.
Bmax default MS - This element is derived from the cell-based database element on the
BSS, that is max_ms_dl_buffer - The default for this element is 38400 bytes and it ranges
from 5120-64000 bytes.
R_default_MS - This element is derived from the cell-based database element on the BSS
that is max_ms_dl_rate - The units for this element in the database are 100 bps (that is
100's of bits-per-second). The default for this element is 900 100-bits-per-second and
it ranges from 1-900 100-bits-per-second.
Cell flow control is always enabled in the BSS. For each incoming DL-UNITDATA PDU from
the SGSN, the BSS ensures that internal cell buffer (or bucket) does not overflow. After a
brief residency in the cell's buffer, data flows out towards the MS over the RF interface in
FIFO (first-in-first-out) order. Simultaneously, the BSS also monitors outgoing data to compute
effective buffer leak rate for each cell. After the initial cell flow control message, another
one is sent out by the BSS if any of the following conditions are met (and subject to the C
timer limitations, as in 08.18):
Computed leak rate is different from the previous reported one to the SGSN. For
example, if a cell's capability increases or decreases due to timeslot coming into or going
out-of-service, or even if the coding schemes for MSs within the cell change, affecting
the overall throughput of the cell.
Cell's current upper buffer level is exceeded or overflows at the BSS.
Cell flow control message acknowledgment timer expires in the BSS (that is if the SGSN
does not acknowledge the FLOW-CONTROL-BVC message within a reasonable time and
the conditions mentioned above are still met).
MS flow control
The MS flow control mechanism is also enabled in the BSS, by default. However, it may be
changed using the BSS database element _bss_data [0]. A value of 0 for this element enables
MS flow control, while a value of 1 disables MS flow control mechanism for all the MSs within
the BSS.
An MS's default buffer size and leak rate are governed by the database elements
max_ms_dl_buffer and max_ms_dl_rate in the same way as for BVC flow control.
Similar to the cell flow control mechanism, the BSS monitors the incoming DL-UNITDATA PDUs
from the SGSN to determine the overflow of individual MS buffers. The BSS also computes the
effective rate at which data is flowing out towards the MS over the RF interface. The BSS
may choose to adjust these values for the SGSN's flow control algorithm by sending out a
FLOW-CONTROL-MS message. Flow control messages for each MS are also subject to the C
frequency timer requirements and are sent out only if any of the following conditions are met:
Computed leak rate is different from the previous reported one to the SGSN. For example,
if an MS's capability increases or decreases due to re-scheduling over the RF interface or if
the coding scheme changes, affecting the overall capability of the MS.
68P02901W36-S 3-67
Jul 2008
Gb paging over the PCCCH Chapter 3: BSS Links
MS's current upper buffer (or bucket) level is exceeded or overflows at the BSS.
MS flow control message acknowledgment timer expires in the BSS (that is if the SGSN
does not acknowledge the FLOW-CONTROL-MS message within a reasonable time and the
conditions mentioned above are still met).
Interaction between MS and BVC flow control
Both these mechanisms share the same algorithm but do not govern each other's values.
The default values, max_ms_dl_buffer and max_ms_dl_rate are however common as they
are mentioned in all the FLOW-CONTROL-BVC messages and also act as initial values for
an individual MS's buffer.
All incoming DL-UNITDATA PDUs are subject to both BVC and MS flow control. Therefore, a
particular PDU can only be accepted as buffered within the BSS if it does not overflow either of
the cell and the MS buffers. Conversely, a DL-UNITDATA PDU may be discarded by cell flow
control rules even if it fulfills the MS flow control criteria.
Data level correction
As stated in specification 08.18, messages are utilized to adjust current buffer levels in the
SGSN should the BSS choose to discard data due to overflow or cell reselection or other
abnormal conditions.
GSM reference
3GPP Technical Specification 101 343.
Gb paging over the PCCCH
This message is handled by the Gb Functional Unit and forwarded to the appropriate cell to
the Paging air interface functional unit residing at a PRP. The paging functional unit at the
PRP computes the paging population information and the paging group to which the Paging
Request message is forwarded to the MS.
Gb paging over the CCCH for a single cell
For CCCH configurations, this message can be handled by the Gb functional unit and the Paging
Functional unit and forwarded to the RRSM for a single page for the appropriate cell. The RSS
Layer 1 computes the paging population information and the paging group to which the Paging
Request message is forwarded to the MS.
To control the significant amount of pages that can occur over the LAN when a page all cells
message from the SGSN is received, the Gb functional unit informs the Paging functional unit.
The Paging functional unit informs the existing SCCP pre-processors on existing LCFs. Each
SCCP pre-processor then generates the number of pages required for the number of cells
under all the BTSs under the control of the specific LCF. The single notification to the SCCP
pre-processor prevents the LAN from congestion.
3-68 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Gb flush PDUs
Gb flush PDUs
At receipt of the Flush PDUs message from the SGSN any context (and data) for the mobile
will be deleted. This message is handled by the GB FU and forwarded to the respective packet
scheduler.
GSM reference
Radio status
In the case such that any air interface procedure fails for a specified MS, the BSS generates
a Radio Status message to the SGSN and discards the MS packets. This message includes a
TLLI and radio cause.
This message is handled by the packet scheduler at detection of any abnormal or error scenario.
It notifies the GB FU, which forwards the Radio Status to the SGSN for the specified MS.
GSM reference
Gb status
At receipt of any erroneous messages or elements from the SGSN, the GB FU generates the
Status message accordingly. Alternatively, the GB FU handles any Status messages from the
SGSN and an alarm will be generated.
GSM reference
68P02901W36-S 3-69
Jul 2008
Gb link Chapter 3: BSS Links
Gb link

Gb Link function
The Gb Link (GBL) device refers to the configured number of timeslots on a E1 link between the
PCU and the SGSN. This interface is referred to as the Gb interface. One GBL is allowed per E1
link but the number of MMS timeslots allocated to the GBL is configurable.
The GBL may be multiplexed onto timeslots of the existing A interface. If timeslots on the
existing A interface are used, nailed connections are made through the BSC and on to the
RXCDR (if configured). Nailed connection of the GBL can be made at the RXCDR and this link
can then be extended to the SGSN.
{27955A} All message traffic is load shared across Network Service-Virtual Connections
(NS-VCs) mapped for a single cell across GBLs. If one NS-VC goes out-of-service, traffic is
redistributed to the remaining NS-VCs for that cell, provided the operator has defined additional
supporting Gb mapping.
Equipping and unequipping a GBL
The following MMI commands are used to equip and unequip a GBL and are followed by the
equip (specify a GBL in a PCU from the OMC-R navigation tree).
unequip (delete a GBL in a PCU from the OMC-R navigation tree).
Outside SYSGEN mode, the GBL must be locked before it can be unequipped. When a GBL is
unequipped, all Gb mapping related to that GBL are deleted with the exception of the BVCI
to cell mapping.
A maximum of 12 GBLs may be equipped at a PCU up to a maximum of 20 per BSS.
Taking GBLs in and out of service
The following MMI commands are used to take GBLs in and out-of-service and are followed
by the equivalent OMC-R facility:
lock (specify a GBL in a PCU from the OMC-R navigation tree).
unlock (specify a GBL in a PCU from the OMC-R navigation tree).
3-70 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GBL states and reason codes
During initialization, the GBL is put in the state Disabled-Unlocked with reason code: No
Reason. If the underlying MMS is out-of-service the GBL is put in the state Disabled-Unlocked
with reason code: MMS Not-in-Service. When the system detects that the MMS is again in
service the GBL state changes to Enabled-Unlocked with reason code: Wait. The GBL then
attempts to connect to the SGSN. If the GBL is unlocked, the GBL is put in a state such that
continual attempts are made to bring the link into service. As soon as connection is established,
the GBL transitions to the Busy-Unlocked state.
GBL states and reason codes
Valid GBL Out-Of-Service state reason codes are given in the Maintenance Information: Device
If a GBL is locked, message traffic is redistributed over the remaining NS-VCs mapped for a
single cell across all in service GBLs, providing the operator has defined additional supporting
Gb mappings. If the last NS-VC at the PCU is unavailable, GPRS service is lost for all cells
at that NS-VC.
When the GBL is locked, remaining packets of a packet flow transfer at the PCU may be lost.
Retransmission initiated by the LLC layer is initiated for the loss, providing the operator has
defined additional supporting Gb mapping. The PCU generates BCCH System information
indicating GPRS unavailability for all cells controlled by the locked GBL.
The device state for a GBL equipped outside SYSGEN mode is Disabled-Locked. The GBL
needs to be manually unlocked in order to come in service. All GBLs found equipped during
PCU initialization time are set to Disabled-Unlocked and an attempt is made to bring the GBL
into service.
When a GBL is unlocked, an attempt is made to bring the link into service. Message traffic is
load shared over NS-VCs for single cells across in-service GBLs.
The command ins_device for the GBL is equivalent to a lock and subsequent unlock of the GBL.
{27955A} The loss of in-service GBLs is a major event indicating a loss of capacity, and
throughput to the SGSN is reduced.
Resetting a GBL
Resetting a GBL (with the command reset_device) is equivalent to bringing a GBL device into
service on the link (ins_device command).
Monitoring GBLs
The state command and the disp_equipment command are both available for monitoring GBLs.
The latter displays the information entered during equipping of the GBL.
GBL alarms
The BSS device is reported for device-specific alarms. GBL alarms are described in full in
Maintenance Information: Alarm Handling at the OMC-R (68P02901W26) manual.
68P02901W36-S 3-71
Jul 2008
GBL alarms Chapter 3: BSS Links
The Link Disconnected alarm is supported for the GBL device.
The Last GBL failed alarm is reported against SITE.
3-72 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GPRS data stream
GPRS data stream

GPRS data stream function
The GPRS Data Stream (GDS) device can be equipped to carry either Transcoder Rate Adaption
Unit (TRAU) type traffic or Link Access Procedure D (LAPD) type signaling. The TRAU type GDS
device refers to the traffic route for carrying data between the BSC and the PCU. The LAPD type
GDS refers to the signaling route as defined by the GSLs equipped to the GDS. The connectivity
of the route is defined by the MMSs between the BSC MSI and the PCU MSI. {28351} When the
connectivity between the BSC and the PCU is Ethernet, the GDS type is LAPD_TRAU. {26740}
The Ethernet is provided by PSI (Packet Subrate Interface).
The GDS may or may not have associated GSLs. GDSs without associated GSLs are TRAU
GDSs and will never have associated GSLs. LAPD GDSs have GSLs and TRAU GDSs carry
GPRS data traffic. {28351} LAPD_TRAU GDSs can carry both GSL and TRAU traffic. GDSs
without associated GSLs use up to 31 TDM 64 kbps timeslots for carrying GPRS data. Up to 30
GSLs may be equipped on a GDS and each GSL requires one TDM 64 kbps timeslot for LAPD
signaling. All remaining TDM 64 kbps timeslots on the GDS are unused.
{28351} Each PCU supports a maximum of 38 E1 GDSs (two LAPD GDSs, 36 TRAU GDSs) and
12 Ethernet links (LAPD_TRAU GDS) or a combination of E1 and ETH links configured between
the PCU and the BSC. {26740} The GDS can be configured over the Ethernet as child device
of ETH. For this GDS configuration, the BSC GDS is introduced in pair with the PXP GDS.
The legacy GDS configuration (over E1) is still supported and unchanged. The BSC GDS is
automatically equipped when the PCU GDS is equipped on the PXP.
Equipping and unequipping a GDS
The following MMI commands are used to equip and unequip a GDS and are followed by the
equip (specify a GDS in a PCU from the OMC-R navigation tree).
unequip (delete a GDS in a PCU from the OMC-R navigation tree).
{22415} The BSC issues a warning regarding the total PRP timeslot resources available at
the PCU during a GDS unequipage.
The processing for a TRAU type GDS is handled by a PRP DPROC, as it terminates on an MSI on
a PRP DPROC.
68P02901W36-S 3-73
Jul 2008
Taking a GDS in and out of service Chapter 3: BSS Links
Equipage in sysgen mode
The BSS supports equipage of a GDS inside and outside of SYSGEN mode. Equipage of a GDS
prompts for TRAU or LAPD support and a GDS equipped on an MSI equipped to a PRP DPROC
can only support TRAU. Two TRAU GDSs can be equipped on an MSI (with the introduction
of EDGE both MMS devices on a PMC can be used for TRAU GDSs). A TRAU can only be
equipped on a PRP DPROC. {22415} When the connectivity is ETH, LAPD_TRAU GDS is
equipped automatically without any prompts.
The GDS device is equipped and managed only at the PCU. The device state for newly equipped
GDSs outside SYSGEN mode is Disabled-Locked. The GDS needs to be manually unlocked in
order to come into service. All GDSs found equipped during PCU initialization time have their
states set to Disabled-Unlocked and an attempt is made to bring them into service.
Unequipage in sysgen mode
The BSS supports unequipage of the GDS inside and outside of SYSGEN mode. The GDS can not
be unequipped until all its child devices are unequipped and can only be unequipped at the BSC.
Outside SYSGEN mode, the GDS must be locked at the BSC before it can be unequipped.
Default connectivity must be defined to allow the BSC to attempt initial connections to the PCU.
The default connectivity, which is not dependent upon equipage order, is defined as (slots
and sockets are set to 1):
Timeslot 1 of link 0 of a E1 PMC module in PMC socket 1 of a DPROC in slot 1
Timeslot 1 of link 0 of a E1 PMC module in PMC socket 1 of a DPROC in slot 2
Attempts to leave SYSGEN mode without a GDS with an associated GSL equipped to the default
pathway fail. If a PCU site is equipped outside SYSGEN mode without equipping default
connectivity, the PCU site fails to come in to service and no warning is generated. The following
is required to equip a GDS with an associated GSL to a default pathway:
A PICP DPROC must be equipped in either slot 1, slot 2 or slot 11.
A PCU MSI must be equipped in PMC socket 1 of one of the above PICP DPROCs.
A GDS must be equipped with the PCU termination on link 0 of the MMS for the above
PCU MSI.
A GSL must be equipped to the above GDS.
Taking a GDS in and out of service
The following MMI commands are used to take a GDS in and out-of-service and are followed
lock (specify a GDS in a PCU from the OMC-R navigation tree).
unlock (specify a GDS in a PCU from the OMC-R navigation tree).
Locking the GDS takes the GDS out-of-service and the E1 link is no longer used for carrying
terrestrial backing. Loss of a GDS reduces capacity to the PCU.
3-74 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Resetting a GDS
The BSS supports the lock, unlock and ins_device commands for the GDS device only at
the PCU.
Bringing the GDS device into service (ins_device command) for the GDS is equivalent to a
lock and unlock of the GDS.
Valid GDS Out-Of-Service state reason codes are given in the Maintenance Information: Device
Resetting a GDS
Resetting a GDS (with the command reset_device) is equivalent to bringing a GDS device into
service on the link (ins_device command).
Monitoring a GDS
The following MMI commands are used to monitor a GDS and are followed by the equivalent
OMC-R facility:
disp_equipment (Detailed view at the OMC-R)-displays the status of software and
hardware information.
state (detailed view at OMC-R)-displays the information entered during equipping the GDS.
The PCU GDS device state represents the combined states of its associated BSC MMS and PCU
MMS. The PCU GDS cannot be in service unless both its associated MMSs are in service. If
either MMS is out-of-service, the GDS state is Disabled-Unlocked with reason code: Parent
out-of-service. When both MMSs come back into service, the GDS also comes back into service.
68P02901W36-S 3-75
Jul 2008
GPRS Signaling Link (GSL) Chapter 3: BSS Links
GPRS Signaling Link (GSL)

GPRS signaling link function
The GPRS Signaling Link (GSL) is the signaling connection between the BSC and the PCU and is
also used for code loading the PCU. The GSL is equipped as a 64 k LAPD type signaling link on a
timeslot of the MMS device. {28351} The PCU can support a maximum of 60 GSLs.
NOTE
The PCU can be codeloaded either over legacy GSL, or over GbE link, depending on
boards configured in either slots 1, 2 or 11.
In order to support default connectivity, the first GSL equipped to a GDS uses timeslot 1 and the
subsequent GSLs equipped to that GDS use the next available timeslots on the MMS.
GPRS PCU recovery on last GSL failure
If all the GSL links were to go out-of-service, the PCU cannot perform its function and the
BSC cannot provide the packet data services. Because of this reason, whenever the GSL goes
out-of-service, the PCU resets itself to simplify the releasing and rebuilding of the resources
in the data services.
A problem with the previous design was that once the PCU reset itself, it took unnecessary
time to re-establish the link between the BSC and PCU and then to bring back the PCU into
service in order to process data calls again.
This function enhances the availability of the PCU by preventing the PCU from resetting upon
the last GSL disconnection and quickly brings it up in service again upon the GSL reconnection.
When the last GSL goes out-of-service, the system software in the PCU and BSC now manages
and reconfigures the network resources promptly, smoothly deallocating the resources for data
calls and reallocating them for voice calls.
This function also improves the problem analysis of the PCU because the processes on the
PCU stay up and continue to run during the last GSL allowing the operator to interrogate
the processes for problem analysis remotely.
3-76 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Equipping and Unequipping a GSL
Equipping and Unequipping a GSL
The following MMI commands are used to equip and unequip a GSL and are followed by the
equip (specify GSL in a PCU from the OMC-R navigation tree).
unequip (delete a GSL in a PCU from the OMC-R navigation tree).
An LCF is assigned to a GPROC as the system comes up, not statically (it is not in the db). The
equipping of a GSL to an LCF can be done automatically at SYSGEN time (no current db script
impact), or manually both at SYSGEN and post-SYSGEN, see also Equipping and unequipping
an LCF on page 3-81.
In order to enable OMC control of the PCU, the GSL is managed from the BSC side. The initial
state when equipping a GSL is Disabled-Locked on the BSC side and Disabled-Unlocked on
the PCU side.
The BSC side of a GSL has to be locked before it can be unequipped and the GSL can only be
unequipped from the BSC. If an attempt is made to lock the GSL at the PCU, the unequip
command will be blocked.
Taking a GSL in and out of service
The following MMI commands are used to take a GSL in and out-of-service and are followed
lock (specify GSL in a PCU from the OMC-R navigation tree).
unlock (specify GSL in a PCU from the OMC-R navigation tree).
All GSLs found equipped during BSC init time or PCU init time are set to Disabled-Unlocked and
an attempt is made to bring the GSLs in service, both at the BSC and at the PCU.
The last GSL can be only be locked on the BSC side, as remote access of the PCU would be
prevented if the last GSL could be locked at the PCU.
Locking a GSL terminates the LAPD protocol and transitions the GSL out-of-service. Either the
BSC or PCU GSL may be locked. Locking one side of the GSL causes the other side to go
out-of-service.
NOTE
If the GSL is unlocked and comes back in to service fast enough, the LAPD does not
time-out and does not cause the other side of the link to tear down.
A confirmation prompt is displayed for an attempt to lock a GSL at the PCU. Locking the GSL
causes the state to transition to Disabled-Locked. The GSL does not support the Enabled-Locked
state. Locking the last GSL causes the PCU to go out-of-service.
68P02901W36-S 3-77
Jul 2008
GSL states and reason codes Chapter 3: BSS Links
GSL states and reason codes
Valid GSL Out-Of-Service state reason codes are given in the Maintenance Information: Device
Unlock of the GSL attempts to re-establish the LAPD protocol and bring the link into service.
The PCU device attempts to come into service when the first GSL link is established.
Bringing the GSL device in service (ins_device command) is equivalent to a lock and unlock of
the GSL.
When all GSL parent devices (LCF, BSC MMS and PCU MMS) are in service and the PCU device
is unlocked, the GSL makes continual attempts to establish LAPD in order to come in service. If
during an attempt to bring the GSL in service and out-of-service, a parent device is detected
as locked, or the PCU device is locked, the GSL state reason code reflects the out-of-service
parent. Connection attempts are discontinued until the parent device comes back in service.
All message traffic is shared among the in-service links. If one link goes out-of-service, traffic is
redistributed among the links that remain in service.
BSS channel allocation
The BSS supports allocation of a GPROC HDLC channel during GSL initialization, each GPROC
supports up to 12 GSLs. The GSL is equipped to an LCF. If the LCF is not assigned to any
GPROC, the state of the GSL is NO GPROC AVAILABLE.
The GSL cannot be in service unless its associated MMS is in service. The BSC GSL depends
upon its BSC MMS and the PCU GSL depends upon its PCU MMS. If the GSL associated MMS
is out-of-service, the GSL state is Disabled-Unlocked with reason code: MMS not in service.
When the MMS comes back into service, the GSL also attempts to come back in service. The
associated PCU MSI provides the HDLC channel for the PCU GSL.
After a fault occurs on the GSL, the BSS attempts to bring the GSL back in service without
manual intervention. The last GSL going out-of-service constitutes a critical severity event. The
loss of in-service GSLs is a major severity event, because throughput to/from the PCU is reduced.
A critical severity indicates a loss of service and a major severity indicates a loss of capacity.
LAPD parameter
The LAPD parameter values for n200, t200 and k are fixed and cannot be modified by the
operator. The fixed values are as follows:
n200, 3 retransmissions
t200, 3s
k, 7 frames
3-78 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Resetting a GSL
The PCU GSL may go out-of-service and recover quickly enough such that the BSC GSL does not
detect the outage. If this happens with the only in-service GSL, the following events occur:
When the PCU GSL re-establishes communication with the BSC, the PCU detects that
the BSC GSL remained in service.
The PCU device at the BSC is disabled.
The BSC is forced to enter the initialization sequence for bringing the PCU back into
service.
NOTE
Disabling the PCU device results in the loss of the BSC GSLs, causing the PCU
to wait for a GSL to restore and then resync with the BSC.
If the above condition occurs with multiple in-service GSLs, when the PCU GSL re-establishes
communication with the BSC, the PCU GSL comes into service and the PCU is unaffected.
Termination of LAPD is optimized when an MMS outage is detected. Loss of an MMS is

detectable within the sync_time_oos time period, as defined by the database parameter.
However, LAPD time-out detection is within the (n200 * t200) time period, which may be
significantly longer than defined by sync_time_oos. An MMS outage associated with a GSL
always results in termination of LAPD. So in order to speed up the termination of LAPD, if
possible, the detection of MMS outage should explicitly terminate LAPD rather than waiting
for the expiration of the LAPD timing parameters. This optimization can be accomplished if
at least one other GSL is in service in addition to the failing GSL. If another communication
link is available to the other side of the link, when the MMS outage is detected, a GSL disable
request is sent to the other side of the link and the LAPD disconnect request is delayed such
that it is not processed until (n200 * t200) expires.
This optimization is also used if a GSL is locked.
Resetting a GSL
Resetting a GSL (with the command reset_device) is equivalent to locking and unlocking
the GSL.
Monitoring a GSL
The following MMI commands are used to monitor a GSL and are followed by the equivalent
OMC-R facility:
disp_equipment (Detailed view at the OMC-R)-displays the status of software and
hardware information.
state (detailed view at OMC-R)-displays the information entered during equipping the GDS.
68P02901W36-S 3-79
Jul 2008
GSL alarms Chapter 3: BSS Links
GSL alarms
The underlying GSL device is reported for device-specific alarms GSL alarms are fully described
in Maintenance Information: Alarm Handling at the OMC-R (68P02901W26) manual.
The following alarms are supported for the GSL:
Link Disconnected
LAPD Protocol Error
LAPD Protocol Error Threshold Exceeded
3-80 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GSL link control function
GSL link control function

Link control function management of GSLs
GSLs are managed by Link Control Functions (LCFs) at the BSC. The BSC LCF configures the
High level Data Link Controller (HDLC) channels to support the GSL.
The HDLC channels to support the GSL are configured on the LCF. The GSLs may be distributed
across multiple LCFs. One HDLC channel is required per GSL.
Equipping and unequipping an LCF
An attempt to equip an LCF fails if GPROC channel capacity is insufficient to support the
requested links. The total number of HDLC channels available on a GPROC is defined as the
number of GPROC slots-reserved HDLC channels. Currently, one HDLC channel is reserved.
The LCF equip fails if the total of the values defined by the parameters max_mtls, max_cbls,
and max_gsls exceeds the total available HDLC channels for the LCF. For details of the BSS
database parameters see 68P02901W23 Technical Description: BSS Command Reference
manual. The maximum number of GSLs an LCF can support is defined by the number of
available HDLC channels and is limited to twelve. {28337} The parameters max_gsls and
max_cbls can be changed to a non zero value only when max_mtls is not equal to 31.
LCFs are able to manage GSLs along with any combination of any other link device which is
supported by an LCF, provided HDLC channels are available. For example, an LCF may manage
a mix of RSLs, GSLs, CBLs and MTLs.
NOTE
XBLs and OMLs are link devices which are not managed by LCFs.
The BSS element gsl_lcf_mapping enables the auto or manual modes to be specified when
equipping GSLs in sysgen mode. In manual mode, the operator specifies the LCF during the
equipage of a GSL. In auto mode, the system distributes the equipped GSLs to usable LCFs.
Post SYSGEN, the operator always has to choose which GSL the LCF should be equipped to
manual mode.
Maximum number of GSLs parameter
The value of max_gsls limits the number of HDLC channels available for use by RSLs. Modifying
the value of max_gsls to a larger number results in further limiting the number of HDLC
channels available for use by RSLs. However, increasing this value does not result in disabling
any Busy-Unlocked RSLs even if there are not enough unused channels to accommodate the
increased number of GSLs.
The value specified for max_gsls during LCF equipage may be modified by the modify_value
command. If max_gsls is modified on an in-service LCF, the change takes effect immediately.
68P02901W36-S 3-81
Jul 2008
Taking GSLs in and out of service Chapter 3: BSS Links
Equip GSL parameter
The commands equip GSL or modify_value max_gsls fail if the total max_gsls for all LCFs
would become less than the total number of equipped GSLs. Equipage of additional GSLs is not
permitted until the total max_gsls for all LCFs is increased to support the new GSLs.
The command modify_value max_gsls fails if increased beyond the available LCF HDLC
channel capacity.
Unequip LCF parameter
The command unequip LCF fails if the total max_gsls for all LCFs would become less than the
total number of equipped GSLs. It will succeed only after one of the following actions is taken:
The total max_gsls for all LCFs excluding the LCF that is being unequipped is modified to
be greater than or equal to the number of equipped GSLs.
GSLs are unequipped such that the total equipped does not exceed the total max_gsls
for all LCFs, excluding the LCF that is being unequipped.
An unequip of an LCF will fail if any GSLs are equipped to that LCF.
Taking GSLs in and out of service
If an LCF supporting GSLs goes out-of-service, its associated GSLs are also taken out-of-service
and attempt to come up on other in-service LCFs with available max_gsls. When an LCF comes
into service and can support GSLs, it initiates requests to bring in GSLs which were waiting on it.
Monitoring a GSL
The disp_processor command at the BSC displays the GSLs being managed by the LCFs.
The command disp_hdlc for an LCF displays channels allocated to GSLs.
3-82 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GPRS PCCCH and PBCCH configuration
GPRS PCCCH and PBCCH configuration

PBCCH or PCCCH is the packet data logical channels dedicated for GPRS signaling. With
PBCCH or PCCCH configured in a cell, MS reads system information on PBCCH and perform
packet access activities on PCCCH. The following table shows the functionality of each packet
logical channels on PBCCH or PCCCH.
Table 3-6 PBCCH or PCCCH Channels
Packet transfer
Packet logical channels Functionality
direction
PRACH (PCCCH) Uplink only Used by MS to initiate uplink transfer for
data or signaling information.
PAGCH (PCCCH) Downlink only Used by BSS to send resource assignment
to an MS prior to packet transfer.
PPCH (PCCCH) Downlink only Used by BSS to page a mobile for PS or CS.
PBCCH Downlink only Used by BSS to broadcast packet data

specific System Information.
Without PBCCH or PCCCH configured in a cell, GPRS-related information is broadcasted on

BCCH and GPRS-accessing signaling is conducted on CCCH channels. The following figure
shows how BCCH or CCCH channels are typically configured on BCCH carrier.
Figure 3-19 BCCH or CCCH configuration
Figure 3-19 shows how BCCH or CCCH channels are configured on timeslot 0 on BCCH carrier
in a 51-multiframe. Figure 3-20 shows how a PDCH timeslot is configured in a 52-multiframe
and how PBCCH or PCCCH channels are configured on a PDCH timeslot with the following
configuration parameters:
Four PBCCH blocks
Four PAGCH blocks
Four PPCH blocks
Three PRACH blocks
68P02901W36-S 3-83
Jul 2008
GPRS PCCCH and PBCCH configuration Chapter 3: BSS Links
Figure 3-20 PBCCH or PCCCH configuration
In a lightly loaded GSM/GPRS network, BCCH or CCCH has sufficient signaling capacity for
both GSM/GPRS. However, in a heavily loaded GSM/GPRS network, PBCCH or PCCCH provides
more signaling capabilities for both GSM voice and GPRS service. In addition, PBCCH or
PCCCH reduces internal signaling traffic over the GSL and RSL because there are fewer
requests, assignments or paging messages. See Figure 3-21. This shows GPRS signaling traffic
carried over TRAU GDS. PBCCH or PCCCH also facilitates both MS controlled (C31/C32) cell
reselection and network controlled cell reselection (PSI 3, PSI 3bis and PSI 5), by broadcasting
cell reselection parameters to the MS.
Figure 3-21 Link usage by GPRS
With the PBCCH or PCCCH feature unrestricted, the BSS supports PSI1, PSI2, PSI3, PSI3bis,
PSI3quater, PSI5, PSI8 and PSI13. See the section Network controlled cell reselection
in this manual.
NC0 is broadcasted in SI13 and Network Control Orders are sent in Packet Measurement Order
to each mobile on PACCH. In GSR9, if PBCCH is disabled, we have the same behavior. If PBCCH
is enabled, network_control_order is broadcast on PSI5 and NC0 is still broadcast on SI13.
3-84 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GPRS PCCCH and PBCCH configuration
NOTE
PSI3ter, PSI4, PSI6 and PSI7 messages are not supported.
68P02901W36-S 3-85
Jul 2008
Improved Timeslot Sharing (ITS) Chapter 3: BSS Links
Improved Timeslot Sharing (ITS)

ITS feature
This feature enables customers with CTU2 radios to support EGPRS, while providing a greater
number of timeslots to also support voice/GPRS. The CTU2 effectively transitions from double
density operation to single density operation on a per timeslot basis.
The radio is configured for double density and timeslot pairs are borrowed to operate as a single
EGPRS timeslot. From a firmware perspective, the EGPRS timeslot operates on carrier A,
while the pair timeslot on carrier B is OOS. For example, the CTU2 can support two EGPRS
data timeslots and an additional 12 voice/GPRS timeslots. The BTS makes the idle timeslots
on Carrier B come back to INS when Carrier A on DD CTU2 becomes OOS or does not have
EGPRS PD on it.
This is a restricted feature and requires the EGPRS and VersaTRAU features to be unrestricted.
This feature is supported only by CTU2 which must be controlled by a Horizon II site controller.
This feature interacts with the following features:

VersaTRAU.
EGPRS.
Feature operation
DD CTU2 with 1 Tx EGPRS support (ITS)
On configuring an EGPRS PDCH on DD CTU2 Carrier A, the corresponding timeslot on Carrier B

is set to OOS. These X timeslots can not be activated by UNLOCK or INS command. Figure 3-22
shows an example of 3 PDs configuration.
3-86 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Feature operation
Figure 3-22 DD CTU2 configuration with EGPRS on Carrier A
A B
f2 f1
BTS reconfigures the X timeslots on Carrier B to idle when EGPRS PDs are moved or lost on
Carrier A. Figure 3-23 denotes that PD lost on Carrier A incurs the paired X timeslot on Carrier
B back to TCH idle.
Figure 3-23 X timeslot on Carrier B back to TCH idle when PDs lost on A
g Carrier Carrier
A B A B
freq freq
f1 f2 f1 f2
ti-GSM-X timeslot on Carrier B back to TCH idle-00321-ai-sw
NOTE
When the ITS feature is turned on or off in a live system, it will only take effect on the
relevant DD CTU2(s) following a 64K RTF mapping change on those DD CTU2(s).
68P02901W36-S 3-87
Jul 2008
SD placement Chapter 3: BSS Links
SD placement
As carriers are bought into service, the CRM uses the following CM database parameters
to decide how to configure its logical radio resources: number_sdcchs_preferred,
max_number_sdcchs, sd_priority, the number of barred TCHs, arfcn, pkt_radio_type and
sd_load. For the ITS feature, to maximize the PDCHs configuration on the Carrier A, the CRM
tries to avoid configuring SDCCHs to the DD CTU2 EGPRS Carrier A and its paired Carrier B.
PD configuration
The CRM restricts the EGPRS PDs configuration on Carrier A by taking the extended range
timeslots and SD on Carrier B into account. The CRM does not prefer DD CTU2 Carrier B
with paired DD CTU2 EGPRS Carrier A for PD placements if any carriers are available for PD
configuration as Carrier A is EGPRS capable. It first takes SD CTU2 EGPRS followed by DD
CTU2 EGPRS Carrier A for PD configuration or reconfiguration. The existing PD placement
algorithm is enhanced to support and differentiate between 64k RTFs on SD CTU2 and 64k RTFs
on DD CTU2 Carrier A. The CRM will start the PD placement algorithm when Cell Activate
message or Cell Update message is received from the PCU. For the ITS feature, the algorithm
needs to consider the EGPRS DD CTU2 Carrier A. The PD algorithm will differentiate an EGPRS
SD CTU2 carrier from an EGPRS DD CTU2 Carrier A during PDCH configuration. Besides,
Carrier B will be less favorable for PD placement as Carrier A is EGPRS capable.
description of the commands and parameters.
Parameters
The following parameter is newly added for use with this feature.
improve_ts_enabled - Specifies the Enable/Disable status of this feature in the BSS.
Commands
The disp_options command is modified to display the ITS feature in the list of unrestricted
features if the feature is unrestricted.
Alarm Information
The following alarm is modified by the ITS feature:
EGPRS unavailable No EGPRS carriers available.
For further information, refer to Maintenance Information: Alarm Handling at the OMC-R
(68P02901W26) manual.
3-88 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation CTU2D
CTU2D

{30828}
This feature introduces CTU2D radios that can support both SD (Single Density) and DD
(Double Density) EDGE architectures. This is an optional feature. The CTU2D radio supports
the following EDGE modes:
CTU2D SD: This mode is identical in operation to the existing CTU2 SD.
CTU2D PWR: This mode is also known as ITS mode as the operation is identical to
that of CTU2 in ITS mode.
CTU2D CAP: In this mode, carrier A is fully EDGE capable and carrier B supports
GPRS/TCH. No timeslot blanking is required.
The CTU2D in Capacity mode enables the BTS to support BBH for GMSK carriers assigned to
carrier B irrespective of the EDGE capabilities and PD (Packet Data) support for carrier A.
The CTU2D Capacity mode is applicable only to the new CTU2D radio platform. As it is not
possible to detect the radio platform in all scenarios, radio configuration mismatch handling is
enhanced to support the new mode as follows:
When a non-CTU2 radio is configured in Capacity mode, it will remain OOS.
When a CTU2 is configured in Capacity mode, it assumes double density behavior but
with EDGE restriction.
As the timeslot blanking is removed for Capacity mode configurations, carrier B is similar
to legacy, that is, SD DRIs for GPRS and or BCCH placement. Both carrier A and carrier B
can be considered for SDCCH placement without any restriction. Carrier A and carrier B are
considered as independent and non-interacting when placing PDs, that is, an EDGE PD placed
on carrier A has no impact on carrier Bs ability and priority to support EDGE or GPRS PDs.
Related parameters
This feature introduces the following new parameter:
ctu2dcapopt - This parameter indicates whether the CTU2D capacity feature is restricted or
unrestricted in the BSS. This feature requires the EGPRS feature to be unrestricted.
The following parameter is modified by this feature:
dri_density - The range of this parameter is extended to 3 to allow for the double density
capacity mode.
68P02901W36-S 3-89
Jul 2008
CTU2D Asymmetric Edge Chapter 3: BSS Links
CTU2D Asymmetric Edge

{30830}
This CTU2D Asymmetricis Edge is an optional feature which enables EDGE capability on both
DRIs of the CTU2D. This feature can be supported only on Horizon II macro, Horizon II micro
and Horizon II mini sites. In the asymmetric mode, carrier A is fully EDGE capable and carrier B
supports EDGE on the DL (downlink) and GMSK on the UL (uplink). The asymmetric feature
requires the remapping of the internal TDM allocations to provide 2EDGE carriers. Hence, BBH
support for EDGE is removed for the entire site. Same timeslots on both the carriers cannot
support 8PSK simultaneously.
Feature interaction
GSR9 QoS - EGPRS UL coding scheme value is internally limited to MCS3 on asymmetric EDGE
carriers during admission control and rescheduling.
Parameters
This feature introduces the following new parameters:
ctu2dasymopt - This parameter indicates whether the CTU2D asymmetric feature is restricted
or unrestricted. The asymmetric EDGE feature requires the EGPRS feature and the CTU2D
Capacity feature to be unrestricted.
asym_edge_enabled - This parameter enables or disables asymmetric EGPRS for CTU2D on

per SITE basis. The CTU2D asymmetric feature must be unrestricted to enable this parameter.
The site cabinets have to be Horizon II macro, Horizon II micro and Horizon II mini.
3-90 68P02901W36-S
Jul 2008
Chapter
BSS Software Processes

This chapter provides a description of the function and operation of software processes and
software objects in the BSS and PCU.
BSS software on page 4-2.
BSS software processes on page 4-4.
PCU software processes on page 4-9.
Configuration management database on page 4-12.
Radio Subsystem (RSS) on page 4-16.
Preserve transceiver calibration on page 4-20.
Database load management on page 4-24.
Alarm processing on page 4-26.
Alarm types on page 4-30.
Enhanced Circuit Error Rate Monitor on page 4-36.
GPRS Quality of Service (QoS) on page 4-43.
{27703A} Quality of Service (QoS) Phase 2 on page 4-52.
Audio volume control at the GDP on page 4-58.
{25423} Software patching on page 4-59.
{25424} PCU upgrade without BSC outage on page 4-61.
68P02901W36-S 4-1
Jul 2008
BSS software Chapter 4: BSS Software Processes
BSS software

BSS and PCU processes and objects
The GSM BSS System is composed of various software processes. These processes communicate
through defined messages and do not share the same read/write data, thus isolating the
processes from each other. The executive process (one per GPROC) provides a virtual software
platform supporting logical addressing and message routing. Thus, the system looks the same to
the user processes no matter what changes are made to the underlying hardware configuration
(that is, hardware modifications are transparent to user processes). A process can refer to
another process without knowing its physical address. This also allows processes to be portable
across the BSS. As hardware configurations change, more processor boards can be added. This
allows functions to be distributed across several boards resulting in better performance. All of
this can be done without modifying the user processes.
Processes also exist on peripheral devices, such as MSI, KSW and XCDR. The code objects of
these processes are loaded to the devices by the GPROC. These processes are not the same
as processes that exist on the GPROC (as described above) but functions are specific for the
device to which they are downloaded.
Process description
Each software process has a process description. The format is as follows:

Object number.
Name.
Software version.
Creation date and time.
Checksum.
Size.
Status.
Device type specific.
4-2 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BSS and PCU processes and objects
Table 4-1 explains the meaning of each stage of the process.
Table 4-1 Software process stage descriptions
Process stage Description

Object number Unique number of the code object.
Name Name of the code object.
Software version Version at which the object was made available (Release
and point release).
Creation date and time Date and time of release.
Check sum Calculated by the system.
Size Size of the object (bytes).
Status One of three values:
0 means the code is being downloaded.
1 means that the code is downloaded but not running.
2 means the code is present and executing.
Device type specific Depends on the device associated with the code object.
The specific field has a number of versions. If the number is ffh then this denotes that the code
object is only used at the BSC. A number of b8h requires this object code to be downloaded to a
BTS. This reduces the time taken to bring BTS sites into service.
DSP code contains the BTS flag (such as DRI, CEB, KSW, MSI) followed by the version of the
software.
68P02901W36-S 4-3
Jul 2008
BSS software processes Chapter 4: BSS Software Processes
BSS software processes

BSS software processes by function
The system application processes (and the objects that provide them) are created on individual
processors as decided by the BSS Initialization Process (IP) software during the initialization of
the site. Other BSS functions are provided by the following software processes:
Central Authority (CA).
Security management.
Fault Management (FM).
Call Processing (CP).
Statistics generation and reporting.
SYSGEN.
BSS reset.
Time functions (time stamping).
Software version control and ROM checksum check and display.
Configuration management (CM).
Radio subsystem (RSS).
Load Management (LM).
Alarm processing (FTP and FCP).
Circuit error checking.
In addition to the main system functions above, other BSS software functions include:
Transceiver calibration.
GDP volume control.
The commands and parameters used in the above software processes by the objects that provide
them are described in the Technical Description: BSS Command Reference (68P02901W23)
manual. The equivalent functions at the OMC are described in Installation and Configuration:
GSM System Configuration (68P02901W17) manual.
Architecture-BSS code objects
The Motorola BSS software is made up of a number of different code objects, which are
downloaded into a site as files, by a variety of methods.
4-4 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Central authority
These downloaded code object files are received by all the processors resident in a cabinet
and stored in the processor RAM.
Each code object file provides a system application process, such as the BSS radio subsystem
software and BSS call processing software; exceptions include the:
Database (standard functions).
Executive.
Object list.
Options database.
Library files.
With the exception of the Executive, the other code object files are read-only.
Central authority
One Central Authority (CA) software process is located at every site, BSC and BTS. The CA is in
control of the site. It is resident on the master GPROC only and maintains a list of the status of
every device and software process at the site.
Functions performed by the CA are as follows:

Locking down of all boards (lock or shutdown_device commands).
Moving a process or set of processes:

Bringing in the new device.
Moving the process.
Updates the CA router table and propagates the updates to the individual GPROCs at
all other sites. Note that the Executive process in each GPROC maintains routing
information and the real time clock. It is important that the routing information
is updated at every GPROC at the same time. Therefore, the GPROCs are all
synchronized in time.
Fault management
The Fault Management (FM) objects provide the display and modify commands and parameters,
which show the administrative state of devices and functions within the system. They also
collect alarm and error messages and forward them for the specific RSS instance.
Call processing
BSS Call Processing (CP) is a collection of Layer 3 system application processes that deal with
the high level control of Mobile Subscriber (MS) calls. The CP software is responsible for
the call setup and clearing of all MS calls.
68P02901W36-S 4-5
Jul 2008
Statistics generation and reporting Chapter 4: BSS Software Processes
CP also provides the call trace functions for specified calls by call rate or SCCP connection
number. Data collected can be analyzed later within the BSS system, or by downloading to free
standing computer equipment and using the available Motorola optional tools.
Statistics generation and reporting
The BSS statistics are available within the following categories:

BSS statistics.
Cell statistics.
Neighbor statistics.
Carrier and timeslot statistics.
GPROC statistics.
MTL statistics.
CBL, OML, RSL and XBL statistics.
Key statistics (required by GSM standards).
Network health reports (Motorola specific).
The BSS statistics are described in the Maintenance Information: GSM Statistics Application
(68P02901W56) manual.
BSS commands exist specifically to specify statistics that are required by users.
SYSGEN
The SYSGEN software object restricts certain BSS commands and parameters to be changed
only when the system is in a quiescent state. This is known as SYSGEN ON. Normal operating
state of the BSS is SYSGEN OFF.
The BSS commands and the system state in which they can be used are described in the
Technical Description: BSS Command Reference (68P02901W23) manual.
BSS reset and clear database
Resetting of the whole BSS does not remove the CM databases at the sites. This must be
done using the clear_database. Resetting of the BSS can only be done with the BSC in the
SYSGEN ON state.
Time functions (time stamping)
Most messages in GSM systems are time stamped. This is done automatically by the system
software from reference sources.
4-6 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Software and ROM checks
Software and ROM checks
The disp_flash command checks and displays the software version (load) number, the ROM
checksum and size. Software and databases at each site are downloaded to the BSC and other
sites when changes are made.
Standard GSM and optional functions
Throughout this manual, optional features within the main functions are described as such.
Other features can be assumed to be standard. Optional features are described as restricted if
the feature is not enabled or unrestricted if enabled.
For example, the optional GPRS software is unrestricted or restricted by the cell parameter
(gprs_enabled), as described in Technical Description: BSS Command Reference
(68P02901W23) manual.
Link utilization improvements
Previously within the BSS software, the signaling messages exchanged between the Radio
Subsystem (RSS) and Packet Resource Manager (PRM) processes, over the Radio signaling Link
(RSL) and the GPRS Signaling Link (GSL), had a large header compared with the data part
of the message and consequently this produced a transmission delay. In addition, the BSS
software sent one message per Link Access Procedure for ISDN D-Channel (LAPD) frame on
the RSL and GSL links; this did not fully utilize the maximum size of the LAPD Unnumbered
Information (UI) frame.
This function improves the performance of the RSL/GSL links and reduces the expected
pressure on the capacity and speed of the links from the expanded capacity and high speed
GPRS functions. This Link utilization improvements function reduces the message transmission
time between the BTS and PCU for the InCell, Horizonmacro and Horizonmicro Horizoncompact
by 35% to 40%, 20% to 35% and 15% to 30% respectively. The number of GPRS timeslots that
the RSL can support should be increased by 40% in most GPRS BTS configurations.
The Link utilization improvements function addresses the above issues to speed up messages
exchanged between the RSS and PRM. The following enhancements have been made:
Smaller header for delivering messages between the RSS and PRM.
Message packing/unpacking mechanism at the RSL and GSL end-points.
Creating a high priority mailbox.
Smaller header for delivering messages between the RSS and PRM
The new message header is eight bytes and contains minimum information necessary to deliver
the messages between the two processes. The functionality of the existing routing functions
does not change and a new set of routing methods and Application Programmer Interfaces
(APIs) are created for the application processes to use.
68P02901W36-S 4-7
Jul 2008
Link utilization improvements Chapter 4: BSS Software Processes
Message packing/unpacking mechanism at the RSL and end-points
This improves both speed and utilization of the RSL/GSL links by packing more than one
signaling message into the same LAPD frame thus reducing the LAPD header overhead.
Messages waiting in the RSL/GSL mailboxes are packed in one LAPD frame before writing it
to the link and it is unpacked when it is read from the link.
Creating a high priority mailbox
The function creates a high priority mailbox call LUI mailbox in the Executive Data Link
Service Process (Exec DLSP) for certain high priority messages between the RSS and PRM. This
mailbox is created at both the BTS and PCU. This enables processing of messages in the LUI
mailbox at a higher priority than messages in all other RSL/GSL mailboxes.
The RSS and PRM uses the small header with high priority for only certain high priority
messages. The messages sent with this option are routed to the LUI mailbox and all other
messages between the RSS and PRM (using the small header/normal header) are sent to the
RSL/GSL mailboxes. With this function, the RSS and PRM can send and receive the following
messages:
Messages with normal headers, which go to RSL/GSL mailboxes.
Messages with small headers, which go to the high priority LUI mailbox.
Messages with small headers, which go to the RSL/GSL mailbox.
4-8 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation PCU software processes
PCU software processes

PCU software processes by function
Like the BSS system, the PCU system is composed of software processes. These processes
communicate through defined messages and do not share the same read/write data, thus
isolating the processes from each other. The executive process provides a virtual software
platform supporting logical addressing and message routing. Thus, the system looks the same to
the user processes no matter what changes are made to the underlying hardware configuration
(that is, hardware modifications are transparent to user processes). A process can refer to
another process without knowing its physical address. This also allows processes to be portable
across the BSS. As hardware configurations change, more processor boards may be added. This
allows functions to be distributed across several boards resulting in better performance. All of
this can be done without modifying the user processes.
Software functions
The PCU system application processes (and the objects that provide them) are created on
individual processors as decided by the PCU initialization process software during initialization.
Other PCU functions are provided by the following software processes:
PCU Central Authority (pCA).
PCU Switch Management (pSM).
Cell Balancing (CB).
PCU Fault management (pFTP and pFCP).
PCU Configuration Management (pCM).
The commands and parameters used in the above software processes by the objects that provide
them are described in the Technical Description: BSS Command Reference (68P02901W23)
manual. The equivalent functions at the OMC are described in Installation and Configuration:
GSM System Configuration (68P02901W17) manual.
PCU central authority
One PCU Central Authority (pCA) software process is located at every PCU. The CA is in control
of the PCU. It is resident on the master DPROC (MPROC) only and maintains a list of the status
of every device and every software process at the site. The software is downloaded to the PCU
cabinet by the BSC through E1 link.
68P02901W36-S 4-9
Jul 2008
PCU switch manager Chapter 4: BSS Software Processes
The pCA moves processes or sets of processes as follows:

Brings in new devices.
Moves the process.
Updates the CA router table and propagates the updates to the individual DPROCs (PICPs,
PSPs and PRPs).
NOTE
The Executive process in each DPROC maintains routing information and maintains
the real time clock. It is important that the routing information is updated at every
DPROC at the same time. Therefore, the DPROCs are all synchronized in time.
PCU switch manager
The PCU Switch Manager (pSM) resides on the PSP as part of the Gateway Manager (GWM)
Functional Unit process. The pSM maintains data paths within the PCU and communicates with
the BSC SM for RCI to GDS 16 kbps resource (GCI) mapping. The GDS Channel Identifier (GCI)
consists of the BSC MMS identifiers of the GDS, the timeslot on the GDS and the group number
within that timeslot. Within the PCU, the pSM maps each RCI to a specific GCI for data transfers
uplink and downlink. The pSM maintains a table of all RCI-GCI mapping.
Cell balancer
The Cell Balancer (CB) resides on the PSP as part of the Gateway Manager (GWM) Functional
Unit process. The CB process balances the cells configured for GPRS across PRPs. In the event
of a PRP outage, this process sends message(s) indicating that GPRS service is unavailable to
the appropriate CRM(s) for the cells that could not be moved to an INS (In Service) PRP.
The CB process is invoked during initialization time by PCA once the PRP DPROCs are brought
in service. The PCA process informs the CB which PRPs are in service. Using the information
supplied in the CM database, the CB allocates GPRS timeslots to the available PRPs. Once the
cell balancing is complete, CB informs PCA of the cell to PRP mapping that are to be used in the
routing tables. An algorithm distributes the GPRS timeslots evenly across the PRPs. Timeslots
in one cell are not split across PRPs. Some timeslots of a cell may not be allocated to a PRP.
The CM database can have more GPRS radio timeslots equipped than the available PRP
resources can support. Whenever more PRP resources are made available, the CB attempts to
allocate the remaining GPRS radio timeslots to PRPs.
When a PRP fails, it is CB that informs the appropriate CRM(s) that GPRS is unavailable for the
cell(s). CB also attempts to reallocate the cells to INS (IN Service) PRPs. If successful, CB then
informs GBM and PCA that it has reactivated the cells on appropriate PRPs.
4-10 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Fault management
Fault management
The PCU Fault Translation Process (PFTP) at the PCU handles the following fault indications
that originate at the PCU:
Reporting.
Alarm list handling.
Configuration tag allocation.
Translation.
The PCU Fault Translation Process (PFTP) resides on the PSP as part of the Gateway Manager
(GWM) Functional Unit process. All alarms at the PCU are reported to PFTP. All DPROCs
and the MPROC have a local PCU Fault Collection Process (PFCP) to handle Software Fault
Management indications (SWFMs). The PFTP forwards alarms to the Agent at the BSC and
generates messages to PCA for device transitions as needed, based on faults reported.
PCU configuration management
The PCU Configuration Management (PCM) process resides on the PSP as part of the Gateway
Management (GWM) Functional Unit process.
The CM process at the BSC communicates with the PCU CM (PCM) process in the same manner
as a remote BTS. The CM at the BSC communicates with the PCM on the PSP. Peer processes
of the PCM reside on each DPROC to assist CM database updates. Since there is no MMI
functionality at the PCU, the PCM has reduced functionality compared to the CM at the BSC.
The PCM process handles the automatic equipping of CAB and Cage at the PCU.
The PCM process receives the CM database object from the BSC. A translation of the starting
address and all pointers within the database moves the database from the starting address of
0xc1000000, which is not supported at the PCU. After translation, the database object is stored
in compact flash memory on the PSP. This translated object is cross loaded to the DPROC boards
equipped in the database with the code objects at initialization time. Any subsequent database
updates result in a similar translation and broadcast. The PCM updates the database object
in compact flash memory as well.
68P02901W36-S 4-11
Jul 2008
Configuration management database Chapter 4: BSS Software Processes
Configuration management database

Configuration management functions
The configuration management objects provide the following functions:

Configuration of all the elements in the BSS, including transceivers.
Timeslot usage control (for example, BCCH, SDCCH 8 channel or TCH/FS).
Initialization of the base site and downloading to the BTSs.
Interfacing to the BTS fault management system.
Population of the BSS databases.
Modification of the BSS database elements.
Display of the BSS database elements.
Configuration management database content
The Configuration Management (CM) software is responsible for managing and updating the
main configuration database at either a BSC or a BTS. This is the database that is downloaded
as an object file in the download code. This database holds all the site parameters such as
carrier frequencies, site configuration, surrounding site information and handover parameters.
This database also stores device functionality and distribution as well as all timing information
for the site.
All application processes have access to this database but their access is read only. If the
CM database is required to be changed, the CM process performs this task. This process has
both read/write access to the CM Database.
{28398} The BSC supports database size increases up to 8 MB.
Enhanced BSC capacity phase 2
An optional function known as Enhanced BSC Capacity Phase 2 is made available. It

increases the number of carriers to 600 and the number of Circuit Identity Codes (CICs) to 3200.
The BSS requires GPROC2s or GPROC3s for all GPROCs at the BSC and BTS.
At the user interface, there are 27 links between the BSC and 10 RXCDRs.
NOTE
At the BSS, the BSC-RXCDR connectivity table needs to be increased from 21 to
27 entries.
4-12 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Increased Network Capacity
The feature supports the following configurations:

If the enhanced BSC capacity function is restricted:
The BSS supports the standard database configuration for 384 carriers.
The BSS supports the standard database configuration for 2400 CICs.
If the enhanced BSC capacity function is not restricted:

The BSS supports the enhanced database configuration for 512 carriers.
The BSS supports the enhanced database configuration for 3200 CICs.
Increased Network Capacity
{28398}
The Increased Network Capacity feature is an optional feature which supports BSC database
increases up to 8 MB. When the RAN capacity is increased with this feature, the network can
have maximum configurations of up to 750 carriers, 140 sites, and 4800 circuits per BSC. The
existing RXCDR is capable of supporting 4800 CICs. The BSS supports 42 connections between
one RXCDR and the BSC.
NOTE
At the BSS, the entries in the BSC-RXCDR connectivity table increase from 27 to 42.
If this feature is enabled, the BSS supports the enhanced database configuration for 750
carriers and 4800 CICs.
CM database distribution
Figure 4-1 shows how the CM database is distributed across all active GPROCs on any particular
LAN. On the LAN, one GPROC is designated to have the master CM database. Hence, the CM
application process is also present on this GPROC.
Any changes to the CM database are written to the master CM database through the CM
application process. After the changes have been validated with the objects that use them, the
master CM database broadcasts them to all CM databases on all GPROCs on the particular LAN.
If the CM process is at the BSC, it also broadcasts the changes to each BTS site.
68P02901W36-S 4-13
Jul 2008
CM database distribution Chapter 4: BSS Software Processes
Figure 4-1 CM database distribution
ti-GS M-CM da ta ba se dis tribution-00177-a i-sw
Database levels
Figure 4-2 shows the database level arrangement. Changes in the configuration management
database at the BSC are propagated to any affected BTS site. The database level number is used
to determine if the database at a BTS is synchronized with the BSC database, or at the BSC
to determine if the database is synchronized with the OMC.
The database level number feature keeps a database level number for each site in the BSS. The
database level number increments are sent to a remote BTS only if the database changes for
that site. This feature will help prevent unnecessary database downloads to remote BTSs and
also reduces the message traffic in the BSS.
4-14 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation CM database distribution
Figure 4-2 Database level numbers
68P02901W36-S 4-15
Jul 2008
Radio Subsystem (RSS) Chapter 4: BSS Software Processes
Radio Subsystem (RSS)

Radio Subsystem functions
The Radio Subsystem (RSS) consists of five components, which manage the BSS RF hardware
and the radio link to the MSs:
RSS configuration and fault management.
Layer 1 interface.
Layer 2 interface.
Layer 3 interface.
Abis interface.
Handover detection and power control.
Layer 1 interface
The layer 1 interface is the physical channel hardware layer. It translates the message protocol
used by the RSS software into a protocol used by the channel coding processors. This process
also stacks paging messages and access granted messages until the relevant timeslot appears
on the control channels.
Layer 2 interface
The layer 2 interface is to the MS LAPDm and radio link control and includes the handover
detection and power control process. It translates any signaling information destined for the MS
into GSM signaling used on the air interface, on a per timeslot basis and handles all LAPDm
protocol messaging for the MSs. The layer 2 process also sets up the link to the MS, over the air
interface, to support SMS data transfer, MS-originated or MS-terminated.
Layer 3 interface
The layer 3 interface is to the application layer.
An instance of RSS resides on:

A DHP GPROC in a InCell BTS site.
A Transceiver Control Unit (TCU) device in an M-Cell site.
A Compact Transceiver Unit (CTU) in a Horizonmacro.
4-16 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Abis interface
In InCell environments, the instance of RSS on a DHP GPROC can, in theory, handle up to six
carriers (DRIMs and SCUs); however, due to the processing load required, the GPROC can
generally only handle three carriers.
The RSS load depends entirely on the traffic model in use. The DRIM devices controlled by the
DHP must be in the same case as the DHP, due to MCUP bus communication.
In the Horizon and M-Cell product ranges (with a TCU), the one instance of RSS software is
resident on the TCU, thus controlling one carrier.
In the Horizon macro the one instance of RSS software is resident on the CTU, thus controlling
one carrier.
In Horizon macro or Horizon II macro the instance of RSS software resident on the CTU2
controls two carriers.
Abis interface
The Abis interface translates all messages generated inside the RSS into Abis format messages
for transmission to any layer 3 application processes. Messages received by this process are
verified to ensure they are complete.
The Abis process also counts the number of access bursts being sent on a random access
channel. The number of bursts are counted over a database-definable period. If a predefined
threshold is reached, the Abis process informs the layer 3 software. The software reduces the
amount of access bursts by barring an access class.
Handover detection and power control
The Handover Detection and Power Control (HDPC) object has the following functions:
Controls the transmission power of the MS uplink transmission and its related BTS
transceiver downlink transmission on a per timeslot basis.
The object is to keep both the MS and the BTS transceiver on the lowest possible
transmission power to help reduce interference between system users. Downlink power
control can be specified in the database. Note that the BCCH carrier has to transmit
at the same predefined power constantly.
Calculates the timing advance of the MS and keeps it inside its allocated timeslot.
Initiates the handover process for an MS.
Controls when the handover is necessary, that is, the MS is on maximum power but the
received level at the BSS is still too low, or the MS is on maximum timing advance.
NOTE
The handover procedure follows GSM Recommendation 5.08 and includes
additional Motorola algorithms.
68P02901W36-S 4-17
Jul 2008
RSS component relationship Chapter 4: BSS Software Processes
Monitors the uplink idle TCH interference and reports the average noise level per TCH
to call processing.
To reduce resource wastage by improperly terminated calls, HDPC monitors the SACCH
messages from all MSs on its busy TCHs. If a user specified number of consecutive SACCH
messages are not received from an MS, HDPC informs the call processing software to close
down the resources allocated to that MS.
Power control and handover are fully described in Chapter 8 Power and Handover Control.
RSS component relationship
Figure 4-3 shows the relationship between the RSS components and the RSS impact on other
parts of the BSS.
4-18 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation RSS component relationship
Figure 4-3 RSS component relationship
68P02901W36-S 4-19
Jul 2008
Preserve transceiver calibration Chapter 4: BSS Software Processes
Preserve transceiver calibration

Preserve radio channel unit calibration function
This function enables malfunctioning transceivers to be replaced without the need to remove
the cell from service.
The calibration offsets can be displayed and cleared using the disp_cal_data and
clear_cal_data commands.
Display calibration offsets data
The disp_cal_data command only displays offsets from the radio if the DRI is in the
unlocked/busy state. Otherwise it displays the GPROC CM database values when the radio is
locked or not BU. If there are no calibration values available on the specific RAM of the radio
and the CM database has no copy because they have been cleared then the response will be NO
CALIBRATION DATA AVAILABLE.
Store calibration data
The store_cal_data command sets a flag that indicates that when the radio is unlocked and
comes into service the calibration values are copied from the RAM in the radio into the GPROC
CM database. The values from the RAM in the radio are copied to the GPROC CM database
if there are no calibration values in the database and if the radio has values in the RAM to
be copied.
If the RAM in the radio has been cleared of all values and the GPROC CM database has
calibration values for that specific radio then, upon unlocking, a copy of the calibration values
are obtained from the CM database. Different calibration values for the same radio can exist,
in the CM database and RAM in the radio.
Care has to be taken when calibrating a radio and the existing values in the CM database and
the radio have to be cleared before a calibration can be successful and the right calibration data
can be saved correctly. The clear_cal_data command description explains how to clear the
data and there is a procedure that goes through these considerations. This is to ensure that
the values in the RAM of the radio and CM database have the same calibration data. This
calibration data is stored in the master CM database at the BSC, which is then used to update
the CM database copy at the BTS only if the data is valid.
NOTE
In any transceiver calibration, the value 80 H must be cleared from all the paths
(columns of data) stored in the radio. Otherwise the calibration data is not
passed to the CM database.
4-20 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Preserve radio channel unit calibration function
This applies even when the value 80 H is not in the path of the transceiver being
calibrated. If the 80 H value exists on another path, the data is not copied to the
CM database, when the radio is unlocked calibration will appear to be lost.
If an 80 H value is found, it must be removed by calibrating the radio on that
path.
Clear calibration data
The clear_cal_data command removes the offsets from RAM and the DB. To clear the data the
command should only be issued after the radio is locked. This is valid for a radio that has been
BU in the network. If a new radio is being put into the network, this radio must first be allowed
to become BU then it should be locked and only then this command would clear the calibration
data for this specific radio. This is explained in the calibration procedure.
Calibration data exchange
The process of uploading/downloading calibration data between the radio and the CM database
is automatic, based on the following conditions:
Site Initialization with invalid/no calibration data held in CM Database but with valid
calibration data in radio.
Initially a radio is calibrated and the antenna offsets stored within the radio. When the
BTS initializes and goes into call processing the Central Authority (CA) at the BTS queries
Configuration Management (CM) to see if valid offset data exists. If no valid data exists
then the radio(s) are queried for the offset data, which is sent through the Radio Signaling
Link (RSL) to CM at the BSC.
Site Initialization with calibration data held in CM Database but with invalid/no calibration
data in radio.
If a radio malfunctions and has to be replaced, the associated DRI is locked and the
malfunctioning radio replaced with a new radio while the cell is still in service. The DRI
is then unlocked. When the executive message radio Standby Success is received by the
CA at the BTS, the database is queried to determine if any valid offset data is stored. If
found, the valid offset data is downloaded to the new radio and the radio is allowed to
come into service (BU).
Site Initialization with invalid/no calibration data held in CM Database and invalid/no
calibration data in RCU.
Once the CA at the BTS receives the executive message radio Standby Success, it checks
the CM database for valid offsets. If none exist, the BTS then queries the radio for valid
data. If none exist in the radio, the radio is brought into service but triggers an alarm,
Invalid transceiver calibration data.
The procedure for transceiver calibration is described in Installation and Configuration:

BSS Optimization (68P02901W43) or the relevant Horizon / Horizon II service manual.
68P02901W36-S 4-21
Jul 2008
Preserve radio channel unit calibration function Chapter 4: BSS Software Processes
Displaying calibration data
Examples of displays of calibration data are shown below.
MMI-RAM 0115-> disp_cal_data 8 dri 1 2 0DRI ID: 1 2 0

Calibration Data (All values in Hex):
Transmit Power Offsets = 15
Receiver System Data:
Port Number 1 1 1 2 2 2
Antenna Number 1 2 3 4 5 6
fc, fc, fc, d5, d5, d5,
fc, fc, fc, d7, d7, d7,
fc, fc, fc, db, dc, db,
fc, fc, fc, db, db, db,
fa, fa, fa, d8, d8, d8,
f6, f6, f6, d4, d8, d8,
f4, f4, f4, d8, d8, d8,
f8, f8, f8, d5, d5, d5,
fa, fa, fc, d0, d2, d0,
fc, fc, fa, d4, d4, d4,
f9, f8, f8, d8, d8, d8,
f7, f7, f8, d8, d8, d8,
f8, f8, f8, d3, d3, d3,
f7, f7, f7, d2, d2, d2,
f4, f4, f4, d7, d7, d7,
f4, f4, f5, d8, d8, d8,
MMI-RAM 0115-> disp_cal_data 8 dri 2 0 0

DRI ID: 2 0 0
Antenna Number 1 2 3 4 5 6
3, f8, f8, 4, f8, f8,
1, f6, f6, 5, fc, fc,
2, f4, f4, 7, f8, f8,
2, f7, f8, 6, f6, f6,
0, f7, f7, 1, f8, f8,
fe, f4, f4, 0, fc, fc,
0, 2, f2, 2, f7, f7,
fe, f6, f6, 2, f6, f6,
4-22 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Preserve radio channel unit calibration function
fa, f3, f3, 2, f7, fa,

f8, f0, f0, 3, fa, fa,
fc, f0, f0, 2, f4, f4,
fc, f2, f2, fe, f0, f0,
f6, f2, f2, fa, f5, f5,
f0, ed, ed, fc, f6, f6,
f0, e9, ea, fc, ee, ee,
ee, ea, eb, f4, eb, eb,
{27236} The following example displays the calibration data for a DRI when the 4 Branch
Receive Diversity feature is enabled.
MMI-RAM 0115 -> disp_cal_data 40 dri 0 0

DRI ID: 0 0 0
Data read from transceiver
Store Calibration Data:disabled
Antenna Number 1 2 3 4 5 6 7 8 9 10 11 12
b89, e80, e80, c4e, e80, e80, b89, e80, e80, c4e, e80, e80,
b7f, e80, e80, ca2, e80, e80, b7f, e80, e80, ca2, e80, e80,
b8d, e80, e80, c74, e80, e80, b8d, e80, e80, c74, e80, e80,
b8d, e80, e80, c9d, e80, e80, b8d, e80, e80, c9d, e80, e80,
b61, e80, e80, c65, e80, e80, b61, e80, e80, c65, e80, e80,
b19, e80, e80, c0c, e80, e80, b19, e80, e80, c0c, e80, e80,
aff, e80, e80, bd3, e80, e80, aff, e80, e80, bd3, e80, e80,
b1d, e80, e80, b54, e80, e80, b1d, e80, e80, b54, e80, e80,
b4b, e80, e80, b9f, e80, e80, b4b, e80, e80, b9f, e80, e80,
b5b, e80, e80, b85, e80, e80, b5b, e80, e80, b85, e80, e80,
b4f, e80, e80, b53, e80, e80, b4f, e80, e80, b53, e80, e80,
b4a, e80, e80, b71, e80, e80, b4a, e80, e80, b71, e80, e80,
b2d, e80, e80, b59, e80, e80, b2d, e80, e80, b59, e80, e80,
b1e, e80, e80, b29, e80, e80, b1e, e80, e80, b29, e80, e80,
b08, e80, e80, aab, e80, e80, b08, e80, e80, aab, e80, e80,
a8f, e80, e80, a9f, e80, e80, e80, e80, e80, a9f, e80, e80,
68P02901W36-S 4-23
Jul 2008
Database load management Chapter 4: BSS Software Processes
Database load management

Changing databases
In SYSGEN OFF mode, any changes that are to be made to the CM database have first to be
checked and approved by the CA object to ensure that the state of the devices in the system
are compatible with the change requested. The process is:
Changes to the database are downloaded to the MMI object from the OMC-R.
Changes are downloaded to the CM object from the MMI object.
CM object writes the changes into the CM database.
CM object transfers the proposed changes to the CA object.
CA object approves or disapproves the desired changes (Yes or No).
CA object answers Yes, the CM object broadcasts the changes to all the CM databases of
GPROCs on its site. If the answer is No, the CM object instructs the CM database to
erase the changes.
CM object uploads the outcome of the operation to the MMI object, that is, changes
possible or not possible.
Operation outcome uploaded to the OMC-R.
Database change commands are allowed only at the BSC. At times it is necessary to update the
database while visiting a site. This can be done using rlogin to set up a remote login to a
GPROC at the BSC from the BTS. This then allows MMI commands to be entered from the BTS
as though from the BSC.
Database change level numbers
Subsequent changes to a database during call processing can be made from the OMC using a
number of input mechanisms, these are TTY, Forms, Batch and Detailed view. In all cases the
update is sent to the required entities using the procedure outline in the previous pages.
The whole database for a BSS is stored in every entity of the BSS. The BSC, for example, initially
has the same database as each BTS. Subsequent changes during call processing cause a
disparity between databases held in different entities. If, for example four consecutive changes
are made to the database of BTS 3 using forms at the OMC. The level number for BTS 3 at the
BSC is incremented by four, likewise the level number at BTS 3 is also incremented by four. Even
though the database at BTS 3 has changed, the alterations are not passed on to BTS 1 or 2. They
still have the old database for BTS 3 in store. Certain changes to a BTS database may be copied
to other BTSs, these changes are necessary for the correct operation of the handover procedure.
In the example shown previously (Displaying calibration data sub-section) four changes have
been made to the database of BTS 3 and one change has been made to the database of BTS 2.
For each change made to an individual site the database level number is incremented on a site
basis, for each change made to a BSS database the level number of the BSC is incremented.
4-24 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Database change level numbers
If these changes are made using TTY, Batch, Forms or Detailed View at the OMC the changes
are made in the BSS, but are not copied to the master database held by the OMC. Hence, any
changes made to the BSS database should be followed at some stage with a database upload to
renew the database in the OMC. If this procedure is not carried out, upon a BSC reset, the OMC
could potentially download an old database not current with any recent changes that have been
made. As the OMC is deemed the master entity the BSC would abandon any database it held
and implement the one being held and subsequently downloaded by the OMC.
68P02901W36-S 4-25
Jul 2008
Alarm processing Chapter 4: BSS Software Processes
Alarm processing

Alarm display
The Motorola GSM system provides a comprehensive set of alarm functions permitting effective
and timely resolution of alarms.
When a fault occurs in a network element (NE) or the OMC-R, one of the Fault Management
(FM) responses includes generating alarms and isolating the fault to minimize its impact.
The OMC-R provides several alarm display options, including alarm listings and network maps.
When the OMC-R receives the alarm message, the operator is alerted by the flashing Alarms
icon on the OMC-R GUI front panel. If the Maps function is enabled, the location of the device
reporting the alarm is indicated with a color change.
Alarm listings provide information enabling the operator to troubleshoot and resolve the alarms.
Alarm messages are generated when a specific fault condition occurs within a BSS or the
OMC-R, whether due to hardware or software fault conditions.
All alarms are described in the Maintenance Information: Alarm Handling at the OMC-R
(68P02901W26) manual. General fault handling and resolution functions and procedures
are described to ensure that the operator has an understanding of basic steps for alarm
maintenance and fault resolution.
The Base Station System (BSS) MMI alarm messages are text strings that are sent to the
Operations and Maintenance Center (OMC-R) or to a Local Maintenance Terminal (LMT) on-site
from the master processor.
Note that some alarms are generated exclusively at the OMC-R and cannot be viewed within a
BSS alarm window.
Alarm blacklisting
The Alarm blacklisting permits specified alarms to be blocked from display in the alarm/event
window at the OMC-R.
There are three blacklisting options:

All events from a selected device.
A specific event from a selected device.
A specific event from all devices.
Comment field
The Alarm comment field provides the capability of adding notes or comments to the system
regarding a specific alarm. These notes allow information to be shared online between operators.
4-26 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Alarm consolidation
Alarm consolidation
Faults resulting in device reconfigurations generate more than one alarm. Alarm consolidation
identifies the alarm that causes the device reconfiguration and indicates the impact on the
subscriber. This permits the operator to determine the appearance of alarms in the OMC-R
Alarms window and map displays. Alarms consolidation is enabled using the OMCMAPMODE
environmental variable. There are three reporting and display options available and these are
selected using the CONSOLIDATION environmental variable.
In the Alarms window, there are two types of alarms: tagged and untagged.
Tagged alarms are reported when a device is reconfigured as the result of a fault or operator
action. The alarm associated with the device reconfiguration is the primary alarm. Other alarms
related to the fault but not directly associated with the device reconfiguration are secondary
alarms.
Untagged alarms are reported when a device reports a fault that does not cause a
reconfiguration.
NOTE
If alarms consolidation is not enabled, all alarms are untagged, including alarms that
cause device reconfigurations.
In map displays, there are two modes of operation: subscriber and device.
The subscriber mode displays the impact of an alarm on subscriber service. This reduces
the time required to identify and resolve service-affecting alarms. The device mode displays
the impact of an alarm on devices.
NOTE
Alarms consolidation must be enabled to select the subscriber mode. If not enabled,
or if the subscriber mode is not selected when enabled, the display will be in the
device mode.
Context sensitive help
The OMC-R Context Sensitive Help facility provides a Worldview display of the specific page of
this manual corresponding to a selected alarm message. The displayed page provides online
alarm descriptions and fault isolation procedures.
Paging list
The OMC-R Paging List facility permits operators on call to be alerted when specific alarm or
state changes are detected at an OMC-R and there is no coverage at the OMC-R. The operator
can use this information to determine if an emergency condition exists.
68P02901W36-S 4-27
Jul 2008
Resync Chapter 4: BSS Software Processes
When activated, the on-call operator's alphanumeric pager displays the following information:
Device ID.
Error code.
Severity.
Error message.
NOTE
Due to the constraints in the number of characters which can be displayed on an
alphanumeric pager, the character strings representing the alarm name may be
truncated. In some cases, the limit is 80 characters.
Resync
The OMC-R Resync facility enables the alarm and device state information at the OMC-R to be
updated to reflect the actual device and state and alarm information the network elements (NE).
When to perform a resync
A resync should be performed in the following situations:

The resync operation needs to be performed when a link to a site has failed.
The OMC periodically requests a system-wide alarm and state resynchronization of every
site in the managed network.
A resynchronization can also be done on OMC startup (user-configured) using the OMC
resyncState and resyncAlarm processes.
resyncState
The NE sends the state of the SITE and MMS devices of each of its sites to the OMC.
This information is used by Network Status Summary (NSS) in the network maps, or by any
event display window with the appropriate subscriptions, to indicate if NE sites and links are
operational.
Performing the resync one site at a time reduces the possibility of having a backlog of events at
the OMC.
4-28 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Save alarm context
resyncAlarm
If the result from the resyncState operation is positive, a resyncAlarm operation will be initiated.
The NE sends up the active alarms on its active alarm list to the OMC. The alarms sent are
compared with the alarms currently in the AET of the OMC. If there are any differences, the
alarm messages in the AET are updated to include a resync indicator field.
The different types of entries in this field are expressed:

[R]-Alarm that was first seen at OMC after being sent due to a resync.
[R?]-Alarm that was previously sent during a resync, at end of a subsequent resync, is no
longer in the BSS active alarm list.
[?]-Alarm that is in the OMC active event table, but is no longer in the BSS active alarm
list. These alarms can be handled as a group.
Save alarm context
If the BSS detects that communication with the OMC-R has been lost, it will route all BSS
critical and major alarms and all state change events to a buffer.
When the BSS detects that communication with the OMC-R has been re-established, it will start
sending the events and alarms in the buffer to the OMC-R in chronological order.
Once the buffer is empty, normal event processing will resume at the BSS.
Throttling
Throttling permits the system to limit the number of times a specific intermittent alarm is
reported. This reduces the effort required for an operator to individually clear intermittent
alarms.
Only alarms currently on the internal throttle list can be limited. The list is non-configurable.
When throttling is implemented for a specific alarm, the system reports the first occurrence of
the alarm and sets the throttle timer specified in the Throttle table. During that period, the
system counts the number of times the alarm occurs, but does not report the alarm.
If the number of times a specific alarm occurs does not exceed the threshold, the alarm is not
reported again and the counter is reset to 0.
If a throttled alarm occurs after the initial throttle period ends, the alarm is reported again and
the process is repeated. If a throttled alarm occurs during this time period, the number of
suppressed alarms from the previous throttle period is displayed in the alarm message.
68P02901W36-S 4-29
Jul 2008
Alarm types Chapter 4: BSS Software Processes
Alarm types

Untagged and tagged alarms
There are two types of alarms displayed in Alarms windows. They are untagged and tagged.
Untagged
Untagged alarms are not associated with a device reconfiguration.
NOTE
If the alarms consolidation feature is not enabled, all alarms are displayed as
untagged including alarms that are associated with device reconfigurations.
Untagged alarm format
Untagged alarms only include device alarm information in the following format:
#ID-State-Operator-Comment
Alarm Category-Device Class-Device Instance-Time Date
Alarm Code-Clearing Type-Device Severity Cage/Slot
Additional Information
Example
The following example shows an untagged OMC alarm.
#11-SEEN-*NONE*.
processingFailureEvent- BSS-Trunk10-30/03/2000 17:08:56.
[30002] filexferFailed -Intermittent (0)-Major-Invalid file ID
1- 1-11:0:0-30:3:2000
Tagged
Tagged alarms are associated with device reconfigurations and are assigned a configuration tag.
A configuration tag is a unique number assigned by the BSS that identifies the primary alarm
and all secondary alarms.
4-30 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Tagged
Primary alarm
A primary alarm is the alarm identified by the BSS FM as the cause of the reconfiguration.
Secondary alarms
Secondary alarms are related to the alarm that caused the reconfiguration. Primary and
secondary alarms are presented in the same format, but secondary alarms are identified with
Secondary in the reconfiguration line of the tagged alarm message.
The OMC-R CONSOLIDATION environment variable must be set to 1 to display secondary

alarms. The OMC-R CONSOLIDATION environmental variables are listed in Table 4-2.
Table 4-2 OMC-R CONSOLIDATION environmental
Value Descriptions
1 Display both primary and secondary alarms.
2 Display only primary alarms.
3 Display only primary alarms and select the subscriber mode as the default map
display mode.
Tagged alarm format
Both primary and secondary tagged alarms include the following information:
Device alarm information.
Reconfiguration information.
Impact list.
Out-of-service (OOS) device list.
Tagged alarms use the following format:
#ID-State-Operator-Comment
Alarm Category-Device Class-Device Instance-Time Date
Alarm Code-Clearing Type-Device Severity Cage/Slot
Affected FU:Affect
OOS Device List
Additional Information
68P02901W36-S 4-31
Jul 2008
Alarm states Chapter 4: BSS Software Processes
Example
When a tagged alarm is initially reported, the device alarm information is displayed and includes
the *TAGGED* identifier. The following example shows an unexpanded tagged alarm.
#7-SEEN-*NONE*.
communicationFailureEvent -SITE-Trunk10: 20 SITE-29/03/2000 14:25:03.
[0] Last RSL Link Failure-FMIC-Critical-/-.
*TAGGED*.
Tagged alarms can be expanded to present reconfiguration information by highlighting the

tagged alarm then selecting Show from the Alarm Details option on the Alarms pop-up menu.
The following example shows an expanded primary alarm.
#7-SEEN-*NONE*.
communicationFailureEvent -SITE-Trunk10: 20 SITE-29/03/2000 14:25:03.
[0] Last RSL Link Failure-FMIC-Critical-/-.
LMT request -Lock-RSL 0 20-Alarm-Config Tag 4
At the time of the alarm the subscriber impact was:
SITE 20:Loss of Service
SITE 0:Loss of Service
RSL 0 20 -Enabled-Locked-NO REASON.
SITE 20-Disabled-Unlocked -NO REASON.
PATH 0 20-Disabled-Unlocked-NO REASON.
Alarm states
The alarm state indicates the current status of each alarm in the Alarm window. This allows the
operator to quickly determine what actions are required, if any, are required to clear the alarm.
NEW
When an alarm is received by the OMC-R, it is automatically assigned the NEW state. This
indicates that the alarm was received but has not been acknowledged.
SEEN
When a NEW alarm is selected by an operator, its status is changed from NEW to SEEN. This
indicates that the alarm has been acknowledged by an operator.
HANDLING
When an operator selects start the alarm resolution process, the operator must change the
alarm status to HANDLE. This indicates to anyone reviewing the Alarms window that action is
being taken to resolve the alarm.
4-32 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Alarm categories
CLEARED
When the condition that caused the alarm is resolved, the alarm status is changed to CLEARED.
The system will automatically clear FMIC alarms. Other alarms require operator action to
change the status to CLEARED.
Alarm categories
Alarm categories identify the general area affected by an alarm.
The category names used in this manual are a simplified representation of the naming
convention used in the OMC-R. Minor differences exist in the naming conventions used in the
OMC-R and BSS. The following table displays the naming conventions used in this manual,
the OMC-R and the BSS.
Manual OMC-R BSS

Communication communicationFailureEvent Communication
Quality of Service qualityofserviceFailureEvent Quality of Service
Processing processingFailureEvent Processing
Equipment equipmentFailureEvent Equipment
Environmental environmentFailureEvent Environmental
Link linkFailureEvent Equipment
Communication
A Communication alarm indicates a fault in the transfer of data from one point to another.
Quality of Service
A Quality of Service alarm indicates a degradation in the quality of service.
Processing
A Processing alarm indicates a software or processing fault.
Equipment
An Equipment alarm indicates a hardware failure.
Environmental
An Environmental alarm indicates a change occurred in a physical location.
68P02901W36-S 4-33
Jul 2008
Alarm severity Chapter 4: BSS Software Processes
Link
A Link alarm indicates a fault exists in the X.25 link connection between the OMC and a
network element.
Alarm severity
Each alarm generated by the system is assigned a severity indicating the impact of the fault
condition. The alarm severity is used to establish fault handling priority.
Critical
A critical alarm indicates a loss of service that requires immediate resolution.
Major
A major alarm indicates a loss of capacity that requires immediate resolution, but with less
urgency than a critical alarm.
Minor
A minor alarm indicates a loss of redundancy. Resolution on minor faults does not require
immediate resolution. Minor alarms should be resolved to avoid a more serious fault.
Investigate
An investigate alarm indicates the severity of the fault cannot be determined. Investigate alarms
require operator analysis to determine the impact of the fault causing the alarm.
Clear
This severity indicates the fault condition that caused a previously reported alarm has been
resolved.
Clearing types
After a fault condition is resolved, the alarm must be cleared at the OMC-R. There are three
alarm clearing types.
Intermittent
Intermittent alarms are transient and not usually associated with a serious fault condition.
After the intermittent alarms are displayed in the Alarm window, the operator must handle
and clear the alarm.
4-34 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Clearing types
FMIC
FMIC alarms are automatically cleared by Fault Management when the fault condition that
caused the alarm is resolved. The system will report every occurrence of an FMIC alarm.
OIC
OIC alarms must be cleared by the OMC-R operator after the fault condition that caused the
alarm is resolved. The system will only report an OIC alarm once.
68P02901W36-S 4-35
Jul 2008
Enhanced Circuit Error Rate Monitor Chapter 4: BSS Software Processes
Enhanced Circuit Error Rate Monitor

Enhanced Circuit Error Rate Monitor function
The Enhanced Circuit Error Rate Monitor (ECERM) optional feature provides a means for
identifying when discontinuity is detected on a circuit. The customer can:
Reduce cost of ownership.
Reduce downtime of devices.
Enhance system operability.
Enhance quality of service.
A circuit is considered to be the path along which a connection is made, from the entry point in
the BSS (for example, a radio at the BTS) to the exit point in the BSS (for example, the MMS
timeslot that connects to the MSC or PCU).
The circuit error rate monitor is used to monitor the continuity and sanity of hardware
processing elements in a circuit, on a per call basis. Whenever a discontinuity is detected for a
circuit during a call, error counts are updated for the points monitored for the call. When the
error count at a particular monitoring point reaches or exceeds an operator specified threshold,
an alarm is generated. The alarm contains information identifying the monitored path in which
the error is detected, thus allowing the operator to identify potentially faulty devices.
Enhanced Circuit Error Rate Monitor points
The ECERM function enables monitoring at various points in a GSM network circuit, thus
improving the ability of an operator to narrow down where a faulty device may be located.
Although having these monitoring points in the circuit path narrows down the list of potentially
faulty devices, it does not confirm that a device is faulty. It is still up to the operator to
determine which device is faulty.
The following points in a network can be monitored on a per timeslot basis:

Circuit Identity Codes (CICs) on a link between the RXCDR or BSC and the MSC.
ATER Channel Identifier (ACI) groups on a link between the RXCDR and the BSC.
GPRS Circuit Identifier (GCI) groups on a link between the BSC and the PCU.
Radio Channel Identifiers (RCIs) in the radio hardware.
Path Identity Codes (PICs) on a link between the BSC and a BTS.
4-36 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Enhanced Circuit Error Rate Monitor points
Examples of the location of these monitored points can be seen in Figure 4-4 and Figure 4-5.
Figure 4-4 PCU and local transcoding system showing CERM monitor point links
PICs are measured on a from-BSC-to-site basis. For example, in a path leading from a BSC to
two daisy chained BTSs, the PIC for the second BTS encompasses the path through the first
BTS to the BSC.
68P02901W36-S 4-37
Jul 2008
Enhanced Circuit Error Rate Monitor points Chapter 4: BSS Software Processes
Figure 4-5 Remote XCDR and BTS system showing CERM monitor point links
4-38 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Circuit error rate message flow
Circuit error rate message flow
Figure 4-6, Figure 4-7 and Figure 4-8 show the message flows that result from the following
events with Circuit error rate monitoring unrestricted:
CIC and RCI alarm activation for remote BTS circuit error reporting after threshold
exceeded.
Circuit Error Rate alarm clearing message flow.
Circuit Error Rate Monitor alarm resynchronization with the OMC-R.
68P02901W36-S 4-39
Jul 2008
Circuit error rate message flow Chapter 4: BSS Software Processes
Figure 4-6 CIC and RCI alarm activation message flow for remote BTS
4-40 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Circuit error rate message flow
Figure 4-7 Circuit error rate monitor alarm clearing message flow
Figure 4-8 Circuit error rate monitor alarm resync with OMC
68P02901W36-S 4-41
Jul 2008
System impact Chapter 4: BSS Software Processes
System impact
The Circuit Error Rate Monitor generates alarms that include a number of reports to help BSS
operators locate faulty hardware in the BSS network. Each report is displayed at the BSS and
sent to the OMC-R.
4-42 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GPRS Quality of Service (QoS)
GPRS Quality of Service (QoS)

Introduction
The GPRS Quality of Service feature provides varying levels of service, which guarantee
different probabilities of access to the network and different throughputs of data when the
network is accessed.
It is achieved by the following techniques:

Appropriate admission control and retention.
Appropriate minimum bit rate enforcement.
PFC-bit negotiation with the SGSN
The PCU determines whether to enable or disable QoS functionality before any data traffic is
handled. The state of QoS functionality is determined by the database parameter bssgp_pfc_bit
and PFC-bit negotiation with the SGSN over the Gb interface.
As a precondition, bssgp_pfc_bit has to be 1 before PFC-bit negotiation with the SGSN. If the
SGSN also supports PFM procedures, the PFC-bit negotiation is said to be successful and
the QoS functionality is enabled throughout the PCU. Otherwise, an unsuccessful PFC-bit
negotiation would disable the QoS functionality for the PCU.
Once the state of the QoS functionality is established (enabled or disabled), the PCU carries
the data traffic accordingly.
GPRS QoS Traffic classes
The two most significant factors that influence quality of a service are:
Delay
Throughput
Four traffic classes are defined to accommodate the need for different levels of these factors
for different applications:
Conversational
Streaming
Interactive
Background
68P02901W36-S 4-43
Jul 2008
Traffic Handling Priority (THP) Chapter 4: BSS Software Processes
The BSS has internally defined additional traffic classes created by grouping similar PFC
characteristics:
Short-Term Non-Negotiated Traffic (STNNT)
Pre-admission PFC (PAP)
QoS Disabled
Traffic Handling Priority (THP)
Traffic Handling Priority (THP) provides a mechanism to differentiate services among different
PFCs that may or may not belong to the same user.
Three priorities are defined in the standards for handling the traffic pertaining to the interactive
traffic class only (THP1, THP2 and THP3). For the BSS, these priorities determine relative
throughput assigned to a particular Packet Flow Context (PFC). This is achieved by applying
relative weights defined at a BSS level for each priority. These weights are user-configurable.
In addition, a fourth and a fifth THP are defined internally by the BSS for the Background (BG)
and Best Effort (BE) traffic classes respectively. These values are also user-configurable. The
assigned weights for these internally defined THPs act relative to the three THPs that are
defined for the interactive traffic class by the standards.
Minimum Throughput Budget Requirement (MTBR)
Minimum Throughput Budget Requirement (MTBR) is a non-standards based BSS parameter

associated with each PFC. The MTBR of a given TBF is the sum of MTBRs of all the PFCs
multiplexed on that TBF.
The MTBR allows the BSS to admit each PFC if a minimum budget for resources can be met.
The MTBR is subjected to a minimum of 2 kbps for each admitted PFC (a PFC is admitted
without and associated MTBR). Users can configure the MTBR in both the uplink and downlink
directions separately.
The MTBR is measured as throughput at the RLC/MAC layer without factoring in the Block
Error Rate (BLER) and unsolicited retransmissions. It is a budgeting guideline for the admission
control mechanism which helps to ensure no more users are admitted than the system can
handle without compromising service. MTBR will not be achieved by a TBF with insufficient
data to transmit.
The MTBR is set and regulated in terms of throughput at the RLC/MAC layer. Throughputs at
the application layer will be lower than the RLC/MAC throughput due to overhead consumed by
the headers and retransmissions at the intermediate layers and the application layer.
Admission control and retention
Allocation Retention Priority (ARP) Rank is defined as a QoS attribute, maintained per PFC,
that provides prioritized allocation and retention. It is a subscription parameter and therefore
non-negotiable by the network entities.
ARP value is a per-mobile parameter. Each mobile can have up to one ARP value, chosen as the
first ARP value derived from the first non-, non-PAP PFC for the mobile.
4-44 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Admission control and retention
ARP value ranges from 1 to 3 with 1 being the highest priority. The BSS maps the ARP value and
the traffic class into ARP Rank as shown in Table 4-3. The BSS uses ARP Rank to determine
which PFCs have priority access to the system. ARP Rank 6 is higher priority than ARP Rank 1.
Table 4-3 ARP mobile selection (ARP Rank) order
THP
ARP value 1 2 3 BE BG
1 6 6 6 6 3
2 5 5 5 5 2
3 4 4 4 4 1
Admission Control determines which PFCs get access to the system and which PFCs get
preempted from the system to make room for higher ARP Rank PFCs.
The BSS attempts to grant a Pre-Admission PFC (PAP) access to the system according to the
Procedure 4-1:
Procedure 4-1 PAP access
1 The BSS grants PAP access if the PFC MTBR can be met at the timeslot
zone and at the PRP board levels and if sufficient radio resources (timeslots
and USFs) exist in the cell.
2 If the BSS cannot meet the PFC MTBR, the BSS first considers downgrading
PFCs of a lower ARP Rank to a lower THP (with a lower MTBR) to make
room for the new PFC.
3 If insufficient lower ARP Rank PFCs exist to be downgraded to make

sufficient room, the BSS will next consider preempting PFCs of a lower ARP
Rank to make room.
4 If insufficient lower ARP Rank PFCs exist to be preempted to make sufficient

room, the BSS next attempts to downgrade the entering PFC to a lower THP
(presumably with a lower MTBR).
5 If the PFC MTBR still cannot be met, the PFC is rejected.
The BSS can do a combination of downgrading and preemption of lower ARP Rank PFCs. In
the extreme case, the BSS can preempt all of the lower ARP Rank MSs and downgrade the
entering PFC.
When the PFC is admitted, the BSS can trigger multiple reschedules for PFCs in the same
cell, PFC preemptions in the same cell or in the cells sharing the same PRP board, or any
combination of the above.
Retention occurs when the size of the MTBR resource pool shrinks due to a loss of timeslots.
When the size of the MTBR resource pool shrinks, the BSS is unable to meet the MTBR
commitments it had made to all of the PFCs in the pool. The BSS preempts one or more lower
ARP Rank PFCs from the pool so it can meet its MTBR commitments to the higher ARP Rank
PFCs.
68P02901W36-S 4-45
Jul 2008
Pre-admission PFCs (PAP) Chapter 4: BSS Software Processes
Pre-admission PFCs (PAP)
While the BSS waits for the negotiation of QoS parameters of an unrecognized PFC for an MS to
complete, the BSS handles the traffic for this PFC using an MTBR of 0 and a configured THP
weight of 10-40 (using configured THP weight for Best Effort traffic class). No admission control
or preemption is performed on such MSs until the Aggregate BSS QoS Profile (ABQP) is known.
If SGSN fails to respond back to the BSS with a CREATE-BSS-PFC for a PAP after the BSS
attempted four times (1 attempt and 3 retries), the BSS treats the PFC as a pre-defined Best
Effort.
NOTE
The BSS can still receive data for this PFC (in the downlink, or in the uplink) tagged
with the Packet Flow Identifier (PFI) associated with such a PFC. The BSS does not
initiate any more DOWNLOAD-BSS-PFC procedures on this PFC.
A percentage of resources in the cell is reserved for Short Term Non-Negotiated Traffic
(headroom), that is, SMS and signaling. This traffic uses a THP weight of 40 but has an MTBR
of 0. This allows minimal effects on TBF scheduling for long term traffic while enabling the
utilization of resources in the cell for short term signaling and SMS. Also, with an MTBR of 0,
the PFCs for this traffic class have a very high probability of being admitted.
NOTE
This only applies to the mobiles that support PFC procedures. These PFCs cannot be
candidates for preemption because of their shorter life as STNNTs.
QoS Profile; Aggregate BSS QoS Profile (ABQP)
QoS profile is a single information element comprising a number of attributes. QoS Profile is
dubbed Aggregate BSS QoS Profile (ABQP) when signaled to the BSS over the Gb interface. The
following attributes of ABQP are currently meaningful to the BSS:
Traffic Class.
Traffic Handling Priority.
Precedence Class (when the operator chooses this to be mapped to ARP).
4-46 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Packet Flow Context (PFC)
Packet Flow Context (PFC)
A Packet Flow Context is managed by PFM procedures over the Gb interface. It describes
multiple PDP Contexts with an associated ABQP and is identified by a Packet Flow Identifier
(PFI). A BSS PFC is created or modified through Gb messages. The BSS may negotiate a
downgraded ABQP amid resource shortage.
There are three predefined PFCs whose ABQP is non-negotiable.
Table 4-4 lists the Packet Flow contexts.
Table 4-4 Packet Flow contexts
PFC PFI
Best Effort 0
Signaling 1
GPRS-SMS 2
[Reserved] 37
[Dynamically assigned] 8127
An MS user may establish multiple PFCs through activating multiple PDP contexts. The SGSN
may aggregate similar negotiated PFCs for the same user into one PFC and assign them the
same PFI.
All traffic (PDUs) passing through the BSS with a particular PFI is handled according to the
ABQP in the associated PFC. However, there is a limitation over the air interface for both uplink
and downlink, for example lack of support for a separate TBF for each PFC.
In uplink, the MS has the ability to signal PFI through PRR during TBF establishment with
2-phase access. For TBF establishment with 1-phase access, the MS indicates the PFI along
with the TLLI in the uplink data blocks till contention is resolved on the MSs side. The MS may
also include PFI in PDAK and EPDAK messages for requesting uplink resources during ongoing
downlink TBF. The MS may also signal a change in the PFI during ongoing uplink TBF by
sending a PRR including the new PFI, at most, on every LLC PDU basis. The MS may also signal
a change in the PFI during ongoing uplink and downlink TBF by including a PFI IE with or
without a Channel Request IE in PDAK/EPDAK.
An uplink TBF is operated according to the THP and MTBR of the highest ranked PFC in either
the uplink or downlink direction. The BSS, otherwise, is current on which PFC a particular LLC
PDU belongs to. The BSS tags the UL-UNITDATA PDU with the latest PFI sent by the MS.
When the BSS does not know the PFC associated with a PFI, it requests a DOWNLOAD-BSS-PFC
to the SGSN. Meanwhile, it handles the traffic (PDUs) according to policy for Pre-admission
PFCs. Once the PFC is created on the BSS through CREATE-BSS-PFC message, the BSS is
required to handle the traffic according to the ABQP provided in the PFC.
68P02901W36-S 4-47
Jul 2008
Scheduler Beta () Chapter 4: BSS Software Processes
Preempting / Rejecting PFCs
Rejecting or preempting a PFC triggers the network to perform 2-phase access for a period
determined by the parameter gprs_par_wait_ind plus 5 seconds to account for maximum
queuing delay in UL/DL requests. For the first rejection of a PFC, a one-phase RACH is
discarded; no IAR is sent to the MS. In the case of a 2-phase RACH, the network sends the MS a
PAR with no wait time. If upon the next 2-phase RACH the PFC is again rejected, the network
continues to force 2-phase access for another gprs_par_wait_ind plus 5 seconds. At the same
time, PAR with a wait time of gprs_par_wait_ind seconds is sent to the MS. Forcing 2-phase
access has the effect on enabling the network some control of the access request of other PFCs,
thus reducing congestion.
Regardless of being the only PFC for an MS or one of many, there is no action taken on the Gb
link once a PFC is chosen to be preempted. However, when rejecting the only PFC for an
MS, data is discarded only for that PFC for gprs_par_wait_ind seconds. During this time, all
downlink data belonging to this PFC for this MS is also discarded at the BSS.
When an MS has multiple PFCs and the PFC is rejected, the ABQP is cleared and any downlink
data is discarded only for that PFC (data for this PFC continues in the uplink since the PFI
tagging in the uplink is not reliable). The THP and MTBR commitments for the MS are updated
to reflect the rejected PFC.
NOTE
When 64k resources are not available, EGPRS mobiles with low priority are preempted
and moved from 64k PDs to 16k/32k PDs. This procedure may also cause rejections.
Scheduler Beta ()
When a TBF is operating above its MTBR, b=1 operation weighted by THP weights distributes
available blocks proportional to the THP weight of each TBF. After all TBFs on the timeslot have
achieved MTBR, excess bandwidth is distributed by normalizing total transmission opportunities
(in blocks) in proportion to the THP weights.
When QoS feature is enabled, the BSS attempts to schedule TBFs such that all of them meet
their MTBR. The overall bandwidth (in radio blocks) is then distributed fairly among TBFs
interleaved on same PDCHs, such that each TBF gets blocks proportional to its THP weight. The
throughput depends on the coding scheme of the TBF.
System behavior when QoS feature is disabled
When QoS is disabled, all MSs are effectively treated equally and have equal scheduling
priority: no MTBR, equal THP weight and preemption (ARP) is disabled that is they are served
on a first come, first serve basis. If the BSS receives a PFI, either from the SGSN in the
DL-UNITDATA PDU or from the MS in the uplink, the BSS ignores the PFI and treat the MS
as described above in this section.
4-48 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Capacity
Capacity
This feature retains the 120 MS per PRP board limit. However, this feature can affect the overall
capacity of the PRP board. Each PRP board has a capacity in terms of MTBR. On reaching that
capacity, no more non- MSs or PFCs can be admitted without preempting other PFCs. There is a
compromise between the number of MSs being serviced and the MTBR of the PFCs of the MSs
being serviced. If the MTBR of the various traffic classes are set to high values, or there are
multiple PFCs per MS, fewer MSs can be serviced per PRP board.
When the BSS is managing its pool of MTBR resources, it reserves headroom so that each PFC
has a high probability of meeting its MTBR regardless of coding scheme changes and short-term
PFCs (such as PAP and) can be allowed to enter the system.
The headroom is managed on two distinct levels.
The first level of headroom is at local timeslot zone. The BSS reserves headroom within a
local zone of timeslots such that coding scheme changes by any MS within that local zone of
timeslots, or addition of a or PAP MS to that local zone of timeslots, does not affect the ability of
the MSs within that local zone of timeslot to meet their MTBR requirements.
The second level of headroom is at the PRP board. This is headroom on the PRP board's ability
to service 30 timeslots of throughput. Some of this throughput is reserved for coding scheme
changes and PAP MSs.
When admitting a new MS, the BSS verifies that there is sufficient headroom at both these
levels. If there is insufficient headroom to admit the new MS, other MSs may be downgraded
and/or preempted and the requesting MS may also be downgraded or rejected.
The amount of MTBR throughput that is available on each timeslot to commit to the MSs is a
function of the number of MSs scheduled on that timeslot. In the maximum case, 8 kbps of MTBR
can be allocated per GPRS timeslot. EGPRS timeslots have a limit of 14 kbps if all non-EGPRS
MSs on the timeslot are limited to PAP PFCs only, or all MSs on the timeslot are EGPRS capable.
MTBR Allocation
The BSS attempts to maintain its MTBR commitments to PFCs in order of priority by ARP
Rank. The BSS attempts to ensure the ARP Rank ordering of MTBR commitments through
downgrading and preemption.
Per Timeslot Commitment
The BSS commits a maximum of 6 kbps of MTBR for GPRS and 12 kbps for EGPRS, in the
downlink and in the uplink per timeslot on the air interface when there are less than four MSs
allocated on the timeslot. This maximum commitment per timeslot is independent of the type of
backhaul or the current coding schemes of the MSs. The remaining throughput on the timeslot
above the commitment is headroom and is allocated to the MSs according to THP weights. For
timeslots configured as PCCCH timeslots, the BSS commits 0 kbps of MTBR on that timeslot.
PCCCH timeslots share both user data and control signaling. Therefore the BSS does not
make any MTBR commitments on the PCCCH timeslot. Large amounts of control signaling
transmitting (which is higher priority than user data) would prevent the BSS to maintain MTBR
on this timeslot.
68P02901W36-S 4-49
Jul 2008
MTBR Allocation Chapter 4: BSS Software Processes
In order to admit 4 MSs per timeslot (required to satisfy 120 MSs per PRP board), some of the
headroom on each timeslot may be used to admit a fourth MS on to a timeslot, effectively
increasing the committable bandwidth on that timeslot to 8 kbps for GPRS and 14 kbps if all
non-EGPRS MSs on the timeslot are limited to PAP PFCs only, or all MSs on the timeslot are
EGPRS capable.
This increase only occurs to admit a fourth MS and is not done for any other number of MSs
on the timeslot, as using this headroom may allow individual PFCs to operate further from
prescribed MTBR within the tolerance band, as dictated by PDAK polling rates. This timeslot
MTBR commitment forms the basis for the MTBR allocation. It is driven by the headroom,
which allows the MTBR commitments to be maintained regardless of any coding scheme
changes made by the MS.
Each traffic class has an associated MTBR configurable by the user, or is fixed at zero. Within
the Interactive traffic class, each THP has its own associated MTBR which is configurable by
the user. The MTBR of THP 2 must be less than or equal to the MTBR of THP 1 and the MTBR
of THP 3 must be less than or equal to the MTBR of THP 2.
For all traffic classes except for Interactive THP 1 and Interactive THP 2, the maximum MTBR
can be fit into a single timeslot allocation independent of how the MTBR is set. This guarantees
that these classes are not be rejected by the system when timeslots are idle in the cell and
available throughput exists on the PRP board.
Within the Interactive traffic class, the THP 3 class has a maximum MTBR that can be fit into a
single timeslot allocation independent of how the MTBR is set. A THP 3 is not rejected by the
system when timeslots are idle in the cell and available throughput exists on the PRP board.
Both THP 1 and THP 2 support a maximum MTBR of 24 kbps in the downlink and 6 kbps in the
uplink. THP 1 and THP 2 are downgradable to THP3 so that they can fit into a single timeslot
and thus are not rejected by the system when timeslots are idle in the cell and available
throughput exists on the PRP board.
Per MS Commitment
The BSS limits its MTBR commitment to an MS to a value that the MS is capable of supporting.
The BSS allocates a maximum of 6 kbps of MTBR for GPRS and 12 kbps for EGPRS, to the MS in
each direction (UL/DL). If the MS does not support enough timeslots in the downlink direction
to support the MTBR of its requested THP, which can only occur for Interactive THP 1 and
2, the MS is downgraded.
Biasable MS Commitments
The BSS limits its MTBR commitment to a biasable MS (multislot classes 6 and 10 and any
that map to these classes), to the maximum MTBR allowed per timeslot times the number
of timeslots that are fixed in each direction. For GPRS, multislot class 6 is committed to a
maximum of 12 kbps (2 timeslots) in the downlink and 6 kbps (1 timeslot) in the uplink and class
10 is committed to at most 18 kbps (3 timeslots) in the downlink and 6 kbps (1 timeslot) in the
uplink. For EGPRS, multislot class 6 is committed to a maximum of 24 kbps (2 timeslots) in the
downlink and 12 kbps (1 timeslot) in the uplink and class 10 is committed at most 36 kbps (3
timeslots) in the downlink and 12 kbps (1 timeslot) in the uplink.
4-50 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation MTBR Allocation
Per Timeslot Zone Commitment
A timeslot zone is defined as the timeslot allocation of the mobile requesting the PFC being
admitted plus one timeslot on either side of that allocation if there is an overlapping neighbor
mobile on that side with a non-zero TBF MTBR commitment. A mobile has both a downlink and
an uplink local timeslot zone, which are defined independently and the same methodology is
applied for both directions. For each TBF in the local timeslot zone, the TBFs MTBR is assumed
to be divided equally among all timeslots assigned to that TBF. If the PFC being admitted has a
0 kbps MTBR and this is the only PFC for the mobile, the mobile does not have an associated
timeslot zone.
The BSS limits its MTBR commitment to a timeslot zone to 6 kbps of MTBR for GPRS and 12
kbps for EGPRS, of MTBR in the downlink and in the uplink per timeslot in that timeslot zone
unless scheduling the fourth MS on that timeslot. When scheduling the fourth MS on a timeslot,
the BSS allows a commitment to be 8 kbps for GPRS and 14 kbps for EGPRS on all timeslots
where there are four MSs assigned.
Per PRP Board Commitment
The BSS limits its MTBR commitment to a PRP to 25 active timeslots of throughput in either
direction. The remaining 5 timeslots are reserved as headroom for PAP MSs and for coding
scheme changes. The total committable bandwidth is a function of the coding schemes of
the MSs on the board.
68P02901W36-S 4-51
Jul 2008
Quality of Service (QoS) Phase 2 Chapter 4: BSS Software Processes
Quality of Service (QoS) Phase 2

{27703A}
Introduction
The Quality of Service Phase 2 is a restricted feature and requires the GSR8 QoS feature to be
unrestricted. This feature is achieved by the following techniques:
Appropriate admission control and retention.
Appropriate maximum bit rate enforcement.
This feature is enabled or disabled at the BSS using the parameter qosP2Opt. The maximum
bit rate enforcement is enabled using the parameter qos_mbr_enabled.
QoS Phase 2 Traffic classes
The two most significant factors that influence quality of a service are:
Delay
Throughput
Four traffic classes are defined to accommodate the need for different levels of these factors
for different applications:
Conversational
Streaming
Interactive
Background
The BSS has internally defined additional traffic classes created by grouping similar PFC
characteristics:
Pre-admission PFC (PAP)
Best Effort (BE)
The QoS phase 2 feature provides support for streaming class. The support for streaming
traffic class allows to specify a service requiring constraints on delay and jitter, and minimum
bit rate. Support for PFCs requesting streaming traffic class can be enabled or disabled using
the streaming_enabled parameter. If support for streaming traffic class is disabled, BSS still
tries to admit the streaming traffic classes as one of the matching interactive traffic classes
(determined based on the MTBR settings defined in the GSR8 QoS implementation).
4-52 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Traffic Handling Priority (THP)
The key requirements for support for streaming are:

Support for transfer delay and Guaranteed Bit Rate attributes from the ABQP.
Admission Control
Streaming users that cannot be admitted with the requested Guaranteed Bit Rate and
transfer delay characteristics are negotiated appropriately.
Manage and control separate flow control buffers per PFC/Traffic class negotiated for
each mobile.
Modification of PCU Scheduling algorithms to take streaming class delay/throughput

characteristics into account.
Support for ARP IE (Information Element) as defined in Release6 3GPP specifications.
Traffic Handling Priority (THP)
Traffic Handling Priority (THP) provides a mechanism to differentiate services among different
PFCs that may or may not belong to the same user.
Fourteen priorities are defined in the standards for handling the traffic pertaining to the
interactive traffic class. For the BSS, these priorities determine relative throughput assigned to
a particular Packet Flow Context (PFC). THP weight of the streaming traffic class is determined
by the parameter thp_stream_weight. When streaming_enabled parameter is equal to 1,
this parameter can not be changed.
Guaranteed Bit Rate (GBR)
Guaranteed Bit Rate as per the 3GPP specification is defined as the guaranteed number of
bits delivered at a SAP within a period of time divided by the duration of the period. For the
GPRS RAN, the GBR is defined as the bit rate at the LLC layer. The GBR for each PFC is an
extension of the Minimum Throughput Budget Requirement (MTBR) concept except that the
GBR needs to be enforced as a true guarantee and not just a commitment. The MTBR is
measured as the raw air throughput at the RLC/MAC layer whereas the GBR measurements
exclude any RLC retransmissions.
Transfer delay
Transfer delay indicates maximum delay for 95th percentile of the distribution of delay for all
delivered SDUs during the lifetime of a bearer service. Delay for an SDU is defined as the time
from a request to transfer an SDU at one SAP to its delivery at the other SAP. Transfer delay of
an arbitrary SDU is not meaningful for a bursty source. It is applicable only to real time traffic
classes streaming/conversational. In addition, the transfer delay for Radio Access Bearer is
smaller than the overall requested transfer delay as transport through the core network uses a
part of the acceptable delay.
68P02901W36-S 4-53
Jul 2008
Admission control and retention Chapter 4: BSS Software Processes
Admission control and retention
Allocation Retention Priority (ARP) IE is defined as a QoS attribute in GSR8, maintained per
PFC, that provides prioritized allocation and retention. It is a subscription parameter and
therefore non-negotiable by the network entities.
In GSR9, the BSS is enhanced to include changes based on R6 standards. One of the key
modifications in the R6 standards is the ability of the SGSN to communicate the ARP using the
ARP IE as a part of the BSS Create PFC procedures. If this IE is received, the BSS considers
the priority level of the requested PFC when deciding on the resource allocation. If the ARP IE
is not provided in the Create PFC PDU by the SGSN, parameters are provided to configure
the ARP based on precedence class for all traffic classes/PFCs for which the ARP IE is not
received from the SGSN.
The priority, Preemption Capability indicator (pci) and Preemption Vulnerability indicator
(pvi) attributes of the ARP IE are supported. The queuing allowed indicator (qa) is not
supported by the BSS. The BSS provides the same level of configurability using the attributes
shown in Table 4-5 for the cases where the BSS does not receive the ARP IE attribute from
the SGSN (SGSN may not be R6 compatible or may not include the optional ARP IE in the
CREATE-BSS-PFC message).
Table 4-5 BSS ARP configuration parameters
Precedence class Traffic class

Streaming or Interactive or Best
Background
Conversational Effort
0 arp_streaming_1 arp_i_be_1 arp_bg_1
1 arp_streaming_2 arp_i_be_2 arp_bg_2 license_
release (print
publishing)
2 arp_streaming_3 arp_i_be_3 arp_bg_3
QoS Profile; Aggregate BSS QoS Profile (ABQP)
QoS profile is a single information element comprising a number of attributes. QoS profile is
known as Aggregate BSS QoS Profile (ABQP) when signaled to the BSS over the Gb interface.
The following attributes of ABQP are currently meaningful to the BSS:
Traffic Class.
Traffic Handling Priority.
Precedence Class (when the operator chooses this to be mapped to ARP).
Transfer delay.
GBR.
MBR.
Maximum SDU size.
4-54 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Packet Flow Context (PFC)
Packet Flow Context (PFC)
A packet flow context is managed by PFM procedures over the Gb interface for the non real
time traffic classes based on operator controlled configuration parameter pfm_sig_enabled. It
describes multiple PDP Contexts with an associated ABQP and is identified by a Packet Flow
Identifier (PFI). A BSS PFC is created or modified through Gb messages. The BSS negotiates a
downgraded ABQP when there is resource shortage.
Preempting / Rejecting PFCs
Upon detecting congestion scenarios, PFC downgrades or preemptions are performed

based on operator controlled configuration parameters mtbr_downgrade_enabled and
stream_downgrade_enabled. The congestion scenarios result in the available resource pool
becoming smaller than the resources required to satisfy all admitted PFCs.
Capacity
This feature retains the 120 MS per PRP board limit; however, this feature can affect the overall
capacity of the PRP board. Each PRP board has a capacity in terms of MTBR, when that capacity
is reached, no more MSs or PFCs can be admitted without preempting other PFCs first. There is
a compromise between the number of MSs being serviced and the MTBR of the PFCs of the MSs
being serviced. If the MTBR of the various traffic classes are set to high values, or there are
multiple PFCs per MS, fewer MSs will be able to be serviced per PRP board.
The amount of MTBR throughput that is available on each timeslot to commit to the MSs is
a function of the number of MSs scheduled on that timeslot. In the maximum case, 8 kbps
of MTBR can be allocated per GPRS timeslot. EGPRS timeslots have a limit of 14 kbps if all
non-EGPRS MSs on the timeslot are limited to and PAP PFCs only, or all MSs on the timeslot
are EGPRS capable.
If mtbr_downgrade is disabled then non-real time PFCs of lower ARP are preempted, and if
stream_downgrade is disabled then streaming PFCs of lower ARP are preempted.
MTBR Allocation
The BSS attempts to maintain its MTBR commitments to PFCs in order of priority by ARP IE.
The BSS attempts to ensure the ARP IE ordering of MTBR commitments through downgrading
and preemption.
68P02901W36-S 4-55
Jul 2008
MTBR Allocation Chapter 4: BSS Software Processes
Per Timeslot Commitment
The BSS commits a maximum of 6 kbps of MTBR for GPRS and 12 kbps for EGPRS, in the
downlink and in the uplink per timeslot on the air interface when there are less than four
MSs allocated on the timeslot. This maximum commitment per timeslot is independent of
the type of backhaul or the current coding schemes of the MSs. The remaining throughput
on the timeslot above the commitment is headroom and is allocated to the MSs according
to THP weights. For timeslots configured as PCCCH timeslots, the BSS commits 0 kbps of
MTBR on that timeslot. PCCCH timeslots share both user data and control signaling; therefore
the BSS does not make any MTBR commitments on the PCCCH timeslot. Large amounts of
control signaling transmitting (which is higher priority than user data) would prevent the BSS
to maintain MTBR on this timeslot.
In order to admit 4 MSs per timeslot (required to satisfy 120 MSs per PRP board), some of the
headroom on each timeslot may be used to admit a fourth MS on to a timeslot, effectively
increasing the committable bandwidth on that timeslot to 8 kbps for GPRS and 14 kbps if all
non-EGPRS MSs on the timeslot are limited to and PAP PFCs only, or all MSs on the timeslot
are EGPRS capable.
This increase only occurs to admit a fourth MS and is not done for any other number of MSs
on the timeslot, as using this headroom may allow individual PFCs to operate further from
prescribed MTBR within the tolerance band, as dictated by PDAK polling rates. This timeslot
MTBR commitment forms the basis for the MTBR allocation. It is driven by the headroom,
which allows the MTBR commitments to be maintained regardless of any coding scheme
changes made by the MS.
Each traffic class has an associated MTBR configurable by the User, or is fixed at zero. Within
the Interactive traffic class, each THP has its own associated MTBR which is configurable by
the User. The MTBR of THP 2 must be less than or equal to the MTBR of THP 1 and the MTBR
of THP 3 must be less than or equal to the MTBR of THP 2.
For all traffic classes except for Interactive THP 1 and Interactive THP 2, the maximum MTBR
can be fit into a single timeslot allocation independent of how the MTBR is set. This guarantees
that these classes will not be rejected by the system when timeslots are idle in the cell and
Within the Interactive traffic class, the THP 3 class has a maximum MTBR that can be fit into a
single timeslot allocation independent of how the MTBR is set. A THP 3 will not be rejected
by the system when timeslots are idle in the cell and available throughput exists on the PRP
board. THP 1 and THP 2 both support a maximum MTBR of 24 kbps in the downlink and 6
kbps in the uplink. THP 1 and THP 2 are downgradable to THP3 so they can fit into a single
timeslot and thus will not be rejected by the system when timeslots are idle in the cell and
Per MS Commitment
The BSS limits its MTBR commitment to an MS to a value that the MS is capable of supporting.
The BSS allocates a maximum of 6 kbps of MTBR for GPRS and 12 kbps for EGPRS, to the MS in
each direction (UL/DL). If the MS does not support enough timeslots in the downlink direction
to support the MTBR of its requested THP, which can only occur for Interactive THP 1 and 2,
the MS will be downgraded.
4-56 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation MTBR Allocation
Biasable MS Commitments
The BSS limits its MTBR commitment to a biasable MS (multislot classes 6, 10, 11 and 12 and
any that map to these classes), to the maximum MTBR allowed per timeslot times the number
of timeslots that are fixed in each direction. For GPRS, Multislot class 6 is committed to a
maximum of 12 kbps (2 timeslots) in the downlink and 6 kbps (1 timeslot) in the uplink and class
10 is committed to at most 18 kbps (3 timeslots) in the downlink and 6 kbps (1 timeslot) in the
uplink. For EGPRS, Multislot class 6 is committed to a maximum of 24 kbps (2 timeslots) in
the downlink and 12 kbps (1 timeslot) in the uplink and class 10 is committed at most 36 kbps
(3 timeslots) in the downlink and 12 kbps (1 timeslot) in the uplink. The multislot class 11 is
committed to a maximum of 12 kbps (2 timeslots) MTBR in the downlink and 6 kbps (1 timeslot)
MTBR in the uplink, and class 12 is committed to a maximum of 6 kbps (1 timeslot) MTBR in the
downlink and 6 kbps (1 timeslot) MTBR in the uplink.
Per Timeslot Zone Commitment
A timeslot zone is defined as the timeslot allocation of the mobile requesting the PFC being
admitted plus one timeslot on either side of that allocation if there is an overlapping neighbor
mobile on that side with a non-zero TBF MTBR commitment. A mobile has both a downlink and
an uplink local timeslot zone, which are defined independently and the same methodology is
applied for both directions. For each TBF in the local timeslot zone, the TBFs MTBR is assumed
to be divided equally among all timeslots assigned to that TBF. If the PFC being admitted has a
0 kbps MTBR and this is the only PFC for the mobile, the mobile does not have an associated
timeslot zone.
The BSS limits its MTBR commitment to a timeslot zone to 6 kbps of MTBR for GPRS and 12
kbps for EGPRS, of MTBR in the downlink and in the uplink per timeslot in that timeslot zone
unless scheduling the fourth MS on that timeslot. When scheduling the fourth MS on a timeslot,
the BSS allows a commitment to be 8 kbps for GPRS and 14 kbps for EGPRS on all timeslots
where there will be four MSs assigned.
Per PRP Board Commitment
The BSS limits its MTBR commitment to a PRP to 25 active timeslots of throughput in either
direction. The remaining 5 timeslots are reserved as headroom for and PAP MSs and for
coding scheme changes. The total committable bandwidth is a function of the coding schemes
of the MSs on the board.
68P02901W36-S 4-57
Jul 2008
Audio volume control at the GDP Chapter 4: BSS Software Processes
Audio volume control at the GDP

Volume increase or decrease
It is possible to increase or decrease the audio level of the speech in both the uplink and
downlink directions by manipulating the database.
As the digital PCM signal arriving at the Generic DSP Processor (GDP) board in the RXCDR
or BSC is essentially a binary representation of an integer value representing the amplitude
of a sound wave at a certain point in time, it is possible to apply a multiplication factor to
this binary value. This factor can either increase or decrease the amplitude as represented
by the binary value.
The effect of this volume change is to give better quality louder calls (in the case of volume
increase) than would be the case with the standard volume control performed at the CCDSP
in the BTS.
Care must be taken when choosing the amount by which to change the volume, as the change is
applied to all PCM signals regardless of their previous volume. For example, if the maximum
increase of 15 dB is applied to already loud audio signals the customer perception may be
negative. The choice of level change can be considered an optimization question.
The advantage of this option is that the volume change is performed at the point of transcoding
(GDP board) rather that at the BTS with an already transcoded signal.
The volume_control_type parameter enables the feature on a per RXCDR or BSC basis. If an
RXCDR is connected to 2 BSCs for example, where one uses volume control and one does not
then all CICs associated with the volume control using BSC must be processed by GDP boards.
In this case the bss_id element of this parameter is used to indicate which BSC is concerned,
using the BSC number specified in add_bss_conn; it therefore follows that add_bss_conn must
be entered before this parameter. Care must also be taken to ensure that the add_channel
command does not connect a CIC from a GDP to a non-volume control BSC. If local transcoding
is being used then the above restrictions do not apply, although GDPs must be used throughout,
in place of XCDR boards.
The volume change is specified by ul_audio_lev_offset for the link and by dl_audio_lev_offset
for the downlink. A range of 30 dB is possible, that is +15 to-15 and it is acceptable to enter the
minus sign in the database.
4-58 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Software patching
Software patching

{25423}
Overview
This feature allows processes running on any Executive/Exec API supported processors to load a
software patch without resetting or restarting the processor.
NOTE
Not all process/platform combinations are supported, for example, none of the
GPROC3-2 PQ2 CPU resident processes (such as MTPL3) when on that platform.
MTPL3 running on a GPROC3 is supported.
A software patch allows changes to be applied to a process in active status. This feature allows
small object changes to be downloaded and updated in real-time without board or network
element outage. Certain software problems can be fixed on the system quickly, without causing
any system outage.
A patch level corresponds to a patch which resolve a single problem or an SR. Applying higher
patch level will make all lower patch levels to be applied on BSS. For example, installation of
patch 4 will make BSS install patches 1 to 4.
A patch object contains one or more patch levels compiled together into an object. A patch
object is identified by a unique code object number, that is, object number 251.
A new version of patch object for the same point release will be generated accumulatively from
the previous version of patch object, that is, the new version of patch object will contain all
software patch levels from the previous version of patch object. New patch levels will be built
on top of the patch levels from the previous version of patch object.
In pre-GSR9 versions of the BSS, all network entities reset in order to upgrade to the new
load. In GSR9, the BSS determines the type of upgrade and communicates it to the OMC. The
type of upgrade is one of:
Full BSC reset (which may or may not include patch object update and/or patch level
update).
PCU upgrade only (which may or may not include patch object update and/or patch level
update).
Software Patch object with possible patch level update.
The BSC, upon receiving the CSFP-Swap, communicates the type of upgrade to the OMC.
The OMC acknowledges with the type of upgrade desired by the user. The BSS continues to
process voice calls and GPRS data sessions until the upgrade type is received by the OMC. The
entire BSC is reset only if Full BSC Reset is chosen. If only a PCU upgrade is required, the
BSC directs the PCU to reset and loads the new software. The BSC does not reset. The voice
calls are not impacted during PCU upgrade.
68P02901W36-S 4-59
Jul 2008
Overview Chapter 4: BSS Software Processes
When Patch Object Upgrade is acknowledged by the OMC, if a new patch object is loaded with
the CSFP download, it is distributed to all network entities.
4-60 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation PCU upgrade without BSC outage
PCU upgrade without BSC outage

{25424}
Overview
Prior to GSR9, a new release of PCU software always caused a full BSC reset, even without any
change to the BSC software load. This feature allows a new software release to be loaded on
the PCU without impacting the BSC. Voice calls are not affected and only GPRS calls drop
while the PCU upgrade occurs. This allows PCU service packs upgrade without impacting
voice call revenue.
The system uses CSFP download and swap procedure to support this functionality. The BSC
recognizes that the BSC objects are not changed. Therefore, the BSC does not reset during the
PCU software upgrade. The PCU downloads the software to CSFP in background mode and
swaps code objects after CSFP code download is complete.
This feature interacts with the Software Patching feature. Therefore, the two features are
implemented together.
68P02901W36-S 4-61
Jul 2008
Feature interactions Chapter 4: BSS Software Processes
4-62 68P02901W36-S
Jul 2008
Chapter
Cells

This chapter provides a description of GSM Cells and how they are implemented in a network.

GSM cells on page 5-3.
Online add, copy and delete cell on page 5-5.
Frequency types on page 5-7.
Base station Identity Code (BSIC) on page 5-13.
GSM control channels on page 5-16.
GPRS traffic and control channels on page 5-33.
Mapping packet data channels on to physical channels on page 5-35.
GPRS reserved and switchable timeslots on page 5-36.
Channel allocation on page 5-39.
Channel release on page 5-48.
GSM flow control on page 5-51.
GPRS flow control on page 5-60.
Mobile System (MS) control on page 5-61.
Cell barring on page 5-63.
Call re-establishment on page 5-66.
Cease transmission when cell goes Out-Of-Service on page 5-67.
Concentric cells on page 5-70.
Encryption on page 5-77.
Discontinuous transmission on page 5-79.
Extended range cell on page 5-82.
68P02901W36-S 5-1
Jul 2008
Feature interactions Chapter 5: Cells
Short message service (cell broadcast) on page 5-86.
Cell selection/reselection on page 5-91.
Network Assisted Cell Change (NACC) on page 5-94.
Network controlled cell reselection (packet data) on page 5-103.
5-2 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GSM cells
GSM cells

About this chapter
This chapter describes the Motorola GSM cell functions and cell construction and explains how
these functions are implemented in the system.
Cell elements
The add_cell MMI command adds the elements of a cell to the Configuration Management
(CM) database. The add_cell command is invoked with the location and GSM cell identifier
parameters. After the command is entered, a series of prompts are presented. Values entered in
response to these prompts are stored in the BSS database.
Many cell elements are defaulted when a cell is added. Such parameters can be changed by the
chg_element or chg_cell_element commands, as can those originally entered by add_cell.
The uses of these parameters are described in this manual as appropriate to the function
descriptions.
Refer to the Installation and Configuration: GSM System Configuration (68P02901W17) manual
for the procedures for adding a cell or changing the cell elements from the OMC-R.
Refer to the Technical Description: BSS Command Reference (68P02901W23) manual for a
detailed description of the commands and parameter format, default values and ranges of values.
Different sites can be equipped with various numbers of cells:

Only one cell is permitted at an M-Cell micro, M-Cell city, Horizon micro or Horizon
compact site. The system rejects the add_cell command if it is entered for any of these
systems, where a cell already exists.
Sites can have up to six cells. The system rejects the add_cell command if it is entered
where six cells already exist.
NOTE
Enter this command at the BSS (OMC-R) only. This command does not work
at a BTS site.
68P02901W36-S 5-3
Jul 2008
GSM Cell ID Chapter 5: Cells
GSM Cell ID
The GSM Standard specifications require that GSM Cell ID be unique for all cells in the world.
GSM Cell ID consists of four identifiers: Mobile Country Code (MCC), Mobile Network Code
(MNC), Location Area Code (LAC) and Cell Identity (CI).
Currently, the OMC assumes the MNC and MCC to be the same for cells within the same BSS.
The interface between the OMC and BSS reflects this assumption and only the LAC and CI are
sent over the OMC-BSS interface when sending GSM Cell ID information.
Since multiple cells can exist in a BSS with the same LAC and CI, but having different MCC
and/or MNC, the LAC and CI is not sufficient to uniquely identify a cell in a BSS. The GSM
Cell ID feature overcomes this by sending the full GSM Cell ID (MCC, MNC, LAC, CI) when
transmitting cell information.
With the addition of UTRAN neighbors as a result of the Inter RAT handover feature it is
possible for GSM cells to have 3G external neighbors. The BSS database allows the provisioning
of UTRAN cells to be specified as neighbors of existing GSM cells. It is essential that the OMC
to BSS interface support full UTRAN Cell IDs in the case of a UTRAN neighbor of a GSM cell.
Both OMC and BSS send full Cell IDs over the OMC to BSS interface.
5-4 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Online add, copy and delete cell
Online add, copy and delete cell

Online add, copy or delete cell functions
Cells can be added and deleted within a site while the site is INS (IN Service). A cell in one site
can be copied to another site while both sites remain INS. Call processing service is only affected
on the modified cell if necessary and call processing service on the other cells is not affected.
Previously, a cell could only be added to or removed from a site within the BSS when the site
was not in service, or the BSS was in SYSGEN mode. This meant locking the site before adding
the cell. Call processing was therefore discontinued until the cell had been added and the site
put back into service, which required that the site be reset and the entire database downloaded
to the BTS. In a daisy chain configuration, all sites except the site where the cell was added or
removed were taken out-of-service and required a database download.
Cells can now be added, copied or deleted without being in SYSGEN mode (Figure 5-1). The
changes are added to the database, as with changes made with the chg_element command. No
database download from the OMC is required. The OMC is informed of the added or deleted
cell without an audit. The added cell is then brought into service when RTFs are equipped,
handover/power control algorithms are assigned and neighbors are associated with it. The
add_neighbour/modify_neighbour commands are used to add neighbors for the new cell.
These commands are allowed outside SYSGEN mode.
Figure 5-1 Online add/copy/delete cell
68P02901W36-S 5-5
Jul 2008
Related commands and parameters Chapter 5: Cells
Refer to the Technical Description: BSS Command Reference (68P02901W23) manual for a full
The following MMI commands are used to add, copy or delete cells:
add_cell.
del_cell.
copy_cell.
disp_cell.
System impact
The main impact is that cells can be added, copied or deleted without being in SYSGEN mode
(for which the site must be out-of-service). If the cell configuration is changed through the MMI
commands, the OMC-R is informed (the CM MIB file is updated) of the added or deleted cell
without requiring an audit.
5-6 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Frequency types
Frequency types

Differences between GSM frequency types
GSM allows use of five different frequency bandwidths: GSM 850, GSM 900, Extended GSM
(EGSM), DCS 1800 and PCS 1900.
GSM 850 frequencies
GSM 850 uses the radio frequency range 824-849 MHz for reception and 869-894 MHz for
transmission. RF carriers are spaced every 200 kHz, allowing a total of 124 carriers for use.
Frequency blocks for GSM 850
If GSM 850 is entered as a frequency type, one, or both GSM 850 frequency blocks must be
specified. The GSM 850 frequency block(s), shown in Table 5-1, will determine the available
Absolute Radio Frequency Channel ARFCN(s) for an RTF and possibly restrict the maximum
transmit power for the cell assigned to that RTF.
NOTE
DRIs for Horizon macro BTSs must be equipped as high power only.
Table 5-1 GSM 850 frequency blocks
Frequency Block Channel Number Uplink Frequency Downlink Frequency

A 128-181 824.2-834.8 869.2-879.8
233- 239 845.2-846.4 890.2-891.4
B 183-231 835.2-844.8 880.2-889.8
240- 251 846.6-848.8 891.2-893.8
The following commands are used to set or change GSM 850 frequencies:
freq_types_allowed - Specifies GSM 850 frequency type.
add_cell, add neighbour - Sets GSM 850 frequency for a new cell.
68P02901W36-S 5-7
Jul 2008
GSM 900 frequencies Chapter 5: Cells
chg_element - Allows changes to various parameters necessary for GSM 850

implementation. Setting the tx_power_cap element to 1 changes the DRI cell power to
high.
equip CAB and equip RTF - Equips the CABinet and the RTF for PCS 1900 frequency type.
modify_value - Changes frequency type to GSM 850, using the frequency_type parameter.
chg_rtf_freq - Used to change the ARFCN for a particular RTF.
chg_hopping and chg_hop_params-Used to expand the ARFCN range and add power
frequency restrictions on the edge of a PCS block.
GSM 900 frequencies
GSM 900 uses the radio frequency range 890-915 MHz for receive and 935-960 MHz for
transmit. RF carriers are spaced every 200 kHz, allowing a total of 124 carriers for use.
Extended GSM (EGSM)
The BSS software is capable of supporting an extra 10 MHz bandwidth in the uplink and
downlink, known as Extended GSM 900 (EGSM 900). The extended frequency range is 880-890,
transmit and 925-935, receive.
Provided the frequency type is specified as GSM 900 in the equip site command, all cells at
that site can be configured as GSM 900 with the option to use EGSM 900 as well. The EGSM
frequencies can only be used if the correct radio hardware is available. The BCCH frequency and
the channels configured as SDCCH must always be set within the GSM 900 band to ensure MS
compatibility. The database parameter to enable EGSM is chg_element freq_band_eGSM 900.
An idle MS is notified of the frequencies active in the cell through the cell channel description
element in the system information messages. This element contains 16 available octets in which
to encode the carrier frequencies in use. The number of frequencies that can be encoded
depends upon the following criteria:
If EGSM frequencies are active, 49 carriers may be specified.
If channel 0 is also active, only 17 frequencies may be encoded.
When the CRM allocates a TCH for an EGSM MS it searches between extended then primary
band frequencies starting from best to worst interference bands until a channel is found. To
avoid blocking of primary MSs, an extended MS using a primary resource can be forced to
handover to an idle extended band resource. This feature is controlled by use of the database
parameter chg_element egsm_handover_threshold.
If hopping is active within the cell, the hopping frequencies cannot be mixed; an MS is required
to hop over primary frequencies or EGSM frequencies but not over a mixture of both within
the same call.
5-8 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation DCS 1800 frequencies
BCCH frequency in EGSM
The following configurations are supported by this feature:

Stand alone extension band system.
Dual band system with EGSM and DCS 1800.
Extension band system with originations across the entire 35 MHz (BCCH+SDCCH in
EGSM).
With this feature, the operator can implement a multiband or dual-band network with EGSM
as one of the supported frequency bands, such as EGSM and DCS 1800. It is possible for the
operator to select the EGSM band as the preferred band over the DCS 1800 or GSM 900 band.
This feature allows hopping systems to support the EGSM frequency band (a combination of
frequencies from the PGSM and GSM Extension bands). In a dual band system with EGSM as
one of the supported frequency bands, for example, EGSM and DCS 1800, hopping is only
supported within the bands but not between the bands (as per the GSM specifications).
The following parameters can be used with the chg_element and chg_cell_element commands
to specify EGSM frequencies:
egsm_bcch_sd - Used to enable or disable the configuration of BCCH carriers and the
placement of SDCCH channels in the GSM Extension band.
freq_band_eGSM 900 - Specifies whether the cell supports EGSM frequencies.
egsm_handover_threshold - Indicates the range of interference bands allowed for

handing over EGSM MSs using a primary resource which is needed by a primary MS.
DCS 1800 frequencies
DCS 1800 uses the radio frequency range 1710-1785 MHz to receive and 1805-1880 MHz to
transmit. RF carriers are spaced every 200 kHz, allowing a total of 373 carriers for use (one
used as a guard band).
High power DCS 1800 with increased sensitivity receiver matrix
The receiver sensitivity increases restriction of a single cell in a single cabinet.
The high powered DCS 1800 radio has a calibrated output power of 32 watts measured at
the antenna connector with no combining. The new radio operates in all DCS 1800 TCU
configurations.
The new 32 watt radio cannot be used replacing a 16 watt (16 watts measured at the antenna)
TCU/SCU replacement radio. Therefore cannot be used with other low powered radios within
the same cell.
68P02901W36-S 5-9
Jul 2008
PCS 1900 frequencies Chapter 5: Cells
System impact
The high powered DCS 1800 radio requires changes to the acceptable bay level offset range.
This is due to the high gain, lower noise figure for the dual port pre-selectors (-108.5 dBm
sensitivity).
The high power DCS 1800 radio will also not support Rx daisy chain with the new dual path
pre-selector.
This feature has an impact on the power control algorithm, fault management, configuration
management, the man machine interface and the alarms processes.
The customer can order (or utilize) the high power feature independently from ordering the
increased sensitivity receiver matrix.
A BTS cabinet can contain a high power DCS 1800 radio and an existing DCS 1800 radio, but
will use only one radio type in a cell; no sharing is allowed. In addition, it would not be practical
to install a pre-amplifier with the configuration.
PCS 1900 frequencies
PCS allows an optional third (MNC) digit in the cell identifier. All MMI commands and prompts
requiring a cell identifier optionally accept an eight-digit cell identifier for a PCS 1900 cell. This
eight-digit format is required for PCS 1900 cells and is optional for PGSM, EGSM and DCS 1800
cells. The eight-digit cell id format consists of the four sections (MCC, MNC, LAC, CI).
Frequency blocks for PCS 1900
If PCS 1900 or all is entered as a frequency type, at least one PCS 1900 frequency block
must be specified. The PCS 1900 frequency block(s), shown in Table 5-2, will determine the
available ARFCN(s) for an RTF and possibly restrict the maximum transmit power for the
cell assigned to that RTF.
Table 5-2 PCS 1900 frequency blocks
Frequency Block Channel Number Uplink Frequency Downlink Frequency

A 512 1850.2 1930.2
585 1864.8 1944.8
D 587 1865.2 1945.2
610 1869.8 1949.8
B 612 1870.2 1950.2
685 1884.8 1964.8
E 687 1885.2 1965.2
710 1889.8 1969.8
F 712 1890.2 1970.2
735 1894.8 1974.8
C 737 1895.2 1975.2
810 1909.8 1989.8
5-10 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation PCS 1900 system impact
The following commands are used to set or change PCS 1900 frequencies:
add_cell - Sets PCS 1900 frequency for a cell.
chg_element - The max_tx_bts and the mmi_cell_id_format elements need changing

for PCS 1900 frequency.
chg_hopping and chg_hop_params-Used to expand the ARFCN range and add power
frequency restrictions on the edge of a PCS block.
chg_rtf_freq - Used to change the absolute radio frequency channel for a particular RTF.
equip CAB and equip RTF - Equips the CABinet and the RTF for PCS 1900 frequency type.
freq_types_allowed - Specifies PCS 1900 frequency type.
modify_value - Using the frequency_type parameter, changes frequency type to PCS

1900. Using the tx_pwr_red element, changes the RTF frequency to PCS 1900.
PCS 1900 system impact
The existing functional areas affected by the implementation of PCS 1900 are:
Operations and Maintenance (O and M).
Call Processing (CP).
O and M Initiatives (BSS-OMC GUI Interface).
Operations and maintenance
The O and M area is affected by PCS 1900 as follows:

If one or more PCS 1900 frequency blocks are available to the BSS and the ARFCN which
is one of the block edges is entered, the max_tx_bts for the cell cannot be less than or
equal to 3 (which corresponds to greater than 36 dBm) with the following exceptions:
If the available frequency blocks for the BSS are contiguous and the ARFCN is on the
adjacent border of the selected blocks.
If the Concentric Cells option is purchased, the power based algorithm is used and
the block edge frequency is defined to be an inner zone carrier with a maximum
transmit power level less than 36 dBm.
If the frequency type of the assigned cell is anything other than PCS 1900.
68P02901W36-S 5-11
Jul 2008
PCS 1900 system impact Chapter 5: Cells
If an attempt is made to increase the power level of a cell with frequency type PCS 1900 to
a value greater than 36 dBm, configuration management accepts the command if each of
the carriers within the cell meet one of the following conditions:
If the ARFCN is within one of the selected frequency blocks and not on one of the
block edges.
If the ARFCN is on the adjacent border of contiguous selected frequency blocks.
If the concentric cells option is purchased, the power based use algorithm is used
and the block edge frequency is defined to be an inner zone carrier with a maximum
transmit power level less than 36 dBm.
The MMI allows an ARFCN in the range of 512 to 810 to be entered when equipping an
RTF that has been assigned a cell with a frequency type of PCS 1900.
Call processing
Call processing is affected by PCS 1900 as follows:

Call processing supports the expanded range for the PCS 1900 ARFCN values.
Call processing includes the optional third MNC digit in the location area identification
information element when it is available in all outgoing messages.
For the mobile optimization and debugging feature, call processing extracts the individual
elements of the GSM cell id to format the information to be broadcast. Call processing
includes the third MNC digit when the digit is valid for a PCS 1900 cell.
5-12 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Base station Identity Code (BSIC)
Base station Identity Code (BSIC)

BSIC function
Every cell has a BSIC. The BSIC is a local color code that allows a mobile station to distinguish
between different neighboring base stations. It is encoded on the Synchronization Channel
(SCH).
The size of the BSIC is one octet, made up of two values:

Network Colour Code (NCC)
The NCC is three bits and is the same as the Public land mobile network (PLMN) Colour
Code.
Base station Colour Code (BCC)
The BCC is also three bits.
Figure 5-2 shows the BSIC structure.
Figure 5-2 BSIC structure
The values for the NCC and BCC may range from 000 to 111.
The structure of the BSIC octet is _ _ N C C B C C, where _ _ are unused. The BSIC is calculated
using Table 5-3 and Table 5-4.
A BSIC for a PLMN has one of eight values. A BSIC is reused, but it is important that neighbor
cells do not share the same BSIC and the same BCCH RF carrier.
NOTE
The chg_element command can change the BSIC within an operational site. There is
no requirement to unequip the RTF before making this change.
68P02901W36-S 5-13
Jul 2008
Changing the training sequence code Chapter 5: Cells
Changing the BSIC value can cause the system to take a carrier out-of-service. Calls on this
carrier is lost, depending on the availability of other carriers and timeslots not affected by the
out-of-service carrier. If the carrier is baseband hopping the system will remove it from the
active hopping system until the next site reset. The system will display the following warning:
WARNING: Changing this element will reset all DRIs associated with this cell Are
you sure (y=yes, n=no)?
A Y answer resets all the DRIs.
Table 5-3 Base Station Identity Code-Hexadecimal Values
BCC
NCC
0 1 2 3 4 5 6 7
0 0 1 2 3 4 5 6 7
1 8 9 A B C D E F
2 10 11 12 13 14 15 16 17
3 18 19 1A 1B 1C 1D 1E 1F
4 20 21 22 23 24 25 26 27
5 28 29 2A 2B 2C 2D 2E 2F
6 30 31 32 33 34 35 36 37
7 38 39 3A 3B 3C 3D 3E 3F
Table 5-4 Base Station Identity Code-Decimal Values
BCC
NCC
0 1 2 3 4 5 6 7
0 0 1 2 3 4 5 6 7
1 8 9 10 11 12 13 14 15
2 16 17 18 19 20 21 22 23
3 24 25 26 27 28 29 30 31
4 32 33 34 35 36 37 38 39
5 40 41 42 43 44 45 46 47
6 48 49 50 51 52 53 54 55
7 56 57 58 59 60 61 62 63
Changing the training sequence code
A BSS-wide parameter is available tsc_update_method, which enables the user to specify

the effect on Training Sequence Codes (TSCs) as a result of the BSIC being changed using
the bsic parameter.
5-14 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Changing the training sequence code
Parameter settings are:

Update TSC on BCCH carrier according to the ccch_conf parameter setting when the
BSIC is changed (default).
Update all TSCs on BCCH carrier when the BSIC is changed.
Update all TSCs on all carriers in the cell when the BSIC is changed.
This parameter can be set only when no RTFs are equipped, that is, (before equipping an RTF).
The equip RTF command verifies TSC values based on this setting.
68P02901W36-S 5-15
Jul 2008
GSM control channels Chapter 5: Cells
GSM control channels

GSM control channel groups
The GSM control channel groups are:

Broadcast Control Channel (BCCH).
Common Control Channel (CCCH).
Dedicated Control Channel (DCCH).
Active MSs must frequently monitor both BCCH and CCCH. The CCCH will be transmitted
on the RF carrier with the BCCH.
Broadcast control channel group
The BCCH is transmitted by the BTS at all times. The RF carrier used to transmit the BCCH is
referred to as the BCCH carrier. The information carried on the BCCH is monitored by the MS
periodically (at least every 30 sec), when it is switched on and not in a call.
BCCH-Carries the following information (this is only a partial list):

Location Area Identity (LAI).
List of neighboring cells which should be monitored by the MS.
List of frequencies used in the cell.
Cell identity.
Power control indicator.
DTX permitted.
Access control (for example, emergency calls, call barring).
CBCH description.
The BCCH is transmitted at constant power at all times and its signal strength is measured
by all MS which can seek to use it.
Dummy bursts
Dummy bursts are transmitted to ensure continuity when there is no BCCH carrier traffic.
5-16 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Common control channel group
Frequency correction channel
The Frequency Correction Channel (FCCH) is transmitted frequently on the BCCH timeslot and
allows the mobile to synchronize its own frequency to that of the transmitting base site. The
FCCH can only be sent during timeslot 0 on the BCCH carrier frequency and therefore it acts as
a flag to the mobile to identify Timeslot 0.
Synchronization channel
The Synchronization Channel (SCH) carries the information to enable the MS to synchronize
to the TDMA frame structure and know the timing of the individual timeslots. The following
parameters are sent:
Frame number.
Base Site Identity Code (BSIC).
The MS will monitor BCCH information from surrounding cells and store the information from
the best six cells. The SCH information on these cells is also stored so that the MS can quickly
resynchronize when it enters a new cell.
The GSM Specifications allow the use of a common BCCH for different bands of operation when
resources across all bands are collocated and synchronized. As a result a cell can be specified in
which the BCCH carrier (and any optional non-BCCH carriers) is allocated from one frequency
band and the remaining non-BCCH carriers within the same cell are allocated from another
frequency band. It is possible for carriers within a single cell to be configured with frequencies
from different frequency bands. Because GSM does not specify a mechanism to allow the MS to
pass to the BSS band capability details prior to Immediate Assignment, the BSS always allocates
a resource from the primary band. This aligns with the Concentric Cells feature and this feature
must be unrestricted before the single BCCH feature for dual band cells can be used.
The Overview of single BCCH for dual band cells section in this chapter further describes
this feature. The Concentric cells section in this manual describes the concentric cells feature.
Other optional features that must be unrestricted in order to configure dual band cells are:
Multiband handover-see Multiband inter-cell handover in Chapter 8 Power and
Handover Control.
Dual band cells-see Frequency types in this chapter for frequency details.
Homogeneous cabinet-see the equip CAB command in Technical Description: BSS

Heterogeneous cabinet (for combined cabinet configurations)-see the equip CAB

command in Technical Description: BSS Command Reference (68P02901W23) manual.
Common control channel group
The Common Control Channel (CCCH) is responsible for transferring control information
between all mobiles and the BTS. This is necessary for the implementation of call origination
and call paging functions.
It consists of the following:
68P02901W36-S 5-17
Jul 2008
Dedicated control channel group Chapter 5: Cells
Random access channel
The Random Access Channel (RACH) is used by the mobile when it requires to gain access to
the system. This occurs when the mobile initiates a call or responds to a page.
Paging channel
The Paging Channel (PCH) is used by the BTS to page MS, (paging can be performed by
an IMSI, TMSI or IMEI).
Access grant control channel
The Access Grant Control Channel (AGCH) is used by the BTS to assign a dedicated control
channel to an MS in response to an access message received on the Random Access Channel.
The MS will move to the dedicated channel in order to proceed with either a call setup, response
to a paging message, location area update or short message service.
AGCH and PCH capacity improvement
{34106}
AGCH and PCH capacity improvement mechanism facilitates the system to reduce the flow
control on the Access Grant Channel (AGCH), and provide a logical message handling
mechanism. When AGCH flow control is optimized, the Paging Channel (PCH) response rate
increases and thus the paging success rate is increased.
It provides an additional statistic by reusing the counter array statistics ID that monitors the
IA/IAR messages discarded or sent in the AGCH flow control.
Cell broadcast channel
The Cell Broadcast Channel (CBCH) is used to transmit messages to be broadcast to all MSs
within a cell. The CBCH uses a dedicated control channel to send its messages, however it is
considered a common channel because the messages can be received by all mobiles in the cell.
Dedicated control channel group
The Dedicated Control Channel (DCCH) is a single timeslot on an RF carrier which is used to
convey eight Stand-alone Dedicated Control Channels (SDCCH). An SDCCH is used by a single
MS for call setup, authentication, location updating and SMS point to point.
Up to 128 SDCCHs can be provided per cell:

Two carriers, with eight timeslots on each can be configured for SDCCH.
Eight carriers with two timeslots on each can be configured for SDCCH.
Any combination of both, with up to, but not exceeding 128 SDCCHs.
SDCCH can also be found on a BCCH or CCCH timeslot, this configuration only allows four
SDCCHs.
5-18 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Fast associated control channel
Associated control channels
The Associated Control Channels (ACCH) can be associated with either an SDCCH or a TCH.
They are used for carrying information associated with the process being carried out on either
the SDCCH or the TCH.
All of the control channels are required for system operation, however, in the same way that
different users can share the radio channel by using different timeslots to carry the conversation
data, the control channels share timeslots on the radio channel at different times. This allows
efficient passing of control information without wasting capacity which could be used for call
traffic. This is achieved by organizing the timeslots between those which will be used for traffic
and those which will carry control signaling.
Slow associated control channel
The Slow Associated Control Channel (SACCH) conveys power control and timing advance
information in the downlink direction and Receive Signal Strength Indicator (RSSI) and link
quality reports in the uplink direction.
SACCH system information can be accessed from the BSS on a per-channel basis. This
information can be used to activate a call channel, or create new SACCH information.
The BSS sends SACCH system information uniquely per call, based on the capabilities of the
MS using a particular channel. This can be done at channel activation time by including the
SACCH system information in the CHANNEL ACTIVATION message, or any time during the call
by sending a SACCH INFO MODIFY message.
SACCH system information can now be sent in a message for a given channel activation
procedure. Information should be broadcast until the channel is released or the information is
changed by a SACCH INFO MODIFY message.
The BSS sends the SACCH INFO MODIFY message to update the SACCH SI based on the
frequency band capabilities of a given MS.
The BSS software and firmware support sending SACCH system information on a channel.
The firmware supports the sending of SACCH system information based on the capabilities
of a given MS. If it is determined by the BSS software that these capabilities have changed,
updated SACCH system information can be received at any time (during a call) and should be
broadcast by the firmware.
The top two quartets of the SACCH always contain timing advance information.
Fast associated control channel
The Fast Associated Control Channel (FACCH) is transmitted instead of a TCH. The FACCH
steals the TCH burst and inserts its own information. The FACCH is used to carry out user
authentication, handovers and immediate assignment.
The stolen TCH burst is a normal burst, as indicated by the setting of a stealing bit associated
with a 57-bit data block within the burst. There are two stealing bits each associated with
the two data blocks.
68P02901W36-S 5-19
Jul 2008
Channel combinations Chapter 5: Cells
Channel combinations
The different logical channel types are grouped into channel combinations. The four most
common channel combinations are listed below:
Full-Rate Traffic Channel Combination - TCH8/FACCH + SACCH.
Broadcast Channel Combination - BCCH + CCCH.
Dedicated Channel Combination - SDCCH8 + SACCH8.
Combined Channel Combination - BCCH + CCCH + SDCCH4 + SACCH4.
Control channel mapping to timeslots
The channel combinations we have identified are sent over the air interface in a selected
timeslot.
Some channel combinations can be sent on any timeslot, but others must be sent on specific
timeslots. Table 5-5 shows how the channel combinations are mapped to their respective
timeslots:
Table 5-5 Channel/timeslot mapping
Channel combination Timeslot/s

Traffic Any timeslot
Broadcast 0, 2, 4, 6 (0 is used first). See Note below
Dedicated Any timeslot
Combined 0 only
NOTE
If broadcast is assigned to timeslots 2, 4 or 6 then FCCH and SCH will be

replaced with dummy bursts since these control channels can only occur on
timeslot 0.
Only one BCCH or CCCH timeslot is required per cell (not RF carrier).
5-20 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Overview of single BCCH for dual band cells
Overview of single BCCH for dual band cells
GSM specifications optionally allow the use of a common BCCH for different bands of operation.
Resources across the bands must be collocated and synchronized, that is, equipment for both
bands must be from the same logical site.
A cell can be specified with the BCCH carrier allocated from one frequency band and non-BCCH
carriers within the same cell allocated from another frequency band. For example, an operator
with an established GSM 900 network and access to DCS 1800 frequencies can choose to
allocate DCS 1800 frequencies as non-BCCH carriers added to existing GSM 900 cells. In other
words, there would be a single logical cell supporting both 900 MHz and 1800 MHz carriers,
eliminating the need for a separate DCS 1800 cell with its own BCCH.
NOTE
InCell cabinets cannot be mixed with M-Cell and Horizon cabinets in the same logical
site.
The algorithms for moving traffic between the bands of a multiband cell are an extension of the
concentric cells feature, using a derivation of the power based algorithm. Multiband cells are
configured with only primary band carriers in the outer zone and only secondary band carriers
in the inner zone. The inner zone carriers must be allocated from a different frequency band
than the outer zone carriers. Outer zone carriers can be either frequency. Frequency hopping
is allowed within the GSM 900 band and within the DCS 1800 band but frequency hopping
across bands is not allowed.
NOTE
The Motorola concentric cells implementation in use with single BCCH dual band
cells enables configuration of the inner zone coverage of a cell to be the same as
that of the outer zone.
Using this strategy, the operator gains the benefit of increasing system capacity without
modifying the frequency plan of the GSM 900 network. For example if DCS 1800 is being added
to an existing GSM 900 network, the existing GSM 900 BCCH plan can be used. There is no
need to plan DCS 1800 BCCHs when 1800 MHz carriers are added for capacity. Additionally
no modification to neighbor lists is necessary and the capacity and quality of the multiband
network is increased as fewer channels are taken up with BCCHs.
This method of system expansion is only effective if the subscriber base is populated with
a sufficient number of multiband capable mobiles. For a cell with a GSM 900 outer zone, all
mobiles must be at least GSM 900 capable to access the system. Since the BCCH carriers are
defined in the GSM 900 band, single band DCS 1800 mobiles will be unable to access the system.
68P02901W36-S 5-21
Jul 2008
Configuration of single BCCH dual band cells Chapter 5: Cells
Summary of effects
The main impacts of the Single BCCH for dual band cells feature are as follows:
Support of two different frequency bands within a single cell, using a concentric cells
configuration.
The operator can define the coverage area of the primary and secondary bands
independently by use of BSS database parameters.
Channel allocation algorithms are supplied to incorporate selection of channels from

different frequency bands and ensure the allocation of a secondary band (inner zone)
resource at TCH assignment when required criteria are met.
Power level conversions are provided for intra-cell channel changes and incoming inter-cell
handovers between channels on different frequency bands.
Other optional features that must be unrestricted in order to configure dual band cells are:
Multiband handover-see Multiband inter-cell handover section in Chapter 8 Power and
Handover Control.
Concentric cells-see Concentric cells in this chapter.
Dual band cells-see Frequency types in this chapter for frequency details.
Homogeneous cabinet-see the equip CAB command in Technical Description: BSS

Heterogeneous cabinet (for combined cabinet configurations)-see the equip CAB

command in Technical Description: BSS Command Reference (68P02901W23) manual.
Configuration of single BCCH dual band cells
The Single BCCH for dual band cells feature permits the configuration of carriers with only two
different frequency types at the cell level for the following frequency bands:
PGSM/EGSM.
DCS 1800.
NOTE
Either of the above bands can be assigned as the primary band for the cell.
An operator with an existing single band network and the necessary restricted features
enabled, can change cells from a single band configuration to a dual band configuration
without interruption of service on the primary band. The procedure begins with modifying the
inner_zone_alg parameter and specifying information in reply to the resulting prompts.
5-22 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Dual band inner zone algorithms
The inner_zone_alg parameter and associated parameters set the feature on and enable dual
band cells. The DRIs and RTFs for the secondary band must be equipped. Note that with dual
band cells it is necessary to allow two DRI/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/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. At this point the operator must also indicate
the percentage of outer zone TCHs that need to be in use prior to the assignment of secondary
band channels, by use of the outer_zone_usage_level parameter. The dual band cell is fully
operational once the secondary band DRIs are brought into service.
Dual band inner zone algorithms
The Single BCCH for dual band cells feature needs the inter-zone traffic management provided
by the Concentric Cells feature to account for the two frequency bands possible within a
single cell. Traffic is managed between frequency bands of different cells with the Multiband
feature by using algorithms based on the frequency types of the serving and neighbor cells, as
well as operator preferences defined by the band_preference and band_preference_mode
BSS database parameters.
The dual band inner zone algorithm differs from the power based 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 algorithm defines the maximum transmit power per zone. That is, one
value applied to all secondary band carriers. In order to account for propagation differences
between bands and allow secondary band carriers to provide total cell coverage, the inner zone
algorithm allows the maximum transmit power level of secondary band carriers to exceed the
maximum transmit power level of the primary band.
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 dual band inner zone algorithm must consider other factors when comparing signal
strengths from different frequency bands to accurately determine whether an MS can be served
by a secondary band channel. These factors are:
Loss of power between the radio unit and the top of the antenna can not be consistent
across all radio units within the cell due to different levels of combining. Power loss =
primary band (outer zone) power loss-secondary band (inner zone) power loss.
Propagation loss over the air. RF propagation is weaker at 1800 MHz than at 900 MHz.
These factors are accounted for in the definition of the dual_band_offset BSS database
parameter:
dual_band_offset = Power loss + Propagation loss
In comparing the receive levels (RXLEV) of the outer zone/inner zone threshold, the inner
zone 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 frequency band using
the dual_band_offset parameter as above.
RXLEV (inner) = RXLEV (outer) + dual_band_offset
Assuming balanced links, the same offset is applied to convert both the uplink and downlink
receive levels. The dual_band_offset parameter has a possible range of-63 to 63. This
parameter should normally be set to a negative value when the secondary band is DCS 1800
and the primary band is EGSM/PGSM and to a positive value when the secondary band is
EGSM/PGSM and the primary band is DCS 1800.
68P02901W36-S 5-23
Jul 2008
Dual band inner zone algorithms Chapter 5: Cells
The calculated RXLEV (inner) value is then used in the dual band inner zone algorithm formulae:
(RXLEV_DL (inner) > rxlev_dl_zone + zone_ho_hyst + (BTS_TXPWR-bts_txpwr_max_inner))
and
(RXLEV_UL (inner) > rxlev_ul_zone + zone_ho_hyst + (MS_TXPWR-(Min

(ms_txpwr_max_inner, P))))
Table 5-6 Dual band inner zone algorithms
Where: Is:
RXLEV_DL (inner) measured receive level downlink in the inner zone.
RXLEV_UL (inner) measured receive level uplink in the inner zone.
BTS_TXPWR actual BSS transmit level in dBm.
MS_TXPWR actual MS transmit level in dBm.
bts_txpwr_max_inner maximum inner zone BTS transmit power (defined in
the database per cell).
Min minimum (least of).
ms_txpwr_max_inner maximum power the MS is allowed in the inner zone
frequency band (defined in the database per cell).
P actual maximum transmit power capability of the MS in
the inner zone frequency band.
zone_ho_hyst used to ensure that the signal strength exceeds the
threshold by a sufficient amount to prevent the MS from
bouncing back to the primary band/outer zone (defined
in the database per cell).
When the operator intends to provide total cell coverage with the secondary band/inner zone,
the zone_ho_hyst parameter could be set to 0. As long as the secondary band maximum
transmit power levels are set sufficiently high to allow the mobiles use of secondary band
resources throughout the cell, inter-cell handover criteria should be met prior to the mobile
meeting the criteria to be moved to the secondary band.
Additional criteria are also evaluated in cases when the secondary band meets or exceeds the
boundary of the primary band and the condition to be moved out to the primary band is met.
Before assuming that the primary band is the optimal location for the MS, the neighbor cells
are also evaluated as candidates for inter-cell handover. These neighbor cells must qualify,
selected over the primary band of the serving cell. If no cells qualify, the MS is moved to the
primary band of the serving cell.
5-24 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Channel selection algorithms
If... Then...
BTS power control is ON the Downlink qualification criteria are: (RXLEV_DL <
rxlev_dl_zone) AND (BTS_TXPWR = bts_txpwr_max_inner).
BTS power control is OFF the Downlink qualification criteria are: (RXLEV_DL <
rxlev_dl_zone).
MS power control is ON the Uplink qualification criteria are: (RXLEV_UL
< rxlev_ul_zone) AND (MS_TXPWR =
Min(ms_txpwr_max_inner,P)).
MS power control is OFF the Uplink qualification criteria are: (RXLEV_UL <
RXLEV_UL_ZONE).
the Downlink qualification for each reported neighbor, power budget is evaluated for
criteria or the Uplink greater than handover margin.
qualification criteria are met
any neighbor qualifies handover is initiated to the qualified neighbor. Otherwise the
MS is moved to the outer zone.
NOTE
The preferred band can be set to either the secondary or primary band frequency, it is
expected that it will not be the primary band.
Channel selection algorithms
A resource from either the secondary or primary band of a dual band cell is allocated for
assignments and handovers depending on the band and zone for which the MS is capable
(based on zone entry criteria). Dual band cell inter-zone channel changes for SDCCH to TCH
assignment or TCH to TCH assignment are supported, if the necessary criteria for inter-zone
changes are met.
TCH assignments
For TCH assignment and intra-cell inter-zone handovers in dual band cells, channels are
selected by assignment of a TCH from the inner zone (secondary band) when all of the following
criteria are met:
The classmark indicates that the MS supports the frequency band of the inner zone.
The band_preference parameter is set to the appropriate band.
The band_preference_mode parameter is set to 1, 3, 5, or 6.
The inner zone signal strength criteria are met.
68P02901W36-S 5-25
Jul 2008
Channel selection algorithms Chapter 5: Cells
The percentage of outer zone TCH usage meets or exceeds the outer_zone_usage_level
parameter setting.
The sdcch_tch_band_reassign_delay parameter needs to be set to specify the number

of measurement report periods that the RSS waits before responding to the CRM (Cell
Resource Manager) system, if the MS does not report any preferred band neighbor.
If the band_preference_mode parameter is set to 2, assignment is to the primary band. A

multiband MS is handed over between zones if the zone criteria are met and no inter-cell
handover is required. Handover to the secondary zone is not allowed if the secondary
band is not preferred.
If the band_preference_mode parameter is set to 4, the BSS does not attempt to assign
a preferred band channel at SDCCH-to-TCH assignment. It enters a mode of attempting
to hand over a multiband MS to a cell with the preferred band BCCH, or the preferred
resource in a non-preferred band BCCH. This process continues if the MS meets the inner
zone criteria and the secondary band is the preferred band, until either inter-cell handover
to another cell, or intra-cell handover occurs to the inner zone.
Incoming inter-cell handovers
For incoming inter-cell handover requests in dual band cells, channels are selected by allocation
of a TCH from the secondary band when all of the following conditions are met:
The classmark indicates that the MS supports the frequency type of the secondary band.
The outer_zone_usage_level parameter setting is met or exceeded in the cell.
The band_preference_mode parameter is set to 1, 3, 5, or 6.
The MS reported downlink receive levels for the target cell meet the downlink criteria
for inner zone usage:
RXLEV (inner) = RXLEV (outer) + dual_band_offset
(RXLEV_DL (inner) > rxlev_dl_zone + zone_ho_hyst + (BTS_TXPWR-

bts_txpwr_max_inner))
Table 5-7 summarizes the effect of dual band parameter settings on channel assignments and
handovers between dual band cells.
5-26 68P02901W36-S
Jul 2008
Table 5-7 Dual band parameter effect on assignments and handovers
BSS database parameter Single band cells Dual band cells

interband_ho_allowed When using the In the Dual Band Cells feature, defines
(source to target) Multiband Handover the frequency types of the BCCH carrier
feature, defines the of target cells that are allowed for
frequency types of inter-cell handover. If the target cell
target cells that are is a dual band cell, the actual channel
allowed for inter-cell assigned by the target cell can be
handover. of a frequency type not specified by
inter_band_ho_allowed as long as the
MS supports the assigned frequency
type.
band_preference_mode BSS attempts to hand Assignment is to a primary band carrier.
=0 over a multiband When an inter-cell handover for normal
MS to the strongest radio resource reasons is required, the
reported neighbor BSS attempts to hand over a multiband
when a handover MS to the strongest reported neighbor.
is required for A multiband MS will be handed over
normal radio resource between zones if the zone criteria
reasons. are met and no inter-cell handover is
required. Band preference is ignored.
band_preference_mode The BSS attempts to At SDCCH assignment, the BSS first
= 1 assign a multiband attempts to assign a mutiband MS to
MS to the MS with the preferred band within the cell. If
strongest preferred no preferred band resource is available
band as a reported within the cell or the MS does not meet
neighbor at the time the inner zone criteria, the BSS attempts
of SDCCH to TCH to assign the MS to the strongest MS
assignment.* reported neighbor with the BCCH in
the preferred band or non-preferred
neighbor with resource in the preferred
band. If this is not possible, a resource
is assigned from the serving cell
non-preferred band.* Handover to the
secondary zone is not allowed if the
secondary band is not preferred.
band_preference_mode The BSS attempts to Assignment is to the primary band. When
= 2 hand over a multiband an inter-cell handover is required for
MS to the strongest radio reasons or traffic control, the BSS
preferred band MS attempts to hand over a multiband MS to
reported neighbor the strongest MS reported neighbor with
when a handover is the BCCH in the preferred band, or to
required for radio a non-preferred neighbor with resource
reasons or traffic in the preferred band. A multiband MS
control. is handed over between zones if the
zone criteria are met and no inter-cell
handover is required. Handover to the
secondary zone is not allowed if the
secondary band is not preferred.
Continued
68P02901W36-S 5-27
Jul 2008
Channel selection algorithms Chapter 5: Cells
Table 5-7 Dual band parameter effect on assignments and handovers (Continued)
band_preference_mode The BSS attempts to Combination of 1 and 2.*
= 3 assign a Multiband
MS to the strongest
preferred-band
neighbor that the
MS reported at the
time of SDCCH to
TCH assignment, as
well as attempt to
hand the MS over
to the strongest
preferred-band
neighbor that the
MS reported when a
handover is required
for normal radio
resource reasons.
This value combines
the functions of values
1 and 2.
band_preference_mode The BSS enters a mode The BSS does not attempt to
= 4 of attempting to hand assign a preferred band channel at
over a multiband MS SDCCH-to-TCH assignment. It enters
to a preferred band a mode of attempting to hand over a
cell immediately after multiband MS to a cell with the preferred
initial assignment. band BCCH, or the preferred resource
No attempt is made in a non-preferred band BCCH. This
at SDCCH to TCH process continues if the MS meets the
assignment time to inner zone criteria and the secondary
allocate a TCH in a band is the preferred band, until either
preferred band cell for inter-cell handover to another cell, or
this MS. intra-cell handover occurs to the inner
zone.
band_preference_mode Combination of 1, 2 No additional zone changes
= 5 and 4.* are triggered by congestion.
On SDCCH-to-TCH assignment, if
the secondary band is the preferred
band, a multiband MS is only
targeted at the secondary band if
the cell is congested and the criteria
for the secondary band are met.
A multiband MS cannot perform an
intra-cell handover from the primary to
secondary band, when the secondary
band is the preferred band, unless the
cell is congested and the criteria for the
secondary band are met.
Continued
5-28 68P02901W36-S
Jul 2008
Table 5-7 Dual band parameter effect on assignments and handovers (Continued)
A multiband MS cannot perform an
inter-cell handover from another cell
directly to the secondary band, if the
secondary band is the preferred band,
unless the cell is congested and the
criteria for the secondary band are met.
band_preference_mode Combination of 1, 2 The BSS attempts to assign a multiband
= 6 and 4.* MS to the strongest preferred band
neighbor reported by the MS only
after a cell has become congested.
If this assignment is not possible,
the BSS enters a mode of continually
monitoring for qualified preferred-band
neighbors reported by the MS in
order to hand the MS over. The BSS
stays in this mode until it finds a
neighbor TCH in the preferred band.
Handovers for normal radio resource
reasons may occur during the monitoring
mode, and these handovers are to the
strongest preferred band neighbor
reported by the MS. This setting should
be used in order to activate the multiband
congestion threshold verification.
This value functions identically to value
5, except that it is triggered only when
the cell is congested.
NOTE
In an IMRM cell, a
band_preference_mode
setting of 6, which is designed
to limit multiband activity
based on utilization, is
overridden and handled as for
a setting of 5.
* These modes trigger a check for qualification for a channel from the desired frequency band at
the time of SDCCH to TCH assignment, which results in a delay in the Assignment procedure.
This delay is set by the sdcch_tch_band_reassign_delay parameter.
68P02901W36-S 5-29
Jul 2008
Single BCCH dual band cell handovers Chapter 5: Cells
Single BCCH dual band cell handovers
Handovers can occur in single BCCH dual band cells as follows:

Intra-cell, intra-band.
Intra-cell, inter-band.
Inter-cell, intra-band.
Inter-cell, inter-band.
Single BCCH dual band handovers are described in more detail under Single BCCH dual band
handovers in the chapter Power and quality handovers of this manual.
Single BCCH dual band cell related commands and parameters
Parameters
The following database parameters support the functionality of this feature:

bts_txpwr_max_inner - Maximum transmit power for the inner zone (BTS).
coincident_mb - Determines the ability of a BTS to execute the coincident multiband

handover option.
dual_band_offset - Estimates the effects of the power level differences that occur when
comparing signal strengths from different zones. Set within the range-63 to 63. For GSM
900 outer band, a negative value should be used.
frequency_type - Frequency type (PGSM, EGSM or DCS 1800) of a cell and its BCCH
carrier.
ho_pwr_level_inner - Handover power level for inner zone, when a cell is configured
as a dual band cell.
inner_zone_alg - Algorithm and associated parameters for the inner zone of a cell. For the
single BCCH for dual band cells feature, this must be set to 3.
mb_preference - Status of the multiband inter-cell handover feature.
ms_txpwr_max_inner - Maximum power that an MS can use in the inner zone of a

concentric cell.
pbgt_mode - Selects the preferred method of compensating for a mismatch in frequency

types between the serving channel and the neighboring cell BCCH, when calculating
power budget.
secondary_freq_type - Frequency type of the inner zone frequency band when a cell is
configured as a dual band cell.
tx_power_cap - Low or high transmitting power capability for all cells within a site.
5-30 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Single BCCH dual band cell related commands and parameters
zone_ho_hyst - Positive or negative margin for the inner zone handover hysteresis.
rxlev_xx_zone, where xx can be ul or dl - The uplink or downlink receive level threshold

for the inner zone.
cell_zone - Specifies the zone to which an RTF belongs.
outer_zone_usage_level - The percentage usage of the outer zone traffic channel. Set
below the outer zone maximum load level.
band_preference - Indicates the preferred band for multiband mobile allocation.
band_preference_mode - Indicates the method for multiband mobile allocation.
max_tx_ms - Maximum output power for an MS, in the outer zone only.
handover_power_level - Power level used when an MS hands over into the cell.
max_tx_bts - Maximum output power for a BTS, in the outer zone only.
ms_txpwr_max_cch - Maximum random access power available to an MS before cell

access.
ms_txpwr_max_inner - Maximum power an MS can use in the inner zone of a concentric

cell.
ms_txpwr_max_def - The default value for ms_txpwr_max_cell when the MS transmit

power maximum value is not available from the neighbor cell.
intra_cell handover_allowed - Enables/disables intra-cell handovers.
sdcch_tch_band_reassign_delay - Number of measurement report periods that the RSS

waits before responding to the Cell Resource Manager (CRM) system software if the MS
does not report any preferred band neighbor.
interband_ho_allowed - Interband handover frequency types in a multiband cell.
The description of the setting of these parameters is provided in Technical Description: BSS
Commands
The following MMI commands support the functionality of this feature:

chg_cell_element
chg_hop_params
chg_rtf_freq
del_neighbour
disp_equip
disp_gsm_cells
68P02901W36-S 5-31
Jul 2008
Single BCCH dual band cell related commands and parameters Chapter 5: Cells
disp_options
equip DRI
equip RTF
modify neighbour
modify_value
The description of the use of these commands is provided inTechnical Description: BSS
5-32 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GPRS traffic and control channels
GPRS traffic and control channels

Packet control channels
Like GSM circuit switched channels, there are two main groups of packet logical channels:
traffic channels and control channels.
Packet Common Control Channel (PCCCH)-a set of logical channels used for common
signaling:
Packet Random Access Channel (PRACH)-uplink only, mapped on a PDCH or the
RACH.
Packet Paging Channel (PPCH)-downlink only, mapped on a PDCH or the PCH.
Packet Access Grant Channel (PAGCH)-downlink only, mapped on a PDCH or AGCH.
Packet Notification Channel (PNCH)-downlink only.
Packet random access channel
The Packet Random Access Channel (PRACH) is used in the uplink direction only to initiate
uplink transfer of data, or to respond to a paging message. The PRACH also contains timing
advance information.
Packet paging channel
The Packet Paging Channel (PPCH) is used in the downlink direction only to page GPRS MSs,
when it is required to send packet data. PPCH uses paging groups in order to allow for DRX
(Discontinuous Reception). The PPCH can be used for paging MSs in circuit switched or packet
switched modes but only for class A MSs (simultaneous circuit switched and packet switched
capability) or class B MSs (sequential, but not simultaneous, circuit switched and packet
switched capability).
NOTE
Additionally, an MS that is currently engaged in packet transfer can be paged for
circuit switched services on a PACCH.
68P02901W36-S 5-33
Jul 2008
Packet access grant channel Chapter 5: Cells
Packet access grant channel
The Packet Access Grant Channel (PAGCH) is used in the establishment phase of a packet
transfer to send resource assignment messages to an MS prior to packet transfer.
NOTE
Additional resource management messages can be sent on the PACCH if the MS is
currently involved in a packet transfer.
Packet notification channel
The Packet Notification Channel (PNCH) is used to send a Point-To-Multipoint Multicast

(PTM-M) notification (downlink) to a group of MSs prior to a PTM-M packet transfer. The
notification takes the form of a resource assignment for packet transfer.
Packet data traffic channel
The Packet Data Traffic Channel (PDTCH) is used for packet data transfer, uplink and downlink.
It is dedicated to one MS or a group of MSs in the PTM-M case. In multislot operation, one MS
can use multiple PDTCHs in parallel for an individual packet transfer.
Packet Access Control Channels (PACCHs) are logically mapped on to the PDTCH to convey
signaling information related to a specific MS in uplink and downlink. This information can
include ACKnowledgments and/or No-ACKnowledgments, power control information and
resource reassignments. One PACCH is associated with one or several PDTCHs that are
currently assigned to one MS.
5-34 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Mapping packet data channels on to physical channels
Mapping packet data channels on to physical channels

Timeslot usage by GPRS
A Packet Data Channel (PDCH) is a physical timeslot that has been allocated for use by GPRS.
This allocation can be permanent or temporary in that dynamic allocation of timeslots between
GSM and GPRS takes place. The sharing of the physical channel by the different packet data
logical channels is based on blocks of four consecutive normal TDMA bursts. The PRACH,
however, uses GSM access bursts and the PACCH is able to use four consecutive access bursts
under some message conditions.
The structure of the GPRS 52 multiframe is shown in Figure 5-3. The structure is totally different
from the GSM 51 multiframe and different channels are distinguished by their message types.
If the 52 multiframe is carrying a Packet Traffic Channel (PTCH) then it carries PDTCH or
PACCH messages.
Figure 5-3 52 multiframe structure
T X T X
When no PDCHs exist GPRS MSs camp on to the Common Control Channel (CCCH).
The BSS supports a discontinuous transmission/reception strategy to allow for conservation of

battery power on the MSs.
The BSS supports the procedures initiated by MS class types B and C.
Class A MSs can simultaneously attach, activate, monitor and send data traffic as a GPRS
MS or a GSM circuit switched MS.
Class B MSs can simultaneously attach, activate and monitor but cannot send simultaneous
packet or circuit switched data.
Class C MSs can only do non-simultaneous attachments and non-simultaneous data

transfer.
68P02901W36-S 5-35
Jul 2008
GPRS reserved and switchable timeslots Chapter 5: Cells
GPRS reserved and switchable timeslots

GPRS switchable timeslots function
If the BSS needs to set up a circuit switched call and there is more than one GPRS timeslot in
service, with no idle circuit switched TCHs, the BSS reconfigures a switchable gprs timeslot
for circuit switched service.
The BSS can reconfigure a switchable PDTCH to a TCH at any time. Normally, the BSS only
reconfigures switchable timeslots, but it can reconfigure a reserved timeslot for an emergency
call. If the total number of GPRS timeslots in a cell, switchable and reserved, is greater than
one then the BSS reconfigures that timeslot.
If the BSS needs to use the last GPRS timeslot in the cell then it waits until there is no GPRS
traffic in the cell before it can reconfigure it back to a TCH.
The BSS supports dynamic switching between PDTCHs and TCHs. If it is necessary for the
BSS to use any switchable timeslots for circuit switched purposes, the BSS immediately uses
them by triggering a reconfiguration from a PDTCH to a TCH as long as there is at least one
GPRS timeslot left in the cell.
The BSS will take the smallest numbered switchable gprs timeslot so as to maintain
contiguous GPRS timeslots. For example, suppose that timeslots TS3 and TS4 are switchable
and timeslots TS5 to TS7 are reserved (see Figure 5-4), if the BSS needs to steal a switchable
gprs timeslot, it will take timeslot TS3 before timeslot TS4.
Figure 5-4 GPRS timeslot selection
If the timeslot was in use by any GPRS MSs, the PCU broadcasts the release notification
only on PACCHs where the mobiles are assigned, releasing the timeslot. If this was the only
timeslot in use by the mobile and there is additional downlink data to send the MS, the BSS
sends a channel assignment message on the AGCH starting a new downlink transfer. If
this timeslot was the only uplink timeslot that the MS was using, the PCU will rely on the MS
repeat RACH in order to start a new transfer.
If the number of idle TCHs is greater than a preset threshold set by gprs_recon-
fig_thresh_idle_tch and the operator GPRS intra-cell handover parameter gprs_intraho_allwd
is set the BSS hands over the mobile to an idle TCH and returns the borrowed switchable
timeslot back to GPRS service, reconfiguring it as a PDTCH. Details of gprs_intraho_allwd are
described in the Technical Description: BSS Command Reference (68P02901W23) manual.
When a circuit switched call ends on a switchable GPRS timeslot and the number of idle circuit
switched TCHs is greater than set by the operator parameter gprs_reconfig_thresh_idle_tch
(see Technical Description: BSS Command Reference (68P02901W23) the BSS reconfigures
the borrowed timeslot back to a switchable PDTCH for packet data service. Details of
gprs_reconfig_thresh_idle_tch are described in Technical Description: BSS Command
5-36 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Switchable PDTCH
If the number of idle timeslots is less than or equal to a set threshold, the BSS will not handover
the timeslot back to GPRS.
If the BSS needs to use the last GPRS timeslot in the cell for an emergency call, it reconfigures
the timeslot for the emergency call without waiting for the GPRS data traffic to end.
The BSS can reconfigure any GPRS timeslot to carry emergency calls. If an emergency call is
made at a cell with a GPRS carrier and the emergency call preemption feature is enabled, the
BSS selects the air timeslot that will carry it from the following list (in order of preference):
Idle TCH.
Switchable GPRS timeslot (from lowest to highest).
In use TCH.
Reserved GPRS timeslot (from lowest to highest).
When any GPRS timeslot is taken for circuit switched purposes, whether it is reserved or
switchable, the PCU broadcasts the PDCH release message to the mobile within 600 ms of
receiving notification that the timeslot is taken away from GPRS. The PDCH Release message
informs the mobile that the timeslot is no longer available for GPRS use. The network stops
sending downlink data on that timeslot and the MS stops using that timeslot for uplink data.
Switchable PDTCH
Automatic reconfiguration of CS1-CS4 GPRS switchable timeslots on an AMR Half-Rate (HR)

capable carrier as free generic traffic timeslots is now supported.
Assignment of a Full-Rate (FR) or HR call to a GPRS switchable timeslots is reversed once the
timeslot is completely free.
NOTE
HR resources cannot be reconfigured to PDTCH. They can be reconfigured to only FR
and generic timeslots.
Allocation of GPRS switchable timeslots to FR calls occurs after a search for idle FR traffic
channels. Preference is given to non AMR HR GPRS switchable timeslots over AMR HR GPRS
switchable timeslots. This prevents the loss of GPRS capability as well as the loss of AMR
half-rate capacity.
When searching for a GPRS switchable timeslot upon which to assign an FR (AMR or non AMR)
traffic call, the BSS selects a non AMR HR GPRS switchable timeslot in preference to an AMR
HR GPRS switchable timeslot. Preference is given to idle HR traffic channels and free generic
traffic timeslots over AMR HR GPRS switchable timeslots.
Reserved PDTCH
A GPRS reserved timeslot can be reconfigured to implement an emergency call.
Reconfiguration of a reserved PDTCH to an FR channel is now supported. This means that a

reserved PDTCH can be reconfigured to one in-use and one idle HR channel.
68P02901W36-S 5-37
Jul 2008
Switchable PDTCH Chapter 5: Cells
Protect last TS functionality
Protect last TS functionality protects the last switchable PDTCH from being reconfigured to a
traffic channel when it is the last GPRS timeslot in the cell. This functionality is not affected by
the introduction of AMR.
Support the usage of idle TCH for the packet burst traffic
{34144}
Reserved PDTCH channels and Switchable PDTCH channels are used for the GPRS traffic.
Without this feature, TCH channels are used only for the voice call traffic and cannot be used
for the GPRS traffic.
This mechanism allocates the idle TCH channels as an additional switchable PDTCH resource
when there is GPRS traffic congestion in a cell. It returns these PDTCH resources back to the
TCH resources when the GPRS traffic congestion is relieved. The additional switchable PDTCH
resources are defaulted as TCH resources which have no impact on normal voice call.
NOTE
This mechanism is available only for EDGE enabled cell (at least one 64k PDTCH
available in the cell). The number of additional switchable PDTCHs are calculated
based on the EDGE carrier configuration.
5-38 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Channel allocation
Channel allocation

Channel requests
This feature allows an MS to access the network as efficiently as possible.
MS requests resources from a cell by transmitting an access burst containing the channel
request message. The access burst must be scheduled so that it is transmitted during a frame
that has been configured as a RACH. This scheduling is performed with the aid of a calculated
wait period.
After the first channel request is sent, the next one is repeated after a random wait period
in the set:
(S, S+1....S+T-1)
where:
T = tx_integer (broadcast on BCCH system information).
S is a preset number dependent on the value tx_integer and multiframe type.
Channel requests are only repeated up to M+1 times, where M is equal to max_retran,
broadcast on BCCH system information. After the last channel request, T3126 is started in the
MS; on expiry the channel request procedure is aborted.
68P02901W36-S 5-39
Jul 2008
Channel requests Chapter 5: Cells
Figure 5-5 shows repeated attempts to obtain a channel.
Figure 5-5 Repeated channel request messages
5-40 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Channel requests
Figure 5-6 shows a successful connection establishment between the GSM elements.
Figure 5-6 Successful connection establishment between GSM elements
Modified parameters
The following parameters are used with the chg_element or chg_cell_element commands
to affect channel requests:
tx_integer
Sets the number of RACH slots between the access retry transmission on the RACH.
max_retran
Defines the maximum channel request retransmission value for an MS.
68P02901W36-S 5-41
Jul 2008
Channel reconfiguration Chapter 5: Cells
System impact
Each time an access class is barred, max_retran is decremented and tx_integer is incremented.
The process is reversed when access classes are unbarred.
Channel reconfiguration
On initialization, the Cell Resource Manager (CRM) ensures that each air interface timeslot is
configured in accordance with elements set in the database. Channel reconfiguration permits
this initial setup to be changed dynamically, for the SDCCH and TCH.
Once the BSS is in call processing, the CRM is capable of dynamic channel reconfiguration, that
is, the CRM is capable of changing the mix of channel configuration. If a high proportion of
SDCCHs is in use and more SDCCH requests are received, the CRM is able to reconfigure a
TCH timeslot into SDCCHs.
The channel_reconfiguration_switch element in the BSS database specifies whether the CRM
can or can not perform dynamic channel reconfiguration.
The CRM takes DD CTU2 non-BCCH EGPRS Carrier A followed by DD CTU2 Carrier B with
paired EGPRS Carrier A for the last consideration of reconfiguring TCH to SDCCH and for the
first consideration of reconfiguring SDCCH back to TCH.
SDCCH allocation
On initialization, the CRM is informed of the number_sdcchs_preferred element in the

database which controls the number of SDCCHs that will be configured in a particular cell. The
number of SDCCHs is dependent upon the configuration of timeslot 0 on the BCCH carrier:
whether it supports 4 SDCCHs, or whether all SDCCHs are on their own timeslot at 8 SDCCHs
per timeslot.
For example, if timeslot 0 (TS0) is configured as ccch_conf=1 then four SDCCHs are allocated.
In TS0, the SDCCHs are assigned as 4, 12, 20, 28,..(4+8n). If TS0 is on its own, the SDCCHs are
assigned as 8, 16, 24,..8n.
The number_sdcchs_preferred element also sets the minimum number of SDCCHs that the
reconfiguration algorithm tries to maintain. When channel reconfiguration is enabled the CRM
attempts to maintain the preferred number of SDCCHs for allocation and can reconfigure
idle TCHs to SDCCHs before all SDCCHs are busy and, when the demand falls, reconfigure
the SDCCHs back to TCHs.
CAUTION
While using the dynamic allocation of SDCCH feature, the max value of busy
SDCCH reported in the statistics can exceed temporarily the value set by parameter
max_number_of_sdcchs when re-allocating the SDCCH channels.
5-42 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Channel reconfiguration
SDCCH configuration
The sdcch_need_high_water_mark and sdcch_need_low_water_mark elements are used by

the reconfiguration algorithm to trigger the reconfiguration process. The high water mark
determines the number of free SDCCHs remaining before TCH to SDCCH reconfiguration
should occur. The tch_full_need_low_water_mark also has an effect on such a reconfiguration
to ensure that some idle traffic channels are still left after the conversion. The low water mark
determines the number of free SDCCHs before the SDCCHs obtained by previous reconfiguration
can be converted back to TCHs. The dynamic reconfiguration algorithm is shown below.
The conditions for TCH to SDCCH reconfiguration to occur are as follows:

Number of SDCCHs after reconfiguration must not exceed max_number_of_sdcch.
During the re-configuration phase, the limit can be exceeded. An extra SDCCH/8 TS can be
allocated to re-balance the SDCCH channels of the cells. This is for a very short period,
and can occasionally be seen in periods of high signaling traffic load.
Idle number of free SDCCHs must be lower than sdcch_need_high_water_mark.
Current number of idle TCHs must be greater than tch_full_need_low_water_mark.
NOTE
While using the dynamic allocation of SDCCH feature, the maximum value of busy
SDCCH reported in the statistics can temporarily exceed the value set by parameter
max_number_of_sdcchs when re-allocating the SDCCH channels.
The max_number_of_sdcch parameter specifies the maximum number of SDCCHs to be

configured in the cell. The increased SDCCH feature creates an exception to this rule, and
briefly allows the system to exceed this value in order to rebalance the SDCCHs across the
cell's carriers.
The system should not reach this value frequently, and is expected to revert to
max_number_of_sdcchs as soon as possible after rebalancing the SDCCHs.
The conditions for SDCCH to TCH reconfiguration to occur are as follows:

Total number of SDCCHs after the reconfiguration must not be lower than
number_sdcch_preferred.
Present number of free SDCCHs must be greater than sdcch_need_low_water_mark.
sdcch_need_low_water_mark >= number_sdcch_preferred.
For the Improved Timeslot Sharing (ITS) feature, to maximize the PDCHs configuration on the
Carrier A, the CRM tries to avoid configuring SDCCHs to the DD CTU2 EGPRS Carrier A and
its paired Carrier B.
68P02901W36-S 5-43
Jul 2008
Second assignment Chapter 5: Cells
Refer to the manual Technical Description: BSS Command Reference (68P02901W23) manual
for a full description of commands and parameters.
The following parameters can be changed by use of the chg_element or chg_cell_element

commands for channel reconfiguration:
channel_reconfiguration_switch - Permits dynamic channel reconfiguration
(reassignment) of traffic channels to SDCCHs.
number_sdcchs_preferred - Defines the preferred number of SDCCHs that the channel

reconfiguration algorithm tries to maintain the valid range is 0 to 128, the acceptable
values depend on the value of ccch_conf
when ccch_conf = 1 the acceptable values are: 12, 20, 28, 36, 44, 52, 60, 68, 76, 84,
92, 100, 108, 116, 124.
when ccch_conf = 0, 2, 4 or 6 the acceptable values are: 16, 24, 32, 40, 48, 56, 64, 72,
80, 88, 96, 104, 112, 120, 128.
sdcch_need_low_water_mark - Sets the number of idle SDCCHs that trigger

reconfiguration back to TCHs from SDCCHs, valid range is 10 to 128.
sdcch_need_high_water_mark - Sets the number of idle SDCCHs that trigger

reconfiguration to SDCCHs, the valid range is 1 to 119.
tch_full_need_low_water_mark - Sets the low need threshold to determine the need for
full-rate traffic channel reconfiguration to SDCCHs.
max_number_of_sdcchs - Sets the number of SDCCHs after reconfiguration, the valid

range is 0 to 128, the acceptable values depend on the value of ccch_conf.
when ccch_conf = 1 the acceptable values are: 12, 20, 28, 36, 44, 52, 60, 68, 76, 84,
92, 100, 108, 116, 124.
when ccch_conf = 0, 2, 4 or 6 the acceptable values are: 16, 24, 32, 40, 48, 56, 64, 72,
80, 88, 96, 104, 112, 120, 128.
System impact
The low and high water marks are only in effect if the channel_reconfiguration_switch is
enabled.
The redesigned CRM should not adversely affect CPU and memory utilization.
Second assignment
This feature allows a second attempt to assign a Traffic Channel (TCH) to an MS if the first TCH
assignment attempt fails.
MS requests resources from a cell by transmitting an access burst containing the channel
request message. The BSS assigns an SDCCH to establish a connection and a TCH. If the MS
then fails to access the TCH and the second assignment feature is not restricted, the BSS
initiates a second assignment process.
5-44 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Queue management
The process is as follows:

The MS sends an assignment failure message to the BSS when the first TCH assignment
fails. The BSS then tries a second TCH assignment.
If the second TCH (HR or FR) assignment fails, the BSS sends an assignment failure
message to the MSC with a cause value of CAUSE_RF_FAIL_REVERT_TO_OLD_CHANNEL
instead of the usual cause value in event of failure CAUSE_NO_RADIO_RESOURCE.
The BSS attempts second assignments within the requested band from different carriers from
the outmost zone inwards until a channel is found. If a different carrier is not available, a
second assignment will be attempted to the same carrier. The BSS will not assign to a zone
interior to that qualified for the MS.
The BSS attempts second assignments for an extended range MS to an extended range TCH
from a different carrier. For a normal range MS, the BSS attempts second assignments to an
extended range TCH, if no normal range TCHs are available.
The BSS does not preempt a call during a second assignment attempt for an emergency call, if
there is no resource available.
Directed retry processes are not triggered for a second assignment if the cell is congested.
The BSS will not attempt a multiband handover for a second assignment if the cell is congested.
Related commands and parameters fields
The second assignment function is unrestricted by use of the following command and parameter:
chg_element
second_asgnmnt
The disp_element command includes the setting of second_asgnmnt in the display.
Queue management
Queue management sets the parameters for MSs in the traffic channel (TCH) queue and
controls the queuing for SDCCH handover requests from the MSC.
Several aspects of queue management exist as follows:

TCH queuing, which includes management of half-rate queues.
SDCCH queuing.
TCH queuing
MS requests radio resources through the Random Access Channel (RACH) by sending an access
burst containing a channel request message. Assuming resources are available, the MS is
assigned one of a number of Standalone Dedicated Control Channels (SDCCHs) where the
remainder of call setup procedures take place prior to being allocated a traffic channel (TCH).
If there is no TCH available once the MS has finished on the SDCCH, the system places the MS
in a queue along with other MSs awaiting assignment of a TCH.
68P02901W36-S 5-45
Jul 2008
Queue management Chapter 5: Cells
The length of the queue is dependent upon the value set in the queue_management_infor-
mation field of the BSS database.The range of this field represents the arithmetic sum of the
number of MSs that can wait in a queue for the assignment of a TCH. The value significance is
as follows:
0 Only the internal 25 queue blocks are used for queuing. Only emergency
calls and calls resulting from the congestion relief or directed retry
options, are queued. The queue_management_information field of
the BSS database is not used at all.
1 to 50 The queue_management_information field of the BSS database is
used for queuing all calls (except emergency calls), up to the number
set by the max_q_length_chan parameter, regardless of whether they
result from the congestion relief and/or directed retry options, or not.
Only emergency calls are queued in the 25 internal queue blocks.
The parameter bssmap_t11 controls the maximum time the MS waits in the queue before the
request is dropped.
TCH queues
With TCH queuing the queue_management_information field represents the arithmetic sum
of MSs awaiting assignment of a TCH (full-rate (FR) and half-rate (HR)).
Calls arriving when all positions in the queue are occupied are cleared by the network,
indicating that no circuits/channels are available.
NOTE
max_q_length_chan + max_q_length_sdcch must be less than or equal to
queue_management_information.
Queued calls can be assigned to the inner zone of a multi-zone cell if they meet the qualification
criteria. Emergency calls are assigned or queued to the resource that has just become idle,
prior to any non-emergency calls.
In addition to the existing BSS functionality which matches the idle channel capabilities with the
queued MS capabilities calls, queued calls can be assigned to AMR full or half-rate channels.
The AMR FR and HR capability of a queued call is determined from the MSC preference, CIC
capability and feature enable/disable elements as for assignment of a new call in the cell. This is
done prior to removing the call from the queue and assignment to a freed resource.
When an idle channel becomes available (irrespective of amr_hr_res_ts) and emergency call(s)
are queued, the first emergency call in the queue (which matches the idle channel capabilities)
is assigned first. If no emergency calls are queued highest priority call is assigned.
If a queued emergency call has AMR capabilities, the BSS selects a speech version for the call.
An HR channel could be assigned to the queued resource.
SDCCH queuing
Channel requests cannot be queued: an SDCCH is either available or not available. However,
MSC originating SDCCH handover requests, although not common, can be queued. The
parameter max_q_length_sdcch controls the length of that queue.
5-46 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GPRS resource queuing
GPRS resource queuing
There is no queuing system as such for GPRS resources. An MS requests resources for uplink
transmission in the PRACH, or if already receiving data in the downlink, in the downlink
ACK/NACK message. As the MS continues to request resources at intervals, this request is kept
for a very short time, which cannot be user specified. As soon as the BTS can make timeslots
available, it does so.
For downlink transmission, timeslots are allocated as shown in Air interface packet data
transfer on page 6-68 in this chapter. Receiving MSs start to count down blocks expected and
send this up to the BTS in the downlink ACK/NACK messages. As soon as the BTS perceives this
countdown has started, it begins reallocation of the timeslots affected. It allocates these on a
best fit basis using all of the user allocation of switchable timeslots and within the capability
of the MS to receive the data. Transmitted blocks are kept until the ACK is received, in case
retransmission is required. If a waiting packet expires, it is discarded.
NOTE
Only PDTCHs can be used for packet switched data. GSM timeslots cannot
be allocated to packet switched calls. If a switchable GPRS timeslot is
allocated to GSM it cannot be restored to GPRS use until the threshold set by
gprs_reconfig_thresh_idle_tch has been exceeded for free TCH timeslots.
The following parameters can be used with the chg_element and chg_cell_element commands
to specify the queue management feature:
queue_management_information - Displays the number of subscribers that can wait in
a queue for channel assignment.
max_q_length_chan - Sets the maximum number of MSs that can wait in a queue for
a full-rate channel assignment.
max_q_length_sdcch - Sets the maximum length of the queue for SDCCH requests.
System impact
The TCH queuing parameters are used by the Cell Resource Manager (CRM) and must be
aligned to the value entered in the MSC. A value of 0 for the queue_management_information
parameter indicates that queuing is not allowed.
SDCCH queuing causes possible delays in attempting SDCCH to SDCCH handovers.
68P02901W36-S 5-47
Jul 2008
Channel release Chapter 5: Cells
Channel release

Channel release function
In this section message sequences are shown for channel release when calls are cleared. Call
clearing can be originated by the MS, the BSS or the MSC.
MS originated call clearing
Figure 5-7 shows the call clearing message sequence when initiated by the MS.
Figure 5-7 Call clearing initiated by MS
5-48 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation MSC originated call clearing
MSC originated call clearing
Figure 5-8 shows the call clearing message sequence when initiated by the MSC.
Figure 5-8 Call clearing initiated by MSC
The timer parameters, used with the chg_element and chg_cell_element commands, that can
affect message sequence due to expiry before expected events are as follows:
radio_chan_released - Ensures that the transceiver resources are actually released for
reuse.
rf_chan_rel_ack - Ensures that the internal RSS and RRSM resources of the BTS are
actually released for reuse.
rr_t3109 - Guard timer to ensure that the SACCH is actually released.
rr_t3111 - Delays the actual deactivation procedure for an SDCCH and TCH so that it
cannot be reallocated before the call clearing operation is complete.
sccp_released - Guard timer to ensure the actual release of the SCCP layer.
68P02901W36-S 5-49
Jul 2008
The timer manual Maintenance Information: BSS Timers (68P02901W58) describes the action
of these timers in more detail.
5-50 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GSM flow control
GSM flow control

BSS initiated flow control function
GSM flow control reduces the number of access bursts sent to a site according to the traffic
loading. Flow control takes place in the following channels:
Traffic channels (TCHs).
Random access control channels (RACCHs).
Signaling state machine (SSM).
The flow control features are not optional, but can be restricted if required.
TCH flow control
TCH flow control is necessary to avoid overload conditions on the RACH, CRM or SSM.
CRM overload control is enabled by the change_element command tch_flow_control.
It is further controlled by the two parameters: tch_busy_critical_threshold and
tch_busy_norm_threshold.
When the CRM allocates a TCH it checks both thresholds.
If the tch_busy_norm_threshold is exceeded, the CRM randomly bars one access class (09)
after which two timers T1 and T2 are started (flow_control_t1, flow_control_t2). These timers
control the rate at which access classes are barred and unbarred.
When an overload condition is initiated by the MSC in a situation of high TCH usage, the CRM
subsystem in the BTS starts the timer flow_control_t1. This timer is used in conjunction with
timer flow_control_t2 to control the barring and unbarring of access classes.
This prevents a class of user MSs from making calls on the network and hence reduces the load
on the MSC. This mobile access class information is carried to the mobile subscriber in the
SYSTEM INFORMATION message specified in GSM recommendations.
The BTS (CRM) timer flow_control_t1 specifies the interval that must elapse before new
overload messages of a particular access class are considered by the flow control mechanism.
BSS flow control operation
As soon as an overload condition is initiated by the MSC, CRM bars an access class and
generates the flow control procedure has started barring normal calls from access
classes 0-9 alarm. CRM starts timers flow_control_t1 and flow_control_t2. While
flow_control_t1 is running, CRM ignores all further overload messages.
68P02901W36-S 5-51
Jul 2008
BSS flow control operation Chapter 5: Cells
If, after expiry of flow_control_t1 with flow_control_t2 still running, another overload message
is received, another access class is barred and both timers are restarted.
If, however, timer flow_control_t2 expires without any further overload messages having
been received, an access class is unbarred and only flow_control_t2 is restarted. This
continues as long as no further overload messages are received until all classes are
unbarred, at which time, the flow control procedure has started barring normal calls
from access classes 0-9 alarm is cleared. Of course, if during this process another
overload message is received, another access class is barred and both timers are restarted.
Figure 5-9 shows the operation of the two timers. The example assumes that
flow_control_t1 is set to less than flow_control_t2 and uses access classes 8 and 9.
Figure 5-9 Operation of flow_control_t1 and flow_control t2
If tch_busy_critical_threshold is exceeded, the CRM bars any remaining unbarred

classes, two at a time, each time the threshold is exceeded. flow_control_t1 with
flow_control_t2 still take an active part in barring and unbarring classes.
GSM name
FC_T1 3GPP Technical Specification GSM 08.58.
5-52 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation RACH flow control
RACH flow control
The parameters rach_load_period and ccch_load_period work in conjunction with a

change_element command, rach_load_threshold, to provide traffic flow control by allowing
the RSS to monitor the number of channel requests received in a given period. If this number
exceeds the rach_load_threshold then the RSS transmits a load indication message to call
processing.
On receipt of this message, call processing bars one random access class (09). Simultaneously,
CP starts timers T1 and T2 (flow_control_t1 and flow_control_t2). See Figure 5-9 for the
process of barring and unbarring.
Both the rach_load_period and ccch_load_period are in multiples of 235.5 ms (1 x 51 frame).

The rach_load_period determines the period over which the RACH load is monitored. The
ccch_load_period is in operation only when an overload condition has been triggered in the
previous period (RACH or CCCH).
The rach_load_threshold parameter is calculated as follows:
Total number of channels (TCH/SDCCH) 100

RACH load threshold =
No of RACHs in period No of RACH timeslots
Where:
The numerator is the number of SDCCH sub-slots and TCHs configured for the cell.
The denominator is the number of available RACH slots in 4 x 51 multiframes. This changes
depending on the value of ccch_conf.
The resulting percentage is the rach_load_threshold, with a granularity of 0.01%.
SSM flow control
This feature is implemented to help reduce the loading on an instance of SSM. The
triggers are that either ssm_normal_overload_threshold (one access class barred) or
ssm_critical_overload_threshold (two access classes barred) have been met or exceeded.
These thresholds are calculated as follows:
For GPROC 1
Active calls on that instance of SSM 100
400
For GPROC 2 and GPROC 3

Active calls on that instance of SSM 100
800
Where: Is:
400 the maximum number of calls that can be supported using a GPROC 1.
800 the maximum number of calls that can be supported using a GPROC 2 or GPROC 3.
The normal threshold must be less than the critical threshold.
68P02901W36-S 5-53
Jul 2008
MSC initiated flow control Chapter 5: Cells
The CRM is informed of the threshold met or exceeded and carries out the same procedure as
TFC or RACH flow control.
MSC initiated flow control
The MSC overload control feature adds to the BSS functionality flow control functions specified
within GSM recommendations to support the OVERLOAD message from the MSC on the
A-interface.
The MSC overload control feature extends the flow control mechanism in the BSS to temporarily
reduce the flow of traffic between the MSC and the BSS. This mechanism allows the MSC to
notify the BSS that it is becoming overloaded and to reduce the amount of information being
sent to the MSC from the BSS.
On becoming overloaded, the MSC sends an OVERLOAD message to the BSS. The BSS receives
this message and immediately starts to reduce the traffic loading on the MSC, by barring mobile
access classes within cells in the BSS.
Multiple OVERLOAD messages can be sent from the MSC to the BSS. There is a danger that
access classes will be barred too rapidly, resulting in all access classes being restricted
throughout the BSS. To guard against this a timer is started on reception of an OVERLOAD
message. This timer is called T17. The BSS ignores all subsequent OVERLOAD messages
received after the first instance until T17 expires. When T17 has expired the next OVERLOAD
message received by the BSS will result in the next access class being barred and T17 is
restarted. Timer T17 duration is set by the flow_control_t1 parameter.
There is no message sent from the MSC to the BSS notifying the BSS that the MSC processor
overload condition has cleared. The unbarring of the access classes to increase the traffic to
the MSC is controlled by a timer. This timer is called T18. This timer is also started when the
first OVERLOAD message is received. If no subsequent OVERLOAD message has been received
when the T18 timer expires then the BSS will unbar an access class. The T18 timer will then
be restarted, unless all of the access classes are now unbarred. Timer T18 duration is set
by the flow_control_t2 parameter.
The reception of an OVERLOAD message after the expiry of T17, but before the expiry of T18,
will result in the barring of a mobile access class and both timers T17 and T18 are restarted.
5-54 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation MSC initiated flow control
Example 1
Figure 5-10 shows a single OVERLOAD message received. A single access class is barred and
then unbarred after expiry of the controlling timer.
Figure 5-10 Single overload message received
Example 2
Figure 5-11 shows two OVERLOAD messages received. Only a single access class is barred
and then unbarred. This is because the second OVERLOAD message is received before T17
has expired.
Figure 5-11 Two overload messages received
Example 3
Figure 5-12 shows three OVERLOAD messages received. Two access classes are barred and
then unbarred. This is because the second OVERLOAD message is received before T17 has
expired and is ignored. The third OVERLOAD message is received after the expiry of T17 and
results in the barring of a second access class.
68P02901W36-S 5-55
Jul 2008
MSC initiated flow control Chapter 5: Cells
Figure 5-12 Three overload messages received
OVERLOAD message ignored
The current BSS initiated flow control mechanisms cause a flow control alarm to be raised in
each affected cell for the duration of the flow control. The MSC initiated flow control will not
cause this cell alarm to be raised for the following reasons:
The flow control is not the result of a BSS problem.
Many of alarms could result from a single MSC overload message.
It is assumed that the MSC will report an alarm detailing the cause of the problem.
As already described, there are three BSS initiated flow control mechanisms:
SCCP state machine overload based on the call information blocks.
Cell resource overload based on the utilization of traffic channels.
Radio subsystem overload based on overloading of the AGCH, RACH channels.
The effect of the existing T1 timer in preventing additional flow control from the BSS applies
equally to MSC initiated flow control. Similarly, the effect of the T17 timer on preventing
additional MSC flow control also applies to BSS flow control requests. However, if the cell flow
control alarm has not been raised then it is raised on reception of a BSS flow control request at
the cell, regardless of what timers are active.
NOTE
The cell flow control alarm will only be cleared when all flow control, however
initiated, is cleared.
5-56 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation AGCH flow control management
If the system has SPI or a reset in progress any messages from the MSC relating to an overload
condition are ignored.
The BSS retains statistics to allow the user to trace the effect of the OVERLOAD message
on the BSS.
AGCH flow control management
{31565}
AGCH flow control feature allows the user to manually enable or disable Access Grant Channel
(AGCH) flow control. The users can enable AGCH flow control on the required cells and disable
the AGCH flow control on other cells based on different network situations.
It provides the users with the option to avoid frequent triggering of AGCH overload due to
the trigger of Immediate Assign Reject (IAR). It also adds additional counter array statistic
IA_IAR_MSGS_PER_AGCH to monitor the number of Immediate Assign (IA) or IAR messages
sent over CCCH or discarded when AGCH overload respectively.
The BSS supports a per cell element _cell_data, 20 which indicates whether the functionality of
the AGCH flow control is enabled or disabled. It also specifies the triggers associated with IA
or IAR that can trigger the AGCH overload.
When the functionality of AGCH flow control is disabled, the overall flow control works by
appropriately configuring other parameters that affect RACH/TCH/SSM flow control.
NOTE
To make the overall functionality of flow control efficiently on system level work, it is
recommended that at least one flow control must be enabled and work well.
The following parameters can be used to specify GSM flow control:

tch_flow_control - Enables or disables the TCH flow control option.
tch_busy_critical_threshold - Sets the threshold for initiating the flow control procedure
barring two of the access classes 0 through 9 from making calls due to TCH congestion.
tch_busy_norm_threshold - Sets the threshold for initiating the flow control procedure to
bar a single access class 0 through 9 from making a call due to TCH congestion.
ccch_load_period - Indicates the number of TDMA multiframes between successive

calculations of the RACH load during overload conditions.
rach_load_period - Indicates the number of TDMA multiframes between successive

calculations of the RACH load during non-overload conditions.
68P02901W36-S 5-57
Jul 2008
Related statistic Chapter 5: Cells
rach_load_threshold - Specifies the threshold level for RACH load.
ccch_conf - Defines the organization of the CCCHs on the BCCH.
ssm_normal_overload_threshold - Indicates the usage of call information blocks, as a

ratio of active calls to the maximum calls that the SSM can handle, before an access
class is barred.
ssm_critical_overload_threshold - Indicates the usage of call information blocks, as

a ratio of active calls to the maximum calls that the SSM can handle, before no MS
originated calls are allowed.
bss_msc_overload_allowed - Controls whether the BSS acts upon OVERLOAD messages

received from the MSC.
flow_control_t1 - Specifies the interval that must elapse before new OVERLOAD message
of a particular access class are considered by the flow control mechanism.
NOTE
This is the internal overload message which can originate from either the MSC
or BSS.
flow_control_t2-Specifies the interval that must elapse before an access class, on which a
bar on new OVERLOAD messages has previously been set, can be brought back into service.
NOTE
This is the internal overload message which can originate from either the MSC
or BSS.
Related statistic
The MSC_OVLD_MSGS_RX statistic records the number of OVERLOAD messages received

from the MSC.
System impact
For all control methods, MS access classes can be barred to reduce cell loading.
When the ssm_critical_overload_threshold parameter is exceeded, no MS originated calls

are allowed.
When a cell is deleted from an INS site, the flow control cell alarm is cleared. The OMC
reports the wrong cell ID.
5-58 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Adaptive Multi-Rate (AMR) TCH flow control
Adaptive Multi-Rate (AMR) TCH flow control
TCH flow control is a mechanism provided to allow access to cell control, based on the TCH
usage within that cell. When the congestion level (based on outer zone usage) within the cell
exceeds operator defined thresholds, the BSS begins to bar access classes by updating the
system information messages sent on the BCCH. There are two thresholds related to this feature:
tch_busy_norm_threshold.
tch_busy_critical_threshold.
An incoming call is not considered in the calculation to determine whether the

tch_busy_norm_threshold or tch_busy_critical_threshold is exceeded. For example, if
tch_busy_norm_threshold is set to 0, the flow control is not triggered.
This TCH flow control mechanism is triggered currently when a Full-Rate (FR) or Half-Rate
(HR) traffic channel becomes busy with a call.
When the congestion level of the cell is calculated, idle generic traffic timeslots, busy and idle
HR channels are taken into account. FR and HR resources within the outer zone are considered
when calculating the congestion level for use in triggering of TCH Flow Control.
TCH allocation priority
TCH allocation priority allocates priority for idle TCHs allocation to incoming calls. Each carrier
within the cell can be given a priority, higher priority TCH carriers are allocated before lower
priority carriers with the same interference band.
NOTE
EFR/AMR, FR/AMR, HR capability is considered before the TCH allocation priority,
in order to match the call capability with the carrier.
With the introduction of AMR FR and AMR HR, the BSS has to manage three new idle resources:
Idle AMR FR TCHs.
Idle generic TCHs.
Idle AMR HR TCHs.
The TCH allocation priority functionality functions in an identical way for these new idle
resources as it does for the current idle resources.
The BSS orders all idle traffic channels with respect to the TCH allocation priority within an
interference band. This means that the TCHs on the carrier with the highest priority are
allocated first.
68P02901W36-S 5-59
Jul 2008
GPRS flow control Chapter 5: Cells
GPRS flow control

Description of GPRS flow control
GPRS flow control is provided by the Leaky Bucket method, which is based on the PCU sending
flow control parameters to the SGSN. The SGSN performs flow control for each LLC_SDU
on a MS and BSSGP Virtual Circuit (BVC).
The principle is that the SGSN should not be able to transmit more data than can be contained
in the PCU buffer for a BVC. The system performs flow control on each MS, ensuring that one
MS does not take up the whole of the buffer. This is achieved by the PCU sending a flow control
message containing the Buffer size and leak rate for each TLLI to the SGSN. A percentage value
of the buffer size may also be sent if the parameter bssgp_cbl_bit is enabled.
NOTE
Enabling the bssgp_cbl_bit parameter may trigger a reset of the SGSN resulting
in a loss of service.
Initially the SGSN uses default values until new values are sent in a flow control message.
The frequency at which the flow control information is presented to the SGSN is set by the
parameter bssgp_fc_period_c.
Refer to Chapter 3 BSS Links for a full description of BVC and MS flow control.
5-60 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Mobile System (MS) control
Mobile System (MS) control

MS paging
An MS is required to receive and analyze the paging messages on its paging group.
Common control channel block configuration
On the non-combined BCCH or CCCH multiframe, there are nine CCCH blocks. In the downlink
direction these blocks serve the paging and access granted functions and must be configured
accordingly.
On the combined multiframe structure the number of blocks available is reduced to three
because it now supports four SDCCH/SACCH.
The bs_ag_blks_res field sets the number of blocks reserved for access grant per 51 TDMA
multiframes. The number of paging blocks available is reduced by the number of blocks
reserved for access grant messages. The choice of value is determined by the ratio of
MS-originated to MS-terminated calls.
This parameter is broadcast on BCCH system information messages to an idle MS and is used
by the MS to determine its paging group.
If the paging message uses the TMSI number then four pages can be packed into one paging
group, which takes four consecutive bursts in timeslot 0 to transmit. If IMSI is used the number
of MSs that can be paged in one message is only two.
The field bs_pa_mfrms indicates the number of 51 multiframes between transmission of paging
messages to MSs of the same group.
Therefore, the total number of paging groups per control channel is the total number of CCCH
blocks per timeslot, minus the bs_ag_blks_res multiplied by the bs_pa_mfrms field. MS are
normally required to monitor every nth block where n equals the number of available blocks in
total.
This parameter is broadcast on BCCH system information messages and is one of the fields used
by an idle mobile along with ccch_conf, bs_ag_blks_res and the IMSI number of the MS, to
determine its paging group (formula in GSM 5.02).
In the example shown in Figure 5-13 with ccch_conf set to 0 (No CCCH timeslots used),
bs_ag_blks_res set to 1 (1 block reserved for access grant per 51 multiframes) and
bs_pa_mfrms set to 2 (4 multiframes between transmissions of paging messages to MSs), the
positioning of the Access Grant Channels (AGCHs) is shown. The figure shows setting the
parameters to configure 32 paging groups and four access grant channels every 942 ms.
Figure 5-13 show an example of AGCH positioning.
68P02901W36-S 5-61
Jul 2008
Extended paging Chapter 5: Cells
Figure 5-13 Example AGCH positioning
8 16 24 32 8
7 15 23 31 7
6 14 22 30 6
5 13 21 29 5
4 12 20 28 4
235.5
mS
3 11 19 27 3
2 10 18 26 2
1 9 17 25 1
AGCH AGCH AGCH AGCH AGCH
BCCH BCCH BCCH BCCH BCCH
ti-GS M-AGCH pos itioning-00197-a i-sw
Extended paging
If extended paging is permitted and there are more than four pages for a particular subgroup
then the fifth to eighth pages can be packed into the next but one paging subgroup. The MS
is informed by the page mode flag in the paging message that extended paging has been
dynamically activated. The MS switches on and interrogates the next but one paging group
ahead. Extended paging is deactivated by disabling this flag in add_cell.
More than eight pages for a particular subgroup will not be broadcast until the reappearance of
that paging subgroup. The pages are stored in a buffer.
Preferred number of SDCCH
On initialization, the CRM is informed of the number_sdcchs_preferred field in the database

which will control the number of SDCCHs that will be configured in a particular cell. The
number of SDCCHs is dependent upon the configuration of timeslot 0 on the BCCH carrier,
whether it supports four SDCCHs or whether all SDCCHs are on their own timeslot at eight
SDCCHs per timeslot.
5-62 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Cell barring
Cell barring

Cell barring function
A Mobile Subscriber (MS) can be flagged as barred from making calls on a particular cell; this
barring can be generated internally by the GSM system (for example, by the billing system) or
externally by the operator. Barring can be:
Full.
By MS class.
Traffic control.
For emergency calls only.
Full barring
Cell bar information is transmitted within system information messages to idle MSs. The
network operator, through the MMI, can completely bar access to all normal subscribers in a
particular cell, using the cell_bar_access_switch field.
Users of test phones can employ a mask to enable them to make calls; pages are still transmitted
in barred cells, allowing test MSs to receive calls.
Existing calls can be handed over to a cell which is barred. When the MS completes the call in
this barred cell and returns to the idle state, selection or reselection is to another cell.
Barring by class
The cell_bar_access_class element in the database allows access only to specified MS classes.
This field is mapped onto the BCCH system information field of the cell and informs all MSs
in the cell range which classes of MS are permitted access. Only normal user classes 0 to 9
can be barred using the barring by class flag.
NOTE
User class 10 calls cannot ever be barred.
68P02901W36-S 5-63
Jul 2008
Traffic control
The traffic control reduces the load on the system when the TCH usage goes above thresholds
determined by tch_busy_norm_threshold and tch_busy_critical_threshold parameters.
This control can be achieved by two methods:
Automatic reduction - The flow control procedure reduces the system load when the
TCH usage goes above set thresholds. The reduction in traffic is achieved by barring
access classes.
Manual reduction - The list of authorized access classes is broadcast on the BCCH by
system information messages. The classes also have access to emergency calls. A channel
request can only be initiated when the access class of the mobile is not barred.
Emergency call access
A part of the BCCH system information messages contains the emergency_class_switch field
informing the MS that either all MS are permitted to make emergency calls, or only those
belonging to classes 10 and 11 to 15.
The following parameters can be changed by use of the chg_element or chg_cell_element

commands for cell barring:
emergency_class_switch - Sets a flag to enable or disable emergency calls by access class
(all classes allowed emergency calls or only classes 11 to 15. Class 10 always allowed).
cell_bar_access_class - Defines access classes that are barred access to the PLMN.
cell_bar_access_switch - Determines whether subscribers are barred access to a cell

in idle mode.
Automatic traffic reduction
The following parameters are used with automatic traffic control:

tch_flow_control - Enables or disables TCH flow control.
tch_busy_norm_threshold - Sets the threshold for initiating the flow control procedure to
bar a single access class zero to nine from making a call due to congestion.
tch_busy_critical_threshold - Sets the threshold for initiating the flow control procedure
barring two of the access classes zero to nine from making calls due to congestion.
5-64 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation System impact
Manual traffic reduction
The following parameters are used with manual traffic control:

emergency_class_switch - Acts as a flag to enable or disable emergency calls b access
class.

in idle mode.
System impact
Emergency calls are not available when using full barring.
When barring by class, MSs can still handover into a barred cell, but cannot originate a call.
With automatic traffic control if both thresholds are reached a maximum reduction of 33% in
traffic can be achieved. This excludes the number of emergency calls and depends on the
TCH usage.
With manual traffic control the access classes barred will not have access to the PLMN. All
access classes can be barred permanently, except emergency calls which will always have
access to the network. This must be manually initiated and does not depend on TCH usage.
Under emergency call access barring, all normal class access MSs (classes 0 to 9) are barred
from making emergency calls.
68P02901W36-S 5-65
Jul 2008
Call re-establishment Chapter 5: Cells
Call re-establishment

Call re-establishment function
Call re-establishment permits a call to be re-established in the event of a radio link failure.
If a radio link has failed, for example, due to an MS passing through a tunnel, the MS samples
the received signal strength of BCCH carriers, the original serving cell and the TCH. The
MS then averages the measurements taken and then selects the cell having the highest
average. Assuming that the selected cell is one of the home PLMN cells or one supporting
roaming, that the cell is not barred and that the reestablish_allowed field is set to permit call
re-establishment then the MS attempts to re-establish the call.
If the MS is unsuccessful on the selected cell, it can attempt the same process on five
other cells offering the highest received signal strength measurement. If still unsuccessful,
re-establishment is aborted.
The reestablish_allowed parameter, used with the chg_element or chg_cell_element

commands, enables or disables call re-establishment after a radio link failure.
5-66 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Cease transmission when cell goes Out-Of-Service
Cease transmission when cell goes Out-Of-Service

Overview
This feature stops RF transmission if a cell goes out-of-service; for example, failure of the
last RSL or the BCCH RTF being unequipped.
There could also be problems affecting non-BCCH carriers. For example, carriers transmitted
on an out-of-service cell cannot be accessed remotely because the transmission problem could
impede a frequency replan involving neighboring cells.
CELL transitions
Upon failure of the last RSL:

A CELL DISABLE message transitions the cell to DU: STOP DRIS TRANSMITTING.
A new STOP_DRI_TX disable transition is requested for the cell to take place after a set
period of time. A time-out is appended for the cell.
A DISABLE STOP_DRI_TX transition only takes place if the CELL is DU: STOP DRIS
TRANSMITTING when the time-out expires:
The CELL transitions to DU: NO REASON.
DRI DISABLE: CELL OOS transitions are requested for all the BU DRIs in the CELL.
The CELL transition waits for their completion.
If a CELL ENABLE is requested and the CELL is in DU: STOP DRIS TRANSMITTING state:
The time-out is canceled and the CELL will be re-enabled and set to BU: NO REASON.
During a CELL ENABLE transition, if the CELL is DU: NO REASON:

DRI ENABLE: CELL INS requests are sent to CA for DRIs in the CELL which are
BU: CELL OOS.
DRI transitions
If the PCHNs on the DRI are not in BATTERY_CONSERVATION mode, during a DRI DISABLE:
CELL OOS transition, they are taken OOS and set to the DU: CELL OOS:
The transmit power of the BCCH is attenuated by the maximum amount, to reduce the
transmit power to minimum.
The exciter bit is cleared in the CEB MASK to switch off the PA.
The DRI is set into the BU: CELL OOS.
68P02901W36-S 5-67
Jul 2008
PCHN transitions Chapter 5: Cells
If the CELL of the DRI is not INS and the DRI is not in BATTERY CONSERVATION mode during
a DRI ENABLE transition, the DRI will not start transmitting:
TIMESLOT_STATE_CHANGE messages are sent to CRM to notify that the timeslots are
OOS.
The PCHN states are set to DU: CELL OOS. The DRI continues to come INS, but at the end
of the transition, it is set to BU: CELL OOS.
During a DRI ENABLE: CELL INS transition, if the PCHNs on the DRI are not in
BATTERY_CONSERVATION mode they are brought INS:
CELL OOS is removed.
The transmit power of the BCCH is attenuated by the amount specified in the database.
The exciter bit is set in the CEB MASK to switch on the PA.
The DRI is then set into the BU state with CELL OOS removed.
PCHN transitions
During a PCHN DISABLE: CELL OOS transition, if the PCHNs are not in BATTERY
CONSERVATION mode:
TIMESLOT_STATE_CHANGE messages are sent to notify CRM of the timeslots going OOS,
which causes the active calls on each timeslot to drop.
The PCHNs are set to DU: CELL OOS/Battery Cons to denote that the PCHNs are OOS
for both the battery conservation and CELL OOS reasons.
During a PCHN DISABLE: CELL OOS transition, if

the PCHNs are in BATTERY CONSERVATION mode:
The PCHNs are set into the DU: CELL OOS state.
During a PCHN ENABLE: CELL INS transition, if the PCHNs are not in BATTERY
CONSERVATION mode:
TIMESLOT_STATE_CHANGE messages are sent to notify CRM that the timeslots are INS.
The PCHNs are set into the BU: NO REASON state.
During a PCHN ENABLE: CELL INS transition, if

the PCHNs are in BATTERY CONSERVATION mode:
The PCHNs are set into the DU state, CELL OOS is removed.
COMB communication
If an attempt to communicate with a COMB is made when the controller is in the CELL
OOS state, the exciter bit will be enabled for the communication to be successful. When
communication with the COMB is complete, the exciter bit is disabled.
5-68 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Feature enabling and disabling
Feature enabling and disabling
If the functionality is enabled during normal operational mode, all the BU DRIs in a OOS
CELL must be brought into the BU: CELL OOS state. The CELL will be set in DU: STOP DRIS
TRANSMITTING and a CELL DISABLE: STOP_DRI_TX delayed transition will be requested.
If the functionality is disabled during normal operational mode, all the BU: CELL OOS DRIs
in a OOS CELL, must be ENABLED with reason CELL INS. All CELLs in DU: STOP DRIS
TRANSMITTING should return to DU: NO REASON and all the appended CELL time-outs
will be canceled.
Functionality is enabled or disabled on a per BSS basis during SYSGEN mode and during normal
operational mode (outside SYSGEN), using the database parameter stop_dri_tx_enable.
The following commands also support functionality of this feature:

chg_element
disp_element
The period of time between the CELL going OOS and the radios stop transmitting can be
adjusted using the database parameter stop_dri_tx_time. This value can be changed at any
time, but it will not have effect on the CELL transitioning at that time.
68P02901W36-S 5-69
Jul 2008
Concentric cells Chapter 5: Cells
Concentric cells

Purpose of concentric cells
Concentric cells allow the RF resource allocation for a cell to consist of two frequency channel
groups with a single BCCH frequency to operate in the same coverage area. One of the channel
groups which includes the BCCH provides service to the entire coverage area of the cell (the
outer zone). The second channel group provides service to a smaller area within the coverage
area (the inner zone). This cell structure provides increased capacity through more efficient
reuse of the inner zone frequencies.
The concentric cells feature is optional and if restricted, none of its software processes are
functional.
MS assignment to the inner or outer zone is based on the received signal level of the serving
cell (power-based algorithm) or a comparison of signal levels from the serving and neighbor
cells (interference-based algorithm). Transition between zones is controlled using intra-cell
procedures.
Cell resource partitioning is used to separate the concentric cells to allow for tighter frequency
reuse patterns and increased frequency economy. The operator can configure non-BCCH
carriers within a cell to have a smaller coverage area. The carriers equipped within a cell can be
grouped into zones. Zone 0 (also referred to as the outer zone) is reserved for carriers that
broadcast at the maximum transmit level defined for the cell. Zone 0 always contains the BCCH
carrier. Zone 1 (also referred to as the inner zone) can be defined with non-BCCH carriers.
An MS must meet specified criteria before it can be assigned a traffic channel configured on
a carrier in zone 1.
Concentric cells allow the operator to select between two different algorithms when defining
zone 1 in a cell:
Power based algorithm.
Interference based algorithm.
Both algorithms are described in the following sections.
Power based algorithm
Using this algorithm, the carriers defined to be in the inner zone have reduced maximum uplink
and downlink transmit levels. The coverage area of the inner zone is defined by the maximum
transmit levels of the inner zone carriers. The decision to perform an intra-cell handover
between carriers of different zones is based on power control algorithms. For example, in
Figure 5-14 the decision to move an MS between Zone 0 and Zone 1 is based on the power
levels between the MS and the serving cell.
5-70 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Purpose of concentric cells
Figure 5-14 Concentric cells-power based
Using the power based algorithm, the operator can set each carrier in the inner zone to
different maximum downlink transmit power levels. Using this configuration, the BSS performs
handovers between inner zone carriers based on the same algorithms used to perform
handovers between zones. By utilizing this functionality, the operator can effectively configure
multiple subzones within zone 1. However, all carriers defined to be in zone 1 share the same
maximum uplink transmit level. All carriers defined to be in zone 0 have maximum downlink
transmit level defined by the BCCH power level and the maximum uplink transmit level as
defined per cell in the database.
A concentric cell can be configured, using the power based algorithm, to have a number of power
bands within the inner zone. The BSS does not restrict the placement of an AMR-HR/AMR-FR
capable carrier within the inner zone. It is possible that the AMR-HR/AMR-FR capable carrier
is equipped as one of the weaker power carriers in the Inner zone. The AMR-HR/AMR-FR
capability within the inner zone can not be available to all MSs attempting to access the inner
zone. The AMR capability should be equipped within the highest power band within the inner
zone to ensure that the AMR resources have the highest possible availability.
Interference based algorithm
Using this algorithm, the coverage area of the inner zone is defined by interference levels from
neighbor cells, which use an interfering frequency (for example, the same or a nearby cell
frequency). The decision to perform an intra-cell handover between carriers of different zones is
based on path loss calculations between the MS and the serving cell and the MS and neighbor
cells, utilizing an interfering frequency of the candidate carrier. For example, in Figure 5-15 the
decision to move a call from zone 0 to zone 1 in cell A is based on serving cell measurements
and signal strength measurements of the neighbor cells B and C. When adding a neighbor to a
cells neighbor list, the operator indicates if:
68P02901W36-S 5-71
Jul 2008
Purpose of concentric cells Chapter 5: Cells
The neighbor uses an interfering frequency.
An interference threshold is to be used to determine if the neighbor is strong enough

to interfere with a call in the inner zone.
A margin to ensure enough headroom in the signal strength to prevent the call from
handing back out of the inner zone quickly.
Figure 5-15 Interference based algorithm
Using the interference based algorithm, all carriers in the cell use the BCCH power level as the
maximum downlink transmit level and the database defined per cell parameter for maximum
uplink transmit level. When using the interference based algorithm, the operator must be
aware that changing the frequency of a carrier, equipping a new carrier or unequipping a
carrier could result in the need to re-evaluate the per neighbor database parameters related
to this feature. There is no automatic correction of these database parameters due to any of
these events within the BSS.
5-72 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Related commands and parameters
Statistics
Statistics are added to allow the operator to monitor the usage of channels on each type of
carrier. The current per cell TCH usage and TCH congestion statistics are used for outer zone
resources only. New statistics are added to track the same activities in the inner zone. When
using concentric cells, the inner zone statistics must be enabled to achieve total information
for the cell. New counter arrays are also added to track handovers between the inner and
outer zones.
The parameter inner_zone_alg can be used with the chg_cell_element to specify concentric
cells. It generates several prompts.
The command disp_cell shows the concentric cell settings for the cell.
System impact
Configuration management
The concentric cells feature is optional and if restricted, none of its software processes are
functional. Any attempt to set concentric cell parameters is rejected by the MMI if restricted.
Fault management
The BSS selects a carrier to replace the BCCH carrier using rules to set priority. Carrier units
with pre-assigned RTFs are not considered for replacement of the BCCH carrier.
The replaced carrier is taken out-of-service and the associated carrier unit is used to replace the
BCCH carrier.
Call processing
The CRM process obtains information about the zone of a carrier when the CRM is configuring
carriers and the zone information about each carrier is stored in the CRM to be used for
channel allocation.
The process configures SDCCH channels only on carriers in zone 0. The CRM process configures
only TCH channels on carriers in zone 1.
RSS
The handover process supports additional processing on receipt of a measurement report to

determine if the call qualifies for an inter-zone handover. The handover process uses the per
cell algorithm defined in the database to determine if an inter-zone handover is initiated. The
handover process supports both the power based and interference base algorithms.
68P02901W36-S 5-73
Jul 2008
Adaptive Multi-Rate (AMR) Chapter 5: Cells
Concentric cells
If the concentric cell feature is enabled, the ERC cannot be an inner carrier.
Utilization of AMR half-rate in the inner zone of a multi-zone cell
For multi-zone cells (concentric cells and dual band cells), the reconfig_fr_to_hr and
new_calls_hr thresholds are triggered by the use of the outer zone only, within a cell. It
is possible that the inner zone has low use and the outer zone is congested such that the
reconfig_fr_to_hr threshold is exceeded.
NOTE
The thresholds governing assignation of existing or new calls as either full or

half-rate are still applicable to intra-cell handovers.
Incoming calls are considered in the calculation to determine whether the
reconfig_fr_to_hr threshold is exceeded. The reconfig_fr_to_hr parameter
relates to reconfiguration of established calls. If reconfig_fr_to_hr is set to 0,
the first call is not established on an HR channel even though the threshold is
exceeded, because there are no existing calls to reconfigure. Calls performing
intracell handovers are only considered once in the calculation.
The BSS attempts to trigger Full-Rate (FR) to Half-Rate (HR) intra-cell handovers for suitable
calls. If some of the calls are within the inner zone, the BSS attempts to reconfigure the HR
capable FR calls to HR when the inner zone is not congested. To prevent this occurring some
further parameters are applied.
The inner_hr_usage_thres is used when the utilization of HR is triggered by reconfig_fr_to_hr

being exceeded. This is to protect against calls on the inner zone being reconfigured to HR
when inner zone traffic is low.
Congestion level control
The new inner_hr_usage_thres congestion threshold indicates the congestion level. The BSS
allows reconfiguration of HR capable FR calls to AMR HR calls in the inner zone.
If reconfig_fr_to_hr threshold is exceeded, HR capable FR calls on the inner zone will only be
eligible for reconfiguration from FR to HR if the inner_hr_usage_thres is also exceeded. The
exceeded level is calculated using the equation:
Inner zone congestion level >= inner_hr_usage_thres
The FR and HR resources within the inner zone are combined to calculate a congestion level
to establish if the inner_hr_usage_thres has been exceeded. The HR capable FR calls on the
inner zone can be reconfigured from FR to HR only if the congestion level equation defined
above is satisfied.
5-74 68P02901W36-S
Jul 2008
The inner_hr_usage_thres is also used when the utilization of HR is triggered if new_calls_hr

is exceeded. This protects against new calls, assigned to the inner zone, being allocated HR
channels when use of the inner zone is low.
The inner_hr_usage_thres congestion threshold also indicates the congestion level the BSS
allows the assignment of new calls on HR channels in the inner zone. If the new_calls_hr
threshold is exceeded, HR capable calls can only be assigned directly to HR channels within
the inner zone if the inner_hr_usage_thres is also exceeded.
The BSS only allows new HR capable calls to be assigned directly to HR channels within the
inner zone, if the congestion level equation defined above is satisfied.
Reservation of HR resources
A number of HR resources (on generic timeslots) can be reserved for use during congestion. FR
calls are prevented from using these resources until there are no other timeslots available in
the cell/zone. The reserved generic timeslots are applied to each zone within a multi-zone cell.
If two reserved generic timeslots are allocated, two timeslots are reserved on the inner zone
and two timeslots on the outer zone.
The BSS supports the configuration of the new amr_hr_res_ts element to indicate the maximum
number of generic timeslots to be reserved for HR calls within each zone of the cell. Within the
inner zone, the actual value can be dynamically limited to be less than amr_hr_res_ts.
The BSS limits the amr_hr_res_ts for the inner zone, if the BSS detects that the
inner_hr_usage_thres cannot exceed if the amr_hr_res_ts element is left as defined.
The amr_hr_res_ts element is also limited by the number of HR capable resources available in
the cell or zone. There are no specific dedicated HR reserved timeslots. Any timeslot on an HR
capable carrier can be considered reserved if FR calls have not been assigned to them due there
only being amr_hr_res_ts number of timeslots left in the cell or zone.
The number of HR timeslots allowed to be reserved within a cell are dynamically limited so
that the inner zone can still exceed the inner_hr_usage_thres threshold. The number of HR
timeslots to be reserved has to be dynamically limited for the following reasons:
Cell capacity can be reduced by a carrier becoming unavailable.
Cell capacity can be reduced by a timeslot becoming unavailable.
The inner_hr_usage_thres congestion threshold can be altered by the operator while the
cell is active.
The prerequisites for hr_res_ts to operate, and to prevent Full-Rate only calls using the TS
reserved for Half-Rate, are listed below:
The cell should be equipped with both carrier(s) with Half-Rate enabled and carrier(s)
without Half-Rate enabled.
reconfig_fr_to_hr should be set (should not be equal to 101).
ho_exist_congest should not be set to 0, it should be set to 1 or 2 (both values are valid).
The cell congestion level should be less than reconfig_fr_to_hr.

For more information about these parameters, refer to the manual 68P02901W23 Technical
Description: BSS Command Reference.
68P02901W36-S 5-75
Jul 2008
Adaptive Multi-Rate (AMR) Chapter 5: Cells
Call assignment
HR calls can be assigned to the reserved generic timeslots in the outer zone. The reserved
generic timeslots are available for new calls, set up at HR, if the force_hr_usage element is
set. The reserved generic timeslots are available for calls, set up at HR, due to MSC preference
in the Channel Type IE, or if new_calls_hr, reconfig_fr_to_hr or inner_hr_usage_thres are
exceeded.
In the outer zone, reserved HR capable timeslots are not allocated to FR calls until there are
no more FR resources available in the outer zone. The reserved HR capable timeslots can be
used by HR calls at any time.
FR calls cannot be assigned to the reserved generic timeslots within the outer zone until all
other possible resources that qualify to support the FR call have been exhausted. This ensures
that the last timeslots to be allocated within a cell are HR capable and gives the BSS maximum
flexibility for allocating resources within congestion scenarios.
Switchable PDTCHs are allocated to FR calls prior to the reserved HR capable timeslots. The
only exception to this is when the only available resource able to support the FR request is
the last GPRS timeslot and the protect_last _ts functionality is enabled. Generic timeslots
are reserved in order to ensure availability of HR capable resources, should the cell reach a
congestion level that would trigger reconfiguration to AMR HR of HR-capable FR calls. The
reservation of generic timeslots is linked to the triggering of this reconfiguration procedure.
Generic timeslots are not classed as reserved when the reconfig_fr_to_hr threshold is not
applied. The threshold is not applied when congestion relief is not enabled in the cell, or when
the reconfiguration of HR-capable FR calls is disabled. The outer zone generic timeslots
are not classed as reserved if the use level in the outer zone exceeds the reconfig_fr_to_hr
reconfiguration threshold. Inner zone generic timeslots are not classed as reserved if the use
level in the outer zone exceeds the reconfig_fr_to_hr reconfiguration threshold and the use
level in the inner zone exceeds inner_hr_usage_thres.
Once inner_hr_usage_thres is exceeded, call reconfiguration is complete and HR capable

resources do not need to be reserved. In the inner zone (of a multi-zone cell), the reserved
HR capable timeslots are not allocated to FR calls until the inner_hr_usage_thres has
been exceeded and the use of HR has been triggered by congestion of the outer zone
(reconfig_fr_to_hr or new_calls_hr exceeded). This means that the reserved HR capable
timeslots are barred from use by FR calls, so that when HR use is allowed within the inner zone
there are HR capable resources available.
FR calls cannot be assigned to the reserved generic timeslots within the inner zone until there
are no resources available in the inner and outer zones. This will prevent the inner zone
becoming full with FR calls. Thus, when the outer zone congestion level exceeds new_calls_hr
or reconfig_fr_to_hr, there will be idle HR capable resources within the inner zone to remove
congestion.
5-76 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Encryption
Encryption

GSM encryption function
The optional GSM encryption function provides security for user speech, data and signaling
information. Implementation of this option enables and prioritizes the GSM A5 encryption
algorithms in the BSS.
Encryption in the BSS can be implemented using the multiple encryption option or individual
encryption options.
Multiple encryption provides all of the available GSM encryption versions.
Individual GSM encryption versions can be purchased and enabled.
Multiple encryption algorithms are loaded into the BSS through the software download. During
configuration of the BSC, the CA informs the SSM of the encryption algorithms supported by the
BSS software. Purchasable algorithms include A5/0 (Null encryption), A5/1 (Full encryption)
and A5/2 (Prime). When the MSC sends the Cipher mode command or handover request, the
message can include just one or a number of permitted algorithms. The SSM decides which of
these algorithms are to be used based on the following criteria:
Capability of the MS as indicated by the classmark.
Permitted algorithms supplied by the MSC.
Algorithms purchased by the operator (stored in the GSM database).
Algorithms supported by the DRIM Firmware.
Operator prioritized list of algorithms (stored in the CM database).
If no algorithms meet the above criteria, the SSM sends the appropriate failure message. If
the BSS selects the encryption algorithm from the set of more than one supplied by the MSC,
the SSM includes the chosen algorithm in the cipher mode complete or handover request
acknowledge message to the MSC.
Multiple encryption priority is not necessary when the individual algorithms (1-7) are used
independently from the multiple encryption option; for example, if a customer purchases just
A5/1.
Multiple A5 encryption algorithm versions purchased by the operator must be enabled by the
change element option_alg_a5 command and prioritized by the chg_a5_alg_pr database
command. The order in which they are entered prioritizes their use. The encryption algorithms
are prioritized on a per-BSS basis and only those prioritized can be used. If no algorithms are
prioritized then the default is no encryption.
68P02901W36-S 5-77
Jul 2008
System impact Chapter 5: Cells
The chg_a5_alg_pr command specifies the A5 encryption algorithms in the order they are
used by the BSS.
The option_alg_a5 parameter can be used with the chg_element or chg_cell_element to permit
the encryption algorithm A5/x.
System impact
For effective use, this feature must be deployed at the MSC, BSS and MS.
5-78 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Discontinuous transmission
Discontinuous transmission

Purpose of discontinuous transmission
Discontinuous transmission (DTX) is available in the uplink and downlink modes.
Uplink DTX is a feature available on MSs which maximizes the battery life by disabling the
transmit function when the subscriber is not passing speech or data during a call and helps to
reduce uplink interference.
The downlink DTX feature helps reduce downlink interference in a cell and disables transmission
on the downlink when there is no speech or data.
Description of DTX
The DTX parameters are different for uplink and downlink specification and depend on whether
speech or non-transparent data is being transmitted.
Uplink DTX
One parameter dtx_required controls uplink discontinuous transmission. It can be set to one of
three values, subject to the MS menu options:
0 (MS can use DTX).
1 (MS will use DTX).
2 (MS will not use DTX).
Downlink DTX
Two parameters: dnlk_vad_dtx and dl_dtx_voice_data, control downlink discontinuous

transmission.
Within the XCDR board is a Voice Activity Detector (VAD). The parameter dnlk_vad_dtx enables
or disables the VAD:
0 (VAD enabled).
1 (VAD disabled).
68P02901W36-S 5-79
Jul 2008
Downlink DTX for speech Chapter 5: Cells
The parameter dl_dtx_voice_data further specifies enablement for speech and/or

non-transparent data, on a per cell basis, as follows:
0 (DTX enabled for speech and disabled for non-transparent data).
1 (DTX disabled for speech and disabled for non-transparent data).
2 (DTX disabled for speech and enabled for non-transparent data).
3 (DTX enabled for speech and enabled for non-transparent data).
NOTE
The effect of the dnlk_vad_dtx and dl_dtx_voice_data parameter settings are
interdependent.
Downlink DTX for speech
VAD disabled
With VAD disabled (dnlk_vad_dtx set to 1):
No voice detection is possible, having the effect of speech always being indicated on downlink
TRAU frames. The channel coder has no VAD capability and reads the speech indication on
the TRAU frame. The channel coder then transmits all TRAU frames regardless of the value
assigned to dl_dtx_voice_data.
VAD enabled
With VAD enabled (dnlk_vad_dtx set to 0):
The VAD at the XCDR is enabled and detects silence on speech frames. Silent frames are
indicated to the channel coder through bits as defined by GSM recommendations. If the
channel coder receives frames with silence indicated, the dl_dtx_voice_data parameter value is
checked. If the dl_dtx_voice_data parameter value is set to 0 or 3, the channel coder transmits
nothing, or silence descriptors (comfort noise) is transmitted. If the dl_dtx_voice_data
parameter value is set to 1 or 2, the channel coder transmits the TRAU frame, even though
silence is indicated from the VAD at the XCDR.
Downlink DTX for non-transparent data
The VAD setting parameter dnlk_vad_dtx has no effect on downlink DTX for non-transparent
data.
For non-transparent data transfer in the downlink direction, the MSC signals whether any
information transfer frames are pending transmission. If the MSC signals no information is
being transmitted, the channel coder checks the dl_dtx_voice_data parameter value. If the
MSC signals that information is being transmitted, the value of dl_dtx_voice_data is ignored.
5-80 68P02901W36-S
Jul 2008
Modified parameters
The following parameters can be modified when used with the DTX feature:
Uplink DTX
dtx_required.
Sets the MS capability to use uplink DTX.
Downlink DTX
dnlk_vad_dtx.
Indicates whether downlink VAD/DTX is enabled (set at the R/XCDR).
dl_dtx_voice_data.
Indicates whether downlink DTX is enabled for speech/non-transparent data, on a per

cell basis.
System impact
Enabling uplink and downlink DTX reduces interference. Enabling uplink DTX also has the
effect of saving MS battery life.
The dnlk_vad_dtx parameter is applicable only in locations where the XCDR is present and
if disabled, will not allow downlink DTX for speech to take place regardless of other DTX
parameters. This parameter replaces the xcdr_d_vad_dtx command.
68P02901W36-S 5-81
Jul 2008
Extended range cell Chapter 5: Cells
Extended range cell

Extended range cell function
With the extended range cell (ERC) function, a PGSM/EGSM cell can be extended from 35
km to 121 km.
The current maximum range of a GSM cell in servicing an MS is limited by the 63 bit period
timing advance. For example, for a PGSM/EGSM cell the current maximum range is 35 km.
In flat rural areas and coastal inlands, the coverage of the cell (through high gain antennas
for example) can be increased beyond normal range. This ability allows coverage of a larger
area without additional BTS sites.
Extended range cells cover the needs of an operator in serving MSs at an extended range
from the base station, without any modifications to the existing MS. The extended range cell
feature is a restricted feature that is enabled per cell. The number of extended range timeslots
is configured per carrier.
Extended range cells can be used only with SCU, TCU and CTU radio units. The MS uses a
timing advance to compensate for the propagation delay as the distance changes to the BTS.
The MS has a maximum timing advance of 63 bit periods. This can only handle propagation
delays within the normal range. As the MS moves beyond the normal range, the radio bursts
can arrive within the next timeslot. Hence, to implement this feature, the base station must be
able to receive the uplink radio bursts in two adjacent timeslots instead of one.
The pairing of the adjacent timeslots changes the allocation of timeslots to logical channels.
Instead of one timeslot, two timeslots are allocated for an extended range channel. In
Figure 5-16 the air timeslots are shown in the x-axis and the number of extended range timeslots
in the y-axis. The contents of each timeslot in the figure indicates the type of channels that it
can hold. If an even timeslot is configured as extended, the following odd one would be its
pair in forming the extended range channel. The extended range timeslot pair will always
be identified by an even number.
All BCCH, CCCH and SDCCH channels in an ERC will be extended range channels. They always
reside on the BCCH carrier. The remaining timeslots in the cell can be configured as normal
range traffic channels or extended range traffic channels.
Normal range traffic channels are allocated for call setup for an MS within the normal range,
while extended range traffic channels are allocated for an MS beyond this range. AMR FR/HR
is not supported in extended range timeslots within extended range cells, but is supported on
normal range timeslots in extended range cells.
5-82 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Extended/normal range handover in isolated areas
Figure 5-16 Mapping of extended range timeslots to air timeslots
Extended/normal range handover in isolated areas
All incoming inter-cell handovers into an ERC are asynchronous. Because the timing advance
is not known, an extended range channel allocation is attempted for all incoming inter-cell
handovers, if an ERC is available. Once established and the timing advance is known, an
intra-cell handover to a normal range channel takes place if the MS is in the normal range. If an
ERC is not initially available, an attempt is made to handover to a normal range cell immediately.
Extended to normal intra-cell handovers occur when the absolute timing advance reduces
below 63. Normal to extended intra-cell handovers occur when the absolute timing advance
increases above 63.
Emergency calls originating from the extended range zone preempt a call on an extended range
channel when resources to service it are unavailable and emergency call preemption is in
operation. Otherwise if the emergency call originates from the normal range zone then a call
on an extended range channel is preempted only if calls in normal range channels cannot be
preempted as shown in Figure 5-17.
68P02901W36-S 5-83
Jul 2008
The number of attempted extended range intra-cell handovers and the number of successful
extended range intra-cell handovers statistics can be used to determine the number of extended
range timeslots to configure in an ERC. The extended range traffic channel usage statistic keeps
track of TCH usage for extended range channels in an ERC.
The ability of the cell to successfully serve an MS beyond the normal range depends on the
system design and implementation of antenna systems, MS and RF hardware.
As soon as an MS moves beyond a specified distance from the antenna in a cell, the ERC
neighbors are allocated priority in the neighbor list.
Figure 5-17 Normal range cells (isolated, boundary) within extended range cells
Commands
equip - Modified to prompt for extended range timeslots when equipping an RTF.
disp_equipment - Displays the number of extended range timeslots.
modify_value - Modifies the number of extended range timeslots for an RTF.
chg_hop_params - If a cell contains extended range timeslots, several dependencies must be

checked for the hopping system being enabled.
disp_cell_status - Displays the status of extended range timeslots.
disp_rtf_channel - Indicates extended range timeslots.
5-84 68P02901W36-S
Jul 2008
modify_neighbour - Allows modification of the neighbor range per neighbor.
disp_neighbour - Displays information about the neighbor range per neighbor.
add_neighbour - Prompts for the neighbor range per neighbor.
stat_mode, chg_stat_prop, disp_stat_prop, disp_stats - These commands support:

Statistics for number of attempted intra-cell handovers between normal range and
extended range channels in an ERC.
Statistics for number of successful intra-cell handovers between normal range and
extended range channels in an ERC.
Statistics for traffic channel usage for the channels in the extended range zone of an ERC.
Parameters
ext_range_cell - Added to the list of elements supported by the chg_cell_element and

disp_element commands.
ms_max_range - Maximum value increased to 219 if ERC is enabled for a cell.
System impact
If the ERC feature and the concentric cell feature are implemented, an extended range carrier
cannot be an inner carrier in a concentric cell.
Successful ERC implementation is achieved by RF planning and system design.
Factors for success are:

Maximizing transmit power.
In single carrier cells-Avoid the combination losses of multiple carrier cells.
In multiple carrier cells-Air combining to minimize combination losses.
At base station antennas-high gain directional antennas.
Low loss feeder cables.
Maximizing receiver sensitivities.
MS sensitivity is fixed.
Use of low noise mast head amplifiers.
Only TCU and SCU carriers are supported by the extended range cell function.
A maximum of 20 SDCCH channels must all reside on the BCCH carrier.
Dynamic reconfiguration of channels between TCH and SDCCH is disabled in an extended cell.
EGPRS PDs are not configured on DD CTU2 Carrier A when the corresponding timeslots on B is
extended range timeslots.
68P02901W36-S 5-85
Jul 2008
Short message service (cell broadcast) Chapter 5: Cells
Short message service (cell broadcast)

Short message service function
This function allows text messages to be sent from MS to MS and PLMN to MS.
The service can be divided into two separate functions:

Short Message Service Cell Broadcast (SMSCB).
Point-to-point short message service.
The GSM-defined cell broadcast feature is a means of unilaterally transmitting data to MSs on a
per-cell basis, by use of the Cell Broadcast Channel (CBCH).
The SMSCB function has been upgraded to integrate the changes made to the 3GPP GSM
standards and recommendations since the initial development of the SMSCB features and
provides support for large SMSCB messages.
The main system changes are:

Multiple page message support.
Different message categories.
CBC configurable DRX period.
CBC-BSC interface upgrade.
Support of extended SMS alphabets.
Backward compatibility.
Short message service cell broadcast
A BSC can be connected to a Cell Broadcast Center (CBC), from which cell broadcast messages
are downloaded to the BSC, together with the repetition rate and the number of broadcasts
required per message. The BSC then transmits these updates to the specified BTSs for
transmission to MSs as requested.
The short message service cell broadcast function is a purchasable option, which is unrestricted
(enabled) on a cell basis using the cbch_enabled database parameter with the chg_element
command.
5-86 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Short message service cell broadcast
If purchased and unrestricted, frequency, slot and subslot information present within BCCH
system information cause suitably equipped MSs to monitor the Cell Broadcast Channel (CBCH).
This channel fits into the 102 multiframe in place of SDCCH subslot 2 on an SDCCH/8 and on
the SDCCH subslot number pointed to by bs_ag_blks_res for an SDCCH/4. It can appear on
BCCH or non-BCCH carriers on timeslots 0-3 inclusive. Only one CBCH exists within a cell and
an algorithm specified in 3GPP Specification GSM 05.02 controls its position. A cell broadcast
block is made up of 23 bytes (184 bits) which is encoded to produce the familiar 456 bit block;
this is then transmitted over four successive air interface bursts. In a period of 8 multiframes,
the CBCH is only transmitted on 4 of them. In the case where the CBCH resides on a BCCH
carrier, dummy bursts are transmitted in the other 4 multiframes.
The SMSCB DRX GSM requirement is supported to minimize the battery usage requirements
for an MS. Every one minute, the cell broadcasts a scheduler message on the CBCH. The MS
uses this information to restrict the reception of messages based on customer choice. Channel
number selection, which is a feature on certain MSs, allows the MS user to choose the type
of information to be received. SMSCB scheduler messages are detailed in 3GPP Specification
GSM 04.12.
In the absence of messages originating from the CBC, cell broadcast background messages
up to a maximum of 93 characters can be sent on the SMSCB channel. A maximum of four
background messages can be specified using the chg_smscb_msg database command.
Multiple page message support
The initial implementation limited the number of pages in a WRITE/REPLACE to 1 and the
maximum number of cells in a cell list to 30 cells. If the CBC sends more than 1 page or more
than 30 cells in the cell list, the encoded ASN.1 messages received from the CBC are greater than
the 576 bytes internal exec limit. The RSS Abis interface accepts a message length parameter
from CBS, which is then used to set the last block bit in each SMS block message header.
Different message categories
The 3GPP specifications have been modified to introduce message categories, these categories
are defined as high priority, background or normal. Currently each message has only a
repetition rate to define how often the message is broadcast. The introduction of different
priority messages affects scheduling of both the message itself and the DRX scheduling
messages. New messages are supported from the CBC which reserves certain slots for potential
High Priority messages.
CBC configurable DRX period
The 3GPP specifications have been modified to introduce a configurable DRX message that can
be turned on/off through messages from the CBC. In addition, the period of the DRX message
can be set by the CBC.
CBC-BSC interface upgrade
Short message service cell broadcast provides a configurable DRX period, message categories,
interface version control (vbinds instead of binds), a change in the number of required
broadcasts (from 0-2880, to 0-65535), channel indicator (basic channel), CBCH loading query
and clearing up of the retix tagging issue in REPORTS sent from the BSC to CBC. Also, the
definition of the repetition-rate parameter has changed in the 3GPP specifications.
68P02901W36-S 5-87
Jul 2008
Point to point SMS Chapter 5: Cells
Two functional objects are impacted:

CBA: translates PHASE2 to PHASE2+ for CBS and different range checking.
CBS: PHASE2+ transition of PHASE2 repetition rates.
Support of extended SMS alphabets
3GPP 03.38 provides definitions of the extended alphabets which can be used for SMS cell
broadcast messages. Extended SMS alphabets are supported for messages defined by the cell
broadcast center. To identify the language identity to the mobile, the existing data coding
scheme parameter in the WRITE-REPLACE Request is used. This functionality is not changed
and there is no impact on the BSS. The extended SMS alphabet is not supported for SMS cell
broadcast messages which are defined through the OMC/customer MMI.
Point to point SMS
Point to point SMS provides a means of sending messages of limited size (255 message bytes) to
and from GSM MSs. The ability to provide SMS requires a service center which acts as a store
and forward switch for short messages. To allow for SMS transfer, the MS and BSS must set up
the appropriate air interface protocol (LAPD). The logical channel used for this data transfer
will depend on the following status of the MS:
MS idle-SDCCH.
MS on SDCCH-SDCCH.
MS busy-SACCH or FACCH.
Traffic channel SMS
While engaged on a traffic channel, the MS can still receive SMS through the FACCH or the
SACCH:
If the FACCH is chosen as the means of delivery, an SMS block (23 octets of information) is
transmitted in 8 successive TDMA frames.
If the SACCH is used, an SMS block requires 104 frames for delivery, due to the timing
constraints of the SACCH.
Backward 3GPP compatibility
Because CBC vendors can be working to different versions of the 3GPP specifications GSM
03.41 and GSM 03.49, the BSC operator can select the version of the specification to use. The
database parameter cbc_intface_vers selects either the 410 version or the 411 version of the
PHASE interface. To use the PHASE2+ version, the CBC sends a VBIND message instead
of a BIND message.
5-88 68P02901W36-S
Jul 2008
The following parameters can be used with the chg_element or chg_cell_element commands
to specify the SMSCB option:
bs_ag_blks_res - Sets the number of blocks reserved for access grant per 51 multiframes.
cbch_enabled - Enables the Cell Broadcast Channel (CBCH) option in a cell.
sms_dl_allowed - Sets a flag to enable or disable downlink (MS terminated) point-to-point

short message service.
sms_ul_allowed - Sets a flag to enable or disable uplink (MS originated) point-to-point

short message service.
sms_tch_chan - Determines the logical radio channel used for the short message service,
when in dedicated mode.
cbc_intface_vers - Selects the interface for each BSC site. The available interfaces are
either the standard interface or the interface with the repetition rate interpretation and
CBCH loading fields.
disp_element - Displays the SMSCB elements in the Configuration Management (CM)

database.
chg_smscb_msg - Changes a selected CBCH background message and the language in

which it is presented. The parameters entered at this command are as follows:
msg_num - A number allocated to uniquely identify background messages.
msg_id - Every background message must have a standard identifier. This represents the
source and type of message. On Motorolan MSs it corresponds to the Cell Broadcast (CB)
channel number but this can vary depending on the MS itself.
gs - The geographical scope of the message, that is, the area over which the message is
dispersed uniquely. In the Display Mode Normal options, the MS user is provided with
an indication that the message has been received and must select the message to be
displayed. These options are:
PLMN wide: broadcast the message to all MSs within the PLMN, for example football
scores.
Location area wide: broadcast the message to all MSs within the location area, for
example traffic reports.
Cell wide: broadcast the message to all MSs within the same cell, for example, local
telephone numbers.
In the Immediate display mode option, the message is displayed to the MS user
without any user interaction.
Cell wide (immediate): broadcast the message to all MSs within the same cell, for
example, changed local telephone numbers.
68P02901W36-S 5-89
Jul 2008
System impact Chapter 5: Cells
msg_code - Every background message must have this code in the message number. It is a
10 bit field within the message number (msg_num) and is used to distinguish between
messages with the same message identifier (msg_id).
update_number - Gives the operator the ability to decide which update to send to a
particular cell. For example, it could be required to use the same update of a particular
message to a new cell that is being used in existing cells.
This value differentiates between older and newer versions of the same message, within
the specified geographical scope. A new message can take any update value (not
necessarily 0000) and is incremented by one for each update to a message. This increment
occurs up to 16 times before reverting to the initial update number, that is, if the original
update number is 0000, this value is reverted to after 16 increments. After 17 increments,
the value will be 0001 and so on.
The MS treats the message as new if its update number is within 1 to 8 forward increments
of the last received update number. For example, if the last received update number was
2, the next received message with an update number of 3 to 10 is treated as new. Next
received messages with update number 11 to 15 or 0 to 2 are ignored. If the last received
update number was 9, the next received message with an update number of 10 to 15 or 0
to 1 is treated as new. Next received messages with update number 2 to 9 are ignored.
NOTE
If an MS is switched off and on again, the update number sequence is broken
and update assessment for existing messages can no longer be carried out.
data_coding_scheme - The language in which the CBCH background message is

presented.
System impact
Short Message Service cell broadcast requires the permanent use of an SDCCH.
When using traffic channel SMS, this method has the disadvantage that traffic frames are
stolen, with injurious effect on the audio quality. This frame stealing becomes more noticeable
as the size of the short message increases.
Extending the alphabet should not have an impact on system performance.
References
3GPP specifications GSM 03.41 and GSM 03.49 define the Cell Broadcast short message service.
3GPP Specification 03.38 provides definitions of the extended alphabets which can be used
for SMS cell broadcast messages.
5-90 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Cell selection/reselection
Cell selection/reselection

Cell selection and reselection function
While an MS is idle, it continuously monitors cells in its coverage area for the one with the most
suitable BCCH, for selection and reselection purposes, when required. To do this, the MS
must be switched on and fitted with a SIM card. While in this idle state, it receives a list of
neighbor cell frequencies as broadcast on the BCCH of this serving cell. The MS tunes to each
of these frequencies in turn, gains synchronization and checks the following information for
possible cell reselection:
Correct PLMN.
Cell barring.
Location area.
C1 parameters (P1 and P2).
Assuming the first two of these criteria are met, the major factor used by the MS for cell
reselection is the perceived transmission quality between the MS and the potential cell known
as C1.
C1 (perceived transmission quality)
The major factor used by the MS for cell selection and reselection is C1, which is defined as
the perceived transmission quality between the MS and the potential cell. The calculation of
C1 takes into account the RXLEV of the BCCH, the maximum output power of MS and other
cell specific parameters, as follows:
C1= (A-Max. (B, 0))
Where:
A=RXLEV Average-P1
B=P2-Max O/P Power of MS
P1 and P2 are cell specific parameters:
P1=rxlev_access_min, which determines the min RXLEV required for the MS to access the
system.
P2=ms_txpwr_max_cch, which determines the maximum output power at which the MS can
access the system.
The MS will only select cells of positive C1 and when a choice between cells of the same location
area must be made, the cell of best C1 is chosen.
In the formula, A determines the downlink path and B the uplink path. To reach a positive C1
value, A must be positive. This indicates that the received downlink power is greater than
the minimum required for that cell.
68P02901W36-S 5-91
Jul 2008
Related commands/fields Chapter 5: Cells
A negative value for B indicates that the MS is more than capable of meeting the required access
power and a value of 0 is substituted. A positive value for B indicates a poorer uplink path.
To summarize:
A= + value -> Good downlink path
-value-> Poor downlink path
B= -value -> Good uplink path
+ value-> Poor uplink path
BCCH reselection
When considering BCCH reselection from one cell to another with the same location area, the
value of C1 for a potential cell must be greater than that for the source cell. When the potential
cell is in another location area, the value of C1 must be greater than that of the source cell by a
database-set parameter, the cell_reselect_hysteresis field.
C2 (modified perceived transmission quality)
C2 is an optional GSM feature which can only be used for cell reselection. It can be enabled
or disabled on a per cell basis, by setting the cell_reselect_param_ind parameter. If C2
parameters are not being broadcast in the BCCH, the C1 process is used for reselection. The
formula below shows the relationship between C2 and the original C1 calculation:
C2= C1 + cell_reselection_offset-temporary_offset x H
(for penalty time <31)
C2= C1-cell_reselection_offset
(for penalty time= 31)
Where:
T=length of time the MS has maintained the neighbor in its top six measured cells.
H is determined by penalty time and T
H=0 if penalty time-T < 0
H=1 if penalty time-T > 0
Whilst idle, the MS maintains a list of the strongest six neighbors being monitored from the idle
BA list. The list is constantly updated and reselection parameters regularly checked, though the
timing varies from MS to MS. At least every five seconds the MS calculates C2 for the server
and C2 for neighbors. If the C2 for the best neighbor exceeds that of the server for a period of
five seconds then reselection takes place. If the neighbor is in a different location area then
cell_reselection_hysteresis is also considered for the same period.
Related commands/fields
5-92 68P02901W36-S
Jul 2008
The following parameters are available for use with the chg_element (cell must be specified) or
chg_cell_element commands to modify cell selection or reselection:
cell_reselect_hysteresis - Sets hysteresis level for cell reselection into a different location
area.
rxlev_access_min - Sets the minimum received signal level (dBm) required for an MS to
access the system.
cell_reselect_offset - The MS uses this value to increase the value of C2. This parameter
can be overridden by a different negative offset specified by temporary_offset for a
specified time, specified by penalty_time.
ms_txpwr_max_cch - Defines the maximum power an MS transmits on a control channel

in the cell.
temporary_offset - Used to apply a negative offset to C2 for the duration of the

penalty_time parameter.
penalty_time - Defines the length of time for which the temporary_offset field is active.

in idle mode.
System impact
C2 works only for phase 2 MSs or later.
The elements can not be changed if the cell_reselect_param_ind parameter is not equal to 1
(broadcast and use C2 database elements, as set by cell_bar_quality, cell_reselect_offset,
temporary_offset and penalty_time parameters).
68P02901W36-S 5-93
Jul 2008
Network Assisted Cell Change (NACC) Chapter 5: Cells
Network Assisted Cell Change (NACC)

Introduction
The Network Assisted Cell Change feature improves GPRS performance by reducing delays in
the cell reselection process.
It overcomes the potential problem of an MS selecting a congested target cell, or that the cell
can have GPRS/EGPRS disabled.
Network Assisted Cell Change consists of two independent procedures. The first procedure
allows the MS to indicate to the network the need for a cell change. In the second procedure the
network provides neighbor cell data to the MS.
PCCN procedure
The MS notifies the network using a Packet Cell Change Notification (PCCN) message when
a cell reselection is needed and delays the cell reselection to let the network respond with
neighbor cell system information. This procedure allows the BSS to play a part in deciding the
best target cell to shift an MS. The BSS considers the following to make a decision:
If the neighbor cell is internal or external to the BSS.
RxLev measurements of the serving and the neighbor cell as reported by the MS.
QoS capabilities of the serving and neighbor cells and the QoS profile of the MS.
EGPRS/GPRS availability on the target cells.
Whether the target cells are in the same routing area.
Whether the target cells are on the same PRP board.
Whether the proposed target cell/neighbor cell is a macro or a micro cell.
If the neighbor cell is within the same PCU.
Neighbor cell data
After the target cell has been determined the network sends the MS a Packet neighbor Cell
Data (PNCD) message containing the information needed for the MS to access the target cell.
The neighbor cell information is sent to the MS in the source cell before the MS performs
cell reselection so that the MS could perform packet access without reading all of the system
information in the target cell. This procedure could also be an extension of procedure 1 if the
network has information about the target cell.
5-94 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Network Assisted Cell Change procedures
Network Assisted Cell Change procedures
The network indicates that a cell is capable of the Cell Change Notification (CCN) procedures
by broadcasting CCN_ACTIVE in system information (and PSI messages where provisioned)
messages or dedicated signaling messages (PMO and PCCO).
A NACC-capable MS enters CCN mode when GPRS attached on a cell and the following
conditions are satisfied:
The network indicates CCN_ACTIVE (indicating that the cell supports Network assisted
cell change/CCN procedures).
The MS is in NC0 or in NC1 mode.
The MS is in Packet Transfer mode.
If the MS is in CCN mode, it behaves as in network control mode NC0 or NC1 up to the point
when it needs to perform a cell change. Then, instead of performing the cell change, the
MS informs the network about the proposed cell change by sending a Packet Cell Change
Notification (PCCN) message. The PCCN message contains the ARFCN for the BCCH and the
BSIC as identity of the proposed cell. The message also contains measurement reports for the
proposed cell and for other neighbor cells, if available.
After receiving a Packet Cell Change Notification message from the MS the network can behave
in the following ways:
The network determines that the cell chosen by the MS is the optimal cell for the cell
reselection.
The network sends first necessary system information for the cell proposed in the Packet
Cell Change Notification message in one or more instances of the Packet Neighbor Cell
Data message and sends then a Packet Cell Change Continue message, as shown in
Figure 5-18.
68P02901W36-S 5-95
Jul 2008
Network Assisted Cell Change procedures Chapter 5: Cells
Figure 5-18 Network agrees with the MS target cell selection
The network determines that the cell chosen by the MS is the optimal cell for the cell
reselection. However, there is no target cell data available.
The network responds with a Packet Cell Change Continue message without sending the
PNCD message: The MS leaves CCN mode and continues cell reselection in NC0/NC1
mode. This is applicable to external cell reselections and where one PCU is not aware of
the contents of the system information messages if the target cell is on another PCU. This
is shown in Figure 5-19.
5-96 68P02901W36-S
Jul 2008
Figure 5-19 Network has no target cell information before sending PCCC
The network determines that the cell chosen by the MS is not the optimal cell for the cell
reselection and the network finds another cell in the measurement information that is
more suitable.
The network then sends the first necessary system information for the BSS chosen target
cell in one or more instances of the Packet Neighbor Cell Data message and then sends a
Packet Cell Change Order message. The MS leaves CCN mode and follows the procedures
as specified for the Packet Cell Change Order. This is shown in Figure 5-20.
68P02901W36-S 5-97
Jul 2008
Network Assisted Cell Change procedures Chapter 5: Cells
Figure 5-20 Network evaluates a new target cell for the MS
The network determines that the cell chosen by the MS is not the optimal cell for the cell
reselection and the network finds another cell in the measurement information that is
more suitable.
However there is no target cell data available. The network responds with a Packet Cell
Change Order message without sending the PNCD message. This is applicable to external
cell reselections and where one PCU is not aware of the contents of the system information
messages if the target cell is on another PCU. This is shown in Figure 5-21.
5-98 68P02901W36-S
Jul 2008
Figure 5-21 Network has no target cell information before sending PCCO
The network determines that no cell change is required.
The network orders the MS into NC2 mode if it evaluates that a cell reselection is not
required for the MS under the current radio conditions. The network sends a Packet
Measurement Order message to the MS indicating NC2 mode. When the MS receives the
NC2 order it leaves CCN mode and goes into NC2 mode. When the NC2 mode has been
ordered, if the network has target cell information then the network can send Packet
Neighbor Cell Data messages on the PACCH before sending the Packet Cell Change Order
to the MS. This is shown in Figure 5-22.
68P02901W36-S 5-99
Jul 2008
Type-5 microcellular algorithm for GPRS Chapter 5: Cells
Figure 5-22 Network evaluates that cell reselection is not required for the MS
In the event that the network does not respond to the PCCN or that the MS does not receive the
response from the network, the MS retransmits the Packet Cell Change Notification message
once at the first possible opportunity. If the network still does not respond, the MS leaves CCN
mode and continues cell reselection in NC0/NC1 mode.
The CCN mode is only valid in Packet Transfer Mode. If the MS is in CCN mode when entering
packet idle mode, the MS leaves CCN mode and continues the cell reselection procedure
according to the NC0/NC1 procedures. If Packet Neighbor Cell Data messages are received
on the PACCH before entering packet idle mode, this information can then be used by the
MS at the next cell change.
Type-5 microcellular algorithm for GPRS
This algorithm moves the stationary users in the network that can see a MICRO cell to the micro
cells to free up more bandwidth on the MACRO layer. The algorithm adapts the current type
5 circuit switched algorithm to the packet switched implementation. It attempts to keep the
MS with small quantities of data (example WAP) in the MACRO layer of the network while
performing cell reselection for stationary MSs performing long transfers in the MICRO layer to
provide them with more resources to complete the data transfer. Fast moving MSs are kept on
the MACRO layer and prevented from entering the MICRO layer as the overhead associated
with multiple cell reselections could reduce throughput.
5-100 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation LLC boundary detection algorithm
Additionally, the algorithm for cell reselection from the macros to micros or small macros is
speed sensitive to avoid repeated cell reselections for fast moving mobiles. As part of the GPRS
Type-5 microcellular algorithm, cell reselection is only triggered if the target neighbor micro
cell has continuously qualified for a predefined period. This qualification is indicated by the MS
reporting PMRs with neighbor measurements that indicate that a micro neighbor is reported
stronger than the serving cell. This shows that the MS is slow moving and that it can be cell
reselected to the micro cell neighbor. This algorithm is also designed to perform reselection
only for mobiles with longer TBFs to avoid the extra signaling and service outage for mobiles
that will not obtain full benefit from the micro cell layer.
NOTE
The algorithm applies to cell reselection from macro to micro and micro-to-micro
layer. It can also be used for cell reselection to small macro cells or other types of
cells that are infrequently used by GPRS, for example, DCS 1800 cells.
LLC boundary detection algorithm
Previously, when the MS performs an autonomous cell reselection, the BSS could not determine
the exact time that the MS has left the serving cell. As a result, the packets in the current
downlink LLC frame had to be retransmitted in the target cell from the beginning of the frame
even if there was very little data left in the source cell.
To overcome this, NACC determines if the current downlink LLC frame could be transmitted to
the MS in the source cell within 0.96 seconds. If this evaluation indicates that it can be done
then the TBF is terminated at the LLC boundary before sending the PCCO/PCCC. Otherwise, the
TBF is terminated immediately and the PCCC/PCCO is sent to the MS. In NC2 mode however,
there is no timing constraint as the network initiates the cell reselection procedures without
receiving the PCCN from the MS.
The maximum delay of the MS initiated cell reselection after the MS has sent the Packet Cell
Change Notification message in CCN mode is controlled by the T3208 timer. The T3208 timer is
used by the MS in CCN mode to decide when to stop waiting for network assistance for the cell
reselection (Value: 0.96 sec). Once the MS starts this 0.96 second timer (after sending PCCN to
the network), the PCU terminates the ongoing TBF in about 0.55 seconds so as to still send
the PCCC/PCCO and the PNCD message to the MS in time.
This algorithm would have the following functions:

Predicts whether or not the current downlink LLC frame can be sent before the cell change.
Immediately ends TBF and commands the cell change if not possible to reach LLC boundary.
Delays cell change until LLC boundary when possible.
This algorithm reduces the retransmission of the LLC frames during cell reselection.
68P02901W36-S 5-101
Jul 2008
Idle mode cell reselection enhancement algorithm Chapter 5: Cells
Idle mode cell reselection enhancement algorithm
This algorithm dynamically modifies the logical size (the size perceived by the MS without
changing the transmit power of the cell) of the cell for MSs proportional to the congestion level
of the cell. Changing the logical size of the cell is achieved by increasing the cell reselection
offsets for the neighbors of the source cell to make the neighbors relatively more attractive to
the MS. The aim of this algorithm is to evenly distribute the MS in idle mode in the network
and to minimize the number of active mode cell reselections due to congestion. Active mode
reselections are not desirable, since they cause service outages and subsequently reductions in
throughput. The algorithm is implemented by modifying the idle mode cell reselection offset
parameters, so that the number of MSs encouraged to perform cell reselection is proportional to
cell load.
This algorithm requires the PBCCH to be enabled in the cell because the PBCCH enables the
sending of per-neighbor reselection offsets. This algorithm will not be used in BCCH only cells
because the overhead in sending a PMO to each and every MS to define their cell reselection
offsets would take away valuable user throughput in the downlink direction and cannot be
justified. If gprs_cell_reselect_hysteresis is set to 0 db, the gprs_reselect_offset does not
change on neighbor cells.
Active mode congestion relief algorithm
Whenever cell congestion or PRP congestion is indicated by QoS, the NACC functionality
chooses the most suitable candidates for cell reselection and moves them to other cells.
Congestion relief is triggered on a cell and board basis, when utilization rises above a
pre-determined threshold. When congestion relief is indicated by QoS, NACC runs an algorithm
to pick the worst performing MSs based on RF conditions and coding schemes.
PRP congestion relief allows MSs to be reselected to cells on the same PCU but not on the
congested PRP. With the NACC feature, when cell congestion relief is indicated, the MSs can
be reselected to any other cell on the same PCU. The target cell selection algorithm picks
the best cell for the qualified MS.
NOTE
The cell reselection procedure is applied to only one qualified MS at a time.
5-102 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Network controlled cell reselection (packet data)
Network controlled cell reselection (packet data)

Network Controlled (NC1 and NC2) cell reselection
In a GPRS network, cell reselection is equivalent of a GSM circuit switched handover triggered
by, for example:
Change in location of the mobile.
Change in RF conditions.
Cell congestion.
GPRS cell reselection offers mobility and performs network traffic management. The different
modes of cell reselection in GPRS network are referred as NC0, NC1, NC2 and RESET. In the
initial Motorola GPRS product offering, NC0 was provided. In cell reselection mode NC0, the
mobile performs autonomous cell reselection based upon on the radio environment. Network
Controlled cell reselection is triggered either due to bad RF conditions or due to initiation of
congestion relief. When the serving cell rxlev falls below any neighbor rxlev by a threshold, NC2
cell reselection is initiated. For Congestion relief the network determines when the serving cell
is exceeding congestion threshold & initiates NC2 cell reselection. Table 5-8 shows the different
cell reselection modes, responsible network element and functionality.
Table 5-8 NC cell reselection modes
Cell reselection
Control element Functionality
mode
NC0 MS control Normal GPRS MS control: Autonomous cell reselection.
Enhanced NC0 MS control Functionality in NC0 mode plus: BSS sends cell
reselection commands to GPRS MS to change cell
reselection mode.
NC1 MS control Normal GPRS MS control: Autonomous cell reselection,
MS sends measurement reports to BSS.
Enhanced NC1 MS control Functionality in NC1 mode plus:BSS sends cell
reselection commands to GPRS MS to change cell
reselection mode.
NC2 Network control MS sends measurement report to BSS, BSS sends cell
reselection commands to GPRS MS, BSS instructs MS to
perform cell reselection. During cell reselection in the
NC2 mode, the target cell on the same Packet Resource
Processor (PRP) board as the source cell is going to
be given preference over the target cell on a different
PRP board.
Prior to implementation of network controlled cell reselection (GPRS), the MS autonomously

performed cell reselection based solely on the RF measurements of the serving and neighboring
cells. The GPRS MS is unable to reselect to a neighbor cell based on important factors: such as
congestion, availability of GPRS, ability to support mobiles and current grade of service.
68P02901W36-S 5-103
Jul 2008
Network controlled cell reselection enhancements Chapter 5: Cells
The main objective of the network controlled cell reselection and congestion relief feature is to
increase network capacity and to provide the network operator with a tool for network planning
and improved quality of service. The operator is able to specify GPRS cell reselection mode
on a per cell basis, within the network of cells with the same cell reselection command, thus
providing the flexibility of virtual zones. A significant portion of this feature incorporates the
addition or modification of statistics that reflect radio conditions at the MS and congestion in
the GPRS network. Benefits of statistics collection are as follows:
Provide network information to change cell reselection mode on a per MS basis.
Provide information to monitor network radio and congestion information to determine

and perform cell selection.
Provide network planning information and configuration of NC2 mode parameter. In cell
reselection mode, NC2 enables the BSS to take appropriate action to reduce congestion
if the originating cell is congested (in enhanced modes ENC0, ENC1 the serving cell
Coding Scheme (CS) value, uplink rxlev reported by MS are used to determine if the MS
needs to be put in NC2 mode).
The BSS sends a customized BA (GPRS) list to each mobile on the PACCH or the CCCH. The BA
GPRS list provides optimized cell monitoring and measurement reporting, enabling the MS to
provide measurement reports of those neighbor cells that are configured for GPRS service.
Network controlled cell reselection enhancements
If the Network Controlled Cell Reselection (NCCR) is a restricted feature, the operator is not
allowed to configure the per cell elements, gprs_num_pmrs and gprs_cr_margin.
Cell reselection restricted
During cell reselection in the NC2 mode, the target cell on the same Packet Resource Processor
(PRP) board as the source cell is going to be given preference over the target cell on a different
PRP board.
Target cell
If the difference between the rxlev of the neighbor cell, received as part of PMR from the MS
and rxlev_access_min of the neighbor cell is greater than zero then the PCU will consider
that neighbor cell a target for cell reselection.
The target cell is selected based on the following criteria:

Serving cell rxlev.
Neighbor rxlev.
Congestion in target cell.
In NC2 mechanism, if cell is considered as congested the PCU will trigger Change Cell order if:
Serving cell criteria (Rxlev-rxlev_access_min gprs_cr_margin) < Neighbor cell criteria

(Rxlev-rxlev_access_min gprs_cr_margin)
5-104 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BA (GPRS) list
NOTE
If PBCCH is enabled, rxlev_access_min will be replaced by gprs_rxlev_access_min.
Coding scheme variations
In enhanced cell reselection modes, the PCU will consider the coding scheme variations while
performing network controlled cell reselection. The change in coding scheme reflects the
change in the mobile operational environment such as block error rates and missing downlink
acknowledgments. These coding scheme changes are taken into consideration to detect the
condition of the mobile in the cell and to perform a cell reselection.
BA (GPRS) list
The BA (GPRS) list is sent in the packet measurement order message on the PACCH or the CCCH.
It is the list of BCCH frequencies in use by a given PLMN for GPRS services. The BA (GPRS) list
is used by the MS for cell monitoring and measurement reporting, as shown in Figure 5-23.
Figure 5-23 BA (GPRS) list monitoring before optimization
The operator is restricted to 32 frequencies in the BA (GPRS) list. This limit is consistent with
the number of different frequencies the MS can report in measurement report messages, based
on the format of these messages.
In cell reselection procedure NC2, the network is able to instruct the mobile to send
measurement reports for neighbor cells, suspend the normal (mobile initiated) cell. reselection
and accept a network controlled cell reselection, as shown in Figure 5-24.
68P02901W36-S 5-105
Jul 2008
Related database commands and parameters Chapter 5: Cells
Figure 5-24 BA (GPRS) list monitoring after NC2 optimization
The BSS calculates the network controlled cell reselection criteria that should be used, based
on the GPRS MS measurement reports and congestion information. When the cell reselection
criterion is met, the PCU prioritizes the six strongest neighbor cells based on the cell congestion
and then instructs the MSs to perform cell reselection.
Related database commands and parameters
The following parameters can be used with the chg_element, disp_element and
chg_cell_element commands to specify the network controlled (NC1 and NC2) cell reselection
feature:
Table 5-9 Related database commands and parameters
Parameters Description
nccr_enabled Specifies whether the network controlled cell reselection
option is restricted or unrestricted.
nc_reporting_period_i Specifies the time interval between successive measurement
reports from a GPRS MS to the BSS when the MS is idle.
nc_non_drx_period Specifies the time interval in which the BSS expects the MS
to read the paging channel (CCCH).
nc_reporting_period_t Specifies the time interval between successive measurement
reports from a GPRS MS to the BSS when the MS is
transferring packet data.
network_control_order Specifies the network controlled cell reselection mode (see
Table 5-8).
The following neighbor cell commands are also used by the network controlled (NC1 and
NC2) cell reselection feature: add_neighbour, modify_neighbour, disp_neighbour,
del_neighbour.
5-106 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Related database commands and parameters
The following statistics commands are also used by the network controlled (NC1 and
NC2) cell reselection feature: disp_stats, stat_mode, disp_enable_stat, chg_stat_prop,
disp_stat_prop.
68P02901W36-S 5-107
Jul 2008
Related database commands and parameters Chapter 5: Cells
5-108 68P02901W36-S
Jul 2008
Chapter
Call Processing

This chapter provides a description of the GSM call processing functions and explains how
they are implemented in the system.

Call processing function on page 6-3.
Call setup on page 6-8.
GSM encryption (ciphering) on page 6-16.
Call clearing on page 6-22.
GPRS data transfer processing on page 6-26.
Delayed release of downlink TBF on page 6-37.
Enhanced two uplink timeslots on page 6-40.
Enhanced scheduling on page 6-43.
{23292} Extended Dynamic Allocation Medium Access (EDMAC) Mode on page 6-49.
GPRS timeslot allocation on page 6-51.
EGPRS terrestrial resources on page 6-65.
Air interface packet data transfer on page 6-68.
Call quality monitoring on page 6-85.
Adaptive Multi-Rate (AMR) Optimization Link and Intelligent Optimization System on

page 6-88.
Timing advance on page 6-89.
BTS Concentration Call Priority Handling (BCCPH) on page 6-92.
Call processing: location services on page 6-93.
EGPRS incremental redundancy on page 6-105.
Adaptive Multi-Rate (AMR) Abis-interface on page 6-106.
Emergency call preemption on page 6-107.
AMR channel allocation on page 6-110.
EGPRS system information messages on page 6-122.
68P02901W36-S 6-1
Jul 2008
Related database commands and parameters Chapter 6: Call Processing
GPRS R4 compliance on page 6-123.
Enhanced Multi-Level Precedence and Preemption service (eMLPP) on page 6-125.
Call setup time improvement in a GSM network on page 6-132.
6-2 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Call processing function
Call processing function

BSS Call Processing (CP) is a collection of Layer 3 system application processes that controls
Mobile Subscriber (MS) calls at high level.
The CP software process is responsible for the call setup and clearing of all the MS calls and for
maintaining the channel to the MS, as well as the Mobile Switching Center (MSC) originated
MS pages. The BSS software undertakes all encryption tasks for the system, only over-the-air
interface, all the messages on the system terrestrial links are in plain language.
Once an MS is established on a channel, be it a traffic channel or a control channel, all signaling

between the MS and the MSC are transparent to the BSS software. All that the BSS software
undertakes is, it maintains the channel to the MS, while passing on any signaling to the MS.
The CP executes handover decisions also, which selects the target cell in response to the
choices provided by the RSS.The BSS software controls all intra-cell and intra-BSS handovers,
with the MS remaining on the same terrestrial trunk connection to the MSC, whilst in an
inter-BSS handover the BSS software informs the MSC of the choices of target cells and the
MSC controls the transfer to the new cell.
The call processing software processes include:

MTPL3/SCCP preprocessor (MTPL3).
Connectionless manager (CLM).
SCCP state machine (SSM).
Switch manager (SM).
Cell resource manager (CRM).
Allocation Manager (AM).
Radio resource state machine (RRSM).
Radio channel interface (RCI).
MTP L3/SCCP preprocessor
This process handles the protocol adaption of the messages when transmitting or receiving
messages on the A interface. It also determines which process each message is destined for by
interrogating the message header, it then addresses the message accordingly.
Connectionless manager
The Connectionless Manager (CLM) deals with the global control of a BSS. This process deals
with the non-connection oriented portion of the C7 signaling.
68P02901W36-S 6-3
Jul 2008
SCCP state machine Chapter 6: Call Processing
SCCP state machine
The SCCP State Machine (SSM) is responsible for handling all the connection oriented portion
of the C7 signaling.
The SSM is responsible for coordinating all intra-BSS and intra-cell handovers. It makes sure
that the target cell is informed of the handover request and ensures that a radio channel is
allocated to the MS. This process generates all the required messaging/signaling to coordinate a
handover, it informs the MSC when this procedure has been completed. The SSM informs the
source cell of a successful handover in order that radio resources can be unallocated.
Switch manager
The function of the Switch Manager (SM) is to connect an MS terrestrial trunk from the MSC
(designated by the MSC), to the radio channel given to an MS by the cell resource manager
in the BSS software.
Cell resource manager
The Cell Resource Manager (CRM) is responsible for the allocation of the radio channels in
response to either an MS accessing the system or the MSC paging an MS. The CRM keeps
a dynamic database concerning the state of each of its channels and uses the interference
information provided by the RSS to allocate the best available resource.
When the traffic loading on a BTS site or a cell becomes too heavy, the CRM can instigate the
flow control. The CRM tells the Abis Interface in the RSS software to block any further random
access requests from MS on that cell or site. When traffic load reduces, the flow control is
removed.
Allocation manager
The Allocation Manager (AM) software process exists at the BSC and at the BTS. The CRM
requests terrestrial backing for a TCH from the AM at the BTS site. The CRM releases the
resource by informing the AM when the TCH is freed. The BTS AM requests the resource of
the BSC AM. The BTS AM frees the resource by informing the BSC AM. The AM originates
requests to the SM to provide the connections for allocating and freeing a resource at both the
BSC and the BTS. The AM has a protocol designed to handle problems with communication
over the RSLs between the BSC and the BTS.
If the BTS AM does not receive a reply for a terrestrial backing resource allocation from the BSC
AM within the retry time indicated by the operator, the BTS AM resends its request. The BTS
AM repeats this procedure thrice. At this point, the BTS AM indicates a failure to obtain the
resource to the CRM. The BTS AM starts requesting the BSC AM to free the allocation for the
RCI. The BTS AM repeats this request until the request is acknowledged, or the CRM requests a
terrestrial backing resource for the same TCH.
6-4 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Radio resource state machine
Radio resource state machine
The Radio Resource State Machine (RRSM) is the call processing software process responsible
for the initiation and maintenance of physical connections.
This process is responsible for the activation of the radio channels sourced from the CRM. When
an MS no longer requires a radio channel, the RRSM is responsible for closing the channel down.
Radio channel interface
The Radio Channel Interface (RCI) process changes the address of an MS used in the RSS into
the address used by the Layer 3 call processing processes.
The RSS addresses MS by using its channel number, while the layer 3 call processing processes
address messages for an MS using the SCCP reference number.
These processes can be located dependent on which form of Abis is chosen. Under Motorola
systems, these reside at the BTS cabinet.
68P02901W36-S 6-5
Jul 2008
Radio channel interface Chapter 6: Call Processing
Figure 6-1 shows the relationship between call processing and the RSS.
Figure 6-1 Call processing and the RSS relationship
MTL
BSC
BSP LCF
MTPL2
MTPL3
CLM
SCCP P RE PRO
HO
SSM
EVAL
LCF LCF
MTPL2 MTPL2
MTPL3 MTPL3
SCCP P RE PRO SCCP P RE PRO
HO HO
SSM SSM
EVAL EVAL
In-Cell In-Cell M-Cell

BTS BTS BTS
BTP BTP MCU

RRSM RRSM RRSM
CRM CRM CRM
RCI RCI RCI
DHP DHP DHP DHP DHP TCU
RSS RSS RSS RSS RSS RSS
6-6 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Adaptive Multi-Rate (AMR) call processing
Adaptive Multi-Rate (AMR) call processing
Carrier identification
After the RTF assignment procedure is complete, there can be a number of DRIs with AMR
Half-Rate (HR) RTFs (BCCH or NON-BCCH) assigned to them. Identify these DRIs within the
BSS as AMR HR capable resource, to allow correct management of AMR HR resources.
Similarly, there can be a number of DRIs which are not allocated AMR HR RTFs (BCCH or
NON-BCCH). These remaining DRIs are identified within the BSS as AMR Full-Rate (FR) capable
resources, to allow correct management of AMR FR resources.
Change in AMR enable or disable states for a cell
The operator selects AMR support in a cell. AMR functionality can be enabled or disabled for
that particular cell or at BSS level. If AMR HR channel mode is disabled at the BSS or cell level,
existing AMR half-rate calls are unaffected, as long as they remain in the same air interface
timeslot. Call handovers performed after AMR is disabled, are allocated the highest speech
version available from the MSC by the BSS.
Disabling AMR (at BSS or cell level) causes AMR FR non idle generic capable timeslots to
support standard FR and Enhanced Full-Rate (EFR) speech only, once all existing calls are
completed. Idle generic timeslots still support AMR FR also. If only HR AMR is disabled any idle
HR timeslots are not used until any existing calls are completed. Once all calls are completed
the timeslot supports AMR FR, standard FR and EFR only.
NOTE
A half-rate capable timeslot is known as a generic traffic timeslot when it is not in use.
If AMR half-rate functionality is restricted by modification of per BSS or per cell switches,
existing AMR half-rate calls remain unaffected until the next event within the life of that
call. For example, upon target resource selection for an intra-cell handover, the switches are
re-evaluated and the call could be directed onto an FR resource (depending on scenario and
availability of resources). Until such an event occurs, to initiate re-evaluation of the BSS
configuration, the calls remain AMR half-rate calls.
68P02901W36-S 6-7
Jul 2008
Call setup Chapter 6: Call Processing
Call setup

Connection establishment
In this section, message sequences are shown as ladder diagrams for

the establishment of a connection to a Mobile System (MS) as follows:
Successful connection establishment
Between GSM elements.
Between internal systems and subsystems.

Figure 6-2 shows a successful connection establishment between GSM elements:
Figure 6-2 Successful connection establishment between GSM elements
6-8 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Connection establishment
Successful connection establishment (internal)
Figure 6-3 and Figure 6-4 show the successful connection establishment sequence (in two parts)
within and between the BSC and BTS systems and subsystems.
Figure 6-3 Successful connection within and between BSC and BTS (Part 1)
BTS BSC
RSS CRM RRSM/RCI SSM MTP
CHANNEL REQUIRED
(RACH)
(channel required
received)
(channel assigned)
Note 1
below .
(channel activation)
(channel activation
acknowledge)
IMMEDIATE ASSIGN
COMMAND (AGCH)
ESTABLISH
INDICATION, CM
SER VICE
REQUEST , SABM +
INITIALLAYER 3
MESSAGE
(SDCCH)
(ms power control)
(initial layer 3
information, CM
service request)
CONNECTION
REQUEST ,
COMPLETE LAYER
3 INFORMATION
Note 1 - RSS internal messaging not shown.
ti-GSM-BSC BTS successful connection 1-0021 1-ai-sw
68P02901W36-S 6-9
Jul 2008
Connection establishment Chapter 6: Call Processing
Figure 6-4 Successful connection within and between BSC and BTS (Part 2)
MODE CMD
6-10 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Assignment to TCH
NOTE
In a call establishment process, a multiband MS included in the CM SERVICE
REQUEST messages a bit indicator that informs the network that MS classmark 3
is used. It follows this with a CLASSMARK CHANGE message which contains CM3
information for the BSS to pass to the MSC.
Assignment to TCH
In this section message sequences are shown as ladder diagrams for the
assignment of a Traffic Channel (TCH) to a Mobile System (MS) as follows:
Successful handover
Between GSM elements.Between internal systems and subsystems.
Between internal systems and subsystems.
Figure 6-5 shows a successful TCH assignment between GSM elements:
Figure 6-5 Successful TCH assignment
Successful assignment sequence (internal)
Figure 6-6 and Figure 6-7 show the successful assignment sequence within and between the
BSC and BTS systems and subsystems (in two parts).
68P02901W36-S 6-11
Jul 2008
Assignment to TCH Chapter 6: Call Processing
Figure 6-6 Assignment sequence within and between BSC and BTS (Part 1)
BTS BSC
RSS CRM RRSM/RCI SM SSM MTP

DT1,
ASSIGNMENT
REQUEST
(initiate
assignment)
(assignment
resource
request)
(assignment
channel
assigned)
(physical
context
request)
(physical
context
confirm)
(channel
activation)
(channel
activation
acknowledge)
DATA
REQUEST ,
ASSIGNMENT
COMMAND
(establish
indication)
DATA
INDICATION,
ASSIGNMENT
COMPLETE
ti-GSM-BSC BTS assignment sequence 1-00214-ai-sw
6-12 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Assignment to TCH
Figure 6-7 Assignment sequence within and between BSC and BTS (Part 2)
BTS BSC
RSS CRM RRSM/RCI SM SSM MTP
DATA INDICATION,
ASSIGNMENT
COMPLETE
(deallocate
inactive dch)
(deactivate (assignment
sacch) successful)
(release
confirm)
(transfer
request)
(release
confirm
received)
(switch
response)
(rf channel
release)
DT1,
ASSIGNMENT
COMPLETE
(rf channel
release
acknowledge)
(rf channel
release ack
rf_chan_rel_ack received)
stop>
DTAP, ALERT
(dtap, alert)
DATA
REQUEST ,
ALERT
DTAP, CONN
(dtap, conn)
DATA
REQUEST ,
CONN
DATA IND,
CONN ACK
(dtap, conn
ack)
DTAP, CONN
ACK
ti-GSM-BSC BTS assignment sequence 2-00215-ai-sw
68P02901W36-S 6-13
Jul 2008
Assignment of new calls as Adaptive Multi-Rate (AMR) Half rate Chapter 6: Call Processing
Assignment of new calls as Adaptive Multi-Rate (AMR) Half rate
A congestion threshold, new_calls_hr, is provided. When congestion levels exceed this

threshold, the BSS assigns any new half-rate (HR) capable calls to HR traffic channels. Also, any
MSC specified preference is over-ridden and the use of HR is mandatory for HR capable calls.
NOTE
Assignment of new calls directly to the inner zone of multi-zone cells are further
restricted.
The algorithm applied to establish whether the new_calls_hr threshold has been exceeded
is based upon the use of resources within the outer zone only. The new_calls_hr threshold
is checked on reception of an assignment or handover request message. The threshold is
also checked on receipt of an intra-BSS inter-cell handover request into the cell. If the
inter_cell_handover_allowed element is set to allow the BSS to perform intra-BSS handovers
then the inter-cell handover is performed without receiving a handover request from the MSC.
NOTE
Incoming calls are considered in the calculation to determine whether the
new_calls_hr threshold is exceeded. For example: If new_calls_hr is set to 0 the first
call set exceeds the threshold is established on an HR channel if the call is HR capable.
Calls performing intracell handovers are only considered once in the calculation.
If the AMR HR channel mode is not enabled at either BSS or cell level, the BSS ignores the
new_calls_hr congestion threshold.
An HR channel from a given cell is allocated to a call, if the cell congestion level in that cell
exceeds the new_calls_hr threshold and if the call is HR capable. This action is limited by
the existence of idle HR channels, including HR reserved channels and free generic traffic
channels in the cell.
The new_calls_hr threshold is checked for all calls undergoing intra-cell range handovers. As
AMR is not supported on extended range timeslots, the new_calls_hr threshold only affects
extended to normal range handovers.
Adaptive Multi-Rate (AMR) TCH/H immediate assignment
The speech version capability of an MS is unknown on immediate assignment. If immediate

assignment to a TCH half-rate (TCH/H) channel were permitted then an MS that does not
support the AMR half-rate (HR) channel mode must be reassigned to a TCH Full rate (TCH/F),
immediately after being assigned to the TCH/H.
Therefore, immediate assignment of an MS to an AMR HR traffic channel is not permitted.
NOTE
To prevent an MS from requesting immediate assignment to a TCH/H, the NECI bit
within the cell selection parameters information element (system information type 3
and type 4) is not set.
6-14 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Adaptive Multi-Rate (AMR) TCH/H immediate assignment
The TCH allocated is Full-Rate (FR) capable but can also be AMR FR capable. If the assignment
request from the MSC identifies an AMR FR speech version as highest priority and the allocated
channel does not support AMR full-rate, the BSS selects a speech version of a lower priority,
Enhanced Full-Rate (EFR) or FR. Reallocation of a channel which is not compatible to AMR
FR is not attempted to prevent call delays.
NOTE
If the assignment request from the MSC identifies the AMR FR speech version as
highest priority and the allocated traffic timeslot is AMR FR capable, the BSS uses
the AMR FR speech version for the call.
Non-emergency calls are not permitted to steal channels reserved by the multiband handover
functionality. Reserved HR capable traffic timeslots are considered for use in immediate
assignment directly to a TCH/F if all other resources within the outer zone have been exhausted
(including GPRS switchable timeslots).
68P02901W36-S 6-15
Jul 2008
GSM encryption (ciphering) Chapter 6: Call Processing
GSM encryption (ciphering)

Use of ciphering
GSM encryption provides security for user speech, data, and signaling information. This feature
enables and prioritizes the GSM A5 encryption algorithms in the BSS. Encryption in the BSS can
be implemented using the multiple encryption options or individual encryption options.
Multiple encryption provides all the available GSM encryption versions.
Individual GSM encryption version scan be purchased and enabled.
Multiple encryption algorithms are loaded into the BSS through the software download. During
configuration of the BSC, the CA informs the SSM of the encryption algorithms supported by the
BSS software. Purchasable algorithms include A5/0 (Null encryption), A5/1 (Full encryption)
and A5/2 (Prime). When the MSC sends the cipher mode command or handover request, the
message can include just one or a number of permitted algorithms. The SSM decides which of
these algorithms are to be used based on the following criteria:
Capability of the MS as indicated by the classmark.
Permitted algorithms supplied by the MSC.
Algorithms purchased by the operator (stored in the GSM database).
Algorithms supported by the DRIM Firmware.
Operator prioritized list of algorithms (stored in the CM database).
If no algorithms meet the above criteria, the SSM sends the appropriate failure message. If
the BSS selects the encryption algorithm from the set of more than one supplied by the MSC,
the SSM includes the chosen algorithm in the cipher mode complete or Handover Request
Acknowledge message to the MSC.
Multiple encryption priority is not necessary when the individual algorithms (1-7) are used
independently from the multiple encryption option, for example, if a customer purchases just
A5/1.
Multiple A5 encryption algorithm versions purchased by the operator must be enabled by the
change element option_alg_a5 command and prioritized by the chg_a5_alg_pr database
command. The order in which they are entered prioritizes their use. The encryption algorithms
are prioritized on a per-BSS basis and only those prioritized can be used. If no algorithms are
prioritized then the default is no encryption.
6-16 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Use of ciphering
Message sequences in ciphering
Figure 6-8 shows ciphering commands between the GSM elements.
Figure 6-8 Ciphering commands between GSM elements
Figure 6-9 shows the signal sequence in a successful ciphering specification, within and between
the BSC and BTS systems and subsystems.
Figure 6-9 Successful signal sequence in ciphering specification
68P02901W36-S 6-17
Jul 2008
Related commands and parameters Chapter 6: Call Processing
The option_alg_a5 parameter can be used with the chg_element command to select the
encryption algorithm.
The command chg_a5_alg_pr can be used to prioritize use of the encryption algorithms.
System impact
For effective use, this feature must be deployed at the MSC, BSS and MS. The option to change
and select encryption algorithms must be purchased and unrestricted.
Unless stated otherwise, handover refers to a handover between different call rates as detailed
below:
AMR Full-Rate (FR), EFR, or FR to AMR 16 kbps Half-Rate (HR).
AMR FR, EFR, or FR to AMR 8 kbps HR.
AMR 16 kbps HR to AMR FR, EFR, or FR.
AMR 16 kbps HR to AMR 8 kbps HR.
AMR 8 kbps HR to AMR FR, EFR, or FR.
AMR 8 kbps HR to AMR 16 kbps HR.
{28340}
A list-based Ater search algorithm is used to allocate resources when a new call (mobile
originated, mobile terminated, external handover from MSC), CIC remap or Ater switchover is
initiated or for existing calls with rate change.
When a call is initiated and the CIC is associated with the correct Ater resource then existing
resource is used.
Call setup and handover
The three main states that an Ater can take are as follows:
Float or floating state - An Ater in a float state has no associations to CICs or calls.
Idle state - An Ater in the idle state has an association to a CIC but does not have an
association to a call.
Inuse state - An Ater in the inuse state has an association to a CIC and an association
to a call.
6-18 68P02901W36-S
Jul 2008
The state of an 8 kbps Ater when applying the rules depends not only on its own state but also
the state of its partner (that is, the other 8 kbps half of the 16 kbps group). Therefore, an 8 kbps
Ater needs to be represented by its own state and that of its partner.
Selection of an Ater for a 16 kbps call when the CIC is associated to an 8

kbps Ater When the CIC is associated to an 8 kbps Ater, the other half of the associated 8
kbps Ater is attempted to be used. If the Ater pair is not available, attempts are made to obtain
a 16 kbps Ater for the request. The 16 kbps resource is allocated in the following order after
releasing the current 8 kbps Ater:
1. Float 16 kbps Ater.
2. Idle 16 kbps Ater associated to an HR capable CIC.
3. Idle 16 kbps Ater associated to a non HR capable CIC.
If no 16 kbps Ater is found then the current 8 kbps Ater is released and two contiguous idle/float
8 kbps Ater resources are allocated. Ater signaling is required
The above selection sequence is used for CIC remap also. Ater signaling is required when
the existing Ater is reused.
Selection of an Ater for a 16 kbps call when the CIC is not associated to an
Ater When the CIC is not associated with an Ater, attempts are made to allocate a 16 kbps Ater
in the following sequence:
2. Idle 16 kbps Ater associated to an HR capable CIC.
3. Idle 16 kbps Ater associated to a non HR capable CIC.
If no 16 kbps Ater is available, the call is allocated to two contiguous idle/float 8 kbps Aters in
the following order and Ater signaling is required:
1. 8 kbps Float/(Float).
2. 8 kbps Float/(Idle).
3. 8 kbps Idle/(Idle).
Selection of an Ater for an 8 kbps call when the CIC is not associated to an
Ater Attempts are made to obtain an 8 kbps Ater in the following sequence:
1. 8 kbps Float/(Inuse) Ater.
2. 8 kbps Float/(Idle) Ater.
3. 8 kbps Float/(Float) Ater.
4. 8 kbps Idle/(Inuse) Ater.
5. 8 kbps Idle/(Idle) Ater.
6. 8 kbps Idle/(Float) Ater.
68P02901W36-S 6-19
Jul 2008
Adaptive Multi-Rate (AMR) Chapter 6: Call Processing
If no 8 kbps Ater is available then attempts are made to obtain 16 kbps in the following sequence:
1. 8 kbps of a 16 kbps float Ater.
2. 8 kbps of a 16 kbps Idle Ater associated to an HR capable CIC.
3. 8 kbps of a 16 kbps Idle Ater associated to a non HR capable CIC.

Ater signaling is required.
The above selection sequence is used for CIC remap also. Ater signaling is required when
the existing Ater is reused.
Selection of an Ater for an 8 kbps call when the CIC is associated to a 16

kbps Ater The 16 kbps Ater is released and attempts are made to obtain an 8 kbps Ater
in the following sequence:

When no 8 kbps Ater is available, use 8 kbps of currently assigned 16 kbps Ater.
When the existing Ater is used for CIC remap, Ater signaling is required.
Calls with rate change
When the rate of an existing call is to be changed, the BSC allocates Ater resources according to
the following allocation rules.
Selection of a 16 kbps Ater when the CIC is associated to an 8 kbps Ater The
call is allocated to the pair of the 8 kbps Ater. If it is not available, the 8 kbps Ater is released
and attempts to allocate 16 kbps Ater is made in the following sequence:
2. Idle 16 kbps Ater associated to HR capable CIC.
3. Idle 16 kbps Ater associated to non HR capable CIC.
When no 16 kbps Ater is available, 2 contiguous idle/float 8 kbps Aters are allocated and Ater
signaling is required.
6-20 68P02901W36-S
Jul 2008
Selection of an 8 kbps Ater when the CIC is associated to a 16 kbps Ater The
16 kbps Ater is released and a float 8 kbps Ater is associated.
The 8 kbps of the currently assigned 16 kbps Ater is used as a last option. Ater signaling is
required only when a new resource is allocated.
68P02901W36-S 6-21
Jul 2008
Call clearing Chapter 6: Call Processing
Call clearing

Introduction to call clearing
In this section message sequences are shown for call clearing. The MS, BSS, or the MSC
originates call clearing.
MS originated call clearing
Figure 6-10 and Figure 6-11 show the call clearing message sequence when initiated by the MS.
6-22 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation MS originated call clearing
Figure 6-10 Call clearing initiated by MS (Part 1)
68P02901W36-S 6-23
Jul 2008
MS originated call clearing Chapter 6: Call Processing
Figure 6-11 Call clearing initiated by MS (Part 2)
6-24 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation MSC originated call clearing
MSC originated call clearing
Figure 6-12 shows the call clearing message sequence when initiated by the MSC.
Figure 6-12 Call clearing initiated by MSC
68P02901W36-S 6-25
Jul 2008
GPRS data transfer processing Chapter 6: Call Processing
GPRS data transfer processing

MS states
MSs can be in one of the three states when used for GPRS:
Idle - Could be switched off or in GSM IMSI attach state but not GPRS attached.
Ready - GPRS attached. Context can now be activated. MS performing cell and routing
area updates.
Standby - Similar to GSM Idle state. MS listening and performing only routing area
updates.
In a GPRS network, there are three packet access procedures that the MS can use to establish
an uplink TBF: two-phase, one-phase, or enhanced one-phase.
GPRS two-phase access
The two-phase GPRS access stages depends on whether MS originated (uplink) or MS

terminated (downlink):
Uplink:
GPRS attach.
Packet channel request.
Packet resource request.
Data transmission.
GPRS detach.
Downlink:
GPRS paging request.
Request PDP context activation.
Activate PDP context request.
Packet channel request.
Packet resource request.
Data transmission.
GPRS detach.
The message sequences in the above stages follow.
6-26 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Two-phase attach
Two-phase attach
The MMS sends up an Attach Request message which includes:

IMSI or Packet TMSI.
Old routing area identification (so that new SGSN can check any unacknowledged data
and resend it).
Classmark (multislot capability, GPRS cipher algorithms).
Cipher Key Sequence Number (CKSN).
Attach type (GPRS, IMSI or both).
DRX (Discontinuous Reception) capability.
Old P-TMSI if one exists.
Figure 6-13 below shows only the signaling between the MS and the BSS.
Figure 6-13 GPRS attach messages
Two-phase TBF access (MS originated)
In the two-phase access procedure, the RACH is forwarded from the BTS to the PCU for
processing.
The PCU responds to the RACH with an Immediate Assignment message containing a single
block allocation. The MS moves to the assigned PDTCH and transmits a Packet Resource
Request message. Upon reception of the PRR, the PCU sends a Packet Uplink Assignment
message to the MS containing an uplink assignment. Once the MS receives the PUA, it proceeds
with the uplink data transfer.
68P02901W36-S 6-27
Jul 2008
Two-phase attach Chapter 6: Call Processing
See Figure 6-14 for the message sequence in the two-phase access procedure.
Figure 6-14 Two-phase TBF access
The post BSS two-phase access procedure is slower than the previous two-phase implementation.
If the establishment cause in the Channel Request message indicates a request for one-phase
packet access, the network can grant either a one-phase packet access or a single block packet
access for the MS. If a single block packet access is granted, it forces the MS to perform a
two-phase packet access.
The majority of the MSs that exist request a one-phase packet access when establishing an
uplink TBF. There are few instances when an MS requests a single block allocation (for example,
Packet Measurement Reports if the requested RLC mode is in unacknowledged mode).
Downlink assignments (MS terminated)
During downlink TBF establishment procedures, when the MS is on the PDCH, the PCU does
not poll the downlink assignment message using a Packet Control Ack. Instead, the PCU uses
the Packet Downlink Ack/Nack (acknowledgment/negative acknowledgment) as an implicit
acknowledgment for the downlink assignment message. If an MS is required to transmit a
Packet Control Ack subsequent to a downlink assignment, there is an additional reaction time
before the MS is ready to receive on the new assignment. By eliminating the PCA poll, the MS
can receive on this new assignment some 40 ms earlier. This decreases the downlink TBF
establishment time.
During downlink TBF establishment procedures when the MS is on the CCCH,

the PCU polls the downlink assignment. Upon receiving the Packet Control
Ack, the PCU sends a Packet Power Control Timing Advance (PCTA) message.
6-28 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation MS originated packet transfer
The PCU does not then poll this message using a Packet Control Ack, but instead uses the
Packet Downlink Ack/Nack as an implicit acknowledgment for the PCTA message.
Uplink congestion management
The BSS introduces uplink congestion management functionality by monitoring the GPRS load
of the BSS and limiting the number of new GPRS users into the system. The BSS throttles
RACHs on the RSL (to avoid RSL congestion) and sends Immediate Assignment Reject messages
to users during periods of congestion.
MS originated packet transfer
The process begins with the MS sending a packet channel request message on the PRACH. This
message contains the number of RLC blocks (based on coding sequence CS-1) that the MS
requires to send. The BTS responds with an immediate assignment message with a one block
allocation reserved for use by any MS to send a packet resource request message to the PCU. In
the two-phase access method, the MS sends up a packet resource request message in this one
block allocation and the BTS responds with a packet uplink assignment message.
The packet uplink assignment message contains:

Packet Data Channels (PDCHs) to use.
Temporary Flow Identifier (TFI).
Uplink State Flag (USF).
Temporary Logical Link Identifier (TLLI).

Figure 6-15 shows the message sequence.
Figure 6-15 MS originated packet transfer
68P02901W36-S 6-29
Jul 2008
MS originated packet transfer Chapter 6: Call Processing
Uplink packet transmission then proceeds. Figure 6-16 shows the message sequence for
packet data transfer.
Figure 6-16 Uplink packet data transfer
Dynamic allocation mode
In dynamic allocation mode, three Uplink State Flag (USF) bits are transmitted in every
downlink block. Through these USF bits, the network instructs one of the MSs sharing a
timeslot to transmit data on the uplink. MSs monitor the channel for their instruction to
transmit. The advantage offered by dynamic allocation mode, is flexibility in the assignment of
the air interface resource.
6-30 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation MS terminated packet transfer
MS terminated packet transfer
Paging and acknowledgment
The process begins with the BSS sending a GPRS paging request message on the Paging
Channel (PCH). This message contains the Packet TMSI (P-TMSI), or the TLLI, or the IMSI. If
the MS is in standby mode, it responds with a packet channel request, which contains the TLLI
and a complete LLC frame. The MS is then known to be in the ready state. If the MS is already
in the ready state, a packet resource assignment message is sent straight away.
The MS then initiates an uplink TBF and sends a higher layer protocol message to acknowledge
the TBF.
Figure 6-17 shows the message sequence.
Figure 6-17 MS terminated packet transfer
NOTE
A Temporary Block Flow (TBF) is a logical connection used by the MS to/from the
PC to support the unidirectional transfer of Logical Link Control (LLC) Protocol Data
Units (PDUs) on packet data physical channels. The TBF is allocated radio resource
on one or more PDCHs and comprises a number of Radio Link Control/Medium Access
Control (RLC)/MAC blocks carrying one or more LLC PDUs. A TBF is temporary and
maintained only for the duration of the data transfer (that is to say, until there are
no more RLC or MAC blocks to be transmitted and, in RLC acknowledged mode, all
of the transmitted RLC or MAC blocks have been successfully acknowledged by the
receiving entity).
68P02901W36-S 6-31
Jul 2008
GPRS one-phase access Chapter 6: Call Processing
Downlink data transfer
The message sequence in Figure 6-18 shows the packet flow for multislot downlink data transfer
with resource reassignment and RLC data block transmissions. If the BSS receives an LLC
frame from a GSN, the BSS assumes that the MS is in the ready state and transmits the data to
the MS. Each RLC block contains a Temporary Flow Identifier (TFI) that uniquely identifies each
Temporary Block Flow (TBF). This allows more than one MS to use the same PDTCH.
On release of the resource during downlink transfer, the BSS terminates the transfer and polls
the MS for a final packet ACK/NACK message. As soon as this is received from the MS, the
guard timer expires, the assignment is freed and the USF and TFI are available for reuse.
Figure 6-18 Downlink packet data transfer
GPRS one-phase access
GPRS one-phase uplink TBF access is an improvement over the two-phase uplink TBF access
procedure.
In a GPRS one-phase uplink TBF access, the MS initiates an uplink TBF by

sending a Random Access Channel (RACH) to the BSS. The RACH is received
at the BTS, which is then forwarded to the PCU. The PCU responds to the
RACH with an Immediate Assignment message containing an uplink assignment.
6-32 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Enhanced GPRS one-phase access
The MS moves to the assigned Packet Data (Traffic) Channel (PDTCH) and begins its uplink
data transfer. This procedure allows the MS to gain access to the network much quicker when
comparing against the two-phase establishment procedure.
Figure 6-19 shows a time comparison between two-phase access and one-phase GPRS access.
Figure 6-19 GPRS two-phase and one-phase access
IMMEDIATE
Va lues shown are approximate best case

ti-GS M-GP RS 2 pha s e a nd 1 pha s e a cce ss-0 0200-a i-s w
Enhanced GPRS one-phase access
The enhanced GPRS one-phase uplink TBF access procedure speeds up the one-phase packet
access procedure even further.
The enhanced GPRS one-phase access procedure improves PCU assignment of resources for
a one-phase uplink TBF, by enabling the BTS to react more quickly to a one-phase RACH
without forwarding the RACH to the PCU. This reduces the RSL delay increasing the RSL
load. Depending on the RSL load, the RACH to Immediate Assignment delay reduces by
approximately 60 ms or more.
There are two versions of enhanced GPRS one-phase access:

If the PCU has pre-allocated resources at the BTS and the pre-allocated timeslot is not
in the USF active state, the timeslot broadcasts the corresponding Uplink Stage Flag
(USF), once it knows that an MS has moved to the pre-allocated timeslot. This process is
shown in Figure 6-20 diagram A.
68P02901W36-S 6-33
Jul 2008
Enhanced GPRS one-phase access Chapter 6: Call Processing
If the TS that was pre-allocated by the PCU is in the USF active state, the timeslot
broadcasts a valid USF continuously, as shown in Figure 6-20 diagram B. Once an MS
moves to the pre-allocated timeslot (after the MS receives the Immediate Assignment
message), the MS receives the assigned USF immediately. This is the earliest possible
opportunity for the MS to transmit in the uplink. The only delay between the Immediate
Assignment message and the uplink data transmission is the MS reaction time.
Enhanced GPRS one-phase access must be unrestricted in a network and enabled by the
eop_enabled database parameter.
Figure 6-20 Enhanced GPRS one-phase access showing timeslot USF state
In any cell, all timeslots that are configured on the Broadcast Control Channel (BCCH) carrier
as PDTCHs (and have pre-allocated resources) will always be in the USF active state. In the
same cell, the existing per cell database parameter ts_in_usf_active. can be used to control
the number of non-BCCH carrier timeslots that are in the USF active state. Timeslots in the
USF active state on a non-BCCH carrier cause additional interference in the system, since it
will be broadcasting continuously.
The pkt_radio_type for BCCH parameter is also significant when configuring the BSS for use
with enhanced one-phase access. Because all timeslots on the BCCH broadcast at full power,
it is recommended that this parameter is used to set the BCCH carrier for GPRS, so that the
number of timeslots in a cell that are in the USF active state is maximized.
During system operation, when Enhanced One Phase (EOP) access is enabled (eop_enabled is
set to one), if the total GPRS timeslots in a cell are three or less, then there are no pre-allocated
GPRS timeslots. If a cell has four or more GPRS timeslots and EOP is enabled, then there is
one pre-allocated resource.
6-34 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation EGPRS one-phase access
NOTE
The size of a cell as well as the current load of the system determines the number
of pre-allocated resources in any given cell. If a cell is configured with four or more
GPRS timeslots (Switchable and Reserved), one GPRS timeslot is always observed
in the active state.
EGPRS one-phase access
For EGPRS, the BSS supports the following:

One-phase access for EGPRS mobiles only when the BCCH RTF is mapped to CTU2.
When the BCCH RTF is mapped to a CTU2 the channel coder supports detection of TS1
or TS2 training sequence associated with the 11-bit EGPRS packet channel request
irrespective of backhaul configuration, density of the carrier, or extended-range mode of
the BCCH timeslot. The channel coder indicates to the PCU in the uplink PRACH TRAU
frames the training sequence used to decode the 11-bit channel request which indicates
the mobile support of 8PSK channel coding on the uplink.
Reception of the EGPRS PACKET CHANNEL REQUEST message on the PCCCH on CTU2s.
Reception of the EGPRS PACKET CHANNEL REQUEST message on the CCCH on CTU2s.
11-bit EGPRS Packet Channel Request on the CCCH using training sequence codes TS1
and TS2.
11-bit EGPRS packet channel request on the PCCCH using training sequence codes TS1
and TS2.
EGPRS Packet Channel Request with training sequence code TS1 indicating 8 PSK
capabilities in the uplink.
EGPRS Packet Channel Request with training sequence code TS2 indicating no 8PSK
capability in the uplink.
The BSS responds to an EGPRS Packet Channel Request message on the PCCCH of format:
one-phase Access Request, Short Access Request, and MM signaling with a Packet Uplink
Assignment message indicating dynamic allocation.
The BSS responds to an EGPRS Packet Channel Request messages on the CCCH of format:
one-phase Access Request, Short Access Request and MM signaling with an Immediate
Assignment message indicating dynamic allocation.
The BSS sends an Immediate Assignment message with a single block allocation in
response to an EGPRS Packet Channel Request of format two-phase access on the CCCH.
The BSS sends a Packet Uplink Assignment message with a single block allocation in
response to an EGPRS Packet Channel Request of format two-phase access on the PCCCH.
In the Immediate Assignment the single block allocation is indicated by setting

the Multi Block Allocation IE to 0 0. In the Packet Uplink Assignment the single
block allocation is indicated by setting the Multi Block Allocation IE to 0 0.
68P02901W36-S 6-35
Jul 2008
EGPRS one-phase access Chapter 6: Call Processing
When the BSS sends the Immediate Assignment message in response to an EGPRS Packet
Channel Request message the Request Reference IE is set to the value 0 1 1 1 1 1 1 1
indicating that the extended RA field is included in the IA Rest Octets.
The BSS considers the multi-slot class from the EGPRS Packet Channel Request for
one-phase access request received on the CCCH or PCCCH when allocating resources.
The BSS considers the mobile to be a gprs_common_ms_class mobile station if multi-slot

class is not included in the EGPRS Packet Channel Request for all other access types
except one-phase access.
The BSS ignores an EGPRS Packet Channel Request if the access type of the Packet
Channel Request message is unknown.
Enhanced one-phase access on GPRS carriers only.
EGPRS capabilities in the Packet Resource Request during two-phase access.
The BSS does not support Enhanced one-phase access for EGPRS mobiles requesting
one-phase access. The BSS does not preallocate Enhanced one-phase resources on a
64 k EGPRS carrier.
The BSS services an EPCR requesting one-phase access, short-access, or MM signaling in

the following order:
Allow the PCU to process the EPCR if the site's RSLs have bandwidth for the
additional GPRS/EGPRS traffic.
Utilize available reserved PRR blocks.
Discard EPCR.
The BSS services an EPCR requesting two-phase access in the following order:
Utilize available reserved PRR blocks.
Allow the PCU to process the RACH/EPCR if the site's RSLs have bandwidth for the
additional GPRS/EGPRS traffic.
Discard EPCR.
The BSS uses a different priority scheme to service an EPCR depending on the type of
request specified. The method by which the BSS attempts to service an EGPRS request for
one-phase packet access is different than the method the BSS will use in an attempt to
service an EGPRS request for two-phase packet access.
The BSS throttles EPCRs, Uplink IAs and Downlink IAs over the RSL(s) for each EGPRS
capable cell on a site. The throttling is based on the percent of RSL(s) allowed for GPRS
signaling traffic and the sum of the EPCR and GPRS RACH arrival rate at each cell.
There is independent throttling for both the UL and DL. EPCR messages that need to
be passed through to the PCU for processing will be discarded when the GPRS RACH/
EPCR throttle threshold is reached. When the BSS receives a Channel Request for EGPRS
resources and the PCU cannot assign the mobile resources because the links to the BTS
have reached GPRS/EGPRS capacity, the Channel Request is discarded.
The percentage of the RSL bandwidth given to each cell for GPRS/EGPRS messages is
determined by the number of GPRS enabled cells at the site, the number of GPRS and
EPCRs received at each cell and the percentage of the RSL bandwidth available for all
GPRS/EGPRS messaging at the site, which is equal to 100-percent_traf_cs.
6-36 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Delayed release of downlink TBF
Delayed release of downlink TBF

Overview of delayed release of downlink TBF
NOTE
Delayed release of downlink TBF is sometimes known as Supercoattail.
The delayed release of downlink TBF extends the downlink Temporary Block Flow (TBF) for a
variable period of 0.3 (15 x 20 ms Blocks) to 12 seconds (600 x 20 ms Blocks) by transmitting
dummy Logical Link Control (LLC) frames. By delaying the downlink TBF release, there is no
need to send a new Packet Downlink Assignment (PDA), allowing data to be sent straight away
in the next block period. It also means that if the MS uplink needs to be established while
being polled during the extended downlink TBF period, the CCCH and RACH do not have to
be accessed and a channel request in the DAK message is sent instead, reducing the UL TBF
establishment time by 500 ms.
The delayed downlink TBF release duration parameter, delay_dl_rel_dur, allows the operator
to set the number of blocks for which the network delays the release of a downlink TBF. The
parameter can take values in the range 15 to 600 blocks (one block period equals 20 ms) the
default value is 50 blocks (1 second).
NOTE
The downlink TBF establishment duration is minimized, if a Packet Downlink

Assignment (PDA) is sent on the PACCH while uplink TBF is in progress.
Currently, if the downlink TBF does not exist for the mobile while releasing the
uplink TBF, the uplink TBF is extended by delaying the final PUAK by a fixed
number of block periods.
Using the delay_ul_rel_dur parameter to set the duration of the release of the
uplink TBF delay, the operator can adjust the delay of the uplink TBF.
Basic operation
The basic aspects of Delayed release of downlink TBF operation are:

TBF period duration extended from 40 ms to 4.5 seconds.
Dummy LLCs chopped into CS1 RLC data blocks to be sent down.
On arrival of actual data from upper layers, zero DL TBF establishment time and reduced
Ul TBF establishment time.
68P02901W36-S 6-37
Jul 2008
Activating GPRS timeslots Chapter 6: Call Processing
Before the dummy LLC frames are sent, the MS acknowledges all previous LLCs. If no
meaningful data is sent by an MS on the PD channel for 4.5 seconds, interference to other
MSs transferring data can be caused. To reduce this interference, the Coding Scheme (CS) 1
data blocks corresponding to the dummy LLCs are only sent on the Packet Associated Control
Channel (PACCH) timeslot when the MS needs to be polled.
Activating GPRS timeslots
Without delayed release of downlink TBF communication between a 3RX MS and a GPRS cell
occupies three active timeslots. When using the delayed release feature for a downlink TBF,
the first downlink TBF in the new cell is extended to the end of the current FTP session.
Therefore, a 3RX MS downlink timeslots are changed from three timeslots to one timeslot
during cell reselection for an FTP session. The provision of one timeslot to an MS entering a
new cell is as per design.
New MS in the cell
When the MS initially performs the attach procedure, the data transfer is done using a random
TLLI or TLLI from another cell. In this situation no delayed release of DL TBF is allowed.
Changes in statistics
Changes in number of CS1 and idle blocks:

The delayed release of DL TBF duration is set to 4.5 seconds (225 block periods).
Dummy blocks (CS1) are sent out only on the PACCH timeslots during the polling period.
Because of different polling delays, the number of CS1 blocks sent down during delayed
release of DL TB differ as follows:
If no uplink is available for the MS during delayed release of DL TBF then the polling
delay is 4.
If uplink is available for the same MS then the polling delay is 12.
If uplink is available for a different MS then the polling delay is 4.
Thus the maximum number of CS1 blocks during full delayed release of DL TBF can be
2254 = 57 blocks of CS1.
Coding scheme CS1 forced
If there are multiple bursts (1-2 seconds of data transfer) of downlink data at an interval of at
least 5-6 seconds, (100 transfers) then there will be 100-200 seconds of actual data transfer.
There will also be 500-600 seconds of data transfer (that is >70% if DL blocks are CS1 even
though CS2 would have been forced). If the data transfers are continuous and they consist of
UDPs, the percentage of CS1 blocks should not be significant.
6-38 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Coding scheme CS1 forced
If the interference level is high and an abnormal TBF has occurred due to high BLER, the coding
scheme is forced to CS1 for the next two TBFs. This is because, due to delayed release of
downlink TBF, an FTP session will have only one, extended, TBF (CS1 throughout).
68P02901W36-S 6-39
Jul 2008
Enhanced two uplink timeslots Chapter 6: Call Processing
Enhanced two uplink timeslots

Enhanced two uplink timeslots (2UL) improves MS GPRS performance by assigning up to two
uplink timeslots for multi-slot class MSs that support multiple uplink timeslot allocation.
Enhanced 2UL Timeslot Scheduling
This feature enables operation of two uplink timeslots for MS multi-slot classes that support it.
All multi-slot classes that support multiple uplink timeslots in dynamic mode are mapped to
multi-slot class 5, 6, 9 or 10.
Table 6-1 shows the MS multi-slot class mapping for all GPRS multi-slot classes.
Table 6-1 MS multi-slot class mapping for all GPRS multi-slot classes
Supported as
Multi-slot class
multi-slot class
01 01
02, 03 02
04 04
05 05
06, 07 06
08 08
09, 13 09
10-12, 14-29 10
Advanced uplink/downlink bias detection
For some multi-slot class MSs the maximum number of uplink and downlink timeslots in the
MSs allocation is less than the sum of the maximum number of timeslots that can be allocated in
an individual TBF direction. Such MSs can be allocated with more timeslots in one direction at
the expense of fewer timeslots in the opposite direction. This type of multi-slot class is called
a biasable multi-slot class. The Enhanced Two Uplink Timeslots feature supports biasable
multi-slot classes 6 and 10.
On request to create a Temporary Block Flow (TBF) for multi-slot class 6 or 10 MSs, the
GPRS TBF Scheduler (GTS) attempts to assign one uplink timeslot unless it is determined
that the MS favors uplink resource allocations, in which case the GTS attempts to assign the
maximum possible number of uplink timeslots to the MS. The maximum possible number of
uplink timeslots that the GTS can assign to an MS depends on timeslot utilization, resource
availability, and GPRS MS congestion.
6-40 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Advanced uplink/downlink bias detection
NOTE
In the case of one-phase access multislot class is unknown during initial scheduling.
Two uplink timeslots cannot be assigned until the multi-slot class is determined.
In a downlink data transfer, MS timeslot allocation remains downlink biased. In an uplink

data transfer or simultaneous uplink and downlink data transfer, the MS timeslot allocation
moves from downlink biased to uplink biased. Thus the MS reschedules to an allocation of the
appropriate bias (either uplink or downlink).
Figure 6-21 shows the multi-slot class 6 MS uplink bias configuration of two timeslots in both
downlink and uplink directions, or downlink bias of three downlink timeslots and one uplink
timeslot.
Figure 6-21 Multi-slot class 6 uplink/downlink bias timeslot allocation
Figure 6-22 shows multi-slot class 10 MS uplink bias configuration of two uplink timeslots and
three downlink timeslots, or downlink bias of four downlink timeslots and one uplink timeslot.
Figure 6-22 Multi-slot class 10 uplink/downlink bias timeslot allocation
MS multi-slot classes 5 and 9 support multiple uplink timeslots. However these MSs do not have
the restrictions of biasable classes and uplink/downlink biasing does not apply.
68P02901W36-S 6-41
Jul 2008
Advanced uplink/downlink bias detection Chapter 6: Call Processing
On request to create a TBF for multi-slot class 5 or 9 MSs, the GPRS TBF Scheduler (GTS)
attempts to assign the maximum possible number of uplink timeslots to the MS. Timeslot
utilization, resource availability, and GPRS MS congestion restrict the maximum possible
number of uplink timeslots that the GTS can assign.
NOTE
In the case of one-phase access multislot class is unknown during initial scheduling.
Two uplink timeslots cannot be assigned until the multi-slot class is determined.
6-42 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Enhanced scheduling
Enhanced scheduling

Dynamic allocation of reserved PRR blocks
Currently, EOP and one-phase are the preferred UL TBF establishment methods. Two-phase
access is used only if explicitly requested by the MS. In two-phase access, the RACH is
processed at the PCU and the immediate assignment is sent down the RSL to the BTS for
transmission to the MS, as illustrated in Figure 6-23.
Figure 6-23 Two-phase access procedure without reserved blocks
MS BTS PCU
CHANNEL REQUEST CHANNEL REQUEST

(RACH (Um)) (RACH (RSL))
IMMEDIATE ASSIGN IMMEDIATE ASSIGN

135 ms (AGCH (Um)) UPLINK (RSL)
220 ms PACKET RESOURCE

REQUEST (TRAU)
160 ms PACKET UPLINK

ASSIGNMENT (TRAU)
60 ms UPLINK STAGE
FLAG BITS
20 ms
DATA
Total 595 ms
ti-GSM-2 phase access procedure wo reserved blocks-00231-ai-sw
In all cases signaling messages are exchanged between the PCU and BTS over the RSL and
the signaling links can get overloaded in heavy traffic conditions (see Percentage of RSL
bandwidth reserved for circuit switched traffic). With enhanced scheduling, when the
RACH arrival rate reaches a certain threshold, the BTS requests the PCU to set up reserved PRR
blocks on the PDCHs, allowing more RACHs to be handled without utilizing RSL bandwidth, as
illustrated in Figure 6-24.
68P02901W36-S 6-43
Jul 2008
Priority dynamic allocation scheme Chapter 6: Call Processing
Figure 6-24 Two-phase access procedure with reserved blocks

MS BTS PCU
CHANNEL REQUEST
(RACH (Um))
IMMEDIATE ASSIGN
35 ms (AGCH (Um))
220 ms PACKET RESOURCE

REQUEST (TRAU)
PACKET UPLINK
160 ms
ASSIGNMENT (TRAU)
UPLINK STAGE
60 ms
FLAG BITS
20 ms
DATA
Total 495 ms
ti-GSM-2 phase access procedure with reserved blocks-00232-ai-sw
Once the RACH arrival rate subsides, these reserved blocks are removed. Reserved PRR blocks
are UL RLC blocks that are reserved by the BSS explicitly for PRR transmission. It is possible to
have a minimum number of reserved PRR blocks, subject to operator preference.
The number of PRR blocks is limited to twice the number of PDCHs in service over the four
multiframe period per cell.
If PCCCH is enabled for a GPRS cell then that cell does not receive any GPRS traffic over the
CCCH. Therefore, there is no need for the BSS to allocate any reserved PRR blocks. Reserved
PRR blocks are not supported for cells that have PCCCH enabled.
Priority dynamic allocation scheme
When the BSS receives a GPRS RACH requesting one-phase packet access, a priority scheme is
used to service the RACH. If an EOP TBF exists for that cell then the EOP is used as the first
means for servicing the RACH. If no EOP is available and the RACH throttle threshold has not
been reached, the second option is for the BTS to pass the RACH to the PCU for processing.
If a reserved block exists, the third option is to send an IA to the MS specifying the reserved
uplink block.
6-44 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Escalation method
Escalation method
The BSS uses an escalation mechanism that balances TBF establishment times against
capacity gains as the load in a cell increases. This balancing mechanism between capacity
and performance on a per cell basis is controlled by the database parameters, as shown in
Figure 6-25. The database parameter gprs_min_prr_blks specifies the minimum number of
reserved blocks always setup in a cell.
Figure 6-25 Number of PRR reserved blocks as a function of RACH arrival rate
The subsequent changes in the number of reserved blocks in that cell is proportional to the
database parameter prr_aggr_factor. Higher values of this parameter means a greater change
in the number of reserved blocks for every unit change in the RACH arrival rate and vice versa.
In a cell with 30 PDCHs, with aggressiveness factor set to 4, if there are enough PRR blocks to
support the calculated mean access rate of 12 PRR blocks per second then that cell can support
a peak access rate of 48 PRR accessing per second.
PRR blocks are allocated over a period of four multiframes (approximately one second). As there
are eight PRR blocks per cell, the peak access rate that can be achieved is eight PRR blocks
per second. The number of PRR blocks is limited to twice the number of PDCHs in service over
the four multiframe period.
68P02901W36-S 6-45
Jul 2008
Escalation method Chapter 6: Call Processing
EOP UL TBFs offer the shortest access time but also utilize the most amount of RSL bandwidth
as shown in Figure 6-26.
Figure 6-26 Enhanced one-phase access procedure
One-phase non-EOP TBFs are the second fastest option and use slightly lesser RSL bandwidth
as shown in Figure 6-27. Conversely, TBF establishment using reserved blocks imposes the least
amount of load on RSL but since this method employs two-phase access, it is also the slowest.
Figure 6-27 One-phase access procedure

MS BTS PCU
CHANNEL REQUEST CHANNEL REQUEST

(RACH (Um)) (RACH (RSL))
IMMEDIATE ASSIGN IMMEDIATE ASSIGN

135 ms (AGCH (Um)) UPLINK (RSL)
UPLINK STAGE
60 ms
FLAG BITS
20 ms
DATA
Total 215 ms

ti-GSM-1 phase access procedure-00235-ai-sw
6-46 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Increase number of MSs serviced by each PRP
Increase number of MSs serviced by each PRP
{28000} Each PRP board can support 120 MSs simultaneously when the prp_fanout_mode
= 1. The maximum number of timeslots per PRP board is 120 and each timeslot supports a
maximum of four MSs. When the prp_fanout_mode = 2, each PRP board can support 72 MSs
simultaneously. The maximum number of timeslots per PRP board is 48.
The number of MSs supported is currently fixed, regardless of the applications in use. Enhanced
scheduling takes the user application into consideration and changes the maximum number of
MSs supported, based on the type of traffic. The BSS only detects the TBFs and not the type of
MS traffic. The BSS estimates the type of application based on the amount of data the MS has to
transfer and on the length of the MS session.
One of the main aims of enhanced scheduling is to demonstrate higher numbers of MSs at any
given point and to increase the average number of MSs serviced per second. This increases
the overall system capacity and throughput.
The BSS can handle a combination of MSs in short and long GPRS sessions if the number of
MSs in short GPRS session plus three times the number of MSs in long GPRS session is less
than the maximum number of active MSs supported per PRP.
GPRS sessions
A mobile initiated GPRS session is measured from the point a GPRS one-phase MS RACH is
received by the network to the point the last TBF ends for that MS. For two-phase mobile
initiated transfer, the session is measured from the point PRR is received by the network to the
point the last TBF ends for that MS. If the network initiates a DL transfer (MS in idle state),
the session time is from the point the network sends the initial DL IA or initial PDA to the
point the last TBF ends for that MS.
Figure 6-28 shows an example of an MS initiated GPRS session of an MS doing a WAP transfer.
In this example, the MS GPRS session is considered from the time RACH is received by the
network all the way to T3192 expiry.
Figure 6-28 GPRS session-WAP transfer example
68P02901W36-S 6-47
Jul 2008
Performance enhancements under load Chapter 6: Call Processing
Short GPRS session
If an MS has been in a GPRS session for less than 0.7 seconds and the mobile has transferred 30
or fewer new data blocks (excluding any dummy blocks) in each (UL and DL) direction then that
MS is considered to be in a short GPRS session.
Long GPRS session
If an MS has been in a GPRS session for more than 0.7 seconds or has transferred more than
30 new data blocks (excluding any dummy blocks) in either (UL or DL) direction then that MS
is considered to be in a long GPRS session.
Performance enhancements under load
Performance enhancements under load introduces Delayed Downlink TBF Release (DDTR)
duration as a function of cell availability. This functionality is available only when the parameter
ddtr_ctrl_enabled is enabled. When cell availability is low, the DDTR functionality releases MS
TBFs with a long duration of delayed downlink TBF mode. This action decreases the probability
of blocking new MSs requesting access in a cell.
Performance enhancements under load features pro-active action to make room for future
MSs, enabling the ddtr_ctrl_enabled parameter could prevent the PRP from reaching the
maximum number of MSs on that board. However, it helps to increase the average number of
MSs serviced by the PRP per second by avoiding blocking future MSs.
The inc_prp_cap_ena parameter used to increase PRP capacity and the ddtr_ctrl_enabled
parameter used to enable DDTR functionality can only be enabled if the increased PRP capacity
option is unrestricted.
Percentage of RSL bandwidth reserved for circuit switched

traffic
A database parameter is added to allow control of the percentage of RSL capacity reserved for
circuit switched signaling traffic. A throttling mechanism is introduced to limit GPRS signaling
traffic to the RSL bandwidth not reserved for circuit switched signaling traffic. The UL IA, DL IA
and EOP establishment messages are throttled as part of GPRS signaling in the DL direction
and the GPRS RACHs are throttled as part of GPRS signaling in the UL direction.
6-48 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Extended Dynamic Allocation Medium Access (EDMAC) Mode
Extended Dynamic Allocation Medium Access (EDMAC)

Mode

{23292}
Overview
This is an optional feature for the network. In EDMAC mode, the mobile station monitors its
assigned PDCHs starting with the lowest numbered PDCH. Whenever the mobile station detects
an assigned Uplink Status Flag (USF) value on an assigned PDCH, the mobile station transmits
a single RLC/MAC block on the same PDCH and all higher numbered assigned PDCHs.
When a class 11 or 12 mobile requests an uplink TBF, the network assigns the EDMAC for the
uplink TBF if the mobile supports EDMAC and the TBF allocation requires EDMAC mode. The
network assigns the lowest numbered timeslot in the allocation as PACCH timeslot.
The PCU attempts to assign the maximum possible number of UL timeslots (3 for class 11 and
4 for class 12) to the mobile if gprs_ul_dl_bias is set to UL bias. During the uplink TBF in
EDMAC, the network schedules USFs in the lowest timeslot in the allocation, and the mobile
station transmits a single RLC/MAC block on the same PDCH and all higher numbered assigned
PDCHs. The PCU schedules periodic PUAKs for 3 or 4 UL TBFs frequent enough to prevent
stalling dependent on the number of uplink timeslots (3 or 4) used and GPRS or EGPRS TBF
mode. {26881} The RLC/MAC protocol is enhanced to keep UL TBF alive even if there are
no LLC PDU to transmit.
{26881}
NOTE
The ext_ul_dur parameter is used to set the maximum duration in block periods (1
bp = 20 ms) for which the UL TBF can operate in extended mode without getting
any new real RLC data block.
Dependency
This feature requires the GPRS feature to be unrestricted.
Related parameters and statistics
The parameters and statistics introduced by this feature are given below:
68P02901W36-S 6-49
Jul 2008
Related parameters and statistics Chapter 6: Call Processing
Parameters
The following parameter is introduced by this feature:
edaOpt - Indicates whether the Extended Dynamic Allocation (EDA) feature functionality is
unrestricted in the BSS software.
Statistics
The following statistics are introduced by this feature:

UL_RADIO_BLKS_8PSK_3_TS - Total number of RLC radio blocks received from EGPRS
mobiles that are capable of 8PSK on the uplink and support a maximum of 3 timeslots in
the uplink direction (mobile multislot classes 11).
UL_RADIO_BLKS_GMSK_3_TS - Total number of RLC radio blocks received from mobiles

that support a maximum of 3 timeslots in the uplink direction (mobile multislot classes
11) and are not capable of supporting 8PSK in the uplink.
UL_RADIO_BLKS_8PSK_4_TS - Total number of RLC radio blocks received from EGPRS

mobiles that are capable of 8PSK on the uplink and that support a maximum of 4 timeslots
in the uplink direction (mobile multislot classes 12).
UL_RADIO_BLKS_GMSK_4_TS - Total number of RLC radio blocks received from mobiles

that support a maximum of 4 timeslots in the uplink direction (mobile multislot classes
12) and are not capable of supporting 8PSK in the uplink.
UL_TBF_TIME_8PSK_3_TS - The time duration of the uplink TBFs for mobiles that
support a maximum of 3 timeslots and are capable of supporting 8PSK in the uplink
direction.
UL_TBF_TIME_GMSK_3_TS - The time duration of the uplink TBFs for mobiles that
support a maximum of 3 timeslots in the uplink direction and are not capable of supporting
8PSK in the uplink.
UL_TBF_TIME_8PSK_4_TS - The time duration of the uplink TBFs for mobiles that
support a maximum of 4 timeslots and are capable of supporting 8PSK in the uplink
direction.
UL_TBF_TIME_GMSK_4_TS - The time duration of the uplink TBFs for mobiles that
support a maximum of 4 timeslots in the uplink direction and are not capable of supporting
8PSK in the uplink.
6-50 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GPRS timeslot allocation
GPRS timeslot allocation

GPRS switchable timeslot function
The BSS supports reserved and switchable GPRS timeslots. A reserved GPRS Time Slot (TS) is a
timeslot that is used only for GPRS services. A switchable GPRS timeslot is a timeslot that can
be switched between GPRS service and circuit switched service. The BSS supports an operator
specified number of GPRS timeslots per cell and an operator specified number of reserved GPRS
timeslots per cell. The network operator specified number of reserved GPRS carriers per cell
(up to 5 TDMA frames) for GPRS packet data traffic handling capability.
Configuring switchable timeslots
The operator is offered two options to configure GPRS timeslots on multiple GPRS carriers
per cell:
Configure for performance.
Operator specified.
Configure for performance
Configure for performance provides the network with the capability to configure all the reserved
and switchable GPRS timeslots in a cell contiguously to maximize performance (minimum
contiguous timeslots = 2, maximum contiguous timeslots = 8). The contiguous GPRS timeslots
configured on a carrier in a cell provide ease in scheduling packet data and the capability
to service multiple timeslot GPRS mobiles.
Table 6-2 is an example of multiple GPRS carriers where the default option, configured for
performance, is specified. The GPRS resources are configured contiguously on GPRS carriers in
the cell to maximize performance. The cell has five GPRS carriers, ten reserved timeslots and
eleven switchable timeslots. The first row represents the BCCH carrier.
Table 6-2 Multiple GPRS carriers with default option specified
BCCH SDCCH RES RES RES RES RES RES
SW SW SW SW RES RES RES RES
TCH SW SW SW SW SW SW SW
TCH TCH TCH TCH TCH TCH TCH TCH
68P02901W36-S 6-51
Jul 2008
Reconfiguring switchable timeslots Chapter 6: Call Processing
Operator specified
The operator specified option provides customers with the flexibility to configure the maximum
and minimum GPRS timeslots on a per carrier basis in a cell. Table 6-3 is an example of
GPRS timeslots on a carrier per cell. The cell has five GPRS carriers, ten reserved timeslots
and eleven switchable timeslots. The max_gprs_ts_per_carrier element is set to 6. The first
row represents the BCCH carrier.
Table 6-3 GPRS timeslots distributed over cell carriers
TCH TCH SW SW RES RES RES RES
TCH TCH SW SW SW SW SW SW
TCH TCH TCH TCH TCH SW SW SW
Reconfiguring switchable timeslots
When a carrier that has GPRS timeslots goes out-of-service, GPRS timeslots will be reconfigured
on a different carrier that supports GPRS based on the radio resources available in the cell.
The BSS supports up to 30 GPRS timeslots in a cell, a maximum of eight of which can reside in
the same carrier. At initial configuration GPRS timeslots are configured as PDCHs. Switchable
(SW) GPRS timeslots can be reconfigured as SDCCHs. When a reserved (RES) timeslot is
reconfigured as an SDCCH timeslot and a GPRS switchable or a TCH timeslot becomes
available, the SDCCH is moved to the available timeslot, restoring the reserved timeslot.
The BSS will preferentially choose carriers with 16 k TRAU backing when configuring SDCCH
timeslots.
When the operator increases the requested number of switchable PDCH timeslots, the BSS
allows any circuit switched calls to end before reconfiguring the circuit switched timeslots
as GPRS timeslots.
If the TCH is in use and the operator by programmable parameter indicates that the BSS should
hand over circuit switched calls due to reconfiguration, the BSS attempts to hand over the call
before reconfiguring the TCH. If it is unable to handover the call, it waits until the call ends
before reconfiguring the timeslot. If all TCH timeslots on the GPRS carrier are in use, the
request is accepted and the reconfiguration proceeds after the calls on the respective timeslots
have been handed over or after the timeslot(s) are released. The configuration of the new
switchable PDCHs will continue where the prior configuration ended. If needed, a new carrier
will be found on which to configure the switchable PDCHs.
When the operator decreases the number of GPRS timeslots, the BSS terminates the packet flows
on those PDCHs and reconfigures them as TCHs. If the PDCH is in use, the BSS terminates the
downlink and uplink temporary block flows (TBFs) and immediately reconfigures them to TCHs.
6-52 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Dynamic switching
Dynamic switching
A switchable PDCH can be stolen anytime for use by a CS call except when the switchable PDCH
to be stolen is the last PDCH in the cell and the protect_last_ts parameter is invoked. When a
switchable PDCH needs to be stolen for use by a CS call and the switchable PDCH to be stolen is
the last PDCH in the cell, with the protect_last_ts on, the timeslot is stolen only if there is no
data transfer active or queued for the timeslot. If there are any reserved PDTCHs in the cell, the
switchable PDTCHs will not be protected from being stolen for use by circuit switched calls.
NOTE
When protect_last_ts is enabled, the last TS available cannot be occupied by a CS
call which is being handed-over to the cell.
The BSS supports dynamic switching between switchable PDTCHs and TCHs, either way.
Switchable GPRS timeslots are stolen starting with the lowest numbered GPRS timeslot on a
carrier in order to maintain continuous GPRS timeslots. The BSS selects the switchable GPRS
timeslots to be stolen as follows:
16 k carrier with the least number of available switchable GPRS timeslots (the carrier
does not contain reserved GPRS timeslots).
contains reserved GPRS timeslots).
does not contain reserved GPRS timeslots).
contains reserved GPRS timeslots).
Table 6-4 shows the order in which the timeslots would be stolen, this is shown by the numbers
in parentheses. (The first row represents the BCCH carrier).
Table 6-4 Timeslot stealing order
SW(18) SW(19) SW(20) SW(21) RES RES RES RES
TCH(10) SW(11) SW(12) SW(13) SW(14) SW(15) SW(16) SW(17)
TCH TCH(3) TCH(4) TCH(5) TCH(6) TCH(7) TCH(8) TCH(9)
TCH TCH TCH TCH TCH TCH TCH(1) TCH(2)
If the timeslot is in use by any GPRS mobiles, the PCU releases the timeslot and broadcasts
the release notification only on PACCHs where the mobiles are assigned. If this was the only
timeslot in use by the mobile and there is additional downlink data to send the MS, the BSS
sends a channel assignment message on the AGCH to start a new downlink transfer. If this
timeslot was the only uplink timeslot that the MS was using then the PCU relies on the MS
sending a new RACH in order to start a new transfer.
68P02901W36-S 6-53
Jul 2008
Reconfiguration of GPRS in a cell Chapter 6: Call Processing
If the number of idle TCHs is greater than that set by the database parameter gprs_recon-
fig_thresh_idle_tch and the operator settable parameter intra_cell_handover_allowed is
set, the BSS hands over a CS call which is on a stolen switchable PDCH to an idle TCH and
reconfigures the stolen timeslot back to a switchable PDCH.
When a circuit switched call ends on a stolen switchable PDCH timeslot, the BSS only
reconfigures the stolen timeslot back to a switchable PDCH if the number of idle TCHs is greater
than that set by the parameter gprs_reconfig_thresh_idle_tch.
When the option_emergency_preempt is set to enabled, regardless of the setting of the

protect_last_ts BSS database parameter (enabled or disabled), the BSS is able to steal the last
switchable PDCH in a cell for an emergency call without checking if there is data transfer
active or queued for the timeslot.
Reconfiguration of GPRS in a cell
A performance algorithm can be specified by the pkt_radio_type parameter to enable the BSS
to attempt to reconfigure GPRS timeslots contiguously on GPRS capable carriers in the cell. The
database parameter also determines whether the BCCH carrier can be used for packet data.
Example 1
When the first carrier in a GPRS cell goes Out-Of-Service (OOS), GPRS timeslots will be
redistributed and reconfigured among the remaining carriers in the cell based on the values in
the database parameters sw_ts_less_one_carrier and res_ts_less_one_carrier.
The reconfiguration after one carrier goes OOS will give priority to the configuration of RES
PDCH timeslots (just as during initial configuration of GPRS in a cell).
Example 2
Table 6-5 shows a five carrier cell configuration using the performance algorithm with the
following parameters. (The first row represents the BCCH carrier).
res_gprs_pdchs=10
switch_gprs_pdchs=15
pkt_radio_type=0
Table 6-5 Carrier cell configuration
BCCH SDCCH TCH TCH TCH TCH TCH TCH
RES RES RES RES RES RES RES RES
SW SW SW SW SW SW RES RES
TCH SW SW SW SW SW SW SW
TCH TCH TCH TCH TCH TCH SW SW
6-54 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Reconfiguration of GPRS in a cell
If the second non-BCCH GPRS carrier goes out-of-service in this configuration,

sw_ts_less_one_cr=15 and res_ts_less_one_cr = 5, GPRS timeslots configured in the cell will
be as shown in Table 6-6.
Table 6-6 Second non-BCCH carrier OOS
BCCH SDCCH TCH TCH TCH TCH TCH TCH
SW SW SW RES RES RES RES RES
OOS
SW SW SW SW SW SW SW SW
TCH TCH TCH TCH SW SW SW SW
NOTE
The value of sw_ts_less_one_carrier can be less than, greater than, or equal to the
value of switch_gprs_pdchs. The value res_ts_less_one_carrier can be less than,
greater than, or equal to the value of res_gprs_pdchs.
Each time a carrier goes out-of-service in a cell, the number of reserved timeslots will decrease
by:
dres = res_gprs_pdchs-res_ts_less_one_carrier = 5
and the number of switchable timeslots will decrease by:
dswitch = switch_gprs_pdchs-sw_ts_less_one_carrier = 0
Example 3
Refer to Table 6-7 for carrier to PDCH ratio
res_gprs_pdchs = 10, res_ts_less_one carrier = 5, ratio = 0.5
switch_gprs_pdchs = 15, sw_ts_less_one_carrier = 10, ratio = 0.666
Number of carrier is the cell at initialization = 5
Table 6-7 Ratio of INS carriers to PDCHs
Reserved PDCHs
Number of carriers INS Switchable PDCHs configured
configured
5 10 15
4 5 10
3 2 6
2 1 3
1 0 2
68P02901W36-S 6-55
Jul 2008
PBCCH or PCCCH timeslot allocation Chapter 6: Call Processing
Emergency calls
If the BSS needs to use the last GPRS timeslot in the cell (reserved or switchable) for an
emergency call, it reconfigures the timeslot for the emergency call without waiting for the
GPRS data traffic to end.
The BSS can reconfigure any GPRS timeslot to carry emergency calls. If an emergency call is
made at a cell with a GPRS carrier and the Emergency Call Preemption feature is enabled, the
BSS selects the air timeslot that can carry it from the following list (in order of preference):
Idle TCH.
Switchable GPRS timeslot (from lowest to highest).
In use TCH.
Reserved GPRS timeslot (from lowest to highest).
A non-BCCH carrier can be chosen for GPRS, or the BCCH carrier can be used. If the BCCH
carrier is chosen to support GPRS then the number of timeslots (up to seven) that can be used
for GPRS depends on the number of SDCCHs on that carrier and the database parameter
ccch_conf. The parameter ccch_conf defines the organization of the CCCHs on the BCCH. If a
non-BCCH carrier is chosen then up to eight slots are configured for GPRS based upon other
unrestricted features that affect the configuration.
PBCCH or PCCCH timeslot allocation
The BSS supports only standard GPRS Network Operation Modes II and III on a PCU.
GPRS Network Operation Mode II and III are the same on the Common Control Channel
(CCCH). GPRS Network Operation Mode II is not applicable on a Packet Common Control
Channel (PCCCH) and is therefore not implemented. GPRS Network Operation Mode III is
applicable for both CCCH and PCCCH.
The BSS supports one Packet Broadcast Control Channel (PBCCH) or PCCCH timeslot per
cell, configured on the BCCH carrier.
The PBCCH or PCCCH feature can be enabled for a cell only if the BCCH carrier of the cell is
non-hopping. The first available PDCH timeslot, that contains the PBCCH or PCCCH timeslot, is
always reserved, when PBCCH or PCCCH is enabled for a cell.
The BSS maintains at least one reserved PDCH timeslot when the BSS updates the total number
of reserved GPRS timeslots according to linear scaling of GPRS timeslots on the loss of a carrier
in a GPRS cell with PBCCH or PCCCH enabled.
PBCCH or PCCCH timeslots are configured on the BCCH carrier in the list of timeslots defined
as TS1, TS2, TS3 and TS4 based on the ccch_conf settings, so that the PBCCH description can
be included in neighbor cell description list.
The list for the PBCCH or PCCCH timeslot can be changed upon the value of ccch_conf
element as follows:
6-56 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation PBCCH or PCCCH timeslot allocation
Table 6-8 PBCCH or PCCCH and ccch_conf parameter
ccch_conf parameter PBCCH or PCCCH list of timeslots

0 TS1, TS2, TS3, TS4
1 TS1, TS2, TS3, TS4
2 TS1, TS3, TS4
4 or 6 TS1, TS3
The BSS reconfigures a PBCCH or PCCCH timeslot to another timeslot in the list on the same
carrier in the following situations:
The current PBCCH or PCCCH timeslot is Out-Of-Service (OOS).
The current PBCCH or PCCCH timeslot is out of synchronization for more than two seconds.
If the Emergency Call Preemption feature is unrestricted, the BSS selects the air interface
timeslot to carry the emergency call, from the following list: (most preferable listed first):
Idle TCH.
Switchable PDCH.
In-use TCH or stolen switchable PDCH (based on priority of non-emergency calls).
Reserved PDCH.
PBCCH or PCCCH timeslot.
The BSS always follows the SDCCH placement rule including the settings of the sd_priority
and sd_load parameters. See Technical Description: BSS Command Reference (68P02901W23)
manual for these parameters. If SDCCH is in the PBCCH capable timeslot list and the SDCCH
timeslot needs to be configured as the PBCCH timeslot, the SDCCH can only be moved to the
carrier if it has the same sd_priority and the number of SDCCH timeslots on that carrier
does not exceed the sd_load value.
The BSS unbars GPRS service for a cell with PBCCH or PCCCH enabled, only if the PBCCH or
PCCCH timeslot is active in that cell.
The BSS takes into account the load of the PBCCH or PCCCH timeslot when allocating resources
for MS on uplink and downlink. The PBCCH or PCCCH timeslot load is adjusted such that no
more than two MSs can be scheduled for data transfer on the PBCCH or PCCCH timeslot.
The BSS disables enhanced one-phase functionality if PBCCH or PCCCH is enabled in the cell,
regardless of the setting of the eop_enabled parameter.
The BSS accepts and processes uplink requests on the CCCH in a GPRS cell with PBCCH
or PCCCH enabled.
The BSS sends a network_control_order message to the MS to RESET the Network Control
(NC) parameters that were received from a packet measurement order from the BSS, if there is
any change in any NC parameter (that is, network_control_order, nc_reporting_period, or
nc_reporting_period_t). See Technical Description: BSS Command Reference (68P02901W23)
manual for these parameters.
The BSS will support the RESET value of network_control_order on the PACCH or PCCCH.
The BSS will support the RESET value of network_control_order only in the Packet Measurement
Order message.
68P02901W36-S 6-57
Jul 2008
PBCCH or PCCCH air interface Chapter 6: Call Processing
PBCCH or PCCCH air interface
PBCCH requirements
The BSS supports only Normal Paging mode on the PBCCH and the PCCCH.
The BSS indicates the presence of a PBCCH in a SI13 message on the BCCH and includes
the optional SGSNR. If the PBCCH or PCCCH feature becomes restricted, the SI13 message
is sent without the PBCCH description. The BSS sends a SI5ter message to the dedicated
MSs if PBCCH or PCCCH is enabled.
When an MS moves from PBCCH or PCCCH to BCCH or CCCH during CS call establishment,
the MS does not have any early class mark information for the multiband serving cell. The BSS
includes the persistence_level in the following messages:
Packet Downlink Assignment
Packet Downlink Dummy Control Block
Packet Paging Request
Packet Uplink Assignment
PSI 1 messages if PBCCH or PCCCH timeslot is used for the data transfer
The Packet System Information (PSI) messages are not segmented across more than one RLC or
MAC control block. Only PBCCH blocks are used for scheduling PSI messages.
The PSI1 message is supported on the PBCCH is shown in Procedure 6-1.
Procedure 6-1 PSI1 message supporting the PBCCH
1 The sending of PSI 1 on the PACCH to all mobiles in packet transfer mode
such that the mobiles receive PSI 1 at least once every 8 seconds.
2 The BSS determines psi1_repeat_period based on either the
psi1_repeat_period parameter, or the number of PBCCH blocks per
multiframe (bs_pbcch_blks) and the number of PSI messages including all
the instances.
3 The BSS changes the pbcch_change_mark field in the PSI1 message if there
is a change in any PSI messages except PSI1 itself. The following optional
parameters are supported by the BSS in PSI1:
MSCR
SGSNR
persistence_level
Table 6-9 shows the restrictions for the PSI1 message parameters.
6-58 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation PBCCH or PCCCH air interface
Table 6-9 PSI1 message parameter restrictions
Parameter name Parameter definition

CONTROL_ACK_TYPE Four access bursts.
INT_MEAS_CHANNEL_LIST_AVAIL PSI4 message not broadcast.

Set to 0-always transmit at same output power on
Pb
BCCH regardless of PBCCH location on carrier.
ACC_CONTR_CLASS Access Control Class for all 16 classes are unbarred.
BS_PCC_REL No Channel Release (last PDCH carrying PBCCH and
PCCCH) is pending.
PSI_STATUS_INDICATION The Network does not support the PACKET PSI
STATUS message.
The following optional parameters are supported by the BSS in PSI2 on the PBCCH:
Cell Identification IE: only in the first instance.
Non-GPRS Cell Options IE: only in the first instance.
Additional PSI messages.
ECSC.
3G ECSR.

NON_GSM_INFORMATION Not broadcast on the cell.
PSI8_BROADCAST Broadcast on the cell if cbch_enabled is set to 1-Enabled.
PSI3ter_BROADCAST Not broadcast on the cell.
PSI3quater_BROADCAST Broadcast on the cell if inter_rat_enabled is set to
1-Enabled.
GPRS Mobile Allocations Empty.
3G ECSR Neither UTRAN nor cdma2000 classmark change
message is sent with the Early Classmark Sending.
The following optional parameters are supported by the BSS in PSI3 on the PBCCH:
HCS Serving Cell Parameters.
HCS Neighbor Cell Parameters.
gprs_rxlev_access_min (for neighbor cells).
gprs_ms_txpwr_max_cch (for neighbor cells).
gprs_penalty_time (for neighbor cells).
68P02901W36-S 6-59
Jul 2008
ra_reselect_hysteresis.
gprs_temporary_offset.
gprs_reselect_offset.
SI13 PBCCH Location-if PBCCH or PCCCH feature unrestricted.

CELL_BAR_QUALIFY_2 Voice supported, cell bar indication active.
CELL_BAR_ACCESS_2 Status for cell reselection set to normal.
EXC_ACC Cell not used for Subscription of Localised Service Area (SoLSA)
exclusive access.
The following optional parameters are supported by the BSS in PSI3bis:

HCS Neighbor Cell Parameters.
gprs_rxlev_access_min (for neighbor cells).
gprs_ms_txpwr_max_cch (for neighbor cells).
gprs_penalty_time (for neighbor cells).
ra_reselect_hysteresis.
gprs_temporary_offset.
gprs_reselect_offset.
SI13 PBCCH Location-if PBCCH or PCCCH feature unrestricted.
Table 6-12 shows the restrictions for the PSI3bis message parameters.
Table 6-12 PSI3bis message parameter restrictions

Neighbor Cell parameters 2 Not supported.
CELL_BAR_ACCESS_2 Status for cell reselection set to normal.
EXC_ACC Cell not used for Subscription of Localised Service Area
(SoLSA) exclusive access.
6-60 68P02901W36-S
Jul 2008
The following optional parameters are supported by the BSS in PSI3quater:

3G Neighbor Cells Description
fdd_arfcn.
3G Measurement Parameters Description

fdd_gprs_qoffset.
fdd_qmin.
The following optional parameters are supported by the BSS in PSI5 on the PBCCH if
nccr_enabled is set to 1 and network_control_order is one of NC1, ENC1 or NC2:
3G Neighbor Cells Description

fdd_arfcn.
The following optional parameters are supported by the BSS in PSI5:
NG Measurement Parameters
nc_non_drx_period.
nc_reporting_period_i.
nc_reporting_period_t.
The BSS supports PSI8 if cbch_enabled is set to 1-Enabled.
The BSS supports PSI1 message on the PBCCH as follows:

PSI1 must be sent in block B0 when TC = 0.
If the value of is greater than 1, the PSI1 is also sent in block 6 when TC = 0.
Where: Is:
TC (FN DIV 52) mod
PSI1_REPEAT_PERIOD
The BSS schedules PSI1 on PBCCH before scheduling other PSI messages.
The BSS supports the sending of all other PSI messages except PSI1 on the PBCCH with low
repetition rate. The BSS sends the other PSI messages except for PSI1 in a sequence and
continuously repeats using the PBCCH blocks, which are not occupied by PSI1 message, within
each multiframe.
The BSS supports the sending of PSI13 messages without a PBCCH description on the PACCH
to all the MSs in packet transfer mode, if and when the PBCCH or PCCCH feature becomes
restricted.
The BSS supports the optional SGSNR information element on PSI13. If a PSI message has
multiple instances, the BSS schedules the PSI instances in the same group of PSI messages and
sends them in a single sequence in ascending order of the message instance number.
68P02901W36-S 6-61
Jul 2008
The BSS schedules the same PSI message only once within a group of PSI messages. The BSS
applies the changes on PSI messages, except for a PSI1 message in a group, when the group is
restarted because any of the following change:
The number of PSI messages in a group.
The order of these PSI messages in a group.
The content of these PSI messages.
PCCCH requirements
The BSS uses PCCCH blocks for user data if the PCCCH blocks are available.
The BSS supports only 11-bit format packet channel request on the PRACH and indicates
the blocks used for PRACH blocks by including USF = FREE in the previous downlink block.
Static allocation of PRACH blocks is supported.
The blocks used for static allocation of PRACH blocks follows the ordered list of blocks defined
as B0, B6, B3, B9, B1, B7, B4, B10, B2, B8, B5, B11. The static allocation of blocks used for
PRACH blocks depends on the value of the bs_prach_blks parameter as follows:
Table 6-13 bs_prach_blks PRACH mapping
bs_prach_blks PBCCH or PCCCH list of timeslots

1 B0
2 B0, B6
3 B0, B3, B6
4 B0, B3, B6, B9
5 B0, B1, B3, B6, B9
6 B0, B1, B3, B6, B7, B9
7 B0, B1, B3, B4, B6, B7, B9
8 B0, B1, B3, B4, B6, B7, B9, B10
9 B0, B1, B3, B4, B6, B7, B8, B9, B10
10 B0, B1, B2, B3, B4, B6, B7, B8, B9, B10
11 B0, B1, B2, B3, B4, B5, B6, B7, B8, B9, B10
12 B0, B1, B2, B3, B4, B5, B6, B7, B8, B9, B10, B11
See Technical Description: BSS Command Reference (68P02901W23) manual for the
bs_prach_blks parameter.
The BSS supports dynamic allocation of PRACH blocks. The blocks used for dynamic allocation
of PRACH blocks are the blocks that are not used by an uplink data block or an RLC or MAC
control message and are not part of the PRACH static allocation.
Table 6-14 shows Packet Uplink Assignment (PUA) types in response to a Packet Channel
Request.
6-62 68P02901W36-S
Jul 2008
Table 6-14 Packet Uplink Assignment (PUA) access types

One-phase access request PUA with dynamic allocation.
Short access request PUA with dynamic allocation.
Two-phase access request PUA with single block allocation.
Page response PUA with dynamic allocation.
Cell update PUA with dynamic allocation.
MM procedure PUA with dynamic allocation.
Single block without TBF establishment PUA with single block allocation.
The BSS treats the multi-slot class from the Packet Channel Request as one-phase access
request when allocating resources. If the multi-slot class of a mobile cannot be directly
supported, the multi-slot class is remapped to another multi-slot class.
If the supported multi-slot class indicates that the MS supports multiple uplink timeslots, the
BSS attempts to allocate the uplink allocation with multiple timeslots. However, in a highly
loaded system, the BSS allocates the uplink allocation with only one timeslot.
Except for one-phase access, the BSS treats the MS as gprs_common_ms_class, if multi-slot
class is not included in the Packet Channel Request for other access types, as shown in
Table 6-14.
In response to a Packet Channel Request message, the BSS includes the same packet request
reference as received in the corresponding Packet Channel Request message in the Packet
Uplink Assignment message. The BSS ignores a Packet Channel Request if the access type of
the Packet Channel Request message is unknown.
The BSS supports scheduling on the Packet Paging Channel (PPCH) is described in
Procedure 6-2.
Procedure 6-2 BSS supports scheduling on PPCH
1 PS/CS paging message and RLC or MAC control message.

2 Downlink data block.
CS/PS paging and RLC or MAC control message targeted for a GPRS mobile are scheduled on
paging blocks of the PPCH if the targeted mobile is in DRX mode and on any available blocks on
the PAGCH or PPCH if the targeted mobile is in non-DRX mode. At least one CS or PS page is
included per Packet Paging Request message.
CS/PS paging messages are scheduled on the paging channels based upon the GPRS network
operation mode as shown in Table 6-15 and Table 6-16:
68P02901W36-S 6-63
Jul 2008
Table 6-15 Paging in GPRS Operation Modes I and III (BCCH or CCCH)
Network Operation Network Operation

Cell Message
Mode I Mode III
GPRS-attached MS in CS-paging CCCH paging channel CCCH paging channel
packet idle mode
PS-paging CCCH paging channel CCCH paging channel
GPRS-attached MS in CS-paging PACCH CCCH paging channel
packet transfer mode
PS-paging Not applicable Not applicable
Table 6-16 Paging in GPRS Operation Modes I and III (PBCCH or PCCCH)
Network Operation Network Operation

Cell Message
Mode I Mode III
GPRS-attached MS in CS-paging PCCCH paging CCCH paging channel
packet idle mode channel
PS-paging PCCCH paging PCCCH paging
channel channel
GPRS-attached MS in CS-paging PACCH CCCH paging channel
GPRS-attached MS in PS-paging Not applicable Not applicable
A Packet Downlink Dummy Control Block message is scheduled on a PPCH/PAGCH if there is no

CS/PS paging message, RLC or MAC control message, or downlink data block to be sent on the
PPCH/PAGCH. The BSS supports Packet Downlink Assignment procedure on PAGCH/PPCH.
6-64 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation EGPRS terrestrial resources
EGPRS terrestrial resources

64 kbps terrestrial channels (BSC-BTS & PCU-BSC)
The BSS supports a 64 kbps terrestrial timeslot per air timeslot for use as a TRAU data channel
on BSC-BTS links to support the backhaul required for EGPRS coding schemes MCS1-MCS9.
The BSS supports a 64 kbps terrestrial timeslot per air timeslot for use as a TRAU data channel
on PCU-BSC links to support the backhaul required for EGPRS coding schemes MCS1 through
MCS9.
The BSS allocates all of the E1 timeslots required for an RTF to a single MMS and does not
split them between multiple E1s on the BSC to BTS interface.
The 64 kbps timeslot on the terrestrial resources must be a single, complete DS0 and not simply
a group of four adjacent 16 kbps subrate timeslots to ensure uniform delay of the TRAU data
bits and allow handling of the channel as an octet within the PMC NIB and the channel coder.
The BSS configures 64 kbps terrestrial resources for all eight air timeslots from the BTS to the
BSC when 64 kbps TRAU is enabled on a non-BCCH RTF.
The BSS configures 64 kbps terrestrial resources for seven air timeslots from the BTS to the
BSC when 64 kbps TRAU is enabled on a BCCH RTF. Only seven DS0s of backhaul need to
be allocated because when an RTF is configured to be a BCCH RTF and 64 kbps terrestrial
resources are configured, the BCCH timeslot does not need backhaul assigned on the MMS
between the BTS and BSC.
The TRAU interface between the channel coder and the PCU is implemented using 64 kbps
channels. The PCU supports the 64 kbps TRAU time alignment procedure. The BSS supports
the sending and receipt of the cell, carrier and timeslot numbers in the sync frames of the 64
kbps TRAU channels plus the sending and receipt of the Electronic Identification number from
the channel coder to the PCU in the sync frames of the 64 kbps TRAU channels.
When a 64 kbps PDCH is reconfigured for use as a full-rate circuit switched voice channel, the
voice is carried over sub rate group 0 of the 64 kbps terrestrial timeslot and all other sub
rates are idled on the BSC to BTS interface.
When a 64 kbps PDCH is reconfigured for use for a pair of half-rate circuit switched voice
channels, the voice is carried over sub rate group 0 for sub channel 0 and 1 for sub channel 1 of
the 64 kbps terrestrial timeslot and all other sub rates is idled on the BSC to BTS interface.
When PDCHs are reconfigured as circuit switched voice channels, the unused backhaul is
not removed. Later, when the channel can again be configured as a PDCH the backhaul does
not have to be re-allocated.
The BSS rejects the equipage of an RTF if the number of terrestrial timeslots required by the
RTF between the BSC and the BTS exceeds the number of free terrestrial timeslots between
the BSC and the BTS.
During the equipage of an RTF, the number of terrestrial timeslots (DS0s) required on the link
between the BSC and the BTS is evaluated to ensure that there is enough bandwidth on the
BSC-BTS interface to support the required backhaul for all the air timeslots.
68P02901W36-S 6-65
Jul 2008
64 kbps terrestrial channels (BSC-BTS & PCU-BSC) Chapter 6: Call Processing
On the PMC NIB, the BSS supports an arbitrary mixture of 124-16 kbps TRAU, 62-32 kbps TRAU
and 62-64 kbps TRAU such that the following equation is satisfied: #16 kbps TS + 2#32
kbps TS + 2#64 kbps TS <= 124.
The PMC NIB has sufficient CPU capacity to support a 12416 kbps TRAU or one full span.
Since 32 kbps TRAU is actually composed of two 16 kbps TRAU channels, the PMC NIB can
support half as many 32 kbps TRAU, or one full span. With the dibit insert/extraction removed in
the 64 kbps TRAU, the PMC NIB can do twice as much bandwidth, which is 62 of the 64 kbps
TRAU channels, or two full spans of 64 kbps TRAU. The PMC NIB can support an arbitrary mix
of 16 kbps and 64 kbps TRAU channels, or channels with dibit insertion or extraction and those
without, trading off at a ratio of two 16 kbps timeslots to one 64 kbps timeslot. Note that when
mixed traffic is used, the two spans on the PMC NIB are not both fully utilized.
The PRP DPROC supports a maximum of 120 TRAU timeslots or any combination of 16 kbps
TRAU, 32 kbps TRAU and 64 kbps TRAU.
The BSS implements 64 kbps TRAU as defined in the PCU CCU Interface Design Specification.
See also VersaTRAU on page 3-30.
EGPRS DRI-RTF Assignment Requirements
The BSS supports the receipt of Bit Error Probability (BEP) and Coefficient of Variance in BEP
from the channel coders on the PCU CCU interface.
The BSS preferentially maps EGPRS RTFs onto single-density CTU2 radios.
If an RTF equipped with 64 kbps backhaul is mapped to a DRI unable to support EGPRS, the
carrier will be configured to support GSM voice only.
The BSS reclaims DRIs for 64 k BCCH RTF is described in Procedure 6-3.
Procedure 6-3 DRIs for 64 k BCCH RTF
1 Single-density CTU2 not implementing any RTF.

2 Dual-density CTU2 not implementing any RTF.
3 Non CTU2 not implementing any RTF.
4 Single density non-EGPRS CTU2.
5 Dual-density CTU2.
6 Single-density EGPRS CTU2.
7 Non CTU.
Non CTU2 DRIs reclaim DRIs for 16 k/32 k BCCH RTF is described in Procedure 6-4:
6-66 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation 64 kbps terrestrial channels (BSC-BTS & PCU-BSC)
Procedure 6-4 DRIs for 16 k/32 k BCCH RTF
1 Dual-density CTU2 not implementing any RTF.

2 Single-density CTU2 not implementing any RTF.
3 DRI without an assigned RTF.
4 Dual-density CTU2.
5 Single-density CTU2.
6 Single density non-EGPRS CTU2.
7 Non CTU2.
When the RTF to DRI mapping is performed, the RTFs equipped for EGPRS are mapped to
single-density equipped CTU2 radios if possible. If no single-density CTU2s are available and
other DRI hardware is available, the EGPRS RTF will be mapped to that other DRI. When such a
mapping occurs, the carrier will only be capable of GSM voice.
Due to the importance of the BCCH carrier, the BCCH is remapped onto an available DRI, even
if that DRI is unable to support EGPRS. In the event that the BCCH RTF is remapped onto a DRI
that cannot support EGPRS, the carrier will only be able to support GSM voice calls.
If the BCCH RTF is configured for EGPRS and there is only one single-density CTU2 available,
the BCCH RTF will be mapped onto that CTU2, since EGPRS service and EGPRS one-phase
access would still be available. However, if the BCCH RTF is not configured with 64 kbps
terrestrial backing and there is only one CTU2 available, the BCCH will be moved to a non-CTU2
radio, since maintaining EGPRS in general would be more important than EGPRS one-phase
access.
If an RTF equipped with 64 kbps backhaul is mapped to a DRI unable to support EGPRS, it is
not taken OOS if single-density CTU2s later become available.
This feature does not attempt to preemptively bring carriers OOS simply to keep EGPRS service
available. If, due to hardware failures or operator intervention, EGPRS-capable RTFs get
assigned to non-EGPRS-capable DRIs, those RTFs remain assigned to the non-EGPRS-capable
DRIs, even if EGPRS-capable radios are later made available for use.
In order to restore EGPRS service, the DRI supporting the EGPRS-capable RTF will need to be
locked (that is ins' or lock' commands at the MMI).
The BSS preferentially maps 64 kbps BCCH RTFs onto single-density CTU2 radios before any
other carriers are assigned.
At initialization the BSS preferentially maps non-EGPRS carriers onto non-CTU2 hardware /
dual-density-equipped CTU2 hardware.
Also, at initialization the BSS loads up non-CTU2 hardware with 16 k/32 k carriers as much
as possible. Thus, the software will attempt to assign EGPRS carriers onto EGPRS-capable
hardware first and then assign carriers to the rest of the hardware in its usual fashion.
Additionally, in order to maintain one-phase access, if the BCCH carrier is equipped to be

EGPRS-capable, the BCCH should always move to a single-density CTU2 if one is available.
Otherwise, the BCCH RTF will move to the first available carrier.
68P02901W36-S 6-67
Jul 2008
Air interface packet data transfer Chapter 6: Call Processing
Air interface packet data transfer

Air interface transmission layers
The Radio Link Control/Medium Access Control (RLC or MAC) layers provide services for
information transfer over the physical layer of the GPRS interface. These functions include
backward error correction procedures that are enabled by selective retransmission of erroneous
blocks of data. The MAC function arbitrates access to the shared medium between a multitude
of MSs and the GPRS network.
The RLC function processes the transfer of Protocol Data Units (PDUs) from the LLC layer.
The MAC function segments and reassembles the LLC PDUs into/from RLC data blocks and
provides the backward error correction function.
Radio link control layer
The input to the Radio Link Control (RLC) from the BSSGP is known as an LLC Protocol Data
Unit (PDU) of up to 1520 octets of data and routing information. The RLC segments this into
RLC data blocks as shown in Figure 6-29 and Figure 6-30. As the figures show, the RLC data
block consists of an RLC header and RLC data with some spare bits. Each RLC data block
can be encoded using either the GPRS channel Coding Schemes (CSs) or the EGPRS channel
Coding Schemes (MCSs). See Coding Schemes later in this chapter. This affects the degree
of segmentation and subsequent reassembly. RLC data blocks are sequentially filled with
consecutive LLC PDU segments until the last one is reached in the current transmission block.
If there is space in the current RLC data block, it is completed by the insertion of spare bits.
The structure of the RLC data block is different for uplink or downlink transmission, as shown in
Figure 6-29, Figure 6-30, Figure 6-31 and Figure 6-32.
6-68 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Radio link control layer
GPRS Uplink RLC data block
Figure 6-29 Uplink RLC data block
.
.
.
.
.
.
68P02901W36-S 6-69
Jul 2008
Radio link control layer Chapter 6: Call Processing
GPRS Downlink RLC data block
Figure 6-30 Downlink RLC data block
6-70 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Radio link control layer
EGPRS Uplink RLC data block
Figure 6-31 Uplink RLC data block
2 1
E
8 7 6 5 4 3 2 1
E Octet 1(optional)
. .
. .
. .
E
\
Octet M+2 } (optional)
/
/
E
.
.
.
-1
68P02901W36-S 6-71
Jul 2008
Radio link control layer Chapter 6: Call Processing
EGPRS downlink RLC data block
Figure 6-32 Downlink RLC data block
Bit
2 1
FBI E
Bit
8 7 6 5 4 3 2 1
Length indicator E
. .
. .
. .
Length indicator E
.
RLC data .
.
-1
ti-G
SM-EGPRS DL RL
C da
tablock-0
0240-ai-s
w
RLC data block fields
The RLC data block fields are as follows:

TFI-Temporary Flow Identifier-identifies the TBF to which the RLC data block belongs. The
TFI is five bits long encoded as a binary value ranging from 0 to 31.
TI-Temporary Logical Link Identifier (TLLI) Indicator-indicates the presence of the optional
TLLI field within the RLC data blocks:
0-TLLI field not present.
1-TLLI field present.
BSN-Block Sequence Number-the absolute sequence number of the RLC data block within
the TBF. The BSN is seven bits long encoded as a decimal value 0 to 127.
E-Extension-indicates the presence of an optional octet in the RLC data block:

0-Extension octet follows.
1-No Extension octet follows.
Length indicator (LI)-delimits LLC PDUs within the RLC data block, when an LLC PDU
boundary occurs in the block. The first LI indicates the number of octets of the RLC data
field that belongs to the first LLC PDU. The second LI indicates the number of octets of
the RLC data field that belongs to the second LLC PDU, and so on. M indicates that there
are more PDUs in the data block.
6-72 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Acknowledged/unacknowledged modes
M-More octets, see LI above.
TLLI-Temporary Logical Link Identifier-the logical link from which the RLC data block was
received. Optional and sent only on the uplink. Included in every uplink RLC data block
until a successful acknowledgment has been received from the network.
FBI Final Block Indicator Indicates whether this RLC data block is the final block of
a DL TBF.
0 Current block is not last RLC data block in TBF.
1 Current block is last RLC data block in TBF.
PFI Packet Flow Identifier Identifies Packet Flow Context for an Aggregate BSS QoS
Profile negotiated between mobile and the network. Optional and sent only on the uplink.
PI PFI Indicator Indicates the presence of the optional PFI field within the uplink RLC
data blocks.
Acknowledged/unacknowledged modes
The RLC in the BSS and the corresponding RLC in the MS control the acknowledgment (ACKs)
and no-acknowledgment (NACKs) on which retransmission of unreceived blocks depends.
Acknowledged mode
The Block Sequence Number (BSN) provides a modulo numbering scheme (7 bits) for the RLC
data blocks within one TBF. From this is derived the maximum threshold of 64 blocks before
an ACK is solicited. Every ACK message acknowledges the number of blocks sent since the
last ACK was sent. When all blocks within a TBF have been sent, a final ACK is sent. The
MS maintains a C block bit map of ACKnowledged blocks and sends this up to the BTS in the
PDTCH. Holes in this bit map inform the BTS which blocks were not received and these are
immediately retransmitted.
Unacknowledged mode
The transfer of RLC data blocks in the unacknowledged RLC or MAC mode is controlled by the
same modulo numbering scheme (7 bits) for the RLC blocks within one TBF, but there are no
retransmissions. The MS extracts user data from the received data blocks and attempts to
preserve the user information by replacing missing RLC data with dummy information bits.
Medium access control layer
The input to the Medium Access Control (MAC) layer is the RLC data block from the RLC. The
main function of the MAC layer is the control of multiple MSs sharing a common resource on the
GPRS air interface. At the MAC layer a MAC header is added as shown in Figure 6-33.
The structure of the MAC header is different for uplink or downlink transmission, as shown
in Figure 6-33.
68P02901W36-S 6-73
Jul 2008
Medium access control layer Chapter 6: Call Processing
Figure 6-33 RLC or MAC block structures
MAC layer fields
The MAC layer fields are as follows:

R-Retry bit, when no acknowledgment has been received.
SI-Stall indicator-signals indicating that the transmission has failed.
Countdown value-Sent by the MS to the BSS so that it can calculate the number of radio
blocks remaining in the current uplink allocation of resources. This ensures a smooth
transfer to the next MS.
Payload type-the type of information in the payload area, that is, data or signaling.
USF-Uplink State Flag-identifies the MS to which the GPRS resource is allocated.
S/P-Supplementary Polling bit-indicates whether the RRBP field is active.
RRBP-Relative Reserved Block Period-specifies that a single uplink block is being used as
an Associated Control Channel (ACCH).
Assuming that the MS is in the GPRS Ready state, that is, the GPRS Attach has been successful
and a PDP context has been activated (PRACH has been acknowledged), the RLC or MAC blocks
can be passed down to the physical layer for transmission to the MS device.
6-74 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation EGPRS RLC or MAC signaling
At initiation on an uplink packet transfer, the BSS accepts either a PRACH or a RACH. The BSS
responds with a packet immediate assignment message reserving the resources on PDCHs used
for uplink transfer of a number of radio blocks. The RSS in the BTS forwards the requirement to
the packet scheduler in the PCU. The data transfer process can then start. This is described in
the Physical Layer section of this chapter.
EGPRS RLC or MAC signaling
For EGPRS, the following information details changes to the RLC or MAC headers.
The following table identifies the type of RLC or MAC Header used for uplink and downlink
data blocks.
Table 6-17 RLC or MAC Header Types
MCS# Uplink Downlink

MCS1 3 3
MCS2 3 3
MCS3 3 3
MCS4 3 3
MCS5 2 2
MCS6 2 2
MCS7 1 1
MCS8 1 1
MCS9 1 1
The BSS sets the Split Block indicator field to 0 0 to indicate no retransmission in split block
format in the RLC or MAC header type 3 and uses the Resent Block bit received in the RLC
uplink header indicating the component RLC blocks within the radio block are retransmissions.
If the BSS receives an RLC data block with BSN less than V(Q) but within the receive state
window then the BSS takes this as an indication of a missing Packet Uplink Ack/Nack and
schedules retransmission of a Packet Uplink Ack/Nack to help the mobile advance its send
state window.
The BSS now supports the following extensions to the RLC:

The BSS indicates the EGPRS Window Size for use in the downlink in the Packet Downlink
Assignment, Packet Timeslot Reconfigure and Immediate Assignment messages. Extended
RLC window size of 192 in the downlink direction for EGPRS TBFs.
The BSS indicates the EGPRS Window Size for use in the uplink in the Packet Uplink
Assignment, Packet Timeslot Reconfigure and Immediate Assignment messages. Extended
RLC window size of 128 in the uplink direction for EGPRS TBFs.
The BSS supports the EGPRS fields in the Packet Downlink Assignment message, the
Immediate Assignment message for Uplink TBFs, the Immediate Assignment message for
Downlink TBFs and the Packet Timeslot Reconfigure message.
68P02901W36-S 6-75
Jul 2008
EGPRS RLC or MAC signaling Chapter 6: Call Processing
EGPRS Packet Downlink ACK/NACK message which includes a TBF release request from
the mobile.
Extended polling requesting partial bitmap and channel quality report in the EGPRS
Packet Downlink Ack/Nack message.
Receipt of the uncompressed bitmap in the EGPRS Ack/Nack Description of the EGPRS
Receipt of the compressed bitmap in the EGPRS Ack/Nack Description of the EGPRS
EGPRS fields in the Packet Uplink ACK/NACK message.
Sending of the compressed bitmap in the EGPRS Ack/Nack Description of the EGPRS
Packet Uplink Ack/Nack message.
Sending of the uncompressed bitmap in the EGPRS Ack/Nack Description of the EGPRS
Packet Uplink Ack/Nack message.
The BSS sends the uncompressed bitmap in the EGPRS Packet Uplink Ack/Nack message
unless the compressed bitmap results in fewer RLC control blocks.
There are cases where the compressed bitmap description is actually longer than the
explicit bitmap Ack/Nack description because the compression is a type of Run Length
compression. The BSS needs to try the compression to see which Ack/Nack description is
shorter and then uses the shorter Ack/Nack description in the Packet Uplink Ack/Nack
message.
The BSS indicates to the mobile station to use Pre_Emptive_Transmission by setting the
pre_emptive_transmission bit to 1 in the Packet Uplink Ack/Nack message.
The BSS sets the TBF_EST field in the Packet Uplink Ack/Nack message to 0 to indicate
that the mobile is not allowed to request the establishment of new TBFs.
The BSS supports the EGPRS fields in the Packet Resource Request message.
The BSS supports the EGPRS fields in the Packet Uplink Assignment message.
The BSS sends the mobile station the tlli_block_channel_coding field in the Packet
Uplink Assignment message to indicate to the mobile station that it is to use either CS1 for
GPRS TBFs or MCS1 for EGPRS TBFs or the commanded channel-coding scheme.
The BSS sets the link_quality_measurement_mode field to 0 0' in the Packet Downlink
Assignment, Packet Timeslot Reconfigure and Immediate Assignment messages thereby
not requesting the mobile to measure the BEP on a per-timeslot basis.
The link_quality_measurement_mode field indicates to the mobile station on which

timeslots the mobile is to measure the quality of the radio channel. The per timeslot
EGPRS Timeslot Link Quality Measurements is only included in Channel Quality Report
if the value of link_quality_measurement_mode is either 1 0 or 1 1. By setting the
link_qualty_measurement to 0 0 the mobile station is not requested to report the per
timeslot link quality measure in the Channel Quality Report.
The BSS sends the mobile station the channel-coding scheme obtained from the
channel-coding algorithm to be used on the uplink channel for new uplink data blocks in
the Packet Uplink Assignment and Packet Uplink Ack/Nack messages.
The BSS supports the new definitions of the Length Indicator field to indicate LLC
boundaries and does not use the M bit for EGPRS TBF mode.
6-76 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Physical layer
Physical layer
The physical layer can be subdivided into two layers: the physical RF layer and the physical link
layer. The physical RF layer performs modulation of the physical waveforms and demodulation
of the received waveform into a sequence of bits then transferred to the physical link layer.
The physical link layer provides the services for information transfer over a physical channel
between the MS and the GPRS network. Functions at this layer include:
Forward Error Correction (FEC) coding-Allows for the detection and correction of
transmitted code words and the indication of code words that can be corrected.
Procedures for detecting physical link congestion.
Synchronization procedures in addition to adjustment of timing advance parameters.
Monitoring and evaluation procedures for radio link signal quality.
Cell selection and reselection procedures.
Transmitter power control procedures.
Battery power conservation procedures such as Discontinuous Reception (DRx).
Rectangular interleaving of one radio block over four bursts in consecutive TDMA frames.
Packet transmission sequence
The TBF received from the MAC layer is split into blocks of eight, 57 bit, data fields in four
consecutive TDMA normal burst frames. These are then transmitted to the MS in downlink.
At regular intervals (no more than 16 blocks) a downlink ACK/NACK request is sent for
acknowledged data. See the section GPRS reserved and switchable timeslots in this Chapter.
Blocks are sent in strict sequence as given by the BSN. If two timeslots are allocated in the four
TDMA frames for packet data, the blocks are sent in sequence alternating between the two
timeslots as shown in Figure 6-34.
Figure 6-34 Packet transmission sequence (two timeslots)
1 2
3 4
Figure 6-35 shows the sequence with three timeslots allocated.
68P02901W36-S 6-77
Jul 2008
Physical layer Chapter 6: Call Processing
Figure 6-35 Packet transmission sequence (three timeslots)
1 2 3
4 5 6
NOTE
On downlink transfers, the BSS will automatically allocate as many switchable
timeslots for packet data as it can, depending on the multi-timeslot capability of
the MS.
When the MS is within 16 blocks of the end of the TBF, it starts a countdown which is returned
in the uplink ACK/NACK message. The PCU then starts to reallocate the packet data timeslots
for the next TBF.
GPRS Interleaving TBFs
The Interleaving Temporary Block Flows (TBFs) function allows the rapid multiplexing of Radio
Signaling Link (RLC) Data Blocks of many different mobiles onto a common air resource.
Multiple mobiles are then able to share a common air resource; although each mobile's effective
throughput on that shared resource decreases.
Each Mobile sharing a common air resource is given a certain percentage of that shared
resource's bandwidth. As an example, if two MSs are interleaved on the same air timeslot,
one MS is given 70% of the timeslot, while the second MS is given the remaining 30% of the
timeslot. Figure 6-36 helps to illustrate TBF Interleaving.
6-78 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Physical layer
Figure 6-36 Example of interleaving DL TBFs
In Figure 6-36, Mobile A and Mobile B are being interleaved on the same air timeslot. However,
Mobile A receives 70% of the timeslots bandwidth, while Mobile B receives 30%.
This interleaving increases the number of users that can be on a single timeslot, therefore
increasing the overall capacity (in terms of number of users) of a serving cell.
Interleaving TBFs in the uplink and downlink direction use the Block-by-Block multiplexing
method.
Block-by-Block multiplexing involves the multiplexing of two or more mobiles on a timeslot, with
the capability of switching between mobiles every block period.
All mobiles on a timeslot are simultaneously active in TBFs. The TBF setup phase, TBF release
phase, or data transfer phase of one mobile's TBF overlap with the TBF setup phase, TBF
release phase, or data transfer phase of other TBFs belonging to other mobiles.
Acknowledged data
If a NACK is returned then the whole block is retransmitted.
If the MS moves to another location area, it informs the BSS and any data that has not been
acknowledged is transferred to the new SGSN for retransmission. The location update message
sent by the MS contains the identity of the old SGSN to enable this to happen.
In the Signaling section in this chapter, message sequence details are described.
Unacknowledged data
For an unacknowledged data transfer, RLC discards the data after transmission and no
ACK/NACK request is sent.
68P02901W36-S 6-79
Jul 2008
Coding schemes Chapter 6: Call Processing
Coding schemes
The priority and data integrity for the transfer of packet data on the air interface is controlled
by selection of coding schemes. The more intensive the integrity checking the less data can be
transmitted per block. Four coding schemes are defined for standard GPRS.
Coding scheme CS-1
Coding scheme CS-1 uses a 40 bits Block Check Sequence (BCS) for increased integrity
protection. With the USF (3 bits), header and data (181 bits) and four tail bits, this amounts to
456 bits. In addition to the BCS check and a checksum check on the header and data, the four
tail bits are subjected to a 1/2 rate convolutional decoder check.
CS-1 therefore gives a data rate of 181 bits per 20 milliseconds or 9.05 kbps.
Figure 6-37 shows the structure of the 456 bit CS-1 block.
Figure 6-37 Structure of the 456 bit CS-1 block

3
6-80 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Coding schemes
Coding scheme CS-2
Coding scheme CS-2 uses only 16 bits for the Block Check Sequence (BCS) but in this case only
a CRC code is used. A 6-bit USF is used in CS-2 to increase robustness over the air interface.
Four tail bits are added so that the whole block amounts to 588 bits. The total is subjected to a
1/2 rate convolutional decoder check. The 588 bits per 20 ms is then reduced to 456 bits so as
to fit the normal GSM burst structure. This is done by puncturing as shown in Figure 6-38.
Figure 6-38 Coding scheme CS-2
1 2 . . . . . .
68P02901W36-S 6-81
Jul 2008
Coding schemes Chapter 6: Call Processing
Coding scheme CS-3
Coding scheme CS-3 also uses a 16 bit CRC for the BCS and a 6-bit USF. Four tail bits are added
so that the whole block, including header and data (312 bits), amounts to 338 bits. The total
block is subjected to a 1/2 rate convolutional decoder check, giving 676 bits. The 676 bits per
20 ms are then reduced to 456 bits, to fit the normal GSM burst structure, by puncturing
220 bits, as shown in Figure 6-39.

+
Punctured bits
1 2 . . . . . .
6-82 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation EGPRS coding schemes
Coding scheme CS-4
Coding scheme CS-4 uses 16 bits for the BCS and 12 bits for the USF. Combined with the header
and data bits (428) this amounts to 456 bits, the standard GPRS frame size.
Coding schemes are allocated dynamically during transmission of packet data depending on
factors such as Block Error Rate (BLER), availability of switchable timeslots, usage of timeslots
by circuit switched network and so on. Obviously, if a data block has to be resent at the RLC
layer, it must have the same coding scheme.
All uplink packet control channels are sent at CS-1 including the PRACH. The PRACH is
described under GPRS traffic and control channels on page 5-33.
The algorithm that controls the selection of coding schemes is the same one that monitors and
controls power levels. Power control is continuously monitored through uplink ACK/NACK
messages (always at CS-1) to the BTS and is determined in two ways. Power control is described
in the Handovers and Power Control chapter.
EGPRS coding schemes
The EGPRS coding scheme algorithm uses BEP (Bit Error Probability) and CV_BEP (Variance in
BEP) to decide the UL and DL coding schemes. The Channel Coder reports the UL BEP and
CV_BEP to the PCU. The Mobile reports the DL BEP and CV_BEP to the PCU in the EGPRS PUAK
message. The BSS supports all existing GPRS coding schemes (CS1-CS4) for GPRS TBFs and all
EGPRS coding schemes (MCS1-MCS9) for EGPRS TBFs on a 64 kbps terrestrial channel.
The coding schemes available for use on each air timeslot depends on the backhaul allocated
to each air timeslot. The BSS supports on a per mobile basis the EGPRS coding schemes on
the uplink air timeslots independently from the EGPRS coding schemes on the downlink air
timeslots.
When a mobile is performing a bi-directional packet transfer or independent packet transfers in

both directions, the PCU allows independent coding scheme selections for each direction. The
BSS limits the uplink channel coding scheme usage to EGPRS-GMSK MCS1-MCS4 for an EGPRS
mode TBF if the mobile indicates no support of uplink 8PSK modulation.
The coding scheme selection algorithms compensate for the artificially low block error rate
introduced by overriding the coding scheme with GMSK modulated radio blocks in the event
that an EGPRS TBF and GPRS TBF are interleaved on the same timeslot and the GPRS TBF
is being sent USFs.
68P02901W36-S 6-83
Jul 2008
EGPRS coding schemes Chapter 6: Call Processing
For uplink data transfers, the BSS selects one of the EGPRS coding schemes (MCS1-MCS9)
on a per EGPRS mobile basis according to measurement information. For downlink data
transfers, the BSS selects one of the EGPRS coding schemes (MCS1-MCS9) on a per EGPRS
mobile basis according to measurement information, unless interleaving with GPRS mobiles
requires GMSK-only (MCS1-MCS4 or CS1-CS4) blocks to be sent to inform the GPRS mobile
of uplink availability.
Transmitting the downlink data blocks at a lower coding scheme causes the blocks to have a
higher probability of being decoded correctly and this can cause the coding scheme algorithms
to have an artificially low block error rate measurement and this is compensated for by the
coding scheme selection algorithm.
The EGPRS coding schemes (MCS1-MCS9) are only used to transmit data blocks. The
coding scheme to use for downlink data blocks is determined in a similar manner as to the
existing coding scheme selection algorithms, considering block error rate, missed downlink
acknowledgments, RLC or MAC window stalls and past performance in higher coding schemes.
The BSS transmits all EGPRS RLC or MAC control blocks using CS1 and uses MCS1 for all LLC
dummy blocks during delayed downlink TBF release mode for EGPRS TBFs.
The BSS supports an algorithm to determine when to retransmit downlink RLC data blocks
using incremental redundancy when current coding scheme is the same as the coding scheme
used in the previous transmission of the RLC block.
6-84 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Call quality monitoring
Call quality monitoring

Bit error rate and quality band
Radio path receive quality measurements for active calls are reported by the BTS transceivers
and the MSs. These measurements allow the HDPC process to make handover decisions and
power control adjustments based on the uplink and downlink quality of the link. There are
two methods of measuring quality: Bit Error Rate (BER) and Quality band (Qband). In both
methods averages are used. Handover and power control processing are the subjects of the
next chapter in this manual.
Bit error rate
The measurements are reported to the HDPC in the form of quality bands ranging from 0-7, as
shown in Table 6-18. 0 corresponds to little or no deterioration of receive quality (RXQUAL)
on the channel and 7 corresponds to greater than 12.8% BER on the channel. These bands,
once received by the HDPC, are mapped to an assumed BER value (defined in GSM 05.08) as
shown in Table 6-18.
Table 6-18 RXQUAL reported bands and assumed BER
BER Reported band Assumed BER

Less than 0.2 % 0 0.14%
0.2-0.4 % 1 0.28%
0.4-0.8 % 2 0.57%
0.8-1.6 % 3 1.13%
1.6-3.2 % 4 2.26%
3.2-6.4 % 5 4.53%
6.4-12.8 % 6 9.05%
Greater than 12.8 % 7 18.1%
The assumed BER values are then stored and input to the averaging mechanism, using the
defined hreqt and hreqave values specified. The detailed settings of the uplink and downlink
quality and handover parameters are described in the Technical Description: BSS Command
68P02901W36-S 6-85
Jul 2008
Quality band Chapter 6: Call Processing
Quality band
An alternate method, known as Quality Band (QBAND) uses the reported bands, 0-7, as the input
to the averaging mechanism, instead of the assumed BER. This modification requires that the
threshold parameters are based on bands also, since the re-averaged values produced related
to the bands rather than BER percentages. Refer to RXQUAL Measurements for details of
QBAND/BER measurement examples.
The alt_qual_proc parameter can be used with the add_cell or chg_element commands to
select the measurement type (BER or Qband).
The thresholds for decision making for handovers or power control adjustments are set by
the following parameters:
I_rxqual_ul_p, u_rxqual_ul_p - lower and upper uplink power.
I_rxqual_dl_p, u_rxqual_dl_p - lower and upper downlink power.
I_rxqual_ul_h - lower uplink handover.
I_rxqual_dl_h - lower downlink handover.

These threshold parameters also exist for decision making for handovers or power control
adjustments for data only transmissions and for hopping cells. The parameter names are the
same except that the suffix _data or _hopping is added.
The parameters are ber_oos_mon_period and ber_restore_mon_period for use with

the modify_value command and ber_loss_daily and ber_loss_hourly for use with the
chg_element command.
The details of setting of the uplink and downlink quality and handover parameters are described
in the Technical Description: BSS Command Reference (68P02901W23) manual.
System impact
The averaging process produces different quality measurement results, depending on whether
BER or QBAND measurements are used in the averaging process:
The QBAND tends to be less sensitive to occasional extreme values, because of its tendency
to round off results.
The default BER generally has better performance, because of its more precise results.
6-86 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Bit error rate loss alarms
Bit error rate loss alarms
Bit error rates are constantly checked by the transcoder (XCDR) MSI boards. Thresholds can be
set by the operator for taking affected MMSs out-of-service and triggering alarms, based on
the number of BER losses in specified times (hourly or daily).
GPRS block error rate monitoring
In acknowledged mode, the Block Sequence Number (BSN) provides a modulo numbering
scheme (7 bits) for the RLC data blocks within one Temporary Block Flow (TBF). From this the
maximum threshold of 64 blocks is derived before an ACK is solicited. Every ACK message
acknowledges the number of blocks sent since the last ACK was sent. When all blocks within a
TBF have been sent, a final ACK is sent. The MS maintains a C block bit map of ACKnowledged
blocks and sends this up to the BTS in the PDTCH. Holes in this bit map inform the BTS which
blocks were not received and these are immediately retransmitted. From this bit map the
BTS maintains a Block Error Rate (BLER).
68P02901W36-S 6-87
Jul 2008
Adaptive Multi-Rate (AMR) Optimization Link and Intelligent Optimization System Chapter 6: Call Processing
Adaptive Multi-Rate (AMR) Optimization Link and

Intelligent Optimization System

Optimization Link (OPL)
The Optimization Link (OPL) is used to carry measurement report data out of the BSS to
the Intelligent Optimization System (IOS). The OPL reports AMR Half-Rate (HR) call data,
measurement report data, rapid handover events, RxQual or interference handover events for
AMR HR calls.
The BSS OPL uses a new cause value, within the exception handover information message, to
indicate that the handover was due to congestion based reconfiguration to HR. The cause value
refers to the value inserted in the cause octet of the exception handover information message.
This cause value indicates to the IOS the cause of the handover.
A new value is used to indicate that a rapid handover event was caused by congestion based
reconfiguration of a Full-Rate (FR) call to an HR call. Missing power budget neighbor event
data is sent to the IOS, if specified. In addition, missing neighbor event data is also sent, if
specified. The same missing neighbor occurrence message is used for both missing power
budget neighbor and missing neighbor event data reporting.
Each measurement report from the OPL indicates the AMR speech version and channel type.
Intelligent Optimization System (IOS)
The IOS collates the measurement report data from the OPL and makes recommendations on
how the network and cells in the network can be optimized. The chg_opl_data MMI command
is used to specify the data types to be reported to the IOS from which DRIs or timeslots. The
OPL interface is modified to support the existing reported data types for AMR HR calls.
Rapid handover, RxQual and interference handover event data are reported to the IOS, if
specified. The exception handover information message is used for both rapid handover event
data reporting and RxQual/interference handover event data reporting.
6-88 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Timing advance
Timing advance

Circuit switched timing advance
To simplify the design of the MS, the GSM recommendations specify an offset of three timeslots
between the BSS and MS timing, thus avoiding the necessity for the MS to transmit and receive
simultaneously.
However, the synchronization of a TDMA system is critical because bursts have to be transmitted
and received within the precise timeslots allotted to them. The farther the MS is from the BSS,
the longer it takes for the bursts to travel the distance between them. The GSM BSS caters
for this problem by instructing the MS to advance its timing to compensate for the increased
propagation delay.
This advance is then superimposed upon the three timeslot nominal offset, as shown in
Figure 6-41.
Figure 6-41 Timing advance illustration
Packet switched timing advance
Initial timing advance for a GPRS MS is calculated on the access burst (PRACH). Unlike GSM, an
MS using GPRS can only have a downlink channel activated, so it cannot update timing advance
information continuously and regularly. Timing advance information is, however, measured by
the BTS in the downlink ACK/NACK messages. These are polled for every 16 LLC PDUs that are
sent from the BSS to the MS during downlink packet data transmission. Timing advance values
are calculated by the BSS and then sent to the MS in the immediate assign messages.
68P02901W36-S 6-89
Jul 2008
Packet switched timing advance Chapter 6: Call Processing
In addition to this, GPRS introduces a process known as Timing Advance (TA) continuous
update. This process involves the MS sending access bursts on an assigned PACCH, using a
reserved timeslot and receiving a unique timing advance indicator number to which are linked
TA instructions on a subsequent TA message. In case this message is missed or interpreted
incorrectly, the MS is instructed by TAI to listen to the next three TA messages as well. These
TA reserved timeslots are listened to by all MSs in the cell and the TAI specifies which four TA
timeslots in consecutive messages an MS should listen to. These TA values are calculated at the
BTS. In order to avoid conflicting values being sent by the PCU and the BTS due to transmission
delays between them, the PCU allows for this when assigning TA values.
In Figure 6-42, the MS is allocated TAI of 1 after transmitting an access burst (uplink). This
TAI is sent down in the resultant immediate assignment message. One downlink frame is then
missed to allow the MS to change from Tx to Rx and the next downlink transmission contains
the TA value for MS with TAI 1 in both TA reserved slots. This is repeated in the next downlink
multiframe, making four opportunities for the MS to read it. Note that these TA timeslots will
contain TA values for up to 16 MSs and they read the values according to their assigned TAIs.
Figure 6-42 shows the packet switched timing advance.
6-90 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Packet switched timing advance
Figure 6-42 Packet switched timing advance
68P02901W36-S 6-91
Jul 2008
BTS Concentration Call Priority Handling (BCCPH) Chapter 6: Call Processing
BTS Concentration Call Priority Handling (BCCPH)

BCCPH function
BCCPH enables the BSS to prioritize the order in which non-emergency circuit switched calls are
preempted by emergency calls. When an emergency call requires terrestrial backing resources
the BSS can now preempt a non-emergency circuit switched call, based on priority and age.
Before the BCCPH feature was introduced, if an emergency call was received at a BTS and
no resources were available on the Abis interface (link between a remote BSC and BTS),
Preemption of existing calls took place in the following order:
Switchable packet data resources (GPRS) on the air interface.
Non-emergency circuit switched calls.
Reserved packet data resources (GPRS) on the air interface.
Within each category the calls are chosen in the sequence:

Oldest to newest Abis channels mapped to switchable GPRS resources. Within the GPRS
timeslots, the call that has the lowest priority is preempted first. If the calls have the same
priority, the call that has been connected longest is preempted first.
Oldest to newest non-emergency circuit switched calls. These calls are in the order of the
same cell, same site and the same dynamic network as the emergency call within each
category.
Oldest to newest Abis channels mapped to reserved GPRS resources. Within the GPRS
timeslots, the call that has the lowest priority is preempted first. If the calls have the same
priority, the call that has been connected longest is preempted first.
BCCPH preempts circuit switched calls based on priority as well as age. The BSS attempts to
preempt the lowest priority non-emergency circuit switched call first and the highest priority
non-emergency circuit switched call last. If two calls have the same priority, the oldest is chosen
first. To summarize the selection sequence:
Lowest priority and oldest non-emergency call.
Highest priority and newest non-emergency call.
The calls are chosen on priority first and age second. The priority levels are from 1 to 14 where
1 is highest and 14 is lowest. GPRS calls do not have call priority levels. They are therefore
preempted according to the priority of the cell that they are in.
NOTE
Non-emergency calls cannot preempt emergency calls.
6-92 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Call processing: location services
Call processing: location services

Early classmark procedure
The classmark update procedure is initiated at the mobile when the classmark parameters of
the mobile changes. This procedure is normally used only when the power class of the MS
changes, while the MS has a dedicated resource. For location services operation, the MS is
capable of sending up early classmark information, which is defined as the MS sending up
an RR classmark change message within 40 ms of the initial L3 info message. This early
classmark information is the means by which these LCS capable MSs are able to inform the
network of their full capabilities, as the RR classmark change message is the only message
which currently supports the sending of the classmark 3 Info information element, the element
which contains the frequency band capabilities of the MS.
The CM database element early_ classmark_sending must set to allow the early classmark
procedure across the A-interface and the CM database element phase2_classmark_allowed must
be set to Phase 2 with multiband feature format. When the RRSM receives the RR classmark
change message from the MS, it updates the locally stored classmark information for that MS,
sends the MS power control message to the RSS and sends the update classmark message
to the SSM with the new classmark information. Because the update classmark message can
arrive during any state of the SSM and is not restricted to certain states, this procedure does
not enter the SCCP state machine. Upon receipt of the update classmark message from the
RRSM, the SSM stores the new classmark information and must wait this amount of time (40
ms) before sending the BSSMAP classmark update message to the MSC.
Messaging
The BSS is responsible for transferring messages between the SMLC and the MSC when the
SMLC is BSS-based. It is also required to inform the sender of the message of a failure to
deliver the message to the destination (or next intermediary).
GSM messages
There are five GSM 08.08 messages in support of location services.
There are 10 GSM 08.71 messages in support of location services.
There are 11 GSM 09.31 messages in support of location services.
BSSAP messaging
The A-interface and Lb-interface carry C7 BSSAP messaging. The four types of BSSAP
messaging on these interfaces are:
BSSMAP(-LE) on the BSS-based SMLC-BSS link (Lb Interface, a two-way SMLC-BSS
protocol).
68P02901W36-S 6-93
Jul 2008
MSC-SMLC perform location messaging Chapter 6: Call Processing
BSSMAP on the MSC-BSS link (A-interface, a two-way MSC-BSS protocol).
DTAP(-LE) on the BSS-based SMLC-LMU link (a two-way SMLC-LMU protocol). The BSS
transparently forwards DTAP-LE messages which the BSS-based SMLC and LMU use to
communicate with each other. There is, however, no direct link between BSS-based SMLC
and LMU.
DTAP on the BSS-MS link (Air Interface, a two-way MSC-MS protocol). The BSS
transparently forwards DTAP messages which the MSC and MS use to communicate with
each other. There is, however, no direct link between MSC and MS.
MSC-SMLC perform location messaging
In a BSS-based SMLC case, from the BSS viewpoint, the location services procedure starts with
the routing of perform location messaging. This consists of setting up an SCCP connection with
the SMLC and forwarding the initial request to the SMLC. The SMLC most likely performs a
positioning attempt following this.
SMLC-SMLC messaging (BSS-based SMLC only)
Technically, SMLC-SMLC messaging occurs in the NSS-based SMLC case, but the BSS is not
involved in it at all. The BSS is involved in the BSS-based SMLC case only because the only
connection of SMLC to the PLMN (the other components in the network) is through the BSS.
This causes the BSS to act similarly to an STP in SS7.
However, unlike a true STP, the information to route the message appropriately is not found
in the route label-for SMLCPP messages (like any other message), the DPC in any received
message is the SPC of the BSS. The BSSMAP(-LE) connectionless information handling
done by the CLM performs the routing of the message.
Routing
When a BSSMAP-LE connectionless information message is received by MTPL3 from the

SMLC, it comes in an SCCP UDT. Like any other SCCP UDT, it is sent to CLM for processing.
When CLM examines the message type, it discovers that the message is a BSSMAP-LE
connectionless information message. CLM also has access to some means of discriminating
this message as one coming from the SMLC (as opposed to a BSSMAP connectionless
information message coming from the MSC)-this is probably done by the use of separate
mailboxes.
SMLC-SMLC messaging-segmentation
CLM support for SMLCPP message segments carried in BSSMAP(-LE) connectionless

information messages is described in the Segmentation section.
6-94 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation DTAP and DTAP-LE messages
Exception handling
The BSSMAP(-LE) connectionless information message as received by CLM can have

an optional IE called return error request. If present, this field indicates that it is the
responsibility of the intermediary entities to inform the sender of messaging problems. CLM
knows the accessibility of various point codes and subsystems and can use this information
(contained in the SPI state machine) and can inform the sender of routing failure.
When the BSS is in any SPI condition, the CLM responds to the BSSMAP(-LE) connectionless
information message from the sender (SMLC or MSC) with a BSSMAP(-LE) connectionless
information message that has an optional IE called return error cause.
Messages when protocol identifier is set other than SMLCPP
The BSSMAP(-LE) connectionless information message can carry only SMLCPP messages.
DTAP and DTAP-LE messages
Upon receipt of a BSSMAP Paging message from the SMLC, the BSS forwards the message
to the MS.
Encapsulation
The BSS is not concerned about LLP encapsulation since the LLP message is held in the data
portion of a DTAP-LE message. Similarly, SMLCPP messages are already within the data field
of a BSSMAP(-LE) Connectionless Information message.
Segmentation
Segmentation is used to transfer messages that are larger than the maximum size message
allowed for a given protocol. The BSS supports segmentation of messaging involving both
NSS-based and BSS-based SMLCs.
Generally, segmentation support for a received message implies that the BSS is able to
reconstruct the original message from received segments before resegmenting the message
over a different protocol when necessary. Where required, the BSS also segments any message
that it originates if that message is too large to be sent as a single unit.
The parameters used for segmentation are protocol-specific, but in the following requirements
they have been generalized. Below is a list of generalizations and how they apply to particular
protocols:
Segmentation is supported at various protocol levels in the end-to-end view of Location
Services (LCS), where the maximum sizes of the messages listed in section Messages and
encapsulation are constrained by the maximum data size allowed in the lower-level
protocol messages used to carry them. In addition, BSS executive messages can only carry
576 octets of user data. Fortunately, BSS executive messages can be sent over the Mobis
interface without further segmentation since the BSS uses non-standard LAPD frames.
68P02901W36-S 6-95
Jul 2008
Connectionless procedures Chapter 6: Call Processing
RRSM and SSM are the main BSS processes concerned with segmentation over location
services-related connections and each then uses the location services segmentation timer
to limit the time allowed between receipt of the first segment of a message and receipt of
the rest of the segments comprising that message.
CLM receives and forwards location services-related connectionless messages and

message segments, but segmentation support for these messages is limited to that
described in section BSSMAP(-LE) connectionless information size constraints.
To support segmentation, SSM and CLM correspond with two variants of the MTPL3
process. SSM and CLM exchange segmentation-related messages with the MSC through
an MTPL3 serving the A-interface. Similarly, SSM and CLM exchange segmentation-related
messages with the BSS-based SMLC through a MTPL3 serving the Lb-interface.
Illegal messaging
Upon receipt of a BSSMAP-LE message or a BSSLAP message from the BSS-based SMLC
that has invalid contents, the BSS discards the message.
Upon receipt of a BSSMAP message for location services from the MSC that has invalid
contents, the BSS discards the message, as already done for invalid non-location services
messages.
Upon receipt of a BSSLAP message from the MSC that has invalid contents, the BSS
discards the message.
Upon receipt of a new RR message for location services that has invalid contents, the BSS
discards the message, as already done for invalid non-location services messages.
Connectionless procedures
Since the BSS does not support SMLC traffic circuits, global reset and signaling point
inaccessible are the only BSS connectionless procedures concerned with location services.
These procedures manage the signaling connections to the SMLC.
The SMLC-related connectionless procedures use analogues of the timers and CM database
variables that the BSS uses to maintain the signaling point with the MSC. In this section, the
CM elements predating the addition of the Lb-interface are referred to by their common
names and informal names for the corresponding Lb-interface analogues are constructed by
pre-pending a Lb-prefix.
Global reset
CLM coordinates two types of global reset procedures, normal global reset and location services
global reset. For simplicity and consistency with other BSS documentation, normal global reset
is also referred to as global reset. Normal global reset initializes the MSC, SMLC and BSC after
a major failure which resulted in the loss of normal call information. Location services global
reset initializes the BSS and an attached BSS-based SMLC after a major failure which resulted
in the loss of SMLC-related call information. While normal global reset causes the BSS to clear
all call information and call references whether MSC-related or SMLC-related, location services
global reset causes the BSS to clear only Lb SCCP connections.
6-96 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Global reset
Normal global reset is initiated by the MSC or the BSS and location services global reset is
initiated by the BSS or an attached BSS-based SMLC.
During either type of global reset, the reset initiator sends a BSSMAP(-LE) reset message
expecting a BSSMAP(-LE) reset acknowledge message in return. As a reset initiator or
participant during normal global reset, the BSS also sends a BSSMAP-LE reset message
to any attached BSS-based SMLC expecting a BSSMAP-LE reset acknowledge message
in return. In all cases, CLM is responsible for exchanging BSSMAP(-LE) reset and reset
acknowledge messages with the affected BSS peer entities and for notifying the affected BSS
process instances. Since CLM can receive a BSSMAP(-LE) reset message from the MSC or
SMLC, the SCCP preprocessor of the MTPL3 helps CLM to distinguish between MSC-initiated
reset or SMLC-initiated reset (such as by routing the A-related and Lb-related reset messages to
different CLM mailboxes).
The BSS does not support SMLC traffic circuits and location services global reset conditions
do not affect A-interface traffic or signaling.
MSC initiated reset
When CLM receives a BSSMAP reset message from MSC, it starts normal global reset at the
BSS. Normal global reset requires CLM to initiate a global reset at the SMLC by sending it a
BSSMAP-LE reset message. The reset with the MSC and the reset with the SMLC execute in
parallel and CLM guards the receipt of a BSSMAP-LE reset acknowledge from the SMLC
with the Lb-T4 timer.
SMLC initiated reset
The SCCP preprocessor of the MTPL3 helps CLM to distinguish a BSSMAP-LE reset message
originating from the SMLC (such as by routing A-related and Lb-related messages to different
CLM mailboxes). In the case of a location services global reset, once CLM gets the response
from FM with the subsystem instances, CLM sends a location services global reset only to
SSM instances to indicate that SSM should only release its Lb-interface SCCP connections.
The MSC-related SCCP connections of the SSM are unaffected. The SSM then informs other
subsystems within the BSS of the released connections.
BSS initiated reset
The SPI procedure initiates a global reset procedure at the BSS if CLM receives a SPI or Lb-SPI
timer expiry while waiting for the BSS BSSAP layer to come up, or for the MSC or SMLC to
become accessible.
When the SPI timer expires before the MSC is accessible, or the BSS BSSAP layer is operational,
CLM waits for the SPI condition to clear before initiating a normal global reset, which includes
a reset with the MSC and the SMLC. During normal global reset, CLM treats the reset with
the SMLC as a separate transaction. In particular, CLM waits for the SMLC to acknowledge
the BSSMAP-LE reset message in order to send start bss to CRM. Instead, CLM sends the
start bss to CRM as soon as it receives global reset acknowledge from all subsystems and a
BSSMAP reset acknowledge from the MSC.
68P02901W36-S 6-97
Jul 2008
Bearer signaling Chapter 6: Call Processing
BSS initiated location services global reset
When the MSC is accessible and the BSS BSSAP layer is operational before the SPI timer
expires, but the SMLC is not accessible before the Lb-SPI timer expires, CLM waits for the
SPI condition to clear before initiating a location services global reset. In this scenario, CLM
queries FM for SSM instances and then sends location services global reset messages to
SSM instances. The message location services global reset instructs SSM to release only the
Lb-interface SCCP connections.
Bearer signaling
The BSS uses the bearer channels listed in Table 6-19 when sending location services signaling
(RRLP or LLP) to the MS or LMU.
Table 6-19 Bearer channel signaling
Signaling to On Use
MS SDCCH SDCCH
MS TCH FACCH
LMU SDCCH (TCH not allowed) SDCCH
The BSS sends locations services signaling (RRLP) using the SDCCH to an MS that is
currently on an SDCCH.
The BSS sends locations services signaling (RRLP) using the FACCH to an MS that is
currently on a TCH.
The BSS sends locations services signaling (LLP) using the SDCCH to an LMU that is
currently on an SDCCH.
Signaling point inaccessible
CLM coordinates SPI procedures to maintain the links and SCCP and BSSAP subsystems
connecting the MSC, BSC and a BSS-based SMLC. The SMLC SPI procedures of the CLM do not
impact signaling or traffic between the BSC and the MSC. However, if the MSC is inaccessible
long enough for the SPI timer to expire, the CLM initiates a reset with the SMLC along with
reset with MSC after the SPI condition is cleared.
6-98 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Signaling point inaccessible
SMLC inaccessible and then accessible
When all the links to the SMLC go down, FM sends a configuration status message to CLM
with the link type set to SMLC and the INS field set to all links down. After receiving this
message, CLM queries FM for subsystem instances and sends an smlc status message to SSM
and Lb preprocessor instances with the status field set to SMLC prohibited. Once SSM and Lb
preprocessor instances receive smlc prohibited, they suppress all messages that are to be sent
to the SMLC. If FM sends a configuration status (SMLC, one link up) message to CLM before
the Lb-SPI timer times out, the CLM once again queries FM for all SSM and Lb-preprocessor
instances and sends smlc status (allowed) message to the SSM and Lb-preprocessor instances.
When the link comes up, the BSS BSSAP is also up and so CLM sends a subsystem allowed
(BSSAP) message to the SMLC to notify the SMLC that the BSS BSSAP layer is operational.
BSSAP subsystem at BSS goes down and comes back up
FM sends cell change state (no cells up) message to CLM when the BSSAP subsystem goes
down at the BSS. On receiving this message, CLM starts the SPI timer and queries FM for
subsystem instances. After CLM gets the instance response from FM, CLM sends bss status
(bssap prohibited) message to preprocessor (both Lb-interface and A-interface related), CRM
and SSM instances. CLM then sends the subsystem prohibited (BSSAP) message to MSC
and the SMLC. If a BSSAP message comes from the SMLC or the MSC during this time, the
preprocessor responds with a subsystem prohibited (BSSAP) message.
BSSSAP subsystem at SMLC goes down and comes back up
The SMLC sends a subsystem prohibited (BSSAP) message to Lb preprocessor when its
BSSAP subsystem goes down. Upon receipt of this message, the preprocessor sends an smlc
status message to CLM with the status field set to indicate subsystem prohibited. When CLM
gets this message, it starts the Lb-SPI and Lb-T (statistics information) timers. CLM then
queries FM for the subsystem instances and sends an smlc status (bssap prohibited) message
only to SSM instances. SSM is the only process that needs to know that the BSSAP layer is down
at the SMLC, so that the process does not send any location services related messages to the
SMLC. When the SMLC BSSAP layer is up, the SMLC sends a subsystem allowed (BSSAP)
message to the Lb-preprocessor, which in turn sends an smlc status message to CLM with the
status field set to indicate subsystem allowed. CLM now stops the Lb-SPI and Lb-T (statistics
information) timers and sends SSM instances smlc status (allowed) message.
SCCP layer at SMLC goes and comes back up
SMLC sends a user part available (SCCP) message to MTPL3 when its SCCP subsystem goes
down. Upon receipt of this message, MTPL3 sends an smlc status message to CLM with the
status field set to indicate that the SCCP user part is unavailable. When CLM gets this message,
it starts the Lb-SPI timer and then queries FM for the subsystem instances. CLM then sends an
smlc status (sccp prohibited) message only to SSM instances.
SPI status sent in response to register message
Upon receipt of a register message from any process (that is CRM, MTPL3, or SSM currently),
CLM checks SPI conditions to send the register originator an MSc status (allowed) if the MSC is
accessible and a bss status (allowed) if the BSS BSSAP subsystem is up. If CRM was not the
register originator, CLM also replies with an smlc status (allowed) if the SMLC is accessible.
68P02901W36-S 6-99
Jul 2008
NSS-based SMLC positioning scenarios Chapter 6: Call Processing
NSS-based SMLC positioning scenarios
The location services transactions initiated by a NSS-based SMLC terminating at, or routed
through, the BSS. NSS-based SMLC indicates that the SMLC supports the Ls-interface and is
associated with an MSC. All messages between the SMLC and the BSS or MS are through
the MSC in NSS-based positioning.
Timing advance based positioning scenarios
The SMLC is requesting Timing Advance (TA) information for a target MS. To improve the
location calculation accuracy of the MS, the latest measurement report is returned in the data
provided by the BSS to the SMLC. New messages on the A-interface are needed to transfer
embedded requests and responses between the SMLC and the BSS through the MSC.
Preemption
The concepts of priority and Preemption have been added to GSM 04.08 specification. The RR
Application Information message is the only message with low priority. Therefore, the BSS
preempts the RR Application Information message when it receives a high-priority message.
TA based positioning-successful scenario
The NSS-based SMLC causes the MSC to send a BSSMAP connection - oriented information
message containing a BSSLAP TA request message to the BSS. This is received over the
SCCP connection between the BSS and the MSC. The BSS is requested to obtain the timing
advance, the measurement report and the serving cell ID of a target MS. The SSM process
contains the serving cell ID in its data store. SSM does not know the timing advance and
the measurement report information. The timing advance information and the measurement
report are known by the RSS.
Assuming a handover is not in progress, the SSM process within the BSC sends a ta request
message to the RRSM process to obtain the timing advance information and the measurement
report. The SSM starts the timer location services supervision timer to guard the receipt of a ta
response from the RRSM.
Lb procedures
Upon detecting that, the BSS-based SMLC is inaccessible (identified by the last LMTL going
out-of-service), the BSS discards any application messages destined for the BSS-based SMLC
until the BSS-based SMLC is accessible again.
Upon detecting that a previously inaccessible BSS-based SMLC is now accessible (identified
by an LMTL coming into service), the BSS resumes sending any application messages to the
BSS based SMLC.
Upon detecting that the BSS-based SMLC has an SCCP failure (as indicated by an MTPL3
UPU message), the BSS must not send any application messages to the BSS based SMLC until
the SCCP layer is accessible again.
Upon detecting that a BSS-based SMLC with an SCCP failure now has its SCCP layer operating
correctly (as indicated by the receipt of an SCCP or BSSAP message), the BSS resumes sending
any application messages destined for the BSS based SMLC.
6-100 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BSS-based SMLC positioning scenarios
Upon detecting that the BSS-based SMLC has a BSSAP failure (as indicated by an MTPL3
SSP(BSSAP) message), the BSS must not send any application messages to the BSS-based
SMLC until the BSSAP layer is accessible again.
Upon detecting that the BSS-based SMLC with the BSSAP failure now has its BSSAP layer
operating correctly (as indicated by the receipt of an SCCP or BSSAP message), the BSS
resumes sending any application messages destined for the BSS based SMLC.
Tearing down Lb connections for an MS
Whenever the Lb connections to the BSS-based SMLC are torn down, the location services
procedure is either completed or it is being abandoned. Once the location services procedure is
completed, either the BSS-based SMLC or the BSS can initiate the Lb SCCP teardown.
The BSS abandons the location services procedure when the MS Lb SCCP connection is torn
down.
BSS-based SMLC positioning scenarios
The central difference between the BSS-based positioning scenarios and the NSS-based
positioning scenarios is not one of separate message flows, in fact, the messaging exchanged is
nearly identical. The difference lies in the routing of the individual messages. The BSS now
must contend with two terrestrial point codes (SMLC and MSC), whereas previously the BSS
could assume the MSC was the end destination (it was the only other SPC in the network
besides the BSS).
The creation of a new interface and its supporting protocols, introduces a sizeable amount of
added functionality. This section deals with the application level changes dealing directly with
the location services only. Other sections cover changes necessary for the maintenance and
operation of the new interface (such as signaling link maintenance and circuit maintenance).
Initial set up
A portion of the functionality necessary for a BSS-based SMLC is identical regardless of

positioning method. The initial set up of all resources and notification to the SMLC of a
positioning attempt is done prior to the SMLC deciding what type of positioning method to use.
The MSC always knows of a location services attempt before the SMLC or BSS and sets up a
call (at least to an SDCCH) prior to notifying the SMLC of the location attempt. Thus, from the
viewpoint of the BSS, a call is already established before location services even begin.
NOTE
A call could already be in progress (user just happened to be involved in a normal
voice or data call at the time) and the MS could already be on an SDCCH or a TCH. In
that case, the MSC can skip the call setup messaging since it has already been done.
68P02901W36-S 6-101
Jul 2008
Handling issues Chapter 6: Call Processing
Location services teardown
For successful location services cases, the location services positioning procedure can end with
the SMLC sending a BSSMAP-LE perform location response message encapsulated in
an SCCP RLSD message, or the SMLC sending a BSSMAP-LE perform location response
message only.
TA-based positioning scenarios
Similar to the NSS-based SMLC scenario for TA-based positioning, the BSS is gathering internal
data related to an active call and providing that data to the SMLC. Just as in the NSS-based
SMLC case, the latest measurement report is returned in the data provided by the BSS to the
SMLC to possibly improve the location calculation accuracy for the SMLC.
Handling issues
There are a number of handling issues, they are described in the following subsections:
RRLP protocol error message
When SSM receives a BSSLAP MS position command with an RRLP protocol error
encapsulated inside, SSM must encapsulate the RRLP protocol error message into an RR
application information message and forward the message to RRSM. The RRSM sends it
out to RSS process to the MS. This procedure is stateless, so that the BSS does not expect
any response from the MS.
Loss of signaling to the MS
During a TA positioning attempt, if the BSS loses the signaling connection to the MS (such as
expiry of the T10 timer or the T3103 timer), the BSS abandons the ongoing positioning attempt.
BSSLAP abort
During a location services procedure, the SMLC can abort the attempt at any time by sending a
BSSLAP abort message to the BSC. When SSM receives this message, it stops the location
services supervision timer and aborts further processing. Any responses from RRSM for this
location attempt after receiving the BSSLAP abort message are ignored.
Release cases
If, during a location services procedure, SSM determines that the call is going to be released
(this could occur for any number of reasons such as MSC teardown, loss of signaling connection
to the MS such as T10 timer or T3103 timer expire), SSM sends a BSSLAP abort message to
the SMLC with cause value loss of signaling connection to MS and abandons any further
location services processing for this call. Further, if the SCCP connection to the MSC is torn
down, the SCCP connection to the SMLC is torn down as well. Refer to section Location
services teardown for further detail.
6-102 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Preemption, overloading and early provision of TA
If any BSSLAP command is received from the SMLC while the call is being torn down, SSM
responds to the BSSLAP command with a BSSLAP abort with cause value loss of signaling
connection to MS.
No BSS-based SMLC present
When the BSS receives a BSSMAP perform location request from the MSC and there is not a
BSS-based SMLC present, the BSS discards the BSSMAP perform location request message.
Perform location abort
When the BSS receives a BSSMAP perform location abort message from the MSC, it
forwards this message in a BSSMAP-LE perform location abort message to the SMLC on the
existing Lb SCCP connection. The SMLC must respond to the BSS with a BSSMAP-LE perform
location response message when it receives a BSSMAP-LE perform location abort message.
When no Lb SCCP connection exists for this A-interface SCCP connection, or no BSS-based
SMLC exists, the BSS discards the BSSMAP perform location abort message.
LMU procedures
LMUs use the same interface as mobiles, except that all signaling goes to the SMLC and not
to the MSC when the SMLC is BSS-based. The LMUs are allowed to get an SDCCH and even
perform handovers. However, the LMUs cannot get a TCH.
LMU handover
The LMU is similar to a mobile station except for voice capability. All LMU handover messages
are between the LMU, BSS and the BSS-based SMLC or the MSC.
The BSS does not allow an LMU to be assigned to a traffic channel.
The BSS supports inter-BSS and intra-BSS handovers for an LMU.
Preemption, overloading and early provision of TA
Preemption
Preemption can be with or without truncation.
Preemption without truncation
For LCS, the BSS is required to support Preemption of low-priority messages by high-priority
messages. Normal-priority messages can neither preempt nor be preempted. RR application
information messages (such as LCS messages) are considered low priority. Important RR
messages such as channel establishment and release messages, configuration change messages
and handover-related messages are considered high priority. All the MM, CM and non-high
priority RR messages are considered normal priority.
68P02901W36-S 6-103
Jul 2008
Preemption, overloading and early provision of TA Chapter 6: Call Processing
Overloading
In the Motorola implementation of the BSS, overload is detected on a per cell basis. If CRM
detects an overload condition (or the overload is reported by the MSC, SSM, or RSS), CRM uses
a flow-control algorithm to attempt to improve the condition (the BSS does not send overload
messages to the MSC). CRM picks one of ten mobile access classes and bars mobiles of that
class from using the system. CRM continues to bar access classes until the overload condition
is eased.
Early provision of TA
In order to support (and expedite) any basic cell ID activities that can be performed by the MSC
or SMLC during call setup, the BSS supports the provisioning of the initial TA value to the MSC
upon call setup (when the location services feature is enabled). The TA value is that which was
obtained during the RACH procedure. As no MR data is available at the time of the initial
MS message, none is provided to the MSC.
When RRSM sends the initial l3 message to SSM, it includes the TA obtained during the RACH
attempt of the mobile. When SSM receives the initial l3 message, it builds a BSSMAP complete
layer 3 message to be sent to the MSC. SSM includes a BSSLAP TA layer 3 message with the
TA value from the initial l3 message. This BSSLAP message is contained in the optional APDU of
the BSSMAP complete layer 3 message.
Apart from the inclusion of the TA information, this functionality has no other effect on call
setup procedures.
6-104 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation EGPRS incremental redundancy
EGPRS incremental redundancy

Incremental redundancy
For EGPRS, the BSS supports the following:

Ability to use Incremental Redundancy (IR) procedures.
Support for hybrid Type II ARQ mode with IR for uplink EGPRS TBFs.
Support for hybrid Type II ARQ mode with IR for downlink EGPRS TBFs.
Support for Type II ARQ mode (IR) and no resegmentation of RLC data blocks for
retransmitted RLC data blocks in the downlink for TBFs operating in RLC acknowledged
mode.
The PCU, when retransmitting data blocks in the downlink indicates to the radio (CCU) which IR
puncturing codes to use on a per RLC block-basis.
The BSS supports independent IR puncturing codes for each RLC data block in a downlink radio
block in MCS7, MCS8 and MCS9. For retransmissions of MCS1-MCS9 blocks using IR in hybrid
ARQ mode II, the BSS retransmits the RLC data block using another MCS in the same family
as defined for the mobile station.
The MCS7, MCS8 and MCS9 downlink radio blocks are actually composed of two independent
RLC data blocks and these data blocks can have independent IR puncturing schemes (the
puncturing schemes are referred to in the specifications as P1, P2 and P3). The PCU indicates
to the channel coder which puncturing scheme to use with each half of the data block.
The BSS transmits all downlink RLC data blocks using puncturing scheme P1 initially, followed
by P2 for the first retransmission in the same coding scheme on a per-RLC block basis. For
MCS1, MCS2, MCS5 and MCS6 the BSS retransmits at P1 for the second retransmission and
alternates between P2 and P1 thereafter. For MCS3, MCS4, MCS7, MCS8 and MCS9 the BSS
retransmits at P3 for the second retransmission and cycles through P1, P2 and P3 thereafter.
The BSS supports Type II ARQ mode (Incremental Redundancy) by ordering the MS to use a
specific MCS and not setting the RESEGMENT bit in the Packet Uplink Assignment, Packet
Timeslot Reconfigure, EGPRS Packet Uplink Ack/Nack and Immediate Assignment for Uplink
messages.
The BSS is not implementing ARQ mode I which allows the splitting of a single BSN into two
parts for retransmission at lower coding schemes. The BSS only supports splitting the RLC
radio block into two data blocks at the BSN boundary (ARQ mode II). The only time that the BSS
should receive an RLC block that indicates split payload is in the case of a rogue mobile. The
BSS discards any uplink block from the mobile station if the RLC or MAC header indicates that
it is a split payload block.
When operating in ARQ mode II, the mobile station sets the MS OUT OF MEMORY indicator in
the EGPRS Packet Downlink Ack/Nack, the BSS will take into account the fact that the mobile
station is no longer performing IR and that the mobile station cannot realize the gains in
performance afforded by IR.
68P02901W36-S 6-105
Jul 2008
Adaptive Multi-Rate (AMR) Abis-interface Chapter 6: Call Processing
Adaptive Multi-Rate (AMR) Abis-interface

Traffic channel communications
Traffic channel related communication within the BSS indicates the relevant sub channel
in all AMR half-rate channel related messaging within the BSS so that, for AMR Half-Rate
(HR) channels, the BSS refers to the corresponding air interface timeslot sub channel for the
communication.
The channel activation and mode modify messages on the Abis interface both contain the
channel mode information element. The channel mode information element contains the
channel rate and type octet and the speech coding algorithm octet that indicate the channel rate
and speech version respectively and are also coded to indicate a TCH/AHS.
If the channel mode information element within the channel activation message specifies a
TCH/AHS the BSS includes the multi-rate configuration information element. The multi-rate
configuration included in the channel activation message is the uplink multi-rate configuration
for the channel.
If the channel mode information element within the mode modify message specifies a TCH/AHS
the BSS includes the multi-rate configuration information element. The multi-rate configuration
element in the channel activation and mode modify messages on the Abis interface contains the
codec modes in the Active Codec Set (ACS), the Initial Codec Mode (ICM) and the associated
adaptation thresholds and hysteresis values used by an AMR call.
The multi-rate configuration element, in the channel activation and mode modify messages, is
coded to indicate to the CCU the full or HR active codec set, full or HR ICM and the associated
uplink codec mode adaptation thresholds and hysteresis values, specified in the database,
for full or HR AMR calls.
NOTE
Other messages that need to be modified for the implementation of AMR HR, such
as the handover command and assignment command, are also sent across the Abis
interface.
6-106 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Emergency call preemption
Emergency call preemption

Reservation of full-rate TCH for emergency calls
When the BSS receives an emergency CM service request, it attempts to reserve a timeslot
for the incoming emergency call. This ensures that a traffic channel is reserved (ready to
be allocated) for the emergency call when the assignment request is received by the BSS.
Unnecessary delays are not then introduced during the assignment of an emergency call. If the
BSS cannot reserve an idle traffic timeslot, an attempt to steal a traffic timeslot, reserved by the
multiband handover functionality, allocate a reserved AMR half-rate capable traffic timeslot, or
trigger emergency call preemption, if enabled, is made.
When the BSS receives the emergency CM service request it has no indication of the capabilities
of the call, as far as supported speech versions are concerned. The TCH reserved is full-rate
capable, but can also be AMR full-rate capable. It is possible that the assignment request
from the MSC identifies AMR full-rate speech version as having the highest priority or being
the only permitted speech version for the call. The traffic channels reserved for the emergency
call are, in order of preference, as follows:
Full rate only.
If there are no idle full-rate only channels available in the cell, a generic timeslot.
If there are no idle traffic channels in the cell to reserve for an emergency call, a
switchable PDTCH.
If there are no other idle full-rate capable timeslots in the cell, the selection of a reserved
generic timeslot is allowed.
The highest priority speech version supported by the TCH is used when assigning an emergency
call to the allocated timeslot. This can result in the BSS not assigning the highest priority
speech version requested by the MSC to the call but prevents unnecessary re-allocation of
resources within the BSS.
If the reserved timeslot cannot support any of the requested speech versions specified by the
MSC the BSS attempts to allocate a new resource with the correct capabilities.
NOTE
If the channel does need to be altered to satisfy the request from the MSC, this is
done by the re-assignment of the call to the new channel.
68P02901W36-S 6-107
Jul 2008
Reservation of full-rate TCH for emergency calls Chapter 6: Call Processing
Stealing of multiband handover reserved timeslots
Stealing of reserved multiband timeslots occurs when an emergency CM service request is

received and no other traffic channels are available. This happens prior to the BSS triggering
emergency call preemption, if enabled. The channel reserved by the multiband handover
functionality can be either a Full-Rate (FR) or Half-Rate (HR) channel.
The BSS steals FR channels from the channels reserved by the multiband handover functionality.
It is possible that there is an HR channel reserved by the multiband handover functionality,
which is part of a single occupancy HR traffic timeslot (the other sub channel is idle). Also the
other sub channel is reserved by the multiband handover functionality. In this case the BSS will
steal both of the HR sub channels related to the HR traffic timeslot for the emergency call.
The BSS steals an HR channel reserved by the multiband handover functionality, if the other sub
channel associated with the reserved sub channel is also reserved by the multiband handover
functionality.
Use of reserved half-rate capable traffic timeslots
If all other resources have been exhausted, including all idle FR capable timeslots and GPRS
switchable timeslots, the BSS allocates the incoming emergency call to a reserved HR capable
traffic timeslot, prior to initiating preemption.
Emergency call preemption
If an emergency call cannot be assigned an idle traffic channel and there are no GPRS
switchable or multiband reserved timeslots in the target cell, the BSS will preempt a call from
an in use traffic channel. When searching for an in use traffic channel to preempt the call from,
the BSS will preempt a lower priority call in preference to a higher priority call. For HR call
preemption, a dual occupancy HR traffic timeslot is regarded as the highest priority call on that
timeslot. In order to reserve HR traffic channels where possible, after taking into account
priority considerations, the BSS gives preference to preempting FR calls.
When preempting a traffic channel to assign to an emergency call, after considering call priority,
the BSS prioritizes channels based upon the carrier on which those channels exist. Calls are
preempted in the following order of priority:
Full rate call.
If there are no full-rate calls of lower priority, the BSS.
If there are no full-rate or single occupancy half-rate calls with lower priority, two half-rate
calls (occupying the same timeslot) are selected for preemption.
If the BSS is selecting the lowest priority single-occupancy half-rate call for preemption, the
priority of the dual occupancy half-rate timeslot is defined by the highest priority half-rate
call on the timeslot.
If an emergency call is initiated in Enhanced Auto Connect (EAC) mode and no suitable Ater is
available to be assigned to the call the BSS will preempt an existing non-emergency call, or
calls, to obtain a suitable Ater resource. If half-rate is being used, multiple calls have to be
preempted to obtain a 16 kbps Ater.
6-108 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Reservation of full-rate TCH for emergency calls
The preferences for half-rate emergency call preemption are:

An 8 kbps being used for an 8 kbps call.
One half of a 16 kbps Ater being used for a 16 kbps call.
The preferences for full-rate emergency call preemption are:

A 16 kbps Ater being used in a 16 kbps call.
A 16 kbps Ater where 8 kbps is being used in an 8 kbps call and the other 8 kbps is idle.
Two consecutive 8 kbps Aters being used in 8 kbps calls.
Non-emergency calls are preempted in order of priority, beginning with the lowest priority call.
68P02901W36-S 6-109
Jul 2008
AMR channel allocation Chapter 6: Call Processing
AMR channel allocation

Channel information elements
The channel type information element, within the handover and assignment request messages
from the MSC, contains a speech or data indicator octet. The speech/data indicator octet defines
whether the request is for speech, data or signaling. The operation of the BSS is different
for each of these options.
Speech channel information
The channel rate and type octet contained within the channel type information element, in
the handover request and assignment request messages from the MSC to the BSS, indicates
the required channel rate option as follows:
Full-Rate FR.
Half-Rate HR.
Either full-rate or half-rate.
For each option, the preferred channel rate and if rate changes are permitted after initial
channel allocation, can be indicated.
The MSC specifies a particular channel rate within the channel rate and type octet contained in
the channel type information element of an assignment or handover request message. The BSS
attempts to allocate a channel of the specified rate for the call. The permitted speech version
indication octets, within the channel type information element in the handover request or
assignment request messages from the MSC, list, in order of preference, the speech versions
which can be used for the call.
Full rate speech channel request
The MSC specifies that a call must be allocated to an FR traffic channel by setting the channel
rate and type octet within the channel type information element in an assignment request or
handover request message to FR TCH channel Bm.
If the channel rate and type octet of an assignment request or handover request message
from the MSC specifies FR TCH channel Bm, the BSS attempts to allocate an FR channel for
the call. The BSS will allocate an FR channel for the call (if one is available), with speech
version as determined by the permitted speech version indication octets and the capabilities
of the selected CIC.
NOTE
CICs must be on an EGDP to support AMR FR.
6-110 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Channel information elements
Half rate speech channel request
The BSS only supports GSM speech HR version 3 (that is AMR HR). 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 HR TCH channel Lm, the BSS will attempt to allocate an HR
channel to the call if GSM speech HR version 3 is in the permitted speech version indication list.
The BSS will attempt to allocate an AMR HR channel for the call if the channel rate and type
octet of an assignment or handover request message from the MSC specifies the following:
Channel type information element HR TCH channel Lm specified.
The permitted speech version indication octets include GSM HR speech version 3.
If GSM speech HR version 3 is not in the permitted speech version indication list, the BSS
must reject the request.
To reject the request, the BSS sends an assignment or handover failure message, with cause
value (part of the cause information element within the assignment failure message) requesting
speech version unavailable, to the MSC.
Only CICs that are transcoded by an enhanced GDP pair or GDP2 support the AMR HR speech
version. Therefore, if the MSC specifies HR in the channel rate and type octet of an assignment
request or handover request, but the selected CIC is not transcoded by an enhanced GDP pair,
the BSS must reject the request.
CIC transcoding
The BSS includes the AMR HR speech version in the capability list of CICs that are transcoded
by an enhanced GDP pair. This requirement is subject to the restrictions defined as follows:
The BSS excludes AMR HR speech in the capability list of a remotely transcoded CIC, if
that CIC is associated with an RXCDR for which CIC validation is not operational. If CIC
validation is not operational for the RXCDR associated with a given CIC, it is not possible
to tell if the CIC is transcoded by an enhanced GDP pair and therefore, whether that CIC
can support the AMR HR speech version.
NOTE
CIC validation can be regarded as operational for a given RXCDR if the AXCDR
device associated with that RXCDR is busy-unlocked. This automatically implies
that CIC validation is enabled for that RXCDR.
The BSS excludes AMR HR speech from the capability list of a remotely transcoded CIC
if that CIC is associated with an RXCDR that is running a pre-AMR HR channel mode
BSS software release.
The BSS excludes AMR from the capability list of a CIC if that CIC is associated with an
RXCDR or local transcoding BSC that has the AMR using enhanced GDP feature restricted.
68P02901W36-S 6-111
Jul 2008
Channel information elements Chapter 6: Call Processing
If the BSS receives an assignment request or handover request message that specifies that an
AMR HR channel is required and the specified CIC does not have AMR HR speech capability, the
BSS rejects the request. To reject the request, the BSS sends an assignment or handover failure
message, with cause value (part of the cause information element within the assignment failure
message) requested speech version unavailable, to the MSC.
The BSS can only allocate an AMR HR channel if the following are all true:
The AMR HR channel mode is enabled at the BSS level.
The AMR HR channel mode is enabled for the target cell.
There are AMR HR channels available in the target cell.
If an assignment or handover request message from the MSC specifies that an AMR HR
channel is required, but AMR HR is disabled within the BSS, the BSS rejects the assignment
or handover request.
If the BSS receives an assignment or handover request message that specifies that an AMR HR
channel is required, but AMR HR is disabled in the target cell, the BSS rejects the request with
cause value requested speech version unavailable. In addition, if an assignment or handover
request message from the MSC specifies that an AMR HR channel is required, but the BSS
cannot allocate an AMR HR channel, the BSS rejects the assignment/handover request.
If the BSS receives an assignment or handover request message that specifies that an AMR HR
channel is required, but there are no AMR HR channel resources in the target cell, the BSS
rejects the request. To reject the request, the BSS sends an assignment or handover failure
message, with cause value (part of the cause information element within the message) no
radio resource available, to the MSC.
NOTE
The above restrictions are also applicable to AMR FR calls and channels.
AMR full-rate or half-rate channel request
If the channel rate and type octet within an assignment request or handover request message
from the MSC specifies that either an FR or an HR channel can be allocated to the call, the BSS
decides which to allocate. The BSS will attempt to allocate an FR channel to the call as per
existing functionality, if any of the following are true:
The AMR HR channel mode is disabled at the BSS level.
The AMR HR channel mode is disabled for the target cell.
GSM HR speech version 3 is not in the permitted speech version indication list.
The channel rate and type octet indicates that rate changes after initial channel allocation
are not allowed.
The CIC selected for the call does not have AMR HR capability.
Although the AMR HR or FR capability is restricted for a call, when the above conditions apply,
the capabilities of the call (AMR FR or AMR HR) still need to be tracked in case the restrictions
applied within the current environment change. The restrictions can be removed during the
6-112 68P02901W36-S
Jul 2008
duration of the call if any of the conditions within the BSS change. This could occur due to, the
MS handing into a cell, which does support HR AMR, the operator enabling AMR HR with the
cell/BSS, or the CIC supporting the call is altered.
The recommended configuration is for the MSC to leave the choice of channel type up to the
BSC, if the channel rate and type octet specifies that either an FR or an HR channel can be
allocated to the call. In addition, the octet indicates that either there is no preferred channel
rate, or that an FR channel is preferred.
The BSS attempts to allocate an FR channel to the call, unless the criteria that allows the BSS to
ignore the preference specified by the MSC are met. The criteria governing the over-riding of
the preference specified MSC are two fold.
The force_hr_usage per BSS element is enabled.
The new_calls_hr congestion level has been exceeded.
If either of the above criteria are met, the BSS attempts to allocate an HR channel to the call. If
the channel rate and type octet specifies that either an FR or an HR channel can be allocated
to the call and, in addition, the octet indicates that HR is the preferred channel rate, the BSS
attempts to allocate an HR channel to the call.
In the following three requirements, the call has both AMR FR and HR included in the channel
type IE and are still unrestricted after the conditions previously identified requirements for
checking AMR FR capability.
For an initial call assignment, the MSC specified preference in the channel type IE is
obeyed, when the force_hr_usage element is set to disabled.
For an initial call assignment, if the force_hr_usage element is set to enabled, the BSS
elevates the AMR HR speech version to have the highest priority (over-riding the MSC
preference, if specified).
For an initial call assignment, if the new_calls_hr threshold is exceeded, the BSS elevates
the AMR HR speech version to have the highest priority (over-riding the MSC preference,
if specified).
If the BSS fails to allocate an HR resource when it is preferred by the MSC or operator
preference, the BSS downgrades the call (due to unavailable resources) to a lower priority
speech version specified by the MSC. If the BSS has just attempted to allocate an HR channel,
the next lower priority speech version specified by the MSC must be an FR speech version
(as only HR speech version 3 is supported in the BSS). The FR speech version could be AMR
FR, EFR or FR.
If the MSC specifies alternative speech versions to the AMR HR and the BSS cannot allocate an
AMR HR channel, the BSS attempts to downgrade the AMR HR call due to unavailable resources.
NOTE
Downgrading due to unavailable resources is not the same as downgrading the call
due to CIC capabilities. At the point when the BSS is allocating a resource to a call,
the CIC capabilities will have already been validated. The BSS is downgrading to a
speech version known to be supported by the BSS.
To downgrade an AMR HR call the BSS chooses the next speech version in the permitted
speech version list from the MSC. The BSS continues to downgrade the call until a resource is
allocated or there are no speech versions left unattempted in the permitted speech versions list
from the MSC.
68P02901W36-S 6-113
Jul 2008
The BSS allows the call to be downgraded to AMR FR if:

AMR FR is the next speech version in the permitted speech version list from the MSC.
AMR FR is enabled at the BSS and cell level.
The specified CIC is AMR FR capable.
An AMR FR resource is available.
The BSS allows the call to be downgraded to EFR if:

EFR is the next speech version in the permitted speech version list from the MSC.
EFR is enabled in the BSS.
The specified CIC is EFR capable.
EFR resource is available.
The BSS allows the call to be downgraded to FR if:

FR is the next speech version in the permitted speech version list from the MSC.
The specified CIC is FR capable.
FR resource is available.
If the BSS exhausts the permitted speech versions list from the MSC, having checked the CIC
capability, per-BSS enable and per-cell enable flags, the cause speech version unavailable
is sent to the MSC. If the BSS fails to allocate an FR resource (a resource that can support
the highest priority speech version specified by the MSC) when it is preferred by the MSC or
operator preference, the BSS downgrades the call (due to unavailable resources) to a lower
priority speech version specified by the MSC.
If the BSS has just attempted to allocate an FR channel, the next lower priority speech version
specified by the MSC could be an FR speech version, AMR FR, EFR or FR. Alternatively the
next speech version in the speech version list could be an HR speech version, AMR HR (only HR
speech version 3 is supported in the BSS). Downgrading an FR call to an HR speech version is a
functionality added by the introduction of the AMR HR channel mode. The operation of the BSS
in this case is defined as follows.
If the MSC specifies alternative speech versions to FR and the BSS cannot allocate an FR
channel, the BSS attempts to downgrade the FR call due to unavailable resources.
To downgrade an FR call the BSS chooses the next speech version in the permitted list from
the MSC. The BSS continues to downgrade the call until a resource is allocated or there are no
speech versions left unattempted in the permitted list.
6-114 68P02901W36-S
Jul 2008
The BSS allows the call to be downgraded to AMR HR if:

The FR speech versions within the permitted list from the MSC have been exhausted.
AMR HR is an available speech version in the permitted list from the MSC and the MSC
specifies that rate changes are allowed after initial assignment.
AMR HR is enabled at the BSS and cell level.
The specified CIC is AMR HR capable.
An AMR HR resource is available.
Whether downgrading from an FR speech version or an HR speech version, it is possible that

there are no resources available to provide a channel for the call supporting any of the MSC
defined speech versions. In this case the request from the MSC must be rejected. If the BSS,
exhausts the permitted speech versions list from the MSC and a channel has not been allocated
to the call, the BSS rejects the request, returning assignment failure, handover failure message
with the cause no radio resource available to the MSC.
If a TCH is already allocated to the call, as a signaling channel during immediate assignment
or a result of a previous assignment request/handover request being received from the MSC.
There is the possibility that the TCH currently assigned does not support the MSC/operator
preferred speech version. In this scenario, the BSS will first try to choose a speech version (from
the MSC speech version list) which allows the call to stay on the current TCH. Secondly, if the
BSS cannot support the call on the current TCH it attempts to allocate another TCH for the call
with the correct capabilities. This results in the possibility of the call not being allocated the
preferred/highest priority speech version. However, it will prevent the unnecessary re-allocation
of resources within the BSS.
If an assignment request is received for a call already assigned a TCH and the current TCH
cannot support any of the requested speech versions specified by the MSC, the BSS attempts to
allocate a new resource with the correct capabilities. It should be noted that, if the channel does
need to be altered to satisfy the request from the MSC, this is performed by the re-assignment
of the call to the new channel.
If an assignment request is received for a call already assigned a TCH and the current TCH can
support any of the requested speech versions specified by the MSC then highest priority speech
version supported by the current TCH is used.
NOTE
If the TCH is already supporting a speech call, this can result in the speech version
being used for the call being altered to a speech version other than the one currently
in use.
The introduction of HR capability within the BSS introduces the possibility of utilizing an HR
channel for signaling only. The use of HR channels for signaling is governed by the availability
of HR channels within a cell. The BSS allows the use of HR traffic channels for signaling when
the speech/data indicator within the channel type IE indicates signaling. When the BSS is
able to allocate an HR traffic channel as a signaling connection is dependent on the operator
and MSC preferences.
68P02901W36-S 6-115
Jul 2008
SDCCH or full-rate channel or half-rate channel request
The BSS only has the capability to assign the call to an SDCCH or FR TCH during the immediate
assignment procedure. Immediate assignment to an HR TCH is not supported. If an assignment
request is received after immediate assignment, with the option of using an SDCCH, FR or HR
channel, the BSS must already have an SDCCH or FR channel assigned to the call (assigned
during immediate assignment). The BSS remains on the current channel type (SDCCH or FR
channel).
If the channel rate and type octet of an assignment request message specifies that an SDCCH
or FR channel or HR channel is required for a signaling connection, the BSS uses the existing
resource (SDCCH or FR channel) allocated to that call. If an assignment request is received
after traffic channel assignment, with the option of using an SDCCH, FR channel or HR channel,
the BSS must already have an FR channel or HR channel assigned to the call (assigned during
TCH assignment). The BSS remains on the current channel type (HR or FR channel).
If a handover request is received, with the option of using an SDCCH, full or HR channel, the
BSS allocates an SDCCH first. If there are no SDCCH resources available a full or HR resource
is allocated, based on operator preference.
If the channel rate and type octet of a handover request message specifies that an SDCCH or
full or HR channel is required for a signaling connection, the BSS attempts to allocate resource
as defined in Table 6-20.
Table 6-20 BSS resource allocation matrix-SDCCH/full/half-rate channel specified
Channel rate A B C D E F G H
FR/HR/SDCCH N Y/N Y/N Y/N Y/N Y Y/N SDCCH
FR/HR/SDCCH N Y/N Y/N Y/N Y/N N Y FR
FR/HR/SDCCH N Y/N Y/N Y/N Y/N N N NONE
FR/HR/SDCCH Y N Y/N Y/N Y/N Y Y/N SDCCH
FR/HR/SDCCH Y N Y/N Y/N Y/N N Y FR
FR/HR/SDCCH Y N Y/N Y/N Y/N N N NONE
FR/HR/SDCCH Y Y N N Y/N Y Y/N SDCCH
FR/HR/SDlicen Y Y N N Y/N N Y FR
CCH
FR/HR/SDCCH Y Y N N N N N NONE
FR/HR/SDCCH Y Y N N Y N N HR
FR/HR/SDCCH Y Y Y Y/N Y/N Y Y/N SDCCH
FR/HR/SDCCH Y Y Y Y/N Y N Y/N HR
FR/HR/SDCCH Y Y Y Y/N N N Y FR
FR/HR/SDCCH Y Y Y Y/N N N N NONE
FR/HR/SDCCH Y Y N Y Y/N Y Y/N SDCCH
FR/HR/SDCCH Y Y N Y Y N Y/N HR
FR/HR/SDCCH Y Y N Y N N Y FR
FR/HR/SDCCH Y Y N Y N N N NONE
6-116 68P02901W36-S
Jul 2008
The columns designated A-H in Table 6-20 are as follows:

A-HR enabled at BSS.
B-HR enabled at cell.
C-amr_ force_ hr_ usage is enabled.
D-amr_ new calls_ hr exceeded.
E-HR channel free.
F-SDCCH channel free.
G-FR channel free.
H-Resource allocated
SDCCH request
If the channel rate and type octet is set to indicate that only SDCCH is required, the only impact
added due to the introduction of the HR channel mode is that the BSS supports assignment from
an HR TCH to an SDCCH. If the channel rate and type octet of an assignment request message
specifies that an SDCCH is required and the call is already established on an HR channel, the
BSS allocates an SDCCH to the call (if available). This requires a change of radio channel.
SDCCH or full-rate channel request
If the channel rate and type octet is set to indicate that only SDCCH or FR channel is required,
the only impact added due to the introduction of the HR channel mode, is that the BSS supports
assignment from an HR TCH to an SDCCH or FR TCH.
If the channel rate and type octet of an assignment request message specifies that an SDCCH
or FR channel is required and the call is already established on an HR channel, the BSS
allocates an SDCCH to the call (if available). If there are no SDCCH channels available, the
BSS attempts to allocate an FR channel (if available). Either of the previous options require a
change of radio channel.
SDCCH or half-rate channel request
If the channel rate and type octet is set to indicate that only SDCCH or HR channel is required,
the only impact added due to the introduction of the HR channel mode is that the BSS supports
assignment from an HR TCH to an SDCCH and assignment from an FR TCH to an HR TCH.
If the channel rate and type octet of an assignment request message specifies that an SDCCH or
HR channel is required and the call is already established on an HR channel or SDCCH, the BSS
stays on the existing channel. However, if the channel rate and type octet of an assignment
request message specifies that an SDCCH or HR channel is required and the call is already
established on an FR channel, the BSS attempts to allocate an SDCCH to the call (if available).
This requires a change of radio channel.
If there are no SDCCH channels available, the BSS allocates an HR channel (if available
and permitted). This requires a change of radio channel. The selection of an HR channel is
dependent on permission by the force_hr_usage element or new_calls_hr being exceeded.
68P02901W36-S 6-117
Jul 2008
Full rate channel request
If the channel rate and type octet is set to indicate that only an FR channel is required, the
only impact added due to the introduction of the HR channel mode, is that the BSS supports
assignment from an HR TCH to an FR TCH.
If the channel rate and type octet of an assignment request message specifies that an FR
channel is required and the call is already established on an HR channel, the BSS allocates an
FR channel to the call (if available). This requires a change of radio channel.
Half rate channel request
If the channel rate and type octet is set to indicate that only an HR channel is required, the
only impact added due to the introduction of the HR channel mode is, that the BSS supports
assignment from an SDCCH or FR channel to an HR channel. If the channel rate and type octet
of an assignment request message specifies that an SDCCH or HR channel is required and the
call is already established on an HR channel, the BSS stays on the existing channel.
If the channel rate and type octet of an assignment request message specifies that an HR
channel is required and the call is already established on an SDCCH or FR TCH, the BSS
attempts to allocate an HR channel to the call (if available and permitted). This requires a
change of radio channel. The selection of an HR channel is dependent on permission by the
force_hr_usage element or new_calls_hr being exceeded.
Full rate or half-rate channel required
If the channel rate and type octet is set to indicate only an FR channel or HR channel is
required, the only impact added due to the introduction of the HR channel mode is, that the BSS
supports assignment from an SDCCH to an HR channel. If the channel rate and type octet of an
assignment request message specifies that an FR channel or HR channel is required and the call
is already established on a full or HR channel, the BSS stays on the existing channel.
If the channel rate and type octet of an assignment request or handover request message
specifies that an FR channel or HR channel is required for a signaling connection, the BSS
attempts to allocate resource as defined in Table 6-21.
Table 6-21 BSS resource allocation matrix-full/half-rate channel specified
FR/HR/SDCCH N Y/N Y/N Y/N Y/N Y/N Y FR
FR/HR/SDCCH N Y/N Y/N Y/N Y/N Y/N N NONE
FR/HR/SDCCH Y Y N Y/N Y/N Y/N Y FR
FR/HR/SDCCH Y Y N Y/N Y/N Y/N N NONE
FR/HR/SDCCH Y Y Y N N Y/N Y FR
FR/HR/SDCCH Y Y Y N N Y/N N NONE
FR/HR/SDCCH Y Y Y Y Y/N Y Y HR
FR/HR/SDCCH Y Y Y Y Y/N N Y FR
FR/HR/SDCCH Y Y Y Y Y/N N N NONE
Continued
6-118 68P02901W36-S
Jul 2008
Table 6-21 BSS resource allocation matrix-full/half-rate channel specified (Continued)

FR/HR/SDCCH Y Y Y N Y Y Y HR
FR/HR/SDCCH Y Y Y N Y N Y FR
FR/HR/SDCCH Y Y Y N Y N N NONE
FR/HR/SDCCH N Y/N Y/N Y/N Y/N Y/N Y FR
FR/HR/SDCCH N Y/N Y/N Y/N Y/N Y/N N NONE
FR/HR/SDCCH Y N Y/N Y/N Y/N Y/N Y FR
FR/HR/SDCCH Y N Y/N Y/N Y/N Y/N N NONE
FR/HR/SDCCH Y Y N Y/N Y/N Y/N Y FR
FR/HR/SDCCH Y Y N Y/N Y/N Y/N N NONE
FR/HR/SDCCH Y Y Y Y/N Y/N Y Y HR
FR/HR/SDCCH Y Y Y Y/N Y/N Y N HR
FR/HR/SDCCH Y Y Y Y/N Y/N N Y FR
FR/HR/SDCCH Y Y Y Y/N Y/N N N NONE
The columns designated A-H in Table 6-20 are as follows:

A-HR enabled at BSS.
B-HR enabled at cell.
C-Changes allowed after initial allocation.
C-force_hr_usage is enabled.
D-new_calls_hr exceeded.
E-HR channel free.
F-FR channel free.
G-Resource allocated.
This requires a change of radio channel. The selection of an HR channel is dependent on

permission by the force_hr_usage element or new_calls_hr being exceeded.
Data
The use of HR channels for data is not allowed within the BSS. The BSS does not allow the
HR traffic channel to be used for data when the speech or data indicator within the channel
type IE indicates data.
68P02901W36-S 6-119
Jul 2008
Half rate channel request
As data is not supported on an HR channel within the BSS, any requests specifying an HR
channel are rejected. If the BSS receives an assignment or handover request message that
specifies that an HR channel is required for a data connection, the BSS rejects the request. To
reject the request, the BSS sends an assignment or handover failure message, with cause
value (part of the cause information element within the message) requested transcoding/rate
adaption unavailable, to the MSC.
Full rate or half-rate channel request
As data is not supported on an HR channel within the BSS, any requests specifying an FR
channel or HR channel default to FR. If the BSS receives an assignment or handover request
message that specifies an FR or HR channel is required for data connection, the BSS forces
the FR channel mode to be used.
Half rate traffic channel allocation
When selecting an idle HR traffic channel or free generic traffic timeslot to assign an AMR HR
call on, the selection criteria used by the BSS is the same as the existing criteria used for
selecting an idle FR traffic channel.
With the exception specified below, the BSS uses the existing idle FR traffic channel selection
criteria for selecting the HR traffic channel or free generic traffic timeslot for an AMR HR call
assignment. The existing criteria referenced above is the interference band, MS PGSM/EGSM
capability and TCH allocation priority considerations that the BSS uses to select idle FR traffic
timeslots for FR call assignment.
The BSS always assigns an AMR HR call to the idle HR traffic channel of a single occupancy HR
traffic timeslot in preference to assigning the call to a free generic traffic timeslot of the same
interference band class as shown in Table 6-22.
Table 6-22 Resource selection preferences
Priority Preferred channel resources

1 Idle HR traffic channel in the interference band
2 Idle generic traffic timeslot in the interference band
When AMR HR is disabled within the BSS, at the cell or BSS level, the idle generic traffic
timeslots that exist on the HR capable carrier will no longer be HR capable. In this case, the idle
generic traffic timeslots is considered as idle FR traffic timeslots.
The BSS considers a generic traffic timeslot as an idle FR traffic timeslot, if the AMR HR
functionality is disabled at the BSS or cell level. No preference will be given to resources
dependent on their HR capability.
6-120 68P02901W36-S
Jul 2008
Full rate traffic channel assignment in AMR half-rate cells
In order to conserve AMR FR and AMR HR resources where possible, the selection criteria used
by the BSS to determine which traffic channel to assign an FR call is modified. Currently, when
selecting a traffic channel for GSM FR, EFR or GSM data call assignment, the BSS always
selects a traffic channel in a lower interference band in preference to a higher interference
band. Within an interference band class, the BSS takes other criteria into consideration such
as MS PGSM/EGSM capability and TCH allocation priority. With the introduction of the AMR
HR channel mode, within an interference band class, the BSS takes into account the channel
carrier, before taking into account MS PGSM/EGSM capability and TCH allocation priority.
When selecting a traffic channel for a GSM data call as described, the BSS prioritizes channels
based on the carrier on which those channels exist. When selecting a traffic channel for GSM
data call assignment, priority is given to selecting an idle non-AMR HR capable channel.
When selecting a traffic channel for GSM data call assignment, a channel on a generic timeslot
is selected if there are no FR only channels available.
If there are no other channels available, non-AMR calls are placed on AMR HR capable channels
(generic timeslots). When selecting a traffic channel for an AMR FR call assignment, the
prioritization of channels based upon host carrier is changed. Within an interference band class,
the BSS targets AMR FR carriers in preference to non-AMR carriers.
When selecting a traffic channel for an AMR FR call, after considering interference band class
and prior to taking into account MS PGSM/EGSM capability and TCH allocation priority, the
BSS prioritizes channels based upon the carrier on which those channels exist.
When selecting a traffic channel for an AMR FR call, preference is given to selecting an idle FR
traffic timeslot on an FR AMR carrier. A generic timeslot is chosen if there are no AMR FR-only
carriers. If there are no other AMR FR channels available (that is AMR FR is disabled), an AMR
FR call is downgraded to an alternative speech version (if specified by the MSC).
68P02901W36-S 6-121
Jul 2008
EGPRS system information messages Chapter 6: Call Processing
EGPRS system information messages

System information messages
These system information messages are as defined in GSM 04.18.

EGPRS One-phase Access Capability in a cell is indicated by broadcasting support of
EGPRS Packet Channel Request.
The BSS indicates support of EGPRS in the cell setting the choice bit to 1 in the extension
information of the GPRS Cell Option IE in the Packet System Information 1 message on
the PBCCH and PACCH and Packet System Information 13 on the PACCH when at least
one EGPRS timeslot is in-service.
The BSS broadcasts support on the BCCH and PBCCH of the EGPRS Packet Channel
Request message only when the BCCH RTF in the EGPRS cell is configured on a CTU2.
The BSS indicates support of the EGPRS Packet Channel Request in the GPRS Cell Option
IE of the System Information 13 message on the BCCH when at least one EGPRS timeslot
is in-service and the BCCH RTF is assigned to a CTU2.
The BSS indicates support of the EGPRS Packet Channel Request in the GPRS Cell Option
IE of the Packet System Information 1 message on the PBCCH and PACCH and Packet
System Information 13 on the PACCH when at least one EGPRS timeslot is in-service
and the BCCH RTF is assigned to a CTU2.
Due to legacy radio processor limitations it is not possible to decode EGPRS channel
requests on legacy platforms. Consequently, it is recommended to use CTU2 carriers for
the BCCH RTF for EGPRS one-phase access support. If the BCCH RTF is not mapped to
a CTU2 then one-phase access for EGPRS mobile stations is not possible and two-phase
access is used instead, which results in performance degradation.
The BSS broadcasts the BEP_PERIOD parameter in the GPRS Cell Option IE of the System
Information 13 message on the BCCH when at least one EGPRS timeslot is in-service.
The BSS broadcasts the BEP_PERIOD parameter in the GPRS Cell Option IE of the Packet
System Information 1 and 13 messages on the PBCCH and PACCH when at least one
EGPRS timeslot is in-service.
The BSS broadcasts no support of BSS_PAGING_COORDINATION for circuit-switched

pages (set value to 0) in GPRS Cell Options field of System Information 13 on the
BCCH and Packet System Information 1 on the PBCCH and PACCH and Packet System
Information 13 on the PACCH.
The BSS sets the PFC_FEATURE_MODE bit to 0 in GPRS Cell Options field of System
Information 13 on the BCCH and Packet System Information 1 on the PBCCH and PACCH
and Packet System Information 13 on the PACCH.
6-122 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GPRS R4 compliance
GPRS R4 compliance

Supported functionality
The GPRS R4 Compliance feature makes the BSS compliant to all mandatory aspects of the
March 2003 release of the 3GPP GERAN Release 4 standards and offers the following benefits:
Supports the packet radio functionality of R4 mobiles.
Facilitates operation of optional R4 features such as Network Assisted Cell Change (NACC).
The GPRS R4 Compliance feature is unrestricted and compliance to the mandatory aspects of
the GERAN R4 specifications is unconditional.
The main functionalities supported by the feature areas follows:

Enable Packet PSI Status procedure in PBCCH-enabled cells to reduce data outage time
during full or partial acquisition of system information for example, after cell (re)selection;
when the Packet PSI Status procedure is available in a PBCCH-enabled cell, the MS can
enter packet transfer mode after acquiring broadcasts of PSI1 and a consistent set of PSI2
messages; the Packet PSI Status procedure allows the MS to request additional system
information after entering packet transfer mode.
Enable Packet SI Status procedure in cells without PBCCH to reduce data outage time
during full or partial acquisition of system information for example, after cell (re)selection;
when the Packet SI Status procedure is available in a cell without PBCCH, the MS can
enter packet transfer mode after receiving broadcasts of SI3, SI13 and, if present, SI1
messages; the Packet SI Status procedure allows an MS to request additional system
information after entering packet transfer mode.
Implement R4 GPRS/EGPRS message extensions.
68P02901W36-S 6-123
Jul 2008
Related statistics Chapter 6: Call Processing
Figure 6-43 Abstract view of packet SI/PSI status procedures
Related statistics
Refer to the Maintenance Information: GSM Statistics Application (68P02901W56) manual for a
full description of these statistics:
PACKET_SYSINFO_REQ - This statistic tracks MS requests for SI/PSI information on a
per-cell basis.
PACKET_SYSINFO_RESP - This statistic tracks the BSS responses to MS requests for

SI/PSI information on a per-cell basis.
6-124 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Enhanced Multi-Level Precedence and Preemption service (eMLPP)
Enhanced Multi-Level Precedence and Preemption

service (eMLPP)

Feature overview
The eMLPP functionality allows calls to be allocated a precedence dependent on their function.
For example, a premium rate subscriber has a higher precedence than a low tariff subscriber.
This is to allow users of high importance, emergency services or premium rate subscribers to be
given preferential treatment. The BSS uses this precedence to manage active calls in certain
situations.
The MSC allocates eMLPP priority (A, B, 0, 1, 2, 3, 4), preemption capability, preemption
vulnerability and queuing ability to the call. This is mapped by the MSC onto the 48.008 priority
format and transmitted to the BSS.
The BSS manages the MSC request using the information received within the ASSIGNMENT
REQUEST and HANDOVER REQUEST. The information contained within the Priority IE
comprises:
Priority Level
Range from 1 (highest priority) to 14 (lowest priority).
Preemption Capability Indicator (PCI)
Indicates if a call can trigger preemption of vulnerable lower priority calls. Range 0 (not
capable) to 1 (capable).
Preemption vulnerability Indicator (PVI)
Indicates whether the call is vulnerable to preemption. Range 0 (not vulnerable) to

1 (vulnerable).
Queuing Allowed (QA)
Indicates whether the call can be queued or not. Range 0 (not allowed) to 1 (allowed).
The eMLPP feature enables users to implement support for preemption within the network.
It is enabled or disabled on a per BSS basis. The introduction of eMLPP involves a shift in
the control of the preemption functionality. The MSC becomes the entity which controls the
preemption functionality.
Combinations of capabilities defined by the MSC are shown in Table 6-23.
68P02901W36-S 6-125
Jul 2008
Preemption Chapter 6: Call Processing
Table 6-23 eMLPP preemption capability mapping
BSC
MSC priority MSC PCI MSC PVI MSC QA BSS PCI BSS PVI BSS QA
Priority
X1 1 0 Z2 X 1 0 Z
X 1 1 Z X 1 1 Z
X 0 0 Z X 0 0 Z
X 0 1 Z X 0 1 Z
Where: Is:
X1 the 48.008 priority level (range: 0-14)
Z1 the 48.008 queuing allowed flag (range: 0-1)
Contained within the eMLPP feature are optional functionalities which are User-controlled
on a BSS basis:
Priority Protection of PDTCH.
Priority level based selection of functionality.
Preemption
The preemption mechanism allows a call of high priority to gain access to the BSS. Where
there are no idle resources available that can be used by the call, an established vulnerable
call of lower priority is released.
Preemption is based upon priority, the preemption capability of the incoming call and the
preemption vulnerability of the established call.
TCH Preemption
In the eMLPP GSM specifications, emergency calls are identified as possibly no longer having
the highest priority within the BSS. Therefore there is a need to guarantee access for groups
such as emergency calls.
The eMLPP functionality tracks resources within the BSC using the MSC defined priority and
using the preemption capability and vulnerability defined by the MSC.
TCH Preemption during Assignment and Handover
Four additional triggers for TCH preemption are added for the eMLPP features:
ASSIGNMENT REQUEST
For a point-to-point call
For a calling/talking subscriber of a VGC
VGC to Dedicated Handover for talker
6-126 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Preemption
HANDOVER REQUEST
IMPERATIVE INTRA-BSS INTER-CELL HANDOVER

The BSS performs preemption based upon the data defined in the ASSIGNMENT REQUEST
and HANDOVER REQUEST from the MSC. The preemption mechanism is triggered when no
resource can be found to satisfy the requirements of the incoming call and the incoming call
has preemption capability.
The TCH preemption mechanism can be triggered with and without queuing.
If triggered with Queuing, when the preempted resource becomes idle it is allocated to the
highest priority call in the queue. This can or can not be the call which originally preempted the
resource being released.
If triggered without Queuing, when the preempted resource becomes idle it is allocated to the
call which triggered preemption, see Figure 6-44. If there are any higher priority calls in the
Queue they will not be allocated to the preempted resource while the preempting call still
exists. If the preempting call cannot be found then the preempted resource will service any
calls waiting in the queue.
68P02901W36-S 6-127
Jul 2008
Ater preemption Chapter 6: Call Processing
Figure 6-44 New call preemption without queuing
Ater preemption
When the BSS is operating in EAC mode, the number of Ater resources available per RXCDR to
the BSS can be less than the maximum number of CICs that are supported by that RXCDR-BSS
combination. During congestion, it is possible that Ater resources for an RXCDR will be
exhausted. This could be due to incorrect provisioning of Ater resources, or a change in the
network penetration of MSs with restricted capabilities (for example, FR only), or a failure of
a E1 link between the RXCDR and BSC. Preemption can be employed at initial connection
(due to initial Assignment or Incoming External Handover) to guarantee allocation of an Ater
resource to a high priority call.
If the BSS is being operated in AC mode, there is a one-to-one relationship between the CIC
and Ater resources. Therefore, such congestion can only occur when there is a reduction in the
number of Ater resources for an RXCDR due to E1 failure. During E1 failure, preemption can be
triggered to guarantee allocation of an Ater resource to a high priority call.
6-128 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Queuing
Ater Preemption at initial Connection
The ASSIGNMENT REQUEST and HANDOVER REQUEST trigger points for preemption are
available when the eMLPP feature is enabled.
The triggering of preemption is applied to any call with preemption capabilities as defined by
the MSC.
Ater preemption on Intra-BSS Inter-Cell Handover
Preemption on Intra-BSS Inter-Cell Handover follows the MSC defined priority and preemption
capabilities and vulnerabilities.
This is only performed by imperative types of handover (those identified as having to be satisfied
otherwise the call will have an increased chance of being dropped). Preemption on Intra-BSS
Inter-Cell Handovers can only be triggered where the SRC resource is 8 kbps and the target
requires a 16 kbps Ater and is only valid in EAC mode.
Ater Preemption upon Ater Switchover
When a E1 link between an RXCDR and BSC fails, it can be supporting Ater resources with
active calls. To maintain voice continuity of the active calls the BSS performs an Ater switchover.
The Ater switchover procedure involves allocating alternative Ater resources for the active calls
on the failing E1 link. This procedure is time critical, the calling and called parties of the active
calls will experience loss of voice during the switchover. Any large delays produce an audio loss
and lead to dropped calls due to the calling or called parties of the active calls terminating the
call due to perceiving call failure.
The number of resources allocated upon Ater switchover can be large (maximum 248 HR calls
on 8 kbps Aters). If there are not enough idle Ater resources available, the BSS can initiate
preemption for calls that qualify. The preemption mechanism can be triggered by any call with
preemption capability defined by the MSC. As the number of calls able to trigger preemption
in this failure situation could be a maximum of 248, limits are placed on the BSS to provide a
balance between call integrity and performance.
Queuing
The BSS allows an incoming call, for which queuing is allowed (qa=1), to be queued, if no
resources are available for it and queuing is enabled at the BSS, see Figure 6-45. The BSS allows
queuing to be performed after reception of an ASSIGNMENT REQUEST and HANDOVER
REQUEST. The calls are held in the queues ranked according to priority and within each
priority level ranked by age.
Resources are queued according to the priority defined by the MSC. An emergency call is
allocated a priority level by the MSC, this priority level can not be the highest. It is therefore
possible that a call of a higher priority than an emergency call could reside in the queue and be
assigned to a resource becoming idle.
68P02901W36-S 6-129
Jul 2008
Optional eMLPP Functionality Chapter 6: Call Processing
Queuing Preemption
If the queue is full and a high priority call is required to be queued it can dequeue a lower
priority call, dependent on the priority level and internal BSS rules. The preempted call that is
dequeued is released.
Figure 6-45 New call preemption with queuing
Optional eMLPP Functionality
Priority Protection of PDTCH
The BSS allows users to assign a priority level to the switchable PDTCH to prevent circuit
switched calls with equal or lower priority to the PDTCH from stealing the PDTCH resource.
6-130 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Related commands and Parameters
Priority based selection of functionality
Users can specify a priority level threshold. Any call with an equal or higher priority than this
user-defined priority level threshold is exempt from certain BSS operations. This allows the
BSS to provide a better QoS for these high priority calls by not performing any nonessential
operations, such as:
Standard Congestion Handovers.
FR-HR Congestion Handovers.
Multiband Handover upon assignment.
Direct assignment to the secondary band of a Dual Band Cell.
Related commands and Parameters
The commands and parameters related to eMLPP are listed in the text that follows. Refer to
68P02901W23 Technical Description: BSS Command Reference manual for a full description of
commands and parameters.
Commands
disp_options - This command displays a list of restricted/unrestricted features.
disp_element - This command is used to display the option_pre-empt,

emergency_group_priority and sw_pdtch_priority parameters.
chg_element - This command is used to modify the option_pre-empt,

emergency_group_priority and sw_pdtch_priority parameters.
Parameters
enhancedMLPPOpt - This parameter indicates whether the eMLPP feature is restricted

or not in the BSS software. The value is determined by the contents of the BSS options
object and cannot be changed by the operator.
option_pre-empt - This parameter allows the operator to enable/disable the existing ECP
feature and/or the eMLPP feature.
emergency_group_priority - This parameter defines a priority level threshold for calls.

Any call with priority level less than or equal to emergency_group_priority will be
exempt from certain BSS congestion mechanisms.
sw_pdtch_priority - This parameter defines the priority level of switchable PDTCH

resources. This prevents calls with priority level greater than the PDTCH priority level
from stealing PDTCH resources.
68P02901W36-S 6-131
Jul 2008
Call setup time improvement in a GSM network Chapter 6: Call Processing
Call setup time improvement in a GSM network

Overview
During a standard voice call setup, the BSS establishes a signaling link with the MS on the
SDCCH channel, which is a shared resource. All messages transferred between the MS and the
BSS are transferred on this signaling link until the ASSIGN COMMAND message, which notifies
the MS to re-establish the call on a specified TCH.
The time required for call setup can be attributed to:

Signaling on the SDCCH being slower than that of a TCH.
Retuning of MS from SDCCH to TCH.
Establishing the main signaling link after retuning to a TCH.
This feature reduces the time required for call setup by assigning the MS directly to a TCH
during the IMMEDIATE ASSIGNMENT message, while the available TCHs for the BCCH band
are below a user-configured threshold. Once the TCH usage for the BCCH band has exceeded
this threshold, the BSS performs assignment through the SDCCH.
The benefits of direct assignment are:

Retuning the MS from the SDCCH to the TCH is avoided.
Establishing the main signaling link is only done once.
The data throughput on the TCH is faster than that of the SDCCH.
The operator configured thresholds can help avoid cell congestion due to phantom RACHs.
Data throughput times for a single MS using these channels are shown in Table 6-24.
Table 6-24 Comparison of throughput between SDCCH and TCH HR/FR
Logical channel Frame duration Data transferred Throughput

SD/4 or SD/8 235.875 ms 464 bits 1.97 kbps
TCH/H 240 ms 2784 bits 11.61 kbps
TCH/F 240 ms 5568 bits 23.2 kbps
When immediately assigning a TCH to an MS, the MS uses the TCH in signaling mode to
exchange signaling information with the BSS. In order to use that channel for speech, the MS
(and BSS) exchanges two additional messages (CHANNEL MODE MODIFY and CHANNEL
MODE MODIFY ACK) as shown in Figure 6-46.
6-132 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Fast Call Setup behavior
Fast Call Setup behavior
When Half Rate is enabled, no TCH/F is remaining and there is only one TCH/G or 1 TCH/H
remaining in the cell, the software will suspend Fast Call Setup functionalities by default even
when tch_usage_threshold=100.
It requires more than one idle TCH/G to make FCS feature work again. This is required to
accommodate call establishment scenario where MSC specifies that the call should be Full
Rate only call.
If the call is assigned to TCH/H (last TCH/G has been converted to one TCH/Hs) during
immediate assignment and MSC wants FR-only call then there would be no TCH/G to assign and
this call attempt will be dropped due to non-availability of resources. To ensure a successful call
attempt, FCS is disabled so that the call will be assigned to SDCCH and subsequently to TCH.
Figure 6-46 Fast call setup call flow
This feature interacts with the call processing features listed below.
Half-Rate and AMR Half-Rate
The fast call setup feature allows the BSS to establish voice calls directly to a TCH using the
IMMEDIATE ASSIGNMENT message to the MS. The establishment cause indicators (NECI)
allow the MS to inform the BSS of its dual rate capability during the CHANNEL REQUEST. The
RAN broadcasts its support of the NECI on the BCCH, allowing the MS to request a channel
using the new establishment causes.
68P02901W36-S 6-133
Jul 2008
Related commands, parameters and statistics Chapter 6: Call Processing
The NECI information is broadcast through SI3 and SI4 on the BCCH. The information element
cell selection parameter is where the RAN will broadcast its NECI support. The BSS always sets
the NECI field of the cell selection parameter information element of SI3 and SI4 to 1.
When paging an MS the RAN looks at the channel-needed IE of the PAGING REQUEST, if
present, from the MSC and includes it in the PAGING REQUEST when paging the MS. If
the MSC does not have this information element present, the BSS populates the information
element with any channel to allow the MS to request a half-rate channel.
PBCCH
PBCCH requires new sets of system information data to be broadcast. The NECI information
is broadcast through PSI2 on the PBCCH. The RAN will broadcast the NECI support in the
Non GPRS Cell Options IE. As part of this feature, the BSS will always set the NECI field of
the Non GPRS Cell Options IE of PSI2 to 1.
eMLPP
When immediately assigning a TCH to an MS, using the fast call setup feature, the eMLPP
features priority and queuing are changed.
If, after the available TCH threshold is exceeded, an emergency calls is requested, the algorithm
defined by the eMLPP feature is followed.
Related commands, parameters and statistics
The commands, parameters, and statistics related to Call setup time improvement are listed in
the text that follows. Refer to 68P02901W23 Technical Description: BSS Command Reference
manual for a full description of commands and parameters.
Commands
disp_options - This command displays the list of non-restricted features at the BSS. The Fast
Call feature is displayed in this list if the flag indicates that the feature is unrestricted.
Parameters
tch_usage_threshold - This parameter specifies the TCH congestion threshold in a

cell, above which the Fast Call setup feature will be disabled in that cell and voice calls
(emergency and non-emergency) will be assigned to an SDCCH.
FastCallOpt - This parameter indicates whether or not the functionality of the Fast Call
feature is unrestricted in the BSS software.
Statistics
CHAN_REQ_MS_FAIL - This statistic measures the number of failed Establishment Cause from
the MS for SDCCH, Half-Rate channel and Full-Rate channel.
6-134 68P02901W36-S
Jul 2008
Chapter
Tracing Calls and Connectivity

This chapter provides a description of the call trace functions and how it is used in fault
management and subscriber tracing.

Trace call functions on page 7-2.
Available trace call criteria on page 7-8.
Trace call triggering and sending data to the OMC on page 7-10.
Trace tailoring on page 7-12.
Cell level trace call events on page 7-13.
OMC graphical user interface on page 7-18.
OML functions on page 7-21.
Multiple trigger on page 7-24.
Timeslot connectivity on page 7-27.
68P02901W36-S 7-1
Jul 2008
Trace call functions Chapter 7: Tracing Calls and Connectivity
Trace call functions

Description
The trace call functions track an MS as it moves across the network, tracing call data of all calls
made. The MSC operator can invoke call tracing at the BSS over the A interface. The BSS
collects trace call data for either the subscriber (IMSI) or the equipment (IMEI) based upon the
invoking message. Trace call data is then forwarded to the OMC through an event interface
and stored in a file, with the data formatted as specified in 3GPP Specification GSM 12.08
recommendations.
Several expansions of the trace call functions have been made:

The BSS can accept and process trace call requests from the MSC through a GUI interface
and can have up to 16 different criteria active in a BSS at one time, as defined in 3GPP
Technical Specification GSM 08.08.
An added command allows the operator to enter in the device or function information and
obtain the connectivity information for the entered data between the BSC and the call
originating BTS. This is known as the connectivity trace command expansion.
Call traces can be started by a request from the MSC, or by the operator through the MMI.
Trace call data is always sent to the OMC, if initiated by a request from the MSC. The MMI
invoked requests can also be forwarded to the OMC. The OMC provides the support to
convert the forwarded data into the format as specified in 3GPP Specification GSM 12.08
and to store this data in trace call log files. The trace call data can also be forwarded to the
Network Management Center (NMC) if required. The BSS database and MMI command
line interface have been updated to support this feature. The trace_call command prompts
the user for various options. The command, trace_stop, is provided to support the deletion
of trace criteria and to stop the triggered traces.
The two main functions of trace call are fault management (identifying why calls are being
dropped due to RF Loss), and optimization and subscriber tracing (analyzing measurement
reports for a particular call). Trace call can also be used to locate a stolen or defective MS.
At the OMC, an environment variable provides the option to direct the incoming trace call
events to a special file location or to the current event log files. This reduces the need to keep a
rlogin session to the BSS open while waiting for the trace call information to be sent back, as a
rlogin session is needed only to start and stop the call trace.
7-2 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Forwarding trace call data to the NMC
Figure 7-1 shows trace call data forwarded dynamically to the OMC (and NMC through Q3
Agent).
Figure 7-1 Trace call expansion
Forwarding trace call data to the NMC
The trace call data can be forwarded to the Network Management Center (NMC) if required.
The OMC forwards all trace call events received per call trace to the NMC in the form of an
OSP event. The trace call events are posted on to the NMC depending on the value of the
uppermost bit (Priority Bit) of the TraceType field of the invoking event in the BSS trace record.
If this bit is set then the events will be forwarded to the NMC. Refer to the Q3 NMC interface
trace call transfer feature for further details.
Preserving BSS resources for MSC initiated traces
The operator can specify the percentage of BSS resources to be reserved for MSC initiated
traces through the call_trace_options database element. For each BSS, the maximum number
of trace calls allowed at any one time is eight. The valid values for the call_trace_options
element support the reservation of MSC initiated traces.
When the call_trace_options element has been updated, the BSS recalculates the number of
traces reserved for MSC traces. This element must be checked when the MMI sends a request
to create a trace, to verify if there is enough space to create the trace. The space is determined
by the following formula:
M P
N (%) =
100
68P02901W36-S 7-3
Jul 2008
Related commands and parameters Chapter 7: Tracing Calls and Connectivity
Where: Is:
N number of traces reserved.
M maximum number of traces per LCF (up to 8).
P percentage of traces reserved for MSC initiated traces (using call_trace_options
element).
Therefore at any given time, the following trace call slots are available per LCF:
Number of MMI trace slots available =

maximum instances-MSC traces reserved-active MMI instances-
MSC instances beyond reserved
and:
Number of MSC trace slots available =

maximum instances-active MSC instances-active MMI instances
It is also possible to have more than the reserved percentage of resource used for MSC initiated
traces as long as there are not more than 16 active traces per LCF. The reservation described
above prevents MMI traces from using resources reserved for the MSC.
Commands:
The following MMI commands are used for trace call:

trace_call - Allows the user to create a trace call instance using all of the new criteria
introduced by this feature. It generates several user prompts allowing the user to enter
the various trace criteria for a trace call instance. The trace_call MMI command enables
the trace call data to be sent to the OMC as event type messages, to the MMI, or to both.
When it is configured to be sent only to the OMC, the trace call event messages which are
sent are stored in a special trace call file location (set by environment variable, CT_LOG)
or to the current event log files. These are similar to the event and alarm messages
currently sent to the OMC by the BSS.
disp_trace_call - Displays the multiple trace call instances and all of their criteria, as well
as a specific instance identified by its trace reference number. It includes the mode, value
and trace data currently enabled in the BSS and the destination of the trace report.
trace_stop - Delete trace criteria, stop a trace on an individual call given an SCCP
number, delete a trace immediately or when all triggered traces complete, using the trace
reference number.
chg_element, chg_cell_element, disp_element - Changes any of the parameters or

displays their settings.
7-4 68P02901W36-S
Jul 2008
Parameters:
The following database parameters are used for trace call:

trace_msgs_before_ho - Specifies the number of messages that the system collects
immediately before a handover.
trace_msgs_after_ho - Specifies the number of messages that the system collects

immediately after a handover.
auto_rf_loss_trace - Enables or disables automatic RF loss tracing for a cell.
call_trace_options - Enables, reserves space for, or disables Phase 1 and Phase 2 MSC
trace calls for the entire BSS.
ct_flow_control_hi_level - Specifies the percentage of the trace call OML buffer space
that can be used before trace call flow control is enabled. When this limit is reached,
the BSS parameter ct_flow_control_bss_enabled is set to 1. (This level is not used to
disable flow control).
ct_flow_control_lo_level - Specifies the percentage of trace call OML buffer space that
can be used before flow control is enabled. When this limit is reached, the BSS parameter
ct_flow_control_bss_enabled is set to 0 (this level is not used to disable flow control).
call_trace_options - When the call_trace_options element has been updated, the

BSS recalculates the number of traces reserved for MSC traces. See Installation and
Configuration: GSM System Configuration (68P02901W17) manual for further details.
The following parameters are used by the trace call system but are not stored in the BSS
database and therefore cannot be directly set by the operator. However, the settings are visible
to the operator by use of the disp_trace_call command.
ct_flow_control_msc_trace - Specifies whether or not MSC initiated traces are allowed
when flow control is enabled.
ct_flow_control_bss_enabled - Specifies whether the BSS has enabled or disabled flow

control.
System impact
The amount of disk storage space needed on the OMC for the trace call utilities and the trace
call event logs is a maximum of 50 Mb. There is no extra memory (RAM) required on the
current OMC.
The triggering capability for the IMSI, IMEI and TMSI depends on the system configuration.
IMEI is available only from a mobile, with no SIM, making emergency calls. IMEI is available
only if the TMSI is not used.
The user should take care when using trace call function. If the user requests excessive
amounts of trace data, the BSS and OMC performance will degrade. Some trace data will be
discarded to preserve system integrity.
68P02901W36-S 7-5
Jul 2008
Trace call suggestions Chapter 7: Tracing Calls and Connectivity
A heavy burden is placed on the network when the user specifies all data types, a measurement
report interval of 1 and 16 simultaneous calls traced per LCF. It is therefore recommended that
the following guidelines not be exceeded when requesting full data tracing (that is, all data with
measurement report interval = 1):
Maximum number of calls simultaneously traced at the OMC <= 8
Maximum number of calls simultaneously traced per BSS <= 4
NOTE
This limit must be enforced by the user, since the maximum simultaneous calls
traced per LCF limit specified during trace creation is the limit per LCF and a BSC
will typically contain several LCFs.
Maximum number of calls simultaneously traced per MMI TTY <= 2
The user is advised to avoid sending trace data to the OMC when other significant OML
activities, such as uploads and downloads, are occurring. A high call load on the BSS will also
adversely affect the trace call performance.
In general, users can trace a larger number of calls simultaneously by limiting the amount of
data requested for each call.
For example:
For a moderately loaded (2500 cph, 10 s hold time) single LCF system, the following criteria
would not normally result in loss of trace data:
Measurement Report Interval = 10
Data Types: all
Nth call interval = 1
Maximum simultaneous calls per LCF = 8
The auto_rf_loss_trace parameter provides the option to forward the RF loss trace data to the
OMC as special event messages. This replaced the existing per BSS auto_call_trace_options
element.
Trace call suggestions
Specify only the needed data types. RSS data produces the most output. Abis data can also
produce a lot of data, particularly during call creation, handover and completion.
Use the Total number of calls to be traced field to limit the total amount of data
collected.
When specifying RSS (measurement report) data, choose a measurement report interval
greater than 1 (the default is 10).
7-6 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Trace call suggestions
For Nth call trace:

specify a large number for N (for example, 50).
specify a small number for the maximum number of traces per LCF (for example, 2).
Trace on a particular MS, subscriber or call whenever possible.
Use the trace_disp command to monitor the number of calls being traced.
Trace outside of peak call periods whenever possible.
Stop or reduce tracing when performing code/database uploads and downloads.
Delete unwanted trace logs from the OMC. A UNIX cron task periodically deletes old logs.
However, heavy trace call usage can necessitate more frequent attention.
Each trace triggered, provides all the available data. Trace call has safeguards installed
in the agent process at the BSS and the SMASE process at the OMC, to detect overflow
conditions and cut back the amount of trace data being processed.
68P02901W36-S 7-7
Jul 2008
Available trace call criteria Chapter 7: Tracing Calls and Connectivity
Available trace call criteria

Specifying
Trace call criteria are specified by the MSC and/or the MMI (set through the trace_call
command) to create a trace call instance in the BSS. The BSS then uses the criteria to determine
whether a trace should be triggered for a particular call in that BSS. These trace call criteria are
categorized into five areas as follows:
Scope.
Triggering events.
Call selectors.
Record types.
Trace tailoring options.
Before a trace will be triggered for the call, the scope, triggering events, call selectors and
record types must be specified. The trace tailoring options provide more options to create a
trace call instance, but is not a prerequisite for the creation of a trace call instance.
Scope
The scope specifies the level at which the BSS triggers a trace on a particular call (either by
originating in or by handing into the scope). The scope of the trace can be set to a specific RTF
(Carrier), Cell, Site, or BSS. The trace can be set to continue or terminate after the call has
left the scope where the trace was originally triggered under. A trace call invoked by an MSC
always continues when it leaves its current scope.
Expanding the criteria for tracing
Users can tailor a particular trace call to their needs. Examples of this flexibility are:
Add site and carrier levels of trace call scope to the existing BSS wide and cell level scope.
Specify whether a trace is to continue or terminate when the call leaves the scope of the
trace criteria.
Stop all future triggers for a trace call, while allowing all previously created trace instances
to continue tracing.
Terminate the invoked traces for a particular trace call instance in the BSS, while still
leaving the trace call instance active in the BSS.
Specify the rate to collect measurement report data on a per trace call basis instead of per
cell.
7-8 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Scope
Specify a time interval in which trace calls can be triggered for a particular trace call
instance.
Enter total calls to be traced.
Enter maximum simultaneous traces per LCF for Nth trace calls.
Limit the collection of trace data to a period immediately before and immediately after a
handover.
68P02901W36-S 7-9
Jul 2008
Trace call triggering and sending data to the OMC Chapter 7: Tracing Calls and Connectivity
Trace call triggering and sending data to the OMC

Trace instance
A trace instance is created if:

It receives an MSC Invoked Trace (Phase 2) or a trace invocation (Phase 1) request from
the MSC.
The user uses the trace_call command through the MMI rlogin to the BSS to define the
trace requirements.
The trace triggers according to the criteria defining it. The trace call event messages are always
sent to the OMC if the request comes from the MSC. The operator has the option of sending
MMI invoked traces to either the OMC or both the OMC and the MMI. The trace call event
messages are sent over the OML in binary (ASN.1) format using CMIP. The OMC converts the
trace call data to the format specified in 3GPP Specification GSM 12.08 format and stores it
in trace call log files. The trace call data can also be forwarded to the Network Management
Center (NMC) if required.
The environment variable CT_LOG if set, specifies the directory in which the trace call Events
are stored. If this environment variable is not set then the trace call logs are stored in the
directory specified by EV_LOG. The trace call logs are named ct<yymmddhhmmss>. When
event logging is disabled at the OMC the trace call events will not be stored, regardless of
whether or not the CTLOG environment variable is set.
The trace call events cannot be loaded into an ELSP window and cannot be seen in an event
window. All the OMC does with trace call events is log them to the current trace call log file.
There is no other OMC GUI impact as all the processing is done by the trace call product utilities
which provide the facility to interrogate the trace call event data log files.
Trigger events
The trigger event indicates to the BSS when to trigger a trace for a call that is within the scope
and that matches the call selector. Trigger events can be:
Call setup
A trace is triggered for every call that originates in the specified scope and matches
the call selector. This trigger event encompasses both mobile originated and mobile
terminated phone calls.
Call handover
A trace is triggered for every call that hands in to the specified scope and matches the call
selector.
Any origin
When the trigger event is set to any origin, a trace can be triggered by a call originating
in or handing in to the desired scope, or by existing calls.
7-10 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Call selectors
Call selectors
The call selector provides the BSS with the ability to designate a particular call or MS to
trigger a trace as long as the triggering event for the call occurred in the specified scope. The
different call selectors are:
IMSI number.
TMSI number.
IMEI number.
IMEISV number.
SCCP number.
Nth call (call value must be between 1 and 255 inclusive).
Record types
The trace record type informs the BSS what type of data to collect. The possible record types
comply with what is defined in 3GPP Specification GSM 12.08 and are as follows:
Basic.
Radio.
Handover.
MSC requested trace can specify any of the above record types. Traces requested from the MMI
(using the trace_call command) can only choose a subset of the data types contained in Radio
(DTAP, BSSMAP, Abis, RR, RSS and MS_Power).
The record types radio and handover both contain all BSSMAP, DTAP, RR, Abis, MS power
control and measurement report data. The only difference between radio and handover is that
for handover, a specific number of messages are collected for a specific time before and after
a handover. Collecting data for a specified period around a handover will not be addressed
until future releases of this feature.
68P02901W36-S 7-11
Jul 2008
Trace tailoring Chapter 7: Tracing Calls and Connectivity
Trace tailoring

Options
The trace tailoring options provide the user with more options to fine tune the creation of a
trace call instance. The options are as follows:
A daily interval
This takes the form of a start and stop time in which traces can be triggered for that instance.
For example, if a user specifies a trigger activation time of 8:00 and a trigger deactivation time
of 10:00, traces will only trigger between the hours of 8:00 and 10:00 and all other criteria are
met. Note that traces such as this, that have defined an active trigger period, are not deleted
automatically at the end of the period. The interval repeats daily if the criteria is not deleted.
Total number of calls
The trace call instance will be deleted automatically from the BSS when the number of calls
traced for the instance reaches the total number of calls specified. If the total number of calls
is not specified, calls will be traced for the instance indefinitely or until the user deletes the
instance.
Measurement report (RSS) data
Specifying this interval allows the user to control the number of measurement reports that are
included on a per trace call instance basis. The default interval is 10 which is every 480 ms.
Maximum simultaneous number of calls
Applies only if the call selector is set to Nth call
This allows the user to control the number of traces triggered for an Nth trace call such that
other trace call instances trigger traces concurrently. If the maximum simultaneous traces are
not specified, the BSS takes a default value of one. The upper limit is eight for the LCF. This
could potentially trigger all eight traces preventing other trace instances from getting triggered.
7-12 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Cell level trace call events
Cell level trace call events

Function
Cell level trace call events enhance the trace call function by providing the option to forward
trace call information to the OMC in the form of event messages which are then stored in the
OMC. This is an alternative to sending the trace call information to the MMI. Once sent to the
OMC, the trace call data is stored in a log file which can then be analyzed using the Call Trace
Product (CTP) utilities which provide the facility to interrogate the trace call event data log files.
Once a day, as a cron job, a CTP_DA utility runs through the newly received trace call files
extracting relevant data. This utility is automatic, although it can also be run manually. For
each parameter a count is maintained of each value detected, thereby building up distributions
over an extended time period. Three other utilities are based on TCL/Tk scripts, which produce
reports on the extracted data. These are accessible through the command line interface. The
three main functions provided by these utilities are:
Accumulation of measurement report data over an indefinite period.
Decoding and textual representation of the trace call data.
Statistical analysis of the presently held trace call data.
The two main uses of trace call are fault management (identifying why calls are being dropped
due to RF Loss), and optimization and subscriber tracing (analyzing measurement reports for a
particular call) shown in Figure 7-2.
68P02901W36-S 7-13
Jul 2008
The trace call event messages Chapter 7: Tracing Calls and Connectivity
Figure 7-2 Cell level trace call events
MMI paramet er s a er availableto the trace

callMMI co w hich enablethe
trace calldata to be sentto the O MC .
U tilities
are providedattheO MC to
c s te a s ore in the race call.
Trace call can be triggered on a per cell level. The triggering mechanisms are described in
Multiple trigger trace call events.
The trace call event messages
The trace call event message sent to the OMC from the BSS contains the following data:
The time that the last trace call record in the event was generated.
Cause field which identifies whether the event is due to RF loss trace or a trace call.
In the case of an RF loss trace event, the value of the cause field will contain the reason
for the RF Loss.
Multiple RSS or BSSMAP/DTAP data records.
The BSS buffers 9 RSS data records and 12 BSSMAP/DTAP data records before sending a
notification event.
Device instance-the carrier (RTF) that the call was on, when the trace call data was
generated.
MS ID.
Current cell id (the cell that the call was in, when the trace call data was generated).
7-14 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Benefits of using trace call events
SCCP number assigned to the call being traced.
Circuit identification code (CIC) used to connect to the MSC.
Destination local reference (DLR).
Current interference band.
Requested interference band.
Channel description.
All fields in the trace call event notification message sent to the OMC are valid for all data
records that are in the notification. For example, if there are 5 data records in the notification
message, all 5 will have been generated while the call existed in the Cell that is identified in the
current cell id field in the notification message.
Benefits of using trace call events
The trace call event messages are sent over the OML in binary format. This reduces the data
throughput of the OML. When using a rlogin session for a trace call, ASCII data is sent to the
OMC through the rlogin session, significantly more data is being sent across the OML than if
binary data were sent (the number of bytes needed to send a single measurement report to the
OMC reduces from approximately 544 bytes to approximately 121 bytes by sending the data
in binary form).
The single remote login session can be utilized for different purposes other than trace call
because with this enhancement the rlogin session is needed only to has only to start and stop
call traces.
The Measurement Report Analysis (MRA) tool is also used by customers to analyze measurement
reports generated from filters set at the BSS. A customer typically connects a PC running the
MRA tool to a GPROC at the BSC and then starts a filter to gather measurement report data.
Defining the data sent in a trace event
The data sent in a trace event is compliant with 3GPP Specification GSM 12.08.
Elements without a time stamp
Some elements in a trace record that cannot change value during the life of a trace are only sent
once in a trace record. These are defined by 3GPP Specification GSM 12.08 and are as follows:
Transaction ID (only sent for MSC initiated traces).
Trace type (only sent for MSC initiated traces).
OMC ID (only sent for MSC initiated traces).
Start time (must always be sent for a trace).
End time (must always be sent for a trace).
68P02901W36-S 7-15
Jul 2008
Defining the data sent in a trace event Chapter 7: Tracing Calls and Connectivity
Mandatory elements with a time stamp in one trace record
The following elements, defined by 3GPP Specification GSM 12.08, must appear with a time
stamp in at least one trace record sent regardless of the trace record type:
IMSI/TMSI or IMEI/IMEISV-MS ID (must always be sent for a trace).
Base Transceiver Identification (BTS ID) - This is the cell identifier.
Cell name is not passed, since the OMC (and MMI) can access this information, given
the cell number.
Transmitter/receiver Identification (RTF/DRI ID).
Radio channel description.
Base Station Identity Code (BSIC).
Elements with a time stamp when available
The following elements, defined by 3GPP Specification GSM 12.08, must appear with a time
stamp when they are available in at least one trace record:
Channel Release Reason (RR)-reported when a channel is released and an RR cause value
is available. (Sent regardless of the value for the trace record type).
Mobile station classmark I, II and III (regardless of the trace record type).
Circuit Identification Code (CIC) (regardless of the trace record type).
Mobile station power (radio or handover record types only).
Base station power (radio or handover record types only).
Timing advance (radio or handover record types only).
Handover cause (radio or handover record types only).
Handover result (radio or handover record types only).
Handover duration (radio or handover record types only).
Target cell list (radio or handover record types only).
BSSMAP messages (radio or handover record types only).
DTAP messages (radio or handover record types only).
RR messages (radio or handover record types only).
Measurement reports (radio or handover record types only).
Abis messages and selected Mobis messages (radio or handover record types only) that
conform to 3GPP Technical Specification GSM 08.58.
MS power control messages (radio or handover record types only).
7-16 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BSS level RF failure trace call events
BSS level RF failure trace call events
A BSS level RF failure event is generated on the occurrence of an MS RF loss when BSS level
trace call is enabled at the BSS, as shown in Figure 7-3.
Figure 7-3 BSS level RF failure trace call events
A database element is available, auto_rf_loss_trace, which can be set for a particular cell which
specifies whether or not the RF loss tracing is enabled or disabled for the cell. The element can
be set so that on occurrence of an RF loss, the last valid measurement report generated for
the call can be either sent to the MMI (in ASCII format), to the OMC as an event message (in
binary format), or both. These are stored in a file location, as described in Cell level trace
call events. The ASCII measurement report sent to the MMI and the event sent to the OMC is
processed in the same way as the output for the trace_call command.
For the RF loss messages to be automatically sent, call tracing must be set for that cell, as it
uses the call tracing functionality (RF failure is one of the triggers used in trace call).
The RLM cause for the RF Loss has been added to the output for the RF loss trace.
A per BSS element, call_trace_options, is used to enable and disable Phase 1 MSC call
traces for the entire BSS.
68P02901W36-S 7-17
Jul 2008
OMC graphical user interface Chapter 7: Tracing Calls and Connectivity
OMC graphical user interface

Expansion function
The expansion of trace call introduces additional functionality within the BSS which allows the
OMC to provide a graphical user interface for trace call. Trace call data is sent to the OMC and
saved in a format that can be easily displayed and accessed by the user.
On receipt of the first CallTraceDataEvent (or creation event), the OMC begins managing
the data for a particular trace and stops when the final event associated with that trace has
been received.
On receipt of a CallTraceDataEvent, the OMC:

Creates a unique trace call object instance (this is an internal OMC object) associated
with that trace.
Creates a unique log file, if it does not already exist. This is used to log the trace call
data being received. If the relevant log file already exists, it writes in the trace call data
pertaining to that call.
The MMI command line interface is also updated by a command to stop traces: trace_stop.
The trace_call command prompts are updated accordingly.
At the OMC GUI, the trace call feature has a number of windows available. These help the user
to view the traces, view trace records, delete traces and so on. The following windows are
available:
Trace view.
Trace criteria setup.
Invoked trace list.
Trace record view.
Trace view window
This is the first window which appears when the user invokes trace call from the OMC desktop.
All the traces are displayed to the user in this window. The status field of this window shows
one of the values: Active, Deactivated, or Completed. Active traces are those which can still
invoke new instances, whereas Deactivated traces have been deactivated by the user and they
can not invoke any more new instances. All existing invoked instances for a trace terminate
when the call completes or the user intervenes.
7-18 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Trace criteria setup window
Trace criteria setup window
This window helps the user to specify the criteria for a new trace. The user must first specify the
trace selector and the selector value. The trace selector appears as a menu of options, as follows:
Nth Call: selector value is the nth call.
IMSI: selector value is the IMSI number.
TMSI: selector value is the TMSI number.
IMEI: selector value is the IMEI number.
IMEISV: selector value is the IMEISV number.
SCCP #: selector value is the SCCP number.
The user then needs to decide on what the triggering event would be, that is, what should
trigger the trace. This could be either; call setup, hand in, or any origin.
The user then needs to decide on the kind of trace data that the BSS should send to the OMC.
By default, the BSS only sends basic trace records. The user can choose from basic, handover,
or radio record types. Additionally, the user can opt for one or more message types; BSSMAP,
DTAP, Motorola Abis, Radio Resources, or RSS.
NOTE
The above is true for traces invoked from the OMC GUI and MMI. An MMI invoked
trace does not use the same data types, but uses the component data types as options.
The next step is to specify the scope of the trace. The scope identifies the BSS, site, cell, or RTF
under which the trace will be active. The user has to enter values for the BSS-site-cell in the
case where the trace should be active below a cell and values for BSS-Site in the case where
the trace should be active below a site. The trace can be continued beyond the specified scope
in the case where it originates at either the site, cell, or RTF.
The user also has the option of specifying the duration in which the trace will be active. In the
case where such a duration is specified, traces are only invoked if all other criteria are met
and the time is within the daily trace duration window specified, that is, between the daily
enable and disable times.
Finally, the user can specify that this trace should not trace more than a certain total number of
calls. In the case where the trace selector is the Nth Call, the maximum number of simultaneous
calls traced can also be specified.
Once all the criteria are set up, the user can activate the trace by clicking on the Activate button.
68P02901W36-S 7-19
Jul 2008
Invoked trace list Chapter 7: Tracing Calls and Connectivity
Invoked trace list
Once the criteria have been specified and the trace has been activated, various instances of this
trace will be invoked. Each invoked instance is actually for a call, which has a unique SCCP
number associated with it. Therefore, a combination of BSS ID, trace reference number and
SCCP number identify a particular invoked instance for a trace. The user is able to view either all
calls, completed calls, or calls in progress from the view menu option on the trace view window.
Trace record view window
This window is used to display trace records to the user in ASCII format. Trace records can be
shown for a particular SCCP number for a particular set of trace criteria.
7-20 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation OML functions
OML functions

OML Out-of-Service
If the OML is out-of-service, the BSS does not buffer trace call event notifications that were to
be sent to the OMC. The reason is that alarm report events and state change events are high
priority events that are buffered when the OML is not in service. Important operator information
could be lost if trace call events are buffered and begin to overwrite alarms and state changes
when the buffer fills. If there is no OML connected to a BSS and a trace call event is to be sent
to the OMC, the BSS will not report an error when an attempt is made to send the event.
Flow control by OML buffer availability
Flow control is introduced to improve the performance of the OML, the BSS and/or the OMC
during tracing calls. The increased amount of data that is passed over the OML as a result of
the implementation of this feature, would have a significant impact on the performance of the
OML, the BSS and/or the OMC. The increase in the amount of data results from increasing the
number of active traces that can exist in the BSS at a time.
It is possible for the user to request excessive amounts of trace call data; under such conditions
the BSS and OMC has to discard excess trace data in order to preserve system integrity. This
random loss of trace data is undesirable, because trace records could become incomplete
and therefore unusable. Also, the tracingcan have an undesirable load on other parts of the
system. Flow control aims to reduce or eliminate data loss for existing traces while reducing
the future load on the system due to trace call. Flow control is achieved by the temporary
suspension of triggering and the dynamic adjustment of the trace call criteria by the BSS.
The BSS will sense when overflow is imminent, by monitoring OML buffer availability and
automatically enable flow control when OML buffer usage exceeds a user-defined level. The
OMC can request that flow control to be turned on or off. MSC traces can be allowed during
flow control at the user's discretion.
Caution should be taken when determining the number of call traces that are to be concurrently
on multiple BSSs connected to the same OMC. The impact that this amount of data has on the
OML is variable, but a large amount of data generated by numerous call traces coupled with
other network traffic (for example, uploads, downloads and other events) can have a detrimental
impact on the performance of the OML.
Trace call flow control enabled
When flow control is enabled, the BSS:

Disables the triggering of all new traces.
Prevents the creation of all new trace criteria.
Permanently doubles the value of N for certain Nth call traces.
Permanently halves the number of simultaneous traces allowed for certain Nth call traces.
68P02901W36-S 7-21
Jul 2008
Flow control by OML buffer availability Chapter 7: Tracing Calls and Connectivity
MSC traces are excluded from flow control restrictions using the ct_flow_control_msc_trace
database parameter. Only Nth call traces that have triggering enabled and that have already
triggered at least one trace (and therefore contributed to the loading of the system), are updated.
When flow control is disabled, the BSS:

Allows the triggering of new traces.
Allows the creation of new trace criteria.
The original values of the trace criteria are not restored, because this could cause further
overloading.
The BSS must be able to handle overlapping requests, when both the BSS and the OMC wish to
disable or enable flow control. A logical OR describes how flow control is turned ON and OFF in
response to flow control requests from the OMC and the BSS.
The BSS ON condition reflects both the enabled and halt conditions by the BSS.
When flow control is enabled, the BSS:

Does not allow new trace criteria to be created from the BSS MMI.
Does not allow new trace criteria to be created from the OMC unless the database
attribute ct_flow_control_msc_trace indicates that new MSC traces are permitted while
flow control is enabled.
Does not allow triggering of new traces for existing trace criteria.
Notifies the OMC of any changes to the trace call criteria.
Identifies all Nth call trace criteria that have already triggered at least one trace and for
which triggering was not stopped, as candidates for update. The BSS doubles the value
of N for each of these sets of trace criteria and halve the number of simultaneous traces
supported by these sets of trace criteria. Only trace criteria that contributed to the OML
load are updated. The value of N is not updated for Nth call traces that are permanently
deactivated by a trace_stop command.
Trace call flow control disabled
When flow control is disabled, the BSS:

Allows new trace criteria to be created.
Allows triggering for all trace criteria that have not already been permanently deactivated
by a trace_stop command. Attribute change notifications will be used to notify the OMC
of changes in call trace criteria. These notifications will be sent for OMC-initiated flow
control as well as for BSS-initiated flow control.
7-22 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation OMC initiated flow control
OMC initiated flow control
The BSS accepts updates to the ct_flow_control_omc_enabled BSS parameter from the OMC
and immediately enables or disables flow control at the BSS accordingly. This parameter state is
set by the OMC automatically. It is used in combination with the ct_flow_control_bss_enabled
parameter to determine whether flow control is enabled. This parameter is reset to 0 when
the BSS is reset, but it is not persistent. It is not stored in the BSS database and cannot be
changed manually by the operator. The parameter is not supported by the chg_element or
disp_element command, however the disp_trace_call command displays whether or not flow
control is enabled or disabled and by whom. Valid values for this BSS parameter are:
0-flow control has not been enabled by the OMC (default).
1-flow control has been enabled by the OMC.
BSS internal flow control
Overflow conditions can occur at the BSS without overflow conditions being reached at the OMC.
Consequently an internal flow control mechanism exists within the BSS. The BSS establishes
an OML buffer for trace call data, which is not used for rlogin or code load messages. The
OML trace call buffer can be shared with high priority event data. The BSS establishes a high
threshold for call trace data destined for the OML, beyond which flow control is enabled and a
low threshold for trace call data destined for the OML, below which flow control is disabled. The
high and low thresholds can be set by the user through database parameters. Flow control uses
the hysteresis provided by these two levels to avoid rapid oscillation in the flow control state.
The BSS has the parameter ct_flow_control_bss_enabled, to specify whether the BSS has
enabled or disabled flow control. This parameter state is set by the BSS automatically. It is used
in combination with the ct_flow_control_omc_enabled parameter to determine whether flow
control is enabled. The parameter is reset to 0 when the BSS is reset-it is not persistent. It is
not stored in the BSS database and cannot be changed manually by the operator. The parameter
is not supported by the chg_element or disp_element command, however the disp_trace_call
command displays whether or not flow control is enabled or disabled and by whom. Valid
values for this BSS parameter are:
0-flow control has not been enabled by the BSS (default).
1-flow control has been enabled by the BSS.
2-flow control has been halted by the BSS.
The BSS notifies the OMC that it has enabled or disabled internal flow control by updating the
ct_flow_control_bss_enabled parameter. If flow control is enabled due to high priority events,
not trace call data, the BSS does not alter trace call criteria.
If the BSS trace call buffer overflows after flow control has been enabled, the BSS stops
producing trace call data. If flow control is not quick enough to prevent overflow of the trace call
buffer, the BSS stops producing trace call data and blocks any new trace triggering and criteria
creation. Trace call data destined for the MMI is also stopped, as MMI data will travel over the
OML if rlogin is used. Triggering, criteria creation and data transmission are re-enabled (that
is, flow control is disabled) as usual, when the low threshold is reached.
The BSS determines the reason for flow control being enabled.
The BSS stops production of trace call data whenever the virtual circuit for OML events goes
out-of-service and disables trace call flow control every time the virtual circuit for OML events
comes in service.
68P02901W36-S 7-23
Jul 2008
Multiple trigger Chapter 7: Tracing Calls and Connectivity
Multiple trigger

Function
Multiple trigger trace call events is a feature that enhances the trace call function by providing
a finer trigger scope for trace call. Currently the scope of triggers is down to the LCF level,
which results in all cells under that LCF having the same trace triggers enabled. This feature
allows triggers to be set on a cell level and multiple cell level. All current triggering capability is
supported on a per cell or per BSS (LCF) level:
Every Nth call.
SCCP connection number.
RF failure loss.
IMSI number.
IMEI number.
TMSI number.
The user can selectively trace calls in a certain number of cells for the same trace criteria as
long as the criteria is Nth call. If the BSS receives a request to initiate a trace call with the
criteria set to Nth call and no cell is specified, all cells in the cell list will be removed and the
instance will become a BSS wide trace call, as shown in Figure 7-3.
If a user enters a trace call command to stop a trace call having the Nth call criteria, the trace
will be stopped for all cells that are in the cell list for that trace call criteria.
The BSS supports call tracing in as many as 16 specific cells simultaneously when the operator
requests a trace call with the trace criteria being Nth call.
The maximum number of calls that are allowed to be traced per LCF in the BSS is 16.
If the BSS has an active trace call instance with the criteria set to Nth call for a specific cell
and the user enters another trace_call command for Nth call with a different cell specified,
the BSS adds the new cell to the list of cells being traced. If the number of cells in the list is
already 16, the new cell will replace the cell that has been in the list the longest. The newly
entered command will also overwrite the types of data collected and the rate at which traces
are triggered.
Recent enhancement enables the user to have up to 16 different criteria active in the BSS
simultaneously. Prior to this only one type of trace call criteria could be active in the BSS at any
time. For example, if a customer desired to trace every Nth call in a cell and a specific mobile
subscriber, the current system would only allow the customer to do one task at a time. This
enhancement allows the user to perform different tasks such as subscriber observation and
network optimization concurrently.
7-24 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Information contained in call traces
Information contained in call traces
Once the trace is created, the BSS sends an event containing notification of the newly created
instance to the OMC. These creation events sent to the OMC always contain the following to
indicate the criteria used for the trace call instance:
Trace reference (the instance identifier).
Trace scope.
Trace record type(s).
Trace selector and value.
Trace trigger type.
Maximum number of traces (optional).
Maximum simultaneous traces-Nth call only (optional).
Whether to continue tracing out of scope.
Trigger enabled time (optional).
Measurement report interval (optional).
Thereafter, every trace record sent to the OMC must contain the following information to
allow the OMC to distinguish between traces:
Trace reference (Instance Id) - to distinguish between instances.
SCCP number - to distinguish between triggered traces for an instance.
Trace record sequence number - allows the OMC to verify that it has received every
trace record.
When a trace is completed on a call, the last trace record sent by the BSS always contains a last
record indicator to inform the OMC that it is the last record sent for the call being traced. The
trace call instance is then deleted from the BSS.
If the BSS receives a request to delete a trace call instance, the BSS first finds the instance
according to the specified trace reference number, it then terminates all traces that were
triggered for the specified instance and then deletes the instance.
68P02901W36-S 7-25
Jul 2008
Call trace product utilities Chapter 7: Tracing Calls and Connectivity
Call trace product utilities
The Call Trace Product (CTP) utility can be run through the command line or accessed through
the CTP utility GUI. Functions are as follows:
CTP_collect.
CTP_read.
CTP_stats.
CTP_decode.
CTP_monitor.
Once a day, as a cron job, a CTP_DA utility runs through the newly received trace call files
extracting relevant data. This utility is automatic, although it can also be run manually. For each
parameter, a count is maintained of each value detected, thereby building up distributions over
an extended time period.
CTP GUI
Once the CTP utilities have been installed at the OMC, the CTP GUI can be run which provide
GUI based front-ends to the different CTP utilities as shown in Table 7-1.
Table 7-1 The CTP GUI
CTP utilities GUI based front-ends
Decode: CTP_decode <<options>>

Monitor: CTP_monitor <<options>>
Collect Distributions (long term) CTP_collect <<options>>
Display Distributions (long term) CTP_read <<options>>
Distributions (current) CTP_stats <<options>>
Combined Distributions (current) CTP_stats <<options>>
Count BSSAP Messages CTP_stats-total <<options>>
7-26 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Timeslot connectivity
Timeslot connectivity

When the MMI command trace_connection is entered, MMI procures the timeslot connectivity
information from the CM software process. The command allows the operator to enter in device
or function information and obtain the connectivity information for the entered data between
the BSC and the connection terminating site. Since this command is only concerned with
the connectivity, modes of the BTSs (being either static or dynamic) have no impact on the
information displayed. The list of devices or functions with which the command can be used are:
RSL.
GSL.
CIC.
OML.
XBL.
MMS.
MTL.
If the command is executed for MMS, there is an additional field in the display called timeslot
usage. If the MMS timeslot is being used for RTF, RSL-RTF, 16 k RSL, 64 k RSL, MTL,
OML, XBL, XBL-CIC, CIC, DYNET or GSL, the timeslot usage field will display the names of
corresponding devices. If the MMS timeslot is not being used for any of the devices or functions
listed above, the timeslot usage field will display:
INTERNAL Device or Function.
If the MMS timeslot is being used for an RSL or an RTF, Path ID for the RSL or the RTF is
also displayed.
Related command and parameters
The trace_connection MMI command is used for connectivity trace. It allows the user to enter
in device or function information and obtain the connectivity information for the entered data
between the BSC and the connection terminating site.
68P02901W36-S 7-27
Jul 2008
Related command and parameters Chapter 7: Tracing Calls and Connectivity
7-28 68P02901W36-S
Jul 2008
Chapter
Power and Handover Control

This chapter provides a description of the BSS power control and handover control functions.
Power can be increased to improve quality and decreased to save battery life. Handovers can
occur due to power or quality degradation.

Power control on page 8-3.
Fast initial MS power down on page 8-13.
Quality measurement reporting on page 8-16.
Missing report on page 8-18.
Handover decision process on page 8-19.
BA lists on page 8-43.
RXQUAL handover on page 8-45.
Inter-BSS handover on page 8-48.
Inter-BTS handover on page 8-56.
Intra-Cell handover on page 8-60.
Adaptive power handovers on page 8-66.
Handovers in single BCCH dual band cells on page 8-68.
Multiband inter-cell handover on page 8-76.
Adaptive Multi-Rate (AMR) multiband handover on page 8-79.
Coincident multiband handover on page 8-80.
Advanced load management for EGSM carriers on page 8-86.
Intelligent Multi-Layer Resource Management (IMRM) on page 8-88.
Flexible neighbor cell processing on page 8-92.
Microcellular handovers on page 8-95.
68P02901W36-S 8-1
Jul 2008
Related command and parameters Chapter 8: Power and Handover Control
SDCCH handovers on page 8-106.
MS handover power level based on path loss calculations on page 8-109.
Congestion relief on page 8-113.
Adaptive Multi-Rate (AMR) on page 8-122.
Ping-pong on page 8-126.
8-2 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Power control
Power control

Power control description
This feature maintains the MS and BTS within a predetermined uplink or downlink power level
window, respectively, as shown in Figure 8-1.
Figure 8-1 Desired RXLEV window, uplink or downlink
Power control allows the operator not only to compensate for the distance from MS to BSS as
regards timing, but can also cause the BSS and MS to adjust their power output to take account
of the path loss. Less power is required for transmission by both the MS and BSS, when the MS
and BSS are in close proximity. This feature saves radio battery power at the MS and helps to
reduce co-channel and adjacent channel interference.
GSM recommendations state that uplink power control is mandatory, whereas downlink power
control is optional. Power control in packet data transmissions cannot be disabled. The
technology used for this is described in GPRS power control later in this chapter.
The MS reports all downlink power serving, in the uplink SACCH message; in addition, the
uplink power is also processed by the BSS and averaged in the same manner. The HDPC tries to
maintain the respective RXLEV values within an uplink and downlink power window. The process
is subject to the N and P voting mechanism. The following equations summarize this process:
68P02901W36-S 8-3
Jul 2008
Power control description Chapter 8: Power and Handover Control
rxlev XX > u rxlev XX p decrease (TXPWR)
rxlev XX < l rxlev XX p increase (TXPWR)
all others NO ACTION
rxqual XX > u rxqual XX p decrease (TXPWR)
rxqual XX < l rxqual XX p increase (TXPWR)
all others NO ACTION
Where:
XX is Uplink or Downlink.
Quality and level processing
Both quality and level processing occur simultaneously. The resultant action of combinations,
involving both increments and decrements through both causes in the same processing period is
shown in Table 8-1. These resultant actions are only valid when decision_alg_number = 0 or
when decision_alg_number = 1.
Table 8-1 Actions resulting from RXLEV_xx and RXQUAL_xx
RXLEV_xx RXQUAL_xx Result

Decrease Decrease Decrease
Increase Increase
No action Decrease
Increase Decrease Increase (Refer Note 1)
Increase Increase
No action Increase
No action Decrease Decrease (Refer Note 2)
Increase Increase (Refer Note 2)
No action No action
NOTE
There is no limit on good quality.

Before this decision is taken, it will be checked for possible oscillation.
8-4 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Power control description
Oscillation prevention for MS power control
Power control is more complex than described above. If the pow_red_step_size is equal to 2
dB then the HDPC checks if the present power level-2 dB, is not below l_rxlev_ul_p. If this
is the case then a power decrease is ordered. The problem occurs because of the specified
tolerance in MSs, which is 1.5 dBm. Thus, although the HDPC calculates that the threshold
will not be exceeded, in actual fact, depending on the tolerance of the MS, it could exceed. The
pow_inc_step_size set by many operators is 6 dBm, to allow for a fast recovery in the case of an
RXLEV problem. The problem diagram of Figure 8-2 shows the effect of this.
Figure 8-2 MS power control oscillation
This oscillation can be prevented by an algorithm within the HDPC such that the power level
remains reasonably constant at just above the lower RXLEV threshold and does not allow
subsequent power decreases through RXQUAL.
The algorithm is only initiated when the RXLEV drops below the RXLEV threshold if the last
power control instruction was a decrease because of quality. The HDPC computes the necessary
increase and adjusts the power increment step size to that required, not the set database value.
The effect of oscillation would be reduced although the condition still exists to a smaller degree,
mainly due to the computing algorithm being constrained to using fixed 2 dB steps. To remove
these oscillations completely, the HDPC tracks when successive increase in power control
through RXLEV follows power decreases through RXQUAL. If this is the case, power control
decreases through RXQUAL are not ordered. Figure 8-3 shows this effect.
68P02901W36-S 8-5
Jul 2008
Power control description Chapter 8: Power and Handover Control
Figure 8-3 MS power control RXLEV median levels
The database field controlling the use of this algorithm is mspwr_alg, which can be found in
add_cell.
Algorithm 1 settings based on HREQAVE and N&P voting
The following settings use decision_alg_number = 1:
The MS response ms_p_con_ack should equal 2 or 3, because it takes an MS, four or more
SACCH periods to respond to a power control change.
ms_p_con_interval = (hreqave * (n-p+1))/2
The BTS response bts_p_con_ack is 1; the BTS always responds in two SACCH periods after a
power control change.
bts_p_con_interval = (hreqave * (n-p+1))/2
This equation allows for enough averages to make a new decision, based on the changed power
level.
For example, for n = 4, p = 2, a power box of 32 to 38 and hreqave = 2, the formula is (4-2 + 1)
* 2 = 6 SACCH periods before a new power change as shown in Figure 8-4.
Figure 8-4 Power change interval example
No more power control is needed, since three averages were 36 and one average was larger
than 36. The total N would be waiting too long and P would not be enough.
8-6 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Power control description
Algorithm 0 settings based on HREQAVE and N&P voting
The following settings use decision_alg_number=0:
hreqave (n p + 1)
mspconinterval =
2
hreqave (n p + 1)
bspconintervals =
2
Since p_con_ack is not used, the p_con_interval values must take into account the number of
SACCH periods while the power change occurs.
Optimized power control
The objective of this feature is to optimize uplink and downlink power control. This will be done
by adding flexibility in defining power steps, modifying the range of power steps, by allowing
power step sizes to be changed dynamically and by performing downlink oscillation prevention.
These power control modifications will cause the MS and BSS to respond more effectively to
changing power level and quality conditions. This will minimize power output both for the MS
and the BSS as well as reduce interference.
Flexible power steps
Adds the flexibility in defining power steps by allowing uplink and downlink power step
sizes to be controlled separately. This is done by creating two increment and decrement
step size elements, one pair each for uplink and downlink directions.
Extended range for increment step size
The range of the power control steps for increments will be extended. Currently the
allowable values for increment step size are 2, 4 and 6 db. This will be extended to allow
for a range of 2, 4, 6, 8, 10, 1 2 and 14 db in both uplink and downlink directions. This
will allow the power to be brought back into the power box (the acceptable power range)
quickly if it should suddenly fall too low.
Dynamic steps adjust procedures
Power increment and reduction step sizes will be allowed to change dynamically (if the
algorithm is enabled) based on the current power level and proximity to lower and upper
power level and quality thresholds. This will allow the power to be brought up or down at a
faster rate when it has strayed out of the power box or quality box.
Downlink oscillation control
Power oscillation occurs when a decision to reduce power due to good quality is
immediately followed by a decision to increase power due to a low-power level. To prevent
unnecessary power changes, oscillation must be detected and controlled. Currently,
oscillation prevention exists for uplink power control. The Optimized Power Control
feature will extend this to downlink power control using a different algorithm (from the
uplink oscillation control algorithm).
68P02901W36-S 8-7
Jul 2008
Optimized power control enhancement function Chapter 8: Power and Handover Control
Optimized power control enhancement function
This enhancement to the existing optimized power control function allows power level reduction
step sizes to change dynamically based on the current proximity to the upper power level
threshold. This allows the power to be brought down at a faster rate when it has strayed out of
the power box thresholds.
Dynamic power reduction is used in the event that the power level exceeds the upper level
threshold. This procedure allows the decrement step size to change dynamically, based on the
proximity to the upper power threshold and is used to reduce the power level to one under the
threshold level. Calculations are made for both uplink and downlink power control.
The step size for dynamic power reduction is calculated as follows:
DYN_POW_RED_XX_L = fhigh(av_rxlev_xx-u_rxlev_xx_p + pow_red_step_size_xx)
Where: Is:
fhigh() the rounding up of a value to the nearest multiple of 2 dB.
xx the uplink (ul) or downlink (dl) directions.
u_rxlev_xx_p the upper power threshold.
av_rxlev_xx the current power level.
pow_red_step_size_xx the power reduction step size.
A dynamic power reduction due to high level will bring the power down to the standard step
size below the power box.
NOTE
The current rapid_power_down algorithm allowing rapid power reduction in one
step will not be affected and can be used together with this algorithm. When the
power goes above the rapid power trigger point, the rapid power down algorithm
automatically triggers and overrides any dynamic power adjustment decision.
GPRS power control
Unlike GSM, packet switched (GPRS) power control cannot be disabled by the operator. A
similar effect to disabling power control can be achieved by setting the threshold very high.
Because of dynamic reallocation of timeslots and cell reselection, the downlink power control
can be adjusted up or down only to a 10 dB threshold.
Calculation of power control is combined with coding scheme selection. This is described in
Chapter 6 Call Processing of this manual, under the heading Air interface packet data transfer
on page 6-68 and Coding schemes.
In calculating the power control values, the measurement information from the channel coder
radio in the BTS is used, as is the C block bit map that is sent up in the downlink ACK/NACK
messages that are solicited by the BSS. From C bit map the BLock Error Rate (BLER) can
be continuously calculated.
8-8 68P02901W36-S
Jul 2008
The following parameters are used with the chg_cell_element, chg_element and/or add_cell
commands to influence the power control function:
Circuit switched
bts_p_con_ack - Sets the maximum amount of time to wait for RF power change
acknowledgments to the BSS (decision_alg_num = 1 only). Repeats BTS power control
messages, if the power has not been confirmed.
bts_p_con_interval - The time between successive downlink power control changes at

the BTS.
decision_alg_type - Specifies the current power control algorithm.
decision_1_n1 or decision_1_p1 - Defines n1 and p1 voting for power increase, in the

decision algorithm used in the BSS. Also defines n2 and p2 voting for power decrease.
dyn_step_adj - Determines whether the dynamic step adjust algorithm is enabled,

dynamically enabled or disabled.
dyn_step_adj_fmpr - The new element dyn_step_adj_fmpr helps to control the speed of a

dynamic power reduction.
l_rxlev_ul_p or l_rxlev_dl_p - Sets the lower uplink or downlink limit for the rxlev_ul
of the serving cell.
l_rxqual_ul_p or l_rxqual_dl_p - Sets the power control threshold for the worst allowed
receive quality uplink or downlink.
u_rxlev_ul_p or u_rxlev_dl_p - Sets the signal strength for the upper limit of the rxlev_dl
serving cell.
u_rxqual_ul_p or u_rxqual_dl_p - Sets the power control threshold for the best allowed
uplink or downlink receive quality.
ms_p_con_ack - The time between successive mobile (uplink) power control changes.
ms_p_con_interval - The time between successive mobile (uplink) power control changes.
mspwr_alg - Enables or disables the enhanced power control algorithm for oscillation
prevention.
pow_inc_step_size_ul, pow_inc_step_size_dl, pow_red_step_size_ul and

pow_red_step_size_dl-The elements pow_inc_step_size_ul and pow_inc_step_size_dl
replaced the current element pow_inc_step_size. The elements pow_red_step_size_uland
pow_red_step_size_dlreplaced the current element pow_red_step_size.
68P02901W36-S 8-9
Jul 2008
System impact Chapter 8: Power and Handover Control
Packet switched
gprs_pb - Specifies the power reduction factor used by the BTS on the BCCH blocks.
gprs_pc_alpha - Broadcast on the BCCH and used as a multiplier of the power offset in
power control calculations. The actual multiplying factor is one tenth of the value set by
this parameter, that is, if N is the value of this parameter, the multiplying factor is N/10.
gprs_pc_meas_chan - This parameter designates whether the MS measures the received

power level on the downlink BCCH or PDCH in order to control the uplink power.
System impact
Keeping the MS and BSS at a minimum acceptable power output reduces the chances of channel
interference, particularly co-channel.
Power control also extends battery life of the MS, thus maximizing available talk time.
Related features
Fast initial MS power down.
8-10 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation All channels at full power
All channels at full power

All channels at full power function
This feature, configurable on a per cell or site basis, sets all the channels in the cell to broadcast
at a constant power at the power level configured as the maximum transmit power allowed in
the cell. This can be used for worst case interference monitoring for network optimization.
The full power mode can be terminated manually at any time, or automatically stopped by the
BSS on expiry of a timer, which is set when the full power mode is activated.
The MMI command set_full_power activates or deactivates full power mode for any, or all,
cells at a particular site. When activated, all channels broadcast at a constant power at
the power level configured as the maximum transmit power allowed in the cell (set by the
max_tx_bts parameter), as shown in Figure 8-5. A cell must be equipped and in a state other
than out-of-service in order for the command to be accepted.
Figure 8-5 Setting full power mode for an MS
Activation of full power mode will not affect the availability of channels used for the normal
processing of calls in the cell. Idle channels will transmit dummy bursts at the power level set
by the parameter max_tx_bts. The channel is still available for use and will continue the full
power transmission when the channel transitions to an active state.
68P02901W36-S 8-11
Jul 2008
Related commands and parameters Chapter 8: Power and Handover Control
When full power mode is switched on, active channels are affected as follows:
Downlink power will be changed to max_tx_bts.
Downlink DTX will be disabled.
Dynamic downlink power control will be disabled.

The set_full_power command sets a timer which specifies how long the cell(s) remain in full
power mode. The allowed range is between 1 minute to 24 hours. It can also be used to
terminate full power mode at any time. When a channel transitions from full power mode on to
full power mode off, active channels are affected as follows:
Dynamic downlink power control will be resumed, if it is enabled.
Downlink DTX remains off for any calls which are active. New calls are able to use
downlink DTX.
Refer to: Technical Description: BSS Command Reference (68P02901W23) manual for a full
The following commands and parameters are used to influence the full power feature.
Commands
The set_full_power command is used to specify all the channels at full power feature at a site.
Parameters
The following parameters are used with the all channels at full power feature:
max_tx_bts - Sets the maximum output power for a base station transmitter within its
power class.
disp_cell_status - Displays the status of the full power mode for a cell.
System impact
This feature is an enhancement to the existing BSS call processing functionality. Call processing
in the cell is not affected. Full power mode is not allowed at a site where battery conservation is
active. The full mode will be terminated when battery conservation is activated.
Related features
Power control.
8-12 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Fast initial MS power down
Fast initial MS power down

Fast initial MS power down function
This optional feature, configurable on a per cell basis, allows the initial power down of the
Mobile Subscriber (MS) to be set so that the MS power is reduced faster than the standard
ramp down time. This helps allethroughte problems related to intermodulation and receiver
blocking which can occur if the power level of the MS is too high. This can happen particularly
in parts of the network where fiber optic distribution of the RF is deployed, given the smaller
dynamic range is provided. If unrestricted, fast initial MS power down is always active, not just
for the initial setting up of the call.
For example, if the MS enters a building with a micro-cell or pico-cell BTS, that MS needs to
change power levels from a macro-cell (much higher power level) within a very short time
span and distance (a few meters).
When this feature is enabled, a separate power control procedure powers the MS down rapidly
when the BSS detects that the signal strength of the MS is above the specified trigger threshold.
This procedure by passes the pow_dec_step_size setting in the database to bring the power of
the MS to an acceptable level quickly. Figure 8-6 illustrates this situation.
The BSS calculates the reduction required in rxlev_ul. If a constant path loss can be assumed
then the same reduction as that path loss is needed in the MS transmitting power level.
Figure 8-6 BSS detects MS power level too high
68P02901W36-S 8-13
Jul 2008
Fast initial MS power down function Chapter 8: Power and Handover Control
Power down trigger levels
When the uplink rxlev meets or exceeds the rpd_trigger threshold, the MS is commanded
to a power level which has been calculated to put the uplink rxlev equal to the
rpd_trigger-rpd_offset. The rpd_period monitoring period provides the ability to detect a
high-power condition quickly, while still allowing the normal power control procedure to smooth
out the power level averages with larger HREQAVE and HREQT values.
When a radio channel is initially activated, the procedure to detect the need for a rapid power
down does not begin until enough measurements have been received to satisfy rpd_period
monitor period. After the required number of reports have been received, they are averaged
and the result is compared against the rpd_trigger value. No voting is performed. The HREQT,
n and p values are all assumed to be 1. The averaging and comparison is repeated at every
SACCH period, with the most recent rpd_period number of measurements being averaged.
When the average (referred to here as RXLEV_UL) meets or exceeds the trigger, the MS is
immediately ordered to a power level calculated as follows:
ordered power level = current power level + 1/2 (ul rxlev rpd trigger + rpd offset)
NOTE
MS uses 15 power control steps as ordered by the BTS. Each step (power level) is a
decrease of 2 dB in output power. The actual output power decreases as the power
level value increases.
If the result of the calculation above is a value which exceeds the minimum power level that is
supported, the minimum power level is used. This procedure is carried out on every channel
type for the entire duration that the channel is active, regardless of the reason for activation.
The ms_p_con_interval timer is enforced for subsequent power decrements after a rapid power
down. The ms_p_con_interval timer is overridden if the l_rxlev_ul_p threshold is exceeded as
a result of the rapid power down, or if the l_rxqual_ul_p threshold is exceeded. The averages
used from the time of the rapid power down until the expiration of ms_p_con_interval are
those calculated using rpd_period. Over riding the timer allows a recovery from a condition
where the rapid power down took the MS power level to a level too low or to a level which
is resulting in poor quality.
To provide the greatest amount of flexibility in optimizing the operation, only settings which
would completely invalidate the intended operation of the new parameters are prevented. For
example, setting rpd_trigger to a value lower than l_rxlev_ul_p will not be allowed. Setting
rpd_trigger to a value less than rpd_offset will not be allowed. However, the condition where
rpd_trigger - rpd_offset results in a value lower than l_rxlev_ul_p is allowed.
8-14 68P02901W36-S
Jul 2008
The following parameters can be used with the fast initial MS power down feature:
rapid_pwr_down - Enables or disables the rapid power down procedure.
rpd_trigger - If u_rxlev_ul_p is higher than rpd_trigger, the MS power level is reduced

quickly. The setting of this parameter must always be greater than the settings of the
rpd_offset and l_rxlev_ul_p parameters.
rpd_offset - The difference between the trigger threshold and the desired power level. The
setting of this parameter must always be less than the setting of the rpd_trigger parameter.
rpd_period - Specifies the number of SACCH frames used to calculate a rolling average of
uplink rxlev values.
68P02901W36-S 8-15
Jul 2008
Quality measurement reporting Chapter 8: Power and Handover Control
Quality measurement reporting

Receive quality measurement reporting
Radio path receive quality measurements for active calls, are reported by the radio and
MS. These measurements allow the HDPC to make handover decisions and power control
adjustments based on the uplink and downlink quality of the link.
The measurements are reported to the HDPC in the form of quality bands ranging from 0-7, as
shown in Table 8-2. Band 0 corresponds to little or no deterioration of receive quality (RXQUAL)
on the channel and band 7 corresponds to greater than 12.8% bit error rate (BER) on the
channel. These bands, once received by the HDPC, are mapped to an assumed BER value
(defined in 3GPP Technical Specification GSM 05.08) as shown in Table 8-2.
Table 8-2 RXQUAL reported bands and assumed BER
BER Reported band Assumed BER

Less than 0.2% 0 0.14%
0.2-0.4% 1 0.28%
0.4-0.8% 2 0.57%
0.8-1.6% 3 1.13%
1.6-3.2% 4 2.26%
3.2-6.4% 5 4.53%
6.4-12.8% 6 9.05%
Greater than 12.8% 7 18.1%
The assumed BER values are then stored and input to the averaging mechanism, using the
defined HREQT and HREQAVE values specified. The resulting HREQT number of averages is
then used in the applicable voting decision for handover and power control.
Alternative processing of RXQUAL measurements
An alternate method, known as quality band (QBAND) uses the reported bands, 0-7, as the input
to the averaging mechanism, instead of the assumed BER. This modification requires that the
threshold parameters are based on bands also, since the re-averaged values are produced
related to the bands rather than BER percentages.
QBAND averaging is specified by the alt_qual_proc flag in add_cell. This flag impacts the
setting of the quality threshold parameters in add_cell.
8-16 68P02901W36-S
Jul 2008
Difference between BER and QBAND measurements
The averaging process will produce different quality measurement results, depending on
whether BER or QBAND measurements are used in the averaging process:
The QBAND tends to be less sensitive as results are always rounded down to a whole value.
The default BER generally has better performance, because of its more precise and
realistic results.
For example:
If four values of 6, 0, 0 & 0 are received, the average using QBAND would be:
(6+0+0+0)/4 = 1.5 (rounded down to band 1).
The corresponding average, using assumed BER values (from Table 8-2) would be:
(9.05+0.14+0.14+0.14)/4 = 2.37%, which corresponds to band 4.
So there is a possible discrepancy of 3 bands between the two averaging methods.
The averaged value must be greater than the threshold to trigger a decision. So, if the
handover/power control decision level is set at 1, 2 or 3, it would be triggered by the BER
value but not by the QBAND value.
The following parameters can be used with the chg_cell_element, chg_element or add_cell
commands to influence the receive quality measurement reporting function:
alt_qual_proc - Specifies that receive quality processing is performed using Quality Band
(QBAND) units. If alt_qual_proc is left at 0 (default), BER units will be used instead.
u_rxqual_ul_p or u_rxqual_dl_p - Sets the power control threshold for the best allowed
uplink or downlink receive quality.
l_rxqual_ul_p or l_rxqual_dl_p - Sets the power control threshold for the lower received
quality uplink or downlink.
l_rxqual_ul_h or l_rxqual_dl_h - Sets the handover control threshold for the lower
received quality uplink or downlink.
68P02901W36-S 8-17
Jul 2008
Missing report Chapter 8: Power and Handover Control
Missing report

Missing report function
The missing report function provides a means for deciding a course of action on non-receipt
of an uplink measurement report.
The RSS expects an uplink measurement report from the MS every 480 ms (SACCH multiframe).
If this report does not arrive, for example due to an SMS broadcast or due to the report being
corrupted and not being decoded, the action of the RSS is controlled by the missing_rpt
database flag in add_cell.
When the flag is set to 1:

For the downlink, it is as if that reporting period did not take place; no storing, averaging,
decision making, or actions are taken upon the expiry of the SACCH period. Subsequent
reporting periods continue to average normally, ignoring the missed period. The power
budget is not calculated.
For the uplink, averaging and decision making, progress in the normal way.
When the flag is set to 0:

The previously received report is repeated and averaging goes ahead as normal; all related
voting and other actions continue. The power budget is calculated.
The missing_rpt parameter can be used with the chg_cell_element, chg_element or

add_cell commands as a flag which decides the action of the RSS (HDPC) upon non-receipt
of a measurement report.
8-18 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Handover decision process
Handover decision process

Handover decision process
The handover decision process takes place when system measurements indicate a need for the
MS to use a different BTS. When the MS needs to handover, it is enabled according to priority.
BSS measurement averaging
The BSS produces one average per measurement period of each of UL Rxlev, UL Rxqual, timing
advance and UL channel interference on idle radio slots.
These measurements are re-averaged by the RSS, producing a series of unweighted averages
every SACCH multiframe.
Three parameters control this averaging function:

hreqave - The number of reported averages required to produce one rolling average
as one instance of hreqt.
hreqt - The number of averages retained in the handover software task, needs to be at
least equal to the n parameter for that particular threshold.
intave - The number of interference averages, reported by the radio, that are used to
produce one rolling average every 480 ms.
NOTE
hreqt and hreqave have a maximum value of 32, although hreqt x hreqave for
the same averaging process must equal 32 or less (hreqt x hreqave <= 32).
hreqave and hreqt must be defined for:

Rxqual UL/DL: Handover (ho) and power control (pc)
Rxlev UL/DL: Handover (ho) and power control (pc)
Surrounding cell DL: Handover (s_cell)
Timing advance: MS to BS timing advance (rel_tim_adv)
intave must be defined for (when itave has been specified hreqt = 1):
Idle interference UL: Idle channel processing
Figure 8-7 shows uplink SACCH measurement reports for one neighbor.
68P02901W36-S 8-19
Jul 2008
Handover decision process Chapter 8: Power and Handover Control
Figure 8-7 Example of uplink SACCH measurement reports for one neighbor
480 ms HREQAVE=4 HREQT=2
1 2 3 4 5 6 7 8 9 10 11 12 13
A E
averages
A B C D C G E I
performed
...
B F D H
A average of SACCH measurements 1-4

F average of SACCH measurements 6-9
B average of SACCH measurements 2-5
G average of SACCH measurements 7-10
C average of SACCH measurements 3-6
H average of SACCH measurements 8-1 1
D average of SACCH measurements 4-7
I average of SACCH measurements 9-12
E average of SACCH measurements 5-8
ti-GSM-UL SACCH measurement reports 1 neighbor-00267-ai-sw
NOTE
When the averaged value is not an integer, the value is truncated to become an
integer. For example, an averaged value of 3.99 is truncated to 3.
N and P voting mechanism
Together with Hreqave and Hreqt, the N and P voting mechanism ensures that a power control
or handover decision is made over a number of averages and not just a snapshot of MS activity.
The N and P parameters for each decision process can be entered in the add_cell command.
They are defined as follows:
N defines the number of BSS produced averages required for a decision to be made.
P defines the minimum number of BSS produced averages, over the threshold value, to
cause a positive trigger.
A vote occurs for each decision process every SACCH multiframe. If P out of N votes exceed the
threshold then a handover/power control condition will be flagged.
Figure 8-8 shows uplink SACCH measurement reports for dl_rxlev.
8-20 68P02901W36-S
Jul 2008
Figure 8-8 Example of uplink SACCH measurement reports for dl_rxlev
20 21 22 23
P Q R S T U V W X Y Z A B C D E
The MS reports a stream of serving downlink measurements at each reporting period.
Setting the P of N number to a higher value will delay the handover trigger; this effect is
desirable, as it reduces the possibility of the MS bouncing back to the source cell. However, in a
situation where the slow fade effect is accelerated by a fast moving vehicle, the rxlev of the
source becomes too low to perform a handover.
Setting the P out of N number to a lower value will trigger a faster handover, increasing the
chance of the MS bouncing back to the source cell, but ensuring a rxlev of sufficient value
to perform the handover.
68P02901W36-S 8-21
Jul 2008
Hreqave/hreqt and N/P relationship
Figure 8-9 shows a stream of serving downlink measurements as reported by the MS at each
reporting period. Hreqave has been set at 4 and Hreqt has been set at 3. The Rxlev downlink
handover threshold has been set to -90 dBm.
Figure 8-9 Downlink measurements
The optimal handover of an MS between cells is based on handover causes, prioritized as follows:
Receive quality (uplink and downlink).
Interference (uplink and downlink).
Receive signal strength (uplink and downlink).
Distance (timing advance).
Power budget.
Directed retry/congestion relief.
8-22 68P02901W36-S
Jul 2008
Handover decision procedure Quality and signal strength
The BSS handover procedure usually takes place every SACCH multiframe, for each MS
engaged in a call. The following procedure does not include any reference to the microcellular
feature. Figure 8-10 is a flow chart of the handover decision procedure for quality and
Figure 8-11 is a flow chart of the handover decision procedure for signal strength or distance.
The ho_counter decreases from a maximum to ho_recognised_period. The counter is reset to

this maximum immediately after a handover recognized message has been sent from RSS to CP.
If a ho_recognised_message is sent within a time set by ho_recognised_period, the RSS will
not process handover decisions for that MS.
The RSS progresses through each handover decision in a priority order:
ul_rxqual (ul_interference).
dl_rxqual (dl_interference).
ul_rxlev.
dl_rxlev.
ms_distance.
power budget.
If a handover is triggered through one decision process in the priority list, the others further
down the list are ignored. That handover trigger then leads to further processing.
For each handover decision in turn, the RSS first checks that the specified handover type has
been enabled and then, if necessary, processes the voting decision. If a handover has been
disabled, that decision mechanism is skipped.
Both uplink and downlink positive quality decisions are further processed to determine whether
the handover is indeed quality or interference.
Handover decision-data communications
Data calls require a different RXQUAL threshold, because data communication is more sensitive
to bit errors. The handover process keeps track of the call type (voice or data) on a given TCH.
If the call is data, the RSS uses an alternate RXQUAL threshold.
68P02901W36-S 8-23
Jul 2008
Figure 8-10 Flow chart of handover decision procedure-quality
8-24 68P02901W36-S
Jul 2008
Figure 8-11 Flow chart of handover decision procedure-signal strength/distance
68P02901W36-S 8-25
Jul 2008
Power budget assessment process
The power budget formula can be considered in two parts: the expression in the left bracket
refers to the serving cell, while that in the right bracket refers to the neighbor cell. The power
budget calculation is carried out every half second (SACCH multiframe) for each reported
neighbor of all MSs engaged in traffic. The assessment is not subject to N & P voting.
PBGT(n) = [min (ms_txpwr_max, P)-Rxlev_DL-Pwr_C_D]
-[min (ms_txpwr_max, P)-Rxlev_DL]
Where:
[min (ms_txpwr_max, P)-Rxlev_DL-Pwr_C_D] refers to the serving cell.
[min (ms_txpwr_max, P)-Rxlev_DL] refers to the neighbor cell.
The aim of the formula is to afford the MS the lowest uplink path loss.
Downlink RXLEV only
Probably the most important factor in any handover decision and selection process is the
perception of the MS about its serving downlink level as compared to its neighbor's downlink
level. This is accounted for in the power budget expression:
PBGT(n) = [-Rxlev_DL]-[-Rxlev_DL]
In this case, all the other inputs to the formula have been removed and the comparison at
this level can be seen easily. PBGT(n) becomes greater than 0 if the reported neighbor level
becomes greater than that of the server.
Adapted power consideration
A direct level comparison is not always correct because the MS is potentially reporting adapted
power on the serving cell, whereas the neighbor is being measured at its full BCCH power level.
A correction factor must therefore be considered:
PBGT(n) = [-Rxlev_DL-PWR_C_D]-[-Rxlev_DL]
Where:
PWR_C_D = max_tx_bts-Actual BTS output power.
PWR_C_D will always equal a positive value, or zero when the MS can no longer be maintained
in the downlink power window.
Uplink consideration
The aim of this formula is to provide the MS with the lowest uplink path loss. The first part of
each side of the formula provides this comparison:
min (ms_txpwr_max, P)
Where:
ms_txpwr_max of the server equates to the value specified in max_tx_ms in the add_cell.
ms_txpwr_max of the neighbor can be specified in add_neighbour for an external cell.
8-26 68P02901W36-S
Jul 2008
For an internal neighbor, ms_txpwr_max will be specified by max_tx_ms in the neighbors's

add_cell.
The value of P equates to the maximum power of the MS concerned.
The power budget formula is designed for an MS suited to the PLMN being used, that is, the
MS always has sufficient power to support all cells within the PLMN. In this case the P value is
never used and the ms_txpwr_max is always the deciding uplink factor.
Handover decision procedure-Power budget
The lowest priority for processing is the power budget handover. The condition that must be
met for this cause value is:
PBGT (n) > ho_margin
The handover margin for each neighbor can be set differently. The margin is specified in
the add_neighbour command, although this field is optional for internal cells and can be
interpolated by the servers ho_margin_def value of the server, which is found in add_cell.
Criteria 1
Criteria 1 ensures that the MS is perceiving each neighbor's Rxlev at a power level good enough
for the downlink path to uplink path to support a good call. Criteria 1 specifies that:
Rxlev_ncell > Rxlev_min (n) + Max (0, Pa)
Where: Is:
Rxlev_ncell the latest averaged average processed for that neighbor.
Rxlev_min (n) the database parameter set in the add_neighbour 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 = maximum 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.
If the MS is not suited to that neighbor, that is, its maximum power cannot 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 neighbor.
Any neighbor failing criteria 1 is not considered further in any handover decision process.
68P02901W36-S 8-27
Jul 2008
Criteria 2
Each neighbor for the MS that satisfies criteria 1 is then subjected to criteria 2, which specifies
that:
PBGT(n)-ho_margin >0
Where:
ho_margin for both external and internal cells can be specified in the add_neighbour
command.
For internal cells this parameter is optional and if not specified then the ho_margin_def in
the add_cell of the server is used.
For level and quality handovers, if ho_margin_usage_flag = 1, ho_margin is replaced by

ho_margin_rxlev and ho_margin_rxqual.
ho_margin_usage_flag can be specified with the chg_cell_element and chg_element

commands.
ho_margin_rxlev and ho_margin_rxqual can be specified through the modify_neighbour

command.
Criteria 2 produces either a positive or negative result for each neighbor, which is further
considered in the following specific handover procedure.
Handover decision procedure Qualified neighbor flag
All handover triggers for any cause value will be further processed.
MS reports up to 6 neighbors every SACCH period; the neighbors reported in that period are
considered qualified candidates for further criteria 1 and 2 processing.
Uplink and downlink quality handover processing
The uplink and downlink quality handover procedures are identical.
If no handover candidates are available the whole procedure is skipped and results in a
ho_recognised message being sent, but without any handover candidates specified. This
results in an intra-cell handover, if enabled.
If one or more handover candidates are available then the procedure shown in Figure 8-12 takes
place making use of the quality flags, if set.
w_qual_flag -This flag is only applied to quality-related averaging mechanisms when

the weighted averaging algorithm (number 1) is used. This algorithm causes the
most recent reported averages to be repeated a number of times, in accordance with
the weighting factor, before an average is calculated by the averaging mechanism.
For example, if w_qual is set to 2, the latest measurement report average
is used twice to give it more influence on the outcome of the quality voting.
The weighted algorithm only applies when the reported averages are full values, not sub rate
values such as discontinuous transmission.
8-28 68P02901W36-S
Jul 2008
Figure 8-12 Uplink/downlink quality handover procedure
Downlink level handover procedure
Only candidates passing criterion 1 are considered further in the downlink level handover
procedure. The process followed will depend upon the settings of ho_margin_usage_flag,
ho_only_max_pwr and worse_neighbour_ho, as shown in Figure 8-13.
If ho_only_max_pwr is enabled and no candidates have a positive criterion 2 then the handover
will be aborted if the BTS is not at max_tx_bts (as specified in add_cell). If the BTS is
transmitting at full power and worse_neighbour_ho is NOT enabled then an RXLEV check is
made to delete possible target cells having weaker RXLEV than the server. This deletion of
a candidate will happen if the last computed neighbor RXLEV average is less than the last
computed serving cell RXLEV average. When the handover recognized message is sent it will
contain neighbors ordered on a best to worst basis using the results from criterion 2.
NOTE
decision_alg_num=1 must be used if ho_only_max_pwr is to be enabled.
68P02901W36-S 8-29
Jul 2008
Figure 8-13 Downlink level handover procedure
Yes
No
No
Uplink level handover procedure
The uplink handover procedure is much the same as the downlink level case. The only real
difference is that the RSS does not remove weaker candidates from the ho_recognised message.
Distance handover procedure
The distance handover procedure, shown in Figure 8-14, only results in a handover recognized
message if candidates have met Criteria 1. Criteria 2 is used as a scaling factor to position each
candidate in the ho_recognised message.
8-30 68P02901W36-S
Jul 2008
Figure 8-14 Distance handover procedure
Power budget handover procedure
The power budget handover procedure, shown in Figure 8-15, results in a ho_recognised
message when candidates have a positive criteria 2 result. Candidates not meeting this criteria
are omitted from the message.
68P02901W36-S 8-31
Jul 2008
Figure 8-15 Power budget handover procedure
8-32 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Directed retry
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 an 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 (that is, 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 signaling 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, the channel mode element is sent to the
mobile. The channel mode element indicates to the mobile that the target channel supports,
either speech, signaling or data. Of course a directed retry handover will not be initiated unless
the MS has reported a strong enough neighbor 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 neighbors 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 is 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 neighbors are reported then the TFC request will remain queued for the
remainder of the relevant queuing timer.
Directed retry considerations
Before enabling directed retry the following should be considered:

Algorithm for number of handovers: The BSS processes as many handover requests as
are queued, even after the candidate information timer expires. Handovers are based
on the number of assignment requests or the number of handover candidates as shown
in Figure 8-16.
68P02901W36-S 8-33
Jul 2008
Directed retry Chapter 8: Power and Handover Control
Figure 8-16 Handovers based on assignment requests or number of candidates
1* 2* 3* 2* 3* 4*
When the handover and assignment procedures are handled simultaneously, the per
cell key statistic TCH ASSIGNMENT SUCCESS RATE count can be different from when
each handover procedure begins and ends before an assignment procedure. The TCH
ASSIGNMENT SUCCESS RATE count is lower if an internal inter-cell or external handover
is initiated during assignment.
In the case of standard directed retry congestion or handing a handover during the
assignment procedure, the MSC has to increase the timer waiting for the assignment
complete message from the BSS.
For maximum benefit of directed retry or congestion relief, TCH flow control should be
disabled. Because this feature supports more calls in the network through handovers to
less congested cells, it is not advantageous to bar any access classes due to TCH usage as
in the case of TCH flow control.
Emergency and EGSM calls in cells using directed retry.
If the emergency call preemption feature is enabled, emergency calls will not be handed
over for congestion reasons unless all the calls in the cell are emergency calls. In this case
preemption cannot occur, so a handover is attempted to service the incoming emergency
call.
MS on an EGSM channel is not handed over from an EGSM frequency due to congestion
unless an EGSM-capable MS is queued.
Microcellular purchasable option and directed retry.
If a neighbor qualifies for a congestion handover prior to satisfying the microcellular

algorithm selected for that cell, a handover will be attempted (cause directed retry),
provided directed retry and/or congestion relief are allowed. To avoid this give the
microcell neighbors a high congestion_handover_margin.
8-34 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Congestion relief
Congestion relief
This feature must be purchased and enabled.
This feature consists of two mutually exclusive congestion relief procedures that can be enabled
independently or in conjunction with directed retry. The maximum number of handovers
initiated by this feature is one of the following:
The number of queued requests in the congested cell.
The number of calls meeting the congestion handover criteria in the congested cell. This
selection provides more effective congestion relief for cells that experience frequent
congestion.
When the cell becomes congested, TCH requests are queued regardless of whether queuing is
enabled in the cell in order to give the congestion procedure a chance to work before failing the
requests. If queuing is disabled in the cell, no queuing indication message is sent to the MSC.
Handovers are initiated only for established calls if neighbors are available that meet the
specified congestion handover criteria.
Enhanced congestion relief
With implementation of enhanced congestion relief procedures, the existing congestion relief
procedures can benefit from the following advantages:
Faster congestion relief (non-ideal targets will not be tried).
Reduced signaling (fewer handover attempts).
Less congestion and fewer congestion relief triggers (handovers that can lead to congestion
are not accepted).
Efficient congestion control in the preferred band of a multiband network.
For correct implementation of this feature, the following functionality is supported within the
BSS:
Non-imperative handover rejection
The BSS rejects an incoming non-imperative handover if it will cause congestion relief
procedures to be triggered. The BSS does not allow an incoming handover if the reason
for that handover is congestion relief and the handover itself will lead to the invocation of
congestion relief procedures. If such a handover is allowed then the net result would simply be
the movement of a congestion problem from one cell to another.
Congestion relief handover retry
The source cell will not attempt a congestion relief handover, for a period of time, to a target cell
which had rejected a previous handover attempt (imperative, non-imperative and congestion
relief). Two new timer elements, rtry_cand_prd and ext_rtry_cand_prd, control this period of
time. These timers do not, however, affect any imperative handover retries. These handovers
are allowed to take place regardless of such timers, as they are needed to keep the call active.
68P02901W36-S 8-35
Jul 2008
Multiband MS subscriber redirection Chapter 8: Power and Handover Control
Incoming handover requests
If a BSS target cell rejects an incoming handover, because that handover would trigger
congestion relief procedures, the target cell attempts to inform the source cell of its future,
intra-BSS only, accessibility status. If the target cell is configured to optionally invoke
congestion relief procedures after rejecting the handover request then it is capable of handling
the necessary handovers.
Enhanced_relief database parameter
This database parameter when enabled removes rejection of non imperative handovers when
congest_at_targetis set to 1.
Valid Range: 0, 1 Default: 0.
Multiband MS subscriber redirection
A new element, mb_tch_congest_thres, has been implemented with this feature. This element
controls the percentage point at which multiband mobile subscribers 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. If such a handover is allowed
to be serviced, the net result would simply be the movement of a multiband congestion problem
from one cell to another.
Handover criteria for directed retry and congestion relief
The handover criteria for both features can be specified on a per cell basis.
Criteria 1
congestion_handover_marginadd_neighbour
Criteria 2
If a neighbor meets criteria 2, Pbgt-Congestion_Handover_Margin > 0, it can then

be used to move affected MSs.
Pointing averaging mechanisms to decision processes
Each averaging mechanism produces at least one set of averages every SACCH multiframe,
these averages are used by decision processes controlling handover and power control. The
software bin where each set of averages are stored has to be pointed to the decision process
utilising them. This pin-pointing is specified in add_cell.
The ten algorithms that exist are:
rel_tim_adv.
rxlev_dl_ho.
rxlev_dl_pc.
8-36 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Pointing averaging mechanisms to decision processes
rxlev_ul_ho.
rxlev_ul_pc.
rxqual_dl_ho.
rxqual_dl_pc.
rxqual_ul_ho.
rxqual_ul_pc.
surround_cell.
Each algorithm consists of two bins and each bin is made up of three indices where unique RSS
algorithm parameters, such as hreqave and hreqt, shown in Table 8-3, are stored. The indices
are represented as bytes.
Of the two bins for each algorithm, each bin corresponds to one set of index values that the user
can set up together and instruct the RSS to use.
Several index parameters in the bin pointing mechanism are implemented with other parameters.
The current per cell parameter ho_only_max_pwr implements the functionality of the quality
power flag index parameter. The per neighbor parameter handover_margin_rxqual[n]
implements the functionality in both the quality margin flag and adjacent quality margin index
parameters.
Table 8-3 Index parameters
Index Index parameters

0 hreqave
1 hreqt
2 quality weight
NOTE
N must be equal or lower than HREQT. P must be equal to or lower than N.
A simple example to focus on is uplink power control:

chg_cell_element rxlev_ul_pc 0 0 cell 0010112
Enter hregave: 4
Enter hregt: 1
chg_element decision_1_ul_rxlev_av_p 0 cell 0010112
In the above simple example, the value of the averaging bin pointer, decision_1_ul_rxlev_av_p,
specifies which algorithm to be used by the corresponding bin. The corresponding algorithm
that will be used is shown in Table 8-4. The averaging data stored for the algorithm will be
used by the decision process.
68P02901W36-S 8-37
Jul 2008
Extended Range Cell (ERC) prioritization Chapter 8: Power and Handover Control
Table 8-4 Decision process algorithm
Number N and P definitions Averaging bin pointer Algorithm

N1/P1 Power increase due to decision_1_dl_rxlev_av_ rxlev_dl_pcrxlev_ul_pc
level pdecision_1_ul_rxlev_av_p
N2/P2 Power decrease due to decision_1_dl_rxlev_av_ rxlev_dl_pcrxlev_ul_pc
level pdecision_1_ul_rxlev_av_p
N3/P3 Power increase due to decision_1_dl_rxqual_av_ rxqual_dl_pcrxqual_ul_pc
qual pdecision_1_ul_rxqual_av_p
N4/P4 Power decrease due to decision_1_dl_rxqual_av_ rxqual_dl_pcrxqual_ul_pc
qual pdecision_1_ul_rxqual_
av_p
N5/P5 Handover decision due decision_1_dl_rxlev_av_ rxlev_dl_horxlev_ul_ho
to level hdecision_1_ul_rxlev_
v_h
N6/P6 Handover decision due decision_1_dl_rxqual_av_ rxqual_dl_horxqual_ul_ho
to quality hdecision_1_ul_rxqual_
av_h
N7/P7 Handover decision due decision_1_dl_rxlev_av_ rxlev_dl_horxlev_dl_ho
to interference ihdecision_1_ul_rxlev_
av_ih
N8/P8 Handover decision due decision_1_tim_adv_ rel_tim_adv
to timing advance av_alg
Extended Range Cell (ERC) prioritization
The chg_element command parameter erc_ta_priority allows the priority threshold for
extended range cell neighbors to be altered.
At present the extended range cell prioritization has a default value of 50. This feature allows
a priority threshold to be set, which can override the default value. If the absolute timing
advance is greater than the priority threshold then the ERC neighbors is placed at the top of
the list of sorted handover candidates. Otherwise, the ERC neighbors will be appended to the
end of the list of candidates.
Worst quality
The RSS expects an uplink measurement report from the MS every half second (SAACH
multiframe), this report does not arrive perhaps due to SMS, or the message itself could have
been corrupted and could not be decoded. In either situation the RSS has missed a report.
The action, by the RSS, upon missing this report is controlled by a database flag in add_cell.
The flag is missing_rpt.
When the flag is set to one, in respect of downlink, it is as if that reporting period did not take
place at all, no storing, averaging, decision making, or actions will be taken upon the expiry of
the SAACH period. Subsequent reporting periods will continue to average in the normal way
ignoring the missed period. For the uplink case, averaging and decision making will progress in
the normal way. When the flag is set to zero, the previously received report is repeated and
averaging goes ahead as normal, all related voting continues.
8-38 68P02901W36-S
Jul 2008
missing_rpt = 0: rpt_bad_qual_no_mr
When missing_rpt = 0, a choice is offered between allowing the quality measurement in the
repeated report to be simply accepted by the system, or to make an immediate difference in the
significance of the repeated report by setting the quality at a lower level than the last received
report. The rpt_bad_qual_no_mr parameter allows the quality value to be used by the system
under these circumstances to be set to its previous value, or to 7, meaning that the assumed
quality of the report is at the lowest possible level or for the measurement report to be left blank.
When rpt_bad_qual_no_mr is set to 0, the missed rxqual measurement report is left blank and
is not used to signify the rxqual measurement.
When rpt_bad_qual_no_mr is set to 1, the worst quality value, 7, is used.
When rpt_bad_qual_no_mr is set to 2, the quality value from the previous measurement is
used. The default value is 0.
The following commands can be used to modify the parameters listed to specify the handover
decision process:
Commands
chg_act_alg_data.
chg_cell_element.
chg_element.
disp_cell.
add_cell.
add_neighbour.
If the neighbor is internal then add_neighbour prompts for the congestion_ho_margin.

Its default is the same as the per neighbor value of ho_margin. To disable handovers
for congestion to this cell, set this value to its maximum; to make it easy to trigger a
congestion handover to this cell, set it lower than the ho_margin of that cell.
If the neighbor is external then add_neighbour prompts for congestion_ho_margin and

whether or not directed retry is allowed to that cell.
Parameters
data_qual_enabled - This flag indicates whether an incoming call is voice or data. If data,
the RSS uses a different handover threshold.
dl_rxlev_ho_allowed - Sets the flag that enables or disables a handover due to downlink
receive level.
68P02901W36-S 8-39
Jul 2008
dl_rxqual_ho_allowed - Sets the flag that enables or disables a handover due to the
downlink receive quality and therefore interference as well.
dr_chan_mode_modify - This parameter 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 (as defined in 3GPP Technical Specification GSM 04.08). The BSS reads
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 since some MSs cannot interpret the channel _mode element of the
Handover Command.
handover_required_curr_ch - 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, as defined in 3GPP Technical Specification GSM 08.08.
handover_recognised_period - Sets the period for which a handover is disabled following

a ho_recognised message relating to the same call.
ho_margin_def - Sets the default value for the neighbor handover margin attribute of the
source cell, with respect to all neighbors.
hreqave - The number of reported averages required to produce one rolling average
of the measurement concerned.
hreqt - The number of averages required before N/P voting can happen.
l_rxqual_dl_h_data - Sets the downlink lower threshold for data handovers.
l_rxqual_ul_h_data - Sets the uplink lower threshold for data handovers.
l_rxqual_dl_p_data - Sets the downlink lower threshold for data power control.
l_rxqual_ul_p_data - Sets the uplink lower threshold for data power control.
max_tx_bts - Sets the maximum output power for a base station transmitter within its
power class, to establish a cell boundary.
max_tx_ms - Sets the maximum MS output power.
ms_distance_allowed - Sets the flag that enables or disables a handover due to the MS
BTS distance.
ms_txpwr_max_cell - Specifies the maximum MS transmit power in each neighbor cell.
msc_preference - This parameter sets the message flow sequence used on the A interface
for external handovers during the assignment procedure. This parameter must align
with the MSC expectations. The MSC implementation can depend on whether queuing is
enabled in the cell. This parameter is only applicable when dr_preference is enabled at
the BSC.
num_ho_cand - The number of handover candidates qualified to be in the ho_rec message.
rxlev_min_cell/rxlev_min_def-Sets the default value for receive levels in a cell and

therefore interference.
8-40 68P02901W36-S
Jul 2008
surround_cell - The averaging algorithm for neighbors of a serving cell. Produces the
rxlev_dl values for the neighbor side of the pbgt(n) formula.
ul_rxlev_ho_allowed - Sets the flag that enables or disables a handover due to uplink
receive level.
ul_rxqual_ho_allowed - Sets the flag that enables or disables a handover due to the uplink
receive quality and therefore interference as well.
dl_rxqual_ho_allowed - Sets the flag that enables or disables a handover due to the
downlink receive quality and therefore interference as well.
ul_interference_ho_allowed - Sets the flag that enables or disables a handover due to

the uplink interference.
dl_interference_ho_allowed - Sets the flag that enables or disables a handover due to

the downlink interference.
w_qual - A flag which can only be applied to quality related averaging mechanisms when
using the weighted averaging algorithm (1). Biases quality measurements in favour of the
most recent neighbor, for faster handover response for quality interference.
Database parameters are available for the enhanced congestion relief procedures:
congest_at_source - Used to control how a given cell behaves if it is unable to force a
given imperative handover. Enables the source cell to optionally retry an imperative,
intra-BSS only, handover to target cells which rejected the initial handover request and
initiated a congestion relief procedure.
congest_at_target - Controls the behavior of the target cell should it reject a handover
request, either imperative or congestion relief.
mb_tch_congest_thres - Used to control the percentage point at which a multiband MS

will start to be redirected to the preferred band.
rtry_cand_prd - 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 imperative or congestion relief attempt).
ext_rtry_cand_prd - 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 imperative or congestion relief attempt).
erc_ta_priority - Specifies the priority threshold for extended range cell neighbors.
rpt_bad_qual_no_mr - Specifies the values to enter for quality when the MS measurement
report has not been received.
System impact
Optimizes handovers between cells for MSs.
68P02901W36-S 8-41
Jul 2008
Related features Chapter 8: Power and Handover Control
Related features
The following features share functionality, or are otherwise related to the handover decision
algorithm feature:
Directed retry.
Congestion relief.
Class 7 algorithm for microcellular neighbor.
Microcellular handovers.
BSS measurement averaging.
8-42 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BA lists
BA lists

Reason for BA lists
BA lists enable neighbors to be allocated to system information messages to allow the MS to

monitor neighbors for handover purposes.
The BA(BCCH) list and BA(SACCH) list provide the neighbor cells that the MS monitors for
handover measurements.
Separate BA lists
Separate BA lists can be broadcast on the BCCH and on the SACCH.
The BA(BCCH) list defines the cells to be used in the reselection process and the BA(SACCH)
list defines the cells which are to be monitored in the handover process. There are a number of
options for using this facility to improve the idle mode behavior.
Neighbors can be placed in either or both lists:

The BA sent in system information message type 2 on the BCCH is a list of BCCH
frequencies in use by a given PLMN in a given geographical area. It is used by the MS
in cell selection and reselection.
The BA sent in system information message type 5 on SACCH indicates to the MS the
BCCH frequencies to be monitored for handover purposes.
By maintaining two distinct BA lists, the operator has the flexibility to vary the frequencies
the MS monitors in idle mode independent of the frequencies the MS monitors as potential
neighbors in active mode.
Frequencies
A combined total of 64 distinct frequencies can be set up in the BA(BCCH) and BA(SACCH) lists.
Each of the 64 frequencies can be included in one or both of these lists:
The BA(SACCH) is limited to a maximum of 32 neighbors due to a restriction of GSM,
which is consistent with the number of neighbors an MS is able to report.
The BA(BCCH) can contain up to 64 distinct neighbors, but only if all the frequencies
included in the BA(SACCH) are included in the BA(BCCH).
Adding neighbors to the lists
The add_neighbour command is used to add neighbors to the BA lists. The command is
essentially prompt-based after the first command line.
If the microcellular feature is purchased and activated, the MMI process also prompts for
microcellular specific information.
68P02901W36-S 8-43
Jul 2008
The ba_alloc_proc parameter is used with the BA lists feature. It sets a flag to enable or disable
reinitialization of the active block following a change in the broadcast control channel allocation
(BA) and to suspend subsequent measurements until the new BA is reported.
System impact
The add_cell command automatically places the specified cell in the BA(BCCH) neighbor list.
Related features
Handover decision process.
8-44 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation RXQUAL handover
RXQUAL handover

RXQUAL handover function
In areas of poor cell receiver quality (RXQUAL), the operator can choose to change cells, or if
this results in a ping-pong effect, not to change cells.
Intra-BSS repeated handover protection
On intra-BSS imperative handovers (for congestion or quality reasons), the BSS provides a
configurable time interval during which increased handover margins are applied to the original
cell for that call only to discourage handing the call back.
The criteria for excluding neighbors from the candidate list is PBGT(n)-MARGIN(n) <
0. The sorting of neighbors in the candidate list is performed according to the value of
PBGT(n)-MARGIN(n). The highest value begins first in the list; the others are included in
decreasing order.
Handover margin per cause
Two handover margins have been configured per neighbor, specific to the cause of the handover
being performed. This cause specific handover margin will always be used in determining if the
neighbor should be excluded from the candidate list.
ho_margin_rxqual[n] (63 to 63): The value to be applied to the PBGT calculation when
handover cause is RXQUAL.
If PBGT ho_margin_rxqual[n] < 0, the neighbor will be excluded.
ho_margin_rxlev[n] (-63 to 63): The value to be applied to the PBGT calculation when
handover cause is RXLEV.
If PBGT-ho_margin_rxlev[n] < 0, the neighbor will be excluded.
A per cell flag is used to determine if the cause-specific margin should be used in the candidate
ordering procedure.
ho_margin_usage_flag = 0. ho_margin[n] value (standard handover margin) will be used for

sorting the candidate list for RXLEV and RXQUAL handovers.
ho_margin_usage_flag = 1. ho_margin_rxqual[n] or ho_margin_rxlev[n] will be used for

sorting the candidate list for RXQUAL or RXLEV handovers.
Individual neighbors can be guaranteed not to be the target of a particular type of handover
by setting the cause-specific margin to the highest value. The margin can be set to control
the level at which the neighbor must be at before considering it as a candidate for a specific
handover cause.
68P02901W36-S 8-45
Jul 2008
Application
With this feature, there is more flexibility since it gives a possibility to:
Avoid the handover to unwanted neighbors where the call will be at risk.
Sort the neighbors in the desired order, for going to the less congested cells or to the
less interfered neighbors.
Handover the calls only to good neighbors. For some of them this condition will be
satisfied, even with negative PBGT to the server and for others, it will be necessary to
have positive PBGT.
Time limitation for excessive intra-cell handover
The hop_count_timer limits the number of intra-cell handovers due to interference which can
occur in a specified amount of time. If a specified number of handovers occur within a specified
amount of time, the handover will be escalated to be an RXQUAL handover to another cell. A
value of 0 for hop_count_timer disables the functionality, which will result in no limit to the
number of intra-cell handovers.
Parameters
The following parameters are used with RXQUAL handovers:
prioritize_microcell - Modifies the margin of the source cell during which the protection from
unnecessary handovers is applied. Restricted for use with microcellular handovers.
hop_count - A per cell parameter added for RXQUAL handovers.
hop_count_timer - A per cell parameter added for RXQUAL handovers.
layer_number - A per cell parameter added for RXQUAL handovers.
System impact
Prefer different carrier for intra-cell handover
This functionality is always enabled. Even though the new channel may have a higher level
of uplink interference, if it is believed a carrier change is likely to be in the best interest of
most mobiles experiencing an interference situation. This situation can only change if the
interference band of the target timeslot is higher than the serving carrier timeslot. To avoid
this band zero can be made large so all timeslots fall within it.
8-46 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Related features
Intra-BSS handover ping-pong protection
If a quality handover ends in a cell with less power budget than the cell in which provoked the
handover quality problems, the MS hands back to the original cell for better cell reasons. This
process is repeated for the duration of the call and therefore results in lower quality of service.
This is prevented by using bounce protection.
Micro-micro quality handover
This allows microcells (neighbor types 3, 4, 5 and 6) to be the preferred candidates for
handovers when the cause value is RXQUAL. Without this feature, the preferred candidate
would be a type 1 or 2 neighbor which is normally a macrocell. This allows the flexibility to
target microcells if they are available and keep the traffic within the microcell layer.
Prefer different carrier for intra-cell handover
This functionality is always enabled. Even though the new channel can have a higher level
of uplink interference, if it is believed a carrier change is likely to be in the best interest of
most mobiles experiencing an interference situation, band zero can be made larger in order
to capture a wider variety of idle channels.
Intra-BSS handover ping-pong protection
If a quality handover ends in a cell with less power budget than the cell in which provoked the
handover quality problems, there can be unnecessary inter-BSS handovers and lower service
quality.
Micro-micro quality handover
Not having this flexibility results in unnecessary inter BSC handovers, which degrades the
system's capacity. The only way to use this handover class is by defining the micros as type 2
neighbors. This excludes them from other HO types, such as 3 or 4, which leaves the macros as
the only practical type 2 neighbors.
Time limitation for excessive intra-cell handover
If the timer is disabled, there is no limit to the number of intra-cell handovers.
Related features
68P02901W36-S 8-47
Jul 2008
Inter-BSS handover Chapter 8: Power and Handover Control
Inter-BSS handover

Message sequences
In this section message sequences are shown for inter-BSS handover as follows:
Successful handover
Between internal processes and the GSM elements.
This is handover between two different BSSs and controlled by the MSC.
Successful handover
Between GSM elements
Figure 8-17 shows the successful inter-BSS handover sequence between the GSM elements:
8-48 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Successful handover
Figure 8-17 Successful inter-BSS handover between GSM elements
NOTE
The message sequence for a multiband handover reassignment is the same as for a
normal single band handover. When a handover is required to assign a TCH on a
different frequency band, the HANDOVER COMMAND message is used. The only
difference is the ARFCN of the target cell. For further information refer the section
SDCCH handovers on page 8-106.
Between internal processes-Source cell
Figure 8-18 shows the successful inter-BSS handover sequence within and between the BSC and
BTS processes in the source cell:
68P02901W36-S 8-49
Jul 2008
Successful handover Chapter 8: Power and Handover Control
Figure 8-18 Successful inter-BSS handover sequence
8-50 68P02901W36-S
Jul 2008
Between internal processes-Target cell (piggy-backed)
A HANDOVER REQUEST message from the MSC can be encapsulated within a CR (Connection
Request) message, or separate when a connection has already been established by a preceding
CR message. Both methods are valid GSM MSC implementations. The former is also known as a
piggy-backed handover request and is the most common method. The differences in message
sequence and timers in the target cell are shown in the two diagrams.
Figure 8-19 shows the successful inter-BSS handover sequence within and between the BSC
and BTS processes in the target cell, when the HANDOVER REQUEST message is received
encapsulated (piggy-backed) within a CR message.
68P02901W36-S 8-51
Jul 2008
8-52 68P02901W36-S
Jul 2008
Between internal processes-Target cell (separate from CR)
Figure 8-20 shows the successful inter-BSS handover sequence within and between the BSC
and BTS processes in the target cell, when the HANDOVER REQUEST message is received
separately from a CR (Connection Request) message. A connection has already been established.
68P02901W36-S 8-53
Jul 2008
8-54 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation EFR in inter-BSS handovers
EFR in inter-BSS handovers
For the MS to change the codec mode from EFR to FR it must receive the CHANNEL MODE
element in the HANDOVER COMMAND. The target BSS builds the HANDOVER COMMAND
following receipt of the HANDOVER REQUEST message from the MSC. The target BSS includes
the channel mode element only if the HANDOVER REQUEST message contained the speech
version (used) field. The MSC builds the HANDOVER REQUEST message after receipt of the
HANDOVER REQUIRED message from the source BSS. The MSC only includes the speech
version (used) field in the HANDOVER REQUEST message if the source BSS included the
speech version (used) field in the HANDOVER REQUIRED message. The source BSS should
always include the speech version (used) field in the HANDOVER REQUIRED message in
the case of a speech call.
If the source BSS, MSC and target BSS all obey the GSM recommendations, there should be no
audio problems following an EFR to FR handover.
68P02901W36-S 8-55
Jul 2008
Inter-BTS handover Chapter 8: Power and Handover Control
Inter-BTS handover

Message sequences
In this section message sequences are shown for the inter-BTS handover procedure as follows:
Successful handover
This is handover between two different cells in the same BSS and controlled by a common BSC.
Handover successful
Figure 8-21 shows a successful inter-BTS handover between GSM elements:
Figure 8-21 Successful inter-BTS handover between GSM elements
8-56 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Handover successful
NOTE
The message sequence for a multiband handover reassignment is the same as for a
normal single band handover. When a handover is required to assign a TCH on a
different frequency band, the HANDOVER COMMAND message is used. The only
difference is the ARFCN of the target cell as described in section SDCCH handovers
on page 8-106 in this chapter.
Handover successful (internal)
Figure 8-22 and Figure 8-23 show a successful inter-BTS handover between internal processes
and the GSM elements:
68P02901W36-S 8-57
Jul 2008
Handover successful Chapter 8: Power and Handover Control
Figure 8-22 Successful inter-BTS handover (Part 1)
8-58 68P02901W36-S
Jul 2008
Figure 8-23 Successful inter-BTS handover (Part 2)
68P02901W36-S 8-59
Jul 2008
Intra-Cell handover Chapter 8: Power and Handover Control
Intra-Cell handover

Message sequences
In this section message sequences are shown for intra-cell handover as follows:
Successful handover
Intra-cell handovers are between channels within the same cell. The target cell is the same as
the source cell.
Handover successful
Successful handover between GSM elements
Figure 8-24 shows a successful intra-cell handover between GSM elements:
Figure 8-24 Successful intra-cell handover
8-60 68P02901W36-S
Jul 2008
Between internal processes-Intra-cell
Figure 8-25 and Figure 8-26 show a successful intra-cell handover between internal processes
and the GSM elements (source and target cells) in two parts:
68P02901W36-S 8-61
Jul 2008
Handover successful Chapter 8: Power and Handover Control
Figure 8-25 Successful intra-cell handover between source and target cells (Part 1)
8-62 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BSS forced handovers
Figure 8-26 Successful intra-cell handover between source and target cells (Part 2)
BSS forced handovers
Forced intra-cell handover due to equipment failure
When a carrier or a Physical channel (PCHN) is taken out-of-service (due to operator

intervention or equipment failure), any busy calls that are affected are handed over to another
carrier within the cell. This handover takes the form of an intra-cell handover. Calls residing on
TCHs becoming barred to traffic as a result of terrestrial resources being taken out-of-service
(due to operator intervention or equipment failure) can have the same type of handover.
Forced intra-cell handovers are triggered due to equipment failure for Half-Rate (HR) channels.
This can mean that two HR calls must be handed over when a single timeslot goes out-of-service.
68P02901W36-S 8-63
Jul 2008
BSS forced handovers Chapter 8: Power and Handover Control
Up to two forced intra-cell handovers are triggered (due to equipment failure) per timeslot,
dependent on the number of busy traffic channels on the timeslot. The target resource for the
handover is Full-Rate (FR) in preference to HR.
The channel mode of the call can alter during a forced intra-cell handover due to operator
intervention or equipment failure.
NOTE
If the channel mode of the traffic channel changes from HR to FR and the capacity
of the cell has already been reduced by the resource (carrier or PCHN) going
out-of-service, there is a possibility that congestion procedures can be initiated.
Forced intra-cell handover due to GPRS reconfiguration
Before a timeslot supporting a circuit switched call can be reconfigured back to a PDTCH, the
BSS must force the call on the timeslot to perform an intra-cell handover to another resource.
The BSS will trigger forced intra-cell handovers for busy HR channels when the resource they
are using is required to be reconfigured as a PDTCH.
Forced intra-cell handover due to CBCH provisioning
Before a timeslot supporting a circuit switched call can be reconfigured to an SDCCH for CBCH
provisioning, the BSS must force the call existing on the timeslot to perform an intra-cell
handover to another resource. The BSS will trigger forced intra-cell handovers for busy HR
channels when the resource they are using is required to be reconfigured as an SDCCH for
CBCH provisioning.
Forced EGSM intra-cell handover
Forced EGSM handovers are enabled through the BSS database. A forced EGSM handover is an
intra-cell handover of an EGSM capable call from a PGSM traffic channel to an EGSM traffic
channel. Forced EGSM handovers are performed when the BSS needs to free a PGSM channel
for use by a non-EGSM capable call, because there are no PGSM resources available. If the
EGSM forced handover is not performed then the incoming PGSM call must be queued (if
allowed).
Forced EGSM handover functionality is modified to take into account AMR HR calls. Only an
incoming FR PGSM call could force up to two HR calls to be forced, to perform an intra-cell
handover to make a PGSM resource available. Alternatively, an incoming HR only PGSM call,
could force an HR call to be forced to perform an intra-cell handover to make a PGSM HR
resource available.
The forced handover of two EGSM AMR HR calls onto any channel rate or speech version
on an EGSM carrier is supported.
8-64 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BSS forced handovers
NOTE
The BSS attempts to handover the HR call(s).
The BSS cannot guarantee the success of these handover(s). Hence, the availability of a resource
for the incoming PGSM only capable MS is not guaranteed by triggering this procedure.
68P02901W36-S 8-65
Jul 2008
Adaptive power handovers Chapter 8: Power and Handover Control
Adaptive power handovers

Purpose of adaptive power handovers
The purpose of this feature is to allow the operator to define a cumulative area on a per cell
basis for adaptive power budget handovers.
Description of power control
Before adaptive handover implementation, power handovers occurred based on voting criteria
such that if the most recent average met certain criteria then a need for a handover was
recognized. Adaptive handovers can occur more rapidly when conditions are deteriorating
quickly and less rapidly when conditions are only marginally poor. A per cell cumulative area is
maintained and updated at each measurement. As long as a marginal need for a handover exists
the area is incremented (based on the difference between a handover threshold and the current
measurement). The area is reset to zero any time there is no marginal need for a handover,
except for adaptive power budget handovers where a leaky bucket criteria is used instead.
When the cumulative area reaches a trigger point (depending on type of adaptive handover), a
handover need is recognized and a handover cause generated.
Adaptive handovers are triggered based on measurements in a cumulative area rather than
by vote. At each measurement report the cumulative area is updated and compared to a
cumulative trigger. The leaky bucket methodology is used in updates of the cumulative area.
This means that if the power budget (pbgt) dips below the handover margin temporarily then
the cumulative area will be decremented by the difference between the power budget and the
handover margin. The cumulative area will be reset only if the cumulative area dips below
this difference. This assures the call will be more often handed over to the better cell. If this
cumulative area is then greater than the cumulative pbgt trigger, a need for a handover is
recognized. The cumulative area is on a per cell basis.
The following parameters can be used with the chg_element or chg_cell_element commands:
adap_ho_pbgt - Specifies whether the system allows adaptive power budget handovers.
The cumulative area for the adaptive power budget handovers can be defined as per
cell or per neighbor.
adap_ho_rxlev - Specifies whether the system allows adaptive receive level handovers.
adap_ho_rxqual - Specifies whether the system allows adaptive quality handovers.
8-66 68P02901W36-S
Jul 2008
adap_ho_alt_trigger_rxqual - Specifies whether the system uses alternative trigger

values for adaptive quality handovers for a cell which is frequency hopping.
adap_trigger_pbgt - Specifies the cumulative trigger level for adaptive power budget
handovers. When the threshold set by this parameter is exceeded, the system triggers a
handover to a better cell.
adap_trigger_rxlev_dl - Specifies the cumulative trigger level for adaptive receive level
downlink handovers. When the threshold set by this parameter is exceeded, the system
performs a downlink strength handover.
adap_trigger_rxlev_ul - Specifies the cumulative trigger level for adaptive receive level
uplink handovers. When the threshold set by this parameter is exceeded, the system
performs an uplink strength handover.
adap_trigger_rxqual_dl - Specifies the cumulative trigger level for adaptive rxqual

downlink handovers. When the threshold set by this parameter is exceeded, the system
performs a downlink quality handover.
adap_trigger_rxqual_ul - Specifies the cumulative trigger level for adaptive rxqual uplink
handovers. When the threshold set by this parameter is exceeded, the system performs an
uplink quality handover.
adap_trigger_hop_rxqual_dl - Specifies the trigger threshold for downlink rxqual to be

used for calls which are frequency hopping.
adap_trigger_hop_rxqual_ul - Specifies the trigger threshold for uplink rxqual to be

used for calls which are frequency hopping.
68P02901W36-S 8-67
Jul 2008
Handovers in single BCCH dual band cells Chapter 8: Power and Handover Control
Handovers in single BCCH dual band cells

Overview of dual bands handover types
There are three types of dual band handover in single BCCH dual band cells as follows:
Intra-cell, intra-band handover.
Intra-cell, inter-band (zone) handover.
Inter-cell, intra-band handover.
Inter-cell, inter-band (zone) handover.
The dual band cells feature used with the Concentric Cells feature makes it possible to perform
intra-cell handovers within the secondary and primary bands as well as between the secondary
and primary bands of a dual band cell.
A description of the single BCCH for dual band cells feature is given in Single BCCH for Dual
Band Cells in Chapter 5 Cells of this manual.
Intra-cell, intra-band handover
This option is a function of signal quality and level. It can be applied if either signal quality
is poor and the signal level exceeds the interference threshold, or interference is detected.
If signal quality is poor then all other possibilities must have been eliminated, before the
handover is attempted. If interference is detected then an intra-band handover is attempted as
the preferred option.
The parameters that influence this type of handover are:
intra_cell_handover_allowed - Disables or enables intra-cell handovers under two conditions:

to begin the handover or to begin the handover when co-channel interference is suspected.
l_rxlev_dl_h - Specifies the handover thresholds for the lower Receive (Rx) level downlink. This
threshold is checked to determine if a handover condition exists.
l_rxlev_ul_h - Specifies the handover threshold for the lower Receive (Rx) level uplink. This
threshold is checked to determine if a handover condition exists.
l_rxqual_dl_h - Specifies the handover control threshold for the lower Received (Rx) quality
downlink. This threshold is checked to determine if a handover condition exists.
l_rxqual_ul_h - Specifies the handover control threshold for the receive (Rx) quality uplink.
This threshold is checked to determine if a handover condition exists.
A description of these parameters, giving value ranges and defaults is provided in the Technical
Description: BSS Command Reference (68P02901W23) manual.
8-68 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Overview of dual bands handover types
Intra-cell, inter-band (zone) handover
This option is applied if signal quality is poor and requires that the calling MS is multiband.
Because the GSM Specifications contain different power level definitions for each frequency
band, the BSS performs power level conversions during intra-cell channel changes between
channels of different frequency bands.
There are two possible sets of criteria that must be met for inter-band handovers to occur
as follows:
Outer to inner zone handover; demands the following criteria are met:
Uplink and downlink signal level poor.
Parameter outer_zone_usage_level equaled or exceeded.
No neighboring cells meet the requirements of parameter pbgt(n).
Inner to outer zone handover; demands the following criteria are met:
Uplink and downlink signal level poor.
No neighboring cells meet the requirements of parameter pbgt(n).
Inter-cell handover
Inter-cell handovers can be divided in to two distinct categories:

Non imperative - Triggered by loss of signal level, power budgeting considerations
or for congestion relief. Traffic congestion is calculated from the outer zone traffic
only, as the inner zone is designated as the preferred zone and so handles more traffic
in general. An inter-cell handover due to congestion will only occur when parameter
outer_zone_usage_level is equaled or exceeded and calls cannot be moved to the inner
zone.
Imperative - Triggered when the quality drops below the thresholds set by the parameters
l_rxqual_dl_h and l_rxqual_ul_h, or the signal level drops below the thresholds set by the
parameters l_lxlev_dl_h and l_rxlev_ul_h.
The dual band cells feature used with the Concentric Cells feature makes it possible 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 level to the neighbor cell BCCH signal level. This
means the signal level in a dual band cell must come from the primary zone. When the call is
in the secondary zone, the signal level 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. There are two ways to obtain the primary zone signal level,
selectable through the dual_band_pbgt_mode database parameter, as follows:
dual_band_pbgt_mode = 0
dual_band_pbgt_mode = 1
68P02901W36-S 8-69
Jul 2008
Overview of dual bands handover types Chapter 8: Power and Handover Control
The effect of these settings is described below. The terms shown in emphasized text are MMI
command parameters that can be changed by the system operator.
A description of these parameters, giving value ranges and defaults is provided in the Technical
Description: BSS Command Reference (68P02901W23) manual.
Dual band power budget parameter set to 0
When the MS is assigned to a resource on the secondary band, the MS uses the serving channel
measurements with the subtraction of the dual band offset (set by the dual_band_offset
parameter) when calculating the power budget for a neighbor with the BCCH frequency
allocated from the primary frequency band, as follows:
RXLEV_DL (EST_BCCH) = rxlev_dl_zone-dual_band_offset
If we put this into the power budget equation:
PBGT(n) = (Min(max_tx_ms, P)-RXLEV_DL (EST_BCCH)-PWR_CD)
-(Min(max_tx_ms(n), P)-RXLEV_NCELL(n))
Where: Is:
PBGT(n) power budget for neighbor n.
Min Minimum (least of).
max_tx_ms maximum power the MS would be allowed in the outer zone.
P maximum transmit power capability of the MS in the outer
zone frequency band.
RXLEV_DL(EST_BCCH) downlink receive level (allocated BCCH frequency).
PWR_CD maximum downlink power permitted in the outer zone minus
the BTS actual downlink power.
max_tx_ms(n) maximum power the MS is allowed in the neighbor cell.
RXLEV_NCELL(n) reported neighbor cell signal level.
Dual band power budget parameter set to 1
The SACCH System Information messages for all channels are modified to include the serving
cell BCCH frequency. The MS reports serving cell signal level for the primary band, which can
be used in the calculation of power budget for neighbors with BCCH frequency allocated from
the same frequency band as the serving cell BCCH. If the MS does not report on the serving
cell, the serving channel measurements are used with the addition of the dual band offset (just
as for dual_band_pbgt_mode = 0).
NOTE
When the BSS software adds the primary band BCCH frequency to the neighbor
cells description, the number of actual neighbor frequencies which can be sent to
the MS is reduced by 1.
8-70 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Statistics useful with single BCCH for dual band cells
When the operator has specified a full set of neighbor frequencies and the serving cell BCCH
frequency must be added to the list, the operator must remove a neighbor before enabling the
feature. Since the serving cell BCCH is the strongest neighbor cell, the MS is likely to report
on the serving cell in every measurement report. This process reduces the number of true
neighbors the MS can report on from six to five in each measurement report, assuming that the
BCCH frequency is one of the strongest neighbors.
When dual band cells are enabled at the BSS and measurement reports indicate that a particular
MS needs to hand over from a cell, the order of the neighbors in the candidate list is affected
by the setting of the band_preference parameter as defined in the Multiband Inter-cell
Handover in this chapter. However, this cell ordering is based only on the frequency type of the
BCCH of the neighbor cell. As the target cell can have available channels of different frequency
bands, a channel from the secondary band could be selected at the target cell. The channel
selection algorithm used at the target cell of an inter-cell handover is defined in Table 5-7
in Chapter 5 Cells of this manual.
Statistics useful with single BCCH for dual band cells
As the dual band cells optional feature is an extension of the Concentric Cells optional feature,
tracking of inter-band channel changes (handovers) is accomplished using the statistics
provided for the Concentric Cells feature, handovers and the Multiband feature.
A more detailed description of these statistics is provided in Maintenance Information: GSM

Statistics Application (68P02901W56) manual.
Concentric cell statistics
This section contains a brief reminder of the functions of these statistics, some peggings of
which have been changed for dual band cell use.
TCH_USAGE_INNER_ZONE: Measures the usage of TCHs belonging to carriers in the inner

zone. This statistic is the sum of the time that each TCH was active with a call for all TCHs on
the inner zone. This statistic is activated per cell.
TCH_USAGE: When the Dual band cell feature is enabled, this statistic measures the usage of
TCHs belonging to carriers in the outer zone. This statistic is activated per cell basis.
TCH_CONGESTION: Measures the total length of time in which all of the TCHs in a cell are
busy. The timer for this statistic is started when all TCHs belonging to the cell are busy. When
the Dual band cell feature is enabled, this statistic measures the usage of TCHs belonging to
carriers in the outer zone. This statistic is activated per cell basis.
TCH_CONG_INNER_ZONE: Measures the total length of time in which all of the TCHs in the
inner zone are busy. The timer for this statistic is started when all TCHs belonging to TCHs
in the inner zone are busy. The timer is stopped when an inner zone TCH is set free. This
statistic is activated per cell.
ZONE_CHANGE_ATMPT: Counter array statistic that is used to track attempts of each type of
dual band cell-specific handover. This statistic is activated per cell. Table 8-5 shows the bins
used for each type of handover attempt.
68P02901W36-S 8-71
Jul 2008
Statistics useful with single BCCH for dual band cells Chapter 8: Power and Handover Control
Table 8-5 Bins used for each handover type
Bin Handover type Description

0 INNER_TO_OUTER_ZONE Number of handover attempts inner to outer
zone.
1 OUTER_TO_INNER_ZONE Number of handover attempts outer to inner
zone.
2 INTRA_ZONE Number of intra-zone handover attempts.
3 TCH_ASSIGN_TO_INNER_ZONE Number of TCH assignment attempts directly to
inner zone cells.
4 IN_INTER_CELL_HO_TO_IN_ZONE Number of internal inter-cell handover attempts
to inner zone.
ZONE_CHANGE_SUC: Counter array statistic that is used to track each type of successful
concentric cell specific handover. This statistic is activated per cell. Table 8-5 shows the bins
used for each type of successful handover attempt.
Table 8-6 Bins used for each successful handover type
Bin Handover type Description

0 INNER_TO_OUTER_ZONE Number of successful handover attempts inner
to outer zone.
1 OUTER_TO_INNER_ZONE Number of successful handover attempts outer
to inner zone.
2 INTRA_ZONE Number of successful intra-zone handover
attempts.
3 INTRA_ZONE_HO Number of successful TCH assignment attempts
directly to intra zone cells.
4 IN_INTER_CELL_HO_TO_IN_ZONE Number of successful internal inter-cell
handover attempts to inner zone.
Each bin is pegged when a corresponding dual band cell handover is successful.
8-72 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Statistics useful with single BCCH for dual band cells
Multiband statistics
MS_TCH_USAGE_BY_TYPE: Counter array statistic that tracks the length of time spent on TCHs
by the various types of MSs. Duration is measured in deciminutes. (One deciminute equals six
seconds. For example, if MS_TCH_USAGE_BY_TYPE = 31, the call duration was 3.1 minutes or
186 seconds). The type of MS is included in the MS Classmark 3 information. This statistic is
activated per cell. Table 8-7 shows the bins used for each MS bandwidth capability.
Table 8-7 Bins used for each MS bandwidth capability
Bin MS capability Description

0 MS_PGSM_ONLY Base GSM band only
1 MS_DCS 1800_ONLY DCS 1800 band only
2 MS_PCS 1900_ONLY PCS 1900 band only
3 MS_PGSM_EGSM Base and extended GSM bands
4 MS_PGSM_DCS 1800 Base GSM and DCS 1800 bands
5 MS_PGSM_EGSM_DCS 1800 Base GSM, extended GSM and DCS 1800 bands
6 MS_PGSM_PCS 1900 Base GSM and PCS 1900 bands
7 MS_PGSM_EGSM_PCS 1900 Base GSM, extended GSM and PCS 1900 bands
MS_ACCESS_BY_TYPE: This is a counter array statistic that tracks the number of system
accesses by the various types of MSs. This statistic is activated per cell.
Handover statistics
Here are the main statistics pegged by dual band cells.
INTRA_CELL_HO: Intra-cell Handover. Pegged to measure the number of intra-cell (same

source and target cell) handover situations and excludes any range intra-cell handovers. This
statistic is activated per cell.
This statistic is subdivided into individual counters as follows:
INTRA_CELL_HO_REQ: Intra-cell handover (Channel Assignment) required. The counter is

incremented each time there is a requirement for an intra-cell handover.
INTRA_CELL_HO_ATMPT: Intra-cell handover attempt. The counter is incremented each time

an intra-cell handover is attempted.
INTRA_CELL_HO_SUC: Intra-cell handover success. The counter is incremented for each

Handover Performed message that is sent to the MSC, after an intra-cell handover completes
successfully.
OUT_HO_NC_SUC: Successful outgoing inter-cell handovers per target cell.

This statistic is pegged at the same time as the intra-BSS handover completed
statistic OUT_INTRA_BSS_HO_SUC and the incoming intra-BSS handover statistic
IN_INTRA_BSS_HO_SUC for an internal inter-cell handover. However, for an external handover,
this statistic is pegged when the BSS receives a Clear Command message from the MSC,
indicating a successful handover. The difference is that this per neighbor statistic instance
specifies both the target cell and the source cell of the handover instead of one or the other.
The target cell in the instance is represented by its BCCH frequency and by its BSIC. This
statistic is activated per neighbor.
68P02901W36-S 8-73
Jul 2008
Statistics useful with single BCCH for dual band cells Chapter 8: Power and Handover Control
OUT_HO_NC_CAUSE_ATMPT: Attempted outgoing inter-cell handovers per target cell per cause.
This large counter array statistic is pegged at the same time as OUT_INTRA_BSS_HO_ATMPT
for internal inter-cell handovers and as OUT_INTER_BSS_HO_ATMPT for external handovers.
The difference is that this per neighbor statistic instance specifies both the source cell and the
target cell of the handover instead of just the source cell. The target cell in the instance is
represented by its BSIC and BCCH frequency. This also tracks the cause for the handover. This
statistic is activated per neighbor.
Table 8-8 shows the bins used for each type of cause and the reason for the handover.
Table 8-8 Bins used for causes per handover reason
Bin Cause Description

0 UPQUAL Handovers due to uplink quality
1 UPLEVEL Handover due to uplink level
2 DOWNQUAL Handovers due to downlink quality
3 DOWNLEVEL Handovers due to downlink level
4 DISTANCE Handovers due to distance
5 UPINTERF Handovers due to uplink interference
6 DOWNINTERF Handovers due to downlink interference
7 POWERBDGT Handovers due to power budget
8 CONGESTION Handovers due to congestion
9 ADJ_CHAN_INTF Handovers due to adjacent channel interference
10 BAND_RE_ASSIGN Handovers due to band reassignmnet
11 BAND_HANDOVER Handovers between bands
IN_INTRA_BSS_NC_SUC: Successful incoming internal inter-cell handovers per originating

cell. This statistic is pegged at the same time as OUT_INTRA_BSS_HO_SUC and
IN_INTRA_BSS_HO_SUC, (these are bins and not statistics of the statistics). The difference
is that this per neighbor statistic specifies both the target cell and the source cell of the
handover and not only one or the other. The source cell in the instance is represented by its
BCCH frequency and by its BSIC. This statistic is activated per neighbor.
IN_INTRA_BSS_NC_ATMPT: Attempted incoming internal inter-cell handovers per originating

cell. This statistic is pegged at the same time as the intra-BSS handover required statistic
OUT_INTRA_BSS_HO_REQ. The difference is that this per neighbor statistic instance specifies
both the target cell and the source cell of the handover and not only the source cell. The source
cell in the instance is represented by its BSIC and BCCH frequency. This statistic is activated
per neighbor.
OUT_HO_CAUSE_ATMPT: Attempted outgoing inter-cell handovers per Cause per

cell. This statistic is pegged at the same time as the intra-BSS handover attempt
statistic OUT_INTRA_BSS_HO_ATMPT and the inter-BSS handover attempt statistic
OUT_INTER_BSS_HO_ATMPT, (these are bins of OUT_INTRA_BSS_HO and
OUT_INTER_BSS_HO respectively). This statistic also tracks the cause for the handover. This
statistic is activated per cell. Table 8-8 shows the bins used for Causes per handover reason.
INTERBAND_ACTIVITY: Counts the interband handover attempts based on the target frequency
band. The statistics consist of several bins, where each bin is used for recording the number of
multiband handover attempt and failure. Assignment and handover failures due to incorrect
or unsupported frequency information are also tracked. This statistic is activated per cell.
Table 8-9 lists the bins, causes and the target band types.
8-74 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Adaptive Multi-Rate dual band cells
Table 8-9 Bins, Causes and the target band types
Bin Cause Description

0 PGSM_HO_ATMPT Attempts to handover to base GSM band
1 EGSM_HO_ATMPT Attempts to handover to Extended GSM band
2 DCS 1800_HO_ATMPT Attempts to handover to DCS 1800
3 PCS 1900_HO_ATMPT Attempts to handover to PCS 1900
4 PGSM_HO_FAIL Handover failure to GSM band
5 EGSM_HO_FAIL Handover failure to Extended GSM band
6 DCS 1800_HO_FAIL Handover failure to DCS 1800 band
7 PCS 1900_HO_FAIL Handover failure to PCS 1900 band
8 INVALID_FREQ_ASGN Frequency no implemented for assignment request
9 INVALID_FREQ_HO Frequency not implemented for handover
Adaptive Multi-Rate dual band cells
Existing congestion relief procedures are instigated in both the inner and outer zone of dual
band cells based upon outer zone-specific congestion thresholds. For the new AMR half-rate
channel mode congestion relief procedures, this philosophy is modified. The AMR half-rate
congestion procedures are only applied to the inner zone of a dual band cell when both the outer
and inner zones have exceeded the relevant congestion thresholds.
In addition, prior to the qualification of a dual band MS (due to RxLev) to be allowed access to
the inner zone upon SDCCH to TCH assignment, the BSS reserves an inner zone timeslot for the
call. This is so that a resource is available after the qualification procedure is complete. With
the introduction of the half-rate channel mode, the channel reserved for the dual band MS could
be a half-rate or full-rate channel. Whether the BSS allocates a full-rate or half-rate channel is
governed by a number of factors as follows:
Congestion levels
force_hr_usage
MSC preference
If the BSS finds that the criteria for allowing the assignment of a half-rate channel have been
exceeded then a half-rate channel is reserved. The BSS reserves a half-rate channel for a multi
band MS being assigned to the inner zone of a dual band cell, if the criteria set by the MSC
preference and operator preference allow it.
68P02901W36-S 8-75
Jul 2008
Multiband inter-cell handover Chapter 8: Power and Handover Control
Multiband inter-cell handover

Multiband inter-cell handover function
Mobile Stations (MSs) can operate in any one of the currently supported frequency bands:
Primary GSM (PGSM) 900.
Extended GSM (EGSM) 900.
DCS 1800.
PCS 1900.
With the multiband inter-cell handover feature, MSs can operate in any of these bands for
which they are capable, though only one band at a time. There are MSs that are capable of
operating in any of these bands and the network provides support for dynamic inter-cell
switching between these bands.
A single cell can serve multiple frequency bands and have a common BCCH. Intra-cell handovers
between channels of differing frequency bands is not supported, unless the Single BCCH for
dual band cells feature is unrestricted. See Handovers in single BCCH dual band cells
section in this chapter. The one exception to this stipulation is allowed intra-cell channel change
(also known as handover) between PGSM and EGSM bands. This feature incorporates concepts
of Directed Retry at assignment (SDCCH to TCH). The BSS can optionally be configured to
attempt to assign a TCH of a configurative preferred frequency band of operation. The BSS
attempts this type of TCH assignment should the preferred BSS band differ from the chosen
MS band of operation.
8-76 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Multiband inter-cell handover function
Network summary
Figure 8-27 shows a multiband inter-cell handover. 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.
Figure 8-27 Multiband inter-cell handover
Infrastructure sharing
BSS software supports multiple frequency types per BSS. Multiband inter-cell handover
supports multiple frequency types per BTS site and supports multiple frequency types inside the
same cabinet. The software makes sure that the configuration of cells and carriers conforms to
the constraints of the cabinet which supports these devices.
Related parameters
The parameter sdcch_tch_band_reassign_delay, in a multiband handover, sets the number

of measurement report periods that the RSS waits before corresponding to CRM if the MS
does not report a preferred band neighbor.
68P02901W36-S 8-77
Jul 2008
System impact Chapter 8: Power and Handover Control
System impact
There is a change to the use of Radio Resource (RR) commands for multiband MSs and hence
a need to change the processing of these commands. Sending messages to an MS with
frequencies that the MS cannot support should result in the MS sending up either RR STATUS
failures, an ASSIGNMENT FAILURE, or a HANDOVER FAILURE depending on the situation. An
MS which informs the BSS of such a problem, stays on its current channel and this should force
the BSS to prevent sending such messages for the duration of that call connection.
For multiband MSs, the strongest non-serving carriers can belong to different frequency bands.
In order to deal with this, the MS will be allowed to report frequencies from any band in the
measurement reports sent uplink by the MS. The amount and type of frequencies reported by
the MS is controlled by a database configurative parameter which is broadcast in BCCH SI type
2ter and SACCH SI type 5ter messages. This will allow the BSS to then select from these
frequencies and order a handover to the best carrier regardless of frequency band.
Related features
Directed retry.
8-78 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Adaptive Multi-Rate (AMR) multiband handover
Adaptive Multi-Rate (AMR) multiband handover

Multiband handover allows a dual band MS established on a band which is not the preferred
band for this cell, to attempt an inter-cell handover to preferred band neighbor cells or preferred
band layers within neighbor cells. This mechanism can be triggered in three different ways,
as specified by operator:
During handover triggered by radio conditions.
Forced inter-cell handover when the MS is not established on the preferred band.
During SDCCH to TCH assignment.
The first two options are treated as normal inter-cell handovers. The last option is specifically
impacted by the introduction of the AMR Half-Rate (HR) channel mode.
A timeslot is reserved in the source cell (outer zone) to be used in case the inter-cell handover to
a preferred band neighbor is unsuccessful.
If the MSC specifies that the call must be assigned an HR channel, or if the congestion levels
and channel allocation criteria in the source cell dictate that an HR channel must be used, a
half-rate traffic channel is reserved in the source cell. The decision to reserve a Full-Rate (FR)
or HR channel is based on the same criteria as if the MS was allocated to a TCH resource in
the source cell.
If an HR traffic channel is reserved on a free generic traffic timeslot, the other HR traffic
channel on that timeslot is regarded as the idle HR traffic channel of a single occupancy HR
traffic timeslot. For an FR channel, the half-rate capable traffic timeslots will be conserved
within the cell where possible.
68P02901W36-S 8-79
Jul 2008
Coincident multiband handover Chapter 8: Power and Handover Control
Coincident multiband handover

Coincident multiband handover
Coincident multiband handover enables operators to install new radios in a different frequency
band and more easily configure multiple frequencies. 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 optimizing the existing infrastructure. With
the addition of a secondary frequency band, with different propagation characteristics, this
optimization 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 optimizing two networks, it is logical that the new secondary frequency
band should complement the existing infrastructure. To achieve this, the software must
be configurable enough to allow the new frequency band to use the same cell boundaries
established by the original frequency band and to allow the new frequency band cells to use
the handover measurement reports based on the cells in the original frequency band. This can
be done by using mobile-reported measurement reports of the primary frequency band while
a call is established on the secondary frequency band. This allows the mobile to be handled
as if it were on the primary frequency band, using the primary boundaries and minimizing
propagation characteristic differences, whilst not taking any primary frequency band resources.
The software redirects the calls capable of operating in the secondary band to the secondary
band, so that the primary band does not get congested.
This feature is designed to complement the Multiband Inter-cell Handover feature and the
functionality described here is available only if that feature is enabled.
The following terms are used:
Table 8-10 Coincident multiband handover
Terms Definition
Coincident A cell that has a collocated neighbor cell whose cell boundary follows that
cell of the said cell, but has a different frequency type (but same BSIC) to that
of the neighbor cell.
Primary cell A cell which is already optimized in the network and had a collocated
neighbor 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.
Secondary A cell which is not optimized and has a collocated neighbor whose cell
cell boundary follows the boundary of the specified cell. The secondary cell has
a preferred band, the same as that of its own frequency type.
8-80 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Coincident multiband handover
Figure 8-28 illustrates the relationship of coincident and neighbor cells.
Figure 8-28 Relationship of coincident and neighbor cells
C B D
Cells B, C and D are cells which are optimized (power budget handovers can occur). Cells B
and D are neighbors of each other as are cells B and C. Cells B, C and D belong to the same
frequency band. To increase capacity with minimal configuration, cell A is added to cover the
same area as cell B. Cell A is now the secondary cell and cell B is the primary cell and both are
coincident to each other. Cell A need not be added to the neighbor list of cells C, D, or other cells
in the area. Cell A is only added to the neighbor list of cell B and the rest of the neighboring
cells are added to the neighbor list of cell A, including the primary cell, cell B.
Feature objectives
This feature has three main objectives:

To allow an operator to configure a cell as a secondary cell which only acquires traffic from
its coincident primary cell or neighboring secondary cells.
To maintain the quality in the primary cell frequency band and require only handover
parameters to be configured for one frequency band.
To simplify roll out of sites with multiband capabilities by allowing the operator to
configure certain frequency band cells to have the same cell boundaries as a cell using a
different frequency band.
Feature benefits
The motivation for and the benefits provided by, implementing this feature are as follows:
Simplify rollout of a multiband network by using existing GSM cell boundaries.
Introduce virtually plug and play simplicity for upgrading a network to a multiband
network.
Reduce maintenance costs for a multiband network. By configuring one network, both
networks will be optimized.
Provides an entry route for the operator into multiband networks.
68P02901W36-S 8-81
Jul 2008
Assumption made
When using a coincident network, the following assumption is made:
The secondary cell has all the same neighbors as the primary cell, as well as the collocated
primary cell as a neighbor. In addition to the primary cells, the secondary cell can have other
secondary cells specified as neighbors.
Defined neighbor relations
Figure 8-29 shows the neighbor relationships (solid lines) defined for each cell, as well as the
coincident cell relationships (dashed lines).
For example, assume that a mobile was using a traffic channel on cell A. The mobile would
be measuring the strength of cell B and cell D (because they are defined in the neighbor
database). When cell A receives the measurement report from the mobile, 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. This is done because the propagation characteristics
of the two cells can vary.
If cell C was also a neighbor of cell A, the downlink receive level of cell A is used in the serving
cell power budget calculation. While comparing against the coincident neighbor cell B for power
budget handover condition, the downlink receive level of cell A is used.
Figure 8-29 Defined neighbor relations
A C
B D
NOTE
Normal multiband handovers to a preferred band will not be affected by the

coincident multiband feature.
Cell B must be a neighbor of cell A and cell A must be a neighbor of cell B.
Measurement reports for a handover (coincident_mb = 1)
Figure 8-30 shows normal coincident cell functionality, specifically, the measurement reports
used to make a handover. In this case, the mobile is again occupying a traffic channel on cell
A and the cells have the same neighbor and coincident relationships as those in Figure 8-29.
8-82 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Coincident multiband handover
The BSS uses the signal strength reports of cell B from the mobile to make a decision as to
whether a handover is needed. The BSS uses the signal strength reports of cell D from the
mobile to determine whether there are any throughable candidates for the needed handover.
Figure 8-30 Measurement reports used to make a handover
Handing over to an unreported neighbor (coincident_mb = 2)
Figure 8-31 shows the enhanced functionality of handing over to an unreported neighbor. If
the BSS decides that cell D is a throughable candidate for handover for a mobile occupying a
traffic channel on cell A, the BSS will detect that cell C is a coincident cell of cell D and will
redirect the handovers to cell C.
Figure 8-31 Handing over to an unreported neighbor
In order for a coincident cell redirection handover (coincident_mb set to 2) to take place
successfully, the following conditions must apply:
Cells C and D must be synchronized in order to perform a handover to an unreported
neighbor cell C.
Cells C and D must be located at the same site.
Cells C and D must use the same BSIC (to communicate successfully on the MTL upon
handover).
Cells C and D must be neighbors of each other.
68P02901W36-S 8-83
Jul 2008
Measurement reports for a handover (coincident_mb = 3)
Intra BSC handovers behave the same as when coincident_mb=2, but for inter BSC handovers
the call is targeted at the primary cell as shown in Figure 8-32.
Figure 8-32 Inter BSC handover
A C
B D
Examples of use
The following are examples of possible uses of this feature and the system responses to illegal
configuration attempts.
To enable coincident multiband handovers at a cell, using better cell detection and entering a
cell which is a SACCH neighbor of the cell at which the parameter is being changed, enter the
following:
MMI-RAM 0114-> chg_cell_element coincident_mb 1 1 cell 0 0 1 0 1 1 7

Enter the coincident cell: 0 0 1 0 1 1 6
Attempting to enable coincident multiband handovers at a cell, using bet-

ter cell detection and entering a cell which is not in the neighbor list of
the cell at which the parameter is being changed, results in the following:
MMI-RAM 0114-> chg_cell_element coincident_mb 1 1 cell 0 0 1 0 1 1 7Enter the
coincident cell: 0 0 1 0 1 1 5COMMAND REJECTED: The specified coincident cell
must be a sacch neighbor of the source cell.
Attempting to enable coincident multiband handovers at a cell, using better cell detection
and pressing RETURN when prompted for the coincident cell, results in the following:
coincident cell: <RETURN>COMMAND REJECTED: A coincident cell must be specified
before coincident_mb can be changed. The specified coincident cell must be a
sacch neighbor of the source cell
Attempting to enable coincident multiband handovers at a cell, using coincident cell

redirection and entering a cell at a different site to the coincident cell, results in the following:
coincident cell: 0 0 1 0 1 1 8COMMAND REJECTED: Source and Coincident Cell must
exist at the same site for coincident_mb=2.
8-84 68P02901W36-S
Jul 2008
Attempting to enable coincident multiband handovers at a cell, using coincident cell redirection
and entering a cell which is at the same site, but on a different BSIC, results in the following:
MMI-RAM 0114-> chg_cell_element coincident_mb 2 cell 0 0 1 0 1 1 8

Enter the coincident cell: 0 0 1 0 1 1 9
COMMAND REJECTED: Source and Coincident Cell must have same BSIC for coincident_mb=2.
To display the current setting for coincident_mb, enter the following:
MMI-RAM 0114-> disp_element coincident_mb 1 cell 0 0 1 0 1 1 7

coincident_mb: 1
To display the current setting for coincident_cell, enter the following:
MMI-RAM 0114-> disp_element coincident_cell 1 cell 0 0 1 0 1 1 7

coincident_cell: 0 0 1 0 1 1 6
The following database parameters have been added to support the functionality of this feature:
coincident_mb - Used to enable or disable the ability for a BTS to execute coincident multiband
handover algorithms.
coincident_cell - Used to specify the cell which is coincident to the specified cell.
coincident_offset - Used to specify the value added to the ho_margin when handover is
based on receive level from the serving cell.
low_sig_thresh - Used to specify the value of receive level that must be exceeded by a
coincident cell to cause a handover to that cell.
These parameters are set to default values, can be changed using the chg_cell_element or
chg_element commands and viewed using the disp_element command.
System impact
An MS can be handled as if it were on the primary frequency band, while not taking any primary
frequency band resources.
Related features
This feature is designed to complement the Multiband Inter-cell Handover feature.

Coincident multiband handover is available only if the multiband feature is enabled.
68P02901W36-S 8-85
Jul 2008
Advanced load management for EGSM carriers Chapter 8: Power and Handover Control
Advanced load management for EGSM carriers

EGSM to EGSM handovers
The advanced load handover management for EGSM carriers function set offers the operator
the ability to specify EGSM band handovers only to other EGSM bands. Otherwise EGSM
handovers can occur to neighboring cells that do not have an EGSM band available. DCS
1800 bands can be used wastefully, particularly if the band_preference parameter is set, for
example, to DCS 1800. A new parameter bss_egsm_alm_allowed enables the EGSM handovers
to only occur at EGSM sites, whatever be the setting of band_preference.
When a handover is triggered with this function set, the neighbor list of an EGSM MS on an
EGSM resource is manipulated such that EGSM internal neighbor cells are given preference
over non-EGSM neighbor cells.
Example
Figure 8-33 shows two handovers with band_preference set to 4 (DCS 1800) and
bss_egsm_alm_allowed set to 1 (enabled). When an EGSM capable MS establishes a call on an
EGSM Traffic Channel (TCH) in cell B and a handover is triggered, the list of candidate cells is
manipulated such that any PGSM cell with EGSM capability becomes the preferred band, to
which the call is then directed (cell D).
When a second handover is triggered, the BSS again targets the handover to an EGSM TCH in a
PGSM cell with EGSM capability. This is shown in Handover 2 in Figure 8-33.
Figure 8-33 Example EGSM handover
In multiband cells, the handover is directed to the secondary band within the cell by the zone
handover mechanism. If the call is on an EGSM band in the outer zone, this advanced load
management feature does not permit the zone handover and forces the call to stay on the
EGSM band.
8-86 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Related features
Related features
Multiband inter-cell handover.
Coincident multiband handover.
Directed retry.
Related parameters
bss_egsm_alm_allowed
band_preference
68P02901W36-S 8-87
Jul 2008
Intelligent Multi-Layer Resource Management (IMRM) Chapter 8: Power and Handover Control
Intelligent Multi-Layer Resource Management (IMRM)

Overview
IMRM allows users to better match overall traffic distribution to intrinsic network capacity and
MS penetration. By supporting, on a per cell basis, weightings for each of his available bands,
the system can effect a more dynamic distribution based on factors such as:
Local (cell) per band capacity.
Neighbor (For example, micro underlay, macro overlay) per band capacity.
Mobile Capability penetration for example Multiband versus Single Band.
Congestion Management that is half-rate management.
Other System Considerations (For example, GPRS capacity).
The Layer Weightings supported are:

PGSM.
EGSM.
DCS 1800.
UMTS.
The individual layer weightings are dynamically combined with a requesting MS capabilities
to define a set of probabilities for each of the supported layers; a random selection based on
these probabilities then effects the traffic distribution. The higher the layer weighting the
higher the probability and hence more likely selection. Setting any Layer Weighting to the
maximum defined value results in a fixed (to that layer) preference selection as per existing
ALM procedures.
The default for all available layers is set to Unsupported. Where IMRM is enabled in a cell with
all layers set to Unsupported, the system applies a set of fixed internal defaults for input into
the Preference Selection Algorithm. The system supports 2 sets of defaults with selection
based on local EGSM availability:
Table 8-11 Default Band Weightings
EGSM
PGSM EGSM DCS 1800 PCS 850 PCS 1900 GSM 450 UMTS
Support
YES 45 10 45 N/A N/A N/A 0
NO 50 0 50 N/A N/A N/A 0
8-88 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Feature interactions
The Preference Selection Algorithm is run for each initial network resource request
(Assignment and incoming External Handover) and is used in conjunction with the existing
band_preference_mode parameter to determine both initial resource targeting and also any
subsequent handover activity. The selected preference is then retained or utilized for the call
whilst it remains within the current BSS. There are situations whereby the Preference Selection
Algorithm can be rerun for existing calls, either due to system operation and/or operator control
as follows:
Intra-BSS hand-in from non-IMRM Source to IMRM Target.
Intra-BSS hand-in from IMRM Source with a locally unsupported Preference.
Intra-BSS hand-in to an IMRM Target with (configured) Forced Recalculation of Preference.
New statistics have been introduced to allow tracking of cell availability and utilization on a
per layer basis.
Multiband Handover
Multiband Handover support is a prerequisite for IMRM.
Basic operation is to re-allocate a current call (on a non-preferred band resource example TCH or
SDCCH) to a neighbor preferred band resource either on initial resource assignment (whilst on
SDCCH), at handover (from a TCH for normal radio reasons), or to continually attempt to identify
qualifying neighbors (whilst on a TCH) for handover. The band_preference_mode setting in
conjunction with band_preference controls system behavior. In IMRM cells band_preference is
replaced with a Per Call Preferred Band setting which is applied in the same manner.
The introduction of IMRM allows users to simplify and better control traffic distribution and as
such overrides existing procedures. Hence a band_preference_mode setting of 6, designed to
limit multiband activity based on utilization, is overridden and handled as for a setting of 5.
For those networks supporting EGSM, IMRM can be configured to support the independent
management of EGSM Zone resources for the EGSM and PGSM bands that is multiband
handover is applicable to Per Call Preferred Band settings of both EGSM and PGSM.
EGSM
As shown for Multiband Handover, IMRM allows the differentiation of the EGSM and PGSM
bands within an EGSM Zone. Similarly, for inter-cell (intra-BSS) handovers with Per Call
Preferred Band settings of EGSM or PGSM, the system gives priority to handover to and
allocation of, preferred band resources.
The current Advanced Load Management for EGSM Carriers do not apply for IMRM supporting
cells-as above explicit targeting of EGSM resources is governed by a Per Call Preferred Band
setting of EGSM.
IMRM Source cells consider EGSM neighbors as PGSM capable for handover management.
68P02901W36-S 8-89
Jul 2008
Feature interactions Chapter 8: Power and Handover Control
Coincident Multiband
Coincident neighbors are targeted where they are preferred that is appropriate setting of the
Per Call Preferred Band, as current.
Single BCCH
Targeting of the Inner Zone is governed by preferred band. For IMRM the Per Call Preferred
Band can be any band within any zone. The Per Call Preferred Band is combined with
band_preference_mode (as current) to dictate initial resource allocation.
For Outer Zone allocation (band_preference_mode settings of 0, 2, 4) with a Per Call Preferred
Band of Inner Zone, any outer zone resource can be targeted. With a Per Call Preferred Band
supported on the Outer Zone then priority is given to allocating a resource from that band.
For Preferred Band allocation (band_preference_mode settings of 1, 3, 5, 6) priority is given

to allocating a local Per Call Preferred Band resource, with failure resulting in multiband
handover as current. Where no neighbor preferred band resources have been identified, a
non-preferred Outer Zone resource is targeted. For a Per Call Preferred Band set to an Outer
Zone band, priority is given to allocating a resource from that band and on failure a multiband
handover to a preferred band neighbor is attempted. A non-preferred Outer Zone resource is
targeted as a last resort.
Gating of access to preferred resources that is mb_tch_congest_thres for

band_preference_mode of 6 and the outer_zone_usage_level threshold, do not apply in
IMRM cells.
2G/3G
IMRM can be used to target a 3G layer for handover. This is used in conjunction with and
dependent on, the 2G/3G Handover Feature. The Per Call Preferred Band is combined with
the (possible) SERVICE HANDOVER IE (as optionally provided by the MSC at Assignment or
Handover) and the UMTS_BAND_PREFERRED flag to determine 2G and 3G preference at
handover time as follows:
SERVICE HANDOVER IE included and indicates that 2G should or will be used.
Per Call Preferred Band of UMTS not possible. Preference to 2G Layer.
SERVICE HANDOVER IE included and indicates 3G preference.
Per Call Preferred Band of UMTS possible, if set to 2G band then 2G neighbors ordered by
preferred band, 3G neighbors prioritized.
SERVICE HANDOVER IE not included in MSC request.
UMTS_BAND_PREFERRED set to 3G. Per Call Preferred Band of UMTS possible, if set to
2G band then 2G neighbors ordered by preferred band, 3G neighbors prioritized.
UMTS_BAND_PREFERRED set to 2G.
Per Call Preferred Band of UMTS possible, if set to 3G then 3G neighbors prioritized. If set
to 2G then 2G neighbors prioritized and ordered by preferred band.
At initial assignment for a Per Call Preferred Band of UMTS, an outer zone resource is targeted.
8-90 68P02901W36-S
Jul 2008
Refer to 68P02901W23 Technical Description: BSS Command Reference manual for further
information.
Commands
disp_options This command displays restricted and unrestricted features for the
BSS.
copy_cell This command copies a cell within the BSS.
chg_element This command modifies an attribute within the BSS.
chg_cell_element This command modifies an attribute within the BSS.
disp_element This command displays the attribute of a cell at a BSS.
disp_cell This command displays the attributes associated with a Cell within
the BSS.
Parameters
imrm_pgsm_weight This parameter sets the weighting for the PGSM frequency
band.
imrm_egsm_weight This parameter sets the weighting for the EGSM frequency
band.
imrm_DCS 1800_weight This parameter sets the weighting for the DCS 1800
frequency band.
imrm_umts_weight This parameter sets the weighting for the UMTS frequency
band.
imrm_force_recalc When this flag is enabled, a recalculation on the preferred
band to handover to is executed on the specified cell.
band_preference This element determines the destination frequency band for
handover that a cell prefers.
68P02901W36-S 8-91
Jul 2008
Flexible neighbor cell processing Chapter 8: Power and Handover Control
Flexible neighbor cell processing

Functions
Flexible neighbor cell processing enhances the existing handover decision process by adding
more flexibility in the way neighbor cell processing is carried out for handovers.
Four different functional blocks are covered by this enhancement:

Allow neighbors with lower RxLev than the serving cell as valid candidates for handover.
Include neighbor cells whose disuse count is less than or equal to the maximum disuse
count. Disuse count is defined as the number of consecutive measurement reports for
which a previously reported neighbor is not reported by the MS.
Uses RxQual or RxLev handovers only when the BTS or MS is at full power. Removes all
candidates for interference handovers until BTS or MS reach full power. Applicable only
for decision algorithm 1.
Allows no warm-up period for neighbors. Averaging and power budget calculations will
begin immediately. Uses an RxLev of 0 if missing a measurement report.
The functionality of this feature is implemented by adding four new database parameters. This
functionality is described in the following sections.
NOTE
The OMC-R offers the ability to traverse automatically the neighbor statistics in
rotation on a per cell basis.
Allow downlink RxLevel handovers to worse neighbors
This option is controlled by the worse_neighbour_ho database parameter. Setting the value
of this parameter to 1 enables the option, setting it to 0 disables the option. If the option is
enabled, neighbors with a lower RxLev than the current serving cell RxLev are considered as
valid candidates for a downlink RxLevel handover.
Allow disuse count > 0
The disuse count is defined as the number of consecutive measurement reports for which a
previously reported neighbor is not reported by the MS. If the neighbor is reported before the
maximum disuse count is reached, the disuse count is reset to 0.
This option is controlled by the disuse_cnt_hreqave database parameter. Setting the value
of this parameter to 1 enables the option, setting it to 0 disables the option. If the option is
enabled, the maximum disuse count is defined by the surrounding cell hreqave, neighbors with
a disuse count less than or equal to the maximum disuse count are still considered as valid
candidates for a handover.
8-92 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Functions
Allow full power for RxLev or RxQual handovers
This option is controlled by the ho_only_max_pwr database parameter. Setting the value of this
parameter to 1 enables the option, setting it to 0 disables the option. If the option is enabled,
either of the following must be true:
For an uplink handover, the mobile must be at full power.
For a downlink handover, the BTS must be at maximum power.
This option also removes all candidates for interference handovers until either of the above
are true.
NOTE
This option requires the use of decision algorithm 1 to allow the BTS or the mobile to
reach full power for quality cases.
Allow neighbor journal
This option is controlled by the neighbour_journal database parameter. Setting the value of
this parameter to 1 enables the option, setting it to 0 disables the option.
If the option is enabled, the following are true:

There is no warm-up period for neighbors, all neighbor information is padded with zeros
(0), averaging and power budget calculations begin immediately.
If a previously reported neighbor is missing in the measurement report, a value of 0 is

used for its RxLev.
Stored neighbor information is removed when the maximum disuse count is reached. The
maximum disuse count is defined by the surrounding cell hreqave.
If the option is not enabled, the following are true:

There will be a warm-up period for the surround cell hreqave before power budget
calculations begin.
The last received RxLev for the unreported neighbor is used.
The maximum disuse count is set to 0 before the neighbors are removed.
68P02901W36-S 8-93
Jul 2008
The following database parameters have been added for use with the chg_cell_element or
chg_element (per cell), to support the functionality of this feature:
disuse_cnt_hreqave - Used to enable or disable the flexible neighbor cell feature to include
neighbor cells whose disuse count is less than or equal to the maximum disuse count.
ho_only_max_pwr - Used to enable or disable the flexible neighbor cell feature to use
RxQual or RxLev handovers only when the BTS or MS is at full power.
neighbour_journal - Used to enable or disable the flexible neighbor cell feature to allow
no warm-up period for neighbors.
worse_neighbour_ho - Used to enable or disable the flexible neighbor cell feature to

allow neighbors with lower RxLev than the serving cell as valid candidates for a downlink
RxLevel handover.
The values of these parameters are viewed using the disp_element command.
Related features
8-94 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Microcellular handovers
Microcellular handovers

Microcellular handover function
Microcellular handovers enable the optimal handover of an MS between microcells or between

microcells and macrocells and manage the traffic capacity in a microcellular network.
Motorola implements seven algorithm types, which are appropriate for various situations. The
algorithm type to be used is specified on a per neighbor basis.
Handover candidates
A key component of the algorithms is their treatment of handover candidate ordering. Each
neighbor cell is classified as a type N neighbor (N = 1 to 7), where N is the number of the
algorithm that is selected for that neighbor. An example is shown in Figure 8-34. The candidate
ordering is described later.
Figure 8-34 Microcellular handover to neighbor (numbered) cells

A f j f
68P02901W36-S 8-95
Jul 2008
Micro-macro handover algorithms Chapter 8: Power and Handover Control
Micro-macro handover algorithms
Figure 8-35 illustrates which algorithms are used for types of micro-macro handover.
Figure 8-35 Micro-macro handover types of algorithm
NOTE
* Numbers indicate suggested choice of algorithm. Other algorithms can prove just
as useful if optimized correctly.
There are two types of handover: where a PBGT or a non-PBGT handover is generated.
8-96 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Micro-macro handover algorithms
Type 1 algorithm
Algorithm 1 is the standard GSM power budget algorithm described in Handover decision
algorithm for non-microcellular, except that the averaging period hreqave can be set on a
per neighbor basis. Handover decision procedure later in this section describes handover
process.
Since this is an extension of the existing algorithm to a per neighbor basis, it is still mainly used
in its traditional role for macro to macro cell handovers.
Typical uses:
Serving cell is a macrocell.
Preferred handover mechanism for macro to macro handovers.
NOTE
If using algorithm 1 with multiband handover, Advanced Load Management
(ALM) features take precedence over the M-Cell/Horizon algorithm.
Type 2 algorithm
If an imperative handover is caused (which usually means that the quality is degraded) then
handovers to type 2 cells will be preferred.
Typical uses:
Serving cell is a microcell; macrocell would be made a type 2 neighbor to eliminate power
budget handovers between layers.
If it is imperative that a handover takes place (RXLEV/RXQUAL), algorithm 2 neighbor gets

priority, that is, go to macrocell in case of imperative handover.
Additionally, if algorithm 3 (round the corner neighbor) generates a handover cause and
the handover fails then algorithm 2 neighbor (macrocell) is next in the candidate list.
Type 3 algorithm
A handover request to a type 3 neighbor is only triggered if the power budget, PBGT exceeds
the handover margin, HO_MARGIN and the received signal level, RXLEV from the serving cell
is below a threshold. Both uplink and downlink serving signal strength must be below the
threshold in order for the handover to be requested. 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 45 MHz frequency separation.
Handover occurs when:

PBGT(n) > HO_MARGIN
RXLEV(s) < THRESHOLD (for UL and DL)
68P02901W36-S 8-97
Jul 2008
The above conditions can be summarized in the following formula:
[ul rxlev (averaged) + ul rxlev adj < ul rxlev serv l]

AN D [dl rxlev (averaged) + dl rxlev adj < dl rxlev serv l]

AN D pbgt(n) > ho margin
Where: Is:
ul rxlev (averaged) the averaged RxLev calculated by the BTS based on the
UL RxLev received in the last hreqave number of MRs.
dl rxlev (averaged) the averaged RxLev calculated by the BTS based on the
DL RxLev received by the MS and reported to the BTS in
the last hreqave number of MRs.
ul_rxlev_adj an adjustment that takes into account the difference
between the max_tx_ms and the actual MS power as
reported in the last Measurement Report.
dl_rxlev_adj an adjustment that takes into account the difference
between the max_tx_bts and the actual BTS power as
reported in the last Measurement Report.
ul_rxlev_srev_l the UL RxLev threshold as set in the add_neighbor
command.
dl_rxlev_srev_l the DL RxLev threshold as set in the add_neighbor
command.
ul_rxlev_adj and dl_rxlev_adj are calculated as follows:
ul_rxlev_adj= max_tx_ms (in dBm) actual MS power (in dBm)
dl_rxlev_adj= max_tx_bts (in dBm) actual BTS power (in dBm)
The type 3 algorithm is when a handover is required due to a drop in service RXLEV. Some
examples are:
Serving cell is a microcell, microcell neighbor which is round the corner is type 3.
RXLEV threshold ensures corner has been turned before handover (up to 20 dB drop).
Candidate ordering ensured type 2 macrocell is a secondary candidate.
Serving cell is a microcell, neighbor cell is an in-building microcell.
8-98 68P02901W36-S
Jul 2008
Type 4 algorithm
This is a delayed handover. A timer is started when an MS hands into the micro server cell. The
handover request is generated if PBGT exceeds HO_MARGIN after the timer has expired.
This delay mechanism discourages handover into transient microcells which are potential
candidates only for a short period of time and can be used to force a fast moving MS to enter an
interference zone before handing over to the neighbor microcell. This causes a hand up to the
macrocell, where the MS is encouraged to stay.
Additionally, the algorithm is to label a cell as a microcell for later use in the candidate ordering
algorithm. In this case the timer has to be set to zero.

Timer has expired and PBGT(n) > HO_MARGIN.
Typical uses:
Serving cell is a microcell, target cell is a microcell with direct path to neighbor, levels
from both cells are high so rxlev threshold would be ineffective to start timer.
With timer set to zero, algorithms can be used simply to label a cell as a micro neighbor.
Timer limits spurious handovers, forcing imperative handups for fast MS subscribers.
Type 5 algorithm
This is also a delayed handover. A timer is started when the latest rolling average from
the neighbor in question exceed a certain threshold. The timer is reset when the neighbor
signal strength falls below this threshold. A handover request is generated if PBGT exceeds
HO_MARGIN after the timer has expired.
If the latest rolling average drops below the threshold, the timer stops.

Timer expired and PBGT(n) > HO_MARGIN.
NOTE
HO_MARGIN could be a negative value.
Typical uses:
Serving cell is a macrocell, target cell is a type 5 microcell.
Timer prevents fast moving MSs from handing down.
Combination of a timer with a short averaging period provides better performance than a
long averaging period, as up to date data is used in the handover decision.
Disabling PBGT(n) is useful when close to macro BTS, since macro strength versus micro
strength can be high.
Serving cell is a microcell and there is a type 5 microcell neighbor with a direct path.
68P02901W36-S 8-99
Jul 2008
Type 6 algorithm
A timer is started when PBGT exceeds HO_MARGIN. An offset is added to HO_MARGIN to

further discourage handovers. If PBGT exceeds the offset HO_MARGIN whilst the timer is
running, a handover request is generated. After the timer has expired, a dynamic offset is
subtracted from the static offset making a power budget handover easier to a neighbor.

During Timer Period
PBGT(n) > HO_MARGIN + STATIC OFFSET.
After Timer Period
PBGT(n) > HO_MARGIN + STATIC OFFSET-DYNAMIC OFFSET.
Typical uses:
Serving cell is a macrocell, target cell is a type 6 microcell.
Timer prevents fast moving MSs from handing down to microcell.
Serving cell is a micro, there is a type 6 micro with a direct path.
Type 7 algorithm
A type 7 algorithm has been defined to facilitate early detection of adjacent channel interference
problem. In a microcellular environment, an operator will typically define a neighbor to be of
type 7 if both the source cell and the neighbor are single carrier cells with BCCH on adjacent
channels. Figure 8-36 shows an example of a type 7 algorithm.
If an MS is moving from a serving cell to a neighbor which has an adjacent channel BCCH
frequency the quality of the call will keep on dropping due to increasing level of adjacent
channel interference. Assuming that both serving cell and the interfering neighbor are single
carrier cells then neither an intra-cell nor an inter-cell handover to the interfering neighbor will
help. The handover should be performed to a third neighbor which is not on an adjacent channel.
8-100 68P02901W36-S
Jul 2008
Figure 8-36 Type 7 algorithm example
ti-GS M-Type 7a lgorithm-00295-a i-sw
The type 7 algorithm uses a new parameter pbgt_adj_chan_ho_margin to detect a handover

condition due to adjacent channel interference. This parameter is typically set to a negative
value which causes the power budget handover to be generated before the signal strength
of the interfering neighbor becomes too strong to drop the call. Therefore, for handover
detection purposes, the HDPC process uses the parameter pbgt_adj_chan_ho_margin for a
type 7 neighbor to satisfy power budget equation. Once the power budget handover condition
has been detected, the HDPC process recomputes the value of power budget using the value
of per neighbor handover margin.
68P02901W36-S 8-101
Jul 2008
Handover decision procedure Chapter 8: Power and Handover Control
Figure 8-37 Microcell algorithm type 7
Calls can also be dropped when a cell hands over to a neighbor which in turn has a neighbor
with adjacent (BCCH) channel frequency.
Handover decision procedure
Using the microcell implementation, each neighbor is assigned a power budget algorithm to be
used for that neighbor. Upon receipt of each measurement report, the BSS uses the assigned
algorithm for each neighbor reported by the MS to determine if the MS qualifies for a power
budget handover to that neighbor. The BSS then evaluates the number of neighbors which
qualify for a power budget handover. These neighbors are then prioritized in a candidate list.
This list is created based on the cause of the handover and the evaluation of the two equations
defined in 3GPP Technical Specification GSM 05.08. Typically in macrocell only networks, the
candidates with the greatest power budget value are listed first, but with the addition of the
microcellular support feature, the order of the candidates in the list can be altered prior to
generating the request for a handover.
8-102 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Setting the candidate list
Handover candidates are ordered to achieve the objective of biasing towards microcells while
limiting dropped calls. RXLEV handovers prefer macrocell (algorithm 2), but include microcell
neighbor as secondary even if not qualified. For example, around-corner handovers (algorithm
3) prefer around-corner cell, but include macrocell (algorithm 2) neighbors as secondary
candidates. The basic idea is to have several segments to the candidate list for different groups
of neighbor classes each individually ranked by PBGT.
Microcellular handover detection and power control process
The parameter use_neighbour_pbgt_hreqave must be set cell by cell to determine HREQAVE

on a per neighbor basis for microcellular.
NOTE
If the microcell feature is not purchased, all neighbors have pbgt_alg_type equal to 1
(standard GSM PBGT).
Modification of candidate list
Motorola has developed a method of listing potential handover candidates in order to address
some of the requirements of micro/micro and macro/micro handovers.
Handover candidates are ordered to achieve the objective of biasing towards microcells while
limiting dropped calls.
When the process determines that a handover is required, a list of qualified candidate cells is
generated, based on the cause of the handover and the evaluation of the two equations defined
in 3GPP Technical Specification GSM 05.08.
With the addition of the microcell feature, the order of the candidates in the list is altered
prior to generating the request for a handover based on the neighbor type so that there are
several segments to the candidate list for different groups of neighbor classes, each individually
ranked by PBGT.
Setting the candidate list
The BSS manipulates the list of candidate cells in the following way:
Removes any neighbor that fails the Interference Avoidance Test.
Removes any neighbor which does not satisfy additional requirements of its algorithm (this
does not apply for type 1 and 2).
Depending on how the handover is triggered, preference is then given to neighbors

as shown in Table 8-12.
68P02901W36-S 8-103
Jul 2008
Table 8-12 Handover trigger and preference
Handover
Preference
trigger
Type 2 Given to type 3 neighbors. Candidate list is built in the following order:
neighbor
All algorithm 3 neighbors which qualify, ranked by power budget.
All algorithm 1 and 2 which qualify, ranked by power budget.
Any algorithm 4, 5 and 6 which qualify, ranked by power budget.

The intention is to prefer type 3 neighbors, use type 2 neighbors as default
candidates in case of blocking and use the other types which generated the
handover causes as a last resort.
Type 4, Given to qualified microcell neighbors. Candidate list is built in the following
5 and 6 order:
neighbor
Remove algorithm 2 neighbors from the list.
All algorithm 4, 5 and 6 neighbors (in that order) which qualify, ranked by
power budget.
Any algorithm 1 neighbors which qualify, ranked by power budget.

This gives handover preference to any qualified microcell neighbors and uses
algorithm 1 candidates as default in the case of there being no qualified
microcell neighbors.
Imperative Preference given to macrocells. Candidate list is built in the following order:
handovers
(cause other Remove any algorithm 7 neighbor which fails the test:
than power
budget) or Power budget-pbgt_adj_chan_ho_margin >= 0.
Adjacent
channel
All algorithm 1 and 2 neighbors (in that order) which qualify, ranked by
interface
power budget.
Any other neighbors which qualify for power budget handovers, ranked
by power budget.
This gives handover preference to macrocell neighbors, in the case of
imperative/adjacent channel interference handovers but uses all other
neighbor types as default candidates, ranked by power budget, if no macrocell
is available.
Refer to Technical Descriptions: BSS Command Reference (68P02901W23) manual for a full
8-104 68P02901W36-S
Jul 2008
Parameters:
The use_neighbour_pbgt_hreqave parameter can be used with the chg_element or

chg_cell_element commands to indicate whether the per cell or per neighbor HREQAVE will
be used for the PBGT > HO_MARGIN trigger assignment.
System impact
When this feature is purchased and enabled, the add_neighbour command and neighbor
processing are modified.
The main O and M impact of the feature is the addition of another choice of microcellular
algorithm, in addition to the existing six algorithms already available. These algorithms are
all defined on a per neighbor basis.
Additional neighbor parameters have been provided to support this new algorithm at
the BSS and at the OMC-R GUI.
The Neighbor Detailed View and the Neighbor/Source View have also been updated to
support these parameters.
The BSS software fully supports the additional microcellular functionality.
A modified raw statistic, OUT_HO_NC_CAUSE_ATMPT, counts the handovers with a cause

of adjacent channel interference (ADJ_CHAN_INTF).
68P02901W36-S 8-105
Jul 2008
SDCCH handovers Chapter 8: Power and Handover Control
SDCCH handovers

Purpose of SDCCH handovers
An MS is allocated an SDCCH to carry out the call setup procedures, including authentication,
validation of equipment and subscriber, encryption setting and allocation of a TCH if required.
An SDCCH is also used for SMS delivery and location updating.
Description of SDCCH handover
It is possible that an MS using an SDCCH slot has to perform an inter-cell or intra-cell handover.
This need is calculated by the HDPC algorithms using uplink and downlink measurement reports
in the normal way. SDCCH handovers are permitted by the setting of the sdcch_ho flag.
This handover only occurs if the MS has occupied the SDCCH for at least the period set in
sdcch_timer_ho.
Carrier prioritization for SDCCH
One important item to note is that the interference band allocated to a channel is still the first
criterion in the channel allocation algorithms. A channel from the highest priority carrier
matching the requested interference band is allocated to a channel request. Moreover, the
channel allocation priority is also a secondary criterion after the existing criteria of channel
selection in a multiband, concentric cell and extended range cell environment. Also, the channel
allocation priority can not be followed for an emergency call if a channel is allocated from the
emergency reserved channel pool.
For interference-based intra-cell handovers, the channel selection algorithm for a non-hopping
cell has been modified to consider the channel allocation priority as follows:
Compile a list A with any channels in the best interference band.
From list A, select any channels on a carrier other than the current carrier and compile a
list B. If none are available, select the best channel from list A.
From list B, select a channel with the best available channel allocation priority.
NOTE
The preference of BCCH over non-BCCH is replaced by the channel allocation priority.
SDCCH to TCH assignment for multiband MSs
Increases the success rate of assignment to a preferred band cell, that is, going from an SDCCH
in a non-preferred band cell directly to a TCH in a preferred band cell.
8-106 68P02901W36-S
Jul 2008
Multiband handover allows the operator to select the band preference mode. When the
sdcch_tch_band_reassign_delay parameter is set to 0, 1, 2, 3 or 4 (default 0), using the
chg_element or chg_cell_element command, the software makes an attempt to move calls to
a neighbor cell of the preferred band at the time of SDCCH to TCH assignment.
At the time of TCH assignment, the CP process queries RSS for qualified neighbor cells of the
preferred frequency band. If the MS has not reported a qualified signal strength for a preferred
band neighbor cell, the MS is assigned a TCH from the serving cell. In practice, it has often
been found that the MS does not report on neighbor cells from other frequency bands fast
enough to allow the TCH assignment to the preferred band neighbor cell.
The sdcch_tch_band_reassign_delay set is used only for multiband MSs. It does not affect the
call setup time for non-multiband MSs. Use of this parameter causes a delay in call setup of up
to two seconds. This parameter is supported across the BSS-OMC interface.
Refer to Technical BSS Command Reference (68P02901W23) manual for a full description of
commands and parameters.
Modified parameters
The following parameters are used with the modify_value command for SDCCH prioritization:
chan_alloc_priority - Identifies the priority of a carrier when utilizing the radio channel
(SDCCH/TCH) allocation algorithm. Carriers with low values of chan_alloc_priority are selected
first for channel allocation.
sd_load - Specifies the number of carrier timeslots that can be configured to carry SDCCHs.
sd_priority - Identifies the priority of this carrier for SDCCH placement. Carriers with low
values of sd_priority are selected first when SDCCHs are placed.
Change parameter
The sdcch_tch_band_reassign_delay is sent with the chg_element or chg_cell_element

command to cause a call delay.
System impact
When handovers are enabled on the SDCCH, handovers are notallowed until at least
(sdcch_timer_ho * 2) measurement report periods have elapsed.
External SDCCH handovers must be enabled by the MSC. Not all MSCs support this feature.
Set the handovers on the SDCCH with minimum delay by setting sdcch_ho to 1.
Use of the sdcch_tch_band_reassign_delay parameter can cause a delay in call setup of up

to two seconds.
68P02901W36-S 8-107
Jul 2008
Related features Chapter 8: Power and Handover Control
Related features
The following features share functionality, or are otherwise related to the SDCCH handover
feature:
Directed retry.
Congestion relief.
SDCCH queuing.
Call trace management through BSS.
8-108 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation MS handover power level based on path loss calculations
MS handover power level based on path loss

calculations

MS handover power level based on path loss calculations
On handover, the MS is commanded to a power level on the target cell based on the path loss
calculations for promoting battery conservation and interference reduction.
With this standard (unrestricted) feature, the BSS uses measurement information to derive the
power level to be included in the Handover Command for inter-cell, intra-BSS handovers if the
flag use_derived_ho_power is enabled within the database.
This functionality can only be provided for intra-BSS handovers because the target cell needs
the power level information to be included in the initial downlink SACCH. Therefore, the target
cell must have access to the handover power level that is included in the Handover Command.
3GPP Technical Specification GSM 08.08 does not provide a means to convey power information
to the target cell for an external handover. Therefore, with this in mind, the target cell is
unable to compute the power level for external handovers since it does not know the received
level strength reported by the MS.
Therefore the power level is calculated for intra-BSS handovers as follows:
HANDOVER POWER LEVEL (INTRA-BSS) = MIN (C + (A-B), D, P)
Where: Is:
A max_tx_bts of the target cell.
B RxLEV reported by the MS for the target cell.
C middle of the power box of the target cell:(u_rxlev_ul_p + l_rxlev_ul_p)/2.
D max_tx_ms of the target cell.
P maximum power capability of the MS.
This calculation aims at instructing the MS to access the cell at the middle of the power box.
For incoming external handovers, the BSS always instructs the MS to use the value of
handover_power_level as defined within the database of the target cell. Additionally, if
the flag use_derived_ho_power is disabled in the database, the BSS uses the value of
handover_power_level at the target cell for incoming intra-BSS handovers.
Path loss calculations
The calculation aims at instructing the MS to access the target cell at the middle of the database
defined power box ((u_rxlev_ul_p +l_rxlev_ul_p)/2).
68P02901W36-S 8-109
Jul 2008
Description of handover power calculation Chapter 8: Power and Handover Control
Description of handover power calculation
Enabling path loss calculation by use_derived_ho_power command
Previously the database defined parameter handover_power_level was used to instruct the
MS on inter-cell handovers.
The path loss calculation algorithm is used whenever the use_derived_ho_power command is
enabled per cell (enabled = value 1).
Whenever the use_derived_ho_power element is not enabled (feature disabled = value 0

(default)), the handover_power_level parameter is used instead.
Handover power level calculation based on path loss
NOTE
For incoming external handovers, the BSS instructs the MS to use the database
defined handover_power_level.
The handover power level is derived as follows:
Handover power level = MIN (C+((A-g)-B), D, P).
Where:
A = max_tx_bts of the target cell.
B = rxlev reported by the MS for the target cell.
C = middle of the target cell power box: (u_rxlev_ul_p + l_rxlev_ul_p)/2.
D = max_tx_ms of the target cell.
P = maximum power capability of the MS.
g = power adjustment to the actual radiated DL transmit power (internal path loss, for cabling
and levels of combining).
The desired handover power level cannot exceed either max_tx_ms (D) or the MS physical
capability to produce power (P). Thus, the lowest of the three terms is used.
8-110 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Example of handover power level path loss calculation
Example of handover power level path loss calculation
Figure 8-38 shows an example where the inter-cell handover orders the MS to access the target
cell with power level 7. The calculation is as follows:
Target cell:
rxlev_dl = 34
max_tx_bts = 6 (31 dBm)
max_tx_ms = 2 (39 dBm)
handover_power_level = 2 (39 dBm)
l_rxlev_ul_p = 30
u_rxlev_ul_p = 40
Power class 2 MS = 39 dBm
g (internal path loss) = 3 dB

Derived handover power level:
= MIN ((40 + 30)/2 + ((31-3)-34), 39, 39)
= MIN (29, 39, 39)
= 29 dBm (power level 7)
Figure 8-38 Example of handover power level path loss calculation
68P02901W36-S 8-111
Jul 2008
The parameter use_derived_ho_power can be used with the chg_element command to

influence MS handover power level based on path loss calculations.
It derives the power level to be included in the Handover Command for inter-cell intra-BSS
handovers.
8-112 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Congestion relief
Congestion relief

Congestion relief processes
Congestion relief processes are initiated when available resources in a cell exceed an operator
specified threshold. Separate criteria are defined to select active calls to be handed over in
order to relieve congestion in the cell. The congestion relief processes also need to take into
account the congestion status of the neighbor cells, before beginning processes to order MSs off
to other frequencies in these neighbor cells.
Advantages available from Motorola's enhanced congestion relief feature are:

Faster congestion relief (only uncongested targets are tried).
Reduced signaling (fewer handover attempts).
Less congestion and fewer congestion relief triggers (handovers that can lead to congestion
are not accepted).
Efficient congestion control in the preferred band of a multiband network.
The number of calls selected for handover due to congestion is dependent on an operator
specified database parameter. A selected call can have more than one possible target. For each
call to be handed over, internal target cells are tried one at a time. For external handovers the
number of target cells included in the handover required message sent to the MSC is dependent
on the number of cells in the candidate list and an operator specified database parameter.
The following assumptions are made:

The target cell does not accept a congestion relief handover if it would lead to the
invocation of congestion relief procedures.
The source cell does not attempt a congestion relief handover for a period of time to
a target cell which had rejected a previous handover attempt (both imperative and
congestion relief). The time period can be specified by the operator.
The target cell optionally invokes congestion relief after rejecting a handover request
(imperative and congestion relief).
The source cell optionally retries an imperative handover to target cells that rejected the
initial handover request and initiated a congestion relief procedure.
To prevent congested conditions being merely passed from one cell to another, the BSS does
not allow an incoming handover if the service of that handover causes the congestion relief
procedures to be triggered.
If a BSS target cell rejects an incoming inter-BTS handover due to the fact that the handover
would trigger congestion relief procedures, the target cell attempts to inform the source cell if
it performed congestion relief. If this target is configured to trigger its own congestion relief
procedures, it can be capable of handling necessary handovers.
68P02901W36-S 8-113
Jul 2008
The following database parameters are available to the operator to influence handovers due
to congestion:
rtry_cand_prd - sets the inter-BTS (intra-BSS) timer that is used to control the time
for which a cell is marked as congested and will not accept incoming non-imperative
handovers.
ext_rtry_cand_prd - sets the inter-BSS timer that is used to control the time for which a
cell is marked as congested and will not accept incoming non-imperative handovers.
NOTE
In an inter-BTS handover, with the inter_cell_handover_allowed parameter set
to 0 (MSC controlled) and the only eligible target being a congested internal cell,
the ext_rtry_cand_prd parameter is ignored by the BSC. This is due to the lack of
information that the MSC sends in the HANDOVER_REQUIRED_REJECT message.
congest_at_target - operator specified action for a target cell rejecting a handover due to
congestion.
congest_at_source - operator specified action for a source cell rejecting an imperative

handover. This occurs only for handovers which were originally rejected due to a target cell
being unable to currently serve the handover request, but which was in the process of invoking
congestion relief procedures itself.
mb_tch_congest_thres - controls the threshold at which multiband MSs start to be re-directed

to the preferred band (through the band_preference parameter set to 6, when this mode of
operation is invoked). This threshold is defined to be the percentage of overall TCH utilization
by any MS in a given cell. In an intra-BSS handover, the BSS does not allow a band preference
handover that would cause the percentage to be exceeded. For inter-BSS handovers this
threshold cannot be checked as there are no defined A interface causes to represent band
handovers.
8-114 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Half Rate congestion relief procedure interaction
Half Rate congestion relief procedure interaction
Based on how the congestion relief thresholds are configured in the BSS database, multiple
congestion thresholds are exceeded at the same time. Due to the qualification criteria, calls
which qualify for the existing congestion based inter-cell handover are mutually exclusive
with the calls which qualify for the congestion based, intra-cell handover from Full-Rate (FR)
to Half-Rate (HR). Therefore, both mechanisms can be triggered, at the same time, to provide
congestion relief by utilization of HR channels and also inter-cell handovers to neighboring cells.
There are currently two thresholds defined within a cell that control the triggering of congestion
based inter-cell handovers:
tch_congest_prevent_thres.
mb_tch_congest_thres.
When either of these thresholds are exceeded, the setting of the existing element
ho_exist_congest causes the BSS to:
Attempt to handover as many calls as the number of queued requests.
Attempt to handover as many calls as meet the congestion handover criteria.
If mb_tch_congest_thres, or tch_congest_prevent_thres and reconfig_fr_to_hr are

exceeded, the BSS triggers both inter-cell and intra-cell handover congestion-related
mechanisms together. When the mb_tch_congest_thres is exceeded, only MSs within the cell,
that report out of band neighbors, are considered candidates for inter-cell handover.
NOTE
Intra-cell handovers are triggered on all HR capable full-rate calls irrespective of
the MSs multiband capabilities.
The BSS combines the FR and HR resources within the outer zone to calculate if the
mb_tch_congest_thres is exceeded.
Triggering the congestion-related mechanisms causes inter and intra-cell handovers to be

triggered within the cell. The number of inter-cell handovers is governed by the setting of
ho_exist_congest. The maximum number of intra-cell handover attempts is governed by the
amount of idle HR capable resources available within the zone. The actual number of intra-cell
handovers triggered will be dependent on the AMR qualification criteria.
If both intra and inter-cell congestion mechanisms are triggered and the ho_exist_congest
element is set to indicate that all candidates are handed over to other cells, all calls that are
not candidates for inter-cell handover, are considered for FR to HR handover. Similarly, if
both intra-cell and inter-cell congestion mechanisms are triggered and the ho_exist_congest
element is set to indicate that the number of calls currently queued for assignment in the cell
is used to determine the number of calls to handover. All calls, that are not candidates for
inter-cell handover, are considered for FR to HR handover.
If a congestion procedure is triggered, while the BSS is still performing a previously triggered
congestion procedure, the BSS attempts to satisfy the second of the congestion procedures
based upon the information gathered for the first congestion procedure. It is therefore possible
that the second congestion procedure will only be partially satisfied, or not satisfied at all,
based on the information available to the BSS.
68P02901W36-S 8-115
Jul 2008
Half Rate congestion relief procedure interaction Chapter 8: Power and Handover Control
Forced use of half-rate
Calls can be forced to use Half Rate (HR). This effectively overrides the MSC preference and
force HR usage prior to cell congestion.
The force_hr_usage element is checked at the following times:

On reception of an assignment request message, which assigns a new channel to the call.
On reception of a handover request for an inter-cell handover to the cell.
On reception of a request for an intra-BSS, inter-cell, handover to the cell.
During intra-cell handovers.
Handover restrictions
When the BSS performs any type of handover for a call, the target channel must satisfy the
requirements specified by the MSC in the assignment request or handover request message for
that call. This applies to all types of handover. If the BSS triggers a handover for an AMR HR
call and the MSC specified preference is for HR within the channel type Information Element
(IE), the target channel for the handover must be an HR traffic channel.
If the HR channel mode is unavailable within the target cell for the handover, the call must
be allocated an FR channel within the target cell. For non-congestion, intra-cell, handovers
between zones within a cell, or inter-cell, handovers, the congestion relief parameters are
rechecked so that FR to HR handovers or inter-cell congestion relief can be initiated. There are
a number of different types of intra-cell handover that need to be considered. These intra-cell
handovers can be triggered by:
Quality.
RxLev.
Congestion.
Range.
Forced handovers due to equipment failure/operator intervention.
If the BSS performs an intra-cell handover, the channel to be used as the target resource for the
handover must conform to the restrictions specified by the MSC in the initial assignment or
handover request message.
8-116 68P02901W36-S
Jul 2008
Intra-zone, intra-cell handovers
Existing intra-cell handovers, that do not involve changing zones are as follows:
Intra-cell handovers from normal range to extended range.
Intra-cell handovers from extended range to normal range.
FR intra-cell quality handovers.
NOTE
This type of intra-cell handover can cause a zone change in a fault scenario.
When there are no resources on the inner zone, it is possible that a resource
on the outer zone can be allocated.
The following text describes the requirements affecting FR intra-cell quality handovers.
When a resource for an FR intra-cell quality handover is required, the BSS allocates a reserved
generic timeslot if there are no other FR resources available in the zone. Reserved HR capable
timeslots are always the last timeslots to be allocated within a zone. All other FR resources
must be exhausted before generic timeslots are allocated.
New intra-cell handovers which do not involve changing zones are as follows:
intra-cell handovers FR to HR due to congestion.
intra-cell handovers HR to FR due to channel quality.
intra-cell handovers HR to HR due to channel quality.
When selecting a target resource, there are a number of restrictions that apply to intra-cell
handover types to support the HR channel mode, as follows:
New hr_intracell_ho_allowed element.
Dependences on congestion.
Dependences on the reserved HR capable timeslots.
New hr_fr_hop_count element.
Dependences on the existing hop_count and hop_count_timer elements.
The following requirements define the interaction of the new intra-cell quality handovers:
The BSS supports intra-cell quality handovers from HR channels to FR channels.
The BSS supports intra-cell quality handovers from HR channels to HR channels.
Intra-cell quality handovers from HR channels are performed between channels within the
same zone. This is true whether the target resource for the intra-cell quality handover
is an FR or HR channel.
68P02901W36-S 8-117
Jul 2008
The BSS allows the operator to define the preferred target channel mode selected for an
intra-cell quality handover from an HR channel.
The new hr_intracell_ho_allowed element contains an option to disable intra-cell quality

handovers for HR channels.
The force_hr_usage element overrides any preference specified with the

hr_intracell_ho_allowed element.
When an HR intra-cell quality handover is triggered by the BSS the following requirements
are applied:
If hr_intracell_ho_allowed is set so that, HR intra-cell quality handovers are disabled,
handover required sent to MSC then the control for this HR intra-cell quality handover will
be passed to the MSC by sending a handover required message identifying the current cell
as the only handover candidate. This functionality mirrors the FR functionality specified by
the element intra_cell_handover_allowed.
If hr_intracell_ho_allowed is set such that, HR intra-cell quality handovers are

disabled. No handover required sent to MSC then HR intra-cell quality handovers
are not supported within the cell. The intra-cell handover request will be ignored
by the BSS. This functionality mirrors the FR functionality specified by the element
intra_cell_handover_allowed.
If hr_intracell_ho_allowed is set such that, HR intra-cell quality handovers are enabled.

FR only allowed, the BSS will attempt to allocate an FR channel as a target resource for
the HR intra-cell quality handover.
If hr_intracell_ho_allowed is set to only allow FR calls and there are no FR resources

available within the zone then the intra-cell quality handover cannot be successful.
The FR resources within a zone include any reserved generic traffic timeslots, when the cell has
severe congestion. The HR channel continues to trigger the handover indication until an FR
resource becomes available, or the call performs a handover to another zone or cell.
If hr_intracell_ho_allowed is set to only allow FR calls and the channel rate specified by the
MSC indicates HR only then the intra-cell handover cannot be successful. The HR channel
continues to trigger the handover indication until the call performs a handover to another cell.
If hr_intracell_ho_allowed is set so that HR intra-cell quality handovers are enabled, HR

allowed, the BSS attempts to allocate a target for the HR intra-cell quality handover. This
handover is based on the congestion levels within the cell, the MSC preference and the operator
preference. The MSC preference can be set as; HR, FR or no preference, as defined by the
force_hr_usage indicator.
An attempt is made to handover the call to AMR FR, or EFR, if permitted by the initial MSC
request, the AMR FR enable per cell and per BSS elements, under the following three conditions:
If hr_intracell_ho_allowed is set to allow HR handovers.
There are no generic timeslots (including switchable PDTCH timeslots that support HR
channels and reserved generic timeslots).
There are no idle HR channels available in the cell.
If there are no idle timeslots at all available in the cell, the handover cannot be successful.
The BSS will attempt to allocate an HR channel as the target for the intra-cell quality handover,
if available, under the following three conditions:
8-118 68P02901W36-S
Jul 2008
If hr_intracell_ho_allowed is set to allow HR handovers.
The call resides on the outer zone.
The congestion level within the cell exceeds reconfig_fr_to_hr.
When reconfig_fr_to_hr is exceeded, the MSC preference is overridden and the use of HR
forced by the BSS. If the call stays on the inner zone of a multi-zone cell, the use of an HR
channel is further restricted by inner_hr_usage_thres. But the previous three conditions still
apply. If there are no HR resources available in either zone, the BSS attempts to allocate an FR
channel as a target for the intra-cell quality handover, if available.
The BSS attempts to allocate a channel based on the MSC preference or operator preference
as the target for the intra-cell quality handover providing the congestion level within the cell
does not exceed reconfig_fr_to_hr. This is true for an outer zone call only. If the call is on the
inner zone of the cell inner_hr_usage_thres must also not be exceeded. If force_hr_usage
element is enabled, the BSS attempts to allocate an HR channel as the target for the intra-cell
quality handover, if available.
If the force_hr_usage element is disabled, the BSS attempts to allocate a channel as the target
resource for the intra-cell quality handover based on the MSC preference. If the MSC specifies
no preference, the BSS attempts to allocate the MSC non-preferred channel mode (FR or HR
as applicable), if available. FR resource is attempted prior to an HR resource. If the MSC
non-preferred channel mode is unavailable, within the zone then the intra-cell quality handover
cannot be successful.
Handover number restrictions
The intra-zone intra-cell HR quality handovers are also governed by the BSS, in a similar
manner to the way FR calls are governed by the existing hop_count and hop_count_timer
elements. This current functionality restricts the number (hop_count) of intra-cell quality
based handovers within a period (hop_count_timer). If the hop_count is exceeded within the
hop_count_timer period, the BSS triggers an inter-cell quality based handover for the call.
If so many intra-cell quality based handovers are performed in a short period of time, it indicates
that the cell is experiencing problems with interference and the call would be best served by
the network by being moved to another cell.
For intra-cell HR quality handovers, a similar mechanism is employed. All intra-cell HR quality
handovers contribute to the existing hop_count. A new element hr_fr_hop_count is provided
to limit the number of intra-cell quality based handovers from HR to FR. This new count also
introduces restrictions upon intra-zone, intra-cell, handovers from FR to HR. This means that
a call experiencing repeated high interference levels remains on an FR channel rather than
HR, during congestion.
The hr_fr_hop_count must be set to a value less than or equal to the hop_count. The
hop_count limits the total number of intra-cell quality handovers for a call (between channel
modes or at the same channel mode).
The hr_fr_hop_count is incremented when an intra-cell HR quality handover is moved to an HR

or FR channel. The functionality of the existing hop_count is not altered. So, if the hop_count
is exceeded before the hop_count_timer expires, the BSS triggers an inter rather than an
intra-cell handover. An intra-cell congestion handover is not performed by a call for which the
hr_fr_hop_count is met and the hop_count_timer has not expired.
When the hop_count_timer expires, hr_fr_hop_count is reset to zero. The following section
defines the interaction of the new intra-zone, intra-cell, FR to HR, handovers due to congestion.
68P02901W36-S 8-119
Jul 2008
Inter-zone, intra-cell handovers
Existing intra-cell handovers which do involve changing zones are as follows:

Intra-cell handovers from outer zone to inner zone.
Intra-cell handovers from inner zone to outer zone.
Existing handovers are affected by the introduction of the HR channel mode during the
allocation of a target resource for the inter-zone intra-cell handover. If the available channel
modes and MSC preference allows, the inter-zone, intra-cell handover can possibly result in a
change of channel mode. This action is governed by the congestion levels within the cell and
the MSC and operator preferences. Inter-zone, intra-cell handovers are not restricted by the
existing intra_cell_handover_allowed element or the new hr_intracell_ho_allowed element.
The restrictions governing the allocation of HR channels when performing an inter-zone,

intra-cell handover to the outer or inner zone will follow the rules specified previously.
Essentially the allocation of a resource for an inter-zone, intra-cell handover is treated as if it
were the initial assignment of a traffic channel within the cell.
Intra-BSS, inter-cell handovers
Intra-BSS inter-cell handovers are treated as new calls entering a cell. It is the possible that,
if the available channel modes and MSC preference allows, the intra-BSS, inter-cell handover
can result in a change of channel mode. This is governed by the congestion levels within the
target cell, MSC and operator preferences.
Intra-BSS, inter-cell handovers can be from FR, AMR FR or EFR to HR channels, HR to FR

channels or HR to HR channels.
If the BSS needs to perform an intra-BSS, inter-cell handover, the channel to be used as the
target resource for the handover is required to conform to the restrictions specified by the MSC
in the initial assignment request or handover request message. The BSS will also reapply the
rules that were used upon the initial establishment of the call within the cell.
There is a further requirement when an intra-BSS, inter-cell handover directed to the inner zone
of a multi-zone cell is taken into consideration. The use of the HR channel mode within the inner
zone of a dual band cell is restricted by the inner_hr_usage_thres. This parameter is applied
when the force_hr_usage element is set to disabled, the MSC preference is not HR and the
congestion level exceeds the new_calls_hr threshold.
If the BSS has directed the call to the inner zone upon intra-BSS, inter-cell handover and there
is no target resource available within the target cell for the handover, the handover cannot be
successful. The BSS attempts to handover to the next candidate. If the channel rate specified
by the MSC indicates HR only and the BSS cannot allocate an HR resource as a target for the
intra-BSS, inter-cell handover, the intra-BSS, inter-cell handover cannot be successful.
If the handover to the target cell is unsuccessful, the BSS continues (as existing functionality
dictates) with the next handover candidate. If the BSS cannot hand the call over to a neighbor
cell, the call will remain on the current channel until the radio conditions cause the call to be
released. Release of the call depends on loss of SACCH measurement reports from the MS.
During this period, the call continues to attempt to handover to neighbor cells.
8-120 68P02901W36-S
Jul 2008
Inter-BSS, inter-cell handovers
For an inter-BSS, inter-cell handover, the target channel must satisfy the requirements specified
by the MSC in the assignment request or handover request message. If the available channel
mode and MSC preference allows, the inter-BSS, inter-cell handover can result in a change
of channel mode. This is governed by the congestion levels within the target cell, MSC and
operator preferences.
NOTE
Intra-BSS, inter-cell handovers are treated as inter-BSS, inter-cell handovers if the
inter_cell_handover_allowed parameter is disabled.
If there is no target resource available within the target cell for the handover, the handover
cannot be successful. The BSS will attempt to handover to the next candidate.
If channel rate specified by the MSC indicates HR only and the BSS cannot allocate an HR
resource as a target resource for the inter-BSS handover, the inter-BSS inter-cell handover will
be unsuccessful. If the handover to this target cell is unsuccessful, the BSS will continue (as
existing functionality dictates) with the next handover candidate.
If the next handover is unsuccessful, the call will remain on the current channel until the
radio conditions cause the call to be released. Release of the call is caused by loss of SACCH
measurement reports from the MS. During this period, the call will continue to attempt to
handover to candidate neighbor cells.
Directed retry alternatives
The overall operation of congestion relief (directed retry alternatives) functionality is unaffected
with the introduction of half-rate features (AMR HR, GSM HR). Some aspects related to the
triggering of this functionality are changed to allow Half Rate resources to be managed within
the cell.
The BSS triggers the congestion relief mechanism when a half-rate channel becomes busy with
a call. When the BSS calculates the congestion level of the cell, it includes idle generic traffic
timeslots, busy half-rate channels and idle half-rate channels.
The BSS combines full-rate and half-rate resources within the outer zone when calculating the
congestion level for triggering congestion relief. With half-rate, carriers do not all share the
same capabilities, therefore the lack of resources for a particular call does not necessarily
imply overall cell congestion.
If channel allocation fails due to unavailability of resources for a call which only allows GSM
Half-Rate speech version 3, the BSS does not trigger congestion relief procedures. Unavailability
of half-rate resources does not imply cell congestion. However, if a handover fails due to
unavailability of resources the BSS marks the target cell as congested. As a result, congestion
or traffic related handovers are not directed to that cell for a user-configurable period.
If an intra-BSS handover fails due to unavailability of resources for a call which only allows
GSM half-rate speech version 3 the BSS does not mark the target cell as congested. This
does not apply to inter-BSS handovers, as the source BSS cannot assume information about
the congestion level in the target BSS. In this case the functionality will work as current
implementation (target cell always marked as congested).
68P02901W36-S 8-121
Jul 2008
Adaptive Multi-Rate (AMR) Chapter 8: Power and Handover Control

Handover Decision and Power Correction (HDPC)
The HDPC algorithms are identical for AMR Full-Rate (FR) and Half-Rate (HR) to existing
calls. However, new values apply for Rxqual-based decisions (XX = ul or dl). Separate Rxqual
threshold values are used for AMR FR calls, with the exception of the existing threshold
u_rxqual_XX_p which will be applied to all FR calls.
For AMR FR:

l_rxqual_XX_p_amr_fr.
l_rxqual_XX_h_amr_fr.
l_rxqual_XX_h_hopping_amr_fr.
l_rxqual_XX_p_hopping_amr_fr.
Separate Rxqual threshold values are used for AMR HR calls.
NOTE
The existing N and P voting parameters and RxLev decision thresholds are applied
to AMR HR calls.
For AMR HR:

l_rxqual_XX_p_amr_hr.
l_rxqual_XX_h_amr_hr.
u_rxqual_XX_p_amr_hr.
l_rxqual_XX_h_hopping_amr_hr.
l_rxqual_XX_p_hopping_amr_hr.
AMR codec modes provide differing error correction capabilities, allowing different channel Bit
Error Rates (BER) for acceptable quality of service. In a lower codec mode with more error
correction capability, a lower Rxqual is acceptable for some channels. The handover and power
control algorithms use a different set of handover and power control Rxqual thresholds for FR
and HR AMR calls. AMR calls use the standard RxLev thresholds in the database.
The existing GSM power control algorithm is used for downlink quality based power control
for AMR calls.
8-122 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Handover Decision and Power Correction (HDPC)
Parameter definitions
The new parameters for AMR FR calls are defined as follows:

l_rxqual_dl_p_amr_fr is used as the lower bound threshold for quality based power
control in the downlink direction.
l_rxqual_ul_h_amr_fr is used as the uplink quality handover threshold.
l_rxqual_ul_p_amr_fr is used as the lower bound threshold for quality based power
control in the uplink direction.
l_rxqual_dl_h_amr_fr is used as the downlink quality handover threshold.
The new parameters for AMR HR calls are defined as follows:

l_rxqual_dl_p_amr_hr is used as the lower bound threshold for quality based power
u_rxqual_dl_p_amr_hr is used as the upper bound threshold for quality based power
l_rxqual_ul_p_amr_hr is used as the lower bound threshold for quality based power
u_rxqual_ul_p_amr_hr is used as the upper bound threshold for quality based power
l_rxqual_dl_h_amr_hr is used as the downlink quality handover threshold.
l_rxqual_ul_h_amr_hr is used as the uplink quality handover threshold.
The new parameters for calls during frequency hopping are defined as follows:
l_rxqual_dl_p_hopping_amr_fr is used as the lower bound threshold for quality based
power control in the downlink direction for FR AMR calls that are hopping. This parameter
is enabled and set for FR AMR hopping calls by use of the hop_qual_enabled cell
parameter. In this situation this threshold is used instead of the l_rxqual_dl_p_amr_fr
parameter.
l_rxqual_dl_p_hopping_amr_hr is used as the lower bound threshold for quality based

power control in the downlink direction for HR AMR calls that are hopping. This parameter
is enabled and set for HR AMR hopping calls by use of the hop_qual_enabled cell
parameter. In this situation this threshold is used instead of the l_rxqual_dl_p_amr_hr
parameter.
l_rxqual_ul_p_hopping_amr_fr is used as the lower bound threshold for quality based

power control in the uplink direction for FR AMR calls that are hopping. This parameter is
enabled and set for FR AMR hopping calls by use of the hop_qual_enabled cell parameter.
In this situation this threshold is used instead of the l_rxqual_ul_p_amr_fr parameter.
l_rxqual_ul_p_hopping_amr_hr is used as the lower bound threshold for quality based

power control in the uplink direction for HR AMR calls that are hopping. This parameter is
enabled and set for HR AMR hopping calls by use of the hop_qual_enabled cell parameter.
In this situation this threshold is used instead of the l_rxqual_ul_p_amr_hr parameter.
68P02901W36-S 8-123
Jul 2008
Ater assignment Chapter 8: Power and Handover Control
l_rxqual_dl_h_hopping_amr_fr is used as the downlink quality handover threshold for FR

AMR calls that are hopping. This parameter is enabled and set for FR AMR hopping calls
by use of the hop_qual_enabled cell parameter. In this situation this threshold is used
instead of the l_rxqual_dl_h_amr_fr parameter.
l_rxqual_dl_h_hopping_amr_hr is used as the downlink quality handover threshold for

HR AMR calls that are hopping. This parameter is enabled and set for HR AMR hopping
calls by use of the hop_qual_enabled cell parameter. In this situation this threshold is
used instead of the l_rxqual_dl_h_amr_hr parameter.
l_rxqual_ul_h_hopping_amr_fr is used as the uplink quality handover threshold for FR

AMR calls that are hopping. This parameter is enabled and set for FR AMR hopping calls
instead of the l_rxqual_ul_h_amr_fr parameter.
l_rxqual_ul_h_hopping_amr_hr is used as the uplink quality handover threshold for HR

AMR calls that are hopping. This parameter is enabled and set for HR AMR hopping calls
instead of the l_rxqual_ul_h_amr_hr parameter.
Ater assignment
Ater assignment is the initial assignment and configuration of timeslots in Enhanced Auto
Connect (EAC) mode for use in AMR 8 kbps half-rate. The BSS does not utilize 8 kbps Aters on a
BSC-RXCDR interface if EAC mode is disabled for the AXCDR.
When the EAC mode parameter eac_mode is disabled for an AXCDR, the BSS terminates
all active calls associated with the AXCDR and reconfigures the CIC-Ater assignments to
auto connect mode. If the EAC mode parameter cic_validation is disabled for an AXCDR,
the BSS terminates all active calls associated with the AXCDR and reconfigures the CIC-Ater
assignments to backward compatible mode.
The requirements for call reassignment apply irrespective of the state of the existing
parameter amr_bss_half_rate_enabled since there are no restrictions on disabling
eac_mode or cic_validation when amr_bss_half_rate_enabled is enabled. However, if
amr_bss_half_rate_enabled is enabled, a warning is issued when eac_mode or cic_validation
is disabled.
In EAC mode, with 8 kbps switching enabled on a BSC-RXCDR interface, the CIC-Ater
connections remain in place. During transition to the BU-EAC state, the existing CIC-Ater
connections remain in place.
During initialization, the CIC-Ater connections are assigned on a 16 kbps basis for both auto
connect and EAC modes. This avoids unnecessary impact on existing calls. Connections remain
the same when EAC mode is enabled on the BSC-RXCDR interface.
When the BSC is initialized in EAC mode, the initial CIC-Ater assignments are configured on a
16 kbps basis using the same algorithm as auto connect mode to select the Aters. This algorithm
does not allow for half-rate usage so there can be insufficient 16 kbps Aters for all the CICs.
If an RXCDR is not capable of 8 kbps switching, 8 kbps Aters are not assigned to calls even if
EAC is enabled for an AXCDR. The BSS behaves as if in auto connect mode. This means that
only 16 kbps Aters are used and no CICs are unblocked but not assigned. If more CICs exist
than available Aters any CICs without an Ater is blocked. This has no impact to the half-rate
calls on the BSC to BTS or air interfaces.
8-124 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Ater assignment
The BSS does not utilize 8 kbps Aters if EAC is enabled and all available CICs are assigned a 16
kbps Ater during initialization. The system behaves functionally as in Auto Connect mode but
some EAC-specific functionality can still occur. The CIC-Ater connection audits that form part of
the periodic audits if mismatched resources exist, can be carried out.
In EAC mode when Aters assigned to CICs are blocked, CICs remain unassigned and in an
unblocked state if:
There are no other Aters available to be assigned.
8 kbps switching is being utilized and Aters assigned to CICs are unprovisioned, if there
are no other Aters available to be assigned.
8 kbps switching is being utilized if CICs are equipped and there are no other Aters
available to be assigned to the CICs.
CIC blocking is dependent on reaching the blocking threshold.
In EAC mode and 8 kbps switching is being utilized, if CICs assigned to Aters are blocked, or
unequipped, the Aters are reassigned to any CICs in the unblocked state with no Ater assigned.
68P02901W36-S 8-125
Jul 2008
Ping-pong Chapter 8: Power and Handover Control
Ping-pong

In dual band cells it has been found that inter-zone ping-pong handover can occur at a high rate
causing degradation in voice quality.
The solution is to limit the number of times, within a defined period, that a single call can
ping-pong between cell zones. If a call exceeds the allowed number of inter-zone handovers
threshold set by the customer, that call is not allowed to be handed over to the other cell zone
for a user-specified period.
The customer also specifies which zone is to be used to service ping-pong calls. The BSS
attempts to hand over calls not already in the preferred zone into the preferred zone when a
call exceeds the threshold. These handover attempts can fail due to a lack of resources in
the target zone.
8-126 68P02901W36-S
Jul 2008
Chapter
EGPRS and GPRS Power Control

This chapter provides a description of the Motorola EGPRS and GPRS power control and coding
schemes and how coding schemes are used in power control.

EGPRS and GPRS power control and coding schemes on page 9-2.
MS signal level measurements on page 9-5.
GPRS uplink power control on page 9-13.
GPRS downlink power control on page 9-18.
GPRS coding scheme selection on page 9-32.
EGPRS power control on page 9-38.
EGPRS uplink power control on page 9-39.
EGPRS downlink power control on page 9-40.
EGPRS coding scheme selection on page 9-46.
68P02901W36-S 9-1
Jul 2008
EGPRS and GPRS power control and coding schemes Chapter 9: EGPRS and GPRS Power Control
EGPRS and GPRS power control and coding schemes

Overview of (E)GPRS power control and coding schemes
Unlike GSM, (E)GPRS has the ability to vary the coding scheme being used in order to protect
the data. Coding scheme selection and power control are therefore closely related as the data
transfer can be improved by varying the power, or by selecting a different coding scheme.
Effectively the Packet Control Unit (PCU) has individual algorithms for both varying the power
and selecting a different coding scheme.
As in GSM, power control is derived following a number of measurements taken by both the
MS and the BTS. Once the measurements are taken, uplink power control is either performed
under the control of the BSS (closed loop), or autonomously by the MS (open loop). Downlink
power control works on a closed loop system. The measurements and algorithms in use will also
determine which coding schemes are used.
Types of (E)GPRS power control
(E)GPRS power control is divided into uplink and downlink power control.
Uplink power control
The Motorola (E)GPRS solution supports the following types of uplink power control:
Closed loop.
Open loop.
Combined.
Downlink power control
The Motorola (E)GPRS solution supports only one type of downlink power control. Downlink
power control is divided into five phases, which depend on the current transfer state of the MS.
The power control method is different in each phase.
Coding schemes
The Motorola (E)GPRS solution supports all existing GPRS coding schemes (CS1-CS4) for
GPRS TBFs and all EGPRS coding schemes (MCS1-MCS9) for EGPRS TBFs on a 64 kbps
terrestrial channel.
9-2 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Measurement reporting
Measurement reporting
Measurement reports are taken to keep the MS and the BTS within the power window. The
measurements are averaged and then compared against various thresholds (normally set in
the database) before an action is carried out.
MS measurement
The MS performs the following measurements:

Received level of neighbor cells-BCCH carrier.
Decode BSIC of neighbor cells.
Received signal level of serving cell-BCCH carrier.
Received signal level of serving cell-at least one Packet Data Traffic Channel (PDTCH)
allocated to the MS.
Channel quality or interference level on idle frames on as many PDTCH as possible. The
actual number depends upon the multi-class slot of the MS.
The received signal level of the serving cell BCCH carrier, as measured by the MS, will be used
for both power control selection and cell selection (C1). To ensure this occurs, the database
parameter gprs_pc_meas_chan must be set to BCCH Failure to do this could result in the C1
calculation being inaccurate leading to unnecessary reselection.
Channel quality reports
Unlike GSM, an MS within a Motorola GPRS system does not send measurement reports to
the BSS. Instead Channel quality reports are used by the PCU from the downlink Ack/Nack
message.
BSS measurement
The BSS measures the received signal strength and quality of the MS in the uplink. In addition,
it also measures the interference on all idle timeslots within a carrier, together with the distance
of all MSs relative to the BTS that it is currently serving. The following measurements are
performed by the BSS:
Received signal level per radio block that is received.
Idle power measurements. This is taken on idle frames 1 and 3 of the 52-multiframe
for every GPRS enabled channel.
Received quality of each radio block received.
Average timing advance error.
The measurements are then passed to the PCU for further processing. Additionally, the PCU
also performs BLER measurements on the contents of the uplink Ack/Nack message.
68P02901W36-S 9-3
Jul 2008
Methods of GPRS power control Chapter 9: EGPRS and GPRS Power Control
Methods of GPRS power control
When deciding to alter the power of the MS or BTS, the system employs two methods, they
are as follows:
Stepped power control (Downlink)
Altering the power level in pre-defined step sizes can take many steps before the desired power
level is reached within the power window.
NOTE
Uplink power control does not use stepped power control.
Dynamic power control (Uplink and Downlink)
By using this method a quicker solution can be achieved with the help of the algorithms, thereby
enhancing the flexibility of the network.
9-4 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation MS signal level measurements
MS signal level measurements

Types of signal level measurements
During a packet transfer, the MS is taking measurements on the downlink for the serving cell.
This is performed on the BCCH and at least one of the PDTCH that it is assigned.
The measurement taken on the BCCH is known as the normalized C value and will be used for
both power control and cell selection (C1). This measurement will be taken when the MS is in
either the standby or ready state.
The measurement taken on the PDTCH is a signal variance level taken between decoded
Radio Link Control (RLC) blocks.
Normalized C
The normalized C value consists of an average of received signal level of the decode blocks.
The mean value of the 4 bursts that make up the block is calculated by the formula:
C Block [n] = SSBlock [n] +P B
where,
SS = mean of receive signal level of the block.
PB = BTS output power reduction (always 0 if BCCH used).
N = Block in progress.
The mean of each block is calculated over a period set by a database parameter, t_avg_t
for the ready state or t_avg_w for the standby state, using the formula:
C [n] = (1 b) C [n1] +b SS[n]
where,
C[n-1] = normalized value of previous block.
b = The period the average is calculated over. This is given by another formula:
1 1
b= or b =
6 tavgt 12 tavgt
68P02901W36-S 9-5
Jul 2008
Types of signal level measurements Chapter 9: EGPRS and GPRS Power Control
The first is used if measurements are on the BCCH, the second if measurements are taken
on a PDCH where,
n = Block in progress.
When completed the normalized C value is encoded by a scale of 0-63, as used for GSM.
Figure 9-1 illustrates the normalized C value calculations.
Figure 9-1 Normalized C value
Signal variance PDTCH
During packet transfer mode the MS will also calculate the signal variance between radio
blocks on at least one of the allocated PDTCHs. The PDTCH that is chosen will be the one
that its PACH is allocated on, as this will be used to send channel quality reports. The level is
calculated using the formula:
4
X
1 2
BLVAR [n] = SS[k ] SSBlock [n]
j 1
k =1
where,
SS[k] is the received signal level of the individual burst within a block.
SSBlock[n] is the mean of the received signal level of the j normal bursts that compose the radio
block.
j is the number of bursts in the radio block, that is, j = 4.
The value of signal variance that is reported, SIGN_VAR, is the average of BL_VAR taken over
the reporting period.
Figure 9-2 illustrates the signal variance PDTCH calculation.
9-6 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Types of signal level measurements
Figure 9-2 Signal variance PDTCH
The reporting period lasts from the first assignment message and continues until two blocks
before the transmission of a Channel Quality Report, which is sent during the Ack of a
transmission of radio blocks. If an MS is performing an uplink transfer only, it will not take
measurements on any PDTCH allocated. Figure 9-3 shows the RLC data block reporting periods.
68P02901W36-S 9-7
Jul 2008
Channel interference measurement reports Chapter 9: EGPRS and GPRS Power Control
Figure 9-3 RLC data block reporting periods A and B
Channel interference measurement reports
Channel quality is taken as a measure of interference. The MS will take these measurements on
the allocated PDTCH mutliframes as a minimum and if possible on channels that correspond to
the multislot class of the MS. If the allocated timeslot is assigned to the BCCH carrier, these
measurements will not be used due to the constant power output of the carrier.
During the mutiframes, the MS will take measurements on:

Idle frames.
The interval between transmission and reception, which will depend upon the capability
of the MS (tta/b, tra/b).
Any other inactivity period.
The interference level is calculated over a period of time, which is set by the formula:
1
d=
MIN (n , navgi)
where,
9-8 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Channel interference measurement reports
n_avg_i is database parameter which ensures that at least n_avg_i measurements are taken
before valid interference levels are declared.
The MS will calculate the interference level by using the formula:
yCH [n] = (1 d) yCH [n1] +d SS CH [n]
where,
d = the measurement period.
SSch[n] = the signal level of the channel in question.
If an MS changes cell, the value of n starts again at 1. Once the interference levels have been
obtained they are mapped to the normalized C value.
Figure 9-4 illustrates the channel interference measurements.
Figure 9-4 Channel interference measurements
RXQUAL measurements
In addition, the MS must also make RXQUAL measurement on any blocks received during a
downlink transfer as defined for GSM.
68P02901W36-S 9-9
Jul 2008
BSS received signal level Chapter 9: EGPRS and GPRS Power Control
Channel quality reports
Once the MS has completed its signal and interference level measurements, a Channel Quality
Report is compiled, before being sent with the Packet Downlink Ack/Nack message to the
network. The contents of this message is:
Normalized C value-this is essentially the average receive level of the monitored channel
relative to the BCCH, encoded as per GSM.
Signal Variance-this is the average signal level difference between received Radio Blocks.
The value is encoded in 0.25db steps from 0 to-15.75 dB.
Interference Levels-this is the signal interference level of all 8 timeslots. The value in each
timeslots is mapped to the normalized C value in 2db steps from 0>-30dB.
RXQUAL-this is the receive quality of blocks received during a downlink transfer, encoded
as per GSM.
BSS received signal level
The BSS will calculate the received signal level for all in use PDTCHs during the power control
period. The duration of the power control period is from the period the immediate assignment is
sent until the Packet Downlink Ack/Nack is sent.
The average is calculated as follows:
(RXLEV 1burst1 + RXLEV 2burst2 + RXLEV 3burst3 + RXLEV 4burst4)

ULRXRXLEV =
4
Once obtained the level for a particular radio block is averaged over a number of radio
blocks to give a final figure for each PDTCH. This is calculated by using the following
formula:

Maxbeta
Maxbeta beta SSB [n1] = beta ULRXRXLEV +
2
SSB [n] =
Maxbeta
where,
SSB[n] is new averaged UL received level at BTS.
SSB[n-1] is up to last block averaged UL received level at BTS.
UL_RX_RXLEV is the current block UL received level at BTS.
Beta is the UL received level averaging factor ranging from 1 to 100. Effectively, the
value of this parameter decides how much weight is given to the receive level value of
the previous block.
Max_beta is 100.
(Max_beta/2) is used to round off the calculation.
9-10 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BSS received interference level
Figure 9-5 illustrates the BSS received signal level calculations.
Figure 9-5 BSS received signal level
a b c d
BSS received interference level
To estimate the interference that each timeslot is subject to, the BSS will make two sets of
measurements. These are as follows:
The BSS will measure the received power level on any idle radio block within a PDCH.
A single power level will be derived form the average of the 4 power measurements that
correspond to each burst.
The BSS will measure the received power level of idle slots 2 and 4 in the 52 multiframe
structure of the PDCH. It is important that the idle slots used for continuous timing
advance are not monitored.
Received C/I estimation
The interference level of the PDCH at the BSS will be used in the calculation of
Carrier/Interference estimation. The results of this calculation will then directly affect which
coding scheme will be selected.
BSS RXQUAL measurements
The BSS must also make RXQUAL measurement on any decoded blocks received during an
uplink transfer as defined for GSM. Figure 9-6 illustrates the BSS received interference level
measurements.
68P02901W36-S 9-11
Jul 2008
BSS received interference level Chapter 9: EGPRS and GPRS Power Control
Figure 9-6 BSS received interference level measurements
B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11
H
H
9-12 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation GPRS uplink power control
GPRS uplink power control

Uplink algorithms
Based upon information provided by the PCU the MS performs the power control execution.
However, the information provided and how the MS carries out this task depend upon database
parameters and differing algorithms.
While the chosen algorithms can be different, they are all based upon the following formula:
P CH = MIN ( 0 CH a (C + 48) , PMAX )
where,
CH is an MS and channel specific power control parameter, sent to the MS in a Release

Complete (RLC) control message.
0 is a constant. 39 dBm for GSM 900, 36 dBm for DCS 1800.
a is a system parameter gprs_pc_alph, broadcasted on the BCCH or optionally sent to the MS

in an RLC control message. This parameter denotes the type of uplink power control in use.
The range for a goes from 0 to 1.
NOTE
The database value is the value of a multiplied by a factor of 10.
If a = 0, it denotes Closed loop power control.
If a = 1, it denotes Open loop power control.
If a > 0 and a < 1, it denotes Combined power control.
C is the normalized received signal level at the MS.
PMAX is the maximum transmitted output power allowed for mobiles in the cell. This value
is given by the database parameter ms_txpwr_max_cch.
Periodically the MS can receive new values for CH and a. These values are then applied to
the algorithm to ascertain a new value of Pch. The MS can round up the calculated output
if required. Nevertheless it will apply the calculated value to all four bursts that make up
the radio block.
Obviously, before an MS has received a power control instruction, or merely requires to RACH
in, it must use a default transmit power level value. This value is set by the PMAX.
68P02901W36-S 9-13
Jul 2008
Closed loop uplink power control Chapter 9: EGPRS and GPRS Power Control
Closed loop uplink power control
Motorola supports closed loop uplink power control. Closed loop power control can be achieved
by setting the database parameter gprs_pc_alpha to 0. By doing this, the uplink power control
algorithm becomes an algorithm very similar to the one used in circuit switched power control.
When this algorithm is used, the PCU effectively sends the mobile station the actual attenuation
of maximum power, (CH ) to transmit at. By setting a to zero, the mobile station uses the
following equation to determine the power level to transmit at:
P CH = 0 CH
where,
o is a constant that depends on the frequency band that the mobile is operating within (equal
to 39 dBm for GSM 900 and equal to 36 dBm for DCS 1800.
CH is dynamically adjusted as required so that the received signal level at the BSS (SSB)
is within a predefined power box.
The power window mean is given by:
URXLEVULP +LRXLEVULP
P wrBoxM ean =
2
and it represents the center value of the power window. The algorithm for closed-loop uplink
power control will increase or reduce CH if SSB is out of the power box.
A quantity ms_pwr_offset will be calculated to reflect the amount of adjustment required in CH

such that the received signal level moves closer to the power box. The ms_pwr__offset value
depends on how far the BSS receive signal level (SSB) is from the power box and for how many
iterations the PCU has been trying to pull the mobile back into the power box. If (SSB(dbm) >
U_RXLEV_UL_P(dbm) or SSB(dbm) <L_RXLEV_UL_P (9 dbm) then:
0 = CH msowroffset
Minimum value of CH is (o-ms_txpwr_max_cch). By sending this value of CH the mobile will

transmit at maximum power allowed by the network.
Maximum value of CH is 63.
If the calculated CH value is beyond the limits, the PCU clips CH to its closest limit.
The values for SSB, L_RXLEV_UL_P and U_RXLEV_UL_P are given in Table 9-1.
Table 9-1 Range and values for SSB L_RXLEV_UL_P and U_RXLEV_UL_P
SSB GSR9.0 SSB Default

0 = 110 dBm 0 = 128 dBm 0 =-110 dBm
1 = 109 dBm 1 = 127 dBm 1 = 109 dBm
63 =-47 dBm 127 =-1 dBm 63 =-47 dBm
9-14 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Open loop uplink power control
So, the BSS will periodically send adjustments to the MS by means of the CH parameter, so that
the received signal level in the uplink is within a pre-defined power box (as for GSM calls). This
power box is shown in Figure 9-7.
Figure 9-7 Uplink power control window
--47 dB m
U R XLEV U L
L R XLEV U L
--110 dB m
The same upper and lower thresholds for the power box are used for GSM and GPRS calls. The
thresholds can be set by the user in the BSS database.
Open loop uplink power control
With this method, it is the MS that has most of the power control. The principle is based upon
the assumption by the MS, that the signal level it receives from the BTS downlink has the same
path loss as the BTS experiences in the uplink direction.
To use this type of power control, the database parameter gprs_pc_alpha is set to 1. The BTS
will calculate the value of CH by use of the formula:
CH = 0 P BTS SSB 48
where,
0 is a constant. 39 dBm for GSM 900, 36 dBm for DCS 1800
48 is a value used to encode the value of CH.
PBTS is the maximum output power of the BTS.

SSB is the received signal level at the BTS.
The result is the level the MS would have to transmit at if it is to stay within the power window.
The BTS will then pass this to the MS during the power control or timing advance update
message or during a packet uplink Ack/Nack message. Once received, the MS will recalculate
its own the power level instead of using the ordered level of the network to stay within the
BTS power window.
68P02901W36-S 9-15
Jul 2008
Combined uplink power control Chapter 9: EGPRS and GPRS Power Control
NOTE
Alpha and Gamma could be sent to the mobile in the power control or timing advance
message, packet uplink Ack/Nack, packet uplink assignment and packet downlink
assignment.
The equation used by the MS is as follows:
P CH = 0 CH C 48
where,
C is the normalized signal level received from the BTS.
48 is a value used to encode the value of CH.
0 is a constant. (that is 39 dBm for GSM 900 and 36 dBm for DCS 1800).
Combined uplink power control
Combined power control can be achieved by setting 1 > a > 0. This algorithm is the combination
of open loop and closed loop power control. Depending on the value of a, CH is calculated
using the following equation:
CH = (1 a) close +a open
where,
close is the attenuation calculated using the close loop algorithm.
open is the attenuation calculated using the open loop algorithm.
Signaling uplink power control
The MS carries out uplink power control, under the control of the network or independently.
However, in both cases the decision is reached using information provided by the other Network
Element. This can be summarized as follows:
9-16 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Signaling uplink power control
BSS to MS
CH
MS and channel specific power control parameter, sent to the MS in an RLC control
message.
A database parameter indicating the type of uplink power control.
NOTE
Alpha and Gamma can be sent to the mobile in the power control or timing
advance message, packet uplink Ack/Nack, packet uplink assignment and packet
downlink assignment.
MS to BSS
Channel Quality Reports.
These are uplinked to the Network during a Packet DL Ack/Nack message.
68P02901W36-S 9-17
Jul 2008
GPRS downlink power control Chapter 9: EGPRS and GPRS Power Control
GPRS downlink power control

Downlink power control is used by the network to keep the BTS transmit power level to a
minimum. This allows a distant MS to obtain the usable signal at the lowest power level, while
using the best coding scheme to afford it the best throughput. In addition, this will have
the advantage of reducing interference with neighbor cells in the event of a tight frequency
reuse pattern.
Phases of downlink power control
Unlike uplink power control, downlink power control is split in to 5 distinct phases. This will
depend upon the transfer state the MS is currently engaged in. Additionally, the power control
applied at each level will be calculated using differing methods. Once the power level has
been decided, it will remain in force for all radio blocks that make up a burst. The 5 phases of
downlink power control are as follows:
Phase 1 - Start condition
BCCH/PBCCH power level.
Phase 2 - Immediate assignment downlink message sent

Phase 3 - Packet downlink assignment message sent

Phase 4 - Packet control Ack received from the MS

Reciprocal path loss.
Phase 5 - Packet downlink Ack/Nack received from the MS

Closed-loop based on the MS reported C. RXQUAL and BLER estimates from the
RLC bitmap.
The power level and coding scheme will be updated everytime a packet downlink
Ack/Nack message is received from the MS.
9-18 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Phases of downlink power control
Figure 9-8 illustrates the 5 phases of downlink TBF power control.
Figure 9-8 Phases of downlink TBF power control
As it can be seen, the algorithm starts at BCH power level (phases 1, 2 and 3) until a packet
control Ack message is received from the MS. This is the first time during a downlink TBF
establishment that the BSS gets an indication about the distance to the MS and output power
requirements.
At this point, phase 4 starts. The RXLEV and RXQUAL of the packet control Ack message
are measured at the BSS and the initial output power is estimated by performing a path loss
calculation.
Phase 5 (closed loop power control) starts when the first packet downlink Ack/Nack message
is received from the MS. This message includes a channel quality report from the MS, which
contains the C value and RXQUAL. The MS Mode A reported values serve as input to the power
control algorithm so that adjustments are calculated and applied as required.
68P02901W36-S 9-19
Jul 2008
Downlink power control modes Chapter 9: EGPRS and GPRS Power Control
Downlink power control modes
During the five phases of downlink power controlmode A operation is implemented (Mode
B is no longer supported). The parameter gprs_dl_pwr_mode must be set to Mode A. This
parameter is broadcast to the MS in the packet uplink assignment message.
Mode A
Mode A is used when the PCU is using dynamic allocation of uplink resources. When using
Mode A, the power of the BTS is limited to a value between BCCH and BCCH-10 dB.
Mode B
Since the fixed allocation of resources is not allowed, Mode B operation is not supported.
Figure 9-9 illustrates Mode A downlink power control.
Figure 9-9 Mode A and Mode B downlink power control
Increments/Decrements
When the BTS has decided that a change in the downlink power level is required, it will change
the level in steps of 2 dBs for every 3 blocks until the desired level is reached.
9-20 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Phases 1, 2 and 3
Phases 1, 2 and 3
Phases 1,2 and 3 will always use a power level set by the BCCH. It cannot change to a different
level until the MS has made contact with the Network, which occurs when the MS sends a
packet control Ack message.
At this point, the network is able to measure the RXLEV and RXQUAL of the message to
determine the requirements of the MS and so begins to use Phase 4, which is based upon
a reciprocal path loss calculation.
When the MS has sent a channel quality report during its first packet downlink Ack/Nack
message to the network, the normalized C value and RXQUAL measurements are used as an
input for closed loop power control algorithms, phase 5.
Phase 1-Start condition
Phase 1 of downlink power control begins when the BSS transmits, at the BCCH/PBCCH power
level, the immediate assignment message to the MS.
Phase 2-Immediate assignment downlink-message sent
Phase 2 of downlink power control begins when the BSS transmits, at the BCCH/PBCCH power
level, the packet downlink assignment message to the MS.
Phase 3-Packet downlink assignment-message sent
Phase 3 of downlink power control begins when the MS transmits, at BCCH/PBCCH power level,
the packet downlink assignment message to the BSS.
Phase 4 packet control Ack received from the MS
Upon receipt of the packet control Ack message from the MS, the BSS can begin phase 4 of
downlink power control, the principle mechanism of which is reciprocal path loss.
To perform this calculation the BSS evaluates the packet control Ack message in terms of:
RXQUAL
RXLEV
The path loss is first calculated on the uplink. This is followed by an estimation of the downlink
path loss, before an estimation of the received signal strength at the MS is performed.
68P02901W36-S 9-21
Jul 2008
Phase 4 threshold comparisons Chapter 9: EGPRS and GPRS Power Control
Uplink path loss is calculated as the MS transmit power level (PMAX) of the packet control Ack
message minus the received power level at the BSS, using the following formula:
P LU L = mstxpwrmaxcch rxlev
Downlink path loss is estimated as the uplink path loss plus a *margin to account for extra
looses on the uplink, due to signal level fading.
P LDL = PL UL +Mar gin
*The margin is 13dB for general use and 5dB in the case of frequency hopping.
Finally, an estimation of the receive level of the MS is calculated, as if the BTS were to transmit
at maximum power. This is carried out as follows:
RX M S = maxtxbts PL DL
where,
RXms = the estimated receive level of the MS.
max_tx_bts = the maximum power of the BTS.
PLDL = the estimated downlink path loss.
Phase 4 threshold comparisons
Once the estimated receive level of the MS has been calculated, it is compared along with the
receive quality of the packet control Ack message against a set of hardware encoded thresholds.
The result of this comparison is a calculated power level of the BTS, along with the coding
scheme to be used. The coding scheme is based on quality, but as already stated, power control
or level and quality are linked. As in GSM there can be a number of conditions in relation to
the received signal:
Good level, good quality.
Bad Level, bad quality.
Bad level, good quality.
Good level, bad quality.
How the network deals with the results will depend upon the actual levels in relation to the
thresholds. Essentially in case 1, the system will drop the power level and change coding
scheme to offer a higher throughput of data. In case 4, the coding scheme has to be changed
and the power level has to be increased.
In each case the quality is assessed first, followed by the estimated receive level. Figure 9-10
illustrates the phase 4 threshold comparison.
9-22 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Phase 4 threshold comparisons
Figure 9-10 Phase 4 threshold comparisons
Threshold level 3 quality level
The threshold for quality, threshold 3; is hard coded at a value of 2. The scale used corresponds
to the GSM rxqual quality scale, which is split into 7 bands from 0.14% to 8.10%. See
Figure 9-10.
If the resultant quality level falls fall below 3, it is deemed to low to apply any power reduction
or higher coding scheme. In this case the output power of the BTS would be set to the maximum
power of the carrier and the coding scheme would remain at CS1.
Threshold level 1 RXQUAL
There are two hard coded threshold levels used in the comparison of the estimated MS receive
level. The first, threshold 2; is set at 65 dBm. The second, threshold 1; is set at-85 dBm. The
scale used in the same rxlev scale used in GSM, ranging between 47 dBm to 110 dBm.
See Figure 9-10.
If the rxqual, when compared against threshold 3, is less than or equal to 2, the estimated
rxlev is then considered. If the rxlev is less than the hard coded threshold,-85 dBm, the level
is deemed to be to weak to apply any power reduction or higher coding scheme. In this case
the output power of the BTS would be set to the max power of the carrier and the coding
scheme would remain at CS1.
68P02901W36-S 9-23
Jul 2008
Phase 4 threshold comparisons Chapter 9: EGPRS and GPRS Power Control
However, if the estimated rxlev is greater than the hard coded threshold,-85 dBm, the quality
and level are considered good enough to apply power control and a different coding scheme.
To decide if it is just the power level, the coding scheme or both that needs to be changed,
we use threshold 2.
Threshold level 2 RXLEV
If RXQUAL is greater than Threshold_1 (RXQUAL > 2), signal quality is considered bad and BSS
output power is set to PBCCH and coding scheme is set to CS1.
If RXQUAL is less than or equal to Threshold_1 (RXQUAL < 2), the estimated signal level at the
MS is considered to compute BSS output power and coding scheme using following algorithm:
If RXLEV is below Threshold_2 (RXLEV <-73 dBm), the coding scheme is set to CS1 and
the BSS output power is set to PBCCH. The following expression is used to compute PBSS
P BSS = PL BCCH
the BSS output power is decreased so that the estimated signal level at the MS equals
Threshold_2 (-73 dBm). The expression used to compute PBSS is the following:
P BSS = Thr eshold2 + PL DL
If RXLEV is above Threshold_4 (RXLEV >-20 dBm), the coding scheme is set to CS4 and
Threshold_3 and Threshold_4 are kept very high because in phase 4, the PCU wants to avoid
using CS3 or CS4. Thresholds are true at present and could be changed to different values if
any optimization is required.
BCCH/Non BCCH
If the GPRS timeslots are equipped on the BCCH carrier, the rxlev thresholds will have no
effect, as the BCCH carrier is required to transmit on full power at all times. If the timeslots
are equipped on a non-BCCH carrier they will have an effect.
9-24 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Phase 5 closed loop power control
Phase 5 closed loop power control
Phase 4 of downlink power control will continue to be used until the MS transmits its first
packet downlink Ack/Nack message to the Network. At this point Phase 5 of downlink power
control will begin.
NOTE
Within phase 5, which is a closed loop system, power control and coding scheme
selection are handled separately.
Metrics
The metrics used with phase 5 are derived from the packet downlink Ack/Nack message,
they are:
MS reported C value-CMS.
MS reported receive quality-rxqual.
MS reported Received Block Bitmap (RRB).
The BTS will then use these metrics to ascertain the BTS output power.
Power output
The BTS will perform two calculations, one relating to Block Error Rate (BLER), the other
relating to level and quality. Once the value has been obtained they will be used in the following
formula to determine the BTS power level:
PBSS = MAX (PCvalue PBLER)
where,
PBSS is the selected BTS output power level.
PCvalue is the BTS power output level calculated from reported signal level and quality.
PBLER is the BTS power output level calculated from the BLER.
68P02901W36-S 9-25
Jul 2008
Phase 5 closed loop power control Chapter 9: EGPRS and GPRS Power Control
Phase 5 PCvalue
The BTS will calculate its required output power level relative to the reported signal level and
quality from the MS. The reported signal level, C, is of course measured on the BCCH, not a
PDTCH. To account for this, the level is adjusted using the formula:
CMSadjusted = CMS (PBCCH PBSS [n1])
where,
CMS is the mobile reported received level on BCCH, in the latest Packet Downlink Ack/Nack
message sent by the MS.
PBCCH is the output power of the BCCH carrier.
PBSS[n-1] is the BSS output power level used on an individual PDTCH.
The resultant of this formula will be updated following the reception at the BTS of a packet
downlink Ack/Nack message.
Figure 9-11 illustrates the Phase 5 PCvalue calculation.
Figure 9-11 Phase 5 PCvalue calculation
9-26 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Phase 5 threshold comparisons
Phase 5 threshold comparisons
Once the reported signal level has been adjusted, it is compared, along with the reported quality
against a number of hard coded thresholds. The aim is to keep the reported signal level and
quality inside the power window of the MS, which is defined by the use of hard coded thresholds.
This comparison is made by the BTS in terms of:

RXQUAL
RXLEV
RXQUAL thresholds
There are two thresholds for quality, threshold 6 and 7. Threshold 6 is hard coded at a value of
0, while threshold 7 is hard coded at a value of 5. The scale used corresponds to the GSM rxqual
quality scale, which is split into 7 bands from 0.14% 18.10%.
RXLEV thresholds
There are two hard coded thresholds used for the modified reported receive level. The first,
threshold 5; is set at 65 dBm. The second, threshold 4; is set at 85 dBm. The scale used in
the same rxlev scale used in GSM, ranging between 47 dBm to 110 dBm.
Phase 5 threshold comparison decisions
The reported received signal quality in the packet control Ack message is compared to the
thresholds shown in Figure 9-11. Depending on whether these values are greater or less than
the given threshold the BSS will be required to either increase or decrease power.
Decision 1
The reported received signal quality in the packet downlink Ack/Nack message is compared
against Threshold 7, hard coded at a value of 5. If the value is greater than the threshold, the
BSS needs to increase the power.
Decision 2
If the reported received signal quality in the downlink Ack/Nack message is between Threshold
6, hard coded at a value of 0 and Threshold 7, hard coded at a value of 5, the reported received
signal level is considered. If it is less than Threshold 4, hard coded at 85 dBm, the BSS needs
to increase the power.
Decision 3
6, hard coded at a value of 0 and Threshold 7, hard coded at a value of 5, the reported received
signal level is considered. If it is above Threshold 5, hard coded at 65 dBm, the BSS output
power can be decreased.
68P02901W36-S 9-27
Jul 2008
Phase 5 threshold comparison decisions Chapter 9: EGPRS and GPRS Power Control
Decision 4
6, hard coded at a value of 0 and Threshold 7, hard coded at a value of 5 and the reported
received signal level is between Threshold 4, hard coded at a value of-85 dBm and Threshold
5, hard coded at a value of-65 dBm, the reported signal level and quality is within the power
box and so the BSS output power is left as it is. The results of these calculations are known as
the PCvalue and will be used in the final decision process. Also, any change in power levels must
take into account the mode in use, A or B. Changes in power levels will occur as increments of
4dB and decrements of 2dB.
Figure 9-12 further illustrates the phase 5 threshold comparison and decisions.
Figure 9-12 Phase 5 threshold comparisons and decisions
9-28 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Phase 5 PBLER
Phase 5 PBLER
Block Error Rate (BLER) is calculated as the moving average of the ratio of bad blocks versus
the total blocks. BLER is based on a history of the x number of blocks. x can be any number
but is a minimum of 32 blocks and maximum of 128 blocks and is more practically set to one
hundred or more. A BLER bitmap of 128 bits is shown in Figure 9-13.
Figure 9-13 BLER bitmap
PBLER thresholds and decisions
Once the BLER has been calculated, it is compared against a set of hard coded thresholds to
decide if the BTS power needs to be incremented or decremented. The thresholds are:
Threshold 10-BLER of 0.12
Decision 1
If the BLER value is greater than threshold 10, the BLER is considered to be excessive and so
the BTS will be incremented by 6 dB.
Decision 2
If the BLER value is less than threshold 10, but greater than Threshold 9, the BLER is considered
to be still highly excessive and so the BTS will be incremented by 2 dB.
Decision 3
If the BLER value is less than threshold 9, but greater than Threshold 8, the BLER is considered
to be acceptable and so the BTS power will not be changed.
Decision 4
If the BLER value is less than threshold 8, the BLER is considered to be very low and so the
BTS will be decremented by 2 dB.
The results of this calculation is known as the PBLER and will be used in the final decision process.
Also, any change in power levels must take into account the mode in use, A or B.
Figure 9-14 illustrates the PBLER threshold decisions.
68P02901W36-S 9-29
Jul 2008
Phase 5 algorithm selection Chapter 9: EGPRS and GPRS Power Control
Figure 9-14 PBLER threshold decisions
Phase 5 algorithm selection
Following the calculation of PCvalue and PBLER the final stage in the calculation is to decide which
result to use. This is determined by using the formula:
PBSS = MAX (PCvalue PBLER)
Once decided, the output power of the BTS for a particular MS is set to the value of PBSS.
9-30 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Phase 5 algorithm selection
Downlink signaling
The phase 5 downlink power control algorithms, are executed upon receipt of a packet downlink
Ack/Nack message. This is of course initiated when the network sends the MS a data block with
a data bit set. It is normal to expect the polling bits to be set at a rate of 2-12 blocks.
Figure 9-15 illustrates the phase 5 algorithm selection.
Figure 9-15 Phase 5 algorithm selection
68P02901W36-S 9-31
Jul 2008
GPRS coding scheme selection Chapter 9: EGPRS and GPRS Power Control
GPRS coding scheme selection

Coding scheme selection methods
The initial coding scheme selection for a downlink data transfer is performed in phase 4 path
loss calculations where the estimated received signal level at the MS is compared with
Threshold_1, Threshold_2, Threshold_12 and Threshold_13 and the RXQUAL is compared with
Threshold_3. This occurs after receiving the first Packet Control Ack message. Downlink
data blocks sent before receiving this first Packet Control Ack message are transmitted
using CS2. With respect to the transmission of downlink signaling blocks, they are always
transmitted using CS1.
Downlink coding decisions
The following factors are considered in determining the coding scheme in phase five:
BLER.
Missing Downlink Acknowledgments (DAK).
Rlc_mac stalls.
(Pif-Penalty)-Failed past DL TBFs or previous unsuccessful channel coding scheme

selections.
Score
An equation has been established to determine a score based on all the four factors. Score
is an indicator of how bad the current coding scheme performs. A high score means poor
performance. Based on the score, coding scheme can be promoted or demoted or continued.
Score = a.BLER = b.missDAKP enalty + c.stallP enalty + d.pif P enalty
where,
BLER is the contribution due to block errors detected over the air interface.
missDakPenalty is the contribution whenever a Downlink acknowledgment is detected as

having been missed.
stallPenalty is the contribution whenever a Stall is encountered on the RLC/MAC layer due to
unreceived/missed outstanding blocks.
pifPenalty is the contribution due to a demotion from a higher coding scheme to a lower coding
scheme when it is detected that an inefficient coding scheme decision was made.
a, b, c, d are the coefficients used to weight the individual terms according to importance and to
scale the score appropriately for the lookup table. Currently they are set to 1.
9-32 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Downlink coding decisions
the total blocks. BLER is based on a history of the x number of blocks. x can be any number
but is a minimum of 32 blocks and maximum of 128 blocks and is more practically set to one
hundred or more. A BLER bitmap of 128 bits is shown in Figure 9-16.
Figure 9-16 BLER bitmap
When the conditions are bad for the current coding scheme, the bad blocks to total blocks ratio
is high and hence increases the BLER value. If the conditions are good for the current coding
scheme, there will be fewer bad blocks and thus a lower value of BLER. BLER is used as a
percentage value in above score equation.
missedDakPenalty
When the PCU detects that a DAK has been missed, the value of missedDAkPenalty is
incremented by a predetermined value. Care must be taken, however so as not to penalize
this parameter if the DAK was missed due to a pending poll block of a coding scheme higher
than the current coding scheme following a coding scheme downgrade. A linear decay over
time is used to devalue the missedDAkPenalty. It is decremented by a predefined value after a
DAK is received successfully.
stallPenalty
When the PCU detects that the RLC/MAC protocol has stalled due to the sliding window not
moving, the value of stallPenalty is incremented by a predetermined value. As in the case of
missed DAKs, this parameter is not penalized for stalls caused due to higher coding scheme
blocks following a coding scheme downgrade. A linear decay over time is used to devalue the
stallPenalty. It is decremented by a predefined value after a DAK is received successfully and
the RLC window has started moving.
pifPenalty
Whenever there is a downgrade from a higher coding scheme to a lower coding scheme,
stallPenalty is penalized and reset to X, a value that contributes to the score preventing the
PCU from hastily promoting the mobile station again to a higher coding scheme. As the RF
conditions become good and suit the current coding scheme, stallPenalty is forgiven and
decayed by a magnitude known as the decayMagnitude at every successful DAK. The total time
to deplete stallPenalty, known as depletionTime, is determined based on the number of times the
coding scheme is downgraded to a lower coding scheme. When there is a downgrade from one
coding scheme to a lower coding scheme for the first time, (as shown in Figure 11 Point 1) the
depletionTime is set to 8 Round Trip Delays (RTD), which is approximately equal to 48 block
periods. The formula can be written as follows:
Detection and Demotion duration (depletionTime) = 8 RTD = 48 block periods.
Total time to decay PIF to 0 (depletionTime) = (X / decayMagnitude) * decayTime.
68P02901W36-S 9-33
Jul 2008
Downlink coding decisions Chapter 9: EGPRS and GPRS Power Control
The decayTime is determined from the above equation and pifPenalty is decayed by the
decayMagnitude on every DAK received. Thus, this decay is done only if the current block
number is greater than or equal to the block number determined by the decayTime. Figure 9-17
shows the pifPenalty degradation over time.
The second time there is a downgrade, as shown in Figure 9-17 Point 2, pifPenalty is reset to
X. But this time, the depletionTime is incremented by two times. Hence the depletionTime is
now 16 RTD or approximately 128 blocks. This is done so as to penalize the system heavier
the second time so that it takes longer to get back to higher coding scheme. For example, if
there is a downgrade from CS4 to CS3, pifPenalty is reset to X and the depletionTime is 4 RTDs.
Then, if there is a second consecutive downgrade from CS3 to CS2, pifPenalty is reset to X
again; but now, the depletionTime is 8 RTDs.
Figure 9-17 pifPenalty degradation over time
Once score is calculated the coding scheme is selected according to Figure 9-18.
9-34 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Downlink coding decisions
Figure 9-18 DL Phase 5 Score based CS selection/UL BLER based CS selection
1 1 1 1
... 1 1 1 1
... 1 1 1 1
... 1 1 1 1
1 1 1 1
1 1 1 2
... 1 1 1 2
...
1 1 1 2
...
1 1 1 2
1 1 1 2
1 1 2 3
... 1 1 2 3
... 1 1 2 3
... 1 1 2 3
1 1 2 3
1 2 2 4
... 1 2 2 4
... 1 2 2 4
... 1 2 2 4
1 2 2 4
1 2 3 4
... 1 2 3 4
... 1 2 3 4
... 1 2 3 4
3 1 2 3 4
2 2 3 4 4
1 2 3 4 4
0 2 3 4 4
68P02901W36-S 9-35
Jul 2008
Uplink coding scheme selection and decisions Chapter 9: EGPRS and GPRS Power Control
Uplink coding scheme selection and decisions
The coding scheme used in the uplink direction will be determined by the following factors:
C/I
Uplink BLER
Uplink BLER
The PCU will keep track of the current BLER for every TBF. This BLER will be the percentage of
bad blocks in the current TBF. An uplink bad block will be defined as follows:
The UL_Date bit is set in the command array.
A control Ack message is not expected on that block number.
The bad block does not have a frame type of CS1, CS2, CS3, CS4 or it has a crc_error.
Idle blocks will not be counted as part of the rate, so they will not be included in the array. The
PCU will keep a history of the last 128 blocks, with a configurable window size of current data
that will be used to calculate a rolling average. This window size will default to 20 blocks,
but can be changed by a msg_send. To implement this variable window size, we will keep a
front_window_index into this bitmap. In Figure 9-19 given below Example Array, window_size =
50, BLER = 8%.
Figure 9-19 Example array window size
0 1 2 3 ... 24 25 26 ... 50 51 52 53 54 55 56 57 58 ... 100
G G B G G B B G G G B B G B G G G G G B
Front_window_index
Window_size=50
G = Good block
B = Bad block
Bad_block_count=4
ti-GS M-Arra y window s ize -00321-a i-s w
When the PCU starts a new TBF, there will not be enough data initially to fill the window_size.
The PCU will not compute BLER until it receives or missed at least a window size worth of
UL data blocks.
9-36 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Uplink coding scheme selection and decisions
The following steps will be taken whenever an Uplink data block is expected.
1. Insert current block being processed by shifting to the right. The bitmap is 128 bits long.
0's in the bitmap represent bad blocks and 1's represent good blocks.
2. Increment front_window_index if front_window_index is <128.
BLER is calculated as follows:
N umberof badblocks
U plinkBLER =
W indowsize
Whenever the PCU sends a PUA/PTR/PUAK to the mobile a new BLER will be calculated and a
coding scheme appropriate to the BLER and C/I is determined. The coding scheme from BLER
is chosen from Figure 9-18 and the coding scheme from C/I is chosen from Figure 9-20. The
lower value of the two will be used for Uplink data transmission.
Figure 9-20 Uplink C/I based coding scheme selection
{23292}
NOTE
The PCU supports extended RLC window size of 192 for EGPRS UL TBFs that are
assigned one to four timeslots in the uplink. This is done to prevent stalling and
achieve optimum throughput performance of all supported classes of mobiles.
68P02901W36-S 9-37
Jul 2008
EGPRS power control Chapter 9: EGPRS and GPRS Power Control
EGPRS power control

Power control
The link quality control for EGPRS is slightly more complex than GPRS with the addition of the
new coding schemes and incremental redundancy. The existing link adaptation algorithms are
extended to support the addition of the modulated coding schemes and code combining.
Additionally, the existing downlink power control algorithms are applied to the EGPRS mobiles
as well. The CTU2 radio has a limitation on the maximum power level that it can transmit when
configured as an EGPRS carrier. The CTU2 can operate in a normal power or high-power
mode while doing 8PSK. The specifications allow the top power step for 8PSK to be different
than GMSK. However, at the next step lower in 8PSK mode, the GMSK power level must be
the same as 8PSK. If the max_tx_bts at the cell is greater than 2 then the 8PSK and GMSK
power are output at the same level.
The BSS software and Horizon II firmware allow each CTU2 to be able to rapidly switch between
Double Density modulation and Single Density modulation to support EGPRS on DD CTU2. The
power output is not affected, thus allowing the EGPRS PDTCH to be configured on Carrier A of
DD CTU2 while the corresponding timeslots on the paired Carrier B are OOS.
At a site with ALL CTU2s, configuring operation in High Power Mode or Normal Power Mode
is performed by the operator. The output power of the CTU2 radios will not be artificially
lowered through software or database.
During the uplink, the network disregards the MS power capability and if the network requests
the MS to transfer at a power higher than its capability, the MS uses the supported power level
which is closest to the calculated output power. (3GPP 5.08, sec 10.2.2).
9-38 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation EGPRS uplink power control
EGPRS uplink power control

EGPRS uplink power control does not differ from GPRS uplink power control.
68P02901W36-S 9-39
Jul 2008
EGPRS downlink power control Chapter 9: EGPRS and GPRS Power Control
EGPRS downlink power control

Downlink power control is used by the network to keep the BTS transmit power level to a
minimum. This allows a distant MS to obtain the usable signal at the lowest power level, whilst
using the best coding scheme to afford it the best throughput. In addition, this will have
the advantage of reducing interference with neighbor cells in the event of a tight frequency
reuse pattern.
Unlike uplink power control, downlink power control is split into five phases. The phase depends
on what transfer state the MS is currently engaged in. Additionally, the power control applied at
each phase will be calculated using differing methods. Once the power level has been decided it
will remain in force for all radio blocks that make up a burst. But while phase 4 sees the MCS
chosen in conjunction with power control, phase 5 sees them chosen independently of each other.
The five phases of downlink power control are:

Phase 1. Start condition uses BCCH or PBCCH power level.
Phase 2. Immediate assignment downlink uses BCCH or PBCCH power level.
Phase 3. Packet downlink assignment uses BCCH or PBCCH power level.
Phase 4. Packet control ack uses reciprocal path loss.
Phase 5. Packet downlink ack/nack uses closed loop power control.
Phases 1, 2 and 3
Phases 1, 2 and 3 always use the power level set by the BCCH or PBCCH. The power level
cannot change until the MS has made contact with the Network, which occurs when the MS
sends a packet control ack message. The coding scheme used for this stage is MCS1.
Phase 1
Phase 1 of downlink power control is considered as the start condition and will actually consist
of the BSS transmitting at the determined BCCH or PBCCH power level.
Phase 2
Phase 2 of downlink power control begins when the BSS transmits, at the BCCH or PBCCH
power level, the immediate assignment message to the MS.
Phase 3
Phase 3 of downlink power control begins when the BSS transmits: at BCCH or PBCCH level the
packet downlink assignment message to the MS.
9-40 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Phase 4
Phase 4
At this point, the network is able to measure the RXLEV and NPRACH of the power control ACK
message to determine the requirements of the MS and so begins to use Phase 4, which is based
upon a reciprocal path loss calculation. The modulation coding scheme directly relates to the
chosen power level as derived from a look up table.
EGPRS phase 4 metrics
Upon receipt of the packet control ack message from the EGPRS MS, the BSS can begin phase 4
of downlink power control, the principle mechanism of which is reciprocal path loss.
To perform this calculation, the BSS evaluates the packet control ack message in terms of:
rxlev
nprach
Path loss calculation
The path loss is first calculated for the uplink. This is followed by an estimation of the downlink
path loss, before an estimation of the received signal strength at the EGPRS MS is performed.
Uplink path loss is calculated as the EGPRS MS transmit power level (PMAX) of the packet
control ack message minus the received power level at the BSS. If a PBCCH or PCCCH has not
been equipped in the cell then ms_txpwr_max_cch would be used in the following calculation.
est.ul.pathloss = gprs.ms.txpwr.max.cch rexlev
Downlink path loss is estimated as the uplink path loss plus an adjustment to account for extra
losses on the uplink, due to signal level fading.
est.dl.path.loss = est.ul.pathloss + ul.to.dl.cvrt.adjustment
The margin is set at 3 dB.
Finally, an estimation of the receive level of the MS is calculated, as if the BTS were to transmit
at maximum power. This is carried out as follows:
Rx
ms= max.tx.bts est.dl.pathloss
Where:
Rxms is the estimated receive level of the MS.
max.tx.bts is the maximum power of the BTS.
est.dl.pathloss is the estimated down link path loss.
68P02901W36-S 9-41
Jul 2008
Phase 4 Chapter 9: EGPRS and GPRS Power Control
NPRACH
NPRACH is the number of PRACH bursts in the EGPRS packet control ACK message that have
been successfully decoded (there can be a maximum of four bursts in this message).
EGPRS phase 4 power control and MCS selection
Unlike GPRS Phase 4, there is no power reduction for EGPRS Phase 4 Power control. This
means that the BTS will continue to transmit at the power level of the BCCH or PBCCH even
though the EGPRS MS is on a PDTCH and can well be on a non BCCH carrier. Unfortunately
this is a very coarse estimation of the TRAU channel conditions, as rxlev does not give indication
of carrier or interference ratio, while NPRACH is not an indication of the receiver performance.
Only Modulation Coding Schemes 1-4 can be used for EGPRS Phase 4 Power control. When
selecting the Modulation Coding Scheme to be used in EGPRS Phase 4, the system will select a
value based upon the look up table shown in Table 9-2. The Rx level is scaled from 0-127 dbm. If
any of the bursts within the EGPRS Packet Control message are unsuccessfully decoded, the
modulation coding scheme will default to 1.
Table 9-2 EGPRS Phase 4 look up table
RXLEV NPRACH RXLEV NPRACH RXLEV NPRACH

0 1 2 3 4 0 1 2 3 4 0 1 2 3 4
0 1 1 1 1 1 43 1 1 1 1 2 86 1 1 1 1 2
1 1 1 1 1 1 44 1 1 1 1 2 87 1 1 1 1 2
2 1 1 1 1 1 45 1 1 1 1 2 88 1 1 1 1 2
3 1 1 1 1 1 46 1 1 1 1 2 89 1 1 1 1 2
4 1 1 1 1 1 47 1 1 1 1 2 90 1 1 1 1 2
5 1 1 1 1 1 48 1 1 1 1 2 91 1 1 1 1 2
6 1 1 1 1 1 49 1 1 1 1 2 92 1 1 1 1 2
7 1 1 1 1 1 50 1 1 1 1 2 93 1 1 1 1 2
8 1 1 1 1 1 51 1 1 1 1 2 94 1 1 1 1 2
9 1 1 1 1 1 52 1 1 1 1 2 95 1 1 1 1 2
10 1 1 1 1 1 53 1 1 1 1 2 96 1 1 1 1 2
11 1 1 1 1 1 54 1 1 1 1 2 97 1 1 1 1 2
12 1 1 1 1 1 55 1 1 1 1 2 98 1 1 1 1 2
13 1 1 1 1 1 56 1 1 1 1 2 99 1 1 1 1 2
14 1 1 1 1 1 57 1 1 1 1 2 100 1 1 1 1 2
15 1 1 1 1 1 58 1 1 1 1 2 101 1 1 1 1 2
16 1 1 1 1 1 59 1 1 1 1 2 102 1 1 1 1 2
17 1 1 1 1 1 60 1 1 1 1 2 103 1 1 1 1 2
18 1 1 1 1 1 61 1 1 1 1 2 104 1 1 1 1 2
19 1 1 1 1 1 62 1 1 1 1 2 105 1 1 1 1 2
Continued
9-42 68P02901W36-S
Jul 2008
Table 9-2 EGPRS Phase 4 look up table (Continued)

RXLEV NPRACH RXLEV NPRACH RXLEV NPRACH
20 1 1 1 1 1 63 1 1 1 1 2 106 1 1 1 1 3
21 1 1 1 1 1 64 1 1 1 1 2 107 1 1 1 1 3
22 1 1 1 1 1 65 1 1 1 1 2 108 1 1 1 1 3
23 1 1 1 1 1 66 1 1 1 1 2 109 1 1 1 1 3
24 1 1 1 1 1 67 1 1 1 1 2 110 1 1 1 1 3
25 1 1 1 1 1 68 1 1 1 1 2 111 1 1 1 1 3
26 1 1 1 1 1 69 1 1 1 1 2 112 1 1 1 1 3
27 1 1 1 1 1 70 1 1 1 1 2 113 1 1 1 1 3
28 1 1 1 1 1 71 1 1 1 1 2 114 1 1 1 1 3
29 1 1 1 1 1 72 1 1 1 1 2 115 1 1 1 1 3
30 1 1 1 1 1 73 1 1 1 1 2 116 1 1 1 1 3
31 1 1 1 1 1 74 1 1 1 1 2 117 1 1 1 1 3
32 1 1 1 1 1 75 1 1 1 1 2 118 1 1 1 1 3
33 1 1 1 1 1 76 1 1 1 1 2 119 1 1 1 1 3
34 1 1 1 1 1 77 1 1 1 1 2 120 1 1 1 1 3
35 1 1 1 1 1 78 1 1 1 1 2 121 1 1 1 1 3
36 1 1 1 1 1 79 1 1 1 1 2 122 1 1 1 1 3
37 1 1 1 1 1 80 1 1 1 1 2 123 1 1 1 1 3
38 1 1 1 1 1 81 1 1 1 1 2 124 1 1 1 1 3
39 1 1 1 1 1 82 1 1 1 1 2 125 1 1 1 1 3
40 1 1 1 1 1 83 1 1 1 1 2 126 1 1 1 1 3
41 1 1 1 1 1 84 1 1 1 1 2 127 1 1 1 1 3
42 1 1 1 1 1 85 1 1 1 1 2
Phase 5
When the EGPRS MS has sent a channel quality report during its first packet downlink ack/nack
message to the network, the normalized C value and BEP measurements are used, together with
the BLER estimates from the RLC bitmaps, as an input for closed loop power control algorithms,
phase 5. The modulation coding scheme is determined from the EGPRS score formula and a
look up table for GMSK or 8PSK.
Power output
The BSS will perform three calculations, one relating to Block Error Rate (BLER), one relating
to BEP estimates and the other relating to signal level. Once these values have been obtained,
the largest of the three is chosen as the BTS output power level.
68P02901W36-S 9-43
Jul 2008
Phase 5 Chapter 9: EGPRS and GPRS Power Control
EGPRS phase 5 metrics
The metrics used with phase 5 are derived from the EGPRS packet downlink ack/nack message.
These are:
MS reported C value.
MS reported Received Block Bitmap (RRB).
MS reported stall indication.
MS reported BEP estimates.
The BSS uses these metrics to calculate the BTS output power.
Power output
The BSSl performs three calculations, one relating to Block Error Rate (BLER), one relating to
BEP estimates and the other relating to signal level. Once these values have been obtained,
they will be used in the formula below to determine the BTS power level.
P
BSS = M AX (Cvalue , BLERvalue , SI, BEPvalue )
Where:
PBSS is the selected BTS output power.
Cvalue is the BTS power output level calculated from reported signal level.
BLERvalue is the BTS power output level calculated from the RBB.
SI is the RLC or MAC stall indicator.
BEPvalue is the BTS power output as calculated from the BEP measurements.
EGPRS phase 5 Cvalue
The BSS will calculate its required output power level relative to the reported signal level and
quality from the EGPRS MS. The reported signal level, CMS,BCCH, is measured on the BCCH, not a
PDTCH and to account for this, the level is adjusted using the formula:

CM S,P DCH = CM S,BCCH PBCCH PBSS[n1]
Where:
CM S,P DCH is the mobile reported received level on BCCH, in the latest EGPRS Packet Downlink
Ack/Nack message sent by the MS.
PBCCH is the output power of the BCCH carrier.
PBSS[n1] is the BSS output power level used on an individual PDTCH.
The result of this formula is updated following the reception at the BTS of a GPRS packet
downlink ack/nack message.
9-44 68P02901W36-S
Jul 2008
EGPRS phase 5 BLER
the total blocks. BLER is based on a history of x number of blocks. x can be any number but is a
minimum of 32 blocks and maximum of 128 blocks. It is more practical to set x to a value of one
hundred or more to allow for greater accuracy. A BLER bitmap of 128 bits is shown below.
00000001100000111111100000111111. 00001111111111100000001111101010.
00000000000000001111111111111111. 11111111111111111111111111111111.
1 = good block, 0 = bad block
Once the BLER has been calculated, it is compared against a set of hard coded thresholds to
decide if the BTS power needs to be incremented or decremented.
The thresholds, which are the same as used in the GPRS phase 5 PBLER calculation, are listed
below:
Threshold 10 BLER of 0.12.

If... Then...
the BLER value is greater than the BLER is considered to be excessive and so the
Threshold 10 BTS power will be incremented by 6 dB.
the BLER value is less than the BLER is considered to be still highly excessive
Threshold 10, but greater than and so the BTS power will be incremented by 2 dB.
Threshold 9
the BLER value is less than the BLER is considered to be acceptable and so the
Threshold 9, but greater than BTS power will not be changed.
Threshold 8
the BLER value is less than the BLER is considered to be very low and so the
Threshold 8 BTS power will be decremented by 2 dB.
The result of these calculations is known as the BLER value and will be used in the final decision
process. It will also take into account the stall indication value.
EGPRS BEP value
The reported Mean_BEP and CV_BEP will be averaged out using a weighting factor. This will
either be bep_period sent to all EGPRS MS or bep_period2 sent to individual EGPS MS. It will
be only Mean _BEP that will be used in the EGPRS Phase 5 calculation.
Once calculated Mean _BEP will be compared against a number of preset system thresholds.
This threshold consists of an upper and lower level for each modulation coding scheme and are
known as BEP_TRGT_UL_MCSx and BEP_TRGT_LL_MCSx.
If Mean_BEP BEP_TRGT_UL_MCSx power is decremented by 2 dB.
If Mean_BEP BEP_TRGT_LL_MCSx power is incremented by 4 dB.
If Mean_BEP BEP_TRGT_LL_MCSx and BEP_TRGT_UL_MCSx power is not adjusted.
68P02901W36-S 9-45
Jul 2008
EGPRS coding scheme selection Chapter 9: EGPRS and GPRS Power Control
EGPRS coding scheme selection

The method of choosing the modulation coding scheme dynamically, is closely allied to the
method used in Power Control. Indeed, it is possible to improve the quality of the signal by
increasing/decreasing power levels without changing modulation coding schemes. Uplink and
downlink coding schemes are selected separately, but use the same methods of selection.
{30830} In ASYM mode, CTU2D Carrier B is restricted to GMSK coding schemes in the UL.
Therefore, the 8PSK coding schemes MCS 5-9 will not be selected for that carrier in the UL.
Initial coding scheme selection
As with GPRS, the operator is able to set the initial modulation coding scheme for use with
EGPRS. This can be done for both uplink and downlink, using the parameters egprs_init_dl_cs
and egprs_init_ul_cs. {30830} In ASYM mode, egprs_init_ul_cs is internally limited to a
maximum of MCS3 when considering CTU2D Carrier B.
TLLI block coding
The TLLI identifies the logical link from the subscriber to the SGSN and is used for contention
resolution, which is of particular importance when using the one-phase Access procedure. The
operator is able to command the MS to use MCS-1 to transmit blocks during the contention
resolution phase. By using MCS-1 there is a high probability that the uplink TBF will be
established successfully. This is achieved by using the database parameter tlli_blk_coding
which is also used for GPRS TTLI Block Coding.
EGPRS downlink modulation coding scheme selection
EGPRS Downlink modulation coding scheme selection is based upon a number of factors:
Mean_BEP
CV_BEP
Missing EGPRS downlink acknowledgments.
RLC_MAC stalls
PifPenalty
{30830} Mean_BEP and CV_BEP result in a preliminary selection of a modulation coding
scheme against the look up tables shown in Table 9-4, Table 9-5, Table 9-6, Table 9-7, Table 9-8,
and Table 9-9. This preliminary selection is then modified using the EGPRS score equation,
which takes into account the other factors listed above.
CTU2Ds 8PSK output power is 10 W in Capacity and ASYM modes while the GMSK output power
is 20 W. This output power differential in GMSK and 8PSK impacts the coding scheme selection
algorithms. The PCU uses Downlink_8PSK_Power_Backoff (power difference between GMSK
and 8PSK) along with the configured max_tx_bts to calculate the 8PSK Power Differential.
9-46 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation EGPRS downlink modulation coding scheme selection
8PSK Power Differential = Downlink_8PSK_Power_Backoff - (2*max_tx_bts)
Based on the 8PSK Power Differential, the appropriate coding scheme selection tables are
selected as shown in Table 9-3.
Table 9-3 Selecting coding scheme selection table
8PSK Power Differential Coding scheme selection table

<= 1.5 Existing DL CS selection tables
> 1.6 and < 3.6 New set of DL CS Selection tables
> = 3.7 Existing DL CS selection tables
68P02901W36-S 9-47
Jul 2008
EGPRS downlink modulation coding scheme selection Chapter 9: EGPRS and GPRS Power Control
Table 9-4 EGPRS MCS selection based on 8PSK reports (for 8PSK Power Differential
of 1.5dB or lesser)
8PSK
CV_BEP/8PSK 0 1 2 3 4 5 6 7
Mean_BEP
0 MCS-1 MCS-1 MCS-1 MCS-1 MCS-1 MCS-1 MCS-1 MCS-1
9-48 68P02901W36-S
Jul 2008
of 1.6 to 3.6dB)
8PSK
CV_BEP/8PSK 0 1 2 3 4 5 6 7
Mean_BEP
68P02901W36-S 9-49
Jul 2008
of 3.7dB or greater)
8PSK
CV_BEP/8PSK 0 1 2 3 4 5 6 7
Mean_BEP
9-50 68P02901W36-S
Jul 2008
Table 9-7 EGPRS MCS selection based upon GMSK reports (for 8PSK Power
Differential of 1.5dB or lesser)
GMSK
CV_BEP/GMSK 0 1 2 3 4 5 6 7
Mean_BEP
68P02901W36-S 9-51
Jul 2008
Differential of 1.6 to 3.6dB)
GMSK
CV_BEP/GMSK 0 1 2 3 4 5 6 7
Mean_BEP
9-52 68P02901W36-S
Jul 2008
Differential of 3.7dB or greater)
GMSK
CV_BEP/GMSK 0 1 2 3 4 5 6 7
Mean_BEP
68P02901W36-S 9-53
Jul 2008
EGPRS uplink modulation coding scheme selection Chapter 9: EGPRS and GPRS Power Control
EGPRS uplink modulation coding scheme selection
EGPRS uplink modulation coding scheme selection uses only the Mean_BEP and CV_BEP look
up tables as shown in Table 9-10.
9-54 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation EGPRS uplink modulation coding scheme selection
Table 9-10 EGPRS MCS selection based on GMSK reports (CTU2D Asymmetric mode)
GMSK
CV_BEP/GMSK 0 1 2 3 4 5 6 7
Mean_BEP
68P02901W36-S 9-55
Jul 2008
EGPRS uplink modulation coding scheme selection Chapter 9: EGPRS and GPRS Power Control
9-56 68P02901W36-S
Jul 2008
Chapter
10
Frequency Hopping

This chapter provides descriptions of both synthesizer and base band frequency hopping.
Frequency hopping on page 10-2.
68P02901W36-S 10-1
Jul 2008
Frequency hopping Chapter 10: Frequency Hopping
Frequency hopping

Purpose of frequency hopping
The frequency hopping feature can be unrestricted in a cell to help overcome the effect of
multi-path fading.
Frequency hopping can be implemented by two means:

Fast tune frequency hopping, also known as Synthesizer Frequency Hopping (SFH),
depends on the transceiver (radio) agility in changing frequency in both uplink and
downlink direction. The BCCH transceiver, therefore, can be used to support fast tune
frequency hopping, but cannot carry call traffic.
Base band frequency hopping (BBH) requires the BCCH transceiver to change frequency
on the uplink direction so the BCCH frequency can be used to support frequency hopping.
NOTE
The CTU2 supports synthesizer and baseband frequency hopping in dual carrier
mode, the following examples however show a (single carrier) CTU for simplicity.
Synthesizer Frequency Hopping (SFH)
SFH uses the frequency agility of the CTU to change Tx/Rx frequency on any timeslot (TS),
without affecting other timeslots.
SFH can only be used with wideband combining.
With SFH, each TS is allocated some frequencies (maximum of 64) over which hopping can be
performed. When determining the hardware requirement for CTUs using SFH, the following
rules apply:
A minimum of two CTUs are required per cell due to BCCH requirements. Timeslot 0 of
CTU 0 is used for the BCCH carrier as shown in Figure 10-1. CTU 0 cannot use SFH. Only
CTU 1 and additional CTUs can use SFH.
Hopping through the BCCH carrier (using the BCCH carrier frequency as one of the SFH
frequencies) is permitted except for timeslot 0. However, the corresponding timeslot for
the BCCH CTU switches off for this period.
Figure 10-1 shows the minimum SFH requirement.
10-2 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation SFH example not through BCCH
Figure 10-1 Minimum SFH requirement
SFH example not through BCCH
CTU 0
In this example of SFH, CTU 0 provides the BCCH and cannot frequency hop. CTU 0 has to
transmit at maximum cell site power to meet the BCCH requirement. Timeslots are used as
follow:
TS 0 = Combined BCCH TS (BCCH/CCCH/DCCH). Transmitted at maximum cell site power.
TS 1-7 = Traffic channels, all non-hopping. All traffic channels transmit at maximum
cell site power.
CTU 1 and additional CTUs
CTU 1 and any additional CTUs provide SFH traffic channels as follow::
TS 0-7 = Frequency hopping traffic channels. The frequency allocated to the BCCH of CTU 0
cannot be used for frequency hopping purposes.
68P02901W36-S 10-3
Jul 2008
SFH example hopping through BCCH carrier Chapter 10: Frequency Hopping
SFH example hopping through BCCH carrier
CTU 0
In this example of SFH, CTU 0 provides the BCCH and cannot frequency hop. CTU 0 has to
transmit at maximum cell site power to meet the BCCH requirement. Timeslots are used as
follow:
TS 0 = Combined BCCH timeslot (BCCH/CCCH/DCCH). Transmitted at maximum cell
site power.
TS 1-7 = Unused timeslots transmitting dummy bursts for BCCH. All channels transmit at
maximum cell site power.
CTU 1 and additional CTUs
CTU 1 and any additional CTUs provide SFH traffic channels as follow:
TS 0 = Frequency hopping traffic channel, but prevented from using BCCH frequency.
TS 1-7 = Frequency hopping traffic channels, using all available frequencies, including
BCCH.
When the SFH selects the BCCH frequency, the CTU transmits at maximum cell site power and
the corresponding TS on CTU 0 is switched off for this period.
Baseband Frequency Hopping (BBH)
BBH requires all eight timeslots of the CTU Tx (downlink) at the same frequency. In the Rx
(uplink) direction, the frequency agility of the CTU is used to change timeslot frequencies on a
timeslot basis. The BCCH frequency is always transmitted at maximum cell site power.
BBH can use either Tx blocks or CCB Tx combining equipment. The main reason for using BBH
instead of SFH is to enable frequency hopping when using CCBs, because the mechanical
tuning of CCBs is too slow for SFH.
The number of CTUs required to support BBH is equal to the number of frequencies used.
BBH is not supported on GSM 850 or PCS 1900 BTSs. In addition, DD CTU2s do not support
BBH when the controlling cabinets are Horizon macro and M-Cell, due to the switching
capability of the MCU/MCUF. The BTS restricts the BBH capabilities on DD CTU2 DRIs which of
Carrier A is EGPRS capable. The disp_hopp <cell_id> [active] command allows to view
the hopping information.
BBH example
In Figure 10-2 MSs A, B and C are using TS 5 of CTUs 0, 1 and 2, respectively.
10-4 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation BBH example
Figure 10-2 Diagram of BBH example using three CTUs
0 0 0
1 1 1
2 2 2
3 3 3
4 4 4
5 A 5 B 5 C
6 6 6
7 7 7
If the MSs are using cyclic hopping across ARFCNs 10, 20, 30 (an example using EGSM 900),
each MS must transmit a burst of information each TDMA frame (4.615 ms) on a different
frequency. Each CTU receives the data for the burst in turn (ARFCN 10, 20, 30), as shown in
Table 10-1.
Table 10-1 BBH sequence example (EGSM 900)
Burst Sequence Steps CTU 0 Tx Rx CTU 1 Tx Rx CTU 2 Tx Rx

1 A10 A10 B20 B20 C30 C30
2 C10 A20 A20 B30 B30 C10
3 B10 A30 C20 B10 A30 C20
4 (same as 1) A10 A10 B20 B20 C30 C30
5 (same as 2) C10 A20 A20 B30 B30 C10
6 (same as 3) B10 A30 C20 B10 A30 C20
In the uplink direction the controlling CTU (for example CTU 0 for MS A in Figure 10-2) tunes
TS 5 in accordance with the frequency expected from the MS for that particular burst.
Transmit
The transmit is described by the following, as shown in Figure 10-3:

1. Traffic data from the network is passed through the NIU to the MCUF. Within the MCUF, an
ASIC switches the data to CTU0 (the dedicated CTU for this particular MS call example).
2. The CTU after processing the data (channel coding, interleaving, encryption, and routing
information) passes the data back to the ASIC.
3. The ASIC follows the BBH routing information to direct the data to the next Tx CTU in the
sequence of Table 10-1.
68P02901W36-S 10-5
Jul 2008
Implementing BBH restriction for DDEGPRS Chapter 10: Frequency Hopping
NOTE
BBH differs from normal and SFH CTU Tx procedures, in that the data is
directed to CTUs in a cyclic sequence at stage 3. Without BBH, stage 3 always
routes data to the original CTU.
Figure 10-3 shows a schematic diagram of an example of base band hopping.
Figure 10-3 Schematic of BBH example
Tx cycles
through CTU
sequence NIU
ASIC
MCUF
3 3 1
3
CTU2 CTU1 CTU0
ig.297.rh
Receive
Data from the MS is received by one CTU allocated to that MS (in this case CTU0). The CTU
synthesizes hop to the Rx signal. This ensures that the handover and equalizers within only
one CTU are connected to a particular MS.
Implementing BBH restriction for DDEGPRS
Due to the interaction of ITS with BBH, the characteristic of BBH are restricted on EGPRS
enabled DD-CTU2 DRIs.
During cell initialization and pairing configuration
During cell initialization and pairing configuration, to implement BBH restriction for DD-EGPRS,
CRM and CA ensure RTFs mapped to DD CTU2 DRIs to conform to the Table 10-2.
10-6 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Implementing BBH restriction for DDEGPRS
Table 10-2 Initialization and pairing configuration
RTF of Carrier B
BBH Non BBH None (Idle)
Both Carrier A Carrier A is restricted Carrier A is restricted
64k and Carrier B are to non BBH. Carrier B to non BBH. Carrier B is
restricted to non retained as non BBH. restricted as non BBH
BBH. when later is assigned
RTF.
RTF Non No restrictions. No restrictions. No restrictions.
of 64k
Carrier
A Carrier B retains No restrictions. No restrictions.
None as BBH. Carrier A
(Idle) cannot be mapped
to EGPRS RTF
(Downgraded to
16k if RTF has
to be placed on
Carrier A.
NOTE
Once Carrier A is capable of EGPRS, Carrier B cannot come back to BBH by
locking/unlocking Carrier A.
When idle Carrier A is mapped to an RTF after initialization
When the idle Carrier A is mapped to an RTF after initialization, to implement BBH restriction
for DD-EGPRS, CRM ensures that RTFs mapped to DD CTU2 DRIs conform to Table 10-3.
Table 10-3 Mapping to idle Carrier A where Carrier B is already supported
RTF on Carrier B
BBH Non BBH None (Idle)
Carrier A is Carrier A is configured Carrier A is restricted
RTF 64k downgraded to support as EGPRS and non to non BBH. Carrier B
on 16k and non BBH. BBH. is restricted to non BBH
Carrier Carrier B is retained as when later is assigned an
A BBH. RTF.
Non No restrictions. No restrictions. No restrictions.
64k
68P02901W36-S 10-7
Jul 2008
Frequency hopping without site reset Chapter 10: Frequency Hopping
When idle Carrier B is mapped to an RTF after initialization
When idle Carrier B is mapped to an RTF after initialization, to implement BBH restriction for
DD-EGPRS, CRM ensures that RTFs mapped to DD CTU2 DRIs conform to Table 10-4.
Table 10-4 Mapping to idle Carrier B where Carrier A is already supported
RTF mapping transition on Carrier B

BBH Non BBH
64k Both Carrier A and Carrier B are No restrictions.
RTF restricted to non BBH.
on
Carrier Non No restrictions. No restrictions.
A 64k
None Carrier B is retained as BBH. No restrictions.
(Idle)
NOTE
Once Carrier A is capable of EGPRS, Carrier B cannot come back to BBH.

If at initialization 64k is mapped to Carrier A and Carrier B is set to non-BBH
(even configured as BBH in database), another 64k remapping to Carrier A leads
Carrier A to be downgraded to support 16k only.
Frequency hopping without site reset
This option enhances the operability of the existing frequency hopping feature.
The site will not be reset once the operator changes certain frequency hopping parameters.
The operator will be able to enable both synthesizer and baseband hopping at different
cells at the same site.
No site reset will occur when an FHI is enabled/disabled.
All the enhancements mentioned above relate to baseband hopping and normal synthesizer
hopping. For an FHI which is synthesizer through the BCCH hopping, restrictions still exist when
hopping parameters are changed or the FHI is enabled/disabled and a site reset can still occur.
10-8 68P02901W36-S
Jul 2008
Commands
The following commands are used with the listed parameters to specify the frequency hopping
functions:
chg_hop_params
Modifies the hopping support, to enable or disable the hopping systems. Changes the
HSN and the mobile allocation.
chg_rtf_freq
Modifies the ARFCN of a particular RTF.
Parameters
The following parameters can be set in the BSS database to specify the frequency hopping
functions, as described in the Technical Description: BSS Command Reference (68P02901W23)
manual:
hopping_support
Defines the frequency hopping in a cell (baseband or synthesizer hopping).
hop_qual_enabled
Provides an alternate quality threshold for handover of calls that are hopping.
hopping_systems_enabled
Sets a flag to enable or disable a frequency hopping system.
hopping_systems_hsn
Represents the frequency hopping system using the hopping sequence (generator) number
(HSN).
hopping_systems_mobile_alloc
Allocates the Absolute Radio Frequency Channel Number (ARFCN) frequencies for
hopping (either baseband or synthesizer).
The following parameters can be set as prompted by the equip RTF command, as described in
the Technical Description: BSS Command Reference (68P02901W23) manual:
FHI (Frequency Hopping Indicators)
Represents the frequency hopping system using the frequency hopping indicators (eight
per RTF).
MA (Mobile Allocation)
This is the list of frequencies that the hopping system is using to frequency hop over.
68P02901W36-S 10-9
Jul 2008
Adaptive Multi-Rate (AMR) frequency redefinition Chapter 10: Frequency Hopping
MAIO (Mobile Allocation Index Offset)
The MAIO for each carrier is the index of the carrier's ARFCN in the mobile allocation.
Although this cannot be directly set in the database, the setting of the Absolute Radio
Frequency Channel Number (ARFCN), in response to the equip RTF prompt, or by use of
the hopping_systems_mobile_alloc parameter, is used to set the Mobile Allocation Index
Offset (MAIO). This defines the channel from which the MS is to hop.
For example:
If the MA is 12 15 18 21, the MAIO will be set to 1 if 15 is set for the ARFCN in the RTF
(Enter 15 at the Enter carrier absolute radio freq. channel prompt in the equip RTF
command).
Hopping Support
This attribute indicates the type of hopping supported in this cell.
Adaptive Multi-Rate (AMR) frequency redefinition
When a Half-Rate (HR) call timeslot undergoes hopping reconfiguration, inform the MSs about
the change to the hopping system. The MS is informed of the change to the hopping system by a
mechanism called frequency redefinition. The introduction of half-rate into the BSS impacts the
frequency redefinition procedure in the following way.
If the hopping system on a half-rate timeslot supporting a single half-rate call is altered, the
half-rate call triggers the frequency redefinition procedure. In this case, the other channel
associated with the half-rate timeslot is idle and therefore performs hopping reconfiguration.
If the hopping system on an HR timeslot supporting two HR calls is altered. Both the calls
trigger the frequency redefinition procedure.
Pretransfer functionality
Inorder to minimize the audio hole when performing handovers the pretransfer functionality is
used. This functionality can only be used when both the source and the target channel of the
handover use the same speech codec. This means that the functionality cannot be applied to
calls which are assigned AMR, Full-Rate (FR) or HR, in either the source or the target channel.
The BSS does not apply the pretransfer functionality to handovers involving a call which is
assigned AMR full-rate or AMR half-rate in the source and/or target channel.
Call connectivity trace
The call connectivity trace is now supported on HR channels.
10-10 68P02901W36-S
Jul 2008
Chapter
11
BSS Inter-Radio Access Technology

Handover

This chapter provides a description of the Inter-Radio Access Technology that allows multi-RAT
MSs to hand over calls between GSM and UMTS radio systems.

BSS Inter-Radio access technology handover on page 11-2.
Enhanced 2G/3G handover and cell reselection on page 11-7.
{31400} TD-SCDMA and GSM interworking feature on page 11-15.
68P02901W36-S 11-1
Jul 2008
BSS Inter-Radio access technology handover Chapter 11: BSS Inter-Radio Access Technology Handover
BSS Inter-Radio access technology handover

GSM and UMTS handovers
The BSS Inter-Radio Access Technology (Inter-RAT) handover GSM function enables multi-RAT
MSs, that are capable of accessing the CN from both UMTS and GSM coverage areas, to hand
over calls between GSM and UMTS radio systems.
Motorola is implementing this function as two distinct release features. This section documents
the first of these features. BSS changes allow 2G (GSM) to 3G (UMTS) cell reselection in GSM
idle mode and 3G to 2G handovers in circuit-switched dedicated mode.
The BSS Inter-Radio Access Technology (Inter-RAT) handover GSM function is an option that
must be unrestricted by Motorola. It also requires unrestricting on site by the user with the
inter_rat_enabled parameter.
The second release feature, not yet implemented, contains BSS changes to allow 2G to 3G
handovers in circuit-switched dedicated mode. This feature is documented when it is released.
With the release of UMTS systems, there are likely to be small UMTS coverage areas within
larger GSM coverage areas. In such an environment, when a UMTS subscriber goes out of a
UMTS coverage area into a GSM coverage area, the call would drop. Congestion in the smaller
UMTS areas could become a problem when the traffic in the UMTS coverage area is high. A
GSM subscriber can wish to access a service with specific QoS characteristic (for example, high
bit rate data service) that cannot be supported in the GSM system. To avoid these problems the
operators can wish to configure their network such that hand over and cell reselection between
UMTS and GSM is possible. The GSM BSS Inter-RAT Handover function provides a solution to
these problems, by allowing a multi-RAT MS to perform cell reselection while in idle mode and
to hand over while in dedicated mode from a UMTS FDD mode cell to a GSM cell.
Effect on GSM
Aspects of the GSM BSS system affected by this function are:

Air interface.
ABIS interface.
A-interface.
BSS database.
System architecture.
11-2 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Effect on GSM
Air interface
The BSS Inter-Radio Access Technology (Inter-RAT) handover function introduces the system
information message: SYSTEM INFORMATION 2quater. The existing SI2ter, SI3, SI13, and
the HANDOVER COMMAND messages are updated to allow a multi-RAT MS to perform
measurements on UMTS Frequency Division Duplex (FDD) neighbor cells for the purpose of
cell reselection. The CLASSMARK UPDATE message is updated to support the MS revision
level (2) multi-RAT MS.
CCDSP firmware has been updated to store multiple instances of the SI2ter and SI2quater
messages.
Abis interface
The Abis Interface supports changes to the A-Interface required for messages passed from
the BSC to the BTS.
A interface
The HANDOVER REQUEST message sent from the MSC is updated with a new serving area
identifier within the cell identifier (serving). This indicates that the handover originates from a
UMTS network. This interface also provides support for the Information Interface Equipment
(IE) at the handing over BSS to that at the receiving BSS. This container can contain some User
Equipment (UE) specific IEs relating to the capabilities of the multi-RAT MS.
BSS database
The BSS database is updated to allow the provisioning of UTRAN cells to be specified as
neighbors of existing GSM cells. The database also supports the configuration of new
parameters associated with messaging to the multi-RAT MS.
68P02901W36-S 11-3
Jul 2008
System considerations Chapter 11: BSS Inter-Radio Access Technology Handover
System architecture
Figure 11-1 shows the system architecture for the GSM BSS Inter-RAT Handover feature.
Figure 11-1 GSM and UMTS system nodes and interfaces
System considerations
Existing 2G Core Network (CN) nodes must be able to interact with the 3G CN nodes through
MAP procedures defined on the E-interface between a 3G CN node and 2G CN node.
GSM BSS Inter-RAT Handover does not support:

Cell reselection to UTRAN TDD neighbor cells or CDMA2000 neighbor cells.
Dedicated call handover procedures from GSM to UMTS.
Extended Measurement Reporting.
Enhanced Measurement Reporting.
The sending of UMTS Frequency List as part of the RR-CHANNEL RELEASE message.
Blind search.
11-4 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Parameters
The sending of SI2quater on extended BCCH.
The BSS restricts the maximum number of UTRAN neighbors per GSM cell to 16.
BSS does not support statistics for this feature.
The OMC interface only supports UTRAN neighbor cells which have a unique RNC-id and
cell id combination within the BSS database.
Parameters
The BSS Inter-Radio Access Technology (Inter-RAT) handover GSM function is configured using
the following parameters, as shown in Table 11-1.
Table 11-1 RAT configuration parameters
Parameter Function
inter_rat-enabled Inter-RAT handover functionality for a cell:0 OFF1 2 to 3G idle2 3 to 2G
dedicated3 2 to 3G idle and 3 to 2G dedicated.
qsearch_i When the MS starts measurement of a UTRAN neighbor cell.
qsearch_c_initial MS uses qsearch_i, or always to search.
fdd_qoffset Used in the MS cell reselection algorithm followed by the MS.
fdd_qmin Used in the MS implemented cell reselection algorithm.
msc_release The release of the MSC to which the BSS is connected:0 Release 1998
or earlier 0 Release 1999 or later.
tdd_arfcn Indicates the TD-SCDMA frequency.
tdd_cell_param Indicates the TD-SCDMA cell parameter as defined in TS25.223.
tdd_tstd_mode Indicates the TD-SCDMA Time Switched Transmit Diversity mode.
tdd_sctd_mode Indicates the TD-SCDMA cell diversity capability (Space Code Transmit
Diversity).
tdOpt Indicates whether the TD-SCDMA inter-working feature functionality is
restricted or unrestricted in BSS software.
td_enabled Specfies whether TD-SCDMA inter-working function is enabled or
disabled.
Details of the setting of these parameters are described in Technical Description: BSS Command
68P02901W36-S 11-5
Jul 2008
New neighbor attributes Chapter 11: BSS Inter-Radio Access Technology Handover
New neighbor attributes
Table 11-2 shows the new attributes for UTRAN neighbors cells, used in the neighbor commands:
add_neighbour
modify_neighbour
del_neighbour
disp_neighbour
Table 11-2 Attributes for UTRAN neighbor cells
Attribute Valid Input Default

utran_cell_id The identifier of the UTRAN neighbor cell.
fdd_arcfn The frequency of the cell.
scr_code The primary scrambling code.
diversity_enabled Whether diversity is enabled from the cell.
These parameters are prompted for at the OMC-R or when the commands are entered at the
MMI. Details of the setting of these parameters are described in Technical Description: BSS
Commands
The following commands are used as indicated in Table 11-3.
Table 11-3 Changed commands
Command Function
add_neighbour neighbour_cell_id is updated to include utran_cell_id.
Placement is updated to include placement type umts_fdd.
del_neighbour neighbour_cell_id is updated to include utran_cell_id.
modify_neighbour neighbour_cell_id is updated to include utran_cell_id.
Neighbor cell attributes can be entered as UTRAN values.
Neighbor cell values can be entered as UTRAN values.
disp_neighbour neighbour_cell_id is updated to include utran_cell_id.
Details of the setting of these parameters are described in Technical Description: BSS Command
11-6 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Enhanced 2G/3G handover and cell reselection
Enhanced 2G/3G handover and cell reselection

Overview
This feature is an extension to GSM BSS Inter-RAT Handover, which provides BSS support for
idle mode cell reselection from 2G to 3G, NC0 (MS controlled) cell reselection in Packet Idle
Mode and Packet Transfer Mode from 2.5G to 3G and incoming dedicated mode handover
from 3G to 2G.
The Enhanced 2G/3G Handover and Cell Reselection feature provides BSS support for outgoing
dedicated mode handover from 2G to 3G.
In addition, the feature supports BSS control for measurement reporting by multi-RAT MS,
UTRAN early classmark sending blind search for cell reselection from 2G to 3G and Inter-RAT
related performance measurements.
Blind search by a multi-RAT MS
Blind search allows multi-RAT MS to perform cell reselection from 2G to 3G using just the
UTRAN FDD-ARFCN without knowing any explicit description of 3G neighbor cells to which cell
reselection can be performed. The BSS support for blind search involves the ability for the BSS
to broadcast FDD-ARFCN by itself in the SYSTEM INFORMATION TYPE 2quater message on
BCCH and PSI3Quater on PBCCH.
Blind search minimizes the information sent to the MS and consequently the time associated
with broadcasting 3G neighbor information is minimized. However, blind search increases the
actual time to synchronize to 3G cells by the multi-RAT MS. The MS in idle mode can spend a
longer time to synchronize with 3G cells than an MS in dedicated mode.
Measurement reporting and handover from 2G to 3G
Measurement reporting in dedicated mode
In dedicated mode, the MS measures attributes of the downlink radio link from BSS to MS
and reports these measurements back to the BSS. The BSS uses these measurements for
handover and RF power control purposes. The MS performs measurements on the serving cell
and neighbor cells.
The measurement quantity for a GSM serving cell are the received RF signal level (RXLEV) and
the RF signal quality (RXQUAL). The measurement quantity for GSM neighbor cells is the
RXLEV. For UTRAN FDD neighbor cells the multi-RAT MS measures either CPICH RSCP or
CPICH Ec/No as controlled by the parameter FDD_REP_QUANT.
Information about neighbor cells is provided to an MS in dedicated mode on SACCH by the BSS.
The MS uses this information to build lists which it uses for the reporting measurements. The
MS reports these measurements using MEASUREMENT REPORT message which is signaled
to the MS by the BSS in MEASUREMENT INFORMATION message. The MEASUREMENT
68P02901W36-S 11-7
Jul 2008
Measurement reporting and handover from 2G to 3G Chapter 11: BSS Inter-Radio Access Technology Handover
INFORMATION message is sent to multi-RAT MS supporting revision level 2 and RAT capability
as indicated by the classmark information. For reporting using MEASUREMENT REPORT, an
MS at revision level 2 uses two separate lists: a BA(list) and a 3G Neighbor Cell List for GSM
and UTRAN FDD cells respectively.
The BA(list) is the BCCH Frequency List sent in SYSTEM INFORMATION TYPE 5 and optionally
through SYSTEM INFORMATION TYPE 5bis and SYSTEM INFORMATION TYPE 5ter messages
on SACCH. The 3G Neighbor Cell List is built by the MS based on 3G Neighbor Cell Reselection
List in the System Information 2Quater and is added to or replaced when the 3G Neighbor Cell
Description information sent in MEASUREMENT INFORMATION message on SACCH has
been received.
NOTE
Where the MS is in dedicated mode and reporting 3G neighbor receive levels based
on the 3G cell reselection list sent in the SI 2Quater (that is the MEASUREMENT
INFORMATION has not yet been sent by the BSS or received by the MultiRAT MS),
it is possible that the MS reports receive levels from blind search neighbors. In
this instance, the MEASUREMENT REPORT includes the RSSI of the blind search
neighbor. Blind search in dedicated mode is not supported; therefore the BSS ignores
any 3G neighbor RSSIs received in the MEASUREMENT REPORT.
The SI5bis message is sent only when the EXT IND bit in both SI5 and SI5bis are set, indicating
that part of the BCCH Frequency List is in SI5 and the rest (extension) of the BCCH Frequency
List is in SI5bis. The various lists used by the MS are summarized in Table 11-4.
Table 11-4 Summary of lists used by the MS
Sent On
List On Channel Used For Size
Message
BCCH Channel List SI2/2bis/2ter BCCH Idle mode cell 32
[BA (list) on BCCH or reselection and as
BA (BCCH) ] an initial list for
reporting using
MEASUREMENT
REPORT message
when the MS
is assigned a
dedicated channel.
BCCH Channel List SI5/5bis/5ter SACCH For reporting about 32
[BA (list) on SACCH GSM neighbor When 3G
or BA (SACCH) ] cells using cells are also
MEASUREMENT reported using
REPORT message MEASUREMENT
when the MS is in REPORT, the
dedicated mode. maximum is 31.
Continued
11-8 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation Measurement reporting and handover from 2G to 3G
Table 11-4 Summary of lists used by the MS (Continued)

Sent On
List On Channel Used For Size
Message
3G neighbor Cell List SI2quater BCCH Idle mode cell 32 + 8 Blind
on BCCH reselection and as Search
an initial list for
reporting using
MEASUREMENT
REPORT message
when the MS
is assigned a
dedicated channel.
3G neighbor Cell List MEASUREMENT INFORMATION
SACCH For reporting about 32
on SACCH UTRAN neighbor
cells using
MEASUREMENT
REPORT message
when the MS
is in dedicated
mode. (MS uses
a different list
to report using
MEASUREMENT
REPORT message
for GSM cells. See
BA (SACCH)
The BA (list) or BCCH Channel list comprises one or two BCCH channel sublists, one derived
from the set of frequencies sent in SI5 (and SI5bis if EXT_IND bit is set in both SI5 and SI5bis)
and the other derived from the set of frequencies sent in SI5ter (if present). If two sub lists
are present then the BA (list) is the union of the two sublists. The frequencies within each sub
list are placed in increasing order of ARFCN, except for ARFCN 0, if included, is put in the last
position in the sub list. The BA (list), whether consisting of one or two sublists, cannot exceed
the maximum size of 32.
In dedicated mode, the MS performs measurements every SACCH multiframe and reports it at
the next SACCH block designated for the timeslot the MS is on.
For a multi-RAT MS, the measurement of UTRAN neighbor cells in dedicated mode is controlled
by BSS by the Qsearch_C and 3G_SEARCH_PRIO parameters. The Qsearch_C parameter,
like Qsearch_I in idle mode, defines a threshold and also indicates when measurements on
UTRAN neighbor cells are triggered. The MS uses the Qsearch_C parameter only after a
certain number of instances of MEASUREMENT INFORMATION messages are received as
controlled by the 3G_WAIT parameter. Until a valid Qsearch_C is available, the MS uses the
Qsearch_C_Initial parameter broadcast on BCCH in the SYSTEM INFORMATION TYPE 2quater.
The 3G_SEARCH_PRIO is a Boolean flag that indicates whether search frames, which otherwise
can be used for BSIC decoding, are used for searching UTRAN cells or not. The number
of best valid UTRAN FDD cells reported by a multi-RAT MS is controlled by the parameter
FDD_MULTIRAT_REPORTING. A valid cell is a UTRAN FDD cell in the neighbor list with a
correct scrambling code for the frequency of the cell.
A multi-RAT MS sends MEASUREMENT REPORT to BSS containing measurements for one

serving cell and up to six neighbor cells. Six neighbor cells is the maximum that can be reported
irrespective of whether there are GSM cells in one frequency band or many frequency bands and
UTRAN FDD cells. The parameters MULTIBAND_REPORTING, SERVING_BAND_REPORTING,
and FDD_MULTIRAT_REPORTING control the minimum number of these different type of
cells reported. Using MEASUREMENT REPORT to report both GSM and UTRAN FDD cells is
68P02901W36-S 11-9
Jul 2008
possible only when 31 GSM cells or less are in the BA(list) and 64 cells are in the 3G neighbor
Cell List. RXLEV-NCELL, BCCH-FREQ-NCELL, and BSIC are reported for a GSM neighbor
cell in the MEASUREMENT REPORT. For UTRAN FDD cell RXLEV-NCELL is replaced with
the CPICH Ec/No or CPICH RSCP mapped appropriately, BCCH-FREQ-NCELL is set to 31 to
indicate that it is for a 3G cell and the BSIC contains the index to the 3G neighbor Cell List from
where the FDD-ARFCN and Scrambling Code can be obtained.
2G to 3G handover procedure
GSM BSS Inter-RAT Handover is the transition of a multi-RAT MS in dedicated mode under
GSM system to UTRAN connected mode in UTRAN system. The multi-RAT MS performs
measurements on serving GSM cell and neighbor GSM or UTRAN cells and sends measurements
to BSS using MEASUREMENT REPORT message. The BSS controls the measurement performed
by the MS using the MEASUREMENT INFORMATION message. Based on the MS reported
measurements, BSS evaluates a need for handover from GSM to UTRAN. Once the decision
to perform a handover has been made various procedures across the MSC, BSS, RNS, and
multi-RAT MS are executed.
Inter-System Handover Required Indication
If BSS decides to handover the MS from GSM to UTRAN, the MSC receives a
BSSMAP-HANDOVER REQUIRED message from the BSS. The MSC performs MAP procedure
to initiate a UTRAN specific resource allocation procedure and if it is successful, the MSC
responds to the BSS with a BSSMAP HANDOVER COMMAND message.
Inter-System Handover Resource Allocation
The 2G MSC sends a MAP-PREPARE HANDOVER to a 3G MSC (UTRAN Core Network node)
which initiates the UTRAN-specific Relocation Resource Allocation procedure. If the resource
allocation is successful, the 2G MSC receives a MAP-PREPARE HANDOVER RESPONSE
message. If the BSS is connected to a 3G MSC, the MAP procedures on E-interface between a
2G MSC and 3G MSC are not needed. The 3G MSC directly initiates the UTRAN Relocation
Resource Allocation procedure.
Inter-System Handover Execution
The 2G MSC sends a BSSMAP-HANDOVER message to the BSS which triggers the handover
to UTRAN procedure in the BSS.
The BSS sends a radio interface RR-INTER SYSTEM TO UTRAN HANDOVER message to the
MS. This RR message contains the HANDOVER TO UTRAN Information Element.
A multi-RAT MS experiences the following sequence of events:

The suspension of normal operation except for RR management (layer 3).
The disconnection of the main signaling link (SDCCH or FACCH) any other links (local end
release (layer 2)) and the disconnection of TCH(s), if any.
The disconnection and the deactivation of previously assigned channels and their release
(layer 1).
The establishment of a UTRAN channel.
Figure 11-2 shows the signaling involved in a GSM BSS Inter-RAT Handover for a successful
handover from GSM to UTRAN.
11-10 68P02901W36-S
Jul 2008
Figure 11-2 GSM to UTRAN handover signaling
The signaling involved in a GSM BSS Inter-RAT Handover for a successful handover from GSM
to UTRAN is described in Procedure 11-1.
Procedure 11-1 GSM BSS Inter-RAT Handover from GSM to UTRAN
1 The BSS sends BSSMAP-HANDOVER REQUIRED message to the MSC.

2 The request for handover resource allocation from GSM results in the
execution of the Relocation Resource Allocation procedure. The CN initiates
this procedure by sending the RANAP-RELOCATION REQUEST message to
Target RNC. This message contains the Source RTarget RNC Transparent
Information from GSM system. It is used to convey the UE capability
Information to the RNS.
3 When target RNC allocates resources for the handover it sends a
RANAP-RELOCATION REQUEST ACKNOWLEDGE message to the CN. This
message contains the Target RNC Source RNC Transparent Container IE
which includes an RRC-HANDOVER TO UTRAN COMMAND message built
by the RNS.
Continued
68P02901W36-S 11-11
Jul 2008
Procedure 11-1 GSM BSS Inter-RAT Handover from GSM to UTRAN (Continued)
4 The GSM MSC sends a BSSMAP-HANDOVER COMMAND message to the
BSS. This message contains the Layer 3 Information IE. This IE carries the
RRC-HANDOVER TO UTRAN COMMAND sent in the Target RNC to Source
RNC Transparent Container IE of the RANAP-RELOCATION REQUEST
ACKNOWLEDGE message.
5 The BSS sends an RR-INTER SYSTEM TO UTRAN HANDOVER COMMAND
message to the multi-RAT MS. This message contains the HANDOVER TO
UTRAN COMMAND IE, which is the RRC message from the UTRAN passed
to the MS. The MS uses the information contained in the HANDOVER TO
UTRAN COMMAND to establish a UTRAN channel. The information in the
HANDOVER TO UTRAN COMMAND can be complete specification of the
Radio Bearer, Transport Channel and Physical Channel parameters or it can
be information on predefined configurations stored in the MS.
6 A RELOCATION DETECT message is sent from the RNS to the CN (3G MSC).
7 When the MS successfully establishes a UTRAN channel, it switches to
RRC connected mode (RRC signaling connection exists) and sends an
RRC-HANDOVER TO UTRAN COMPLETE message to the RNS.
8 The Relocation Complete procedure is executed in UTRAN.
9 MSC initiates a Clear sequence by sending the BSSMAP-CLEAR COMMAND
message to the BSS.
10 BSS responds with a BSSMAP-CLEAR COMPLETE message to the MSC.
Measurement Criteria
The term Measurement Based Handover indicates the minimum algorithm used for deciding
whether a UTRAN FDD cell qualifies for handover. In order for a reported 3G UTRAN neighbor
to qualify for handover, the following criteria are checked:
UTRAN measurement quantity > (Minimum threshold + Margin)
UTRAN measurement quantity
Averaged UTRAN neighbor receive level.
Minimum Threshold
Operator configured per cell threshold: umts_cpich_ec_no_min or umts_cpich_rscp_min,

gated by fdd_rep_quant
If fdd_rep_quant = 0, use umts_cpich_rscp_min; if fdd_rep_quant = 1, use

umts_cpich_ec_no_min
Margin
Operator configured per neighbor threshold: umts_meas_margin
If the check passes, the UTRAN neighbor is considered to have passed the 3G
Measurement Criteria and is a valid candidate for handover.
11-12 68P02901W36-S
Jul 2008
Service based handover from 2G to 3G
The service type and data rate requested by the MS normally trigger service based handovers.
The MSC triggers a service based handover by signaling service handover recommendation to
the BSS over the A-interface. To support this signaling, an optional SERVICE HANDOVER IE
in ASSIGNMENT REQUEST message and HANDOVER REQUEST message is introduced. The
SERVICE HANDOVER IE contains 3 bits, which are coded as follows:
000 Handover to 3G is preferred

001 Handover to 2G is preferred
010 Handover to 3G is not allowed
The BSS stores the SERVICE HANDOVER IE and uses this stored information during handover
evaluations. The MSC sets up the SERVICE HANDOVER IE depending on the algorithm
implemented in the BSS, of a multi-RAT service based handover triggered during: call
establishment (on assignment handover) in GSM, after call establishment in GSM, while in-call
or after handover within a GSM cell, or handover from a UTRAN to GSM.
MS Classmark Handling
The classmark indicates the capabilities of an MS. An MS sends classmark information to

the BSS whenever there is a change in the characteristics of the MS. An MS implementing
controlled early classmark sending option sends classmark information to the BSS as soon as
possible after access, even if there are no change in characteristics of the MS. The BSS can
enquire the MS classmark whenever the BSS needs additional classmark information.
An MS supporting UTRAN sends a UTRAN Classmark Change message. When a CLASSMARK

CHANGE message and one or more additional UTRAN messages are to be sent, the
CLASSMARK CHANGE message is sent first.
An MS which implements the support of one or more 3G Radio Access Technology also
implements the Controlled Early Classmark Sending option. The network can prevent the MS
from sending UTRAN CLASSMARK CHANGE message by the use of the 3G Early Classmark
Sending Restriction parameter.
The last reception in the accessed cell of the SYSTEM INFORMATION TYPE 3 message on
the BCCH and PSI2 on the PBCCH.
The UTRAN Classmark message has UMTS related information about the MS. The BSS saves it
and uses it to populate the RRC container (for Inter RAT Handover IE) of Source RNC to Target
RNC transparent container in the Handover Required message.
A multi-RAT MS sends a UTRAN CLASSMARK CHANGE message to the BSS autonomously or

in response to a CLASSMARK ENQUIRY message from the BSS. The UTRAN CLASSMARK
CHANGE message contains UE capability information, predefined configuration status
information or security-related information, START-CS, to be used after handover to UTRAN.
The BSS stores internally the information obtained from UTRAN CLASSMARK CHANGE
message and later uses when initiating a handover from GSM to UTRAN. The BSS requests
UTRAN classmark information by setting the appropriate bit in the Classmark Enquiry Mask in
the CLASSMARK ENQUIRY message.
68P02901W36-S 11-13
Jul 2008
Handover Control Parameters
The following handover control parameters are used in the Enhanced 2G/3G Handover and Cell
Reselection feature.
Qsearch_C This parameter defines the search for 3G cells if signal

level below threshold 0-7, or above threshold 8-15.
FDD_MULTIRAT_REPORTING This parameter defines the number of UTRAN FDD cells
(one or more) that can be included in the list of strongest
cells or in the measurement report.
FDD_REP_QUANT cells This parameter indicates the reporting quantity for
UTRAN.
3G_SEARCH_PRIO This parameter indicates if 3G cells can be searched when
BSIC decoding is required. It is not user-configurable.
This parameter is named SEARCH_PRIO_3G in the BSS
database.
MULTIBAND_REPORTING This parameter indicates the number of cells to be
reported for each band (other than the serving frequency
band) in multiband operation.
SERVING_BAND_REPORTING This parameter indicates the number of cells to be
reported from the GSM serving frequency band in
multiband operation.
BLIND_SEARCH_PREFERENCE This parameter indicates if blind search is to used.
UMTS_BAND_PREFERRED This parameter defines user preference for UMTS band.
UMTS_CPICH_EC_NO_MIN This parameter defines Handover Threshold when
FDD_REP_QUANT=1.
UMTS_CPICH_RSCP_MIN This parameter defines Handover Threshold when
FDD_REP_QUANT = 0.
UMTS_MEAS_MARGIN This parameter defines the Per neighbor Handover
threshold.
UMTS_NCELL_AVG_PERIOD This parameter defines the Per neighbor averaging.
11-14 68P02901W36-S
Jul 2008
Technical Description: BSS Implementation TD-SCDMA and GSM interworking feature
TD-SCDMA and GSM interworking feature

{31400}
Overview
This feature provides GSM/TD-SCDMA inter-working support. It is an optional feature and

supports the following functions:
Supports GSM/GPRS to TD-SCDMA cell reselection in circuit-switched idle mode and
packet idle mode by broadcasting TD-SCDMA neighbor list and corresponding 3G
measurement parameters in SI2ter, SI2Quater
Supports GSM/GPRS to TD-SCDMA cell reselection in packet transfer mode.
Supports MS reselect to GSM/GPRS from TD-SCDMA.
Supports TD-SCDMA to GSM handover in circuit-switched dedicated mode.
The operator can add/change/delete/display the TD-SCDMA neighbor list from the BSS MMI
or from the OMC-R.
A GSM cell can have up to 16 TD-SCDMA neighbors. The total TDD-ARFCN per GSM cell is 3. It
implies that the TD-SCDMA maximum neighbor cell number per TDD-ARFCN is 16.
Dependencies
This feature is supported only in Mcell, Horizon, and Horizon II cabinets. It cannot be enabled
in an Incell cabinet.
Refer to Technical Description: BSS Command Reference (68P02901W23) for more information.
68P02901W36-S 11-15
Jul 2008
Limitations Chapter 11: BSS Inter-Radio Access Technology Handover
Limitations
This feature can be enabled only if the Inter-RAT handover and Enhanced 2G/3G
Inter-RAT handover features are restricted.
The OMC interface supports the TD-SCDMA UTRAN neighbor cells which have a unique
RNC-Id and cell Id combination within the BSS database.
BSS does not support new statistics for this feature.
The following functions are not considered part of this feature:

Dedicated call handover procedures from GSM to TD-SCDMA.
Support for extended measurement reporting.
3G neighbor cell information and measurement parameters in packet measurement

order.
Support of packet measurement report with TDD neighbor measurement results.
Blind search.
The following functions not supported by this feature:

Cell reselection to UTRAN FDD neighbor cells or CDMA2000 neighbor cells.
Sending the TD-SCDMA frequency list as part of the RR-CHANNEL RELEASE

message.
Sending SI2quater on extended BCCH.
11-16 68P02901W36-S
Jul 2008
Index
Index

16 kbps RSL 2048 timeslot capability. . . . . . . . . . 2-58

DYNET . . . . . . . . . . . . . . . . . 3-23 8 kbps switching . . . . . . . . . . . . . 1-86
A interface . . . . . . . . . . . . . . . . . 1-9 AMR (contd.)

ABSS . . . . . . . . . . . . . . . . . . . 2-29 HR capable sub-equipped carrier backhaul
disabling CIC validation. . . . . . . . . 2-29 mappings . . . . . . . . . . . . . . . . 2-47
equipping and unequipping . . . . . . . 2-29 radio interface and timeslot allocation. . 1-31
XBL . . . . . . . . . . . . . . . . . . . 3-52 Radio platform operational require-
ABSS (associated BSS) . . . . . . . . . . 2-29 ments . . . . . . . . . . . . . . . . . . 2-12
ABSS (Associated BSS) . . . . . . . . . . 3-10 TDM timeslot allocation. . . . . . . . . 2-90
adaptive power handovers . . . . . . . . 8-66 TDM timeslot labelling . . . . . . . . . 3-46
advanced load handover management for EGSM AMR Abis-interface . . . . . . . . . . . . 6-106
carriers . . . . . . . . . . . . . . . . . . 8-86 AMR and GSM HR capable, GPRS CS3/4 capable
Aggregate Abis . . . . . . . . . . . . . . 3-62 carrier 8 kbps BSC-BTS backhaul mappi. . 2-45
air interface AMR call processing . . . . . . . . . . . . 6-7
PBCCH requirements . . . . . . . . . . 6-58 AMR half-rate capable, GPRS CS3/4 capable
PCCCH requirements . . . . . . . . . . 6-62 carrier 8 kbps BSC-BTS backhaul mappi. . 2-44
air interface packet data transfer . . . . . 6-68 AMR half-rate enhanced CIC validation . . 3-11
alarm categories . . . . . . . . . . . . . 4-33 AMR HR capable carrier 8 kbps BSC - BTS
alarm clearing types . . . . . . . . . . . 4-34 backhaul mappings . . . . . . . . . . . . 2-45
alarm consolidation . . . . . . . . . . . . 4-27 AMR HR capable sub-equipped carrier backhaul
alarm processing . . . . . . . . . . . . . 4-26 mappings . . . . . . . . . . . . . . . . . 2-47
blacklisting . . . . . . . . . . . . . . . 4-26 AMR radio interface and timeslot alloca-
display . . . . . . . . . . . . . . . . . 4-26 tion . . . . . . . . . . . . . . . . . . . . 1-31
alarm severity. . . . . . . . . . . . . . . 4-34 architecture
alarm states . . . . . . . . . . . . . . . . 4-32 code objects. . . . . . . . . . . . . . . . 4-4
alarm types . . . . . . . . . . . . . . . . 4-30 assignment of new calls as Adaptive Multi-Rate
tagged . . . . . . . . . . . . . . . . . 4-30 half-rate
untagged . . . . . . . . . . . . . . . . 4-30 AMR . . . . . . . . . . . . . . . . . . 6-14
alarms assignment to TCH . . . . . . . . . . . . 6-11
XBL . . . . . . . . . . . . . . . . . . . 3-57 Associated BSS (ABSS) . . . . . . . . 2-29, 3-10
all channels at full power . . . . . . . 8-11, 8-13 Associated Transcoder (AXCDR) . . . . . 2-30
AMR . . . . 3-28, 5-37, 5-59, 5-74, 6-14, 6-107, Ater interface in Enhanced Auto Connect (EAC)
6-110, 8-63, 8-75, 8-79, 8-122, 10-10 mode . . . . . . . . . . . . . . . . . . . 2-27
8 kbps switching . . . . . . . . . . . . 1-86 audio volume control at the GDP . . . . . 4-58
Abis-interface . . . . . . . . . . . . . . 6-106 auto_rf_loss_trace . . . . . . . . . . . . . . 7-5
Ater interface in Enhanced Auto Connect (EAC) available trace call criteria . . . . . . . . . 7-8
mode . . . . . . . . . . . . . . . . . . 2-27 averaging mechanisms
blocking/unblocking thresholds . . . . . 3-12 pointing to decision processes . . . . . 8-36
call setup, handover and teardown . . . 6-18 averaging quality
EGDP . . . . . . . . . . . . . . . . . . 2-89 BER and QBAND . . . . . . . . . . 6-85, 8-16
emergency call handling . . . . . . . . 6-108 AXCDR . . . . . . . . . . . . . . . . . . 2-30
half rate carrier configuration . . . . . 2-42 disabling CIC validation. . . . . . . . . 2-30
equipping and unequipping . . . . . . . 2-30
68P02901W36-S IX-17
Jul 2008
Index
AXCDR (contd.) AXCDR (Associated Transcoder) . . . . . 2-30

XBL . . . . . . . . . . . . . . . . . . . 3-52 AXCDR and ABSS . . . . . . . . . . . . . 2-31
BA (GRPS) list. . . . . . . . . . . . . . . 5-105 BSS devices and functions (contd.)

BA lists . . . . . . . . . . . . . . . . . . 8-43 BSC . . . . . . . . . . . . . . . . . . . . 2-5
BA(SACCH) list . . . . . . . . . . . . . . 8-43 BTF . . . . . . . . . . . . . . . . . . . 2-96
band_preference . . . . . . . . . . . . . 8-87 BTS . . . . . . . . . . . . . . . . . . . 2-10
band_preference_mode parameter . . . . 5-26 cabinet . . . . . . . . . . . . . . . . . 2-14
barring by class . . . . . . . . . . . . . . 5-63 cage. . . . . . . . . . . . . . . . . . . 2-15
Base Station Identity Code (BSIC) . . . . 5-13 cell . . . . . . . . . . . . . . . . . . . 2-32
Baseband hopping . . . . . . . . . . . . 10-4 connectivity AXCDR and ABSS . . . . . 2-31
BCC (BTS Colour Code) . . . . . . . . . . 5-13 device equipage and maintenance . . . . 2-3
BER . . . . . . . . . . . . . . . . . . 6-85, 8-16 DRI . . . . . . . . . . . . . . . . . . . 2-33
block coding . . . . . . . . . . . . . . . 1-26 EAS . . . . . . . . . . . . . . . . . . . 2-93
Block Error Rate (BLER) . . . . . . . . . 6-87 GCLK . . . . . . . . . . . . . . . . . . 2-61
Block Sequence Number (BSN) . . . . . . 6-87 GPROCs. . . . . . . . . . . . . . . . . 2-69
blocking/unblocking threshold . . . . . . 3-12 GPRS PCU . . . . . . . . . . . . . . . 2-101
BSC . . . . . . . . . . . . . . . . . . . . . 2-5 KSW and KSWX . . . . . . . . . . . . . 2-53
connectivity verification. . . . . . . . . 3-54 LCF . . . . . . . . . . . . . . . . . . . 2-97
functions . . . . . . . . . . . . . . . . . 1-3 MSI . . . . . . . . . . . . . . . . . . . 2-85
BSC reset management . . . . . . . . . . 1-95 OMF . . . . . . . . . . . . . . . . . . 2-100
BSC/RXCDR validation RTF . . . . . . . . . . . . . . . . . . . 2-36
XBL . . . . . . . . . . . . . . . . . . . 3-51 XCDR and RXCDR. . . . . . . . . . . . 2-16
BSIC (Base Station Identity Code) . . . . 5-13 BSS Feature
BSS Enhanced GPRS one phase access . . . 6-33
handover BSS level RF failure call trace events . . . 7-17
inter-BSS . . . . . . . . . . . . . . . 1-56 BSS links
intra-BSS . . . . . . . . . . . . . . . 1-59 Aggregate Abis . . . . . . . . . . . . . 3-62
intra-BTS . . . . . . . . . . . . . . . 1-62 BVC and MS flow control . . . . . . . . 3-66
purpose . . . . . . . . . . . . . . . . . . 1-3 BVC flow control . . . . . . . . . . . . 3-67
BSS based SMLC . . . . . . . . . . . . . 1-78 CBL . . . . . . . . . . . . . . . . . . . . 3-6
BSS channel allocation . . . . . . . . . . 3-78 CIC . . . . . . . . . . . . . . . . . . . . 3-8
BSS database parameter DARBC . . . . . . . . . . . . . . . . . 3-14
trace call DYNET . . . . . . . . . . . . . . . . . 3-18
trace_msgs_before_ho. . . . . . . . . . 7-5 E1/T1 link management . . . . . . . . . 3-59
BSS database parameters GB link . . . . . . . . . . . . . . . . . 3-70
congestion relief GPRS data stream. . . . . . . . . . . . 3-73
congest_at_source . . . . . . . . . . 8-114 GPRS Gb Interface to Air Interface
congest_at_target . . . . . . . . . . . 8-114 Mapping . . . . . . . . . . . . . . . . 3-66
ext_rtry_cand_prd . . . . . . . . . . . 8-114 GPRS Signalling Link (GSL). . . . . . . 3-76
mb_tch_congest_thres. . . . . . . . . 8-114 GSL link control function . . . . . . . . 3-81
rtry_cand_prd . . . . . . . . . . . . . 8-114 HDSL . . . . . . . . . . . . . . . . . . 3-33
rapid_pwr_down . . . . . . . . . . . . 8-15 MS flow control . . . . . . . . . . . . . 3-67
rpd_period . . . . . . . . . . . . . . . 8-15 MTL. . . . . . . . . . . . . . . . . . . . 3-3
rpd_trigger . . . . . . . . . . . . . . . 8-15 PATH . . . . . . . . . . . . . . . . . . 3-41
trace call PBCCH and PCCCH configuration . . . 3-83
auto_rf_loss_trace . . . . . . . . . . . . 7-5 PCU links . . . . . . . . . . . . . . . . 3-63
call_trace_options . . . . . . . . . . . . 7-5 RSL . . . . . . . . . . . . . . . . . . . 3-48
ct_flow_control_hi_level . . . . . . . . . 7-5 timeslot reservation . . . . . . . . . . . 3-43
ct_flow_control_lo_level . . . . . . . . . 7-5 XBL . . . . . . . . . . . . . . . . . . . 3-50
trace_msgs_after_ho . . . . . . . . . . 7-5 BSS reset and clear database . . . . . . . . 4-6
BSS devices and functions BSS Software feature
ABSS . . . . . . . . . . . . . . . . . . 2-29 Inter-Radio Access Technology (RAT) 2G to 3G
AXCDR . . . . . . . . . . . . . . . . . 2-30 handover . . . . . . . . . . . . . . . . 11-2
IX-18 68P02901W36-S
Jul 2008
Index
BSS software features . . . . 1-43, 1-83, 2-69, BTS . . . . . . . . . . . . . . . . . . . . 2-10

2-75, 2-98 to 2-99, 4-12, 6-40, 6-43 dynamic network . . . . . . . . . . . . 3-18
BSS software functions . . . . . . . . . . . 4-4 functions . . . . . . . . . . . . . . . . . 1-3
BSS software processes . . . . . . . . . . . 4-2 BTS Concentration Call Priority Handling
process description . . . . . . . . . . . . 4-2 (BCCPH)
bss_egsm_alm_allowed . . . . . . . . . . 8-87 call processing . . . . . . . . . . . . . 6-92
BSS-XCDR traffic channels BTS types . . . . . . . . . . . . . . . . . 2-11
16 kbps XBL . . . . . . . . . . . . . . 3-50 BVC flow control
BTF . . . . . . . . . . . . . . . . . . . . 2-96 BSS links . . . . . . . . . . . . . . . . 3-67
CA process . . . . . . . . . . . . . . . . . 4-5 call processing (contd.)

cabinet . . . . . . . . . . . . . . . . . . 2-14 radio channel interface . . . . . . . . . . 6-5
cage. . . . . . . . . . . . . . . . . . . . 2-15 radio resource state machine . . . . . . . 6-5
call clearing . . . . . . . . . . . . . . . . 6-22 SCCP state machine . . . . . . . . . . . 6-4
channel release . . . . . . . . . . . . . 5-48 switch manager . . . . . . . . . . . . . . 6-4
internal_MTT . . . . . . . . . . . . . . 6-22 terminated by MS
MS originated . . . . . . . . . . . . 5-48, 6-22 call setup . . . . . . . . . . . . . . . 1-51
MSC originated . . . . . . . . . . . 5-49, 6-25 Call Processing (CP) . . . . . . . . . . . . 4-5
radio_chan_released . . . . . . . . . . 6-22 call re-establishment . . . . . . . . . . . 5-66
rf_chan_rel_ack . . . . . . . . . . . . . 6-22 call setup . . . . . . . . . . . . . . . . . . 6-8
rr_t3109. . . . . . . . . . . . . . . . . 6-22 call setup handovers and teardown . . . . 6-18
rr_t3111. . . . . . . . . . . . . . . . . 6-22 Call setup time improvement in a GSM
sccp_released . . . . . . . . . . . . . . 6-22 network . . . . . . . . . . . . . . . . . . 6-132
call downgrade on CIC capability mis- call trace enhancements
match . . . . . . . . . . . . . . . . . . . 3-53 BSS level RF failure call trace events . . 7-17
GDP and XCDR . . . . . . . . . . . . . 3-53 cell level call trace events. . . . . . . . 7-13
call handling multiple trigger call trace events . . . . 7-24
DYNET . . . . . . . . . . . . . . . . . 3-22 call trace event
call processes benefits . . . . . . . . . . . . . . . . . 7-15
overview . . . . . . . . . . . . . . . . 1-44 data defining . . . . . . . . . . . . . . 7-15
call processing . . . . . . . . . . . . . . . 6-3 messages . . . . . . . . . . . . . . . . 7-14
allocation manager . . . . . . . . . . . . 6-4 OMC GUI . . . . . . . . . . . . . . . . 7-18
AMR . . . . . . . . . . . . . . . . . . . 6-7 call_trace_options . . . . . . . . . . . . . . 7-5
assignment to TCH . . . . . . . . . . . 6-11 carrier prioritization for SDCCH
BTS Concentration Call Priority Handling call processing . . . . . . . . . . . . . 1-74
(BCCPH) . . . . . . . . . . . . . . . . 6-92 SDCCH handovers . . . . . . . . . . . 8-106
call setup . . . . . . . . . . . . . . . . . 6-8 CB software process . . . . . . . . . . . 4-10
cell resource manager . . . . . . . . . . 6-4 CBL . . . . . . . . . . . . . . . . . . . . . 3-6
connection establishment . . . . . . . . . 6-8 CCITT Signalling System Number 7
connectionless manager . . . . . . . . . 6-3 (SSN7) . . . . . . . . . . . . . . . . . . . 3-3
GPRS timeslot allocation . . . . . . . . 6-51 Cease transmission when cell goes Out Of
GSM encryption (ciphering). . . . . . . 6-16 Service . . . . . . . . . . . . . . . . . . 5-67
location services support . . . . . . . . 6-93 cell . . . . . . . . . . . . . . . . . . . . 2-32
MS idle time reporting . . . . . . . 1-49, 1-55 add, copy or delete . . . . . . . . . . . . 5-5
MS-BSS-MSC signalling Cell Balancer (CB) . . . . . . . . . . . . 4-10
overview . . . . . . . . . . . . . . . 1-45 cell barring . . . . . . . . . . . . . . . . 5-63
MTP L3/SCCP preprocessor. . . . . . . . 6-3 function . . . . . . . . . . . . . . . . . 5-63
originated by MS cell broadcast link
call setup . . . . . . . . . . . . . . . 1-46 bi-directional data link . . . . . . . . . . 3-6
downlink . . . . . . . . . . . . . . . 1-49 cell level call trace events . . . . . . . . . 7-13
uplink . . . . . . . . . . . . . . . . . 1-49 cell selection/reselection . . . . . . . . . 5-91
overview . . . . . . . . . . . . . . . . 1-43 cells . . . . . . . . . . . . . . . . . . . . . 5-3
PCS1900 concentric. . . . . . . . . . . . . . . . 5-70
frequency types . . . . . . . . . . . . 5-12 elements . . . . . . . . . . . . . . . . . 5-3
68P02901W36-S IX-19
Jul 2008
Index
Central Authority (CA) . . . . . . . . . . . 4-5 concentric cells . . . . . . . . . . . . . . 5-70

channel allocation. . . . . . . . . . . . . 5-39 AMR . . . . . . . . . . . . . . . . . . 5-74
AMR . . . . . . . . . . . . . . . . . . 6-110 call processing . . . . . . . . . . . . . 5-73
channel reconfiguration configuration management . . . . . . . 5-73
SDCCH/TCH setup . . . . . . . . . . . 5-42 extended range cells . . . . . . . . . . 5-74
channel release fault management. . . . . . . . . . . . 5-73
radio_chan_released . . . . . . . . . . 5-48 handover . . . . . . . . . . . . . . . . 5-73
channel requests . . . . . . . . . . . . . 5-39 interference based algorithm . . . . . . 5-71
channels power based algorithm . . . . . . . . . 5-70
equalization . . . . . . . . . . . . . . . 1-25 statistics in . . . . . . . . . . . . . . . 5-73
logical. . . . . . . . . . . . . . . . . . 1-14 concentric cells feature in single BCCH. . 5-17
traffic and control configuration management database . . . 4-12
GPRS . . . . . . . . . . . . . . . . . 1-18 congestion relief . . . . . . . . . . 8-35, 8-113
checks enhanced . . . . . . . . . . . . . . . . 8-35
software and ROM . . . . . . . . . . . . 4-7 handover criteria . . . . . . . . . . . . 8-36
CIC . . . . . . . . . . . . . . . . . . . . . 3-8 connection establishment . . . . . . . . . . 6-8
AMR half-rate . . . . . . . . . . . . . . 3-11 connectivity verification
blocking. . . . . . . . . . . . . . . . . 3-51 BSC . . . . . . . . . . . . . . . . . . . 3-54
CIC connectivity verification . . . . . . . 3-54 CIC . . . . . . . . . . . . . . . . . . . 3-54
circuit error rate monitor message flow. . 4-39 RXCDR . . . . . . . . . . . . . . . . . 3-55
clearing types . . . . . . . . . . . . . . . 4-34 consolidation
code storage facility processor alarms . . . . . . . . . . . . . . . . . 4-27
GPROC or PCMCIA device . . . . . . . 2-81 context sensitive help
coding description . . . . . . . . . . . . . . . 4-27
channel . . . . . . . . . . . . . . . . . 1-26 control channels
speech . . . . . . . . . . . . . . . . . 1-27 PBCCH/PCCCH . . . . . . . . . . . . . 6-56
transmissions . . . . . . . . . . . . . . 1-11 control, MS . . . . . . . . . . . . . . . . 5-61
coding schemes . . . . . . . . . . . . . . 6-80 convolution coding . . . . . . . . . . . . 1-26
coincident multiband handover CP software process . . . . . . . . . . . . 4-5
coincident multiband . . . . . . . . . . 8-80 CRM subsystem in BTS
comfort noise flow control operation. . . . . . . . . . 5-51
DTX . . . . . . . . . . . . . . . . . . . 5-80 CS/PS paging channels . . . . . . . . . . 6-63
comment field ct_flow_control_bss_enabled . . . . . . . . 7-5
description . . . . . . . . . . . . . . . 4-26 ct_flow_control_hi_level . . . . . . . . . . . 7-5
common control channel block configura- ct_flow_control_lo_level . . . . . . . . . . . 7-5
tion . . . . . . . . . . . . . . . . . . . . 5-61 ct_flow_control_msc_trace . . . . . . . . . 7-5
concentric cell
statistics in dual band . . . . . . . . . . 8-71
daisy chain connection data transfer processing (contd.)

DYNET . . . . . . . . . . . . . . . . . 3-20 GPRS two-phase attach . . . . . . . . . 6-27
DARBC . . . . . . . . . . . . . . . . . . 3-14 MS originated packet transfer . . . . . 6-29
block/unblock . . . . . . . . . . . . . . 3-15 MS states . . . . . . . . . . . . . . . . 6-26
equipage . . . . . . . . . . . . . . . . 3-15 MS terminated packet transfer . . . . . 6-31
DARBC (Dynamic Allocation of RXCDR-BSC Paging and acknowledgement. . . . . . 6-31
Circuits). . . . . . . . . . . . . . . . . . 3-14 database load management . . . . . . . . 4-24
DARBC validation DCS1800
XBL . . . . . . . . . . . . . . . . . . . 3-52 frequency band . . . . . . . . . . . 1-13, 5-9
data transfer processing high power . . . . . . . . . . . . . . . . 5-9
Downlink data transfer . . . . . . . . . 6-32 decision process
Enhanced GPRS one phase access . . . 6-33 handover . . . . . . . . . . . . . . . . 8-19
GPRS . . . . . . . . . . . . . . . . . . 6-26 definitions
GPRS one phase access . . . . . . . . . 6-32 E1 link . . . . . . . . . . . . . . . . . . 1-9
GPRS two phase access . . . . . . . . . 6-26 T1 link . . . . . . . . . . . . . . . . . . 1-9
IX-20 68P02901W36-S
Jul 2008
Index
delay DPROC (contd.)

downlink TBF, release. . . . . . . . . . 6-37 MMSs on DPROCs . . . . . . . . . . . 2-114
delayed release of downlink TBF . . . . . 6-37 MSI . . . . . . . . . . . . . . . . . . . 2-113
CS1 forcing . . . . . . . . . . . . . . . 6-38 DRI . . . . . . . . . . . . . . . . . . . . 2-33
statistical changes . . . . . . . . . . . 6-38 DSW . . . . . . . . . . . . . . . . . . . 2-58
desired RXLEV window DTX
power control . . . . . . . . . . . . . . . 8-3 downlink . . . . . . . . . . . . . . . . 5-79
Destination Point Code (DPC) . . . . . . . . 3-4 for non-transparent data . . . . . . . 5-80
device equipage and maintenance . . . . . 2-3 for speech. . . . . . . . . . . . . . . 5-80
Digital Radio Interface downlink for speech
(DRI) . . . . . . . . . . . . . . . . . . 2-33 VAD disabled . . . . . . . . . . . . . 5-80
directed retry . . . . . . . . . . . . . . . 8-33 VAD enabled . . . . . . . . . . . . . 5-80
handover criteria . . . . . . . . . . . . 8-36 uplink . . . . . . . . . . . . . . . . . . 5-79
discontinuous transmission dual band cell single BCCH handovers . . 5-30
downlink . . . . . . . . . . . . . . . . 5-79 dual band cells
for non-transparent data . . . . . . . 5-80 AMR . . . . . . . . . . . . . . . . . . 8-75
downlink for speech inner zone algorithms . . . . . . . . . . 5-23
VAD disabled . . . . . . . . . . . . . 5-80 single BCCH . . . . . . . . . . . . . . 5-21
VAD enabled . . . . . . . . . . . . . 5-80 Dynamic Allocation of RXCDR-BSC Circuits
uplink . . . . . . . . . . . . . . . . . . 5-79 (DARBC) . . . . . . . . . . . . . . . . . 3-14
Discontinuous Transmission Dynamic NETwork of BTSs
DTX . . . . . . . . . . . . . . . . . . . 5-79 (DYNET) . . . . . . . . . . . . . . . . 3-18
discontinuous transmission (DTX) DYNET . . . . . . . . . . . . . . . . . . 3-18
downlink 16 kbps RSL . . . . . . . . . . . . . . 3-23
for speech. . . . . . . . . . . . . . . 5-80 AMR . . . . . . . . . . . . . . . . . . 3-28
disp_trace_call . . . . . . . . . . . . . . . 7-4 call handling . . . . . . . . . . . . . . 3-22
diversity E1/T1 links . . . . . . . . . . . . . . . 3-21
overview . . . . . . . . . . . . . . . . 1-25 nailed paths . . . . . . . . . . . . . . . 3-21
double kiloport switch . . . . . . . . . . 2-58 NIU daisy chaining . . . . . . . . . . . 3-35
downlink level handover procedure . . . . 8-29 redundancy . . . . . . . . . . . . . . . 3-25
DPC (Destination Point Code) . . . . . . . . 3-4 terrestrial backhaul resources
DPROC DYNET . . . . . . . . . . . . . . . . 3-23
E1 link Emergency caller location (contd.)

definition . . . . . . . . . . . . . . . . . 1-9 LCS . . . . . . . . . . . . . . . . . . . 1-76
E1/T1 link management emergency calls
link quality . . . . . . . . . . . . . . . 3-59 AMR . . . . . . . . . . . . . . . . . . 6-107
E1/T1 links no barring. . . . . . . . . . . . . . . . 5-64
DYNET . . . . . . . . . . . . . . . . . 3-21 eMLPP . . . . . . . . . . . . . . . . . . 6-125
EAS . . . . . . . . . . . . . . . . . . . . 2-93 encryption
ECERM GSM . . . . . . . . . . . . . . . . . . 5-77
AMR half-rate . . . . . . . . . . . . . . 3-11 Enhanced 2G/3G Handover and Cell
EFR Reselection . . . . . . . . . . . . . . . . 11-7
in inter-BSS handovers . . . . . . . . . 8-55 enhanced call trace management
EGDP and GDP2 . . . . . . . . . . . . . 2-89 call processing . . . . . . . . . . . . . 1-65
EGPRS system information messages . . . 6-122 overview . . . . . . . . . . . . . . . . 1-64
EGSM Enhanced Circuit Error Rate Monitor . . . 4-36
handovers . . . . . . . . . . . . . . . . 8-86 enhanced circuit error rate monitor
EGSM to EGSM handovers . . . . . . . . 8-86 points . . . . . . . . . . . . . . . . . . . 4-36
EGSM900 enhanced congestion relief . . . . . . . . 8-35
frequency band . . . . . . . . . . . 1-13, 5-8 Enhanced Generic DSP Processor provision-
BCCH . . . . . . . . . . . . . . . . . . 5-9 ing . . . . . . . . . . . . . . . . . . . . 2-23
emergency call handling . . . . . . . . . 6-108 Enhanced Multi-Level Precedence and
Emergency caller location Pre-emption service . . . . . . . . . . . . 6-125
68P02901W36-S IX-21
Jul 2008
Index
equalization . . . . . . . . . . . . . . . . 1-25 extended paging (contd.)

overview . . . . . . . . . . . . . . . . 1-25 MS control . . . . . . . . . . . . . . . 5-62
ERCs (Extended Range Cells) . . . . . . . 5-82 extended range cell (ERC)
Extended Dynamic Allocation Medium Access PGSM/EGSM . . . . . . . . . . . . . . 5-82
(EDMAC) Mode . . . . . . . . . . . . . . 6-49 extended range cells (ERC)
extended paging prioritization . . . . . . . . . . . . . . 8-38
Fault Management (FM) . . . . . . . . . . 4-5 frequency (contd.)

feature . . . . 1-18, 1-36, 2-57, 2-105 to 2-106, bands (contd.)
3-72, 3-78, 3-81, 3-83, 5-104, 6-56, 6-58 GSM850 . . . . . . . . . . . . . 1-13, 5-7
flexible neighbour cell processing. . . . . 8-92 GSM900 . . . . . . . . . . . . . 1-13, 5-8
flow control PCS1900 . . . . . . . . . . . . . 1-13, 5-10
BSS . . . . . . . . . . . . . . . . . . . 5-51 frequency blocks
GPRS . . . . . . . . . . . . . . . . . . 5-60 GSM850 . . . . . . . . . . . . . . . . . 5-7
MSC overload control . . . . . . . . . . 5-54 PCS1900 . . . . . . . . . . . . . . . . 5-10
Flow control frequency hopping . . . . . . . . . . . . 10-2
BVC . . . . . . . . . . . . . . . . . . . 3-67 Frequency hopping
MS . . . . . . . . . . . . . . . . . . . 3-67 Frequency hopping overview . . . . . . 1-30
flow control and trace call . . . . . . . . 7-21 Frequency Hopping Indicators (FHI) . . . 10-9
FM software process . . . . . . . . . . . . 4-5 frequency re-definition
forced handovers AMR . . . . . . . . . . . . . . . . . . 10-10
AMR . . . . . . . . . . . . . . . . . . 8-63 Frequency types
frequency PCS network . . . . . . . . . . . . . . . 5-7
bands full barring . . . . . . . . . . . . . . . . 5-63
DCS1800 . . . . . . . . . . . . . 1-13, 5-9 full rate speech coder . . . . . . . . . . . 1-27
EGSM900 . . . . . . . . . . . . . 1-13, 5-8
Gateway Mobile Location Center . . . . . 1-78 GPRS

Gaussian Minimum Shift Keying acknowledged and unacknowledged
(GMSK) . . . . . . . . . . . . . . . . . . 1-13 modes . . . . . . . . . . . . . . . . . . 6-73
Gb Link (GBL). . . . . . . . . . . . . . . 3-70 control channels
GBL . . . . . . . . . . . . . . . . . . . . 3-70 PBCCH/PCCCH . . . . . . . . . . . . 6-56
GBL interface data transfer processing . . . . . . . . 6-26
PVC (permanent virtual connection) . . 3-63 MAC layer. . . . . . . . . . . . . . . . 6-73
GCLK . . . . . . . . . . . . . . . . . . . 2-61 PCU . . . . . . . . . . . . . . . . . . . 2-101
GDP and XCDR combination physical layer . . . . . . . . . . . . . . 6-77
Enhanced Full Rate (EFR)FR . . . . . . 3-53 power control . . . . . . . . . . . . . . . 8-8
GDS . . . . . . . . . . . . . . . . . . . . 3-73 reserved and switchable timeslots . . . 5-36
Generic Clock RLC layer . . . . . . . . . . . . . . . . 6-68
(GCLK) . . . . . . . . . . . . . . . . . 2-61 switchable timeslots
Generic PROCessors (GPROCs) . . . . . . 2-69 configure . . . . . . . . . . . . . . . 6-51
GMLC . . . . . . . . . . . . . . . . . . . 1-78 dynamic switching . . . . . . . . . . 6-53
GMSK . . . . . . . . . . . . . . . . . . . 1-13 in cell reconfigure. . . . . . . . . . . 6-54
GPROC reconfigure . . . . . . . . . . . . . . 6-52
functions . . . . . . . . . . . . . . . . 2-69 traffic and control channels . . . . . . . 5-33
GPROC2 GPRS Data Stream (GDS) . . . . . . . . . 3-73
call processing function . . . . . . . . . 1-43 GPRS PCU recovery on last GSL failure . . 3-76
fast reset . . . . . . . . . . . . . . . . 2-70 GPRS Power Control
functions . . . . . . . . . . . . . . . . 2-69 BSS received interference level . . . . . 9-11
GPROCS . . . . . . . . . . . . . . . . . 2-69 BSS received signal level . . . . . . . . 9-10
IX-22 68P02901W36-S
Jul 2008
Index
GPRS Power Control (contd.) GPRS timeslot allocation . . . . . . . . . 6-51

Channel interference measurement GPRS two-phase attach . . . . . . . . . . 6-27
reports . . . . . . . . . . . . . . . . . . 9-8 data transfer processing . . . . . . . . 6-27
Closed loop uplink power control . . . . 9-14 GSL . . . . . . . . . . . . . . . . . . . . 3-76
Coding scheme selection methods . . . 9-32 LCF management . . . . . . . . . . . . 3-81
Downlink coding decisions . . . . . . . 9-32 GSL states and reason codes . . . . . . . 3-78
Downlink power control. . . . . . . . . 9-18 BSS channel allocation . . . . . . . . . 3-78
Downlink power control modes . . . . . 9-20 LAPD parameter . . . . . . . . . . . . 3-78
MS signal level measurements GSM
Types of signal level measurements. . . 9-5 cells . . . . . . . . . . . . . . . . . . . . 5-3
Open loop uplink power control . . . . . 9-15 control channels . . . . . . . . . . . . 5-16
Phases of downlink power control. . . . 9-18 encryption . . . . . . . . . . . . . . . 5-77
Quality loop uplink power control . . . . 9-16 GSM Cell ID. . . . . . . . . . . . . . . . . 5-4
Signalling uplink power control . . . . . 9-16 GSM encryption (ciphering). . . . . . . . 6-16
Types of signal level measurements. . . . 9-5 GSM flow control
Uplink algorithms . . . . . . . . . . . . 9-13 AGCH flow control management . . . . 5-57
Uplink coding scheme selection and GSM HR
decisions . . . . . . . . . . . . . . . . 9-36 AMR and GSM HR capable carrier 8 kbps BSC -
Uplink power control BTS backhaul mappings. . . . . . . . . 2-46
Uplink algorithms . . . . . . . . . . . 9-13 half rate carrier configuration . . . . . 2-43
GPRS power control and coding schemes . . 9-2 HR capable sub-equipped carrier backhaul
Measurement reporting . . . . . . . . . . 9-3 mappings . . . . . . . . . . . . . . . . 2-48
Methods of GPRS power control . . . . . 9-4 GSM HR capable sub-equipped carrier backhaul
Overview . . . . . . . . . . . . . . . . . 9-2 mappings . . . . . . . . . . . . . . . . . 2-48
Types of GPRS power control . . . . . . . 9-2 GSM850
GPRS quality of service . . . . . . . . 4-43, 4-52 frequency band . . . . . . . . . . . 1-13, 5-7
GPRS R4 Compliance . . . . . . . . . . . 6-123 frequency blocks . . . . . . . . . . . . . 5-7
GPRS Signalling Link (GSL) . . . . . . . . 3-76 GSM900
GPRS PCU recovery on last GSL fail- frequency band . . . . . . . . . . . 1-13, 5-8
ure . . . . . . . . . . . . . . . . . . . 3-76
Half Rate handovers (contd.)

congestion relief procedure interac- decisions . . . . . . . . . . . . . . . . 8-102
tion . . . . . . . . . . . . . . . . . . . 8-115 downlink level procedure . . . . . . . . 8-29
half rate carrier configuration. . . . . . . 2-42 dual band cell, single BCCH . . . . . . 5-30
handover EGSM to EGSM . . . . . . . . . . . . . 8-86
inter-BSS . . . . . . . . . . . . . . . . 1-56 ERCs . . . . . . . . . . . . . . . . . . 5-83
intra-BSS . . . . . . . . . . . . . . . . 1-59 inter-BSS
intra-BTS message sequences . . . . . . . . . . 8-48
asynchronous . . . . . . . . . . . . . 1-62 inter-BTS
synchronous . . . . . . . . . . . . . 1-62 message sequences . . . . . . . . . . 8-56
statistics in dual band . . . . . . . . . . 8-73 intra-cell . . . . . . . . . . . . . . . . 8-60
handover decision and power control power budget procedure . . . . . . . . 8-31
AMR . . . . . . . . . . . . . . . . . . 8-122 single BCCH dual band cells . . . . . . 5-30
handover decisions Handovers
power control . . . . . . . . . . . . . . . 8-3 in single BCCH dual band cells . . . . . 8-68
handovers HDSL . . . . . . . . . . . . . . . . . . . 3-33
adaptive power . . . . . . . . . . . . . 8-66 HDSL (High bit-rate Digital Subscriber
advanced load management for EGSM Line) . . . . . . . . . . . . . . . . . . . 3-33
carriers . . . . . . . . . . . . . . . . . 8-86 high power DCS1800 . . . . . . . . . . . . 5-9
criteria hopping support . . . . . . . . . . . . . 10-10
congestion relief . . . . . . . . . . . 8-36 hreqave and hreqt
directed retry . . . . . . . . . . . . . 8-36 in measurements . . . . . . . . . . . . 8-22
decision process . . . . . . . . . . . . 8-19
68P02901W36-S IX-23
Jul 2008
Index
IMRM . . . . . . . . . . . . . . . . . . . 8-88 interfaces (contd.)

in call modification A . . . . . . . . . . . . . . . . . . . . . 1-9
AMR half-rate . . . . . . . . . . . . . . 3-11 redundancy . . . . . . . . . . . . . . . 1-83
inner zone use algorithms RXCDR . . . . . . . . . . . . . . . . . 1-82
inner zone algorithms . . . . . . . . . . 5-23 WebMMI . . . . . . . . . . . . . . . . 2-117
Intelligent Multi-Layer Resource Manage- interference based algorithm
ment . . . . . . . . . . . . . . . . . . . 8-88 concentric cells . . . . . . . . . . . . . 5-71
inter-BSS handover . . . . . . . . . . . . 1-56 interleaving . . . . . . . . . . . . . . . . 1-28
inter-BSS handovers internal MTT
internal processes call clearing . . . . . . . . . . . . . . . 6-22
message sequence . . . . . . . . . . 8-48 internal parameters
inter-BTS handovers trace call
message sequences . . . . . . . . . . . 8-56 ct_flow_control_bss_enabled . . . . . . 7-5
inter_cell handovers ct_flow_control_msc_trace . . . . . . . 7-5
in single BCCH dual band cells intra-BSS handover . . . . . . . . . . . . 1-59
imperative . . . . . . . . . . . . . . 8-69 intra-BTS handover
non-imperative . . . . . . . . . . . . 8-69 asynchronous . . . . . . . . . . . . . . 1-62
interconnecting the BSC and BTSs synchronous . . . . . . . . . . . . . . 1-62
network topology intra-cell handovers . . . . . . . . . . . . 8-60
daisy chain connection . . . . . . . . 3-20 intra-cell, inter-band handovers
DYNET . . . . . . . . . . . . . . . . 3-18 in single BCCH dual band cells . . . . . 8-69
star connection . . . . . . . . . . . . 3-19 intra-cell, intra-band handovers
interfaces in single BCCH dual band cells . . . . . 8-68
Kiloport Switch and eXtension KSW and KSWX . . . . . . . . . . . . . . 2-53

(KSW and KSWX) . . . . . . . . . . . . 2-53
l_rxlev_ul_p . . . . . . . . . . . . . . . . 8-15 Link utlization improvements . . . . . . . . 4-7

LAPD parameter . . . . . . . . . . . . . 3-78 list
LAPD protocol . . . . . . . . . . . . . . 2-40 BA (GPRS) . . . . . . . . . . . . . . . 5-105
LCF . . . . . . . . . . . . . . . . . . . . 2-97 location
LCF management of GSLs . . . . . . . . 3-81 of transcoding. . . . . . . . . . . . . . 1-82
LCS Location Services (LCS). . . . . . . . . . 1-76
Location Services . . . . . . . . . . . . 1-76 location services support
linear predictive coding . . . . . . . . . . 1-11 call processing . . . . . . . . . . . . . 6-93
link control
XBL . . . . . . . . . . . . . . . . . . . 3-51
mapping packet data channels on to physical message flow

channels . . . . . . . . . . . . . . . . . 5-35 circuit error rate monitor (CERM) . . . 4-39
measurements Message Transfer Link (MTL) . . . . . . . . 3-3
hreqave and hreqt . . . . . . . . . . . 8-22 Message Transfer Part (MTP) layer 3 . . . . 3-3
Medium Access Control (MAC) layer . . . 6-73 microcellular handovers
IX-24 68P02901W36-S
Jul 2008
Index
microcellular handovers (contd.) MS flow control

Microcellular handovers . . . . . . . . 8-95 BSS links . . . . . . . . . . . . . . . . 3-67
missing report . . . . . . . . . . . . . . 8-18 MS originated packet transfer . . . . . . 6-29
MMI command data transfer processing . . . . . . . . 6-29
disp_trace_call . . . . . . . . . . . . . . 7-4 MS states . . . . . . . . . . . . . . . . . 6-26
trace_call . . . . . . . . . . . . . . . . . 7-4 data transfer processing . . . . . . . . 6-26
trace_stop . . . . . . . . . . . . . . . . . 7-4 MS terminated packet transfer . . . . . . 6-31
MMI commands data transfer processing . . . . . . . . 6-31
chg_element, chg_cell_element, disp_element MSI . . . . . . . . . . . . . . . . . . . . 2-85
in trace call . . . . . . . . . . . . . . . . 7-4 MSI-2 board with E1/T1 (feature) . . . . . 2-85
MMS on a DPROC. . . . . . . . . . . . . 2-114 MSIs on DPROCs . . . . . . . . . . . . . 2-113
Mobile Allocation (MA) . . . . . . . . . . 10-9 MTL (Message Transfer Link) . . . . . . . . 3-3
Mobile Allocation Index Offset (MAIO) . . 10-10 multi-band handover
Mobile System (MS) AMR . . . . . . . . . . . . . . . . . . 8-79
control . . . . . . . . . . . . . . . . . 5-61 multiband
modulation statistics in dual band . . . . . . . . . . 8-73
overview . . . . . . . . . . . . . . . . 1-23 multiband intercell handover
MS PGSM900, EGSM900, DCS1800,
control . . . . . . . . . . . . . . . . . 5-61 PCS1900 . . . . . . . . . . . . . . . . 8-76
extended paging . . . . . . . . . . . 5-62 multiband MS subscriber redirection . . . 8-36
handover multipath fading . . . . . . . . . . . . . 1-24
power level on path loss . . . . . . . 8-109 multiple trigger call trace events (fea-
handover power ture) . . . . . . . . . . . . . . . . . . . 7-24
path loss calculation . . . . . . . . . 8-109 multiplexing
idle time reporting . . . . . . . . . . . 1-49 radio channel . . . . . . . . . . . . . . 1-14
n and p voting. . . . . . . . . . . . . . . 8-20 Network (PLMN) Colour Code (NCC) (contd.)

nailed paths Network (PLMN) Colour Code (NCC) . . 5-13
DYNET . . . . . . . . . . . . . . . . . 3-21 Network Assisted Cell Change . . . . . . 5-94
nailing timeslots . . . . . . . . . . . . . 3-43 Network Controlled cell reselection
NC1 NC1/NC2 . . . . . . . . . . . . . . . . 5-103
Nework Controlled cell reselection and location network topology
services . . . . . . . . . . . . . . . . . 5-103 daisy chain connection . . . . . . . . . 3-20
NC2 star connection . . . . . . . . . . . . . 3-19
Network Controlled cell reselection. . . 5-103 NIU diasy chaining
NCC (Network Colour Code) DYNET . . . . . . . . . . . . . . . . . 3-35
NCC (Network Colour Code) . . . . . . 5-13 no barring emergency calls . . . . . . . . 5-64
Network (PLMN) Colour Code (NCC) NSS based SMLC . . . . . . . . . . . . . 1-78
OMC alarm blacklisting OMF (contd.)

description . . . . . . . . . . . . . . . 4-26 in GPROC function pre-emption . . . . . 2-71
OMC GUI OMF (Operation and Maintenance Func-
invoked trace list . . . . . . . . . . . . 7-20 tion). . . . . . . . . . . . . . . . . . . . 2-100
trace call . . . . . . . . . . . . . . . . 7-18 OML . . . . . . . . . . . . . . . . . . . 1-84
trace criteria setup window . . . . . . . 7-19 OML functions
trace record view window. . . . . . . . 7-20 flow control (BSC internal) . . . . . . . 7-23
trace view window . . . . . . . . . . . 7-18 flow control (OMC initiated) . . . . . . 7-23
OMC paging list out of service . . . . . . . . . . . . . . 7-21
description . . . . . . . . . . . . . . . 4-27 trace call . . . . . . . . . . . . . . . . 7-21
OMF . . . . . . . . . . . . . . . . . . . 2-100 on-line add, copy and delete cell . . . . . . 5-5
68P02901W36-S IX-25
Jul 2008
Index
OPC (Originating Point Code) . . . . . . . . 3-4 Originating Point Code (OPC) . . . . . . . . 3-4
Operation and Maintenance Function oscillation prevention for MS power
(OMF) . . . . . . . . . . . . . . . . . . . 2-100 control . . . . . . . . . . . . . . . . . . . 8-5
optimized power control . . . . . . . 1-24, 8-7
Packet Broadcast Control Channel PCU Central Authority (pCA) . . . . . . . . 4-9

(PBCCH) . . . . . . . . . . . . . . . 3-83, 6-56 PCU Configuration Management (pCM). . 4-11
Packet Common Control Channel (PC- PCU Switch Manager (pSM) . . . . . . . 4-10
CCH) . . . . . . . . . . . . . . . . . . . 6-56 Permanent Virtual Connection (PVC) . . . 3-63
configuration . . . . . . . . . . . . . . 3-83 pFCP software process . . . . . . . . . . 4-11
Packet Random Access Channel (PRACH) pFTP software process . . . . . . . . . . 4-11
mapping . . . . . . . . . . . . . . . . . 6-62 physical layer (GPRS) . . . . . . . . . . . 6-77
paging channels GPRS ping-pong . . . . . . . . . . . . . . . . . 8-126
CS/PS . . . . . . . . . . . . . . . . . . 6-63 PLMN . . . . . . . . . . . . . . . . . . . 5-13
parameter power based algorithm
band_preference_mode . . . . . . . . . 5-26 concentric cells . . . . . . . . . . . . . 5-70
dual_band_pbgt_mode . . . . . . . . . 8-69 power budget assessment. . . . . . . . . 8-26
second assignment . . . . . . . . . . . 5-45 power budget equation . . . . . . . . . . 8-69
parameters power budget handover procedure . . . . 8-31
dual band cell, single BCCH . . . . . . 5-30 power control . . . . . . . . . . . . . . . . 8-3
single BCCH dual band cell . . . . . . . 5-30 GPRS . . . . . . . . . . . . . . . . . . . 8-8
PATH . . . . . . . . . . . . . . . . . . . 3-41 optimized . . . . . . . . . . . . . . . . . 8-7
path loss calculation preferred number of SDCCH . . . . . . . 5-62
MS handover power. . . . . . . . . . . 8-109 preserve RCU calibration . . . . . . . . . 4-20
path loss calculations clear data . . . . . . . . . . . . . . . . 4-21
MS handover power level . . . . . . . . 8-109 display data . . . . . . . . . . . . . . . 4-20
PBCCH examples . . . . . . . . . . . . . . . 4-22
Packet Broadcast Control Channel . . . 1-18 exchange data . . . . . . . . . . . . . 4-21
PBCCH/PCCCH feature store data . . . . . . . . . . . . . . . . 4-20
timeslot allocation . . . . . . . . . . . 6-56 primary alarm. . . . . . . . . . . . . . . 4-31
pCA software process . . . . . . . . . . . . 4-9 prioritization
pCM software process . . . . . . . . . . 4-11 extended range cells (ERC) . . . . . . . 8-38
PCS1900 process description
frequency band . . . . . . . . . . . 1-13, 5-10 software
frequency blocks . . . . . . . . . . . . 5-10 BSS . . . . . . . . . . . . . . . . . . . 4-2
PCU processes
fault management process software
pFTP and pFCP . . . . . . . . . . . . 4-11 BSS . . . . . . . . . . . . . . . . . . . 4-2
site . . . . . . . . . . . . . . . . . . . 2-103 PCU . . . . . . . . . . . . . . . . . . . 4-9
software functions . . . . . . . . . . . . 4-9 pSM software process. . . . . . . . . . . 4-10
software processes . . . . . . . . . . . . 4-9 PVC . . . . . . . . . . . . . . . . . . . . 3-63
QBAND . . . . . . . . . . . . . . . . 6-85, 8-16 quality measurement (contd.)

quality BER and QBAND . . . . . . . . . . 6-85, 8-16
worst . . . . . . . . . . . . . . . . . . 8-38 queue management . . . . . . . . . . . . 5-45
quality and signal strength queuing
in handover decisions . . . . . . . . . . 8-23 SDCCH . . . . . . . . . . . . . . . . . 5-46
quality measurement TCH . . . . . . . . . . . . . . . . . . . 5-45
IX-26 68P02901W36-S
Jul 2008
Index
radio channel bit rate . . . . . . . . . . . 1-13 related commands and parameters (contd.)
Radio Link Control (RLC) layer . . . . . . 6-68 RX quality measurements . . . . . . . . 8-17
Radio platform operational require- SDCCH handovers . . . . . . . . . . . 8-107
ments . . . . . . . . . . . . . . . . . . . 2-12 second assignment
Radio Signalling Link (RSL) . . . . . . . . 3-48 channel allocation. . . . . . . . . . . 5-45
Radio Sub-System (RSS) . . . . . . . . . 4-16 short message service. . . . . . . . . . 5-89
Abis interface . . . . . . . . . . . . . . 4-17 timeslot connectivity . . . . . . . . . . 7-27
function and interfaces . . . . . . . . . 4-16 timeslot reservation . . . . . . . . . . . 3-45
radio_chan_released trace call . . . . . . . . . . . . . . . . . 7-4
call clearing . . . . . . . . . . . . . . . 6-22 related features
rapid_pwr_down . . . . . . . . . . . . . 8-15 all channels at full power . . . . . . . . 8-12
receive quality measurement reporting . . 8-16 BA lists . . . . . . . . . . . . . . . . . 8-44
redirection coincident multiband handovers . . 8-85, 8-87
multiband MS subscriber . . . . . . . . 8-36 directed retry . . . . . . . . . . . . . . 8-87
redundancy flexible neighbour cell processing
DYNET . . . . . . . . . . . . . . . . . 3-25 feature . . . . . . . . . . . . . . . . . 8-94
interfaces . . . . . . . . . . . . . . . . 1-83 handover decision process . . . . . . . 8-42
related commands and parameters multiband intercell handover . . . . . . 8-78
adaptive power handovers . . . . . . . 8-66 multiband intercell handovers . . . . . 8-87
all channels at full power . . . . . . . . 8-12 power control . . . . . . . . . . . . . . 8-10
audio volume at GDP . . . . . . . . . . 4-58 RX quality handovers . . . . . . . . . . 8-47
BA lists . . . . . . . . . . . . . . . . . 8-44 SDCCH handovers . . . . . . . . . . . 8-108
call processing setup . . . . . . . . . . 6-18 reserving timeslots . . . . . . . . . . . . 3-43
call quality monitoring . . . . . . . . . 6-86 reset and clear database
call reestablishment. . . . . . . . . . . 5-66 BSS . . . . . . . . . . . . . . . . . . . . 4-6
cell barring . . . . . . . . . . . . . . . 5-64 resync
channel configuration description . . . . . . . . . . . . . . . 4-28
channel allocation. . . . . . . . . . . 5-44 resyncAlarm . . . . . . . . . . . . . . 4-29
channel release . . . . . . . . . . . . . 5-49 resyncState . . . . . . . . . . . . . . . 4-28
coincident multiband handovers . . . . 8-85 when to perform . . . . . . . . . . . . 4-28
concentric cells . . . . . . . . . . . . . 5-73 rf_chan_rel_ack
congestion relief . . . . . . . . . . . . 8-114 call clearing . . . . . . . . . . . . . . . 6-22
discontinuous transmission . . . . . . . 5-81 rpd_offset . . . . . . . . . . . . . . . . . 8-15
E1/T1 link management . . . . . . . . . 3-60 rpd_trigger . . . . . . . . . . . . . . . . 8-15
EGSM RPE-LTP
frequency types . . . . . . . . . . . . . 5-9 RPE?LTP . . . . . . . . . . . . . . . . 1-27
encryption . . . . . . . . . . . . . . . 5-77 rr_t3109
enhanced XBL. . . . . . . . . . . . . . 3-57 call clearing . . . . . . . . . . . . . . . 6-22
flexible neighbour cell processing rr_t3111
feature . . . . . . . . . . . . . . . . . 8-94 call clearing . . . . . . . . . . . . . . . 6-22
flow control . . . . . . . . . . . . . . . 5-57 RSL (Radio Signalling Link) . . . . . . . . 3-48
frequency hopping . . . . . . . . . . . 10-9 RTF . . . . . . . . . . . . . . . . . . . . 2-36
GPRS resource queuing fully equipped . . . . . . . . . . . . . . 2-37
channel allocation. . . . . . . . . . . 5-47 configurations. . . . . . . . . . . . . 2-39
GSM850 sub-equipped . . . . . . . . . . . . . . 2-39
frequency types . . . . . . . . . . . . . 5-7 RXCDR
handover decision process . . . . . . . 8-39 functions . . . . . . . . . . . . . . . . . 1-4
microcell handovers. . . . . . . . . . . 8-104 interfaces . . . . . . . . . . . . . . . . 1-82
missing report function . . . . . . . . . 8-18 links
MS handover power level path loss . . . 8-112 OML . . . . . . . . . . . . . . . . . 1-84
online add, copy, delete cell . . . . . . . . 5-6 XBL . . . . . . . . . . . . . . . . . . 1-84
PCS1900 overview . . . . . . . . . . . . . . . . 1-83
frequency types . . . . . . . . . . . . 5-11 traffic flow
power control . . . . . . . . . . . . . . . 8-9 downlink . . . . . . . . . . . . . . . 1-85
RX quality handovers . . . . . . . . . . 8-46 uplink . . . . . . . . . . . . . . . . . 1-85
68P02901W36-S IX-27
Jul 2008
Index
RXCDR connectivity verification . . . . . 3-55 RXU shelf modules

RXCDR/BSC validation overview . . . . . . . . . . . . . . . . 1-83
XBL . . . . . . . . . . . . . . . . . . . 3-51
save alarm context, buffer . . . . . . . . 4-29 star connection

sccp_released DYNET . . . . . . . . . . . . . . . . . 3-19
call clearing . . . . . . . . . . . . . . . 6-22 statistics
SDCCH concentric cells . . . . . . . . . . . . . 5-73
preferred number . . . . . . . . . . . . 5-62 useful in single BCCH dual band cells. . 8-71
SDCCH handovers statistics reporting software . . . . . . . . 4-6
intracell handover. . . . . . . . . . . . 8-106 switchable PDTCH
SDCCH queuing. . . . . . . . . . . . . . 5-46 AMR . . . . . . . . . . . . . . . . . . 5-37
SDCCH to TCH assignment for multiband MSs synchronization
handovers . . . . . . . . . . . . . . . . 8-106 GCLK . . . . . . . . . . . . . . . . . . 2-61
second assignment . . . . . . . . . . . . 5-44 Synthesizer hopping . . . . . . . . . . . 10-2
second_asgnmnt parameter . . . . . . . . 5-45 SYSGEN software process . . . . . . . . . 4-6
secondary alarms . . . . . . . . . . . . . 4-31 system impact
separate BA lists . . . . . . . . . . . . . 8-43 all channels at full power . . . . . . . . 8-12
Serving Mobile Location Center. . . . . . 1-78 BA lists . . . . . . . . . . . . . . . . . 8-44
Short Message Service (SMS). . . . . . . 1-17 call processing setup . . . . . . . . . . 6-18
cell broadcast call quality monitoring . . . . . . . . . 6-86
point to point . . . . . . . . . . . . . 5-86 call trace . . . . . . . . . . . . . . . . . 7-5
signalling link cell barring . . . . . . . . . . . . . . . 5-65
call processing . . . . . . . . . . . . . 1-45 channel configuration
Signalling Link Selection (SLC) . . . . . . . 3-4 channel allocation. . . . . . . . . . . 5-44
Signalling Point Codes (SPCs). . . . . . . . 3-3 circuit error rate monitor . . . . . . . . 4-42
single BCCH dual band cell coincident multiband handovers . . . . 8-85
parameters . . . . . . . . . . . . . . . 5-30 concentric cells . . . . . . . . . . . . . 5-73
single BCCH dual band cell handovers . . 5-30 discontinuous transmission . . . . . . . 5-81
single BCCH dual band cells DYNET . . . . . . . . . . . . . . . . . 3-27
handovers . . . . . . . . . . . . . . . . 8-68 encryption . . . . . . . . . . . . . . . 5-78
statistics used . . . . . . . . . . . . . . 8-71 flow control . . . . . . . . . . . . . . . 5-58
single BCCH for dual band cells . . . 5-17, 5-21 handover decision process . . . . . . . 8-41
feature dependencies . . . . . . . . . . 5-22 HDSL . . . . . . . . . . . . . . . . . . 3-40
SLS (Signalling Link Selection) . . . . . . . 3-4 high power DCS1800
SMLC . . . . . . . . . . . . . . . . . . . 1-78 frequency types . . . . . . . . . . . . 5-10
software functions microcell handovers. . . . . . . . . . . 8-105
BSS . . . . . . . . . . . . . . . . . . . . 4-4 multiband intercell handover . . . . . . 8-78
PCU . . . . . . . . . . . . . . . . . . . . 4-9 online add, copy, delete cell . . . . . . . . 5-6
software process PCS1900
SYSGEN . . . . . . . . . . . . . . . . . 4-6 frequency types . . . . . . . . . . . . 5-11
SPC power control . . . . . . . . . . . . . . 8-10
Signalling Point Code . . . . . . . . . . . 3-3 RX quality handovers . . . . . . . . . . 8-46
SSN7 (CCITT Signalling System Number SDCCH handovers . . . . . . . . . . . 8-107
7) . . . . . . . . . . . . . . . . . . . . . . 3-3 short message service. . . . . . . . . . 5-90
SSN7 MTP layer 3 . . . . . . . . . . . . . 3-3
T1 link TBF . . . . . . . . 6-32, 6-72, 6-77 to 6-78, 6-87

definition . . . . . . . . . . . . . . . . . 1-9 downlink release delay . . . . . . . . . 6-37
tagged alarm format . . . . . . . . . . . 4-31 TCH flow control
IX-28 68P02901W36-S
Jul 2008
Index
TCH flow control (contd.) trace call functions (contd.)

AMR . . . . . . . . . . . . . . . . . . 5-59 preserving BSS resource for MSC
TCH queuing . . . . . . . . . . . . . . . 5-45 traces . . . . . . . . . . . . . . . . . . . 7-3
TDM timeslot allocation . . . . . . . . . . 2-90 trace call triggering and sending data to the
TDM timeslot labelling . . . . . . . . . . 3-46 OMC . . . . . . . . . . . . . . . . . . . 7-10
TDMA trace tailoring . . . . . . . . . . . . . . . 7-12
overview . . . . . . . . . . . . . . . . 1-20 trace_msgs_after_ho . . . . . . . . . . . . 7-5
terrestrial backhaul resources trace_msgs_before_ho. . . . . . . . . . . . 7-5
allocating . . . . . . . . . . . . . . . . 3-23 trace_stop command . . . . . . . . . . . . 7-4
terrestrial circuit device management traffic control . . . . . . . . . . . . . . . 5-64
CIC devices . . . . . . . . . . . . . . . . 3-8 traffic flow
throttling . . . . . . . . . . . . . . . . . 4-29 RXCDR
time functions downlink . . . . . . . . . . . . . . . 1-85
stamping . . . . . . . . . . . . . . . . . 4-6 uplink . . . . . . . . . . . . . . . . . 1-85
timeslot allocation Training Sequence Code (TSC)
PBCCH/PCCCH . . . . . . . . . . . . . 6-56 changing . . . . . . . . . . . . . . . . 5-14
timeslots transcoding . . . . . . . . . . . . . . . . 1-82
connectivity . . . . . . . . . . . . . . . 7-27 location . . . . . . . . . . . . . . . . . 1-82
reservation . . . . . . . . . . . . . . . 3-43 transcoding function . . . . . . . . . . . 1-82
timing advance RXCDR description . . . . . . . . . . . 1-83
circuit switched . . . . . . . . . . . . . 6-89 RXCDR interfaces . . . . . . . . . . . . 1-82
packet switched . . . . . . . . . . . . . 6-89 RXU shelf modules . . . . . . . . . . . 1-83
trace call transcoding . . . . . . . . . . . . . . . 1-82
contained information. . . . . . . . . . 7-25 transmission
CTP GUI . . . . . . . . . . . . . . . . 7-26 coded . . . . . . . . . . . . . . . . . . 1-11
flow control . . . . . . . . . . . . . . . 7-21 TSC (Training Sequence Code)
OML functions . . . . . . . . . . . . . 7-21 changing . . . . . . . . . . . . . . . . 5-14
product utilities . . . . . . . . . . . . . 7-26 type 0 BTS . . . . . . . . . . . . . . . . 2-11
suggestions . . . . . . . . . . . . . . . . 7-6 type 1 BSC . . . . . . . . . . . . . . . . . 2-6
trace call functions . . . . . . . . . . . . . 7-2 type 1 BTS . . . . . . . . . . . . . . . . 2-11
forwarding trace call data to the NMC . . 7-3 type 2 BSC . . . . . . . . . . . . . . . . . 2-7
untagged alarm format . . . . . . . . . . 4-30
Versa-TRAU . . . . . . . . . . . . . . . . 3-30 voting

Voice Activity Detector (VAD) n and p . . . . . . . . . . . . . . . . . 8-20
Voice Activity Detector . . . . . . . . . 5-80
WebMMI WebMMI (contd.)

BSS requirements. . . . . . . . . . . . 2-116 operation . . . . . . . . . . . . . . . . 2-115
function . . . . . . . . . . . . . . . . . 2-115 PC requirements . . . . . . . . . . . . 2-116
interfaces . . . . . . . . . . . . . . . . 2-117 worst quality . . . . . . . . . . . . . . . 8-38
68P02901W36-S IX-29
Jul 2008
Index
XBL . . . . . . . . . . . . . . . . . . . . 1-84 XBL alarms . . . . . . . . . . . . . . . . 3-57

16 kbps . . . . . . . . . . . . . . . . . 3-50 XBL verification . . . . . . . . . . . . . . 3-55
BSC/RXCDR validation . . . . . . . . . 3-51 XCDR and RXCDR. . . . . . . . . . . . . 2-16
DARBC validation . . . . . . . . . . . . 3-52
link control . . . . . . . . . . . . . . . 3-51
IX-30 68P02901W36-S
Jul 2008

68P02901W36

Uploaded by

Document Information

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

68P02901W36

Uploaded by

Copyright:

Available Formats

BSS Implementation

2008 Motorola, Inc. All Rights Reserved.

Technical Description: BSS Implementation

Chapter 1: BSS Functional Description

Transmission systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9

Synchronized intra-BTS handover process . . . . . . . . . . . . . . . . . . . . . . . . . . 1-63

Related commands and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-97

Chapter 2: BSS Devices and Functions

DRI pairing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-33

Base Transceiver Processor (BTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-77

GPRS Packet Control Unit (PCU). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-101

Chapter 3: BSS Links

Improved load-sharing of traffic on MTLs . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4

BVC and MS flow control mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-66

Chapter 4: BSS Software Processes

Statistics generation and reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6

Common control channel group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17

Related commands and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-66

Chapter 6: Call Processing

GPRS switchable timeslot function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-51

Channel information elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-110

Chapter 7: Tracing Calls and Connectivity

Call trace product utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-26

Chapter 8: Power and Handover Control

Intra-Cell handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-60

Half Rate congestion relief procedure interaction . . . . . . . . . . . . . . . . . . . . . . 8-115

Chapter 9: EGPRS and GPRS Power Control

Chapter 10: Frequency Hopping

Synthesizer Frequency Hopping (SFH) . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2

Chapter 11: BSS Inter-Radio Access Technology Handover

Figure 1-1: BSS with BSC transcoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

Figure 2-14: Kiloport switch data layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-54

Figure 5-15: Interference based algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-72

Figure 7-3: BSS level RF failure trace call events . . . . . . . . . . . . . . . . . . . . . . . . 7-17

Figure 9-20: Uplink C/I based coding scheme selection . . . . . . . . . . . . . . . . . . . . . 9-37

Table 1-1: Coding and transmission system comparison . . . . . . . . . . . . . . . . . . . . . 1-4

Table 4-4: Packet Flow contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-47

Technical Description: BSS Implementation

What is covered in this manual?

Chapter 1 BSS Functional Description.

Chapter 2 BSS Devices and Functions.

Chapter 3 BSS Links.

Chapter 4 BSS Software Processes.

Chapter 6 Call Processing.

Chapter 7 Tracing Calls and Connectivity.

Chapter 8 Power and Handover Control.

Chapter 9 EGPRS and GPRS Power Control.

Chapter 10 Frequency Hopping.

Chapter 11 BSS Inter-Radio Access Technology Handover.

The following sections show the revision status of this document.

Issue Date of issue Remarks

Resolution of Service Requests

The following Service Requests are resolved in this document:

Service Request CMBP Number Remarks

Incorporation of Change Notices

The following Change Notices (CN) are incorporated in this document:

CN Date CN Number Title

Characters typed in at the keyboard are shown like this sentence.

Messages, prompts, file listings, directories, utilities, and environmental

Special key sequences

Special key sequences are represented as follows:

Motorola appreciates feedback from the users of our documents.

Questions and comments

The document title, part number, and revision character