About AMR

BSS Equipment Planning
System Information
GSR10
68P02900W21-T
2010 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.
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 2010
Table
of
Contents
Contents
System Information: BSS Equipment Planning

Revision history . . . . . . . . . . . .
Version information . . . . . . . .
Release information . . . . . . . .
Resolution of Service Requests . .
General information . . . . . . . . . .
Purpose . . . . . . . . . . . . . .
Cross references . . . . . . . . . .
Document banner definitions . . .
Text conventions . . . . . . . . . .
Contacting Motorola . . . . . . . . . .
24hour support . . . . . . . . . .
Ordering documents and CD-ROMs
Questions and comments . . . . .
Errors . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
2
2
3
3
3
3
4
5
5
5
5
5
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
Link)
. . .
. . .
. . .
. . .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1-2
1-2
1-2
1-4
1-4
1-5
1-11
1-11
1-12
1-12
1-13
1-13
1-14
1-14
1-15
1-16
1-17
1-18
1-19
1-19
1-20
1-20
1-22
1-23
1-23
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Chapter 1: Introduction to planning

Manual overview . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . .
Contents . . . . . . . . . . . . . . . . . . . . . . . . .
BSS equipment overview. . . . . . . . . . . . . . . . . . .
System architecture . . . . . . . . . . . . . . . . . . .
System components . . . . . . . . . . . . . . . . . . .
BSS features . . . . . . . . . . . . . . . . . . . . . . . . .
Planning impacts. . . . . . . . . . . . . . . . . . . . .
Diversity . . . . . . . . . . . . . . . . . . . . . . . . .
Frequency hopping . . . . . . . . . . . . . . . . . . .
Short Message Service, Cell Broadcast (SMS CB) . . . .
Code Storage Facility Processor (CSFP) . . . . . . . . .
PCU for GPRS upgrade . . . . . . . . . . . . . . . . .
Enhanced-GPRS (EGPRS) . . . . . . . . . . . . . . . .
Adaptive Multi-Rate (AMR) . . . . . . . . . . . . . . .
GSM half rate . . . . . . . . . . . . . . . . . . . . . .
LoCation Services (LCS) . . . . . . . . . . . . . . . . .
IOS (Intelligent Optimization Service)/OPL (Optimization
BSC Reset Management (BRM) . . . . . . . . . . . . .
Advanced Speech Call Item (ASCI). . . . . . . . . . . .
VersaTRAU backhaul for EGPRS . . . . . . . . . . . . .
Quality of Service (QoS) . . . . . . . . . . . . . . . . .
QoS2 . . . . . . . . . . . . . . . . . . . . . . . . . . .
Increased Network Capacity (Huge BSC) . . . . . . . .
Improved Timeslot Sharing (ITS) . . . . . . . . . . . .
68P02900W21-T
Jul 2010
Contents
Enhanced BSC capacity using DSW2 . . . . . . . . . . . . .

High Speed MTL . . . . . . . . . . . . . . . . . . . . . . . .
Addition of new BSC/PCU software (PXP) and hardware (PSI2)
(ePCU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
High bandwidth interconnect between BSC and PCU (PSI2) . .
CTU2D . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96 MSIs . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Support usage of idle TCH for burst packet traffic . . . . . . .
Extended Range Cell for Data . . . . . . . . . . . . . . . . .
Horizon II Site Controller-2 . . . . . . . . . . . . . . . . . .
CTU8m and RCTU8m feature . . . . . . . . . . . . . . . . .
CTU8m and RCTU8m 8 carrier support . . . . . . . . . . . .
Increase RSL-LCF capacity on GPROC3/GPROC3-2 . . . . . .
SGSN(Gb) interface using Ethernet (Gb over IP). . . . . . . .
PA bias feature in Horizon II sites with mixed radios. . . . . .
BBU-E 8/8/8 CTU8m HR EPG impact . . . . . . . . . . . . .
Support large site 12/12/12 for GSR program . . . . . . . . .
Increased Network Capacity (1000TRX BSC) enhancement . .
EGPRS Enhancement . . . . . . . . . . . . . . . . . . . . .
Porting Horizon II Site Controller 2 to GSR9. . . . . . . . . .
BSS planning overview. . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .
Background information . . . . . . . . . . . . . . . . . . . .
Planning methodology . . . . . . . . . . . . . . . . . . . . .
Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Acronym list . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . .
. . . . . .
to increase
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . . . .
. . . . . . . .
GPRS capacity
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
.
.
1-24
1-24
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1-24
1-24
1-24
1-26
1-26
1-27
1-28
1-29
1-31
1-32
1-32
1-33
1-34
1-34
1-35
1-35
1-36
1-37
1-37
1-37
1-39
1-40
1-40
Chapter 2: Transmission systems

BSS interfaces . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . .
Interconnecting the BSC and BTSs . . . . . . .
Introduction . . . . . . . . . . . . . . . . .
Interconnection rules . . . . . . . . . . . .
Network topology . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . .
Star connection . . . . . . . . . . . . . . .
Daisy chain connection . . . . . . . . . . .
Daisy chain planning . . . . . . . . . . . . .
Aggregate Abis. . . . . . . . . . . . . . . .
RTF path fault containment . . . . . . . . .
16 kbps XBL . . . . . . . . . . . . . . . . .
Dynamic allocation of RXCDR to BSC circuits
Managed HDSL on micro BTSs . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . .
Integrated HDSL interface . . . . . . . . . .
General HDSL guidelines . . . . . . . . . .
Microcell system planning . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
(DARBC)
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2-2
2-2
2-4
2-4
2-4
2-6
2-6
2-7
2-8
2-8
2-10
2-15
2-20
2-21
2-24
2-24
2-24
2-26
2-27
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3-3
3-3
3-4
3-4
3-4
3-5
3-5
Chapter 3: BSS cell planning

Planning tools . . . .
Introduction . . .
Traffic capacity . . .
Dimensioning . .
Channel blocking
Traffic flow. . . .
Grade of service .
ii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
68P02900W21-T
Jul 2010
Adaptive multi-rate (AMR) . . . . . . . . . . . . . . . . . . . . . . .

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Capacity and coverage . . . . . . . . . . . . . . . . . . . . . . .
Quality of service . . . . . . . . . . . . . . . . . . . . . . . . .
Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Migration to AMR half rate . . . . . . . . . . . . . . . . . . . .
Interoperability with GSM half rate . . . . . . . . . . . . . . . .
Interoperability with EGPRS . . . . . . . . . . . . . . . . . . . .
GSM half rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Capacity and coverage . . . . . . . . . . . . . . . . . . . . . . .
Quality of service . . . . . . . . . . . . . . . . . . . . . . . . .
Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Migration to half rate . . . . . . . . . . . . . . . . . . . . . . .
Interoperability with AMR half rate . . . . . . . . . . . . . . . .
Interoperability with EGPRS . . . . . . . . . . . . . . . . . . . .
Channel coding schemes . . . . . . . . . . . . . . . . . . . . . . . .
Channel coding scheme 1 (CS1) . . . . . . . . . . . . . . . . . .
16/32 kbps TRAU . . . . . . . . . . . . . . . . . . . . . . . . .
EGPRS channel coding schemes . . . . . . . . . . . . . . . . . .
64 kbps TRAU for EGPRS . . . . . . . . . . . . . . . . . . . . .
Link adaptation (LA) in GPRS/EGPRS . . . . . . . . . . . . . . .
Subscriber environment . . . . . . . . . . . . . . . . . . . . . . . .
Subscriber hardware. . . . . . . . . . . . . . . . . . . . . . . .
Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hand portable subscribers . . . . . . . . . . . . . . . . . . . . .
Future planning . . . . . . . . . . . . . . . . . . . . . . . . . .
Microcellular solution . . . . . . . . . . . . . . . . . . . . . . . . .
Layered architecture. . . . . . . . . . . . . . . . . . . . . . . .
Combined cell architecture . . . . . . . . . . . . . . . . . . . .
Combined cell architecture structure . . . . . . . . . . . . . . .
Expansion solution . . . . . . . . . . . . . . . . . . . . . . . . .
Frequency planning . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rules for Synthesizer Frequency Hopping (SFH) . . . . . . . . .
Rules for BaseBand Hopping (BBH) . . . . . . . . . . . . . . . .
Inter-radio access technology (2G-3G) cell reselection and handovers .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2G-3G handover description . . . . . . . . . . . . . . . . . . . .
Impact of 2G-3G handovers on GSM system architecture . . . . .
System consideration . . . . . . . . . . . . . . . . . . . . . . .
TD-SCDMA and GSM interworking feature . . . . . . . . . . . . . .
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . .
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Call model parameters for capacity calculations . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Typical call parameters . . . . . . . . . . . . . . . . . . . . . .
Control channel calculations . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning considerations . . . . . . . . . . . . . . . . . . . . . .
Combined BCCH . . . . . . . . . . . . . . . . . . . . . . . . . .
Number of CCCHs and PCCCHs per BTS cell . . . . . . . . . . .
User data capacity on the PCCCH timeslot . . . . . . . . . . . .
68P02900W21-T
Jul 2010
Contents
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3-6
3-6
3-6
3-7
3-8
3-9
3-9
3-9
3-10
3-10
3-10
3-11
3-11
3-12
3-12
3-12
3-13
3-13
3-14
3-15
3-16
3-17
3-18
3-28
3-29
3-30
3-30
3-30
3-31
3-32
3-33
3-34
3-34
3-35
3-35
3-36
3-38
3-38
3-38
3-42
3-44
3-44
3-44
3-45
3-46
3-47
3-47
3-47
3-47
3-48
3-48
3-48
3-52
3-52
3-53
3-54
3-55
3-65
iii
Contents
Number of SDCCHs per BTS cell . . . . . . . . . . . . . . . .

Control channel configurations . . . . . . . . . . . . . . . . .
GPRS/EGPRS traffic planning . . . . . . . . . . . . . . . . . . . .
Determination of expected load . . . . . . . . . . . . . . . . .
Network planning flow . . . . . . . . . . . . . . . . . . . . . .
GPRS/EGPRS network traffic estimation and key concepts . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dynamic timeslot allocation . . . . . . . . . . . . . . . . . . .
Carrier timeslot allocation examples . . . . . . . . . . . . . . .
BSS timeslot allocation methods . . . . . . . . . . . . . . . . .
Recommendation for switchable timeslot usage . . . . . . . . .
Timeslot allocation process on carriers with GPRS traffic . . . .
GPRS/EGPRS air interface planning process . . . . . . . . . . . . .
Influential factors in GPRS/EGPRS cell planning and deployment
Estimating the air interface traffic throughput. . . . . . . . . .
Select a cell plan . . . . . . . . . . . . . . . . . . . . . . . . .
Estimating timeslot provisioning requirements . . . . . . . . .
Configurable initial coding scheme . . . . . . . . . . . . . . .
GPRS/EGPRS data rates . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3-66
3-69
3-73
3-73
3-73
3-74
3-74
3-76
3-83
3-91
3-93
3-95
3-96
3-96
3-107
3-108
3-109
3-117
3-118
Chapter 4: AMR and GSM half-rate planning

Introduction to AMR and GSM planning . . . . . . . .
AMR basic operation . . . . . . . . . . . . . . . .
GSM half rate basic operation . . . . . . . . . . .
AMR and GSM half rate interaction . . . . . . . .
New hardware . . . . . . . . . . . . . . . . . . .
Influencing factors . . . . . . . . . . . . . . . . .
Planning . . . . . . . . . . . . . . . . . . . . . .
Quality and capacity . . . . . . . . . . . . . . . . . .
Benefits of AMR . . . . . . . . . . . . . . . . . .
AMR Full Rate and AMR Half Rate speech quality .
AMR voice quality improvement and coverage . . .
Benefits of GSM half rate . . . . . . . . . . . . .
GSM Half Rate speech quality . . . . . . . . . . .
Capacity increase due to half rate usage . . . . . .
Timeslot usage . . . . . . . . . . . . . . . . . . .
Miscellaneous information . . . . . . . . . . . . . . .
Emergency call handling . . . . . . . . . . . . . .
Circuit pooling . . . . . . . . . . . . . . . . . . .
Half rate utilization . . . . . . . . . . . . . . . . . .
Description . . . . . . . . . . . . . . . . . . . .
Parameter descriptions . . . . . . . . . . . . . .
Operational aspects . . . . . . . . . . . . . . . .
Hardware . . . . . . . . . . . . . . . . . . . . . . .
Equipment descriptions . . . . . . . . . . . . . .
Backhaul . . . . . . . . . . . . . . . . . . . . . .
Summary. . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4-2
4-2
4-2
4-3
4-3
4-3
4-4
4-5
4-5
4-5
4-9
4-10
4-11
4-11
4-14
4-16
4-16
4-16
4-17
4-17
4-17
4-23
4-26
4-26
4-28
4-32
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-2
5-2
5-3
5-4
5-4
5-5
5-6
Chapter 5: BTS planning steps and rules

BTS planning overview. . . . . . . . . . .
Introduction . . . . . . . . . . . . . .
Outline of planning steps . . . . . . .
Macrocell cabinets . . . . . . . . . . . . .
Horizon II macro . . . . . . . . . . . .
Horizonmacro . . . . . . . . . . . . .
Horizoncompact and Horizoncompact2
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
68P02900W21-T
Jul 2010
M-Cell6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
M-Cell2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Microcell enclosures . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Horizon II mini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Horizonmicro and Horizonmicro2 . . . . . . . . . . . . . . . . . . . .
Horizon II micro . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Receive configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . .
Transmit configurations . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transmit planning actions . . . . . . . . . . . . . . . . . . . . . . . .
EGPRS enabled CTU2/CTU2D configuration . . . . . . . . . . . . . . . . .
EGPRS enabled CTU2/CTU2D configuration limitations . . . . . . . . .
EGPRS general configuration . . . . . . . . . . . . . . . . . . . . . .
BaseBand Hopping (BBH) . . . . . . . . . . . . . . . . . . . . . . . .
Broadcast Control CHannel (BCCH) RTF configuration . . . . . . . . .
Carrier equipment (transceiver unit). . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Restrictions in CTU2s usage in Horizonmacro BTSs . . . . . . . . . . .
CTU/CTU2 power supply considerations . . . . . . . . . . . . . . . . .
Transceiver planning actions . . . . . . . . . . . . . . . . . . . . . .
Micro base control unit (microBCU) . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MicroBCU planning actions . . . . . . . . . . . . . . . . . . . . . . .
Network interface unit (NIU) and site connection . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NIU planning actions . . . . . . . . . . . . . . . . . . . . . . . . . .
BTS main control unit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning considerations Horizon II macro/Horizon II mini as expansion
Planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cabinet interconnection . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Horizon II mini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning considerations - Horizon II macro as master cabinet . . . . . .
Planning considerations - Horizon II mini as master cabinet . . . . . . .
XMUX/FMUX/FOX planning actions . . . . . . . . . . . . . . . . . . .
Site expansion board planning actions (Horizon II macro only) . . . . .
Battery back-up provisioning. . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
External power requirements . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Power planning actions . . . . . . . . . . . . . . . . . . . . . . . . .
Network expansion using macro/microcell BTSs . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Expansion considerations . . . . . . . . . . . . . . . . . . . . . . . .
Mixed site utilization. . . . . . . . . . . . . . . . . . . . . . . . . . .
Line interface modules (HIM-75, HIM-120) . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68P02900W21-T
Jul 2010
Contents
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
cabinet
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-6
5-7
5-8
5-8
5-9
5-9
5-11
5-11
5-11
5-14
5-14
5-14
5-17
5-18
5-18
5-18
5-18
5-19
5-20
5-20
5-21
5-21
5-23
5-24
5-25
5-25
5-25
5-25
5-26
5-26
5-26
5-28
5-29
5-29
5-30
5-31
5-32
5-33
5-33
5-34
5-34
5-36
5-37
5-37
5-37
5-38
5-38
5-38
5-39
5-39
5-39
5-40
5-41
5-41
5-41
5-41
5-42
5-42
Contents
Planning considerations . . . . . . . . . . . .
HIM-75/HIM-120 planning actions . . . . . . .
DRI/Combiner operability components . . . . . . .
Overview. . . . . . . . . . . . . . . . . . . .
DRI and combiner relationship. . . . . . . . .
CTU8m D4+ Link . . . . . . . . . . . . . . . . .
Overview. . . . . . . . . . . . . . . . . . . .
Supported topologies . . . . . . . . . . . . .
Link selection . . . . . . . . . . . . . . . . .
Recommended D4+ configurations (CTU8m) .
Recommended D4+ configurations (RCTU8m) .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-42
5-42
5-43
5-43
5-43
5-44
5-44
5-45
5-51
5-55
5-58
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
BTS E1
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-3
6-3
6-3
6-4
6-6
6-6
6-6
6-7
6-7
6-9
6-10
6-10
6-10
6-11
6-11
6-14
6-18
6-20
6-22
6-22
6-22
6-23
6-24
6-24
6-27
6-27
6-28
6-31
6-32
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-33
6-37
6-37
6-37
6-38
6-40
6-41
6-43
6-43
6-44
6-44
6-45
6-45
6-45
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Chapter 6: BSC planning steps and rules

BSC planning overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mixing of equipment types . . . . . . . . . . . . . . . . . . . . . . . . . .
Outline of planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Capacity calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remote transcoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BSC system capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System capacity summary . . . . . . . . . . . . . . . . . . . . . . . . . .
Scalable BSC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enhanced BSC capacity option. . . . . . . . . . . . . . . . . . . . . . . .
Huge BSC capacity option . . . . . . . . . . . . . . . . . . . . . . . . . .
LCS option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Determining the required BSS signaling link capacities . . . . . . . . . . . . .
BSC signaling traffic model . . . . . . . . . . . . . . . . . . . . . . . . .
Typical parameter values . . . . . . . . . . . . . . . . . . . . . . . . . .
Assumptions used in capacity calculations . . . . . . . . . . . . . . . . . .
Link capacities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Determining the number of RSLs required . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . .
Determining the number of RSLs . . . . . . . . . . . . . . . . . . . . . .
One phase access and enhanced one phase . . . . . . . . . . . . . . . . .
Standard traffic model . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Non-standard traffic model . . . . . . . . . . . . . . . . . . . . . . . . .
With one phase access . . . . . . . . . . . . . . . . . . . . . . . . . . . .
With enhanced one phase access . . . . . . . . . . . . . . . . . . . . . .
BSC to BTS E1 interconnect planning actions . . . . . . . . . . . . . . . .
BSC to BTS E1 interconnect planning example . . . . . . . . . . . . . . .
Determining the number of LCF GPROCs for RSL and GSL processing BSC
interconnect planning actions . . . . . . . . . . . . . . . . . . . . . . . .
Determining the number of MTLs required . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standard traffic model . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Non-standard traffic model for 64 k MTL . . . . . . . . . . . . . . . . . .
Non-standard traffic model for HSP MTL . . . . . . . . . . . . . . . . . .
Calculate the number of LCFs for MTL processing. . . . . . . . . . . . . .
LCFs for 64 k MTL links . . . . . . . . . . . . . . . . . . . . . . . . . . .
LCFs for HSP MTL links . . . . . . . . . . . . . . . . . . . . . . . . . . .
MSC to BSC signaling over a satellite link . . . . . . . . . . . . . . . . . .
Determining the number of LMTLs required . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
to
.
.
.
.
.
.
.
.
.
.
.
.
.
.
68P02900W21-T
Jul 2010
Determining the number of LMTLs . . . . . . . . . . . . . . . . . . . .

BSC to SMLC interconnection planning actions . . . . . . . . . . . . . .
Calculate the number of LCFs for LMTL processing . . . . . . . . . . . .
Determining the number of XBLs required. . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Determining the number of XBLs . . . . . . . . . . . . . . . . . . . . .
Standard traffic model . . . . . . . . . . . . . . . . . . . . . . . . . . .
Non standard traffic model . . . . . . . . . . . . . . . . . . . . . . . .
Determining the number of GSLs required. . . . . . . . . . . . . . . . . . .
Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . .
Load balancing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generic processor (GPROC) . . . . . . . . . . . . . . . . . . . . . . . . . .
GPROC nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPROC functions and types . . . . . . . . . . . . . . . . . . . . . . . .
GPROC3/GPROC3-2 planning assumptions . . . . . . . . . . . . . . . .
BSC types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cell broadcast link . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimizations Link (OPL) . . . . . . . . . . . . . . . . . . . . . . . . .
OMF GPROC required . . . . . . . . . . . . . . . . . . . . . . . . . . .
Code storage facility processor . . . . . . . . . . . . . . . . . . . . . .
GPROC redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPROC planning actions . . . . . . . . . . . . . . . . . . . . . . . . . .
Transcoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GDP/XCDR/EGDP/GDP2 planning considerations . . . . . . . . . . . . .
EGDP provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning actions for transcoding at the BSC . . . . . . . . . . . . . . . .
Multiple serial interface (MSI) . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MSI planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . .
Packet Subrate Interface (PSI2) . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning consideration. . . . . . . . . . . . . . . . . . . . . . . . . . .
PSI2 planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . .
Kiloport switch (KSW) and double kiloport switch (DSW2) . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
KSW/DSW2 planning actions. . . . . . . . . . . . . . . . . . . . . . . .
BSU shelves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BSU shelf planning actions . . . . . . . . . . . . . . . . . . . . . . . .
Kiloport switch extender (KSWX) and double kiloport switch extender (DSWX)
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
KSWX/DSWX planning actions . . . . . . . . . . . . . . . . . . . . . . .
Generic clock (GCLK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GCLK planning actions. . . . . . . . . . . . . . . . . . . . . . . . . . .
Clock extender (CLKX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CLKX planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . .
Local area network extender (LANX) . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68P02900W21-T
Jul 2010
Contents
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-45
6-46
6-46
6-47
6-47
6-47
6-48
6-49
6-50
6-50
6-52
6-53
6-53
6-53
6-53
6-55
6-55
6-56
6-58
6-58
6-58
6-59
6-59
6-62
6-63
6-64
6-65
6-67
6-70
6-70
6-70
6-71
6-72
6-72
6-72
6-72
6-73
6-73
6-73
6-75
6-77
6-77
6-77
6-77
6-80
6-80
6-80
6-81
6-82
6-82
6-82
6-82
6-83
6-83
6-83
6-84
6-85
6-85
vii
Contents
Planning considerations . . . . . . . . . .
LANX planning actions. . . . . . . . . . .
Parallel interface extender (PIX) . . . . . . . .
Introduction . . . . . . . . . . . . . . . .
PIX planning actions . . . . . . . . . . . .
Line interface boards (BIB/PBIB, T43/PT43) . .
Introduction . . . . . . . . . . . . . . . .
(P)BIB/(P)T43 planning actions . . . . . .
Digital shelf power supply . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . .
Power supply planning actions . . . . . . .
Non Volatile Memory (NVM) board . . . . . .
Introduction . . . . . . . . . . . . . . . .
NVM planning actions . . . . . . . . . . .
Verifying the number of BSU shelves and BSSC
Verification. . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
cabinets
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-85
6-85
6-86
6-86
6-86
6-86
6-87
6-87
6-87
6-88
6-89
6-89
6-89
6-89
6-90
6-90
6-90
6-90
6-91
6-91
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7-2
7-2
7-2
7-4
7-4
7-5
7-5
7-5
7-6
7-6
7-7
7-8
7-8
7-8
7-9
7-9
7-9
7-9
7-10
7-10
7-12
7-13
7-15
7-17
7-17
7-17
7-18
7-19
7-19
7-19
7-20
7-22
7-22
7-22
7-23
Chapter 7: RXCDR planning steps and rules

Overview of remote transcoder planning. . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . .
Outline of planning steps . . . . . . . . . . . . . . .
RXCDR system capacity . . . . . . . . . . . . . . . . . .
System capacity summary . . . . . . . . . . . . . . .
RXCDR to BSC connectivity . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . .
Capacity . . . . . . . . . . . . . . . . . . . . . . . .
RXCDR to BSC links . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . .
E1 interconnect planning actions . . . . . . . . . . .
RXCDR to MSC links . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . .
E1 interconnect planning actions . . . . . . . . . . .
Generic processor (GPROC) . . . . . . . . . . . . . . . .
GPROC nomenclature . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . .
Planning considerations . . . . . . . . . . . . . . . .
Transcoding . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . .
XCDR/GDP/EGDP/GDP2 planning considerations . . .
EGDP provisioning . . . . . . . . . . . . . . . . . . .
Planning actions for transcoding at the RXCDR . . . .
Multiple serial interface (MSI) . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . .
MSI planning actions . . . . . . . . . . . . . . . . .
Kiloport switch (KSW) and double kiloport switch (DSW2) .
Introduction . . . . . . . . . . . . . . . . . . . . . .
KSW/DSW2 planning actions. . . . . . . . . . . . . .
RXU shelves . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . .
RXU shelf planning actions . . . . . . . . . . . . . .
viii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
68P02900W21-T
Jul 2010
Contents
Enhanced capacity mode is enabled (non-extension shelf) . . . . . . . . .

Enhanced capacity mode is enabled (extension shelf) . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
KSWX/DSWX planning actions . . . . . . . . . . . . . . . . . . . . . . .
Generic clock (GCLK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GCLK planning actions. . . . . . . . . . . . . . . . . . . . . . . . . . .
Clock extender (CLKX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CLKX planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . .
LAN extender (LANX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LANX planning actions. . . . . . . . . . . . . . . . . . . . . . . . . . .
Parallel interface extender (PIX) . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PIX planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Line interfaces (BIB, T43) . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BIB/T43 planning actions . . . . . . . . . . . . . . . . . . . . . . . . .
Digital shelf power supply . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Power supply planning actions . . . . . . . . . . . . . . . . . . . . . . .
Non Volatile Memory (NVM) board . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NVM planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verify the number of RXU shelves and BSSC cabinets . . . . . . . . . . . . .
Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7-24
7-24
7-25
7-25
7-25
7-26
7-28
7-28
7-28
7-28
7-29
7-29
7-29
7-29
7-31
7-31
7-31
7-31
7-32
7-32
7-32
7-32
7-33
7-33
7-33
7-34
7-35
7-35
7-35
7-35
7-36
7-36
7-36
7-36
7-37
7-37
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8-2
8-2
8-2
8-3
8-21
8-22
8-22
8-22
8-24
8-24
8-24
8-25
8-25
8-25
8-28
8-30
8-30
8-30
8-31
Chapter 8: BSS planning for GPRS/EGPRS

BSS planning for GPRS/EGPRS . . . . . . . . . .
Introduction to BSS planning for GPRS/EGPRS
PCU to SGSN interface planning . . . . . . .
Feature compatibility . . . . . . . . . . . . .
PCU hardware layout . . . . . . . . . . . . . . .
PCU shelf (cPCI) . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . .
MPROC board . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . .
PSP planning considerations . . . . . . . . .
DPROC board . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . .
PICP or PRP planning considerations . . . . .
PXP planning considerations . . . . . . . . .
PMC module . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . .
(Packet) Rear Transition Module . . . . . . . . . .
68P02900W21-T
Jul 2010
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ix
Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning considerations . . . . . . . . . . . . . . . . . . . . . . .
PCU equipment redundancy and provisioning goals . . . . . . . . . . .
Support for equipment redundancy . . . . . . . . . . . . . . . . .
PCU equipment redundancy planning . . . . . . . . . . . . . . . .
PRP/PICP configure . . . . . . . . . . . . . . . . . . . . . . . . .
PXP configuration . . . . . . . . . . . . . . . . . . . . . . . . . .
Upgrading the PCU . . . . . . . . . . . . . . . . . . . . . . . . .
E1 link/ETH link provisioning for GPRS and EGPRS . . . . . . . . . . .
E1 interface provisioning . . . . . . . . . . . . . . . . . . . . . .
E1 Planning considerations . . . . . . . . . . . . . . . . . . . . .
Ethernet interface provisioning . . . . . . . . . . . . . . . . . . .
QoS capacity and QoS2 impact. . . . . . . . . . . . . . . . . . . . . .
MTBR allocation . . . . . . . . . . . . . . . . . . . . . . . . . . .
PRP-PDTCH QoS planning . . . . . . . . . . . . . . . . . . . . . .
Calculating PRP board throughput . . . . . . . . . . . . . . . . . .
Calculating average downlink EGBR . . . . . . . . . . . . . . . . .
CTU2D impact . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PCU-SGSN: traffic and signal planning . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gb entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General planning guidelines . . . . . . . . . . . . . . . . . . . . .
Specific planning guidelines . . . . . . . . . . . . . . . . . . . . .
Gb signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Determining net Gb load . . . . . . . . . . . . . . . . . . . . . . .
Gb link timeslots (for Frame relay Gb) . . . . . . . . . . . . . . . .
Frame relay parameter values . . . . . . . . . . . . . . . . . . . .
Gb link (for Ethernet Gb) . . . . . . . . . . . . . . . . . . . . . .
BSS-PCU hardware planning example for GPRS . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BSS - PCU planning example for GPRS . . . . . . . . . . . . . . .
BSS-PCU hardware planning example for EGPRS . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BSS - PCU planning example for EGPRS . . . . . . . . . . . . . .
BSS - PCU planning example for EGPRS with QoS enabled, QoS2 not
BSS - PCU planning example for EGPRS with QoS and QoS2 enabled
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
enabled
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8-31
8-31
8-32
8-32
8-32
8-33
8-38
8-43
8-46
8-46
8-46
8-47
8-49
8-51
8-54
8-54
8-55
8-62
8-63
8-63
8-63
8-64
8-65
8-65
8-65
8-66
8-67
8-69
8-72
8-72
8-72
8-79
8-79
8-79
8-86
8-93
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9-2
9-2
9-3
9-4
9-4
9-5
9-5
9-6
9-8
9-8
9-8
9-8
9-9
9-9
9-11
9-11
9-13
9-14
9-14
Chapter 9: Planning examples

Pre-requisites . . . . . . . . . . . . . . . . . . . . .
Requirements . . . . . . . . . . . . . . . . . . .
Network topology . . . . . . . . . . . . . . . . .
Exercises. . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . .
Determine the hardware requirements for BTS B . . .
Cabinet . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . .
Determine the hardware requirements for BTS K . . .
Introduction . . . . . . . . . . . . . . . . . . . .
Cabinet . . . . . . . . . . . . . . . . . . . . . .
Receiver requirements . . . . . . . . . . . . . . .
Transmitter combining requirements . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . .
Determine the hardware requirements for the BSC . .
Introduction . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . .
Determine the hardware requirements for the RXCDR.
MSI requirements . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
68P02900W21-T
Jul 2010
Contents
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9-14
9-15
9-15
9-15
9-15
9-15
9-15
9-15
9-16
9-16
9-16
9-17
9-17
9-17
9-30
9-46
9-59
9-59
9-59
9-62
Location area planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Location area planning calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-2
10-3
10-3
Transcoder requirement . . . . . . . . . . . . . . . . . . . . . .
Link interface . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPROC requirement . . . . . . . . . . . . . . . . . . . . . . . .
KSW/DSW2 requirement . . . . . . . . . . . . . . . . . . . . . .
KSWX/DSWX requirement . . . . . . . . . . . . . . . . . . . . .
GCLK requirement . . . . . . . . . . . . . . . . . . . . . . . . .
CLKX requirement . . . . . . . . . . . . . . . . . . . . . . . . .
PIX requirement . . . . . . . . . . . . . . . . . . . . . . . . . .
LANX requirement . . . . . . . . . . . . . . . . . . . . . . . . .
Power supply. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Calculations using alternative call models . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning example 1 . . . . . . . . . . . . . . . . . . . . . . . .
Planning example 2 (using AMR) . . . . . . . . . . . . . . . . .
Planning example 3 . . . . . . . . . . . . . . . . . . . . . . . .
Planning example of BSS support for LCS provisioning . . . . . . . .
Typical parameter values . . . . . . . . . . . . . . . . . . . . .
LCS planning example calculations . . . . . . . . . . . . . . . .
Planning example for GSR10 with no (E)GPRS and high signaling .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Chapter 10: Location area planning
Chapter 11: Call model parameters

Deriving call model parameters from network statistics
Standard call model parameters . . . . . . . . . .
Call duration (T) . . . . . . . . . . . . . . . . . .
Ratio of SMSs per call (S) . . . . . . . . . . . . .
Ratio of handovers per call (H). . . . . . . . . . .
Ratio of intra BSS handovers to all handovers (i) .
Ratio of location updates per call (I) . . . . . . . .
Ratio of IMSI detaches per call (I) . . . . . . . . .
Location update factor (L) . . . . . . . . . . . . .
Paging rate (PGSM) . . . . . . . . . . . . . . . . .
Pages per call (PPC) . . . . . . . . . . . . . . . .
Percent link utilization MSC to BSS [U(MSC BSS)] . .
Percent link utilization BSC to BTS [U(BSC BTS)] . .
Percent Link Utilization BSC to SMLC (U(BSC SMLC))
Blocking for TCHs (PB TCHs)1 . . . . . . . . . . .
GPRS CS1 uplink usage (CS1_usage_UL) . . . . .
GPRS CS1 downlink usage (CS1_usage_DL) . . . .
EGPRS MCS1 uplink usage (MCS1_usage_UL). . .
EGPRS MCS1 downlink usage (MCS1_usage_DL) .
68P02900W21-T
Jul 2010
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11-2
11-2
11-5
11-6
11-7
11-7
11-8
11-8
11-9
11-9
11-10
11-11
11-11
11-12
11-12
11-13
11-14
11-14
11-15
11-16
11-17
11-18
11-19
11-19
11-20
11-21
11-22
11-23
11-24
xi
Contents
EGPRS MCS4 uplink usage (MCS4_usage_UL). .

EGPRS MCS4 downlink usage (MCS4_usage_DL)
Sample statistic calculations . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11-24
11-25
11-26
11-27
11-28
11-29
11-29
11-30
11-31
11-32
11-33
11-34
11-34
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12-2
12-2
12-2
12-2
12-3
12-3
12-3
Chapter 12: Hardware and compatibility

Hardware configuration . .
Horizon II . . . . . . .
Horizonmacro . . . . .
M-Cell . . . . . . . . .
Micro Base Transceiver
BSC/RXCDR . . . . . .
PCU . . . . . . . . . .
xii
. . . . .
. . . . .
. . . . .
. . . . .
Stations .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
68P02900W21-T
Jul 2010
List
of
Figures
List of Figures
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
1-1: BSS block diagram . . . . . . . . . . . . . . . . . . . . . . . . .

1-2: Intelligent Optimization Service . . . . . . . . . . . . . . . . . . .
1-3: CTU2D PWR . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-4: CTU2D CAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-5: CTU2D ASYM . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-6: Normal and extended range timeslots . . . . . . . . . . . . . . . .
1-7: Architecture diagram of (R)CTU8m . . . . . . . . . . . . . . . . .
2-1: BSS interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-2: Possible network topology . . . . . . . . . . . . . . . . . . . . . .
2-3: Star connection . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-4: Closed loop and open ended daisy chains . . . . . . . . . . . . . .
2-5: Simple daisy chain . . . . . . . . . . . . . . . . . . . . . . . . . .
2-6: Daisy chain with branch . . . . . . . . . . . . . . . . . . . . . . .
2-7: Typical low capacity BSC/BTS configuration . . . . . . . . . . . . .
2-8: Example using a switching network . . . . . . . . . . . . . . . . .
2-9: Timeslot allocation using new and old algorithms . . . . . . . . . .
2-10: Alternative network configuration with E1 switching network . . .
2-11: A configuration with a BTS equipped with two redundant RTFs . .
2-12: A configuration with a BTS equipped with two non-redundant RTFs
2-13: Fully equipped RTF. . . . . . . . . . . . . . . . . . . . . . . . .
2-14: Sub-equipped RTF . . . . . . . . . . . . . . . . . . . . . . . . .
2-15: XBL utilization . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-16: Conversion of E1 to HDSL links by modem and microsite . . . . .
2-17: Microcell daisy chain network configuration . . . . . . . . . . . .
2-18: Microcell star network configuration . . . . . . . . . . . . . . . .
2-19: Microcell configuration using E1/HDSL links. . . . . . . . . . . .
3-1: AMR half rate capacity increase . . . . . . . . . . . . . . . . . . .
3-2: AMR full rate call quality improvements . . . . . . . . . . . . . . .
3-3: GSM half rate capacity increase . . . . . . . . . . . . . . . . . . .
3-4: GSM half rate codec comparison . . . . . . . . . . . . . . . . . .
3-5: GPRS channel coding scheme 1 (CS1) . . . . . . . . . . . . . . . .
3-9: EGPRS channel coding scheme 1 (MCS-1) . . . . . . . . . . . . . .
3-10: EGPRS channel coding scheme 2 (MCS-2) . . . . . . . . . . . . .
3-18: Subscriber environment . . . . . . . . . . . . . . . . . . . . . .
3-19: Subscriber distribution . . . . . . . . . . . . . . . . . . . . . . .
68P02900W21-T
Jul 2010
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1-4
1-18
1-25
1-25
1-26
1-28
1-30
2-2
2-6
2-7
2-8
2-9
2-10
2-11
2-12
2-13
2-14
2-16
2-16
2-18
2-19
2-21
2-27
2-27
2-28
2-28
3-7
3-8
3-10
3-11
3-13
3-14
3-15
3-16
3-19
3-20
3-21
3-22
3-23
3-24
3-25
3-26
3-27
3-31
3-32
xiii
List of Figures
Figure 3-20: Layered architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 3-21: Combined cell architecture . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 3-22: Combined cell architecture structure . . . . . . . . . . . . . . . . . . .
Figure 3-23: Separating BCCH and TCH bands . . . . . . . . . . . . . . . . . . . . .
Figure 3-24: Band usage for macrocells with microcells . . . . . . . . . . . . . . . . .
Figure 3-25: Frequency split for TCH re-use planning example . . . . . . . . . . . . .
Figure 3-26: Avoiding co-channel and adjacent channel interference . . . . . . . . . .
Figure 3-27: BBH frequency spectrum allocation . . . . . . . . . . . . . . . . . . . .
Figure 3-28: GSM and UMTS system nodes and interfaces . . . . . . . . . . . . . . .
Figure 3-29: CCCH and PCCCH decision tree . . . . . . . . . . . . . . . . . . . . . .
Figure 3-30: Location area diagram . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 3-31: MM state models for MS and SGSN . . . . . . . . . . . . . . . . . . . .
Figure 3-32: Carrier with reserved and switchable GPRS/EGPRS timeslots . . . . . . .
Figure 3-33: Generic planning and dimensioning process . . . . . . . . . . . . . . . .
Figure 3-34: Multiplexing 4 TBFs on an air timeslot . . . . . . . . . . . . . . . . . . .
Figure 3-35: LLC PDU to TDMA bursts . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-1: AMR FR/clean speech versus EFR versus performance requirements . . . .
Figure 4-2: AMR FR/clean speech codec modes . . . . . . . . . . . . . . . . . . . . .
Figure 4-3: AMR HR/clean speech versus EFR versus GSM FR versus GSM HR versus
performance requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-4: AMR HR/clean speech codec modes . . . . . . . . . . . . . . . . . . . . .
Figure 4-5: 3 carriers, only one hr-capable carrier. . . . . . . . . . . . . . . . . . . .
Figure 4-6: 3 carriers, all hr-capable. . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-7: 5 carriers, only one hr-capable carrier. . . . . . . . . . . . . . . . . . . .
Figure 4-8: 5 carriers, only 3 hr-capable carriers . . . . . . . . . . . . . . . . . . . .
Figure 4-9: 5 carriers, all hr-capable carriers . . . . . . . . . . . . . . . . . . . . . .
Figure 4-10: Congestion threshold settings for AMR half rate . . . . . . . . . . . . . .
Figure 4-11: Alternative configurations for the BSSC3 cabinet . . . . . . . . . . . . .
Figure 4-12: AMR backhaul paths . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-13: hr backhaul paths - ESS mode enabled . . . . . . . . . . . . . . . . . . .
Figure 5-1: DRI and combiner relationship . . . . . . . . . . . . . . . . . . . . . . .
Figure 5-2: Relationship of the D4+ interface to the CTU8m radio and BBU-E . . . . .
Figure 5-3: D4+ Star topology (Single BBU-E). . . . . . . . . . . . . . . . . . . . . .
Figure 5-4: D4+ Star topology (Dual BBU-E) . . . . . . . . . . . . . . . . . . . . . .
Figure 5-5: D4+ Redundant-star topology . . . . . . . . . . . . . . . . . . . . . . . .
Figure 5-6: D4+ Daisy-chain topology . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 5-7: D4+ Star/daisy-chain topology. . . . . . . . . . . . . . . . . . . . . . . .
Figure 5-8: D4+ Dual star topology (redundant D4+ link) . . . . . . . . . . . . . . . .
Figure 5-9: D4+ Daisy-chain topology (redundant D4+ link). . . . . . . . . . . . . . .
Figure 5-10: D4+ link types (illustrative) . . . . . . . . . . . . . . . . . . . . . . . .
Figure 5-11: D4+ configuration for 3 CTU8m radios (non-redundant) . . . . . . . . . .
Figure 5-12: D4+ configuration for 3 CTU8m radios (redundant) . . . . . . . . . . . .
Figure 5-13: D4+ configuration for 6 CTU8m radios (single BBU-E) . . . . . . . . . . .
Figure 5-14: D4+ configuration for 6 CTU8m radios (dual BBU-E) . . . . . . . . . . .
Figure 5-15: D4+ star configuration for 1-3 RCTU8m radios (non-redundant) . . . . . .
Figure 5-16: D4+ daisy-chain configuration for 1-3 RCTU8m radios (non-redundant) . .
Figure 5-17: D4+ daisy-chain configuration for 1-3 RCTU8m radios (redundant) . . . .
Figure 5-18: D4+ configuration for 4-6 RCTU8m radios (single-BBU-E) . . . . . . . . .
Figure 5-19: D4+ configuration for 4-6 RCTU8m radios (dual-BBU-E) . . . . . . . . . .
Figure 6-1: BSS planning diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 6-2: EGDP configuration with the additional E1 termination in use. . . . . . . .
Figure 6-3: EGDP configuration without the additional E1 termination in use . . . . . .
Figure 7-1: Sub-multiplexing and speech transcoding at the RXCDR . . . . . . . . . .
Figure 7-2: EGDP configuration with the additional E1 termination in use. . . . . . . .
Figure 7-3: EGDP configuration without the additional E1 termination in use . . . . . .
Figure 8-1: PCU to SGSN interface planning . . . . . . . . . . . . . . . . . . . . . .
Figure 8-2: Mixed Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 8-3: PCU shelf layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xiv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3-34
3-35
3-36
3-38
3-39
3-40
3-42
3-42
3-45
3-54
3-67
3-76
3-93
3-96
3-100
3-119
4-6
4-7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4-8
4-9
4-12
4-12
4-13
4-13
4-14
4-24
4-28
4-30
4-31
5-43
5-44
5-46
5-47
5-47
5-48
5-48
5-49
5-49
5-52
5-56
5-56
5-57
5-58
5-59
5-60
5-61
5-62
5-63
6-13
6-66
6-67
7-12
7-14
7-15
8-3
8-11
8-21
68P02900W21-T
Jul 2010
List of Figures
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
8-4: Provisioning goals (full redundancy) . . . . . . . . . . . . . . . . . . . .

8-5: Provisioning goals (Maximum coverage) . . . . . . . . . . . . . . . . . .
8-6: EGPRS maximum throughput and coverage, full redundancy not required
8-7: Provisioning goals (full redundancy) . . . . . . . . . . . . . . . . . . . .
8-8: Provisioning goals (maximum coverage) . . . . . . . . . . . . . . . . . .
8-9: Provisioning goals achieved with instance of PCU provisioning . . . . . .
8-10: Provisioning goals achieved with instance of PCU provisioning (ET Gb) .
8-11: BER versus Number of mobiles. . . . . . . . . . . . . . . . . . . . . .
8-12: Frame relay parameters . . . . . . . . . . . . . . . . . . . . . . . . .
8-13: Gb over IP full mesh connectivity between PCU and SGSN. . . . . . . .
8-14: PCU equipment and link planning for GPRS . . . . . . . . . . . . . . .
8-15: PCU Equipment and link planning for EGPRS . . . . . . . . . . . . . .
9-1: Network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-1: Four BSCs in one LAC . . . . . . . . . . . . . . . . . . . . . . . . . .
10-2: Four BSCs divided into two LACs. . . . . . . . . . . . . . . . . . . . .
68P02900W21-T
Jul 2010
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8-34
8-35
8-36
8-39
8-40
8-41
8-42
8-61
8-67
8-71
8-72
8-79
9-3
10-4
10-6
xv
List of Figures
xvi
68P02900W21-T
Jul 2010
List
of
Tables
List of Tables
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
1-1: Transceiver unit usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-2: Acronym list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-1: BSS interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-2: RTF types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-1: Coding parameters for GPRS coding schemes . . . . . . . . . . . . . . . . . .
3-2: Coding parameters for EGPRS coding schemes . . . . . . . . . . . . . . . . . .
3-3: Frequency and parameter setting plan . . . . . . . . . . . . . . . . . . . . . .
3-4: RTF-DRI mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-5: Typical parameters for BTS call planning . . . . . . . . . . . . . . . . . . . . .
3-6: Control channel configurations . . . . . . . . . . . . . . . . . . . . . . . . . .
3-7: Example Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-8: Control channel configurations for non-border location area . . . . . . . . . . .
3-9: Control channel configurations for border location area . . . . . . . . . . . . .
3-10: MM state model of MS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-11: Capping settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-12: Output power capacity of (R)CTU8m for GMSK and 8-PSK . . . . . . . . . . .
3-13: CTU2D output power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-14: DRI-RTF Mapping functionality . . . . . . . . . . . . . . . . . . . . . . . . .
3-15: Arrangement of packet data timeslots for example 1 . . . . . . . . . . . . . .
3-25: Typical TCP throughput against RLC/MAC throughput at zero block error rate .
3-26: r for various transfer delays at GBR 15 kbps or less . . . . . . . . . . . . . . .
3-27: r for transfer delay = 500 ms at GBR greater than 15 kbps . . . . . . . . . . .
3-28: r for transfer delay = 250 ms at GBR greater than 15 kbps . . . . . . . . . . .
3-29: ARP mobile selection (ARP Rank) order . . . . . . . . . . . . . . . . . . . . .
3-30: BSS ARP configuration Parameters . . . . . . . . . . . . . . . . . . . . . . .
3-31: Percentage of code utilization in a 4x3 non-hopping re-use pattern at 20% BLER
3-32: MTBR Mix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-33: MTBR Constant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-34: THP Weight Mix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-35: THP Weight Constant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-36: QoS Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . .
3-37: QoS Disabled; Capacity: 18 users, DL Throughput per MS: 0.33 (6/18) TS . . .
3-38: QoS Enabled; Capacity: 11 users, DL Throughput per MS: 0.54 (6/11) TS. . . .
3-39: GPRS downlink data rates (kbps) with TCP (CS1) . . . . . . . . . . . . . . . .
68P02900W21-T
Jul 2010
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1-5
1-40
2-2
2-17
3-17
3-28
3-41
3-43
3-48
3-59
3-69
3-70
3-71
3-75
3-78
3-78
3-79
3-79
3-84
3-85
3-86
3-87
3-88
3-89
3-89
3-90
3-91
3-91
3-102
3-103
3-104
3-105
3-106
3-107
3-108
3-112
3-113
3-113
3-113
3-113
3-114
3-116
3-120
3-120
3-120
xvii
List of Tables
Table 3-42: GPRS downlink data rates (kbps) with TCP (CS4) . . . . . . . . . . . . . . . .
Table 3-43: GPRS downlink data rates (kbps) with UDP (CS1) . . . . . . . . . . . . . . . .
Table 3-47: EGPRS downlink data rates (kbps) with TCP (MCS1) . . . . . . . . . . . . . .
Table 3-56: EGPRS downlink data rates (kbps) with UDP (MCS1) . . . . . . . . . . . . . .
Table 4-1: AMR potential coverage gains . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 4-2: Backhaul configuration based on parameter settings . . . . . . . . . . . . . . .
Table 4-3: Call placement on terrestrial backhaul . . . . . . . . . . . . . . . . . . . . . .
Table 4-4: Voice call mapping on the backhaul for a 64 k RTF . . . . . . . . . . . . . . . .
Table 5-1: Specifications for CTU8m in Horizon II macro . . . . . . . . . . . . . . . . . .
Table 5-2: Transmit configurations pre-CTU8m radio . . . . . . . . . . . . . . . . . . .
Table 5-3: Transmission configurations CTU8m in 4-carrier mode . . . . . . . . . . . . .
Table 5-6: BBH capability for Horizon II macro Site Controller . . . . . . . . . . . . . . .
Table 5-7: BBH capability for Horizonmacro Site Controller . . . . . . . . . . . . . . . . .
Table 5-8: CTU/CTU2 power requirements. . . . . . . . . . . . . . . . . . . . . . . . . .
Table 5-9: CTU/CTU2 power requirements for M-Cell cabinets . . . . . . . . . . . . . . .
Table 5-10: Site connection requirements for M-Cell2 and M-Cell6 . . . . . . . . . . . . .
Table 5-11: Horizon II macro XMUX expansion requirements . . . . . . . . . . . . . . . .
Table 5-12: Horizon II mini only network XMUX expansion requirements . . . . . . . . . .
Table 5-13: Horizon II macro as master - Horizon II mini as expansion XMUX requirements
Table 5-14: Horizonmacro as master - Horizon II mini as expansion XMUX/FMUX
requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 5-15: Horizonmacro as master - Horizonmacro as expansion FMUX requirements . .
Table 6-1: BSC maximum capacities . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 6-2: BSC configuration capacities . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 6-3: Typical call parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 6-4: Other parameters used in determining GPROC and link requirements . . . . . .
Table 6-5: Signaling message procedures . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 6-6: BTS support for 64kbit/s RSL or 16 kbps RSLs . . . . . . . . . . . . . . . . . .
Table 6-7: Number of BSC to BTS signaling links (without LCS) . . . . . . . . . . . . . . .
Table 6-8: Backhaul requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 6-9: Number of MSC and BSC signaling links without LCS (20% utilization) . . . . .
Table 6-12: Number of BSC to RXCDR signaling links . . . . . . . . . . . . . . . . . . . .
Table 6-13: Typical call parameters relating to XBLs . . . . . . . . . . . . . . . . . . . .
Table 6-14: GPROC type/function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 6-15: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xviii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3-121
3-121
3-121
3-122
3-122
3-122
3-123
3-123
3-123
3-124
3-124
3-124
3-125
3-125
3-125
3-126
3-126
3-126
3-127
3-127
3-127
3-128
3-128
4-10
4-29
4-29
4-29
5-4
5-15
5-16
5-16
5-16
5-19
5-19
5-21
5-23
5-27
5-34
5-35
5-35
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-35
5-36
6-7
6-8
6-14
6-18
6-18
6-23
6-25
6-31
6-39
6-39
6-40
6-48
6-48
6-54
6-61
68P02900W21-T
Jul 2010
List of Tables
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
6-16: BSS configurations and their availability . . . . . . . . . . . . . . .

6-17: KSWX/DSWX (non-redundant) . . . . . . . . . . . . . . . . . . . . .
6-18: KSWX/DSWX (redundant) . . . . . . . . . . . . . . . . . . . . . . .
7-1: RXCDR maximum capacities . . . . . . . . . . . . . . . . . . . . . .
7-2: KSWX/DSWX (non-redundant) . . . . . . . . . . . . . . . . . . . . .
7-3: KSWX/DSWX (redundant) . . . . . . . . . . . . . . . . . . . . . . . .
8-1: VersaTRAU backhaul recommendations for a given number of PDTCHs
8-2: Expected throughput/TS and coding schemes (conservative) . . . . . .
8-3: Expected throughput/TS and coding schemes (aggressive) . . . . . . .
8-4: BSS upgrade in support of GPRS/EGPRS . . . . . . . . . . . . . . . .
8-5: Recommended maximum BSS network parameter values (part A) . . .
8-6: Recommended maximum BSS parameter values (part B) . . . . . . . .
8-7: Recommended maximum BSS network parameter (part C) . . . . . . .
8-8: Maximum number of timeslots that can be processed. . . . . . . . . .
8-9: Maximum number of timeslots that can be provisioned . . . . . . . .
8-10: Provisioning goals (per PCU) . . . . . . . . . . . . . . . . . . . . .
8-11: Provisioning goals (per PCU) . . . . . . . . . . . . . . . . . . . . .
8-12: Upgrade scenarios for PRP configuration . . . . . . . . . . . . . . .
8-13: Upgrade scenarios for PXP configuration . . . . . . . . . . . . . . .
8-14: Local Timeslot Zone Level capacity 4MS/PDTCH . . . . . . . . . . .
8-15: PRP Board Service Level Capacity 4MS/PDTCH . . . . . . . . . . . .
8-16: Maximum MTBR in UL/DL per multislot capability . . . . . . . . . .
8-17: r for various transfer delays at GBR 15 kbps or less . . . . . . . . . .
8-18: r for Transfer delay = 500 ms at GBR greater than 15 kbps . . . . . .
8-19: r for Transfer delay = 250 ms at GBR greater than 15 kbps . . . . . .
8-20: Gb entities and identifiers . . . . . . . . . . . . . . . . . . . . . . .
8-21: GPRS call mode . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-22: EGPRS call model . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-23: EGPRS with QoS enabled call model . . . . . . . . . . . . . . . . .
8-24: EGPRS with QoS and QoS2 enabled call model . . . . . . . . . . . .
9-1: Busy hour demand and number of carriers . . . . . . . . . . . . . . .
9-2: Customer ordering guide 900 MHz (M-Cell6 indoor) . . . . . . . . . .
9-3: Customer ordering guide 900 MHz (M-Cell6 indoor) . . . . . . . . . .
9-4: Customer ordering guide 1800 MHz (Horizon II macro indoor) . . . . .
9-5: Customer ordering guide 1800 MHz (Horizon II macro indoor) . . . . .
9-6: GPROCs required at the BSC . . . . . . . . . . . . . . . . . . . . . .
9-7: BSC timeslot requirements . . . . . . . . . . . . . . . . . . . . . . .
9-8: Equipment required for the BSC . . . . . . . . . . . . . . . . . . . .
9-9: Equipment required for the RXCDR . . . . . . . . . . . . . . . . . . .
9-10: BSU Shelves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9-11: RXU shelves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9-12: Control channel calculation . . . . . . . . . . . . . . . . . . . . . .
9-13: BSU Shelves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9-14: Determining the number of XCDR/GDP/GDP2 cards . . . . . . . . . .
9-15: RXU3 shelves . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9-16: KSW/DSW2 requirements . . . . . . . . . . . . . . . . . . . . . . .
9-17: Typical LCS call model parameter . . . . . . . . . . . . . . . . . . .
10-1: Example of values for the parameters for location area planning . . .
11-1: Typical parameters for BTS call planning . . . . . . . . . . . . . . .
11-2: Sample statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . .
68P02900W21-T
Jul 2010
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-62
6-81
6-81
7-4
7-27
7-27
8-8
8-8
8-9
8-13
8-14
8-16
8-19
8-22
8-23
8-36
8-42
8-44
8-45
8-50
8-51
8-53
8-56
8-58
8-59
8-63
8-72
8-80
8-86
8-94
9-2
9-6
9-6
9-9
9-10
9-12
9-12
9-13
9-16
9-25
9-28
9-32
9-40
9-43
9-44
9-56
9-59
10-3
11-2
11-34
xix
List of Tables
xx
68P02900W21-T
Jul 2010
About
This
Manual
System Information: BSS Equipment

Planning
What is covered in this manual?

This manual provides an overview of the various BSS elements and BSS planning methodology.
It describes the requirements and procedures for planning a BSS cell site, a BTS including
Horizon and M-cell range of equipment, a BSC including the scenario when an LCS is used, an
RXCDR and location area. It provides an overview of AMR and its usage in the Motorola system.
It describes about obtaining the call model parameters from network statistics collected at the
OMC-R. This manual also deals with standard BSS, Horizon BTS, and M-Cell BTS configurations.
68P02900W21-T
Jul 2010
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
Jan 2005
Includes GSM Software Release 8
Mar 2009
Software release GSR9
Jul 2010
Software release GSR10
Release information
This section describes the changes in this document in release GSR10. The following features
have been incorporated:
Gb over IP
Enhanced Horizon II Site Controller
Reduced number of LCFs
CTU8m
PA bias in mixed radio Horizon II sites
Resolution of Service Requests

The following Service Requests are resolved in this document:
Service
Request
CMBP Number
N/A
N/A
Remarks
68P02900W21-T
Jul 2010
General information
General information
Purpose
Motorola documents provide the information to operate, install, and maintain Motorola
equipment. 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.
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
68P02900W21-T
Jul 2010
Text conventions
Text conventions
The following conventions are used in 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
CTRL+SHIFT+C
Press the Ctrl, Shift, and C keys at the same time.
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.
68P02900W21-T
Jul 2010
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.
Ordering documents and CD-ROMs

With internet access available, to view, download, or order documents (original or revised), visit
the Motorola 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.
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
68P02900W21-T
Jul 2010
Errors
68P02900W21-T
Jul 2010
Chapter
1
Introduction to planning
An overview of this manual and the various elements of a BSS and the BSS planning
methodology are provided here. Included is information about BSS system architecture,
components, and features that can affect the planning stage together with information required
before planning can begin.
The following topics are described:
Manual overview on page 1-2
BSS equipment overview on page 1-4
BSS features on page 1-11
BSS planning overview on page 1-37
Acronyms on page 1-40
NOTE
68P02900W21-T
Jul 2010
OMC-R planning is beyond the scope of this manual.
For information on installing a new OMC-R, refer to 68P02901W47, Installation

and Configuration: OMC-R Clean Install. For information on upgrading an
existing OMC-R for this software release, refer to 68P02901W74, Software
Release Notes: OMC-R System.
1-1
Manual overview
Manual overview
Introduction
The manual contains information about planning a GSM network, and utilizing a combination of
Horizon and M-Cell BTS equipment.
Contents
The manual contains the following chapters:
Chapter 1 Introduction to planning

Provides an overview of the various elements of a BSS and the BSS planning methodology.
Chapter 2 Transmission systems

This chapter provides an overview of the transmission systems used in GSM.
Chapter 3 BSS cell planning

States the requirements and procedures used in producing a BSS cell site plan.
Chapter 4 AMR and GSM half-rate planning

Provides an overview of the AMR and usage in the Motorola system.
Chapter 5 BTS planning steps and rules

Provides the planning steps and rules for the BTS, including the Horizon and M-Cell range
of equipment.
Chapter 6 BSC planning steps and rules

Provides the planning steps and rules for the BSC, including when LCS is used.
Chapter 7 RXCDR planning steps and rules

Provides the planning steps and rules for the RXCDR.
Chapter 8 BSS planning for GPRS/EGPRS

Provides information for the PCU upgrade to the BSS.
Chapter 9 Planning examples

Provides planning exercises designed to illustrate the use of the rules and formulae
provided in Chapters 3, 4, 5, 6, 7, and 8.
Chapter 10 Location area planning

Provides the planning steps and rules for location area planning.
1-2
68P02900W21-T
Jul 2010
Contents
Chapter 11 Call model parameters

Provides the planning steps and rules for deriving call model parameters from network
statistics collected at the OMC-R.
Chapter 12 Hardware and compatibility

Provides diagrams of the logical interconnections of the components in various standard
BSS and Horizon BTS site configurations.
68P02900W21-T
1-3
Jul 2010
BSS equipment overview
BSS equipment overview
System architecture
The architecture of the Motorola Base Station System (BSS) is versatile, and allows several
possible configurations for a given system. The BSS is a combination of digital and RF
equipment that communicates with the Mobile Switching Center (MSC), the Operations and
Maintenance Center Radio (OMC-R), and the Mobile Stations (MS) as shown in Figure 1-1.
Figure 1-1 BSS block diagram

A INTERFACE
MSC LRs
OMC-R
RXCDR
SGSN
BSS
O&M
PCU
BSS
BSC
ABIS INTERFACE
BTS 1
BTS 5
BTS 2
BTS 6
BTS 3
BTS 7
BTS 8
...
BTS n
BTS 4
AIR INTERFACE
MS
MS
...
MS
MS
...
ti-GSM-BSS_block_diagram-00001-ai-sw
1-4
68P02900W21-T
Jul 2010
System components
NOTE
The OMC-R can be linked through the RXCDR and/or to the BSS/BSC direct.
The example of multiple MSs connected to BTS 4 and BTS 7, is connected to all
the other BTSs as shown in Figure 1-1.
System components
The BSS is divided into a Base Station Controller (BSC), Remote Transcoder (RXCDR), Packet
Control Unit (PCU), and one or more Base Transceiver Stations (BTSs). These components
can be in-built or externally located Horizon II macro, Horizonmacro, or M-Cell BTS cabinets
or enclosures.
The Transcoder (XCDR) or Generic Digital Processor (GDP, EGDP, or GDP2) provides 4:1
multiplexing of the traffic, and can be located at the BSC or between the BSC and MSC. When
half rate is in use, it is possible to achieve a greater reduction (refer to the transcoding sections
of Chapter 6 BSC planning steps and rules and Chapter 7 RXCDR planning steps and rules
for a detailed description).
When the XCDR/GDP/EGDP/GDP2 is located at the MSC, it reduces the number of
communication links to the BSC. When transcoding is not performed at the BSC, the XCDR is
referred to as a remote transcoder (RXCDR). The RXCDR is part of the BSS but can serve
more than one BSS.
In the Motorola BTS product line, the radio transmit and receive functions are provided as
listed in Table 1-1:
Table 1-1
Transceiver unit usage

Transceiver unit
Where used
{34371G} Compact Transceiver Unit

8multi ((R)CTU8m)
Horizon II macro, Horizon II micro, Horizon II mini,

Horizon II extension (but connect the fiber link back
to the BBU at the master cabinet).
Compact Transceiver Unit 2-D

(CTU2D)

and Horizon II extension of the H2 master cabinet.
Compact Transceiver Unit 2D-CPI

(CTU2-D-CPI)

Horizon II extension of the H2 master cabinet.
Compact Transceiver Unit 2 (CTU2)
Horizon II macro, Horizonmacro (with limitations.

see CTU2D on page 1-6), M-Cell6 and M-Cell2 with
CTU2 Adapter.
Compact Transceiver Unit (CTU)
Horizonmacro
Dual Transceiver Module (DTRX)
Horizonmicro, Horizonmicro2, Horizoncompact and

Horizoncompact2.
Transceiver Control Unit (TCU)
M-Cell6, M-Cell2 and BTS6.
Transceiver Control Unit (TCU-B)
M-Cell6 and M-Cell2.
Transceiver Control Unit, micro

(TCU-m)
M-Cellmicro, M-Cellcity and M-Cellcity+.
68P02900W21-T
1-5
Jul 2010
System components
NOTE
Except for the TCU, which is backwards compatible by switching from TCU to SCU on
the front panel, all other transceiver units are compatible only with the equipment
listed.
(R)CTU8m
{34371G}
There are two types of CTU8m, an in-cabinet (CTU8m) and an out-of-cabinet ((R)CTU8m)
variants, which can be configured to operate up to 4 or 6 or {35200G} 8 carriers. In Horizon II
macro, Horizon II micro, Horizon II mini, the transceiver functions are provided by the in-cabinet
CTU8ms plugged into earlier cabinet slots, or out-of-cabinet (R)CTU8m placed at remote places.
NOTE
(R)CTU8m provides transceiver functions in Horizon II micro. Description and
planning rules for the (R)CTU8m are provided in Chapter 5 BTS planning steps and
rules of this manual. Configuration diagrams are shown in Chapter 12 Hardware and
compatibility. The (R)CTU8m receivers can support 2 branch receive diversity (do
not support 4 branch receive diversity).
CTU2D
In Horizon II family, which includes Horizon II macro, Horizon II micro, Horizon II mini, and
Horizon II extension of the H2 master cabinet, the CTU2D provides the transceiver functions. It
can be configured to operate in single or double density mode.
CTU2D retains the behavior of CTU2 and extends to support two simultaneous carriers for
EGPRS (Carrier B UL GMSK limited). The main reason for CTU2D not supporting unrestricted
EDGE on both carriers is MIPS constraints of the host processor. CTU2D radio can support the
following working modes:
1-6
CTU2D single density mode: This mode is identical in operation to the existing CTU2
single density mode.
CTU2D double density power mode: This mode is also known as ITS Mode whereby the
CTU2 and CTU2D operations are identical.
CTU2D double density capacity mode: Of the two carriers, carrier A is fully
EDGE-capable, while carrier B supports GPRS/TCH. TS blanking is not required. The
maximum output power of carrier A in 8-PSK mode is 10 W* and GMSK mode is 20 W*.
The maximum output power carrier B (GMSK only) is always 20 W*.
CTU2D double density asymmetric mode: Of the two carriers, carrier A is fully EDGE
capable, while carrier B supports EDGE on the DL and GMSK (EDGE) on the UL. The
maximum output power of carrier A in 8-PSK mode is 10 W* and GMSK mode is 20 W*.
The maximum output power of carrier B in GMSK mode is 20 W*.
68P02900W21-T
Jul 2010
System components
NOTE
The output powers listed are for 900 MHz frequency. For all other frequencies, the
output power varies.
Power-saving variants of the CTU2D have the capability to switch into sleep mode when idle,
reducing power consumption by about 27 W per radio per idle TS.
The hybrid of CTU2 and CTU2D can be configured in different operational modes within one
cell. Description and planning rules for the CTU2 are provided in Chapter 5 BTS planning steps
and rules of this manual. Configuration diagrams are shown in Chapter 12 Hardware and
compatibility. The receivers can support receive diversity.
CTU2
In Horizon II macro, the CTU2 provides the transceiver functions, which can be configured
to operate in single or double density mode.
The Horizonmacro can use this CTU2 as a CTU replacement with restrictions. Depending on the
number of CTU/CTU2s in the Horizonmacro cabinet, there are output power restrictions that
needs a mandatory third power supply installed in the Horizonmacro cabinet. This can affect the
battery hold-up module in ac-powered cabinets, as the location for the third power supply. That
is, the battery hold-up module should be removed, and an external battery backup unit added.
There are no available slots for the redundant power supply if three power supplies are required.
M-Cell6 and M-Cell2 can also use this CTU2 with a CTU2 Adapter. The M-Cell6 cabinet requires
up to three power supplies when used with CTU2s. The M-Cell2 cabinet requires up to two
power supplies when used with CTU2s.
Description and planning rules for the CTU2 are provided in Chapter 5 BTS planning steps
and rules of this manual. Configuration diagrams are shown in Chapter 12 Hardware and
NOTE
CTU2s do not support the use of CCBs. A CTU2 cannot be CCB equipped and does
not act as a full replacement or swap for the CTU. The CTU2 only acts as a CTU
replacement in the non-controller or standby controller mode. Contact the Motorola
Local Office for details. When installed in Horizonmacro, the CTU2 only supports
baseband hopping in single density mode.
CTU
The CTU provides the transceiver functions in Horizonmacro. Description and planning
rules for the CTU are provided in Chapter 5 BTS planning steps and rules of this manual.
Configuration diagrams are shown in Chapter 12 Hardware and compatibility. The receivers
can support receive diversity.
68P02900W21-T
1-7
Jul 2010
System components
DTRX
The dual transceiver module (DTRX) provides the transceiver functions in Horizonmicro,
Horizonmicro2, Horizoncompact, and Horizoncompact2. System planning is described in
Chapter 2 Transmission systems and configuration diagrams are shown in Chapter 12 Hardware
and compatibility. The receivers do not support receive-diversity.
TCU/TCU-B
The TCU or TCU-B (not BTS6) provides the transceiver functions in M-Cell6, M-Cell2, and BTS6.
Description and planning rules for the TCU/TCU-B are provided in Chapter 5 BTS planning
steps and rules of this manual. Configuration diagrams are shown in Chapter 12 Hardware and
TCU-m
A pair of TCU-ms provides the transceiver functions in M-Cellmicro, M-Cellcity and M-Cellcity+.
The receivers do not support receive diversity.
{FR35414} In the Motorola Horizon II BTS product line (macro, mini and micro), the functions
previously handled on the legacy MCUF, FMUX, and BPSM modules in the Horizonmacro
cabinet, are all integrated on a site controller board. Depending on the call load, site
configuration, and type of site controller, it is possible that the site controller can be the limiting
factor in defining the system capacity. A high level description of the different types of site
controller board available is now provided.
Horizon II Site Controller

The HIISC in Horizon II equipment provides all the site processing functions (except for the
CTU2 RF functions). The functionality of the separate, legacy MCUF, NIU, FMUX, and BPSM
modules in the Horizonmacro cabinet are all integrated within the HIISC.
The main features of the HIISC are as follows:
Processors for the software and NIU functionality.
Programmable timeslot interchanger (TSI) that supports the following:

TDM links for single (legacy) and double density GSM and single density EGPRS.
Three expansion links (FMUX equivalent). These links can connect to additional
Horizon II equipment (with double density GSM or single density EGPRS transceivers)
or legacy Horizonmacro cabinets (with single/double density GSM or single density
EGPRS transceivers).
BBH routing for the GSM/GPRS (single or double density) or the EGPRS transceivers.
Six integrated backhaul E1 span line interfaces.
Link to redundant HIISC (in Horizon II macro only).

The ASIC can switch any timeslot on the redundancy link to any timeslot on any of the
other links connected to it such as the transceiver links, network links, redundancy
links, or processor links.
1-8
68P02900W21-T
Jul 2010
System components
Front Panel Interfaces support:

Compact Flash card interface.
The card can be used to support onsite codeloading or copying of code objects from
the site.
RS232 TTY MMI interface.
A local maintenance terminal can be attached to this port to use the MMI of the HIISC.
CAL port interface.
HIISC-2
The Horizon II Site Controller-2 (HIISC-2) in Horizon II equipment provides the same set of
site processing functions offered by the HIISC. The HIISC-2 uses a hardware architecture
that is more powerful in terms of available memory, raw MIPS, and flexibility, which supports
more aggressive call loads.
In addition, it supports:
{33851} An automated clock calibration feature, in addition to the earlier manual

calibration method.
A front panel Ethernet port that allows a fast local codeload and copy back facility as well
as a fast and secure MMI/TTY access to the processors.
This Front Panel Ethernet port-based feature combined with the fixed onboard
non-volatile memory replaces the Horizon II Site Controller Compact Flash
functionality.
Up to 12 RSL per BTS
Redundancy when paired with another HIISC-2.
Redundancy when paired with a HIISC is not supported.
HIISC2-S is an enhanced variant of HIISC-2.
68P02900W21-T
1-9
Jul 2010
System components
HIISC2-S and HIISC2-E

The HIISC2-S and HIISC2-E in Horizon II equipment provides the same set of site processing
functions offered by the HIISC, using a hardware architecture that is significantly more powerful
in terms of available memory, raw MIPs and flexibility, enabling it to support more aggressive
call loads.
In addition it supports:
An automated clock calibration feature.

This is in addition to the legacy manual calibration method.
A front panel Ethernet port that allows fast local codeload and copyback facility as well as
fast and secure MMI/TTY access to the processors.
This Front Panel Ethernet port based feature combined with fixed onboard
non-volatile memory replaces the legacy H2SC Compact Flash functionality.
Support for redundancy when paired with another HIISC2-S or HIISC2-E.
HIISC2-E also provides an additional processor dedicated to support future packetized backhaul
features.
BBU-E
This board supports the same feature set as the HIISC2-S but an additional mezzanine card
is fitted to support (R)CTU8m radios and an additional processor dedicated to support future
packetized backhaul features.
Support for redundancy when paired with another BBU-E.
{34371-34374} Refer to CTU8m and RCTU8m feature on page 1-29 for further details regarding
the BBU.
NOTE
Mixed pair of HIISC2-S/E and BBU-E for redundancy is supported technically, but it
is not recommended due to its restricted application.
1-10
68P02900W21-T
Jul 2010
BSS features
BSS features
Planning impacts
This section provides a description of the software features that might affect the required
equipment before planning the actual equipment. Check with the appropriate Motorola sales
office regarding software availability with respect to these features.
Diversity on page 1-12
Frequency hopping on page 1-12
Short Message Service, Cell Broadcast (SMS CB) on page 1-13
Code Storage Facility Processor (CSFP) on page 1-13
PCU for GPRS upgrade on page 1-14
Enhanced-GPRS (EGPRS) on page 1-14
Adaptive Multi-Rate (AMR) on page 1-15
GSM half rate on page 1-16
LoCation Services (LCS) on page 1-17
IOS (Intelligent Optimization Service)/OPL (Optimization Link) on page 1-18
BSC Reset Management (BRM) on page 1-19
Advanced Speech Call Item (ASCI) on page 1-19
VersaTRAU backhaul for EGPRS on page 1-20
Quality of Service (QoS) on page 1-20)
QoS2 on page 1-22
Increased Network Capacity (Huge BSC) on page 1-23
Improved Timeslot Sharing (ITS) on page 1-23
Enhanced BSC capacity using DSW2 on page 1-24
High Speed MTL on page 1-24
Addition of new BSC/PCU software (PXP) and hardware (PSI2) to increase GPRS capacity
(ePCU) on page 1-24
High bandwidth interconnect between BSC and PCU (PSI2) on page 1-24
CTU2D on page 1-24
96 MSIs on page 1-26
68P02900W21-T
1-11
Jul 2010
Diversity
Support usage of idle TCH for burst packet traffic on page 1-26
{33254} Horizon II Site Controller-2 on page 1-28
{34371G} CTU8m and RCTU8m feature CTU8m and RCTU8m feature on page 1-29
{35200G} CTU8m and RCTU8m 8 carrier support on page 1-31
{34282} Increase RSL-LCF capacity on GPROC3/GPROC3-2 on page 1-32
{26638} SGSN(Gb) interface using Ethernet (Gb over IP) on page 1-32
{34416} PA bias feature in Horizon II sites with mixed radios on page 1-33
Increased Network Capacity (1000TRX BSC) enhancement on page 1-35
EGPRS Enhancement on page 1-35
{9810G} BBU-E 8/8/8 CTU8m HR EPG impact on page 1-34
{9722} Support large site 12/12/12 for GSR program on page 1-34
{35414} Porting Horizon II Site Controller 2 to GSR9 on page 1-36
Diversity
Diversity reception (spatial diversity) at the BTS is obtained by supplying two uncorrelated
receive signals to the transceiver. Each transceiver unit includes two receivers, which
independently process the two received signals and combine the results to produce an output.
This results in improved receiver performance when multipath propagation is significant and in
improved interference protection. Two Rx antennas are required for each sector. Equivalent
overlapping antenna patterns and sufficient physical separation between the two antennas are
required to obtain the necessary de-correlation.
Frequency hopping
There are two methods of providing frequency hopping synthesizer hopping and baseband
hopping. Each method has different hardware requirements.
The main differences are as follows:
1-12
Synthesizer hopping needs the use of wideband (hybrid) combiners for transmit combining,
while baseband hopping does not.
Baseband hopping needs the use of one transceiver for each allocated frequency, while
synthesizer hopping does not.
68P02900W21-T
Jul 2010
Short Message Service, Cell Broadcast (SMS CB)
Synthesizer hopping
Synthesizer hopping uses the frequency agility of the transceiver to change frequencies on a
timeslot basis for both receive and transmit. The transceiver calculates the next frequency and
re-programs its synthesizer to move to the new frequency. There are three important points to
note when using this method of providing frequency hopping:
Use Hybrid combining. Cavity combining is not allowed when using synthesizer hopping.
The output power available with the use of the hybrid combiners must be consistent with
coverage requirements.
It is only necessary to provide as many transceivers as required by the traffic. One

transceiver in each sector must be on a fixed frequency to provide the BCCH carrier.
Baseband hopping
For baseband hopping, each transceiver operates on preset frequencies in the transmit
direction. Baseband signals for a particular call are switched to a different transceiver at each
TDM frame to achieve frequency hopping. There are three important points to note when using
this method of providing frequency hopping:
The number of transceivers must be equal to the number of transmit (or receive)
frequencies required.
Use of either remote tuning combiners (only with single carrier radios, not the CTU2 and
CTU2D in double density, CTU8m, or (R)CTU8m) or hybrid combiners is acceptable. The
Horizon II cabinet does not support the integration of RTC.
Calls could be dropped, if a single transceiver fails, due to the inability to inform the MSs.
Short Message Service, Cell Broadcast (SMS CB)

The Short Message Service, Cell Broadcast (SMS CB) feature, is a means of unilaterally
transmitting data to MSs on a per cell basis. A Cell Broadcast Channel (CBCH) provides
this feature. The data originates from either a Cell Broadcast Center (CBC) or an OMC-R
(user-defined messages are entered using the appropriate MMI command). The CBC or OMC-R
downloads cell broadcast messages to the BSC, together with indications of the repetition rate,
and the number of broadcasts required per message. The BSC transmits these updates to the
appropriate BTSs, which ensures that the message is transmitted as requested.
Code Storage Facility Processor (CSFP)

The BSS supports a GPROC acting as the Code Storage Facility Processor (CSFP). The CSFP
allows preloading of a new software release while the BSS is operational. When BTSs are
connected to the BSC, a CSFP is required at the BSC and a second CSFP is equipped for
redundancy as required.
68P02900W21-T
1-13
Jul 2010
PCU for GPRS upgrade
PCU for GPRS upgrade

The PCU hardware provides GPRS functionality and is part of the BSS equipment. GPRS
planning is fundamentally different to the planning of circuit-switched networks. One of the
reasons for the difference is that a GPRS network allows the queuing of data traffic instead of
blocking a call when a circuit is unavailable. Consequently, the use of Erlang B tables for
estimating the number of trunks or timeslots required is not a valid planning approach for
the GPRS packet data provisioning process.
Enhanced-GPRS (EGPRS)
The Enhanced Data Rates for Global Evolution (EDGE) enhances the data throughput of the
GPRS to enable the Enhanced-GPRS (EGPRS) system. The planning guide takes into account
the larger data capacity of the system dependent on the expected EGPRS usage.
The EGPRS feature is an extension to the software architecture of the General Packet Radio
Service (GPRS) feature, and the Coding Scheme 3/Coding Scheme 4 feature. This means that
a network supporting EGPRS also provides support for the GSM voice and GPRS data. The
following are some of the features included with EGPRS:
EGPRS employs a new set of GSM modulation and channel coding techniques that increase
a packet data throughput of the user from a maximum of 21.4 kbps per air timeslot with
GPRS to a maximum of 59.2 kbps per air timeslot with EGPRS.
The maximum data throughput for a multi-slot mobile is significantly increased compared
to that in GPRS.
The initial release of EGPRS provides support for a multi-slot mobile using four downlink
and two uplink air timeslots. The EDMAC feature allows the support of mobiles classes
11 and 12 to enable 3 or 4 timeslot assignment in the UL.
The GSR10 release improves EGPRS to provide support for a multi-slot mobile using
5 downlink air timeslots. Extension of the EDMAC feature allows the support of mobiles
classes 11, 12, 32, and 33 to enable 3 or 4 timeslot assignment in the UL.
Support for the mobile classes, which dictate the multi-slot capabilities of a mobile and is
the same for EGPRS as in GPRS (classes 1-12 and 30-33).
Although a large portion of the EGPRS impact, the BSS software is focused on the air interface.
Impacts also exist on the terrestrial interfaces to carry the large volume of data traffic produced
by these new data rates.
NOTE
The data rates used here are theoretical values.
1-14
68P02900W21-T
Jul 2010
Adaptive Multi-Rate (AMR)
Adaptive Multi-Rate (AMR)

The AMR feature provides enhanced speech quality by adapting the speech and channel coding
rates according to the quality of the radio channel. It provides increased capacity by allocating
half rate channels to some or all mobiles. AMR selects the optimum channel rate as full rate (fr)
or half rate (hr) and codec mode (speech and channel bit rates) to provide the best combination
of speech quality and system capacity. The network user tunes this feature, on a cell-by-cell
basis to obtain the best balance between quality and capacity.
Due to the increased processing requirements of AMR, the existing GDP (which currently
supports 30 voice channels and data services) only supports 15 AMR voice channels. However,
two GDPs are paired to support a full E1s worth of channels (30). This results in an overall
reduction in transcoding shelf (or cage) capacity - 30 channels per GDP pair.
The AMR transcoder equipment (GDP2) is capable of supporting 60 voice (AMR or non-AMR)
channels, to reduce footprint. The RXU shelf has only one E1 connection per transcoder slot,
hence the GDP2 supports 30 channels in this configuration. The RXU3 and BSSC3 cabinet
utilize the added capacity.
NOTE
When using the GDP2 within the extension RXU3 shelf in a non-MSI slot, enable
the enhanced capacity mode to access the second E1.
The GDP2 can be used to full capacity in the existing BSU shelf, which has
no associated E1 limitation.
The existing hardware supports 16 kbps switching on the backhaul between the BSC and BTS.
Therefore, when using the existing switching hardware, each half rate equipped RTF must have
an additional two 64 kbps timeslots equipped to fully utilize all 16 half rate channels. The
existing hardware also supports 16 kbps switching on the backhaul between the BSC and
RXCDR, requiring 16 kbps per voice channel.
The Double Kiloport Switch (DSW2) has been introduced to address the problem. The DSW2
supports double the number of ports (enhanced capacity mode) when used in the RXCDR, as
well as subrate switching capability down to 8 kbps (extended subrate switching mode). With 8
kbps switching between the BSC and BTS, a half rate voice stream can be carried in an 8 kbps
subchannel, rather than the 16 kbps subchannel required with KSWs. This eliminates the
need for the two additional 64 kbps timeslots required per half rate capable RTF. There is one
exception, that is, when the 7.95 kbps half rate codec mode is included in the half rate Active
Codec Set. This codec mode needs 16 kbps backhaul, mandating the extra backhaul resources.
The half rate Active Codec Set is provisioned on a per cell basis.
Before AMR (and the use of half rate), all channels between the BSC and RXCDR (referred
to as the Ater interface) required 16 kbps Ater channels, which were assigned during
initialization/reconfiguration. With AMR, when a half rate traffic channel is assigned, the voice
stream utilizes an 8 kbps channel (depending upon the codec modes employed). The DSW2
benefit of 8 kbps subrate switching allows this capability to be realized. Dynamic assignment
of BSC to RXCDR channels is employed to maximize Ater channel usage. The BSC assigns an
8 kbps or 16 kbps channel as required, based upon the backhaul in use across the BSC-BTS
interface. This allows the operator to equip fewer channels than previously possible, with the
assumption that some calls are utilizing half rate backhaul.
68P02900W21-T
1-15
Jul 2010
GSM half rate
Extended range cells

AMR is only supported on the normal range timeslots and not on extended range timeslots.
Intra-cell handovers are supported between the two types of timeslots with the restriction that
an AMR call on a normal timeslot has to hand over to EFR/FR on the extended range timeslot.
Handovers in the opposite direction can hand over to AMR.
GSM half rate

GSM half rate offers enhanced capacity over the air interface, corresponding to the proportion
of mobiles within a coverage area that supports half rate. An air timeslot is split into two
subchannels, each containing a half rate channel. Speech quality is considered inferior to other
speech codecs but has a high penetration level (of GSM HR capable mobiles) due to its early
introduction into the standards and is considered a viable option for high-density areas.
The GDP and GDP2 boards are enhanced to support GSM HR, thus providing 30 and 60
channels of transcoding capability, respectively. The old RXU shelf has only one E1 connection
per transcoder slot, the GDP2 supports 30 channels when used in this configuration. The RXU3
shelf and BSSC3 cabinet are used to utilize the full capacity.
The backhaul between the BTS and BSC is 8 kbps or 16 kbps. 8 kbps needs that the subrate (8
k) switching is present at the BSC.
The existing hardware only supports 16 kbps switching on the backhaul between the BSC and
BTS. Therefore, when using the existing switching hardware, each half rate equipped RTF must
have an additional two 64 kbps timeslots equipped to fully utilize all 16 half rate channels. The
existing hardware also supports only 16 kbps switching on the backhaul between the BSC and
RXCDR, requiring 16 kbps per voice channel (as it does currently).
The Double Kiloport Switch (DSW2) supports subrate switching capability down to 8 kbps
(extended subrate switching mode), and double the number of ports (enhanced capacity mode).
With 8 kbps switching between the BSC and BTS, a half rate voice stream is carried in an 8 kbps
subchannel, rather than the 16 kbps subchannel required with KSWs. This eliminates the need
for the two additional 64 kbps timeslots required per half rate capable RTF.
As with AMR half rate, a GSM half rate call can fit within an 8 kbps timeslot (an Ater channel) on
the terrestrial resource from the BSC to the RXCDR, rather than the 16 kbps timeslot required
for full rate calls. If a percentage of the active calls is assumed to be half rate, the efficiency
can be gained by reducing the number of terrestrial resources between the BSC and RXCDR.
The DSW2 benefit of 8 kbps subrate switching allows this capability to be realized. Dynamic
assignment of BSC to RXCDR channels is employed to maximize Ater channel usage. The BSC
can assign an 8 kbps or 16 kbps channel as required, based upon the backhaul in use across the
BSCBTS interface. This allows the user to equip fewer channels than previously possible, with
the assumption that some calls are utilizing half rate backhaul. This dynamic allocation is an
enhancement to the existing Auto Connect mode feature, referred to as Enhanced Auto Connect
mode. Enhanced Auto Connect is applicable to both AMR and GSM half rate.

GSM half rate is only supported on the normal range timeslots and not on extended range
timeslots (it is envisaged that the C/I ratio in the extended range portion of an extended range
cell does not support a half rate call).
1-16
68P02900W21-T
Jul 2010
LoCation Services (LCS)
LoCation Services (LCS)

LCS provides a set of capabilities that determine location estimates of mobile stations and
makes that information available to location applications. Applications requesting location
estimates from LCS can be located in the MS, the network, or external to the PLMN. LCS is
not classified as a supplementary service and can be subscribed to without subscribing to a
basic telecommunication service. LCS is applicable to any target MS, whether the MS supports
LCS. However, there are restrictions on choice of positioning method or notification of a location
request to the MS user when the LCS or individual positioning methods respectively are not
supported by the MS.
LCS utilizes one or more positioning mechanisms to determine the location of a mobile station.
Positioning an MS involves two main steps:
Signal measurements.
Location estimate computation based on the measured signals.
Location service requests are divided into three categories:
Mobile originating location request (MO-LR)

Any location request from a client MS to the LCS server made over the GSM air interface.
While an MO-LR can be used to request the location of another MS. The primary purpose
of the request is to obtain an estimate of the location of the client MS, either for the client
MS itself or for another LCS client designated by the MS.
Mobile terminating location request (MT-LR)

Any location request from an LCS client where the client is treated as external to the
PLMN to which the location request is made.
Network induced location request (NI-LR)

Any location request for a target MS from a client considered to be within any of the PLMN
entities currently serving the target MS. In this case, the LCS client is also within the
LCS server. Examples of a NI-LR include a location request required for supplementary
services, for emergency call origination and by O&M in a visited PLMN.
LCS architecture
The LCS architecture can be one of the following:
NSS-based
The Serving Mobile Location Center (SMLC) is connected to an MSC instead of a BSC. The
MSC acts as a relay point for LCS signaling between the SMLC and BSC.
BSS-based
The SMLC is connected to a BSC instead of an MSC. The LCS signaling between the SMLC
and BSC goes directly between the two entities.
68P02900W21-T
1-17
Jul 2010
IOS (Intelligent Optimization Service)/OPL (Optimization Link)
IOS (Intelligent Optimization Service)/OPL (Optimization Link)

The Intelligent Optimization Service (IOS) is a network-based system which collects its
data from OPL. It involves analyzing large volumes of subscriber generated data regarding
the current network configuration and conditions. The operator uses the data to produce
recommendations for neighbor topology and frequency plan changes.
The Optimization Link (OPL) is used to carry measurement report data out of the BSC. The
link is a dedicated HDLC link between the BSC and IOS platform. It is a 64 kbps link that is
equipped to a E1 timeslot on an existing MMS. Operator commands indicate which LCF has
to be used for the data stream and indicates which data is required. If OPL is equipped in
the BSS system, it impacts on LCF and MSI planning in BSC. For detailed information, refer
Chapter 6 BSC planning steps and rules.
Figure 1-2 Intelligent Optimization Service
MS
RSL
BTS1
MS
BSC
RSL
BTS2
MS
RSL
OML
X.25
OPL
(64k HDLC)
OMC-R
LAN
BTSn
INTELLIGENT OPTIMIZATION SERVICE
DATA
COLLECTION
SYSTEM
LAN
DATA
ANALYSIS
SYSTEM
ti-GSM-IOS_OPL-00260-ai-sw
1-18
68P02900W21-T
Jul 2010
BSC Reset Management (BRM)
BSC Reset Management (BRM)

BSC Reset Management (BRM) provides the option for fast failover of the BSC, for certain types
of equipment failure. This minimizes the BSS outage, reducing the downtime from 10 minutes
to 20 minutes to less than two minutes for most occurrences.
NOTE
Equip the BSC with a redundant secondary BSP GPROC3/GPROC3-2 to utilize this
feature.
Advanced Speech Call Item (ASCI)

The Advanced Speech Call Item (ASCI) feature includes the enhanced Multi-Level Precedence
and Preemption (eMLPP) feature.
Enhanced Multi-level Precedence and Preemption

With the enhanced Multi-level Precedence and Preemption (eMLPP) feature, operators can
provide preferential services to special users with higher priority such as police and medical
personnel during emergency situations and high priority subscribers.
With the eMLPP feature, the following functions are supported:
Preemption: The Motorola BSS supports resource preemption based on a full set of A
Interface priority levels and procedures as defined in 3GPP TS 48.008. Enhancements
based on priority are also provided. Resources of lower priority calls can be preempted
to allow higher priority calls to go through. Preemption is supported in the following
procedures:
CS point-to-point call:
New call set-up
External handovers
Internal imperative handovers
Call switchover where calls do not necessarily require to be terminated due to a

single failure on the linkset between an RXCDR-BSC or due to MSC indicated
CIC changes.
The following types of resource preemption are supported:
TCH
Ater channel
Queue block
Priority Protection of switchable PDTCH Resources.
eMLPP priority support - BSS supports eMLPP priority between the MSC and MS.
68P02900W21-T
1-19
Jul 2010
VersaTRAU backhaul for EGPRS
VersaTRAU backhaul for EGPRS

VersaTRAU reduces EGPRS backhaul costs by taking advantage of statistical multiplexing. This
is achieved when packing variable size radio blocks to be sent over PDTCHs on a carrier, into
one large TRAU frame associated with the carrier. Analysis of the RF conditions of current
GPRS networks and predictions for EGPRS indicate that the average maximum throughput per
EGPRS TS does not use the entire DS0 (that is, reach MCS9).
The following are some of the key features included with VersaTRAU:
VersaTRAU allows the backhaul for an EGPRS capable carrier to be dynamically

provisioned in terms of 64 kbps terrestrial timeslots (DS0s).
Statistics are provided to the operator to measure the backhaul utilization for an EGPRS
capable carrier to detect whether the backhaul is under or over provisioned.
Traffic from all PDTCHs on a carrier is packed efficiently into a Versachannel of one
or more terrestrial timeslots associated with this carrier. Versachannel is defined as
the portion of the backhaul associated with an RTF that is used to carry TRAU frames
associated with the air timeslots configured as a PDTCH. TRAU frame formats carry the
multiplexed data blocks over the Versachannel.
All EGPRS capable carriers use VersaTRAU frame formats on the backhaul after introduction of
VersaTRAU. If half rate (GSM/AMR) is enabled on an EGPRS carrier, in order to maximize the
backhaul utilization, the 16 kbps switching format for the half rate calls is not supported on the
backhaul and 8 kbps switching (requiring DSWs) must be used.
Quality of Service (QoS)

With the Quality of Service (QoS) feature, operators are able to enter into varying levels of
Service Level agreements with end users that guarantee both different probabilities of access to
the network and different throughputs once the network is accessed. Admission and retention
control based Allocation/Retention priority (ARP), is provided for Interactive and Background
traffic classes. QoS for conversational and streaming traffic classes is not supported, however,
conversational and streaming traffic is allowed into the GPRS network and downgraded to
Interactive class and is not subject to further downgrade or preemption.
The QoS feature allows operators to charge premium rates for the highest quality of service
classes and thus to focus the resources of their network to their revenue generating customers.
The provision of focused QoS classes ensures that the subscribers receive the best possible
service specific to the types of applications used and specific to the type of tariff selected.
1-20
68P02900W21-T
Jul 2010
Quality of Service (QoS)
QoS dimensioning
The two most significant factors that influence quality of a service are:
Delay
Throughput
In R99 and beyond, four traffic classes are defined to accommodate the need for different levels
of these factors for different applications. These are as follows:
Conversational
Streaming
Interactive
Background
The BSS has internally defined additional traffic classes created by grouping similar PFC
characteristics. The internally defined traffic classes are as follows:
Short-Term Non-Negotiated Traffic (STNNT)
Pre-Admission PFC (PAP)
QoS disabled
As the specification for conversational and streaming is still evolving, the BSS is implementing
differentiation of service among interactive and background traffic classes. Requests to create
packet flows for streaming or conversational mode are treated as interactive traffic flows.
Support for streaming or conversational traffic class at the BSS is limited in its scope. That is,
streaming and conversational traffic classes get QoS of interactive traffic class when admitted.
However, the BSS does not make any guarantees regarding sustaining applications using the
streaming and conversational traffic classes.
QoS impacts on BSS

The QoS feature influence the following BSS entities:
Gb interface
PFM procedures over the Gb interface are defined in 48.018 as CREATE_BSS_PFC,
MODIFY_BSS_PFC, DOWNLOAD_BSS_PFC, DELETE_BSS_PFC, and their corresponding
ACKs and NACKs. In addition, the support for optional PFI IE in UL_UNITDATA and
DL_UNITDATA PDUs is also dictated by the support for PFM procedures.
PDTCH planning
The PDTCH formula in Chapter 3 BSS cell planning, has been updated to reflect the QoS
design to allow QoS to reserve the appropriate amount of throughput per cell. The updated
equations provide the cell with appropriate amount of throughput for QoS subscribers
based on the input to the formulas.
68P02900W21-T
1-21
Jul 2010
QoS2
PDTCH assignment to PRP

The formula for assigning PDTCHs to a PRP has been updated to allow subscribers with
QoS to have the necessary throughput reserved at the PRP. The formulas use the user
configurable parameters for MTBR for each Traffic Class and Coding Scheme usage to
determine the maximum number of PDTCHs to assign to a PRP.
QoS2
The QoS2 builds on top of QoS. The key components of QoS2 implementation are as follows:
Add support for Streaming Traffic class.
Maximum bit-rate enforcement as per the QoS profile.
Capacity is based on a less conservative budget to start (using user configurable initial
coding scheme).
Support for Streaming Traffic Class allows the operator to specify a service requiring constraints
on delay and jitter as well as minimum bit rate. Support for PFCs requesting streaming traffic
class can be enabled/disabled using the streaming_enabled BSS parameter. If support for
streaming traffic class is disabled, the BSS tries to admit the streaming traffic classes as one
of the matching interactive traffic classes (determined based on the MTBR settings, details
defined in the GSR8 QoS implementation).
Guaranteed Bit Rate as per the 3GPP specification is defined as the guaranteed number of bits
delivered at an SAP within a period (if there is data to deliver), divided by the duration of
the period. For the GPRS RAN, the guaranteed bit rate is defined as the bit rate at the LLC
layer. QoS introduced the internal BSS concept of an MTBR (Minimum Throughput Budget
Requirement) associated with each PFC. The Guaranteed Bit Rate for each PFC is an extension
of this concept except that the GBR must be enforced as a 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 (definition as per 23.107) indicates maximum delay for 95th percentile of the
distribution of delay for all delivered SDUs during the lifetime of a bearer service, where 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
(applicable only to real-time traffic classes streaming/conversational). In addition, the transfer
delay for Radio Access Bearer can be smaller than the overall requested transfer delay, as
transport through the core network uses a part of the acceptable delay. Transfer delay as all
other attributes in the Aggregate BSS QoS profile is negotiable.
QoS2 is based on the GSR8 implementation of QoS. All the PFCs for a given operator share the
same TBF over the air interface to transfer data for the PFCs. LLC scheduling within the TBF
is enhanced, and real-time service is prioritized appropriately over the non real-time services
where necessary. However, at the RLC layer, all PFCs for the mobile still share the same pipe.
Streaming support is limited to at most one active real-time PFC per user at any given time.
1-22
68P02900W21-T
Jul 2010
Increased Network Capacity (Huge BSC)
Maximum Bit Rate enforcement allows the BSS to throttle the throughput of the user to the
maximum bit - rate stated in the QoS parameters (ABQP) even if there is capacity to provide
the user a higher throughput. The main purpose of the maximum bit rate enforcement from a
users perspective is to limit the delivered bit rate to the applications or external networks and
to allow maximum required or permitted bit rate to be defined for applications able to operate
with different rates. The maximum bit rate applies to all traffic classes.
Streaming_enabled and qos_mbr_enabled parameters affect cell capacity. In addition,
some other parameters influence user experience although there is no impact to capacity,
which include stream_downgrade_enabled and mtbr_downgrade_enabled. For example, if
stream_downgrade_enabled is disabled and the idle resource is not enough, RT service is
rejected.
Increased Network Capacity (Huge BSC)

The optional feature, Increased Network Capacity enhances the network capacity and supports
database capacity up to 8 MB.
The network capacity is as follows:
The maximum number of carriers that a BSC supports increases from 512 to 750.
The maximum number of sites that a BSC supports increases from 100 to 140.
The maximum number of circuits that a BSC supports increases from 3200 to 4800.
The maximum number of BSC-XCDR connectivity that a BSC supports increases from
27 to 42.
This feature has an impact on the collection and dispatch of the additional statistics due to the
increased number of managed objects. The upload and collection of statistics to the OMC takes
place at 30 minute or 60 minute intervals, and lasts for 20 minutes.
Improved Timeslot Sharing (ITS)

The Improved Timeslot Sharing feature supports EGPRS on DD CTU2 and does not retain
hardware changes of the CTU2. The BSS software and Horizon II firmware allow each CTU2
to be able to switch rapidly between Double Density modulation (GMSK) and Single Density
modulation (8-PSK). The power output is not affected for GMSK and 8-PSK. Thus, the EGPRS
PDTCH can only be configured on Carrier A of DD CTU2 while the corresponding timeslots on
the paired Carrier B have to be blanked out. Although the feature of ITS does not double the
voice capacity per CTU2, compared with EGPRS on single Density Mode CTU2, it offers more
channels to service voice users with EGPRS service in parallel.
68P02900W21-T
1-23
Jul 2010
Enhanced BSC capacity using DSW2
Enhanced BSC capacity using DSW2

This feature expands (double) the TDM timeslots in the BSC from 1024 TSs to 2048 TSs in one
switch cage using bank 0/1 extension mode. When this switch cage has one or more extension
cages, the switch cage uses 1024 TSs (BANK0), and other extension cages share the rest of the
1024 TSs (BANK1). When up to 4 switch cages are configured, the maximum capacity is 8192 x
64 kbps TSs. This allows more devices, for example MSI, PSI to be equipped in multiple cages.
High Speed MTL

HSP MTL feature offers enhanced capacity and flexibility of MTL to support huge BSC
configurations by increasing the capacity of MTL from 64 k to 2M. The BSC supports High
Speed MTL (HSP MTL) link utilization to a maximum of 13%. This feature utilizes and needs the
GPROC3-2 hardware to increase the MTL capacity.
Addition of new BSC/PCU software (PXP) and hardware (PSI2)

to increase GPRS capacity (ePCU)
The evolved PCU feature provides a migration path to expand existing GPRS capabilities.
The U-DPROC2 brings all the functionality of the DPROC board, with additional capability
for high-capacity operations. The U-DPROC2 is configured as a PXP, which combines the
functionality of the PICP and PRP on the same board. The PXP is connected to the PSI2 board in
the BSC through an Ethernet link.
High bandwidth interconnect between BSC and PCU (PSI2)

The PSI2 card connects the BSC to the PCU with Ethernet connectivity. The physical interface
from the card is a 1000BASE-T over four pairs of copper wire. This connection can also be
operated in 100BASE-TX mode of operation, utilizing two pairs of copper wire. The standard
backplane connection is used, with a PBIB or PT43 board replacing the BIB or T43 board,
respectively, at the top of the cabinet. The new interconnect board (PBIB or PT43) at the top
of the BSC cabinet allows a single RJ45 Ethernet connection instead of two span lines for one
of the supported MSI positions. This link is referred as the Ethernet Link unless it is required
to specify 100BASE-TX or 1000BASE-T modes of operation.
CTU2D
The CTU2-D radios support both SD and DD EDGE architectures in addition to the various
modes supported by the existing CTU2 radios. The previous CTU-2 Carrier A/B definitions and
nomenclature also apply to the CTU2D. The following EDGE modes are supported:
1-24
68P02900W21-T
Jul 2010
CTU2D
CTU2D SD
This mode is identical in operation to the existing CTU2 SD and is only included for
reference.
CTU2D PWR
This mode is also known as ITS Mode whereby the CTU2 and CTU2-D operations are
identical. Of the two carriers, if the TS on carrier A is supporting an EDGE TS, then the
corresponding TS on carrier B is blanked, that is, it does not support anything. The Carrier
B TS is capable of supporting only TCH or GPRS PDs while the corresponding TS on
carrier A does not have an EDGE TS. The maximum output power of both carriers whether
in GMSK or 8-PSK mode is 20 W* as shown in Figure 1-3.
Figure 1-3 CTU2D PWR
T
DD 20 W
CTU2D PWR/CTU2 ITS
T/G T/G T/G T/G

ti-GSM-CTU2D_PWR-00002-ai-sw
CTU2D CAP
Of the two carriers, carrier A is fully EDGE-capable, while carrier B supports GPRS/TCH.
TS blanking is not required. The maximum output power of carrier A in 8-PSK mode is
10 W* and GMSK mode is 20 W*. The maximum output power carrier B (GMSK only)
is always 20 W* as shown in Figure 1-4.
Figure 1-4 CTU2D CAP
E
DD 10 W
CTU2D CAP
or T or G
No E
B
T/G T/G T/G T/G T/G T/G T/G T/G
ti-GSM-CTU2D_CAP-00003-ai-sw
68P02900W21-T
1-25
Jul 2010
96 MSIs
CTU2D ASYM
Of the two carriers, carrier A is fully EDGE-capable, while carrier B supports EDGE on
the DL and GMSK (EDGE) on the UL. The maximum output power of carrier A in 8-PSK
mode is 10 W* and GMSK mode is 20 W*. The maximum output power of carrier B in
GMSK mode is 20 W* as shown in Figure 1-5.
Figure 1-5
CTU2D ASYM
All PDCHs on this

carrier do not support
8 PSK in UL (aka are
GMSK restriction)
E
DD 10 W
CTU2D ASYM
or T or G
B
or T or G
NOTE
The output powers listed are for 900 MHz frequency. For all other frequencies, the
output power varies.
96 MSIs
This feature expands the number of MSIs supported from 56 to 96 and allows for additional E1s
between the BSC and the BTSs, RXCDRs, and PCU.
The impact on BSS is as follows:
If 96 MSIs are equipped at a BSC (12 MSIs in each of 8 cages), one PCU is deployed per
BSC to keep the total number of MMS/MSIs in the entire BSS system limit.
If the Enhanced Capacity mode at the BSC feature is enabled:

When the system is operating in single rate mode, some devices can be out-of-service
until the full enhanced capacity mode is re-enabled.
The OML controls the BSC in OMC side. An algorithm configures the MSI with the
OML with priority in the database to ensure the availability of MSI in either single
rate or enhanced capacity mode.
Support usage of idle TCH for burst packet traffic

This feature provides a mechanism which allocates additional switchable PDTCH resource when
there is GPRS traffic congestion in this cell, and returns these PDTCH resources back to TCH
resources when GPRS traffic congestion is relieved. The additional switchable PDTCH resources
in this feature are defaulted as TCH resources which have no impact to normal voice call, and
is converted to switchable PDTCH when GPRS is congested.
1-26
68P02900W21-T
Jul 2010
Extended Range Cell for Data
The impact on BSS is as follows:
Timeslot planning
Idle TCH can be used for packet traffic when GPRS is congested in the cell level and the
feature is enabled, which impacts timeslot planning.
PCU processing capability planning

The feature supports the use of idle TCH for packet traffic only when GPRS is congested
in the cell level and the feature is enabled. These additional channels are configured as
switchable PDTCH which share the PCU resource in GPRS congestion status, but are
configured as TCH resource when GPRS congestion is relieved. The PCU processing
capability has to be planned considering these additional timeslots may be processed
during GPRS congestion status if this feature is enabled.
E1 planning
Some idle TCH can be used as switchable PDTCH for packet traffic when GPRS is congested
in the cell level and the feature is enabled. The additional switchable PDTCH during GPRS
congestion uses the additional GDS TRAU resources. The additional 64 k PDTCH shares
the RTF backhaul with the existing 64 k PDTCHs. Therefore, the additional GDS resource
and RTF resource for 64 k carriers (rtf_ds0_count) have to be considered while planning.
Extended Range Cell for Data

The conventional BSS system has a limited cell coverage radius. It cannot satisfy special
requirements at some specific network deployment environments, such as:
Larger cell sites allow better coastal and rural coverage
Reduced OPEX in sparsely populated areas
Providing service equilibrium across the network
Larger diameters of cell sites in areas where there is less traffic reduces the equipment needs in
sparsely populated areas. A normal GSM/ GPRS cell covers a radius of 35 km. An extended
range GSM cell can cover up to 121 km radius. In the normal range, the maximum timing
advance value of an MS can only go up to 63 bits. To accommodate the additional propagation
delay in the extended range, an extended range timeslot needs to support a timing advance
value of up to 219 bits. An extended range timeslot is created by coupling two regular TDMA
timeslots to support the extended timing advance, see Figure 1-6. Only the even-numbered
timeslot in an extended range pair is operational over the air.
68P02900W21-T
1-27
Jul 2010
Horizon II Site Controller-2
Figure 1-6
0
Normal and extended range timeslots
N o rm a l ra n g e
T D M A F ra m e w ith n o rm a l tim in g
a d va n ce ra n g e
E xte n d e d R a n g e
T D M A F ra m e w ith e xte n d e d ra n g e
tim in g a d va n ce
ti-GSM-T D M A fra m e _n o rm a l_extented_tim in g advance-00060-ai-sw
Earlier, when ERC feature was enabled, only GSM channel type (for example, TCH, SDCCH,
CCCH, BCCH, and others) could be supported on the extended timeslot. In this feature, the
GPRS/EGPRS channel type (that is, PDCH) can also be supported on extended timeslots of CTU2
and CTU2D radios. Extended timeslots can also be supported on a 64 k carrier, besides the
original 16 k/32k carrier. Extended PDCH can only be configured on one carrier per cell. An MS
in the extended range can only be allocated on an extended PDCH, while an MS in the normal
range can be allocated on a normal PDCH and/or an extended PDCH.
Horizon II Site Controller-2

{33254}
The HIISC2-S/E in Horizon II equipment provides the same set of site processing functions
offered by the Horizon II SC. The HIISC-2 uses a hardware architecture that is more powerful in
terms of available memory, raw MIPS, and flexibility, which supports more aggressive call loads.
1-28
68P02900W21-T
Jul 2010
CTU8m and RCTU8m feature
Planning impact
Updated information is available in the following chapters:
Key planning impacts and feature constraints are:
RSL planning impact
GPROC planning impact
It is necessary to understand the differences between the three SC2 variants (HIISC2-S,
HIISC2-E and BBU-E). For details refer BSS equipment overview on page 1-4 .

{34371G}
The new Horizon II BBU (R)CTU8m radio platform radically changes the traditional architecture
of Motorola GSM BTS product by separating the baseband and RF functionalities. The baseband
and RF functionalities are combined on traditional radio units, across a new dedicated baseband
unit (BBU) processing board and an in-cabinet (CTU8m) and out-of-cabinet ((R)CTU8m) variants
of RF units.
The GSM BBU module is a mezzanine baseband processing card attached to the Horizon II Site
Controller 2 (forming the BBU-E) within the GSM Horizon-II BTS family. It is responsible for
most digital baseband processing for multiple radio units (for example, channel coding/decoding,
filtering, demodulation, equalization, modem control loops, and so on), and the Radio
Sub-System (RSS). The RF unit deals with all the remaining radio functionalities between the RF
side input/output of a CTU-type radio and the over-sampled digital interface to the BBU. This
functionality includes most of the digital filtering applied in both transmit and receive directions.
Each such unit can handle up to 4 or 6 or {35200G} 8 GSM carriers. Both variants of the RF
solutions adopt wideband transmission and reception, using multi-carrier power amplifiers
(MCPA) and wideband receiver line-ups. The BBU refers to the BBU-E (combination of BBU and
Site Controller) card as a whole. Figure 1-7 shows the architecture diagram of (R)CTU8m.
68P02900W21-T
1-29
Jul 2010
Figure 1-7 Architecture diagram of (R)CTU8m
RCTU8m
RCTU8m
RCTU8m
RCTU8m
RCTU8m
Horizon II Cabinet
PSU
Site
Exp.
RF Modules
Site
Exp.
E1
Site
IO
Alarm Board
PSU
PSU
PSU
D4+
Links
D4+
Links
CTU2D
CTU2D
CTU2D
CTU8m CTU8m
Circuit
Breakers
CTU8m
BBU
BBU
Fans
ti-GSM-Architecture diagram (R)CTU4-00003.a-ai-sw
The features are:
1-30
CTU8m in-cabinet radio.
Remote Radio Head solution ((R)CTU8m), with fiber connection.
Introduction of an MCPA (Multiple Carrier Power Amplifier), with 20 MHz bandwidth.
Improved receiver sensitivity.
Radio hardware capability for LTE.
Future provisioning for higher density cell configurations (more carriers per cabinet).
68P02900W21-T
Jul 2010
CTU8m and RCTU8m 8 carrier support
Planning impact
R(CTU8m) radio
BBU-E board
D4+ link
R(CTU8m) and BBU-E connection and supported topologies
There is an RF bandwidth constraint of 20 MHz contiguous coverage in both the 900 MHz and
1800 MHz band per (R)CTU8m. For further details refer to Frequency planning on page 3-38
CTU8m and RCTU8m 8 carrier support

{35200G}
This feature adds seven and eight carrier mode of operation to the base CTU8m feature. Up
to eight carriers are supported in both the in-cabinet and remote radio units operating in the
900MHz and 1800MHz bands.
Planning impact
Key planning impact and feature constraint is

BSC capacity limits increased
NOTE
The 7 or 8 carriers per each (R)CUT4 radio can only be deployed in countries
accepting 3GPP multicarrier class 2 specifications (3GPP TS 45.008).
68P02900W21-T
1-31
Jul 2010
Increase RSL-LCF capacity on GPROC3/GPROC3-2
Increase RSL-LCF capacity on GPROC3/GPROC3-2

{34282}
This feature increases the capacity of LCFs on GPROC3 and GPROC3-2 boards that are
supporting RSLs and can be used to reduce the number of LCFs required for RSL processing. A
reduction in the number of LCFs required for RSL processing frees capacity at the BSC which
can be used to provide TDM timeslots for other devices at the BSC, or to support an increased
call load. The feature impacts planning for LCF GPROCs for RSL processing as the GPROC type
has to be considered due to different capabilities of GPROC2 and GPROC3/GPROC3-2 boards.
Planning impact
Chapter 9 Planning examples
GPROC3/GPRC3-2 capacity impact
Number of LCF GPROC calculation
NOTE
It is recommended that all the pool GPROCs are GPROC3/GPROC3-2 when the LCFs
supporting RSLs have been planned based on the capabilities of GPROC3/GPROC3-2.
If BSC configurations have mixture of GPROCs which include GPROC2s, there will
be a risk of overloading.
SGSN(Gb) interface using Ethernet (Gb over IP)

{26638}
Gb over IP provides network operators the flexibility to select more cost effective backhaul
options than E1. This would provide an alternative connection to the current E1 using frame
relay.
The option of supporting Gb interfaces over IP backhaul provides a lower cost (OPEX and
CAPEX) alternative to using Frame Relay over E1 for the Gb links. This also has the additional
benefits of an IP-based network such as flexibility, more standardization, better product
positioning, and not requiring expensive leased E1 lines/timeslots, and so on.
Only U-DPROC2 can interface IP-based Gb links. The reason being the U-DPROC2 has an
Ethernet interface on front panel that is necessary to support IP.
1-32
68P02900W21-T
Jul 2010
PA bias feature in Horizon II sites with mixed radios
With this option, the operator can configure a PXP type U-DPROC2 to be able to carry both Gb
over IP and GDS/GSL over IP traffic simultaneously. Such PXPs require two Ethernet ports. One
Ethernet port is physically used to transport Gb traffic and the other Ethernet port is physically
used to transport GDS/GSL traffic. The GDS Ethernet link between a PXP to a PSI in the BSC is
point to point. The PPROC mounted on these PXPs is capable of processing both GDS and Gb
traffic while the baseboard of the PXP is capable of processing GDS traffic.
The physical Ethernet Gb link is concatenated using an IP router/switch and connected to the
operators IP backbone which provides the necessary telecom security and QoS environment, for
example, VPN, IPSec, access control, attack protection, QoS networking.
Planning impact
Chapter 2 Transmission systems
Key planning impacts and feature constraint is

Number of Ethernet GBL link calculation
NOTE
The Ethernet GBL is supported only on the PXP U-DPROC2 board, and is therefore
not supported on the PICP and PRP boards. The Gb over IP feature is therefore
dependant on the ePCU feature in DD2 or DD3 configurations.
PA bias feature in Horizon II sites with mixed radios

{34416}
This power-saving feature supports the reduction in the Total Cost of Ownership (TCO). A traffic
allocation algorithm identifies the power-saving capabilities of different radios and concentrates
traffic on those that cannot be turned into sleep mode, so that the remaining radios in the BTS
can be kept in power-saving mode for a longer time.
Power savings can still be made if there are no power-saving radios in a BTS, by re-allocating
traffic on to the BCCH carrier enabling non-power-saving radios to stay in idle mode longer.
68P02900W21-T
1-33
Jul 2010
BBU-E 8/8/8 CTU8m HR EPG impact
Planning impact

Radio planning to maximal power saving
BBU-E 8/8/8 CTU8m HR EPG impact

{9810G}
The BBU-E capability is enhanced to support 24 carriers in any combination of GMSK or/and
8PSK modulation (including half rate, full rate, GPRS and EDGE carriers).
Updated Chapters
Key EPG impact and feature constraints
BBU-E planning impact
Support large site 12/12/12 for GSR program

{9722}
This feature supports large site 12/12/12 on GSR10 when Horizon II macro with two BBU-Es
and 6 (R)CTU8m is configurated, the maximum RF carriers per site is supported up to 36.
Updated chapters
Chapter 6: BSC Planning Steps and Rules
Key EPG impact and feature constraints
1-34
BTS planning impact
GPROC planning impact
68P02900W21-T
Jul 2010
Increased Network Capacity (1000TRX BSC) enhancement
Increased Network Capacity (1000TRX BSC) enhancement

GSR10 supports 1000TRX per BSC with the Increased Network Capacity (Huge BSC) feature
enabled. It requires that all the GPROCs in the BSC are GPROC3 or GPROC3-2.
Planning impact
Chapter 7 RXCDR planning steps and rules

BSC capacity limits increased
NOTE
The E1 limitation (up to 192 E1s in total in BSC) may be reached before the number
of carriers limit is reached in some situations. Methods of reducing the required
E1 resource on BSC are:
Upgrade from PCU to ePCU feature, which replaces E1 links with Ethernet links
saving a number of BSC E1 ports (MSI slots).
Applying daisy chaining and/or applying half rate Ater channels based on call
model can increase E1 utilization thus save E1 ports in BSC.
EGPRS Enhancement
The EGPRS Enhancement extends the current downlink mobile allocation from 4 to 5 downlink
air timeslots, and extension of the EDMAC feature increases uplink throughput of a mobile.
Planning impact

There are no specific planning impacts except where indicated in the text
68P02900W21-T
1-35
Jul 2010
Porting Horizon II Site Controller 2 to GSR9
Porting Horizon II Site Controller 2 to GSR9

{35414}
The HIISC2-S and HIISC2-E in Horizon II equipment provides the same set of site processing
functions offered by the H2SC, using a hardware architecture that is significantly more
powerful in terms of available memory, raw MIPs, and flexibility, enabling it to support more
aggressive call loads.
1-36
68P02900W21-T
Jul 2010
BSS planning overview
BSS planning overview
Introduction
A brief overview of the planning process is provided in this section.
Background information
Before planning, the required information is categorized into three main areas:
Traffic model and capacity calculations
Category of service
Site planning
Traffic model and capacity calculations

The following information is required to calculate the capacity required:
Traffic information (Erlangs/BTS) over desired service area
Average traffic per site
Call duration
Number of handovers per call
Ratio of location updates to calls
Ratio of total pages sent to time in seconds (pages per second)
Ratio of intra-BSC handovers to all handovers
LCS usage
Number of TCHs
Half rate (AMR or GSM) usage
Ratio of SDCCHs to TCHs
Link utilization (for C7 MSC to BSS links)
SMS utilization (both cell broadcast and point to point)
Expected (applied and effective) GPRS load
68P02900W21-T
1-37
Jul 2010
Background information
eMLPP impact on BSS equipment and capacity calculations

With eMLPP feature, preferential service is provided for higher priority calls by preempting the
resource from lower priority calls when the system is under congestion. When planning radio
and terrestrial resources, the adequate resources require to be planned by treating all calls
equal without considering preemption. That is, BSS planning focuses on providing planning
steps and rules under normal traffic load without congestion, with certain capacity margin
planned for traffic surge or congestion, such as link provisioning based on 25% or 35% or 40%
signaling link utilization, or processor provisioning based on 70% utilization.
Therefore, BSS equipment planning disregards the eMLPP feature, and capacity or equipment
calculation formula is not updated for this feature.
Category of service
Category of service area urban, suburban, or rural:

Cell configuration in each category, sector against omni.
Frequency re-use scheme to meet traffic and C/I requirements.
Number of RF carriers in cell/sector to support traffic.
Grade of service of the trunks between the MSC/BSC, that is, Erlang B at 1%.
Grade of service of the traffic channels (TCH) between the MS and BTS, that is, Erlang
B at 2%.
Cell grid plan, a function of the following:

Desired grade of service or acceptable level of blockage.
Typical cell radio link budget.
Results of field tests.
Site planning
The following information is required to plan each site.
Location of the BSC and BTSs.
Local restrictions affecting antenna heights, equipment shelters, and so on.
Number of sites required (RF planning issues).
Re-use plan (frequency planning) omni or sector:

Spectrum availability.
Number of RF carrier frequencies available.
Antenna types and gain specification.
1-38
Diversity requirement. Diversity doubles the number of Rx antennas and associated

equipment.
68P02900W21-T
Jul 2010
Redundancy level requirements (determined for each item).
Supply voltage.
Planning methodology
Planning methodology
A GSM digital cellular system consists of several BSSs. The planning cycle begins with defining
the BSS cell, followed by the BTSs, BSCs, and the RXCDRs.
Planning a BSS involves the following:
Select the configuration, omni, or sectored and the frequency re-use scheme that satisfies
traffic, interference, and growth requirements.
Plan all the BTS sites as follows:

Use an appropriate RF planning tool to determine the geographical location of sites
and the RF parameters of the selected terrain.
Determine which equipment affecting features are required at each site. For example,
diversity or frequency hopping.
Plan the RF equipment portion and cabinets for each BTS site.
Plan the digital equipment portion for each BTS site.
Plan the BSCs after the BTS sites are configured and determine the following:
Which BTSs are connected to which BSC
How the BTSs are connected to the BSCs.
Traffic requirements for the BSCs.
Digital equipment for each BSC site.
Shelf, cabinets, and power requirements for each BSC.
Plan the remote transcoder (RXCDR) requirements and, if required, the subsequent
hardware implementation.
Plan the Packet Control Unit (PCU) for the desired packet data capacity for the system.
68P02900W21-T
1-39
Jul 2010
Acronyms
Acronyms
Acronym list
Table 1-2 contains a list of acronyms as used in this manual.
Table 1-2 Acronym list

Acronym
Meaning
AGCH
Access grant channel
A-GPS
Assisted GPS
ALM
Advanced load management
AMR
Adaptive multi-rate
ARFCN
Absolute radio frequency channel number
ARP
Allocation / retention priority
ARQ
Automatic repeat request
ASCI
Advanced speech call item
ATB
All trunks busy
BBH
Baseband hopping
{34371G} BBU
Baseband unit
BBU-E
Baseband unit-Enhanced
BCCH
Broadcast control channel
BCS
Block check sequence
BCU
Base controller unit
BE
Best effort
BER
Bit error rate
BG
Back ground
BHCA
BIB
Busy hour call attempts

Balanced line interface board
BLER
Block error rate
BRM
BSC reset management
BSC
Base station controller
BSP
Base station processor
BSS
Base station system
BSSC(n)
Base station system control (n = 2 or 3)

Continued
1-40
68P02900W21-T
Jul 2010
Acronym list
Table 1-2 Acronym list (Continued)

Acronym
Meaning
BSU
Base station unit
BTC
Bus termination card
BTF
Base transceiver function
BTP
Base transceiver processor
BTS
Base transceiver station
BVC(I)
C/I
BSSGP virtual circuit (identifier)

Carrier to interference ratio
CBC
Cell broadcast center
CBF
Combining bandpass filter
CBL
Cell broadcast centre link
CCB
Cavity combining block
CCCH
Common control channel
CDMA
Code division multiple access
CIC
Circuit identity code
CIR
Committed information rate
CLKX
Clock extender
CN
Core network
CP
Call processing
cPCI
Compact PCI
CPU
Central processing unit
CRC
Cyclic redundancy check
CS(n)
Channel coding scheme (number)
CSFP
Code storage facility processor
CTU
Compact transceiver unit
CTU2
Compact transceiver unit 2
CTU2D PWR
CTU2D double density power mode
CTU2D CAP
CTU2D double density capacity mode
CTU2D ASYM
{34371G}CTU8m
{34371G}D4+
DARBC
dB
CTU2D double density asymmetric mode

Compact transceiver unit 4
The Motorola defined fiber link standard
Dynamic allocation of RXCDR to BSC circuits
Decibel
DCD
Duty Cycle Distortion
DCF
Duplexed combining bandpass filter

Continued
68P02900W21-T
1-41
Jul 2010
Acronym list

Acronym
Meaning
DDF
Dual stage duplexed combining filter
DCS
Digital cellular system
DECT
DD
Digital enhanced cordless telephony

Double density
DDM
Dual density mode
DHU
Dual hybrid combiner unit
DL
Downlink
DLCI
Data link connection identifier
DLNB
Dual low noise block
DPROC
Data processor
(D)RAM
(Dynamic) random access memory
DRCU
DRI
DRIM
Diversity radio control unit

Digital radio interface
Digital radio interface module
DRX
Discontinuous reception
DSP
Digital signal processor
DSW2
Double kiloport switch
DSWX
Double kiloport switch (extender)
DTE
Data terminal equipment
DTRX
Dual transceiver module
DTX
Discontinuous transmission
DUP
Duplexer
DYNET
e
E1
EAC
EDGE
EDMAC
EFR
EGDP
Dynamic network
Erlang
32 channel 2.048 Mbps span line
Enhanced auto-connect
Enhanced data rates for global evolution
Enhanced Dynamic Allocation Medium Access Mode
Enhanced full rate
Enhanced generic digital processor
EGPRS
Enhanced-GPRS
EGSM
Enhanced global system for mobile communication
ELM
E-OTD
EGSM layer management

Enhanced observed time difference
Continued
1-42
68P02900W21-T
Jul 2010
Acronym list

Acronym
Meaning
ePCU
Evolved PCU (Enhanced PCU)
EMC
Electro Magnetic Compatibility
eMLPP
Enhanced multi-level precedence and preemption
FACCH
Fast access control channel
FEC
Forward error correction
FHI
Frequency hopping index
FM
Fault management
FMUX
FN
FOX
Fiber optic multiplexer (Horizonmacro)

Frame number
Fiber optic multiplexer (M-Cell)
fr
Full rate referring to the channel rate
FR
Frame relay, or full rate referring to the speech codec
FTD
File transit delay
FTP
File transfer protocol
GBL (or GbL)

GCLK
GDP(2)
GDS
Gb link
Generic clock
Generic digital processor (2)
GPRS data stream
GGSN
Gateway GPRS support node
GMLC
Gateway mobile location centre
GMM
GPRS mobility management
GMSK
Gaussian minimum shift keying
GOS
GPROC(n)
Grade of service
Generic processor (n = 1, 2, or 3)
GPRS
General packet radio system
GPS
Global positioning by satellite
GSM
Global system for mobile communication
GSM half rate
GSM half rate (GSM half rate speech version 1) feature
GSN
GPRS support node
GSR
GSM software release
HCOMB
Hybrid combiner
HCD
Hybrid combining duplexer
HCU
Hybrid combining unit
HDLC
High level data link control

Continued
68P02900W21-T
1-43
Jul 2010
Acronym list

Acronym
Meaning
HDSL
High bit rate digital subscriber line
HIISC
Horizon II macro site controller
HIISC2-E
Horizon II macro site controller 2-Enhanced
HIISC2-S
Horizon II macro site controller 2-Standard
HPM
High power mode
hr
Half rate (AMR or GSM), referring to the channel rate
HR
Half rate (AMR or GSM), referring to the speech codec
HSC
Hot swap controller
HSNI
Hopping sequence number interactive
IADU
Integrated antenna distribution unit
IMRM
Intelligent multi-layer resource management
IMSI
International mobile subscriber identity
INS
In service
IOS
Intelligent optimization service
IP
Internet protocol
IPL
Initial program load
IR
Incremental redundancy
ITS
Improved Timeslot Sharing
ISDN
Integrated services digital network
ISI
Inter symbol interference
ISP
Internet service provider
KSW(X)
LA
LAC
Kiloport switch (extender)

Link adaptation
Location area code
LAN(X)
Local area network (extender)
LAPB
Link access protocol balanced
LAPD
Link access protocol data
LCF
Link control function
LCS
Location services
LLC
Logical link control
LMTL
Location service MTL
LMU
Location measurement unit
LNA
Low noise amplifier
MA(IO)
Mobile allocation (index offset)

Continued
1-44
68P02900W21-T
Jul 2010
Acronym list

Acronym
Meaning
MAC
Medium access control
MAP
Mobile application part
MBR
Maximum bit rate
MCAP
MCBTS
{34371G}MCPA
MCU
MCUF
Motorola cellular advanced processor bus

Multi-Carrier Base Transceiver Station
Multi-carrier power amplifier
Main control unit
Main control unit with dual FMUX
MIB
Management information base
MLC
Mobile location centre
MMI
Man machine interface
MPROC
MS
MSC
MSI (-2)
MTBR
Master processor
Mobile station
Mobile switching centre
Multiple serial interface (2)
Minimum throughput budget requirement
MTL
MTP transport layer link
MTP
Message transfer part
NCH
Notification channel
NE
Network element
NIU
Network interface unit
NPM
Normal power mode
NSE (I)
Network service entity (identifier)
NSP
Network support program
NSS
Network subsystem
NSVC (I)
Network service layer virtual circuit (identifier)
NTP
Network time protocol
NVM
Non volatile memory
O&M
Operations and maintenance
OLM
Off line MIB
OMA
Optical Modulation Amplitude
OMC-R
Operations and maintenance centre - radio
OMF
Operations and maintenance function
OML
Operations and maintenance link

Continued
68P02900W21-T
1-45
Jul 2010
Acronym list

Acronym
Meaning
OOS
Out-of-service
OPL
Optimization link
PACCH
Packet associated control channel
PAGCH
Packet access grant channel
PAP
Pre-admission PFC
PAR
Peak to average ratio
PBCCH
PBIB
PCCCH
Packet broadcast control channel

Packet BIB
Packet common control channel
PCH
Paging channel
PCI
Peripheral component interconnect
PCM
PCMCIA
Pulse code modulation

Personal computer memory card international association
PCR
Preventive cyclic retransmission
PCS
Personal communication system
PCU
Packet control unit
PDCCH
Packet dedicated control channel
PDN
Packet data network
PDP
Packet data protocol
PDTCH
Packet data traffic channel
PDU
Protocol data unit
PFC
Packet flow context
PFM
Packet flow management
PICP
Packet interface control processor
PIX
Parallel interface extender
PLMN
Public land mobile network
PMC
PCI mezzanine card
PNCH
Packet notification channel
PPCH
Packet paging channel
PPP
Point to point protocol
PRACH
Packet random access channel
PSI2
Packet Subrate Interface 2
PSK
Phase shift keying
PSM
Power supply module

Continued
1-46
68P02900W21-T
Jul 2010
Acronym list

Acronym
PSTN
Meaning
Public switched telephone network
PSU
Power supply unit
PT43
Packet T43
PTCCH/D
Packet timing advance control channel / downlink
PTCCH/U
Packet timing advance control channel / uplink
PTP
Point to point
PVC
Permanent virtual circuit
PXP
Processor with PRP and PICP function
QOS (or QoS)
Quality of service
RACH
Random access channel
RAM
Random access memory
RAN
Radio access network
RAT
Radio access technology
RAU
Routing area update
{34371G}RCTU8m
RDB
Remote compact transceiver unit 4

Requirements database
RF
Radio frequency
RIN
Relative Intensity Noise
RLC
Radio link control
ROM
Read only memory
RRI
Radio refractive index
RSL
Radio signaling link
RTD
RLC transit delay
RTF
Radio transceiver function
RX (or Rx)
RXCDR
RXU
SACCH
SB
{33254}SC-2
SCC
Receive
Remote transcoder
Remote transcoder unit
Slow access control channel
Stealing bit
Horizon II site controller-2
Serial channel controller
SCCP
SS7 signaling connection control part
SCH
Synchronization channel
SCM
Status control manager

Continued
68P02900W21-T
1-47
Jul 2010
Acronym list

Acronym
SCU
SD
SDCCH
Meaning
Slim channel unit
Single Density
Stand alone dedicated control channel
SDM
Single density mode
SFH
Synthesizer frequency hopping
SFP
Small Form-Factor Pluggable
SGSN
Serving GPRS support node
SID
Silence descriptor
SLS
Signaling link selection
SM
Session management
SMLC
SMS
SNDCP
Serving mobile location centre

Short message service
Sub network dependent convergence protocol
SS7
CCITT signaling system number 7
STNNT
Short-term non-negotiated traffic
STP
SURF
SURF2
TBF
TCCH
Shielded twisted pair

Sectorized universal receiver front end (Horizonmacro)
Sectorized universal receiver front end 2 (Horizon II macro)
Temporary block flow
Timing access control channel
TCH
Traffic channel
TCP
Transmission control protocol
TCU
Transceiver control unit
TDM
Time division multiplexing
TDMA
Time division multiple access
TMSI
Temporary mobile subscriber identity
TOA
Time of arrival
TRAU
TS
TSW
Transcoder rate adaptation unit

Timeslot
Timeslot switch
TX (or Tx)
Transmit
U-DPROC2
Universal DPROC2
UE
User equipment
UL
Uplink
Continued
1-48
68P02900W21-T
Jul 2010
Acronym list

Acronym
UMTS
Uplink state flag
UTP
Unshielded twisted pair
VersaTRAU
Jul 2010
Universal mobile telecommunication system
USF
UTRAN
68P02900W21-T
Meaning
UMTS radio access network

Versatile transcoder rate adaptation unit
VGC
Voice group call
WAN
Wide area network
WAP
Wireless access protocol
XBL
Transcoder to BSS link
XCDR
Transcoder board
XMUX
Expansion multiplexer (Horizon II macro)
1-49
Acronym list
1-50
68P02900W21-T
Jul 2010
Chapter
2
Transmission systems
This chapter contains possible logical interconnections and descriptions of BSS interconnections.
The following topics are described:
BSS interfaces on page 2-2
Interconnecting the BSC and BTSs on page 2-4
Network topology on page 2-6
Managed HDSL on micro BTSs on page 2-24
68P02900W21-T
Jul 2010
2-1
BSS interfaces
BSS interfaces
Introduction
Figure 2-1 and Table 2-1 indicate the type of interface, rates, and transmission systems used to
convey information around the various parts of the BSS system.
Figure 2-1
BSS interfaces
OMC-R
OML
X.25
(LAPB)
Gb OPTION B
MSC
Air interface
MS
(LAPDm)
Abis interface
BTS
BSC
RSL (LAPD)
A interface
RXCDR
MTL (C7), XBL

(LAPD)
OML (X.25)
SGSN
GDS
Gb OPTION A
Gb OPTION C
PCU
CBL
X.25
(LAPB)
CBC
Gb OPTION D
(Ethernet/IP)
ti-GSM-BSS_interfaces-00005-ai-sw
Table 2-1
BSS interface
Interface
From/To
Signaling by
Air
MS - BTS
RACH, SDCCH,
SACCH, FACCH
Rate
Using
LAPDm
E1links
Abis (Mobis)
BTS - BSC
RSL
16/64 kbps
LAPD
Continued
2-2
68P02900W21-T
Jul 2010
Table 2-1
Introduction
BSS interface (Continued)
Interface
From/To
Signaling by
Rate
Using
BSS - MSC
MTL (OML, CBL)
64 kbps or
2048 kbps*
C7
RXCDR - BSC
XBL
16/64 kbps
LAPD
OMCR RXCDR/BSC
OML (X.25)
64 kbps
LAPB
BSC - CBC
CBL (X.25)
64 kbps
LAPB
BSC - IOS
OPL
64 kbps
HDLC
Gb
PCU - SGSN
GBL
E1 or 100M/
1000M
Ethernet**
Frame Relay or
Ethernet
GDS
PCU - BSC
GSL
64 kbps
LAPD
NOTE
68P02900W21-T
* The HSP MTL feature enables BSS support of 2048 kbps high speed signaling
link, that is, a whole E1 signaling link.
**The Gb over IP feature allows the choice of the Gb interface as either frame
relay E1 or 100M/1000M Ethernet. The Gb over IP feature only applies for
Option C as shown in Figure 2-1
2-3
Jul 2010
Interconnecting the BSC and BTSs
Interconnecting the BSC and BTSs
Introduction
Network topology is specified in terms of the paths between the BSC and the BTS sites. A
path is determined by E1 circuits, and possible intervening BTS sites are used to provide the
connection. Transcoding is performed at the BSC or RXCDR.
Interconnection rules
The following rules must be observed while interconnecting a BSC and BTSs:
2-4
The BSC shares MSI boards between BTSs. When there are two or more E1 circuits, at
least two MSIs are recommended for redundancy.
A minimum of one MSI is required at each BTS.
The maximum number of active carrier units is determined by available E1 circuit capacity.
Typically, a carrier unit needs two 64 kbps timeslots on an E1 circuit. An RTF is configured
as half rate capable, which means it can support AMR half rate and/or GSM half rate. Once
an RTF is configured as AMR half rate capable, and if AMR half rate is enabled, the 7.95
kbps half rate codec mode is included in the Half Rate Active Codec Set or (for either AMR
half rate or GSM half rate), 8 kbps subrate switching is not available. For example, if 16
kbps is used for the backhaul, then the carrier unit assigned to that RTF needs four 64
kbps timeslots on the E1 circuit (Refer to the NOTE).
In a redundant connection, each carrier unit needs two 64 kbps timeslots on two different
E1 circuits. If the half rate exception case applies four 64 kbps timeslots are required. The
AMR half rate exception case is defined as - A carrier which is assigned an RTF configured
as (AMR or GSM) half rate capable, and 8 kbps subrate switching is not available (for
example, 16 kbps is used for the backhaul), or (for AMR) the 7.95 kbps half rate codec
mode is included in the Half Rate Active Codec Set.
The Half Rate Active Codec Set is AMR specific and is configured on a per cell basis.
At the BSC, one E1 circuit is required to connect to a daisy chain. If the connection is a
closed loop daisy chain, two E1 circuits are required. To provide redundancy, the two E1
circuits must be terminated on different MSIs.
In a closed loop daisy chain, the primary RSLs for all BTS sites are routed in the same
direction with the secondary RSLs routed in the opposite direction. The primary RSL
at each BTS site in the daisy chain is always equipped on the multiple serial interface
link (MMS) equipped in CAGE 15, slot 16, port A. The secondary RSL at each BTS site is
equipped on the MMS equipped in either shelf 15, slot 16, port B, or shelf 15, slot 14,
port A, or shelf 14, slot 16, port A.
68P02900W21-T
Jul 2010
Interconnection rules
NOTE
When discussing the BSC or RXCDR, cage is a term previously used in BSS
commands that is replaced by shelf in this manual. That is, cage and shelf
mean the same thing.
Additional backhaul bandwidth is required to support GPRS traffic using CS3/CS4 coding
schemes. Each timeslot, on a CS3/CS4 capable carrier, needs 32 kbps for a total of four 64
kbps timeslots on the E1 circuit, irrespective of the speech coding.
Additional backhaul bandwidth is required to support EGPRS traffic using MCS1-MCS9

coding schemes. Each non-signaling timeslot, shares the Versachannel backhaul associated
with the particular carrier. Backhaul is provisioned based on expected EGPRS usage and
recommendation in Table 8-1 of Chapter 8 BSS planning for GPRS/EGPRS. Versachannel
is defined as the portion of the RTF backhaul that is used to carry the data for the air
timeslots configured as PDTCHs, at any given time.
The following rules must be observed while interconnecting InCell and M-Cell equipment:
Reconfigure the InCell BTS to have integral sectors in the cabinet.
Install M-Cell cabinets to serve the remaining sectors.
Daisy chain the M-Cell E1 links to the BSC.
68P02900W21-T
2-5
Jul 2010
Network topology
Network topology
Introduction
The operator can specify the traffic that is to use a specific path. A direct route between any
two adjacent sites in a network can consist of one or more E1 circuits. Figure 2-2 shows a
possible network topology.
Figure 2-2
Possible network topology
BSC
BTS 10
BTS 11
BTS 1
BTS 5
BTS 2
BTS 6
BTS 3
BTS 7
BTS 4
BTS 8
BTS 9
ti-GSM-Network_topologies-00006-ai-sw
Each BTS site in the network must obey the following maximum restrictions:
2-6
Six serial interfaces supported at a Horizon II macro BTS.
Six serial interfaces supported at a Horizonmacro BTS.
Two serial interfaces supported at a Horizonmicro2 / Horizoncompact2 BTS.
Six serial interfaces supported at an M-Cell6 BTS.
Four serial interfaces supported at an M-Cell2 BTS.
Two serial interfaces supported at an M-Cellcity / M-Cellcity+ BTS.
Ten BTS(s) in a path, including the terminating BTS for E1 circuit.
Six RSL signaling links per Horizon II macro BTS site (maximum of four per path).
Twelve RSL signaling links per Horizon II macro (mini/micro) with HIISC2-S/HIISC2E/BBU-E BTS site (maximum of four per path).
Six RSL signaling links per Horizonmacro or M-Cell BTS site (maximum of two per path).
68P02900W21-T
Jul 2010
Star connection
An alternative path is reserved for voice/data traffic in the case of path failure. This is known
as a redundant path, and is used to provide voice/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. If a path fails, the traffic can be
rerouted, but the signaling links go out-of-service, and the load is carried on the redundant links.
Star connection
A star connection is defined by installing E1 circuits between each BTS site and the BSC, as
shown in Figure 2-3.
Figure 2-3
Star connection
BTS 3
BTS 4
BTS 2
BTS 1
BTS 5
BSC
MSC
BTS 7
BTS 9
BTS 8
ti-GSM-Star_connection-00007-ai-sw
A star connection requires more MSI cards at the BSC than daisy chaining, for the same number
of BTS sites. The star connection allows for a greater number of carrier units per BTS site. An
E1 circuit provides for one signaling link, along with either:
Fifteen GSM voice carriers
Fifteen CS1/CS2 GPRS carriers
Seven CS3/CS4 carriers
Three or more EGPRS carriers (depending on the backhaul configured for each of these
carriers if VersaTRAU is enabled) or
Some proportionate mix of GSM, GPRS, and EGPRS
68P02900W21-T
2-7
Jul 2010
Daisy chain connection
NOTE
The number of carriers on an E1 circuit is reduced by 1 for each carrier to which

the half rate exception case applies.
The half rate exception case is defined in the section Interconnecting the BSC
and BTSs on page 2-4.

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 and interconnects smaller sites back to the BSC.
The daisy chain can be open ended or closed looped back to the BSC as shown in Figure 2-4.
Figure 2-4 Closed loop and open ended daisy chains
BTS 3
BTS 4
BTS 2
BTS 10
DAISY CHAIN
CLOSED LOOP
BTS 1
BRANCH OF THE
DAISY CHAIN
BTS 6
BTS 5
BSC
MSC
DAISY CHAIN
CLOSED LOOP
BTS 11
BTS 7
BTS 9
BTS 8
SINGLE MEMBER
DAISY CHAIN, A STAR
ti-GSM-Closed_loop_open_ended_daisy_chain-00008-ai-sw
The closed loop version provides for redundancy while the open ended version does not.
NOTE
Longer daisy chains (five or more sites) cannot meet the suggested round-trip delay.
Daisy chain planning

The introduction of multiple E1 circuits and branches increases the complexity of the network
topology. Since the network can contain multiple E1 circuits, branches, multiple paths over the
same E1 circuit, and closed loop interconnections, each E1 circuit is planned individually.
2-8
68P02900W21-T
Jul 2010
Daisy chain planning
Simple daisy chain

A daisy chain without branches and with a single E1 circuit between each of the BTSs is
referred to as a simple daisy chain. The maximum capacity supported in this connection is
limited by the capacity of the connection between the BSC and the first BTS in the chain. A
simple daisy chain is shown in Figure 2-5.
Figure 2-5 Simple daisy chain
Tx
Rx
Rx
Tx
BSC
Tx
Rx
Rx
Tx
Rx
BTS 1
BTS 2
Tx
Tx
USED IN CLOSED LOOP
CONNECTION ONLY
Rx
Tx
Rx
Rx
Tx
BTS 3
Tx
Rx
Rx
Tx
BTS 4
BTS X
ti-GSM-Simple_daisy_chain-00009-ai-sw
The capacity of a closed loop single E1 circuit daisy chain is the same as a daisy chain. The
closed loop daisy chain has redundant signaling links for each BTS, although they transverse the
chain in opposite directions back to the BSC.
The following equation determines the number of E1s required for a daisy chain:
NBSCBT S =
nE
GP RS
i=0
RT F DSO COU N T i + (nCGP RS 4) + (nTGP RS 2) + TAHRE 4 + b
Where:
NBSCBT S
31
Is:
minimum number of E1 links required (rounded up to an integer).
nEGP RS
total number of carriers in the daisy chain with EGPRS enabled.
nCGP RS
total number of carriers in the daisy chain with GPRS CS3 and CS4
enabled.
nTGP RS
total number of carriers in the daisy chain with GPRS CS1 and CS2
enabled, and GSM voice only carriers, where the half rate exception
case does not apply.
value of rtf_ds0_count for the RTF.
RT F DSO COU N T i
nTAHRE
b
68P02900W21-T
total number of GSM voice only carriers in the daisy chain where
the half rate exception applies.
number of BTS sites in the chain.
2-9
Jul 2010
Aggregate Abis
Example
Consider a daisy chain with three BTSs, each with 1 GSM voice carrier, 1 CS3/4 enabled carrier
and 1 EGPRS enabled carrier for which the half rate exception case does not apply. The number
of E1s required (assuming VersaTRAU is restricted - RTF_DS0_COUNT = 8 for each EGPRS RTF
and all EGPRS RTFs are non-BCCH) is shown:
[(3 8) + (3 4) + (3 2) + (0 4) + 3]
= 1.45E1s
31
Two E1s are required to support daisy chaining between the BTSs and the BSC.
Daisy chain with branch BTS site

The addition of a branch BTS site (BTS Y), as shown in Figure 2-6, affects the capacity of the
links between the BSC and the site from which the branch originates, as these are used for the
path to the branched site.
Figure 2-6 Daisy chain with branch
Tx
Tx
Rx
BSC
Rx
BTS 1
Rx
Tx
BTS 2
Rx
Tx
Rx
Tx
Tx
USED IN CLOSED LOOP
CONNECTION ONLY
Rx
Tx
Rx
Rx
Tx
BTS 3
Tx
Rx
Rx
Tx
BTS 4
BTS X
Rx
BTS Y
Tx
ti-GSM-Daisy_chain_with_branch-00010-ai-sw
A branch can have multiple BTS sites on it. A branch can be closed, in which case there are
redundant signaling links on different E1 circuits. In a closed loop, which needs redundant
signaling links for each BTS site, with an open branch, the E1 circuit to the branch has to carry
redundant signaling links.
Aggregate Abis
This is an option designed to allow greater flexibility while planning the network. It can also
help reduce leasing costs of E1 links by optimizing link usage over the greatest distance
between a BSC and a BTS.
2-10
68P02900W21-T
Jul 2010
Aggregate Abis
This is achieved by the introduction of third-party multiplexer equipment enabled by Motorola

software. This equipment allows timeslots on one E1 link to be multiplexed to more than one
BTS. Therefore, if the situation arises where several single carrier BTSs each need their own
dedicated E1 link, this greatly under utilizes each link capacity.
If the geographical locations of the sites and the distances of the E1 links are advantageous, it is
possible to initially send all the traffic channels for every site over one E1 link to the third-party
multiplexer and then distribute them over shorter distances to the required sites.
If the distance between the BSC and the multiplexer site is sufficiently large, this results in
significant leasing cost savings compared to the original configuration. There are two diagrams
illustrating the following (Figure 2-7) and subsequent (Figure 2-8) scenarios.
Figure 2-7 Typical low capacity BSC/BTS configuration
BSC
5x64 kbit/s TIMESLOTS USED
26x64 kbit/s TIMESLOTS UNUSED

BTS
BTS
TWO CARRIER
ONE RSL
TWO CARRIER
ONE RSL
BTS
TWO CARRIER
ONE RSL
ti-GSM-Low_capacity_BSC/BTS_configuration-00011-ai-sw
68P02900W21-T
2-11
Jul 2010
Aggregate Abis
Figure 2-8
Example using a switching network
BSC
MORE EFFICIENT USE OF

LONGEST E1 LINK

TWO CARRIER
ONE RSL
BTS

TWO CARRIER
ONE RSL
E1
MULTIPLEXER


BTS

BTS
BTS
TWO CARRIER
ONE RSL
TWO CARRIER
ONE RSL
ti-GSM-switching_network-00012-ai-sw
Another advantage of introducing the multiplexer is the improvement in the timeslot mapping
onto the Abis interface.
Currently they are allocated from timeslot 1 upwards for RSLs and timeslot 31 downwards for
RTF traffic channels. Most link providers lease timeslots in contiguous blocks (that is, there are
no gaps between timeslots). Under the existing timeslot allocation scheme this often means
leasing a whole E1 link for a few timeslots. There is a new algorithm for allocating timeslots
on the Abis interface. This is only used on the links that are directly connected to the new
aggregate service. The existing algorithm for allocating timeslots is used on the other links.
The new software allocates timeslots from timeslot 1 upwards. The RSLs are allocated first and
the RTF timeslots next, with each site being equipped consecutively, thus allowing contiguous
blocks of timeslots to be leased.
It is important that the sites are equipped in the order that they are presented. Also, RSLs
must be equipped first on a per site basis to coincide with the default timeslots for software
downloads to the BTSs. Figure 2-9 is an example of timeslot allocation in a network using an
aggregate service, with links to the aggregate service and links bypassing it.
NOTE
While it is possible to equip Horizon II macro BTSs supporting either the
HIISC2-S/E or BBU-E, with up to 12 RSLs, there are certain non-standard RSL PATH
configurations (the default RSL timeslots are not configured as RSL) that could
lead to only ten of these 12 RSLs being available (that is, enter the B-U state) for
codeloading to the BTS. Once the codeloading is complete, the remaining two RSLs
will be INS for normal Mobis signaling traffic. It is recommended to configure all the
three default RSL timeslots (one for each of the first 3 E1 span connection locations)
as RSL, so that all the configured RSLs are available for codeloading to the BTS.
2-12
68P02900W21-T
Jul 2010
Aggregate Abis
Figure 2-9 Timeslot allocation using new and old algorithms
NEW ALGORITHM
RSL1
6
RSL2
1
RTF1
RTF3
2
7
RTF1
3
RTF3
8
RTF2
4
9
RTF4
RTF2 10
5
RTF4
11
12
13
14
15
RSL3
RTF5
RTF5
RTF6
RTF6
TWO CARRIER
ONE RSL
1
2
3
4
5
RSL1
RTF1
RTF1
RTF2
RTF2
NEW
ALGORITHM
1
31
30
29
28
ALLOCATION
UNAFFECTED
16
17
18
19
20
RSL4
RTF7
RTF7
RTF8
RTF8
ALLOCATION AFFECTED
BTS 1
ORIGINAL
ALGORITHM
BSC
ALLOCATION
AFFECTED
1
2
3
4
5
RSL3
RTF5
RTF5
RTF6
RTF6
NEW ALGORITHM
RSL3
RTF5
RTF5
RTF6
RTF6
6
7
8
9
10
RSL4
RTF7
RTF7
RTF8
RTF8
E1
MULTIPLEXER
BTS 3
ALLOCATION AFFECTED
NEW
ALGORITHM
RSL2
1
RTF3
2
RTF3
3
4
RTF4
RTF4
5
ALLOCATION
AFFECTED
BTS 2
ORIGINAL
ALGORITHM
RSL4
1
RTF7
31
30
RTF7
RTF8
29
RTF8
28
ALLOCATION
UNAFFECTED
BTS 4
ti-GSM-Timeslot_allocation-00013-ai-sw
Similar problems are encountered while equipping redundant RSL devices onto paths containing
aggregate services. The new method of allocating timeslots when connecting to an aggregate
service is from timeslot 1 upwards, so it is not possible to reserve the default download RSL
timeslot. This gives rise to a situation where the default RSL timeslot is already allocated to
another device, for example RTF.
To avoid this situation, the primary and redundant RSLs can be equipped first (in an order that
results in the correct allocation of default RSL timeslots), or reserve the default download RSL
timeslot so that it is correctly allocated when the primary or redundant RSL is equipped.
If the site has to be expanded in the future to preserve blocks of contiguous timeslots on the
links, it is possible to reserve the timeslots required for the expansion so that they can be
made free in the future.
Alarm reporting
This feature has an impact on the alarm reporting for the E1 links. If the link is connected to a
third-party switching network and is taken out-of-service, the BTS reports the local alarm, but
the remote alarm only goes to the third-party aggregate service supporting the E1 link.
A situation may arise where the internal links within the E1 switching network fail, causing the
RSL to go out-of-service with no link alarms generated by GSM network entities (BTS, BSC). In
these cases, it is the responsibility of the third-party aggregate service provider to inform the
users of the link outage. The only indication of failure is the RSL state change to out-of-service.
68P02900W21-T
2-13
Jul 2010
Aggregate Abis
Figure 2-10 shows a possible network configuration using several switching networks.
Figure 2-10 Alternative network configuration with E1 switching network
BSC
E1
MULTIPLEXER
BTS
BTS
BTS
E1
MULTIPLEXER
BTS
BTS
BTS
BTS
BTS
E1
MULTIPLEXER
BTS
BTS
E1
MULTIPLEXER
BTS
BTS
ti-GSM-Alternative_network_configuration-00014-ai-sw
Restrictions/limitations
The ability to nail path timeslots along a link containing an E1 switching network is supported.
The operator is able to reserve, nail, and free timeslots.
The maximum number of sites within a path is ten for E1 networks. Even though it is a pseudo
site, the aggregate service is counted as a site in the path. Hence, the number of BTSs that can
be present in a path is reduced from ten to nine.
GCLK synchronization functions, but any BTS sites connected downlink from a switching
network synchronizes to it and not to the uplink GSM network entity (BTS, BSC).
2-14
68P02900W21-T
Jul 2010
RTF path fault containment

Each transceiver at a BTS needs a receive/transmit function to be enabled which notifies the
transceiver about various operating parameters which can be used. These include the ARFCN,
type of carrier, and primary/secondary path, among others. The path is of utmost importance.
An RTF can be assigned different paths. The path is the route which the two (or four for the half
rate exception case) 64 kbps timeslots, assigned to the transceiver from the E1 link, take to
get to and from the BTS/BSC. Each RTF can be assigned a different path for its two (or four)
timeslots, including RTFs that are in the same cell.
One path is designated as the primary, the other as the secondary. If the primary path fails,
the RTF selects the secondary path, and the carrier remains in call processing. If all the paths
to one RTF fail, the entire cell is taken out of call processing, regardless of whether there are
other transceivers/RTFs with serviceable paths in the same cell.
This allows the cell to remain in call processing if all paths to one RTF fail, as described in the
previous paragraphs. If there are available timeslots, any call in progress on the failed path is
handed over to the remaining RTFs in the same cell. If timeslots are unavailable, the call is
released. In addition, the timeslots on the transceiver of the failed path are barred from traffic
until the path is re-established, but any SDCCHs on the carrier remain active.
If all paths to all RTFs in an active cell have failed and there is still an active RSL, then the
cell is barred from traffic.
Advantages
This feature reduces timeslot, and removes redundant paths, that are normally equipped to
manage path failure. Figure 2-11 shows the conventional redundant set-up, which needs four
extra timeslots to provide for redundant paths. Figure 2-12 shows the alternative configuration,
where if one RTF path fails, call processing continues through the other path, although with
reduced capacity. This configuration only needs four timeslots instead of eight, as required
for Figure 2-11.
NOTE
Double the number of timeslots required for RTFs to which the half rate exception
case applies.
If an RTF path fails, the cost saving advantages of the alternative configuration has to be
balanced against the reduced capacity.
68P02900W21-T
2-15
Jul 2010
Figure 2-11 A configuration with a BTS equipped with two redundant RTFs
BSC
RTF1 EQUIPPED
ON PATH 1
(2 TIMESLOTS)
RTF1 EQUIPPED
ON PATH 2
(2 TIMESLOTS)
BTS 3
BTS 1
RTF2 EQUIPPED
ON PATH 1
(2 TIMESLOTS)
RTF2 EQUIPPED
ON PATH 2
(2 TIMESLOTS)
BTS 2
ti-GSM-BTS_with_two_redundant_RTFs-00015-ai-sw
Figure 2-12 A configuration with a BTS equipped with two non-redundant RTFs
BSC
RTF1 EQUIPPED
ON PATH 2
(2 TIMESLOTS)
RTF2 EQUIPPED
ON PATH 1
(2 TIMESLOTS)
BTS 3
BTS 1
BTS 2
ti-GSM-BTS_with_two_non_redundant_RTFs-00016-ai-sw
2-16
68P02900W21-T
Jul 2010
16 kbps RSL
The 16 kbps RSL reduces the transmission costs between the BSC and BTS (Abis interface)
for single carrier sites in particular.
Before the introduction of the 16 kbps RSL, a single carrier BTS required 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 normally accommodate eight traffic channels.
In a single carrier site, it is not possible to use all eight traffic channels of the two 64 kbps
timeslots. The reason being that, in the case of a single carrier site, the carrier is the BCCH
carrier and the air interface timeslot 0 of the BCCH carrier is reserved for BCCH information.
This information is generated at the BTS. The TSW at the BTS routes the traffic channels from
the two specified timeslots on the Abis interface to the dedicated transceiver for transmission.
The traffic channel on the Abis interface corresponding to the timeslot 0 on the air interface is
unused and is available to carry the signaling traffic. Therefore one 16 kbps subchannel remains
unused on the Abis interface, which is a waste of resources.
With the introduction of the 16 kbps RSL, it is possible to place it on this unused subchannel
because the RSL is not transmitting on the air interface. The advantage is that it frees up one 64
kbps timeslot on the Abis interface, reducing the requirement to serve a single carrier system to
only two 64 kbps timeslots. This operates with Horizon BTSs using KSW switching.
In a similar manner, when the single carrier is half rate capable and 16 kbps backhaul is used (8
kbps switching is unavailable or the 7.95 codec rate for AMR is included in the half rate active
codec set for that cell), this feature reduces the number of required E1 64 kbps timeslots from
five to four. (This is not shown in the table and figures.)
Figure 2-13 (fully-equipped RTF) and Figure 2-14 (sub-equipped RTF) show the eight types of
RTF which are possible using the previously described options. They are listed in Table 2-2.
Table 2-2
Type
68P02900W21-T
RTF types
Options
A fully equipped BCCH RTF with an associated 16 kbps RSL.
A fully equipped BCCH RTF with no associated 16 kbps RSL.
A fully equipped non-BCCH RTF with an associated 16 kbps RSL.
A fully equipped non-BCCH RTF with no associated 16 kbps RSL.
A sub-equipped BCCH RTF with an associated 16 kbps RSL.
A sub-equipped BCCH RTF with no associated 16 kbps RSL.
A sub-equipped non-BCCH RTF with an associated 16 kbps RSL.
A sub-equipped non-BCCH RTF with no associated 16 kbps RSL.
2-17
Jul 2010
Fully equipped RTF
Figure 2-13
Fully equipped RTF
FULLY EQUIPPED RTF
BCCH
NON-BCCH
16 kbit/s
BTS only
16 kbit/s
BTS only
ASSOCIATED
16 kbit/s RSL
NO
ASSOCIATED
16 kbit/s RSL
Configuration
ASSOCIATED
16 kbit/s RSL
3
NO
ASSOCIATED
16 kbit/s RSL
4
Timeslot X
Timeslot Y
KEY
16 kbit/s sub-channel unavailable for use.

16 kbit/s sub-channel used for 16 kbit/s RSL.
16 kbit/s sub-channel available for voice traffic.
ti-GSM-Fully_equipped_RTF-00017-ai-sw
2-18
68P02900W21-T
Jul 2010
Sub-equipped RTF
Figure 2-14 Sub-equipped RTF
SUB-EQUIPPED RTF
BCCH
NON-BCCH
16 kbit/s
BTS only
16 kbit/s
BTS only
ASSOCIATED
16 kbit/s RSL
NO
ASSOCIATED
16 kbit/s RSL
ASSOCIATED
16 kbit/s RSL
Configuration
NO
ASSOCIATED
16 kbit/s RSL
8
Timeslot X
Timeslot Y
KEY
16 kbit/s sub-channel used for 16 kbit/s RSL.

16 kbit/s sub-channel available for voice traffic.
ti-GSM-Sub_equipped_RTF-00018-ai-sw
68P02900W21-T
2-19
Jul 2010
16 kbps XBL
Planning constraints
The following RSL planning constraints apply:
A BTS supports either 16 kbps RSLs or 64 kbps RSLs, not both.
A BSC supports both 16 kbps and 64 kbps RSLs.
A BSU-based BTS supports up to six RSLs.
Horizon II macro and Horizonmacro supports up to six RSLs.
Horizon II macro (mini/micro) with HIISC2-S/HIISC2-E or BBU-E supports up to 12 RSLs.
Horizonmicro2 or Horizoncompact2 supports up to two RSLs.
M-Cell6 supports up to six RSLs.
M-Cell2 supports up to four RSLs.
M-Cellmicro and M-Cellcity support up to two RSLs.
The BTS and BSC support a mix of both fully equipped and sub-equipped RTFs.
A ROM download is carried out over a 64 kbps RSL, even at a site designated as a 16
kbps RSL.
A CSFP download utilizes a 16 kbps RSL at a 16 kbps designated site.
Up to twelve RSL links can be used for code loading when Horizon II macro (mini/micro)
configured with HIISC2-S/HIISC2-E or BBU-E.
The 16 kbps RSL can only be configured on CCITT subchannel 3 of a 64 kbps E1 timeslot
for BSU-based sites.
An associated 16 kbps RSL is supported on redundant RTF paths where one exists on the
primary path.
16 kbps XBL
The 16 kbps XBL provides a lower-cost solution by reducing the interconnect costs between
an RXCDR and BSC.
This is achieved by reducing the XBL data rate from the current 64 kbps to 16 kbps. This
frees three 16 kbps subchannels on the E1 64 kbps timeslot and enables them to be used as
TCHs. A BSC can interconnect up to ten RXCDRs. A total of 20 XBL links are deployed in any
configuration. An XBL can be configured without restriction in any timeslot.
It is possible to select a rate of 16 kbps or 64 kbps on an XBL basis. Therefore, there can
be two different rates at the same BSC to RXCDR, although this is not considered a typical
configuration. As a result of the introduction of the 16 kbps RSL, there is no reduction in the
processing capacity of the BSC or the RXCDR.
2-20
68P02900W21-T
Jul 2010
Dynamic allocation of RXCDR to BSC circuits (DARBC)
Figure 2-15 demonstrates XBL utilization.
Figure 2-15
XBL utilization
BSC 1
XBL
XBL
BSC 2
XBL
XBL
BSC 3
XBL
XBL
BSC 9
XBL
XBL
BSC 10
XBL
XBL
RXCDR
ti-GSM-XBL_utilization-00019-ai-sw
NOTE
In Figure 2-15 a maximum of two XBLs can be utilized between the BSC and
XCDR of either 64 kbps or 16 kbps on the E1 link.
A maximum of ten BSCs and RXCDR can be interconnected.

The DARBC feature provides fault management for call traffic on the BSC to RXCDR (Ater)
interface by managing the individual 16 kbps Ater channels. In addition, this feature provides
for validation of the 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 feature
in place, fault management of the Ater channels is not possible. All Ater and CIC information
must be manually verified by the operator, resulting in a higher O&M cost for the Motorola BSS.
An operator has the option to operate either in the auto-connect mode or in the backwards
compatibility mode. These modes are managed on a per AXCDR basis.
68P02900W21-T
2-21
Jul 2010
Auto-connect mode
The operator can select this mode. This mode refers to a BSC in which Ater channels are
allocated and released dynamically as resources are provisioned, unprovisioned, or while
handling a fault condition. Auto-connect mode provides fault tolerance along with the call
processing efficiency of the backwards compatibility mode. This is the recommended mode
of operation for the BSC.
Backward compatibility mode
NOTE
Backward compatibility mode cannot be used in conjunction with the AMR or GSM
half rate features. Auto-connect or enhanced auto-connect mode has to be specified.
This is a user selectable mode which refers to a BSC and/or RXCDR in which Ater channels and
CICs are statically switch connected. This mode does not provide any fault tolerance and CIC
validations. It is intended only to provide an upgrade path. Once both the BSC and RXCDR are
upgraded, the use of auto-connect mode is recommended.
NOTE
While upgrading the network, if the BSC is upgraded before the RXCDR, backwards
compatibility mode must be used for the corresponding AXCDR.
Before the introduction of this feature, all Ater channels were statically assigned and use of
XBL links was not mandatory. Currently, if an operator decides to use the auto-connect, it is
necessary to equip XBL links on the RXCDR and BSC. If XBLs are not equipped, and the AXCDR
is operating in the auto-connect mode, all CICs at the BSC associated with that AXCDR are
blocked and call traffic does not go to that AXCDR.
Enhanced auto-connect (EAC) mode

EAC mode allows for per call allocation of RXCDR to BSC circuits (Ater channels). There are
some issues that the operator must consider when planning and provisioning the BSC/RXCDR
network.
EAC mode is part of the AMR feature and also applies to the GSM half rate feature. It takes
advantage of the use of half rate traffic channels where only 8 kbps backhaul to the RXCDR
is required. EAC mode is user enabled across a BSC - RXCDR interface and only provides
benefits when the RXCDR is equipped with any number of EGDPs or GDP/GDP2s, and the BSC
and RXCDR are populated exclusively with DSW2s (no KSWs).
2-22
68P02900W21-T
Jul 2010
When in EAC mode, a CIC no longer has a fixed position on the Ater interface. Rather, a CIC
can be considered 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 a pooling
is that the number of CICs equipped that go through the RXCDR may not be the same as the
number of Ater channels from the BSC to the RXCDR. XBL links are required between the
BSC and RXCDR as in the auto-connect mode.
Equipping less than 16 kbps in Ater capacity per equipped CIC relies upon a percentage of the
calls to be utilizing half rate backhaul. If that assumption proves to be false, some capacity is
lost as CICs are unusable due to a lack of Ater resources [if CIC - Ater provisioning is equal (16
kbps Ater capacity per CIC), EAC mode is not required and the system automatically reverts to
auto-connect mode even if EAC is enabled]. EAC mode also needs XBL bandwidth. Use of EAC
mode (specifically the provisioning of fewer Ater channels than CICs) is best considered when
BSC - RXCDR backhaul costs are a concern.
If the operator chooses to equip a higher number of CICs than can be handled by the Ater
channels, there is a possibility that a call assignment may fail because Ater channels are
unavailable. To prevent such assignments from failing, the BSC provides a facility that
automatically blocks at the MSC, all idle CICs that go through a particular RXCDR when the
number of available Ater channels to RXCDR reaches a configurable threshold. The operator
controls such thresholds through the cic_block_thresh and cic_unblock_thresh values. These
thresholds are used to maintain Ater resources, to ensure that resources are available when a
fault occurs and also to balance the call load.
NOTE
For AMR, when the 7.95 kbps half rate codec mode is included in the Half Rate Active
Codec Set, 16 kbps backhaul is required. This is provisioned on a per cell basis and
should be taken into consideration when provisioning Ater resources.
68P02900W21-T
2-23
Jul 2010
Managed HDSL on micro BTSs
Introduction
Managed HDSL brings the benefits of full OMC-R management to those products that support
integrated HDSL technology. Specifically, it allows remote configuration, status, control, and
quality of service information to be handled by the OMC-R. External HDSL modems configured
as slave devices can also be managed by the same mechanism as long as they are connected to
an integrated master HDSL port.
This enables such an HDSL link to be managed entirely from the OMC-R. Following the
introduction of this feature, the initial basic version of the product is no longer supported.
NOTE
Horizonmicro2 microcell BTSs (and Horizoncompact2 macrocell BTSs) shipped
after 31st December 2001 are not fitted with an internal HDSL modem. A suitable
external HDSL modem must be used if an HDSL link to the BSC is required for these
BTSs. The local Motorola office can provide assistance before purchasing an HDSL
modem for this purpose.
Integrated HDSL interface

HDSL cable selection
The cabling has to comply with the following selection guidelines:
Correct number of pairs for an application.
Each tip and ring pair must be of a twisted construction.
The tip and ring must not be mixed between the pairs, that is, tip1 must not be used as
a pair with ring 2.
Either unshielded twisted pair (UTP) or shielded twisted pair (STP) can be used.
The cable gauge should be between 0.4 mm and 0.91 mm (AWG 26 to AWG 19).
Attenuation at 260 kHz should be less than 10.5 dB/km.
Cable runs should be limited to a length depending on the product.
Certain types of cables are known to perform suitably in HDSL applications, provided they are
correctly installed, and the guidelines for selection and installation are observed.
2-24
68P02900W21-T
Jul 2010
Integrated HDSL interface
Recommendations for the types of cables are as follows:
Unshielded twisted pair

BT CW1308 and equivalents
Category 3 UTP
Category 4 UTP
Category 5 UTP
Shielded twisted pair

Category 3 STP
Category 4 STP
Category 5 STP
The following kinds of cables should be avoided for HDSL applications:
Twisted quad cable is unsuitable for use in HDSL applications.
A drop wire that consists of two parallel conductors with supporting steel cable works with
HDSL but since it is not twisted, it provides little immunity from noise, and is therefore
not recommended.
An information cable which is typically made of non-twisted, multicore construction, for

example, ribbon cable, is not recommended.
HDSL cable installation

If cabling does not exist between two end sites, the guidelines to be followed for the installation
of cables are:
The conductor pairs should be connected point-to-point only, not point to multipoint.
The use of different gauges of cable in one link should be avoided.
Bridge taps in the cable run should be avoided.
Loading coils in the cable run must be removed.
The isolation between the tip and the ring should be greater than 1 M ohm (at SELV
voltage levels).
The isolation between the tip and earth should be greater than 1 M ohm (at SELV voltage
levels).
The isolation between the ring and earth should be greater than 1 M ohm (at SELV voltage
levels).
68P02900W21-T
2-25
Jul 2010
General HDSL guidelines
HDSL range
HDSL range is affected by many factors, which should be taken into account when planning
the system.
Microcell systems can have longer distances, typically 2 km or so, because of their
different link error requirements.
The following factors reduce the available distances:

Bridge gaps add unwanted loads onto the cables
Gauge changes add unwanted signal reflections
Small gauge cables increase the signal attenuations
Other noise sources
HDSL is specified not to affect other digital subscriber link systems and voice traffic.
NOTE
However, if unshielded from each other standard E1 traffic affects (and is affected
by) HDSL systems running in the same cable binder.
General HDSL guidelines

Conversion of E1 to HDSL at a site away from the BSC needs either an external modem or a
microsite. It is better to utilize the microsite to carry out this conversion (refer to Figure 2-16).
Microcell BTSs have a maximum of two 2.048 Mbps links. If the HDSL equipped version is
purchased (not available for Horizonmicro2 after December 2001), the links are automatically
configured as either E1 or HDSL through a combination of database settings and auto-detection
mechanisms. The setting of master/slave defaults can be changed by database settings for those
scenarios, such as a closed loop daisy chain, where the defaults are not appropriate.
2-26
68P02900W21-T
Jul 2010
Microcell system planning
Figure 2-16 Conversion of E1 to HDSL links by modem and microsite

E1 LINK
HDSL
SLAVE
EXTERNAL
MODEM
Horizonmicro2
E1 LINK
E1 LINK
BSC
Horizonmicro2
E1 LINK
HDSL
EXTERNAL
MODEM
HDSL
Horizonmicro2
Horizonmicro2
BTS
HDSL
E1 LINK
Horizonmacro
M - MASTER
SLAVE
HDSL
Horizonmicro2
Horizonmicro2
S - SLAVE
HDSL
Horizonmicro2
ti-GSM-Conversion_of_E1_to_HDSL_links-00020-ai-sw

Network configurations from the BSC can be a combination of daisy chain and star. Links can be
either E1 or HDSL, and can be mixed as appropriate within the network.
Daisy chain
Figure 2-17 shows a BSC connected to an external modem which then connects from its slave
port to the master port of the Horizonmicro2. The slave port of the Horizonmicro2 connects to
the next Horizonmicro2 master port, and so on, until the last Horizonmicro2 port is connected.
Figure 2-17
BSC
Microcell daisy chain network configuration
E1 LINK
SLAVE
EXTERNAL
MODEM
M - MASTER
S - SLAVE
68P02900W21-T
HDSL
Horizonmicro2
HDSL
Horizonmicro2
HDSL
Horizonmicro2
ti-GSM-Microcell_daisy_chain_network-ooo21-ai-sw
2-27
Jul 2010
Star configuration
Figure 2-18 shows a BSC which is connected to an external modem, which then connects from
its slave port to the master port of a Horizonmicro2. In this configuration, an external modem is
used every time a link to a Horizonmicro2 is used, hence the star formation.
Figure 2-18 Microcell star network configuration
E1 LINK
SLAVE
HDSL
EXTERNAL
MODEM
E1 LINK
BSC
SLAVE
Horizonmicro2
HDSL
EXTERNAL
MODEM
E1 LINK
SLAVE
Horizonmicro2
HDSL
EXTERNAL
MODEM
Horizonmicro2
M - MASTER
ti-GSM-Microcell_star_network_configuration-00022-ai-sw
E1 link
In Figure 2-19, an E1 link is used from the BSC to the first Horizonmicro2. From there onwards,
HDSL links are used, running from master to slave in each Horizonmicro2, or conversion can
be at any BTS, in either direction.
Figure 2-19
Microcell configuration using E1/HDSL links
E1 LINK
S
Horizonmicro2
HDSL
Horizonmicro2
HDSL
M
Horizonmicro2
BSC
M - MASTER
S - SLAVE
2-28
ti-GSM-Microcell_configuration_using_E1/HDSL_links-00023-ai-sw
68P02900W21-T
Jul 2010
Chapter
3
BSS cell planning
When planning a mobile telephone system, the aim is to create a communications network that
fulfills the following requirements:
Provides the desired capacity
Offers good frequency efficiency
Implemented at low cost
High grade service
These requirements, when analyzed, actually conflict with one another. Therefore, the operating
network is always a solution achieved through compromise. The cost of different network
configurations can vary considerably. From an engineering point of view, it would be worthwhile
to use efficient solutions despite high costs. However, a mobile telephone network is so huge
an investment that the financial factors are always going to limit the possibilities. The effect
of limited funds is obvious during the first stage of the network. Consequently, economical
planning is a condition for giving the best possible service from the onset.
The use of the GSM900, EGSM900, and DCS1800 frequency bands create many
propagation-based problems. As the channel characteristics are not fixed, design challenges
and impairments arise. These impediments must be dealt with to protect MS telephone users
from experiencing excessively varying signal levels and lack of voice quality.
It is important to predict the RF path loss between the BTS and the MS within the coverage area
in different types of environment. Knowledge of the transmitter and receiver antenna heights,
nature of the environment, and terrain variations is essential.
When planning a network, there are several major factors to be considered. These are described
in the following topics:
Planning tools on page 3-3
Traffic capacity on page 3-4
Adaptive multi-rate (AMR) on page 3-6
GSM half rate on page 3-10
Channel coding schemes on page 3-13
Subscriber environment on page 3-30
68P02900W21-T
Jul 2010
3-1
3-2
Microcellular solution on page 3-34
Frequency planning on page 3-38
Inter-radio access technology (2G-3G) cell reselection and handovers on page 3-44
Call model parameters for capacity calculations on page 3-48
Control channel calculations on page 3-52
GPRS/EGPRS traffic planning on page 3-73
GPRS/EGPRS network traffic estimation and key concepts on page 3-74
GPRS/EGPRS air interface planning process on page 3-96
68P02900W21-T
Jul 2010
Planning tools
Planning tools
Introduction
It is essential to make many calculations at regular intervals from the BTS to predict the signal
strength in a cell area. The smaller the interval, the more accurate is the propagation model. In
addition, calculations should be performed at regular distances along each radial arm from the
BTS, to map the signal strength as a function of distance from the BTS.
The result is the necessity to perform hundreds of calculations for each cell, which is time
consuming, but for the intervention of the software-planning tool.
The planning tool can be fed with all the details of the cell, such as:
Type of terrain
Environment
Heights of antennas
It can perform the necessary number of calculations required to provide an accurate picture of
the propagation paths of the cell.
Several planning tools are available in the market, such as Netplan or Planet, and it is up to
the operators to select the required tools that suit them best.
Check the figures by practical measurements after the calculation and implementation of the
cell. This is because, with all the variable factors in propagation modeling, an accuracy of
80% is considered excellent.
68P02900W21-T
3-3
Jul 2010
Traffic capacity
Traffic capacity
Dimensioning
One of the most important steps in cellular planning is system dimensioning. Some idea of the
projected usage of the system must be obtained (for example, the number of people wishing to
use the system simultaneously) to dimension a system correctly. This means traffic engineering.
Consider a cell with N voice channels; the cell is therefore capable of carrying N individual
simultaneous calls. The traffic flow is defined as the average number of concurrent calls carried
in the cell. The unit of traffic intensity is the Erlang. The traffic defined in this way can be
thought of as a measure of the voice load carried by the cell. The maximum carried traffic in a
cell is N Erlangs, which occurs when there is a call on each voice channel all the time.
If during a time period T (seconds), a channel carrying traffic is busy for t (seconds), then the
average carried traffic, in Erlangs, is t/T. The total traffic carried by the cell is the sum of the
traffic carried by each channel. The mean call holding time is the average time a channel is
serving a call.
Channel blocking
The standard model used to dimension a system is the Erlang B model, which models the
number of traffic channels or trunks required or a given grade of service and given offered
traffic. There are times when a call request is made and all the channels or trunks are in use,
this call is then blocked. The probability of this happening is the grade of service of the cell. If
blocking occurs, then the carried traffic is less than the offered traffic. If a call is blocked, the
caller can try again within a short interval.
If there is an absence of blocking, repeated call attempts increase the offered traffic the level.
Because of this effect, the notion of offered traffic is confusing. However, if the blocking
probability is small, ignore the effect of repeated call attempts and assume that the blocked
calls are abandoned.
The number of calls handled during a 24-hour period varies considerably with time. There are
two peaks during weekdays, although the pattern can change from day to day. Across the
typical day, the variation is such that a one-hour period shows greater usage than any other
does. From the hour with the least traffic to the hour with the greatest traffic, the variation can
exceed 100:1.
There can also be unpredictable peaks caused by a wide variety of events (for example, the
weather, natural disasters, conventions, sports events). In addition to this, system growth
should be taken into account. There are a set of common definitions to describe this busy
hour traffic loading.
Busy Hour: The busy hour is a continuous period during which traffic volume or number of
call attempts is the greatest.
Peak Busy Hour: The busy hour each day, it is not usually the same over some days.
Time Constant Busy Hour: The one-hour period starting at the same time each day for which
the average traffic volume or call attempts count is greatest over the days under consideration.
3-4
68P02900W21-T
Jul 2010
Traffic flow
Busy Season Busy Hour: The engineering period where the grade of service criteria is applied
for the busiest clock hour of the busiest weeks of the year.
Average Busy Season Busy Hour: The average busy season busy hour is used for trunk
groups and always has a grade of service criteria applied. For example, for the Average Busy
Season Busy Hour load, a call requiring a circuit in a trunk group should not encounter All
Trunks Busy (ATB) no more than 1% of the time. Peak loads are of more concern than average
loads when engineering traffic routes and switching equipment.
Traffic flow
If mobile traffic is defined as the aggregate number of MS calls (C) in a cell with regard to the
duration of the calls (T) as well as their number, then traffic flow (A) can be defined as:
Traffic Flow (A) = C x T
Where:
Is:
the calling rate per hour.
the average holding time per call.
Suppose an average hold time of 1.5 minutes is assumed and the calling rate in the busy hour is
120, then the traffic flow would be 120 x 1.5 = 180 call minutes or 3 call hours. One Erlang
of traffic intensity on one traffic channel means a continuous occupancy of that particular
traffic channel.
Considering a group of traffic channels, the traffic intensity in Erlangs is the number of
call-seconds per second or the number of call-hours per hour. For example, if there are a group
of 10 traffic channels, which had a call intensity of 5 Erlangs, then half of the circuits would be
busy at the time of measurement.
Grade of service
One measure of the quality of service is how many times a subscriber is unsuccessful in setting
up a call (blocking). Blocking data states what grade of service is required. It is given as a
percentage of the time that the subscriber is unable to make a call. Typical blocking for the
MS-BSC link is 2% with 1% being acceptable on the BSC-MSC link. There is a direct relationship
between the grade of service required and the number of channels. The desired grade of service
has a direct effect on the number of channels required in the network.
68P02900W21-T
3-5
Jul 2010
Adaptive multi-rate (AMR)
Adaptive multi-rate (AMR)
Introduction
AMR offers two strong benefits:
Expands air interface capacity through AMR half rate.
Expands the area of high call quality coverage through AMR full rate.
The ability of the AMR codec to change the allocation of source and channel coding bits provide
a high level of speech quality. The overall improvements are dependant upon channel quality
(C/I). A codec with a higher level of error protection (and a corresponding decrease in speech
quality) is selected as channel quality deteriorates, leading to an increase in the sensitivity of
the transceivers, thus providing optimum performance.
The half rate (hr) ability of AMR, which allows for two calls per timeslot, provides the largest
increase in capacity, but at a cost of a decrease in voice quality. Initially the AMR capable MS
penetration rate may be low; suggesting that in circumstances where capacity is paramount and
voice quality is secondary then GSM half rate is employed as an alternative. For details about
GSM half rate, see GSM half rate on page 3-10. With AMR operating in full rate mode, or in a
mix of full rate and half rate where handovers between the modes are permitted, a capacity gain
can be realized as a result of being able to operate at a lower C/I threshold. This can result in
higher traffic loading. However, the benefits of AMR do not extend to the signaling channels,
or to the use of non-AMR codecs and data services. Capacity gains of this type are dependent
upon other factors (for example, propagation conditions) and any improvement gained by a
replanning of existing systems should be considered with care.
The 3GPP document, TR 46.076, Adaptive Multi-Rate (AMR) speech codec; Study Phase Report,
is a summary of a report on AMR which contains additional information regarding the technical
aspects and benefits.
Capacity and coverage

AMR half rate doubles the number of voice calls that can be supported over the air interface,
thus allowing up to double the number of subscribers that are supported by a base station. This
is achieved by halving the air interface necessary to support a single voice call using AMR half
rate. On the backhaul, it is possible to support 8 voice calls per E1 timeslot instead of 4 when 8
kbps backhaul is used (refer to Figure 3-1).
3-6
68P02900W21-T
Jul 2010
Quality of service
Figure 3-1 AMR half rate capacity increase

AMR Full Rate, Enhanced Full Rate
and Full Rate coverage area
Timeslot 1
AMR Full Rate 1
AMR Half Rate coverage area
Timeslot 3
1 2 3 4
Timeslot 2
1 2 3 4
16 kbit/s
AMR Half Rate
1 23 4 5 6 7 8 1 23 4 5 6 7 8 1 2 3 45 6 7 8
8 kbit/s
2 X voice calls supported

per timeslot in AMR Half Rate
coverage area
ti-GSM-AMR_half_rate_capacity_increase-00127-ai-sw
Quality of service
AMR full rate delivers improved voice quality in poorer radio environments, providing high
quality in poorer signaling conditions:
AMR full rate offers higher quality voice communications in poor radio environments
such as corporate and urban buildings where no dedicated in-building coverage has been
provided.
AMR full rate improves voice quality across the entire network, by supporting high-quality
voice codecs in radio environments that cannot support Enhanced Full Rate (EFR).
AMR full rate expands the area of high-quality voice coverage within a cell by intelligently
selecting the best from a selection of codecs in various radio environments. Figure 3-2 shows
the different profiles of these codecs.
68P02900W21-T
3-7
Jul 2010
Applications
Figure 3-2 AMR full rate call quality improvements

In good radio environments:
AMR Full Rate voice quality = EFR Voice Quality
AMR Quality Improvements:

High voice quality in reduced radio quality
Mean Opinion
Score (MOS)
of voice
5.0
quality
4.0
3.0
2.0
1.0
EFR
12.2
10.2
7.95
7.4
6.7
5.9
5.15
4.75
No Errors C/I=16 dB C/I=13 dB C/I=10 dB C/I=7 dB
C/I=4 dB
C/I=1 dB
Conditions
ti-GSM-AMR_full_rate_call_quality_improvements-00128-ai-sw
In comparison to the EFR curve, AMR full rate offers a higher quality codec solution in marginal
radio environments (C/I = 13 dB to 4 dB). This enables operators to offer high voice quality
in radio environments that does not support EFR. This improvement is paramount in urban
environments, which usually have a C/I between 11 dB and 13 dB.
Applications
With the flexibility of the AMR system, it is possible to customize the application of AMR to meet
specific network and service needs. Some of the potential application scenarios are identified
together with the advantages offered and the types of networks to which they suit.
Full rate only - High quality over full range of channel errors
Due to the robust error correction, ability of AMR, improved resilience to errors compared to
GSM EFR is provided. So that when in call, the speech quality varies little with channel errors.
It also provides improved quality under marginal coverage conditions (for example, at cell
edge, coverage holes, and so on). Some capacity advantage is also derived from the improved
resilience under low C/I conditions. It supports tighter frequency re-use.
Potential service applications - Suitable for operators who do not require to increase capacity
through half rate operation, but wish to offer the best speech quality possible to all users.
Half rate only - Improved quality over current HR codec

The AMR codec can be operated in half rate channel mode to gain maximum capacity
advantage. Potential service applications - Suitable for operators who need the greatest capacity
enhancement from half rate operation. Some loss of quality at high channel error rates and in
background noise can be expected.
3-8
68P02900W21-T
Jul 2010
Migration to AMR half rate
Full and half rate operation - HR tied to cell congestion

In this case, full rate is used until cell congestion triggers a switch to use of half rate channels.
The operator also specifies a handover of half rate capable mobiles from a full rate channel to a
half rate channel to help ease the congestion. This provides a tuneable trade-off between call
quality and capacity. Potential service applications - Suitable for operators who want to combine
speech quality and capacity improvements.
Migration to AMR half rate

When migrating, care should be taken to ensure that the call capacity rating of the various
components of the system are not exceeded. Use of AMR HR improves the spectral efficiency
over the air interface (and potentially the backhaul), but from a load perspective a half rate
call has the same impact as a full rate call.
Interoperability with GSM half rate

AMR half rate and GSM half rate can coexist within a system, down to the RTF level. One
subrate operates as AMR half rate, the other as GSM half rate.
Interoperability with EGPRS

When AMR half rate is enabled on an EGPRS capable carrier (pkt_radio_type = 3) to maximize
the VersaTRAU backhaul utilization, only 8 kbps switching on the backhaul is supported.
68P02900W21-T
3-9
Jul 2010
GSM half rate
GSM half rate
Introduction
GSM half rate offers enhanced capacity over the air interface, corresponding to the proportion
of mobiles within a coverage area that supports GSM half rate. An air timeslot is split into two
subchannels, each containing a half rate channel. Although the speech quality is considered
inferior to other speech codecs, GSM half rate capable mobiles have a high penetration level
due to its early introduction into the standards and hence it is considered a viable option for
high-density areas.
Capacity and coverage

GSM half rate doubles the number of voice calls that can be supported over the air interface as
with AMR half rate, thus allowing up to double the number of subscribers that are supported
by a base station. This is achieved by halving the air interface capacity necessary to support a
single voice call using GSM half rate. On the backhaul, it is possible to support 8 voice calls per
E1 timeslot instead of 4 when 8 kbps backhaul is used (refer to Figure 3-3).
Figure 3-3 GSM half rate capacity increase

GSM Full Rate, Enhanced Full Rate
and Full Rate coverage area
Timeslot 1
Full Rate
GSM Half Rate coverage area
Timeslot 3
1 2 3 4
Timeslot 2
2 3 4
16 kbit/s
GSM Half Rate
1 23 4 5 6 7 8 1 23 4 5 6 7 8 1 2 3 45 6 7 8
8 kbit/s
2 X voice calls supported

per timeslot in GSM Half Rate
coverage area
ti-GSM-GSM_half_rate_capacity_increase-00129-ai-sw
3-10
68P02900W21-T
Jul 2010
Quality of service
Quality of service
The GSM half rate codec does not perform as well as the AMR half rate codec. Figure 3-4
shows the Mean Opinion Scores (MOS) for the various coding schemes versus C/I (the 4.75
<-> 7.95 values are for AMR half rate). This provides a relative comparison of voice quality
against the other codecs.
Figure 3-4 GSM half rate codec comparison
ti-GSM-GSM_half_rate_codec_comparison-00130-ai-sw
Applications
GSM half rate is best suited for use when spectral efficiency is required. Two useful application
scenarios are identified together with the advantages offered and the types of networks to
which they are suited.
NOTE
GSM half rate can be controlled at the cell level and is suitable to deal with high
user density clusters.
Half rate
The GSM half rate codec can be operated in half rate channel mode to gain maximum capacity
advantage. All qualifying calls are placed on a half rate channel.
Potential service applications - Suitable for operators who need the greatest capacity
enhancement from half rate operation. A reduction in speech quality is expected.
68P02900W21-T
3-11
Jul 2010
Migration to half rate
Full and Half rate operation - HR tied to cell congestion

In this case full rate is used until cell congestion triggers a switch to use GSM half rate
channels. The operator also specifies a handover of half rate capable mobiles from a full rate
channel to a half rate channel to help ease the congestion. This provides a tuneable trade-off
between call quality and capacity.
Potential service applications - Suitable for operators who want to combine speech quality
and capacity improvements.
Migration to half rate

When migrating, care should be taken to ensure that the call capacity rating of the various
components of the system are not exceeded. Use of GSM half rate improves the spectral
efficiency over the air interface (and potentially the backhaul), but from a load perspective a
half rate call has the same impact as a full rate call.
Interoperability with AMR half rate

GSM half rate and AMR half rate can coexist within a system, down to the RTF level. One
subrate is operating as GSM half rate, the other as AMR half rate.

When GSM half rate is enabled on an EGPRS capable carrier (pkt_radio_type = 3) to maximize
the VersaTRAU backhaul utilization, only 8 kbps switching on the backhaul is supported.
3-12
68P02900W21-T
Jul 2010
Channel coding schemes
Channel coding schemes
Channel coding scheme 1 (CS1)

CS1 is the most robust coding scheme of the four GPRS coding schemes. Figure 3-5 shows the
encoding of the user data (160 bits RLC data block, segmented LLC PDUs) and the RLC/MAC
header (24 bits) for downlink. In the first stage of coding, these 184 bits are protected according
to Fire code using extra 40 bits (BCS) for error detection (used in ARQ). The subsequent 224
bits are then convolutionally coded followed by interleaving over four bursts. CS1 provides a
user data rate (excluding RLC/MAC header) of 8 kbits/s.
Figure 3-5 GPRS channel coding scheme 1 (CS1)

3 bits
21 bits
160 bits
40 bits
USF
RLC/MAC Header
Data
BCS
Block coded
4 bits
TB
224 bits
Rate 1/2 convolutional coding
456 bits
Puncturing
456 bits
Block interleaving over 4 bursts
114 bits
114 bits
114 bits
114 bits
Mapped to 4 TDMA bursts; coding scheme

signalled through 8 stealing bits (2 per burst)
TB
Header & data
SB
TS
3 bits
57 bits
1 bit
26 bits
SB
Header & data
1 bit
57 bits
TB
3 bits
ti-GSM-GPRS_channel_coding_scheme_1-00172-ai-sw
68P02900W21-T
3-13
Jul 2010

CS2 is less robust than CS1 at the expense of providing higher user data rate. Figure 3-6
shows the encoding of the user data (240 bits RLC data block, segmented LLC PDUs) and the
RLC/MAC header (34 bits) for downlink. The USF bits (3) are pre-coded to provide additional
protection. In the first stage of coding, these 274 bits are protected according to Fire code
using extra 16 bits (BCS) for error detection (used in ARQ). The subsequent 290 bits are then
convolutionally coded, punctured, and interleaved over four bursts. CS2 provides a user data
rate (excluding RLC/MAC header) of 12 kbits/s.

6 bits
(pre-coded)
USF
28 bits
240 bits
16 bits
RLC/MAC Header
Data
BCS
Block coded
4 bits
TB
290 bits
588 bits
Puncturing
456 bits
114 bits
114 bits
114 bits
114 bits

TB
3 bits
Header & data

57 bits
SB
1 bit
TS
26 bits
SB
Header & data
1 bit
57 bits
TB
3 bits
3-14
68P02900W21-T
Jul 2010

CS3 is less robust than CS1 and CS2 at the expense of providing higher user data rate.
Figure 3-7 shows the encoding of the user data (288 bits RLC data block, segmented LLC PDUs)
and the RLC/MAC header (30 bits) for downlink. The USF bits (3) are pre-coded to provide
additional protection. In the first stage of coding, these 318 bits are protected according to the
Fire code using extra 16 bits for (BCS) for error detection (used in ARQ). The subsequent 334
bits are then convolutionally coded, punctured, and interleaved over four bursts. CS3 provides a
user data rate (excluding RLC/MAC header) of 14.4 kbits/s.

6 bits
(pre-coded)
USF
24 bits
288 bits
16 bits
RLC/MAC Header
Data
BCS
Block coded
4 bits
TB
344 bits
676 bits
Puncturing
456 bits
114 bits
114 bits
114 bits
114 bits

TB
3 bits
Header & data

57 bits
SB
1 bit
TS
26 bits
SB
Header & data
1 bit
57 bits
TB
3 bits
68P02900W21-T
3-15
Jul 2010

CS4 is the least robust GPRS coding scheme and it has no FEC capability. Figure 3-8 shows the
encoding of the user data (400 bits RLC data block, segmented LLC PDUs) and the RLC/MAC
header (40 bits) for downlink. The USF bits (3) are pre-coded to provide additional protection.
These 440 bits are protected according to Fire code using extra 16 bits (BCS) for error detection
(used in ARQ). The subsequent 456 bits are then interleaved (no convolutionally coding) over
four bursts. CS4 provides a user data rate (excluding RLC/MAC header) of 20 kbits/s.

12 bits
(pre-coded)
USF
28 bits
400 bits
16 bits
RLC/MAC Header
Data
BCS
Block coded
456 bits (0 bits TB)
No convolutional coding
456 bits
No puncturing
456 bits
114 bits
114 bits
114 bits
114 bits

TB
Header & data
SB
TS
3 bits
57 bits
1 bit
26 bits
SB
Header & data
1 bit
57 bits
TB
3 bits
All control channels except for the PRACH use CS1. Two types of packet random access burst
are transmitted on the PRACH: an 8 information bits random access burst, or an 11 information
bits random access burst (called the extended packet random access burst). The mobile must
support both random access burst types.
3-16
68P02900W21-T
Jul 2010
16/32 kbps TRAU
GPRS traffic channels use scheme CS1, CS2, CS3, or CS4. This allows the coding scheme to
be dynamically adapted to the channel conditions and thereby maximizing throughput and
optimizing the performance.
USF is the Uplink State Flag, which is transmitted on the downlink and is an invitation to an MS
to transmit. The BCS is Block Check Sequence, which is used for the detection of errors and
subsequent Automatic Repeat Request (ARQ).
Table 3-1 summarizes the coding parameters for the GPRS coding schemes.
Table 3-1 Coding parameters for GPRS coding schemes

Coding scheme
CS1
CS2
CS3
CS4
1/2
2/3
3/4
USF
Pre-coded USF
12
21
28
24
28
181
268
312
428
BCS
40
16
16
16
Tail
456
588
676
456
Punctured bits
132
220
User Data rate at RLC/MAC kbps
12
14.4
20
Effective Code rate after 1/2 convolutional coding and

puncturing
RLC/MAC header/bits
User bits (RLC blocks; segmented LLC PDUCs)
Coded bits
16/32 kbps TRAU

In the BSS architecture, the link, which the GPRS data traverses from the channel coders in
the BTS to the PCU, is currently implemented using 16 kbps TRAU-like links. These links are
carried over subrate switched E1 timeslots, which have some signaling included to ensure that
the link is synchronized between the channel coders and the PCU. However, Table 3-1 shows
that there is not enough bandwidth available on a 16 kbps link to carry CS3 and CS4, therefore
the 32 kbps TRAU is required.
The method used is to combine two component 16 kbps TRAU channels to create a 32 kbps
TRAU channel. The two 16 kbps channels are referred to as the left and right channels. The
left channel is the primary channel, which is currently used for all GPRS traffic. The right (or
auxiliary) channel is used for the larger CS3 and CS4 GPRS TRAU-like frames.
NOTE
Only one 16 kbps timeslot (CIC) is used between the BSC and RXCDR for a CS call,
therefore termination is necessary.
68P02900W21-T
3-17
Jul 2010
EGPRS channel coding schemes

Nine different coding schemes have been defined for EGPRS, MCS-1 to MCS-9. MCS-1 to
MCS-4 coding schemes use GMSK and MCS-5 to MCS-9 coding schemes use 8-PSK. The
mother code used is a 1/3 rate convolutional coder applied to all the coding schemes followed
by various puncturing schemes leading to various effective code rates. The following apply to
all nine coding schemes:
User data (RLC data block, segmented LLC PDUs), RLC/MAC header and the USF bits
are coded independently.
The USF bits (3) are block coded, resulting in 12 bits and 36 bits for GMSK and 8-PSK
coding schemes respectively. In case of MCS-1 to MCS-4, USF block coding is identical
to CS-4. This facilitates multiplexing of GPRS and EGPRS on the same timeslot (GPRS
mobiles must be able to detect USF sent by EGPRS GMSK block).
The mother code used is 1/3 rate convolutional encoder.
There are three different RLC/MAC header types used, which contain information about
the coding and puncturing scheme, used for a block. Header type 1 is used for MCS-7 to
MCS-9, header type 2 is used for MCS-5 and MCS-6, and header type 3 is used for MCS-1
to MCS-4.
Eight stealing bits (SBs) are used to signal which header type should be used to extract
various information.
Coding schemes MCS-7 to MCS-9 are interleaved over two bursts and coding schemes
MCS-1 to MCS-6 are interleaved over four bursts.
Two or three puncturing schemes per coding scheme are used enabling Incremental
Redundancy (IR); the code combining process of radio blocks in error thus providing
additional coding gain, particularly for higher code rates.
There are three code families, A, B, and C. The code families facilitate re-segmentation
of erroneous radio blocks into more robust coding schemes for re-transmission. Coding
schemes MCS-1 and 4 are in family C, MCS-2, 5, and 7 are in family B, and MCS-3, 6,
8, and 9 are in family A.
NOTE
Hybrid ARQ type I is not supported.
These are described in the following sections.
3-18
68P02900W21-T
Jul 2010
Channel coding scheme MCS-1

MCS1 is the most robust coding scheme of the four EGPRS GMSK modulated coding schemes.
Figure 3-9 shows the encoding of the user data (176 bits RLC data block, segmented LLC
PDUs), the RLC/MAC header (28 bits, header type 3) for downlink. Extra 12 bits (BCS) for error
detection (used in ARQ) protect the user data. The subsequent 196 bits (including tail bits, FBI
and E bits) are then convolutionally coded, punctured, and interleaved over four bursts. Extra
8 bits (HCS) for error detection protect the header data. The subsequent 36 bits are then
convolutionally coded, punctured, and interleaved over four bursts. MCS1 provides a user data
rate (excluding RLC/MAC header) of 8.8 kbits/s.
Figure 3-9 EGPRS channel coding scheme 1 (MCS-1)

196 bits
3 bits
USF
8 bits 2 bits
28 bits
176 bits
12 bits 6 bits
BCS TB
RLC/MAC Header HCS FBI E Data
Block
coded
12 bits
108 bits
588 bits
Puncturing
SB = 12
12 bits
68 bits
Burst 1
TB
3 bits
P1
P2
372 bits
372 bits
Burst 2
Header & data

57 bits
SB
1 bit
Burst 3
TS
26 bits
SB
1 bit
Burst 4
Header & data

57 bits
TB
3 bits
ti-GSM-EGPRS_channel_coding_scheme_1-00176-ai-sw
68P02900W21-T
3-19
Jul 2010

MCS-2 coding scheme is less robust than MCS-1. Figure 3-10 shows the encoding of the user
data (224 bits), the RLC/MAC header (28 bits, header type 3) for downlink. Extra 12 bits (BCS)
for error detection (used in ARQ) protect the user data. The subsequent 244 bits (including
tail bits, FBI and E bits) are then convolutionally coded, punctured, and interleaved over four
bursts. Extra 8 bits (HCS) for error detection protect the header data. The subsequent 36 bits
are then convolutionally coded, punctured, and interleaved over four bursts. MCS2 provides a

244 bits
3 bits
USF
8 bits 2 bits
28 bits
224 bits
12 bits 6 bits
BCS TB
Block
coded
12 bits
108 bits
672 bits
Puncturing
SB = 12
12 bits
68 bits
Burst 1
TB
3 bits
P1
P2
372 bits
372 bits
Burst 2
Header & data

57 bits
SB
1 bit
Burst 3
TS
26 bits
SB
1 bit
Burst 4
Header & data

57 bits
TB
3 bits
3-20
68P02900W21-T
Jul 2010

MCS-3 coding scheme is less robust than MCS-1 and MCS-2. Figure 3-11 shows the encoding of
the user data (296 bits), the RLC/MAC header (28 bits, header type 3) for downlink. Extra 12
bits (BCS) for error detection (used in ARQ) protect the user data. The subsequent 316 bits
(including tail bits, FBI and E bits) are then convolutionally coded, punctured, and interleaved
over four bursts. Extra 8 bits (HCS) for error detection protect the header data. The subsequent
36 bits are then convolutionally coded, punctured, and interleaved over four bursts. MCS-3
provides a user data rate (excluding RLC/MAC header) of 14.8 kbits/s.

244 bits
3 bits
USF
8 bits 2 bits
28 bits
12 bits
108 bits
672 bits
Puncturing
Puncturing
P1
12 bits
68 bits
Burst 1
TB
3 bits
12 bits 6 bits
BCS TB
Block
coded
SB = 12
224 bits
P2
372 bits
372 bits
Burst 2
Header & data

57 bits
SB
1 bit
Burst 3
TS
26 bits
SB
1 bit
P3
372 bits
Burst 4
Header & data

57 bits
TB
3 bits
68P02900W21-T
3-21
Jul 2010

MCS-4 coding scheme is the least robust GMSK modulated coding scheme; it has no FEC
capability. Figure 3-12 shows the encoding of the user data (352 bits), the RLC/MAC header
(28 bits, header type 3) for downlink. Extra 12 bits (BCS) for error detection (used in ARQ)
protect the user data. The subsequent 372 bits (including tail bits, FBI and E bits) are then
convolutionally coded, punctured, and interleaved over four bursts. Extra 8 bits (HCS) for error
detection protect the header data. The subsequent 36 bits are then convolutionally coded,
punctured, and interleaved over four bursts. MCS-4 provides a user data rate (excluding
RLC/MAC header) of 17.6 kbits/s.

372 bits
3 bits
USF
8 bits 2 bits
28 bits
352 bits
BCS TB
Block
coded
12 bits 6 bits
12 bits
108 bits
1116 bits
Puncturing
Puncturing
P1
SB = 12
12 bits
68 bits
Burst 1
TB
3 bits
P2
372 bits
372 bits
Burst 2
Header & data

57 bits
SB
1 bit
Burst 3
TS
26 bits
SB
1 bit
P3
372 bits
Burst 4
Header & data

57 bits
TB
3 bits
3-22
68P02900W21-T
Jul 2010

MCS-5 is the most robust coding scheme of the five EGPRS 8-PSK modulated coding schemes.
Figure 3-13 shows the encoding of the user data (448 bits), the RLC/MAC header (25 bits, header
type 2) for downlink. Extra 12 bits (BCS) for error detection (used in ARQ) protect the user data.
The subsequent 468 bits (including tail bits, FBI, and E bits) are then convolutionally coded,
punctured, and interleaved over four bursts. Extra 8 bits (HCS) for error detection protect the
header data. The subsequent 33 bits are then convolutionally coded, punctured, and interleaved
over four bursts. MCS-5 provides a user data rate (excluding RLC/MAC header) of 22.4 kbits/s.

468 bits
3 bits
USF
25 bits
8 bits 2 bits
BCS TB
99+1 spare bits
1404 bits
No
puncturing
Puncturing
P2
P1
36 bits
SB = 8
Burst 1
TB
9 bits
68P02900W21-T
12 bits 6 bits
Block
coded
36 bits
448 bits
1248 bits
100 bits
Burst 2
Data
156 bits
U SB
12 5 1 bit
bits bits
Burst 3
TS
78 bits
SB U H
1 4 13
bit bits bits
1248 bits
Burst 4
Data
57 bits
TB
9 bits
3-23
Jul 2010

MCS-6 coding scheme is less robust than MCS-5. Figure 3-14 shows the encoding of the user
data (592 bits), the RLC/MAC header (25 bits, header type 2) for downlink. Extra 12 bits (BCS)
for error detection (used in ARQ) protect the user data. The subsequent 612 bits (including
tail bits, FBI, and E bits) are then convolutionally coded, punctured, and interleaved over four
bursts. Extra 8 bits (HCS) for error detection protect the header data. The subsequent 33 bits
are then convolutionally coded, punctured, and interleaved over four bursts. MCS-6 provides a

612 bits
3 bits
USF
25 bits
8 bits 2 bits
99+1 spare bits
1836 bits
Puncturing
P2
P1
36 bits
Burst 1
TB
9 bits
BCS TB
No
puncturing
SB = 8
12 bits 6 bits
Data
RLC/MAC Header HCS FBI E
Block
coded
36 bits
592 bits
1248 bits
100 bits
Burst 2
Data
156 bits
U SB
12 5 1 bit
bits bits
Burst 3
TS
78 bits
SB U H
1 4 13
bit bits bits
1248 bits
Burst 4
Data
57 bits
TB
9 bits
3-24
68P02900W21-T
Jul 2010

MCS-7 coding scheme is less robust than MCS-5 and MCS-6. It also carries two radio blocks per
20 ms. Figure 3-15 shows the encoding of the user data, which consists of two separate user
data blocks, 448 bits each, the RLC/MAC header (37 bits, header type 1) for downlink. Extra
12 bits (BCS) for error detection (used in ARQ) protect each user data block. The subsequent
468 bits per radio block (including tail bits, FBI, and E bits) are then convolutionally coded,
punctured, and interleaved over two bursts. Extra 8 bits (HCS) for error detection protect the

468 bits
3
bits
USF
37
bits
8
bits
2
bits
RLC/MAC HCS FBI E

Header
Block
coded
36 bits
135 bits
Burst 1
TB
9
bits
153 bits
Data
BCS TB FBI E Data
448
bits
12 6
bits bits
BCS TB
1404 bits
Puncturing
P3
612 bits 612 bits
124 bits
Puncturing
P2
Burst 2
Data
2
bits
1404 bits
P1
36 bits
12 6
bits bits
Puncturing
SB = 8
448
bits
P1
P2
612 bits 612 bits
Burst 3
P3
612 bits 612 bits
Burst 4
U SB
TS
SB U
15
bits
5 1
bits bit
78
bits
1 4 16
bit bits bits
Data
TB
153 bits
9
bits
68P02900W21-T
3-25
Jul 2010

MCS-8 coding scheme carries two user data blocks like MCS-7. Figure 3-16 shows the encoding
of the two user data blocks, 544 bits each, the RLC/MAC header (37 bits, header type 1)
for downlink. Extra 12 bits (BCS) for error detection (used in ARQ) protect each user data
block. The subsequent 564 bits per radio block (including tail bits, FBI and E bits) are then
convolutionally coded, punctured, and interleaved over two bursts. Extra 8 bits (HCS) for error
detection protect the header data. The subsequent 45 bits are then convolutionally coded,
punctured, and interleaved over four bursts. MCS-8 provides a user data rate (excluding
RLC/MAC header) of 54.4 kbits/s.

564 bits
3
bits
USF
37
bits
8
bits
2
bits
RLC/MAC HCS FBI E

Header
Block
coded
36 bits
135 bits
Burst 1
TB
9
bits
153 bits
Data
BCS TB FBI E Data
544
bits
12 6
bits bits
BCS TB
1692 bits
Puncturing
P3
612 bits 612 bits
124 bits
Puncturing
P2
Burst 2
Data
2
bits
1692 bits
P1
36 bits
12 6
bits bits
Puncturing
SB = 8
544
bits
P1
P2
612 bits 612 bits
Burst 3
P3
612 bits 612 bits
Burst 4
U SB
TS
SB U
15
bits
5 1
bits bit
78
bits
1 4 16
bit bits bits
Data
TB
153 bits
9
bits
3-26
68P02900W21-T
Jul 2010

MCS-9 coding scheme carries two user data blocks like MCS-7 and 8. Figure 3-17 shows the
encoding of the MCS-9 two user data blocks, 592 bits each, the RLC/MAC header (37 bits,
header type 1) for downlink. Extra 12 bits (BCS) for error detection (used in ARQ) protect each
user data block. The subsequent 612 bits per radio block (including tail bits, FBI and E bits) are
then convolutionally coded, punctured, and interleaved over two bursts. The puncturing results
in MCS-9 with having no FEC protection. Extra 8 bits (HCS) for error detection protect the

612 bits
3
bits
USF
37
bits
8
bits
2
bits
RLC/MAC HCS FBI E

Header
Block
coded
36 bits
135 bits
Burst 1
TB
9
bits
153 bits
Data
BCS TB FBI E Data
592
bits
12 6
bits bits
BCS TB
1836 bits
Puncturing
P3
612 bits 612 bits
124 bits
Puncturing
P2
Burst 2
Data
2
bits
1836 bits
P1
36 bits
12 6
bits bits
Puncturing
SB = 8
592
bits
P1
P2
612 bits 612 bits
Burst 3
P3
612 bits 612 bits
Burst 4
U SB
TS
SB U
15
bits
5 1
bits bit
78
bits
1 4 16
bit bits bits
Data
TB
153 bits
9
bits
EGPRS traffic channels use coding schemes MCS-1 to MCS-9. This allows the coding scheme
to be dynamically adapted to the channel conditions like GPRS through the (LA) process (see
Link adaptation (LA) in GPRS/EGPRS on page 3-29 ) and thereby maximizing throughput and
68P02900W21-T
3-27
Jul 2010
64 kbps TRAU for EGPRS
optimizing the performance. The IR feature of EGPRS also allows the LA process to be more
aggressive in terms of BLER on the first transmissions and thereby increasing the utilization of
higher code rates over a larger percentage of a cell.
Table 3-2 summarizes the coding parameters for the EGPRS coding schemes.
Table 3-2 Coding parameters for EGPRS coding schemes

Coding scheme: MCS-n
9
Effective Code
rate after 1/2
convolutional coding
and puncturing
1.0
0.92
0.76
0.49
0.37
1.0
0.85
0.66
0.53
Effective Header
Code rate after 1/2
convolutional coding
and puncturing
0.36
0.36
0.36
1/3
1/3
0.53
0.53
0.53
0.53
8-PSK
Modulation
RLC blocks per Radio
Block (20 ms)
Raw Data within one
Radio Block
Family
2x592 2x544 2x448

A
BCS
Tail payload
GMSK
1
592
448
352
296
224
176
14.8
11.2
8.8
2x12
12
2x6
HCS
User Data rate at
RLC/MAC kb/s
8
59.2
54.4
44.8
29.6
22.4
17.6
64 kbps TRAU for EGPRS

In the BSS architecture, the link, which the EGPRS data traverses from the channel coders in
the BTS to the PCU, is currently implemented using 16 kbps TRAU-like links. These links are
carried over subrate switched E1 timeslots, which have some signaling included to ensure the
link is synchronized between the channel coders and the PCU. In case of GPRS, 32 kbits/s TRAU
is used to carry CS3 and CS4. In case of EGPRS, Table 3-2 shows that there is not enough
bandwidth available on a 32 kbps link to carry MCS- 7 to 9, therefore VersaTRAU frame formats
are used to statistically multiplex the data for each air timeslot configured as a PDTCH on the
RTF backhaul available for use as Versachannel.
For EGPRS, any enabled carrier has a certain amount (ranging from 3 to 8 DS0s) of terrestrial
backhaul configured and a portion of this backhaul is used as the Versachannel to carry the data
for the air timeslots configured as PDTCHs. The EGPRS feature needs additional backhaul to
provision EGPRS carriers. The additional backhaul is either 7 DS0s to implement EGPRS on a
BCCH carrier or 8 DS0s to implement EGPRS on a non-BCCH carrier, if VersaTRAU feature
is restricted. If VersaTRAU feature is unrestricted, the backhaul for an EGPRS carrier can be
configured using the rtf_ds0_count parameter.
3-28
68P02900W21-T
Jul 2010
Link adaptation (LA) in GPRS/EGPRS
Link adaptation (LA) in GPRS/EGPRS

The Link Adaptation (LA) process is used to improve the throughput of users and system by
adapting the highest coding scheme to the prevailing radio channel condition. The development
of LA algorithm is generally based on maximizing user or system throughput, under the
constraint of keeping the operating BLER of the system within an acceptable bound. This
ensures that the overall throughput performance is not degraded due to the operation of higher
layers protocols.
The implementation of LA is manufacturer dependant and is also mandatory. The standards
provide sufficient information and guidelines to facilitate the development of proprietary
algorithms. This is achieved through specific information elements in the various header and
control messages communicated between the BTS and MS. In addition, there are various
measurement reports produced by the MS that can be used as inputs to the LA process. The
actual implementation is generally based on guidelines provided by the standards and the
boundaries specified in the standards.
The LA impact in improving the system performance is greater in EGPRS compared to GPRS
due to:
Higher number of codes, that is, better granularity.
Richer MS measurement reports.
Incremental redundancy (Hybrid ARQ type II).
The LA process uses the measurement reports as inputs to move between various codes per
packet downlink Ack/Nack period. In Motorolas implementation, a code change is applied to
all the blocks and timeslots. In addition, IR is the only mode used in EGPRS, and appropriate
measures are taken to comply with the constraints specified in the standards.
68P02900W21-T
3-29
Jul 2010
Subscriber environment
Subscriber environment
Subscriber hardware
Perceived system quality (for example, voice quality), system access, and grade of service are
the most significant factors in the success of a cellular network. The everyday subscriber
neither knows nor really cares about the high level of technology incorporated into a cellular
network. However, they do care about the quality of their calls.
What the network designer must remember is that it is the subscriber who selects the type of
equipment they wish to use on the network. It is up to the network provider to satisfy the
subscriber, whatever they choose. The output power of the mobile subscriber is limited in a
GSM system to a maximum of 8 W for a mobile and a minimum of 0.8 W for a hand portable. For
a DCS1800 system, the mobile subscriber is restricted to a maximum of 1 W and a minimum
of 250 mW hand portable.
Environment
Not only does the network designer have to plan for the choice of phone of subscribers, the
designer has to plan for the choice of subscribers as to where they wish to use that phone.
When only the mobile unit was available, system coverage and hence subscriber use was limited
to on street, high density urban or low capacity rural coverage areas. During the early stages
of cellular system implementation, the major concern was trying to provide system coverage
inside tunnels.
However, with the advances in technology the hand portable subscriber unit is now firmly
established. With this introduction came new problems for the network designer. The portable
subscriber unit provides the user far more freedom of use but the subscriber still expected the
same service. The subscriber now wants quality service from the system at any location. This
location can be on a street or any floor of a building whether it is the basement or the penthouse
and even in lifts (see Figure 3-18). Thus, greater freedom of use for the subscriber gives the
network designer even greater problems when designing and implementing a cellular system.
3-30
68P02900W21-T
Jul 2010
Distribution
Figure 3-18 Subscriber environment

URBAN/CITY
ENVIRONMENTS
RURAL AREAS
BUILDINGS
LIFTS
TUNNELS
ti-GSM-Subscriber_environment-00188-ai-sw
Distribution
Not only do network designers have to identify the types of subscriber that use the cellular
network now and in the future, but also at what location these subscribers are attempting
to use their phones.
Dense urban environments need an entirely different design approach, due to considerations
mentioned earlier in this chapter, than the approach used to design coverage for a sparsely
populated rural environment. Road and rail networks have subscribers moving at high speed,
so this must be accounted for when planning the interaction between network entities while
the subscriber is using the network. Even in urban areas, the network designer must be aware
that traffic is not necessarily evenly distributed. As Figure 3-19 illustrates, an urban area can
contain sub-areas of uneven distribution such as a business or industrial district, and has to plan
for a seasonal increase of traffic due to, for example, a convention center. It is vitally important
that the traffic distribution is known and understood before network design, to ensure that a
successful quality network is implemented.
68P02900W21-T
3-31
Jul 2010
Hand portable subscribers
Figure 3-19 Subscriber distribution

HIGH SPEED MOBILES
(RAILWAYS)
RURAL
URBAN
BUSINESS AREAS
40%
ROAD/RAIL
NETWORK
INDUSTRIAL
20%
EXHIBITIONS
10%
RESIDENTIAL
30%
SUBSCRIBERS DISTRIBUTION CHANGES ON A HOURLY BASIS

ti-GSM-Subscriber_distribution-00190-ai-sw
Hand portable subscribers

The network designer must ensure that the network is designed to ensure a quality service for
the most demanding subscriber. This is the hand portable subscriber. The hand portable now
represents the vast majority of all new subscriber units introduced into cellular networks. So
clearly the network users, and hence the network designers, must recognize this.
Before commencing the network design based around hand portable coverage, the network
designer must first understand the limitations of the hand portable unit and second, what the
hand portable actually needs from the network.
The hand portable phone is a small lightweight unit, which is easy to carry and has the ability
to be used from any location. The ability of the unit to be used at any location means that the
network must be designed with the provision of good in-building coverage as an essential
element.
The hand portable units have a low output power. For example:
0.8 W to 8 W (GMSK) and 0.2 W to 2 W (8-PSK) for GSM900.
0.25 W to 1 W (GMSK) and 0.107 W to 1 W (8-PSK) for DCS1800.
Therefore, the distance at which these units can be used from a cell is constrained by RF
propagation limitations.
For practical purposes, the actual transmit power of the hand portable should be kept as low as
possible during operation. This helps from not only an interference point of view, but also helps
to extend the available talk time of the subscriber unit, which is limited by battery life.
3-32
68P02900W21-T
Jul 2010
Future planning
Future planning
Normal practice in network planning is to select one point of a well-known re-use model as a
starting point. Even at this early stage, the model must be improved because any true traffic
density does not follow the homogeneous pattern assumed in any theoretical models.
Small-sized heavy traffic concentrations are characteristic of the real traffic distributions.
Another well-known traffic characteristic feature is the fast descent in the density of traffic
when leaving city areas. It is uneconomical to build the whole network using a standard cell
size; it becomes necessary to use cells of varying sizes.
Connecting areas with different cell sizes bring about new problems. In principle, it is possible
to use cells of different size side-by-side, but without careful consideration, this leads to a
wasteful frequency plan. This is because the re-use distance of larger cells is greater than that
of smaller cells. The situation is often that the borders are so close to the high-density areas
that the longer re-use distances mean decreased capacity. Another solution, offering better
frequency efficiency, is to enlarge the cell size gradually from small cells into larger cells.
In most cases, the traffic concentrations are so close to each other that the expansion cannot be
completed before it is time to start approaching the next concentration, by gradually decreasing
the cell size. This is why the practical network is not a regular cluster composition, but a group
of directional cells of varying size. Besides this need for cells of different size, the unevenness
of the traffic distribution also causes problems in frequency planning. Theoretical frequency
division methods applicable to homogenous clusters cannot be used. It is rare that two or more
neighboring cells need the same quantity of channels. It must always be kept in mind that the
values calculated for future traffic distribution are only crude estimates and that the real traffic
distribution always deviates from these estimates. In consequence, the network plan should be
flexible enough to allow for rearrangement of the network to meet the real traffic needs.
Conclusion
In conclusion, there are no fixed rules for radio network planning. It is a case of experimenting
and reiterating. By comparing different alternatives, the network designers should find a plan
that both fulfills the given requirements and keeps within practical limitations. When making
network plans, the designers should always remember that every location in a network has its
own conditions, and all local problems must be tackled and solved on an individual basis.
68P02900W21-T
3-33
Jul 2010
Microcellular solution
Microcellular solution
Layered architecture
The basic term layered architecture is used in the microcellular context to explain how
macrocells overlay microcells. It is worth noting that when talking of the traffic capacity of a
microcell it is additional capacity to that of the macrocell in the areas of microcellular coverage.
The traditional cell architecture design, Figure 3-20, ensures that, as far as possible, the cell
gives almost total coverage for all the MSs within its area.
Figure 3-20 Layered architecture
MACROCELL
MICROCELL A
MICROCELL B
TOP VIEW
SIDE VIEW
MACROCELL
MICROCELL A
MICROCELL B
ti-GSM-Layered_architecture-00191-ai-sw
3-34
68P02900W21-T
Jul 2010
Combined cell architecture
Combined cell architecture

A combined cell architecture system, as illustrated in Figure 3-21, is a multi-layer system of
macrocells and microcells. The simplest implementation contains two layers. The bulk of the
capacity in a combined cell architecture is provided by the microcells. Combined cell systems
can be implemented into other vendor networks.
Figure 3-21 Combined cell architecture

UNDERLAYED
MICROCELL (COULD BE A
DIFFERENT VENDOR)
OVERLAYED MACROCELLS
CONTIGUOUS COVERAGE OVER AREAS OF

HIGH SLOW MOVING TRAFFIC DENSITY
ti-GSM-Combined_cell_architecture-00192-ai-sw
Macrocells: Implemented specifically to cater to the fast-moving MSs and to provide a fallback
service for coverage of holes and pockets of interference in the microcell layer. Macrocells
form an umbrella over the smaller microcells.
Microcells: Microcells handle the traffic from slow-moving MSs. The microcells can give
contiguous coverage over the required areas of heavy subscriber traffic.
Combined cell architecture structure

A combined cell architecture employs cells of different sizes overlaid to provide contiguous
coverage. This structure is shown in Figure 3-22.
68P02900W21-T
3-35
Jul 2010
Expansion solution
Figure 3-22 Combined cell architecture structure

LINK TO IMPLEMENT MICROCELLS AS A SEPARATE SYSTEM
ALTERNATIVE SYSTEM (MICROCELLS CONTROLLED BY THE SAME BSC AS MACROCELLS)
MSC
BSC A
SYSTEM 2
MICROCELL
BSC B
SYSTEM 1
MACROCELL
BTS 1
BTS 5
BTS 2
BTS 3
BTS 4
MICROCELL
COVERAGE
MACROCELL COVERAGE
SYSTEM 1 = OVERLAY SYSTEM

SYSTEM 2 = UNDERLAY SYSTEM
ti-GSM-Combined_cell_architecture_structure-00193-ai-sw
NOTE
Macrocell and microcell networks are operated as individual systems.
The macrocell network is more dominant as it handles the greater amount of

traffic.
Microcells can be underlaid into existing networks.
Expansion solution
As the GSM network evolves and matures, its traffic loading increases as the number of
subscribers grow. Eventually a network reaches a point of traffic saturation. The use of
microcells can provide high traffic capacity in localized areas.
3-36
68P02900W21-T
Jul 2010
Expansion solution
The expansion of a BTS site past its original designed capacity can be a costly exercise and
the frequency re-use implications require to be planned carefully (co-channel and adjacent
channel interference). The use of microcells can alleviate the increase in congestion; the
microcells could be stand-alone cells to cover traffic hotspots or a contiguous cover of cells in
a combined architecture.
68P02900W21-T
3-37
Jul 2010
Frequency planning
Frequency planning
Introduction
The ultimate goal of frequency planning in a GSM network is attaining and maintaining the
highest possible C/I ratio everywhere within the network coverage area. A general requirement
is at least 12 dB C/I, allowing tolerance in signal fading the 9 dB specification of GSM.
The actual plan of a real network is a function of its operating environment (geography, RF, and
so on) and there is no universal textbook plan that suits every network. Nevertheless, some
practical guidelines gathered from experience can help to reduce the planning cycle time.
{34371G} There is an RF bandwidth constraint of 20 MHz contiguous coverage in both the 900
MHz and 1800 MHz band per (R)CTU8m. The starting frequency point of the (R)CTU8m working
bandwidth is specified by the CTU8m parameter lowest_arfcn. The (R)CTU8m works from the
lowest_arfcn to the lowest_arfcn +20 MHz within the band boundary. The modification of the
(R)CTU8m working bandwidth impacts other carriers and service of the (R)CTU8m.
Rules for Synthesizer Frequency Hopping (SFH)

As the BCCH carrier is not hopping, it is strongly recommended to separate bands for BCCH
and TCH, as shown in Figure 3-23.
Figure 3-23 Separating BCCH and TCH bands

m channels
n channels
TCH
BCCH
Guard Band
ti-GSM-Separating_BCCH_and_TCH_bands-00194-ai-sw
The benefits are as follows:
Makes planning simpler.
Better control of interference.
If microcells are included in the frequency plan, the band usage shown in Figure 3-24 is
suggested.
3-38
68P02900W21-T
Jul 2010
Figure 3-24
Band usage for macrocells with microcells
Macro BCCH
Micro
Macro TCH
Micro TCH
BCCH
(SFH)
ti-GSM-Band_usage_for_macrocells_with_microcells-00195-ai-sw
{34371G} There is an RF bandwidth constraint of 20 MHz contiguous coverage in either the

900 MHz or 1800 MHz band per (R)CTU8m. The serving RF bandwidth during Synthesizer
hopping for each (R)CTU8m cannot exceed the 20 MHz contiguous bandwidth.
Practical rules for TCH 1x3 re-use pattern
BCCH re-use plan: 4x3 or 5x3, depending on the bandwidth available and operating
environment.
Divide the dedicated band for TCH into 3 groups with an equal number of frequencies (N).
These frequencies are the ARFCN equipped in the MA list of a hopping system (FHI).
Use an equal number of frequencies in all cells within the hopping area. The allocation
of frequencies to each sector is recommended to be in a regular or continuous sequence
(see planning example).
The number of frequencies (N) in each group is determined by the design loading factor (or
carrier-to-frequency ratio). A theoretical maximum of 50% is permitted in 1x3 SFH. Any
value higher than 50% would practically result in unacceptable quality. Some commonly
used loading factors (sometimes termed as fractional load factors) are 40%, 33%, 25%,
and so on.
As a general guideline,
N=
(highest non BCCH transceiver count in a cell )

(loading f actor)
No more than 48 frequencies in a cell with multiple carriers with GPRS/EGPRS timeslots.
Use the same HSN for sectors within the same site. Use different HSNs for different sites.
This helps to randomize the co-channel interference level between the sites.
Use different MAIOs to control adjacent channel interference between the sectors within a
site.
68P02900W21-T
3-39
Jul 2010
NOTE
Mobile Allocation (MA) is the set of frequencies that the mobile or BTS
is allowed to hop over. Two timeslots on the same transceiver of a cell are
configured to operate on different MAs. MA is the subset of the total allocated
spectrum for the GSM user and the maximum number of frequencies in a MA list
is limited to 64 by GSM recommendations.
Mobile Allocation Index Offset (MAIO) is an integer offset that determines

which frequency within the MA is the operating frequency. If there are N
frequencies in the MA list, then MAIO = {0, 1, 2, N-1}.
Hopping Sequence Number (HSN) is an integer parameter that determines

how the frequencies within the MA list are arranged. There are 64 HSNs defined
by GSM. HSN = 0 sets a cyclical hopping sequence where the frequencies within
the MA list are repeated in a cyclical manner.
HSN = 1 to 63 provides a pseudo random hopping sequence. The pseudo random
pattern repeats itself after every hyperframe, which is equal to 2,715,648 (26 x
51 x 2048) TDMA frames, or about 3 hours 28 minutes and 54 seconds.
Motorola defines a Frequency Hopping Indicator (FHI) that is made up of

the three GSM defined parameters. Up to 4 different FHIs can be defined for a
cell in a Motorola BSS and every timeslot on a transceiver can be independently
assigned one of the defined FHI. MAI is an integer that points to the frequency
within a MA list, where MAI = 0 and MAI = N-1 being the lowest and highest
frequencies in the MA list of N frequencies. MAI is a function of the TDMA
frame number (FN), HSN and MAIO of a frequency hopping system.
TCH re-use planning example
Bandwidth: 10 MHz
Site configuration: Mix of 2-2-2, 3-3-3, and 4-4-4
Loading factor: 33%
Environment: Multi layer (micro and macro co-exist)
The spectrum is split as shown in Figure 3-25.
Figure 3-25
Frequency split for TCH re-use planning example

8 channels
Macro BCCH
Micro
Macro TCH
Micro TCH
BCCH
(SFH)
12 channels
27 channels
ti-GSM-Frequency_split_for_TCH_re-use_planning_example-00196-ai-sw
3-40
68P02900W21-T
Jul 2010
A total of 49 channels are available and the first and last one are reserved as guard bands. Thus,
there are 47 usable channels. 12 channels are used in the BCCH layer with a 4x3 re-use pattern.
Based on 33% loading and a 4-4-4 configuration, N is calculated as N = 3 / 0.33 = 9 hopping
frequencies per cell. Thus, a total of 27 channels are required for the hopping TCH layer. The
remaining 8 channels are used in the micro layer as BCCH.
One of the possible frequency and parameter setting plans are outlined in Table 3-3.
Table 3-3 Frequency and parameter setting plan

ARFCN
HSN
MAIO
Sector A
21, 24, 27, 30, 33, 36, 39, 42, 45
Any from {1, 2, 63}
0, 2, 4
Sector B
22, 25, 28, 31, 34, 37, 40, 43, 46
Same as
1, 3, 5
Sector C
23, 26, 29, 32, 35, 38, 41, 44, 47
Same as
0, 2, 4
The MAIO setting avoids all possible adjacent channel interference among sectors within the
same site. The interference (co or adjacent channel) between sites still exists but it is reduced
by the randomization effect of the different HSNs.
Practical rules for TCH 1x1 re-use pattern
1x1 is practical in rural area of low traffic density, where the average occupancy of the
hopping frequencies is low. With careful planning, it can be used in high traffic areas as
well.
BCCH re-use plan: 4X3 or 5X3, depending on the bandwidth available and operating
environment.
The allocation of TCH frequencies to each sector is recommended to be in a regular or

continuous sequence.
Use different HSNs to reduce interference (co and adjacent channel) between the sites.
Use the same HSNs for all carriers within a site and use MAIOs to avoid adjacent and
co-channel interference between the carriers. Repeated or adjacent MAIOs are not to
be used within the same site to avoid co-channel and adjacent channel interference
respectively.
A maximum loading factor of 1/6 or 16.7% is inherent in a continuous sequence of

frequency allocation. Since adjacent MAIOs are restricted, the maximum number of
MAIOs permitted is:
M ax M AIOs =
1
(T otal allocated channels)
2
In a 3-cell site configuration, the logical maximum loading factor is 1/6 or 16.7%.
Figure 3-26 illustrates how co-channel and adjacent channel interference can be avoided.
68P02900W21-T
3-41
Jul 2010
Rules for BaseBand Hopping (BBH)
Figure 3-26 Avoiding co-channel and adjacent channel interference

1
Different MAIOs to
avoid co-channel
interference
13
HSN = 1
15
11
HSN = 1
17
HSN = 1
Non adjacent MAIOs to

avoid adjacent channel
interference
ti-GSM-Avoiding_co-channel_and_adjacent_channel_interference-00197-ai-sw

All the rules outlined for SFH are generally applicable to BBH. As the BCCH is in the hopping
frequency list, a dedicated band separated from TCH is not essential.
An example of frequency spectrum allocation is shown in Figure 3-27.
Figure 3-27
BBH frequency spectrum allocation

Micro BCCH
BBH channels and micro TCH

ti-GSM-BBH_frequency_spectrum_allocation-00198-ai-sw
If the ITS feature is unrestricted and enabled, the baseband hopping characteristic is restricted
on the DD CTU2 DRIs of which Carrier A is EGPRS capable. These DRIs do not join the BBH
even if in the database their corresponding ARFCNs are configured in the MA list.
3-42
68P02900W21-T
Jul 2010
For effective utilization of the ITS feature and to maintain stability, it is recommended to use the
parameter re_rtf_id to map the DD CTU2 Carrier A to 64 k RTF and exclude these ARFCNs
from the MA list if BBH must be applied for the cell.
CTU2D defines a new site-level parameter of asym_edge_enabled for the CTU2D asymmetric
feature. The element enables or disables support of asymmetric EGPRS for CTU2D on per SITE
basis. The use of this functionality needs that the system remaps its internal TDM allocations
resulting in the removal of BBH support for EDGE (in any mode) for the entire Site. As this
only impacts Baseband hopping and does not need wholesale configuration changes, the system
simply does not configure hopping systems for SD EDGE and DD EDGE.
When CTU2D is configured in CAPacity mode, BTS supports the GMSK Baseband Hopping of the
carrier B, that is, for BBH the system supports hopping for GMSK carriers assigned to Carrier B
irrespective of the EDGE capabilities and PD support for Carrier A.
For a cell with extended PDCH, baseband hopping is disabled.
{34416} If power-saving radios are mixed with non-power-saving radios in the same BBH
hopping group, using the PA bias feature in Horizon II sites with mixed radios will not deliver
the expected power savings.
{34371G} The non-CTU8m and (R)CTU8m radios cannot be mixed in the same BBH hopping
group. The non-(R)CTU8m (for example, CTU/CTU2/CTU2D, and so on) radios may reside in the
same cell as CTU8m / RCTU8m radios, but must use their own hopping group, that is, different
FHI groups for legacy and CTU8m/RCTU8m radios.
{34371G} There is an RF bandwidth constraint of 20 MHz contiguous coverage in either the
900 MHz or 1800 MHz band per (R)CTU8m. The serving RF bandwidth during the baseband
hopping for each (R)CTU8m cannot exceed 20 MHz contiguous bandwidth.
For example, there are two (R)CTU8m radios with 4 carriers each. The hopping group includes
f3, f4, f5, f6:
CTU8m #1
CTU8m #2
f1, f2, <f3, f4
f5, f6>, f7, f8
For CTU8m #1, the software ensures that (f1, f2, <f3, f4, f5, f6>) are within the 20 MHz
limitation. For CTU8m #2, the software ensures that (<f3, f4, f5, f6>, f7, f8) are within the
20 MHz limitation. Only if these two conditions are met the hopping group <f3, f4, f5, f6>
will be valid for the CTU8m radios.
In such a scenario, if (f1, f2, <f3, f4, f5, f6>) or (<f3, f4, f5, f6>, f7, f8) cannot be met, but both
the groups of hopping frequencies <f3, f4, f5, f6> and non-hopping frequencies (f1, f2, f7, f8)
are within the 20M Hz bandwidth, the operator can manually specify the RTF-DRI mapping (by
setting preferred RTF in DRI equipage) as given in the following table to enable hopping.
Table 3-4 RTF-DRI mapping
68P02900W21-T
CTU8m #1
CTU8m #2
<f3, f4, f5, f6>
f1, f2, f7, f8
3-43
Jul 2010
Inter-radio access technology (2G-3G) cell reselection and handovers
Inter-radio access technology (2G-3G) cell reselection

and handovers
Introduction
An optional feature is supported for handovers and cell reselection between different Radio
Access Technology (RAT) networks in the circuit and packet switched domain. The RAT can
be either GSM/GPRS/EDGE (2G/2.5G) or the Universal Mobile Telecommunication System
(UMTS) (3G).
UMTS is beyond the scope of this manual and only its handover interaction with GSM is
described here. For further information on UMTS, refer to System Information: UMTS
Equipment Planning, 68P02905W22.
2G-3G handover description

The 2G-3G handover feature supports handovers between different RAT networks. The RAT can
be either 2G/2.5G (GSM/GPRS/EDGE) or 3G (UMTS).
Current evolving 3G UMTS networks soon allow operators to provide UMTS coverage along
with GSM/GPRS/EGPRS coverage in their networks.
This feature enables a multi-RAT MS (a mobile station that can function in multiple Radio
Access Networks RANs) to either reselect or handover between a GSM RAN(GERAN) and a
UMTS Radio Access Network (UTRAN). To accomplish this, support is required from the MS,
core network elements (MSC) and GSM/UMTS network elements.
The GSM BSS support for this feature includes:
Cell reselection across UTRAN (UMTS FDD neighbors) and GERAN in idle mode.
Handovers between 3G (UMTS-FDD) and 2G (GSM) in active mode.
Restriction
There is currently an upper limit of 32 FDD UTRAN neighbors in the GSM/GPRS system.
Implementation
The BSS Inter-RAT handover GSM function is an option that must be unrestricted by Motorola.
It also needs unrestricting on site by the operator with the inter_rat_enabled parameter.
With the arrival of UMTS systems, there are likely to be small UMTS coverage areas within
larger GSM coverage areas. In such an environment the call would drop when a UMTS
subscriber goes out of a UMTS coverage area and into a GSM coverage area.
3-44
68P02900W21-T
Jul 2010
Impact of 2G-3G handovers on GSM system architecture
Congestion in the smaller UMTS areas could become a problem when the traffic in the UMTS
coverage area is high. A GSM subscriber may wish to access a service with specific QoS
characteristic (for example, high bit rate data service) that may not be supported in the GSM
system.
To avoid these problems the operator may wish to configure their network such that handover
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 and handover while between an UMTS FDD cell and a GSM cell.
Impact of 2G-3G handovers on GSM system architecture

Figure 3-28 shows the system architecture for the GSM BSS inter-RAT handover feature.
Figure 3-28 GSM and UMTS system nodes and interfaces

E-Interface
GSM Core Network
(MSC/GSN)
A-Interface
UMTS Core Network

(3G MSC/SGSN)
Gn-Interface
Gb-Interface
Iu-Cs-Interface
Iu-Ps--Interface
GSM/GPRS
PCU
BSS
UTRAN
RNS
RNC
BSC
Iub
Abis
BTS
BTS
Um
Node B
RNS
Iur
RNC
Iub
Node B
Uu
Multi-RAT MS
ti-GSM-GSM_and_UMTS_system_nodes_and_interfaces-00199-ai-sw
68P02900W21-T
3-45
Jul 2010
System consideration
System consideration
Existing 2G CoreNetwork (CN) nodes must be able to interact with the 3G CN nodes through
MAP procedures defined on the E-interface between a 2G CN node and 3G CN node.
The GSM BSS inter-RAT handover feature does not support:
3-46
Cell reselection to UTRAN TDD neighbor cells or CDMA2000 neighbor cells.
Extended measurement reporting.
Enhanced measurement reporting.
Blind handovers.
The sending of SI2quater on extended BCCH.
The BSS restricts the maximum number of UTRAN neighbors per GSM cell to 32.
68P02900W21-T
Jul 2010
TD-SCDMA and GSM interworking feature
TD-SCDMA and GSM interworking feature
Overview
This feature provides GSM/TD-SCDMA inter-working support. It is an optional feature and
supports the following functions:
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.
GSM/GPRS to TD-SCDMA cell re-selection in packet transfer mode.
MS reselect to GSM/GPRS from TD-SCDMA.
Supports TD-SCDMA to GSM handover in circuit-switched dedicated mode.
The user 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. This implies that the TD-SCDMA maximum neighbor cell number per TDD-ARFCN is 16.
Requirements
This feature is supported only in Mcell, Horizon, and Horizon II cabinets. It cannot be enabled
in an Incell cabinet.
Limitations
This feature can be enabled only if the Inter-RAT Handover and Enhanced 2G/3G Inter-RAT
handover features are restricted.
68P02900W21-T
3-47
Jul 2010
Call model parameters for capacity calculations
Call model parameters for capacity calculations
Introduction
This section provides information on how to determine the number of control channels required
at a BTS. This information is required for the sizing of the links to the BSC, and is required when
calculating the exact configuration of the BSC required to support a given BSS.
Typical call parameters

The number of control channels required at a BTS depends on a set of call parameters; typical
call parameters for BTS planning are given in Table 3-5.
Table 3-5 Typical parameters for BTS call planning

Busy hour peak signaling traffic model
Parameter reference
Call duration
T = 83.27 seconds
Ratio of SMSs per call
S = 3.2
H = 3.54
Ratio of location updates to calls: non-border

location area
l = 2.73
Ratio of location updates to calls: border

location area
l=7
Ratio of IMSI detaches to calls
I = 0.05
Location update factor: non-border location

area using IMSI type 2
L = l + 0.5I = 2.75
Location update factor: border location area

using IMSI type
2 L = l + 0.5I = 7.02
GSM circuit-switched paging rate in pages per

second
PGSM = 90.8
Ratio of intra-BSC handovers to all handovers
i = 0.82
Ratio of LCSs per call
Lcs = 0
Mobile terminated LCS ratio
LRMT = 0.95
Mobile originated LCS ratio
LRMO = 0.05
Percent link utilization (MSC to BSS) for

GPROC2/GPROC3 (64 k MTL)
U(MSC - BSS) = 0.20
Percent link utilization for HSP MTL
U(MSC - BSS) = 0.13
Percent link utilization (BSC to BTS)
U(BSC - BTS) = 0.25

Continued
3-48
68P02900W21-T
Jul 2010
Table 3-5 Typical parameters for BTS call planning (Continued)

Parameter reference
Percent link utilization (BSC to RXCDR)
UBSC-RXCDR = 0.40
Percent link utilization (BSC to SMLC)
UBSC-SMLC = 0.40
Percent link utilization (BSC to PCU)
UBSC-PCU = 0.25
Percent link utilization (BSS to SGSN)
UGBL = 0.40
Percent CCCH utilization
UCCCH = 0.33
Block Rate for TCHs
PB-TCHs = 1%
Block Rate for MSC-BSS trunks
PB-Trunks = 0%
Number of cells per BTS
CBTS = 3
Average SMS message size (payload only)
SMSSIZE = 100 bytes
Number of BSCs per location area
BSCLA = 1
Busy Hour Call Attempts per sub/BH
BHCAsub = 1.03
XBL (enhanced auto connect) parameters

Number of XBL messages per new call
MNEWCALL = 1
Number of XBL messages per hr <-> fr

handover
MHANDOVER = 1
Length of an average XBL message, in bytes
LXBL = 50
Number of hr <-> fr handovers per call
Hhr-fr = 1
GPRS parameters
GPRS Average packet size (bytes)
PKSIZE = 315.48
GPRS Traffic per subscriber /BH (kBytes/hr)

- Uplink
ULRATE = 1.48
GPRS Traffic per subscriber /BH (kBytes/hr) Downlink
DLRATE = 5.96
Average sessions per subscriber (per BH)
Avg_Sessions_per_sub = 0.026
PS attach/detach rate (per sub/BH)
PSATT/DETACH = 0.49
PDP context activation/deactivation (per

sub/BH)
PDPACT/DEACT = 0.63
Routing area update
RAU = 1.4
GPRS paging rate in pages per second
PGPRS = 2.02
Coding scheme rates (CS1 to CS4) at the

RLC/MAC layer
CS1
CS2
CS3
CS4
= 9.2 kbps
= 13.6 kbps
= 15.8 kbps
= 21.8 kbps
Continued
68P02900W21-T
3-49
Jul 2010

Parameter reference
Coding scheme usage (CS1 to CS4) at a BLER

of 5%
CS1_usage_UL = 11%
CS1_usage_DL = 8%
CS2_usage_UL = 35.5%
CS2_usage_DL = 35.5%
CS3_usage_UL = 8%
CS3_usage_DL = 21%
Percentage GPRS coding scheme usage in

total traffic
CSuse_UL_GPRS = 87.9%
CSuse_DL_GPRS = 90.1%
Cell updates (per sub/BH)
CellUpdate = 0.33
EGPRS parameters
EGPRS Average packet size (bytes) - Uplink
PKULSIZE = 130.75
EGPRS Average packet size (bytes) - Downlink
PKDLSIZE = 485.9
EGPRS Traffic per sub/BH (kBytes/hr) -Uplink
ULRATE = 1.48
EGPRS Traffic per sub/BH (kBytes/hr)

-Downlink
DLRATE = 5.96
EGPRS coding scheme rates (MCS-1 to

MCS-9) at the RLC/MAC layer
MCS1
MCS2
MCS3
MCS4
MCS5
MCS6
MCS7
MCS8
MCS9
Coding scheme usage (MCS1 to MCS9) at a

BLER of 12.02%
MCS1_usage_UL = 0.5%
MCS1_usage_DL = 11%
MCS2_usage_UL = 2%
MCS2_usage_DL = 12%
MCS3_usage_DL = 8.5%
MCS4_usage_DL = 7%
MCS5_usage_DL = 5%
MCS6_usage_DL = 19%
MCS7_usage_DL = 8%
MCS8_usage_DL = 8%
Percentage EGPRS coding scheme usage in

total traffic
CSuse_UL_EGPRS = 12.1%
CSuse_DL_EGPRS = 9.9%
= 10.55 kbps
= 12.95 kbps
= 16.55 kbps
= 19.35 kbps
= 23.90 kbps
= 29.60 kbps
= 31.10 kbps
= 46.90 kbps
= 61.30 kbps
Continued
3-50
68P02900W21-T
Jul 2010

Parameter reference
Average packet size for GPRS and EGPRS

traffic mix (bytes) Uplink
PKULSIZE = 130.75

traffic mix (bytes) Downlink
PKDLSIZE = 485.9
QoS parameters
Average GBR for service mix (kbps) - Uplink
GBRAVG_UL = 3.80
Average GBR for service mix (kbps) - Downlink
GBRAVG_DL = 5.59
Peak GBR for service mix (kbps) - Uplink
GBRPEAK_UL = 9.64
Peak GBR for service mix (kbps) - Downlink
GBRPEAK_DL = 12.69
NOTE
Number of handovers per call and Ratio of intra-BSC handovers to all handovers
include 2G-3G handovers.
The percentages represent the split of the traffic between the GPRS and EGPRS
traffic mix which is network-dependent. The percentages can be used to
determine the average traffic per sub/BH for a GPRS and EGPRS traffic mix as
follows:
Traffic per subscriber/BH for GPRS and EGPRS mix (kBytes/hr) =
(Percentage GPRS coding scheme usage in total traffic * GPRS Traffic
per sub/BH) + (Percentage EGPRS coding scheme usage in total traffic *
EGPRS Traffic per sub/BH).
The average packet sizes for a GPRS and EGPRS traffic mix are based on the
GPRS and EGPRS percentage splits defined for this model.
An MS in the extended range has a lower coding scheme than in the normal
range due to the longer distance between the MS and BTS. For the cell with
extended PDCH, the lower coding scheme has a higher usage percentage value
than the corresponding typical usage percentage value given in Table 3-5.
Location update factor (L)

The location update factor (L) is a function of the ratio of location updates to calls (I), the ratio
of IMSI detaches to calls (I) and whether the short message sequence (type 1) or long message
sequence (type 2) is used for IMSI detach; typically I = 0 (that is IMSI detach is disabled) as in
the first formula given . When IMSI detach is enabled, the second or third of the formulas given
should be used. The type of IMSI detach used is a function of the MSC.
If IMSI detach is disabled: L = I
If IMSI detach type 1 is enabled: L = I + 0.2 * I
If IMSI detach type 2 is enabled: L = I + 0.5 * I
68P02900W21-T
3-51
Jul 2010
Control channel calculations
Control channel calculations
Introduction
There are four types of air interface control channels, they are:
Broadcast Control CHannel (BCCH)
Common Control CHannel (CCCH)
Standalone Dedicated Control CHannel (SDCCH)
Cell Broadcast CHannel (CBCH), which uses one SDCCH
GPRS/EGPRS defines several new radio channels and packet data traffic channels.
Packet Common Control CHannels (PCCCHs)

The following channels are mapped onto PCCCH:
Packet Access Grant CHannel (PAGCH)

Downlink only, mapped on AGCH or PDTCH. Used to allocate one or several PDTCHs.
Packet Broadcast Control CHannel (PBCCH)

Downlink only, mapped on BCCH or PDTCH.
Packet Notification CHannel (PNCH)

Downlink only. Used to notify the MS of a PTM-M. This is not used in the first GPRS/EGPRS
release.
Packet Paging Channel (PPCH)

Downlink only, mapped on DTCH or CCCH. This is used to page the MS.
Packet Random Access CHannel (PRACH)

Uplink only. This is used to allow request allocation of one or several PDTCHs, in either
uplink or downlink directions.
Packet Data Traffic CHannel (PDTCH)

A PDTCH corresponds to the resource allocated to a single MS on one physical channel for
user data transmission.
3-52
68P02900W21-T
Jul 2010
Planning considerations
Packet Dedicated Control CHannels (PDCCHs)
Packet Associated Control CHannel (PACCH)

The PACCH is bi-directional. It is used for MS-PCU control signaling while the MS is
performing a packet transfer.
Packet Timing advance Control CHannel (PTCCH/U)

Uplink channel, used to transmit random access bursts. The transceiver uses these bursts
to estimate the timing advance for an MS when it is in transfer state.
Packet Timing advance Control CHannel (PTCCH/D)

Downlink channel, used to transmit timing advance updates to several MSs at the same
time.
In planning the GSM/GPRS/EGPRS control channel configuration, the network planner must
consider three main variables:
Signaling requirements of the CCCH
Signaling requirements of the PCCCH (if enabled)
Signaling requirements of the SDCCH
SDCCH planning can be done independently, but CCCH planning depends on PCCCH planning.
It is assumed that by adequate provisioning of the downlink part of the CCCH or PCCCH, the
uplink part is implicitly provisioned with sufficient capacity.
CCCH and PCCCH planning

When PCCCH is disabled (pccch_enabled is set to zero), all control signaling for GSM and
GPRS/EGPRS occur on the CCCH. When PCCCH is enabled, control signaling for GPRS/EGPRS
occurs on the PCCCH instead of the CCCH. Thus, CCCH signaling decreases when PCCCH is
enabled. In other words, the CCCH planning is dependent on PCCCH planning.
When PCCCH is enabled (pccch_enabled is set to 1), an additional variable must be considered.
The network planner must decide whether to use paging coordination in the system. If the
planner decides to use paging coordination (also called Network Operation Mode I), then an MS
only needs to monitor the paging channel on the PCCCH, and receives circuit-switched pages
on the PACCH when it has been assigned a PDTCH. If the planner decides not to use paging
coordination (called Network Operation Mode III), the MS that needs to receive pages for
both circuit-switched and packet-switched services should monitor paging channels on both
PCCCH and CCCH.
NOTE
Network Operation Mode II is currently not supported in the Motorola BSS.
68P02900W21-T
3-53
Jul 2010
Combined BCCH
CCCH and PCCCH decision tree

Figure 3-29 summarizes the decisions used to determine which planning steps should be used to
determine the CCCH and PCCCH signaling capacity requirements.
Figure 3-29 CCCH and PCCCH decision tree
pccch_enabled = 1
pccch_enabled = 0
(1) Decide whether or not paging coordination will be used in the network.
(2) Calculate the number of CCCHs per BTS cell when PCCCH is enabled.
(3) Calculate the number of PRACH blocks per BTS cell.
(4) Calculate the number of PAGCHblocks per BTS cell.
(5) Calculate the number of PPCH blocks per BTS cell.
(6) Calculate the number of PBCCH blocks per BTS cell.
Calculate the number of CCCHs per BTS cell when PCCCH is disabled.
ti-GSM-CCCH_and_PCCCH_decision_tree-00201ai-sw
Combined BCCH
This planning guide provides the planning rules that enable the network planner to evaluate
whether a combined BCCH can be used, or if a non-combined BCCH is required. The decision
to use a non-combined BCCH is a function of the number of CCCH channels required and the
number of SDCCH channels required.
The use of a combined BCCH is desirable because it permits the use of only one timeslot on
a carrier that is used for signaling. A combined BCCH can offer four more SDCCH blocks for
use by the GSM circuit-switched signaling traffic. If more than an average of three CCCH
blocks, or more than four SDCCH blocks, are required to handle the signaling load, more
control channel timeslots are required.
The planning approach for GPRS/EGPRS/GSM control channel provisioning is to determine
whether a combined BCCH is possible, given the load on the CCCH control channel. When more
than three and less than nine CCCH blocks are required to handle the combined load, the use of
a combined BCCH is not possible. When more than nine CCCH blocks are needed, one or more
timeslots are required to handle the CCCH signaling. In this case, it is advantageous to use a
combined BCCH again, depending on the CCCH and SDCCH load.
The determination of how many CCCH and SDCCH blocks are required to support the
circuit-switched GSM traffic is deferred to the network planning that is performed with the aid
of the relevant planning information for GSM. The network planning that is performed using the
planning information determines how many CCCH and SDCCH blocks are required, and then
how many timeslots in total are required to support the CCCH and SDCCH signaling load.
3-54
68P02900W21-T
Jul 2010
Number of CCCHs and PCCCHs per BTS cell

The following factors should be considered when calculating the number of CCCHs per BTS cell
are as follows:
The CCCH channels comprise the Paging CHannel (PCH) and Access Grant CHannel
(AGCH) in the downlink, and the Random Access CHannel (RACH) in the uplink.
If PCCCH is enabled (pccch_enabled is set to 1), then the PCCCH relieves all GPRS/EGPRS
control signaling from the CCCH. Further, if paging coordination is also enabled, GSM CS
paging also occurs on the PCCCH for all GPRS/EGPRS-enabled mobiles.
If the CCCH has a low traffic requirement, the CCCH can share its timeslot with SDCCHs
(combined BCCH). If the CCCH carries high traffic, a non-combined BCCH must be used.
Combined BCCH (with four SDCCHs)
Number of CCCH blocks = 3
Number of CCCH blocks reserved for AGCH bs_ag_blks_res is 0 to 2
Number of CCCH blocks available for PCH is 1 to 3
Non-combined BCCH
Number of CCCH blocks = 9
Number of CCCH blocks reserved for AGCH bs_ag_blks_res is 0 to 7
Number of CCCH blocks available for PCH is 2 to 9
When a non-combined BCCH is used, it is possible to add additional CCCH control channels
(in addition to the mandatory BCCH on timeslot 0). These additional CCCH control
channels are added, in order, on timeslots 2, 4, and 6 of the BCCH carrier, thus creating
cells with 18, 27, and 36 CCCH blocks. These configurations would only be required for
high capacity cells or in large location areas with a large number of pages.
Each CCCH block can carry one message. The message capacity of each CCCH block is
4.25 messages/second. This is due to the 51-frame multiframe structure of the channel.
Each PCCCH block can carry one message. The message capacity of each PCCCH block is
4.17 messages/second. This is due to the 52-frame multiframe structure of the channel.
The AGCH is used to send immediate assignment and immediate assignment reject
messages for GSM MSs and, if PCCCH is not enabled, GPRS/EGPRS MSs. Each AGCH
immediate assignment message can convey channel assignments for up to two MSs. Each
AGCH immediate assignment reject message can reject channel requests from up to four
MSs.
The PCH is used to send GSM paging messages and, if PCCCH is not enabled, GPRS/EGPRS
paging messages. Each PCH paging message can contain pages for up to four MSs
using TMSI or two MSs using IMSI. If no paging messages are to be sent in a particular
CCCH block, then an immediate assignment or immediate assignment reject message
can be sent instead.
68P02900W21-T
3-55
Jul 2010
The current Motorola BSS implementation applies the following priority (highest to lowest)
for downlink CCCH messages:
Paging message (if not reserved for AGCH)
Immediate assignment message
Immediate assignment reject message
Thus, for example, if for a particular CCCH subchannel there are always paging messages
(that is high paging load) waiting to be sent, no immediate assignment or immediate
assignment reject messages are sent on that CCCH subchannel. Hence the option to
reserve CCCH channels for AGCH.
It can normally be assumed that sufficient capacity exists on the uplink CCCH (RACH) once
the downlink CCCH is correctly dimensioned.
Some other parameters can be used to configure the CCCH channels. Some of these are:
Number of paging groups. Each MS is a member of only one paging group and only
needs to listen to the PCH subchannel corresponding to that group. Paging group size
is a trade off between MS idle-mode battery life and speed of access (for example,
a lot of paging groups, means the MS need only listen occasionally to the PCH, but
as a consequence it takes longer to page that MS, resulting in slower call set-up
as perceived by a PSTN calling party).
Number of repetitions for MSs attempting to access the network on the RACH.
The time MS must wait between repetitions on the RACH.
Extended Uplink TBF is the feature that enhances uplink data performance by minimizing
the interruptions of uplink data flow in GPRS/EGPRS networks due to a frequent release
and establishment of uplink TBF. According to the principle of Extended Uplink TBF, this
feature decreases the amount of RACH for uplink applications session like uplink FTP. If
the uplink application is rare, total amount of decreased RACH is small. Thus the impact of
RACH decrement can be ignored, if the uplink application is booming and total amount of
decreased RACH is huge, otherwise the impact of RACH decrement cannot be ignored and
RACH decrement is taken into account for CCCHs calculation.
Precise determination of the CCCH requirements is difficult. However, some statistics can
be collected (for example ACCESS_PER_PCH, ACCESS_PER_AGCH) by the BSS and can be
used to determine the CCCH loading and hence perform adjustments.
For the cell with extended PDCH, PCCCH is disabled.
Calculating the number of CCCHs per BTS cell - PCCCH disabled

When PCCCH is disabled (pccch_enabled is set to zero), the provisioning of the CCCH
is estimated by calculating the combined load from the GPRS/EGPRS pages, GSM pages,
GPRS/EGPRS access grant messages and GSM access grant messages. The calculation is
performed by adding the estimated GPRS/EGPRS and GSM paging blocks for the BTS cell to
the estimated number of GPRS/EGPRS and GSM access grant blocks for the BTS cell, and
dividing that sum by the CCCH utilization factor.
3-56
68P02900W21-T
Jul 2010
NOTE
Introducing the GPRS/EGPRS feature into a cell may cause noticeable delays for
paging in that cell. Motorola advises operators to re-check the NPAGCH and NPCH
equations provided here when adding GPRS/EGPRS to a cell. Enable PCCCH in
cells with heavy paging.
The following planning actions are required:
NOTE
In the following paragraphs, GPRS notation represents GPRS/EGPRS.
Determine the number of CCCHs per BTS. The average number of blocks required to support
AGCH and PCH is given by the following equation:
NP CH AGCH N CH = NP CH + NAGCH + NN CH
The average number of blocks required to support AGCH and PCH is given by the following
equation:
NP CH+AGCH =
NAGCH + NP CH
UCCCH
The average number of blocks required to support AGCH only is given by the following equation:
NAGCH = +NAGCH GSM + NAGCH GP RS

The average number of blocks required to support AGCH for GSM traffic is given by the
following equation:
NP CH+AGCH =
AGCH
NAGCH/Block 4.25
The number of access grants per AGCH block is 2.
NAGCH/Block = 2
The average number of blocks required to support AGCH for GPRS/EGPRS traffic is given
by the following equation:
NAGCH GP RS =
68P02900W21-T
RACHA Arrivals/Sec 1.1

4.25
3-57
Jul 2010
Where:
GP RS U sers Avg Sessions per user
3600
RACHA Arrivals per sec =
The access grant rate is given by the following equation:
AGCH = CALL + L + S + LCS

The call rate (calls per hour) is given by the following equation:
CALL =
e
T
The location update rate (LU per hour) is given by the following equation:
L = L
e
T
The SMS rate (SMSs per hour) is given by the following equation:
S = S
e
T
The LCS rate (LCSs per hour) is given by the following equation:
LCS = LCS
e
T
The average number of blocks required to support PCH only is given by the following equation:
NP CH = +NP CH GSM + NP CH GP RS
The average number of blocks required to support GSM CS paging only is given by the following
equation:
NP CH GSM =
PGSM
NP ages/Block 4.25
The number of pages per paging PCH block depends on whether paging is performed using
TMSI or IMSI.
For TMSI paging: N pages/Block = 4
For IMSI paging: N pages/Block = 2
The number of paging blocks required at a cell to support GPRS/EGPRS is given by:
NP CH GP RS =
3-58
PGP RS 1.2
4.25
68P02900W21-T
Jul 2010
Where:
Is:
UCCCH
CCCH utilization.
lAGCH
access grant rate (per second).
GPRS_Users
number of GPRS and EGPRS users on a cell.
Avg_Sessions_per_user
lcall
average number of sessions originated by user per busy hour

(this includes the sessions for signaling).
call arrival rate per second.
lL
location update rate per second.
lS
number of SMSs per second.
number of Erlangs per cell.
average call length, in seconds.
PGSM
number of GSM circuit-switched traffic pages transmitted to

a BTS cell per second.
PGPRS
number of GPRS or EGPRS pages transmitted to a BTS cell

per second.
The following table provides the control channel configurations.
Table 3-6
Control channel configurations
Timeslot 0
Other timeslots
Comments
1 BCCH + 3 CCCH +
4 SDCCH
N x 8 SDCCH
Combined BCCH. The other timeslot

may or may not be required, depending
on the support of circuit-switched traffic
where the value of N is 0.
1 BCCH + 9 CCCH
N x 8 SDCCH
Non-combined BCCH. The value of N is

1.
1 BCCH + 9 CCCH
N x 8 SDCCH, 9
CCCH
Non-combined BCCH. This is an example

of one extra timeslot of CCCHs added
in support of GPRS traffic. The value of
N is 1.
Calculating the number of CCCHs per BTS cell - PCCCH enabled

When PCCCH is enabled (pccch_enabled is set to 1), the Network Operation Mode becomes
relevant to the planning rules. If paging coordination is used and Network Operation Mode is I,
then circuit-switched pages for Class A and Class B mobiles (mobiles that are capable of both
GSM and GPRS) and pages for EGPRS mobiles are sent on the PCCCH instead of the CCCH.
Regardless of paging coordination though, all GPRS/EGPRS control signaling occurs on the
PCCCH. Hence, the following planning rules should be used.
The average number of blocks required to support AGCH and PCH is given by the following
equation:
NP CH+AGCH = (NAGCH + NP CH )
68P02900W21-T
1
UCCCH
3-59
Jul 2010
The average number of blocks required to support AGCH only is given by the following equation:
NAGCH GSM =
AGCH
NAGCH/Block 4.25
The number of access grants per AGCH block is 2.
NAGCH/Block = 2
AGCH = CALL + L + S + LCS

call =
e
T
The location update rate (LU per hour) is given by the following equation:
L = L
e
T
The SMS rate (SMSs per hour) is given by the following equation:
S = S
e
T
The LCS rate (LCSs per hour) is given by the following equation:
LCS = LCS
e
T
The average number of blocks required to support PCH depends on the provisioning of paging
coordination in the cell. If paging coordination is not enabled then the average number of blocks
required to support GSM CS paging is given by the following equation:
NP CH =
PGSM
NP ages/Block 4.25
If paging coordination is enabled, the average number of blocks required to support GSM
CS paging is given by the following equation:
NP CH =
NGSM Only M S
NGSM Capable M S
PGSM
NP ages/Block 4.25
The number of pages per paging PCH block depends on whether paging is performed using
TMSI or IMSI.
3-60
68P02900W21-T
Jul 2010
For TMSI paging: N pages/Block = 4

For IMSI paging: N pages/Block = 2
The number of paging blocks required at a cell to support GPRS/EGPRS is given by the
following equation:
NP CH GP RS =
PGP RS 1.2
4.25
Where:
Is:
UCCCH
CCCH utilization.
lAGCH
access grant rate (per second).
P
lcall
paging rate per second.

lL
location update rate per second.
lS
number of Erlangs per cell.
average call length, in seconds.
PGSM
the number of GSM circuit-switched traffic pages transmitted to

a BTS cell per second.
NGSM_Only_MS
number of mobiles in the system that do not support GPRS/EGPRS
NGSM_Capable_MS
number of mobiles in the system that support GSM and, optionally,

GPRS/EGPRS. This is also equal to the total number of mobiles
in the system minus the number of GPRS/EGPRS-only mobiles
in the system.
The network planner can provision up to 1 PCCCH timeslot per BTS cell. If the PCCCH is
enabled, then the PCCCH occupies a reserved PDTCH timeslot on the BCCH carrier. The
use_bcch_for_gprs parameter is ignored to allow only the PCCCH timeslot on the BCCH carrier.
If the feature, Baseband Hopping on BCCH carrier of the cell with PBCCH functionality is
used, the PCCCH/PBCCH can be enabled if BCCH carrier is part of the hopping system and
TS1 of the BCCH carrier is a non-hopping timeslot. Hopping can be enabled on TS2 to TS7
of the BCCH carrier while PCCCH/PBCCH is enabled and TS1 is configured or allocated as
PCCCH/PBCCH timeslot.
The network planner can reserve 1 to 12 of the radio blocks on the uplink PCCCH as PRACH,
For GPRS/EGPRS random access, using the cells bs_prach_blks parameter. Any uplink PCCCH
blocks that are not reserved for PRACH can be used as PDTCH for up to 2 mobiles.
The network planner allocates the 12 radio blocks on the downlink PCCCH among 4 logical
channels: PBCCH, PPCH, PAGCH, and PDTCH. Allocation among these channels is a trade-off
between the following factors:
The PPCH and PAGCH capacity required for the cell.
The delay required for mobiles to acquire PBCCH system information upon entering the
cell. This delay is directly related to the delay before a mobile can start a data session
following cell selection.
The PDTCH capacity available on the PCCCH timeslot.
68P02900W21-T
3-61
Jul 2010
PBCCH blocks are reserved using the bs_pbcch_blks parameter. PAGCH blocks can be
reserved using the bs_ag_blks_res parameter. All other downlink PCCCH blocks can be used
for the PPCH, but there is no parameter to reserve PPCH blocks. Nevertheless, the network
planner should calculate the number of PPCH blocks required in a BTS cell to determine how
many blocks can be allocated to PBCCH blocks.
Any downlink PCCCH blocks that are not reserved for PBCCH, can be used for user data
transmission when not being utilized for control signaling. The PCCCH timeslot is used for user
data for up to 2 mobiles.
For the subsequent calculations, the message capacity for each PCCCH block is 1 message per
0.240 second.
Calculating the number of PRACH blocks per BTS cell

The network planner should use the average number of blocks necessary to support PRACH
to set the cells bs_prach_blks parameter.
NOTE
bs_prach_blk = Roundup(NPRACH)
The average number of blocks required to support PRACH is given by the following equation:
NP RACH =
GP RS RACH/Sec 0.24
UP CCCH
The average number of PRACH arrivals per second is given by the following equation:
GP RS RACH/Sec =

3600
Where:
UCCCH
GPRS_RACH/sec
GPRS_Users
3-62
Is:
desired PCCCH utilization.
GPRS/EGPRS random access rate (per second).
68P02900W21-T
Jul 2010
Calculating the number of PAGCH blocks per BTS cell

The network planner should use the average number of blocks necessary to support PAGCH
to set the cells bs_pag_blk_res parameter.
bs_pag_blk = Roundup(NPAGCH)
The average number of blocks required to support PAGCH is given by the following equation:
NP AGCH =
GP RS RACH/Sec 1.1 0.24

UP CCCH
The average number of RACH arrivals per second is given by the following equation:
GP RS RACH/Sec =

3600
Where:
Is:
UCCCH
GPRS_RACH/sec
GPRS/EGPRS random access rate (per second).
GPRS_Users

Calculating the number of PPCH blocks per BTS cell

The average number of blocks required to support PPCH is given by:
NP P CH =
NP P CH GSM + NP P CH GP RS
UP CCCH
NOTE
If paging coordination is not enabled in the network, then the average number of PPCH blocks
required to support GSM CS paging only is zero:
NP P CH GSM = 0
68P02900W21-T
3-63
Jul 2010
If paging coordination is enabled, then the average number of blocks required to support PPCH
is given by the following equation:
NP P CH GSM =
NGSM GP RS M S
P GSM 0.24
NALL M S
The average number of PPCH blocks required to support GPRS/EGPRS paging only is given
NP P CH GSM = PGP RS 1.2 0.24

Where:
UCCCH
NGSM_GPRS_MS
NALL_MS
PGSM
Is:
number of mobiles in the system that are capable of both GSM and
GPRS/EGPRS services.
total number of mobiles in the system.
number of GSM circuit-switched traffic pages transmitted to a BTS cell per
second PGPRS number of GPRS/EGPRS pages transmitted to a BTS cell per
second.
NOTE
When GSM CS paging load becomes heavy and paging coordination is enabled, the
PPCH blocks exceed the capacity of PCCCH.
Selecting the number of PBCCH blocks per BTS cell

The network planner must allocate between 1 and 4 PBCCH radio blocks on the downlink
PCCCH by setting the cells bs_pbcch_blks parameter.
An allocation of 4 PBCCH blocks minimizes the time required for the mobile to acquire the
GPRS/EGPRS broadcast system information of the cell. In turn, this minimizes the delay before
the mobile can start data transmission upon cell selection or reselection. An allocation of
1 PBCCH block minimizes the radio resources consumed by PBCCH, freeing up more radio
resources for PAGCH, PPCH, and user data transmission. Thus choosing the number of PBCCH
blocks per BTS cell is a trade-off between the data transmission delay following cell selection or
reselection against radio resources available for PPCH, PAGCH, and PDTCH.
The number of PCCCH blocks available for PBCCH is given by the following equation:
Available = 12 Roundup (NP AGCH ) Roundup (NP P CH )
3-64
68P02900W21-T
Jul 2010
User data capacity on the PCCCH timeslot
So, the network planner must select the number of PBCCH block (NPBCCH) such that it does
not exceed the blocks available (maximum of 4 blocks). The network planner must also consider
the trade-off with PDTCH capacity on the PCCCH timeslot.
It is recommended that the network planner maximize the PBCCH blocks instead of PDTCH
capacity on the PCCCH timeslot. The PCCCH timeslot is only used for PDTCHs during conditions
of cell congestion. Therefore, the network planner can improve the user experience more by
maximizing the PBCCH blocks and consequently minimizing data transmission delay following
cell selection or reselection. The network user chooses to prioritize PDTCH capacity when only
a single PDTCH exists in the cell, that is, the PCCCH timeslot is the only GPRS/EGPRS timeslot.
User data capacity on the PCCCH timeslot

The PCCCH timeslot can support user data traffic (PDTCH) for up to two mobiles. The radio
blocks on the uplink PCCCH timeslot that are not required for PRACH are available for PDTCH.
Similarly, the radio blocks on the downlink PCCCH timeslot that are not required for PBCCH,
PAGCH, or PPCH are available for PDTCH as well. If other PDTCHs are available in the cell,
PDTCHs are allocated on the PCCCH timeslot when the cell is congested.
Accordingly, the network planner can estimate the data capacity on the PCCCH timeslot. The
formulas given can be use to estimate the raw data capacity of the PCCCH timeslot. The raw
data rate estimates are not adjusted for protocol overhead and possible data compression.
They are for informational use only.
The raw downlink PDTCH capacity is given by the following equation:
Downlink Capacity =
12 NP BCCH NP AGCH NP P CH
T S Data Rate
12
The raw uplink PDTCH capacity is given by the following equation:
U plink Capacity =
Where:
TS_Data_Rate
12 Roundup (NP RACH )

T S Data Rate
12
Is:
average data rate of the PCCCH timeslot based on the expected radio
conditions on the PCCCH carrier.
The radio conditions determine the coding scheme used for the data transmission.
For example, suppose the network planner expects good radio conditions on the PCCCH carrier
so that CS4 is used 80% of the time and CS3 is used 20% of the time. The network planner also
calculates the following when dimensioning the PCCCH:
NPAGCH = 2
NPPCH = 3
NPBCCH = 4
68P02900W21-T
3-65
Jul 2010
Number of SDCCHs per BTS cell
In this case, the average data rate is calculated as follows:
T S Data Rate = 0.80 20 + 0.2 14.6 = 18.92 Kbits/s

So the raw data capacity for the downlink PCCCH can be calculated using the following equation:
Downlink Capacity =
12 4 2 3
18.92 = 4.73 Kbits/s
12

Determining the SDCCH requirement is an important part of the planning process. The SDCCH
is where a large portion of signaling and data messaging takes place for SMS, location update
and call set-up. As the number of calls taking place in a BTS increases, greater demand is placed
on the control channel for call set-up and the same is true if the number of SMS increases.
The Fast Call Setup feature allows the BSS to allocate an appropriate channel based on
the establishment cause. That is, TCH directly to the MS if the MS intends to make a
speech call, or SDCCH if the MS intends to send an SMS. The user configurable parameter
TCH_usage_threshold keeps track of the percentage of TCH that are busy in the BCCH band.
When the busy percentage is equal or higher to TCH_usage_threshold, the BSS turns this
feature off.
By reviewing the collected network statistics GTTP_UL_LLC and GTTP_DL_LLC on a continuous
basis, the network planner can tune the Max_Lapdm parameter, as well as the SDCCH
configuration. Based on the analysis, the GTTP has only minor impact on SDCCH planning.
NOTE
Considering the impact to voice quality from GTTP signaling, set Max_Lapdm
parameter to the default value of 5.
The following factors should be considered when calculating the number of SDCCH per BTS cell:
3-66
To determine the required number of SDCCHs for a given number of TCHs per cell, the
call, location update, and SMS (point to point) rates must be determined. A TCH is directly
allocated to the MS for a speech call when the Fast Call Setup feature is turned on. The
SDCCH usage drops require to be accounted for. Refer to the equations for information on
calculating these rates. Once these rates are determined, the required number of SDCCHs
for the given number of TCHs can be determined. Refer to the equations for information
on calculating the required number of SDCCHs.
The rates for SMS are for the SMSs taking place over an SDCCH. For MSs involved in a call,
the SMS takes place over the TCH, and does not need the use of an SDCCH. Further, if the
network is configured to send SMS over GPRS, SMS does not need the use of an SDCCH.
68P02900W21-T
Jul 2010
Calculating the number of SDCCHs required is necessary for each cell at a BTS site.
The equation for NSDCCH is used to determine the average number of SDCCHs.
There is a limit of 124 or 128 SDCCHs (depending on whether control channels are
combined or not) per cell. This limits the number of supportable TCHs within a cell.
A change in the call model also affects the number of SDCCHs (and supportable TCHs)
required. The formula should then be used to calculate the number of SDCCHs needed.
The number of Erlangs in Table 3-8 and Table 3-9 is the number of Erlangs supported
by a given cell, based on the number of TCHs in that cell. To determine the number of
Erlangs supported by a cell, use Erlang B.
The number of TCHs in a cell vary depending upon the number of carriers that are (AMR or
GSM) half rate capable. The number of calls that use the half rate capable carriers varies
depending upon such factor as cell loading, mobile penetration and so on. In Table 3-8
and Table 3-9, a worst case scenario is assumed, where all half rate capable carriers
are used as half rate.
NOTE
Not all combinations of half rate usage are shown in the tables.
The call arrival rate is derived from the number of Erlangs (Erlangs divided by call
duration).
Use Erlang B (on the value of NSDCCH) to determine the required number of SDCCHs
necessary to support the desired grade of service.
The number of location updates is higher for sites located on the borders of location areas,
as compared to inner sites of a location area (refer to Figure 3-30).
Figure 3-30
Location area diagram
BORDER BTS =
INNER BTS =
LOCATION AREA
ti-GSM-Location_area_diagram-00202-ai-sw
68P02900W21-T
3-67
Jul 2010
Calculating the number of SDCCHs per BTS cell

Determine the number of SDCCHs per BTS cell. The average number of SDCCHs is given
NSDCCH = Call Tc Tu + L (TL + Tg ) + S (TS + Tg ) + LCS (TLCS + Tg )

Where:
Is:
NSDCCH
average number of SDCCHs.
lcall
Tc
time duration for call set-up.
Tu
the Fast Call Setup component. This is set to 1 if Fast Call Setup is disabled
or not purchased otherwise this is set to (100 - TCH usage threshold)/100.
lL
location update rate.
TL
time duration of location updates.
Tg
guard time for SDCCH.
lS
TS
time duration of SMS (Short Message Service set-up).
lLCS
number of LCSs per second.
TLCS
time duration of LCS (Location Service Set-up).
The timeslots allocated for SDCCH follows the new algorithm for picking the timeslots based on
the following parameter settings:
3-68
Per carrier db parameter sd_priority: The parameter sd_priority takes a value in the
range 0 to 250, and this assigns a priority value to the carrier (RTF); the lower the priority
the higher the possibility to get an SDCCH in the carrier (RTF).
PBCCH: If PBCCH is configured, the NON BCCH carrier has preference over the BCCH
carrier.
Number of available TCH barred timeslots: Available TCH barred timeslots are TCH barred
timeslots which are not configured as SDCCH timeslots yet. TCH or PDTCH cannot be
configured on a TCH barred timeslot since it does not have a terrestrial backhaul. It can
only be used for SDCCHs since SDCCH timeslots do not need terrestrial backhaul.
PGSM/EGSM: The PGSM carrier is preferred over EGSM carriers.
Per carrier db parameter pkt_radio_type: The parameter pkt_radio_type determines if

the RTF can carry GPRS/EDGE or not. Carriers with lower pkt_radio_type are preferred
over carriers with higher pkt_radio_type.
Half Rate: Non Half Rate carriers are preferred over Half Rate capable carriers.
68P02900W21-T
Jul 2010
SDCCH loading (Not the db parameter sd_load, but the actual number of SDCCH
timeslots configured). Carriers with fewer sdcch loading are selected over carriers with
higher sdcch loading so that SDs get distributed among carriers with identical SD-related
parameters. The db parameter sd_load determines the number of timeslots in the carrier
that can be SDCCH. This can take a value of 0 through 8; that is, up to 8 timeslots can be
configured as SDCCH in a single carrier.
Carrier id: Carrier id is used as a tie breaker among two carriers. Carrier with lower
carrier id is selected over carrier with higher carrier id.
SDCCH configuration recommendations

SDCCH TS should be spread as widely as possible across available carriers. Only one SDCCH TS
is allowed on the BCCH Carrier. This can be achieved by setting sd_load parameter for BCCH
RTF to 1. A maximum of 3 SDCCH TS on other carriers are recommended, though 2 SDCCH TS
is a preferred maximum. This can be achieved by setting sd_load on non BCCH RTF to 2 or 3.
Number_sdcchs_preferred is the number of SDCCH the system configures at the system
initialization time.
When channel_reconfiguration_switch is enabled, then based on SDCCH usage, the TCH in
the cell can be reconfigured to SDCCH up to max_number_of_sdcchs based on need.
When SDCCH blocking is perceived to be high at a cell, set the max_number_of_sdcchs to be
greater than number_sdcchs_preferred. This can help alleviate SDCCH blocking in that cell.
The following table provides a set of example configurations.
Table 3-7
Example Configurations
Number of
SDCCH/ cell
SDCCH
on BCCH
carrier
SDCCH
on second
carrier
SDCCH on
third carrier
SDCCH
on fourth
carrier
SDCCH on
fifth carrier
SDCCH
on sixth
carrier
60
12
16
16
16
64
16
16
16
92
12
16
16
16
16
16

Table 3-8 and Table 3-9 give typical control channel configurations based on the typical BTS
planning parameters given in Table 3-5. Due to the many combinations of half rate capable
RTFs, only a partial listing is depicted.
68P02900W21-T
3-69
Jul 2010
Control channel configurations for non-border location area

Table 3-8 shows the configurations for non-border location area cell, where the ratio of location
updates to calls is 2.
Table 3-8
Number of
RTFs
Control channel configurations for non-border location area

Number of
TCHs
Number of
Erlangs
Number of
SDCCHs
Timeslot utilization
Timeslot 0
Other timeslots
1 fr
2.94
1 BCCH +3 CCCH
+4 SDCCH
N/A
1 hr
12
6.61
1 BCCH + 9 CCCh
8 SDCCH
2 fr
14
8.20
1 BCCH + 3 CCCH+4
SDCCH
8 SDCCH
1 fr
1 hr
21
14.03
13
1 BCCH + 9 CCCH
2 * 8 SDCCH
2 hr
26
18.38
15
1 BCCH + 9 CCCH
2 * 8 SDCCH
3 fr
21
14.04
13
1 BCCH + 9 CCCH
2 * 8 SDCCH
2 fr
1 hr
29
21.03
16
1 BCCH + 9 CCCH
2 * 8 SDCCH
1 fr
2 hr
36
27.3
21
1 BCCH + 9 CCCH
3 * 8 SDCCH
3 hr
40
31.0
22
1 BCCH + 9 CCCH
3 * 8 SDCCH
4 fr
29
21.03
16
1 BCCH + 9 CCCH
2 * 8 SDCCH
3 fr
1 hr
36
27.3
20
1 BCCH + 9 CCCH
3 * 8 SDCCH
3 hr
40
31.0
22
1 BCCH + 9 CCCH
3 * 8 SDCCH
4 fr
29
21.03
16
1 BCCH + 9 CCCH
2 * 8 SDCCH
3 hr
40
31.0
22
1 BCCH + 9 CCCH
3 * 8 SDCCH
4 fr
29
21.03
16
1 BCCH + 9 CCCH
2 * 8 SDCCH
3 fr
1 hr
36
27.3
20
1 BCCH + 9 CCCH
3 * 8 SDCCH
5 fr
36
27.3
20
1 BCCH + 9 CCCH
3 * 8 SDCCH
Continued
3-70
68P02900W21-T
Jul 2010
Table 3-8
Number of
RTFs
Control channel configurations for non-border location area (Continued)

Number of
TCHs
Number of
Erlangs
Number of
SDCCHs
Timeslot 0
Other timeslots
6 fr
44
34.7
24
1 BCCH + 9 CCCH
3 * 8 SDCCH
5 fr
1 hr
51
41.2
28
1 BCCH + 9 CCCH
4 * 8 SDCCH
3 fr
3 hr
66
55.3
35
1 BCCH + 9 CCCH
5 * 8 SDCCH
6 hr
82
70.6
43
1 BCCH + 9 CCCH
6 * 8 SDCCH
7 fr
51
41.2
28
1 BCCH + 9 CCCH
4 * 8 SDCCH
8 fr
59
49.6
32
1 BCCH + 9 CCCH
4 * 8 SDCCH
9 fr
66
55.3
35
1 BCCH + 9 CCCH
5 * 8 SDCCH
10 fr
74
62.9
39
1 BCCH + 9 CCCH
5 * 8 SDCCH
NOTE
The CBCH reduces the number of SDCCHs by one and needs another channel.
Control channel configurations for border location area

The following table shows the configurations for the border location area cell, where the ratio of
location updates to calls is 7.
Table 3-9
Control channel configurations for border location area

Number
of RTFs
Number
of TCHs
Number of
Erlangs
Number of
SDCCHs
Timeslot 0
Other
timeslots
1 fr
2.28
1 BCCH + 9 CCCH
8 SDCCH
1 hr
12
6.61
12
1 BCCH +3 CCCH +
4SDCCH
8 SDCCH
2 fr
13
7.4
15
1 BCCH + 9 CCCH
2 * 8 SDCCH
1 fr
1 hr
21
14.0
20
1 BCCH + 3 CCCH +
4 SDCCH
2 * 8 SDCCH
2 hr
24
16.6
24
1 BCCH + 9 CCCH
3 * 8 SDCCH
3 fr
20
13.2
21
1 BCCH + 9 CCCH
3 * 8 SDCCH
2 fr
1 hr
27
19.3
27
1 BCCH + 9 CCCH
4 * SDCCH
1 fr
2 hr
34
25.5
34
1 BCCH + 9CCCH
5 * 8 SDCCH
Continued
68P02900W21-T
3-71
Jul 2010
Table 3-9
Control channel configurations for border location area (Continued)

Number
of RTFs
Number
of TCHs
Number of
Erlangs
Number of
SDCCHs
Timeslot 0
Other
timeslots
3 hr
36
27.3
36
1 BCCH + 9CCCH
5 * 8 SDCCH
4 fr
27
19.3
27
1 BCCH + 9 CCCH
4 * 8 SDCCH
3 fr
1 hr
34
25.5
34
1 BCCH + 9CCCH
4 * 8 SDCCH
5 fr
35
26.4
35
1 BCCH + 9CCCH
5 * 8 SDCCH
6 fr
42
32.8
41
1 BCCH + 9 CCCH
6 * 8 SDCCH
5 fr
1 hr
49
39.3
48
1 BCCH + 9 CCCH
6 * 8 SDCCH
3 fr
3 hr
63
52.5
62
1 BCCH + 9 CCCH
8 * 8 SDCCH
7 fr
49
39.3
48
1 BCCH + 9 CCCH
6 * 8 SDCCH
8 fr
56
45.9
55
1 BCCH + 9CCCH
7 x 8 SDCCH
9 fr
63
52.5
64
1 BCCH + 9 CCCH
8 * 8 SDCCH
10 fr
70
59.1
68
1 BCCH + 9 CCCH
9 * 8 SDCCH
For the ITS feature, to configure more EGPRS PDs on DD CTU2 Carrier A, set sd_priority to
lowest value and set sd_load to 0 for both carrier A and B.
3-72
68P02900W21-T
Jul 2010
GPRS/EGPRS traffic planning
GPRS/EGPRS traffic planning
Determination of expected load

The planning process begins by determining the expected GPRS/EGPRS load (applied load) to
the system. The next step is to determine the effective load to the system by weighing the
applied load by network operating parameters. These parameters consist of the expected
BLock Error Rate (BLER) based on the cell RF plan, the protocol overhead (GPRS/EGPRS
protocol stack, that is TCP/IP, LLC, SNDCP, RLC/MAC), the expected advantage from V.42bis
compression, SIP signaling compression and TCP/IP header compression, and the multislot
operation of the mobiles and infrastructure.
The effective load at a cell is used to determine the number of GPRS timeslots required to
provision a cell. The provisioning process can be performed for a uniform load distribution
across all cells in the network or on an individual cell basis for varying GPRS cell loads.
The number of GPRS/EGPRS timeslots is the key piece of information that drives the BSS
provisioning process in support of GPRS/EGPRS.
The planning process also uses network generated statistics, available after initial deployment,
for replanning a network. The statistics fall into two categories: PCU-specific statistics, and
GSN (SGSN + GGSN) statistics.
Network planning flow

The following sections are presented in support of the GPRS/EGPRS network planning:
GPRS/EGPRS network traffic estimation and key concepts

This section describes the key concepts involved in planning a network. GPRS/EGPRS uses
switchable timeslots that can be shared by both the GSM circuit-switched infrastructure
and by the GPRS/EGPRS infrastructure, much of the content is dedicated to the discussion
of this topic.
GPRS/EGPRS air interface planning process

This provides a table of inputs that can serve as a guide in the planning process. In
subsequent planning sections, references are made to parameters in this table of inputs. A
key piece of information that is required for the planning process is the RF cell plan. This
subsection discusses the impact of different cell plans on the GPRS/EGPRS provisioning
process, and how to use this information to determine the number of GPRS/EGPRS
timeslots that are required on a per cell basis.
68P02900W21-T
3-73
Jul 2010
GPRS/EGPRS network traffic estimation and key concepts
GPRS/EGPRS network traffic estimation and key

concepts
Introduction
NOTE
Packet data notation is interchangeably used in this section.
The GPRS/EGPRS network planning is fundamentally different from the planning of
circuit-switched networks. One of the fundamental reasons for the difference is that a
GPRS/EGPRS network allows the queuing of data traffic instead of blocking a call when a
circuit is unavailable. Consequently, the use of Erlang B tables for estimating the number of
trunks or timeslots required is not a valid planning approach for the GPRS/EGPRS packet
data provisioning process.
The GPRS/EGPRS traffic estimation process starts by looking at the per cell GPRS/EGPRS
data traffic profile such as fleet management communications, E-mail communications, web
browsing, audio/video playing, PoC service and large file transfers. Once a typical data traffic
profile mix is determined, the required network throughput per cell can be calculated as
measured in kbps. The desired network throughput per cell is used to calculate the number of
GPRS/EGPRS timeslots required to support this throughput on a per cell basis.
The estimated GPRS/EGPRS network delay is derived based on computer modeling of the delay
between the Um interface and the Gi interface. The results are provided in this planning guide.
The network delay can be used to determine the mean or average time it takes to transfer a file
of arbitrary length. To simulate the delay, the following factors are considered:
Traffic load per cell
Mean packet size
Number of available GPRS/EGPRS timeslots
Distribution of CS1 to CS4 and MCS-1 to MCS-9 rate utilization
Distribution of Mobile Station (MS) multi-slot operation (1, 2, 3, 4 or 5)
BLER
Use of timeslots
The use of timeslots for GPRS/EGPRS traffic is different from how they are used in the GSM
circuit-switched case. In circuit-switched mode, an MS is either in idle mode or dedicated mode.
In dedicated mode, a circuit is assigned through the infrastructure, whether a subscriber is
transporting voice or data. In idle mode, the network knows where the MS is, but there is
no circuit assigned. In GPRS/EGPRS mode, a subscriber uses the infrastructure timeslots
for carrying data only when there is data to be sent. However, the GPRS/EGPRS subscriber
3-74
68P02900W21-T
Jul 2010
Introduction
can be attached and not sending data, and this still presents a load to the GSN part of the
GPRS/EGPRS system, which must be accounted for when provisioning the GPRS infrastructure
in state 2 as explained.
The GPRS/EGPRS mobile states and conditions for transferring between states are provided in
Table 3-10 and shown in Figure 3-31 to specify when infrastructure resources are being used to
transfer data. The comment column specifies what the load is on the infrastructure equipment
for that state, and only in state 3 does the infrastructure equipment actually carry user data.
The infrastructure equipment is planned such that many more MSs can be attached to the
GPRS/EGPRS network that is in state 2, than there is bandwidth available to simultaneously
transfer data. One of the more significant input decisions for the network planning process is
to determine and specify how many of the attached MSs are actively transmitting data in the
Ready state 3. In the Standby state 2, no data is being transferred but the MS is using network
resources to notify the network of its location. The infrastructure has equipment limits as to
how many MSs can be in state 2. When the MS is in state 1, the only required infrastructure
equipment support is the storage of MS records in the HLR.
Network provisioning needs planning for traffic channels and for signaling channels, also
referred to as control channels. The BSS combines the circuit-switched and GPRS control
channels together as BCCH/CCCH. The software provides the option of configuring the
PBCCH/PCCCH for GPRS/EGPRS control channels.
Table 3-10 MM state model of MS

Present
state
number
Present
state
Next state
Condition for state

transfer
READY(3)
IDLE
GPRS/EGPRS Attach
Subscriber is not monitored

by the infrastructure that is
not attached to GPRS/EGPRS
MM, and therefore does not
load the system other than
the HLR records.
READY(3)
STANDBY
PDU Transmission
Subscriber is attached to
GPRS/EGPRS MM and is
being actively monitored by
the infrastructure that is
MS and SGSN establish MM
context for subscriber IMSI,
but no data transmission
occurs in this state.
IDLE(1)S
READY
GPRS/EGPR Detach
Data transmission through

the infrastructure occurs in
the Ready state.
STANDBY(2)
READY
Ready timer expiry

or force to Standby
(network or the MS
can send a GMM
signaling message
to invoke force to
Standby).
The ready timer (T3314)

default time is 32 seconds.
The timer value can be
modified during the signaling
process by MS request.2 - 60
s in 2 s increments or 61 1800 s in 60 s increments.
Comments (present state)
The MS and SGSN state models are illustrated in Figure 3-31.
68P02900W21-T
3-75
Jul 2010
Dynamic timeslot allocation
Figure 3-31
MM state models for MS and SGSN
IDLE
GPRS Attach
STANDBY timer
expiry
IDLE
GPRS Detach
READY
GPRS Attach
STANDBY timer expiry

or
Cancel Location
PDU transmission
READY timer expiry

or
Force to STANDBY
STANDBY
MM State Model of MS
GPRS Detach
or
Cancel Location
READY
READY timer expiry

or
PDU reception
Force to STANDBY
or
Abnormal RLC condition
STANDBY
MM State Model of SGSN

ti-GSM-MM_state_models_for_MS_and_SGSN-00203-ai-sw

This section proposes a network planning approach when utilizing dynamic timeslot mode
switching of timeslots on a carrier with GPRS/EGPRS timeslots. The radio interface resources
can be shared dynamically between the GSM circuit-switched services and GPRS/EGPRS data
services as a function of service load and user preference.
The timeslots on any carrier can be reserved for packet data use, for circuit-switched use
only, or allocated as switchable. Motorola uses the term switchable to describe a timeslot
that can be dynamically allocated for packet data service or for circuit-switched service. Idle
circuit-switched timeslots can be used as switchable PDTCHs for packet traffic when GPRS is
congested in the cell.
The timeslot allocation is performed such that the GPRS/EGPRS reserved timeslots are allocated
for GPRS/EGPRS use before switchable timeslots. GSM circuit-switched timeslots are allocated
to the circuit-switched calls before switchable timeslots. The switchable timeslots are allocated
with priority given to circuit-switched calls.
Switchable timeslots are compatible with the AMR and GSM half rate features.
Timeslots are further allocated by TRAU type and BCCH carrier. 64 kbps TRAU are allocated
before 32 kbps TRAU, 32 kbps TRAU are allocated before 16 kbps TRAU. In addition, TRAU
types are given priority over the BCCH carrier.
3-76
68P02900W21-T
Jul 2010
For cell extended PDCH configuration, the extended PDCH is always allocated before the
normal PDCH.
For EGPRS, 64 kbps terrestrial timeslots are required on the link between the BTS and BSC to
support the backhaul required for EGPRS coding schemes MCS-1 to MCS-9. This is a single 64
kbps and not adjacent 16 kbps subrate timeslots. For Non-BCCH carriers all timeslots should
have 64 kbps while for BCCH, the BCCH times slot uses 16 kbps sub rate.
It is possible for the circuit-switched part of the network to be assigned all of the switchable
terrestrial backing under high load conditions and, in effect, block GPRS access to the
switchable timeslots at the BTS. In addition, the reserved GPRS pool of backing resources
can be taken by the circuit-switched part of the network when BSC to BTS E1 outages occur,
and when emergency preemption type of calls occurs and cannot be served with the pool of
non-reserved resources.
Background and discussion

Multiple carriers per cell can be configured with GPRS/EGPRS timeslots by the operator for
packet data traffic handling capability. By doing so, it can meet the expanding base of packet
data subscribers and enhance performance, that is, increase data throughput.
There are two options to configure GPRS/EGPRS timeslots on multiple carriers per cell:
Configure for performance

This is the network default option. Configure for performance provides the network with
the capability to configure all the reserved and switchable GPRS/EGPRS timeslots in a cell
contiguously to maximize performance. The contiguous GPRS/EGPRS timeslots configured
on a carrier in a cell provide ease in scheduling packet data and the capability to service
multiple timeslot GPRS mobiles.
User specified
This provides the flexibility to configure reserve and switchable GPRS/EGPRS timeslots
on a per carrier basis in a cell.
Depending on hardware configuration at a cell, there maybe some limitations on how timeslots
are allocated to EGPRS on a carrier.
EGPRS is available on Horizon macro II through software upgrade. It is also available on
Horizon macro through CTUII upgrade. Since 8-PSK modulated signals do not posses a constant
envelope, linearity requirement on the power amplifier is increased to maintain the out-of-band
radiation to a minimum. The Compact transceiver unit (CTUII) can operate in two modes: High
Power Mode (HPM) or Normal Power Mode (NPM). Each have two sub-modes of operations as
far as number of carriers are concerned: Single Density Mode (SDM) or Dual Density Mode
(DDM).
With the introduction of ITS, EGPRS can operate in SDM and in DDM under which the output
power in GMSK mode (irrespective of whether in EGPRS, GPRS, or voice) can be similar or
higher than the output power in 8-PSK mode, depending on whether operating in NPM or HPM
respectively. CTUII produces the same average output power in EGPRS 8-PSK mode as that
of GSM (GMSK) when GSM is configured in DDM. However, when GSM is in SDM, its output
power can be up to 5 dB higher than EGPRS. There is a settable capping of the output power to
equalize the average output power in GMSK and 8-PSK modes, if required. To support EGPRS
on DDM CTU2 and retain no HW changes of CTU2, each CTU2 is able to rapidly switch between
Double Density modulation (GMSK) and Single Density modulation (8-PSK). The power output is
not affected by the ITS feature for GMSK and 8-PSK. The capping works in 4 steps by setting
a data base parameter to the values as shown in Table 3-11.
68P02900W21-T
3-77
Jul 2010
Table 3-11
Capping settings
Step
Data base parameter value
5 dB higher
2 dB higher
1 dB higher
> 2
0 dB difference
Therefore, depending on the configuration of a cell, it is possible that GMSK signals can be set
to have, on average, higher power than 8-PSK signals. The following are the scenarios in which
there can be up to 5 dB difference between GMSK and 8-PSK modulated signals:
A 2-carrier cell (2/2/2) can have one EGPRS carrier and one GSM full power carrier.
Some of the timeslots of a 1-carrier cell (1/1/1) are allocated to EGPRS. Different powers
are on timeslot by timeslot basis.
On the same timeslot allocated to EGPRS, operators can operate on MCS-1 to MCS-4
and MCS-5 to MCS-9.
However, as a general deployment rule the GMSK and 8-PSK signal power levels should be
set equally (data base parameter value > 2).
{34371G} Compliance of the (R)CTU8m output power capacity for both the GMSK and 8-PSK
is depicted in Table 3-12.
Table 3-12 Output power capacity of (R)CTU8m for GMSK and 8-PSK
GMSK and 8-PSK
E/PGSM900 (R)CTU8m @ 1 carrier per
RF transmission port
GMSK 40 W, 8PSK 30
W -0/+2 dB
E/PGSM900 (R)CTU8m @ 2 carriers per

GMSK 20 W, 8PSK 15
W -0/+2 dB
E/PGSM900 (R)CTU8m @ 3 carriers per

GMSK 10 W, 8PSK 8.5

W -0/+2 dB
{35200G} E/PGSM900 (R)CTU8m @ 4

carriers per RF transmission port
GMSK 8 W, 8PSK 6W
-0/+2 dB
DCS1800 (R)CTU8m @ 1 carriers per RF

transmission port
GMSK 32 W, 8PSK 24
W -0/+2 dB

transmission port
GMSK 16 W, 8PSK 12
W -0/+2 dB

transmission port
GMSK 8 W, 8PSK 6.8

W -0/+2 dB
{35200G} DCS1800 (R)CTU8m @ 4

carriers per RF transmission port
GMSK 6.5 W, 8PSK 5W

-0/+2 dB
CTU2D output power is depicted in Table 3-13.
3-78
68P02900W21-T
Jul 2010
Table 3-13 CTU2D output power

GMSK
8-PSK
EGSM900 SD
63 W -0/+2
dB
EGSM900
DD
20 W -0/+2dB
DCS1800 SD
50 W -0/+2
dB
16 W -0/+2 dB
DCS1800 DD
16 W -0/+2
dB
8-PSK 16 W - 0/+2 dB (Timeslot Blanking, that is, ITS Mode

8-PSK 8 W - /+2 dB (no Timeslot Blanking, that is, ITS Mode)
20 W -0/+2 dB
8-PSK 20 W - 0/+2 dB (Timeslot Blanking, that is, ITS Mode)
8-PSK 9 W - 0/+2 dB (no Timeslot Blanking, that is, ITS
Mode)
When the RTF to DRI mapping is performed, the RTFs equipped for EGPRS (that is, 64 kbps
TRAU) are mapped to SDM or DDM equipped CTUII radios if possible. If the ITS feature is
unrestricted and enabled, it is not recommended to map user preferred 64 k RTF to improper
DRI because it would invalidate the ITS feature. If no single-density or double-density CTUIIs
are available and other DRI hardware is available, the EGPRS RTF falls back to 16 k TRAU.
When such a mapping occurs, the carrier supports signaling, voice and data.
The existing DRI-RTF Mapping functionality is enhanced to cater to the new radio (CTU2D) and
enhanced capabilities (CAP and ASTM mode) which are summarized in the following table:
Table 3-14
DRI-RTF Mapping functionality
DRI-RTF Mapping functionality
Where:
68P02900W21-T
CAP and ASTM mode
SD
CTU2/CTU2D in Single Density (Level0)
A DD
CTU2/CTU2D GMSK Carrier A (Level1)
DD-B
CTU2/CTU2D GMSK Carrier B with DD-A (Level1)
PWR-A
CTU2/CTU2D Edge Carrier A (Level2)
PWR-B
CTU2/CTU2d D GMSK Carrier B with PWR-A (Level2)
CAP-A
CTU2D Edge Carrier A (Level3/4)
CAP-B
CTU2D Edge Carrier B with CAP-A (ASYM supported

Level4)
or
CTU2D GMSK Carrier B with CAP-A (ASYM not supported
Level3)
Is:
Level 0
basic SD Edge/GMSK operation (CTU2/CTU2D Equivalent).
Level 1
basic DD GMSK/GMSK Operation (CTU2/CTU2D Equivalent).
Level 2
Level 1 + Basic DD Edge/GMSK Operation with A Edge and B GMSK with

Timeslot Blanking (CTU2/CTU2D Equivalent).
Level 3
Level 1 + Enhanced DD Edge/GMSK removes B TS Blanking (CTU2D Only).
Level 4
Level 3 + Edge/Edge with B restricted to UL GMSK Only (CTU2D Only).
3-79
Jul 2010
The mapping preferences are given by:
Edge RTF Priority: SD / CAP-A / {34371G} CTU8m / CAP-B (1) / PWR-A / CAP-B (2,3) /
PWR-B (3)
When ASYM enabled
When ASYM disabled
Edge downgraded to 16 k
Non Edge BCCH RTF Priority: CAP-B (1) / PWR-A / {34371G} CTU8m / CAP-A / SD /
PWR-B (2)
CAP-B is preferred due to removal of timeslot blanking and the use is unrestricted.
It results in PWR-A Edge being either stolen or downgraded to 16 k.
Non Edge non BCCH RTF Priority: As legacy except CAP-B is considered unrestricted.
For the cell with extended PDCH, the RTF with extended PDCH shall be preferentially mapped
to CTU-2/CTU2D DRI than non-CTU2/CTU2D DRI, since the extended PDCH can only be
supported on CTU2/CTU2D radios. And for the BTS with extended PDCH, asymmetric mode
shall be disabled.
During site initialization, RTF-DRI mapping preference for 64 k RTF with extended PDCH
shall be:
SD CTU2, SD CTU2D
CAP CTU2D carrier A
DD CTU2 carrier A, DD CTU2D carrier A
CAP CTU2D carrier B, CAP CTU2 carrier A, CAP CTU2 carrier B
DD CTU2 carrier B, DD CTU2D carrier B
Non-CTU2/CTU2D
During site initialization, RTF-DRI mapping preference for Non-64 k RTF with extended PDCH
shall be:
3-80
CAP CTU2D carrier B, CAP CTU2 carrier B, CAP CTU2 carrier A
DD CTU2 carrier B with non-edge carrier A, DD CTU2D carrier B with non-edge carrier A
DD CTU2 carrier B with locked or free carrier A, DD CTU2D carrier B with locked or
free carrier A
DD CTU2 carrier A, DD CTU2D carrier A
CAP CTU2D carrier A
SD CTU2, SD CTU2D
DD CTU2 carrier B with edge carrier A, DD CTU2D carrier B with edge carrier A
Non-CTU2/CTU2D
68P02900W21-T
Jul 2010
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 can only support GSM voice calls.
The BCCH RTF always attempts to migrate to a CTUII if possible. This requirement primarily
comes into play post-initialization when the BCCH RTF fails. The BSS software attempts to both
maintain EGPRS service and keep the BCCH on a CTUII if at all possible. If the BCCH RTF is
configured for EGPRS and there is only one SDM CTUII available, the BCCH RTF is mapped
onto that CTUII, 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 CTUII available, the BCCH is moved to a non-CTUII radio.
At initialization, the BSS should load up non-CTUII hardware with 16 k/32 k carriers as much
as possible. Thus, the BSS software attempts to assign EGPRS carriers onto EGPRS-capable
hardware first, and then assign carriers to the rest of the hardware in its usual fashion. If
PBCCH/PCCCH is enabled in the cell, the BSS ignores the pkt_radio_type value of the BCCH
carrier.
The minimum backhaul requirement is determined to be 3 DS0s since a minimum of 2 DS0s are
required to support voice traffic if all 8 timeslots on a carrier are configured as TCH and the
additional third DS0 provides the bare minimum backhaul required for configurations when 1 to
3 timeslots on the carrier are configured as PDTCHs. The third DS0 also helps in reducing the
time required to start servicing the first PDTCH timeslot by keeping this backhaul synchronized
between the BTS and the PCU even when there are no PDTCHs active on a carrier (provided
there are enough GDS resources available across the cell).
The RTF allow_32k_trau and use_bcch_for_gprs attributes were replaced with a new
parameter pkt_radio_type. pkt_radio_type also accommodates the 64 k backhaul necessary
to support EGPRS and makes it possible to configure RTFs on which GPRS data is specifically
disallowed. Technical Description: BSS Implementation (68PO2901W36) provides a complete
description of these commands.
Depending on the restrictions imposed on GPRS (32 kbps TRAU) and EGPRS (enabled or
disabled), pkt_radio_type can be set between 0 (no packet data) and 3 (64 k).
Every RTF equipped as pkt_radio_type = 3 (64 k) also has a configurable attribute
rtf_ds0_count. If the VersaTRAU feature is unrestricted, the operator can configure the RTF
backhaul for an EGPRS capable carrier to be between 3 kbps and 8 64 kbps terrestrial timeslots.
The BSS supports a minimum of zero to a maximum of 30 GPRS/EGPRS timeslots per cell. The
sum of reserved and switchable GPRS/EGPRS timeslots should not exceed 30.
The GPRS/EGPRS carriers can be provisioned to carry a mix of circuit-switched traffic and
GPRS traffic. There are three provisioning choices combined with timeslot configuration options
selected:
Reserved GPRS/EGPRS timeslots allocated only for packet data use.
Switchable timeslots dynamically allocated for either GSM circuit-switched traffic or

GPRS/EGPRS traffic (designated as switchable timeslots by Motorola).
Remaining timeslots on the carrier with GPRS/EGPRS timeslots, if any, only for
circuit-switched use. Idle circuit-switched timeslots can be used as switchable PDTCHs for
packet traffic when GPRS is congested in the cell.
{34416} If radios with power-saving radios are mixed with non-power-saving radios in the
same BBH hopping group, using PA bias feature in Horizon II sites with mixed radios will
not deliver as the expected power savings.
It is also recommended that the least-preferred RTFs are mapped onto power-saving radios to
maximize power savings.
68P02900W21-T
3-81
Jul 2010
Planning goals - reserved against switchable timeslots

The network planner can consider the following network planning goals when trying to
determine when to use reserved timeslots against when to use switchable timeslots:
Use reserved timeslots to guarantee a minimum quality of service (QoS) for packet data
users.
Use switchable timeslots to provide low circuit mode blocking and high packet data
throughput when the voice busy hour and the GPRS busy hour do not coincide.
Use switchable timeslots to provide higher packet data throughput without increasing
the circuit-switched blocking rate. If all the GPRS/EGPRS timeslots are provisioned
as switchable, the last available timeslot is not given to a circuit-switched call until
transmission of all the GPRS/EGPRS traffic on that last timeslot is completed. Therefore,
there is a circuit-switched blocking on that last timeslot on the cell until the timeslot
becomes free.
Use switchable timeslots to provide some GPRS/EGPRS service coverage in low GPRS
traffic volume areas.
Use switchable timeslots to provide extra circuit-switched capacity in spectrum limited

areas. To make the decision on how to best allocate reserved and switchable timeslots,
the network planner needs to have a good idea of the traffic level for both services. The
proposal in this planning guide is to drive the allocation of switchable timeslots and
reserved GPRS/EGPRS timeslots from a circuit-switched point of view.
Start by looking at the circuit-switched grade of service objectives and the busy hour traffic
level, as measured in Erlangs. Once the circuit-switched information is known, the potential
impact on switchable timeslots can be analyzed. The GPRS/EGPRS QoS can be planned by
counting the number of available reserved GPRS/EGPRS timeslots, and by evaluating the
expected utilization of the switchable timeslots by the circuit-switched part of the network
during the GPRS/EGPRS busy hour.
The priority of timeslot allocation takes into account the factors in the following list. The highest
priority starts with number 1 and the lowest priority is number 5. In the examples that follows,
priorities 3 and 4 are not considered.
1.
TRAU-Type - in the order 64 k, 32 k, and 16 k.
2.
BCCH Carrier.
3.
Most INS number of timeslots: At this step, the following are taken into account:
Continuous timeslots
SD load (signaling load)
SD priority
3-82
68P02900W21-T
Jul 2010
Carrier timeslot allocation examples
4.
The highest local carrier id: This may or may not be corresponding to the RTF index. So,
the highest local carrier id may not necessarily be RTF + 3 if there is a 4 carrier cell (RTF
+ 0 to RTF +3). Hence, the RTF index is irrelevant.
5.
TS priority in the following order:

Reserved
Switchable
Circuit-switched (T)
The 64 k DDM CTU2 carrier A is less preferred for 64 k PDCH placement and its paired 32 k
carrier B is less preferred for 32 k PDCH placement.
With the removal of timeslot blanking for CAP configurations of CTU2D (CAP mode), both
Carrier A and Carrier B is considered as independent and non-interacting when placing PDs,
that is, an EDGE PD placed on A has no impact on Bs ability and priority for the support of
EDGE/GPRS PDs. When CTU2D is configured in ASYM mode, 64 k Carrier A is preferred to 64 k
Carrier B due to asymmetric capability of Carrier B UL restriction to GMSK.
{34371G} 64 k CTU8m carriers are preferred for 64 k PDTCH placement over the non-CTU8m
carriers.
For cell extended PDCH configuration, the extended PDCH is always allocated before the
normal PDCH.

The following configuration examples explore different ways to configure timeslots in a cell.
Some of these examples also illustrate the usage of the PDTCH/backhaul proportion when
configuring the timeslots on an EGPRS capable carrier (pkt_radio_type set to 3) with a
configurable RTF backhaul (using the rtf_ds0_count parameter).
In the examples, the following annotations are used:
B = BCCH/CCCH timeslot for GPRS/GSM signaling.
SD = The ith SDCCH timeslot for GSM signaling. The subscript represents the ascending order
in which the SDCCH timeslots are allocated across carriers.
Ext = Extended timeslot (associated slave timeslot for extended GSM/GPRS/EGPRS channels)
P = PCCCH timeslot for GPRS/EGPRS signaling.
RG = Reserved GPRS timeslot (EGPRS cannot be used, if non-64 k RTF).
RE = Reserved EGPRS timeslot (GPRS can be used).
SG = Switchable GPRS timeslot (EGPRS cannot be used, if non-64 k RTF).
SE = Switchable EGPRS timeslot (GPRS can be used).
T = Circuit-switched use only timeslots.
X = Blanked-out timeslots (on DDM CTU2 Carrier B as Carrier A is capable of EGPRS).
68P02900W21-T
3-83
Jul 2010
Example 1
There are 15 switchable GPRS/EGPRS timeslots and 10 reserved GPRS/EGPRS timeslots in
a 5 carrier cell.
This example assumes that the VersaTRAU feature is not purchased. In this case, the RTF
backhaul for an RTF with pkt_radio_type set to 3 (64 k) is defaulted to 7 DS0s if it is the BCCH
RTF or 8 DS0s if it is a non-BCCH RTF. The following are assumed:
pkt_radio_type is set to:

PGSM BCCH RTF: 64 k (3)
EGSM 2 non-BCCH carriers: 32 k (2)
PGSM 1 non-BCCH carrier: 16 k (1)
PGSM 1 non-BCCH carrier: None (0)
One CTUII and four non-CTUII
GPRS 32 k and EGPRS unrestricted
Assuming sd_load of 2, sd_priority is the same for all the carriers, and PBCCH is not enabled,
the preferred number of SDCCH is 64, HR is disabled, and the timeslot allocation is shown as
illustrated. The GPRS/EGPRS timeslots are configured contiguously for performance. The
packet data timeslots are arranged as shown in the table . The BCCH RTF is mapped to CTUII
and all the reserved timeslots are EGPRS capable. The non-BCCH 32 k carriers are used for
GPRS CS1 to CS4. The remaining switchable timeslots are mapped to one of the non-BCCH 16
k carrier.
Table 3-15 Arrangement of packet data timeslots for example 1

Carrier
TS0
TS1
TS2
TS3
TS4
TS5
TS6
TS7
SD5
SD6
RE
RE
RE
RE
RE
Non-BCCH 32 k (non-CTUII)
SD7
SG
SG
RG
RG
RG
RG
RG
Non-BCCH 32 k(non-CTUII)
SD8
SG
SG
SG
SG
SG
SG
SG
Non-BCCH 16 k (non-CTUII)
SD3
SD4
SG
SG
SG
SG
SG
SG
Non-BCCH (non-CTUII)
SD1
SD2
BCCH 64 k (CTUII)
3-84
68P02900W21-T
Jul 2010
Example 2
a 5 carrier cell.
backhaul for an RTF with pkt_radio_type set to 3 (64 k) is defaulted to 7 DS0s if it is the
BCCH RTF or 8 DS0s if it is a non-BCCH RTF.
The following are assumed:

BCCH RTF: None (0)
1 non-BCCH carrier: 64 k (3)
2 non-BCCH carriers: 32 k (2)
non-BCCH carrier: 16 k (1)
The GPRS/EGPRS timeslots are configured contiguously for performance. The packet data
timeslots are arranged as shown in the table. The BCCH RTF is mapped to non-CTUII DRI
and all the circuit-switched timeslots are allocated to it. The EGPRS and GPRS timeslots are
allocated to non-BCCH carriers as shown.

Carrier
TS0
TS1
TS2
TS3
TS4
TS5
TS6
TS7
BCCH 16 k (non-CTUII)
SD
Non-BCCH 64 k (CTUII)
RE
RE
RE
RE
RE
RE
RE
RE
Non-BCCH 32 k
(non-CTUII)
SG
SG
SG
SG
SG
SG
SG
SG
SG
SG
SG
SG
SG
Non-BCCH 32 k
(non-CTUII)
Non-BCCH 16 k
(non-CTUII)
68P02900W21-T
3-85
Jul 2010
Example 3
There are 8 switchable GPRS/EGPRS timeslots and 4 reserved GPRS/EGPRS timeslots in a 5
carrier cell.
backhaul for an RTF with pkt_radio_type set to 3 (64 k) is defaulted to 7 DS0s, if it is the BCCH

PGSM BCCH RTF: 64 k (3) and PBCCH enabled with sd_priority = 255
PGSM 2 non-BCCH carriers: 32 k (2) with sd_priority = 100
EGSM non-BCCH carriers: None (0) with sd_priority = 255
EGSM non-BCCH carrier: None (0) with sd_priority = 200
max_gprs_ts_carrier = 4
Assuming sd_load of 2 for all the carriers, preferred number of SDCCH being 64, PBCCH is
enabled (BSS level and cell level, and at the carrier level hr_allowed) the timeslot allocation is
shown in Table 3-17.

Carrier
TS0
TS1
TS2
TS3
TS4
TS5
TS6
TS7
RE
RE
RE
RE
Non-BCCH 32 k
(non-CTUII)
SD1
SD3
SG
SG
SG
SG
Non-BCCH 32 k
(non-CTUII)
SD2
SD4
SG
SG
SG
SG
Non-BCCH
(non-CTUII)
SD7
SD8
Non-BCCH
(non-CTUII)
SD5
SD6
BCCH 64 k (CTUII)
3-86
68P02900W21-T
Jul 2010
Example 4
a 5 carrier cell.
backhaul for an RTF with pkt_radio_type set to 3 (64 k) is defaulted to 7 DS0s, if it is the BCCH

BCCH RTF: None (0)
2 non-BCCH carriers: 64 k (3)
1 non-BCCH carrier: None (0)
Two CTUII and three non-CTUII
pccch_enabled = 1
In this example, the BCCH carrier is not configured to be used as the carrier for GPRS/EGPRS.
However, since there are two CTUIIs available, BCCH is mapped to CTUII even though is
not capable of supporting EGPRS. Additionally, the non-BCCH carrier configured with 64 k
backhaul is not used for packet data. PCCCH, however, is always allocated on the BCCH carrier.
Therefore, on the BCCH carrier, TS2 is allocated to PCCCH and TS3 to TS7 is allocated to
circuit-switch TCH only. The following table shows the timeslot allocation.

Carrier
TS0
TS1
TS2
TS3
TS4
TS5
TS6
TS7
BCCH (CTUII)
SD
Non-BCCH 64 k
(CTUII)
RE
RE
RE
RE
RE
RE
RE
RE
Non-BCCH 64 k
(non-CTUII)
Non-BCCH 32 k
(non-CTUII)
SG
SG
SG
SG
SG
SG
Non-BCCH
(non-CTUII)
68P02900W21-T
3-87
Jul 2010
Example 5
a 6 carrier cell.
backhaul for an RTF with pkt_radio_type set to 3 (64 k) is defaulted to 7 DS0s if it is the BCCH

BCCH RTF: 64 k (3)
3 non-BCCH carriers: None (0)
Three CTUII and three non-CTUII
Two (AMR or GSM) half-rate enabled carriers
The following table shows the timeslot allocation.

Carrier
TS0
TS1
TS2
TS3
TS4
TS5
TS6
TS7
BCCH 64 k (CTUII)
SD
RE
RE
RE
RE
RE
SE
SE
SE
SE
RE
RE
RE
RE
Non-BCCH 32 k(non-CTUII
SG
SG
SG
SG
SG
SG
SG
SG
Non-BCCH 16 k
(non-CTUII)
Non-BCCH 16 k (hr
enabled) (non-CTUII)
Non-BCCH 16 k (hr
enabled) (non-CTUII)
Example 6
There are 4 switchable EGPRS timeslots and 4 reserved EGPRS timeslots in a 4 carrier cell.
3-88
pkt_radio_type set to BCCH RTF 64 k (3)
3 CTUIIs
EGPRS unrestricted
68P02900W21-T
Jul 2010
Table 3-20 shows the timeslot allocation.

Carrier
TS0
TS1
TS2
TS3
TS4
TS5
TS6
TS7
BCCH 64 k (CTUII)
SD
SE
SE
RE
RE
RE
RE
SE
SE
SE
SE
RE
RE
RE
RE
SE
SE
Example 7
There are 10 switchable GPRS/EGPRS timeslots and 12 reserved GPRS/EGPRS timeslots in a
6 carrier cell. The following are assumed:
pkt_radio_type set to:

BCCH RTF: 64 k (3), rtf_ds0_count = 4
1 non-BCCH carrier: 64 k (3), rtf_ds0_count = 5
3 non-BCCH carriers None (0)
Three CTUII and three non-CTUII
GPRS 32 k and VersaTRAU (and therefore EGPRS) unrestricted
Two (AMR or GSM) half-rate enabled carriers

Carrier
TS0
TS1
TS2
TS3
TS4
TS5
TS6
TS7
BCCH 64 k (CTUII)
SD
RE
RE
RE
RE
RE
RE
SE
SE
RE
RE
RE
RE
RE
RE
SG
SG
SG
SG
SG
SG
SG
SG
Non-BCCH (non-CTUII)
Non-BCCH (hr enabled)

(non-CTUII)
Non-BCCH (hr enabled)

(non-CTUII)
68P02900W21-T
3-89
Jul 2010
Example 8
carrier cell.
pkt_radio_type set to:

BCCH RTF: 64 k (3), rtf_ds0_count = 6
1 non-BCCH carrier: 64 k (3), rtf_ds0_count = 6
CTUII (DDM)
EGPRS and VersaTRAU unrestricted
pccch_enabled = 1

Carrier
TS0
TS1
TS2
TS3
BCCH 64 k (CTUII DD Carrier A)
SD
Non-BCCH 64 k (CTUII DD
Carrier)
SG
SG
SG
TS4
TS5
TS6
TS7
RE
RE
RE
Non-BCCH 64 k are downgraded to 32 k. The maximum PDs configuration for two carriers of
DD CTU2 is 8 if Carrier A has EGPRS PDs. The requested 9 PDs cannot be all met.
Example 9
carrier cell. The CTU2D Asymmetric feature is unrestricted and ASYM mode is enabled for the
site on which these 4 carriers are configured. PBCCH is enabled and the preferred number of
SDCCH is 80. The sd_priority = 2 and sd_load = 3 for all the carriers.
3-90
1 CTU2D (CAP) and 1 CTU2 (PWR)
PGSM BCCH carrier: 64 k
1 PGSM non-BCCH carrier: 64 k with rtf_ds0_count = 6, mapped to CTU2D CAP_B
1 PGSM non-BCCH carrier: 64 k with rtf_ds0_count = 4, mapped to CTU2D PWR_A
1 PGSM non-BCCH carrier: 32 k
68P02900W21-T
Jul 2010
BSS timeslot allocation methods

Carrier
TS0
TS1
TS2
TS3
TS4
TS5
TS6
TS7
BCCH 64 k (CTU2D
CAP A)
PB
SD(4)
SD(5)
SD(6)
RE
RE
RE
Non-BCCH 64 k
(CTU2D CAP B)
SD(1)
SD(2)
SD(3)
SE
SE
SE
SE
Non-BCCH 64 k
(CTU2D PWR A)
SD(7)
SD(8)
SD(9)
SE
SE
SE
Non-BCCH 32 k
(CTU2D PWR B)
SD(10)
Example 10
There are 3 switchable GPRS/EGPRS channel and 1 reserved GPRS/EGPRS channel in a 3
carrier cell. The following are assumed.
Extended PDCH is configured in the cell.
PBCCH is disabled in the cell.
Number of carriers = 3.
1 BCCH 64 k carrier on CTU2D SD with rtf_ds0_count = 7, ext_timeslot = 2, ext_pdch = 0.
1 non-BCCH 32 k carrier on CTU2D SD with ext_timeslot = 0, ext_pdch =0.
1 non-BCCH 16 k carrier on CTU2D SD with ext_timeslot = 4, ext_pdch = 2.

Carrier
TS0
TS1
TS2
TS3
TS4
TS5
TS6
TS7
BCCH 64 k (CTU2D
SD)
Ext
SD
Ext
SE
SE
Non-BCCH 16 k
(CTU2D SD)
Ext
Ext
SG
Ext
RG
Ext
Non-BCCH 32 k
(CTU2D SD)

The BSS algorithm that is used to determine allocation of switchable timeslots gives priority
to circuit-switched calls. Consequently, if a switchable timeslot is being used by a packet
data mobile and a circuit-switched call is requested after all other circuit-switched timeslots
are used, the BSS takes the timeslot away from the packet data mobile and gives it to the
circuit-switched mobile, except when the switchable timeslot to be stolen is the last packet data
timeslot in the cell and the protect_last_ts element is enabled.
68P02900W21-T
3-91
Jul 2010
The switchable timeslot is re-allocated back to the packet data mobile when the circuit-switched
call ends. The number of reserved packet data timeslots can be changed by the operator to
guarantee a minimum number of dedicated packet data timeslots at all times. The operator
provisions the packet data timeslots on a carrier by selecting the number of timeslots that are
allocated as reserved and switchable, and not by specifically assigning timeslots on the carrier.
Motorola has implemented an idle circuit-switched parameter that enables the operator to
strongly favor circuit-switched calls from a network provisioning perspective. By setting the idle
parameter to 0, this capability is turned off.
When a circuit-switched call ends on a switchable packet data timeslot and the number of idle
circuit-switched timeslots is greater than a user-defined threshold, the BSS re-allocates the
borrowed timeslot for packet data service. When the number of idle timeslots is less than or
equal to a programmable threshold, the BSS does not allocate the timeslot back for packet data
service, even if it is the last available timeslot for packet data traffic.
Stolen timeslots
A switchable timeslot can be stolen at any time for use by a CS call, except when the switchable
timeslot to be stolen is the last packet data timeslot in the cell and the protect_last_ts element
is enabled.
When a switchable timeslot needs to be stolen for use by a CS call, the switchable timeslot to be
stolen is the last packet data timeslot in the cell, and the protect_last_ts element is enabled,
the timeslot is stolen only if there is no data transfer active or queued for the timeslot.
If there are any reserved packet data timeslots in the cell, the switchable timeslots are not
protected from being stolen for use by circuit-switched calls.
The BSS supports dynamic switching between switchable timeslots and circuit-switched
timeslots.
Switchable packet data timeslots are stolen starting with the lowest numbered GPRS timeslot
on a carrier to maintain continuous packet data timeslots.
The BSS selects which switchable packet data timeslot is stolen based on an algorithm that
takes into account the pkt_radio_type (GPRS/EGPRS capability), the associated RTF backhaul
(configured as rtf_ds0_count for EGPRS capable carriers if VersaTRAU is unrestricted or
statically computed in other cases depending on the pkt_radio_type) and the number of
switchable or reserved timeslots already on the carrier. A rank order based on the backhaul
to PDTCH ratio is established at the time of the initial air timeslot allocation. This rank order
is also used at the time of allocating the reserved and switchable timeslots in the cell. The
switchable timeslots are the ones that result in the least degradation in the backhaul to PDTCH
ratio for the cell when they get stolen for voice traffic.
For the cell with extended PDCH, when the MS is in the normal range, the extended PDCH can
be stolen only if there is no normal PDCH available. When the MS is in the extended range, only
the extended PDCH can be stolen.
When (AMR or GSM) half rate is enabled on one or more (RTFs assigned to) carriers in a cell and
some number of timeslots are reserved for half rate usage (hr_res_ts), then the BSS attempts
to ensure that the last timeslots to be allocated within a cell are half rate capable. Therefore
switchable timeslots are allocated to full rate calls before the reserved half rate capable timeslots
(the only exception to this being when the only available resource able to support the full rate
request is the last GPRS/EGPRS timeslot, and the protect last ts functionality is enabled).
3-92
68P02900W21-T
Jul 2010
Recommendation for switchable timeslot usage
When the ITS feature is unrestricted and enabled and a voice call steals one EGPRS PD timeslot
on a DD CTU2 Carrier A, the corresponding blanked-out timeslot on Carrier B comes back into
service. If the stolen EGPRS timeslot on DD CTU2 comes back to PDCH, the corresponding
blanked-out timeslot on Carrier B is configured back to OOS. CTU2D PWR mode is treated the
same as the ITS mode whereby the stolen operation is identical.
Contiguous timeslots
Multislot mobile operation needs that contiguous timeslots are available. The BSS takes the
lowest numbered switchable timeslot in such a manner as to maintain contiguous GPRS/EGPRS
timeslots for multislot GPRS/EGPRS operation and at the same time maintain an optimum ratio
of PDTCH/available backhaul per carrier across the cell. The BSS attempts to allocate as many
timeslots as requested in multislot mode, and then backoff from that number as timeslots are
not available. For example, suppose that timeslots 3 and 4 are switchable, and timeslots 5, 6,
and 7 are GPRS/EGPRS reserved (refer to Figure 3-32). When the BSS needs to re-allocate a
switchable timeslot from GPRS/EGPRS mode to circuit-switched mode, the BSS assigns timeslot
3 before it assigns timeslot 4 for circuit-switched mode. Figure 3-32 provides timeslot allocation
with reserved and switchable timeslots.
Figure 3-32 Carrier with reserved and switchable GPRS/EGPRS timeslots
R
TS7
TS0
R: Reserved PDTCH.
S: Switchable PDTCH.
Blank: Circuit-switched use only timeslots.
ti-GSM-Carrier_with_reserved_and_switchable_GPRS_EGPRS_timeslots-00204-ai-sw
If the emergency call preemption feature is enabled, the BSS selects the air timeslot that carries
the emergency call from the following list (most preferable listed first):
Idle circuit-switched
Idle or in-service switchable GPRS/EGPRS timeslot (from lowest to highest)
In-service circuit-switched
Idle or in-service reserved GPRS/EGPRS timeslot (from lowest to highest)
For the cell with extended PDCH, when the MS is in the normal range, the extended PDCH can
be stolen for emergency call only if there is no normal PDCH available. When the MS is in the
extended range, only the extended PDCH can be stolen for emergency call.

The following recommendation is offered when using switchable timeslots. It is important to
determine the GOS objectives for circuit-switched traffic and QoS objectives for packet data
traffic before selecting the number of switchable timeslots to deploy.
68P02900W21-T
3-93
Jul 2010
During the circuit-switched busy hour, potentially all switchable timeslots are occasionally used
by the circuit-switched calls. The circuit-switched timeslot allocation mechanism continues to
assign switchable timeslots as circuit-switched timeslots as the circuit-switched packet data
continues to increase. Therefore, if there is a minimum capacity requirement for GPRS services,
the network planner should plan the carrier with enough reserved timeslots to handle the
expected packet data traffic. This ensures that there is a minimum guaranteed network capacity
for the data traffic during the circuit-switched busy hour.
During the non-busy hours, the switchable timeslots are considered as available for use by the
packet data network. Therefore, in the circuit-switched off busy hours, potentially all switchable
timeslots could be available for the packet data network traffic. The BSS call statistics should
be inspected to determine the actual use of the switchable timeslots by the circuit-switched
services.
The circuit-switched busy hour and the packet data busy hour should be monitored to see if
they overlap when switchable timeslots are in use. If the busy hours overlap, an adjustment is
made to the number of reserved timeslots allocated to the packet data portion of the network
to guarantee a minimum packet data quality of service (QoS) as measured by packet data
throughput and delay. Furthermore, one or more circuit-switched carriers require to be added
to the cell being planned or replanned so that the switchable timeslots are not required to offer
the desired circuit-switched grade of service.
Assume that switchable timeslots are occasionally unavailable for packet data traffic during
the circuit-switched portion of the network busy hour. Provision enough reserved timeslots for
packet data traffic during the circuit-switched busy hour to meet the desired minimum packet
data QoS objectives, as measured by packet data throughput.
When CS and PS busy hour coincide, it is recommended that RES TS are configured to
be sufficient to service the mean PS load, particularly if QoS is enabled, since CS traffic
automatically preempts any PS traffic on SW TS. In these networks, the difference between
the mean and peak traffic (as evidenced by the mean_load_factor parameter), can then be
serviced by SW TS. Any TS configured as RES TS reduces the CS call capacity. More flexibility
is envisaged with QoS disabled and if the operator does not have a strong commitment (for
example, due to pricing plans) to maintain a certain level of service for PS data.
If the CS and PS busy hour do not coincide, then the number of RES TS configured depends
on the degree of overlap of the CS and PS load. In general, the rule is where there is more
overlap than more RES TS is required. If there is no overlap whatsoever, that is, most TSs
are assumed to be available to PS users during the PS busy hour, then a majority SW TS
configuration is acceptable.
For example, if 8 PDCHs are required for mean_load_traffic, and it is assumed
mean_load_factor is 200%, peak_load_traffic needs 16 PDCHs.
If overlap = 100% (CS and PS busy hour coincide), then 8 RS and 8 SW PDCHs are required.
If overlap = 0 (CS and PS busy hour totally do not coincide), then 4 RS (recommended minimum
configuration for a larger GPRS cell) and 12 SW are required.
If overlap = 50% (CS and PS busy hour partly coincide), then 4 - 8 RS and 12 - 8 SW are
required, the detailed value is decided according to statistics.
The TCH packet burst traffic feature supports allocation of additional switchable PDTCH from
idle TCH resource for packet traffic use only when the GPRS is congested at the cell level. This
benefits the handling of the packet burst traffic with low voice traffic load. This feature is
available only for the EDGE enabled cell (at least one 64 k PDTCH should be available in the
cell). The number of additional switchable PDTCHs are calculated based on the EDGE carrier
configuration.
3-94
68P02900W21-T
Jul 2010
Timeslot allocation process on carriers with GPRS traffic
Timeslot allocation process on carriers with GPRS traffic

The following procedure helps in determining how to allocate GPRS/EGPRS timeslots.
Procedure 3-1 Determining the allocation of GPRS/EGPRS timeslots
Estimate reserved timeslot requirement:

Determine the number of reserved GPRS/EGPRS timeslots are required on
a per cell basis to satisfy a packet data throughput QoS. The use of PBCCH
in a cell needs at least one reserved GPRS/EGPRS timeslot in that cell. The
GPRS/EGPRS reserved timeslots should equal the sum of the active and
standby timeslots that are allocated to a carrier.
Allocate switchable timeslots:

Determine the number of reserved GPRS/EGPRS timeslots are required on
a per cell basis. If the traffic is staggered in time, the use of switchable
timeslots can potentially offer increased capacity to both the GPRS/EGPRS
and circuit-switched traffic.
Add an extra circuit-switched carrier:

If there is a requirement to use some timeslots on the carrier with only
GPRS/EGPRS timeslots to satisfy the circuit-switched GOS objectives and the
timeslot requirement overlaps with the number of reserved GPRS/EGPRS
timeslots, consider adding another circuit-switched carrier to the cell.
Monitor network statistics:

After deploying the GPRS/EGPRS timeslots on the cell, review the collected
network statistics on a continuous basis to determine whether the
reserved GPRS/EGPRS timeslots, switchable GPRS/EGPRS timeslots, and
circuit-switched timeslots are truly serving the GOS and QoS objectives.
As previously discussed, the use of switchable timeslots can offer network
capacity advantages to both circuit-switched traffic and packet data traffic as
long as the demand for these timeslots is staggered in time.
68P02900W21-T
3-95
Jul 2010
Influential factors in GPRS/EGPRS cell planning and

deployment
The planning and dimensioning of a system containing packet data users is not as
straightforward as a system populated with only circuit-switched users. Sophisticated tools are
required to properly model the behavior of packet data users and dimension the required
bandwidth for a given service mix. In GSM, the issues are further complicated when EGPRS is
introduced in an existing GSM network which also supports GPRS.
A generic planning and dimensioning process is shown in Figure 3-33. The main objectives
are to minimize the number of sites and timeslots (spectrum) to support a given packet data
users load at an acceptable QoS without compromising the QoS of voice users. Acceptable
QoS for the packet data users with best effort type service is qualified by the bitrate or delay
experienced. This should be at least like those experienced while using the normal wired line
analog modems. The QoS feature allows the system to differentiate between subscribers based
on the QoS level subscribed to or negotiated by the system. QoS2 can support RT streaming.
It occupies more PDCHs.
Figure 3-33 Generic planning and dimensioning process
Number of subscribers
(GPRS/EGPRS split)
Area to cover coverage
requirements
RF Information
Traffic Profile and Service mix
QoS requirements
Bandwidth available
Network configurations
RLC/MAC overheads
Input parameters
Traffic characterisation
RF cell planning
BTS dimensioning
TS dimensioning
BSS dimensioning
Interface dimensioning
Planning tools
Cell sizes
Number of cells
TS requirements
BSS requirements
Interface requirements
Output parameters
ti-GSM-Generic_planning_and_dimensioning_process-00208-ai-sw
3-96
68P02900W21-T
Jul 2010
At a higher level, the cell planning and deployment can be broken down into two activities, which
become inter-related depending on the traffic volumes supported and bandwidth available.
These are cell coverage and cell dimensioning. In addition, there are some deployment rules
that are applied if there is sufficient flexibility in the choice of carrier and segregation of
timeslots, this depends on the network configuration. Issues and influential factors that should
be consider in carrying out the process shown are qualified.
Network configuration
Network configurations in which packet data (GPRS or EGPRS) can be introduced include:
Existing GSM network with GPRS already deployed.
Existing GSM network without GPRS.
Rolling out a new GSM network with or without GPRS.
A new GSM-based packet data system only.
Of these, the first configuration is the most likely deployment and the most challenging one. The
second one dictates mass GPRS and/or EGPRS handset deployment to justify its deployment.
The last two configurations are less of concern as they can be fine-tuned to provide adequate
coverage and grade of service. So, only the first configuration is considered.
RF cell planning (cell coverage)

The degree of coverage per GPRS and EGPRS coding scheme varies depending on several
factors including:
Spectrum availability.
Re-use patterns: hopping or non-hopping.
Environment: As the radio conditions change the subsequent C/I (C/N) requirements at a
given BLER also change.
BTS power amplifier capability and how it is set for GMSK and 8-PSK modes.
Cell sizes and cell border design criteria.
BSS algorithms (for example, LA).
EGPRS can be introduced in an existing GSM network with full EGPRS coverage. The following
factors are to be considered:
When the QoS feature is not enabled, the system employs the best effort packet data
services (no high QoS requirements are supported) with RLC acknowledge mode (ARQ).
The choice of operating BLER point is flexible within a certain range. In Motorolas
implementation, acceptable BLER operating point is embedded in the LA algorithms for
GPRS and EGPRS.
When the QoS feature is enabled, the BSS is able to assign an MTBR per PFC. This
allows the system to reserve throughput at the Local Timeslot Zone (Cell Level) and PRP
(board level).
When QoS2 feature is enabled, the BSS is able to support real-time service and enforce
MBR for a PFC. It provides a more optimistic coding scheme for admission.
68P02900W21-T
3-97
Jul 2010
For the cell with extended PDCH, when the QoS feature is enabled, the MS in the extended
range is always admitted with MTBR = 0.
CS1 and MCS-1 have been designed such that they match the voice coverage footprint. In
addition, due to IR in EGPRS, higher operating BLERs can be tolerated.
The higher the operating BLER the higher the coverage per GPRS/EGPRS coding scheme.
However, the operating BLER cannot be excessive since it has undesirable consequences
on system capacity and as such impacts the number of users that can be supported. In
Motorolas implementation, the LA algorithm attempts to maximize the throughput while
keeping implicitly the BLER operating regions within an acceptable bound in order not to
degrade the overall system performance.
The PA output power capability does not impact the EGPRS availability at cell borders
since power difference in HPM applies only to 8-PSK modulated coding schemes. This,
however, leads to less coverage (lower C/I or C/N) for higher code rates and impacts
the system capacity.
Frequency re-planning is required not so much to guarantee GPRS/EGPRS coverage but

more to eliminate possible coverage degradation for voice users. In a conventional GSM
voice network, the frequency planning of the traffic carriers are based on assuming certain
activity factors (DTX). When GPRS/EGPRS are introduced, the level of interference goes up
because of the following factors:
Higher activity: This depends on how the timeslot dimensioning is carried out
to account for packet data users. If timeslots are driven hard, then the level of
activity can be higher than that assumed for the voice only system. Also due to
behavior of packet data users being different, data flow control throughout the
network, multiplexing of users on the same timeslot, the activity profile are different.
Maintaining the same quality of service for the voice users means loading due to
packet data users needs scaling.
8-PSK signal peak to average ratio (PAR): due to 8-PSK envelop variation, the GMSK
symbols are occasionally hit with higher interference than usual when average
power of GMSK and 8-PSK signals are set to be the same. However, the level of
degradation should be considered within the context of the likely degradation that
may encounter otherwise as a result of having a lower average power in the 8-PSK
mode (thus reducing the impact of PAR). It is envisaged that the impact of lower
average power prevails the impact of PAR, and the average powers in GMSK and
8-PSK modes should be set equal.
Cell/timeslot dimensioning
The following factors influence cell/TS dimensioning since they impact throughput per TS as
well as the apparent throughput seen by a user, that is, pipe size:
3-98
Types of services, applications, and volume of data that are to be supported.
QoS required (user experience).
Number of users multiplexed on the same timeslot.
Multiplexing of GPRS and EGPRS users on the same timeslot.
Signaling overhead (control channels).
68P02900W21-T
Jul 2010
RLC/MAC protocol parameters setting.
Multi-slot operation.
QoS feature enable or disabled.
QoS2 feature, Streaming service is enabled or disabled. Enforce MBR is enabled or

disabled.
Cell selection and re-selection.
Hardware limitations, for example, number of timeslots supported per cell.
Re-use pattern: BCCH carrier, FH carrier.
Of the influences listed, the last two can be easily dealt with while the remaining ones need
detailed investigation, through simulation, to fully quantify their impacts. The following shed
light on some of the issues that are encountered:
If QoS is enabled, the number of PDTCHs required to support the MTBR specified is
different than when QoS is disabled. The BSS treats all mobiles equally when scheduling
the air interface in a QoS disabled environment.
If QoS2 feature is enabled, PDCHs required to support real-time service are more than
QoS2 disabled. BSS provide more bandwidth and higher priority for real-time service to
ensure that transfer delay is met.
Volume of data has varying impacts on system capacity. Short messages do not benefit
from higher code rates for those users in good radio conditions since LA process needs
time to converge to higher code rates. Moreover, RLC protocols, such as TBF holding
time, degrade the capacity for short messages. As a general rule, the throughput seen
in practice is lower than the ideal throughput for short messages and is closer to the
ideal throughput for long messages.
Up to four users can be multiplexed on a timeslot. Depending on system loading the

apparent bit pipe seen by a user is subsequently reduced as in Figure 3-34. In addition, this
could impact the throughput per timeslot since the LA process suffers due to variation of
radio channel conditions between scheduling opportunities. Thus, even for long messages
the ideal throughput is hardly achieved. In Motorolas implementation, there is an
intelligent load management algorithm in the PCU that attempts to balance the load across
resources allocated to the packet data users. This improves the overall system and QoS
performance of the operators depending on the bandwidth provisioned for the packet data
users. The QoS feature extends this general concept to provide per traffic class MTBR.
Multiplexing of GPRS and EGPRS users on the same timeslot is possible. The only impact
is a slight degradation in maximum achievable throughput for EGPRS users in the DL. This
is because the GMSK has to be used in the DL when the GPRS is to be scheduled in the UL.
This allows GPRS users to decode their block allocations sent on the DL (decoding the USF).
RLC protocols such as TBF holding time, poll period (to receive measurement reports
and Ack/Nack status of the transmitted blocks), RLC Ack/Nack window size, impacts the
throughput per timeslot and as such number of users that can be supported. If Extended
Uplink TBF feature is enabled, the TBF holding time is longer than that when the feature is
disabled.
If the PFC is in Ack mode, it is possible that the transfer delay for the LLC frame exceeds
the TD guarantee, but given that the TD guarantee is performed over a set of packets,
the impact is minimal. Alternately, if the PFC is in UnAck mode, there is no impact for
TD guarantee.
68P02900W21-T
3-99
Jul 2010
The operating BLER is an important parameter in optimizing the end-to-end throughput.

The higher the operating BLER the higher the coverage per GPRS/EGPRS coding scheme.
However, the operating BLER cannot be excessive since it has undesirable consequences
on system capacity and as such impacts the number of users that can be supported. For
example, although IR enables MCS-9 throughput to be like other coding schemes at
low C/I values, but the corresponding BLER is high. This from system viewpoint could
have detrimental effects due to the RLC protocol operation such as those in the last
bullet points. In Motorolas implementation, the LA algorithm attempts to maximize the
throughput while keeping implicitly the BLER operating regions within an acceptable
bound in order not to degrade the system performance.
If PCCCH is enabled, timeslot dimensioning for packet data traffic should consider the
blocks used for control signaling.
Figure 3-34 Multiplexing 4 TBFs on an air timeslot

4 TBFs/TS
User 1
User 2
User 3
80ms
User 4
20ms block
Time
ti-GSM-Multiplexing_4_TBFs_on_an_air_timeslot-00209-ai-sw
QoS dimensioning and QoS2 dimensioning

The two most significant factors that influence quality of a service are:
3-100
Delay
Throughput
68P02900W21-T
Jul 2010
In R99 and beyond, four traffic classes are defined to accommodate the need for different levels
of these factors for different applications. These are:
Conversational
Streaming
Interactive
Background
The BSS has internally defined additional traffic classes created by grouping similar PFC
characteristics. The internally defined traffic classes are:
Short-Term Non-Negotiated Traffic (STNNT)
Pre-admission PFC (PAP)
QoS Disabled
Currently the BSS does not support conversational service, it is downgraded to streaming
service when QoS2 is unrestricted and streaming_enabled is enabled. Requests to create
packet flows for conversational mode are treated as streaming. the BSS does not make any
guarantee regarding strict parameter for conversational traffic.
Traffic handling priority (THP)

Three priorities are defined in the standards for handling the traffic pertaining to the interactive
traffic class only. For the BSS, these priorities determine relative throughput assigned to a
particular Packet Flow Context (PFC). This is achieved by applying relative weights for each
priority, defined at a BSS level. These weights are user configurable.
In addition to the three standardized priorities, a fourth and a fifth THP are defined internally by
the BSS for the background and best effort traffic classes respectively. 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.
THP provides a mechanism to differentiate services among different PFCs that may or may not
belong to the same user.
Minimum Throughput Budget Requirement (MTBR)

A Minimum Throughput Budget Requirement (MTBR) is non-standards based BSS parameter
associated with each PFC. The MTBR of a given TBF is the sum of MTBRs of all the PFCs that
are multiplexed on that TBF. 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.
The operator is allowed to configure the minimum throughput budget requirement in both the
uplink and downlink directions separately.
For the cell with extended PDCH, when QoS feature is enabled, the MS in the extended range is
always admitted with MTBR = 0.
68P02900W21-T
3-101
Jul 2010
MTBR is measured as raw air throughput at the RLC/MAC layer without factoring in the Block
Error Rate (BLER) and unsolicited retransmissions. It is not a guaranteed bitrate. MTBR is
merely a budgeting guideline for the admission control mechanism. This helps to ensure that no
more users are admitted than the system can handle without compromising service.
MTBR is not achieved by a TBF with insufficient data to transmit. MTBR is set and regulated in
terms of throughput at the RLC/MAC layer. Throughputs at the application layer are lower than
the RLC/MAC throughput due to overhead consumed by the headers and retransmissions at the
intermediate layers and the application layer. Table 3-25 shows typical TCP throughput for each
10 kbps of RLC/MAC throughput at zero block error rate. The TCP throughput depends upon
the IP packet size and the LLC PDU size. Several typical values are shown in the following table.
Table 3-25 Typical TCP throughput against RLC/MAC throughput at zero block error
rate
RLC/MAC
throughput (kbps)
IP packet size (octets)
LLC PDU size (octets)
Typical TCP throughput

(kbps)
10.0
1500
1508
8.73
10.0
1500
600
8.33
10.0
576
604
8.28
Guaranteed Bit Rate (GBR)

The Guaranteed Bit Rate is defined in specification 3GPP TS 23.107 Quality of Service
(QoS) concept and architecture, Release 6 as a QoS attribute, maintained per streaming
and conversational PFC. The GBR is a negotiable parameter. The EGBR is the additional
throughput that is allocated to a user that is sufficient to service the GBR and the transfer delay
requirements of the streaming service. The TABR of a given TBF is the sum of MTBRs and
EGBRs of all the PFCs that are multiplexed on that TBF. The GBR in the uplink and downlink
directions have different values.
EGBR is defined as GBR/r, where r is a value between 0 and 1. To find the average downlink
EGBR the minimum value for r must first be found.
Average downlink Streaming EGBR is calculated as follows:
STR_EGBR = Average_GBR / r * (1+BLER)
BLER is typically 10%-15%. The value of r is dependent on the transfer delay parameter for the
streaming service. The minimum transfer delay that the PCU supports is user configurable. For
planning purposes this value of minimum transfer delay is used to determine the value of r.
For a given GBR, the value of r is dependent on the transfer delay parameter for the streaming
service.
To determine the value of r to use, first obtain the weighted average GBR per service in the
network. This is obtained by multiplying the frequency of the service in the network by the
GBR of the service.
3-102
68P02900W21-T
Jul 2010
N
AverageGBR = GBRi F Si/ST Ri
i=1
Where:
N
Is:
the number of streaming service types in the network.
GBRi
FSi
the GBR of streaming service i.

the percentage of streaming service i in service mix of subscribers in a given
PCU.
STRi
the percentage of total streaming service in service mix of subscribers in a

given PCU.
Looking up that Average GBR value in the tables, obtain the r value to use.
The following table provides the minimum value of r given the minimum transfer delay
supported in the PCU, in networks where the majority of streaming services have GBR of 15
kbps or lower, for example, PoC. If an application does not need a stringent transfer delay then
the r will be larger for that application, resulting in less EGBR required for a particular GBR.
The default minimum transfer delay value is set to 500 ms resulting in r = 0.62.
Table 3-26 for various transfer delays at GBR 15 kbps or less

Minimum Transfer
delay (ms)
Minimum Transfer
delay (ms)
Minimum Transfer
delay (ms)
250
0.42
1550
0.84
2850
0.9
300
0.48
1600
0.84
2900
0.9
350
0.52
1650
0.84
2950
0.9
400
0.56
1700
0.85
3000
0.91
450
0.59
1750
0.85
3050
0.91
500
0.62
1800
0.85
3100
0.91
550
0.64
1850
0.86
3150
0.91
600
0.66
1900
0.86
3200
0.91
650
0.68
1950
0.86
3250
0.91
700
0.7
2000
0.87
3300
0.91
750
0.71
2050
0.87
3350
0.91
800
0.73
2100
0.87
3400
0.91
850
0.74
2150
0.87
3450
0.92
900
0.75
2200
0.88
3500
0.92
950
0.76
2250
0.88
3550
0.92
1000
0.77
2300
0.88
3600
0.92
Continued
68P02900W21-T
3-103
Jul 2010
Table 3-26 for various transfer delays at GBR 15 kbps or less (Continued)
Minimum Transfer
delay (ms)
Minimum Transfer
delay (ms)
Minimum Transfer
delay (ms)
1050
0.78
2350
0.88
3650
0.92
1100
0.78
2400
0.89
3700
0.92
1150
0.79
2450
0.89
3750
0.92
1200
0.8
2500
0.89
3800
0.92
1250
0.8
2550
0.89
3850
0.92
1300
0.81
2600
0.89
3900
0.92
1350
0.82
2650
0.89
3950
0.93
1400
0.82
2700
0.9
4000
0.93
1450
0.83
2750
0.9
1500
0.83
2800
0.9
For networks where the majority of streaming services have GBR greater than 15 kbps, the
following two tables provide the minimum values of r for transfer delays of 500 ms and 250 ms.
In networks where the configured minimum transfer delay parameter is set to be greater than
500 ms then the table for the transfer delay of 500 ms should be used.
Here, the procedure is to first determine the GBR for which the majority of service in the
network operate, for example, video streaming 40 kbps, then looking up the GBR at the table,
obtain r. If the GBR value is not in the table, then the two closest GBR values should be
evaluated and the value resulting in the lower r value should be selected.
Table 3-27 for transfer delay = 500 ms at GBR greater than 15 kbps
GBR (bits/s)
GBR (bits/s)
GBR (bits/s)
15000
0.62
41000
0.8
67000
0.86
16000
0.63
42000
0.8
68000
0.86
17000
0.65
43000
0.8
69000
0.86
18000
0.66
44000
0.81
70000
0.86
19000
0.67
45000
0.81
71000
0.87
20000
0.68
46000
0.81
72000
0.87
21000
0.69
47000
0.82
73000
0.87
22000
0.69
48000
0.82
74000
0.87
23000
0.7
49000
0.82
75000
0.87
24000
0.71
50000
0.82
76000
0.87
25000
0.72
51000
0.83
77000
0.87
26000
0.72
52000
0.83
78000
0.88
27000
0.73
53000
0.83
79000
0.88
28000
0.74
54000
0.83
80000
0.88
Continued
3-104
68P02900W21-T
Jul 2010
Table 3-27 for transfer delay = 500 ms at GBR greater than 15 kbps (Continued)
GBR (bits/s)
GBR (bits/s)
GBR (bits/s)
29000
0.74
55000
0.84
81000
0.88
30000
0.75
56000
0.84
82000
0.88
31000
0.75
57000
0.84
83000
0.88
32000
0.76
58000
0.84
84000
0.88
33000
0.76
59000
0.85
85000
0.88
34000
0.77
60000
0.85
86000
0.89
35000
0.77
61000
0.85
87000
0.89
36000
0.78
62000
0.85
88000
0.89
37000
0.78
63000
0.85
89000
0.89
38000
0.79
64000
0.85
90000
0.89
39000
0.79
65000
0.86
40000
0.79
66000
0.86
Table 3-28 for transfer delay = 250 ms at GBR greater than 15 kbps
GBR (bits/s)
GBR (bits/s)
GBR (bits/s)
15000
0.42
41000
0.63
67000
0.72
16000
0.43
42000
0.63
68000
0.72
17000
0.45
43000
0.64
69000
0.72
18000
0.46
44000
0.64
70000
0.73
19000
0.47
45000
0.64
71000
0.73
20000
0.48
46000
0.65
72000
0.73
21000
0.49
47000
0.65
73000
0.73
22000
0.5
48000
0.66
74000
0.74
23000
0.51
49000
0.66
75000
0.74
24000
0.52
50000
0.66
76000
0.74
25000
0.52
51000
0.67
77000
0.74
26000
0.53
52000
0.67
78000
0.74
27000
0.54
53000
0.68
79000
0.75
28000
0.55
54000
0.68
80000
0.75
29000
0.56
55000
0.68
81000
0.75
30000
0.56
56000
0.69
82000
0.75
31000
0.57
57000
0.69
83000
0.76
32000
0.58
58000
0.69
84000
0.76
33000
0.58
59000
0.7
85000
0.76
Continued
68P02900W21-T
3-105
Jul 2010
Table 3-28 for transfer delay = 250 ms at GBR greater than 15 kbps (Continued)
GBR (bits/s)
GBR (bits/s)
GBR (bits/s)
34000
0.59
60000
0.7
86000
0.76
35000
0.59
61000
0.7
87000
0.76
36000
0.6
62000
0.7
88000
0.76
37000
0.61
630000
0.71
89000
0.77
38000
0.61
64000
0.71
90000
0.77
39000
0.62
65000
0.71
40000
0.62
66000
0.72
Admission control and retention (GSR8 QoS)

Allocation/Retention Priority (ARP) is defined in specification 3GPP TS 23.107 Quality of Service
(QoS) concept and architecture, version 4.6.0 Release 4 as a QoS attribute, maintained per PFC,
that provides prioritized allocation and retention. It is a subscription parameter, meaning
non-negotiable by the network entities. ARP ranges from 1 to 3 with 1 being the highest priority.
The BSS maps the ARP parameter and the traffic class into ARP Rank, as shown in Table 3-29.
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 3-29 ARP mobile selection (ARP Rank) order

ARP value
THP 1
THP 2
THP 3
Effort
Background
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.
For a complete description of allocating resources at the cell and PRP level, refer to Chapter 8
BSS planning for GPRS/EGPRS and QoS capacity and QoS2 impact on page 8-49.
ARP (QoS2)
The priority, pci and pvi attributes of the ARP IE are supported as part of the QoS Phase II
Feature. The BSS uses ARP to determine which PFCs have priority access to the system. The
BSS provides the user the same level of configurability using the attributes shown in the table
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).
3-106
68P02900W21-T
Jul 2010
Estimating the air interface traffic throughput
Table 3-30 BSS ARP configuration Parameters

Traffic Class
Precedence
Class
Streaming or
Conversational
Interactive or Best
Effort
Background
arp_streaming_1
arp_i_be_1
arp_bg_1
arp_streaming_2
arp_i_be_2
arp_bg_2
arp_streaming_3
arp_i_be_3
arp_bg_3
Admission Control determines which PFCs get access to the system and which PFCs get
preempted from the system to make room for higher ARP PFCs.
For a complete description of allocating resources at the cell and PRP level, refer to Chapter 8
BSS planning for GPRS/EGPRS and QoS capacity and QoS2 impact on page 8-49.
Estimating the air interface traffic throughput

The GPRS/EGPRS data throughput estimation process given in this chapter is based upon
the Poisson process for determining the GPRS/EGPRS mobile packet transfer arrivals to the
network and for determining the size of GPRS/EGPRS data packets generated or received by
the GPRS/EGPRS mobiles.
Some wired LAN/WAN traffic studies have shown that packet interarrival rates are not
exponentially distributed. Recent work argues that LAN traffic is much better modeled using
statistically self-similar processes instead of Poisson or Markovian processes. Self-similar
traffic pattern means that the interarrival rates appear the same, regardless of the timescale
at which it is viewed (in contrast to Poisson process, which tends to be smoothed around the
mean in a larger timescale). The exact nature of wireless GPRS traffic pattern is not known due
to lack of field data.
To minimize the negative impact of under-estimating the nature of the GPRS/EGPRS traffic,
it is proposed in this planning guide to adjust the mean GPRS/EGPRS cell loading value, by a
factor of 200% to account for the burstiness of GPRS/EGPRS traffic. When mean_load_factor
parameter is assumed 200%, it means the peak traffic is twice of mean traffic. This parameter
impacts the connection between RS PDCH and SW PDCH with different overlap scenarios.
Using this cell loading factor has the following advantages:
Cell overloading due to the bursty nature of GPRS/EGPRS traffic is minimized.
The variance in file transit delay over the Um to Gi interface is minimized such that the
delay can be considered a constant value for the purposes of calculating the time to
transfer a file of arbitrary size.
LAN/WAN wireline studies have also shown that even when statistically valid studies are
performed, the results come out different in follow-up studies. It turns out that web traffic
patterns are difficult to predict accurately and, therefore, it is highly recommended that the
network planner makes routine use of the GPRS/EGPRS network statistics.
The following sections describe dimensioning the system:
Select a cell plan on page 3-108
Estimating timeslot provisioning requirements on page 3-109
68P02900W21-T
3-107
Jul 2010
Select a cell plan
The results depend on the choices made in sections Select a cell plan on page 3-108 and
Estimating timeslot provisioning requirements on page 3-109 .
Select a cell plan

Select a cell plan to determine the expected BLER and percentage of time data is transferred at
the GPRS/EGPRS data rates. The cell plan that is selected for GPRS/EGPRS can be determined
by the plan currently in use for the GSM circuit-switched part of the network. However, it is
necessary to change an existing cell plan used for GSM circuit-switched to get better BLER
performance for the GPRS/EGPRS part of the network.
The PCU dynamically selects the best coding scheme to maximize the data throughput on
a per mobile basis. The coding scheme rate selection is performed periodically during the
temporary block flow (TBF). When planning frequency, it is required that there are no more than
48 frequencies in a cell with multiple carriers supporting GPRS/EGPRS timeslots.
To demonstrate the performance of various GPRS and EGPRS coding schemes, Table 3-31 shows
the percentage utilization of GPRS and EGPRS coding schemes at a fixed operating BLER
of 20% in a 4x3 BCCH (non-hopping) re-use pattern, and under a TU channel condition. If
non-regular patterns are used, a specific simulation study is required to match the particular
cell characteristics. The simulation process is outside the scope of this planning guide.
The MS in the extended range will have a lower coding scheme than in the normal range due
to the longer distance between the MS and BTS. For the cell with extended PDCH, the lower
coding scheme will have a higher utilization percentage value than the corresponding typical
utilization percentage value in the following table.
NOTE
When the QoS feature is enabled, the timeslot zone and PRP board level headroom
compensate for BLER.
Table 3-31 Percentage of code utilization in a 4x3 non-hopping re-use pattern at

20% BLER
Coding scheme
% of code utilization
CS1
10.0
CS2
22.5
CS3
12.5
CS4
5.0
MCS-1
5.0
Continued
3-108
68P02900W21-T
Jul 2010
Estimating timeslot provisioning requirements
Table 3-31 Percentage of code utilization in a 4x3 non-hopping re-use pattern at

20% BLER (Continued)
Coding scheme
% of code utilization
MCS-2
4.0
MCS-3
16.5
MCS-4
0.5
MCS-5
10.5
MCS-6
7.5
MCS-7
2.5
MCS-8
1.5
MCS-9
2.0

Here, the number of GPRS/EGPRS timeslots that require to be provisioned on a per cell basis is
determined. Timeslot provisioning is based on the expected per cell mean GPRS/EGPRS traffic
load, as measured in kbps. The packet data traffic load includes all SMS traffic routed through
the GSN. The SMS traffic is handled by the GPRS/EGPRS infrastructure in the same manner
as all other GPRS traffic originating from the PDN. The cell BLER and CS rate characteristics
selected, provide the required information for evaluating the following equation (totally
segregated EGPRS and GPRS timeslots):
M ean traf f ic load GP RS M ean load f actor
T S Data Rate GP RS
N o P DT CH T S = Roundup
M ean traf f ic load EGP RS M ean load f actor +
T S Data Rate EGP RS

68P02900W21-T
3-109
Jul 2010
NOTE
The equation is based on the DL traffic load and it is assumed that the DL
provisioning would be sufficient to handle UL traffic, without additional
provisioning.
The Mean_load_factor of 200% has been applied to the traffic load for systems
without the QoS feature enabled to account for any surges in the data traffic
and to carry packet switched signaling traffic. For example, assuming a traffic
load with normal distribution, given a mean traffic load of M, the 99th-percentile
peak traffic load, P, could be calculated as P = M + 3*M. The Mean_load_factor
for networks with that traffic distribution is then P/M*100%. For systems with
the QoS feature enabled the Mean_load_factor can be used to take into account
when multiple QoS enabled mobiles are in a cell at the same instance. Traffic
class, GBR and MTBR mix, relative THP, mobiles multi-slot capability, local
timeslot zone (cell level), and PRP board level headroom are considered in the
Mean_load_factor. Higher the Traffic Class, the MTBR required and the relative
THP weight would be higher which has a direct effect on Mean_load_factor. If
there are more numbers of higher multi-slot capable mobiles in the traffic the
Mean_load_factor is further increased. If more headroom is reserved for local
timeslot zone/PRP board level the number of PDCH provisioned should be more
to meet the QoS requirements in the cell. With QoS enabled headroom of 16.7%
is reserved for local timeslot zone/PRP board level. Allocating more PDTCHs has
the effect that QoS mobiles are not downgraded during peak usage at a cell.
For systems without the QoS feature enabled, Mean_traffic_load for each cell can be calculated
using the following formulae:
Avg sessions per sub Data per sub per session GP RS sub per cell
3600
Avg sessions per sub Data per sub per session EGP RS sub per cell
M ean traf f ic load EGP RS =
3600
M ean traf f ic load GP RS =
For systems with the QoS feature enabled, Mean_traffic_load for each cell can be calculated
using the following formulae:
M ean traf f ic load GP RS = (ST R EGBR %subs ST R + I1 M T BR %subsI1)

+ (I2 M T BR %subs I2 + I3 M T BR %subs I3 + BG M T BR %subs BG)
+ (BE M T BR %subs BE) GP RS subs per cell/3600
M ean traf f ic load EGP RS = (ST R EGBR %subs ST R + I1 M T BR % subsI1)

+ (I2 M T BR %subs I2 + I3 M T BR %subs I3 + BG M T BR %subs BG)
+ (BE M T BR %subs BE) EGP RS subs per cell/3600
3-110
68P02900W21-T
Jul 2010
NOTE
The unit for Data_per_sub_per_session is kbyte/hr.
For systems without the QoS feature enabled:
T S Data Rate GP RS =
T S Data Rate EGP RS =
4
1
CSi %Codeutilization CSi U serData Rate (1 BLER)
100
i=1
4
1
M CSi %Codeutilization M CSi U serData Rate (1 BLER)
100
i=1
For systems with the QoS feature enabled:
1
(SU M f rom CSI to egprs init cs (CS Codeutilization CS U serData rate ))
100
+SU M f rom egprs init cs to max egprs cs (CS Codeutilization CS U serData Rate f or gprs init cs )
T S Data Rate GP RS =
1
(SU M f rom M CSI to egprs init cs (CS Codeutilization CS U serData rate ))
100
+SU M f rom egprs init cs to max egprs cs (CS Codeutilization CS U serData Rate f or gprs init cs )
T S Data Rate EGP RS =
For systems with the QoS2 feature enabled, default coding scheme is CS2 and MCS3 (refer
to GPRS/EGPRS data rates on page 3-118).
NOTE
(M)CS_USAGE is the percentage of usage of (E)GPRS coding schemes.
68P02900W21-T
3-111
Jul 2010
Number of timeslots
The number of PDTCH timeslots calculated in the section Estimating timeslot provisioning
requirements on page 3-109, denotes the number of timeslots that need to be provisioned on the
cell to carry the mean traffic load on the cell.
It is important to differentiate between the required number of timeslots processed at any
instance in time and the total provisioned timeslots because it directly affects the provisioning
of the communication links and the PCU hardware. The active timeslots are timeslots that are
simultaneously carrying data being processed by the PRP on the PCU at any instance in time. It
is possible, however, to transfer packet switched data on each of the 1080 timeslots of a PCU
simultaneously (assuming that all 9 PRPs are configured), The PCU rapidly multiplex all the
timeslots with a maximum of 270 timeslots at any instance in time. For example, if there are
MSs on each of 1080 timeslots provisioned on the air interface, the PCU processes timeslots in 4
sets of 270 timeslots, with switching between sets occurring every block period.
The use of timeslots processed at any instance and total provisioned timeslots enables several
cells to share the PCU resource. While one cell is experiencing a high load condition, using
all eight packet data timeslots for instance, another cell operating its mean load averages
out the packet data traffic load at the PCU.
If the feature Support the usage of idle TCH for the packet burst traffic is used, idle
congested in the cell. These additional channels will be configured as switchable PDTCH which
share the PCU resource in GPRS congestion status, but will be configured as TCH resource
when GPRS congestion is relieved. If this feature is enabled, the PCU processing capability
should be planned considering these additional timeslots may be processed during GPRS
congestion status.
The E1s between the BTS and BSC must be provisioned to handle the number of timeslots
calculated because all of the timeslots can become active under high load conditions.
Timeslot refinement with Qos/QoS2 enabled

The number of PDTCHs determined for support of Qos/QoS2 should be compared to the
examples given. Refer to the examples to determine a refined number of PDTCHs to support
Qos/QoS2 with a given set of configuration parameters.
Table 3-32 MTBR Mix

MTBR Mix
3-112
Qos Type
DL
UL
Streaming
16
I1
14
I2
10
I3
BG
BE
68P02900W21-T
Jul 2010
Table 3-33 MTBR Constant

MTBR Constant
Qos Type
DL
UL
Streaming
I1
I2
I3
BG
BE
Table 3-34 THP Weight Mix

THP Weight Mix
Streaming
40
I1
40
I2
40
I3
20
BG
20
BE
20
Table 3-35
THP Weight Constant

THP Weight Constant
Streaming
40
I1
40
I2
40
I3
40
BG
40
BE
40
Table 3-36 shows the QoS configuration examples.
Table 3-36 QoS Configuration Examples
THP
QOS PDTCHs
weight
No
QoS
QoS
NA
Constant
Mobile
Trau
Multi-slot
Type
class
Subscriber
Mix
MTBR
Number of PFCs admitted (Valid

for MTBR/THP mix only)
Subscriber
allowed
on
carrier
Strea
ming
I1
I2
I3
BG
BE
16/32
No
MTBR
NA
18
64
3DL/1UL
Mix
14
Continued
68P02900W21-T
3-113
Jul 2010
Table 3-36 QoS Configuration Examples (Continued)
THP
QOS PDTCHs
weight
QoS
Constant
Mobile
Trau
Multi-slot
Type
class
4
64
Subscriber
Mix
MTBR
3DL/1UL
Mix
Number of PFCs admitted (Valid

for MTBR/THP mix only)
Subscriber
allowed
on
carrier
Strea
ming
I1
I2
I3
BG
BE
QoS
Constant
16/32
3DL/1UL
Mix
QoS
Constant
16/32
3DL/1UL
Mix
QoS
Constant
16/32
3DL/1UL
Mix
QoS
Constant
10
16/32
4DL/1UL
Mix
QoS
Constant
16/32
3DL/1UL Constant
11
QoS
Constant
10
16/32
3DL/2UL Constant
12
QoS
Mix
10
16/32
4DL/1UL Constant
QoS
Mix
10
64
4DL/1UL Constant
QoS
16/32
3DL/1UL
Mix
10
QoS
Mix
10
16/32
4DL/1UL
Mix
QoS
Mix
10
64
4DL/1UL
Mix
10
QoS
Constant
10
16/32
4DL/1UL Constant
10
QoS
Constant
10
16/32
3DL/2UL Constant
12
QoS
Constant
16/32
3DL/2UL Constant
12
QoS2
Constant
10
16
4DL/1UL
Mix
QoS2
Constant
10
32
4DL/1UL
Mix
QoS2
Constant
10
64
4DL/1UL
Mix
Constant
Comparison: Number of Class 4 Mobiles in a Cell with 6 PDTCHs; TRAU = 16 k, all THP
weight = 40, MTBR = 2.
Table 3-37 and Table 3-38 show the impact of QoS on the number of PDTCHs required to
support a given traffic mix. The colored cells highlight the additional mobile being added for
the specified time period.
Table 3-37 QoS Disabled; Capacity: 18 users, DL Throughput per MS: 0.33 (6/18) TS
Mobiles
Link
MS per TS
33
33
33
DL
0.50
100
UL
33
33
33
33
33
33
DL
100
100
UL
33
33
33
333
83
83
DL
100
100
100
UL
1.00
1.33
Continued
3-114
68P02900W21-T
Jul 2010
Table 3-37 QoS Disabled; Capacity: 18 users, DL Throughput per MS: 0.33 (6/18)
TS (Continued)
Mobiles
Link
MS per TS
33
33
83
83
83
84
DL
1.67
100
100
100
100
UL
133
33
83
83
83
83
DL
100
100
100
100
100
UL
133
133
83
83
83
83
DL
100
200
100
100
100
UL
133
133
183
83
83
83
DL
100
200
100
100
100
200
UL
133
133
183
83
183
83
DL
100
200
100
100
200
200
UL
133
133
183
183
183
83
DL
100
200
100
200
200
200
UL
133
133
183
183
183
183
DL
100
200
100
200
200
300
UL
233
133
183
183
183
183
DL
200
200
100
200
200
300
UL
233
233
183
183
183
183
DL
200
300
100
200
200
300
UL
233
233
283
183
183
183
DL
200
300
200
200
200
300
UL
233
233
283
183
283
183
DL
200
300
200
200
300
300
UL
233
233
283
283
283
183
DL
200
300
200
300
300
300
UL
233
233
283
283
283
283
DL
200
300
200
300
300
400
UL
333
233
283
283
283
283
DL
300
300
200
300
300
400
UL
333
333
283
283
283
283
DL
300
400
200
300
300
400
UL
333
333
283
283
283
283
DL
300
400
200
300
300
400
UL
333
333
283
283
283
283
DL
300
400
200
300
300
400
UL
10
11
12
13
14
15
16
17
18
19
20
1.83
2.00
2.17
2.33
2.50
2.67
2.83
3.00
3.17
3.33
3.50
3.67
3.83
Continued
68P02900W21-T
3-115
Jul 2010
Table 3-37 QoS Disabled; Capacity: 18 users, DL Throughput per MS: 0.33 (6/18)
TS (Continued)
Mobiles
Link
21
333
333
283
283
283
283
DL
300
400
200
300
300
400
UL
333
333
283
283
283
283
DL
300
400
200
300
300
400
UL
333
333
283
283
283
283
DL
300
400
200
300
300
400
UL
22
23
MS per TS
Table 3-38 QoS Enabled; Capacity: 11 users, DL Throughput per MS: 0.54 (6/11) TS
Mobiles
Link
MS per TS
33
33
33
DL
0.50
100
UL
33
33
33
33
33
33
DL
100
100
UL
33
33
67
67
67
33
DL
100
100
100
UL
83
83
67
67
67
333
DL
100
100
100
UL
83
83
67
67
117
83
DL
100
100
100
100
100
UL
83
117
100
100
117
83
DL
100
100
100
100
100
100
UL
83
117
150
150
117
83
DL
100
100
100
200
100
200
UL
83
117
150
150
167
133
DL
100
100
100
200
100
200
UL
133
167
150
150
167
133
DL
100
200
100
200
100
200
UL
133
167
150
150
167
233
DL
100
200
100
200
100
300
UL
233
167
150
150
167
233
DL
200
200
100
200
100
300
UL
233
167
150
150
167
233
DL
200
200
100
200
100
300
UL
10
11
12
1.00
1.50
1.83
2.17
2.67
3.00
3.33
3.67
3.83
4.00
Continued
3-116
68P02900W21-T
Jul 2010
Configurable initial coding scheme
Table 3-38 QoS Enabled; Capacity: 11 users, DL Throughput per MS: 0.54 (6/11)
TS (Continued)
Mobiles
Link
13
233
167
150
150
167
233
DL
200
200
100
200
1200
300
UL
233
167
150
150
167
233
DL
200
200
100
200
100
300
UL
233
167
150
150
167
233
DL
200
300
100
200
100
300
UL
233
167
150
150
167
233
DL
200
200
100
200
100
300
UL
233
167
150
150
167
233
DL
200
200
100
200
100
300
UL
233
167
150
150
167
233
DL
200
200
100
100
100
300
UL
233
167
150
150
167
233
DL
200
200
100
200
100
300
UL
233
167
150
150
167
233
DL
200
200
100
200
100
300
UL
233
167
150
150
167
233
DL
200
200
100
200
100
300
UL
233
167
150
150
167
233
DL
200
200
100
200
100
300
UL
233
167
150
150
167
233
DL
200
200
100
200
100
300
UL
14
15
16
17
18
19
20
21
22
23
MS per TS
Configurable initial coding scheme

The operator is able to control the initial downlink coding scheme (using database parameters)
to improve throughput of cells in which it is known that all mobiles are capable of higher coding
schemes, such as microcells. CS2 is still used to start when the carrier or PDTCHs assigned for
the TBFs are not capable of the initial coding scheme CS3 or CS4 if they are set in the database.
The feature also applies to EGPRS, for examples, MCS-2 can be selected as the initial coding
scheme.
QoS2 has default value of CS-2 and MCS3. If the coding scheme configured is lower, the
budgeted throughput per TS is lower.
In CTU2D ASYM mode, Carrier Bs UL TS is always restricted to GMSK (CS 1 to CS 4, or MCS 1
to MCS 4). Therefore when the egprs_init_ul_cs is configured higher than MCS4 it is restricted
to MCS3 when admitting a new mobile on Carrier B.
68P02900W21-T
3-117
Jul 2010
GPRS/EGPRS data rates
For the cell with extended PDCH, lower initial coding scheme is configured as per the cell
coverage and radio condition, and not higher than default database value CS-2 and MCS3.
NOTE
The information provided is for reference only. If required, it is also used to

calculate timeslot data rates at each layer. These are theoretical calculated
values, based on the protocol overheads at each layer. They do not necessarily
represent the data rates that the system can support.
The final throughput at application layer is less than those quoted in the tables
due to various protocol overheads and the behavior of various layers in response
to packet data flow.
The following assumptions are made to arrive at the numbers:
Mean IP packet size of approximately 500 bytes.
LLC in unacknowledged mode. This implies that it is assumed there is no signaling

overhead to acknowledge LLC frames. In practice, the LLC acknowledged mode imposes
relatively significant overhead at RLC/MAC level due to additional signaling required
over the user data channel.
V42.bis data compression is disabled (if V42.bis is enabled, the data rate is highly variable
depending on data contents. This parameter is also configured in SGSN).
The behavior of TCP, for example, slow start, is not taken into consideration, that is, perfect
TCP response is assumed. In practice, this imposes additional overhead since the channel
is not fully utilized for certain portion of time.
Increased efficiencies gained from lowered overhead, as a result of using higher numbers
of timeslots, is not calculated for this analysis.
C/I for each coding scheme is sufficient to support error free transport, that is, BLER = 0.
H/C = Header compression.
TS = Timeslot.
3-118
68P02900W21-T
Jul 2010
The rates are calculated bottom to top as follows (refer Figure 3-35):
Physical layer: GSM data rates.
RLC/MAC: Error free data rate including RLC/MAC headers (see earlier description of
various coding schemes, user and header encoding procedures).
LLC: Error free user data rate excluding RLC/MAC header, that is, LLC broken into RLC
blocks (Figure 3-35).
SNDCP: Includes header associated with LLC (7 bytes + 4 bytes CRC, Figure 3-33).
IP user rate: Includes header associated with SNDCP (2 bytes, Figure 3-33).
TCP: includes header associated with IP (20 bytes, Figure 3-33). The header compression
is not applied to the first LLC IP frame.
App. user rate: Includes header associated with TCP (20 bytes, Figure 3-33).
For more than 1 timeslot, the overheads are applied only to one of the timeslots.
Figure 3-35
LLC PDU to TDMA bursts
LLC frame
LLC
layer
RLC block
Segment
Segment
Segment
RLC/MAC
layer
Header
RLC data
Tail
Radio link
layer
Convolutional encoding (dictates code rate), Puncturing and Interleaving
Burst 1
Burst 2
Burst 3
Burst 4
Transmission across the radio link

ti-GSM-LLC_PDU_to_TDMA_bursts-00211-ai-sw
68P02900W21-T
3-119
Jul 2010
Table 3-39 through Table 3-64 provide illustrations of the data rates by application at each
layer in the GPRS stack.
Table 3-39 GPRS downlink data rates (kbps) with TCP (CS1)
Protocol Stack
CS1 and TS = 1
CS1 and TS = 2
CS1 and TS = 3
CS1 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
7.73
7.91
15.73
15.93
23.73
23.93
31.73
31.93
TCP
7.83
7.92
15.83
15.93
23.83
23.93
31.83
31.93
IP user rate
7.93
15.93
23.93
31.93
SNDCP
7.94
15.94
23.94
31.94
LLC
8.00
16
24
32.9
20
18.4
27.6
36.8
33.86
67.72
101.58
135.44
RLC/MAC
Physical layer
Protocol Stack
CS2 and TS = 1
CS2 and TS = 2
CS2 and TS = 3
CS2 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
11.60
11.86
23.60
23.89
35.60
35.89
47.60
47.89
TCP
11.75
11.89
23.75
23.90
35.75
35.90
47.75
47.90
IP user rate
11.90
23.90
35.90
47.90
SNDCP
11.92
23.92
35.92
47.92
12
24
36
48
13.6
27.1
40.65
54.2
33.86
67.72
101.58
135.44
LLC
RLC/MAC
Physical layer
Protocol Stack
CS3 and TS = 2
CS3 and TS = 3
CS3 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user
rate
13.92
14.24
28.32
28.67
42.72
43.07
57.12
57.47
TCP
14.10
14.26
28.50
28.68
42.90
43.08
57.30
57.48
IP user rate
14.28
28.68
43.08
57.48
SNDCP
14.30
28.70
43.10
57.50
LLC
14.4
28.8
43.2
57.6
RLC/MAC
15.8
31.5
47.3
63.0
33.86
67.72
101.58
135.44
Physical layer
3-120
CS3 and TS = 1
68P02900W21-T
Jul 2010
Protocol Stack
CS4 and TS = 1
CS4 and TS = 2
CS4 and TS = 3
CS4 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
7.73
7.91
15.73
15.93
23.73
23.93
31.73
31.93
TCP
7.83
7.92
15.83
15.93
23.83
23.93
31.83
31.93
IP user rate
7.93
15.93
23.93
31.93
SNDCP
7.94
15.94
23.94
31.94
LLC
8.00
16
24
32
RLC/MAC
9.20
18.4
27.6
36.8
33.86
67.72
101.58
135.44
Physical layer
Table 3-43 GPRS downlink data rates (kbps) with UDP (CS1)
Protocol Stack
CS1 and TS = 1
CS1 and TS = 2
CS1 and TS = 3
CS1 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
7.79
7.92
15.79
15.93
23.79
23.93
31.79
31.93
UDP
7.83
7.92
15.83
15.93
23.83
23.93
31.83
31.93
IP user rate
7.93
15.93
23.93
31.93
SNDCP
7.94
15.94
23.94
31.94
LLC
8.00
16
24
32
RLC/MAC
9.20
18.4
27.6
36.8
33.86
67.72
101.58
135.44
Physical layer
Protocol Stack
CS2 and TS = 1
CS2 and TS = 2
CS2 and TS = 3
CS2 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
11.69
11.88
23.69
23.89
35.69
35.89
47.69
47.89
UDP
11.75
11.89
23.75
23.90
35.75
35.90
47.75
47.90
IP user rate
11.90
23.90
35.90
47.90
SNDCP
11.92
23.92
35.92
47.92
12
24
36
48
13.6
27.1
40.65
54.2
33.86
67.72
101.58
135.44
LLC
RLC/MAC
Physical layer
68P02900W21-T
3-121
Jul 2010
Protocol Stack
CS3 and TS = 1
CS3 and TS = 2
CS3 and TS = 3
CS3 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
14.03
14.25
28.43
28.67
42.83
43.07
57.23
57.47
UDP
14.10
14.26
28.50
28.68
42.90
43.08
57.30
57.48
IP user rate
14.28
28.68
43.08
57.48
SNDCP
14.30
28.70
43.10
57.50
LLC
14.4
28.8
43.2
57.6
RLC/MAC
15.8
31.5
47.3
63.0
33.86
67.72
101.58
135.44
Physical layer
Protocol Stack
CS4 and TS = 1
CS4 and TS = 2
CS4 and TS = 3
CS4 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
19.49
19.80
39.48
39.82
59.48
59.82
79.48
79.82
UDP
19.58
19.81
39.58
39.83
59.58
59.83
79.58
79.83
IP user rate
19.84
39.84
59.84
79.84
SNDCP
19.86
39.86
59.86
79.86
20
40
60
80
21.6
43.1
64.7
86.2
33.86
67.72
101.58
135.44
LLC
RLC/MAC
Physical layer
Table 3-47 EGPRS downlink data rates (kbps) with TCP (MCS1)
Protocol Stack
3-122
MCS1 and TS = 1
MCS1 and TS = 2
MCS1 and TS = 3
MCS1 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
8.51
8.70
17.31
17.52
26.11
26.32
34.91
35.12
TCP
8.62
8.72
17.42
17.52
26.22
26.32
35.02
35.12
IP user rate
8.73
17.53
26.33
35.13
SNDCP
8.74
17.54
26.34
35.14
LLC
8.80
17.60
26.40
35.20
RLC/MAC
10.55
21.10
31.65
42.20
Physical layer
33.86
67.72
101.58
135.44
68P02900W21-T
Jul 2010
Protocol Stack
MCS2 and TS = 1
MCS2 and TS = 2
MCS2 and TS = 3
MCS2 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
10.83
11.07
22.03
22.30
33.23
33.50
44.43
44.70
TCP
10.97
11.09
22.17
22.30
33.37
33.50
44.57
44.70
IP user rate
11.11
22.31
33.51
44.71
SNDCP
11.12
22.32
33.52
44.72
LLC
11.20
22.40
33.60
44.80
RLC/MAC
12.95
25.90
38.85
51.80
Physical layer
33.86
67.72
101.58
135.44
Protocol Stack
MCS3 and TS = 1
MCS3 and TS = 2
MCS3 and TS = 3
MCS3 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
14.31
14.63
29.11
29.46
43.91
44.26
58.70
59.06
TCP
14.49
14.66
29.29
29.47
44.09
44.27
58.89
59.07
IP user rate
14.68
29.48
44.28
59.08
SNDCP
1470
29.50
44.30
59.10
LLC
14.80
29.60
44.40
59.20
RLC/MAC
16.55
33.10
49.65
66.20
Physical layer
33.86
67.72
101.58
135.44
Protocol Stack
MCS4 and TS = 1
MCS4 and TS = 2
MCS4 and TS = 3
MCS4 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
17.02
17.40
34.61
35.04
52.21
52.64
69.81
70.24
TCP
17.23
17.43
34.83
35.05
52.43
52.65
70.03
70.25
IP user rate
17.46
35.06
52.66
70.26
SNDCP
17.48
35.08
52.68
70.28
LLC
17.60
35.20
52.80
70.40
RLC/MAC
19.35
38.70
58.05
77.40
Physical layer
33.86
67.72
101.58
135.44
68P02900W21-T
3-123
Jul 2010
Protocol Stack
MCS5 and TS = 1
MCS5 and TS = 2
MCS5 and TS = 3
MCS5 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
21.66
22.15
44.05
44.59
66.45
66.99
88.85
89.39
TCP
21.93
22.19
44.33
44.61
66.73
67.01
88.13
89.41
IP user rate
22.22
44.62
67.02
89.42
SNDCP
22.24
44.64
67.04
89.44
LLC
22.40
44.80
67.20
89.60
RLC/MAC
23.90
23.90
23.90
23.90
101.58
203.16
304.74
406.32
Physical layer
Protocol Stack
MCS6 and TS = 1
MCS6 and TS = 2
MCS6 and TS = 3
MCS6 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
28.62
29.26
58.21
58.93
87.81
88.53
117.41
118.13
TCP
28.99
29.32
58.58
58.94
88.18
88.54
117.78
118.14
IP user rate
29.36
58.96
88.56
118.16
SNDCP
29.39
58.99
88.59
118.19
LLC
29.60
59.20
88.80
118.40
RLC/MAC
31.10
62.20
93.30
124.40
101.58
203.16
304.74
406.32
Physical layer
Protocol Stack
MCS7 and TS = 1
MCS7 and TS = 2
MCS7 and TS = 3
MCS7 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
43.31
44.29
88.11
89.19
132.90
133.99
177.70
178.79
TCP
43.87
44.38
88.67
89.21
`
133.47
134.01
178.27
178.81
IP user rate
44.43
89.23
134.03
178.83
SNDCP
44.49
89.29
134.09
178.89
LLC
44.80
89.60
134.40
179.20
RLC/MAC
46.90
93.80
140.70
187.60
101.58
203.16
304.74
406.32
Physical layer
3-124
68P02900W21-T
Jul 2010
Protocol Stack
MCS8 and TS = 1
MCS8 and TS = 2
MCS8 and TS = 3
MCS8 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
52.60
53.78
106.99
108.30
161.38
162.70
215.78
217.10
TCP
53.27
53.88
107.67
108.33
162.07
162.73
216.47
217.13
IP user rate
53.95
108.35
162.75
217.15
SNDCP
54.02
108.42
162.82
217.22
LLC
54.40
108.80
163.20
217.60
RLC/MAC
56.50
113.00
169.50
226.00
101.58
203.16
304.74
406.32
Physical layer
Protocol Stack
MCS9 and TS = 1
MCS9 and TS = 2
MCS9 and TS = 3
MCS9 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
57.24
58.53
116.43
117.85
175.62
177.05
234.82
236.25
TCP
57.97
58.64
117.17
117.89
176.37
177.09
235.57
236.29
IP user rate
58.71
117.91
177.11
236.31
SNDCP
58.79
117.99
177.19
236.39
LLC
59.20
118.40
177.60
236.80
RLC/MAC
61.30
122.60
183.90
245.20
101.58
203.16
304.74
406.32
Physical layer
Table 3-56
EGPRS downlink data rates (kbps) with UDP (MCS1)
Protocol Stack
MCS1 and TS = 1
MCS1 and TS = 2
MCS1 and TS = 3
MCS1 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
8.57
8.71
17.37
17.52
26.17
26.32
34.97
35.12
UDP
8.62
8.72
17.42
17.52
26.22
26.32
35.02
35.12
IP user rate
8.73
17.53
26.33
35.13
SNDCP
8.74
17.54
26.34
35.14
LLC
8.80
17.60
26.40
35.20
RLC/MAC
10.55
21.10
31.65
42.20
Physical layer
33.86
67.72
101.58
135.44
68P02900W21-T
3-125
Jul 2010
Table 3-57
Protocol Stack
MCS2 and TS = 1
MCS2 and TS = 2
MCS2 and TS = 3
MCS2 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
10.91
11.09
22.11
22.30
33.31
33.50
44.51
44.70
UDP
10.97
11.09
22.17
22.30
33.37
33.50
44.57
44.70
IP user rate
11.11
22.31
33.51
44.71
SNDCP
11.12
22.32
33.52
44.72
LLC
11.20
22.40
33.60
44.80
RLC/MAC
12.95
25.90
38.85
51.80
Physical layer
33.86
67.72
101.58
135.44
Table 3-58
Protocol Stack
MCS3 and TS = 1
MCS3 and TS = 2
MCS3 and TS = 3
MCS3 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
14.42
14.65
29.22
29.47
44.02
44.27
58.82
59.07
UDP
14.49
14.66
29.29
29.47
44.09
44.27
58.89
59.07
IP user rate
14.68
29.48
44.28
59.08
SNDCP
14.70
29.50
44.30
59.10
LLC
14.80
29.60
44.40
59.20
RLC/MAC
16.55
33.10
49.65
66.20
Physical layer
33.86
67.72
101.58
135.44
Table 3-59
Protocol Stack
3-126
MCS4 and TS = 1
MCS4 and TS = 2
MCS4 and TS = 3
MCS4 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
17.15
17.42
34.75
35.04
52.34
52.64
69.94
70.24
UDP
17.23
17.43
34.83
35.05
52.43
52.65
70.03
70.25
IP user rate
17.46
35.06
52.66
70.26
SNDCP
17.48
35.08
52.68
70.28
LLC
17.60
35.20
52.80
70.40
RLC/MAC
19.35
38.70
58.05
77.40
Physical layer
33.86
67.72
101.58
135.44
68P02900W21-T
Jul 2010
Table 3-60
Protocol Stack
MCS5 and TS = 1
MCS5 and TS = 2
MCS5 and TS = 3
MCS5 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
21.82
22.17
44.22
44.60
66.62
67.00
89.02
89.40
UDP
21.93
22.19
44.33
44.61
66.73
67.01
88.13
89.41
IP user rate
22.22
44.62
67.02
89.42
SNDCP
22.24
44.64
67.04
89.44
LLC
22.40
44.80
67.20
89.60
RLC/MAC
23.90
23.90
23.90
23.90
101.58
203.16
304.74
406.32
Physical layer
Table 3-61
Protocol Stack
MCS6 and TS = 1
MCS6 and TS = 2
MCS6 and TS = 3
MCS6 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
28.84
29.30
58.44
58.94
88.03
88.54
117.63
118.14
UDP
28.99
29.32
58.58
58.94
88.18
88.54
117.78
118.14
IP user rate
29.36
58.96
88.56
118.16
SNDCP
29.39
58.99
88.59
118.19
LLC
29.60
59.20
88.80
118.40
RLC/MAC
31.10
62.20
93.30
124.40
101.58
203.16
304.74
406.32
Physical layer
Table 3-62
Protocol Stack
MCS7 and TS = 1
MCS7 and TS = 2
MCS7 and TS = 3
MCS7 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
43.65
44.35
88.44
89.20
133.24
134.00
178.04
178.80
UDP
43.87
44.38
88.67
89.21
133.47
134.01
178.27
178.81
IP user rate
44.43
89.23
134.03
178.83
SNDCP
44.49
89.29
134.09
178.89
LLC
44.80
89.60
134.40
179.20
RLC/MAC
46.90
93.80
140.70
187.60
101.58
203.16
304.74
406.32
Physical layer
68P02900W21-T
3-127
Jul 2010
Table 3-63
Protocol Stack
MCS8 and TS = 1
MCS8 and TS = 2
MCS8 and TS = 3
MCS8 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
53.00
53.85
107.39
108.32
161.79
162.72
216.19
217.12
UDP
53.27
53.88
107.67
108.33
162.07
162.73
216.47
217.13
IP user rate
53.95
108.35
162.75
217.15
SNDCP
54.02
108.42
162.82
217.22
LLC
54.40
108.80
163.20
217.60
RLC/MAC
56.50
113.00
169.50
226.00
101.58
203.16
304.74
406.32
Physical layer
Table 3-64
Protocol Stack
MCS9 and TS = 1
MCS9 and TS = 2
MCS9 and TS = 3
MCS9 and TS = 4
No H/C
H/C
No H/C
H/C
No H/C
H/C
No H/C
H/C
App. user rate
57.68
58.60
116.87
117.88
176.07
177.08
235.27
236.28
UDP
57.97
58.64
117.17
117.89
176.37
177.09
235.57
236.29
IP user rate
58.71
117.91
177.11
236.31
SNDCP
58.79
117.99
177.19
236.39
LLC
59.20
118.40
177.60
236.80
RLC/MAC
61.30
122.60
183.90
245.20
101.58
203.16
304.74
406.32
Physical layer
3-128
68P02900W21-T
Jul 2010
Chapter
4
AMR and GSM half-rate planning
This chapter provides an overview of the Adaptive Multi-Rate (AMR) and GSM half rate feature
and their operation within the Motorola system. The GSM half rate and the half rate portion of
AMR are similar. Hence, the information here covers both features.
The benefits of the features are outlined, and performance discussed. The manual gives an
understanding of how AMR and GSM half rate works and how they are configured. The various
parameters controlling AMR operation are discussed. However, not all of the commands and
parameters are shown in detail.
The topics described are as follows:
Introduction to AMR and GSM planning on page 4-2
Quality and capacity on page 4-5
Miscellaneous information on page 4-16
Half rate utilization on page 4-17
Hardware on page 4-26
68P02900W21-T
Jul 2010
4-1
Introduction to AMR and GSM planning
AMR basic operation

Existing GSM speech codecs operate at a fixed coding rate. Channel protection is also fixed.
AMR adapts the speech and channel coding rates according to the quality of the radio channel.
This gives better channel quality and better robustness to errors.
Capacity is enhanced by allocating half rate channels to some or all mobiles. To obtain the best
balance between quality and capacity, the system allocates a half rate (hr) or full rate (fr)
channel according to channel quality and the traffic load on the cell.
The control system is not fixed but can be tuned to meet particular needs. The three primary
levels of adaptation of the control system are:
Handovers between hr and fr channels according to traffic demands.
Variable partitioning between speech and channel coding bit rates to adapt to channel
conditions for best speech quality.
Optimization of channel and codec control algorithms to meet specific user needs and
network conditions.
This allows the codec to be applied in many ways, of which three important examples are:
fr only for maximum robustness to channel errors but no capacity advantage.
hr only for maximum capacity advantage.
Mixed hr/fr operation allowing a trade-off between quality and capacity.
GSM half rate basic operation

GSM half rate was introduced in phase 2 of the standards, and operates at a fixed coding rate.
Due to this early introduction into the standards, the penetration rate of half rate capable
mobiles is high. However, the speech quality is poor when compared to the half rate mode of
AMR (as well as all forms of full rate speech).
GSM half rate is used as a means to increase capacity within a cell. As with AMR half rate,
capacity is increased by either always preferring half rate (hr), or by allocating a half rate or
full rate (fr) channel according to channel quality and the traffic load on the cell. Handovers
between hr and fr channels vary according to traffic demands.
The best examples of applying the codec are:
4-2
hr only for maximum capacity advantage.
Mixed hr/fr operation allowing a trade-off between quality and capacity.
68P02900W21-T
Jul 2010
AMR and GSM half rate interaction
AMR and GSM half rate interaction

AMR and GSM half rate can co-exist in a cell. A carrier could have a mix of GSM half rate and
AMR (full rate and/or half rate) simultaneously. The parameters that govern half rate operation
have been made generic to facilitate that style of operation.
New hardware
New hardware has been developed to support the AMR and the GSM half rate features. This
equipment, with the supporting software and firmware, provides the capabilities necessary to
exploit the advantages of AMR and/or GSM half rate.
This equipment consists of the following:
Double Kiloport Switch (DSW2)
Double Kiloport Switch Extender (DSWX)
Generic DSP Processing board 2 (GDP2)
Remote Transcoder Unit 3 (shelf) (RXU3)
Base Station System Cabinet 3 (BSSC3)
AMR and GSM half rate is used without the benefit of any of the new hardware; although not as
efficiently (this is discussed later in the chapter).
NOTE
Without new hardware, AMR needs the use of GDPs configured as EGDP(s).
Influencing factors
There are many factors to be taken into account when configuring/operating a system in which
AMR and/or GSM half rate is present. These include the following:
AMR-capable handset penetration (see the first NOTE)
GSM half rate-capable handset penetration (see the second NOTE)
Transceiver capability
Carrier configuration
Use of reserved channels/cell congestion
68P02900W21-T
4-3
Jul 2010
Planning
NOTE
It is assumed that an AMR-capable handset or mobile includes both fr and hr

capability.
Most handsets or mobiles are GSM half rate capable.
Planning
The system operator must decide how the system should operate with regard to full and half
rate, and what combination of new and old equipment is to be utilized. Other decisions, such
as codec rates and backhaul, must also be made. Utilization of the half rate capability of AMR
and/or GSM half rate must also be made. Quality and capacity on page 4-5 describes the
benefits of the AMR codecs and how AMR Full Rate and AMR Half Rate compare to the existing
GSM codecs. The GSM Half Rate codec is compared to the other GSM codecs. Also discussed
are the benefits in coverage of AMR Full Rate. The capacity increases made possible with half
rate are discussed, with examples showing the potential gains under a variety of configurations
and (half rate) capable handset penetration.
The information in Quality and capacity on page 4-5 can be used to help determine how AMR
full rate and AMR/GSM half rate is utilized. As stated earlier, there are three primary methods
of AMR usage, two of which apply to GSM half rate:
AMR full rate only (AMR only): This has the advantage of providing better voice quality
under a broad range of channel conditions. This method is robust but provides no capacity
advantage per carrier. It is particularly suited to areas where adverse propagation
conditions prevail.
Forced half rate: This is used when capacity is paramount. Voice quality is sacrificed
to carry more calls per carrier. It is used in severely congested areas, or where voice
quality is not a concern.
A mix of full rate and half rate: Full rate is generally used until the cell becomes congested,
at which time half rate is employed. This configuration provides quality voice coverage
until congestion is reached. This capacity on-demand configuration is well suited for
environments with varying traffic patterns. The information contained in Half rate
utilization on page 4-17 can be used to help configure the system to maximum effectiveness
when half rate is used.
Miscellaneous information on page 4-16 provides information on emergency call handling

and circuit pooling. Hardware on page 4-26 contains a description of the new hardware and
what advantages it delivers.
4-4
68P02900W21-T
Jul 2010
Quality and capacity
Quality and capacity
Benefits of AMR
The ability of the AMR codec to change dynamically the allocation of source and channel coding
bits provides a high level of speech quality. The overall improvements are dependant upon
channel quality (C/I). As channel quality deteriorates, a codec with a higher level of error
protection (and a corresponding decrease in speech quality) is selected, leading to an increase
in sensitivity of the transceivers, thus providing optimum performance.
The half rate mode of AMR can be utilized to obtain a capacity gain on the air interface. This
can be tied to congestion at the cell level to provide capacity gains on an as needed basis.
With AMR operating in full rate mode, or in a mix of full rate and half rate where handovers
between the modes are permitted, a capacity gain can be realized because of the ability to
operate at a lower C/I threshold. This can result in potentially higher traffic loading. However,
the benefits of AMR do not extend to the signaling channels, or to the use of non-AMR codecs
and data services. Capacity gains of this type are dependent on other factors (for example,
propagation conditions) and are beyond the scope of this chapter.
Under high channel error conditions, an AMR FR codec mode, which has a low source-coding
rate and a high level of error protection, is selected. This allows good speech quality to be
maintained under conditions 6 dB worse than the corresponding level for EFR. This translates to
an improvement in terminal or BTS sensitivity, but is subject to the limit of robustness of the
signaling channels (presumed to be at least 2 dB, and possibly as high as 4 dB or 6 dB). This
can be exploited for range extension, or improved coverage in buildings. Range extension is
discussed further in AMR voice quality improvement and coverage on page 4-9 later in this
chapter.
AMR Full Rate and AMR Half Rate speech quality

Introduction
Here, the relative performance of the AMR Full Rate and Half Rate speech codecs is shown
for comparative purposes. Mean Opinion Scores (MOS) are subjective. Test conditions affect
MOS. However, the relative performance of the codecs to each other is reliable. The conditions
used in the tests are no background impairments, static channel conditions, and ideal frequency
hopping.
NOTE
The graphs in Figure 4-1 to Figure 4-4 and the accompanying information are
extracted from GSM 06.75 (v. 7.2.0), Performance Characterization of the GSM
Adaptive Multi-Rate (AMR) speech codec.
68P02900W21-T
4-5
Jul 2010
AMR Full Rate

In Figure 4-1, AMR FR speech quality (best AMR codec) is compared with EFR and performance
requirements under a range of channel conditions.
Figure 4-1 AMR FR/clean speech versus EFR versus performance requirements
MOS
5.0
4.0
3.0
2.0
Sel. Requirements
AMR-FR
EFR
Conditions
1.0
No Errors
C/I=16 dB
C/I=13 dB
C/I=10 dB
C/I= 7 dB
Sel. Requirements
4.01
4.01
4.01
AMR-FR
4.06
4.06
EFR
4.01
C/I= 4 dB
4.13
4.08
3.96
3.59
4.01
3.65
3.05
1.53
C/I= 1 dB
3.65
2.66
ti-GSM-AMR_FR_clean_speech_versus_EFR-00112-ai-sw
Figure 4-2 shows the individual codec modes for AMR FR/clean speech, as illustrated in
Figure 4-1.
4-6
68P02900W21-T
Jul 2010
Figure 4-2 AMR FR/clean speech codec modes

MOS
5.0
4.0
3.0
EFR
12.2
10.2
7.95
7.4
6.7
5.9
5.15
4.75
2.0
Conditions
1.0
No Errors
C/I=16 dB
C/I=13 dB
C/I=10 dB
C/I= 7 dB
C/I= 4 dB
4.01
3.65
3.05
1.53
C/I= 1 dB
EFR
4.01
12.2
4.01
4.13
3.93
3.44
1.46
10.2
4.06
3.96
4.05
3.80
2.04
7.95
3.91
4.01
4.08
3.96
3.26
1.43
7.4
3.83
3.94
3.98
3.84
3.11
1.39
6.7
3.77
3.80
3.86
3.29
1.87
5.9
3.72
3.69
3.59
2.20
5.15
3.50
3.58
3.44
2.43
4.75
3.50
3.52
3.43
2.66
4.06
ti-GSM-AMR_FR_clean_speech_codec_modes-00113-ai-sw
AMR half rate

Figure 4-3 and Figure 4-4 show performance curves for AMR HR speech quality compared to
EFR as well as GSM FR and HR under the same range of channel conditions as the AMR FR
comparison shown in Figure 4-1 and Figure 4-2.
68P02900W21-T
4-7
Jul 2010
Figure 4-3 AMR HR/clean speech versus EFR versus GSM FR versus GSM HR versus
performance requirements
MOS
5.0
4.0
3.0
Sel. Requirements
AMR-HR
2.0
EFR
FR
HR
Conditions
1.0
No Errors
C/I=19 dB
C/I=16 dB
3.99
3.99
3.99
C/I=10 dB
C/I= 7 dB
C/I= 4 dB
3.14
2.74
1.50
AMR-HR
4.11
4.04
3.96
3.72
3.38
3.10
2.00
EFR
4.21
4.21
3.74
3.34
1.58
FR
3.50
3.50
3.14
2.74
1.50
HR
3.35
3.24
2.80
1.92
Sel. Requirements
C/I=13 dB
ti-GSM-AMR_HR_EFR_GSM_FR_GSM_HR_versus_perform_reqnts-00114-ai-sw
4-8
68P02900W21-T
Jul 2010
AMR voice quality improvement and coverage
Figure 4-4 AMR HR/clean speech codec modes

MOS
5.0
4.0
3.0
EFR
7.95
7.4
6.7
5.9
5.15
4.75
FR
HR
2.0
1.0
Conditions
No Errors
C/I=19 dB
C/I=16 dB
C/I=13 dB
C/I=10 dB
C/I= 7 dB
C/I= 4 dB
4.21
3.74
3.74
1.58
EFR
4.21
7.95
4.11
4.04
3.96
3.37
2.53
1.60
7.4
3.93
3.93
3.95
3.52
2.74
1.78
6.7
3.94
3.90
3.53
3.10
2.22
1.21
5.9
3.68
3.82
3.72
3.19
2.57
1.33
5.15
3.70
3.60
3.60
3.38
2.85
1.84
4.75
3.59
3.46
3.42
3.30
3.10
2.00
3.14
2.74
1.50
3.24
2.80
1.92
FR
3.50
HR
3.35
3.50
ti-GSM-AMR HR_clean_speech_codec_modes-00115-ai-sw
AMR voice quality improvement and coverage

Analysis has shown that AMR FR under C/I = 13 dB provides the same quality of service (MOS
= 4) as GSM FR/EFR under C/I = 15 dB. AMR FR provides better overall voice quality than GSM
FR/EFR under comparable radio conditions. This can translate to an increase in coverage area.
68P02900W21-T
4-9
Jul 2010
Benefits of GSM half rate
A study has been done to quantify the potential coverage gains. The following assumptions
are used:
System is interference-limited (the impact of thermal noise is negligible compared with

the level of interference).
System is 100% loaded: all the available physical resources are used (this is the worst-case
assumption - coverage gains increase with less loading).
Path loss exponent assumed to be 3.76, and the shadowing lognormal standard deviation
is 10 dB.
Power control and any type of DTX are not used.
All terminals are AMR.
The results of the study are shown in Table 4-1.

The coverage reliability is expected to increase by 5 to 8 percentage points depending on the
frequency reuse patterns. The link budget improvement can potentially lead to an increase
in cell areas around 27%.
This type of increase in coverage applies to existing networks where site spacing can be
modified or new networks where it has to be selected. The majority of terminals are AMR.
Non-AMR terminal performance could be degraded under these conditions.
Table 4-1
AMR potential coverage gains
Frequency re-use
pattern
Coverage at
15 dB
Coverage at
13 dB
Gain in coverage
(increase in cell
radius)
Gain in
coverage area
1-3-3
44%
36%
8%
16.6%
3-1-3
57%
49%
8%
16.6%
3-3-9
81%
74%
7%
14.5%
4-1-4
70%
62%
8%
16.6%
4-3-12
92%
87%
5%
10.3%
7-1-7
88%
82%
6%
12.4%
7-3-21
98%
96%
2%
4%
NOTE
First digit = # cell sites, second digit = # sectors/cell and third digit = # carriers/cell.
Benefits of GSM half rate

GSM Half Rate offers enhanced capacity over the air interface, corresponding to the proportion
of mobiles within a coverage area that supports Half Rate. GSM half rate has a high penetration
level (of GSM HR capable mobiles) due to its early introduction into the standards. Due to these
large penetration levels, it is considered a viable option for high-density areas.
4-10
68P02900W21-T
Jul 2010
GSM Half Rate speech quality
The GSM Half Rate codec uses the VSELP (Vector-Sum Excited Linear Prediction) algorithm.
The VSELP algorithm is an analysis-by-synthesis coding technique and belongs to the class of
speech coding algorithms known as CELP (Code Excited Linear Prediction).
The benefits of GSM half rate are an increase in capacity at a cell without requiring additional
transceiver boards or carriers. The use of half rate can be tied to congestion at the cell level
to provide capacity gains on a needed basis.
GSM Half Rate speech quality

Figure 4-3 shows how GSM Half Rate compares with the EFR, FR, and AMR HR codecs. Mean
Opinion Scores (MOS) are subjective and can be affected by test conditions. However, the
relative performance of the codecs to each other is reliable. The conditions used in the tests are
no background impairments, static channel conditions, and ideal frequency hopping.
In conclusion, the GSM Half Rate codec voice quality performance is inferior to the other
codecs. This suggests a deployment strategy of using fr mode until capacity limitations force
calls to utilize hr mode, at which time some fr calls can also be moved to hr. An hr call is also
moved to a fr channel through an interference-based handover, depending on the congestion
state of the cell and system parameter settings, as well as a quality-based handover when no
viable candidate neighbor cells exist.
The Motorola system supports this configuration, as well as many others, including forcing all
calls to use hr all the time, equipment permitting.
Selection of a particular mode of operation is the decision of the user.
Capacity increase due to half rate usage

On the air interface up to twice as many calls can be handled in a cell when half rate is used
(as previously mentioned, this is a trade-off with quality). The actual increase in call carrying
capacity is typically less than 100% due in part to the penetration level of half rate capable
handsets. As the penetration level rises, the half rate carriers become more efficient.
In Figure 4-5 to Figure 4-9, the carried Erlangs (at 2% blocking) are shown for a variety of
carrier configurations. For each configuration, the capacity increase is shown as a function
of the handset penetration level.
The results shown were obtained through simulation and under the following assumptions:
An hr-capable handset is given an hr timeslot if available, else a fr timeslot on a fr carrier.
Preference is to assign a fr-capable only handset to a fr carrier if available; else, it is

assigned to an hr-capable carrier.
Preference is at call establishment to assign an hr-capable handset an idle subchannel on a

timeslot that has the other subchannel occupied with a call.
Graphs
The graphs are intended to illustrate the call carrying effectiveness as a function of hr carriers
and hr-capable MS penetration and do not take into account any control channels. The actual
carried Erlangs can be slightly less than the Erlangs in the graphs.
68P02900W21-T
4-11
Jul 2010
Figure 4-5 3 carriers, only one hr-capable carrier

Carried Erlangs
(at ~2% blocking)
25.000
20.000
15.000
10.000
5.000
0.000
0.00
0.10
0.20
0.30
0.40
0.50
0.60
0.70
0.80
0.90
1.00
AMR Capable MS Penetration

ti-GSM-3_carriers_only_one_hr_capable_ carrier-00116-ai-sw
Figure 4-6 3 carriers, all hr-capable

Carried Erlangs
(at ~2% blocking)
40.000
35.000
30.000
25.000
20.000
15.000
10.000
5.000
0.000
0.00
0.20
0.40
0.60
0.80
1.00

ti-GSM-3_carriers_all_ hr_capabler-00117-ai-sw
4-12
68P02900W21-T
Jul 2010
Figure 4-7 5 carriers, only one hr-capable carrier

Carried Erlangs
(at ~2% blocking)
40.000
35.000
30.000
25.000
20.000
15.000
10.000
5.000
0.000
0.00
0.20
1.00
0.80
0.60
0.40

ti-GSM-5_carriers_only_one_hr_capable_carrier-00118-ai-sw
Figure 4-8 5 carriers, only 3 hr-capable carriers

Carried Erlangs
(at ~2% blocking)
60.000
50.000
40.000
30.000
20.000
10.000
0.000
0.00
0.10
0.20
0.30
0.40
0.50
0.60
0.70
0.80
0.90
1.00

ti-GSM-5_carriers_only_3 hr_capable_carriers-0019-ai-sw
68P02900W21-T
4-13
Jul 2010
Timeslot usage
Figure 4-9
5 carriers, all hr-capable carriers
Carried Erlangs
(at ~2% blocking)
80.000
70.000
60.000
50.000
40.000
30.000
20.000
10.000
0.000
0.00
0.10
0.20
0.30
0.40
0.50
0.60
0.70
0.80
0.90
1.00

ti-GSM-5_carriers_all_hr_capable_carriers-00120-ai-sw
Conclusions
Figure 4-5 to Figure 4-9 are useful in illustrating that, for some deployment strategies such as a
maximum capacity configuration, more carrier equipment should be configured as hr-capable
when hr capable handset penetration raises. For example, in a 5 carrier cell with a 50% handset
penetration rate, there is not much difference in Erlang capacity between a 3 hr-capable
carrier configuration and a 5 (all) hr-capable carrier configuration. The 5 hr-capable carrier
configuration is better able to utilize the extra capacity that hr offers as the handset penetration
rises. GSM hr-capable handset penetration is expected to be high.
When migrating a system to one that includes half rate, ensure that the call capacity rating of
the various components of the system have not exceeded. Use of hr improves the spectral
efficiency over the air interface (and potentially the backhaul), but from a load perspective, a
half rate call has the same impact as a full rate call.
Other strategies, such as utilizing hr only during periods of high demand, would need fewer
hr-capable carriers. Figure 4-5 to Figure 4-9 demonstrates how even adding one hr-capable
carrier can increase Erlang capacity.
Timeslot usage
This section briefly describes timeslot configuration and the algorithm used to optimize usage.
A GSM carrier consists of 8 timeslots, some or all of which can be used for voice traffic. In
full rate, each voice call occupies one timeslot. In half rate, the timeslot is split into two
subchannels, each of which is capable of supporting one hr call. A fr call cannot be carried
within two subchannels split across two timeslots. At any instance, depending on configuration,
a carrier contains a combination of fr and hr calls. To optimize capacity, it is desirable not to
have fragmented hr usage. That is, it is best to use both subchannels of a single timeslot rather
than one subchannel on two timeslots. This frees up contiguous subchannels for use in a fr call.
4-14
68P02900W21-T
Jul 2010
Timeslot usage
The Motorola algorithm attempts first to assign new calls to timeslots that have one subchannel
in use before using a timeslot with both subchannels idle. This provides a large degree of
concentration. Some degree of fragmenting is unavoidable as calls begin and end and the
algorithm attempts to fill in the holes as new calls arrive. This applies to all arriving calls (for
example, originations, handovers, and so on).
It was also considered whether to further pack hr calls together through intra-cell handover
whenever fragmenting reaches a level where a fr call can be blocked. Simulations have been
carried out under a variety of configurations and conditions, and it was determined that the
negative aspects of performing the otherwise unnecessary handover outweigh the slight
capacity gain. Although the results varied according to penetration rate and configuration, in
general, additional blocking of 1.5% or less resulted for the fr only handsets (as compared with
the hr-capable handsets). Limiting the number of hr capable carriers in a cell can reduce this
disparity.
68P02900W21-T
4-15
Jul 2010
Miscellaneous information
Miscellaneous information
Emergency call handling

It is a priority to place an emergency call upon a fr channel, if possible. If necessary to do so, a
call of a lower priority is preempted. When selecting a call to preempt, the software attempts to
minimize the disruption by choosing first a fr call of lower priority. Failing that, a lower priority
single occupancy hr call (the other subchannel is idle) is searched for, followed by a timeslot
carrying two hr calls (both being of lower priority).
Circuit pooling
On the terrestrial route connecting the BSS and the MSC, certain circuits can be used for
different combinations of bearer capabilities. This can be realized in practice by grouping the
circuits into pools supporting the same channel types. The MSC holds this information as route
data. If the MSC allocates an A Interface circuit, it should only ask for resources from the BSS
that it knows are not incompatible with the nominated circuit.
In the case where several circuit pools (groups of circuits supporting the same channel types)
are available on the BSS MSC interface, the terrestrial circuit allocated by the MSC is selected
taking into account the circuit pool the circuit belongs to and the required channel type.
The GDP supports FR, GSM HR, and EFR speech only, while the EGDP supports fr, EFR, and
AMR. The GDP2 supports FR, GSM HR, EFR, and AMR. The older XCDR card only supports
GSM full rate.
When a mix of transcoding equipment (GDP, EGDP/GDP2) is used with AMR being enabled, the
MSC must select a CIC, which is attached to an EGDP or GDP2, if AMR is the only option allowed
in the Channel Type element of the Assignment Request or Handover Request messages. If
AMR is one of the possible options (FR or EFR being the others) then the MSC should select an
EGDP/GDP2 CIC. If the call is not AMR possible, the MSC should select a GDP CIC. If AMR is
indicated as the only option and a CIC attached to a GDP is selected, the call is rejected.
Similarly, when GSM HR is the only option allowed, the MSC must avoid choosing an EGDP
CIC. The ability of the MSC to select a CIC based on the available channel types is called circuit
pooling. The BSC does not support the option to do the CIC selection, nor the circuit pool and
circuit pool list elements. Therefore, it is incumbent upon the MSC to do the selection. The MSC
vendors (Alcatel, Siemens, Nokia, and Nortel) support circuit pooling. (Specifically it was asked
about circuit pool 26, which all except Alcatel support - Alcatel supports circuit pool 27.)
This topic is expanded upon in Transcoding on page 6-63 in Chapter 6 BSC planning steps and
rules, and Transcoding on page 7-10 in Chapter 7 RXCDR planning steps and rules.
For more detailed information on circuit pooling, refer to GSM 08, Mobile-services Switching
Center - Base Station System (MSC - BSS) interface; Layer 3 specification.
4-16
68P02900W21-T
Jul 2010
Half rate utilization
Half rate utilization
Description
Some parameters associated with the usage of half rate (hr) allow the operator to tailor their
system to suit their needs. Brief descriptions of these parameters and their impact to system
operation are provided here.
Parameter descriptions
Unconditionally forcing hr usage
Force hr usage (force_hr_usage)
This parameter allows the operator to force hr usage when assigning a resource. The MSC
channel type preference is overridden whenever possible. The parameter is checked upon
arrival of a new call entering the system and all handovers.
The parameter can be set to enable or disable and defaults to disable. It is configurable on a
BSS basis.
Cell congestion threshold forcing hr usage

Congestion thresholds for hr usage (new_calls_hr) and AMR hr usage (new_calls_amr_hr)
The new_calls_hr parameter is used to qualify the hr usage in a cell with the level of cell
congestion (that is, busy traffic channels). When triggered, the MSC channel type preference is
overridden whenever possible and the call is setup as the GSM hr or AMR hr depending on the
speech version capability and the hr speech version preferences.
The parameter new_calls_amr_hr is used to qualify the AMR hr usage in a cell with the level
of cell congestion (that is, busy traffic channels) allowing calls to be targeted at the AMR hr
at a lower level of congestion than calls targeted at the GSM hr. When triggered, if the call
has AMR hr as the first permitted hr speech version, the MSC channel type preference is
overridden whenever possible and the call is setup as the AMR hr depending on the speech
version capability and the hr speech version preferences.
The parameters are checked upon arrival of a new call entering the system and for all
handovers. The parameter new_calls_amr_hr has no effect when the value is higher than the
value of new_calls_hr since congestion relief is triggered based on the new_calls_hr which
targets AMR hr and GSM hr.
68P02900W21-T
4-17
Jul 2010
For multi-zone cells, the BSS considers only outer zone resources when establishing whether
the threshold has been exceeded. Both the fr and hr resources within the outer zone are used
for the calculation. See also the Inner zone utilization threshold on page 4-20.
This parameter range is 0-101 in steps of 1%. The value of 101 indicates the mechanism is
disabled and is the default value. It is configurable on a cell basis.
Congestion relief
Some capabilities of hr utilization are similar to, or make use of the calculations of, some parts of
the existing congestion relief feature set; in particular, directed retry and advanced congestion
relief. These features must be enabled for those particular hr capabilities to operate properly. A
brief description of the pertinent congestion relief features is provided for completeness.
Advanced congestion relief allows the operator to set thresholds, in units of percentage, on a
cell basis that can trigger the handover of some calls to neighboring cells to reduce congestion
in the triggering cell.
There are two sets of thresholds defined within a cell that control the triggering of
congestion-based intercell handovers:
tch_congest_prevent_thres (1-101)
mb_tch_congest_thres (1-101)
The tch_congest_prevent_thres parameter specifies the level at which the congestion relief
procedure is initiated. The mb_tch_congest_thres parameter specifies the level at which a
MultiBand MS is redirected to the preferred band. mb_tch_congest_thres must be less than or
equal to tch_congest_prevent_thres.
When the congestion exceeds the relief threshold (tch_congest_prevent_thres), the BSS
behaves according to the setting of the ho_exist_congest parameter:
Attempts to hand over as many calls as the number of queued requests = 1

Attempts to hand over as many calls as meet the congestion handover criteria = 2
Off = 0
Calls within the cell consider RF conditions, so only the MSs near the candidate cells are moved.
Directed retry (mb_tch_congest_thres) redirects new traffic when the cell is congested,
resulting in the new call being moved to an alternative cell.
4-18
68P02900W21-T
Jul 2010
Call reconfiguration threshold

Intra-cell fr to hr call reconfiguration thresholds (reconfig_fr_to_hr and reconfig_fr_to_amr_hr)
When the reconfig_fr_to_hr threshold is exceeded, some fr calls within a cell are reconfigured
(by handover) to GSM hr or AMR hr on an hr channel within the same cell to reduce congestion
in that cell. When the reconfig_fr_to_amr_hr threshold is exceeded, some fr calls with AMR
hr as the first permitted hr speech version within a cell are reconfigured (by handover) to
the AMR hr on an hr channel within the same cell to reduce congestion in that cell. The
parameter reconfig_fr_to_amr_hr has no effect when the value is higher than the value
of reconfig_fr_to_hr since congestion relief is triggered based on reconfig_fr_to_hr which
targets AMR hr and GSM hr.
This mechanism works in conjunction with the congestion relief feature, and needs congestion
relief to be enabled (within the cell). The threshold is calculated upon arrival of a new call
entering the system and all handovers.
NOTE
The BSS applies qualification criteria to the half rate capable full rate calls before
allowing the reconfiguration to a half rate traffic channel. The qualification is
based upon the existing congestion relief (directed retry alternatives) criteria for
congestion-based inter-cell handovers. The criteria identify calls, which are at the
extremities of the cell by using a power budget calculation involving the neighbor
handover congestion margin. The BSS does not perform reassignment to a half
rate traffic channel for a call, which is identified by the existing congestion relief
calculations as being at the extremities of the cell. This qualification is performed in
an attempt to ensure that the operator is provided with adequate QoS when the call is
reassigned to a half rate traffic channel.
For multi-zone cells, the BSS considers only outer zone resources when establishing whether
the threshold has been exceeded. Both the fr and hr resources within the outer zone are used
for the calculation. See also the Inner zone utilization threshold on page 4-20.
Once triggered, the BSS reconfigures, as many qualifying existing hr-capable calls (currently
using fr) to use hr as there are hr resources available.
This parameter range is 0-101 in steps of 1%. The value of 101 indicates the mechanism is
disabled and is the default value. It is configurable on a cell basis.
68P02900W21-T
4-19
Jul 2010
Inner zone utilization threshold

Inner zone utilization thresholds (inner_hr_usage_thres and inner_amr_hr_usage_thres)
These parameters are necessary because the reconfig_fr_to_hr, new_calls_hr,
new_calls_amr_hr, and reconfig_fr_to_amr_hr thresholds are triggered by the usage of
the outer zone only within a cell.
Both concentric cells and dual band cells are multi-zone cells. The situation can occur where the
inner zone has low usage but the outer zone is congested such that the reconfig_fr_to_hr or
reconfig_fr_to_amr_hr threshold is exceeded. The BSS attempts to trigger full rate to half
rate intra-cell handovers for the calls that qualify. If some of the calls that qualify reside within
the inner zone, the BSS attempts to reconfigure these half rate capable full rate calls to half
rate when the inner zone is not congested.
A similar situation can occur when the new_calls_hr or new_calls_amr_hr threshold is
exceeded and new calls are assigned. To prevent these situations from occurring, an additional
threshold is applied.
The inner zone utilization thresholds (inner_hr_usage_thres and inner_amr_hr_usage_thres)
are used for this purpose. They protect against reconfigurations within, and new hr calls
assigned to the inner zone, when the usage of the inner zone is low. The inner_hr_usage_thres
and inner_amr_hr_usage_thres are applied when the utilization of half rate is triggered by
reconfig_fr_to_hr and reconfig_fr_to_amr_hr are being exceeded and when new_calls_hr and
new_calls_amr_hr are exceeded.
If the threshold reconfig_fr_to_hr has been exceeded, half rate capable full rate calls residing
on the inner zone are eligible as candidates for reconfiguration from full rate to half rate if the
inner_hr_usage_thres has also been exceeded. If the threshold reconfig_fr_to_amr_hr has
been exceeded, full rate calls with AMR hr as the first permitted hr speech version residing on
the inner zone will only be eligible as candidates for reconfiguration from full rate to half rate if
inner_hr_usage_thres or inner_amr_hr_usage_thres has also been exceeded.
If the threshold new_calls_hr has been exceeded, half rate capable calls are eligible to be
assigned directly to half rate channels within the inner zone if the inner_hr_usage_thres has
also been exceeded. If the threshold new_calls_amr_hr has been exceeded, calls with AMR
hr as the first permitted hr speech version is only eligible to be assigned directly to half rate
channels within the inner zone if inner_hr_usage_thres or inner_amr_hr_usage_thres has
also been exceeded
The range for both parameters is 0-101 in steps of 1%. The value of 101 indicates no half
rate usage in the inner zone and is the default value. The parameters are configurable on a
cell basis. The parameter inner_amr_hr_usage_thres has no effect when the value is higher
than the value of inner_hr_usage_thres since congestion relief is triggered based on the
inner_hr_usage_thres which targets AMR hr and GSM hr.
4-20
68P02900W21-T
Jul 2010
Reserved timeslots
Half rate resource guard limit (hr_res_ts)
When congestion triggered half rate usage is employed, either through call assignments
(cell congestion threshold forcing hr usage) or through reconfigurations (call reconfiguration
threshold), the hr resources must be available for the mechanism to work properly. This is
normally accounted for by setting reconfig_fr_to_hr, new_calls_hr, new_calls_amr_hr, and
reconfig_fr_to_amr_hr such that when they are triggered, there are sufficient resources
available for the half rate calls. However, in multi-zone cells, inner zone resources could be
exhausted before any congestion thresholds are reached (the thresholds only consider outer
zone resources).
To ensure that there are half rate resources available, the operator has the option to allow the
BSS to reserve a maximum number of (half rate capable) traffic timeslots within the inner zone.
This facility is provided to ensure that when a multi-zone cell enters into congestion, there are
half rate capable resources available within the inner zone to allow half rate utilization-related
procedures to be employed. When only the reserved timeslots are left within an inner zone, a
full rate resource is sought in the outer zone before the reserved timeslots in the inner zone
are considered.
The reserved timeslots are applied to the inner zone only, although it is configurable on all cells
and not just multi-zone cells. It has no effect when set on a non multi-zone cell.
The actual value within the inner zone can be dynamically limited to be less than hr_res_ts
by the BSS. The BSS limits the hr_res_ts for the inner zone if the BSS detects that the
inner_hr_usage_thres or inner_amr_hr_usage_thres is not able to exceed if the hr_res_ts
element is left as the user-defined. hr_res_ts is also limited by the number of half rate capable
resources available in the cell or zone.
The BSS SW adjusts the hr_res_ts parameter for the inner zone in such a way that the number
of actual HR slots reserved by the inner_hr_usage_thres or inner_amr_hr_usage_thres
parameters is always higher than hr_res_ts. This automatic adjustment ensures that
inner_hr_usage_thres or inner_amr_hr_usage_thres parameters will never get suppresed by
hr_res_ts.
This parameter range is 0-255 in steps of one timeslot. The default value is 2 timeslots (each
timeslot is capable of supporting two hr calls). It is configurable on a cell basis.
68P02900W21-T
4-21
Jul 2010
Intra-cell hop count

Number of intra-cell interference handovers (hr_fr_hop_count).
Intra-zone intra-cell hr interference handovers are governed by the BSS in a similar manner to
how fr calls are governed by the existing hop_count and hop_count_timer elements.
The current functionality restricts the number (hop_count) of intra-cell interference-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 interference-based handovers are performed in a short period, it indicates
that the cell is experiencing problems with bad interference and the call would be best served
by the network by being moved to another cell.
A similar mechanism is employed for intra-cell half rate interference handovers. All intra-cell
half rate interference handovers contribute to the existing hop_count. The hr_fr_hop_count
parameter is provided to limit the number of intra-cell interference-based handovers from hr
to fr.
The BSS does not allow an intra-cell congestion handover to be performed by a call for which
the hr_fr_hop_count is met and the hop_count_timer has not expired. This allows a call
experiencing repeated high interference levels to remain on a hr channel rather than fr during
congestion. An inter-cell handover is not triggered by hr_fr_hop_count, for this functionality
the existing hop_count parameter is used. The hop count timer (hop_count_timer) is an
existing parameter, used to qualify the new hr (hr_fr_hop_count) element and the existing
element (hop_count).
This parameter range is 0-255 in steps of 1. The default value is 1 hop. It is configurable on a
cell basis. It must be set to a value less than or equal to hop_count.
hr intra-cell handover support

Enable/Disable (support) of hr intra-cell handover (hr_intracell_ho_allowed).
The hr_intracell_ho_allowed element contains an option to disable intra-cell quality handovers
for half rate channels. The element has 4 possible values, which take effect when an hr intra-cell
handover is triggered by the BSS. For interference-based handovers it further specifies the
possible target channel types - full and/or half rate. Quality-based handovers always target a
full rate channel when handovers are enabled. The force_hr_usage element overrides any
preference specified with the hr_intracell_ho_allowed element.
The value of the element causes the following behavior:
If hr_intracell_ho_allowed is set to hr intra-cell, handovers are disabled. If handover required
is sent to MSC, then the control for this hr intra-cell handover is 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 intracell handovers are disabled. Then no
Handover Required is sent to MSC, then hr intra-cell handovers are not supported within the
cell. The intra-cell handover request is ignored by the BSS.
4-22
68P02900W21-T
Jul 2010
Operational aspects
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 handovers are enabled and fr is only
allowed, the BSS attempts to allocate a fr channel as a target resource for the hr intra-cell
interference or quality-based handover.
If hr_intracell_ho_allowed is set such that hr intra-cell handovers are enabled and hr
is allowed, the BSS attempts to allocate an hr or fr target resource for the hr intra-cell
interference-based handover, based on the congestion levels within the cell, the MSC preference
and the user preference. A quality-based handover always targets a fr channel.
This parameter range is 0-3 and is configurable on a cell basis. The default value is 3.
Where:
Is:
Half-rate intra-cell handovers are not initiated by the BSS. Handover Required
sent to MSC.
Half-rate intra-cell handovers are disabled. Handover Required not sent to

MSC.
Half-rate intra-cell handovers are enabled. Full-rate only allowed.
Half-rate Intra-Cell handovers are enabled. Half-rate and full-rate allowed.
It is recommended that hr_intracell_ho_allowed is set to a value of 2 or 3 dependent on the

half rate (AMR or GSM) strategy of the network. Where half rate is being used to maximize
capacity gains by half rate, with call quality of secondary concern, then a value of 3 should be
used. Where half rate is being used to provide capacity gains using half rate but with more
emphasis placed on call quality, then a value of 2 should be used.
Operational aspects
Using half rate exclusively
In some situations, the operator can decide to maximize half rate usage in the system by
enabling the force AMR hr usage parameter (force_hr_usage). This forces all hr-capable MSs
to be placed on an available hr capable carrier, provided it is possible (that is MSC allows AMR
hr and/or GSM hr, the CIC is capable of the transcoding, an hr channel is available, and so on).
This setting maximizes Erlang capacity in the system at the expense of call quality (due
primarily to the lower MOS of hr) and to a lesser extent the prohibiting of hr to fr intra-cell
handovers). As an alternative to using force_hr_usage, new_calls_hr can be set low and
hr_intracell_ho_allowed used to control intra-cell handovers. hr_intracell_ho_allowed can
then be set to allow hr to fr intra-cell handovers, thus improving call quality in some instances.
Using half rate in conjunction with congestion

The system is configured on a cell basis, to tie hr usage to the congestion level within a cell
(new_calls_hr and new_calls_amr_hr). This allows calls to be handled at the higher voice
quality (fr) level until cell congestion reaches a configurable threshold, at which point new
hr-capable calls are assigned to hr channels (hr-capable means that the MSC allows AMR and/or
GSM hr, the CIC is capable of the transcoding, an hr channel is available, and so on).
68P02900W21-T
4-23
Jul 2010
Operational aspects
By using the existing congestion relief feature and the cell reconfiguration threshold, additional
capacity can be attained. As described earlier, the congestion relief feature can be used to
identify calls most likely to benefit from a switch to another, less congested, cell, and perform a
handover to move them. When this mechanism is employed, the operator can then use the cell
reconfiguration capability to increase capacity further by reconfiguring qualifying fr calls to hr.
Congestion is calculated as a function of busy timeslots (and half timeslots) divided by all
timeslots (not counting control channels). The inner zone utilization threshold is used in
multi-zone cells and prevents unnecessary inner zone reconfigurations. The configuration of
parameters takes place as follows:
The congestion threshold for hr usage (new_calls_hr) and/or AMR hr usage (new_calls_amr_hr)
is selected.
If it is desired to attain additional capacity through call reconfigurations, and the congestion
relief feature is enabled, then the cell reconfiguration threshold is set at a level at which it wishes
to force qualifying MSs (on a fr channel) to be reconfigured to AMR hr (reconfig_fr_to_amr_hr)
or hr (reconfig_fr_to_hr). This can be set above or below the congestion relief threshold, as
calls qualifying for congestion relief are not candidates for fr to hr reconfiguration. If voice
quality (that is, fr) is the primary concern, then congestion relief handover should be performed
first. In addition, the reconfiguration threshold must not be set lower than the congestion
threshold for hr usage (new_calls_hr) and AMR hr usage (new_calls_amr_hr), otherwise calls
could be assigned fr and immediately reconfigured to hr. For multi-zone cells, an inner zone
utilization threshold is selected. In many cases, the criteria for inner zone hr utilization is the
same as the outer zone. In these cases, the inner zone utilization threshold can be set the same
as the new call threshold or the reconfiguration threshold.
Following the descriptions, the thresholds could be set in the pattern shown in Figure 4-10.
Figure 4-10 Congestion threshold settings for AMR half rate

CONGESTION
HIGH
reconfig_fr_to_hr
recongig_fr_to_amr_hr
new_calls_hr and inner_hr_usage_thres
new_calls_amr_hr and inner_amr_hr_usage_thres
congestion relief treshold
LOW
ti_GSM-Congestion_threshold_settings_for_AMR_half-rate-00122-ai-sw
hr intra-cell handover control

The intra-cell hop count (hr_fr_hop_count) is set to the desired value. It must be set equal to
or less than the hop_count parameter. The hop count timer (hop_count_timer) is also set to
the desired value. The level of support of hr intra-cell handovers (hr_intracell_ho_allowed) is
configured. The value of these settings is particular to the system being optimized.
4-24
68P02900W21-T
Jul 2010
Operational aspects
AMR hr and GSM hr operation

AMR hr and GSM hr are compatible with each other. When GSM half rate and AMR are enabled
in the BSS and in a cell, half rate-enabled carriers are capable of supporting both AMR and
GSM calls. The selection of AMR or GSM is dependent upon the MSC preferences (indicated
in the Channel Type element of the Assignment Request or Handover Request messages) and
the capabilities of the selected CIC.
68P02900W21-T
4-25
Jul 2010
Hardware
Hardware
Equipment descriptions
New hardware (and associated software) has been developed to enhance the operation of AMR
and/or GSM half rate. Each new item is described here.
DSW2 and DSWX

The DSW2 provides two improvements over existing capability:
It allows for 8 kbps subrate switching in the BSC and RXCDR (called extended subrate
switching (ESS) mode).
When used in the RXCDR along with DSWXs, it allows for double the timeslot capacity
(with one extension shelf, 1024 timeslots per shelf) (called enhanced capacity (EC) mode).
ESS mode is used to decrease backhaul costs when half rate is in use between the BTS and BSC
and (if also enabled in the RXCDR) the BSC and RXCDR. As long as the 7.95 codec mode (AMR)
is not used, the backhauled TRAU fits in an 8 kbps subchannel. On the BTS - BSC interface,
this can result in a 50% saving in backhaul costs per 8 kbps hr-capable carrier. Without 8 kbps
switching, each half rate call needs a full 16 kbps backhaul bearer, or four 64 kbps timeslots
per carrier. With 8 kbps switching, the same backhaul as is required for full rate (two 64 kbps
timeslots) is used. A similar saving can be achieved on the BSC - RXCDR interface.
When ESS mode is enabled in the BSC, 8 kbps backhaul can be used between the BTS and
BSC. For every connected RXCDR with ESS enabled, 8 kbps backhaul can be used between
the BSC and that RXCDR.
Use of ESS mode needs all DSW2s to be used (within the BSC or RXCDR). KSWXs and DSWXs
are used (exclusively or mixed), with the restriction that a KSWX cannot be connected to a
DSWX or vice-versa. EC mode is available in the RXCDR and can be used to increase the number
of timeslots available. Each device (that is MSIs, GDPs, EGDPs, and GDP2s) needs a specific
number of timeslots. By increasing the number of timeslots available across two shelves, more
combinations of equipment are possible. This capability is likely to be used in conjunction with
the RXU3 shelf, which provides for additional E1 connectivity. (More detailed information is
available in the later chapters of this manual.)
EC mode needs the use of all DSW2s and DSWXs.
DSW2s and DSWXs are backwards compatible with KSWs and KSWXs, and are interchangeable
(in non- ESS and non-EC modes) with, again, the restriction that a KSWX cannot be connected
to a DSWX or vice-versa.
4-26
68P02900W21-T
Jul 2010
Equipment descriptions
EGDP and GDP2

The current GDP can terminate 30 terrestrial circuits and handle the transcoding for GSM
Full Rate (FR), Enhanced Full Rate (EFR) and GSM Half Rate (HR). It takes up one slot and
connects to a single E1 span line.
Due to the added processor burden required by AMR, the GDP cannot support 30 channels
beyond FR/EFR/HR. Two cards however, operating in a tandem configuration through a
firmware upgrade, can support two GDPs and 30 channels of FR/EFR/AMR. This arrangement of
two GDPs is called an EGDP. It occupies two card slots and can terminate one E1 span line.
NOTE
EGDP cannot support GSM HR.
A more efficient solution is provided through a new development, the GDP2. With its
upgraded DSP and other enhancements, the GDP2 is capable of transcoding 60 channels of
FR/EFR/HR/AMR. It takes up one card slot and can terminate two E1 span lines.
All card combinations are present in a system simultaneously.
When the GDP2 is inserted into a card slot that terminates only one E1 span (a non-RXU3
shelf) 30 terrestrial circuits are supported.
RXU3
The earlier RXU shelf provides 19 MSI slots (see NOTE), of which 5 are considered MSI-capable,
meaning they have connectivity for two E1 span lines. The other 14 slots can terminate only one
E1 span line, as they were designed to hold GDPs (or the older XCDRs).
The RXU3 shelf provides for termination of two E1 span lines per card slot. A combination of
MSIs and XCDR/GDP/EGDP/GDP2s can share these 19 slots without connectivity restriction
(timeslot restrictions still apply). This enables the GDP2s to be used to capacity. Within the
extension RXCDR shelf, enhanced capacity mode must be enabled to access the second E1
when GDP2s are used.
Within the BSC, the BSU shelf contains 12 MSI slots, of which up to 6 slots are used for the
transcoder function. All slots support the connectivity for two E1 terminations per card slot,
allowing GDP2s to be used to capacity.
NOTE
These are called MSI slots, but they may contain either an MSI or a transcoder board.
BSSC3
The BSSC2 cabinet has connectivity for up to 48 E1 span lines, which is the capacity of two
of the earlier shelves. To accommodate the additional shelf capacity, the BSSC3 cabinet has
been developed which can terminate up to 76 E1 span lines. This is accomplished by adding 6
additional T43/BIB boards to the cabinet top.
Like the BSSC2, the BSSC3 cabinet can function as a BSC (BSC2) or an RXCDR (RXCDR2),
depending on how the cabinet shelves are equipped. Figure 4-11 shows the alternative
configurations available for the BSSC3.
68P02900W21-T
4-27
Jul 2010
Backhaul
NOTE
Earlier BSUs/RXUs were used in the BSSC3 cabinet instead of or with the BSU2/RXU3.
Figure 4-11 Alternative configurations for the BSSC3 cabinet

BSC2 Configuration
RXCDR2 Configuration
BSU2
RXU3
BSU2
BSU2
BSU2
Basic BSC2
With
expansion
shelf, or as 2
separate
BSC2s
BSC2 with
transcoding
RXU3
RXU3
Basic
RXCDR2
RXU3
RXCDR2 with
expansion
shelf
ti-GSM-Alternative_configurations_for_the_BSSC3_cabinet-00123-ai-sw
Backhaul
Table 4-2 and Table 4-3 show how one fr voice call or two hr calls on a single air timeslot are
mapped to terrestrial resources at the RTF. Table 4-2 shows how the amount of backhaul
configured for each timeslot for a given RTF is based on database parameter settings.
The amount of terrestrial backing allocated for an RTF is based on three parameters:
4-28
hr_enabled (with values 0 = no half rate, 1 = half rate)
allow_8k_trau (with values 0 = no 8 k TRAU, 1 = 8 k TRAU)
pkt_radio_type (adds EGPRS support and supersedes allow_32k_trau)
68P02900W21-T
Jul 2010
Backhaul
Table 4-2 Backhaul configuration based on parameter settings

hr_enabled
pkt_radio_type
allow_8 k
_trau
0 = voice
only
1 = 16 k data
and voice
2 = 32 k
data and
voice
16 k
16 k
32 k
VersaTRAU
32 k
32 k (data
uses only
16 k)
32 k
Not Supported (allow_ 8

k_trau cannot be set to 0
if pkt_radio_ type is 3)
16 k
16 k
32 k
VersaTRAU
3 = 64 k data and voice
Table 4-3 shows how a fr call or two hr calls are placed onto the terrestrial backhaul.
Table 4-3 Call placement on terrestrial backhaul

hr_enabled
pkt_radio_type
allow_8
k
_trau
0 = voice
only
1 = 16 k
data and
voice
2 = 32 k data
and voice
2 half rate calls on separate

16 k subrates
2 half rate calls share one

16 k subrate
Full rate
call on 16
k
Full rate call on left

most 16 k subrate
group of the 32 k
(duplicated on both 16
k in the UL)
3 = 64 k data and voice

Full rate call on 16 k subrate
corresponding to the air
timeslot - see Table 4-4.
Not supported.
Half rate with 8 k switching
assigns the two half rate
voice channels to the two bits
allocated to an air timeslot.
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 see Table 4-4.
Table 4-4 Voice call mapping on the backhaul for a 64 k RTF

VersaTRAU
subchannel
DS0 Bit
0
DS0 Bit
1
DS0 Bit
2
DS0 Bit
3
DS0 Bit
4
DS0 Bit
5
DS0 Bit
6
DS0 Bit
7
A0
A1
B0
B1
C0
C1
D0
D1
E0
E1
F0
F1
G0
G1
H0
H1
68P02900W21-T
4-29
Jul 2010
Backhaul
Key: A - H are air timeslots 0 - 7 respectively.
NOTE
The VersaTRAU Subchannel2 and any higher numbered VersaTRAU Subchannels

are always used to carry the multiplexed data for all the PDCHs configured on
this carrier.
The tables give sample configurations for 16 kbps, 32 kbps, and 64 kbps
backhaul. Figure 4-12 and Figure 4-13 apply only to the 16 kbps backhaul.
When a fr call is connected, the BTS-BSC-RXCDR backhaul path is as shown on the left in
Figure 4-12. 16 kbps backhaul is required on all the legs.
When an AMR hr call is connected which includes the 7.95 kbps rate in the Active Codec Set,
then a similar backhaul path is needed, as shown on the right in Figure 4-12.
Figure 4-12 AMR backhaul paths

16 kbit/s
After-CIC
connection
CIC
EGDP/GDP2
16 kbit/s
Ater-CIC
connection
CIC
EGDP/GDP2
RXCDR
Switch
RXCDR
Switch
16 kbit/s Ater
allocated
16 kbit/s Ater
allocated
BSC
Switch
BSC
Switch
16 kbit/s Abis
backhaul
16 kbit/s Abis
backhaul
BTS
Switch
CCU
BTS
Switch
AMR fr call over

air interface
CCU
hr call over air

interface
(w / 7.95 kbit/s)
ti-GSM-AMR_backhaul_paths-00124-ai-sw
4-30
68P02900W21-T
Jul 2010
Backhaul
For a connected AMR hr call not requiring the 7.95 codec rate or a GSM hr call, if ESS mode
is enabled in the BSC, but not in the RXCDR, then the backhaul path shown on the left in
Figure 4-13 results. For the same call, if ESS mode is enabled in the BSC and the RXCDR then
the path is shown on the right in Figure 4-13 results. (The idle tone insertion is used internally
to fill the 16 kbps timeslot.)
Figure 4-13 hr backhaul paths - ESS mode enabled

16 kbit/s
Ater-CIC
connection
CIC
EGDP / GDP2
8 kbit/s
Ater-CIC
connection
CIC
EGDP / GDP2
8 kbit/s
idle tone
RXCDR
Switch
RXCDR
Switch
8 kbit/s Ater
allocated
16 kbit/s Ater
allocated
8 kbit/s
idle tone
BSC
Switch
BSC
Switch
8 kbit/s Abis
backhaul
8 kbit/s Abis
backhaul
BTS
Switch
BTS
Switch
CCU
CCU
hr call over air
interface
hr call over air

interface
ti-GSM-hr_backhaul_paths_ESS_mode_enabled-00125-ai-sw
68P02900W21-T
4-31
Jul 2010
Summary
Summary
AMR transcoding is supported using existing GDPs working in a tandem configuration,

the EGDP, or with the GDP2. The former provides a capacity of one half (15 channels of
FR/EFR/AMR per card slot) of what is currently supported for the GDP (30 channels FR/EFR/HR
per card slot); the latter double the capacity (60 channels of FR/EFR/HR/AMR per card slot).
GSM HR transcoding can be supported with the GDP (30 channels) or the GDP2 (60 channels).
GDP2s can work in the earlier RXU shelf, but only at half capacity because there is connectivity
of only one E1 per card slot (for most slots). The RXU3 shelf provides 2 x E1 connectivity for all
card slots (enhanced capacity mode must be enabled to access the second E1 when GDP2s are
used in nonMSI slots in the extension shelf). The earlier BSU shelf provides two E1 connectors
per card slot, for local transcoding configurations.
The BSSC2 cabinet provides for 48 E1 terminations. To use the RXU3 shelves to capacity, the
BSSC3 cabinet has been developed. This can terminate 76 E1 span lines.
The DSW2 can be utilized to reduce backhaul costs between both the BTS and BSC and the
BSC and RXCDR, when hr is used. Additionally, within the RXCDR, use of DSW2s/DSWXs
can support a greater number of timeslots, which translates to more combinations of card
types, particularly MSIs.
The proper combinations of equipment should be tailored per network.
4-32
68P02900W21-T
Jul 2010
Chapter
5
BTS planning steps and rules
This chapter describes the planning steps and rules for the BTS, including the macrocell and the
microcell. The planning steps and rules for the BSC are provided in Chapter 6 BSC planning
steps and rules, and that for the remote transcoder (RXCDR) are in Chapter 7 RXCDR planning
steps and rules. This chapter details the following sections:
BTS planning overview on page 5-2
Macrocell cabinets on page 5-4
Microcell enclosures on page 5-8
Receive configurations on page 5-11
Transmit configurations on page 5-14
EGPRS enabled CTU2/CTU2D configuration on page 5-18
Carrier equipment (transceiver unit) on page 5-20
Micro base control unit (microBCU) on page 5-25
Network interface unit (NIU) and site connection on page 5-26
BTS main control unit on page 5-29
Cabinet interconnection on page 5-33
Battery back-up provisioning on page 5-38
External power requirements on page 5-39
Network expansion using macro/microcell BTSs on page 5-41
Line interface modules (HIM-75, HIM-120) on page 5-42
DRI/Combiner operability components on page 5-43
CTU8m D4+ Link on page 5-44
68P02900W21-T
Jul 2010
5-1
BTS planning overview
BTS planning overview
Introduction
The following information should be available to plan the equipage of a BTS site:
Number of cells controlled by the site
Number of carriers required
Number of standby carriers per cell
Output power per cell

The required output power must be known to ensure that the selected combining method
and antenna configuration provides sufficient output power. Alternatives include changing
combiner types or using more than one transmitting antenna. Duplexers can be used to
reduce the amount of cabling and the number of antennas.
Antenna configuration for each cell
Cabinet or enclosure types to be used
Future growth potential

The potential future growth of the site must be known to make intelligent trade offs
between fewer cabinets/enclosures initially and ease of expansion later.
Existence of equipment shelters at the site

Macro or microcell outdoor equipment should be included in the BTS planning for locations
where there are no equipment shelters. Macro or microcell should be included where
rooftop mounting or distributed RF coverage is required or where space and access are
restricted.
5-2
Requirement of battery backup equipment for the outdoor equipment
Requirement of CTU8m BBU-E or D4+ link redundancy
Location of any CTU8m/RCTU8m radio in relation to the Horizon II cabinet
68P02900W21-T
Jul 2010
Outline of planning steps

Macrocell and microcell BTS sites
The information required for planning a macro/microcell BTS site is as follows:
Determine if the site is indoor or outdoor.
Number of macrocell cabinets required, refer to the section Macrocell cabinets on page 5-4.
For number of microcell enclosures required, refer to the section Microcell enclosures on
page 5-8.
For receiver configuration (including planning for Dual Band), refer to the section Receive
configurations on page 5-11.
For transmit configuration, refer to the section Transmit configurations on page 5-14.
For EGPRS enabled CTU2 configuration, refer to the section EGPRS enabled CTU2/CTU2D
configuration on page 5-18.
For the amount of carrier equipment required, refer to the section Carrier equipment
(transceiver unit) on page 5-20.
For the number of micro base control units required, refer to the section Micro base
control unit (microBCU) on page 5-25.
For the number of network interface units required, refer to the section Network interface
unit (NIU) and site connection on page 5-26.
For the number of E1 links required, refer to the section Network interface unit (NIU)
and site connection on page 5-26.
For the number of main control units required, refer to the section BTS main control
unit on page 5-29.
For the number of FOX and FMUX boards required, refer to the section Cabinet
interconnection on page 5-33.
For battery back-up provisioning, refer to the section Battery back-up provisioning on
page 5-38.
For external power supply requirements, refer to the section External power requirements
on page 5-39.
For using CTU8m/RCTU8m radios, the location of the CTU8m/RCTU8m radio in relation
to the cabinet, the desired D4+/BBU-E redundancy level, refer to CTU8m D4+ Link on
page 5-44 .
68P02900W21-T
5-3
Jul 2010
Macrocell cabinets
Macrocell cabinets
Horizon II macro
Horizon II macro is the next generation replacement for Horizonmacro. Horizon II macro and
Horizonmacro are identical in terms of capacity and support the same numbers of carriers,
RSLs, and E1s. The Horizon II macro supports equipping of four RSLs per E1, thus reducing
the amount of E1 spans needed at a site that needs more than two RSLs. Horizonmacro and
M-Cell BTSs currently support two RSLs per E1.
A Horizon II macro cabinet (indoor or outdoor) can support 12 carriers when populated fully
with six CTU2s/CTU2Ds, used in double density mode, or can support six carriers when the six
CTU2s/CTU2Ds are used in single density mode. If the CTU2D Capacity feature is unrestricted,
the mode Capacity can be configured for CTU2D. Expansion beyond 12 carriers per cabinet
needs additional cabinets. The maximum RF carriers supported per Horizon II macro Site
Controller (HIISC or HIISC2-S or HIISC2-E) is 24.
{9722} This feature supports large site 12/12/12 on GSR10 when Horizon II macro with two
BBU-Es and 6 (R)CTU8 is configurated, the maximum RF carriers per site is supported up to 36.
{34371G} A Horizon II macro cabinet (indoor or outdoor) when fully populated, can support up
to 6 CTU8ms or out-of-cabinet RCTU8ms or mixed configuration. The maximum RF carriers
supported is 24 carriers in one Horizon II macro cabinet. The Base Band Unit (BBU-E) is
required to support (R)CTU8ms. The Horizon II macro can support up to two BBU-Es. The
circuit breaker and fans must be upgraded for CTU8m in the Horizon II macro cabinet. The
+27V PSU shall not be used to support CTU8ms in Horizon II macro cabinet. Both the -48V
DC and 220V AC 800W PSU and new 1600W PSU can be used for CTU8m in the Horizon II
macro cabinet with below recommendation:
Table 5-1 Specifications for CTU8m in Horizon II macro

Non-redundant mode
Number of
Radios
Redundant mode
Number of
CTU2D
Number of
CTU8m
Number of
800W PSU
required
Number of
1600W PSU
required
Number of
800W PSU
required
Number of
1600W PSU
required
2
Continued
5-4
68P02900W21-T
Jul 2010
Horizonmacro
Table 5-1 Specifications for CTU8m in Horizon II macro (Continued)

Non-redundant mode
Number of
Radios
Redundant mode
Number of
CTU2D
Number of
CTU8m
Number of
800W PSU
required
Number of
1600W PSU
required
Number of
800W PSU
required
Number of
1600W PSU
required
N/A
N/A
The Horizon II macro outdoor is a Horizon II macro indoor along with an outdoor enclosure that
incorporates heat management. The Horizon II macro outdoor can operate in the temperature
range from -40 C to 50 C.
NOTE
The Horizon II macro does not support the use of CCBs.
Horizonmacro
A Horizonmacro cabinet (indoor or outdoor) can support six carriers (CTUs). Expansion beyond
six carriers needs additional cabinets. The Horizonmacro 12 carrier outdoor is, in effect, an
outdoor enclosure which can accommodate either one or two indoor cabinets for 6 or 12 carrier
operation.
NOTE
CCBs cannot be used with the Horizonmacro indoor cabinet if the cabinet is to be
installed in the 12 carrier outdoor enclosure.
68P02900W21-T
5-5
Jul 2010
All Horizonmacro cabinets/enclosures incorporate heat management systems. The

Horizonmacro outdoor can operate at ambient temperatures up to 50 C. The Horizonmacro 12
carrier outdoor can operate at ambient temperatures up to 45 C.

The Horizoncompact and the Horizoncompact2 are an integrated cell site, designed primarily
for outdoor operation and consist of:
BTS unit
This is like Horizonmicro / Horizonmicro2 and is a two-carrier cell with combining.
Booster unit
This incorporates two Tx amplifiers, delivering 10 W (nominal) at each antenna.
The BTS can be wall-mounted or pole-mounted. The wall can be concrete, brickwork, stonework,
dense aggregate block work, or reconstituted stone, with or without rendering.
Cooling is by natural convection, and the unit can operate at ambient temperatures up to 50 C.
NOTE
The main difference between the Horizoncompact and the Horizoncompact2 is

that the latter can be expanded to support two additional BTSs.
In this document, future references to Horizoncompact2 also include

Horizoncompact unless stated otherwise.
M-Cell6
The M-Cell6 cabinet can support six carriers (TCUs or CTU2 Adapter in an EGPRS configuration)
or 12 carriers (TCUs or CTU2 Adapter in a non-EGPRS configuration). Expansion beyond
this needs additional cabinets. Outdoor cell sites are provided with an ancillary cabinet and
a side cabinet.
The M-Cell6 HMS has the following options:
5-6
Fans that circulate ambient air through the cabinet, for both indoor and outdoor units.
An air conditioning unit for ambient temperatures up to 55 C, for outdoor cabinets only.
A heat exchanger for ambient temperatures up to 45 C, for outdoor cabinets only.
68P02900W21-T
Jul 2010
M-Cell2
M-Cell2
The M-Cell2 cabinet can support two carriers (CTU2 Adapter in EGPRS configuration) or
four carriers (CTU2 Adapter in non-EGPRS configuration). The M-Cell2 outdoor cabinet
accommodates all the elements in an indoor cabinet. It also provides limited accommodation for
LTUs and battery backup. A fan within the cabinet provides cooling. Unlike M-Cell6 outdoor
cabinets where the antenna terminations are in a side cabinet, M-Cell2 terminations are
on the main cabinet.
The M-Cell2 HMS has the following options:
Fans that circulate ambient air through the cabinet, for both indoor and outdoor units.
A heat exchanger for ambient temperatures up to 45 C, for outdoor cabinets only.
An air conditioning unit for ambient temperatures up to 55 C, for outdoor cabinets only.
68P02900W21-T
5-7
Jul 2010
Microcell enclosures
Microcell enclosures
Horizon II mini
The Horizon II mini BTS satisfies the Horizon II macro requirements, and adds significant
functionality that enables it to be classed as a Mini Macro BTS similar to the M-Cell2 BTS.
The architecture is based on the Horizon II macro architecture and effectively Horizon II
mini operates like a Horizon II macro cabinet. The Mini BTS can be expanded from the
Horizon II macro, Horizonmacro, and M-Cell6. The Horizon II mini enclosure can house two
CTU2s/CTU2Ds that can be configured in both single density and double density mode. If the
CTU2D Capacity feature is unrestricted, the mode capacity can be configured for CTU2D. As a
result, the carrier capacity is 1-4 carriers, for a maximum network configuration of 16 to 24
carriers per site dependent on cabinet capacity.
{34371G} A Horizon II mini cabinet when fully populated can support up to 2 CTU8ms. The
maximum RF carriers that can be supported in one Horizon II mini cabinet is 16 carriers using
CTU8m at 8 carriers mode, 12 carriers using CTU8m at 6 carriers mode, or 8 carriers using
CTU8m at 4 carriers mode.
A Horizon II mini cabinet can support up to 6 out-of-cabinet (R)CTU8ms. The maximum RF
carriers that can be supported in one Horizon II mini cabinet is 24 carriers using (R)CTU8m.
The Base Band Unit (BBU-E) is required to support (R)CTU8ms. The Horizon II mini can
support maximum of one BBU-E.
The circuit breaker and fans must be upgraded for CTU8m in the Horizon II mini cabinet. The
+27V PSU shall not be used to support CTU8ms in Horizon II mini cabinet. Both the -48V DC
and 220V AC 800W PSU and new 1600W PSU can be used for CTU8m in the Horizon II mini
cabinet. If two CTU8m radios are equipped, the new 1600W PSU must be used.
Horizon II mini is available as indoor and outdoor variant, and can be mounted on wall, floor,
or rack. The wall may be concrete, brickwork, stonework, dense aggregate block work, or
reconstituted stone, with or without rendering.
Software parameters are added to distinguish Horizon II mini cabinets to allow easier
configuration. The Horizon II mini parameters allow for:
Only one BTP to be equipped to a Horizon II mini master cabinet.
A maximum of two physical radios to be equipped to a Horizon II mini cabinet.
Due to the compact and low-cost nature of this product, there is no accommodation for
redundancy hardware.
Horizon II mini can only be equipped with CTU2/CTU2D radios and, therefore, supports EGPRS.
NOTE
The Horizon II mini uses E1 links for both TRAU and RSL and can be expanded from a
Horizonmacro family BTS or be used as a network of Horizon II mini cabinets.
5-8
68P02900W21-T
Jul 2010
Horizonmicro and Horizonmicro2
SDH feature
Horizon II mini also supports an auxiliary power supply or an optional third-party SDH module
requiring a 48 V dc power supply up to a maximum dissipation of 60 W.
When the outdoor enclosure is configured with the SDH module, it can be a standalone only BTS.
NOTE
The outdoor enclosure configuration cannot be expanded in a network, as the
communications power card, to supply -48 V dc, should be inserted in the Site I/O slot.
Horizonmicro and Horizonmicro2

The Horizonmicro and the Horizonmicro2 are an integrated cell site, designed primarily for
outdoor operation and consist of a single small two-carrier BTS unit. The Horizonmicro and
Horizonmicro2 can be wall or pole-mounted. The wall may be concrete, brickwork, stonework,
dense aggregate block work, or reconstituted stone, with or without rendering.
Cooling is by natural convection, and the unit can operate at ambient temperatures up to 50 C.
NOTE
The main difference between the Horizonmicro and the Horizonmicro2 is that
the latter can be expanded to support two additional BTSs.
In this document, future references to Horizonmicro2 also include Horizonmicro

unless stated otherwise.
Horizon II micro
The Horizon II micro is an integrated cell site, designed for indoor, and outdoor microcellular
applications and consists of a single small two carrier BTS (CTU2/CTU2D) unit. It can be
configured for two carriers in double density mode for GSM/GPRS or one carrier in Single
Density mode for EGPRS. If ITS is unrestricted and enabled, double density mode can be used
for EGPRS. If the CTU2D Capacity feature is unrestricted, the mode capacity can be configured
for CTU2D. It can be seen as a replacement to the Horizonmicro2 where it deems obsolete
(because of an obsolete chip set or where features no longer can be supported) and is to target
applications in both 900 MHz and 1800 MHz bands.
{34371G} The Horizon II micro cabinet can support the RCTU8m only. A Horizon II micro
cabinet can support up to six out-of-cabinet RCTU8ms. The maximum RF carriers that can be
supported in one Horizon II micro cabinet is 24 carriers using RCTU8m. The Base Band Unit
(BBU-E) is required to support RCTU8ms. The Horizon II micro can support one BBU-E.
The circuit breaker and fans should be upgraded for the Horizon II micro cabinet to support
(R)CTU8ms. The 220V ac power supply unit (PSU) upgrade for Horizon II micro is not required.
The Horizon II micro can be wall or pole-mounted. The wall may be concrete, brickwork,
stonework, dense aggregate block work, or reconstituted stone, with or without rendering.
68P02900W21-T
5-9
Jul 2010
Horizon II micro
Cooling is by natural convection or by an internal fan. The unit can operate at ambient
temperatures up to 50 C.
5-10
68P02900W21-T
Jul 2010
Receive configurations
Receive configurations
Introduction
The receiver equipment provides the termination and distribution of the received signals
from the Rx antennas. Receiver equipment is required for each Rx signal in every cabinet or
enclosure in which it is used. Each Rx antenna must terminate on a single cabinet or enclosure.
If the signal is to go to multiple cabinets, it is distributed from the first cabinet.
When (R)CTU8m units are employed the antenna is directly connected to the (R)CTU8m unit.
NOTE
Horizonmicro2 and Horizon II micro are two-carriers only, combined to a single

antenna. Horizoncompact2 is two-carriers only, with two antennas.
Two versions of the Horizonmicro2 and Horizoncompact2 BTSs are available.

One version can operate on GSM900 frequencies and the other can operate on
DCS1800 frequencies.
The factors affecting planning for GSM900 and DCS1800 BTSs are provided in this section.
GSM900
GSM carriers can be supported using remote RCTU8m radios, or through the radios located in
the BTS cabinet. With RCTU8m radios, the antennas for a sector are directly connected to the
RCTU8m radio and no other receiver equipment is required.
The RCTU8m radio has two antenna ports that can be connected directly to one or two antennas
without additional receive equipment. The RCTU8m also supports 2-way diversity using these
antennas. 4-way receive diversity is not supported on the RCTU8m radio.
When using radios located in the BTS cabinet the following factors should be considered when
planning the GSM900 receiver equipment:
Horizon II macro and Horizon II mini BTSs need one 900 MHz SURF2 for each cabinet.
Currently, for Horizon II macro only, a second (optional) 900 MHz SURF2 can be installed
to provide 4-branch diversity.
NOTE
68P02900W21-T
4 branch receive diversity is not supported with the CTU8m radio.
For Horizon II macro only, an optional SURF2 dual-band adapter allows

a 900 MHz SURF2 and a 1800 MHz SURFs to be installed in the same
cabinet, thus providing dual band capability.
5-11
Jul 2010
Receive antennas can be extended across Horizon II macro/Horizon II mini cabinets by

using the 900 SURF2 expansion ports to feed a SURF2 in another cabinet.
Horizonmacro BTSs need one 900 MHz SURF for each cabinet. This has dual band
(900/1800 MHz) capability.
Receive antennas can be extended across Horizonmacro cabinets by using the 900 SURF
expansion ports to feed a SURF in another cabinet.
M-Cell2 and M-Cell6 BTSs need one DLNB for each sector.
Receive antennas can be extended across M-Cell6 cabinets by using the IADU expansion
ports to feed an IADU in another cabinet.
DCS1800
GSM carriers can be supported using remote RCTU8m radios, or through the radios located in
the BTS cabinet. With RCTU8m radios the antennas for a sector are directly connected to the
RCTU8m radio and no other receiver equipment is required.
The RCTU8m radio has two antenna ports that can be connected directly to one or two antennas
without additional receiver equipment. The RCTU8m also supports 2-way diversity using these
antennas. 4-way receive diversity is not supported on the RCTU8m radio.
When using radios located in the BTS cabinet the following factors should be considered when
planning the DCS1800 receiver equipment:
Horizon II macro and Horizon II mini BTSs need one 1800 MHz SURF2 for each cabinet.
Currently, the SURF2 is not dual band and only supports 900 MHz/1800 MHz capability in
separate cabinets. For Horizon II macro only, a second (optional) 1800 MHz SURF2 can
be installed to provide 4-branch diversity.
NOTE
4 branch receive diversity is not supported with the CTU8m radio.
Receive antennas can be extended across Horizon II macro/Horizon II mini cabinets by
using the 1800 SURF2 expansion ports to feed a SURF2 in another cabinet.
Horizonmacro BTSs need one 1800 MHz SURF for each cabinet. Receive antennas can
be extended across Horizonmacro cabinets by using the 1800 SURF expansion ports to
feed a SURF in another cabinet.
NOTE
Two types of 1800 SURF are available: One is 1800 MHz single band and the
other is 1800 MHz/900 MHz dual band.
5-12
M-Cell2 and M-Cell6 BTSs need one LNA for each sector. Receive antennas can be
extended across M-Cell6 cabinets by using the LNA expansion ports to feed an LNA
in another cabinet.
68P02900W21-T
Jul 2010
DCS1800 and GSM900

It should be considered that Horizon II macro dual band capable cabinets need one 1800 MHz
SURF2, one 900 MHz SURF2 and a dual band adapter, when planning dual band (that is,
support for both DCS1800 and GSM900 within a single cabinet) receive equipment.
NOTE
The maximum number of transceiver units for a dual-band cabinet configuration

is 3 CTU2s/CTU2Ds/CTU8ms per band. A third power supply is required.
The rear SURF2 controls CTU2/CTU2D radio slots 3, 4, and 5. The front SURF2
controls CTU2/CTU2D/CTU8m radio slots 0, 1, and 2.
Contact your Motorola Local Office for more information.
Refer to Chapter 12 Hardware and compatibility, for dual band cabinet physical
configuration.
Dual-band configurations can also be created using the RCTU8m radio which is not subject to
the restrictions above. The 900 MHz and 1800 MHz RCTU8m radios can be mixed remotely
for the Horizon II cabinets, as each RCTU8m radio is connected to its own antennas to receive
the signal.
Receiver planning actions

Determine the number of cells.
Determine the number of cells which have {34371G}CTU8m CTU2s/CTU2Ds/CTUs/TCUs

in more than one cabinet.
Determine the number of Rx antennas per cell supported in each cabinet.
Determine the type and quantity of receive equipment required.
NOTE
68P02900W21-T
{34371G}When using CTU2s/CTU8m, in high-density mode, all carriers should

be in the same sector. Disabling one carrier does not affect other CTU2/CTU8m
carriers.
All carriers supported on a CTU8m or RCTU8m radio must be in the same sector
and frequency band. Dropping one carrier does not impact the other carriers
on that radio.
5-13
Jul 2010
Transmit configurations
Transmit configurations
Introduction
The transmit equipment provides bandpass filtering and signal combining for the BTS cabinets.
The CTU2/CTU2D used in Horizon II macro can be configured to use a single high-power carrier
(single density mode) or two lower power carriers (double density mode). For M-Cell2 and
M-Cell6 cabinets, a TxBPF is required for each antenna.
NOTE
Horizonmicro2 and Horizon II micro are two-carrier only, combined to a single

antenna.
Horizoncompact2 is two-carrier only, with two antennas.
The CTU8m and RCTU8m radios are capable of operating in three different modes:
The 4-carrier mode supports the 3GPP Release 8 MCBTS Class 1 specification (1 or 2
carriers per Tx output).
The 6-carrier mode supports the 3GPP Release 8 MCBTS Class 2 specification (1 to 3
The 8-carrier mode supports the 3GPP Release 8 MCBTS Class 2 specification (1 to 4
Different countries may restrict the use of the radios operating to the 3GPP Release 8 MCBTS
Class 1 or 2 specifications. If a country does not license the use of the 3GPP Release 8 MCBTS
Class 1 equipment, then CTU8m/RCTU8m radios cannot be deployed in that country. If the
country permits the use of 3GPP Release 8 MCBTS Class 1 equipment but restricts the use
of 3GPP Release 8 MCBTS Class 2 equipment, then the CTU8m/RCTU8m radio may only be
operated in 4-carrier mode.
As a CTU8m radio provides two transmit outputs per radio slot in the cabinet, a new hybrid
combining duplexer (HCD) combines these two outputs and also provides a duplexer function in
a device.
CTU8m radios must be compatible with newer duplexers or HCDs to meet the earlier discussed
MCBTS classes. Older duplexers supplied before the GSR10 release must not be used with the
CTU8m radios (use SVLF9150G or later). The latest GSR10 duplexers are backward compatible.
The transmit configurations available for Horizon II macro, Horizon II mini, Horizonmacro,
M-Cell2 and M-Cell6 BTSs are listed in Table 5-2.
5-14
68P02900W21-T
Jul 2010
Table 5-2
Transmit configurations pre-CTU8m radio

Cabinet Transmit
Configurations Wide
Band Combining
Cabinet Transmit
Configurations Cavity
Combining
M-Cell2 and
M-Cell6
1 TxBPF
Not available
Horizonmacro
1 DCF or 1 TDF
Not available
1 or 2
Horizon II macro
1 DUP
Not available
1 or 2
Horizon II mini
2 DUP (BowtieCombiner)
Not available
M-Cell2 and
M-Cell6
1 HCOMB + 1 TxBPF
1 CCB output
Horizonmacro
1 DCF
1 CCB output
M-Cell6
2 HCOMB + 1 TxBPF
1 CCB output
Horizonmacro
2 DCF or 1 DDF
1 CCB output
3 or 4
Horizon II macro
DUP + 1 HCU or 2
DUP and Air
CCBs not supported
3 or 4
Horizon II mini
2 DUP (BowtieCombiner) and Air
CCBs not supported
M-Cell6
2 HCOMB + 1 TxBPF
1 CCB output + 1
CCB extension
Horizonmacro
1 DDF + 1 HCU
1 CCB output + 1
CCB extension
M-Cell6
HCOMB + 1 TxBPF
1 CCB output + 1
CCB extension
Horizonmacro
2 DDF and Air
1 CCB output + 1
CCB extension
M-Cell6
4 HCOMB + 1 TxBPF
1 CCB output + 1
CCB extension
Horizonmacro
2 DDF and Air
1 CCB output + 1
CCB extension
Horizon II macro
1 DUP + 1 DHU or 2
DUP + 1 HCU and Air
CCBs not supported
Number of Carriers
BTS Types
NOTE
A CCB output includes a TxBPF, but a CCB extension does not include it.
68P02900W21-T
5-15
Jul 2010
With the CTU8m radio, the supported configurations per BTS depend on whether the radio is
operated in 4, 6, or 8 carrier mode. Table 5-3 shows the per-sector transit configurations of
the CTU8m in 4-carrier mode. Table 5-4 shows the alternative configurations with CTU8m
operating in the 6-carrier mode and 8-carrier mode respectively.
NOTE
Table 5-3
Cavity combining is not supported with the CTU8m radio.
The CTU8m radio is supported only by the Horizon II macro and Horizon II
mini BTSs.
Transmission configurations CTU8m in 4-carrier mode
Number of
Carriers
BTS Type
Cabinet Transmission
Configurations Wide
Band Combining
Notes
Horizon II macro
Horizon II mini
1 HCD or 2 DUP and Air
Horizon II macro
Horizon II mini
1 DHU + 1 DUP or 1 HCD +

1 DUP and Air
Using one CTU8m with one

CTU2D
Horizon II macro
2 HCD + 2 DUP and Air
Using 2 CTU8ms
Horizon II macro
1 HCD + 1 DHU + 1 DUP

and Air
Using 2 CTU8ms with one

CTU2D
Horizon II macro
2 DHU + 2 DUP and Air
Using 3 CTU8ms
10
12
Table 5-4
Number of
Carriers
BTS Type
Configurations Wide
Band Combining
Horizon II macro
Horizon II mini
12
Horizon II macro
2 HCD and Air
Table 5-5
Number of
Carriers
8
Notes
Using 2 CTU8ms

BTS Type
Horizon II macro
Horizon II mini
Configurations Wide Band
Combining
Notes
If more than six duplexers/combiner units are required to support the radios in a single Horizon
II macro cabinet, a duplexer expansion frame may be fitted above the Horizon II macro cabinet
to provide 12 duplexer/combiner bays.
The RCTU8m radio has two antenna ports which are connected directly to the antennas by
suitable cables. No additional RF hardware is required.
5-16
68P02900W21-T
Jul 2010
Transmit planning actions
CTU2D, CTU8m, and RCTU8m radios may be used together to support carriers that are in
the same cell. However, the cables from each radio to the antennas must not differ in length
by more than 100 m.
Transmit planning actions

Determine the transmit equipment required.
Unused Tx block locations must be covered with a blanking plate for correct air flow and EMC
shielding.
68P02900W21-T
5-17
Jul 2010
EGPRS enabled CTU2/CTU2D configuration
EGPRS enabled CTU2/CTU2D configuration
EGPRS enabled CTU2/CTU2D configuration limitations

EGPRS is a restricted feature. This configuration is supported only when this feature is
unrestricted. If ITS feature is unrestricted and enabled, the EGPRS can be configured on double
density CTU2. The CTU2 radio is supported in the Horizon II macro and Horizonmacro BTS
cabinet platforms. In addition, the CTU2 radio is supported in the M-Cell6 and M-Cell2 cabinet
platforms when the CTU2 Adapter is used. CTU2D is supported on Horizon II macro, Horizon
II mini, and Horizon II micro Sites only. When the master cabinets are Horizon II macro and
Horizon II mini, the extension Horizon II cabinets support CTU2D; M-Cell and Horizon extension
cabinets do not support CTU2D and remain OOS.
EGPRS general configuration

The EGPRS feature needs additional backhaul to provision EGPRS carriers. The additional
backhaul is either seven DS0s to implement EGPRS on a BCCH carrier or eight DS0s to
implement EGPRS on a non- BCCH carrier, if VersaTRAU feature is restricted. If VersaTRAU
feature is unrestricted, the backhaul for an EGPRS carrier can be configured using the
rtf_ds0_count parameter.
If VersaTRAU is restricted, the maximum number of EGPRS carriers that can be equipped for a
three sector site is 21. The total number of E1s available at a Horizonmacro or Horizon II macro
site is 6. Some numbers of these DS0s are required for RSLs to the BSC (up to 6 with MCUF,
and Horizon II site controller). The rest of the DS0s are available for TRAU. An entire RTF must
be configured to the same physical E1. This allows configuration of three non-BCCHs.
EGPRS RTFs on each E1 (using 24 DS0s) for a total of 18 EGPRS non-BCCH carriers.
The remaining 7 DS0s can be used for BCCH RTFs and RSLs. Therefore, the worst-case
configuration when every possible timeslot is configured as an EGPRS carrier in a three-sector
site is 21 carriers:
18 (3x6) non-BCCH (with 8 air timeslots on each RTF) carriers at a site.
Three BCCH carriers (with 7 air timeslots on each RTF).
The remaining DS0s are available for use as RSLs.
If VersaTRAU is unrestricted, the maximum number of EGPRS carriers for the same
configuration can be up to 24. If the recommended non-aggressive backhaul of five DS0s per
EGPRS carrier is used, six EGPRS carriers (using 30 DS0s) can be configured on each E1. This
would need four E1s for the 24 EGPRS carriers leaving the remaining four DS0s available
for RSLs.
BaseBand Hopping (BBH)

There are several restrictions for an EGPRS enabled CTU2/CTU2D.
5-18
68P02900W21-T
Jul 2010
Broadcast Control CHannel (BCCH) RTF configuration
Baseband hopping (BBH) is only allowed with other EGPRS enabled CTU2 radios in the same
hopping group. Table 5-6 and Table 5-7 show the restrictions for the Horizon II macro Site
Controller and the Horizonmacro Site Controller respectively. In ITS mode, EGPRS double
density carrier A and its pair are excluded for BBH. For BBH restriction aspect, CTU2D PWR
mode and ITS mode are identical. In CTU2D CAP mode, the BBH restrict ion on carrier A is
the same as PWR mode, and GMSK carrier B supports for BBH. In CTU2D ASYM mode, all the
EGPRS carriers (in SD/DD/Capacity mode) within the site are removed from BBH system.
For the cell with extended PDCH, BBH is disabled.
NOTE
Table 5-6 indicates that BBH is not permitted with EDGE enabled CTU2s when
Horizonmacro is the Master Site Controller. BBH is only permitted with EDGE enabled
CTU2s when they are controlled by the Horizon II macro Site controller as Master.
Table 5-6 BBH capability for Horizon II macro Site Controller

CTU2 (SD
EGPRS)
CTU2 (DD
GSM)
CTU2 (SD
GSM)
CTU (SD GSM)
CTU2 (SD EGPRS)
CTU2 (DD GSM)
CTU2 (SD GSM)
CTU (SD GSM)
Table 5-7 BBH capability for Horizonmacro Site Controller

CTU2 (SD
EGPRS)
CTU2 (DD GSM)
CTU2 (SD
GSM)
CTU (SD GSM)
CTU2 (SD EGPRS)
CTU2 (DD GSM)
CTU2 (SD GSM)
CTU (SD GSM)
Broadcast Control CHannel (BCCH) RTF configuration

The Broadcast control channel (BCCH) Radio Transceiver Function (RTF) should be configured
as a 64 k carrier. For EGPRS, the only radio that supports 64 k is the CTU2/CTU2D. It is not
necessary that the CTU2/CTU2D used for the BCCH RTF is EGPRS enabled.
{34416} If the Traffic Packing with PA Bias feature is enabled in Horizon II sites with mixed
radios, to maximize power savings, the BTS software prefers to allocate the BCCH carrier to
non-power-saving radios. Power savings delivered by this feature increase with the number of
TCHs in the BCCH available for traffic allocation, providing priority of the BCCH carrier in traffic
allocation (for example, chan_alloc_priority) is configured to be higher than any other carriers.
68P02900W21-T
5-19
Jul 2010
Carrier equipment (transceiver unit)
Carrier equipment (transceiver unit)
Introduction
The transceiver unit for Horizon II macro and Horizon II mini is the CTU2/CTU2D/ {34371G}
CTU8m/RCTU8m. The CTU2/CTU2D can be configured to operate in single density (single
carrier) or double density (2 carrier) mode. The CTU2 can also be used as a CTU replacement
(subject to restrictions) in a Horizonmacro cabinet, but NOT an outdoor cabinet.
NOTE
CCBs are not supported by the CTU2/CTU2D (refer to Chapter 1 Introduction to
planning for more information of CTU2D configuration).
The CTU8m/RCTU8m has two transmission ports and each port can be configured to operate
up to {35200G} 4 carriers mode. The RCTU8m is a remote radio head, it can be deployed a
maximum of 1000 m away per hop.
NOTE
The 2 carriers mode is compliant to 3GPP Rel-8 MCBTS Class 1 specification and 3 and
{35200G} 4 carriers mode are compliant to 3GPP Rel-8 MCBTS Class 2 specification.
The transceiver unit for Horizonmacro is a CTU. This is eventually phased out and replaced by
the CTU2, as used in the Horizon II macro
For rules relating to replacement of a CTU with a CTU2, contact your Motorola Local Office.
The transceiver unit for Horizonmicro2 and Horizoncompact2 is a DTRX.
The transceiver unit for M-Cell2 and M-Cell6 is either a TCU or a TCU-B. The TCU-B is an
enhancement of the original TCU and can be used as a direct replacement for the TCU. However,
TCU-B has the following differences:
The TCU-B only supports GSM/EGSM900.
The TCU-B cannot be used as a SCU (in pre M-Cell equipment).
References to TCU in the text include TCU-B, except where stated otherwise.
AMR and GSM half rate are supported on all transceiver equipment described here, except
for the DTRX.
Extended PDCH can be supported only on CTU2/CTU2D radios. For a BTS with extended PDCH,
asymmetric mode shall be disabled for all the CTU2Ds in the BTS.
5-20
68P02900W21-T
Jul 2010
Restrictions in CTU2s usage in Horizonmacro BTSs
Restrictions in CTU2s usage in Horizonmacro BTSs

The following restrictions apply when CTU2s are used to replace CTUs in Horizonmacro BTSs:
CTU2s cannot be used in Horizonmacro outdoor BTSs.
CTU2s cannot be used in Horizonmacro indoor BTSs that are powered from 110 V ac.
BBH is only supported in single density mode when CTU2s are used in Horizonmacro
indoor BTSs.
CCBs are not supported when CTU2s are used in Horizonmacro indoor BTSs.
RF power output from the CTU2s is reduced.
Fully populated Horizonmacro cabinets that contain two or more CTU2s need three PSUs.
PSU redundancy is not available in these configurations.
CTU/CTU2 power supply considerations

Under normal circumstances, the Horizonmacro only needs two power supply modules (PSMs)
to power six CTUs, and the third PSM slot can be used either for a redundant PSM or for an
optional hold-up battery module (in ac-powered systems).
These power supply requirements change if CTU2s are used in the Horizonmacro cabinet.
Depending on the number of CTU2s used, it can be necessary to install a third PSM, thus losing
the internal battery backup facility. In cases where battery backup is required, an external
battery backup unit (BBS) needs to be added. In addition, where a third (redundant) PSM is
already installed, redundancy is lost. Table 5-8 lists the CTU/CTU2 combinations and power
supply requirements in Horizonmacro and Horizon II macro cabinets. This table applied to
both GPRS and the EGPRS feature overlay.
NOTE
Table 5-8 does not include Horizon II mini, as Horizon II mini needs only one power
supply as minimum/maximum.
Table 5-8 CTU/CTU2 power requirements

Horizonmacro
Horizon II macro
Number of
CTUs
Number of
CTU2s
Number of power
supplies required
Number of
CTU2s
Number of power
supplies required
1
Continued
68P02900W21-T
5-21
Jul 2010
CTU/CTU2 power supply considerations
Table 5-8 CTU/CTU2 power requirements (Continued)

Horizonmacro
Horizon II macro
Number of
CTUs
Number of
CTU2s
Number of power
supplies required
Number of
CTU2s
Number of power
supplies required
NOTE
The Horizon II macro always has a spare fourth power supply slot available for either
a redundant power supply or for a hold-up battery module (in ac-powered cabinets).
Table 5-9 lists the CTU/CTU2 combinations and power supply requirements in M-Cell6 and
M-Cell2 cabinets. This table is independent of the CTU2 operating mode or feature overlay. This
table assumes that slots that do not use CTU2 adapters are populated with TCUs.
5-22
68P02900W21-T
Jul 2010
Table 5-9 CTU/CTU2 power requirements for M-Cell cabinets

Number of CTU2 Adapters
Number of power supplies required
M-Cell6 AC Indoor:
16
14
56
14
56
2 (add one more for redundancy)
1 (add one more for redundancy)
M-Cell6 AC Outdoor:
M-Cell6 DC Indoor:
M-Cell2 AC Indoor and M-Cell2

AC Outdoor:
The following factors should be considered when planning carrier equipment:
The number of carriers based on traffic considerations.
Plan for future growth.
Allowance must be made for BCCH and SDCCH control channels. Information about how
to determine the number of control channels required is in the Control channel calculations
on page 3-52 section in Chapter 3 BSS cell planning.
One transceiver unit is required to provide each RF carrier. However, with the introduction
of the CTU2/CTU2D this is no longer true. The CTU2/CTU2D is capable of single and
double density operation for GSM/GPRS; one CTU2/CTU2D can support one RF carrier or
be configured to support two RF carriers. The exception to this is for EGPRS. An EGPRS
enabled CTU2 can only be configured in single density mode (that is, one CTU2 per
carrier). If ITS feature is unrestricted and enabled, an EGPRS enabled CTU2 can also be
configured in double density mode but with timeslot blanking on the paired carrier. With
the introduction of CTU2D more modes, that is, CAP and ASYM, can support EGPRS with
double density without timeslot blanking.
Include redundancy requirements. Redundancy can be achieved by installing excess

capacity in the form of additional transceiver units.
Plan the number of power supplies required in accordance with the number of transceivers
required.
68P02900W21-T
5-23
Jul 2010
Transceiver planning actions
{34416} Traffic packing for power saving. The amount of power saved by the feature is
proportional to the number of TSs re-allocated from power-saving radios onto the BCCH
and the non-power-saving radios. Power savings delivered by this feature increase with the
traffic load if the percentage of non-power-saving radios is adequate for traffic packing.
Power-saving from traffic packing reaches its maximum when the percentage of the radios
is 50%. Adding more power-saving radios beyond this only generates power savings from
their sleeping capabilities in idle state.
Transceiver planning actions

Determine the number of transceivers required and the number of power supplies required
to power the transceivers.
5-24
68P02900W21-T
Jul 2010
Micro base control unit (microBCU)
Micro base control unit (microBCU)
Introduction
The microBCU (or m BCU) is the macro/microcell implementation of a BTS site controller.
The following factors should be considered when planning the m BCU complement:
Horizon II macro/Horizon II mini

{FR35414} The Horizon II macro/Horizon II mini is similar to the Horizonmacro in that it
has a built-in digital module shelf. However, unlike Horizonmacro, the NIU is integrated
on the HII Site Controller (HIISC or HIISC2-S or HIISC2-E) and external FMUXs and
BPSMs are not required. The digital module shelf can be equipped for redundancy and/or
additional E1/T1 link capacity with the addition of a redundant matching Site Controller.
Horizonmacro
Each Horizonmacro cabinet has a built-in digital module shelf. This provides the
Horizonmacro equivalent of M-Cell6 microBCU cage functionality.
The digital module shelf can be equipped for redundancy and/or additional E1 link capacity
with the addition of a redundant MCUF, NIU, FMUX, and BPSM.
M-Cell6
Each M-Cell6 cabinet needs one microBCU cage. Two microBCU cages can be equipped
for redundancy and/or additional E1 link capacity with the addition of a redundant MCU,
NIU, and FOX/FMUX.
M-Cell2
The first M-Cell2 cabinet needs one microBCU2 cage. Two microBCU2 cages can be
equipped for redundancy and/or additional E1 link capacity. Additional cabinets do not
need microBCU2 cages.
MicroBCU planning actions

For M-Cell equipment, determine the number of microBCUs required.
68P02900W21-T
5-25
Jul 2010
Network interface unit (NIU) and site connection
Network interface unit (NIU) and site connection
Introduction
The NIU provides the interface for the Horizon II macro, Horizonmacro or M-Cell2/6 BTS
to the terrestrial network.
NOTE
M-Cellcity and M-Cellcity+ are fitted with a single NIU-m only.
The equivalent modules in Horizoncompact2 and Horizonmicro2 are

RHINO/DINO.
Depending on the BTS equipment installed, the following factors should be considered when
planning the NIU complement:
5-26
Both Horizon IImacro and Horizon IImini require a Horizon II site controller (either the
HIISC or either the HIISC2-S or HIISC2-E).
NIU functionality is integrated into the Horizon II site controller (either the HIISC or either
the HIISC2-S or HIISC2-E). From a functional standpoint, the Integrated NIU functions the
same as the standalone NIU with the exception that support for 4 RSL links per E1 and a
maximum of 6 E1s is now supported in Horizon II macro and Horizon II mini.
A minimum of one Horizon II site controller (either the HIISC or either the HIISC2-S or
HIISC2-E) is required in the master cabinet for each Horizon II macro BTS site. Horizon II
mini does not support hardware redundancy.
For a Horizon II macro master cabinet, redundancy for the NIU functionality depends on a
matching redundant Horizon II site controller (either the HIISC or either the HIISC2-S
or BBU-E). If a redundant HIISC is installed, a redundant site expansion board is also
required. Slave Horizon II macro cabinets connected to the master cabinet also require
redundant site expansion boards and redundant XMUXs.
68P02900W21-T
Jul 2010
NOTE
For Horizon II macro only: The integrated NIU within the redundant Horizon II
site controller (HIISC or HIISC2-S or HIISC2-E) has connectivity to all the E1 links
for that site through the use of relays and switches. The redundant Horizon II site
controller (HIISC or HIISC2-S or HIISC2-E) can be switched automatically to become
the main Horizon II site controller, taking over all duties of the main Horizon II site
controller (including controlling all E1 links at that site) through a BTS reset.
Horizonmacro and M-Cell
The first NIU in a digital module shelf (Horizonmacro) or microBCU cage (M-Cell6) can
interface two E1 links.
The second NIU in a digital module shelf or microBCU cage can interface one E1 link.
Each E1 link provides 31 (E1) usable 64 kbps links.
A minimum of one NIU is required for each BTS site.
One NIU can support two MCUFs (Horizonmacro) or two MCUs (M-Cell6).
The NIU feeds the active MCUF/MCU.
To calculate the number of 64 kbps links required, view the site as consisting of its own
equipment, and that of other sites, which are connected to it by the drop and insert (daisy
chain) method.
Two 64 kbps links are required for each active transceiver.
A 64 kbps link is required for every RSL (LAPD signaling channel) to the site. In
the drop and insert (daisy chain) configuration, every site needs its own 64 kbps
link for signaling.
Redundancy for the NIU module depends on the number of redundant E1 links to the site.
Plan for a maximum of two NIUs per digital module shelf or microBCU cage (three E1 links).
Plan for a maximum of one NIU per microBCU2 cage for M-Cell2 cabinets (two E1 links).
The minimum number of NIUs and microBCU cages required for a given number of E1 links to a
single M-Cell cabinet is shown in Table 5-10.
Table 5-10 Site connection requirements for M-Cell2 and M-Cell6

Number of E1 links
Minimum number
of NIU required
Number of BCU
cages required
Notes
M-Cell2 and M-Cell6
M-Cell2 and M-Cell6
M-Cell6
M-Cell2 and M-Cell6

Continued
68P02900W21-T
5-27
Jul 2010
NIU planning actions
Table 5-10
Site connection requirements for M-Cell2 and M-Cell6 (Continued)
Number of E1 links
Minimum number
of NIU required
Number of BCU
cages required
Notes
M-Cell2 and M-Cell6
M-Cell6 only
M-Cell6 only
NOTE
Only one digital module shelf is installed in the Horizon II macro and Horizonmacro.
E1 link interfaces
For driving a balanced 120 ohm 3 V (peak pulse) line, use a BIB.
For driving a single ended 75 ohm 2.37 V (peak pulse) line, use a T43.
NIU planning actions

Determine the number of NIUs required.
5-28
68P02900W21-T
Jul 2010
BTS main control unit
BTS main control unit
Introduction
The main control unit provides the main site control functions for a BTS. The main control unit
used depends on the BTS equipment:
Both Horizon II macro and Horizon II mini use a Horizon II macro site controller (HIISC or
HIISC2-S or HIISC2-E) with triple XMUX.
Horizonmacro uses a main control unit with dual FMUX (MCUF).
M-Cell6 and M-Cell2 use a main control unit (MCU).
NOTE
The HIISC, HIISC-S, and HIISC2-E can be used only in Horizon II macro.
The MCUF is backward compatible with the MCU and can be used in
M-Cell6 and M-Cell2 BTSs.
Horizon II mini is a new small macro BTS and the HIISC (or HIISC2-S or
HIISC2-E) used within can support a maximum of 24 RF carriers across
the sites.
The HIISC (or HIISC2-S or HIISC2-E) used in Horizon II macro can also
support 24 RF carriers.
{34371G} The BBU-E is required for CTU8m and RCTU8m.

The GSM BBU (Base Band Unit) module is a mezzanine baseband processing card attached to
the Horizon II Site Controller 2 (HIISC2) within the GSM Horizon II BTS family. It is responsible
for majority of the digital baseband processing for multiple radio units (for example, channel
coding/decoding, some filtering, demodulation, equalization, modem control loops, and so
on) and the Radio Sub-System processing.
The BBU-E has three D4+ SFP ports to connect to the (R)CTU8ms using fiber links or electrical
cables. (The electrical cable is capable only inside the cabinet).
68P02900W21-T
5-29
Jul 2010
Horizon II macro
The following factors should be considered when planning the HII site controller (either HIISC
or HIISC2-S or HIISC2-E) complement for a Horizon II macro site:
Only the master Horizon II macro cabinet needs a HII site controller (either HIISC or
HIISC2-S or HIISC2-E).
For redundancy, add a second matching site controller in the digital module shelf of the
master cabinet. This also provides redundancy for the NIU and XMUX as well, since
they are integrated in the site controller.
NOTE
This redundancy configuration also needs a redundant site expansion board in
all Horizon II macro cabinets at sites where more than one cabinet is installed.
Horizon II mini
Only the master Horizon II mini cabinet needs a HIISC (or HIISC2-S or HIISC2-E). The
HIISC (or HIISC2-S or HIISC2-E) used can support a maximum of 24 RF carriers across
the sites.
There is no accommodation for redundancy in this BTS.
Horizonmacro
The following factors should be considered when planning the MCUF complement for a
Horizonmacro site:
Only the master cabinet needs an MCUF.
An optional 20 MB PCMCIA memory card is installed for non-volatile code storage.
For redundancy, add another MCUF in the digital module shelf of the master cabinet.
M-Cell6 and M-Cell2

The following factors should be considered when planning the MCU complement for an M-Cell6
or M-Cell2 site:
5-30
Only the master cabinet needs an MCU.
An optional 20 MB PCMCIA memory card is installed for non-volatile code storage.
For redundancy, add another mBCU cage and MCU in the master cabinet.
68P02900W21-T
Jul 2010

considerations Horizon II macro/Horizon II mini as expansion cabinet
Planning
BBU-E
{34371G}
The BBU-E can be equipped only in the master Horizon II cabinet. The CTU8m can be populated
in both master and slave cabinet, but must be connected back to the BBU-E SFP ports in the
master cabinet.
The BBU-E used in the Horizon II can support up to 24 RF carriers, which can be a mixture
of CTU/CTU2/CTU2D and (R)CTU8ms, {9810G} in any combination of GMSK or/and 8PSK
modulation (including half rate, full rate, GPRS and EDGE carriers).
NOTE
All the carriers on one CTU8m/RCTU8m radio can only be allocated to one BBU-E
board. This constraint should be considered during the CTU8m/RCTU8m and BBU-E
planning.
The proper topologies for the BBU-E(s) and (R)CTU8m (specified in CTU8m D4+ Link on page
5-44 and Chapter 12 Hardware and compatibility) should be selected to ensure the above
capacity and redundancy is achieved.
Planning considerations Horizon II macro/Horizon II mini as

expansion cabinet
This information describes the factors that require to be taken into account if Horizon II macro
cabinets are used to expand existing Horizonmacro or M-Cell6 sites.
Horizon II macro slave BTS planning considerations
An XMUX is required instead of a HIISC (or HIISC2-S or HIISC2-E) in the slave cabinet.
A site expansion board is required.
If redundancy is required, a redundant XMUX and redundant site expansion board must be
installed.
Horizon II mini slave BTS planning considerations
An XMUX is required instead of a HIISC (or HIISC2-S or HIISC2-E) in the slave cabinet.
A site expansion board is required.
The Horizon II mini does not support hardware redundancy.
68P02900W21-T
5-31
Jul 2010
Planning actions
Horizonmacro master BTS planning considerations
Only the master cabinet needs an MCUF.
A 20 MB PCMCIA memory card running CSFP must be installed in the MCUF to

accommodate the use of the CTU2 transceiver from a code storage standpoint. If the site is
equipped with a redundant MCUF, the PCMCIA is also mandatory for the redundant MCUF.
M-Cell6 master BTS planning considerations
NOTE
Due to expansion limitations, M-Cell2 BTSs cannot be used with Horizon II macro (or
Horizonmacro) cabinets.
Only the master cabinet needs an MCU.
A 20 MB PCMCIA memory card running CSFP must be installed in the MCU to

accommodate the use of the CTU2 transceiver from a code storage standpoint.
If the site is equipped with a redundant MCU, the PCMCIA is also mandatory
for the redundant MCU.
The master cabinet must have an FMUX installed to communicate with the
Horizon II macro BTS.
Planning actions
Determine the number of site controllers site controllers (either HIISC or HIISC2-S or HIISC2-E)
required.
Horizonmacro
Determine the number and configuration of MCUFs required.
M-Cell6 and M-Cell2

Determine the number and configuration of MCUs required.
5-32
68P02900W21-T
Jul 2010
Cabinet interconnection
Cabinet interconnection
Introduction
Horizon II macro
The XMUX multiplexes and demultiplexes full duplex transceiver links between a site expansion
board and up to six CTU2s/CTU2Ds in a Horizon II macro expansion cabinet.
Horizon II mini
The XMUX multiplexes and demultiplexes full duplex transceiver links between a site expansion
board and two CTU2s/CTU2Ds in a Horizon II mini expansion cabinet.
Horizon II micro
Horizon II micro supports up to three cabinets. It can be connected to either another Horizon
II micro, all Horizon BTSs, or M-Cell6 through an expansion board such as the Horizon II
macro Site I/O.
Horizonmacro
The FMUX multiplexes and demultiplexes full duplex transceiver links between an MCUF
and up to six CTUs.
M-Cell6 and M-Cell2

The FOX provides the bidirectional electrical to optical interface between an MCU and FMUX
and up to six TCUs.
The FMUX multiplexes and demultiplexes electrical connections for up to six TCUs or CTU2
Adapters onto a single fiber optic connection operating at the rate of 16.384 Mbps.
NOTE
In slave cabinets with CTU8m only, Site Expansion/XMUX cards are not required.
68P02900W21-T
5-33
Jul 2010
Horizon II macro
The following factors should be considered when planning the XMUX complement:
An XMUX is required in each Horizon II macro expansion cabinet.
The master Horizon II macro cabinet does not need an XMUX as a triple XMUX is
integrated on the HII site controller (HIISC or HIISC2-S or HIISC2-E).
There is no support for hardware redundancy in Horizon II mini.
A site expansion board (unique to Horizon II macro) is required for the master and every
expansion cabinet in the Horizon II macro BTS site when expansion is required (see
Table 5-11).
Redundancy needs duplication of the HII site controller (HIISC or HIISC2-S or HIISC2-E)
in the master cabinet and all XMUXs and site expansion boards.
Mixed redundancy is only supported between HIISC2-S and HIISC2-E types.
Table 5-11 Horizon II macro XMUX expansion requirements

Cabinet
Master
Expansion 1
Expansion 2
0 (master)
None
1 site expansion
board only
1 XMUX + 1 site
expansion board
1 site expansion
board only
1 XMUX + 1 site
expansion board
1 XMUX + 1 site
expansion board
1 site expansion
board only
1 XMUX + 1 site
expansion board
1 XMUX + 1 site
expansion board
Expansion 3
1 XMUX + 1 site
expansion board
Horizon II mini
The following factors should be considered when planning the XMUX complement:
5-34
An XMUX is required in each Horizon II mini expansion cabinet.
The master Horizon II mini cabinet does not need an XMUX, as a triple XMUX is integrated
on the HII site controller (HIISC or HIISC2-S or HIISC2-E).
A site expansion board (unique to Horizon II macro and Horizon II mini) is required for
the master and every expansion cabinet in the Horizon II macro BTS site when expansion
is required (see Table 5-12 to Table 5-14).
68P02900W21-T
Jul 2010
Horizon II mini
Table 5-12 Horizon II mini only network XMUX expansion requirements

Cabinet
Master
Expansion 1
Expansion 2
0 (master)
None
1 site expansion
board only
1 XMUX + 1 site
expansion board
1 site expansion
board only
1 XMUX + 1 site
expansion board
1 XMUX + 1 site
expansion board
1 site expansion
board only
1 XMUX + 1 site
expansion board
1 XMUX + 1 site
expansion board
Expansion 3
1 XMUX + 1
site expansion
board
Table 5-13 Horizon II macro as master - Horizon II mini as expansion XMUX

requirements
Cabinet
Master
Expansion 1
Expansion 2
0 (master)
None
1 site expansion
board only
1 XMUX + 1 site
expansion board
1 site expansion
board only
1 XMUX + 1 site
expansion board
1 XMUX + 1 site
expansion board
1 site expansion
board only
1 XMUX + 1 site
expansion board
1 XMUX + 1 site
expansion board
Expansion 3
1 XMUX + 1 site
expansion board
Table 5-14 Horizonmacro as master - Horizon II mini as expansion XMUX/FMUX

requirements
Cabinet
Master
Expansion 1
Expansion 2
0 (master)
None
None
1 XMUX + 1 site
expansion board
None
1 XMUX + 1 site
expansion board
1 XMUX + 1 site
expansion board
1 FMUX
1 XMUX + 1 site
expansion board
1 XMUX + 1 site
expansion board
Expansion 3
1 XMUX + 1 site
expansion board
NOTE
The Horizon II mini is a micro family BTS and the HII site controller (HIISC or
HIISC2-S or HIISC2-E) used has RF limitations of 24 carriers per site in a Horizon II
mini network.
68P02900W21-T
5-35
Jul 2010
Planning considerations - Horizon II macro as master cabinet
Horizonmacro
The following factors should be considered when planning the FMUX complement:
An FMUX is not required in the master cabinet for two or three cabinet configurations
(see Table 5-15). An FMUX is required in each expansion cabinet.
A fourth Horizonmacro cabinet needs one FMUX plus one FMUX in the master cabinet
(see Table 5-15).
Redundancy needs duplication of an FMUX and associated MCUF.
Table 5-15 Horizonmacro as master - Horizonmacro as expansion FMUX requirements

Cabinet
Master
Expansion 1
Expansion 2
0 (master)
None
None
1 FMUX
None
1 FMUX
1 FMUX
1 FMUX
1 FMUX
1 FMUX
Expansion 3
1 FMUX
M-Cell6 and M-Cell2

The following factors should be considered when planning the FOX/FMUX complement:
A FOX board is required for more than two TCUs.
Each additional M-Cell6 cabinet needs a minimum of one FOX and FMUX plus one FMUX
in the first cabinet.
Redundancy needs duplication of all FOX and FMUX boards and associated MCU and
microBCU cages.
Planning considerations - Horizon II macro as master cabinet
NOTE
Due to expansion limitations, M-Cell2 BTSs cannot be used with Horizon II macro
cabinets.
The following factors should be considered while planning to use a Horizon II macro as a master
cabinet with Horizonmacro or M-Cell6 expansion cabinets:
5-36
A site expansion board is required in the Horizon II macro master cabinet.
68P02900W21-T
Jul 2010
Planning considerations - Horizon II mini as master cabinet
An XMUX is not required in the Horizon II macro master cabinet.
Each Horizonmacro or M-Cell6 slave cabinet must contain an FMUX (replaces the
MCUF/MCU).
For redundancy, the master Horizon II macro cabinet needs an additional HII site controller
(HIISC or HIISC2-S or HIISC2-E) and site expansion board. Each Horizonmacro slave
cabinet needs an additional FMUX, and each M-Cell6 slave cabinet needs an additional
FMUX and FOX.
Planning considerations - Horizon II mini as master cabinet
NOTE
Horizon II mini as a Master cabinet and Macro family BTS as expansions are
considered a non-Motorola approved configuration.
Horizon II mini outdoor variant needs a -230 V DC supply.
XMUX/FMUX/FOX planning actions

Horizon II macro
Determine the number of XMUXs required (applies to expansion cabinets only).
Horizonmacro
Determine the number of FMUXs required.
M-Cell6 and M-Cell2

Determine the number of FOX/FMUXs required.
NOTE
M-Cell2 BTSs are not supported as an expansion to Horizon II macro or Horizonmacro
cabinets.
Site expansion board planning actions (Horizon II macro only)

If more than one cabinet is to be used at a site, determine the number of site expansion boards
required.
68P02900W21-T
5-37
Jul 2010
Battery back-up provisioning
Battery back-up provisioning
Introduction
The Horizon II outdoor enclosure can be provisioned to have battery back-up in case of power
failure at the site.
The following factors influence the planning for battery back-up for a Horizon II outdoor
enclosure.
Two optional internal batteries to provide a minimum of 5 minutes back-up.
An optional external battery cabinet has dimensions 1555 x 799 x 760 mm and weight
110 kg when empty, 590 kg with 16 SBS C11 batteries included. This cabinet can house
up to 16 Hawker SBS C11 battery cells (8 strings) or equivalent. Two string sets can
provide a battery back-up for about one hour; a full cabinet can provide battery back-up
for about four hours.
The intermediate battery back-up solution consists of a frame fixed to the ground housing
the batteries and an oversized shroud fitted over it fixed onto the main cabinet.
Size: 350 mm wide x 687 mm deep x 1441 mm high.
Weight: Without batteries including metal work and interconnect cables, the weight
is 40 kg. With batteries, the weight is 160 kg.
The frame can house a maximum of two strings of SBS C11 batteries (each string consisting of 2
batteries) which provides 1 hour back-up power.
NOTE
The back-up times for the internal, intermediate, and external battery backup are for
a fully loaded system in a worst case scenario. Longer back-up times are achieved
under a typical load.
There is a visual display of outdoor battery voltages.
5-38
68P02900W21-T
Jul 2010
External power requirements
External power requirements
Introduction
Macrocell cabinets and Microcell enclosures can operate from a variety of power supplies.
The following factors should be considered when planning the power supply requirements:
Horizon II macro
Horizon II macro power requirements are determined by the BTS cabinet type.
Indoor: +27 V dc, -48 V dc, 110-230 V ac
NOTE
+27 V dc is not allowed for CTU8m radios.
Outdoor: 200-240 V ac single/3-phase only
Horizon II mini
Horizon II mini power requirements are determined by the BTS cabinet type.
Indoor: +27 V dc, -48 V dc, 110-230 V ac
NOTE
+27 V dc is not allowed for CTU8m radios.
Outdoor: 230 V ac only
Horizonmacro
Indoor: +27 V dc, -48 V dc, 230 V ac
Outdoor: 110 V ac single phase, 230 V ac single/3-phase
12 carrier outdoor: 230 V ac single/3-phase
NOTE
Only -48 V dc indoor cabinets can be installed in the 12 carrier outdoor.
68P02900W21-T
5-39
Jul 2010
Power planning actions
Horizonmicro2 and Horizoncompact2

The Horizonmicro2 and Horizoncompact2 enclosures operate from 88 V ac to 265 V ac
power source.
Horizon II micro
The Horizon II micro enclosure operates from 88 V ac to 300 V ac power source.
M-Cell6
The M-Cell6 BTS cabinet can be configured to operate from either a +27 V dc or -48 V/-60
V dc power source (indoor) or 230 V/110 V ac.
M-Cell2
The M-Cell2 BTS cabinet can be configured to operate from either a +27 V dc or 230
V/110 V ac power source.
M-Cellcity and M-Cellcity+

The M-Cellcity and M-Cellcity+ BTS enclosures operate from 88 V ac to 265 V ac power
source.
RCTU8m
The RCTU8m operates from the -48 V dc power source.
Power planning actions

Determine the power supply required.
5-40
68P02900W21-T
Jul 2010
Network expansion using macro/microcell BTSs
Network expansion using macro/microcell BTSs
Introduction
An existing network with previous generations of Motorola equipment such as BTS4, BTS5,
BTS6, TopCell, or ExCell can be expanded using macro/microcell. The Network topology can
be any of those specified in Chapter 2 Transmission systems of this manual. A macro/microcell
BTS can occupy any position in a network.
Expansion considerations
The following factors should be considered when expanding an existing network using
macro/microcell BTS cabinets:
A macro/microcell BTS cannot share a cell with a BTS4, BTS5, BTS6, TopCell, or ExCell.
The rules governing the number of NIUs required at the macro/microcell BTS are given in
Table 5-10 of this chapter.
The rules governing the number of MSIs required at the BSC are given in the Multiple
serial interface (MSI) on page 6-70 section of Chapter 6 BSC planning steps and rules.
Mixed site utilization

To upgrade sites utilizing previous generations of Motorola equipment such as BTS5, BTS4,
BTS6, TopCell, or ExCell, proceed in the following manner:
Sites with previous generation equipment should be expanded with the appropriate
modules, until the cabinets are full.
To expand a previous generation site, the equipment in the previous generation cabinet
must be re-configured so that it serves a complete set of sectors in the target configuration.
A macro site should then be added to the site to serve the remaining sectors.
The macro site should then be connected into the network by daisy chaining it to the
existing site.
Example
To upgrade a BTS6 2/2/2 to a 3/3/3, reconfigure the BTS6 to a 3/3, order an M-Cell omni 3 and
install it to serve the third sector.
68P02900W21-T
5-41
Jul 2010
Line interface modules (HIM-75, HIM-120)
Line interface modules (HIM-75, HIM-120)
Introduction
The line interface modules, HDSL interface module, 75 ohm (HIM-75), and HDSL interface
module, 120 ohm (HIM-120), provide impedance matching for E1, and HDSL links.
The following factors should be considered when planning the line interface complement:
To match a balanced 120 ohm (E1 2.048 Mbps) 3 V (peak pulse) line, use a HIM-120.
To match a single ended unbalanced 75 ohm (E1 2.048 Mbps) 2.37 V (peak pulse) line,
use a HIM-75.
Each HIM-75/HIM-120 can interface four E1 links to specific slots on one shelf.
HIM-75/HIM-120 planning actions

Determine the number to be deployed.
Determine the number of HIM-75s or HIM-120s required.
M inimum number of HIM 75s or HIM 120s =
5-42
N umber of P CU s
2
68P02900W21-T
Jul 2010
DRI/Combiner operability components
DRI/Combiner operability components
Overview
This enhancement improves the operability of the Digital Radio Interface (DRI) and combiner
devices by increasing the flexibility with which these devices can be equipped, unequipped,
and re-equipped.
This feature is achieved by specifying the DRI role in system combining when equipping the DRI.
DRI and combiner relationship

Figure 5-1 illustrates the DRI and combiner relationship.
Figure 5-1 DRI and combiner relationship
COMB 0
First controlling
DRI
DRI 0 0
Second controlling
DRI
DRI 0 1
ti-GSM-DRI_and_combiner_relationship-00126-ai-sw
68P02900W21-T
5-43
Jul 2010
CTU8m D4+ Link
CTU8m D4+ Link
Overview
The Horizon II CTU8m/RCTU8m radio unit implements a separation of the RF radio aspects
and the digital baseband components of the air-interface. The digital baseband aspects of the
air-interface are located on the BBU-E card located in the Horizon II macro, Horizon II mini
and Horizon II micro cabinets. The RF radio aspects are located within the CTU8m/RCTU8m
radio. The CTU8m radio may be located in a Horizon II macro or a Horizon II mini cabinet. The
RCTU8m radio can be located outside a Horizon II cabinet. The BBU-E and CTU8m/RCTU8m
radio are connected by the D4+ interface link.
Figure 5-2 Relationship of the D4+ interface to the CTU8m radio and BBU-E
RCTU8m
RCTU8m
D4+
Link
D4+
Link
D4+
Link
CTU8m
CTU8m
D4+
Link
BBU-E
Horizon II cabinet (master)
Horizon II cabinet (slave)
ti-GSM-relationship_D4+Intf_CTU4 radio_BBU-E-00126.a-ai-sw
The interconnection of CTU8m and RCTU8m radios by the D4+ link topology is independent
of the physical location of the radio. Thus, from a D4+ interface configuration point of view,
a CTU8m in the master cabinet, slave cabinet, or a remotely located RCTU8m radio are all
equivalent. In a D4+ daisy-chain configuration some D4+ links could go to an in-cabinet CTU8m
radio and others to a remote RCTU8m unit without impacting the D4+ configuration.
For RCTU8m installations, it is possible to fit high-speed LTE capable D4+ links that allow the
RCTU8m to be later upgraded to support LTE traffic without requiring a visit to the radio head.
5-44
68P02900W21-T
Jul 2010
Supported topologies
General principles
The D4+ interface system provides a large degree of freedom in configuring the D4+
interconnections. The D4+ interface planning process is independent of the RF planning
process. It is recommended that the RF configuration of the BTS site is first determined before
selecting a D4+ interface configuration to service the CTU8m/RCTU8m radios in that BTS
configuration.
The selection of a particular D4+ configuration may depend on:
The number of CTU8m/RCTU8m radios that are in use at the BTS.
Whether the radios are located in the master Horizon II cabinet or remotely.
The amount of tolerance the BTS must have for single failures (BBU-E, CTU8m/RCTU8m,
or D4+ link).
The number and the cost of the D4+ links employed.
The length of the D4+ interconnections.
Whether the D4+ link should support a future upgrade to LTE.
The permitted configurations of the D4+ links depend on design rules:
D4+ ports in the BBU-E are equivalent (any port may be used in any topology).
D4+ ports in the RCTU8m/CTU8m are equivalent (either port may be used and the ports
may be swapped compared to the topology diagram). The DRI configuration must reflect
the actual D4+ connections deployed.
Up to 6 CTU8m/RCTU8m radios may exist in a single daisy-chain configuration from a

single BBU-E port.
The D4+ media type may be varied for each hop of a D4+ link in a topology.
A single D4+ link can be up to 1 km in length, although the maximum length may be
restricted by the particular D4+ media type used (for example, electrical link, single-mode
fiber link, multimode fiber link).
D4+ optical fiber link connections should be point to point, that is, direct connection
only. Optical repeaters are not supported.
A CTU8m/RCTU8m radio may have more than one D4+ link back to one or more BBU-Es,
although only one of these links is active at any time. This arrangement can provide
protection from BBU-E or D4+ link failure.
In dual BBU-E configurations a BBU-EBBU-E link that is sometimes employed which permits
one BBU-E to communicate with CTU8m/RCTU8m radios connected to the other BBU-E. It also
permits the BTS to load-share the carriers over both BBU-Es for those CTU8m/RCTU8m radios
with a communication path that connects to both BBU-Es.
68P02900W21-T
5-45
Jul 2010
NOTE
The BBU-EBBU-E D4+ link is directional. If it is used to permit carriers on BBU-E
#0 to connect to a CTU8m/RCTU8m unit by BBU-E #1, it is not possible for carriers
hosted on BBU-E #1 to simultaneously use this link to talk to a CTU8m unit through
BBU-E #0.
Standard topologies
This section describes the key supported D4+ link topologies. An RCTU8m radio can
be substituted for any CTU8m radio in the following description. Though the maximum
configuration possible per topology is shown, real implementations may have fewer
CTU8m/RCTU8m employed.
The simplest D4+ topology supported is to have a single D4+ link from each BBU-E to one
CTU8m/RCTU8m radio. This topology limits the impact of a single D4+ link or CTU8m/RCTU8m
radio failure. However, without the BBU-EBBU-E D4+ link it is not possible to load-share
carriers across the two BBU-Es.
Figure 5-3 D4+ Star topology (Single BBU-E)
CTU8m
#0
CTU8m
#1
CTU8m
#2
BBU #0
ti-GSM-D4+_star_topology-00126.b-ai-sw
5-46
68P02900W21-T
Jul 2010
Figure 5-4 D4+ Star topology (Dual BBU-E)
CTU8m
#0
CTU8m
#1
CTU8m CTU8m
#2
#3
BBU #0
CTU8m
#4
CTU8m
#5
BBU #1
ti-GSM-D4+_star_topology-00126.b-1-ai-sw
In situations where there are 1-3 CTU8m/RCTU8m radios, a second BBU-E can be deployed
and a redundant D4+ link per CTU8m radio deployed. Carriers may be load-shared across
both BBU-Es.
NOTE
In normal operations, carriers must remain hosted on a single BBU-E.
If CTU8m is configured on 8 carrier mode and not all carriers are full rate, in
some unexpected situation, not all CTU8m DRIs can be INS due to the BBU-E
capability limitation. So the D4+ redundant-star topology is not recommended
for CTU8m in 8 carrier mode.
Figure 5-5 D4+ Redundant-star topology
CTU8m
#0
CTU8m
#1
BBU-E #0
CTU8m
#2
BBU-E #1
ti-GSM-D4+_red und ant_star_top ology-00126.c-ai-sw
68P02900W21-T
5-47
Jul 2010
In situations where there are more than three CTU8m/RCTU8m units per BBU-E, or where
there is the need for a long fiber run between the Horizon II cabinet and RCTU8m radios, a D4+
daisy-chain configuration may be employed. In this configuration the D4+ path to a CTU8m unit
may traverse intermediate CTU8m radios or a BBU-E. This configuration is sensitive to D4+ link
or CTU8m/RCTU8m radio failures, which can impact several radios.
Figure 5-6
D4+ Daisy-chain topology
CTU8m
CTU8m
CTU8m
CTU8m
CTU8m
CTU8m
CTU8m
CTU8m
CTU8m
CTU8m
CTU8m
CTU8m
#0
#1
#2
#3
#4
#5
#0
#1
#2
#3
#4
#5
BBU-E #0
BBU-E #0
BBU-E #1
ti-GSM-D4+daisy-chain_topolpgy-00126.d-ai-sw
D4+ daisy-chain configurations may be mixed with a D4+ star configuration to provide a simple
means of supporting more than three CTU8m/RCTU8m radios per BBU-E, with failures having
minor consequences than the pure daisy-chain configuration.
Figure 5-7
CTU8m
#0
D4+ Star/daisy-chain topology
CTU8m
#1
CTU8m
#2
CTU8m
#3
CTU8m
#4
CTU8m
#5
BBU-E #0
ti-GSM-D4+_star_daisy_topol-00126.e-ai-sw
5-48
68P02900W21-T
Jul 2010
D4+ redundancy
In the D4+ topology, for increased resilience to D4+ link or CTU8m failures, additional D4+
links can be deployed to provide an additional path around a single point of failure. Although a
redundant D4+ link may be installed, D4+ ports at each end of this link must be disabled in
the BTS configuration. With this arrangement the redundant D4+ link is not visible to the
system in normal operation, and the D4+ system behaves as one of the topologies described in
Standard topologies on page 5-46.
The following diagrams describe the supported topologies where a redundant D4+ link can be
deployed but is disabled in the normal configuration by disabling the D4+ port on the BBU-E.
The disabled D4+ link is marked as a dashed link.
Figure 5-8
CTU8m
#0
D4+ Dual star topology (redundant D4+ link)
CTU8m
#1
CTU8m
#2
CTU8m
#3
BBU #0
CTU8m
#4
CTU8m
#5
BBU #1
ti-GSM-D4+_dual star_topol_rdn_fibr-00126.f-ai-sw
Figure 5-9 D4+ Daisy-chain topology (redundant D4+ link)
CTU8m
#0
CTU8m
#1
BBU-E #0
CTU8m
#2
CTU8m
#3
CTU8m
#4
CTU8m
#5
CTU8m
#0
CTU8m
#1
BBU-E #0
CTU8m
#2
CTU8m
#3
CTU8m
#4
CTU8m
#5
BBU-E #1
ti-GSM-D4+_dual daisy-chain_topol_rdn_fibr-00126.g-ai-sw
68P02900W21-T
5-49
Jul 2010
If the BTS suffers a failure in the normal D4+ topology, the operator has the option to use the
deployed redundant D4+ link. The operator must manually reconfigure the D4+ topology to
work around the point of failure. Links that have failed must have the D4+ ports at each end of
the link disabled to avoid accidentally creating an active D4+ ring configuration.
5-50
68P02900W21-T
Jul 2010
Link selection
Link selection
General principles
D4+ links consist of:
An optical fiber.
SFP transceiver modules, suitable for the optical fiber, which plug into the D4+ ports on
the units at each end of the link.
An exception to this are the in-cabinet electrical D4+ links where the SFP modules are part
of the link assembly.
NOTE
Motorola supplied SFP connector modules are mandatory for D4+ optical fiber
link connections.
The optical fiber used for the D4+ link connectivity should be compliant with
ITU-T G.652.D fiber specifications.
In GSM, the D4+ link operates at 3.072 Gbit/s and the standard SFP modules are rated to
drive the fiber-optic cable at this speed. However, the customer may choose to deploy SFP
modules capable of operating at 6.144 Gbit/s. These faster SFPs allow a GSM CTU8m/RCTU8m
radio to be later converted to support LTE without replacing the fiber or SFPs supporting that
CTU8m/RCTU8m unit. The following table lists the types of D4+ interconnection that may be
employed in a site:
Case
Link Length
Link Type
BBU-E to BBU-E
Intra-cabinet
D4+ Link #1
BBU-E to CTU8m
Intra-cabinet
D4+ Link #1
BBU-E to CTU8m
Inter-cabinet
D4+ Link #2
CTU8m to CTU8m
Intra-cabinet
D4+ Link #1
CTU8m to CTU8m
Inter-cabinet
D4+ Link #2
BBU-E to RCTU8m
100m
D4+ Link #3
BBU-E to RCTU8m
>100m or custom
cable
D4+ Link #5
CTU8m to RCTU8m
100m
D4+ Link #3
CTU8m to RCTU8m
>100m or custom
cable
D4+ Link #5
RCTU8m to RCTU8m
100m
D4+ Link #4
RCTU8m to RCTU8m
>100m or custom
cable
D4+ Link #5
7
8
9
10
11
68P02900W21-T
Interconnections
5-51
Jul 2010
Link selection
Figure 5-10 D4+ link types (illustrative)
RCTU8m
RCTU8m
RCTU8m
Case #6
D4+ Link #3
Case #7
D4+ Link #5
Case #9
D4+ Link #5
RCTU8m
RCTU8m
RCTU8m
Case #11
D4+ Link #5
Case #10
D4+ Link #4
Case #8
D4+ Link #3
CTU8m
CTU8m
Case #4
D4+ Link #1
CTU8m
Case #5
D4+ Link #2
Case #2
D4+ Link #1
CTU8m
CTU8m
Case #4
D4+ Link #1
Case #3
D4+ Link #2
Case #1
D4+ Link #1
BBU-E
BBU-E
Horizon II Master Cabinet
Horizon II Slave Cabinet

ti-GSM-D4+ link types (illustrative)-00126.g-1-ai-sw
D4+ Link #1: Electrical intra-cabinet D4+ link

This D4+ cable is used to interconnect BBU-E cards and CTU8m radios located within the
same Horizon II cabinet. Motorola supplies an electrical cable for this link that is supplied
pre-terminated with an SFP transceiver module at each end. This cable supports both the GSM
3.072 Gbit/s and LTE 6.144 Gbit/s D4+ data rates.
NOTE
To prevent EMC interference issues, these electrical cables must not be used to
make connections outside the cabinet.
D4+ Link #2: Inter-cabinet D4+ link

D4+ interconnections that exit a cabinet use a multi-mode fiber-optic cable. The Motorola
BBU-CTU8m multi-mode fiber used must be matched to Motorola multi-mode fiber SFPs at
the BBU-E / CTU8m units.
5-52
68P02900W21-T
Jul 2010
Link selection
D4+ Links #3 & #4: Multi-mode D4+ links

For D4+ links that are not completely placed within a single cabinet, where the link length is
100 m, Motorola supplies a range of different multi-mode fiber-optic cables. These cables are
available in various lengths such as: 6 m, 20 m, 40 m, 60 m, 80 m, and 100 m.
The RCTU8m-BBU cable supports connections from a BBU-E or CTU8m radio inside a Horizon
II cabinet to the RCTU8m radio. This cable is supplied with a weather sealing cable gland
at the RCTU8m end.
The RCTU8mRCTU8m cable supports connections between two RCTU8m radios. This cable is
provided with weather sealing cable glands at each end of the fiber.
In addition to the cable, the units at each end of the D4+ link must be fitted with a Motorola
multi-mode SFP transceiver module. The SFP in the CTU8m/RCTU8m radio may be a 3.072
Gbit/s GSM-capable SFP or a 6.144 Gbit/s GSM/LTE module.
For links that are required to support the 6.144 Gbit/s LTE data rate the maximum cable length
required is 80 m. For link lengths greater than 80 m, a single-mode optical fiber should be
deployed (as discussed the following section).
D4+ Link #5: Single mode D4+ link

If a D4+ link length is more than 100 m, a single mode fiber optic cable must be employed.
This D4+ cable may be up to 1 km in length.
Motorola also provides single mode cables that are made to order for details refer to the
Order Guide. These cables will include a weather sealing cable gland at the ends connecting to
the RCTU8m radio.
Motorola SFPs, supporting this single-mode fiber, must be employed at the unit connected to
each end of the D4+ link. These SFPs may be a 3.072 Gbit/s GSM-capable SFP or a 6.144
Gbit/s GSM/LTE module.
Alternatively, the customer may supply their own single-mode fiber for the D4+ interconnection.
Single mode SFP modules of Motorola support up to 1 km of ITU-T G.652 (03/06) fiber. This
fiber must be fitted with a weather sealing cable gland at the ends connecting to the RCTU8m
radio and terminated with LC-type connectors.
The fiber link, including connections, must deliver a bit error ratio performance better than
10-12 when used with these SFP modules at the 3.072 Gbit/s line rate. The fiber-optic link
budget should be computed for these links, as described in the next section, to ensure correct
operation.
D4+ Link Optical Budget

For short-range D4+ links using multi-mode fiber and SFPs supplied by Motorola it is not
necessary to perform a fiber-optic link power budget calculation. However, with D4+ links using
custom lengths of single-mode fiber (D4+ Link #5) the optical power budget should be verified.
The data sheets of SFP transceivers employed at each end of this D4+ fiber should be checked
to obtain the following key parameter values:
68P02900W21-T
5-53
Jul 2010
Link selection
Parameter
Description
Units
Pmax
SFP maximum optical output power (OMA)
dBm
Ptx
SFP minimum optical output power (OMA)
dBm
Prx
SFP minimum optical input sensitivity (OMA)
dBm
Psat
SFP maximum optical input power at saturation (OMA)
dBm
The single-mode fiber link, including any splices, attenuates the optical signal. This fiber loss
must be obtained by calculation or measurement.
Parameter
Pfibre
Description
Optical fiber attenuation including splices
Typical value
0.4 dB / km
The optical link is subjected to a number of factors that degrades the received signal. These
factors include:
Extinction Ratio Penalty (normally included in the SFP receiver specifications)
Relative Intensity Noise (RIN)
Jitter penalty (DCD deterministic jitter)
Mode Partition Noise penalty
Dispersion / ISI penalty
If the link power budget is marginal, the values for the degrading factors should be computed
using the specifications of the optical-fiber and the SFPs employed. However, for planning 1 km
D4+ links using Motorola supplied parts a simple fixed degradation factor, Ppen, is sufficient.
Other path impairments include the loss encountered at each connector in the link: Pcon.
Finally, it is advised that an engineering margin, Pmargin, is included in the link budget calculation
to ensure that the system continues to operate satisfactorily through the lifetime of the BTS
deployment.
The following table indicates typical values for the discussed factors:
Parameter
Description
Ppen
Transmission penalties (RIN, jitter, and so on)
Pcon
Connector losses
Pmargin
Engineering margin to guarantee reliability
Typical value
2 dB
0.5 dB / connector
3 dB
For short fiber runs it is necessary to ensure that the maximum SFP transmitter power cannot
overload the SFP receiver at the other end of the link.
Pmax Pf ibre Psat

The following equations compute the optical power budget for the D4+ link.
Plink = (Ptx Pf ibre Ppen Pcon ) Prx
5-54
68P02900W21-T
Jul 2010
Recommended D4+ configurations (CTU8m)
To ensure reliability of the link, this optical power budget should exceed the specified
engineering margin:
Plink Pmargin
The following example shows the calculation for a typical 1 km link:
Parameter
Description
Value
Ptx
SFP average optical output power
Pfibre
Fiber losses (included splices): 1km @ 0.4 dB/km
Ppen
Transmission penalties (RIN, jitter, etc.)
2 dB
Pcon
Connector losses: 2 connectors at 0.5

dB/connector
1 dB
Prx
SFP receiver sensitivity @ 10-12 BER
Plink
Link margin: Plink = (Ptx Pf ibre Ppen Pcon )

Prx
-7.2 dBm
0.4 dB
-15.4 dBm
4.8 dB

The following are recommended D4+ interconnection configurations for signal cabinet CTU8m
deployments (Electrical D4+ links are used in all configurations). The deployments depend
on the number of CTU8m radios.
1-3 CTU8m radios

For configurations involving one to three CTU8m radios, D4+ star configurations are
recommended. Each CTU8m radio is provided with a dedicated point-to-point D4+ link to a
BBU-E interface port.
68P02900W21-T
5-55
Jul 2010
Figure 5-11 D4+ configuration for 3 CTU8m radios (non-redundant)
LINK
D4+
2
1
D4+ D4+
1
0
D4+ D4+
1
0
D4+ D4+
1
0
EMPTY
CTU8m
EMPTY
CTU8m
EMPTY
CTU8m
EMPTY
BBU-E
Horizon II macro CABINET

ti-GSM-D4+ config_3 CTU4 radios_(non-rdndnt)-00126.h-ai-sw
Adding a second BBU-E and duplicating the D4+ links to this second BBU-E provides a
redundant solution tolerant to single points of failure.
Figure 5-12 D4+ configuration for 3 CTU8m radios (redundant)
LINK
D4+ D4+
1
0
D4+ D4+
1
0
LINK
D4+
D4+
D4+ D4+
1
0
CTU2D
CTU8m
CTU2D
CTU8m
CTU2D
CTU8m
BBU-E
BBU-E

ti-GSM-D4+ config_3 CTU4 radios (rdndnt)-00126.i-ai-sw
5-56
68P02900W21-T
Jul 2010
4-6 CTU8m radios (single BBU-E)

When there is only one BBU-E installed in the Horizon II cabinet, the D4+ star arrangement
must be extended to create two daisy-chained CTU8m radios as required on each link from the
BBU-E. It is recommended that the second CTU8m in the daisy-chain link hosts carriers for a
different sector, not the first CTU8m radio in the daisy-chain. This helps to limit the chances of
losing all carriers in a sector when the first CTU8m radio becomes unavailable.
Figure 5-13 D4+ configuration for 6 CTU8m radios (single BBU-E)
Same Sector
Same Sector
Same Sector
LINK
D4+
2
1
0
D4+ D4+
1
0
D4+ D4+
1
0
D4+ D4+
1
0
D4+ D4+
1
0
D4+ D4+
1
0
D4+ D4+
1
0
CTU8m
CTU8m
CTU8m
CTU8m
CTU8m
CTU8m
EMPTY
BBU-E

ti-GSM-D4+ config 6 CTU4 radios (single BBU-E)-00126.j-ai-sw
4-6 CTU8m radios (dual BBU-E)

In situations where there are two BBU-Es, it is possible to modify the D4+ star configuration
to provide additional redundancy paths to permit reconfiguration around the failure of a D4+
link or BBU-E. The recommended configuration uses a D4+ star from each BBU-E up to the
CTU8m radios. If there are two or more CTU8m units serving a single sector, at least one of
the CTU8m radios should have a D4+ connection to a different BBU-E to the other CTU8m
radios in that sector. This provides some carrier support in the sector in case of BBU-E failure.
Optionally each pair of CTU8ms can be interconnected to provide a standby D4+ link for use in
case of D4+ link or BBU-E failure.
68P02900W21-T
5-57
Jul 2010
Recommended D4+ configurations (RCTU8m)
Figure 5-14 D4+ configuration for 6 CTU8m radios (dual BBU-E)
Same Sector
D4+ D4+
1
0
D4+ D4+
1
0
Same Sector
D4+
1
D4+
0
D4+
1
Same Sector
D4+
0
D4+ D4+
1
0
D4+ D4+
1
0
LINK
LINK
D4+
D4+
CTU8m
CTU8m
CTU8m
CTU8m
CTU8m
CTU8m
1800 MHz
900 MHz
1800 MHz
900 MHz
1800 MHz
900 MHz
BBU
BBU

ti-GSM-D4+ config 6 CTU4 radios (dual BBU-E)-00126.k-ai-sw

The following are the recommended D4+ interconnection configurations for RCTU8m
deployments where the radio may be located at some distance from the Horizon II cabinet. The
best configuration to be used for a particular BTS deployment is influenced by the cost of laying
fiber optic D4+ interface cables in the location of the BTS deployment.
NOTE
The D4+ links used to connect RCTU8m radios use a fiber-optic media type. However,
the electrical D4+ cable is used for the BBU-EBBU-E D4+ link.
1-3 RCTU8m radios (non-redundant)

When the D4+ cable run length is relatively short, the simplest configuration is a direct
point-to-point fiber-optic link from each BBU-E D4+ port to each RCTU8m radio.
5-58
68P02900W21-T
Jul 2010
Figure 5-15 D4+ star configuration for 1-3 RCTU8m radios (non-redundant)
D4+ D4+
1
0
D4+ D4+
1
0
D4+ D4+
1
0
RCTU8m
RCTU8m
RCTU8m
LINK
D4+
2
1
0
EMPTY
BBU-E
Horizon II CABINET
ti-GSM-D4+ star config 1-3 RCTU4 radios (non-rdndnt)-00126.l-ai-sw
An alternative D4+ topology is preferable when there is a relatively long D4+ interface run
length, or when additional RCTU8m radios may be deployed in the future beside the original
RCTU8ms, which use a D4+ daisy-chain topology. Although only one D4+ link is required
between the RCTU8m and the BBU-E, it is recommended that a second physical D4+ link is
provisioned in a disabled state, creating a physical fiber-optic ring running as a daisy-chain
D4+ topology.
68P02900W21-T
5-59
Jul 2010
Figure 5-16 D4+ daisy-chain configuration for 1-3 RCTU8m radios (non-redundant)
D4+ D4+
1
0
D4+
1
D4+
0
D4+ D4+
1
0
RCTU8m
RCTU8m
RCTU8m
Optional
(Disabled)
LINK
D4+
2
1
0
EMPTY
BBU-E
Horizon II CABINET
ti-GSM-D4+ daisy-chain config 1-3 RCTU4 radios (non-rdndnt)-00126.m-ai-sw
Where full BBU-E redundancy is deployed, the daisy-chain option is preferred. The
BBU-EBBU-E D4+ link permits both BBU-Es to load-share the support of the RCTU8m carriers.
Although only one D4+ link is required between the RCTU8m and the BBU-E, it is recommended
that a second physical D4+ link is provisioned in a disabled state, creating a physical fiber-optic
ring running as daisy-chain D4+ topology.
5-60
68P02900W21-T
Jul 2010
Figure 5-17 D4+ daisy-chain configuration for 1-3 RCTU8m radios (redundant)
D4+ D4+
1
0
D4+
1
D4+
0
D4+ D4+
1
0
RCTU8m
RCTU8m
RCTU8m
Optional
(Disabled)
LINK
LINK
D4+
D4+
BBU-E
BBU-E
Horizon II CABINET
ti-GSM-D4+ daisy-chain config 1-3 RCTU4 radios (rdndnt)-00126.n-ai-sw
68P02900W21-T
5-61
Jul 2010
4-6 RCTU8m radios (single BBU-E)

The daisy-chain D4+ topology is recommended when more than three RCTU8m radios are to be
supported. Although only one D4+ link is required between the RCTU8m and the BBU-E, it
is recommended that a second physical D4+ link is provisioned in a disabled state, creating a
physical fiber-optic ring running as a daisy-chain D4+ topology.
Figure 5-18 D4+ configuration for 4-6 RCTU8m radios (single-BBU-E)
D4+ D4+
1
0
D4+
1
D4+
0
D4+ D4+
1
0
D4+ D4+
1
0
D4+ D4+
1
0
D4+ D4+
1
0
RCTU8m
RCTU8m
RCTU8m
RCTU8m
RCTU8m
RCTU8m
LINK
Optional (Disabled)
D4+
2
1
0
EMPTY
BBU-E
Horizon II CABINET
ti-GSM-D4+ config 4-6 RCTU4 radios (single-BBU-E)-00126.o-ai-sw
5-62
68P02900W21-T
Jul 2010
4-6 RCTU8m radios (dual BBU-E)

When two BBU-Es are deployed, to support the required capacity or to provide BBU-E
redundancy, the daisy-chain topology is deployed with a BBU-EBBU-E D4+ link. It is
recommended that a second physical D4+ link is provisioned between the BBU-Es and the
RCTU8ms, configured in a disabled state. This creates a physical fiber-optic ring running as
daisy-chain D4+ topology.
Figure 5-19
D4+ configuration for 4-6 RCTU8m radios (dual-BBU-E)
D4+ D4+
1
0
D4+
1
D4+
0
RCTU8m
RCTU8m
D4+
1
D4+
0
D4+ D4+
1
0
D4+ D4+
1
0
D4+
1
RCTU8m
RCTU8m
RCTU8m
RCTU8m
LINK
LINK
D4+
D4+
BBU
BBU
Optional (Disabled)
D4+
0
Horizon II CABINET
ti-GSM-D4+ config 4-6 RCTU4 radios (single-BBU-E)-00126.p-ai-sw
68P02900W21-T
Jul 2010
5-63
5-64
68P02900W21-T
Jul 2010
Chapter
6
BSC planning steps and rules
The plans for setting up a BSC and the relevant rules to be followed are described in this
chapter. The topics described in this chapter are as follows:
BSC planning overview on page 6-3
Capacity calculations on page 6-6
BSC system capacity on page 6-7
Determining the required BSS signaling link capacities on page 6-11
Determining the number of RSLs required on page 6-22
Determining the number of MTLs required on page 6-37
Determining the number of LMTLs required on page 6-45
Determining the number of XBLs required on page 6-47
Determining the number of GSLs required on page 6-50
Generic processor (GPROC) on page 6-53
Transcoding on page 6-63
Multiple serial interface (MSI) on page 6-70
Packet Subrate Interface (PSI2) on page 6-72
Kiloport switch (KSW) and double kiloport switch (DSW2) on page 6-73
BSU shelves on page 6-77
Kiloport switch extender (KSWX) and double kiloport switch extender (DSWX) on page 6-80
Generic clock (GCLK) on page 6-82
Clock extender (CLKX) on page 6-83
Local area network extender (LANX) on page 6-85
Parallel interface extender (PIX) on page 6-86
Line interface boards (BIB/PBIB, T43/PT43) on page 6-87
68P02900W21-T
Jul 2010
6-1
6-2
Digital shelf power supply on page 6-89
Non Volatile Memory (NVM) board on page 6-90
Verifying the number of BSU shelves and BSSC cabinets on page 6-91
68P02900W21-T
Jul 2010
BSC planning overview
BSC planning overview
Introduction
Information pertaining to the NEs must be known to plan the equipage of a BSC. The NE
configuration needs the following information:
Number of BTS sites to be controlled.
Number of RF carriers (RTF) at each BTS site.
The type of site controller used at the BTS site.
Number of TCHs and PDTCHs at each site.
Total number of AMR half rate or GSM half rate capable TCHs at each site.
Total number of TCHs and PDTCHs under the BSC.
Number of cells controlled from each BTS site should not exceed the maximum number of
cells per BSC detailed in Table 6-1.
Physical interconnection of the BTS sites to the BSC.
Location of the XCDR function.
Path for the OML links to the OMC-R.
Use of E1 links.
Use of Ethernet links.
Use of balanced or unbalanced E1.
Use of PBIB or PT43.
Traffic load to be handled (also take future growth into consideration).
Number of MSCs to BSC trunks.
LCS architecture.
Mixing of equipment types

The planning rules for each type of shelf should be taken into account, when mixing the BSU
and RXU shelves at a BSC. This needs using the information contained in this chapter (for the
BSC) and those in Chapter 7 RXCDR planning steps and rules (for the RXCDR), as the RXU shelf
is primarily used in the RXCDR. This applies to both the RXU3 shelf and the existing RXU.
The additional connectivity provided by the new BSSC3 is also required in the BSC when the
RXU3 shelf or shelves are used.
68P02900W21-T
6-3
Jul 2010
Outline of planning
Outline of planning
Planning a BSC involves the following steps:
6-4
Plan the number of RSL links between the BSC and BTS site(s). Refer to the section
Determining the number of RSLs required on page 6-22.
Plan the number of E1 links between the BSC and BTS site(s). Refer to the section BSC to
BTS E1 interconnect planning actions on page 6-31.
Plan the number of MTL links between the BSC and MSC. Refer to the section Determining
the number of MTLs required on page 6-37.
Plan the number of XBL links required between the BSC and AXCDR. Refer to the section
Determining the number of XBLs required on page 6-47.
Plan the number of GSL links required between the BSC and the PCU. Refer to Determining
the number of GSLs required on page 6-50.
Plan the number of GPROCs required. Refer to the section Generic processor (GPROC)
on page 6-53.
Plan the number of XCDR/GDP/EGDP/GDP2s required. Refer to the section Transcoding

on page 6-63.
Plan the number of LMTL links required between the BSC and the SMLC, if LCS is
enabled in the BSS and if BSS-based LCS architecture is supported. Refer to the section
Determining the number of LMTLs required on page 6-45. Ignore this if the BSS supports
only the NSS-based LCS architecture.
Plan the number of E1 links between the BSC and SMLC if LCS is enabled in the BSS and if
BSS-based LCS architecture is supported. Refer to the section Determining the number
of LMTLs required on page 6-45. Ignore this if the BSS supports only the NSS-based
LCS architecture.
Plan the number of MSIs required. Refer to the section Multiple serial interface (MSI)
on page 6-70.
Plan the number of PSI2s required. Refer to the section Packet Subrate Interface (PSI2)
on page 6-72.
Plan the number of KSWs/DSW2s and timeslots required. Refer to the section Kiloport
switch (KSW) and double kiloport switch (DSW2) on page 6-73.
Plan the number of BSU shelves. Refer to the section BSU shelves on page 6-77.
Plan the number of KSWXs/DSWXs required. Refer to the section Kiloport switch extender
(KSWX) and double kiloport switch extender (DSWX) on page 6-80.
Plan the number of GCLKs required. Refer to the section Generic clock (GCLK) on page
6-82.
Plan the number of CLKXs required. Refer to the section Clock extender (CLKX) on page
6-83.
Plan the number of LANXs required. Refer to the section Local area network extender
(LANX) on page 6-85.
68P02900W21-T
Jul 2010
Outline of planning
Plan the number of PIXs required. Refer to the section Parallel interface extender (PIX)
on page 6-86.
Plan the number of (P) BIB or (P) T43s required. Refer to the section Line interface boards
(BIB/PBIB, T43/PT43) on page 6-87.
Plan the power requirements. Refer to the section Digital shelf power supply on page 6-89.
Decide whether an NVM board is required. Refer to the section Non Volatile Memory
(NVM) board on page 6-90.
Verify the planning process. Refer to the section Verifying the number of BSU shelves
and BSSC cabinets on page 6-91.
68P02900W21-T
6-5
Jul 2010
Capacity calculations
Capacity calculations
Introduction
The throughput capacities of the BSC processing elements (for example, GPROC) and the
throughput capacities of its data links, determine the number of supported traffic channels
(TCHs). These capacities are limited by the ability of the processors, and the links to process
the signaling information associated with these TCHs.
The following sections, discussed, provide information on how to calculate processor
requirements, signaling link capacities, and BSC processing capacities:
BSC system capacities
BSS signaling link capacities
Traffic models
BSC GPROC functions and types
Number of GPROCs required
Remote transcoding
When the transcoding function resides outside of the BSC cabinet, in the RXCDR, it is possible
to have multiple RXCDRs connected to a single BSC, and vice-versa. This is especially useful
for two reasons:
In certain configurations, the RXCDR call (CIC) capacity is greater than that of a BSC.
A failure of an RXCDR or communication line does not result in a complete failure of

the BSC to handle calls.
BSC and RXCDRs support nine interconnections between them. The level of connectivity is
constrained by the number of XBLs supported. The connectivity is limited to 20 at each BSC and
RXCDR (refer to Determining the number of XBLs required on page 6-47 in this chapter).
The operator determines the level of connectivity. Excess RXCDR capacity should not be wasted,
nor should larger BSCs be connected only to one RXCDR. One guideline is to have each BSC
connect to four RXCDRs. System size, capacity, and cost are the major factors in deciding the
configuration.
6-6
68P02900W21-T
Jul 2010
BSC system capacity
BSC system capacity
System capacity summary

Table 6-1 provides a summary of BSC maximum capacities.
Table 6-1 BSC maximum capacities

GSR8
GSR9
GSR10
(1000 carriers)g
BTS sites
100
100d
100d
BTSs (cells)
250
250
250
Active RF carriers
384a,b
384a,b,d
384a,b,d
DRIs
384a,b
384a,d
384a,b
RSLs
250
250
250
PCUs
GSLs
180c
60c
60c
MMS
112
112e
112e
PATHs
250
250
250
DHPs
232
232
232
LCFs
25
25h
38h
190
190
300I
2400a,b
2400a,b,d
2400a,b,d
C7 links to MSC
16
16
16
C7 links to SMLC
16
16
16
E1 links
112
112e
112e
Ethernet links
N/A
12f
12f
120,000
180,000d
194,500
Item
Cabinets
Trunks (see NOTE )
Maximum busy hour

call attempts
68P02900W21-T
6-7
Jul 2010
Where:
Is:
The capacity can be increased to 512 carriers and 3200 trunks if the optional
enhanced BSC capacity feature is enabled. The maximum DRIs is 512.
It is mandatory to deploy GPROC3/GPROC3-2s in active and/or standby BSP

slots in the BSC in any potential BSP slots on a site. For example, slot 20 and
slot 24 in shelf 0 and slot 20 in shelf 1.
180 for 3xPCU, 60 per PCU in GSR8 and GSR9, BSS can support 60 GSLs with
the introduction of ePCU (refer to Chapter 8 BSS planning for GPRS/EGPRS).
The capacities represent the BSS capacities for GSM circuit-switched traffic.
If the GPRS traffic is carried on the BSS, the GSM circuit-switched traffic
handling capacity reduces in direct proportion to the timeslots configured
for GPRS traffic.
The capacity can be increased to 140 BTS sites, 750 carriers, and 4800
trunks, if the optional huge BSC capacity feature is enabled. The maximum
number of DRIs is 750.
With 96 MSI feature, a BSC site can support 192 MMSs.
A PSI2 replaces an MSI to support the Ethernet link between BSC and PCU.
The maximum number of PSI2 boards and Ethernet links is 12. The MMS
number and E1 links decrease accordingly.
The BSC configuration of the 1000 carriers with the huge BSC capacity
feature enabled. The enhanced capacities are listed in Table 6-2 BSC
configuration capacities.The BHCA can be different depending on the call
duration parameter. Under a given call model, the required equipment is
calculated based on the call model (including BHCA 8i) using the formula
provided in the following sub-sections in this chapter. The BHCA limit should
be checked after planning and should not be exceeded to ensure that the
stability and performance of the system are maintained.
The max number of LCF per BSC is increased from 25 to 38.
Table 6-2- provides BSC configuration capacities of the 1000 carriers:
Table 6-2
BSC configuration capacities

Item
1000 carriers BSC
BTS sites
140
BTSs (cells)
250
Active RF carriers
1000
DRIs
1000
RSLs
250
PCUs
GSLs
60
MMS
192
PATHs
250
DHPs
232
LCFs
38
Continued
6-8
68P02900W21-T
Jul 2010
Table 6-2
Scalable BSC
BSC configuration capacities (Continued)

Item
1000 carriers BSC
Cabinets
300I
Trunks
6200
C7 links to MSC
16
C7 links to SMLC
16
E1 links
192
Ethernet links
12
Maximum busy hour call attempts
255,000*
(Call duration = 83.27s)
NOTE
I - The maximum of 190 cabinets can be equipped per BSS, which is the sum of the
cabinets equipped in BSC, PCU and BTS. The limit has been extended to 300 in GSR10.
When planning a BSC, any limit given in Table 6-1 should not be exceeded for the GSR version
used. The first element to reach its limit sets the capacity of the BSC. For example, when
dimensioning a BSC with a specific non-standard call model, there is a possibility that the LCF
or C7 limit is reached before the Erlang limit is reached.
Scalable BSC
With the launch of the scalable BSC, Motorola moved to a position where the diverse
requirements of network users in terms of BSC size are addressed by a single platform that can
be efficiently configured in small, medium, or large models.
Before GSR7, the move to a scalable BSC is enabled through the migration of the processing
boards within the BSC to use the GPROC2 throughout. Now, GPROC2s can be replaced by
the new GPROC3s at board level in any slot, thus preserving the scalable BSC architecture.
BSSs targeted at small, medium, or large networks are efficiently addressed by the scalable
BSC where minimal incremental hardware is required to be added as the networks grow. From
GSR8, it is mandatory to deploy GPROC3s in active and/or standby BSP slots in the BSC in any
potential BSP slots on a site (that is, slot 20 and slot 24 in shelf 0 and slot 20 in shelf 1). Being
able to expand capacity within a BSC is beneficial from an operational viewpoint, because there
is less time and effort involved than compared with having to move sites from one BSC to
another, or even from one OMC-R to another.
Put into context, the BSC capacity before GSR3 supported in the order of 40 sites of three sectors
and one carrier per sector; or alternatively, 20 sites of three sectors and two carriers per sector.
At GSR3, the capacity was increased to allow the operator to move to support in the order of 40
sites of three sectors and two carriers per sector. At GSR4, the capacity is increased to allow the
operator to move to support in the order of 64 sites of three sectors and two carriers per sector.
The scalable BSC also offers a substantial advantage for microcellular deployment where a single
BSC is able to support up to 100 microcellular BTSs, each equipped with two carriers per site.
The scalable BSC capacity is enabled because of the increased processing performance and
memory of the GPROC. The maximum capacity is increased as shown in Table 6-1.
68P02900W21-T
6-9
Jul 2010
Enhanced BSC capacity option
This increased capacity is achieved through the deployment of GPROC2s or

GPROC3s/GPROC3-2s for each function at the BSC, including Base Station Processor (BSP)
and Link Control Function (LCF).
NOTE
The GPROC3/GPROC3-2 is a high performance direct replacement for the GPROC2.
Enhanced BSC capacity option

This feature is a restricted option. If the feature is restricted, the BSC supports the normal
BSC maximum capacity of 384 RF carriers, and 2400 trunks (see Table 6-1). If the feature is
unrestricted, the BSC maximum capacity is increased to 512 RF carriers and 3200 trunks.
Hardware upgrades are required by the BSS to support the optional Enhanced BSC capacity.
BTP processors at the InCell BTSs must be replaced with GPROC2s.
NOTE
GPROC3s are required in the BSP slots. InCell BTS is no longer supported.
Huge BSC capacity option

This feature is a restricted option. If the feature is restricted, the BSC supports the BSC
maximum capacity of 100 BTS sites, 384 RF carriers, and 2400 trunks (see Table 6-1). If the
feature is unrestricted, the BSC maximum capacity is increased to 140 BTS sites, 750 RF
carriers, and 4800 trunks.
Hardware upgrades are required by the BSS to support the optional Huge BSC capacity.
Specifically, HSP MTLLCF processors must be replaced with GPROC3-2 to support the HSP MTL
link and DSW2/DSWX is mandatory to increase the number of TDM timeslots from 1024 to 2048.
LCS option
This feature is a restricted option. If the feature is restricted, no location service capability is
provided. If the feature is unrestricted, the BSS supports the Network Sub-System (NSS) based
Serving Mobile Location Center (SMLC) architecture or the BSS-based SMLC architecture, and
the BSS supports new LCS signaling for cell ID +TA positioning method:
New LCS signaling messages on the A Interface or Lb interface.
New LCS signaling messages on the Mobis interface and Um interface.
The provisioning rules and steps for BSS equipment only support cell ID and the TA positioning
method for LCS is provided for NSS-based and BSS-based LCS architectures respectively in
the following sections.
6-10
68P02900W21-T
Jul 2010
Determining the required BSS signaling link capacities
Determining the required BSS signaling link capacities
BSC signaling traffic model

For a GSM system, the throughput of network entities, including subcomponents, depends
upon the assumed traffic model used in the network design or operation. Traffic models are
fundamental to some planning actions.
The capacity of the BSC as a whole, or the capacity of a particular GPROC, depends on its
ability to process information transported through signaling links connecting it to the other
network elements. These elements include MSC, BTSs, and the OMC-R. Depending on its device
type and BSC configuration, a GPROC controls signaling links to one or more other network
elements. A capacity figure can be stated for each GPROC device type in terms of a static
capacity such as the number of physical signaling links supported, and a dynamic capacity such
as processing throughput.
In general telephony environments, processing and link throughput capacities can be stated in
terms of the offered call load. To apply this for the GSM BSC, all signaling information to be
processed by the BSC is related to the offered call load (the amount of traffic offered/generated
by subscribers). When calls are blocked due to all trunks or all TCHs being busy, most of the
signaling associated with call set up and clearing still takes place, even though few or no trunk
resources are utilized. Therefore, the offered call load (which includes the blocked calls) should
be used in planning the signaling resources (for example; MTLs and RSLs).
In the case where the BSC has more than enough trunks to handle the offered traffic, adequate
signaling resources should be planned to handle the potential carried traffic. The trunk count
can be used as an approximate Erlang value for the potential load carried.
As a result, the signaling links and processing requirements should be able to handle the
greater of the following:
Offered load
Potential load
The number of trunks or the offered call load in Erlangs (whichever is greater) should be used
to determine the link and processing requirements of the BSC.
BSC capacity planning needs a model that takes into consideration the signaling generated from
all the pertinent GSM procedures: call setup and clearing, handover, location updating, and
paging, to the offered call load. To establish the relationship between all the procedures, the
traffic model expresses processing requirements for these procedures as ratios to the number
of call attempts processed. The rate at which call attempts are processed is a function of the
offered call load and the average call hold time.
68P02900W21-T
6-11
Jul 2010
NOTE
A standard traffic model can be assumed when initially planning a network.

However, once the network is running, it is critical to monitor and measure the
real call parameters (described in Chapter 11 Call model parameters) from the
live network to ascertain the true network call model.
Future planning should then be based on this actual (non-standard) call model
instead of the standard call model. Past studies have shown that the actual call
model in some networks differs considerably from the standard call model, and
this has a direct impact on dimensioning requirements.
Figure 6-1 graphically depicts various factors that should be taken into account when planning a
BSS.
6-12
68P02900W21-T
Jul 2010
Figure 6-1 BSS planning diagram

MSC
TRANSCODER
WITH SUBMULTIPLEXING TRANSCODING AT MSC
1 x 64 KBIT/S CIRCUIT/C7 SIGNALLING LINK
1 x 64 KBIT/S CIRCUIT/X.25 SIGNALLING LINK *
1 x 64 KBIT/S CIRCUIT/ XBL
1 x 64 KBIT/S CIRCUIT/4 TRUNKS
1 x 64 KBIT/S CIRCUIT/8 TRUNKS
(HALF RATE WITH 8 KBIT/S SUBMULTIPLEXING ENABLED)
A INTERFACE (TERRESTRIAL LINKS)

-C7 SIGNALLING LINKS
-X.25 CONTROL LINK *
-REQUIRED TRUNKS
WITH SUBMULTIPLEXING TRANSCODING AT BSC

1 x 64 KBIT/S CIRCUIT/C7 SIGNALLING LINK
1 x 64 KBIT/S CIRCUIT/X.25 SIGNALLING LINK*
1 x 64 KBIT/S CIRCUIT/TRUNK
GDS INTERFACE **
- GDS TRAU CHANNELS
- GSL LINKS
GBL
BSC TO PCU
GDS-TRAU
CIRCUITS
THE # OF GSLs
THE # OF GBLs
PCU
1 x 16 KBIT/S CIRCUIT/GPRS TIMESLOT

FOR CS1 AND CS2
2 x 16 KBIT/S CIRCUIT/GPRS TIMESLOTS
FOR CS3 AND CS4
1 x 64 KBIT/S GSL LINK
RTF_DS0_COUNT x 64 KBIT/S
FOR EACH EGPRS RTF
THE BSC TO MSC 64 kbit/s CIRCUITS ARE DETERMINED

FROM THE # OF TRUNKS REQUIRED TO CARRY THE
SUMMATION OF AIR INTERFACE TRAFFIC (IN ERLANGS,
TYPICALLY USING 1% BLOCKING) FROM ALL BTSs
- PLUS THE # OF GDS TRAU LINKS (DETERMINED FROM THE
NUMBER OF GPRS TIMESLOTS UNDER A BSC)
- PLUS THE # OF C7 SIGNALLING LINKS
- PLUS - (IF APPLICABLE*)
THE # OF X.25 LINKS (USUALLY ONE PER BSC)
- PLUS THE # OF XBL LINKS
- PLUS THE # OF GSL LINKS
BSC
1 x 64 KBIT/S OF 1 x 16 KBIT/S RTF CIRCUIT/LAPD
SIGNALLING LINK
2 x 64 KBIT/S CIRCUITS/RTF
4 x 64 KBIT/S CIRCUITS/RTF (SEE NOTE)
MOTOROLA BSC/BTS INTERFACE

NON-BLOCKING
THE # OF TCHs REQUIRED (USING TYPICALLY 2%

BLOCKING) TO CARRY SUBSCRIBER TRAFFIC.
THE TCHs PLUS THE REQUIRED SIGNALLING TSs
DIVIDED BY EIGHT (OR 16 WITH HALF RATE
MANDATED) DETERMINES THE CARRIERS REQUIRED
(ON A BTS/SECTOR BASIS)
BTS
AIR INTERFACE
-TCHs, PDTCHs AND SIGNALLING TSs
-TYPICALLY 2% BLOCKING FOR CS
TRAFFIC
AIR INTERFACE
TRANSCODING MUST BE LOCATED AT THE

BSC, OR BETWEEN THE BSC AND MSC
8 pt. left aligned text
TCH
= TRAFFIC
CHANNEL TS
=
TIMESLOT
USING TRAFFIC, TO DETERMINE THE E1 LINK INTERCONNECT

HARDWARE FOR THE A AND BSC TO BTS INTERFACE
ti-GSM-BSS_planning_diagram-00127-ai-sw
68P02900W21-T
6-13
Jul 2010
Typical parameter values
NOTE
4 x 64 kbps circuits/RTF for a (AMR or GSM) HR RTF and 8 kbps switching is not
provisioned, or (for AMR only) the 7.95 kbps half rate codec mode is included in
the Half Rate Active Codec Set.
Besides the factors described in Figure 6-1, when LCS is enabled in the BSS, the following
factors require to be taken into account when planning a BSS:
MTL link provisioning to support LCS signaling between the MSC and BSC for either
NSS-based LCS architecture or BSS-based LCS architecture, but not both.
LMTL link provisioning for BSS-based LCS architecture only.
RSL link provisioning with LCS supported.

The parameters required to calculate BSC processing and signaling link capacities are listed in
Table 6-3 with their typical values.
Two methods for determining the BSC link capacity are given. The first method is based on the
typical call parameters given in Table 6-3 and simplifies planning to look up tables, or the simple
formulae indicated in the standard traffic model planning steps. When the call parameters being
planned differ significantly from the standard traffic model, more complex formulae must be
used as indicated in Nonstandard traffic model planning steps.
Table 6-3 Typical call parameters

Busy hour peak signaling traffic parameter
Reference parameter
Call duration
T = 83.27 seconds
S = 3.2
H = 3.54
Ratio of location updates to calls: non-border location area
l = 2.73
Ratio of location updates to calls: border location area
l=7
I = 0.05
Location update factor: non-border location area using IMSI

type 2
L = l + 0.5I = 2.75
Location update factor: border location area using IMSI type 2
L = l + 0.5I = 7.02
GSM circuit-switched paging rate in pages per second
PGSM = 90.8
Ratio of intra-BSC handovers to all handovers (see NOTE)
i = 0.82
Lcs = 0
LRMT = 0.95
LRMO = 0.05
Percent link utilization (MSC to BSS) for 64 k
U(MSC BSS) = 0.20

Continued
6-14
68P02900W21-T
Jul 2010
Table 6-3 Typical call parameters (Continued)

Reference parameter
Percent link utilization (MSC to BSC) for HSP MTL
U(MSC BSC) = 0.13
U(MSC BTS) = 0.25
UBSC-RXCDR = 0.40
UBSC-SMLC = 0.40
UBSC-PCU = 0.25
Percent link utilization (BSC to SGSN)
UGBL = 0.40
UCCCH = 0.33
Block Rate for TCHs
PB-TCHs = 1%
PB-Trunks = 0%
CBTS = 3
SMSSIZE = 100 bytes
BSCLA = 1
BHCAsub = 1.03

MNEWCALL = 1
Number of XBL messages per hr <-> fr handover
MHANDOVER = 1
LXBL =50
Hhr-fr = 1
GPRS parameters
PKSIZE = 315.48
GPRS Traffic per sub/BH (bytes/hr) Uplink
ULRATE = 1.48
GPRS Traffic per sub/BH (bytes/hr) Downlink
DLRATE = 5.96
PSATT/DETACH = 0.49
PDP context activation/deactivation (per sub/BH)
PDPACT/DEACT = 0.63
Routing area update
RAU = 1.4
PGPRS = 2.02
Coding scheme rates (CS1 to CS4) at the RLC/MAC layer
CS1
CS2
CS3
CS4
= 9.2 kbps
= 13.6 kbps
= 15.8 kbps
= 21.8 kbps
Continued
68P02900W21-T
6-15
Jul 2010

Reference parameter
Coding scheme usage (CS1 to CS4) at a BLER of 5%
CS1_usage_UL = 11%
CS1_usage_DL = 8%
CS3_usage_UL = 8%
CS3_usage_DL = 21%
Percentage GPRS coding scheme usage in total traffic (see

NOTE)
CellUpdate = 0.33
EGPRS parameters
PKULSIZE = 130.75
PKDLDLSIZE = 485.9
EGPRS Traffic per sub/BH (kBytes/hr) - Uplink
ULRATE = 1.48
EGPRS Traffic per sub/BH (kBytes/hr) - Downlink
DLRATE = 5.96
Avg Sessions per sub = 0.026
PSATT/DETACH = 0.49
PDPACT/DEACT = 0.63
Routing area update
RAU = 1.4
PGPRS = 2.02
Coding scheme rates (MSC1-MSC9) at the RLC/MAC layer
MCS1
MCS2
MCS3
MCS4
MCS5
MCS6
MCS7
MCS8
MCS9
Coding scheme usage (MCS1 to MCS9) at a BLER of 12.02%
MCS1_usage_DL = 11%
MCS2_usage_UL = 2%
MCS2_usage_DL = 12%
MCS4_usage_DL = 7%
MCS5_usage_DL = 5%
MCS6_usage_DL = 19%
MCS7_usage_DL = 8%
= 10.55
= 12.95
= 16.55
= 19.35
= 23.90
= 29.60
= 31.10
= 46.90
= 61.30
Continued
6-16
68P02900W21-T
Jul 2010

Reference parameter
MCS8_usage_DL = 8%
Percentage EGPRS coding scheme usage in total traffic
Average packet size for GPRS and EGPRS traffic mix (bytes)
Uplink (see NOTE)
PKULSIZE = 130.75
Average packet size for GPRS and EGPRS traffic mix (bytes)
Downlink (see NOTE)
PKDLSIZE = 485.9
QoS parameters
GBRAVG_UL = 3.80
GBRAVG_DL = 5.59
GBRPEAK_UL = 9.64
GBRPEAK_DL = 12.69
NOTE
Number of handovers: These include 2G-3G handovers.
Percentage GPRS coding scheme usage: These percentages represent

the split of the traffic between for GPRS and EGPRS traffic mix, which is
network-dependent. The percentages can be used to determine the average
traffic per sub/BH for a GPRS and EGPRS traffic mix as follows:
Traffic per sub/BH for GPRS and EGPRS mix (kBytes/hr) = (Percentage
GPRS coding scheme usage in total traffic * GPRS Traffic per sub/BH) +
(Percentage EGPRS coding scheme usage in total traffic * EGPRS Traffic
per sub/BH)
Average packet size for GPRS and EGPRS traffic mix (bytes): These are the
average packet sizes for a GPRS and EGPRS traffic mix based on the GPRS and
EGPRS percentage splits defined for this model.
Location update factor

The location update factor (L) is a function of the ratio of location updates to calls (l), the ratio
of IMSI detaches to calls (I) and whether the short message sequence (type 1) or long message
sequence (type 2) is used for IMSI detach; typically I = 0 (that is IMSI detach is disabled) as in
the first formula given . When IMSI detach is enabled, the second or third of the formulas given
should be used. The type of IMSI detach used is a function of the MSC.
If IMSI detach is disabled:
L=1
If IMSI detach type 1 is enabled:
L = 1 + 0.2 * I
68P02900W21-T
6-17
Jul 2010
Assumptions used in capacity calculations
If IMSI detach type 2 is enabled:

L = 1 + 0.5 * I
Other parameters
Other parameters used to determine GPROC and link requirements are listed in Table 6-4.
Table 6-4
Other parameters used in determining GPROC and link requirements
Busy hour peak signaling traffic mode
Reference parameter
Number of MSC - BSC trunks
Number of BTSs per BSS
Number of cells per BSS
Pages per call
PPC = PGSM * (T/N)
LCS request rate (req/sec/BSC)
LCS_BSC_Rate = (N/T) * LCS

Signaling message sequence and size assumptions
Certain signaling message sequence patterns and message sizes have been assumed to calculate
link and processing capacity values for the various procedures included in the signaling traffic
model. These assumptions translate into specific formula coefficients and include a margin of
safety. As they are dependent on call procedures, they are recalculated for every major software
release. Link utilization should be monitored to detect significantly different behavior. The
procedures used for the calculations are provided in Table 6-5.
Table 6-5 Signaling message procedures

MSC - BSC
BSC - BTS
SMLC - BSC
Call setup and clearing
Call setup and clearing
N/A
Handover, incoming and

outgoing
Handover, incoming and

outgoing
N/A
Location update
Location update
N/A
SMS - P to P
SMS - P to P
N/A
IMSI detach (type 1)
N/A

Paging
N/A

Paging
One phase access and
Enhanced one phase access
N/A
N/A
N/A
Continued
6-18
68P02900W21-T
Jul 2010
Table 6-5 Signaling message procedures (Continued)

MSC - BSC
BSC - BTS
SMLC - BSC
NOTE
Enhanced One
Phase is not
supported with
EGPRS carriers.
LCS
LCS
LCS
The BSS software uses a new small message header (compact header) for delivering messages
between the BSC/PCU and the BTS. The new message header contains the minimum information
necessary to deliver the messages between the processes. The size of the message header is 8
bytes. This reduces the signaling link utilization between the BSC-BTS and BSC-PCU.
An additional assumption, which is made in determining the formula coefficients, is that the
procedures not included in the traffic model are considered to have a negligible effect.
NOTE
Supplementary Service (SS) messaging has not been taken into account. This could
contribute a significant signaling overhead in some networks.
Paging assumptions
In calculating the average message size for paging, it is assumed that paging is by LAC (or
LAI) only. Paging by LAC only, is the recommended method. Paging by LAC and cell ID is not
necessary, and has two major disadvantages:
The paging method is controlled by the MSC and is signaled to the BSC through the
setting of the Cell Identification Discriminator in the BSSMAP paging message. The BSC
can determine from its Configuration Management database the cells that require to be
paged from the location area code only. Therefore, the MSC does not require to send a
list of each individual cell identity. Paging by LAC and Cell ID increases the length of the
BSSMAP paging considerably and significantly increases the C7 signaling load between
the MSC and BSC.
Paging by LAC only reduces the possibility of paging channel overload on the air interface
caused by any database mismatch between the BSC and MSC. If the BSC receives a cell
identity in the paging message from the MSC that does not exist in its Configuration
Management database, it defaults to paging all cells in the BSS for safety reasons. This
can cause overload of the paging channel on the radio interface.
68P02900W21-T
6-19
Jul 2010
Link capacities
Half rate assumptions

A (AMR or GSM) half rate enabled carrier is capable of carrying two half rate calls in each
timeslot, for 16 (half rate) TCHs. The actual number in use at a given instance depends upon
such factors as user (both BSS and MSC) preference, mobile (that is, AMR capable) penetration,
RF conditions, handoff parameter, and threshold setting, cell congestion levels, and so on.
If it is known to a large degree of certainty what is the mix of half rate and full rate calls, that
number can be used when considering equipment planning. Otherwise, it is recommended that
a worst case approach be taken. For example, when determining the RSL signaling link capacity
required, and half rate usage is expected to be no more than 50%, and there are two (both half
rate enabled) carriers, a mix of 9 fr and 10 hr (plus 2 timeslots for signaling) TCHs can be used
(for a total of 19). A worst case estimate assumes 16 TCHs per half rate enabled carrier, for 28
TCHs. If only one carrier is half rate enabled, worst case results in (16 hr, 6 fr) 22 TCHs.
When 8 kbps subrate switching is not available, or an RTF is configured as AMR half rate capable
and the 7.95 kbps half rate codec mode is included in the Half Rate Active Codec Set, then the
carrier unit assigned to that RTF needs four 64 kbps timeslots on the E1 circuit (regardless of
how they are utilized). For an EGPRS capable RTF (pkt_radio_type set to 3), 16 kbps switching
on the backhaul is not supported and allow_8k_trau has to be enabled if half rate is supported.
NOTE
AMR HR Active Codec Set cannot include 7.95 kbps, when pkt_radio_type is set to 3.
Link capacities
The level of link utilization is largely a matter of choice of the system designer. A design that
has more links running at a lower message rate can have the advantage of offering better
fault tolerance, since the impact of failure of any one link on the signaling traffic is less.
Reconfiguration around the fault could be less disruptive. Such a design could offer reduced
queuing delays for signaling messages. A design that utilizes fewer links at a higher message
rate, reduces the number of 64 kbps circuits required for signaling, and potentially reduces the
number of resources (processors, data ports) required in the MSC. It is recommended that the
C7 links be designed to operate at no more than 40% utilization when the MTL/LMTL is running
on a GPROC2 or GPROC3. Before use of the 40% utilization for GPROC2 or GPROC3, it is
imperative that the operator verifies that the MSC/SMLC vendor can also support 40% utilization
at the MSC/SMLC end; if not, only 20% link utilization should be used for GPROC2 and GPROC3.
If HSP MTL is enabled, it is recommended no more than 13% link utilization for the 2M MTL.
If higher link utilizations are used, the controlling GPROCs (LCF-MTLs/LCF-LMTLs) become
overloaded.
NOTE
Overloading GPROCs can cause the BSC to become unstable. Links must be
monitored closely to ensure that link utilization does not exceed the maximum. If link
utilization is regularly approaching the maximum, additional capacity should be
added to reduce the possibility of overloading the GPROCs.
6-20
68P02900W21-T
Jul 2010
Link capacities
The protocol C7, used for the MSC to BSC links and SMLC to BSC links, allows for the signaling
traffic from the failed link to be redistributed among the remaining functioning links. Both the
MSC-BSC and SMLC-BSC C7 link set officially have at least two and at most 16 links. The
failure of links, for any reason, causes the signaling to be shared across the remaining members
of the link set. Therefore, the design must plan for reserve link and processing capacity to
support a certain number of failed signaling links.
68P02900W21-T
6-21
Jul 2010
Determining the number of RSLs required
Determining the number of RSLs required
Introduction
Each BTS site that is connected directly to the BSC, including the first site in a daisy chain,
must be considered individually. Once individual RSL requirements are calculated, the total
number of LCFs can be determined for the BSC.
The following factors should be considered when planning the provision of RSL (LAPD signaling)
links from the BSC to BTS sites:
With the Motorola BSC/BTS interface, there is a need for at least one RSL link to every
BTS site. One link can support multiple collocated cells. As the system grows, additional
signaling links are required. Refer to the section Determining the required BSS signaling
link capacities on page 6-11 in this chapter to determine the number of RSL links required.
If closed loop daisy chains are used, each site needs an RSL in both directions.
The provision of additional RSL links for redundancy.
PCCCH signaling traverses the GDS (on a PDTCH) instead of the RSL. Thus, cells with
PCCCH enabled do not add to the RSL requirements for the BTS.
If paging coordination is enabled with PCCCH, GSM circuit-switched pages are sent on the
PCCCH. Thus, some of the GSM paging load is removed from the RSL.
If LCS is enabled in the BSS, the signaling load due to LCS needs to be taken into account.
The number of 16 kbps RSL links is limited, depending on the platform. See 16 kbps RSL
on page 2-17 in Chapter 2 Transmission systems for further details. 64 kbps RSLs must be
used when allowable numbers are exceeded.
Extended Uplink TBF is the feature enhances uplink data performance by minimizing the
interruptions of uplink data flow in GPRS/EGPRS networks due to a frequent release and
establishment of uplink TBF. According to the principle of Extended Uplink TBF, this feature
decreases the amount of RACH for uplink applications session like uplink FTP, and so on. If
the uplink application is rare, the total amount of decreased RACH is small. Thus, the impact
of RACH decrement can be ignored. If the uplink applications are booming, total amount of
decreased RACH is huge. Therefore the impact of RACH decrement cannot be ignored, and
RACH decrement is taken into account for RSL calculation.
6-22
68P02900W21-T
Jul 2010
Determining the number of RSLs
Table 6-6 lists the limitations for 64kbit/s RSL or 16 kbps RSLs supported on each BTS platform.
Table 6-6 BTS support for 64kbit/s RSL or 16 kbps RSLs

BTS Platform
Number of 64kbit/s RSL or 16 kbps

RSLs Supported
A BSU-based BTS
Horizon II macro and Horizonmacro
Horizon II macro (mini/micro)with Horizon

II SC-2/E or /BBU-E
12
Horizonmicro2 / Horizoncompact2
M-Cell6
M-Cell2
M-Cellmicro and M-Cellcity
NOTE
Horizon II macro BTSs support 4 x RSLs per E1, whereas Horizonmacro

and M-Cell BTSs only support 2 x RSLs per E1. This should be taken into
consideration when determining the number of E1s required to support the
calculated RSLs per site.
While it is possible to equip Horizon II macro BTSs supporting either the

HIISC2-S/E or BBU-E, with up to 12 RSLs, there are certain non-standard
RSL PATH configurations (the default RSL timeslots are not configured as
RSL defined in the database) that could lead to only 10 of these 12 RSLs
being available (that is, enter the B-U state) for codeloading to the BTS. Once
codeloading is complete, the remaining 2 RSLs come INS for normal Mobis
signaling traffic. It is recommended to configure all the three default RSL
timeslots (one for each of the first three E1 span connection locations) as RSL,
so that all the configured RSLs can be available for codeloading to the BTS.
In case BTS of HIISC2-S/E and BBU-E are equipped under the BSC, equip some
GPROC3 or GPROC3-2 LCFs on BSC to speed up the conventional downloading,
since HIISC-2 objects are stored on GPROC3 or GPROC3-2 only. To achieve the
shortest downloading duration, the number of GPROC3 or GPROC3-2 in BSC
should not be less than: N_newBTS/10 + 1.
N_newBTS = Number of HIISC2-S/E or BBU-E equipped BTS under the BSC
Determining the number of RSLs

The equation for determining the number of RSL links for the combined signaling load is as
follows:
RSLGP RS+GSM = RSLGP RS + RSLGSM

This is evaluated for 16 kbps RSLs or for 64 kbps RSLs. The interface between the BTS and BSC
does not permit mixing the two RSL rates.
68P02900W21-T
6-23
Jul 2010
One phase access and enhanced one phase
Where:
Is:
RSLGPRS+GSM
the combined number of RSL signaling links on a per BTS site basis
operating at a 16 kbps RSL rate or at a 64 kbps RSL rate.
NOTE
{33254} The HIISC2-S/E and BBU-E require a significant increase in the number
and size of code objects. Codeload time is an additional RSL-related planning
consideration.
Initial estimates suggest that raw RSL codeloading rates (exclude time to
distribute and Codeload objects to the various DRIs at a site) can be increased
almost linearly with the number of RSLs.
RSLGPRS
the number of RSL signaling links required to serve the GPRS part of
the network at 16 kbps or at 64 kbps.
RSLGSM
the number of RSL signaling links required to serve the GSM part of
the network at 16 kbps or at 64 kbps.
One phase access and enhanced one phase

In a GPRS network, there are two packet access procedures that a mobile station can use to
establish an uplink TBF. The packet access performs in either one phase or in two phases.
One phase access

In a one phase uplink TBF access, the MS initiates an uplink TBF by sending a RACH to the BSS.
The RACH is received at the BTS and is then forwarded to the PCU. The PCU responds to the
RACH with an Immediate Assignment message containing an uplink assignment. The MS moves
to the assigned PDTCH and begins its uplink data transfer. This procedure allows the MS to
gain access to the network much quicker than the two-phase establishment procedure.
Enhanced one phase

The enhanced one phase uplink TBF access procedure speeds up the one phase packet access
procedure even further. The enhanced one phase access procedure allows the PCU to assign
resources for a one phase uplink TBF, allowing the BTS to react quickly to a one phase RACH
without forwarding the RACH to the PCU and incurring excessive RSL delay and increasing
RSL load. Depending on the RSL load, the RACH to Immediate Assignment delay reduces
by approximately 60 ms or more.
Standard traffic model

The number of BSC to BTS signaling links (RSLs) must be determined for each BTS. This number
depends on the number of TCHs and PDTCHs at the BTS. Table 6-7 gives the number of RSLs
required (rounded up to the nearest integer value) for a BTS to support the given number of
TCHs and PDTCHs, based on the typical call parameters given in the standard traffic model
column of Table 6-3. If the call parameters differ significantly from the standard traffic model,
use the formulae for the non-standard traffic model.
6-24
68P02900W21-T
Jul 2010
NOTE
Table 6-7 assumes that there are no cells with PCCCH enabled.
Enhanced One Phase is not supported with EGPRS carriers.
For assumptions specific to half rate refer to Half rate assumptions on page 6-20.
Table 6-7 Number of BSC to BTS signaling links (without LCS)

With Enhanced One Phase
Access
With One Phase Access
#TCHs/BTS
(n)
#PDTCHs/
BTS (Ngprs)
# 64 kbps
RSLs
# 16 kbps
RSLs
# 64 kbps RSLs
# 16 kbps RSLs
30
10
10
15
10
10
30
10
10
45
10
10
60
10
10
75
10
10
90
10
10
12
12
15
12
12
30
12
12
45
12
12
60
12
12
75
12
12
90
12
12
14
14
15
14
14
30
14
14
45
14
14
60
14
14
75
14
14
90
14
14
31 to 60
61 to 90
Continued
68P02900W21-T
6-25
Jul 2010
Table 6-7 Number of BSC to BTS signaling links (without LCS) (Continued)
With Enhanced One Phase
Access
#TCHs/BTS
(n)
#PDTCHs/
BTS (Ngprs)
# 64 kbps
RSLs
# 16 kbps
RSLs
# 64 kbps RSLs
# 16 kbps RSLs
91 to 120
17
17
15
17
17
30
17
17
45
17
17
60
17
17
75
17
17
90
17
17
19
19
15
19
19
30
19
19
45
19
19
60
19
19
75
19
19
90
19
19
21
21
15
21
21
30
21
21
45
21
21
60
21
21
75
21
21
90
21
21
23
23
15
23
23
30
23
23
45
23
23
60
23
23
75
23
23
90
23
23
121 to 150
151 to 180
181 to 210
6-26
With One Phase Access
68P02900W21-T
Jul 2010
Non-standard traffic model
NOTE
The RSL calculations assume PGPRS = 0 for cells in which NGPRS = 0. This is not
necessarily true. If the BSC has GPRS timeslots, even if the cells do not have
traffic channels configured as PDTCHs, it may have paging traffic.
RACH_Arrivals/sec figures have been calculated using Avg_Sessions_per_user

as in the call model table. GPRS_Users_BTS has been calculated based on the
number of timeslots configured on the cell.
A BTS can support either 64 kbps RSLs or 16 kbps RSLs, but not both. The
number of 16 kbps RSLs allowable is dependent on the hardware platform and
some 16 kbps values in the tables may not be valid. 64 kbps RSLs must be used
if the allowable number of 16 kbps RSLs is exceeded.

64 kbps RSLs
If the call parameters differ significantly from those given in Table 6-3, use the following formula
to determine the required number of 64 kbps RSLs.
If LCS is enabled at the BSS, LCS signaling (+ 24 * LCS) needs to be included (as shown) in the
following equations. If LCS is disabled, remove (+ 24 * LCS) from the equations.
If paging coordination (NOM I) is enabled and every cell in the BTS site has PCCCH enabled
(pccch_enabled = 1):
RSLGSM @64K =
(n) (59 + S (25 + SM SSIZE 0.125) + 38 H + 24 L + 24 LCS )

(1000 U T )
+ ((31 + 3 CBT S ) PGSM / (8000 U )) NGSM only M S /NGSM Capable M S
The RSL traffic load for GPRS depends on the following factors:
PCCCH provisioning per cell.
The access mechanism used on the air interface. Motorola BSCs allow use of one phase
access or a Motorola proprietary enhanced one phase mechanism.
With one phase access
RSLGP RS@64K =
68P02900W21-T

5.5 GP RS RACH/sec
(32 + CBT S ) PGP RS
(P CCCH BT S) +
1 RP CCCH Cells in BT S
8000 U
1000 U
6-27
Jul 2010
With enhanced one phase access
NOTE
RSLGP RS@64K =

7.5 GP RS RACH/sec
(P CCCH BT S) +
1 RP CCCH Cells in BT S
8000 U
1000 U
Therefore, the total number of 64 kbps RSLs required is:
RSLGSM +GP RS@64K = Roundup (RSLGSM @64k + RSLGP RS@64k )
NOTE
When all cells in the BTS have PCCCH enabled then RSLGPRS@64k = 0.
16 kbps RSLs
If the call parameters differ significantly from those given in Table 6-3, use the following formula
to determine the required number of 16 kbps RSLs.
If LCS is enabled at the BSS, LCS signaling (+ 24 * LCS) needs to be included (as shown) in the
following equations. If LCS is disabled, remove (+ 24 * LCS) from the equations.
If paging coordination (for example NOM I) is enabled and every cell in the BTS site has PCCCH
enabled (pccch_enabled = 1):
RSLGSM@16K
(n)
(59
+
S
(25
+
SMS
0.125)
+
38
H
+
24
L
+
24
L
)
SIZE
CS
4

=
NGSM only MS
BTS )PGSM
(1000 U T) + (31+3C
NGSM
(8000U)
Capable MS
RSLGP RS@16K
6-28

GP RS RACH/sec
(P CCCH BT S) +
1 RP CCCH Cells In BT S 4
=
8000 U
1000 U

68P02900W21-T
Jul 2010
NOTE
RSLGP RS@16K =

7.5 GP RS RACH/sec
(P CCCH BT S) +
(1 RP CCCHCellsInBT S ) 4
8000 U
1000 U
Therefore, the total number of 16 kbps RSLs required is:

RSLGSM+GPRS@16k = Round up (RSLGSM@16K + RSLGPRS@16k)
NOTE
When all cells in the BTS have PCCCH enabled then RSLGPRS@16k = 0.
GPRS RACH arrivals

The average number of RACH arrivals per second is given by:
GP RS RACH/sec =
GP RS U sers BT S Avg Session per user

3600
NOTE
RACH/sec depends on the traffic profile on the network. For the same amount of
data transferred per user in a busy hour, if the traffic is predominantly WAP, then
the number of RACH arrivals is high compared to what is observed when the data
traffic is predominantly FTP transfers. The traffic profile should be calculated based
on the applications running on the network. With interleaving, TBFs it is possible to
have multiple MSs on each timeslot. This should be considered when estimating the
sessions for the formula.
In the equations:
Where:
RSLGSM + GPRS
Is:
the number of BSC-BTS signaling links.
the greater number of TCH and Eralang supported at the BTS.
the ratio of SMSs to calls.
SMSSIZE
H
the average size of the SMS message (payload only).

the number of handovers per call.
Continued
68P02900W21-T
6-29
Jul 2010
Where:
L
LCS
Is:
the location update factor
the number of LCSs per call.
the percent link utilization (example 0.25).
the average call duration.
PGSM
the GSM paging rate in pages/second.
PGPRS
the GPRS paging rate in pages/second.
CBTS
the number of cells at the BTS.
GPRS_RACH/sec
the number of RACH arrivals/ second/BTS.
GPRS_Users_BTS
the number of GPRS users on the BTS.
Avg_Sessions
_per_user
the average number of sessions per user in a busy hour. This

includes the sessions required for signaling (attach, detach, PDP
context activation/ deactivation, routing area updates, and so on).
NGSM_Only_MS
the number of mobiles in the system that do not support GPRS.
PCCCH_BTS
equals 0, if all cells in the BTS have PCCCH enabled, otherwise,

this equals 1.
RPCCCH_Cells_in_BT
the ratio of PCCCH-enabled cells at the BTS (the number of cells

at the BTS with PCCCH enabled divided by the total number of
cells at the BTS).
RCS
probability that a sub is in dedicated mode
RPS
probability that a sub is in Packet transfer mode
BHCA_per_sub
RAU
Busy Hour Call Attempts Per Sub

routing area update
PDPACT/DEACT
PSATT/DETACH
CellUpdate
cell updates (per sub/BH)
ULRate
Traffic per sub/BH (kBytes/hr) - Uplink
DLRate
Traffic per sub/BH (kBytes/hr) - Downlink
Total_subs_per_BSS
the total users under a BSS in the busy hour
The Enhanced Scheduling feature introduces a new parameter percent_traf_cs, which secures
a portion of the bandwidth on the RSL for Circuit Switched (CS) traffic. The default value of this
parameter is 55%, which means that GPRS traffic cannot utilize more than 45% of the total RSL
bandwidth, that is, 45% of the total link capacity (16 k or 64 k).
By setting percent_traf_cs to zero, CS and GPRS calls have equal privileges to occupy the
RSL. Normal RSL planning does not recommend exceeding a MEAN of 25% RSL utilization.
Hence, the thresholds for this parameter are to be triggered under abnormal conditions, where
unexpected sustained surge occurs. Assuming that during a surge of traffic (much higher than
the planned 25%) the ratio of CS to GPRS traffic is maintained, the default value (55%) for
percent_traf_cs can be adjusted to reflect it.
6-30
68P02900W21-T
Jul 2010
BSC to BTS E1 interconnect planning actions
Take an example where total RSL MEAN utilization is 25%, and the ratio of CS to GPRS traffic
4 to 1. In other words, CS contributes 20% to RSL utilization and GPRS contributes 5%.
Maintaining the same ratio during a surge suggests to set percent_traf_cs to 80%, meaning
that GPRS cannot occupy more than 20% of total RSL bandwidth.
BSC to BTS E1 interconnect planning actions

If required, determine the number of E1 links required to connect to a BTS. Redundant links
are added. To determine the impact of different coding schemes on interconnect planning,
use the following equation:
NBSCBT S =
nE
GP RS
i=0

RT F DSO COU N T i + (nCGP RS 4) + (nGGP RS 2) + (L16/4) + L64
31
Where:
NBSC-BTS
Is:
the minimum number of E1 links required (rounded up to an
integer).
nEGPRS
the number of carriers with EGPRS enabled.
nCGPRS
the number of carriers with GPRS CS3 and CS4 enabled and GSM
voice only carriers where the half rate exception case applies.
nGGPRS
the number of carriers with GPRS CS1 and CS2 enabled and GSM
voice only carriers where the half rate exception case does not apply.
L16
the number of 16 kbps RSLs (LAPD links).
L64
the number of 64 kbps RSLs (LAPD links).
RTF_DSO_COUNTi
value of rtf_dso_count for the RTF.
NOTE
This formula includes both L16 and L64 to provide the necessary number of RSLs. As,
either L16 or L64 RSL can be used to a single BTS, but not both.
Table 6-8 defines the backhaul required for the different coding schemes and configurations.
Table 6-8 Backhaul requirements

16 kbps
32 kbps
GSM Voice only carries

where the half rate
exception case does not
apply.
GSM Voice only carriers

where the half rate exception
case does apply.
Carriers with only GPRS

CS1 and CS2 enabled.
Carriers with only GPRS CS1,

CS2, CS3, and CS4 enabled.
68P02900W21-T
VersaTRAU backhaul
EGPRS capable carriers
(MCS1-MCS9).
6-31
Jul 2010
BSC to BTS E1 interconnect planning example
NOTE
All EGPRS carriers (pkt_radio_type = 3) use VersaTRAU frame formats on the
backhaul between BTS and PCU to carry the data for PDTCHs on this carrier
irrespective of whether VersaTRAU is restricted/unrestricted.
BSC to BTS E1 interconnect planning example

Assume a three sector BTS with 8 carriers per sector. Each sector has:
2 carriers of GSM voice with no half rate exception.
1 carrier with GPRS CS1 and CS2.
2 carriers of GSM voice with half rate exception.
2 carriers of GPRS CS1, CS2, CS3, CS4.
1 carrier of EGPRS, VersaTRAU is restricted and all EGPRS RTFs are non-BCCH.
The number of E1s is calculated as follows:
N umber of E1s =
{[(3 8) + (12 4) + (9 2) + 0] + 1}
=3
31
In this example, 3 E1s are required to backhaul this BTS to the BSC. To find out the total
number of E1s required for a BSC, all of the BTSs backhaul requirements would require to be
calculated and then added together.
Refer to the network configuration to determine if backhaul from multiple BTSs could be
multiplexed on a single E1. Examples of this type of capability would be if:
The BTSs are daisy chained,
The network uses cross connect equipment between BTSs and BSCs.
The same example is presented in a scenario where VersaTRAU is unrestricted. There is a 3

sector BTS with 8 carriers per sector. Each sector has:
6-32
2 carriers of GSM voice with no half rate exception.
1 carrier with GPRS CS1 and CS2.
2 carriers of GSM voice with half rate exception.
2 carriers of GPRS CS1, CS2, CS3, and CS4.
1 carrier of EGPRS, VersaTRAU is unrestricted and RTF backhaul is set to 5.
68P02900W21-T
Jul 2010

GPROCs for RSL and GSL processing BSC to BTS E1 interconnect planning actions
Determining the number of LCF
The number of E1s is calculated as follows:
N umber of E1s =
{[(3 5) + (12 4) + (9 2) + 0] + 1}
=3
31
In this example, 3 E1s are required to backhaul this BTS to the BSC. To find out the total
number of E1s required for a BSC, all the BTSs backhaul requirements would require to be
calculated and then added.
Determining the number of LCF GPROCs for RSL and GSL

processing BSC to BTS E1 interconnect planning actions
Determine the number of GPROCs required to support the layer 3 call processing.
NOTE
GPROC2, GPROC3, and GPROC3-2 or a combination of the three can perform layer
3 call processing for GSM and GPRS, but GPROC3 and GPROC3-2 have a greater
capacity than GPROC2. If an LCF is allocated to a GPROC2, BSC configurations with
a mix of GPROCs which includes GPROC2s are not recommended when the LCFs
supporting RSLs have been planned based on the capabilities of GPROC3s/GPROC3-2s
due to the risk of overloading. Refer to Generic processor (GPROC) on page 6-53
later in this chapter.
The calculations are performed separately for the number of GPROCs required for GSM traffic
and for GPRS traffic.
The LCF GPROCs can simultaneously handle signaling traffic from both the GSM and GPRS
parts of the network. It is possible to calculate the GPRS/EGPRS part of the signaling load for
the LCF GPROCs in fractional increments. The GPRS/EGPRS LCF GPROC requirements can
be directly added to the GSM requirements to determine the total number of LCF GPROCs to
equip at a BSC.
GSM layer 3
There are two methods for calculating this number. The first is used when the call parameters
are like those listed in Table 6-3 (standard traffic model). The second method is used when
the call parameters differ significantly from those listed in the tables (that is, non-standard
traffic model).
Standard traffic model (without LCS)
Use the following formula for the GPROC type:
68P02900W21-T
6-33
Jul 2010
Determining the number of LCF GPROCs for RSL and GSL processing BSC to BTS E1 interconnect planning actions Chapter
6: BSC planning steps and rules
LCFs using GPROC2 boards:

GL3 =
n
B
C
+
+
308.66
9.29
87
LCFs using GPROC3 or GPROC3-2 boards:

GL3 =
n
B
C
+
+
363.35
18.32
396
Where:
GL3
Is:
the number of LCF GPROCs required to support the layer 3 call processing.
the number of TCHs at the BSC (see Half rate assumptions on page 6-20
earlier in this chapter).
the number of BTS sites.
the number of cells.

If the call parameters differ significantly from those given in Table 6-3, the alternative formula
given should be used to determine the recommended number of LCFs based on the type
of GPROC.
LCFs using GPROC2 boards:
GL3 = n
C
[1 + 0.35 S + 0.35 H (1 0.43 i) + 0.30 L + 0.35 Lcs]
+ (0.00113 PGSM + 0.0005) B +
(13.89 T)
87
LCFs using GPROC3 or GPROC3-2 boards:
GL3 = n
6-34
[1 + 0.42 S + 0.5 H (1 0.5 i) + 0.42 L + 0.35 Lcs]

C
+ (0.00059 PGSM + 0.0001) B +
(34.72 T)
396
68P02900W21-T
Jul 2010

GPROCs for RSL and GSL processing BSC to BTS E1 interconnect planning actions
Where:
Determining the number of LCF
Is:
GL3
the number of LCF GPROCs required to support the layer 3 call processing.
the number of TCHs under the BSC (see Half rate assumptions on page 6-20
earlier in this chapter).
the ratio of SMSs to calls.
the ratio of intra-BSC handovers to all handovers.
the location update factor.
PGSM
the GSM paging rate in pages per second.
LCS
Having calculated the LCF GPROCs for RSLs, ensure that the traffic is evenly distributed across
the LCFs. This can be difficult in cases where large sites are being used, and in such cases
additional LCFs are required. Alternatively, use the formula for traffic channels on each LCF. If
the calculated value exceeds 1, the sites should be redistributed on the other available LCFs, or
additional LCFs should be equipped.
GPRS layer 3
The MSC can send GSM alerting pages to a GPRS/EGPRS mobile that operates in class A or
class B modes. The significance of this is that GPRS/EGPRS mobile stations capable of class
A and B operation create a larger population of GSM capable mobile stations that should be
considered when provisioning the LCF GPROCs. The planning information provided here should
be used for this provisioning.

GL3 GP RS = 0.002 T otal RACH/sec 1 RP CCCH Cells + 0.00075 B PGP RS P CCCH BSS
Where:
T otal Rach/sec =
68P02900W21-T
GP RS subs per P CU Avg session per subs

3600
6-35
Jul 2010
Determining the number of LCF GPROCs for RSL and GSL processing BSC to BTS E1 interconnect planning actions Chapter
6: BSC planning steps and rules
Where:
GL3_GPRS
Total_RACH/sec
RPCCCH_Cells
B
PCCCH_BSS
PGPRS
Is:
the sum of all GPRS RACH arrivals at the BSC.
the number of TCHs under the BSC (see Half rate assumptions on
page 6-20 earlier in this chapter).
the ratio of PCCCH-enabled cells (the number of cells in the BSS
with PCCCH enabled divided by the total number of cells in the BSS.
0 if all cells in the BSS have PCCCH enabled, otherwise = 1.
paging rate in pages per second.
GPRS_subs_per
_PCU
the total number of GPRS users under a PCU in the busy hour.
Avg_session_per
_subs
the average number of sessions per subscriber in a busy hour

(includes sessions for signaling).
NOTE
For GSR10, it is advantageous to use GPROC3/GPROC3-2s LCF while introducing
sites using the HIISC-2/E with BBU-E. The greater on-board memory of the
GPROC3/3-2s LCF compared with GPROC2 LCF in certain scenarios enable faster
codeloading to these BTS sites using the HIISC-2/E with BBU-E.
6-36
68P02900W21-T
Jul 2010
Determining the number of MTLs required
Determining the number of MTLs required
Introduction
MTLs carry signaling traffic between the MSC and BSC. BSC supports MTL with 64 kbps and
2 Mbps. The number of required MTLs depends upon the BSS configuration size and traffic
model. 64 kbps MTLs are carried on E1 links between the MSC and BSC, which are also used
for traffic. HSP MTLs are only supported on E1 links.
NOTE
HSP MTL (High Speed MTL) is part of Huge BSC feature to provide 2M MTL
capacity. When it is deployed, GPROC3-2 is required to host HSP LCF.
Only one HSP MTL can be supported on a GPROC3-2 board.
Mix configuration of 64 kbps and HSP MTLs is not supported.
The following factors should be considered when planning the links from the BSC to MSC:
Determine traffic requirements for the BSC. Traffic is determined using either of the
following methods:
Multiply the number of subscribers expected to use the BSC by the average traffic
per subscriber.
or
Total the traffic potential of each BTS under the BSC, determined by the number of
TCHs available, the number of TCHs required or the subscriber potential.
Determine the number of trunks to support the traffic requirements of the BSC using
Erlang B tables at the required blocking rate.
Determine the MTL loadshare granularity to be used for the BSC. MTL loadshare
granularity determines the number of logical links that is mapped onto the physical links.
Setting the mtl_loadshare_granularity database element to 1 results in a more even
distribution of traffic across the MTL links. This feature allows a more gradual increase in
the number of MTLs required with the increased traffic load on the BSC.
68P02900W21-T
6-37
Jul 2010
Determine if LCS is enabled in the BSS and which LCS architecture is supported by
the BSC. The BSC can support either NSS-based LCS architecture or BSS-based LCS
architecture, but not both.
For example, with an increase in the number of MSC-BSC trunks from 1550 to 1600,
with 20% link utilization, the number of 64 k MTLs required for a BSC goes up from 8 to
16, if using a granularity of 0. When using a granularity of 1, only 10 64 k MTLs are
required. This results from the enhanced load sharing of 64 k MTLs and illustrates the
difference between setting the load share granularity to 0 and 1 respectively. Table 6-9
and Table 6-10 illustrate the difference between setting the load share granularity to 0
and 1 for 64 k MTL. Table 6-11 and Table 6-12 illustrate the difference between setting
the load share granularity to 0 and 1 for HSP MTL. Load share granularity of 0 means 16
logical links mapped to equipped physical MTL links. Load share granularity of 1 means
64 logical links mapped to equipped physical MTL links.
These calculations are for the MTLs required from the BSS perspective, using the
BSS planning rules. If the MSC vendor supplies their own planning rules for a given
configuration, the more conservative MTL provisioning figures should be used. If the MSC
vendor does not provide the planning rules for the MTLs required in a downlink direction,
then use a load share granularity of 0 to be conservative in MTL provisioning.
Load sharing of MTLs in the downlink direction depends on the mechanism used by the
MSC to load share the signaling links from the MSC to BSC.

The number of MSC to BSC signaling links (MTL) required depends on the desired link
utilization, the type, and capacity of the GPROCs controlling the MTLs and the MTL load share
granularity. The BSS software distributes call-signaling traffic across 16 or 64 logical links,
which are then evenly spread across the active MTLs.
NOTE
GPROC3s are required in the BSP slots.
GPROC3-2 is required at BSC for supporting HSP MTL. There is only one HSP
MTL per GPROC3-2 board.
CCITT C7 uses a 4-bit number, the Signaling Link Selection (SLS), generated by the upper
layer to load share message traffic among the in-service links of a link set. When the number
of in-service links is not a power of 2, some links experience a higher load. The BSS supports
distribution of signaling in the uplink direction, over 64 logical links. The BSS evenly distributes
the 64 logical links over the active MTLs. The number of MTLs is a function of the number
of MSC to BSC trunks or the offered call load and signaling for the call load. Table 6-9 and
Table 6-10 give the recommended minimum number of MSC to BSC signaling links based on the
typical call parameters, detailed in Table 6-3. The value for N is the greater of the following:
The offered call load (in Erlangs) from all the BTSs controlled by the BSC.
The potential carried load (approximately equal to the number of MSC to BSC trunks).
The offered call load for a BSS is the sum of the offered call load from all the cells of the BSS.
The offered call load at a cell is a function of the number of TCHs and blocking. As blocking
increases, the offered call load also increases. For example, for a cell with 15 TCHs and 2%
blocking, the offered call load is 9.01 Erlangs.
6-38
68P02900W21-T
Jul 2010
NOTE
Before setting the load share granularity to 1, it is recommended that confirmation is
gained from the Motorola local contact, or local office, that the switch is compatible
with the load share granularity set to 1.
Table 6-9 and Table 6-10 show how to estimate the number of 64 k MTLs to be used for the BSC,
with 20% and 40% link utilization, respectively.
Table 6-9
Number of MSC and BSC signaling links without LCS (20% utilization)
N = the greater of number

of MSC-BSC trunks or the
offered load from the BTSs
Number of MTLs with 16

logical links

logical links
Minimum
required
With
redundancy
Minimum
required
With
redundancy
N 85
85 < N 170
170 < N 350
16
16
11
12
350 < N 450
16
16
13
14
450 < N 660
16
16
16
16
660 < N
16
16
16
16
Table 6-10 Number of MSC and BSC signaling links without LCS (40% utilization)
N = the greater of number
of MSC-BSC trunks or the
68P02900W21-T

logical links

logical links
Minimum
required
With
redundancy
Minimum
required
With
redundancy
N 85
85 < N 170
170 < N 350
350 < N 520
520 < N 880
16
16
10
11
880 < N 1000
16
16
11
12
1000 < N 1200
16
16
13
13
1200 < N 1500
16
16
16
16
1500 < N
16
16
16
16
6-39
Jul 2010
Non-standard traffic model for 64 k MTL
Table 6-11 shows how to estimate the number of 2M HSP MTLs to be used for the BSC, with
13% link utilization.
Table 6-11 Number of MSC and BSC signaling links without LCS (13% utilization)
N=the greater of number
of MSCBSC trunks or the

logical links

logical links
Minimum
required
With
redundancy
Minimum
required
With
redundancy
N 482
483 < N 1966
1966 < N 2956
2956 < N 3315
3315 < N 4800
4800 < N 6200
The capacities shown in Table 6-9 , Table 6-10 and Table 6-11 are based on the standard traffic
model shown in Table 6-3.
It is recommended that the C7 links be designed to operate at no more than 40% utilization
when the MTL/LMTL is running on a GPROC2 or GPROC3/GPROC3-2. Before use of the 40%
utilization for GPROC2 or GPROC3/GPROC3-2, it is imperative that the operator verifies if
the MSC vendor can also support 40% utilization at the MSC end. If not, then only 20% link
utilization should be used for GPROC2 and GPROC3/GPROC3-2.
It is required the HSP MTLs be designed to operate at no more than 13% utilization.
Non-standard traffic model for 64 k MTL

If the call parameters differ significantly from those given in Table 6-3, the following procedure
is used to determine the required number of 64 k DS0 MSC to BSC signaling links:
nlink =
Use the formula to determine the maximum number of Erlangs supported by a C7 signaling
link (nlink).
1000 U T
40 + S (26 + 0.125 SM SSIZE ) + 24 H (1 0.83 i) + 24 L + CICS LCS + 9 PP C
Use the formula to determine the maximum number of Erlangs supported by a GPROC
(LCF-MTL) supporting a C7 signaling link (nlLCF-MTL).
nLCF M T L =
20 T
(1 + 0.16 S + 0.5 H (1 0.6 i) + 0.42 L + 0.45 LCS + PP C (0.005 B + 0.05))
The maximum amount of traffic an MTL (a physical link) can handle (nlmin) is the smaller
of the two numbers from:
nlmin = M IN nlink , nlLCF M T L
6-40

68P02900W21-T
Jul 2010
Non-standard traffic model for HSP MTL
Signaling over the A Interface is uniformly distributed over some logical links. The number
of logical links is defined on the BSC by database parameter mtl_loadshare_granularity
= 0 or 1, which corresponds to 16 or 64 logical links, respectively, over which the MTL
signaling is load shared. Hence, the total amount of traffic that a logical link would hold, is
calculated as:
Nlogical =
N
Ng
Next determine the number of logical links each MTL (physical link) can handle
nlog per mtl = rounddown
nlmin
Nlogical
Finally, the number of required MTLs (mtls) is:
mtls = roundup
Ng
nlog per mtl
+ R 16
NOTE
mtls should not exceed 16 per BSC.
The formula to determine the maximum number of Erlangs supported by a

GPROC (LCF-MTL) has been calculated using 70% mean utilization of GPROC2
(see Calculate the number of LCFs for MTL processing on page 6-43 later in this
section). Suggest to maintain the mean utilization of GPROCs at or 70%.

If the call parameters differ significantly from those given in Table 6-3, the following procedure
is used to determine the required number of MSC to BSC HSP signaling links:
nlink =
Use the formula to determine the maximum number of Erlangs supported by a C7 signaling
link (nlink).
31000 U T
40 + S (26 + 0.125 SM SSIZE ) + 24 H (1 0.83 i) + 24 L + CICS LCS + 9 PP C
Use the formula to determine the maximum number of Erlangs supported by a GPROC3-2
(LCF-MTL) supporting a C7 signaling link (nlLCF-MTL).
n1LCF M T L =
68P02900W21-T
(1 +
0.53 S
0.5 H
(1
0.92 i)
56 T
+ 0.52 L + 0.92 LCS + PP C (0.006 B + 0.10))
6-41
Jul 2010
The maximum amount of traffic an MTL (a physical link) can handle (nlmin) is the smaller
of the two numbers from the previous two formulae.
nlmin = M IN nlink , nlLCF M T L
Signaling over the A Interface is uniformly distributed over some logical links. The number
of logical links is defined on the BSC by database parameter mtl_loadshare_granularity
= 0 or 1, which corresponds to 16 or 64 logical links, respectively, over which the MTL
signaling is load shared. Hence, the total amount of traffic that a logical link would hold, is
calculated as:
Nlogical =
N
Ng
Next determine the number of logical links each MTL (physical link) can handle
nlink
Nlogical
Finally, the number of required MTLs (mtls) is:
mtls = roundup
6-42
Ng
nlog per mtl
+ R 16
68P02900W21-T
Jul 2010
Calculate the number of LCFs for MTL processing
Where:
Is:
the percent link utilization (for example 0.13).
call hold time.
the ratio of SMSs per call
SMSSIZE
the average size of the SMS message (payload only).
the ratio of intra-BSC handovers to all handovers.
the location update factor.
Clcs
26 for NSS-based architecture. 31 for BSS-based architecture.
LCS
PPC
the number of pages per call.
the number of BTSs supported by the BSC.
mtls
the number of MTLs required
round up
round up to the next integer.
round down
MIN
N
Ng
R
round down to the next integer.

the minimum of two values.
the number of MSC-BSC trunks.
the number of logical links (16 or 64).
the number of redundant MTLs.
Calculate the number of LCFs for MTL processing

The purpose of the MTL LCF GPROC is to support the functions of MSC link protocol.
NOTE
Both GPROC2 and GPROC3 or a combination of the two can perform MTL
processing. Refer to Generic processor (GPROC) on page 6-53 in this chapter.
It is not recommended that an LCF supports both MTLs and RSLs. It is not
permitted for an LCF to support both MTLs and LMTLs.
LCFs for 64 k MTL links

Since one LCF GPROC can support two 64 k MTLs, the number of required LCFs is:
NLCF = Roundup
mtls
2
However, if the traffic model does not conform to the standard model:
68P02900W21-T
6-43
Jul 2010
LCFs for HSP MTL links
If 2 * nlink > nlLCF-MTL, then NLCF = mtls

Otherwise,
NLCF = Roundup
mtls
2
LCFs for HSP MTL links

Since one GPROC3-2 LCF can support one HSP MTL, the number of required LCFs is the
number of HSP MTLs.
NLCF = mtls
Where:
NLCF
ROUND UP
Is:
the number of LCF GPROCs required.
rounding up to the next integer.
mtls
calculated in the previous section.
nlink
nlLCF-MTL
MSC to BSC signaling over a satellite link

The BSC supports Preventive Cyclic Retransmission (PCR) to interface to the MSC over a
satellite link. PCR retransmits unacknowledged messages when there are no new messages to
be sent. This puts an additional processing load on the GPROC (LCF-MTLs) controlling the C7
signaling links. It is recommended that when PCR is used, that the number of MTLs (and thus
the number of LCF-MTLs) be doubled from the number normally required.
6-44
68P02900W21-T
Jul 2010
Determining the number of LMTLs required
Determining the number of LMTLs required
Introduction
LMTLs carry the LCS signaling traffic between the BSC and the SMLC. This is only applicable
for BSS-based LCS architecture when LCS is enabled in the BSS.
The number of required LMTLs depends upon the BSS configuration size and traffic model.
LMTLs are carried on E1 between the SMLC and BSC.
The following factors require to be considered when planning the number of LMTL links from
the BSC to the SMLC:
Determine the LCS traffic requirements of the BSC.
A BSC can only connect to one SMLC.
Determining the number of LMTLs

Traffic model
The number of required LMTLs depends upon the BSS configuration size and traffic model. See
Table 6-1, Table 6-3, and Table 6-5.
LMTL number
Use the following formula to determine the required number of 64 kbps LMTLs (rounded up
to the next integer):
LLM T L = Roundup
LCS BSC Rate 19

1000 UBSC SM LC
Where:
LLMTL
Is:
the number of BSC to SMLC signaling links.
LCS_BSC_Rate
requests number per BSC per second.
UBSC_SMLC
the percentage of the link utilization.
ROUND UP
68P02900W21-T
6-45
Jul 2010
BSC to SMLC interconnection planning actions
BSC to SMLC interconnection planning actions

Determine the number of E1 links required to connect to an SMLC. Redundant links are added,
if required.
NBSCSM LC = Roundup
LLM T L
31
Where:
Is:
NBSC-SMLC
the minimum number of E1 links required (rounded up to an integer).
ROUND UP
NOTE
The BSC-SMLC signaling link LLMTL can only be terminated on an E1.
Calculate the number of LCFs for LMTL processing

The purpose of the LMTL LCF GPROC is to support the functions of the SMLC link protocol. For
the LCF GPROC, one dedicated LCF-LMTL is required for processing LMTLs.
NOTE
6-46
Both GPROC2 and GPROC3 or a combination of the two can perform LMTL
processing. Refer to Generic processor (GPROC) on page 6-53 later in this
chapter. If the LMTL functionality is assigned to the BSP, a GPROC3 is required.
It is not recommended that an LCF supports both LMTLs and RSLs.
It is not permitted for an LCF to support both MTLs and LMTLs.
68P02900W21-T
Jul 2010
Determining the number of XBLs required
Determining the number of XBLs required
Introduction
XBLs carry the signaling traffic between the BSC and RXCDR. The number of XBL links required
depends upon the number of CICs and/or the number of Ater interface channels.
The following factors require to be considered when planning the number of XBL links from the
BSC to the RXCDR:
Determine the traffic requirements of the BSC and/or the number of trunks (CICs) used
between the BSC and RXCDR.
Determine the mode (backward compatibility or auto-connect/ enhanced auto connect) in

which the BSC and RXCDR operate. See Chapter 2 Transmission systems for a description
of the modes.
A maximum of 20 XBLs (64 kbps or 16 kbps) can be configured for a BSC/RXCDR.
A BSC can connect to a maximum of 10 RXCDRs and vice-versa.
Determining the number of XBLs

The calculations should be performed for every connected RXCDR.
The number of XBL links depends on the number of trunks on the BSC-RXCDR interface and
whether the auto-connect mode or enhanced auto-connect mode is enabled at the RXCDR/BSC.
Table 6-12 details the minimum number of XBLs required to support the given number of trunks
between the BSC and RXCDR, with auto-connect mode or enhanced auto-connect mode.
68P02900W21-T
6-47
Jul 2010
Table 6-12
Number of BSC to RXCDR signaling links

No redundancy
With redundancy
N = number of
redundancy MSC
to BSC trunks
Number of 64
kbps XBLs
Number of 16
kbps XBLs
Number of 64
kbps XBLs
Number of 16
kbps XBLs
N 1200
1200 < N
2400
16
2400 < N
3200
11
22*
3200 < N
4800
16
32*
4800 < N
6200
20
10
40
* This exceeds the 20 XBL limit and is therefore not a valid configuration.
It is recommended that the XBL link utilization does not exceed 40%. This allows a link to
double the capacity (to 80%) under fault conditions (in some configurations). 80% utilization,
queuing delays could become substantial. Although both auto-connect mode and enhanced
auto-connect mode apply a load, it is the enhanced auto-connect mode load that can vary
depending on system configuration. When operating in this mode, the XBL link utilization
should be monitored to determine if additional capacity is required. The number of XBL links as
shown is a minimum number that are required, regardless of measured utilization. This is due
to peak usage requirements during start-up and reconfigurations due to faults and maintenance.
XBL link utilization is a network statistic, calculated on a per XBL basis.

The minimum number of XBL links required as given in Table 6-12 was verified using a standard
set of call parameters. These are given in Table 6-13.
Table 6-13
Typical call parameters relating to XBLs

Parameter
Link utilization
Call duration
Average XBL message size
Value
40%
83.27 s
50 bytes
XBL messages per new call *
XBL messages per full rate <-> half rate

handover
Full rate <-> half rate handovers per call
* Mobile origination, mobile termination, hand-in from MSC.
6-48
68P02900W21-T
Jul 2010
Non standard traffic model
Non standard traffic model

If the call parameters differ significantly from those given in Table 6-13, use the following
formula to determine if the required number of 64 kbps XBLs (rounded up to the next integer)
should be adjusted:
XBL =
(N/T ) (Mnewcell + Mhandover Hf rhr ) LXBL 8

64000 UBSCRXCDBC
Use the following formula to determine if the required number of 16 kbps XBLs (rounded
up to the next integer) should be adjusted:

(N/T ) (Mnewcell + Mhandover Hf rhr ) LXBL 8
XBL =
4
64000 UBSCRXCDBC
Where:
XBL
Is:
the number of BSC to RXCDR signaling links.
the number of MSC-BSC trunks.
the average call duration in seconds.
Mnewcall
the number of XBL messages per new call.
Mhandover
the number of XBL messages per hr <-> fr handover.
Hfr-hr
the number hr <-> fr handovers per call.
LXBL
the average length of an XBL message in bytes.
U(BSC-RXCDR)
the percentage link utilization (0.40, for example).
Double the number if redundancy is desired.

The number of XBLs required is then the larger of the number as determined by the formula
and the number given in Table 6-12.
68P02900W21-T
6-49
Jul 2010
Determining the number of GSLs required
Determining the number of GSLs required
The connection between PCU and BSC can be E1 and/or Ethernet link. Ethernet links and E1
links can be equipped simultaneously in the system.
When only E1 is used, PCU needs one E1 to carry GSL signaling, and a second E1 for
redundancy. In this configuration, PCU can support up to 30 primary GSL 64 kbps timeslots and
30 redundant. Each 64 kbps timeslot is one LAPD channel.
When Ethernet link is used, maximum of 30 GSL 64 kbps timeslots can be carried by one
Ethernet link. In the following configuration, up to 60 GSL 64 kbps timeslots can be supported
in the system:
Only Ethernet links are used.
Ethernet and E1 links are used simultaneously.
It is recommended that two GSL E1/Ethernet links per PCU are provisioned even when the GSL
is lightly loaded. GSL provision should be load-balanced over multiple links, as the mechanism
for providing resiliency against link failures. The number of GSLs required is calculated
as follows:
GSL = M AX GSLrun time , GSLinit time
The requirement for the number of GSLs during system initialization (GSLinit_time) is 6. Each
GSL message consists of three parts: LAPD protocol, BSS executive header protocol, and the
application message carrying actual signaling information. The LAPD and BSS protocol parts
can be considered messaging overhead. In addition, in a similar manner to RSL, the GSL traffic
depends on the access mechanism used on the Air interface. The calculation for the required
number of GSL links during runtime (after the system stabilizes) is as shown.
GSLrun time = GSLP aging + GSLRACH

GSLRACH =
6-50

1 RP CCH Cells T otal RACH/sec 5.5
1000 U
68P02900W21-T
Jul 2010
NOTE
GSLRACH

1 RP CCH Cells T otal RACH/sec 7.5
=
1000 U
Where:
T otal RACH/sec =
GP RS subs per P CU Avg session per subs

3600
GPRS paging is performed per routing area (RA). A GPRS page is sent to all cells within the RA.
If PCCCH is enabled at a cell then the GPRS page is sent to that cell on the GDS TRAU link. The
GSL requirement for GPRS paging is given by the following:
GSLP aging =
Where:
GSL
8.5 PGP RS N o LCF s f or RSL P CCCH BSS

1000 U
Is:
the number of 64 kbps LAPD GSL timeslots to provision.
GSLinit_time
the number of GSLs required for system initialization.
GSLrun_time
the number of GSLs required for signaling while the system is stable.
PGPRS
Total_RACH/sec
U
the GPRS paging rate in pages per second.

the sum of all GPRS RACH arrivals on the BSC.
the link utilization, typically 0.25.
GPRS_subs_per_
PCU
the total GPRS users under a PCU in the busy hour.
Avg_session_per_
subs
the average number of sessions per subscriber in a busy hour (this

includes sessions for signaling).
RPCCCH_Cells
the ratio of PCCCH-enabled cells (the number of cells with PCCCH

enabled divided by the total number of all cells in the BSS).
No_LCFs_for_RSL
PCCCH_BSS
the number of LCF boards in the BSC that terminate RSL links.
= 0 if all cells in the BSS have PCCCH enabled, otherwise = 1
RCS
probability that a sub is in dedicated mode.
RPS
probability that a sub is in Packet transfer mode.
BHCA_per_sub
Busy Hour Call Attempts Per Sub.

Continued
68P02900W21-T
6-51
Jul 2010
Load balancing
Where:
H
Is:
number of handovers per call.
PGSM
GSM circuit-switched paging rate in pages per second.
RAU
routing area update.
PDPACT/DEACT
PDP context activation/deactivation (per sub/BH).
PSATT/DETACH
PS attach/detach rate (per sub/BH).
CellUpdate
T
cell updates (per sub/BH).

call duration.
ULRate
Traffic per sub/BH (kBytes/hr) Uplink.
DLRate
Traffic per sub/BH (kBytes/hr) Downlink.
Total_subs_per_
BSS
the total users under a BSS in the busy hour.
Load balancing
When applying even distribution of GSLs terminated on LCFs, the GSL traffic is load balanced
over all GSLs. Furthermore, should more than one GSL terminate on an LCF, the load is
balanced over these GSLs. The general rule of thumb is to terminate at least one GSL on a SITE
LCF in a heavily loaded system to avoid unnecessary LAN traffic.
In sysgen, the gsl_lcf_mapping parameter determines if the BSS automatically distributes the
GSLs to different LCFs (Auto mode) or if the operator should specify the LCF (Manual mode)
that terminates the GSL.
In Auto mode, the user is not prompted for the LCF during the equipage of the GSL and the
system distributes the GSLs as evenly as possible on the LCFs.
In Manual mode, the user is prompted for an LCF during the equipage of the GSL. Auto mode
of gsl_lcf_mapping is only valid in sysgen. Outside of sysgen, gsl_lcf_mapping is always
set to Manual.
Should the operator require to specify LCFs outside of sysgen mode or wish to configure the
system manually, the GSLs should be evenly distributed among the LCFs that terminate the
RSLs.
The operator can choose to distribute manually the GSLs. Use a similar approach to evenly
distribute among LCFs carrying RSL traffic. Although it is not necessary, the operator can
choose to consider the total count of PDTCHs on each LCF and assign more GSLs to those
LCFs having more PDTCHs.
6-52
68P02900W21-T
Jul 2010
Generic processor (GPROC)
GPROC nomenclature
For the purposes of this manual only and to avoid confusion between different versions of the
generic processor (GPROC), the following nomenclature is used:
GPROC2 specifically refers to the GPROC2.
GPROC3 specifically refers to the GPROC3.
GPROC3-2 specifically refers to the GPROC3 phase2.
GPROC is used in this manual as a non-specific term referring to both GPROC2, GPROC3,
and GPROC3-2.
Introduction
Generic processor (GPROC) boards are used throughout the Motorola BSS as a control
processor.
This section describes the BSC GPROC types and their functions. The BSC configuration type
and GPROC device type are essential factors for BSC planning.
The GPROC3/GPROC3-2 is a high performance direct replacement for GPROC2s. This
allows for any combination of GPROC types to be installed except in the BSP slots where
a GPROC3/GPROC3-2 is required.
One GPROC3-2 is required to support each HSP MTL.
GPROC functions and types

GPROCs are assigned functions and are then known by their function names.
The GPROC is the basic building block of a distributed architecture. The GPROC provides the
processing platform for the BSC. By using multiple GPROCs, software tasks can be distributed
across GPROCs to provide greater capacity. The set of tasks that a GPROC is assigned, depends
upon the configuration and capacity requirements of the BSC. Although every GPROC of the
same type is similar from a hardware standpoint, when a group of tasks are assigned to a
GPROC, it is considered to be a unique GPROC device type or function in the BSC configuration
management scheme.
There are a limited number of defined task groupings in the BSC, which result in the naming of
four unique GPROC device types for the BSC. The processing requirement of a particular BSC
determines the selection and quantity of each GPROC device type.
68P02900W21-T
6-53
Jul 2010
GPROC functions and types
The possible general task groupings or functions for assignment to GPROCs are:
BSC common control functions.
OMC-R communications - OML (X.25) including statistics gathering.
MSC link protocol (C7).
SMLC link protocol (C7).
BSS Layer 3 call processing (BSSAP) and BTS link protocol, RSL (LAPD).
LAPD-type GDS link protocol, GSL.
Cell broadcast center link (CBL).
Optimization Link (OPL)
The defined GPROC devices and functions for the BSC are as follows (also see Table 6-14):
Base Site Control Processor (BSP).
Link Control Function (LCF).
Operations and Maintenance Function (OMF).
Code Storage Facility Processor (CSFP).
Table 6-14 defines the GPROC types/functions for different software releases.
Table 6-14
GPROC type/function
Software
Release
BSP
MTL-LCF
LMTLLCF
RSL-LCF
OMF
CSFP
GSR 8
GPROC3
GPROC2
or
GPROC3
GPROC2
or
GPROC3
GPROC2
or
GPROC3
GPROC2
or
GPROC3
GPROC2
or
GPROC3
GSR9
GPROC3
or
GPROC3-2
GPROC2
or
GPROC3
or
GPROC3- 2
GPROC2
or
GPROC3
or
GPROC3- 2
GPROC2
or
GPROC3
or
GPROC3- 2
GPROC2
or
GPROC3
or
GPROC3- 2
GPROC3
or
GPROC3-2
GPROC3 GPROC2 or
or
GPROC3 or
GPROC3-2 GPROC3- 2
GPROC2 or
GPROC3 or
GPROC3- 2
GPROC2 or
GPROC3 or
GPROC3- 2
GPROC2 or
GPROC3 or
GPROC3- 2
GPROC3 or
GPROC3-2
GSR 10
NOTE
6-54
It is mandatory for a GPROC3/GPROC3-2 to be installed in BSP capable slots

at the BSC. A GPROC3-2 is required for hosting HSP MTL LCFs. For the 1000
carriers BSC configuration, GPROC3 or GPROC3-2 is required for the other
GPROC functions.
GPROC3/3-2 is mandatory for OMF when large_site_support is enabled, which

extends the support carriers up to 36 per site when equipping two BBU-Es with
6 (R)CTU8m is configurated.
68P02900W21-T
Jul 2010
GPROC3/GPROC3-2 planning assumptions
GPROC3/GPROC3-2 planning assumptions

The following assumptions are made regarding planning GPROC3 and GPROC3-2 usage:
GPROC3/GPROC3-2 processing performance is improved, when compared with GPROC2.
A GPROC3/GPROC3-2 is required in the BSP slots.
Only GPROC3/GPROC3_2 can be used as CSFP.
A GPROC3-2 is required for supporting each HSP MTL.
The GPROC3/GPROC3-2 can be used for other board functions besides BSP, in the BSC
as a board level replacement. Replacement is not mandatory for these functions. The
GPROC3/GPROC3-2 does not provide any capacity and performance improvements in
terms of number of links or sites supported. In GSR10 and onwards it can be used to
increase the capacity of LCFs used to RSLs and BTSs. The only difference from other
board functions is that in the GPROC3/GPROC3-2, lower processor utilizations are seen.
The GPROC3/GPROC3-2 can be used as board level replacement for GPROC2 at a BTS.
The GPROC3/GPROC3-2 can be used as board level replacement for GPROC2 at the
RXCDR.
The GPROC3/GPROC3-2 is mandatory for 1000 carriers BSC configuration.
GPROC3/3-2 is mandatory for OMF when large_site_support is enabled, which extends

the support carriers up to 36 per site when equipping two BBU-Es with 6 (R)CTU8m is
configurated.
BSC types
The BSC is configured as one of two types; the type is determined by the GPROCs present.
BSC type 1
Master GPROC
Running the base site control processor (BSP) and carrying out operations and
maintenance functionalities.
Link control processor (LCF)
Running the radio-signaling link (RSL) and layer 3 processing or MTL/LMTL (C7
signaling link) communications links. It also runs the GSLs for GPRS signaling
between the BSC and PCU.
68P02900W21-T
6-55
Jul 2010
BSC type 2
Master GPROC
Running the BSP
LCF
OMF
Running the O&M, including statistics collection, and OML link (X.25 control links
to the OMC-R.
The following factors should be considered when planning the GPROC complement:
BSP limitation
It is mandatory to deploy GPROC3s/GPROC3-2 in any potential BSP slot in the site, both
active and standby (slot 20 and 24 in shelf 0 and slot 20 in shelf 1).
Each BSC needs:

One master GPROC3/GPROC3-2 (BSP).
One OMF (if it is a type 2 BSC).
Some LCFs for MTLs, see Link control function on page 6-56.
One dedicated LCF for LMTL (if LCS is enabled and the BSS LCS architecture is
supported).
LCFs to support the RSL and control of the BTSs.
LCFs to support the GSLs for GPRS signaling between the BSC and PCU.
Optional GPROCs include:

One redundant master GPROC3/GPROC3-2 (BSP).
At least one redundant pool GPROC (covers LCFs).
An optional dedicated CSFP. It is mandatory to deploy GPROC3/GPROC3- 2 for CSFP.
A maximum of eight GPROCs can be supported in a BSU shelf.
For redundancy, each BSC should be equipped with a redundant BSP controller and an
additional GPROC3/GPROC3-2 to provide redundancy for the signaling LCFs. Where
multiple shelves exist, each shelf should have a minimum of two GPROCs to provide
redundancy within that shelf.
Link control function

The following factors should be considered when planning the number of LCFs:
6-56
68P02900W21-T
Jul 2010
MTLs are assigned to dedicate LCFs.
LMTLs are handled by one dedicated LCF.
HSP MTL can only be supported by GPROC3-2.
The maximum number of active calls that can be processed by an LCF supporting RSLs
varies based on the GPROC type and the ssm_critical_over-load_threshold
If the ssm_critical_over-load_threshold is set to 100, a single GPROC3/GPROC3-2
LCF can process up to 1620 active calls. The default value is 80, meaning that the
1297th non-emergency call is rejected (80% x 1620 = 1296 active calls).
If the ssm_critical_overload_threshold is set to 100, a single GPROC LCF can
process up to 800 active calls. The default value is 80, meaning that the 641st
non-emergency call is rejected (80% x 800 = 640 active calls). Refer to Technical
Description: BSS Command Reference (68P02901W23) for further details.
For optimum performance, the GSL handling should be distributed among the LCFs that
terminate RSLs. (Refer to Load balancing on page 6-52).
NOTE
Combining MTL and RSL processing on a single GPROC is not

recommended.
BSC configurations with a mix of GPROCs which includes GPROC2s are not
recommended when the LCFs supporting RSLs have been planned based
on the capabilities of GPROC3s/GPROC3-2s due to the risk of overloading if
an LCF is allocated to a GPROC2.
The planning rules for LCFs using GPROCs are:
A single GPROC supports two MTLs each working at 20% link utilization. However, if the
link utilization is higher, the actual number of MTLs supported per LCF depends on the
Erlangs supported per LCF and MTL for that particular call model. A single GPROC3-2
supports one HSP MTL working at 13% link utilization.
If any LCF does not satisfy the criteria, either rebalancing of sites on the available LCF
GPROCs at the BSC is required or additional LCF GPROCs are required to be equipped at
the BSC to process the traffic load.
The link utilization of an RSL should not exceed 25%.
A single GPROC can support up to 12 GSLs. This is set by the GPROC max_gsls parameter.
Up to 38 LCFs can be supported.
68P02900W21-T
6-57
Jul 2010
Cell broadcast link
A maximum of 31 BTS sites can be controlled by a single LCF. All RSLs (LAPD links) for
the BTSs terminate on the same GPROC, so if return loops are used, then the maximum
number of BTS sites is 15 (if GPROC_slots = 32). If GPROC_slots is set to 16 then at the
most 15 RSLs may exist which would support up to 7 BTS sites, and if GPROC_slots is set
to 24 then at the most 23 RSLs may exist, supporting up to 11 BTS sites.
NOTE
The number of serial links per GPROC must be determined. The current values
are 16, 24, or 32 with 16 being the default value. One link is reserved for each
board (for GPROC test purposes) so the number of available serial links is
15, 23, or 31. However, when the links are running at high load, the GPROC
experiences some performance problems when terminating 31 links. Hence, the
use of more than 23 links per board is not recommended.
Setting GPROC_slots = 24 allows for additional LAPD links up to the recommended

maximum without the timeslot under-utilization associated with a GPROC_slots setting
of 32.
Cell broadcast link

The cell broadcast link (CBL) connects the BSC to the cell broadcast center. For typical
applications (less than ten messages per second), this link can exist on the same LCF as that
used to control BTSs. The CBL should not be controlled by an LCF MTL (a GPROC controlling
an MTL).
Optimizations Link (OPL)

The OPL is used to carry measurement reports out of the BSC to the IOS (Intelligent
Optimization Service). The link is as an HDLC stream of UI frames. The source of the data is
the RSS Handover and Power Control (HDPC) process. Operator commands indicate which
data is required. Operator commands also indicate which LCF GPROC is used for the OPL. It
is recommended to use the LCF which is least utilized. To minimize the HDLC configurations
supported, an LCF may not support both a CBL and an OPL.
OMF GPROC required

The BSC type 2 configuration offloads many of the O&M functions and control of the interface
to the OMC-R from the BSP. One of the major functions offloaded from the BSP is the central
statistics process. It is recommended to equip an OMF, especially with the introduction of the
BSP highload Protection mechanism feature in GSR 9.
GPROC3/3-2 is mandatory for OMF when large_site_support is enabled, which extends the
support carriers up to 36 per site when equipping two BBU-Es with 6 (R)CTU8m.
6-58
68P02900W21-T
Jul 2010

The BSS supports a GPROC acting as the code storage facility processor (CSFP). The CSFP
allows preloading of a new software release while the BSS is operational.
GPROC3/GPROC3-2 is required for CSFP. If a dedicated GPROC is to exist for the CSFP, an
additional GPROC is required.
When Horizon II macro, Horizonmacro or M-Cell BTSs are connected to the BSC, a dedicated
CSFP is required at the BSC and a second dedicated CSFP should be equipped for redundancy.
The BSS supports a method whereby a dedicated CSFP GPROC is not required. This method is
implemented using the configure_csfp command and works as follows:
The system can borrow certain devices and temporarily convert them into a CSFP, and when
the CSFP functionality is no longer required the device can be converted back into its previous
device. The devices the system can borrow are a redundant BSP/BTP or a pooled GPROC3-2.
This functionality allows an operator who already has either a redundant BSP/BTP or a pooled
GPROC3-2 in service to execute a command from the OMC-R to borrow the device and convert
it into a CSFP. The operator can then download the new software load or database and execute a
CSFP swap. Once the swap has been completed and verified as successful, the operator can
return the CSFP back to the previous redundant or pooled device type through a separate
command from the OMC-R.
See Technical Description: BSS Command Reference (68P02901W23) for more details on the
configure_csfp command.
GPROC redundancy
BSP redundancy
A failure of the BSP GPROC3/GPROC3-2 causes a system outage. If the BSC is equipped with a
redundant BSP GPROC3/GPROC3-2, the system restarts under the control of the redundant BSP
GPROC3s. If the BSC is not equipped with a redundant BSP and the BSP GPROC3/GPROC3-2
was to fail, the BSC would be inoperable.
The BSC Reset Management feature is enabled by default. This feature provides fast switchover
between master and redundant BSP processors in the event of a BSP failure. This reduces the
outage time from 10 minutes to 20 minutes to less than 2 minutes.
Pooled GPROCs for LCF and OMF redundancy

The BSS supports pooled GPROCs for LCF and OMF redundancy. By equipping additional
GPROCs for spares, if an LCF or the OMF GPROC were to fail, the system software automatically
activates a spare GPROC from the GPROC pool to replace the failed GPROC. It is recommended
that all the pooled GPROCs are GPROC3/GPROC3-2 when the LCFs supporting RSLs have been
planned based on the capabilities of the GPROC3/GPROC3-2.
68P02900W21-T
6-59
Jul 2010
GPROC redundancy
GPROC preemption
The GPROC preemption function 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 is preempted by the higher priority function.
The BSS uses the function type and function id to determine the order in which functions are
brought into service. The order of function type is OMF first, LCF second, and BTF third. The
function with the lower id is of higher priority than that of the function with the higher id.
Functions with lower ids are brought into service before functions with higher ids. This priority
scheme allows the operator to arrange functions in the order of importance.
The operator can configure the preemption algorithm using a database element as follows:
chg_element pool_gproc_pre_emption <value> 0
Value = 0: No preemption.
Value = 1: Function level preemption. If a function of lower priority is running on a GPROC, that
function is preempted. In the case of a preempted LCF, the LCF with the highest function id is
preempted. OMF can preempt LCF.
Value = 2: Intra function level preemption. OMF cannot preempt LCF. If a function of lower
priority is running on a GPROC, that function is 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, then the function tables are searched for a lower priority LCF to preempt.
The default value is 1.
With the HSP MTL, the preemption algorithm is altered. GPROC type is considered more
important than the LCF id. The priority order is as follows:
OMF: When OMF needs to preempt or camp on other GPROCs, it selects the GPROC
based on the following order:
If the Increased Network Capacity Feature is unrestricted, the order is GPROC3 >
GPROC2 > GPROC3-2.
If the Increased Network Capacity feature is restricted, the order is GPROC3-2
> GPROC3 > GPROC2.
HSP LCF (LCF when configured with max_mtls = 31). This can only be supported on
GPROC 3-2.
Standard LCF (LCF when configured with max_mtls = 0, 1, or 2). This can be MTL LCF or
LCF for SITEs.
BTF
When GPROC preemption occurs, service on lower priority GPROC should be terminated. To
minimize service interruption, following are suggested for GPROC planning:
6-60
Equip redundant GPROC for pooled GPROC.
Assign lowest priority to LCF which serves least traffic.
Equip HSP MTL LCF before other Standard LCF.
68P02900W21-T
Jul 2010
GPROC redundancy
From GSR10 FP2, high capacity RSL-LCF is introduced, which is decided by customer according
to the number of total carriers being attached on. The HC LCF has a higher priority to be
mapped on to GPROC3/3-2 than normal RSL-LCF, also the pre-emption algorithm is altered as
below, that the priority of high capacity RSL-LCF is lower than HSP MTL LCF but higher than
normal LCF. The normal RSL-LCF cannot pre-empt the HC RSL-LCF, but can be pre-empted by
HC RSL-LCF when the intra-function pre-emption is being enabled.
Table 6-15
Highest
priority
Lowest
Priority
Function Type Priorities
Priorities within Function

Type
OMF
N/A
HSP MTL LCF
Lowest ID to Highest ID
High capacity RSL-LCF
LCF supporting RSLs,

DS0/64K MTLs or GSLs **
Recommendations for High-Availability
To reach high availability, GPROC redundancy for BSP (1+1), MTL_LCF (N+1), RSL_LCF
(N+1) and other functions (OMF, CSFP, LMTL) (N+1) are recommended.
To achieve medium availability, GPROC redundancy for BSP(1+1), MTL_LCF, RSL_LCF,

CSFP, OMF, LMTL, (N+1) are recommended.
The worst cases and lowest availability is only one GPROC spare for BSP redundancy.
The following are the three distinct redundant alternatives for a huge BSC configuration.
Alternative 1
Offers the best availability and relies on resource

pools with over provisioning for both LCF
functionalities, that is, both the MTL-LCF and
RSL-LCF pool have their own extra GPROC boards
to provide the best resilience to the pool. These
extra boards are kept active to load-balance their
respective pool load. The CSFP, OML, and LMTL
active/standby configurations share a common
spare. Hence, four spare GPROC boards are
required in this configuration: 1 GPROC3/GPROC3-2
for BSP, 1 GPROC3-2 for MTL-LCF and 2 GPROCs
for the other functions (when the LCFs supporting
RSLs have been planned based on the capabilities of
GPROC3/GPROC3-2 it is recommended that these
pool GPROCs are GPROC3/GPROC3-2).
Alternative 2
Represents an intermediate solution were a common

spare is provided as backup of the CSFP, OML,
LMTL, MTL-LCF pool, and RSL-LCF pool. Because
of the MTL-LCF computational requirements, this
common spare board should be a GPROC3-2 board.
Alternative 3
Represents the worst-case scenario, the only

redundant component is the BSP.
68P02900W21-T
6-61
Jul 2010
GPROC planning actions
Table 6-14 lists availability predictions for three distinct redundant alternatives for a huge
BSC configuration.
Table 6-16 BSS configurations and their availability

Availability
BSC Configurations
Act/Sby BSP, 3+1 MTL-LCF, 19+1 RSL-LCF,
Act/Sby CSFP, Act/Sby OML, Act/Sby LMTL (1)
99.9978%
Act/Sby BSP, 3:1 MTL-LCF, 19:1 RSL-LCF, Act/Sby

CSFP, Act/Sby OML, Act/Sby LMTL (2)
99.9974%
Act/Sby BSP, 3+0 MTL-LCF, 19+0 RSL-LCF,

Simplex CSFP, Simplex OML, Simplex LMTL (3)
99.9921%
GPROC planning actions

Determine the number of GPROCs required.
NGPROC=B+L+C+R
Where:
NGPROC
Is:
the total number of GPROCs required.
the number of BSP GPROC3s/GPROC3-2.
the number of LCF GPROCs.
the number of CSFP GPROC3s/GPROC3-2.
the number of pool GPROCs (for redundancy).
NOTE
6-62
If dedicated GPROCs are required for either the CSFP or OMF functions then
they should be provisioned separately.
GPROC3/3-2 is mandatory for OMF when large_site_support is enabled, which

extends the support carriers up to 36 per site when equipping two BBU-Es
with 6 (R)CTU8m.
68P02900W21-T
Jul 2010
Transcoding
Transcoding
Transcoding reduces the number of cellular subscriber voice/data trunks required by a factor of
four. When (AMR or GSM) half rate is in use and 8 kbps subrate switching is available and (for
AMR only) the 7.95 kbps half rate codec mode is not included in the Half Rate Active Codec Set,
the reduction factor for the half rate calls becomes eight. In most configurations, half rate is
used only for part of the time, thus yielding a reduction factor of less than eight. If transcoding
takes place at the switch using an RXCDR, the number of links between the RXCDR and the BSC
is reduced to approximately one quarter (less when half rate is employed under the conditions
described) of the number of links between the RXCDR and the MSC. The GDP2 can process 60
channels of FR, EFR, AMR, GSM HR, and Phase 2 data services and is capable of terminating
two E1 links from the MSC. It can also function as a replacement for the GDP.
The capacity of one BSU shelf is 12 MSI slots, six of which contain a transcoder (XCDR), generic
digital processor (GDP), enhanced digital processor (EGDP), or generic digital processor 2
(GDP2); this limitation is due to power constraints.
An RXU shelf can support up to 16 GDP/XCDR/EGDP/GDP2s and typically provides a better
solution of the transcoding function for larger commercial systems. The GDP2 is used to 60
channel capacity in the BSU shelf, and when used in the new RXU3 shelf and BSSC3 cabinet
(within the RXCDR, enhanced capacity mode must be enabled to access the second E1 when
GDP2s are used). The existing RXU shelf has only one E1 per transcoder slot, therefore the
GDP2 cannot be used to its full capacity in the existing RXU shelf (the GDP2 supports only 30
channels when used in the RXU shelf). Refer to Overview of remote transcoder planning on
page 7-2 in Chapter 7 RXCDR planning steps and rules.
An EGDP is a new development of the GDP board, used to support AMR. Due to the additional
transcoding requirements of AMR, each of the 15 DSPs on the GDP board is only capable of
supporting the transcoding function for a single channel of GSM speech (AMR, FR, and EFR)
and Phase 2 data services. To offer 30 channels of enhanced transcoding using the same E1 span
line to the MSC, enhanced GDPs are equipped as pairs, each providing half of the transcoding
resources. This results in an overall reduction in capacity - equivalent to 30 channels per GDP
pair. Use of an EGDP is practical only when used in conjunction with AMR. The EGDP does not
support GSM half rate. The EGDP can also terminate one Abis E1 link, thus reducing the
number of MSIs boards required (see EGDP provisioning on page 6-65). Due to the ability of the
GDP2 to function as a GDP, it can replace one or both of the GDPs in the EGDP configuration.
This is not an optimal use of the GDP2 and is most likely to occur in emergency situations (for
example, board replacement). As a result, it is not considered in the planning procedures.
The MSC recommends a particular codec type or types to be used on a call-by-call basis. It
sends the BSC a preference-ordered list, based on such factors as MS capabilities and user
configuration. When the MSC is capable of choosing the MSC-RXCDR trunk (CIC) based upon
the preferred codec type, a mix of transcoding equipment can be used. If this capability (called
circuit pooling) is not present, then some equipment combinations can result in non-optimal
behavior.
When circuit pooling is available in an AMR enabled system, both AMR capable (EGDP/GDP2)
and non- AMR capable (XCDR/GDP) equipment can be used. If circuit pooling is not present,
GDP2s or EGDPs should be used exclusively to prevent downgrading or blocking of calls.
68P02900W21-T
6-63
Jul 2010
GDP/XCDR/EGDP/GDP2 planning considerations
When AMR is employed and both XCDR/GDPs and EGDP/GDP2s are present (and circuit pooling
is present at the MSC), there must be sufficient GDP2 and EGDP equipment available to handle
the expected AMR traffic. The proportion of AMR capable transcoding circuits versus non-AMR
capable transcoding circuits should be no less than the proportion of AMR capable MSs versus
non-AMR capable MSs. A safety factor of no less than 20% is recommended (20% allows for
some variation in the actual number and allows for a period of growth in AMR capable MS
penetration before having to add more AMR transcoding ability). Each AMR half rate call
needs one (AMR) transcoder circuit. Lack of an available AMR circuit could cause a call to be
downgraded to another codec type or possibly blocked.
When the GSM half rate is employed and a mix of XCDRs and GDP/GDP2s are present, a similar
situation exists. However, due to the early introduction into the standards of GSM half rate,
most mobile are expected to be GSM half rate capable. Since a CIC is not tied to any particular
voice channel, circuit pooling is rendered ineffective, as there is no way to predict which mobiles
require GSM half rate. It becomes necessary to update all transcoding to support GSM HR to
guarantee GSM half rate can be used when needed. Without this upgrade, calls on non-GSM HR
capable CICs remain on a full rate channel.
When GSM half rate and AMR are both in use and a combination of AMR transcoding equipment
(EGDP, GDP2) and GSM half rate transcoding equipment (GDP, GDP2) exist, circuit pooling is
most effective when choosing AMR CICs (EGDP, GDP2) for AMR capable mobiles, and the
remaining CICs for non- AMR capable mobiles. Ideally, for AMR capable mobiles the MSC would
first select a CIC attached to an EGDP, followed by one attached to a GDP2. For a non-AMR
capable mobile the MSC would first select a CIC attached to a GDP, followed by one attached
to a GDP2. The selection of the proper CIC (circuit pool) is dependent upon the capability of
the connected MSC.
GDP/XCDR/EGDP/GDP2 planning considerations

The following factors should be considered when planning the GDP/XCDR/EGDP/GDP2
complement:
An XCDR can process 30 voice channels (E1), supports GSM Full Rate speech (GSM FR),
uplink/downlink volume control and is capable of terminating one E1 link from the MSC.
A GDP can process 30 voice channels (E1), supports GSM FR, enhanced Full Rate speech
(EFR), GSM half rate speech (GSM HR), uplink/downlink volume control and is capable
of terminating one E1 link from the MSC.
An EGDP consists of a pair of GDP cards, a primary and a secondary. Each EGDP can
process 30 channels of GSM FR, EFR, AMR (FR and HR) speech and Phase 2 data services,
and terminates one E1 link from the MSC.
NOTE
GSM HR is not supported on an EGDP.
6-64
The primary GDP of an EGDP terminates the E1 interface to the MSC.
The secondary GDP of an EGDP terminates an E1 interface to the BTS. See EGDP
provisioning on page 6-65.
68P02900W21-T
Jul 2010
EGDP provisioning
The GDP2 can process 60 channels of FR, EFR, AMR (FR and HR), GSM HR, and Phase 2
data services and is capable of terminating two E1 links from the MSC. It can also function
as a replacement for the GDP.
XCDRs, GDPs, EGDPs, and GDP2s can co-exist in a shelf.
The proportion of AMR-capable circuits (GDP2/EGDP) to non AMR-capable circuits

(XCDR/GDP) should be sufficient to handle the expected AMR traffic.
The master MSI slot(s) should always be populated to enable communication with the
OMC-R. The master MSI slot contains an XCDR/GDP/EGDP (see NOTE) /GDP2, if the
OML goes through the MSC.
The A Interface must terminate on the XCDR/GDP/EGDP (either the primary or secondary)
/GDP2.
NOTE
An XCDR card is incompatible with a GPROC3/GPROC3-2 in the BSP slots. XCDRs
must be replaced with GDP/GDP2s.
EGDP provisioning
The secondary GDP of an EGDP can use the E1 connection to terminate an Abis link. This
reduces the need for MSIs and makes more efficient use of the available TDM timeslots. The
(secondary) GDP has one E1 interface (instead of two for an MSI), which must be taken into
account in site (MSI) planning.
Figure 6-2 and Figure 6-3 show the EGDP used in configurations with and without the additional
E1 termination in use respectively.
68P02900W21-T
6-65
Jul 2010
EGDP provisioning
Figure 6-2
EGDP configuration with the additional E1 termination in use

TDM Bus
Primary
GDP
15
DSPs
E1 Span
to MSC
15
DSPs
Secondary
GDP
E1 Span
from an RXCDR
to a BSC or from
a BSC to a BTS
ti-GSM-EGDP_configuration_with_the_additional_E1_termination_in_use-00128-ai-sw
6-66
68P02900W21-T
Jul 2010
Planning actions for transcoding at the BSC
Figure 6-3 EGDP configuration without the additional E1 termination in use
Static
Pass-thru
connections
(at 64kbps)
Subrate
channels
carried onto
the TDM bus
(TRAU frames
using 16Kbps)
RXCDR: Static
or dynamic call
connections
between CICs
for GDP pair
and after
channels
(TRAU frames
using 16Kbps)
BSC: Dynamic call

connections between
CICs for a GDP pair
and Abis channels
(TRAU frames
using 16Kbps)
TDM Bus
Primary
GDP
E1 Span
to MSC
15
DSPs
MSI
E1 Span
from an RXCDR
to a BSC or from
a BSC to a BTS
Secondary
GDP
15
DSPs
ti-GSM-EGDP_configuration_without_the_additional_E1_termination_in_use-00129-ai-sw

Planning transcoding at the BSC must always be performed as it determines the number of
E1 links for the A Interface. This text should be read in conjunction with the BSS planning
diagram, Figure 6-1.
68P02900W21-T
6-67
Jul 2010
Using E1 links
The minimum number of E1 links required for the A Interface is the greater of the two
calculations that follow (fractional values should be rounded up to the next integer value).
N = C2M + (T + O ) /30
N = C2M + (C64k + X + T + O ) /31
NOTE
2M MTL and 64 kbps MTL cannot be supported simultaneously.
Where:
N
Is:
the minimum number of E1 links required.
C64k
the number of 64 kbps MTL links (C7 signaling links) to the MSC.
C2M
the number of HSP MTL (if HSP MTL feature is unrestricted) to

the MSC.
the number of OML links (X.25 control links to the OMC-R) through
the MSC.
the number of trunks between the MSC and the BSC (see Figure 6-1).
the number of OPL links.
NOTE
The OPL (Optimization Link) is used to carry measurement reports out of the BSC
to the IOS (Intelligent optimization Service). In a normal operation, the OPL is
equipped up on a spare TS on the E1 link from the BSC to the RXCDR. From there it
is nailed (along with other BSCs OPL links connected to the RXCDR) to another E1
link on route to the collection.
Each XCDR/GDP/EGDP can terminate one E1 link. Each GDP2 can terminate two E1 links (when
used in a BSU or RXU3 shelf (enhanced capacity mode must be enabled within the RXCDR to
access the second E1 when GDP2s are used)).
The equipment can be mixed within the following calculation:
N = XGE + 2 G2
6-68
68P02900W21-T
Jul 2010
Where:
N
Is:
the minimum number of E1 links required.
XGE
the number of XCDR/GDP/EGDPs.
G2
the number of GDP2s.
Verify that the number of AMR circuits is sufficient to handle the expected AMR traffic. If
necessary, adjust the number of EGDP/GDP2s. The following formula is used to determine the
percentage of AMR capable circuits:
%AM Rcircuits =
GDP 2 60 + EGDP 30
100
GDP 2 60 + EGDP 30 + XCDR 30 + GDP 30
NOTE
Count primary and secondary EGDPs as one EGDP in the equation.
68P02900W21-T
6-69
Jul 2010
Multiple serial interface (MSI)
Introduction
A multiple serial interface provides the interface for the links between a BSSC cabinet and other
network entities in the BSS, BSC to BTS, and BSC to RXCDR. An MSI can interface only E1 links.
The following factors should be considered when planning the transcoder complement:
Each MSI can interface two E1 links.
NOTE
An MSI card is compliant with G703 (1998).
Each E1 link provides 31 usable 64 kbps channels.
Redundancy for the MSI depends on the provisioning of redundant E1 links connected
to the site.
The master MSI slots should always be populated to enable communication with OMC-R.
If the OML links go directly to the MSC, the master slot should be filled with an XCDR/GDP/EGDP
(primary or secondary) /GDP2, else the slot should be filled with an MSI, which terminates the
E1 link carrying the OML link to the OMC-R. These E1 links do not require to go directly to the
OMC-R, they can go to another network element for concentration. With the introduction of the
96 MSI feature, the MSI with OML can be configured with priority in the database to make sure
that the MSI is available in either single rate or enhanced capacity mode.
When the HSP MTL feature is unrestricted, the E1 links used to carry HSP MTL should be taken
into account. There are two connected modes. In the first connection mode, the E1 links go
to the MSC through the RXCDR. The impact of this mode of connection on the RXCDR can be
found in Chapter 7 RXCDR planning steps and rules. In the second connection mode, the E1
links go to the MSC directly. Both the modes impact E1 planning in BSC.
6-70
68P02900W21-T
Jul 2010
MSI planning actions

If local transcoding is used then the NBSC-RXCDR element in the following equations can be
ignored, otherwise refer to Chapter 7 RXCDR planning steps and rules for the determination of
the NBSCRXCDR element.
With E1 links
Determine the number of MSIs required.
Without LCS:
NM SI =
NBSCBT S + NBSCRXCDR + NGDST RAU + NGSLE1 )

2
With LCS for BSS-based LCS architecture:
NM SI =
NBSCBT S + NBSCRXCDR + NBSCSM LC + NGDST RAU + NGSLE1 )

2
NOTE
The upper limit of the E1 backhaul per BSC is 96*2=192, as up to 96 MSI boards can
be hosted by BSC. When the planned E1 cables per BSC exceed the limit, use the
following methods to reduce the required MSI boards:
68P02900W21-T
1.
Apply BTS daisy chain to reduce the E1 cables between BTS and BSC.
2.
Apply half rate Ater channels to reduce the E1 cables between BSC and RXCDR.
3.
Replace E1 GDS/GSL with Ethernet GDS/GSL to reduce the E1 cables between

BSC and PCU.
6-71
Jul 2010
Packet Subrate Interface (PSI2)
Packet Subrate Interface (PSI2)
Introduction
The PSI2 card is used to connect BSC to PCU with Ethernet connectivity. The physical interface
from the card is a 1000 BASE-T over four pairs of copper wire. This same connection can be
operated in 100 BASE-TX mode of operation as well. The standard backplane connections can
be used, with a PBIB or PT43 board replacing the BIB or T43 board, respectively, at the top of
the cabinet. The new interconnect board (PBIB or PT43) at the top of the BSC cabinet allows a
single RJ45 Ethernet connection instead of two span lines for one of the supported MSI positions.
Planning consideration
The following factors should be considered when planning the equipage of PSI2 cards:
Each PSI2 connects PXP in PCU with Ethernet link. Every PSI2/PXP pair provides an
Ethernet link, which can carry both GSL and GSD TRAU simultaneously.
Each BSC cage can be typically equipped with two PSI2 cards when KSW and KSWXs are
used and three PSI2 cards when DSW2 and DSWX are used. They occupy MSI slots 6, 7,
12, and 13. There are up to 12 PSI2 cards in a BSC site.
A PSI2 can support 64 to 320 usable 64 kbps TDM channels. Refer to TDM_Ts_Blocks
planning in KSW/DSW2 planning actions on page 6-75.
Redundancy for PSI2 depends on the provisioning of redundant Ethernet links connected
with PXP in PCU.
PSI2 planning actions

The number of PSI2 cards required is dependent on planning of the PXP boards in PCU (refer to
Chapter 8 BSS planning for GPRS/EGPRS).
6-72
68P02900W21-T
Jul 2010
Kiloport switch (KSW) and double kiloport switch (DSW2)
Kiloport switch (KSW) and double kiloport switch

(DSW2)
Introduction
The kiloport switch (KSW) card provides digital switching for the TDM highway of the BSC.
The double kiloport switch (DSW2) is an enhanced version of the KSW, which supports twice the
number of ports (enhanced capacity mode), as well as extended subrate switch capability of
8 kbps (extended subrate switching capability). Use of 8 kbps subrate switching can reduce
backhaul costs when used in conjunction with the AMR or GSM half rate feature.
The following factors should be considered when planning the KSW/DSW2 complement:
A minimum of one KSW/DSW2 is required for each BSC site.
The KSW, or DSW2 not in enhanced capacity mode, has a capacity of 1024 x 64 kbps
ports or 4096 x 16 kbps ports, which can be expanded by adding up to three additional
KSW/DSW2s, giving a total switching capacity of 4096 x 64 kbps ports or 16384 x 16
kbps ports.
When operating in enhanced capacity mode, the DSW2 has a capacity of 2048 x 64 kbps
DSW2s, giving a total switching capacity of 8192 x 64 kbps ports or 32768 x 16 kbps ports.
When operating in extended subrate switching mode (but not enhanced capacity mode),
the DSW2 can further switch 8192 x 8 kbps ports which can be expanded by adding up to
three additional DSW2s, giving a total switching capacity of 32768 x 8 kbits/s ports.
When operating in extended subrate switching mode and enhanced capacity mode, the
DSW2 can further switch 16384 x 8 kbps ports which can be expanded by adding up to
Eight (64 kbps) timeslots per KSW/DSW2 are reserved by the system for test purposes and
are not available for use.
A mix of KSWs and DSW2s needs that the DSW2s are not operated in the enhanced
capacity mode.
For redundancy, duplicate all KSWs/DSW2s. In mixed configurations (KSWs and DSW2s),
KSWs can be redundant to DSW2s and vice-versa.
68P02900W21-T
6-73
Jul 2010
Verify that each KSW or DSW2 that is not in enhanced capacity mode uses no more than
1016 ports, or that each DSW2 in enhanced capacity mode uses no more than 2040 ports
(8 ports are used internally). The devices in a BSC that need TDM timeslots are:
GPROC1 = 16 timeslots.
GPROC2 or GPROC3, GPROC3-2 = 32 or 16 timeslots.
NOTE
With gproc_slots = 24, a value of 32 should be used for calculating TDM
timeslot usage
GDP or XCDR (or GDP2 acting as a GDP replacement) = 16 timeslots.

EGDP = 96 timeslots.
GDP2 = 24 timeslots.
MSI = 64 timeslots.
PSI2 = tdm_ts_blocks timeslots *32 (64 ~ 320 timeslots).
NOTE
The tdm_ts_blocks is a database parameter used to set the number of
TDM timeslot blocks for each PSI2. One block contains 32 TDM timeslots.
When the PXP (the partner of PSI2) works in prp_fanout_mode 1 (refer
to PXP planning considerations on page 8-28 in Chapter 8 BSS planning
for GPRS/EGPRS), 10 blocks are recommended. When the PXP works in
prp_fanout_mode2, 5 blocks are recommended. In situations where the
total number of TDM timeslots is limited by a cage or KSW/DSW constraints
(that is there are insufficient TDM resources to set the tdm_ts_blocks
to the recommended value), it is recommended that the tdm_ts_blocks
number for PSI2 is set to the highest value possible within the constraints.
However, in such situations TDM resource limitations can reduce the
number of supportable PDCHs. The general rule for tdm_ts_blocks
planning is to provide each PDCH with one TDM timeslot regardless of
what type it is, 16 k, 32 k, or 64 k. In addition, one TDM timeslot is
provided for each GSL TS on the PSI2/PXP connectivity.
There is one additional consideration with regard to timeslot usage, which is related to the
timeslot allocation policy employed. Timeslots are grouped in 32 blocks of 32 timeslots
each. Generally, groups of 16 (the first 16 or last 16) can be allocated within a block.
NOTE
The GDP2 is a special case, as it requires 24 timeslots, a group of 16 and another
8 out of an additional block. The remaining 8 timeslots (within the block of 16)
can only be used by another GDP2. Hence, if there is an odd number of GDP2s
then 8 timeslots are unusable.
The number of TDM timeslots is given by:

N = (G n) + (RGDP XCDR 16) + (REGDP 96) + (RGDP 2 24) + (M 64) + (RP SI2 t)
6-74
68P02900W21-T
Jul 2010
KSW/DSW2 planning actions
Where:
Is:
the number of timeslots required.
the number of GPROCs.
16 or 32 (depending on the value of the gproc_slots database

parameter)
RGDPXCDR
the number of GDP/XCDRs.
REGDP
the number of EGDPs.
RGDP2
the number of MSI.
RPSI2
the number of PSI2s
64 ~ 320 (depending on the value of the tdm_ts_blocks

database parameter, t = tdm_ts_blocks * 32).
Any BSC site, which contains a DRIM, has 352 timeslots allocated to DRIMs, irrespective of the
number of DRIMs equipped.

Calculate the minimum number of KSWs/DSW2s required per BSC:
Use this formula when enhanced capacity mode is not enabled:
N = ((G n) + (RGDP XCDR 16) + (REGDP 96) + (RGDP 2 24) + (M 64) + (RP SI2 t)) /1016
Use this formula when enhanced capacity mode is enabled:
N = ((G n) + (RGDP XCDR 16) + (REGDP 96) + (RGDP 2 24) + (M 64) + (RP SI2 t)) /2040
NOTE
In the above two formulae, if the number of required GDP2s is odd, additional 8
timeslots need to be added.
68P02900W21-T
6-75
Jul 2010
Where:
Is:
the number of KSWs/DSW2s required.
16 or 32 (depending on the value of the gproc_slots database parameter).
RGDPXCDR
the number of GDP/XCDRs.
REGDP
the number of EGDPs.
RGDP2
M
RPSI2
t
the number of MSIs.

64 ~ 320 (depending on the value of the tdm_ts_blocks database
parameter, t = tdm_ts_blocks * 32)
Each KSW/DSW2 has to serve the boards in its shelf and the boards of any extension shelf
connected to its shelf by its TDM highway of 1016 available timeslots (or 2040 when operating
in enhanced capacity mode).
In case of multiple expansion shelves, the TDM highways of each shelf do not merge into a
common unique TDM highway across all shelves, that is, a KSW/DSW2 in one shelf cannot serve
boards in other expansion shelves.
For example, in the case of a BSC consisting of two shelves each having 32 unused timeslots per
KSW/DSW2 free, an additional MSI board CANNOT be added even if an MSI slot is free at each
shelf, (but one GPROC per shelf can be added if one GPROC slot per shelf is free).
6-76
68P02900W21-T
Jul 2010
BSU shelves
BSU shelves
Introduction
The number of BSU shelves is normally a function of the number of GPROCs, MSIs, and
XCDR/GDP/EGDP/GDP2s required.
The following factors should be considered when planning the number of BSU shelves:
Each BSU shelf supports up to eight GPROCs. If the number of these exceeds the number
of slots available, an additional BSU shelf is required.
Each expansion shelf is allocated to a single KSW/DSW2 and extension shelves are
differentiated by the presence of the KSW/DSW2. Extension shelves are those, which do
not contain a primary KSW/DSW2. Shelves containing a KSW/DSW2 are called expansion
shelves.
An extension shelf extends the TDM highway. It is limited to the same number of
(aggregate) timeslots as the shelf containing the KSW/DSW2.
An expansion shelf adds an additional TDM highway. It increases the number of timeslots
to that of the additional KSW/DSW2.
The following capacities depend on timeslot usage. Refer to Kiloport switch (KSW) and
double kiloport switch (DSW2) on page 6-73 for information on how to determine timeslot
usage.
A BSU shelf can support up to 12 MSI boards.
A BSU shelf can support up to six XCDR/GDP/EGDP/GDP2s (reducing the number
of MSI boards appropriately).
NOTE
For EGDPs, both the primary and the secondary must be counted.
An XCDR card is incompatible with a GPROC3/GPROC3-2 in the BSP

slots. XCDRs must be replaced with GDP/GDP2s.
BSU shelf planning actions

Determine the number of BSU shelves required.
68P02900W21-T
6-77
Jul 2010
The number of BSU shelves required is the highest value result of the following three
calculations (fractional values should be rounded up to the next integer value):
BS =
BS =
G
8
M +R
12
BS =
R
6
Or BS=(M+R+P)/12 when PSI2 cards used in BSC cage.

Where:
Is:
Bs
the minimum number of BSU shelves required.
the number of MSIs.
the number of XCDR/GDP/EGDP/GDP2s (see NOTE).
the number of PSI2 cards.
For EGDPs, both the primary and the secondary EGDPs must be counted.
The number of timeslots equipped to each shelf must be verified. This verification procedure
is like Planning considerations (the KSW/DSW2 timeslot validation prevents a shelf from
exceeding the timeslot limit) and is repeated here for completeness.
(G n) + (RGDP XCDR 16) + (REGDP 96) + (RGDP 2 24) + (M 64) + (RP SI2 t) 1016
Where:
G
the number of GPROCs in the shelf.
16, 24, or 32 (depending on the value of the gproc_slots database

parameter).
RGDPXCDR
the number of GDP/XCDRs in the shelf.
REGDP
the number of EGDPs in the shelf.
RGDP2
the number of GDP2s in the shelf.
M
RPSI2
t
6-78
Is:
the number of MSIs in the shelf.

the number of PSI2s
64~320 (depending on the value of the tdm_ts_blocks database
parameter, t = tdm_ts_blocks *32).
68P02900W21-T
Jul 2010
When enhanced capacity mode is not enabled (non-extension shelf):
When enhanced capacity mode is enabled (extension shelf):
If the result of the equation exceeds the value quoted, the configuration of MSIs, GPROCs, and
GDPs and PSI2s can be adjusted, or an additional shelf or shelves is required.
NOTE
68P02900W21-T
The number of shelves should be larger if an attempt to reduce the number of

KSWs/DSW2s is made. The maximum number of shelves at a site = 8.
The maximum number of cabinets at a site = 8.
Horizon and M-Cell sites need only a cabinet to be equipped and not a shelf.
Without {22169}: Although the BSC can support a maximum of 56 MSIs and
each of up to 4 BSU shelves can support 12 MSIs, adding one extension shelf
does not provide additional capacity for the extra 8 MSIs.
With {22169}: The BSC can support 96 MSIs with 12 MSIs in each of the
8 cages.
6-79
Jul 2010
Kiloport switch extender (KSWX) and double kiloport

switch extender (DSWX)
Introduction
The KSWX extends the TDM highway of a BSU to other BSUs and supplies clock signals to all
shelves in multi-shelf configurations. The KSWX is required whenever a network element
expands beyond a single shelf. The DSWX performs the same function as the KSWX when used
in the BSU. It is necessary when enhanced capacity mode (2048 timeslots capacity) is used.
DSWXs are not required to pair with DSW2s when extended subrate switching mode is used
(KSWXs can be used).
The following factors should be considered when planning the KSWX/DSWX complement:
KSWXs/DSWXs are not required in a single shelf configuration (that is, when expansion or
extension is not required).
For redundancy, duplicate all KSWX/DSWX boards (needs redundant KSW/DSW2). In mixed
configurations (KSWXs and DSWXs), KSWXs can be redundant to DSWXs and vice-versa.
KSWXs/DSWXs are used in three modes:

KSWX/DSWXE (Expansion) is required to interconnect the KSWs/DSW2s for sites
with multiple KSWs/DSW2s.
KSWX/DSWXR (Remote) is required in shelves with KSWs/DSW2s to drive the TDM
highway in shelves that do not have KSWs/DSW2s.
KSWX/DSWXL (Local) are used in shelves that have KSWs/DSW2s to drive the clock
bus in that shelf and in shelves that do not have KSWs/DSW2s to drive both the local
TDM highway and the clock bus in that shelf.
Five of the redundant KSWX/DSWX slots are also CLKX slots.
The maximum number of KSWX/DSWX slots per shelf is 18, nine per KSW/DSW2.
KSWXs and DSWXs can both be used, however they should always be used with like pairs,
for example DSWXs with DSWXs and KSWXs with KSWXs.
Operation in enhanced capacity mode needs the use of all DSWXs (and DSW2s).
NOTE
The fiber optic cables, which are used to extend/expand the TDM highway from
one BSU to another BSU, must be of the same length to limit the risk of TDM
highway extension/expansion errors.
6-80
68P02900W21-T
Jul 2010
KSWX/DSWX planning actions

The number of KSWXs/DSWXs required is the sum of the KSWX/DSWXE, KSWX/DSWXL and
KSWX/DSWXR.
NKX = NKXE + NKXR + NKXL
NKXE = K (K 1)
NKXR = SE
When SE = 0, NKXL = 0
When SE > 0, NKXL = K + SE
Where:
Is:
NKX
the number of KSWXs/DSWXs required.
NKXE
the number of KSWX/DSWXE.
NKXR
the number of KSWX/DSWXR.
the number of non-redundant KSWs/DSW2s.
SE
the number of extension shelves.
For example:
Table 6-17 KSWX/DSWX (non-redundant)

KSW/DSW2 (non redundant)
Extension shelves
16
11
18
13
20
10
15
22
12
17
24
Table 6-18 KSWX/DSWX (redundant)

KSW/DSW2 (redundant)
68P02900W21-T
Extension shelves
18
32
12
22
36
10
16
26
40
14
20
30
44
18
24
34
48
6-81
Jul 2010
Generic clock (GCLK)
Introduction
The generic clock (GCLK) generates all the timing reference signals required by a BSU.
The following factors should be considered when planning the GCLK complement:
One GCLK is required at each BSC.
The maximum number of GCLK slots per shelf is two.
For redundancy, add a second GCLK at each BSC in the same shelf as the first GCLK.
GCLK planning actions

Determine the number of GCLKs required.
GCLKs = 1 + 1 redundant
6-82
68P02900W21-T
Jul 2010
Clock extender (CLKX)
Introduction
A clock extender (CLKX) board provides expansion of GCLK timing to more than one BSU.
The following factors should be considered when planning the CLKX complement:
One CLKX is required in the first BSU shelf, which contains the GCLK when expanding
beyond the shelf occurs.
Each CLKX can supply the GCLK signals to six shelves.
There are three CLKX slots for each GCLK, allowing each GCLK to support up to 18 shelves
(LAN extension allows only 14 shelves in a single network element).
(LAN extension allows only 14 shelves in a single network element).
The maximum number of CLKX slots per shelf is six. (The CLKX uses six of the redundant
KSWX slots.)
With a CLKX, a KSWX/DSWXL is required to distribute the clocks in the master and each of
the expansion/extension shelves.
For redundancy, duplicate each CLKX (needs a redundant GCLK).
Fiber optic cables that extending clock reference signals from the parent shelf to all other
shelves and itself at a site must be of the same length to maintain site synchronization
integrity.
68P02900W21-T
6-83
Jul 2010
CLKX planning actions

Determine the number of CLKXs required.
NCLKX = ROU N DU P
E
6
Where:
6-84
(1 + RF )
Is:
NCLKX
the number of CLKXs required.
ROUND UP
the number of expansion/extension shelves.
RF
redundancy factor (1 if redundancy is required (recommended), 0 for no

redundancy).
68P02900W21-T
Jul 2010
Local area network extender (LANX)
Local area network extender (LANX)
Introduction
The LANX provides a LAN interconnection for communications between all GPROCs at a site.
The following factors should be considered when planning the LANX complement:
One LANX is supplied in each shelf.
For full redundancy add one LANX for each shelf.
The LANX can support a maximum network size of 14 shelves.
LANX planning actions

Determine the number of LANXs required.
NLAN X = NBSU (1 + RF )
BSU 14
Where:
NLANX
the number of LANXs required.
NBSU
the number of BSU shelves.
RF
68P02900W21-T
Is:
redundancy factor (1 if redundancy is required (recommended), 0

for no redundancy).
6-85
Jul 2010
Parallel interface extender (PIX)
Introduction
The PIX board provides eight inputs and four outputs for site alarms.
The following factors should be considered when planning the PIX complement:
The maximum number of PIX board slots per shelf is two.
The maximum number of PIX board slots per site is eight.
PIX planning actions

Select the number of PIXs required.
P IX 2 number of BSU s
or
P IX 8
6-86
68P02900W21-T
Jul 2010
Line interface boards (BIB/PBIB, T43/PT43)
Line interface boards (BIB/PBIB, T43/PT43)
Introduction
The line interfaces, balanced-line interface board (BIB) and T43 board (T43), provide impedance
matching for E1 links. The PBIB and PT43 provide an Ethernet link in addition to impedance
matching for E1links.
Use a BIB or PBIB to match a balanced 120-ohm (E1 2.048 Mbps) or balanced 110-ohm 3
V (peak pulse) line.
Use a T43 Board (T43) or PT43 board to match a single ended unbalanced 75 ohm (E1
2.048 Mbps) 2.37 V (peak pulse) line.
The PBIB and PT43 are used when PSI2s exist in BSC cage. They are at the top of the BSC
cabinet and replace two span lines with a single RJ45 connection for Ethernet.
Each BIB/T43 can interface six E1 links to specific slots on one shelf.
Each PBIB/PT43 can interface four E1 links and one Ethernet link to specific slots on
one shelf.
Up to four (P)BIBs or (P)T43s per shelf can be mounted on a BSSC2 cabinet.

A maximum of 24 E1 links can be connected to a BSU shelf.
A BSSC2 cabinet with two BSU shelves can interface a maximum of 48 E1 links.
A maximum of four Ethernet links can be connected to a BSU shelf.
A maximum of eight Ethernet links can be connected to a BSSC cabinet.
The number of E1links is reduced by 2 times the number of Ethernet links provisioned.
NOTE
A BSSC3 cabinet can have up to seven (P)BIBs or (P)T43s per shelf mounted, but
in the BSU configuration this additional connectivity is not needed.
68P02900W21-T
6-87
Jul 2010
(P)BIB/(P)T43 planning actions
(P)BIB/(P)T43 planning actions

6-88
Determine the number and type of link (E1) to be driven.
Determine the number of Ethernet links to be driven.
Determine the number of (P)BIBs or (P)T43s required.
Determine the split between BIB/T43 and PBIB/PT43 boards required.
Minimum number of MSIs = (Number of E1 /2).
Number of PBIB/PT43 = number of PSI2s.
Minimum number of BIB/T43= (number of MSIs - 2* number of PSI2s) /3.
68P02900W21-T
Jul 2010
Digital shelf power supply
Introduction
A BSSC2 or BSSC3 cabinet can be supplied to operate from a +27 V dc or -48 V/-60 V dc
power source.
NOTE
In this manual, BSSC is a generic term that means both BSSC2 and/or BSSC3.
The following factors should be considered when planning the PSU complement:
Two DPSMs are required for each shelf in the BSSC.
Two IPSMs are required for each shelf in the BSSC2 (-48 V/-60 V dc).
Two IPSM2s are required for each shelf in the BSSC3 (-48 V/-60 V dc).
Two EPSMs are required for each shelf in the BSSC (+27 V dc).
For redundancy, add one DPSM, IPSM, or EPSM for each shelf.
Power supply planning actions

Determine the number of PSUs required.
PSUs = 2 * Number of BSUs + RF * Number of BSUs
Where
RF is the redundancy factor (1 if redundancy is required (recommended), 0 for no redundancy).
68P02900W21-T
6-89
Jul 2010
Non Volatile Memory (NVM) board
Introduction
The optional non volatile memory board provides the BSC with an improved recovery facility
following a total power loss. With the NVM board installed, data is retrieved from the NVM
board rather than from the OMC-R during recovery from a total power loss.
The following factors should be considered when planning the NVM complement:
Only one NVM board can be installed at the BSC.
The NVM board uses slot 26 in the BSU shelf 0 (master) of the BSC, which is an unused slot.
The appropriate software required to support the NVM board must be loaded at the
OMC-R and downloaded to the BSC.
NVM planning actions

The NVM board is optional.
6-90
68P02900W21-T
Jul 2010
Verifying the number of BSU shelves and BSSC cabinets
Verifying the number of BSU shelves and BSSC cabinets
Verification
After planning is complete, verify that:
The number of shelves is greater than one-eighth of the number of GPROC modules.
The number of cabinets is less than or equal to 300.
Each non-redundant KSW/DSW2 has its own shelf.
Each extension shelf supports extension of a single KSW/DSW2.
The number of KSWX/DSWXs, LANXs, CLKXs, and GPROCs is correct.
The number of MSI, PSI2s, and XCDR/GDP/EGDP/GDP2s 12 * number of shelves.

The upper limit of the E1 backhaul per BSC is 96*2=192, as up to 96 MSI boards can be
hosted by BSC. When the planned E1 cables per BSC exceed the limit, use the following
methods to reduce the required MSI boards:
a.
Apply BTS daisy chain to reduce the E1 cables between BTS and BSC.
b.
Apply half rate Ater channels to reduce the E1 cables between BSC and RXCDR.
c.
Replace E1 GDS/GSL with Ethernet GDS/GSL to reduce the E1 cables between BSC
and PCU.
The number of XCDR/GDP/EGDP/GDP2s 6 * number of shelves.
The number of PSI2s 4 per shelf and 12 per site.
NOTE
For the two calculations, the EGDP consists of a primary and a secondary board.
The number of BTS sites 100
The number of BTS cells 250
RSLs 250
Carriers 384
68P02900W21-T
6-91
Jul 2010
Verification
LCFs 38
Erlangs 2250
NOTE
6-92
With the Enhanced BSC feature enabled, up to 140 BTS sites, 512 carriers
and 3000 Erlangs are supported.
With the Huge BSC feature enabled, up to 140 BTS sites are supported.
If all the GPROCs in the BSC are GPROC3/3-2, up to 1000 carriers and
5900 Erlangs are supported, otherwise the upper limits are 750 carriers
and 4500 Erlangs.
If necessary, extra BSU shelves may need to be added. Each BSSC cabinet
supports two BSU shelves.
68P02900W21-T
Jul 2010
Chapter
7
RXCDR planning steps and rules
This chapter provides an overview of the manual. It also provides information on various
elements of BSS, BSS planning methodology, and BSS system architecture, components, and
features.
This chapter describes the planning steps and rules for the RXCDR in the following sections:
Overview of remote transcoder planning on page 7-2
RXCDR system capacity on page 7-4
RXCDR to BSC connectivity on page 7-5
RXCDR to BSC links on page 7-6
RXCDR to MSC links on page 7-8
Generic processor (GPROC) on page 7-9
Transcoding on page 7-10
Multiple serial interface (MSI) on page 7-17
Kiloport switch (KSW) and double kiloport switch (DSW2) on page 7-19
RXU shelves on page 7-22
Kiloport switch extender (KSWX) and double kiloport switch extender (DSWX) on page 7-25
Generic clock (GCLK) on page 7-28
Clock extender (CLKX) on page 7-29
LAN extender (LANX) on page 7-31
Parallel interface extender (PIX) on page 7-32
Line interfaces (BIB, T43) on page 7-33
Digital shelf power supply on page 7-35
Non Volatile Memory (NVM) board on page 7-36
Verify the number of RXU shelves and BSSC cabinets on page 7-37
68P02900W21-T
Jul 2010
7-1
Overview of remote transcoder planning
Overview of remote transcoder planning
Introduction
The following information is required to plan the equipage of an RXCDR:
BSC traffic requirements.
Number of trunks (including redundancy) from the MSC.
Each RXCDR can support multiple BSCs.
The sum of the MSIs and the XCDR/GDP/EGDP/GDP2s for each BSC define the number
of slots required at the RXCDR.
NOTE
Each EGDP comprises two GDP cards.
The use of E1 links.
The use of balanced or unbalanced E1.

Follow Procedure 7-1 to plan an RXCDR.
Procedure 7-1
Planning an RXCDR
Plan the number of links between the XCDR and BSC sites by referring to the
section Overview of remote transcoder planning on page 7-2.
Plan the number of E1 links between the RXCDR and MSC sites by referring
to the section RXCDR to MSC links on page 7-8.
Plan the number of GPROCs required by referring to the section Generic

processor (GPROC) on page 7-9.
Plan the number of XCDR/GDP/EGDP/GDP2s required by referring to the

section Transcoding on page 7-10.
Plan the number of MSIs required by referring to the section Multiple serial
interface (MSI) on page 7-17.
Continued
7-2
68P02900W21-T
Jul 2010
Procedure 7-1
68P02900W21-T
Planning an RXCDR (Continued)
Plan the number of KSWs/DSW2s and timeslots required by referring to the

section Kiloport switch (KSW) and double kiloport switch (DSW2) on page
7-19.
Plan the number of RXU shelves by referring to the section RXU shelves
on page 7-22.
Plan the number of KSWXs/DSWXs required by referring to the section

on page 7-25.
Plan the number of GCLKs required by referring to the section Generic clock
(GCLK) on page 7-28.
10
Plan the number of CLKXs required by referring to the section Clock extender
(CLKX) on page 7-29.
11
Plan the number of LANXs required by referring to the section .
12
Plan the number of PIXs required by referring to the section Parallel interface
extender (PIX) Parallel interface extender (PIX) on page 7-32.
13
Plan the number of BIB or T43s required by referring to the section Line
interfaces (BIB, T43) on page 7-33.
14
Plan the power requirements by referring to the section Digital shelf power
supply on page 7-35.
15
Decide whether an NVM board is required by referring to the section Non

Volatile Memory (NVM) board on page 7-36.
16
Verify the planning process by referring to the section Verify the number of
RXU shelves and BSSC cabinets on page 7-37.
7-3
Jul 2010
RXCDR system capacity
RXCDR system capacity

Table 7-1 provides a summary of RXCDR maximum capacities.
Table 7-1
RXCDR maximum capacities
Item
GSR8
GSR9
GSR10
RXCDR per BSC
10
10
10
XBLs
20
20
20
2400a
2400ab
2400ab
GPROCs per shelf

CIC
OMLs
a Increased to 4800 CICs when AMR (and/or GSM half rate) are both enabled.
b Increased to 6200 CICs with the huge BSC capacity feature enabled and 20% HR is assumed.
7-4
68P02900W21-T
Jul 2010
RXCDR to BSC connectivity
RXCDR to BSC connectivity
Introduction
A single BSC can have multiple RXCDRs connected to it and vice-versa. This is useful for the
following reasons:
In some configurations, the RXCDR call (CIC) capacity is greater than that of a BSC.
Failure of an RXCDR, or the communication path between BSC and RXCDR results in loss
of capacity but not a complete failure of the serving BSC.
Capacity
Each BSC can connect to up to ten RXCDRs and vice-versa. The level of connectivity is
constrained by the number of XBLs (limit of 20 at each BSC and RXCDR) that can be supported.
Refer to Determining the number of XBLs required on page 6-47 for further details.
The level of connectivity is determined by the operator. Excess RXCDR capacity should not be
wasted. Larger BSCs should not be connected to only one RXCDR. Each BSC should connect
to four RXCDRs. System size, capacity, and cost are the major influences on the selected
configuration.
With the introduction of advanced transcoding capabilities (that is, AMR), care should be
taken when distributing the functions across multiple RXCDRs. For optimum redundancy,
each RXCDR should have an appropriate mix of transcoder capability. For example, in a four
BSC, four RXCDR configuration where all are interconnected and there are a limited number
of transcoder cards capable of AMR (for example, GDP2s), optimally the cards are distributed
equally among the RXCDRs.
68P02900W21-T
7-5
Jul 2010
RXCDR to BSC links
RXCDR to BSC links
Introduction
Refer to Figure 6-1 for the RXCDR to BSC links. The number of E1 links between the RXCDR
and the BSCs is the number required to support the A Interface from the RXCDR to the BSC.
The number of E1 links between the RXCDR and the BSC is reduced to approximately one
quarter of the number of links between the RXCDR and the MSC when 16 kbps backhaul is
used. When (AMR or GSM) half rate is in use, 8 kbps subrate switching is available and (for
AMR only) the 7.95 kbps half rate codec mode is not included in the Half Rate Active Codec
Set, the reduction factor for the half rate calls becomes eight.
NOTE
In most configurations, half rate is likely to be used only a part of the time, thus
yielding a reduction factor of less than eight.
8 kbps backhaul can be used when (AMR or GSM) half rate is in use, the 7.95 kbps half rate
codec mode is not included in the Half Rate Active Codec Set, and 8 kbps subrate switching
is in use.
If a percentage of the active calls is assumed to be half rate, the efficiency can be increased by
reducing the number of terrestrial resources between the BSC and RXCDR. This is possible only
if the BSC can dynamically allocate a timeslot to a CIC. This dynamic allocation is performed
across a trunked interface between the BSC and a remote transcoder (RXCDR). This interface is
called the Ater interface. The dynamic allocation is referred to as Enhanced Auto Connect mode.
Whenever the number of CICs exceeds the number of 16 kbps trunks between the RXCDR
and BSC, there is a possibility that a call assignment may fail because of resource shortage.
Therefore, ensure the accuracy of half rate usage estimations. The number depends on a
combination of factors, which includes (AMR or GSM) capable mobile penetration, whether
forced half rate usage is enabled and/or tied in with congestion, and MSC preferences. It is
recommended that a safety factor of at least 20% is factored into any half rate usage estimate
(20% allows for some variation in the actual number).
When HSP MTL feature is unrestricted, the E1 links used to carry HSP MTL require to be
accounted. There are two connected modes. One is the E1 links go to MSC by RXCDR. Another
is the E1 links go to MSC directly. For the first connected mode, MSIs are required to terminate
HSP MTL at RXCDR (A HSP MTL from MSC is terminated at one port of an MSI and nailed to
BSC from another MSI port) whereas for the second connected mode (E1 links go from BSC to
MSC directly), there is no impact on RXCDR planning.
NOTE
4 x 64 kbps circuits/RTF for a (AMR or GSM) HR RTF and 8 kbps switching is not
provisioned, or, (for AMR only) the 7.95 kbps half rate codec mode is included in
the Half Rate Active Codec Set.
7-6
68P02900W21-T
Jul 2010
E1 interconnect planning actions

Determine the number of E1 links required. If HSP MTLs are deployed and they pass through
RXCDR:
NBSCRXCDR = C2M + {C64k + X + B64 + O + [T (1 PHR ) + B16 ] /4 + (T PHR ) /8} /31

Where:
NBSC-RXCDR
Is:
minimum number of E1 links required.
C64k
number of 64 kbps C7 signaling links to the MSC.
C2M
number of HSP MTLs to the BSC.
X
B64
number of OML links (X.25 control links to the OMC-R) through the
RXCDR.
number of 64 kbps XBL links.
number of trunks between the MSC and the BSC (refer to Figure 6-1).
PHR
percentage in decimal (for example, 0.35) of expected half rate usage

(meeting the criteria stated previously).
B16
number of 16 kbps XBL links.
number of OPL links.
NOTE
PHR is zero if Enhanced Auto Connect mode is not in use.
The OPL (Optimization Link) is used to carry measurement reports out of the BSC
to IOS (Intelligent optimization Service). In normal operation, the OPL is equipped
up on a spare TS on the E1 link from BSC to the RXCDR. From there it would be
nailed (along with other BSCs OPL links connected to the RXCDR) to another E1
link on route to the collection.
Each E1 link carries up to 120 (240 at half rate) trunks with a signaling link or 124 (248 at half
rate) trunks without a signaling link.
NOTE
The half rate numbers are only possible with all calls using half rate. HSP MTL and
64 kbps MTL cannot be supported simultaneously.
Redundant E1 links carrying extra trunks can be added. If HSP MTLs go to MSC directly (not
through RXCDR), C2M is 0 in the equation.
68P02900W21-T
7-7
Jul 2010
RXCDR to MSC links
RXCDR to MSC links
Introduction
The number of E1 links between the RXCDR and the MSC is the number required to support
the A Interface from the RXCDR to the MSC.

Determine the number of E1 links required.
The minimum number of E1 links required for the A Interface is the greater of the two following
calculations (fractional values should be rounded up to the next integer value):
NRXCDRM SC = C2M + T /30
NRXCDRM SC = C2M + (C64k + X + T ) /31

Where:
NRXCDR-MSC
Is:
minimum number of E1 links required.
C64k
number of 64 kbps C7 signaling links to the MSC.
C2M
number of HSP MTL links.
number of OML links (X.25 control links to the OMC-R) through the
MSC.
number of trunks between the MSC and the BSC (Refer to Figure 7-1).
NOTE
7-8
When HSP MTL feature is used and the E1 links go to MSC by RXCDR, MSIs
are required to terminate HSP MTL at RXCDR. If the HSP MTLs go from the
BSC to the MSC directly, there is no impact on RXCDR planning and C2M is 0
in the equation.
HSP MTL and 64 kbps MTL cannot be supported simultaneously.
68P02900W21-T
Jul 2010
GPROC nomenclature
In this manual, the different versions of the Generic Processor are as follows:
GPROC2: Refers to GPROC2
GPROC3: Refers to GPROC3
GPROC3-2: Refers to GPROC3 phase 2
GPROC: Refers to both GPROC2 and GPROC3/GPROC3-2
Introduction
Generic processor (GPROC) boards are used throughout the Motorola BSS as a control
processor. The GPROC3/GPROC3-2 is a high performance direct replacement for GPROC2s.
This allows for any combination of GPROC types to be installed.
The following factors should be considered when planning the GPROC complement at the
RXCDR:
Each shelf needs at least one GPROC board, along with one for redundancy.
A maximum of two GPROCs per shelf are supported:

One BSP GPROC
One GPROC that can be configured as a redundant BSP GPROC or as a CSFP GPROC
NOTE
For RXCDR, both GPROC2 and GPROC3s/GPROC3-2s can be in the BSP slots.
68P02900W21-T
7-9
Jul 2010
Transcoding
Transcoding
Introduction
Transcoders (XCDR/GDP/EGDP/GDP2s) provide the interface for the E1 links between the
MSC and the BSC.
The XCDR/GDP/EGDP/GDP2s perform the transcoding/rate adaptation function, which
compresses the information on the trunks by a factor of four (16 kbps). When (AMR or GSM)
half rate is in use and 8 kbps subrate switching is available [and the 7.95 kbps half rate codec
mode is not included in the Half Rate Active Codec Set (AMR)] the reduction factor for the half
rate calls becomes eight.
NOTE
In most configurations, half rate is used only a part of the time, thus yielding a
reduction factor of less than eight.
The number of links between the RXCDR and the BSC is reduced to approximately one quarter
(less when half rate is employed under the conditions described ) of the number of links
between the RXCDR and the MSC.
The GDP2 can process 60 channels of FR, EFR, AMR, GSM HR, and Phase 2 data services, and
is capable of terminating two E1 links from the MSC. It can also function as a replacement for
the GDP. Within the RXCDR, enhanced capacity mode must be enabled to access the second
E1 when GDP2s are used.
An EGDP is a new configuration of the GDP board, which is used to support AMR. Due to the
additional transcoding requirements of AMR, each of the 15 DSPs on the GDP board is only
capable of supporting the transcoding function for a single channel of GSM speech (AMR,
FR, and EFR) and Phase 2 data services. To offer 30 channels of enhanced transcoding using
the same E1 span line to the MSC, EGDPs are equipped as pairs, each providing half of the
transcoding resources.
NOTE
This results in an overall reduction in transcoding shelf capacity, which is equivalent
to 30 channels per GDP pair.
Use of an EGDP is practical only when used with AMR. The EGDP does not support GSM half
rate. The EGDP can also terminate one Ater E1 link, thus reducing the number of MSI boards
required (Refer to EGDP provisioning on page 7-13). The GDP2 can function as GDP and hence
it can replace one or both the GDPs in the EGDP configuration. This is not an optimal use of the
GDP2 and occurs in emergency situations (for example, board replacement). As a result, it is
not considered in the planning procedures.
7-10
68P02900W21-T
Jul 2010
Introduction
The MSC recommends a particular codec type or types to be used on a call by call basis. It
sends the BSC a preference-ordered list, based on factors such as MS capabilities and user
configuration. When the MSC is capable of selecting the MSC-RXCDR trunk (CIC) based upon
the preferred codec type, a mix of transcoding equipment can be used. If this circuit pooling
capability is not present, some equipment combinations can result in non-optimal behavior.
When circuit pooling is available in an AMR enabled system, both AMR-capable (EGDP/GDP2)
and non -AMR-capable (XCDR/GDP) equipment are used. If circuit pooling is not present, GDP2s
or EGDPs should be used exclusively to prevent downgrading or blocking of calls.
When AMR is employed and both XCDR/GDPs and EGDP/GDP2s are present (and circuit pooling
is present at the MSC), there must be sufficient GDP2 and EGDP equipment available to handle
the expected AMR traffic. The proportion of AMR-capable transcoding circuits versus nonAMR-capable transcoding circuits should not be less than the proportion of AMR-capable MSs
versus non -AMR-capable MSs. A safety factor of no less than 20% is recommended (20% allows
for some variation in the actual number and allows for a period of growth in AMR-capable MS
penetration before having to add more AMR transcoding ability). Each AMR half rate call
needs one (AMR) transcoder circuit. Lack of an available AMR circuit could cause a call to be
downgraded to another codec type or possibly blocked.
When GSM half rate is employed and a mix of XCDRs and GDP/GDP2s are present, a similar
situation exists. However, due to the early introduction into the standards of GSM half rate,
most mobiles are expected to be GSM half rate capable. Since a CIC is not tied to any particular
voice channel, circuit pooling is rendered ineffective, as there is no way to predict which
mobiles need GSM half rate. It becomes necessary to update all transcoding to support GSM
HR to guarantee that GSM half rate can be used when required. Without this upgrade, calls
on non-GSM HR capable CICs remain on a full rate channel.
When GSM half rate and AMR are both in use and a combination of AMR transcoding equipment
(EGDP, GDP2) and GSM half rate transcoding equipment (GDP, GDP2) exist, circuit pooling is
most effective when selecting AMR CICs (EGDP, GDP2) for AMR capable mobiles, and the
remaining CICs for non- AMR capable mobiles. Ideally, for AMR capable mobiles the MSC would
first select a CIC attached to an EGDP, followed by one attached to a GDP2. For a non-AMR
capable mobile the MSC would first select a CIC attached to a GDP, followed by one attached
to a GDP2. The selection of the proper CIC (circuit pool) is dependent upon the capability of
the connected MSC.
Each trunk needs a quarter (1/4th) (or an eighth (1/8th) in some cases for AMR half rate as
described ) of a 64 kbps circuit between the RXCDR and BSC.
Each control link (RSL, OML, XBL, C7) needs one 64 kbps circuit (RSL and XBL have the
option of using 16 kbps circuits).
Figure 7-1 shows sub-multiplexing and speech transcoding at the RXCDR.
68P02900W21-T
7-11
Jul 2010
XCDR/GDP/EGDP/GDP2 planning considerations
Figure 7-1 Sub-multiplexing and speech transcoding at the RXCDR

BSC
RXCDR
X
C
D
R/
G
D
P/
G
D
P
2
M
S
C
64 kbit/s
A-LAW
TRUNKS
K
S
W
/
D
S
W
2
M
S
I
/
M
S
I
2
M
S
I
/
M
S
I
2
4 TO 8 TRUNKS PER
64 kbit/s CIRCUIT
THE XCDR/GDP/GDP2 TRANSCODES 64 kbit/s

A-LAW PCM TO/ FROM 13 kbit/s MAPPED
ONTO 16 kbit/s OR UP TO 8 kbit/s MAPPED
ONTO 8 kbit/s, AND SUBMULTIPLEXES 4 to 8
TRUNKS TO/FROM 1 x 64 kbit/s CIRCUIT.
Horizon II macro BTS
K
S
W
/
D
S
W
2
M
S
I
/
M
S
I
2
N
I
U
ONE RF
CARRIER
C
T
U
2
HIISC
64 kbit/s
4 OR 8 TCHs
THE KSW (DSW2)

SUBRATE SWITCHES
16 kbit/s (8 kbit/s)
TIMESLOTS.
THE CTU2 ENCODES/DECODES
13 (UP TO 8 FOR HALF RATE) kbit/s
TO/FROM 22.8 (11.4) kbit/s FOR 8 (16)
TIMESLOTS, AND SUBMULTIPLEXES 4
(13 kbit/s MAPPED ON 16 kbit/s) OR 8
(UP TO 8 kbit/s MAPPED ON 8 kbit/s
FOR HALF RATE) TIMESLOTS ONTO 1 x
64 kbit/s CIRCUIT, OR THE OTHER WAY
AROUND.
8 x 22.8 kbit/s TIMESLOTS OR

16 x 11.4 kbit/s TIMESLOTS
ti-GSM-Sub_multiplexing_and_speech_transcoding_at_the_RXCDR-00130-ai-sw
NOTE
In Figure 7-1, the CTU2 operates in single density mode (one carrier), although it
can also operate in double density mode (two carriers).
XCDR/GDP/EGDP/GDP2 planning considerations

The following factors should be considered when planning the XCDR/GDP/EGDP/GDP2
complement:
7-12
An XCDR can process 30 voice channels (E1), support GSM Full Rate speech (GSM FR),
uplink/downlink volume control and is capable of terminating one E1 link from the MSC.
A GDP can process 30 voice channels (E1), support GSM FR, enhanced Full Rate speech
(EFR), GSM half rate speech (GSM HR), uplink/downlink volume control and is capable
of terminating one E1 link from the MSC.
An EGDP consists of a pair of GDP cards, a primary and a secondary. Each EGDP can
process 30 channels of GSM FR, EFR, AMR (FR and HR speech), and Phase 2 data services,
and terminates one E1 link from the MSC.
The primary GDP of an EGDP terminates the E1 interface to the MSC.
68P02900W21-T
Jul 2010
EGDP provisioning
The secondary GDP of an EGDP may terminate an E1 interface to the BSC. Refer to EGDP
provisioning on page 7-13.
The GDP2 can process 60 channels of FR, EFR, AMR (FR and HR), GSM HR, and Phase 2
data services and is capable of terminating two E1 links from the MSC. It can also function
as a replacement for the GDP.
The GDP2 is used to terminate 2 E1s (that is, 60 voice channels) only in the RXU3 shelf
and BSSC3 cabinet (enhanced capacity mode must be enabled to access the second E1
when GDP2s are used). The current RXU shelf has only one E1 per transcoder slot, and the
current BSSC2 cabinet does not have space for additional line interface boards. The GDP2
supports only 30 channels when used in the RXU shelf and/or BSSC2 cabinet.
XCDRs, GDPs, EGDPs, and GDP2s can co-exist in a shelf.
The proportion of AMR-capable circuits (GDP2/EGDP) to non AMR-capable circuits

(XCDR/GDP) should be sufficient to handle the expected AMR traffic.
The master MSI slot(s) should always be populated to enable communication with the
OMC-R. The master MSI slot can contain an XCDR/GDP/EGDP (either the primary or the
secondary) /GDP2, if the OML goes through the MSC.
The A Interface must terminate on the XCDR/GDP/EGDP (either the primary or the
secondary) /GDP2.
Slot 24 (XCDR 0) in the RXU shelf 0 (master) is lost if an optional NVM board is required.
NOTE
An XCDR card is incompatible with a GPROC3/GPROC3-2 in the BSP slots.
XCDRs must be replaced with GDP/GDP2s.
EGDP provisioning
The secondary GDP of an EGDP uses the E1 connection to terminate an Ater link. This reduces
the need for MSIs and makes more efficient use of the available TDM timeslots.
NOTE
The secondary GDP has one E1 interface (instead of two for an MSI), which must be
taken into account in site (MSI) planning.
Figure 7-2 and Figure 7-3 show the EGDP used in configurations with and without the additional
E1 termination in use, respectively.
68P02900W21-T
7-13
Jul 2010
EGDP provisioning
Figure 7-2
EGDP configuration with the additional E1 termination in use

TDM Bus
Primary
GDP
15
DSPs
E1 Spam
to MSC
15
DSPs
Secondary
GDP
E1 Span
from an RXCDR
to a BSC or from
a BSC to a BTS
ti-GSM-EGDP_configuration_with_the_additional_E1_termination_in_use-00131-ai-sw
7-14
68P02900W21-T
Jul 2010
Planning actions for transcoding at the RXCDR
Figure 7-3 EGDP configuration without the additional E1 termination in use
Static
Pass-thru
connections
(at 64kbps)
Subrate
channels
carried onto
the TDM bus
(TRAU frames
using 16Kbps)
RXCDR: Static
or dynamic call
connections
between CICs
for GDP pair
and after
channels
(TRAU frames
using 16Kbps)
BSC: Dynamic call

connections between
CICs for a GDP pair
and Abis channels
(TRAU frames
using 16Kbps)
TDM Bus
Primary
GDP
E1 Span
to MSC
15
DSPs
MSI
E1 Span
from an RXCDR
to a BSC or from
a BSC to a BTS
Secondary
GDP
15
DSPs
ti-GSM-EGDP_configuration_without_the_additional_E1_termination_in_use-00132-ai-sw

The number of transcoders at the RXCDR is proportional to the number of E1 links between
the RXCDR and the MSC.
Using E1 links
Each XCDR/GDP/EGDP can terminate one E1 link. Each GDP2 can terminate two E1 links [when
used in an RXU3 shelf with enhanced capacity mode enabled (when GDP2s are used)].
Plan the equipment according to the following formula:
XGE + 2 G2 = NRXCDRM SC
68P02900W21-T
7-15
Jul 2010
Where:
Is:
XGE
number of XCDRs, GDPs, and EGDPs.
G2
number of GDP2s.
NRXCDR-MSC
minimum number of E1 links required (as N is calculated in RXCDR

to MSC links on page 7-8).
Verify that the number of AMR circuits is sufficient to handle the expected AMR traffic. If
necessary, adjust the number of EGDP/GDP2s. Use the following formula to determine the
percentage of AMR-capable circuits:
%AM R Circuits =
(GDP 2 60 + EGDP 2 30)

100
(GDP 2 60 + EGDP 2 30 + XCDR 30 + GDP 30)
NOTE
In the equation, count the primary and secondary EGDPs as one EGDP.
If HSP MTL is unrestricted and passes through RXCDR, MSI cards are required
to terminate HSP MTLs between RXCDR and MSC (refer to the section RXCDR
to BSC links on page 7-6).
XGE + 2 G2 = NRXCDRM SC C2M
7-16
In the equation, C2M is the number of HSP MTLs.
68P02900W21-T
Jul 2010
Introduction
A multiple serial interface provides the interface for the links between an RXCDR site and other
network entities, RXCDR to OMC-R and RXCDR to BSC.
The following factors should be considered when planning the transcoder complement:
Each MSI can interface two E1 links.
Each E1 link provides 31 usable 64 kbps channels.
Redundancy for the MSI depends on the provisioning of redundant E1 links connected
to the site.
When one remote transcoder site supports multiple BSCs, each BSC needs its own E1
interface as follows:
The number of MSIs should be equal to half the number of RXCDR to BSC E1 links.
Redundancy needs additional links and MSIs.
If the OMLs (X.25 links) do not go through the MSC, a dedicated E1 link (half an MSI)
is required for the X.25 links to the OMC-R.
If HSP MTL is used and passes through RXCDR, additional E1 links are required for
HSP MTLs. MSI cards are required to terminate HSP MTLs that go to the MSC.
Additional E1 links are required to support OPL link.
Additional E1 links are required to concentrate X.25 links from other network entities.
Each BSC uses one to four 64 kbps or 16 kbps channels for XBL fault management
communications. Refer to Service Manual: BSC/RXCDR (68P02901W38) for further
details.
The master MSI slots should always be populated to enable communication with the
OMC-R.
If the OML links go directly to the MSC, the master slot should be filled with an
XCDR/GDP/EGDP (primary or secondary) /GDP2, else the slot should be filled with an
MSI that terminates the E1 link carrying the OML link to the OMC-R. These E1 links
should not require to go directly to the OMC-R, they can go to another network element
for concentration.
68P02900W21-T
7-17
Jul 2010

With E1 links
Use the following equation to determine the number of MSIs required:
NM SI = NBSCRXCDR /2
Where:
NMSI
NBSC-RXCDR
7-18
Is:
number of MSIs required.
number of E1 links required (as N calculated in RXCDR to BSC links
on page 7-6).
68P02900W21-T
Jul 2010
Kiloport switch (KSW) and double kiloport switch (DSW2)
Kiloport switch (KSW) and double kiloport switch

(DSW2)
Introduction
The KSW/DSW2 provides digital switching for the TDM highway of the RXU.
The double kiloport switch (DSW2) is an enhanced version of the KSW, which supports double
the number of ports (enhanced capacity mode), as well as extended subrate switching capability
down to 8 kbps (extended subrate switching mode). Use of 8 kbps subrate switching can reduce
backhaul costs when used with the AMR or GSM half rate feature.
The following factors should be considered when planning the KSW/DSW2 complement:
A minimum of one KSW/DSW2 is required for each RXU site.
The KSW or DSW2 which is not in enhanced capacity mode, has a capacity of 1024 x
64 kbps ports or 4096 x 16 kbps ports, which can be expanded by adding up to three
additional KSW/DSW2s, giving a total switching capacity of 4096 x 64 kbps ports or 16384
x 16 kbps ports.
When operating in enhanced capacity mode, the DSW2 has a capacity of 2048 x 64 kbps
DSW2s, giving a total switching capacity of 8192 x 64 kbps ports or 32768 x 16 kbps ports.
When operating in extended subrate switching mode (but not enhanced capacity mode),
the DSW2 can further switch 8192 x 8 kbps ports which can be expanded by adding up to
When operating in extended subrate switching mode and enhanced capacity mode, the
DSW2 can further switch 16384 x 8 kbps ports which can be expanded by adding up to
Eight (64 kbps) timeslots per KSW/DSW2 are reserved by the system for test purposes and
are not available for use.
A mix of KSWs and DSW2s needs that the DSW2s are not operated in the enhanced
capacity mode.
For redundancy, duplicate all KSWs/DSW2s. In mixed configurations (KSWs and DSW2s),
KSWs can be redundant to DSW2s and vice-versa.
Verify that each KSW or DSW2 not in enhanced capacity mode uses no more than 1016
ports, or that each DSW2 in enhanced capacity mode uses no more than 2040 ports (8
ports are used internally). The devices in an RXCDR that need TDM timeslots are:
GPROC2 or GPROC3 = 32 (or 16) timeslots
68P02900W21-T
7-19
Jul 2010
GDP or XCDR (or GDP2 acting as a GDP replacement) = 16 timeslots

EGDP = 96 timeslots
GDP2 = 24 timeslots
MSI = 64 timeslots
The number of TDM timeslots is given by:
N = (G N ) + (RGDP XCDR 16) + (REGP D 96) + (REDP 2 24) + (M 64)

Where:
Is:
number of timeslots required.
number of GPROCs.
RGDPXCDR
number of GDPs/XCDRs.
REGDP
number of EGDPs.
REDP2
number of GDP2s.
number of MSIs.

Use the following formula to determine the number of KSWs or DSW2s required when enhanced
capacity mode is not enabled:
N = [(G n) + (RGDP XCDR 16) + (REGP D 96) + (REDP 2 24) + (M 64)] /1016
Use this formula when enhanced capacity mode is enabled:
N = [(G n) + (RGDP XCDR 16) + (REGP D 96) + (REDP 2 24) + (M 64)] /2040
Where:
N
number of KSWs/DSW2s required.
number of GPROCs.
RGDPXCDR
number of GDPs/XCDRs.
REGDP
number of EGDPs.
REDP2
number of GDP2s.
7-20
Is:
number of MSIs
68P02900W21-T
Jul 2010
Each KSW/DSW2 has to serve the boards in its shelf along with the boards of any extension shelf
connected to its shelf by its TDM highway of 1016 available timeslots (or 2040 when operating
in enhanced capacity mode). In case of multiple expansion shelves, the TDM highways of each
shelf do not merge into a common unique TDM highway across all shelves, that is, a KSW/DSW2
in one shelf cannot serve boards in other expansion shelves.
For example, in the case of an RXCDR consisting of two shelves each having 32 unused timeslots
per KSW/DSW2 free, an additional MSI board cannot be added even if an MSI slot is free at
each shelf (but one GPROC per shelf can be added if one GPROC slot per shelf is free).
68P02900W21-T
7-21
Jul 2010
RXU shelves
RXU shelves
Introduction
The number of RXU shelves is a function of the number of MSIs and XCDR/GDP/EGDP/GDP2s
required.
The following factors should be considered when planning the number of RXU shelves:
7-22
Each expansion shelf is allocated to a single KSW/DSW2 and shelves are differentiated
by the presence of the KSW/DSW2. Extension shelves are those, which do not contain a
primary KSW/DSW2. Shelves containing a KSW/DSW2 are called expansion shelves.
An extension shelf extends the TDM highway. It is constrained to the same number of
(aggregate) timeslots as the shelf containing the KSW/DSW2.
An expansion shelf adds an additional TDM highway. It increases the number of timeslots
to that of the additional KSW/DSW2.
The number of devices that can be served by a KSW/DSW2 is governed by the TDM
timeslot allocation required for each device. This is discussed previously in the KSW/DSW2
planning considerations. The number and type of shelves can then be determined from
the devices required.
For example, two shelves, each equipped with three MSIs and 16 GDP/XCDRs, can be
served by a single KSW.
If each shelf has five MSIs with 14 GDP/XCDRs, the KSW can serve only one shelf, and
two KSWs are required.
The existing RXU shelf has connectivity for up to five MSIs (2 x E1 connections). The
remaining 14 slots have one E1 connection. All slots are used for XCDR/GDP/EGDP
(primary or secondary) /GDP2s.
The RXU3 shelf has connectivity for two E1s per slot. All slots are used for
XCDR/GDP/EGDP/GDP2s and MSIs.
The GDP2 can be used to terminate 2 x E1s (that is, 60 voice channels), only in the RXU3
shelf and BSSC3 cabinet (enhanced capacity mode must be enabled to access the second
E1 when GDP2s are used). The current RXU shelf has only one E1 per transcoder slot, and
the current BSSC2 cabinet does not have space for additional line interface boards. The
GDP2 supports only 30 channels when used in the RXU shelf and/or BSSC2 cabinet.
68P02900W21-T
Jul 2010
RXU shelf planning actions
If all the XCDR slots in the RXU shelf 0 (master) are required, an NVM board cannot be
installed.
NOTE
An XCDR card is incompatible with a GPROC3 in the BSP slots. XCDRs must
be replaced with GDP/GDP2s.
RXU shelf planning actions

Use the appropriate formula (fractional values should be rounded up to the next integer) to
determine the number of RXU shelves required:
For the current generation RXU shelf:
RX = max ((M/5) + (R + NN V M ) /16)

For the new generation RXU3 shelf:
RX3 = (M + R + NN V M ) /19
Where:
Is:
RX
minimum number of RXU shelves required.
RX3
minimum number of RXU3 shelves required.
number of MSIs.
number of XCDR/GDP/EGDP/GDP2s.
NNVM
number of optional NVM boards (0 or 1).
NOTE
For EGDPs, both the primary and the secondary must be counted.
The number of timeslots equipped to each shelf must be verified using the appropriate equation
given.
68P02900W21-T
7-23
Jul 2010
Enhanced capacity mode is enabled (non-extension shelf)
Enhanced capacity mode is not enabled

The verification procedure is like the KSW/DSW2 planning consideration.
(G n) + (RGDP XCDR 16) + (REGDP 96) + (RGDP 2 24) + (M 64) 1016

Where:
Is:
number of GPROCs in the shelf.
16 or 32 (depending on the value of the gproc_slots database

parameter).
RGDPXCDR
number of GDP/XCDRs in the shelf.
REGDP
number of EGDPs in the shelf.
RGDP2
number of GDP2s in the shelf.
number of MSIs in the shelf.
Enhanced capacity mode is enabled (non-extension shelf)
Enhanced capacity mode is enabled (extension shelf)

If the result of using the appropriate equation exceeds the value quoted, the configuration of
MSIs, GPROCs and GDPs can be adjusted, or an additional shelf or shelves are required.
7-24
68P02900W21-T
Jul 2010

extender (KSWX) and double kiloport switch extender (DSWX)
Kiloport switch
Kiloport switch extender (KSWX) and double kiloport

switch extender (DSWX)
Introduction
The KSWX extends the TDM highway of an RXU to other RXUs and supplies clock signals to
all shelves in multi-shelf configurations. The KSWX is required whenever a network element
grows beyond a single shelf. The DSWX performs the same function as the KSWX. It is
necessary when enhanced capacity mode (2048 timeslot capability) is used (but not in extended
subrate switching mode).
The following factors should be considered when planning the KSWX/DSWX complement:
KSWXs/DSWXs are not required in a single shelf configuration (that is, when expansion or
extension is not required).
For redundancy, duplicate all KSWX/DSWX boards (needs redundant KSW/DSW2).
In mixed configurations (KSWXs and DSWXs), KSWXs can be redundant to DSWXs and
vice-versa.
KSWXs/DSWXs are used in three modes:

KSWX/DSWXE (Expansion) are required to interconnect the KSWs/DSW2s for sites
with multiple KSWs/DSW2s.
KSWX/DSWXR (Remote) are required in shelves with KSWs/DSW2s to drive the TDM
highway in shelves that do not have KSWs/DSW2s.
KSWX/DSWXL (Local) are used in shelves that have KSWs/DSW2s to drive the clock
bus in that shelf and in shelves that do not have KSWs/DSW2s to drive both the local
TDM highway and the clock bus in that shelf.
Five of the redundant KSWX/DSWX slots are also CLKX slots.
The maximum number of KSWX/DSWX slots per shelf is 18, nine per KSW/DSW2.
KSWXs and DSWXs may both be used. However, KSWXs and DSWXs should always be
used with like pairs, that is, DSWXs with DSWXs and KSWXs with KSWXs.
68P02900W21-T
7-25
Jul 2010
Operation in enhanced capacity mode needs the use of all DSWXs (and DSW2s).
NOTE
The fiber optic cables, which are used to extend/expand the TDM highway from
one RXU to another RXU, must be of the same length to limit the risk of TDM
highway extension/expansion errors.

The number of KSWXs/DSWXs required is the sum of the KSWX/DSWXE, KSWX/DSWXL and
KSWX/DSWXR.
NKXE = K (K 1)
NKXR = SE
When SE=0, NKXL=0.
When SE>0, NKXL=K+SE.
Where:
7-26
Is:
NKX
the number of KSWXs/DSWXs required.
NKXE
the number of KSWX/DSWXE.
NKXR
the number of KSWX/DSWXR.
NKXL
number of KSWX/DSWXL.
the number of non-redundant KSWs/DSW2s.
SE
the number of extension shelves.
68P02900W21-T
Jul 2010
For example:
Table 7-2
KSWX/DSWX (non-redundant)
Extension shelves
KSW/DSW2 (non redundant)

1
16
11
18
13
20
10
15
22
12
17
24
Table 7-3
KSWX/DSWX (redundant)
Extension shelves
68P02900W21-T
KSW/DSW2 (redundant)
1
18
32
12
22
36
10
16
26
40
14
20
30
44
18
24
34
48
7-27
Jul 2010
Introduction
The generic clock (GCLK) generates all the timing reference signals required by an RXU.
The following factors should be considered when planning the GCLK complement:
One GCLK is required at each RXCDR.
A second GCLK is optionally requested for redundancy.
Both GCLKs must reside in the same shelf of the RXCDR.
GCLK planning actions

Use the following formula to determine the number of GCLKs required:
GCLKs = 1 + 1 redundant
7-28
68P02900W21-T
Jul 2010
Introduction
A clock extender (CLKX) board provides expansion of GCLK timing to more than one RXU.
The following factors should be considered when planning the CLKX complement:
One CLKX is required in the first RXU shelf, which contains the GCLK, when expansion
beyond the shelf occurs.
Each CLKX can supply the GCLK signals to six shelves.
(LAN extension only allows 14 shelves in a single network element).
The maximum number of CLKX slots per shelf is six.
NOTE
The CLKX uses six of the redundant KSWX/DSWX slots.
With a CLKX, a KSWX/DWSXL is required to distribute the clocks in the master and each of
the expansion/extension shelves.
For redundancy, duplicate each CLKX (needs a redundant GCLK).
Fiber optic cables extending clock reference signals, from the parent shelf to all other
shelves and itself at a site, must be of the same length to maintain site synchronization
integrity.

Use the following formula to determine the number of CLKXs required:
NCLKX = ROU N DU P
68P02900W21-T
E
6
(1 + RF )
7-29
Jul 2010
Where:
7-30
Is:
NCLKX
the number of CLKXs required.
ROUND UP
number of shelves.
RF
redundancy factor (1 if redundancy is required (recommended), 0

for no redundancy).
68P02900W21-T
Jul 2010
LAN extender (LANX)
LAN extender (LANX)
Introduction
The LANX provides a LAN interconnection for communications among all GPROCs at a site.
The following factors should be considered when planning the LANX complement:
A LANX is supplied in each shelf.
For full redundancy, add one LANX for each shelf.
The LANX can support a maximum network size of 14 shelves.
LANX planning actions

Use the following formula to determine the number of LANXs required:
NLAN X = NRXU (1 + RF )
Where:
NLANX
number of LANXs required.
NRXU
number of RXU shelves (RXU 14).
RF
68P02900W21-T
Is:
redundancy factor (1 is the recommended value if redundancy is

required, 0 for no redundancy).
7-31
Jul 2010
Introduction
The PIX provides eight inputs and four outputs for site alarms.
The following factors should be considered when planning the PIX complement:
The maximum number of PIX board slots per shelf is two.
The maximum number of PIX board slots per site is eight.
PIX planning actions

Determine the number of PIXs required as follows:
PIX 2 * number of RXUs
or
PIX ? 8
7-32
68P02900W21-T
Jul 2010
Line interfaces (BIB, T43)
Line interfaces (BIB, T43)
Introduction
The line interfaces, balanced-line interface board (BIB) and T43 board (T43), provide impedance
matching for E1 links.
Use a BIB to match a balanced 120 ohm (E1 2.048 Mbps) or balanced 110 ohm 3 V (peak
pulse) line.
Use a T43 Board (T43) to match a single-ended 75 ohm 2.37 V (peak pulse) line.
Each BIB/T43 can interface six E1 links to specific slots on one shelf.
All E1 links must be terminated, including the links, which are fully contained in the
cabinet, for example, between RXU and BSU.
Up to four BIBs or T43s per shelf can be mounted on a BSSC2 cabinet.

A maximum of 24 E1 links can be connected to an RXU shelf.
A BSSC2 cabinet with two RXU shelves can interface 48 E1 links.
Up to seven BIBs or T43s per shelf can be mounted on a BSSC3 cabinet.

A maximum of 38 E1 links can be connected to an RXU3 shelf.
A BSSC3 cabinet with two RXU3 shelves can interface 76 E1 links.
NOTE
68P02900W21-T
When fully equipping two RXU3 shelves with 38 E1s each, there are four unused
E1 links on two of the BIB/T43s.
GDP2s must be used to utilize fully two E1s per slot.
7-33
Jul 2010
BIB/T43 planning actions
BIB/T43 planning actions

7-34
Determine the number E1 link to be driven.
Calculate the number of E1s to be terminated for each shelf.
Determine the number of BIBs or T43s required per shelf.
Minimum number of BIBs or T43s required per shelf = Number of E1 links/6.
Sum up across all shelves for the total.
68P02900W21-T
Jul 2010
Introduction
A BSSC cabinet can be supplied to operate from either a +27 V dc or -48/-60 V dc power source.
The following factors should be considered while planning the PSM complement:
Two DPSMs are required for each shelf in the BSSC/RXCDR.
Two IPSMs are required for each shelf in the BSSC2/RXCDR (-48/-60 V dc).
Two EPSMs are required for each shelf in the BSSC2/RXCDR (+27 V dc).
For redundancy, add one DPSM, IPSM or EPSM for each shelf.
Power supply planning actions

Use the following formula to determine the number of PSMs required:
P SM S = 2 N umber of RXU s + RF N umber of RXU s

Where RF = is the Redundancy factor (recommended value is 1 if redundancy is required, 0
for no redundancy).
68P02900W21-T
7-35
Jul 2010
Introduction
The non volatile memory board provides the Remote Transcoder with an improved recovery
facility following a total power loss. With the NVM board installed, data is retrieved from the
NVM board rather than from the OMC-R during recovery from a total power loss.
The following factors should be considered when planning the NVM complement:
Only one NVM board can be installed at the RXCDR.
The NVM board uses slot 24 on the RXU shelf 0 (master) of the RXCDR. If an XCDR board
is already occupying that slot, the XCDR board and associated interface cabling can be
moved from slot 24 to the spare slot. If there are no spare slots, then remove the XCDR
board occupying slot 24 to accommodate the NVM board, with a subsequent reduction in
capacity of the RXCDR.
Load the appropriate software required to support the NVM board at the OMC-R and
download it to the RXCDR.
NVM planning actions

The NVM board is optional.
7-36
68P02900W21-T
Jul 2010
Verify the number of RXU shelves and BSSC cabinets
Verify the number of RXU shelves and BSSC cabinets
Verification
After planning is complete, verify that:
Each non-redundant KSW/DSW2 has its own shelf.
The number of KSWXs/DSWXs, LANXs, CLKXs, and GPROCs is correct.
The number of (MSIs + XCDRs + GDPs + 2*EGDPs + GDP2s + NVM) 19 * number of

shelves (NVM is an optional board and Max shelves per each RXCDR is 8).
If necessary, add extra RXU shelves. Each BSSC cabinet supports two RXU shelves.
68P02900W21-T
Jul 2010
7-37
Verification
7-38
68P02900W21-T
Jul 2010
Chapter
8
BSS planning for GPRS/EGPRS
The following information for the PCU upgrade to the BSS to support GPRS and EGPRS is
provided:
BSS planning for GPRS/EGPRS on page 8-2
PCU hardware layout on page 8-21
PCU shelf (cPCI) on page 8-22
MPROC board on page 8-24
DPROC board on page 8-25
PMC module on page 8-30
(Packet) Rear Transition Module on page 8-31
PCU equipment redundancy and provisioning goals on page 8-32
E1 link/ETH link provisioning for GPRS and EGPRS on page 8-46
QoS capacity and QoS2 impact on page 8-49
PCU-SGSN: traffic and signal planning on page 8-63
BSS-PCU hardware planning example for GPRS on page 8-72
BSS-PCU hardware planning example for EGPRS on page 8-79
68P02900W21-T
Jul 2010
8-1
Introduction to BSS planning for GPRS/EGPRS

The BSS planning process for GPRS/EGPRS involves adding additional BSS equipment and
software to the BSS, in addition to the PCU hardware and software. The extent of the additional
BSS equipment depends on the amount of traffic expected to be carried over the GPRS/EGPRS
part of the network and the coding schemes used on the air interface.
NOTE
This section contains planning for both GPRS and EGPRS and notes differences
where appropriate.
The section GPRS/EGPRS network traffic estimation and key concepts in Chapter 3 BSS cell
planning is intended to provide the network planner with the rules to determine the number of
GPRS/EGPRS timeslots that are to be provisioned at the BTS, later provisioned in PCU hardware
with communication links.
The BSS planning process described here focuses on the provisioning of the PCU hardware
within the BSS. Refer to BSS-PCU hardware planning example for GPRS on page 8-72 and
BSS-PCU hardware planning example for EGPRS on page 8-79. Its purpose is to unite the
information presented in the entire document from a planning perspective.
PCU to SGSN interface planning

The PCU to SGSN interface is referred to as the Gb Interface. The Gb interface connects the
BSS PCU to the GPRS SGSN. Motorola supports 3 Gb interface options (options A, B, and
C), as shown in Figure 8-1.
8-2
68P02900W21-T
Jul 2010
Figure 8-1
Feature compatibility
PCU to SGSN interface planning
MSC
A interface
Gb
OMC-R
Option A
RXCDR
Gb
Option B
SGSN
BSC
For Option A and B
Gb
Option C
PCU
BTS1
BTS2
Option D
ti-GSM-PCU_to_SGSN_interface_planning-00133-ai-sw
The RXCDR can be used as an E1 switching interface between the PCU and SGSN, as shown in
option A. Alternatively, the BSC can be used as an E1 switching interface, as shown in option B.
In case of option C there is no BSS E1 switching element between the PCU and SGSN. Option D
provides the Ethernet/IP connection between the PCU and the SGSN, for more information refer
to {26638} Gb over IP on page 8-12 with the Gb over IP feature introduction.
The PCU is configured for E1 loop timing recovery on all the PCU E1 interfaces. The PCU is
connected directly to the BSC E1 interfaces and the BSC is configured to provide the E1 master
clock. If the PCU is connected to a GSN that does not have a master clock source, use some
interface equipment that has a master clock source (such as DACs). The Motorola BSC and
RXCDR equipment can be used in place of DACs for this purpose.
When an RXCDR or BSC is used as an E1 switching element, as shown in option A and option
B, respectively, additional equipment provisioning of these network elements are required to
support the PCU E1 interfaces. This is in accordance with the provisioning rules for adding E1
interfaces to the RXCDR and BSC network elements.
Alarms consolidation
No additional BSS, GPRS, or EGPRS network planning is required. PCU device alarms impact
only PCU functional unit severity, and not the cell functional unit severities. Therefore, the
impact is to the following PCU devices: DPROC and PCU System Processor (PSP).
68P02900W21-T
8-3
Jul 2010
BSC-BTS dynamic allocation

No additional BSS or GPRS network planning is required.
The dynamic allocation feature specifies how the BSC configures and shares the terrestrial
backing between the GPRS data traffic and the Circuit-Switched (CS) traffic. The terrestrial
backing between the BTS and BSC should have enough capacity to carry the radio timeslots
assigned to both GPRS and circuit switched traffic. If there is not enough capacity, because
there are not enough physical channels, the BSC allocates the backing to CS first. The
remaining capacity is assigned to GPRS (reserved GPRS timeslots first, and then to switchable
GPRS timeslots).
Any terrestrial backing resources not used by circuit-switched calls are allocated for switchable
use. However, circuit-switched calls can take resources away from the switchable pool when
traffic demands need more terrestrial capacity.
If backing is required for emergency circuit-switched calls, the BSC reassigns GPRS switchable,
or reserved backing to CS. In this case, the switchable and reserved backing is reassigned so
that the remaining GPRS radio timeslots within a carrier are contiguous.
The CS3/CS4 feature and EGPRS feature that need 32 kbps and 64 kbps bandwidth (variable
bandwidth in terms of a configurable rtf_ds0_count if VersaTRAU is unrestricted), respectively
on backhaul, have been designed to work mutually exclusively with the BSC-BTS dynamic
allocation feature.
Circuit error rate monitor

The GPRS/EGPRS feature does not provide no circuit error rate monitor support.
Circuit-switched (voice or data) calls

The addition of GPRS/EGPRS to a GSM network impacts the traffic and signaling handling
network capability for GSM voice and circuit data traffic. Additional loading on the BSS
elements due to the GPRS/EGPRS traffic needs additional BSS equipment and interface circuits.
Three classes of mobile devices permit non-simultaneous attachment to the circuit-switched and
packet data channels. Hence, the BSS need not be provisioned to simultaneously handle the
call processing and signaling for both circuit-switched traffic and GPRS/EGPRS packet data
services on a per subscriber basis.
Therefore, the BSS part of the network supports the simultaneous attachment, activation and
monitoring of circuit-switched and packet data services.
Concentric cells
GPRS/EGPRS timeslots are available in the outer zone carriers.
Congestion relief
No additional BSS or GPRS/EGPRS network planning is required. Congestion relief considers
switchable GPRS/EGPRS timeslots as idle TCHs.
8-4
68P02900W21-T
Jul 2010
Cell resource manager dynamic reconfiguration

No additional BSS or GPRS/EGPRS network planning is required.
The Cell Resource Manager (CRM) dynamic reconfiguration feature can use the switchable
GPRS/EGPRS timeslots, but it cannot reconfigure the reserved GPRS/EGPRS timeslots under
any circumstance.
Directed retry
The BSC uses directed retry to relieve cell congestion by redistributing traffic across cells. For
the GPRS/EGPRS traffic part of the BSS, the BSC treats switchable GPRS/EGPRS timeslots
like idle TCHs.
Emergency call preemption

The BSS can configure any GPRS and/or EGPRS timeslot to carry out emergency calls. If an
emergency call has to be made within a cell with a GPRS or EGPRS carrier, the BSS selects the
air timeslot in the following order:
Idle TCH
Switchable GPRS timeslot (from lowest to highest)
Switchable EGPRS timeslot (from lowest to highest)
If the emergency call preemption feature is enabled, the BSS select the air timeslot from the
following list in the following order:
1.
Idle TCH
2.
Switchable GPRS timeslot (from lowest to highest)
3.
Switchable EGPRS timeslot (from lowest to highest)
4.
In-use TCH
5.
Reserved GPRS timeslot (from lowest to highest)
6.
Reserved EGPRS timeslot (from lowest to highest)
7.
PBCCH/PCCCH timeslot
Emergency TCH channels are preempted when eMLPP is enabled and if the MSC has assigned a
low priority and preemption vulnerability to the emergency call occupying the TCH.
68P02900W21-T
8-5
Jul 2010
For cell with extended PDCH, when an MS is in the normal range, if there is no normal PDCH
available. the extended PDCH can be stolen for emergency call only. When the MS is in the
extended range, only the extended PDCH can be stolen for emergency call.
NOTE
Before any EGPRS timeslots are assigned switchable, all GPRS timeslots, if available,
is assigned to be switchable first.

No additional BSS or GPRS or EGPRS network planning is required.
The extended range cell feature extends the range of a GSM 900 MHz mobile beyond 35 km
up to a maximum range of 121 km (depending on limiting factors). For the cell with extended
PDCH, this range extension is also supported for GPRS or EGPRS carrier. Only one carrier can
be configured with extended PDCH in one cell.
Frequency hopping and redefinition

The GSM radio uses slow frequency hopping to improve data reliability and to increase the
number of active users. The GPRS/EGPRS timeslots assigned to the uplink and downlink
channels must have the same frequency parameters. GPRS/EGPRS timeslots can have a
different timeslot activity factor to voice, and hence cause the cell C/I performance to change
from a GSM-only system.
The frequency redefinition feature extends the GSM 4.08 capabilities to GPRS and EGPRS.
Global reset
The global reset procedure initializes the BSS and MSC in the event of a failure. A global reset
does not affect any resources assigned to GPRS/EGPRS.
Integrated Horizon HDSL interface

No additional BSS, GPRS, or EGPRS network planning is required other than to plan for the
GDS link.
The PCU does not support a high bit-rate subscriber line (HDSL) between the PCU and the
BSC. However, if an E1 is used for the connection, the BSC can use an MSI board (with HDSL
capabilities) to terminate a GDS link to the PCU.
Multiband handovers
No additional BSS, GPRS, or EGPRS network planning is required.
The BSC treats switchable GPRS/EGPRS timeslots like idle TCHs in the case of multiband
handovers.
8-6
68P02900W21-T
Jul 2010
Over the air flow control for circuit-switched mobiles

The BSC treats switchable GPRS/EGPRS timeslots like idle TCHs in the case of over the air flow
control for the circuit-switched mobiles feature.

The BSC uses a switchable GPRS/EGPRS timeslot for a Cell Broadcast CHannel (CBCH) or a
Standalone Dedicated Control CHannel (SDCCH).
The RTF path fault feature converts TCHs to SDCCH when an RTF path fault occurs. The
RTF path feature can also convert TCH barred switchable GPRS/EGPRS timeslots, to SDCCH.
The converted GPRS/EGPRS timeslots are returned to GPRS/EGPRS after the original RTF
path fault is cleared.
SMS cell broadcast

The CBCH can reside on a switchable GPRS/EGPRS timeslot. Therefore, switchable
GPRS/EGPRS timeslots can be reconfigured as SDCCHs. However, GPRS/EGPRS reserved
timeslots cannot be reconfigured as SDCCHs.
SD placement prioritization
A GPRS/EGPRS carrier cannot be configured such that the sum of the number of allowed
SDCCHs and the number of GPRS/EGPRS timeslots exceed the capacity of the carrier.
GPRS seamless cell reselection

Seamless cell reselection alleviates heavy performance degradation in the GPRS/EGPRSs system
due to frequent cell reselections by performing the cell change procedure at the RLC/MAC
layer rather than at a higher layer.
VersaTRAU backhaul
VersaTRAU backhaul feature allows the operator to configure the backhaul required for an
EGPRS capable RTF using the rtf_ds0_count parameter associated with the RTF. Plan the
backhaul per RTF based on the number of reserved and switchable timeslots in the cell and
expected RF conditions.
Table 8-1 summarizes the recommended VersaTRAU backhaul for a given number of configured
PDTCHs per carrier. The recommendations are based on the achievement of average coding
scheme of at least MCS6.
68P02900W21-T
8-7
Jul 2010
Table 8-1
VersaTRAU backhaul recommendations for a given number of PDTCHs

Recommended aggressive VersaTRAU
backhaul (average 28 kbps)
Number of
PDTCH
Recommended non-aggressive
VersaTRAU backhaul
Number of
DS0
Average kbps (effective MCS)
Number of
DS0
Average kbps
(effective MCS)
28 kbps (MCS5)
34 kbps (MCS6)
24 kbps (MCS5)
31 kbps (MCS6)
28 kbps (MCS5)
37 kbps (MCS6)
33 kbps (MCS6)
33 kbps (MCS6)
28 kbps (MCS5)
41 kbps (MCS6)
37 kbps (MCS6)
37 kbps (MCS6)
28 kbps (MCS5)
28 kbps (MCS5)
59 kbps (MCS9)
59 kbps (MCS9)
Table 8-2 shows the recommended initial settings (non-aggressive in terms of backhaul savings)
for the rtf_ds0_count for an EGPRS RTF when VersaTRAU backhaul feature is unrestricted.
The first two rows show the different initial configurations ranging from 1 PDTCH per carrier to
8 PDTCHs per carrier (non- BCCH carrier). The next row shows the number of DS0s forming
the VersaTRAU frame (Versachannel), the expected throughput and coding scheme with the
given VersaTRAU backhaul. The rows further down the table indicate the number of DS0s
constructing the VersaTRAU frame and throughputs after 1, 2, 3, 4, and 5 TSs are stolen for
voice. In this table, the recommended backhaul for the Versachannel is conservative, and
generally results in MCS6 (if all PDTCHs on the given carrier are carrying active data transfers
at the same time. If other timeslots on the carrier are idle due to the benefits of the statistical
multiplexing, higher coding schemes on individual timeslots can be reached).
Table 8-3 is more aggressive and shows the recommended number of DS0s forming the
VersaTRAU, which generally results in MCS5.
Table 8-2 Expected throughput/TS and coding schemes (conservative)

# of PD/carrier
# DS0 for
VersaTRAU
including voice
VersaTRAU %
saving versus
Today
38
38
38
50
50
50
63
63
# PDs left
Average
datarate/TS
34
31
37
33
41
37
28
59
#TRAU
CS used
MCS6 MCS6 MCS6
MCS6
MCS6 MCS6 MCS9
MCS9
Continued
8-8
68P02900W21-T
Jul 2010
Table 8-2 Expected throughput/TS and coding schemes (conservative) (Continued)

#TRAU
# PDs left
Average
datarate/TS
31
37
44
41
37
59
59
MCS6 MCS6 MCS6
CS used
#TRAU
MCS6
MCS6 MCS9 MCS9
# PDs left
Average
datarate/TS
37
44
59
37
59
59
MCS6 MCS6 MCS9
CS used
#TRAU
MCS6
MCS9 MCS9
# PDs left
Average
datarate/TS
44
59
59
59
59
MCS9
MCS9
MCS6 MCS9 MCS9
CS used
#TRAU
# PDs left
Average
datarate/TS
59
59
59
59
MCS9 MCS9 MCS9
CS used
#TRAU
# PDs left
Average
datarate/TS
59
59
59
MCS9
MCS9 MCS9 MCS9
CS used
Table 8-3 Expected throughput/TS and coding schemes (aggressive)

# of PD/carrier
# DS0 for
VersaTRAU
including voice
VersaTRAU %
saving versus.
Today
50
50
50
50
50
63
63
63
# PDs left
Average
datarate/TS
28
24
28
33
28
37
28
59
CS used
MCS5
MCS5
MCS5
MCS6
MCS5
MCS9
#TRAU
MCS5 MCS6
Continued
68P02900W21-T
8-9
Jul 2010
Table 8-3
Expected throughput/TS and coding schemes (aggressive) (Continued)
#TRAU
# PDs left
Average
datarate/TS
24
28
33
41
37
59
59
CS used
MCS5
MCS5
MCS6
MCS6
# PDs left
Average
datarate/TS
28
33
41
37
59
59
CS used
MCS6
MCS6
MCS6
MCS6
# PDs left
Average
datarate/TS
33
41
37
59
59
CS used
MCS6
MCS6
MCS6
MCS9
MCS9
# PDs left
Average
datarate/TS
44
39
59
59
CS used
MCS6
MCS6
MCS9
MCS9
# PDs left
Average
datarate/TS
37
59
59
CS used
MCS7
MCS9
MCS9
#TRAU
#TRAU
#TRAU
#TRAU
MCS6 MCS9
MCS9
MCS9 MCS9
If the feature Support the usage of idle TCH for the packet burst traffic is used, idle
congested in the cell. The additional 64k PDTCH shares the RTF backhaul with existing 64k
PDTCHs. Therefore, the RTF backhaul resource per carrier (rtf_ds0_count) for 64k EDGE
carrier should be sufficient to ensure the additional switchable PDTCH allocated by this feature
at EDGE carrier with least throughput downgrade.
Evolved PCU (ePCU)

The evolved PCU feature provides a migration path to expand existing GPRS capabilities.
The U-DPROC2 brings all the functionality of the DPROC board, with additional capability
for high-capacity operations. The U-DPROC2 is configured as a PXP, which combines the
functionality of the PICP and PRP on the same board. The PXP is connected to the PSI2 board in
the BSC through an Ethernet link.
8-10
68P02900W21-T
Jul 2010
PXP can provide PDCH capacity of 280/70 or 140/140 (Total Fanout/Throughput, refer NOTE). A
combination of PXP, PICP, and PRP can be configured in the PCU. It allows network users to
reuse existing DPROC hardware in PCU. Figure 8-2 is an example of mixed configuration in
which PRP, PICP, and PXP coexist in the PCU.
Figure 8-2 Mixed Deployment
ti-GSM-Mixed_Deployment-00134-ai-sw
Besides the mixed deployment, the PCU can be configured in one of the following ways:
U-DPROC2 boards configured as PICPs and PRPs. The U-DPROC2 functions as a

replacement of DPROC.
U-DPROC2 boards are configured as PXPs. The PCU can be fully configured with 12
U-DPROC2 boards functioning as PXP.
NOTE
68P02900W21-T
The Increase throughput of PRP with the PCU feature, provides an option
to increase PRP/PXP throughput in terms of mobiles that can be admitted
by reducing the PRP/PXP capacity. For prp_fanout_mode1, a maximum of X
timeslots per PRP/PXP (X:30 for PRP, and 70 for PXP) are served at a 20 ms
block period. For prp_fanout_mode2, all timeslots assigned to a PRP/PXP are
served at a 20 ms block period.
8-11
Jul 2010
More GPRS TSs can be set up in the database than the PRP/PXPs can support
without being rejected. MMI commands are accepted with a warning message.
It can save CAPEX of the operator, especially at the initial stage of GPRS
deployment and in the location only requiring GPRS coverage. At least, one
PDCH is assigned to a cell. The coverage has higher priority than capacity.
Enough PDCH resources/PRP should still be available when cell capacity is
required.
Gb over IP
{26638}
The Gb interface between the PCU and SGSN may be optionally provisioned over an IP
sub-network as an alternative connection to the current E1 using frame relay. Gb interfaces
over IP backhaul do not require expensive leased E1 lines/timeslots. They also provide the
benefits of an IP-based network such as lower cost, flexibility, more standardization, better
product positioning, and so on. This IP connection is available only on Ethernet connections
from the PCU.
NOTE
Mixed mode Gb interface (supporting both Frame Relay and IP Gb links to the same
PCU) is NOT supported. All Gb Interfaces to a PCU are assumed to be homogenous.
This is based on the fact that the operator will choose either Frame Relay or IP as
the network service for the Gb interface for a particular PCU, and not both. The IP
addresses used for Gb traffic should be IPv4 and of static configuration only. Static
configuration of NSVC is supported instead of dynamic configuration.
The Gb over IP feature enables the Ethernet port on PMC card (PPROC) in front of the
U-DPROC2 board while the U-DPROC2 is configured as PXP. The PPROC mounted on the PXP is
then capable of processing both Gb traffic and GDS while the baseboard of the PXP is capable of
processing the GDS traffic.
One Gb Ethernet port per PXP is supported. Therefore, maximum 12 Gb Ethernet links per PCU
are supported. The Gb Ethernet port is in 100/1000 Mbps auto negotiation mode.
NOTE
To avoid Ethernet duplex mode mismatch, it is mandatory that the duplex mode
of the Ethernet port to be set to auto negotiation mode at both PCU side and the
node directly connected to the PCU, which could be an SGSN or an intermediated
switch/router.
The Gb over IP feature is based on the ePCU deployment configuration, the U-DPROC2 and
PSI board are necessary for the Gb over IP feature deployment. Only when the U-DPROC2 is
configured as PXP, it supports the Ethernet GBL. The GDS has to be configured on the PXP
board to make the PXP Gb ETH and GBL in service. If the U-DPROC2 is configured as PICP
or PRP, it does not support the IP-based Gb.
The CPU_usage on the PPROC of the PXP board is has no significant difference between Gb
over IP and Gb over Frame Relay with same traffic load. However, Gb over IP provides bigger
throughput capacity than Gb over Frame Relay.
8-12
68P02900W21-T
Jul 2010
Although the Ethernet Gb bandwidth is more in comparison to the E1 Gb, the capacity of the PCU
does not increase due to the constraint of the U-DPROC2 capability. The end-to-end performance
is kept at the same level compared with the Gb over Frame relay under the condition of the
external IP network. Security can be guaranteed. IP intrusion detection and prevention can be
provided by the external IP network and its QoS satisfies the following quality conditions:
One way delay 10 ms
Packet drop rate 0.1%
Delay jitter 5 ms
Planning considerations when QoS is enabled

The QoS feature retains the supported TS per PRP/PXP board limit from previous loads.
However, when this feature is enabled, CPU utilization on DPROC and U-DPROC2 boards
increases. It is recommended to optimize PCU system after the deployment especially when
the PRPs are configured with DPROC boards. There are two key statistics, CPU_Usage and
PRP_LOAD, which should be used to monitor the CPU utilization and replan accordingly. Refer
to the details in the section PRP planning on page 8-26.
BSS upgrade provisioning rules

Table 8-4 identifies the BSS network elements that need upgrading to support GPRS/EGPRS.
Refer to the relevant planning information for the chassis-level planning rules covering the
BSC, BTS, and RXCDR.
Table 8-4 BSS upgrade in support of GPRS/EGPRS

Equipment
BSC
Additional element
Chassis (optional)
Software upgrade
BTS (Horizon II macro,

Horizonmacro, M-Cell6,
M-Cell2)
PCU
CTU2 Transceiver, with

EGPRS Firmware upgrade
(M-Cell6 and M-Cell2 need
the CTU Adapter with the
CTU2s)
Software upgrade
BSS upgrade
Add KSWs/DSW2s, LCF
GPROC2s/GPROC3s/GPROC3-2s,
BSP GPROC3s/GPROC3-2s, MSIs
per BSC as needed in support of
the Gb (where Gb is connected
through the BSC), RSL, BSC-BTS
traffic carrying E1 links. PSI2 or
MSI needed for GDS TRAU, GDS
LAPD (GSL). PT43/PBIB-ES when
PSI2 cards used.
EGPRS enabled CTU2 radios are
required.
CTU2D radios on Horizon II macro
also support EGPRS.
{34371G} CTU8m and RCTU8m
support EGPRS.
UDPROC-2s can replace DPROCs.
Continued
68P02900W21-T
8-13
Jul 2010
Table 8-4 BSS upgrade in support of GPRS/EGPRS (Continued)

Equipment
Additional element
BSS upgrade
For high capacity PCUs where
more than 24 E1s are needed, it is
necessary to add a second T43 or
BIB patch panel to the PCUs. The
upgrade kit includes a patch panel
(75 ohm or 120 ohm) and two cable
management brackets.
Besides E1, ETH is also used for
GDS TRAU and GSL link when
PXP/U-DPROC2 is used. The Gb
ETH is also used as an optional
substitution of the frame relay E1
for the Gb interface with the SGSN
when PXP/U-DPROC2 is used.
OMC-R
Software upgrade for

EGPRS support
One per 64 BSS network elements,

with any mix of circuit or packet
(GPRS) channels supported;
software in support of the PCU.
RXCDR
Chassis (optional)
Add KSWs/DWS2s, GPROC2s

/GPROC3s/GPROC3-2s, MSIs per
RXCDR as needed to support the
Gb interface shown as option A in
Figure 8-1.
NOTE
OMC-R planning steps and rules are beyond the scope of this manual.
Maximum BSS configuration

Table 8-5, Table 8-6 and Table 8-7 provide the recommended maximum BSS network parameter
values in support of GPRS and EGPRS per BSS network element.
Table 8-5 Recommended maximum BSS network parameter values (part A)

Network Element
PCU (PRP)
Network Parameter
Air interface timeslots
processing per PRP
Maximum Value
prp_fanout_mode1- 30 at any instance in
time; 120 total timeslots.
Continued
8-14
68P02900W21-T
Jul 2010

(Continued)
Network Element
PCU (PXP)
Network Parameter
processing per PXP
Maximum Value
PCU (PICP)
PCU-SGSN (Gb)
interface (E1 GBL)
4 Gb E1 to carry frame relay channelized or

non- channelized GPRS traffic deployed over
the BSC to PCU interface. The Gb E1 carries
both data and signaling traffic between the
PCU and SGSN.
PCU (PXP)
PCU-SGSN (Gb)
interface (ETH GBL)
If the Gb over IP feature is unrestricted and

the Gb mode is a static IP, 1 Gb ETH per PXP
is deployed to carry the GPRS traffic over the
BSS/PCU to SGSN interface. The Gb ETH IP
carries both data and signaling traffic between
the PCU and SGSN.
PCU
Maximum PSP
MPROCs
2 (for redundancy)
1 (no redundancy)
PCU
Maximum PICP
DPROCs
4*
PCU
Maximum PRP
DPROCs
9*
PCU
Maximum PXP
DPROCs
12*
PCU
Number of cells
supported
250*****
PCU
Number of BTS sites

supported
140*****
E1 numbers for
GSL (PICP)
Maximum physical
E1s between BSC and
PCU (one primary E1
and one redundant)
ETH links for GSL

(PXP)
Maximum physical
ETH links between
BSC and PCU
ETH links for GBL

(PXP)
Maximum physical Gb
ETH links between
PCU&SGSN
12***
12******
Continued
68P02900W21-T
8-15
Jul 2010

(Continued)
Network Element
LAPD-type GDS
links (GSL)
TRAU-type GDS
links
Network Parameter
Maximum Value
Maximum number
per E1 link (E1
corresponds to a
quantity of thirty 64
kbps LAPD channels)
30
Maximum per ETH

link
30
Maximum number of
E1s per PCU
36**
Maximum number of
ETHs per PCU
12***
NOTE
* The total numbers of DPROCs cannot exceed 12 in PCU.
** Maximum if all supported carriers on the PCU are EGPRS capable. PRPs can
support four E1s when terminating EGPRS timeslots (4x9 PRPs = 36 E1s).
***One ETH per PXP/PSI2 pair. Maximum 12 PXP in PCU. ETH can be 100/1000
Mbps.
***** The number can be reached when Huge BSC is unrestricted (refer to
Chapter 6 BSC planning steps and rules).
******{26638} 1 Gb ETH per PXP from the PMC front panel of the U-DPROC2.
Maximum 12 PXP in PCU, Gb ETH can be 100/1000 Mbps auto negotiation.
Table 8-6 Recommended maximum BSS parameter values (part B)

Network Element
Network Parameter
Maximum Value
BSS (BTS)
GPRS/EGPRS carriers per

cell
12/21* /24**
BSS (BTS)
Timeslots per carrier (GSM,

GPRS and EGPRS)
BSS (BTS)
Users per timeslot in each

direction
BSS (BTS)
Timeslots per active user

DL
BSS (BTS)
Timeslots per active user

UL
2 or 4
BSS (BTS)
GPRS/EGPRS timeslots per

cell (total of switchable and
reserved)
BSS (BSC)
PCU per BSC
30
1
Continued
8-16
68P02900W21-T
Jul 2010
Table 8-6 Recommended maximum BSS parameter values (part B) (Continued)

Network Element
Network Parameter
BSS (PCU)

processed at any instance in
time (with redundancy for
PRP/PICP configuration).
prp_fanout_mode1 - 30 * 8 = 240

processed at any instance
in time (with redundancy
for PXP configuration).
Total air interface timeslots

(with redundancy for
PRP/PICP configuration)

(with redundancy for PXP
configuration)
prp_fanout_mode1 - 280 * 11 = 3080

processed at any instance
in time (for PRP/PICP
configuration)

time (for PXP configuration)
Total air interface

timeslots (for PRP/PICP
configuration)
prp_fanout_mode1 - 120 * 9 = 1080

(for PXP configuration)
prp_fanout_mode1 - 280 * 12 = 3360
BSS (PCU)
BSS (PCU)
BSS (PCU)
BSS (PCU)
BSS (PCU)
BSS (PUCK)
BSS (PCU)
Maximum Value
See Figure 8-3.
prp_fanout_mode2 - 140 * 11 = 1540

See Figure 8-6.
See Figure 8-3.
prp_fanout_mode2 - 140 * 11 = 1540

See Figure 8-6.
See Figure 8-4.
prp_fanout_mode2 - 140 * 12 = 1680

See Figure 8-7.
See Figure 8-4.
prp_fanout_mode2 - 140 * 12 = 1680

See Figure 8-7.
NOTE
* Maximum when all carriers at a BTS are EGPRS enabled.
** If VersaTRAU feature is unrestricted then the maximum number of carriers

when all carriers at the BTS are EGPRS enabled can be 24.
For the mixed configuration using PXP as well as PRP, the parameter values are the capacity
combination of PRP and PXP.
In the field environment, there are two key statistics, CPU_Usage and PRP_LOAD, which
further help in optimizing the PRP/PXP planning. These statistics are collected for an extended
amount of time (representative of peak hour, during holidays, and so on) such that the traffic
patterns can be studied and the PRP/PXP planning can be optimized.
68P02900W21-T
8-17
Jul 2010
CPU_USAGE
Observing the CPU utilization of all PRP/PXPs in the PCU is an important avenue in determining
whether the boards are overloaded. In a system with multiple PRP/PXPs, the load is balanced
across all PRP/PXPs and the CPU utilization is also similar. If the CPU utilization on any of the
PRP/PXPs exceeds 90% (mean usage) during peak hours consistently, add a PRP or PXP in a PCU.
Some factors affect the CPU_Usage largely, such as fanout mode, board type and service
mix. Compared to fanout mode 2, more CPU_Usage can be seen in fanout mode 1, as more
mobiles/TBF require to be scheduled (rolling blackout is called). By using U-DPROC2 as PRP,
which has more processing power, the CPU usage can decrease considerably.
{26638} In the Gb over IP feature, the U-DPROC2 is configured as a PXP with an Ethernet GBL
configured on it. The PPROC CPU usage is critical as it carries both Gb traffic and GDS traffic.
If the CPU utilization on the PPROC exceeds 70% (mean usage) during peak hours on consistent
basis, the general rule of planning the GBL is to add a new Ethernet GBL to carry the Gb traffic.
PRP_LOAD
This statistic is used to determine the actual load on the PRP and to understand the traffic
patterns in the system. This statistic reports a mean value by default. In order to determine
a change in traffic volume over time, it is important to configure the individual bins to get a
finer resolution on the traffic.
The value of this parameter is relevant to PRP/PXP fan out mode 1. For fanout mode 2, the
value is always less or equal to 100.
For the PRP on the DPROC, it is recommended that PRP_LOAD does not exceed a mean of
100 during the busy hour when QoS is critical. A mean value greater than 100 implies that
more than 30 TS are pending service, indicating that the throughput is non-optimal. However,
PRP_LOAD mean figures of 101-160 are acceptable if the traffic density per PDTCH on a
cell level is moderate.
For a MEAN PRP_LOAD exceeding 160, consider adding a PRP. Maintaining a MEAN
PRP_LOAD over 160 results in poor throughput for the end-users as well as the trigger of
rebalancing of cells across PRPs.
For the PRP on U-DPROC2, the CPU usage may be low even at high PRP_LOAD. High PRP_LOAD
value implies the operator can see non-optimal throughput. The same guideline as described
for DPROC PRP is recommended.
For the PXP, the field data is required for the analysis of the right value of PRP_LOAD for
PXP planning.
8-18
68P02900W21-T
Jul 2010
Table 8-7 Recommended maximum BSS network parameter (part C)

Network Element
Network Parameter
Maximum Value
GBL links (E1s)
Maximum per PCU
4 (GPRS only), 12 (PICP)

or 36 (PXP)*
GBL links (ETHs)
Maximum per PCU
12
T43 boards
Maximum per PCU
4
8**
Cable harnesses
To connect 4 x T43 sites
Gb frame relay frame

octet size
Maximum
1600 bytes***
NOTE
* Maximum number when EGPRS supported carriers are being employed.
** For high capacity PCUs, where more than 24 E1s are needed, it is necessary
to add a second T43 patch panel to the PCUs. This number is less if VersaTRAU
is unrestricted and not all EGPRS carriers are provisioned with a backhaul of
8 DS0s, and PRPs are used.
*** If the Gb interface used is Ethernet/IP, the maximum IP packet octet is

suggested as 1500 bytes.
The fact that all of the timeslots of a cell are allocated to the same PRP or PXP board affects
the total number of air interface timeslots supported by the PCU. Allocation of a part of the
GPRS/EGPRS timeslots for a cell to one PRP/PXP and another part of the GPRS/EGPRS timeslots
of the same cell to a different PRP/PXP is not supported. This fragmentation of the cells across
PRP and PXP boards result in not all GPRS/EGPRS timeslots for a cell being assigned to a
PRP/PXP and may even result in not all cells being assigned to a PRP/PXP. When planning
the BSS, if the number of GPRS+EGPRS timeslots in the BSS does not exceed max_GPRS or
max_EGPRS TSg, all GPRS/EGPRS timeslots of all cells are assigned to a PRP or PXP.
If prp_fanout_mode = 1:
max GPRS/max EGPRS TSg = (nPRP * 120) + (mPXP * 280) - max_GPRS_TS_cell
If prp_fanout_mode = 2:
max GPRS/max EGPRS TSg = (nPRP * 48) + (mPXP * 140) - max_GPRS_TS_cell
68P02900W21-T
8-19
Jul 2010
Where:
Is:
max_GPRS/max_EGPRS
TSg
maximum number of GPRS/EGPRS timeslots per PCU

guaranteed to be assigned to a PRP.
nPRP
number of PRP boards in the PCU.
mPXP
number of PXP boards in the PCU.
max_GPRS_TS_cell
number of GPRS/EGPRS timeslots in the cell in the

BSS with the most GPRS timeslots.
prp_fanout_mode
a database parameter indicating the options of PRP

fanout in the PCU. All the PRP/PXPs should have the
same PRP fanout mode.
E1 cable requirements for a fully configured PCU

Each PCU needs at least one interconnection panel, located on the PCU cabinet, which contains
up to 4 x T43 boards. To support a maximum of 24 E1 s for a fully configured PCU, 4 x T43
boards require to be populated.
With EGPRS carriers, if the number of E1s is greater than 24 then a second interconnect panel
can be added.
The number of T43 boards in the second interconnect panel is dependent on the number of E1s
required.
A cable harness is staged with the PCU containing 18 E1 RJ45 to RJ45 cables.
Cage a second cable harness to hold an extra 6 E1 RJ45 to RJ45 cables.
ETH cable requirements for a fully configured PCU

Every PXP board uses an ETH RJ45 port in the RTM. The port uses a standard Category 5e patch
cable. Use the cable for direct connection between BSC and PCU and no longer than 100 m.
{26638} If the ETH is configured for the IP-based GBL, each PXP board uses the ETH port in the
PMC front panel of the U-DPROC2 board. The port is ETH RJ45 and uses a standard Category 5e
patch cable. The cable can be used for direct or indirect connection between the PCU and SGSN.
NOTE
Limit the Cat 5e cable to a maximum distance of 100 m (328 ft) for the Ethernet
network direct connection.
8-20
68P02900W21-T
Jul 2010
PCU hardware layout
PCU hardware layout
There is one PCU per BSS. Figure 8-3 shows the PCU shelf layout.
Figure 8-3 PCU shelf layout

Default LAPD Link To BSC
1
10 11
D
P
R
O
C
D
P
R
O
C
D
P
R
O
C
D
P
R
O
C
D
P
R
O
C
D
P
R
O
C
M
P
R
O
C
M
P
R
O
C
D
P
R
O
C
12 13 14
D
P
R
O
C
D
P
R
O
C
15 16
D
P
R
O
C
D
P
R
O
C
D
P
R
O
C
D
P
R
O
C
R
T
M
D
P
R
O
C
R
T
M
Default LAPD Link To BSC

16
D
P
R
O
C
R
T
M
15 14
D
P
R
O
C
R
T
M
D
P
R
O
C
R
T
M
13 12
D
P
R
O
C
R
T
M
D
P
R
O
C
R
T
M
11 10
D
P
R
O
C
R
T
M
H
S
C
A
M
P
R
O
C
B
R
T
M
H
S
C
B
M
P
R
O
C
A
R
T
M
D
P
R
O
C
R
T
M
D
P
R
O
C
R
T
M
D
P
R
O
C
R
T
M
D
P
R
O
C
R
T
M
ti-GSM-PCU_shelf_layout-00135-ai-sw
NOTE
68P02900W21-T
DPROC in Figure 8-3 includes two hardware types: U-DPROC2 and DPROC.
RTMs are used for DPROCs and P (packet) RTMs for U-DPROC2s. Old and new
RTMs are incompatible, and must match the DPROC type installed in the slot
on the front of the shelf. the U-DPROC2 transition module has 2 GbE ports
(the ETH ports).
If the IP based GBL ETH is configured, the ETH port is from the PMC front
panel of the U-DPROC2/PXP.
Any of the two available default LAPD link slots is used.
8-21
Jul 2010
PCU shelf (cPCI)
PCU shelf (cPCI)
Introduction
The PCU cabinet can hold up to three PCU (cPCI) shelves; only two PCU shelves can be fitted
when EGPRS is used. Each PCU is connected to only one BSC.
Each cabinet is pre-wired with a panel in the rear of the cabinet for the desired E1 termination
type, balanced 120 ohm, or unbalanced 75 ohm terminations with 1500 volt lightning protection
per E1.
Consider the following factors when planning the cPCI complement:
The maximum number of timeslots that can be processed at any instance in time per PCU
in the fully redundant configuration (refer Table 8-5 to Table 8-7)
The maximum number of total timeslots that can be provisioned per PCU in the fully
redundant configuration (refer Table 8-5 to Table 8-7).
Three fan/power supply units per cPCI shelf provide N+1 hot-swap redundancy. If a power
supply unit is not fitted, a minimum of two power supply units are required, with a fan-only
unit required in the third location.
One air filter per fan/power supply unit is required (Total of 3 per PCU).
Each PCU cPCI shelf needs two MPROC boards for redundancy. MPROC redundancy is
not required for normal PCU operation, but is necessary for the PCU to achieve high
availability.
Each MPROC board needs one bridge board and one transition module for a redundant
MPROC configuration, or if the Web MMI feature is enabled.
One alarm board per PCU is required.
One main circuit breaker panel per PCU is required.
There are four bays on the right side of the shelf. These shelves can be used for auxiliary
equipment such as tape drives, CD-ROM drives, and hard disks. The PCU is configured
without any auxiliary equipment. This area of the shelf is covered with blank panels.
Table 8-8 Maximum number of timeslots that can be processed
8-22
Board
prp_fanout_mode = 1
prp_fanout_mode = 2
DPROC/PRPs or
U-DPROC2/PRPs
30 * 8 = 240
48 * 8 = 384
U-DPROC2/PXPs
70 * 11 = 770
140 * 11 = 1540
68P02900W21-T
Jul 2010
Table 8-9
Maximum number of timeslots that can be provisioned
Board
prp_fanout_mode=1
prp_fanout_mode=2
DPROC/PRPs or
U-DPROC2/PRPs
120 * 8 = 960
48 * 8 = 384
U-DPROC2/PXPs
280 * 11 = 3080
140 * 11 = 1540
NOTE
68P02900W21-T
If E1 connectivity is used, additional T43 modules and interconnect cables are

required for the PCU cage. These cables support 18 GDS TRAU links for GPRS
and 36 GDS TRAU links for EGPRS.
If ETH connectivity is used, no additional interconnects are required for GDS. If

more than 24 Gb E1 links are required use additional interconnects.
8-23
Jul 2010
MPROC board
MPROC board
Introduction
The PCU planning process determines the type and number of MPROC boards to populate
in the PCU. The PCU provisioning requirements take the MPROC redundancy solution into
consideration.
PSP planning considerations

The MPROC board is used for PSP purposes. The PSP is the PCU system processor, which is
a master system processor board. The PSP controls compact PCI bus synchronization and
arbitration. It also performs centralized configuration and fault handling for the PCU site.
If MPROC redundancy is required, each PCU cPCI shelf requires two MPROC cards (boards).
Enable the MPROC redundancy flag specified during the equipping of the PCU. Insert the
MPROC cards in slot 7 and 9 (see Figure 8-2). An MPROC (PSP 0) card is inserted into slot 7
and the other MPROC (PSP 1) is inserted into slot 9. The MPROC (PSP 0) in slot 7 is paired with
a hot swap controller/bridge module in slot 10. The MPROC (PSP 1) in slot 9 is paired with a hot
swap controller/bridge module (HSC) in slot 8.
If no redundancy is required, insert only one MPROC card in either slot 7 or 9 of the PCU cage.
Disable the MPROC redundancy flag specified during the equipping of the PCU. The MPROC
(PSP 0) in slot 7 is paired with a hot swap controller/bridge module in slot 10. Also MPROC
(PSP 1) in slot 9 can be paired with a hot swap controller/bridge module (HSC) in slot 8. If both
MPROCs are present but redundancy is not desired or the equip flag is disabled, then the
MPROC in slot 7 is the primary MPROC and is responsible for powering off the MPROC in slot 9.
In this case, the MPROC in slot 9 is considered transparent.
The MPROC card is a Motorola MCP820 or MCP750 microprocessor board with a TMCP700
transition module.
8-24
68P02900W21-T
Jul 2010
DPROC board
DPROC board
Introduction
The PCU planning process determines the type and number of DPROC boards to populate in the
PCU. The PCU provisioning requirements use the number of GPRS timeslots as the planning
rule input. The estimation process for determining the number of GPRS timeslots is provided in
GPRS/EGPRS network traffic estimation and key concepts on page 3-74 in Chapter 3 BSS cell
planning.
PICP or PRP planning considerations

DPROC board slots can be used for either PICP or PRP purposes. Each DPROC has an E1
transition module mounted in the rear of the shelf directly behind it.
A DPROC can be configured as a PICP with zero, one, or two E1 PMC modules, and with PICP
software. The DPROC can be configured as a PRP with either one or two E1 PMC modules, and
with PRP software. The cPCI shelf supports a total of 16 cards. The redundancy MPROC boards
with bridge capability occupy four slots, leaving 12 slots for PICPs or PRPs.
For system availability reasons, distribute the PICPs and PRP boards evenly between the two
backplanes within the PCU shelf. Populate the PICP/PCP provisioned boards from left to right.
Connect the left and right backplanes together through the bridge board located behind the
MPROC processor board. Therefore, the first PICP would occupy board slot 1, PICP 2 would
occupy board slot 11, PICP 3 would be in slot 2 and PICP 4 in slot 12.
Perform the PRP provisioning also in a similar fashion, alternating provisioned boards between
the left and right backplanes.
PICP board
Consider the following factors when planning the complement PICP board:
The PCU can support up to four PICP boards.
A PICP board supports a maximum of two PMC modules or MSIs.
The PICP boards can terminate the following links: LAPD-Type GDS links (GSL), and E1 Gb
links (GBL). But GSL and GBL cannot be resident in the same MSI.
PRP board
Consider the following factors when planning the complement PRP board:
68P02900W21-T
The PCU can support up to 10 PRP boards with the recommended maximum being 9 PRP
boards. When 9 PRP boards are populated, there are three slots available for the PICP
boards.
8-25
Jul 2010
PRP boards with PMCs can terminate one GDS TRAU E1 per PMC module for GPRS and
two GDS TRAU E1s. This is possible when configured exclusively with EGPRS carriers.
The PRP boards cannot terminate GDS LAPD E1 links (GSL) or Gb E1 links (GBL).
Each PRP board must terminate at least one GDS TRAU E1. A PRP board that does
not terminate any GDS TRAU E1s has no function (PRP is always OOS when no GDS
is equipped, or PRP loses normal function when all associated GDSs are OOS). All PDs
handled by a PRP require to be using GDS terminated on the same PRP board.
Up to 120 air timeslots can be terminated on one PRP in prp_fanout_mode1 or up to 48

air timeslots can be terminated on one PRP in prp_fanout_mode2.
In prp_fanout_mode1, the maximum number of air timeslots that can be assigned to a

PRP is 120. The number of air timeslots that can be served at a given time interval is 30.
The timeslot assignment to available PRP is load balanced by software which attempts to
equally distribute the timeslots across PRPs.
In prp_fanout_mode2, the maximum number of air timeslots that can be assigned to a

PRP is 48. All the timeslots provisioned by a PRP can be served at any given time interval.
The timeslot assignment to available PRP is load balanced by software which attempts to
equally distribute the timeslots across PRPs.
NOTE
The actual distribution of timeslots can be slightly different from that shown
here depending on cell configurations. For example, all timeslots for a single
cell must terminate on a single PRP, which can lead to slight imbalances when
multiple timeslots are configured per cell.
The actual distribution of timeslots is also depended on Cell Balance (CB)

Algorithm. The CB algorithm allocates air timeslots based on configuration, PRP
capacity, load, and related TRAU GDS resource. Sometimes when the planned
number of air timeslots or GDS resource is close to the maximum capacity
of the PRP and its GDS, the PRP may not reach its maximum capacity with
non-optimum configuration. The adequacy and evenly distribution of TRAU GDS
is recommended to reduce the possibility. Or an additional PRP is needed.
A PRP board supports up to two PMC modules.
PRP planning
The general guidelines dictate the maximum capacity of the PRP at 120 TS per board. There
are two key statistics, CPU_Usage, and PRP_LOAD, which further help in optimizing the
PRP planning. These statistics are collected for an extended amount of time (representative
of peak hour, during holidays, and so on) such that the traffic patterns can be studied and
the PRP planning can be optimized.
CPU usage
Observing the CPU utilization of all PRPs in the PCU is an important means in determining
whether the boards are overloaded. In a system with multiple PRPs, the load is balanced across
all PRPs and the CPU utilization is similar as well. If the CPU utilization on any of the PRPs
consistently exceeds 90% (mean usage) during peak hours, consider adding a PRP in a PCU as
a general rule.
8-26
68P02900W21-T
Jul 2010
This statistic reports three values for a given time interval - MIN, MAX, and MEAN. Although the
MAX value can reach 100%, (for a fraction of a second at a time), this condition should never
be used as the criteria for the load on the board. In fact, the MEAN value should be the only
indicative of the PRP utilization. In addition, consider several days worth of data (or even
weeks) to make a consistent decision. CPU utilization plots versus time can help observe a
pattern in increased CPU utilization.
NOTE
With QoS enabled, the CPU utilization of DPROC increases. The level of increase is
dependent on the traffic split between DL and UL (higher with symmetrical), type
of backhaul (higher with 32k backhaul) and the number of cells mapped to DPROC.
It is recommended to monitor the DPROC CPU utilization and in events where CPU
is consistently higher than 90% (mean usage), then either add more PRPs to the
distribute load or replace DPROC with U-DPROC2. It is also recommended to add
U-DPROC2 instead of DPROC and configure as PXP instead of PRP since U-DPROC2
has more power than DPROC and PXP configure has much bigger capacity than
PRP configure. If there is no room in a PCU to add new board, replace DPROC with
U-DPROC2 and configure as PXP.
PRP load (modified per service pack 1670.27t1)

This statistic can be instrumental to determine the actual load on the PRP and help to
understand the traffic patterns in the system. For instance, when the majority of the GPRS
traffic is signaling (primarily attach/detach, PDP Context Act/Deact, Cell Update, and RAUs)
the PRP_LOAD is expected to be low. A PRP handling GPRS signaling traffic is expected to
produce a PRP_LOAD value in the range of 5-10. However, the PRP_LOAD is higher when
the PRP handles actual data transfer (WAPs, FTPs, and so on).
This statistic reports a MEAN value by default. However, to determine a change of traffic
volume over time when QoS is critical, it is important to configure the individual bins to get a
finer resolution on the traffic. A mean value greater than 100 implies that more than 30 TS are
pending service, which generally indicates a non-optimal throughput. However, PRP_LOAD
MEAN figures of 101-160 can be acceptable if the traffic density per PDTCH on a cell level is
moderate. A traffic density per PDTCH is considered moderate good throughputs.
For a MEAN PRP_LOAD exceeding 160, consider adding a PRP. Maintaining a MEAN
PRP_LOAD over 160 results in poor throughput for the end-users as well as the trigger of
rebalancing of cells across PRPs.
PDTCH planning
As a general guideline for a new network, configure at least 4 PDTCH/cell on the BCCCH
carrier. This action optimizes the throughput of multi-slot mobiles that are capable of 4 TS on
the DL (downlink). Configuring more than 4 TS/cell normally, assumes the expectancy of high
volumes of actual data traffic and the planning guidelines described in the previous chapter
(Chapter 3 BSS cell planning) apply.
However, if most of the traffic is signaling (attaches/detaches, PDP Context Act/Deact, Cell
Updates, RAUs), monitor the several statistics to determine whether the addition of PDTCHs in
a cell is required. In networks where GPRS subscriber base is widely enabled but the general
data usage per subscriber is low, special consideration is required. The following statistics are
useful in determining the PDTCH requirements for a cell.
68P02900W21-T
8-27
Jul 2010
PXP planning considerations
DL_BUSY_PDTCH
This statistic measures the MEAN, MAX, and MIN number of occupied PDTCH carrying
downlink packet traffic. Normally, observing the MEAN value should be indicative of how the
PDTCHs are utilized in the cell. For a more detailed PDTCH occupancy distribution, this statistic
can also be configured to report ten bins. By default, bin 0 is pegged every block period (20
ms) when no TBFs are allocated on any of the PDTCHs on the cell. Bin 1 is pegged when 1 to 2
PDTCHs are busy; bin 2 is pegged when 3 to 4 PDTCHs are busy, and so on. For example, a cell
configured with 10 PDTCHs, with a MEAN value reported as 9.2 implies that all 10 configured
PDTCHs are being utilized. However, if the MEAN is 5, the configured PDTCHs are probably
under utilized and the number of PDTCHs can be reduced. Before reducing the number of
PDTCHs, evaluate the other statistics first.
AVAILABLE_PDTCH
This statistic enables optimization of the number of switchable versus reserved TSs in a cell.
If the busy hour of voice traffic does not interleave with GPRS busy hour, some TS can be
configured as switchable, carrying voice traffic during CS busy hour and data traffic during
GPRS busy hour.
Example:
8 of 10 TSs are configured as switchable in a cell.
The DL_BUSY_PDTCH reports a MEAN of 5.
This example illustrates a condition where TSs are stolen to handle voice traffic and therefore
needs the addition of TSs to this cell to handle the GPRS traffic.
NO_PDTCH_AVAIL
This statistic is pegged in extreme conditions when the last switchable TS are stolen for a voice
call. This condition indicates that GPRS service is not available at this time on the cell and needs
a reconfiguration of switchable versus reserved TS, or the addition of TS in the cell.
GBL_DL_DATA_THRPUT
The planner shall compare this statistic with the SGSN statistic to determine the actual data
sent across the network that does not result from signaling traffic.

U-DPROC2 boards are inserted in DPROC slots, which can be used for PICP, PRP or PXP
purposes. DPROC board can be referred to when U-DPROC2 board is configured as PRP or
PICP. The U-DPROC2 board has exactly one E1 module (not configurable). It supports up to 4
E1 links providing the same connectivity as the DPROC board with 2 E1 PMC modules. The
software automatically maps E1 PMC modules and span identifiers onto the correct spans
of the U-DPROC2 board.
When a U-DPROC2 board is configured as PXP, and the Gb over IP feature is restricted or
disabled, it has one ETH connection for the GDS (GSL and TRAU Frame), and can be used to
connect up to 3 E1 cables for Frame relay Gb connections.
8-28
68P02900W21-T
Jul 2010
When a U-DPROC2 board is configured as PXP and the Gb over IP feature is unrestricted
and enabled, it can use the U-DPROC2 PPROC ETH port for IP-based GBL. This ETH port is
connected from the U-DPROC2 PMC front panel to the SGSN or IP backbone. Each PXP can
support only 1 Gb ETH port for the GBL.
Each PXP board must terminate only one GDS TRAU. A PXP board that does not terminate any
GDS TRAU has no PRP function (PXP is always in OOS status and the GBL cannot be INS
when no GDS is equipped).
When the PXP ETH port carries Gb traffic, the CPU_usage of the PPROC is expected to increase
due to the increased throughput. The throughput capacity of the Ethernet GBL is determined by
the PPROC average CPU usage not exceeding 70% and assumption of 2:1 peak/mean throughput
ratio. Thus, one Ethernet GBL on the PXP board can provide the average throughput of 5 Mbps
in downlink and 1.5 Mbps in uplink for prp_fanout_mode 1, and 4.9 Mbps in downlink and 1.4
Mbps in uplink for prp_fanout_mode 2. Therefore, the traffic model of 4:1 ratio of Downlink
load/uplink load can be supported.
The cPCI shelf supports a total of 16 cards. The redundant MPROC boards with bridge
capability occupy 4 slots, leaving 12 slots for PXPs, PRPs, and PICPs. To describe the maximum
configuration, it is assumed that only PXPs are used.
Up to 280 air timeslots can be terminated on one PXP in prp_fanout_mode1. The number of
air timeslots that can be served at a given time interval is 70. The assignment of timeslot to
available PXP is load balanced by software.
Up to 140 air timeslots can be terminated on one PXP in prp_fanout_mode2. All the timeslots
provisioned by a PXP can be served at any given time interval. The timeslot assignment to
available PXP is load balanced by software.
NOTE
68P02900W21-T
The actual distribution of timeslots can be slightly different from that shown
here depending on cell configurations, that is, all timeslots for a single cell must
terminate on a single PXP, which can lead to slight imbalances when multiple
timeslots are configured per cell.
The actual distribution of timeslots is also depended on Cell Balance (CB)

Algorithm. The CB algorithm allocates air timeslots based on configuration, PXP
capacity, load, and related GDS resource (tdm_ts_bloacks). Sometimes when the
planned number of air timeslots or GDS resource is close to the maximum limits,
the PXP may not reach its maximum capacity with non-optimum configuration.
The adequacy GDS resource is recommended to reduce the possibility. Or an
additional PXP is needed.
The statistics used for PRP planning are also applied for PXP planning.
8-29
Jul 2010
PMC module
PMC module
Introduction
The number of PMC modules installed depends on the number of PICP /PRP configured boards
in the PCU.
For the PXP (U-DPROC2), one E1 PMC module is always attached and there is no require to
further consider the number of E1 PMCs fitted.
Consider the following factors when planning the PMC complement for the DPROC board:
Each PRP board needs at least one PMC module.
Each PICP board has up to two PMC modules. TRAU-type GDS terminate on a PMC module
in a PRP board. LAPD-type GDS (GSL) and Gb E1 (GBL) links terminate on a PMC module
in PICP board and cannot share a PMC module.
For GPRS, only one TRAU-type GDS per PMC module on a PRP board is allowed. The other
E1 termination on the PMC module cannot be used. For EGPRS, the PRP can support two
PMC modules when configured with EGPRS air timeslots, each with up to two TRAU-type
GDS links.
Up to 2 Gb E1 links (GBL) per PMC module are allowed.
Up to 2 LAPD-type GDS E1 (GSL) links per PMC module are allowed.
On the PMC NIB, the PCU can support an arbitrary mixture of 124-16 kbps TRAU, 62-32
bit/s TRAU and 62-64 kbps (each individual DS0 that is part of a Versachannel is a single
64 kbps TRAU channel) TRAU such that the following equation is satisfied:
#16 kbps TS + (2 x #32 kbps TS) + (2 x 64 kbps DS0s) < 124
For VersaTRAU carriers (pkt_radio_type = 3), there is no one-to-one correlation between the
number of air timeslots and the number of DS0s required on the backhaul so use the number of
DS0s in the equation.
The PMC NIB has sufficient CPU capacity to support a 124-16 kbps TRAU or one full span.
Since 32 kbps TRAU is composed of two 16 kbps TRAU channels, the PMC NIB can support
half as many 32 kbps TRAU, or one full span. With the channelized subrate insert/extraction
removed in the 64 kbps (VersaTRAU) TRAU, the PMC NIB can achieve 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 combination of 16 kbps and 64 kbps (VersaTRAU) TRAU channels, or
channels with channelized subrate insertion/extraction and those without, trading off at a ratio
of two 16 kbps timeslots to one 64 kbps timeslot. When mixed traffic is used, the two spans on
the PMC NIB are not fully utilized.
8-30
68P02900W21-T
Jul 2010
(Packet) Rear Transition Module
(Packet) Rear Transition Module
Introduction
The number of rear transition modules installed depends on the number of PICP/PRP/PXP
boards configured in the PCU.
Consider the following factors when planning the number of rear transition modules required:
One rear transition module is required per PRP board.
One rear transition module is required per PICP board.
One packet rear transition module is required per PXP board.
The rear transition module type must match the board type used in the corresponding card
slot in the front of the shelf.
68P02900W21-T
8-31
Jul 2010
PCU equipment redundancy and provisioning goals
PCU equipment redundancy and provisioning goals
Support for equipment redundancy

The PCU supports four types of redundancy:
2N
1MPROC/bridge board pair (non-redundant), 2 MPROC/bridge board pairs (redundant).
N+1
E1 or IP-based GBL, 2PS/FAN units (non-redundant), 3 PS/FAN unit (redundant). Use 3
fan units.
Load shared
The signaling data on the GSL and GBL are load shared across the available links.
Provisioning more links than is required in the event of a failure creates seamless
redundancy. The GSL and GBL use a routing algorithm to dynamically balance the load
across all available links. The individual GSL and GBL links can be distributed across
the available PICPs/PXPs. If a PICP/PXP fails, the remaining PICP(s)/PXP(s) if equipped
will process the signaling load.
With the {26638} Gb over IP feature unrestricted and enabled, the PCU distributes the NS
SDUs traffic in equal proportion to the relative weights among the available IP endpoints
on the Gb interface (GBL/NSVC). The use of weighted load sharing also provides the upper
layer seamless service upon failure by re-negotiating the NS SDU traffic between the
remaining IP endpoints. Each NSE uses the weighted load sharing function to determine
the local IP endpoint associated with all NS SDU traffic related to an MS. The remote IP
endpoint is initially determined by the load sharing function that distributes the traffic in
equal proportion to the relative weights assigned to endpoints of the peer NSE.
Load balanced
The air timeslots on the GDS links are terminated on a PRP/PXP board. The PCU
automatically balances the number of air timeslots across the available PRP/PXPs. If a GDS
link fails, the BSC and PCU attempt to move the air timeslots to another available GDS
link. If a PRP/PXP fails, all the air timeslots on the failed PRP/PXP are moved to other
PRP/PXPs if adequate resources are available.
PCU equipment redundancy planning

Three configurations are supported: PRPs/PICPs, PXPs only, or a combination of PRP/PICP
and PXPs.
8-32
68P02900W21-T
Jul 2010
PRP/PICP configure
PRP/PICP configure
For redundant PCU operation, plan the PCU such that there are sufficient boards provisioned as
shown in Figure 8-4, that is, only eight PRP boards and two PICP boards are required to handle
the expected maximum GPRS traffic load. The ninth PRP board and third PICP board offer the
extra capacity to provide redundancy in the event of a PRP or PCIP failure. The third PICP board
provides redundancy for the software processes that run on the first two PICP boards.
The GDS TRAU E1 (GDS) link redundancy is obtained by calculating the number of PRP boards
required and then adding an additional PRP board. The GSL E1 link redundancy is obtained by
provisioning a second GSL E1. The PCU load-balances across the LAPD GSL links. If a PRP or
PICP board fails, the PCU automatically re-distributes the load to the other boards in service.
Two Gb E1s (GBL) are required to handle the traffic for a fully configured PCU. Gb E1 link
resiliency is obtained by adding an additional two Gb E1s and load balancing across all of the Gb
E1s. The number of GBLs is increased to 12 per PCU when EGPRS carriers are equipped.
The PRP and PICP (DPROC) boards are hot swappable so that when a board failure is detected,
a replacement board may be inserted without disrupting ongoing GPRS traffic on the other
boards. Lock the DPROC before removal and unlock after board insertion. The PRP and PICP
boards have associated transition module boards. There is an associated redundant transition
module board with each redundant PRP and PICP board.
The PCU shelf hardware allows for N+1 MPROC board redundancy. This N+1 redundancy
capability is subject to MPROC redundancy software availability. The MPROC board(s) and the
MPROC bridge boards are not shown in Figure 8-4 or Figure 8-5, but the redundant MPROC
has an associated redundant bridge board.
The PCU shelf comes with N+1 power supply/fan redundancy. The power supplies are hot
swappable. The power supply/fan units are not shown in Figure 8-4 and Figure 8-5.
The PCU architecture offers a considerable degree of provisioning flexibility. Figure 8-4 and
Figure 8-5 demonstrate this flexibility where the provisioning goals range from full redundancy
(as shown in Figure 8-4) to maximum coverage (as shown in Figure 8-5 for GPRS and Figure 8-6
for EGPRS).
Table 8-10 summarizes the provisioning goals demonstrated with Figure 8-4, Figure 8-5, and
Figure 8-6.
68P02900W21-T
8-33
Jul 2010
PRP/PICP configure
Figure 8-4 Provisioning goals (full redundancy)

124@16K / GDS TRAU
CHANNEL
BSC
GDS
GDS
PMC
PRP1
SGSN
mode1: 30/120
PMC mode2: 48/48
.
To .
.
GDS
GDS
GDS
GDS
GSL
PMC
PRP8
mode1: 30/120
PMC mode2: 48/48
PMC
PMC
PMC
PMC
PRP9
mode1: 30/120
mode2: 48/48
P1 CP1
30 LAPD
TS MAX
GBL
Redundant
GSL
PMC
PMC
P1 CP2
30 LAPD
TS MAX
Redundant GBL
PMC
PMC
P1 CP2
30 LAPD
TS MAX
Redundant GBL
ti-GSM-Provisioning_goals_full_redundancy-00136-ai-sw
Refer to Table 8-10 for a matrix of provisioning goals achieved with this instance of PCU
provisioning.
8-34
68P02900W21-T
Jul 2010
Figure 8-5
PRP/PICP configure
Provisioning goals (Maximum coverage)
124@16K / GDS TRAU

CHANNEL
BSC
GDS
GDS
GDS
GDS
PMC
PRP1
PMC
PRP2
SGSN
mode1: 30/120
PMC mode2: 48/48
mode1: 30/120
PMC mode2: 48/48
To
GDS
GDS
GSL
PMC
PRP9
mode1: 30/120
PMC mode2: 48/48
PMC
PMC
P1 CP1
30 LAPD
TS MAX
GBL
Redundant
PMC
GSL
PMC
P1 CP2
30 LAPD
TS MAX
Redundant GBL
ti-GSM-Provisioning_goals_Maximum_coverage-00137-ai-sw
provisioning.
NOTE
Figure 8-5 shows 18 GDSs, as required for CS3/CS4. Only 9 GDSs are required for
CS1/CS2.
68P02900W21-T
8-35
Jul 2010
PRP/PICP configure
Figure 8-6 EGPRS maximum throughput and coverage, full redundancy not required
124@16K / GDS TRAU
CHANNEL
EGPRS
BSC
GDS
GDS
PMC
PMC
To
EGPRS
GDS
EGPRS
GDS
GDS
GDS
SGSN
PRP1
mode1: 30/120
mode2: 48/48
.
.
.
PMC
PRP8
PMC
mode1: 30/120
mode2: 48/48
PMC
PRP9
PMC
mode1: 30/120
mode2: 48/48
PMC
PMC
P1 CP1
30 LAPD
TS MAX
GBL
PMC
PMC
P1 CP2
30 LAPD
TS MAX
GBL
GBL
PMC
P1 CP3
PMC
GBL
ti-GSM-EGPRS_maximum_throughput_and_coverage_full_redundancy_not_required-00138-ai-sw
NOTE
The number of GDS links per PRP is decreased to 2 for PRP fanout mode 2.
provisioning.
Table 8-10 Provisioning goals (per PCU)

Metric
Goal
GPRS maximum
coverage with
redundant
configuration
(Figure 8-4).
GPRS maximum
coverage, redundancy
not required
(Figure 8-5).
EGPRS maximum
coverage,
redundancy not
required
(Figure 8-6).
Continued
8-36
68P02900W21-T
Jul 2010
PRP/PICP configure
Table 8-10 Provisioning goals (per PCU) (Continued)

Metric
Goal
Number of timeslots
processed at any
instance in time
Mode 1: 240(30*8)
Mode 1: 270(30*9)
Mode 1: 270(30*9)
Mode 2: 384(48*8)
Mode 2: 432(48*9)
Mode 2: 432(48*9)
Total number
of provisioned
timeslots at a BSS
Mode 1: 960(120*8)
Mode 1: 1080(120*9)
Mode 1: 1080(120*9)
Mode 2: 384(48*8)
Mode 2: 432(48*9)
Mode 2: 432(48*9)
Number of MPROCs
Number of PRPs
Number of PICPs
Number of
TRAU-Type GDS
E1s
18
18
36**
Number of
LAPD-Type GDS
(GSL)E1s
Number of Gb E1s
MPROC board
redundancy
Yes
No
No
PRP board
redundancy
Yes
No
No*
PICP board
redundancy
Yes
No
No*
GDS TRAU E1
redundancy
Yes
No
No*
GSL E1 redundancy
Yes
Yes
Yes
Gb E1 redundancy
Yes
Yes
Yes
NOTE
68P02900W21-T
* Capacity does not meet calculated maximums in the event of a failure. This
can or cannot affect the usage dependent on the current load of the system.
** The maximum number of GDS resources can be less if VersaTRAU is

unrestricted and EGPRS carriers are equipped with less than 8 DS0s of backing
on the backhaul.
When EDGE and VersaTRAU are enabled, to ensure that sufficient GDS
resources are planned/configured for all EDGE configured cells to provide EDGE
service, GDS resources for 64 k enabled RTFs (pkt_radio_type = 3) should
be planned as follows.
8-37
Jul 2010
PXP configuration
On per 64 k carrier basis:

If the carrier backhaul configured (rtf_ds0_count) is less than or equal to
the number of 64 k PDTCH configured (including switchable TCH/PDTCH
timeslots), then the GDS DS0 requirement is rtf_ds0_count.
If the carrier backhaul configured (rtf_ds0_count) is greater than the
number of 64 k PDTCH configured (including switchable TCH/PDTCH
timeslots), then the GDS DS0 requirement is the number of 64 k PDTCHs
configured (including switchable TCH/PDTCH timeslots).
PXP configuration
For PXP configuration, an additional board is recommended for load balanced in normal
operation and for redundancy in the event of a PXP failure. For example, plan the PCU such
that there are sufficient boards provisioned as shown in Figure 8-7, that is, only 11 PXP boards
are required to handle the expected maximum GPRS traffic load. The 12th PXP board offers
the extra capacity and provides redundancy.
When PXP is configured, Ethernet connectivity is required between BSC (PSI2) and PCU (PXP).
ETH link carries both GDS TRAU and GDS LAPD. The GDS (TRAU and LAPD) redundancy is
obtained by equipping one more PXP board than the number of PXP boards required. If a
PXP board fails, the PCU automatically re-distributes the load to the other boards in service.
Equipping GSLs over different ETH links is recommended strongly.
If the Gb over IP feature is unrestricted and enabled, the GBL uses the Ethernet connectivity
between the PCU and SGSN. Equip one more PXP board for ETH Gb than the number of PXP
boards required for the N+1 redundancy purpose. If a PXP board fails, the PCU automatically
re-distributes the load to the other boards in service.
Each PXP can support three E1 links, used to transfer E1 Gb (GBL) traffic. The Gb E1 link
resiliency is obtained by adding an additional PXP and load balancing across all of the Gb E1s.
The PCU can support 36 Gb when used with full PXP configuration. The PXP boards have
associated packet rear transition module boards not shown in the figures. There is an associated
redundant packet rear transition module board with each redundant PXP board.
Each PXP can support one Ethernet Gb link used to carry ETH Gb (GBL) traffic. The Gb Ether
link resiliency is obtained by adding an additional PXP and load balancing across all the IP-based
Gb links. The PCU can support 12 Ethernet Gbs when used with full PXP configuration.
The redundancy of MPROC, power supply, and fan is the same as the description in PRP/PICP
configure on page 8-33.
The PCU architecture offers a considerable degree of provisioning flexibility. Figure 8-7 and
Figure 8-8 (Figure 8-8 is for ETH Gb), and Figure 8-9 and Figure 8-10 (Figure 8-10 is for ETH
Gb) demonstrate this flexibility where the provisioning goals range from full redundancy
(as shown in Figure 8-7 and Figure 8-8) to maximum coverage (as shown in Figure 8-9 and
Figure 8-10 for GPRS/EGPRS).
Table 8-11 summarizes the provisioning goals demonstrated with Figure 8-7and Figure 8-9.
8-38
68P02900W21-T
Jul 2010
PXP configuration
Figure 8-7 Provisioning goals (full redundancy)

GDS TRAU CHANNELS can be
GPRS or EGPRS
GDS+GSL
BSC
ETH*1
PXP1
mode1: 70/280
mode2:
140/140
PMC*2
SGSN
GBL
GDS+GSL
ETH*1
PXP2
mode1: 70/280
mode2:
140/140
PMC*2
GBL
.
To .
.
GDS+GSL
ETH*1
PXP11
mode1: 70/280
PMC*2 mode2: 140/140
GBL
Redundant
GDS+GSL
ETH*1
PXP12
mode1: 70/280
PMC*2 mode2: 140/140
Redundant GBL
*1: One ETH can support 30 GSL, and GDS TRAU is not restricted by ETH
*2: PMC supports max 3 GBLs
ti-GSM-Provisioning_goals_full_redundancy-00139-ai-sw
provisioning.
68P02900W21-T
8-39
Jul 2010
PXP configuration
Figure 8-8 Provisioning goals (maximum coverage)

GPRS or EGPRS
GDS+GSL
BSC
ETH *1
PXP1
mode1: 70/280
ETH *2 mode2: 140/140
SGSN
GBL
GDS+GSL
ETH *1
PXP2
mode1: 70/280
*2
mode2:
140/140
ETH
GBL
.
To .
.
GDS+GSL
ETH *1
PXP11
mode1: 70/280
*2
mode2: 140/140
ETH
GBL
Redundant
ETH *1
PXP12
GDS+GSL
mode1: 70/280
ETH *2 mode2: 140/140
Redundant GBL
*2: ETH on the UDPROC2 front panel
ti-GSM-Provisioning_goals_maximum_coverage-00140-ai-sw
8-40
68P02900W21-T
Jul 2010
PXP configuration
Figure 8-9 Provisioning goals achieved with instance of PCU provisioning

GPRS or EGPRS
GDS+GSL
BSC
ETH*1
PXP1
mode1: 70/280
PMC*2 mode2: 140/140
SGSN
GBL
GDS+GSL
ETH*1
PXP2
mode1: 70/280
PMC*2 mode2: 140/140
GBL
.
To .
.
GDS+GSL
ETH*1
PXP11
mode1: 70/280
mode2:
140/140
PMC*2
GBL
GDS+GSL
ETH*1
PXP12
mode1: 70/280
PMC*2 mode2: 140/140
GBL
*2: PMC supports max 3 GBLs
ti-GSM-Provisioning_goals_achivd_instance_PCU provisioning-00141-ai-sw
68P02900W21-T
8-41
Jul 2010
PXP configuration
Figure 8-10
Provisioning goals achieved with instance of PCU provisioning (ET Gb)

GPRS or EGPRS
GDS+GSL
BSC
SGSN
ETH *1
PXP1
mode1: 70/280
ETH *2 mode2: 140/140
GBL
GDS+GSL
ETH *1
PXP2
mode1: 70/280
*2
mode2:
140/140
ETH
GBL
.
To .
.
GDS+GSL
ETH *1
PXP11
mode1: 70/280
*2
mode2: 140/140
ETH
GBL
Redundant
ETH *1
PXP12
GDS+GSL
mode1: 70/280
ETH *2 mode2: 140/140
Redundant GBL
*2: ETH on the UDPROC2 front panel
ti-GSM-Provisioning_goals_achivd_instance_PCU provisioning(ET-Gb)-00141.a-ai-sw
provisioning.
Table 8-11 Provisioning goals (per PCU)

Metric
Goal
GPRS maximum
coverage with redundant
configuration
(Figure 8-7 and Figure 8-8)
GPRS maximum coverage,

Redundancy not required
(Figure 8-9 and Figure 8-10)
Continued
8-42
68P02900W21-T
Jul 2010
Upgrading the PCU
Table 8-11 Provisioning goals (per PCU) (Continued)

Metric
Number of timeslots
time
Total number of provisioned

timeslots at a BSS
Goal
prp_fanout_mode1- 770
(70*11)
prp_fanout_mode1840(70*12)
prp_fanout_mode2- 1540
(140*11)
Number of PXPs
11
12
Number of TRAU-LAPD GDS

ETHs*
11
12
3 * 11 = 33
`
3 * 12 = 36
No. Gb ETHs
11
12
MPROC board redundancy
Yes
No
PXP board redundancy
Yes
No
GDS/GSL ETH redundancy
Yes
Yes
Gb E1 redundancy
Yes
Yes
Gb ETH redundancy
Yes
Yes
Number of MPROCs
Number of Gb E1s
NOTE
* Capacity does not meet calculated maximums in the event of a failure. This may or
may not affect the usage dependent on the current load of the system.
Upgrading the PCU

The PCU can be incrementally upgraded for additional capacity, by adding one PXP board,
PRP board or by one PICP board at a time. Table 8-12 and Table 8-13 show different upgrade
scenarios based on the number of timeslots supported by PXP or PRP and redundancy required.
The actual number of boards and links required is based upon the formulas in this chapter.
If this feature is enabled at the same time while upgrading the PCU, consider the impact of QoS.
That is, enabling QoS increases the CPU utilization of DPROC and U-DPROC2. However the
CPU utilization impact is far lower on the U-DPROC2 due to its higher processing power. When
upgrading PCU, it is recommended to add U-DPROC2 instead of DPROC and configure it as
PXP instead of PRP to gain more capacity.
NOTE
Table 8-12 shows maximum configurations for all DPROC boards configured into PRP.
All the PRPs in the PCU should have the same setting of prp_fanout_mode.
68P02900W21-T
8-43
Jul 2010
Upgrading the PCU
Table 8-12 Upgrade scenarios for PRP configuration

No. of air
timeslots
No. of
PRP
No. of
PICP
No. of
GBL
No. of
GSL
Mode 1-120
Mode 2-48
Mode 1-4
Mode 2-2
Mode 1-8
Mode 2-6
Minimum.
configuration,
no
redundancy
Mode 1-240
Mode 2-96
Mode 1-8
Mode 2-4
Mode 1-12
Mode 2-8
No Gb
redundancy
Mode 1-240
Mode 2-96
Mode 1-8
Mode 2-4
Mode 1-16
Mode 2-12
With
redundant
links
Mode 1-360
Mode 2-144
Mode 1-12
Mode 2-6
Mode 1-20
With
redundant
links
Mode 1-480
Mode 2-192
Mode 1-16
Mode 2-8
Mode 1-24
Mode 2-16
With
redundant
links
Mode 1-600
Mode 2-240
Mode 1-20
Mode 2-10
Mode 1-24
Mode 2-14
No Gb
redundancy
Mode 1-600
Mode 2-240
Mode 1-20
Mode 2-10
Mode 1-28
Mode 2-18
With
redundant
links
Mode 1-720
Mode 2-288
Mode 1-24
Mode 2-12
10
Mode 1-36
Mode 2-24
With
redundant
links
Mode 1-840
Mode 2-336
Mode 1-28
Mode 2-14
10
Mode 1-40
Mode 2-26
With
redundant
links
Mode 1-960
Mode 2-384
Mode 1-32
Mode 2-16
10
Mode 1-44
Mode 2-28
With
redundant
links
Mode 1-1080
Mode 2-432
Mode 1-36
Mode 2-18
10
Mode 1-48
Mode 2-30
With
redundant
links
No. of GDS
Total links
Remarks
NOTE
8-44
* All air timeslots are assumed to be EGPRS capable and assumed to have a
backing on the backhaul of 64 kbps/air timeslot. If VersaTRAU is unrestricted,
the number of GDS resources is between 18 and 36 and depends on the number
of DS0s equipped for each EGPRS RTF on the backhaul.
service, GDS resources for 64 k enabled RTFs (pkt_radio_type = 3) should
68P02900W21-T
Jul 2010
Upgrading the PCU
On per 64 k carrier basis:

the number of 64 k PDTCH configured (including switchable TCH/PDTCH
number of 64 k PDTCH configured (including switchable TCH/PDTCH
timeslots), then the GDS DS0 requirement is the number of 64 k PDTCHs
Table 8-13 shows maximum configurations for all DPROC boards configured into PXP. All the
PXPs in the PCU should have the same setting of prp_fanout_mode.
Table 8-13 Upgrade scenarios for PXP configuration

Number of
PXP
Number of
GDS(TRAU
_LAPD)
Number of
GBL
Mode 1-280
Mode 2-140
Minimum configuration,
no redundancy
Mode 1-560
Mode 2-280
With redundant links
Mode 1-840
Mode 2-420
Mode 1-1120
Mode 2-560
12
Mode 1-1400
Mode 2-700
15
Mode 1-1680
Mode 2-840
18
Mode 1-1960
Mode 2-980
21
Mode 1-2240
Mode 2-1120
24
Mode 1-2520
Mode 2-1260
27
Mode 1-2800
Mode 2-1400
10
10
30
Mode 1-3080
Mode 2-1540
11
11
33
Mode 1-3360
Mode 2-1680
12
12
36
Number of air
timeslots
Remarks
NOTE
* For mixed configuration using PRP as well as PXP, consider the capacities of PRP
and PXP when upgrading for the additional capacity.
68P02900W21-T
8-45
Jul 2010
E1 link/ETH link provisioning for GPRS and EGPRS
E1 link/ETH link provisioning for GPRS and EGPRS
E1 interface provisioning
The BSC to PCU E1 links should not go through any network elements. The E1 links should
meet the ITU-T Recommendation G.703. This recommendation includes E1 length specification.
The PCU is configured for E1 loop timing recovery on all the PCU E1 interfaces. The PCU is
connected directly to the BSC E1 interfaces and the BSC is configured to provide the E1 master
clock. If the PCU attaches to a GSN that does not have a master clock source, use an interface
piece of equipment, such as a Digital Cross Connect switch (DACs) that does have a master clock
source. The Motorola BSC and RXCDR equipment can be used in place of DACs for this purpose.
E1 Planning considerations
Consider the following factors when planning the E1 interfaces and links if all DPROCs are
equipped as PRP/PICP.
GDS TRAU E1
On the PMC NIB, the PCU can support an arbitrary mixture of 124 16 kbps TRAU, 62 32 kbps
TRAU, and 62 64 kbps (VersaTRAU DS0s) TRAU such that the following equation is satisfied:
#16 kbps TS + (2 x #32 kbps TS) + (2 x 64 kbps DS0s) < 124
NOTE
8-46
All PDTCHs of one 64k RTF are required to be mapped to one GDS E1. When
the remaining DS0 of one GDS cannot satisfy one 64k RTF required, part of
DS0s required by the RTF is in intrans state even though the total GDS resource
is enough. In this situation, additional GDS E1s or PRP board are required to
account for this limit.
Based on the design of Cell Balance (CB) algorithm, the TRAU GDS resource is
one of factors which affect the air timeslots allocation on PRP. The adequacy and
evenly distribution of GDS TRAU are recommended.
When GPRS is configured, each PMC on a PRP supports one E1 link. If EGPRS
is configured, each PMC can support two E1 links.
There may be up to 18 TRAU-type GDS E1 links per PCU for GPRS. There may
be up to 36 TRAU-type GDS E1 links per PCU for EGPRS.
68P02900W21-T
Jul 2010
Ethernet interface provisioning
service, GDS resources for 64 K enabled RTFs (pkt_radio_type = 3) should
On per 64 K carrier basis:
the number of 64 K PDTCH configured (including switchable TCH/PDTCH
number of 64 K PDTCH configured (including switchable TCH/PDTCH
timeslots), then the GDS DS0 requirement is the number of 64 K PDTCHs
If the feature Support the usage of idle TCH for the packet burst traffic is used,
idle circuit-switched timeslots can be used as switchable PDTCHs for packet
traffic when GPRS is congested in the cell. The additional switchable PDTCH
during GPRS congestion uses the additional GDS TRAU resources. Therefore,the
GDS TRAU resource should be configured to have some additional margin to
ensure the need of the additional PDTCH.
GSL LAPD (GSL) E1

The GSL traffic is load balanced over all GSLs. Each E1 carries up to 30 LAPD links. For
LAPD-type GDS resiliency, two E1s are recommended, regardless of the number of LAPD
channels required. For example, if only one channel is required to carry the expected signaling
load, use two E1s with one LAPD channel per E1. The MPROC load balancing software
distributes the load evenly between the two LAPD channels.
PCU Gb E1 (GBL)
There can be up to 4 Gb E1s per PCU for GPRS and 12 Gb E1s per PCU for EGPRS.

High bandwidth interconnection between the BSC and PCU provides Ethernet connectivity
between BSC (PSI2) and PCU (PXP). One PSI2/PXP pair supports one ETH link.
Up to 12 Ethernet links can be supported between BSC and PCU. These links can run either in
1000 BASE-TX or 100 BASE-T modes.
{26638} The Gb over IP feature provides Ethernet connectivity between the SGSN and PCU.
One PXP supports one GBL ETH link from its PMC front panel to 12 Ethernet links, which can
be supported in the PCU. These links can be run in 100BaseTx/1000BaseT auto-negotiation
mode on the peer SGSN side.
68P02900W21-T
8-47
Jul 2010
PCU GDS (TRAU-LAPD)

With ETH link, a new type of GDS (TRAU-LAPD) can be equipped. This GDS can carry both
TRAU and LAPD (GSL) simultaneously on ETH link.
The traffic load of GDS on one link depends on the capacity of PXP. The number of PDCH for one
PXP is 280 for prp_fanout_mode1 and 140 for prp_fanout_mode2. Consider the parameter
tdm_ts_blocks for PSI2 for TRAU-LAPD GDS planning. Refer to the tdm_ts_blocks planning
guideline in Chapter 6 BSC planning steps and rules.
The maximum number of GSL on one link is 30. 60 GSLs can be equipped for the PCU. When
multiple ETH links exist, equip GSLs evenly on different links for resiliency. GDS (TRAU-LAPD)
supports N + M redundancy. Signaling and traffic load is shared among in-service ETH links. If
one (pair) fails, the load is redistributed among the remaining in-service links.
PCU Gb (E1)
Every PXP can support 3 Gb (E1) links. There can be up to 36 Gb E1s per PCU for GPRS/EGPRS.
When multiple PXPs exist, it is recommended to equip Gb E1s evenly on different PXPs for
resiliency.
PCU Gb (Ethernet)
Each PXP can support one Gb Ethernet link. There can be up to 12 Gb Ethernet links per PCU. It
is recommended to equip N+1 GBL on different PXP for redundancy.
GPROC LCF
The GPROC LCFs available at the BSC terminate up to 12 LAPD channels. Up to 60 LAPD-type
links can be provisioned at the PCU. The LAPD links can be distributed on the LCF automatically,
based on the capacity available on the LCFs.
NOTE
Either the GPROC2 or the GPROC3/GPROC3-2 can perform LAPD-type link
processing.
8-48
68P02900W21-T
Jul 2010
QoS capacity and QoS2 impact
The QoS feature retains the 120 mobile per PRP board limit from previous loads. However, this
feature can affect the overall capacity of the PRP and PXP board. Each PRP/PXP board has a
capacity in terms of MTBR. When that capacity is reached, no more non-STNNT mobiles or
PFCs can be admitted without preempting other PFCs first. There is a trade-off between the
number of mobiles being serviced and the MTBR of the PFCs of the mobiles being serviced. If
the MTBR of the various traffic classes are set to high values, or there are multiple PFCs per
mobile, fewer mobiles can be serviced per PRP/PXP board.
A simple example is when there is only one GPRS timeslot equipped and in-service, and a
high ARP value PFC is allocated a single timeslot of MTBR (calculated from coding scheme
and MTBR) for its use. Additional non-STNNT PFCs of equal or lower ARP value cannot be
assigned to that timeslot without compromising the service of the first high ARP value PFC and
are later rejected. Four mobiles can be allocated on each PDTCH provided there is sufficient
available throughput.
When the BSS is managing its pool of MTBR resources, it reserves headroom (16.7%), that is, it
does not allocate 100% of its resources in terms of MTBR commitments. The purpose of the
headroom is to reserve some throughput in the system so that each PFC has a high probability
of meeting its MTBR regardless of coding scheme changes and to allow short-term PFCs (such
as PAP and STNNT) 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 mobile within that local
zone of timeslots, or addition of an STNNT or PAP mobile to that local zone of timeslots,
does not affect the ability of the mobiles within that local zone of timeslot to meet their
MTBR requirements.
The second level of headroom is at the PRP/PXP board. This is headroom on the ability of
the PRP/PXP board to service 30/70 timeslots per block period of throughput (assume it
is mode1). Some of this throughput is reserved for coding scheme changes, and STNNT
and PAP mobiles.
When admitting a new mobile, the BSS verifies that there is sufficient headroom at both of
these levels. If there is insufficient headroom to admit the new mobile, other mobiles can be
downgraded and/or preempted and the requesting mobile can also be downgraded or rejected.
The amount of MTBR throughput that is available on each timeslot to commit to the mobiles is a
function of the number of mobiles scheduled on that timeslot. In the maximum case, 8 kbps of
MTBR can be allocated for GPRS and 14 kbps for EGPRS per timeslot. This maximum value
is used for all the capacity calculations. The bandwidth can be obtained from configurable
parameters (egprs_init_dl_cs, egprs_init_ul_cs, init_dl_cs, init_ul_cs). Default value is CS2
(12 kbps) and MCS3 (14.8 kbps).
Consider both levels of headroom to determine the overall MTBR capacity of a PRP board. The
most constricting of these levels of headroom determines the overall capacity of the PRP board.
Table 8-12 shows the summation of the headroom of all of the local timeslot zones on a PRP
board for the downlink and the uplink as well as the corresponding summation of the MTBR
throughputs (or committable throughput) of all the timeslot zones on the PRP board.
68P02900W21-T
8-49
Jul 2010
It is important to note that for these calculations it is assumed there are multislot class 1
mobiles (each using a single uplink and downlink timeslot) and class 4 mobiles scheduled per
timeslot (allowing 8 kbps committable bandwidth per slot). The local timeslot zone headroom
is a function of the coding scheme in use but the MTBR throughput of the PRP board is
independent of the coding schemes used.
Table 8-14 takes the coding schemes allowed on a timeslot (for all timeslots) and calculates a
Local Timeslot Zone Level MTBR throughput summed over all timeslots equipped on the PRP
board. By dividing the summation of the local timeslot zones (the available MTBR commitment)
by the commitment made to each mobile (2 kbps) the theoretical limitation based on this
restriction is calculated. It is clear from this example that the Local Timeslot Zone Level
Headroom, when there are 120 timeslots equipped on the board and mobiles with only 1
timeslot and 2 kbps MTBR requirements, are not the restricting factor as the 120 mobile per
board restriction is more constraining. When PXP board is used, 280 mobiles can be supported.
With the increased throughput of the PRP feature, mode1 is 30/120(70/280) and mode2 is
48/48(140/140).
Table 8-14 Local Timeslot Zone Level capacity 4MS/PDTCH

Parameter
Coding scheme
CS-1/2
CS-3/4
EGPRS
12000
20000
59200
Local timeslot zone MTBR

throughput per TS (bit/s)
8000
8000
8000
Local timeslot zone total

headroom (%)
33.3
60.0
86.5
Number of timeslots
equipped
120
120
120
Summation of local timeslot

zone level MTBR throughput
over PRP (bit/s)
960000
960000
960000
Theoretical limitation based

solely on local timeslot zone
restriction Max MS at 2
kbps/MS
480
480
480
Local timeslot zone

Maximum MS at 2 kbps/MS
120
120
120
Peak throughput per TS

(bit/s)
Table 8-15 shows the PRP board service headroom and corresponding PRP board service level
MTBR throughput. The PRP board service headroom and corresponding PRP board service
throughputs are both a function of the actual coding schemes of the mobiles on the board at
the moment (that is, the MTBR or committable throughput of the board is higher when higher
coding schemes are in use on the board). It is important to note that for these calculations
it is assumed there are multislot class 1 mobiles (each using a single uplink and downlink
timeslot) and class 4 mobiles scheduled per timeslot (allowing 8 kbps committable bandwidth
per slot). CS-1 is the worst case.
8-50
68P02900W21-T
Jul 2010
MTBR allocation
Table 8-15 PRP Board Service Level Capacity 4MS/PDTCH

Parameter
Coding scheme
CS-1
CS-1/2
CS-3/4
EGPRS
Peak throughput per TS (bit/s)
8000
11200
15360
25120
Number of PDCH every block

period (PRP board, 30/120
mode)
30
30
30
30
240000
336000
460800
753600
16.7
16.7
16.7
16.7
Summation of local timeslot

zone level MTBR throughput
over PRP (bit/s)
200000
280000
384000
628000
Theoretical limitation based

solely on local timeslot zone
restriction Maximum MS at 2
kbps/MS
100
140
192
314
Local timeslot zone Maximum

MS at 2 kbps/MS
100
120
120
120
Local timeslot zone MTBR

throughput
Local timeslot zone total
headroom (%)
Table 8-15 takes the current throughput per timeslot and calculates a PRP board service level
MTBR based on the requisite headroom. By dividing the PRP Board Service level MTBR
throughput (the maximum committable bandwidth) by the commitment per mobile (2 kbps
MTBR), a theoretical maximum limitation is calculated. In all but the worst-case scenario (all
mobiles experiencing CS-1), the board level Service Capacity is not the limiting factor in the
number of mobiles supported per board. The 120 mobile per board limit is the constraining
factor. While considering the overall PRP capacity, the PRP service level headroom usually limits
the number of mobiles on the PRP board, that is, as long as there are multiple cells on the PRP
board. For example, if the MTBR is set to 6 kbps in both uplink and downlink for all traffic
classes, interleaving is limited to one mobile per timeslot in the uplink and mobiles with multiple
slots in the downlink. At the timeslot zone level, 120 mobiles are allowed onto the PRP board.
However, at the PRP board service level, in the worst case (all CS-1), only 30 mobiles can be
admitted to the PRP board. With a combination of 20% CS-1 and 80% CS-2, 70 mobiles can be
admitted. With 20% CS-1, 40% CS-3 and 40% CS-4, 60 mobiles can be admitted.
MTBR allocation
The BSS attempts to maintain its MTBR commitments to PFCs in the order of priority by ARP
Value. In other words, PFCs of a higher ARP Value are more likely to get access to the system
and get their requested MTBR.
The BSS attempts to ensure the ARP Value ordering of MTBR commitments through
downgrading and preemption.
68P02900W21-T
8-51
Jul 2010
MTBR allocation
Per timeslot commitment

The BSS commits a maximum of 6 kbps of MTBR in the downlink and in the uplink per GPRS
timeslot on the air interface (and 12 kbps per EGPRS timeslot) when there are less than four
mobiles allocated on the timeslot. This maximum commitment per timeslot is independent of the
type of backhaul or the current coding schemes of the mobiles. The remaining throughput on
the timeslot the commitment is headroom and is allocated to the mobiles according to their
THP weights. For timeslots that are configured as PCCCH timeslots, the BSS commits 0 kbps of
MTBR. PCCCH timeslots share both user data and control signaling. Therefore, the BSS does
not make any MTBR commitments on the PCCCH timeslot. There could be a large amount of
control signaling transmitting (which has higher priority than user data) that would not allow
the BSS to maintain MTBR on this timeslot.
To admit 4 mobiles per timeslot (required to satisfy 120 mobiles per PRP board), some of the
headroom on each timeslot can be used to admit a fourth mobile on to a timeslot, effectively
increasing the committable bandwidth on that GPRS timeslot to 8 kbps (and 14 kbps per EGPRS
timeslot). This increase only occurs to admit a fourth mobile and is not done for any other
number of mobiles on the timeslot, as using this headroom allows 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. The headroom allows
the MTBR commitments to be maintained regardless of any coding scheme changes made
by the mobile.
Each traffic class has an associated MTBR that is configurable by the operator, or is fixed
at zero. Within the interactive traffic class, each THP has its own associated MTBR that is
configurable by the operator.
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 no matter how the MTBR is set. This guarantees that
these classes are not 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 no matter how the MTBR is set. This means that a THP 3 is not
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 that they can be 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 mobile commitment

The BSS limits its MTBR commitment to a mobile to a value that the mobile is capable of
supporting. The BSS allocates resource according to initial coding scheme (it is configurable)
and negotiation number of timeslot.
Refer to Table 8-16 for maximum MTBR in downlink and uplink for each multislot class. m
stands for bitrate (kbps) that one timeslot provides using a coding scheme. For example, m
= 9.2 for CS1, m = 13.6 for CS2.
8-52
68P02900W21-T
Jul 2010
Table 8-16
MTBR allocation
Maximum MTBR in UL/DL per multislot capability
Mobile multislot
class
Multislot class
supported
Maximum MTBR
(uplink)
Maximum MTBR
(downlink)
1 uplink timeslot
1 downlink timeslot
1 uplink timeslot
2 downlink timeslots
2m
1 uplink timeslot
3m
2 uplink timeslots
2m
2 uplink timeslots
or
1 uplink timeslot
2m
1 uplink timeslot
4m
2 uplink timeslots
3m
10
10
1 uplink timeslot
or
2 uplink timeslots
3m
11
11
Class 10 or
3 uplink timeslots
2m
12
12
Class 10 or
4 uplink timeslots
1 downlink timeslot
30
30
1 uplink timeslot
5m
31
31
4downlink timeslots
2 uplink timeslot
4m
32
32
3 uplink timeslot
3m
33
33
4 uplink timeslot
2m
Possible configure
Downlink timeslot
Uplink timeslot
For the cell with extended PDCH, when the QoS feature is enabled, the MS in the extended
range is always admitted with MTBR = 0.
68P02900W21-T
8-53
Jul 2010
PRP-PDTCH QoS planning
Biasable mobile commitment

The BSS limits its MTBR commitment to a biasable mobile (multislot classes 6 and 10, and any
that map to these classes) to the maximum MTBR allowed per timeslot multiplied by the number
of timeslots that are fixed in each direction. Thus, multislot class 6 is committed at most 12 kbps
(2 timeslots) in the downlink and 6 kbps (1 timeslot) in the uplink, and class 10 is committed at
most 18 kbps (3 timeslots) in the downlink and 6 kbps (1 timeslot) in the uplink.
Per timeslot zone commitment

The BSS limits its MTBR commitment to a timeslot zone to 6 kbps of MTBR in the downlink
and in the uplink per timeslot in that timeslot zone unless a fourth mobile is scheduled on that
timeslot. When scheduling the fourth mobile on a timeslot, the BSS allows a commitment to be 8
kbps on all timeslots where there are four mobiles 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 five timeslots are reserved as headroom for STNNT and PAP mobiles
and for coding scheme changes. The total committable bandwidth is a function of the coding
schemes of the mobiles on the board.
PRP-PDTCH QoS planning

The maximum number of PDTCHs to assign per PRP based on the information provided in QoS
capacity and QoS2 impact is calculated using the following steps:
Calculate the PRP board throughput based on coding schemes used while subtracting
PRP board headroom.
Calculate the average downlink MTBR to determine the amount to reserve for each QoS
subscriber.
Divide the PRP board throughput by the average downlink MTBR to determine the
MAX_QOS_PDTCHS_PER_PRP.
Calculating PRP board throughput

PRP board throughput is calculated as follows:
8-54
68P02900W21-T
Jul 2010
Calculating average downlink EGBR
P RP BOARDT HROU GHP U T = T HRU P U T T S {(8000 %CSI U SAGE)+ (12000 %CS2 U SAGE)+
(14400 %CS3 U SAGE) + ...... (20000 %CS4 U SAGE) + (8800 %M CS1 U SAGE) +
(11200 %) (M CS2 U SAGE) + ...... (14800 %M CS3 U SAGE) + (17600 %M CS4 U SAGE) +
(22400 %) (M CS5 U SAGE) + ...... (29600 %M CS6 U SAGE) + (44800 %M CS7 U SAGE) +
(54400 %) (M CS8 U SAGE) + ...... (59200 %M CS9 U SAGE)} (1 16.7)
Where:
Is:
THRUPUT_TS
the maximum TS worth of throughput that can be

supported per PRP/PXP depending on deployment
and mode.
%CS1_USAGE
%CS2_USAGE
%CS3_USAGE
%CS4_USAGE
%MCS1_USAGE
%MCS2_USAGE
%MCS3_USAGE
%MCS4_USAGE
%MCS5_USAGE
%MCS6_USAGE
%MCS7_USAGE
%MCS8_USAGE
%MCS9_USAGE
the percentage of time the relevant coding scheme

is used by subscribers in the cells attached to a
given PCU.
An MS in the extended range has a lower coding scheme than in the normal range due to the
longer distance between the MS and BTS. For the cell with extended PDCH, the lower coding
scheme has a higher usage percentage value than the corresponding typical usage percentage
value for a cell without extended PDCH.

The EGBR is the additional throughput that is allocated to an operator that is sufficient to
service the GBR and the transfer delay requirements of the streaming service.
EGBR is defined as GBR/r, where r is a value between 0 and 1. To find the average downlink
EGBR first find the minimum value for r.
Average downlink Streaming EGBR is calculated as follows:
ST R EGBR = Average GBR/p (1 + BLER)

BLER is typically 10%-15%. The value of r is dependent on the transfer delay parameter for the
streaming service. The minimum transfer delay that the PCU supports is user configurable. For
planning purposes use this value of minimum transfer delay to determine the value of r.
For a given GBR, the value of r is dependent on the transfer delay parameter for the streaming
service. The minimum transfer delay that the PCU supports is user configurable. For planning
purposes, this value of minimum transfer delay is used to determine the value of r.
To determine the value of r to use, first obtain the weighted average GBR per service in the
network.
68P02900W21-T
8-55
Jul 2010
This is obtained by multiplying the frequency of the service in the network by the GBR of the
service.
AverageGBR =
N
X
GBRi F Si/ST Ri
i=1
Where:
N
GBRi
FSi
STRi
Is:
the number of streaming services types in the network.
the GBR of streaming service i.
the percentage of streaming service i in service mix of subscribers in a given
PCU.
the percentage of total streaming service in service mix of subscribers in
a given PCU.
Look up at the Average GBR value in the tables to obtain the r value.
The table provides the minimum value of r for a given minimum transfer delay supported in the
PCU, in networks where the majority of streaming services have GBR of 15 kbps or lower, for
example, PoC. In practice, where an application does not need a stringent transfer delay, r is
larger for that application, resulting in less EGBR required for a particular GBR. The default
minimum transfer delay value has been set to 500 ms resulting in r = 0.62.
Table 8-17 for various transfer delays at GBR 15 kbps or less

Min Transfer
delay (ms)
Min Transfer
delay (ms)
Min Transfer
delay (ms)
250
0.42
1550
0.84
2850
0.9
300
0.48
1600
0.84
2900
0.9
350
0.52
1650
0.84
2950
0.9
400
0.56
1700
0.85
3000
0.91
450
0.59
1750
0.85
3050
0.91
500
0.62
1800
0.85
3100
0.91
550
0.64
1850
0.86
3150
0.91
600
0.66
1900
0.86
3200
0.91
Continued
8-56
68P02900W21-T
Jul 2010
Table 8-17 for various transfer delays at GBR 15 kbps or less (Continued)
Min Transfer
delay (ms)
Min Transfer
delay (ms)
Min Transfer
delay (ms)
650
0.68
1950
0.86
3250
0.91
700
0.7
2000
0.87
3300
0.91
750
0.71
2050
0.87
3350
0.91
800
0.73
2100
0.87
3400
0.91
850
0.74
2150
0.87
3450
0.92
900
0.75
2200
0.88
3500
0.92
950
0.76
2250
0.88
3550
0.92
1000
0.77
2300
0.88
3600
0.92
1050
0.78
2350
0.88
3650
0.92
1100
0.78
2400
0.89
3700
0.92
1150
0.79
2450
0.89
3750
0.92
1200
0.8
2500
0.89
3800
0.92
1250
0.8
2550
0.89
3850
0.92
1300
0.81
2600
0.89
3900
0.92
1350
0.82
2650
0.89
3950
0.92
1400
0.82
2700
0.9
4000
0.92
1450
0.83
2750
0.9
1500
0.83
2800
0.9
For networks where the majority of streaming services have GBR greater than 15 kbps,
Table 8-18 and Table 8-19 provide the minimum values of r for transfer delays of 500 ms and
250 ms. In networks where the configured minimum transfer delay parameter has been set to
be greater than 500 ms, use the table for the transfer delay of 500 ms. First determine the GBR
for which the majority of service in the network operate, for example, video streaming 40 kbps,
then looking up the GBR at the table, obtain r. If the GBR value is not in the table, then evaluate
the two closest GBR values and select the value resulting in the lower r value.
68P02900W21-T
8-57
Jul 2010
Table 8-18 for Transfer delay = 500 ms at GBR greater than 15 kbps
8-58
Min Transfer
delay (ms)
Min Transfer
delay (ms)
Min Transfer
delay (ms)
15000
0.62
41000
0.8
67000
0.86
16000
0.63
42000
0.8
68000
0.86
17000
0.65
43000
0.8
69000
0.86
18000
0.66
44000
0.81
70000
0.86
19000
0.67
45000
0.81
71000
0.87
20000
0.68
46000
0.81
72000
0.87
21000
0.69
47000
0.82
73000
0.87
22000
0.69
48000
0.82
74000
0.87
23000
0.7
49000
0.82
75000
0.87
24000
0.71
50000
0.82
76000
0.87
25000
0.72
51000
0.83
77000
0.87
26000
0.72
52000
0.83
78000
0.88
27000
0.73
53000
0.83
79000
0.88
28000
0.74
54000
0.83
80000
0.88
29000
0.74
55000
0.84
81000
0.88
30000
0.75
56000
0.84
82000
0.88
31000
0.75
57000
0.84
83000
0.88
32000
0.76
58000
0.84
84000
0.88
33000
0.76
59000
0.85
85000
0.88
34000
0.77
60000
0.85
86000
0.89
35000
0.77
61000
0.85
87000
0.89
36000
0.78
62000
0.85
88000
0.89
37000
0.78
63000
0.85
89000
0.89
38000
0.79
64000
0.85
90000
0.89
39000
0.79
65000
0.86
40000
0.79
66000
0.86
68P02900W21-T
Jul 2010
Table 8-19 for Transfer delay = 250 ms at GBR greater than 15 kbps
Min Transfer
delay (ms)
Min Transfer
delay (ms)
Min Transfer
delay (ms)
15000
0.42
41000
0.63
67000
0.72
16000
0.43
42000
0.63
68000
0.72
17000
0.45
43000
0.64
69000
0.72
18000
0.46
44000
0.64
70000
0.73
19000
0.47
45000
0.64
71000
0.73
20000
0.48
46000
0.65
72000
0.73
21000
0.49
47000
0.65
73000
0.73
22000
0.5
48000
0.66
74000
0.74
23000
0.51
49000
0.66
75000
0.74
24000
0.52
50000
0.66
76000
0.74
25000
0.52
51000
0.67
77000
0.74
26000
0.53
52000
0.67
78000
0.74
27000
0.54
53000
0.68
79000
0.75
28000
0.55
54000
0.68
80000
0.75
29000
0.56
55000
0.68
81000
0.75
30000
0.56
56000
0.69
82000
0.75
31000
0.57
57000
0.69
83000
0.76
32000
0.58
58000
0.69
84000
0.76
33000
0.58
59000
0.7
85000
0.76
34000
0.59
60000
0.7
86000
0.76
35000
0.59
61000
0.7
87000
0.76
36000
0.6
62000
0.7
88000
0.77
37000
0.61
63000
0.71
89000
0.77
38000
0.61
64000
0.71
90000
0.89
39000
0.62
65000
0.71
40000
0.62
66000
0.72
68P02900W21-T
8-59
Jul 2010
Calculating average downlink MTBR

Average downlink MTBR is calculated as follows:
AV ERAGEDOW N LIN KM T BR = (ST R EGBR %subs ST R) + (I1M T BR %subs I1) +
(I2M T BR %subs I2) + .... (I3 M T BR %subs I3) + (BG M T BR %subs BG) +
(BE M T BR %subs BE)
Where:
Is:
STR_EGBR
the throughput required to guarantee downlink GBR and average

transfer delay for the streaming traffic class.
I1_MTBR
I2_MTBR
I3_MTBR
BG_MTBR
BE MTBR
the downlink MTBR values set for each of the traffic classes.
% subs_STR
%subs_I1
%subs_I2
%subs_I3
%subs_BG
%subs_BE
the percentage of subs allocated to each of the traffic classes in

the system based on subscription or by default based on no QoS
subscription or roaming subscribers entering the system and having
their QoS attributes negotiated to a traffic class.
NOTE
The MTBR values are defined at the cell level. The values to use for this equation are
either the average MTBRs for each traffic class across all cells connected to a PCU or
the maximum MTBR values set at a cell for each traffic class.
Calculating MAX_QOS_MS_PER_PRP
MAX_QOS_MS_PER_PRP is calculated as follows:
MAX_QOS_ MS_PER PRP = PRP BOARD THROUGHPUT/AVERAGE DOWNLINK MTBR
Maximizing MS and throughput per PRP/PXP

When QoS is enabled, particularly where the traffic is predominantly streaming traffic (which
needs large EGBR), it is advisable that the PRP/PXP operates in mode 2. This is because mode
2 maximizes throughput rather than coverage, whereas mode 1 increases coverage at the
expense of throughput. It is anticipated that in networks where QoS is enabled, data services
are no longer in the initial deployment stage and hence the option that maximizes throughput
is most appropriate.
However, before deciding on the mode, verify the MS per PRP number that can be supported
versus maximizing coverage for mode 1 and mode 2. This information enables to decide upon
the most suitable mode of operation for the particular mix of data services in the network.
Typically in networks where there is no streaming traffic mode 1 operation is acceptable,
particularly, if most services are assigned the minimum MTBR of 2 kbps.
For example, a PRP in mode 1 supports 30 TS throughput/120 TS coverage, while a PRP in mode
2 supports 48 TS throughput/48 TS coverage. Assuming a worst case-coding scheme of CS-1,
the PRP throughput is 240 kbps in mode 1 operation, and 384 kbps in mode 2.
8-60
68P02900W21-T
Jul 2010
NOTE
240 kbps is determined from 8 kbps (CS1) * 30 TS and 384 kbps is determined from 8
kbps (CS1) * 48 TS.
If planning for an average downlink bit rate per mobile (no streaming) of 2 kbps, then in mode 1,
120 mobiles (240/2) can be simultaneously supported over 120 TS and for mode 2, 192 mobiles
(384/2) can be simultaneously supported. However, in mode 2 this is over the PRP board limit of
72 mobiles. Therefore, the PRP board places the limit on the number of supported mobiles to 72
mobiles over the 48 TS of coverage. In this example, mode 1 can support more mobiles than
mode 2 and therefore in this situation mode 1 operation is preferred.
If planning for an average downlink bit rate per mobile (with provision for streaming traffic) of 8
kbps then in mode 1, only 30 mobiles (240/8) can be simultaneously supported over 120 TS and
for mode 2, 48 mobiles can be simultaneously supported. Mode2 support more mobiles than
mode1, achieving a PRP board throughput of 384 kbps (488), and therefore in this situation
mode 2 operation is preferred.
This approach can be summarized in the following manner: If the planned average bit rate per
mobile is R kbps then for mode 1: mobile numbers = Min (240/R, 120); for mode 2: mobile
numbers = Min (384/R, 72). This relationship is plotted for the two modes in the following
graph. The cross over point between preferring mode 2 of mode 1 is R = 3.3 kbps.
Figure 8-11 BER versus Number of mobiles
ti-GSM-BER_versus_Number_of_mobiles-00141-ai-sw
68P02900W21-T
8-61
Jul 2010
CTU2D impact
CTU2D impact
When CTU2D is configured in ASYM mode LA algorithms and when admitting a mobile, BSS
limits uplink-coding schemes on Carrier B to GMSK modulation, that is, MCS1 to MCS4.
Also, in ASYM mode, if egprs_init_ul_cs is higher than MCS4, it is restricted to MCS3 when
admitting a new mobile on Carrier B. MCS3 is selected since it offers a reasonable compromise
of throughput versus link performance, whereas MCS4 is uncoded (code rate = 1) and therefore
it is only appropriate in favorable channel conditions.
8-62
68P02900W21-T
Jul 2010
PCU-SGSN: traffic and signal planning
PCU-SGSN: traffic and signal planning
Introduction
{26638} There are two Gb modes, Frame relay-based Gb and Static IP-based Gb:
Frame relay-based Gb.

The PCU is connected to the SGSN through the Gb interface as a Data Terminal Equipment
(DTE). The physical Gb connection can be established in two ways:
Through point-to-point frame relay connection, with DACs.
Through the frame relay network.
E1 links are used in both cases.
Static IP-based Gb.

The PCU is connected to the SGSN though the Ethernet IP network.
Gb entities
This section describes the Gb entities and illustrates the mapping of GPRS cells using either the
point-to-point frame relay connection (PTP FR) or frame relay network.
Table 8-20 provides a description of the Gb entities and identifiers.
Table 8-20 Gb entities and identifiers

Gb Entity and Identifier
Description
E1
The physical link contains 32 timeslots. One is reserved

for E1 synchronization. Each timeslot uses a rate of 64
kbps.
Frame relay bearer channel

(FR BC)
The bearer channel allows the frame relay protocol to

map its resources to the E1 layer.
Permanent virtual circuit (PVC)
A frame relay virtual circuit. This allows the packet

switched FR network to act as a circuit-switched
network by guaranteeing an information rate and time
delay for a specific PVC.
Data link connection identifier

(DLCI)
A unique number assigned to a PVC end point in a frame

relay network.
IP endpoint
An endpoint is defined by its IP address and the UDP

port. An IP endpoint can be a data endpoint and/or a
signaling endpoint.
Continued
68P02900W21-T
8-63
Jul 2010
General planning guidelines
Table 8-20
Gb entities and identifiers (Continued)

Description
Gb Entity and Identifier

Data traffic
The data traffic for an IP Sub-Network is defined as NS

SDUs for PTP and PTM functional entities (BVCI 1). In
Motorola GB Over IP load sharing algorithm, the Data
traffic refers to NS SDUs that need to be load shared
by the ULC.
Signaling traffic
The signaling traffic for an IP Sub-Network is defined as

NS SDUs for signaling functional entities
(BVCI = 0) and all PDUs for IP Sub-Network Service
Control. In Motorola GB Over IP load sharing algorithm,
the signaling traffic refers to the NS SDUs that need to
be load shared by the GBM and FBM.
Network service entity (NSE)
An instance of the NS layer. Typically, one NSE is used

for each PCU being served by an SGSN. The NSE has
significance across the network, and is therefore the
same at the SGSN and PCU.
Network service entity

identifier (NSEI)
Uniquely identifies an NSE.
Network Service Virtual Circuit

(NSVC)
A logical circuit that connects the NSE peers between

the SGSN and PCU. The NSVC has significance across
the network. Therefore, it is configured identically at
the SGSN and PCU.
Network Service Virtual Circuit

Identifier (NSVCI)
Uniquely identifies an NSVC. There is a one-to-one

mapping between the NSVCI and DLCI.
BSSGP virtual circuit (BVC)
A logical circuit that connects the BSSGP peers between

the BSS and SGSN. It is only configured in the PCU. The
PCU contains one point-to-point BVC per an actively
serving cell.
BSSGP Virtual Circuit Identifier

(BVCI)
Uniquely identifies a BVC.
General planning guidelines

These are the general planning guidelines:
8-64
There can be more than one BVC per NSE/PCU/BSS.
There is one point-to-point BVCI per cell, statically configured at the PCU and dynamically
configured at the SGSN.
There are multiple NSVCs serving one NSE.
There is a one-to-one mapping between Frame relay NSVCIs and DLCIs.
68P02900W21-T
Jul 2010
Specific planning guidelines
There is a one-to-one mapping between the IP-based NSVCI with the PCU IP/UDP port
and the SGSN IP/UDP port pair.
Multiple DLCIs can share the same bearer channel, and therefore the same timeslot
grouping. A bearer channel can be mapped between one and 31 DS0s, depending on the
throughput needed for that particular link.
The DLCI has local significance only while the NSVCI has significance across the network.
One E1 can be fractionalized into several bearer channels.
Specific planning guidelines

Motorola deploys one NSEI per PCU. Each NSEI must be unique.
Gb signaling
This section describes the Gb protocol signaling. Consider the signaling and the Gb link
capacity limitations in each Gb link plan.
Gb protocol signaling
The GPRS/EGPRS Mobility Management (GMM/EGMM) signaling procedures that contribute to
uplink and downlink overhead on the Gb link are as follows:
Attach/Detach with ciphering
Cell reselection
Inter/Intra RAU
PDP activate/deactivate
Paging
Gb link PDU data

Each Gb link PDU carries protocol overhead, which is calculated to be 71 bytes.
Determining net Gb load

Consider the network equipment, traffic model, and protocol overheads to determine the net
load that must be delivered to each PCU served by the SGSN.
68P02900W21-T
8-65
Jul 2010
Gb link timeslots (for Frame relay Gb)
Base formulae
Use the following base formulae to determine the load expected on the Gb interface:

21 Cellupdate + 312 P SAttach/Detach + 125 RAU + 172 P DPAct/deact
Signaling Data Rate (bytes/s) =
Subscribers per P CU
+ 89 PGP RS
3600
n

o
(Subscribers per P CU Data Subscriber 1000) 1 + P K71
SIZE
U ser Data Rate (bytes) =
3600
T otal Date Rate (bytes/s) = Signaling Data Rate + U ser Data Rate
Where:
Is:
Total Data Rate
the required bandwidth (bit/s) for GPRS/EGPRS data transmission

over a GBL interface between the PCU and SGSN after all of the
protocol and signaling overhead is accounted for.
Signaling_Data_Rate
the required rate (bytes/s) for GPRS/EGPRS signaling

transmission over a GBL interface between the PCU and SGSN
after all of the protocol.
User Data Rate
the required rate (bytes/s) for GPRS/EGPRS user application

data over a GBL interface between the PCU and SGSN, including
protocol overhead.
PSattach/detach
the attach/detach rate per sub/BH.
RAU
the periodic, Intra, and inter area update rate per sub/BH.
PDPact/deact
the PDP context activation/deactivation rate per sub/busy hour.
PGPRS
the GPRS paging rate (per sec).
PKSIZE
the average packet size, in bytes.
Subscribers_per PCU
the average number of GPRS/EGPRS subscribers supported on

a PCU.
Data_per Subscriber
the data traffic (GPRS/EGPRS) per subscriber in a busy hour

(kBytes/busy hour).
CellUpdate
the cell reselections rate per sub/busy hour.
NOTE
To simplify Gb planning, the Signaling_Data_Rate can be ignored since it is
insignificant compared to the Total_Data_Rate.
Gb link timeslots (for Frame relay Gb)

The traffic and signaling is carried over the same E1 on the Gb link (GBL). The number of
required 64 kbps Gb link timeslots can be calculated using the equation given. Each E1 can
carry up to 31 timeslots. When fewer than 31 timeslots are needed on an E1, specifying a
fractional E1 is more cost effective.
8-66
68P02900W21-T
Jul 2010
Frame relay parameter values
N o GBL T S = T otal Data Rate/ (8000 U GRI)

N P CU SGSN = N o GBL T S/31
Where:
Is:
No_GBL_TS
the number of timeslots to provision on the GBL E1 between the PCU

and SGSN. This value can be used to specify a fractional E1.
Total_Data_Rate
defined by the equation in the previous section, and represents the

required bandwidth (bps) for GPRS/EGPRS data transmission over a
GBL interface between the PCU and SGSN after all the protocol and
signaling overhead is accounted for.
UGBL
the link utilization.
NPCU-SGSN
the E1 link between the PCU and SGSN.

The network planner should specify the values for the following three frame relay interface
parameters:
Committed Information Rate (CIR)
Committed Burst Rate (Bc)
Burst Excess Rate (Be)
These frame relay parameter values are determined as described in the following text and
illustrated in Figure 8-12.
Figure 8-12 Frame relay parameters
ti-GSM-Frame_relay_parameters-00142-ai-sw
68P02900W21-T
8-67
Jul 2010
Committed Information Rate (CIR)

The recommended cumulative CIR value for NSVC should be greater than, or equal to, 50%
of the cumulative information rate of the active timeslots on the PCU. The Motorola PCU
distributes the use of all the NSVCs by the subscribers evenly in a round-robin manner. The
round-robin algorithm continuously assigns subscribers to the next NSVC in a sequential
manner when a subscriber PDP context is established. If an NSVC becomes unavailable, it is
skipped over, and the next available NSVC in the round-robin is used. The BSSGP feature
inherently provides load sharing over all available NSVCs. The BSSGP high-level protocol layer
provides the load sharing capability over multiple Gb links, which results in link resiliency.
The recommended cumulative CIR value for all PVCs should be greater than, or equal to, half
the cumulative information rate of the active timeslots routed to the NSVC. This mapping is
determined as a mean load, evenly distributed over all the available NSVCs as next described.
Over many cells, it is expected that the PCU handles the traffic throughput equal to the number
of timeslots planned for the busy hour traffic load.
The recommended frame relay network CIR value is calculated as follows:
CIR V alue =
Where:
F T otal Data Rate 8

N um N SV C
Is:
CIR_Value
the committed Information rate per NSVC (PVC).
the CIR provisioning factor, equal to 0.5.
Total_Data_Rate
defined in Determining net Gb load on page 8-65, and represents

the required bandwidth (bit/s) for GPRS data transmission over a
GBL interface between the PCU and SGSN after all the protocol and
signaling overhead is accounted for.
By using half the number of timeslots in the CIR calculation, the load of all the timeslots is
served by the combination of the CIR and Bc frame relay network rated capacity. This strategy
uses the overload carrying capacity of the frame relay network when more than half of the
planned timeslots are in use.
When a cell uses all of its provisioned timeslots as active timeslots (that is, timeslots being
processed by the PCU at that instance in time), other cells must use fewer of their timeslots
being processed for the overall PCU Gb interface bandwidth allocation to be within configured
frame relay network interface parameter (CIR, Bc, Be) values. The BSS attempts to utilize as
many timeslots as are supported in PCU hardware and in communication links simultaneously.
Committed Burst rate (Bc)

The Bc is the maximum amount of data (in bits) that the network agrees to transfer, under
normal conditions, during a time interval Tc.
Configure the Bc value such that if one of the provisioned E1 links fails, the remaining E1 links
can carry the load of the failed link, by operating in the Bc region. For example, with three E1
links provisioned, if any one of the three should fail, the other two should have the capacity to
carry the load of the failed link on the remaining two links, by operating in the Bc region.
8-68
68P02900W21-T
Jul 2010
Gb link (for Ethernet Gb)
Burst excess rate (Be)

The Be is the maximum amount of uncommitted data (in bits) in excess of Bc that a frame
relay network can attempt to deliver, during a time interval Tc. The network treats Be data
as discardable.

The Ethernet Gb link can carry both the data traffic and NS signaling. The number of required
100M/1000M Ethernet Gb links are calculated using the principle that average throughput of
each Ethernet GBL does not lead the 70% of PPROC CPU_usage exceeded under the standard
call model and with the PRP function of the PPROC is fully loaded. Assume the traffic model of
downlink load/uplink load is 4:1, and use the downlink load only to calculate the required Gb
Ethernet links. The required Gb link NPCU-SGSNis calculated using the following equation:
NPCUSGSN =
Total Data Rate 8

+1
GBL Throughput ETH
+1 in the previous equation refers to N+1 Ethernet GBL redundancy.

Where:
Is:
Total_Data_Rate
This is defined in the equation in Base formulae on page

8-66. It represents the required bandwidth (bps) for
GPRS/EGPRS data transmission over a GBL interface
between the PCU and SGSN after the protocol and
signaling overhead per call model is accounted for.
GBL_Throughput_ETH
This indicates the average downlink throughput

on one Ethernet GBL without exceeding 70% of
the PPROC CPU_usage, while the PXP baseboard,
PPROC, and all PRP functions are fully loaded. To
support the peak/mean throughput ratio of 2:1 and
assume 4:1 traffic model of downlink load/uplink load,
GBL_Throughput_ETH is 5 Mbps for prp_fanout_mode
1 and 4.9 Mbps for prp_fanout_mode 2..
NPCU-SGSN
Number of Ethernet Gb links between PCU and SGSN.
Ethernet GBL/NSVC parameter values

The network planner needs to specify the values for the following Ethernet GBL/NSVC
parameters:
NS_VC signaling weight.
NS_VC data weight.
These IP based NS_VC parameter values are determined as follows:
68P02900W21-T
8-69
Jul 2010
The NS_VC load sharing function for the IP sub-network determines the local IP endpoint
and the remote IP endpoint based on the weight information provided by the peer NSE.
Each NSE uses load sharing function to distribute the traffic in equal proportion to the
relative weights assigned by the peer NSE. Both signaling-weights and data-weights have
a value range of 0 to 255.
Outgoing BVCI = 0 NS-SDUs are sent to a remote IP endpoint according to the signaling
weight assigned by the peer NSE. The sending NSE distributes these messages in equal
proportion to the signaling weights assigned to the peer IP endpoints of the NSE.
Following are the examples for signaling weight equal proportion selection:
If the IP endpoint (A) has signaling weight = 5 and the IP endpoint (B) has signaling weight
= 10, the IP endpoint (B) is selected as the signaling IP endpoint is twice as often as
the IP endpoint (A).
If the IP endpoint (A) has signaling weight = 10 and the IP endpoint (B) has signaling
weight = 10, IP endpoint (A) and IP endpoint (B) are selected as the signaling IP endpoint
is on an equal basis.
If the IP endpoint (A) has a signaling weight = 0, IP endpoint (A) is not selected as the
signaling IP endpoint.
For each BVCI>0 NS-SDU, the PCU selects a remote IP endpoint based on the LSP for sending
the NS-SDU to the peer NSE. Remote IP endpoints are selected in equal proportion to the
data-weights assigned to the endpoints of the peer NSE. A data weight of 0 assigned to an IP
endpoint indicates that the load sharing function is not initially associated with this remote IP
endpoint to an LSP. However, if an LSP is already associated with a remote IP endpoint, NS
SDUs associated with the LSP are sent to this remote IP endpoint regardless of their data
weight, that is, even when the data weight has a value of 0. (This association of the LSP to the
IP endpoint with a data weight of 0 may have been requested by the remote NSE through the
Resource Distribution Function.)
Following are the examples for data weight equal proportion selection:
If the IP endpoint (A) has data weight = 5 and endpoint (B) has data weight = 10, the
endpoint (B) is selected for initial association with an LSP twice as often as endpoint (A).
If the IP endpoint (A) has data weight = 10 and the endpoint (B) has data weight = 10,
endpoint (A) and endpoint (B) are selected for initial association with an LSP on an equal
basis.
If the IP endpoint (A) has a data weight = 0, the IP endpoint (A) is selected for initial
association with an LSP. However, the IP endpoint (A) may be associated with an LSP using
the peer NSE of the Resource Distribution Function.
Once a remote IP endpoint is selected for the LSP, the NSE maintains a link between the LSP
and the remote IP endpoint so that NS SDUs with the same LSP are directed to the same remote
IP endpoint. If a remote IP endpoint associated with an LSP is taken OOS, another remote IP
endpoint is selected according to the data-weights assigned by the peer NSE and the associated
LSP. The association of an LSP to a remote IP endpoint can be changed by the peer NSE using
the Resource Distribution function.
8-70
68P02900W21-T
Jul 2010
As the signaling NSVC may share the same local socket, physical Ethernet port and IP route
as data traffic along the path to the SGSN, configure the data and signaling NSVCs different
GBL/ETH links. For example, configure one NSVC with non-zero signaling weight and zero
data weight, so this NSVC can be guaranteed for NS signaling traffic overcoming the priority
handling problem for signaling traffic during periods of high data traffic. However, this will
exhaust more GBL/ETH port resource, so it is important to balance the resource between
signaling and data traffic. With the above configuration, however, there may be situations
where GPRS becomes OOS due to either all signaling or all data NSVC being OOS. During such
a situation, PCU will trigger the appropriate NSVC failure alarm and block all BVCs under
this BSS/PCU. For signaling and data, NSVCs are separated in different GBL/ETH links. N+1
GBL/ETH link redundancy should be considered for signaling and data NSVCs separately.
To ensure that the traffic is load shared according to the data/signaling weights, full mesh
connectivity (any IP endpoint in an NSE is capable of communicating with any IP endpoint in
its peer NSE as shown in Figure 8-13) between the PCU and SGSN is necessary. The number
of NSVCs required for full mesh connectivity between the PCU and SGSN is the product of
the number of IP endpoints supported on each side. It is recommended to configure the
signaling/data weight to each remote IP endpoint with the consistent value for the full mesh
connection.
Figure 8-13 Gb over IP full mesh connectivity between PCU and SGSN
SGSN
IP Endpoint
IP Endpoint
Weight = 3
Weight = 2
Weight = 1
IP Endpoint
ETH
port
ETH
port
PXP
BASE
PCU
PPROC
PXP
BASE
PPROC
ti-GSM-Gb over_IP full mesh_connectivity_btwn_PCU_SGSN-00142.a-ai-sw
68P02900W21-T
8-71
Jul 2010
BSS-PCU hardware planning example for GPRS
BSS-PCU hardware planning example for GPRS
Introduction
This section provides an example of the PCU hardware provisioning process and the link
provisioning process associated with adding a PCU to the BSC as shown in Figure 8-14. For
the provisioning of the BSC hardware, the network planner should follow the relevant planning
rules for adding additional E1 interface hardware in support of the GDS and GSL links.
The provisioning of the SGSN hardware is not covered in this planning guide. The QoS feature
is not enabled.
Figure 8-14 PCU equipment and link planning for GPRS
GDS+GSL
E1 or ETH
BSC
GBL
PCU
E1 or ETH
SGSN
GSM GPRS E1
BTS
ti-GSM-PCU_equipment_and_link_planning_for_GPRS-00143-ai-sw
BSS - PCU planning example for GPRS

Use this example to provision a BSS with 10 sites consisting of 20 cells, one GPRS carrier per
cell, PCCCH disabled (pccch_enabled = 0) at cells, and with the following GPRS call model:
Table 8-21 GPRS call mode

Item
Value
Average packet size (bytes)
PKSIZE = 310.08
Traffic per sub/BH (kBytes/hr) - uplink
ULRATE = 33.46
Traffic per sub/BH (kBytes/hr) - downlink

Data rate_per sub = 90.73

PSattach/detach = 0.5
Continued
8-72
68P02900W21-T
Jul 2010
Table 8-21 GPRS call mode (Continued)

Item
Value
PDPact/deact = 0.4

sub/BH)
RAU = 1.4
Routing area update

Cell Updates
CellUpdate = 0.33
PGPRS = 18.73

GPRS users per cell
200
Average sessions per user per hour

GSM circuit-switched paging rate
(pages/second)
0.45
PGSM = 60
LCS = 0.1
LRMT = 0.95

Ratio of mobiles in the system that are both
GSM and GPRS capable
NGSM GPRS Ms/NaII MS = 0.25
Total number of cells in the BSS
20
TRAU TYPE
64
Mobile Class Type
10
CS utilization
CS
Distribution
Rate
CS1
20%
8 kbps
CS2
45%
12 kbps
CS3
25%
14.4 kbps
CS4
10%
20 kbps
Selecting a cell RF plan

Use the 4 x 3 non-hopping table (Table 8-21) to determine what values to use for CS rate and
BLER for the selected cell RF plan.
Determining the number of CCCHs at each BTS cell

Use the following equation:
NPAGCH = (NAGCH + NPCH) /UCCCH

When pccch_enabled = 0 (PCCCH disabled) at the cell, the BTS combines the additional
control channel load for the GPRS data traffic with the existing circuit-switched traffic load onto
the CCCH. On the other hand, when pccch_enabled = 1 at the cell, GPRS does not add any
additional control channel load on the CCCH. In this case, however, PCCCH reduces the GSM
circuit-switched signaling load on the CCCH.
68P02900W21-T
8-73
Jul 2010
The network planner is required to consider paging coordination, the expected paging rate and
the access grant rate to calculate the number of CCCH blocks needed. Perform this calculation
using the guidelines given in the Control channel calculations on page 3-52 section of Chapter 3
BSS cell planning.
Determining the number of GPRS carrier timeslots at each BTS cell

Use the equation to determine the number of GPRS timeslots that are required on a per cell
basis. To use this equation, the network planner should have the expected cell load in kbps.
M ean traf f ic load =
T S Data Rate =
GP RS U sers Data rate per sub downlink 80bits/byte

3600
= 200 90.73 8/3600 = 40.32kbit/s
4
(8 20 + 12 45 + 14.4 25 + 20 10)
1 X
Csi ERate CSi U tilization =
100 i=1
100
N o P DCH T S = Roundup
= 12.6kbit/s
M ean T raf f ic load M ean load f actor

NP BCCH + NP AGCH + NP P CH
+
T S Data Rate
12

40.32 2
4 + 0.0264 + 38.71
= Roundup
+
= 11
12.6
12
Calculating the number of active timeslots

Assuming that coverage is to be provided to at least half of the timeslots at any instance, the
number of mean 11/2 = 6 PDTCHs (from Determining the number of GPRS carrier timeslots at
each BTS cell on page 8-74), the number of active timeslots is:
6 active timeslots per cell * 20 cells per BSC = 120 active timeslots
If the number of active timeslots exceeds the limit for one PCU, move those cells to another BSS.
Calculating the number of PRP boards and E1 GDS needed

Each PRP board can process 30 active timeslots at any given time for a total of 120 timeslots.
Using the value calculated in Partitioning the load across another PCU (another BSS), the
number of PRPs required to serve 20 cells is:
120 active timeslots/30 active timeslots per PRP = 4 PRPs
These four PRPs have more than enough capacity to handle the additional three standby
timeslots per cell.
Compute the number of GDS TRAU E1 channels required for the air interface timeslots required
to carry the traffic. Remember:
8-74
Each CS1/CS2 timeslot requires 16k TRAU channel, CS3/CS4 timeslots requires 32k TRAU
on GDS TRAU interface.
68P02900W21-T
Jul 2010
CS3/CS4 is enabled on a carrier hence all the GPRS timeslots for that carrier would
require 32k TRAU.
Using the conservative provisioning rule of one GDS TRAU E1 per PRP, 4 GDS TRAU E1s are
provisioned.
Refer to the appropriate section of this chapter for the PCU provisioning rules.
Calculating the BSC LCF impact to support GPRS traffic

The volume of GPRS signaling traffic increases the BSC LCF GPROC processor load. Use the
BSS planning rule for LCF provisioning in the following equation.

GL3 GP RS = 0.002 T otal RACH/sec 1 RP CCH Cells + 0.00075 B PGP RS P CCCH BSS
200 20 5
) (1 0.5) + (0.00075 10) (18.73 1) = 0.146
= 0.002 (
5
Where B is the number of BTS sites.
In this instance, B=10.
The network planner can select to add an additional LCF GPROC or to examine the GSM
circuit-switched provisioning to check if an existing LCF GPROC can process this additional load.
Calculating the number of GBL links

Using the standard traffic model and Gb formulae:
Signalling Data Rate =

21 Cellupdate + 312 P SAttach/Detach + 125 RAU + 172 P DPAct/Deact
+ 89 PGP RS
3600
(21 0.33+312 0.5+125 1.4+172 0.4) 20 200
+ 89 18.73
=
3600
= 2119bytes/s

GP RS U sers P CU Data rate per sub 1000
U ser Data Rate =
+ 1 + P K71
3600
SIZE

71
90.73 1000
1 + 310.08
= 123894 bytes/s
= 200 20 3600

Signaling Data Rate+U ser Data Rate
N o GBL T S = Roundup Data Rate
P er GBL U tilizationGBL

= Roundup 2119+123894
= 63
8000 0.25
N o GBL T S
63
=
= 2.03
NP CU SGSN =
31
31
Hence, 3 Gb links have to be provisioned.
If the ETH GBL is used as the Gb over IP feature enabled, then:
NPCUSGSN = Roundup

(2119 + 123894) 8
+1
GBL T hroughput ET H
Considered the GBL_Throughput_ETH is 5 Mbps, hence, provide 2 Gb links.

68P02900W21-T
8-75
Jul 2010
Calculating the number of GSL links

Use the following equation to calculate how many 64 kbits/s GSL links are required. For this
example, the number of users on a PCU is 5000. It assumes that all 20 cells parented to a single
LCF card in the BSC, after performing this step. Evaluating this equation and the supporting
expressions results in one 64 kbps GSL link being required, assuming that enhanced one phase
is enabled, after rounding up to the nearest integer value (but not including redundancy).
Refer to Determining the number of GSLs required on page 6-50 in Chapter 6 BSC planning
steps and rules for further details on the following equations.
T otal cells GP RS users per cell Averagesessions
3600
(20 200) (0.45)
=
= 0.5/s
3600
number of P CCCH enabled cells
= 10/20 = 0.5
=
total number of cells in BSS
(1 0.5) 0.5 7.5
GSLRACH =
= 0.075
1000 0.25

8.5 18.73 1 1
GSLP aging =
= 0.64
1000 0.25
T otal RACH/sec =
RP CCH Cells
The number of GSL TSs for run time is represented by:
GSLrun time = GSLP aging + GSLRACH = ROU N D U P (0.64 + 0.075) = 1

The number of GSLs required is:

GSL = M AX GSLrun time , GSLinit time = M AX (1, 6) = 6
Calculating the PCU hardware to support the PCU traffic

To calculate the PCU hardware for supporting the PCU traffic, consider the following
requirements.
4 PRP boards, 1 PRP board per GDS E1 link.
2 PICP board, 1 PICP board to process GDS LAPD and GBL link and the other PICP board
for GBL links.
1 MPROC board per PCU shelf (2 for redundancy).
1 PCU shelf with alarm board and 3 power supply/fan assemblies, 1 PCU shelf per 9 PRP
boards.
1 PCU cabinet per 3 PCU shelves (cages).
After calculating the number of GDS, GBL and GSL E1 links, ensure that there are sufficient
number of PICP boards to cover the GBL and GSL E1 links. The PCU hardware calculation
calculates the number of PICP boards based only on the ratio of PICP boards to PRP boards.
The following calculation takes into account the number of E1 links terminated on the PICP
boards for the GBL and GSL E1 links. A PICP board can terminate both GBL and GSL links on
the board, but not on the same PMC module. Each PICP has two PMC modules.
8-76
68P02900W21-T
Jul 2010
Two E1 links are required for the GBL. Each PICP can terminate up to 3 GBL links. Therefore,
2 PICPs are required for the GBL E1 links.
One E1 link is required for the GSL (redundant GSL not provided). Each PICP can terminate up
to 2 E1 GSL links and up to 12 GSL 64 kbps timeslots distributed over two E1s.
NOTE
There is a limit of 2 GSL E1s per PCU. Therefore, 1/4 of a PICP is required for the
GSL E1 link.
The GBL and GSL E1 link requirements show that 2 PICPs are sufficient to process the link
provisioning requirements.
Calculating the increased data traffic load on the E1s between the BSC
and BTSs
It is assumed that the GPRS traffic is in addition to the existing circuit-switched traffic. Six
timeslots are required for the GPRS timeslot traffic on a per cell basis. Therefore, an additional
12 x 16 kbits/s timeslots (CS1/CS2) or 32 kbps timeslots (CS3/CS4) are required on a per BTS
site basis, 2 cells per site, to carry the GPRS traffic.
The allocation of GPRS carrier timeslots has to be decided, that is, they are reserved or
switchable. GSM circuit-switched statistics can be used to decide about the allocation. Refer to
Dynamic timeslot allocation on page 3-76 in Chapter 3 BSS cell planning.
Calculating the changes in signaling traffic load (RSL load) on the E1s
between the BSC and BTSs
For cells without PCCCH (pccch_enabled = 0), the BTS combines the additional signaling
load for the GPRS data traffic with the existing circuit-switched traffic load. This results in an
additional load on the existing RSL links between each BTS and the BSC. For cells with PCCCH,
GPRS does not add significant additional control channel load on the RSL. In this case, however,
PCCCH reduces the GSM circuit-switched signaling load on the RSL with paging coordination.
The new load on the RSL for GPRS is based on the evaluation of the following equation and
other supporting equations.
Refer to Determining the number of RSLs required on page 6-22 in Chapter 6 BSC planning
steps and rules for further details on the following equation.
RSLGP RS + GSM = RSLGP RS + RSLGSM

Perform the GSM RSL calculation with 64 kbps RSL to be consistent with the GPRS calculation.
BSC link provisioning impact

The BSC needs additional hardware to support the addition of the GPRS network traffic. For
BSC provisioning, refer to the planning rules given in Chapter 6 BSC planning steps and rules.
The BSC needs more E1 terminations in support of the additional E1 links to the PCU and in
support of the additional GPRS traffic over the BTS to BSC interface. In this example, 4 E1s
were added for the GDS links and 3 E1s added for the GSL link.
68P02900W21-T
8-77
Jul 2010
BTS provisioning impact

GPRS has no impact on the hardware provisioning of a Horizon II macro, Horizonmacro or
M-Cell BTS.
8-78
68P02900W21-T
Jul 2010
BSS-PCU hardware planning example for EGPRS
BSS-PCU hardware planning example for EGPRS
Introduction
NOTE
This section builds upon the previous example shown in BSS-PCU hardware planning
example for GPRS on page 8-72 by adding EGPRS into the system.
The main additions are:
New EGPRS carriers.
Calculation of the impact of increased data capacity on the system.
The provisioning of the SGSN hardware is not covered in this planning guide.
Figure 8-15
PCU Equipment and link planning for EGPRS
GDS+GSL
E1 or ETH
BSC
GBL
PCU
E1 or ETH
SGSN
GSM EGPRS E1
BTS
ti-GSM-PCU_equipment_and_link_planning_for_EGPRS-00144-ai-sw
BSS - PCU planning example for EGPRS

The example for EGPRS has new call model parameters for increased data usage.
NOTE
Refer to BSS - PCU planning example for GPRS on page 8-72 to compare the
GPRS/EGPRS call model parameters.
68P02900W21-T
8-79
Jul 2010
Use this example to provision a BSS with 10 sites consisting of 20 cells, one GPRS carrier per
cell, PCCCH disabled (pccch_enabled = 0) at cells.
Additional data
The QoS feature is not enabled. Add one EGPRS carrier per cell with the following call model:
Table 8-22
EGPRS call model

Item
Value
Average packet size for GPRS and EGPRS traffic mix

(bytes)
PKULSIZE = 188.71

(bytes)
PKDLSIZE = 435.97
GPRS and EGPRS Traffic per sub/BH (kBytes/hr) - uplink

GPRS and EGPRS Traffic per sub/BH (kBytes/hr) downlink
ULRATE = 35.59
PSATT/DETACH = 0.5
PDPACT/DEACT = 0.4
Routing area update

Cell Updates
RAU = 1.4
CellUpdate = 0.33
PGPRS = 18.73
GPRS/EGPRS users per cell
250
0.45
GSM circuit-switched paging rate (pages/second)
PGSM = 60
LCS = 0.1

Ratio of mobiles in the system that are both GSM and
GPRS capable
Percentage of mobiles that are EGPRS capable
LRMT = 0.95
NGSM GPRS MS/NAU MS = 100%
5%
Continued
8-80
68P02900W21-T
Jul 2010
Table 8-22
EGPRS call model (Continued)

Item
Value
20

CS
CS utilization
Distribution Rate
CS1
10%
CS2
22.5%
12
CS3
12.5%
14.4
CS4
5%
20
MCS1
5%
8.8
MCS2
4%
11.2
MCS3
16.5%
14.8
MCS4
0.5%
17.6
MCS5
10.5%
22.4
MCS6
7.5%
29.6
MCS7
2.5%
44.8
MCS8
1.5%
54.4
MCS9
2%
59.2
Total
100%

Use the 4 x 3 non-hopping table (Table 3-16 in Chapter 3 BSS cell planning) to determine the
values to use for CS rate and BLER for the selected cell RF plan.

NP AGCH = (NAGCH + NP CH ) /U CCCH

circuit-switched signaling load on the CCCH with paging coordination. The network planner is
required to consider paging coordination, the expected paging rate, and the access grant rate to
calculate the number of CCCH blocks needed.
Perform this calculation using the guidelines given in Control channel calculations on page
3-52 in Chapter 3 BSS cell planning.
68P02900W21-T
8-81
Jul 2010
Determining number of GPRS and EGPRS carrier timeslots at each BTS cell
basis. To use this equation, the expected cell load in kbps should be known.
GP RS U sers Data rate per sub 8 bits/byte

3600
250 92.38 8
=
= 51.32kbit/s
3600
!
i=4
9
X
X
Csi Rate Csi distribution +

M Csi Rate M CSi distribution
M ean T raf f ic Load =
T S Data Rate =
1
100
i=1
i=1
17.41 kbit/s
M ean T raf f ic load M ean Load f actor

T S Data Rate

51.32 2
= Roundup
=6
17.41
Therefore, provide 6 timeslots on the cell. If the number of users, Mean_traffic_load and
TS_Data_Rate has increased with the EGPRS capabilities, the timeslots calculation does not
increase as per the GPRS calculation. The new equation provides 6 timeslots but these are
divided between GPRS and EGPRS. In this example, l has 8 GPRS timeslots configured as
switchable or packet data from the original GPRS carrier and 8 timeslots defined as packet data
for the new EGPRS carrier for a total of 16 data capable timeslots per cell. This is a total of
320 data capable timeslots.

For prp_fanout_mode1, a PRP board can be assigned up to 120 timeslots but only 30 can be
serviced (active) at any given time. A PXP board can be assigned up to 280 timeslots but only 70
can be serviced (active) at any given time. For prp_fanout_mode2, 48 timeslots provisioned
by a PRP can be served at any given time interval. 140 timeslots provisioned by a PXP can be
served at any given time interval. The PRP/PXP algorithms handle the scheduling of timeslots
efficiently, depending on the available resources.
Assuming that PXP is used and prp_fanout_mode1 to provide coverage:
Active Timeslots per PXP = 70
Supported Timeslots per PXP = 280
Since the equation resulted in 6 timeslots and the cell has 16 timeslots between GPRS and
EGPRS, the total active timeslots and supported timeslots are:
Total active timeslots = 6*20 = 120
Total supported timeslots = 16*20 = 320
8-82
68P02900W21-T
Jul 2010
Calculating the number of PXP boards

Each PXP board can process 70 active timeslots at any given time for a total of 280 timeslots.
Using the value calculated in Calculating the number of active timeslots on page 8-82 and the
number to assign to each PXP, the following equation is created:
Round Up (120 active timeslots/70 active timeslots per PXP) = 2
Round Up (320 supported timeslots/280 supported timeslots per PXP) = 2
The number of PXP = MAX (2,2) =2
The 2 ETH links are required based on 2 PXPs.
NOTE
Each PXP must terminate one GDS TRAU_LAPD ETH link and the timeslots of an
entire cell must terminate on the same PXP.
Calculate the number of tdm_ts_blocks for GDS ETH links

Based on the analysis in step 5, one PXP can support 160 timeslots. It requires 5 TDM_TS_Blocks
for each GDS ETH link. But considering the capacity enhancement in the future and the
situation one PXP failure, 10 tdm_ts_blocks is recommended.

The volume of GPRS and EGPRS signaling traffic increases the BSC LCF GPROC2 processor
load. Use the BSS planning rule for LCF provisioning in the following equation.

0.002 T otal RACH/sec 1 RP CCCH Cells + 0.00075 B
P
P CCCH BSS

GP RS
250 20 0.45
= 0.002
(1 0.5) + 0.00075 10 18.73 1 = 0.14
3600
GL3 GP RS =
An additional LCF GPROC2 can be added or the GSM circuit-switched provisioning can be
examined to check if an existing LCF GPROC2 can process this additional load.
68P02900W21-T
8-83
Jul 2010

21 CellU pdate + 312 P SAttach/Detach + 125 RAU + 172 P DPACT /Deact

Signaling Data Rate =
+ 89 PGP RS
3600
(21 0.33 + 312 0.5 + 125 1.4 + 172 0.4) 20 250
=
+ 89 18.73
3600
= 2649 bytes/s

71
U ser Data Rate =
1+
3600
P KSIZE

250 20 92.38 1000

71
=
1+
= 149200.77 bytes/s
3600
435.97
T otal Data rate
2649 + 149200.77
N o GBL T S =
=
= 75.92
8000 UGRI
8000 0.25
NP CU SGSN = N o GBL T S/31 = 75.92/31 = 2.45
Hence, provide 3 Gb links.

If the ETH GBL is used s the Gb over IP feature enabled:
NPCUSGSN = Roundup

(2119 + 123894) 8
+1
GBL T hroughput ET H
Considered the GBL_Throughput_ETH is 4.9 Mbps in prp_fanout_mode 2, hence, provide

2 Ethernet GBL link.

Use the following equation to calculate the number of 64 kbits/s GSL links required. In this
example, the number of users on a PCU is 5000. It assumes that all 20 cells are attached to a
single LCF card in the BSC. Evaluating this equation and the supporting expressions results
in one 64 kbps GSL link being required, assuming that preload is enabled, after rounding up
to the nearest integer value (but not including redundancy).
steps and rules for further details on the following equations:
T otal RACH/sec = 20 250 0.45/3600 = 0.625
GSLRACH = (1 0.5) 0.625 5.5/ (1000 0.25) = 0.006875

GSLP aging = 8.5 18.73 1 1/ (1000 0.25) = 0.64
The number of GSL TS for run time is represented by:
GSLrun time = GSLRACH + GSLP aging = Roundup (0.006875 + 0.64) = 1
8-84
68P02900W21-T
Jul 2010
The number of GSL required is

GSL = M AX GSLrun time, GSLinit time = 6

The following is the required PCU hardware:
2 PXP boards, 2 GDS ETH links (GDS TRAU_LAPD) with the PXPs.
3 GBL balanced across 2 PXPs.
1 MPROC board, 1 MPROC board per PCU shelf (2 for redundancy).
1 PCU shelf with alarm board and 3 power supply/fan assemblies, 1 PCU shelf per 12
PXP boards.
1 PCU cabinet, 1 PCU cabinet per 3 PCU shelves.
After calculating the number of GDS, GBL, and GSL links, ensure that there are a sufficient
number of PXP boards to cover the GBL and GSL links. Both GBL and GDS TRAU_LAPD links
can terminate on a PXP board. Each PXP has two PMC modules supporting 2 GBL and 1 RJ45
port supporting 1 ETH link.
and BTSs
It is assumed that the EGPRS traffic is in addition to the existing circuit-switched traffic and
GPRS traffic already available in the system. In Determining the number of CCCHs at each BTS
cell on page 8-88, it was determined that 8 timeslots would be required for the EGPRS required
on a per BTS site basis, 2 cells per site, to carry the GPRS traffic.
A decision can be made at this stage of the provisioning process on how to allocate the EGPRS
carrier timeslots. When EGPRS enabled, all reserved and switchable timeslots are backhauled
from the BTS through the BSC to the PCU. The physical link calculations must take this
into account. The CPU processing equations require to take into account the percentage of
backhauled timeslots that are active at a given time interval. If GSM circuit-switched statistics
are available, they could be reviewed to aid in this decision. Refer to Dynamic timeslot allocation
on page 3-76 in Chapter 3 BSS cell planning.
For cells without PCCCH (pccch_enabled = 0), the BTS combines the additional signaling load
for the EGPRS data traffic with the existing circuit-switched traffic load. This results in an
EGPRS does not add significant additional control channel load on the RSL. In this case, however,
68P02900W21-T
8-85
Jul 2010
BSS - PCU planning example for EGPRS with QoS enabled, QoS2 not enabled
other supporting equations. Refer to Determining the number of GSLs required on page 6-50 in
Chapter 6 BSC planning steps and rules for further details on the following equation.

Perform the GSM RSL calculation with 64 kbps RSL to be consistent with the EGPRS calculation.

The BSC can need additional hardware to support the addition of the EGPRS network traffic. For
BSC provisioning, refer to the planning rules given in Chapter 6 BSC planning steps and rules.
The BSC needs more E1 terminations in support of the additional EGPRS traffic over the BTS to
BSC interface.
BSS - PCU planning example for EGPRS with QoS enabled,

QoS2 not enabled
This example uses the same base call model parameters as those parameters used in BSS - PCU
planning example for EGPRS on page 8-79 except that the QoS feature is enabled. Specify new
call model parameters based on QoS usage as the QoS requirement.
NOTE
Refer to BSS - PCU planning example for EGPRS on page 8-79 to compare the
Additional data
The QoS feature is enabled.
Add one EGPRS carrier per cell with the following call model:
Table 8-23
EGPRS with QoS enabled call model

Item
Value
Average packet size for GPRS and

EGPRS traffic mix (bytes)
PKULSIZE = 188.71
Average packet size for GPRS and

EGPRS traffic mix (bytes)
PKDLSIZE = 435.97
GPRS and EGPRS Traffic per sub/BH

(kBytes/hr) - uplink
ULRATE = 35.59

(kBytes/hr) - downlink
Continued
8-86
68P02900W21-T
Jul 2010
System Information: BSS Equipment Planning BSS - PCU planning example for EGPRS with QoS enabled, QoS2 not enabled
Table 8-23 EGPRS with QoS enabled call model (Continued)

Item
Value
PSATT/DETACH = 0.5

sub/BH)
PDPACT/DEACT = 0.4
Routing area update

Cell Updates
RAU = 1.4
CellUpdate = 0.33
PGPRS = 18.73
250

(pages/second)
PGSM = 60
LCS = 0.1
LRMT = 0.95
Ratio of mobiles in the system that are

both GSM and GPRS capable
Percentage of mobiles that are EGPRS

capable
5%
20
I1_MTBR
14
I2_MTBR
10
I3_MTBR
BG_MTBR
BE_MTBR
I1_MTBR_USAGE
5%
I2_MTBR_USAGE
10%
I3_MTBR_USAGE
25%
BG_MTBR_USAGE
20%
BE_MTBR_USAGE
40%
TRAU Type
64
Mobile Class Type
10
Continued
68P02900W21-T
8-87
Jul 2010
Table 8-23 EGPRS with QoS enabled call model (Continued)

Item
Value
CS
CS distribution
Distribution
Rate
CS1
10%
CS2
22.5%
12
CS3
12.5%
14.4
CS4
5%
20
MCS1
5%
8.8
MCS2
4%
11.2
MCS3
16.5%
14.8
MCS4
0.5%
17.6
MCS5
10.5%
22.4
MCS6
7.5%
29.6
MCS7
2.5%
44.8
MCS8
1.5%
54.4
MCS9
2%
59.2
Total
100%

The PRP board headroom compensates the BLER required for QoS. The CS coding schemes
are set as pre-defined values determined by the QoS feature. For GPRS, the maximum rate is 8
k and for EGPRS the maximum rate is 14 k.


circuit-switched signaling load on the CCCH with paging coordination.
The network planner requires to consider paging coordination, the expected paging rate, and
the access grant rate to calculate the number of CCCH blocks needed. Perform this calculation
using the guidelines given in Control channel calculations on page 3-52 in Chapter 3 BSS cell
planning.
8-88
68P02900W21-T
Jul 2010
basis. To use this equation, the n expected cell load in kbps should be known.
GP RS U sers Data rate per sub 8 bits/bytes

3600
250 92.38 8
=
= 51.32 kbit/s
3600
!
i=4
9
X
X
CSi Rate CSi distribution +

M CSi Rate M CSi distribution
T S Data Rate =
1
100
i=1
i=1
17.41 kbit/s
M ean traf f ic load M ean load f actor

T S Data Rate

51.32 2
= Roundup
=6
17.41
The equation takes into account the amount of local timeslot headroom to allow to the required
MTBR. The mean load factor is set to 2 to accommodate peak data scenarios since the mean
traffic load is based on averages. The defined timeslot throughput and the PRP board headroom
allocated by the QoS feature cover the signaling peak periods.

A PRP board can be assigned up to 120 timeslots but only 30 are serviced (active) at any given
time. The PRP algorithms handle the scheduling of timeslots efficiently, depending on the
available resources. The QoS feature provides further guidelines on the number of timeslots to
assign to a PRP to achieve the requested MTBR per subscriber.
68P02900W21-T
8-89
Jul 2010
PRP board throughput is calculated as follows:
P RP BOARD T HROU GHP U T = T HRU P U T T S {(8000 %CSI U SAGE) +
(12000 %CS2 U SAGE) + (14400 %CS3 U SAGE) + ...... (20000 %CS4 U SAGE)
+ (8800 %M CS1 U SAGE) + (11200 %M CS2 U SAGE) + ......
(14800 %M CS3 U SAGE) + (17600 %M CS4 U SAGE) + (22400 %M CS5 U SAGE)
+...... (29600 %M CS6 U SAGE) + (44800 %M CS7 U SAGE) + (54400 %M CS8 U SAGE)
+...... (59200 %M CS9 U SAGE)} (100%16.7%)
= 30 {8000 10% + (12000 22.5) + (14400 12.5%) + (20000 5%) + (8800 5%) +}
{(11200 4%) + (14800 16.5%) + (17600 0.5%) + (22400 10.5%) + (29600 7.5%) +}
{(44800 2.5%) + (54400) (1.5%) + (59200 2%)} (100% 16.7%)
= 30 17410 83.3% + 435075 bps
AV ERAGEDOW N LIN KM T BR = (ST R EGBR %subs) + (IIM T BR %subs)
+ (12 M T BR %subs) + ...... (13 M T BR %subs) + (BG M T BR %subs)
+ (BE M T BR %subs) = 3.9 kbit/s
NOTE
% subs of STR_EGBR is 0.
Therefore,
MAX_QOS_PDCHS_PER_PRP = 435075/(3.9 * 1000) = 112
Calculating the number of PRP boards and GDS E1 links

The previous example had one GPRS carrier per cell that provided adequate throughput for
the calculated 6 timeslots. The new equation also provides 6 timeslots but these are divided
between GPRS and EGPRS. The new EGPRS carrier provides 8 timeslots of data capacity that is
the required 6. In this example, there are 8 GPRS timeslots configured as switchable or packet
data from the original GPRS carrier and 8 timeslots defined as packet data for the new EGPRS
carrier for a total of 16 data capable timeslots per cell.
This is a total of 320 data capable timeslots.
320 PDTCHs/112 MAX per board = 4 PRP boards.
There are about 5 cells per PRP supporting 80 PDTCHs.
Compute the number of GDS TRAU E1 channels required for the air interface timeslots required
to carry the traffic. Remember:
8-90
Each CS1/CS2 timeslot requires 16k TRAU channel,CS3/CS4 timeslots requires 32k
TRAU,MCS1 through MCS9 require a variable VersaTRAU backhaul in units of 64k DS0s
on the GDS TRAU interface.
68P02900W21-T
Jul 2010
NOTE
The example here assumes that each EGPRS RTF is equipped with a backhaul of
8 DS0s (rtf_ds0_count = 8). This is the worst case. Typical configuration may
require less GDS resources.
CS3/CS4 is enabled on a carrier hence all the GPRS timeslots for that carrier would
require 32k TRAU and the EGPRS carrier would require 64k TRAU.
Considering one PRP supporting 80 PDTCHs which half of them are carried by 32k TRAU and
half with 64k TRAU, 2 GDS E1s for every PRP and 8 GDS E1s to 4 PRPs. Refer to the appropriate
section of this chapter for the PCU provisioning rules.


GL3 GP RS = 0.002 T otal RACH/sec 1 RP CCCH Cells + 0.00075 B
= 0.002
PGP RS P CCCH BSS

250 20 5
(1 0.5) + 0.00075 10 1.4 1 = 0.017
3600
examined to check whether an existing LCF GPROC2 can process this additional load.


71
U ser Data Rate =
1+
3600
P Ksize

250 20 92.38 1000

71
=
1+
= 149200 bytes/s
3600
435.97
T otal Data rate
2649 + 149200
N o GBL T S =
=
= 75
8000 UGRI
8000 0.25
NP CU SGSN = N o GBL T S/31 = 75/31 = 2.42
Hence, 3 Gb links are required.

Use the following equation to calculate the number of 64 kbps GSL links required. In this
example, the number of users on a PCU is 5000. It assumes that all 20 cells are parented to a
68P02900W21-T
8-91
Jul 2010
steps and rules, for further details on the following equations.
T otal RACH/sec = (20 250) (5 + 2.86 + 0.78 + 1) /3600 = 13.39/s

RP CCCH Cells =
(number of P CCCH enabled cells) /total number of cells in the BSS

= 10/20 = 0.5
GSLRACH = ((1 0.5) 13.39 5.5) / (1000 0.25) = 0.147

GSLP aging = 8.5 0.32 1 1/ (1000 0.25) = 0.01
GSLrun time = GSLRACH + GSLP aging = Round U p (0.147 + 0.01) = 1



The following hardware is required:
4 PRP boards, 8 GDS E1 links (GDS) timeslot balanced across the PRPs.
2 PICP boards, 1 PICP board to process GDS LAPD (GSL) and 1 PICP board to process
the GBL traffic.
boards.
After calculating the number of GDS, GBL and GSL E1 links, ensure that there are a sufficient
number of PICP boards to cover the GBL and GSL E1 links. The PCU hardware calculation gives
the number of PICP boards based only on the ratio of PICP boards to PRP boards. The following
calculation takes into account the number of E1 links terminated on the PICP boards for the
GBL and GSL E1 links. A PICP board can terminate both GBL and GSL links on the board, but
not on the same PMC module. Each PICP has two PMC modules.
It was determined that 3 E1 links are required for the GBL. Each PICP can terminate up to 4
GBL links. Therefore, 3/4 of a PICP is required for the GBL E1 links.
It was determined that 1 E1 link is required for the GSL (redundant GSL not provided). Each
PICP can terminate up to 2 E1 GSL links and up to 60 GSL 64 kbps timeslots distributed over
two E1s. There is a limit of 2 GSL E1s per PCU. Therefore, 1/4 of a PICP is required for the
GSL E1 link. Due to the limitation that a PMC cannot share a GSL and GBL, a second PICP is
required. The GBL and GSL E1 link requirements show that one PICP is sufficient to process
the link provisioning requirements.
8-92
68P02900W21-T
Jul 2010
and BTSs
GPRS traffic already available in the system. 8 timeslots would be required for the EGPRS
timeslot traffic on a per cell basis. Therefore, to carry the GPRS traffic, additional 16 x 16 kbits/s
timeslots (MCS1 - MCS9) are required on a per BTS site basis, 2 cells per site.
A decision can be made at this stage on how to allocate the EGPRS carrier timeslots. When
EGPRS is enabled, all reserved and switchable timeslots are backhauled from the BTS through
the BSC to the PCU. The physical link calculations must take this into account. The CPU
processing equations require to take into account the percentage of backhauled timeslots that
are active at a given time interval. If GSM circuit-switched statistics are available, they can be
used. Refer to Dynamic timeslot allocation on page 3-76 in Chapter 3 BSS cell planning.
For cells without PCCCH (pccch_enabled = 0), the BTS combines the additional signaling
load for the EGPRS data traffic with the existing circuit-switched traffic load. This results in
an additional load on the existing RSL links between each BTS and the BSC. For cells with
PCCCH, EGPRS does not add significant additional control channel load on the RSL. In this
case, however, PCCCH reduces the GSM circuit-switched signaling load on the RSL with paging
coordination. The new load on the RSL for GPRS is based on the evaluation of the following
equation and other supporting equations.

To be consistent with the EGPRS calculation perform the GSM RSL calculation with 64 kbps RSL.

To support the addition of the EGPRS network traffic the BSC requires additional hardware.
Refer to the planning rules for BSC provisioning in Chapter 6 BSC planning steps and rules.
The BSC needs more E1 terminations in support of the additional E1 links to the PCU and in
support of the additional EGPRS traffic over the BTS to BSC interface. In this example, eight
E1s were added for the GDS links and one E1 added for the GSL link.
BSS - PCU planning example for EGPRS with QoS and QoS2
enabled
This example uses the same base call model parameters as those used in BSS - PCU planning
example for EGPRS on page 8-79 except that the QoS feature is enabled. QoS requires new
call model parameters to be specified based on QoS usage.
68P02900W21-T
8-93
Jul 2010
NOTE
See BSS - PCU planning example for EGPRS on page 8-79 to compare the
Additional data
The QoS feature is enabled.
Add two EGPRS carriers per cell with the following call model:
Table 8-24
EGPRS with QoS and QoS2 enabled call model

Item
Value

traffic mix (bytes)
PKULSIZE = 188.71

traffic mix (bytes)
PKDLSIZE = 435.97

(kBytes/hr) - uplink
ULRATE = 35.59

(kBytes/hr) - downlink
PSATT/DETACH = 0.45

sub/BH)
PDPACT/DEACT = 0.4
Routing area update

Cell Updates
RAU = 1.4
CellUpdate = 0.33
PGPRS = 18.73
250
0.45

(pages/second)
PGSM = 60
LCS = 0.1

Ratio of mobiles in the system that are both
GSM and GPRS capable
LRMT = 0.95
Percentage of mobiles that are EGPRS

capable
5%
Number of PCCCH-enabled cells in the BSS
10
20
STR_GBR1 (PoC)
8 kbps
STR_GBR2 (Audio)
10 bit/s
Continued
8-94
68P02900W21-T
Jul 2010
Table 8-24 EGPRS with QoS and QoS2 enabled call model (Continued)
Item
Value
STR_GBR2 (video)
18 kbps
I1_MTBR
14
I2_MTBR
10
I3_MTBR
BG_MTBR
BE_MTBR
STR_GBR1_USAGE
15%
STR_GBR2_USAGE
3%
STR_GBR3_USAGE
4%
I1_MTBR_USAGE
3%
I2_MTBR_USAGE
10%
I3_MTBR_USAGE
25%
BG_MTBR_USAGE
15%
BE_MTBR_USAGE
25%
TRAU Type
64
Mobile Class Type
10
CS distribution
CS
Distribution
Rate
CS1
10%
CS2
22.5%
12
CS3
12.5%
14.4
CS4
5%
20
MCS1
5%
8.8
MCS2
4%
11.2
MCS3
16.5%
14.8
MCS4
0.5%
17.6
MCS5
10.5%
22.4
MCS6
7.5%
29.6
MCS7
2.5%
44.8
MCS8
1.5%
54.4
MCS9
2%
59.2
Total
100%

The PRP board headroom compensates the BLER required for QoS. The CS coding schemes
are set as pre-defined values determined by the QoS feature. For GPRS, the maximum rate is 8
k and for EGPRS the maximum rate is 14 k.
68P02900W21-T
8-95
Jul 2010


When pccch_enabled = 0 (PCCCH disabled) at the cell, the BTS combines the additional control
channel load for the GPRS data traffic with the existing circuit-switched traffic load onto
circuit-switched signaling load on the CCCH with paging coordination.
To calculate the number of CCCH blocks required take into account the paging coordination, the
expected paging rate and the access grant rate. Perform this calculation using the guidelines
given in Control channel calculations in Chapter 3 BSS cell planning.
basis. To use this equation, the expected cell load in kbps should be known.
GP RS U sers Data rate per sub 8 bits/byte

3600
250 92.38 8
=
= 51.32kbps
3600
1=4
9
X
1 X
(
CSi Rate CSi distribution +
M CSi Rate M CSi Distribution)
T S Data Rate =
100 i=1
i=1
= 17.41kbps
M ean traf f ic Load M ean Load f actor

= N o P DCH T S = Roundup
T S Data Rate

NP BCCH + NP AGCH + NP P CGH
51.32 2
+
= Roundup
=6
12
17.41
The equation takes into account the amount of local timeslot headroom to allow to the required
MTBR. The mean load factor is set to 2 to accommodate peak data scenarios since the mean
traffic load is based on averages. The defined timeslot throughput and the PRP board headroom
allocated by the QoS feature cover the signaling peak periods.
8-96
68P02900W21-T
Jul 2010

A PRP board can be assigned up to 120 timeslots but only 30 are serviced (active) at any
given time. The PRP algorithms handle the scheduling of timeslots efficiently, depending on
resources available.
The QoS feature provides further guidelines on the number of timeslots to assign to a PRP to
achieve the requested MTBR per subscriber. PRP board throughput is calculated as follows:
Assuming initial coding scheme is CS2 and MCS3:
P RP BOARD T HROU GHP U T = T HRU P U T T S {(8000 CS1 U SAGE) + 12000
(%CS2 U SAGE + CS3 U SAGE + CS4 U SAGGE)} + {(8800 %M CS1 U SAGE) + (11200 %)
(M CS2 U SAGE) + 14800 (%M CS3 U SAGE + M CS4 U SAGE + M CS5 U SAGE+)
(%M CS6 U SAGE + %M CS7 U SAGE + %M CS8 U SAGE + %M CS9 U SAGE)} (100% 16.7%)
= 30 {(8000 10%) + (12000 22.5%) + 14400 (12.5% + 5%) + (8800 5%) + (11200 4%) +
(14800 16.5% + 0.5% + 10.5% + 7.5% + 2.5% + 1.5% + 2%)} (100% 16.7%)
= 30 12976 83.3% = 324270 bit/s
For streaming service, convert GBR to EGBR, assuming TD = 500 ms, BLER = 10%,
Average GBR = (8 15% + 10 3% + 18 4%) (15% + 3% + 4%) = 10.09 kbit/s
ST R EGBR = (10.09kbit/s, 500ms, rho = 0.62) / (1 + BLER) = 10.09/0.62 1.1 = 17.9 kbit/s
AV ERAGEDOW N LIN KM T BR = (ST R EGBR %subs) + (IIM T BR %subs) +
(12M T BR %subs) + ...... (13 M T BR %subs) + (BG M T BR %subs) + (BE M T BR %subs)

= (17.9 22%) + (14 3%) + (10 10%) + (4 25%) + (2 15%) + (2 25%) = 7.16 kbit/s
Therefore:
M AX QOS P DCHS P ER P RP = 324270/ (7.16 1000) = 45
If one PXP board (70TS), mode 1 is used, then
M AX QOS P DCHS P ER P RP = (70/30) 324270/ (7.16 1000) = 105
Calculating the number of PRP boards

The previous example had one GPRS carrier per cell that provided adequate throughput for
the calculated 6 timeslots. The new equation also provides 6 timeslots but these are divided
between GPRS and EGPRS. The new EGPRS carrier provides 8 timeslots of data capacity that is
above the required 6. In this example, there are 8 GPRS timeslots configured as switchable or
packet data from the original GPRS carrier and 8 timeslots defined as packet data for the new
EGPRS carrier for a total of 16 data capable timeslots per cell.
68P02900W21-T
8-97
Jul 2010
This is a total of 320 data capable timeslots.
320 P DT CHs/45 M AX per board = 8 P RP boards

If PXP board is used,
320 P DT CHs/105 M AX per board = 4 P RP boards

The provisioning of the 8 GDS E1s to 9 PRPs is required.
NOTE
Each PRP must terminate at least one GDS TRAU E1 and the timeslots of an entire
cell must terminate on the same PRP.


GL3 GP RS = 0.002 T otal RACH/sec 1 RP CCCH Cells + 0.00075 B
= 0.002
PGP RS P CCCH BSS

250 20 5
(1 0.5) + 0.00075 10 1.4 1 = 0.017
3600
examined to check whether an existing LCF GPROC2 could process this additional load.


71
U ser Data Rate =
1+
3600
P Ksize

250 20 92.38 1000

71
=
1+
= 149200 bytes/s
3600
435.97
T otal Data rate
2649 + 149200
N o GBL T S =
=
= 75
8000 UGRI
8000 0.25
NP CU SGSN = N o GBL T S/31 = 75/31 = 2.42
Hence, 3 Gb links are required.
8-98
68P02900W21-T
Jul 2010

Use the following equation to calculate the number of 64 kbits/s GSL links required. For this
example, the number of users on a PCU is 5000. It assumes that all 20 cells are parented to a
steps and rules for further details on the following equations.
T otal RACH/sec = (20 250) (5 + 2.86 + 0.78 + 1) /3600 = 13.39/s
RP CCCH Cells = (number of P CCCH enabled cells) /total number of cells in the BSS = 10/20 = 0.5
GSLRACH = (1 0.5) 13.39 5.5/ (1000 0.25) = 0.147
GSLP aging = 8.5 0.32 1 1/ (1000 0.25) = 0.01
GSLrun time = GSLRACH + GSLP aging = Round U p (0.147 + 0.001) = 1



The following hardware is required:
4 PXP boards, 4 ETH links (GDS) timeslot balanced across the PRPs.
3 Gb links.
boards.
After calculating the number of GDS, GBL, and GSL E1 link, ensure that there are a sufficient
number of PICP boards to cover the GBL and GSL E1 links. The PCU hardware calculation
calculates the number of PICP boards based only on the ratio of PICP boards to PRP boards.
The following calculation takes into account the number of E1 links terminated on the PICP
boards for the GBL and GSL E1 links. A PICP board can terminate both GBL and GSL links on
the board, but not on the same PMC module. Each PICP has two PMC modules.
It was determined that 3 E1 links are required for the GBL. Each PICP can terminate up to 4
GBL links. Therefore, 3/4 of a PICP is required for the GBL E1 links.
It was determined that one E1 link is required for the GSL (redundant GSL not provided). Each
PICP can terminate up to 2 E1 GSL links and up to 60 GSL 64 kbps timeslots distributed over two
E1s. There is a limit of 2 GSL E1s per PCU. Therefore, 1/4 of a PICP is required for the GSL E1
link. Due to the limitation that a PMC cannot share a GSL and GBL, a second PICP is required.
68P02900W21-T
8-99
Jul 2010
The GBL and GSL E1 link requirements show that one PICP is sufficient to process the link
provisioning requirements.
and BTSs
GPRS traffic already available in the system. 8 timeslots are required for the EGPRS timeslot
traffic on a per cell basis. Therefore, an additional 16 x 16 kbits/s timeslots (MCS1 - MCS9) are
required on a per BTS site basis, 2 cells per site, to carry the GPRS traffic.
A decision can be made at this stage on how to allocate the EGPRS carrier timeslots. When
EGPRS is enabled, all reserved and switchable timeslots are backhauled from the BTS through
the BSC to the PCU. The physical link calculations must take this into account. The CPU
processing equations require to take into account the percentage of backhauled timeslots
that are active at a given time interval. If GSM circuit-switched statistics are available, they
could be reviewed to aid in this decision. Refer to Dynamic timeslot allocation on page 3-76 in
Chapter 3 BSS cell planning.
For cells without PCCCH (pccch_enabled = 0), the BTS combines the additional signaling load
for the EGPRS data traffic with the existing circuit-switched traffic load. This results in an
EGPRS does not add significant additional control channel load on the RSL. In this case, however,
other supporting equations.
Refer to Determining the number of RSLs required on page 6-22 in Chapter 6 BSC planning

To be consistent with the EGPRS calculation perform the GSM RSL calculation with 64 kbps RSL.

To support the addition of the EGPRS network traffic the BSC requires additional hardware.
Refer to the planning rules for BSC provisioning, given in Chapter 6 BSC planning steps and
rules.
The BSC requires more E1 terminations in support of the additional E1 links to the PCU and in
support of the additional EGPRS traffic over the BTS to BSC interface. In this example, eight
E1s are added for the GDS links and one E1 added for the GSL link.
8-100
68P02900W21-T
Jul 2010
Chapter
9
Planning examples
This chapter explains the planning exercises designed to illustrate the use of the rules and
formulae. The tables of required equipment list only the major Motorola supplied items.
Equipment such as not cable, external power supplies, and air conditioning equipment are not
covered. Refer to the Motorola local office for assistance in ensuring that all necessary items
are purchased.
This chapter includes the following sections:
Pre-requisites on page 9-2
Exercises on page 9-4
Determine the hardware requirements for BTS B on page 9-5
Determine the hardware requirements for BTS K on page 9-8
Determine the hardware requirements for the BSC on page 9-11
Determine the hardware requirements for the RXCDR on page 9-14
Calculations using alternative call models on page 9-17
Planning example of BSS support for LCS provisioning on page 9-59
68P02900W21-T
Jul 2010
9-1
Pre-requisites
Pre-requisites
Requirements
In the area of interest, a demand analysis has identified the requirement for 11 BTSs with the
busy hour Erlang requirement shown in second column of Table 9-1.
Table 3-6 or Table 3-7 (depending on position in location area) in the Call model parameters
for capacity calculations on page 3-48 section of Chapter 3 BSS cell planning, provides the
maximum Erlang capacity for a given number of carriers at 2% blocking. The third column of
Table 9-1 provides the number of carriers (RTFs) required.
NOTE
If hr (AMR) is used, take hr usage into account for Erlang calculations.
If other blocking factors at the air interface are required, the number of Erlangs quoted in
Table 3-7 and Table 3-8 in the Call model parameters for capacity calculations on page 3-48
section of Chapter 3 BSS cell planning can be found by reference to standard Erlang B tables for
the equivalent number of traffic channels at the required blocking factor.
Table 9-1 Busy hour demand and number of carriers
9-2
BTS identification
Erlangs
Antenna configuration
Omni 2
Omni 2
Omni 1
Omni 2
14
Omni 3
10
Omni 3
Omni 2
Omni 1
Omni 2
20/20/20
Sector 4/4/4
Omni 2
Total
119
32 carriers
68P02900W21-T
Jul 2010
Network topology
Network topology
Using a frequency-planning tool, assigns adequate frequencies to support the BTS antenna
configurations of Table 9-1. Based on this, initial planning of the network gives the topology
shown in Figure 9-1.
Figure 9-1 Network topology

RXCDR
MSC
BSC
OMC-R
BTS K
BTS L
BTS A
BTS E
BTS B
BTS F
BTS C
BTS G
BTS D
BTS H
BTS J
ti-GSM-Network_topology-00145-ai-sw
68P02900W21-T
9-3
Jul 2010
Exercises
Exercises
Introduction
To illustrate the planning steps, the individual hardware requirements for BTS B and BTS K is
calculated, followed by the calculation to produce the hardware requirements for the BSC, and
RXCDR. The parameters required for the database generation they are noted.
The calculations for the hardware capacity use the standard call model given in Chapter 3 BSS
cell planning and Chapter 6 BSC planning steps and rules. Half rate usage is not specified
for this exercise.
9-4
68P02900W21-T
Jul 2010
Determine the hardware requirements for BTS B
Determine the hardware requirements for BTS B
From Figure 9-1 and Table 9-1, it can be seen that BTS B needs two RF carriers in an omni
configuration to carry a peak demand of five Erlangs.
Cabinet
From the site requirements and the potential future expansion it can be determined that this
site should be built using an M-Cell6 indoor cabinet. For the cabinet and any of the following
items, contact the Motorola local office if part numbers are required.
Main site number

Contact the Motorola local office if part numbers are required.
Interface option
Power redundancy
Duplexing
Only two antennas are used on this site, so specify duplexing. Contact the Motorola local
office if part numbers are required.
Digital redundancy
It is not considered that the purpose of this site justifies the expense of digital redundancy.
Alarm inputs
More that eight alarm inputs are not required, so nothing is needed here.
Memory
Non-volatile code storage is a requirement, it can download code in background mode. Contact
the Motorola local office if part numbers are required.
68P02900W21-T
9-5
Jul 2010
Summary
Database option
Summary
The equipment required and an example of customer order creation for an M-Cell6 indoor (900
MHz) configuration to implement BTS B is listed in Table 9-2 and Table 9-3.
Table 9-2
Customer ordering guide 900 MHz (M-Cell6 indoor)

Question
Compulsory
Voltage used
+27 V dc
-48 V/60 V dc
110/240 V ac
How many cells are required?
123
How many carriers are required per cell? (RF

configuration)
1 2345678
How many cabinets are required for the RF

configuration?
1234
What type of combining is required?
CBF (Hybrid)
CCB (Cavity)
3 I/P
CBF Air
What line interface is required?
T43 (E1) (75 ohm)

BIB (E1) (120 ohm)
Table 9-3
Customer ordering guide 900 MHz (M-Cell6 indoor)

Question
Options
Is link redundancy required?
Yes
No
Is digital redundancy required?
Yes
No
Is power redundancy required?
Yes
No
Is duplexing required?
Yes
No
Is a high-power duplexer shelf or external rack required?
Yes
No
Are 16-way alarm inputs required?
Yes
No
Is a memory card required?
Yes
No
Continued
9-6
68P02900W21-T
Jul 2010
Summary
Table 9-3 Customer ordering guide 900 MHz (M-Cell6 indoor) (Continued)
Question
Options
Is database required? (Provided by local office)
Yes
No
Is ac battery backup required?
Yes
No
Select ac battery box options?
Yes
No
Is -48 V power supply module (APSM) required?
Yes
No
Is Comms Power Supply Module (CPSM) required?
Yes
No
68P02900W21-T
9-7
Jul 2010
Determine the hardware requirements for BTS K
Determine the hardware requirements for BTS K
Introduction
From Figure 9-1 and Table 9-1, it can be seen that BTS K needs 12 RF carriers in a 4/4/4 sector
configuration to carry a peak demand of 20 Erlangs per sector.
Cabinet
From the site requirements and the potential future expansion, it can be determined that this
site is included in two or three Horizonmacro cabinets.
Alternatively, the site can be included is a better word in a single Horizon II macro indoor
cabinet.
Receiver requirements
A single Horizon II macro cabinet solution, a two cabinet Horizonmacro solution and a three
cabinet Horizonmacro solution are provided.
Single cabinet Horizon II macro solution

The single cabinet consists of six CTU2 transceivers, operating in pairs and in dual carrier mode
to provide the 3 sector 4/4/4 configuration.
An optional SURF2 dual-band adapter allows a 900 MHz SURF2 and a 1800 MHz SURF to be
installed in the same cabinet, thus providing dual band capability. A maximum of 3 CTU2s per
band can be accommodated for 2/2/2 and 2/2/2 configuration. Refer to Chapter 12 Hardware
and compatibility for details on configuration.
Two cabinet Horizonmacro solutions

Each cabinet has four carriers of a sector plus two carriers of a shared sector. Two SURF
modules support the four carriers in each sector. The shared sector is supported by
interconnecting the SURF in the master cabinet to the SURF in the extender cabinet.
Three cabinet Horizonmacro solutions

Each cabinet is dedicated to a sector, to support easy expansion.
9-8
68P02900W21-T
Jul 2010
Transmitter combining requirements
Transmitter combining requirements

A one, two, and three cabinet solution is provided.
Single cabinet Horizon II macro solution

Each sector needs two DUPs, one for each CTU2.
Two cabinet Horizonmacro solutions

Each sector needs two DCF modules. The shared sector has one DCF module in the master
cabinet and the other DCF in the extender cabinet.
Three cabinet Horizonmacro solutions

Each cabinet is dedicated to a sector, which needs one DDF and one HCU modules.
Summary
The equipment required, and an example of customer order creation for a single cabinet
Horizon II macro indoor (1800 MHz) configuration, to implement BTS K is listed in Table 9-4
and Table 9-5.
Table 9-4
Customer ordering guide 1800 MHz (Horizon II macro indoor)

Question
Voltage used
Compulsory
+27 V dc
-48 V/60 V dc
240 V ac
How many cells are required?
1
2
3
How many carriers are required per cell? (RF configuration)
1
2
3
4
5
6
7
8
One carrier (single density) or two carriers (double density)

required per CTU2?
1
2
How many cabinets are required for the RF configuration?
1
2
3
4
Continued
68P02900W21-T
9-9
Jul 2010
Summary
Table 9-4
Customer ordering guide 1800 MHz (Horizon II macro indoor) (Continued)

Question
What type of combining is required?
What line interface is required?
Table 9-5
DUP and Air

DUP and HCU
DUP and DHU
DUP, HCU and Air DUP,
DHU and Air DUP,
HCU, DHU, and Air
T43 (E1) (75 ohm)
BIB (E1) (120 ohm)
Customer ordering guide 1800 MHz (Horizon II macro indoor)

Questions
9-10
Compulsory
Options
Is digital redundancy required?
Yes
No
Is power redundancy required?
Yes
No
Is an extra line interface required?
Yes
No
Are 16-way alarm inputs required?
Yes
No
Is a compact flash (memory) card required?
Yes
No
Is a stacking bracket required?
Yes
No
Is battery backup required?
Yes
No
Is database required? (Provided by local office)
Yes
No
68P02900W21-T
Jul 2010
Determine the hardware requirements for the BSC
Determine the hardware requirements for the BSC
Introduction
From Figure 9-1 and Table 9-1, it can be seen that this BSC controls 11 BTSs with 32 carriers in
13 cells to carry a peak demand of 119 Erlangs.
BSC to BTS links

Figure 9-1 shows that the number of links connected from the BTSs to the BSC is four.
BSC to MSC links

Reference to standard Erlang B table shows that 119 Erlangs at 1% blocking needs 138 traffic
channels. One OML link, one XBL link, and one C7 signaling link are required. The number of
trunks required is given by:
[(1 + 1) + (1 + 1) + (1 + 1) + (138/4)]/31 = 1.3
Transcoder requirement
None required, remote transcoding.
MSI requirement
Minimum number of MSIs required is given by:
(4 + 2)/2 = 3
Line interface
Depending on the interface standard used, one BIB or one T43 is sufficient for three MSIs.
68P02900W21-T
9-11
Jul 2010
Introduction
GPROC requirement
GPROC function requirements are listed in Table 9-6.
Table 9-6 GPROCs required at the BSC

Function
Number required
BSP
1 (GPROC3)
LCFs for MTLs
LCFs for RSLs
Optional GPROC requirements

Redundant BSP (GPROC3), CSFP
Redundant LCP
Total GPROC3s
1+1
Total GPROC2s/GPROC3s
2+1
NOTE
The notation n + m means that n is the items required and m the redundancy.
KSW/DSW2 requirement
Device timeslot requirements are listed in Table 9-7.
Table 9-7 BSC timeslot requirements

Device
Number required
GPROCs
5 * 32 = 160
XCDR
None
MSI
3 * 64 = 192
Total timeslots
352
Therefore, the BSC can be accommodated in one BSU shelf and one KSW/DSW2 is required.
KSWX/DSWX requirement
The BSC is included in one shelf so there is no requirement for a KSWX/DSWX.
GCLK requirement
One GCLK per BSC is required plus one for redundancy.
CLKX requirement
The BSC is included in one shelf so there is no requirement for a CLKX.
9-12
68P02900W21-T
Jul 2010
Summary
PIX requirement
The number of PIX boards required depends on the number of external alarms that are required.
Use one for this example.
LANX requirement
An adequate number of LANXs are provided for non-redundant operation. A redundant LAN
needs one additional LANX per cabinet.
Power supply
Depending on the power supply voltage, two EPSM plus one for redundancy or two IPSM
plus one for redundancy is required.
Summary
The equipment required to implement the BSC is listed in Table 9-8.
Table 9-8 Equipment required for the BSC

Equipment
Number required
BSSC2 or BSSC3 cabinet
BSU shelf
MSI
BIB or T43
GPROC3
1+1
GPROC2/GPROC3
2+1
KSW/DSW2
1+1
GCLK
1+1
PIX (provides up to 8 external alarms)
LANX
EPSM/IPSM (+27 V) (-48 V)
2+1
NOTE
The notation n + m means that n the items required plus m the redundancy.
68P02900W21-T
9-13
Jul 2010
Determine the hardware requirements for the RXCDR
Determine the hardware requirements for the RXCDR
MSI requirements
It is necessary to provide enough MSIs to communicate on the links to the BSC, for E1 links the
traffic connection comes directly from the transcoder card.
Links to the BSC

From the calculation refer to BSC to MSC links on page 9-11 in the previous section, it can
be seen that there are two links to the BSC.
Links to the OMC-R

From the topology (see Figure 9-1), it can be seen that a link to the OMC-R from the RXCDR
must be provided.
Number of MSIs required

Three E1 links are required.
The number of MSI cards is given by:
3/ 2 = 1.5
Round off this value to 2.
Transcoder requirement
From the calculation in the previous section BSC to MSC links on page 9-11, it can be seen that
138 traffic channels and two C7 links are required. The number of transcoder cards is given by:
138/30 = 5
A GDP2 can transcode 60 channels and if used exclusively is determined by:
138/60 = 3
NOTE
Enhanced capacity mode must be enabled within the RXCDR to access the second E1
when GDP2s are used in non-MSI slots. XCDR, GDP, and GDP2s are mixed within a
shelf.
Use the RXU3 shelf in the GDP2. The BSSC3 cabinet with two RXU3 shelves can interface up to
76 E1 links. The BSSC2 cabinet can interface only up to 48 E1 link.
9-14
68P02900W21-T
Jul 2010
Link interface
Link interface
From the MSI requirements, it can be seen that, two E1 links to the BSC and one to the OMC-R
are required. From the transcoder requirements it can be seen that a further five E1 links are
required. A total of eight E1 links are required.
The number of BIB/T43s is given by:
8/6 =1.3
Round off this value to 2.
GPROC requirement
One GPROC2/GPROC3 is required, plus one for redundancy.
KSW/DSW2 requirement
From the number of MSIs, transcoders and E1 links, it can be seen that the total number of
timeslots is given by:
2 *16 + 5*16 + 2 * 64 = 240
One KSW/DSW2 is required, plus one for redundancy.
KSWX/DSWX requirement
The RXU is contained in one shelf so there is no requirement for a KSWX/DSWX.
GCLK requirement
One GCLK is required plus one for redundancy.
CLKX requirement
The RXU is contained in one shelf, so there is no requirement for a CLKX.
PIX requirement
The number of PIX boards required depends on the number of external alarms that are required.
Use one for this example.
68P02900W21-T
9-15
Jul 2010
LANX requirement
LANX requirement
An adequate number of LANXs are provided for non-redundant operation. A redundant LAN
needs one additional LANX per cabinet.
Power supply
Depending on the power supply voltage, two EPSMs plus one for redundancy or two IPSMs
plus one for redundancy is required.
Summary
The equipment required to implement the RXCDR is listed in Table 9-9.
Table 9-9 Equipment required for the RXCDR

Equipment
Number required
BSSC2 or BSSC3 cabinet
RXU or RXU3 shelf
MSI
XCDR/GDP-E1
BIB or T43
GPROC2/GPROC3
1+1
KSW or DSW2
1+1
GCLK
1+1
PIX (provides up to 8 external alarms)
LANX
EPSM/IPSM (+27 V) (-48 V)
2+1
NOTE
The notation n + m means that n the items required plus m the redundancy.
9-16
68P02900W21-T
Jul 2010
Calculations using alternative call models
Calculations using alternative call models
Introduction
This section is provided to assist the users for whom the planning models given in Chapter 5
BTS planning steps and rules, Chapter 6 BSC planning steps and rules and Chapter 7 RXCDR
planning steps and rules are inappropriate. Where this is the case, the various planning tables
that are used in the previous example in this chapter is not correct and the actual values require
to be derived using the formulae given in Chapter 5 BTS planning steps and rules, Chapter 6
BSC planning steps and rules and Chapter 7 RXCDR planning steps and rules. The necessary
calculations are demonstrated in the following examples.
Planning example 1
Dimension a network with the following requirements:
GSM software release = GSR7
Number of sites 6/6/6 sites (BTS: M-Cell6) = 20
No AMR support
No Enhanced capacity mode support
Call model parameters
Call duration T = 120 s
Ratio of SMSs per call S = 0.12
Ratio of location updates per call = 2.4
Ratio of IMSI detaches per call I = 0
Location update factor L = 2.4 + 0.5 * 0 = 2.4
Number of handovers per call H = 2.5
Ratio of intra-BSC handovers to all handovers i = 0.6
Paging rate per second PGSM = 8 pages per second
Number of cells at the BTS CBTS = 3
MTL link utilization = 35% (0.35)
RSL link utilization U = 25% (0.25)
68P02900W21-T
9-17
Jul 2010
Planning example 1
CCCH utilization UCCCH = 33% (0.33)
Probability of blocking TCH PB-TCH < 2%
Probability of blocking SDCCH PB-SDCCH < 1%
Probability of blocking on A Interface < 1%
Other considerations
Line interface type = E1
Network termination option = T43
Power voltage option = -48/-60 V dc
Type of combining used = Hybrid (CBF)
Dedicated CSFP = YES
CSFP redundancy = NO
Redundancy for all other modules = YES
MTL links redundancy = YES
RSL link redundancy = NO
Coding schemes CS3 and CS4 used = NO
BTS connectivity = Star configuration
IMSI/TMSI paging = TMSI
MTL load balancing granularity = 16
NVM board fitted at BSC and RXCDR
Cell planning - control channel calculations

From Erlang B tables, the number of Erlangs supported by 48 TCHs (6-carrier cell) with GOS of
2% is 38.39 Erlangs.
Total Erlangs offered by a 6/6/6 BTS = 3 * 38.39 = 115.17 Erlangs
6-carrier cell - determining the number of CCCHs
Call arrival rate:
call = e/T = 38.39/120 = 0.032
9-18
68P02900W21-T
Jul 2010
Planning example 1
SMS Rate:
s = S e/T = 0.12 38.39/120 = 0.038

Location update rate:
LU = L e/T = 2.4 38.39/120 = 0.768

Access grant rate is given by:
AGCH = call + S + LU = 1.126

From the call model parameters, the paging rate P is 8, so the average number of CCCH blocks
required to support paging only is:
NPCH = PGSM / (4 4.25) = 8/ (4 4.25) = 0.471

The average number of CCCH blocks required to support AGCH only is given by:
NAGCH = AGCH / (2 4.25) = 0.132

Using a CCCH utilization figure (UCCCH) of 0.33, the average number of CCCH blocks required
to support both PCH and AGCH is given by:
NPAGCH = (NAGCH + NPCH ) /UCCCH = (0.132 + 0.471) /0.33 = 1.828

Assuming 1% blocking, the Erlang B tables show that 6 CCCHs are required. This can be
supported using a non-combined BCCH with 9 CCCH timeslots. Reserve 3 CCCH blocks for
access grant messages.
Determining the number of SDCCHs per cell
Using the values calculated in the previous section and other call model parameters, the
average number of SDCCHs and NSDCCH is given by the formula mentioned in Chapter 3
BSS cell planning.
NSDCCH = call Tc + LU (TL + Tg ) + s (Ts + Tg )

= 8.126
To support an average number of busy SDCCHs of 8.126 Erlangs signaling traffic with less that
1% blocking is 14 as determined by use of Erlang B tables. Hence, the number of timeslots
required to carry SDCCH signaling traffic is 2, with each timeslot offering maximum 8 SDCCHs.
Determining the number of TCHs
Total number of signaling timeslots required for a 6-carrier configuration, with the given call
model parameters is 3 (1 non-combined BCCH timeslot with 9 CCCHs and 2 timeslots with 8
SDCCHs each).
68P02900W21-T
9-19
Jul 2010
Planning example 1
Therefore, the number of traffic channels per 6 carrier cell = 48 3 = 45.

Hence, traffic offered by a 6-carrier cell is 35.61 Erlangs (45 traffic channels at 2% GOS).
Carried Erlangs is 34.90 Erlangs.
Total channels/carrier = 48
Total traffic channels (voice) = 45
Control/signaling channels = 3
BSS planning
The major steps for planning the BSC system include:
9-20
The number of RSL links between the BSC and BTSs
The number of E1 links between BSC and BTSs
The number of LCFs for RSL processing
The number of MTL links between BSC and MSC
The number of LCFs for MTL processing
The number of XBL links between BSC and RXCDR
The number of GSL links between BSC and RXCDR
The number of GPROCs
The number of XCDR/GDP/GDP2s
The number of MSI cards
The number of KSWs/DSW2s
The number of BSU shelves
The number of KSWXs/DSWXs
The number of GCLKs
The number of CLKXs
The number of LANXs
The number of PIXs
68P02900W21-T
Jul 2010
Planning example 1
The number of line interface cards (T43s)
The number of digital power supplies
Check if an optional NVM board is fitted
RSL requirements
The number of 64 kbps RSLs required is given by:
RSLGGSM+GPRS@64K
(47 + 3 CBT S ) PGSM + (52 + CBT S ) PGP RS

n (95 + 67 S + 35 H + 25 L)
+
+
8000 U
1000
T
=
6 M ean T BF Rate NGP RS
1000 U
Where n is the number of TCHs under the BTS. Hence, for a 6/6/6 site (no GPRS):
RSLGGSM+GPRS@64K =
(47 + 3 3) 10 + (52 + 3) 8
60
45 3 (95 + 67 0.12 + 35 2.5 + 25 2.4)
+
+
8000 0.25
1000 0.25
1000 .25 120
= Roundup (1.351)
The number of RSLs required per 6/6/6 site is 2.
BSC to BTS E1 interconnect planning
Number of E1 links required between a BSC and BTS is given by:
NBSCBTS =
nE
GPRS
i=0

RTF DSO COUNT + (nCGPRS 4) + (nGGPRS 2) + L16/4
+ L64
31
Number of E1 links required between each 6/6/6 BTS and BSC is given by:
((0 8) + (0 4) + (18 2) + (0/4)) + 2
= 1.22
31
Hence, 2 E1 interconnections are required between each BTS and BSC for the given site
configurations (provided they are in star configurations). There are total of 20 * 2 = 40 E1
links needed.
The number of E1s between the BSC and BTS is 40.
Determining the number of LCF GPROCs for RSL processing
Number of LCF-RSLs required is given by:
GL3 =
C
n (1 + 0.35 S + 0.34 H (1 0.4 i) + 0.32 L)
+ (0.00075 PGSM + 0.004) B +
19.6 T
120
Where n is the number of TCHs under a BSC:
GL3 =
2700 (1 + 0.35 1.12 + 0.34 2.6 (1 0.4 0.6) + 0.32 2.5)

60
+ (0.00075 8 + 0.004) 20 +
19.6 100
120
68P02900W21-T

9-21
Jul 2010
Planning example 1
Determining the number of MTLs

Total Erlangs offered by the BSC with 20 sites and 6/6/6 configuration is given by:
20 * 3 * 35.61 = 2136.6 Erlangs
Total Erlangs carried by the BSC with 20 sites and 6/6/6 configuration is given by:
20 * 3 * 34.40 = 2094 Erlangs
The number of trunks required to carry traffic on the A Interface with less than 1% blocking is
2165 (using offered Erlangs to calculate). Verify that this figure is within limits (< 3200 for a
huge BSC system). Number of pages per call:
PPC = PGSM T/N = 8 120/2165 = 0.443

Using the call model parameters, the number of MTLs can be calculated using formulae
mentioned in Chapter 6 BSC planning steps and rules of this manual.
Maximum number of Erlangs supported by a C7 link is given by:
nlink =
nlink =
1000 U T
(40 + 47 S + 22 H (1 0.8 i) + 24 L + 9 PPC )
1000 0.35 120

= 310 Erlangs
(40 + 47 0.12 + 22 2.5 (1 0.8 0.6) + 24 2.4 + 9 0.44)
Maximum number of Erlangs supported by GPROC supporting a C7 signaling link is given by:
n1LCFMTL =
n1LCFMTL =
20 T
(1 + 0.16 S + 0.5 H (1 0.6 i) + 0.42 L + PPC (0.005 B + 0.05))
20 120
(1 + 0.16 0.12 + 0.5 2.6 (1 0.6 0.6) + 0.42 2.4 + 0.44 (0.005 20 + 0.05))
Hence:
= nlmin = min
nlink
nlLCFMTL
= 310 Erlangs
Amount of traffic each logical link holds:

Nlogical = 2165/16 = 135.31 Erlangs
using an MTL load-sharing granularity of 16.
The number of logical links each MTL can handle:
310
135.31
The number of required MTLs.

Check that this figure is within limits (<16).
9-22
68P02900W21-T
Jul 2010
Planning example 1
The number of MTLs required = 9

Determining the number of LCFs for MTL processing
Using the formula mentioned in Chapter 6 BSC planning steps and rules, since:
2 nlink < nlLCFMTL
NLCF

9
= roundup
=5
2
XBL requirements
Referring to Table 6-12 in Chapter 6 BSC planning steps and rules,
Number of XBLs required = 2 (using N = 2165)
GSL requirements
N/A (signaling links between BSC and PCU).
GPROC requirements
NGPROC = 2B + L + C + R
B = Number of BSP GPROC3s (x 2 for redundancy) = 3
NOTE
A total of 3 BSU shelves are required and each shelf must have at least one GPROC (x
2 for redundancy).
L = Total number of LCF GPROCs required = 5
C = Number of CSFP GPROCs (optional) = 0
R = Number of pool GPROCs (for redundancy) = 1
Total number of GPROCs for BSC = (2 * 3 + 5 +0 + 1) = 12
XCDR/GDP/GDP2 requirements
N/A (no local RXCDR).
MSI requirements
Each MSI interfaces two E1 links.
NMSI =
NBSCRXCDR
2
NMSI = Number of MSIs required.

NBSC-RXCDR = Number of E1 links required.
68P02900W21-T
9-23
Jul 2010
Planning example 1
Number of E1 links required at the BSC for interconnecting with the RXCDR is:
NBSCRXCDR =
C + X + B64 + T (1 PHR ) + N16 /4 (T PHR ) /8

31
9 + 2 + 2 + (2165/4)
= 17.9
31
~ 18
PHR in the equation is not considered in non-AMR cases.
Hence the number of MSIs required for the BSC to RXCDR interface is 18/2 = 9.
Each BTS site in this example needs two E1 interconnections. Hence, the number of MSIs
required for BTSs is 20 * 2 / 2 = 20.
Total number of MSIs required at the BSC = 20 + 9 = 29
KSW/DSW2 requirements
Determine the number of KSWs/DSW2s (N) required by using the following formula:
N=
((G n) + RGDPXCDR 16) + REGDP 80 + (RGDP2 24) + (M 64)

1016
Where:
Is:
16 or 32 (16 in this example).
RGDP2
N/A in this example (RXCDR case).
the number of MSIs (29).
NOTE
RGDPXCDR and REGDP are not considered in the equation.
Therefore, the total number of timeslots required is:
12 * 16 + 29 * 64 = 2048
Each KSW/DSW2 provides 1016 TDM timeslots. Hence, 3 non-redundant KSWs/ DSW2s are
required for this configuration. For redundancy, 3 additional KSWs/ DSW2s are required.
Thus total KSWs/DSW2s required (with redundancy) = 3 + 3 = 6
BSU shelves
Ensure that the following is true for each shelf.
Roundup (29/12) = 3 BSU shelves
Total GPROCs = 12 and total MSIs = 29, split between 3 BSU shelves.
9-24
68P02900W21-T
Jul 2010
Planning example 1
Table 9-10 BSU Shelves

BSU 1
BSU 2
BSU 3
Check Limit
12
12
GPROCs
MSI cards
Ensure that the following is true for each shelf.

(G * n) + (M * 64) + (R * 16) 1016
That is,
(4 * 16) + (12 * 64) + (0 * 16) 1016
Therefore, the number of BSU shelves required to accommodate all the hardware needed
for this configuration is NBSU = 3.
KSWX/DSWX requirements
Consider the KSWXs/DSWXs for this example as the configuration needs more than one shelf.
The KSWX/DSWX extends the TDM highway of a BSU to other BSUs and supplies clock
signals to all shelves in the multi-shelf configuration. The KSWX/DSWX can be used in
expansion, remote and local modes. Three BSU shelves are required with 3 master/redundant
KSWs/DSW2s, which implies that 2 expansion shelves are required.
The number of KSWXs/DSWXs required (NKX) is the sum of KSWXDSWXE, KSWX/DSWXR,
and KSWX/DSWXL:

NKXE = K * (K-1) = 3 * 2 = 6 (K is the number of non-redundant KSWs/DSW2s)
NKXR = SE = 0 (SE is the number of extension shelves)
NKXL = K + SE = 3
NKX = 6 + 0 + 3 = 9
The number of KSWXs/DSWXs required (with redundancy) = 18
NOTE
The maximum number of KSWX/DXWX slots per shelf 18.
If KSWXs and DSWXs are used in like pairs, that is, KSWX connected to KSWX
and DSWX connected to DSWX, they can be used together in a shelf.
GCLK requirements
The generic clock generates all the timing reference signals required by a BSU. One GLCK is
required at each BSC.
The number of GCLKs required (with redundancy) = 2
68P02900W21-T
9-25
Jul 2010
Planning example 1
CLKX requirements
Provides expansion of GCLK timing to more than one BSU. Number of CLKXs required is
given by:
NCLKX = Roundup (E/6) (1 + RF )

Where E is the number of expansion/extension shelves and RF is the redundancy factor.
NCLKX = Roundup (3/6) (1 + 3) = 2

The number of CLKXs required (with redundancy) = 2
LANX requirements
NLANX = NBSU (1 + RF ) = 3 2 = 6
Total number of LANXs required (with redundancy) = 6
PIX requirements
PIX provides eight inputs and four outputs for site alarms.
PIX Number of BSUs = 6
Line interfaces
Number of T43s = Roundup (Number of MSIs/3)
Number of T43s = 29/3 ~ 10
The number of T43 boards required is 10.
Digital power supply requirements
The number of PSUs required is given by:
PSUs = NBSU (2 + RF )
One redundant PSU is required for each BSU shelf, hence the total number of PSUs required is:
PSUs = 3 (2 + 1) = 9
The total number of PSUs required is 9.
Non-volatile memory (NVM) board for BSC (optional)
NVM = 0 or 1
An NVM board is required in this example, so NVM = 1.
9-26
68P02900W21-T
Jul 2010
Planning example 1
RXCDR planning
The following planning steps are performed for this example:
The number of links between the RXCDR and BSC
The number of E1 links between the RXCDR and MSC
The number of XCDR/GDP2/GDP2s
The number of MSIs
The number of RXU shelves
The number of GCLKs
The number of CLKXs
The number of LANXs
The number of PIXs
The number of line interface boards (T43s)
The number of digital power supply units
Determining the number of E1 links between the RXCDR and BSC

Number of RXCDR to MSC links is given by:
NRXCDRMSC = (C + X + T) /31
Where:
Is:
the number of MTL links required.
the number of OML links required.
the number of trunks between MSC and BSC.
NRXCDRMSC = (9 + 2 + 2165) /31 = 70.19

The number of E1 links between the RXCDR and MSC = 71
68P02900W21-T
9-27
Jul 2010
Planning example 1
Determining the number of XCDR/GDP/GDP2 cards

Each XCDR/GDP/GDP2 terminates one E1 link (for the RXU shelf).
Hence, the number of non-redundant cards required is 47, which, can be a mix of XCDRs,
GDPs and GDP2s.
The number of non-redundant XCDR/GDP/GDP2 cards = 47
PROC requirements for RXCDR
Each shelf should have minimum of one GPROC. Hence, 5 non-redundant GPROCs are required.
If the operator chooses to use redundancy, 10 GPROCs are required.
The number of GPROCs required for RXCDR = 5 + 5 (for redundancy) = 10
MSI requirements for RXCDR
As calculated in MSI requirements, the number of BSC-RXCDR links is 18. Each MSI card
interfaces 2 E1 links, hence, 9 MSI cards are required on the RXCDR.
MSI requirements for RXCDR = 9
KSW/DSW2 requirements for RXCDR
Number of TDM slots required for the GPROCs, MSIs, and XCDRs is given by:
TDM timeslots required = G * n + M * 64 + R * 16
TDM timeslots required = 12 * 32 + 9 * 64 + 71 * 16 = 2096
Each KSW/DSW2 provides 1016 timeslots on the TDM highway, hence, 3 non-redundant
KSWs/DSW2s are required for RXCDR with this configuration.
KSWs/DSW2s required for the RXCDR = 3 + 3 (redundant) = 6
RXU shelves
The number of RXU shelves required is given by (assuming that an NVM board is fitted):
NRXU = max [M/5, (R + NNVM ) /16] = max (9/5, 71 + 1/16) = 5
Table 9-11 RXU shelves

RXU 1
RXU 2
RXU 3
RXU 4
RXU 5
MSIS
XCDRs/GDPs
GDP2s
GPROCs
Ensure that the following holds good for each shelf.

N + (G * n) + (M * 64) + (R * 16) 1016
Hence, 5 RXU shelves are required to equip 71 XCDR/GDP/GDP2 cards and 9 MSI cards.
The number of RXU shelves required = 5
KSWX/DSWX requirements for RXCDR
9-28
68P02900W21-T
Jul 2010
Planning example 1
The number of KSWXs/DSWXs required is the sum of KSWX/DSWXE, KSWX/DSWXR, and

KSWX/DSWXL. The calculations imply 2 expansion and 2 extension shelves are required.

NKXE = K (K 1) = 3 (3 1) = 6
K is the number of non-redundant KSWs/DSW2s.
NKXR = SE = 2
SE is the number of extension shelves.
NKXL = K + SE = 3 + 2 = 5
NKX = 6 + 2 + 5 = 13
The number of KSWXs/DWSXs required = 13 + 13 (redundant) = 26
NOTE
If KSWXs and DSWXs are used in like pairs, that is, KSWX connected to KSWX and
DSWX connected to DSWX, they can be used together in a shelf.
GCLK requirements
The generic clock generates all the timing reference signals required by an RXU. One GLCK is
required at each RXCDR.
Number of GCLKs required = 1 + 1 (redundant) = 2
CLKX requirements
Provides expansion of GCLK timing to more than one RXU:
NCLKX = Roundup (E/6) (1 + Rf )

Where:
E
RF
Is:
the redundancy factor.
NCLKX = Roundup (4/6) (1 + 1) = 2

The number of CLKXs required = 1 + 1 (redundant) = 2
68P02900W21-T
9-29
Jul 2010
Planning example 2 (using AMR)
LANX requirements
Number of LANXs required is given by:
NLANX = NRXU (1 + RF ) = 5 2 = 10
Where RF it the redundancy factor.
Total number of LANXs required with redundancy = 10
PIX requirements
PIX 2 * Number of RXUs = 2 * 5 = 10
Hence, 10 PIX cards are required for the RXCDR.
Line interfaces
Number of T43s = Number of E1s/6 = (18 +71)/6 ~ 15
The number of T43 boards required = 15
PSUs = 2 * RXUs + RF * RXUs = 2 * 5 + 1 * 5 = 15
One redundant PSU is required for each RXU shelf, hence, the total number of PSUs required
= 15.
Non-volatile memory (NVM) board for RXCDR (optional)
NVM = 1 (required in this example)

9-30
GSM software release = GSR 8
Number of sites 6/6/6 sites (BTS: M-Cell6) = 20
AMR MS penetration rate = 35% (AMR fr/hr-capable MSs)
Total AMR hr usage PHR = 50% * PAMR = 18% (among all MSs)
BSS provides additional ~35% voice traffic supported AMR hr
GPROC3 is mandatory for the BSP
GDP2 is considered to support AMR hr
68P02900W21-T
Jul 2010
New RXCDR shelf is mandatory
No local XCDR
8 k/16 k switching is used (requires DSW2 support)
No enhanced capacity mode support
No GPRS in the system
Ratio of SMSs per call S = 0.12
Ratio of IMSI detaches per call I = 0
Location update factor L = 2.4 + 0.5 * 0 = 2.4
Network termination option = T43
68P02900W21-T
9-31
Jul 2010
Coding schemes CS3 and CS4 used = NO
GSR 8 limitations (assuming huge BSC system)
Maximum BTS sites = 100
Maximum BTS cells = 250
Active RF carriers = 512
Trunks = 3200
C7 links = 16
Cell planning - control channel calculations (based on Erlang B models)

Table 9-12 Control channel calculation
All full rate
AMR (hr) Carrier
Total
Carriers
AMR HR/
Carriers
Total
TCH
Signaling
/ Control
TCH
Total
Voice
TCH
Total
TCH
Signaling
/Control
TCH
Total
Voice
TCH
AMR
HR TCH
AMR
HR
TCH
%
1 / 6
48
45
56
53
16
30.2
2 / 6
48
45
64
60
32
53.3
3 / 6
48
45
72
68
48
70.6
4 / 6
48
45
80
76
64
84.2
5 / 6
48
45
-88
-4
-84
-80
95.2
6 / 6
48
45
96
88
88
100
For planning purposes, it is assumed that the AMR-capable MSs use AMR FR channels, and that
hr is used under conditions of congestion. The estimated AMR penetration rate is 35%, of which
half of those calls are in half rate mode due to congestion (as given in the assumptions), yielding
about 18% of the calls in half rate mode. From the pre-calculated table, it is seen that 1 half rate
enabled carrier would provide about 30% AMR half rate channels. However, to allow for future
growth in the penetration level and to allow for a greater margin of safety, 2 half rate enabled
carriers can be assumed for the remainder of this exercise.
9-32
68P02900W21-T
Jul 2010

Call arrival rate:
call = e/T = 53.43/120 = 0.445

SMS Rate:
s = S e/T = 0.12 53.43/120 = 0.053

Location update rate:
LU = L e/T = 2.4 53.43/120 = 1.069

AGCH = call + S + LU = 1.567

required to support paging only is given
NPCH = PGSM / (4 4.25) = 8/ (4 4.25) = 0.471

NAGCH = AGCH / (2 4.25) = 0.184


Assuming 1% blocking, the Erlang B tables show that seven CCCHs are required. This can be
supported using a non-combined BCCH with 9 CCCH timeslots. Reserve 2 CCCH blocks for
access grant messages.
average number of SDCCHs and NSDCCH is given by the formula mentioned in Chapter 3
BSS cell planning.

= 11.31
68P02900W21-T
9-33
Jul 2010
To support an average number of busy SDCCHs of 11.31 Erlangs signaling traffic with less than
required to carry SDCCH signaling traffic is 3, with each timeslot offering a maximum of 8
SDCCHs.
Total number of signaling timeslots required for a 6-carrier configuration, with the given call
SDCCHs each).
Therefore, the number of traffic channels per 6 carrier cell (4 fr carriers + 2 hr carriers)
= 4 * 8 + 16 * 2 4 = 60
Carried Erlangs is
49.64 * 98% = 48.65 Erlangs.
Total Erlangs offered by the BSC with 20 sites, and 6/6/6 configuration is given by:
20 * 3 * 49.64 = 2978.4 Erlangs
Total Erlangs carried by the BSC with 20 sites, and 6/6/6 configuration is given by:
20 * 3 * 48.65 = 2919 Erlangs
3003. Check this is within the limit of 3200.
If the number of trunks (3003) exceeds the limit by a small number (less than a quarter of a
percent or so), it can be considered negligible and planning can continue. However, there is an
alternative approach, particularly for the half rate usage, which is discussed here. In fact, it is
assumed that the trunk limit is 3000 to provide a working example.
The carried Erlangs were calculated for worst case planning. It is assumed that all AMR half
rate enabled carriers would, at worst case, be handling all AMR half rate calls. However, given
that the AMR-capable mobile penetration is 35%, it is unlikely that all the AMR half rate enabled
carriers are carrying all half rate traffic. Certainly, exclusive (forced) AMR half rate usage could
have been assumed (in which case the AMR hr TCH % should be used to calculate the number of
(total and AMR half rate enabled) carriers required) but that is not the assumption made here.
The approach used here is to relax the AMR half rate usage assumption enough to satisfy the
trunking limit, yet provide a large margin of safety as AMR penetration grows.
A minimal assumption is made, that one of the AMR HR carriers can carry 14 HR calls and 1
FR call. This results the following:
1 HR carrier = 16 AMR HR TCH = 14 AMR HR TCH + 1 FR TCH = 15 TCH
The total number of AMR voice TCH = 4 * 8 + 1 * 16 + 14 TCH + 1 - 4 = 59
The traffic offered by a 6 carrier/cell is (based on 59 TCH with 2% of GOS) = 48.70 Erlangs
Carried Erlangs by such system configuration (per BTS) = 48.70 *98% = 47.73 Erlangs
Total Erlangs carried by the BSC with 20 sites, and 6/6/6 configuration is given:
20 * 3 * 48.70 = 2922 Erlangs
2946.
9-34
68P02900W21-T
Jul 2010
This alternatively calculated number (2946) can be used for the remainder of the calculations
in this section.
# of sites (BTS) per BSC:
20
# of cells per BTS:
# of carriers per cell:
# TCHs per carrier:
63 (AMR HR, AMR FR, GSM FR/EFR, and so on)
# Control channels per carrier:
# of available voice TCH:
59 (30 AMR HR + 29 FR)
# of Erlangs offered per BTS:
48.70
# of Erlangs carried per BTS:
47.73
# of Erlangs offered by this BCS system:
20 * 3 * 48.70 = 2922
# of trunks to carry such traffic:
(using Erlangs B calculation) 2946
BSS planning
The number of GCLKs
The number of CLKXs
The number of LANXs
The number of PIXs
68P02900W21-T
9-35
Jul 2010
RSL requirements
RSLGGSM+GPRS@64K
(47 + 3 CBT S ) PGSM + (52 + CBT S ) PGP RS

n (95 + 67 S + 35 H + 25 L)
+
+
8000 U
1000 U T
=
6 M ean T BF Rate NGP RS
1000 U
Where n is the number of TCHs under the BTS. Hence, for a 6/6/6 site (with AMR but no GPRS):
RSLGGSM+GPRS@64K =
(47 + 3 3) 8 + (52 + 3) 8
0
59 3 (95 + 67 0.12 + 35 2.5 + 25 2.4)
+
+
8000 0.25
1000 0.25
1000 .25 120
= Roundup (1.70)
The number of RSLs required per 6/6/6 site (with 2 carriers of AMR HR) = 2
NBSCBTS =
nE
GPRS
i=0

+ L64
31
Number of E1 links required between each 6/6/6 BTS and BSC:

= [((0 * 8) + (6 * 4) + (12 * 2) + (0/4))/31] ~ 1.61
Hence, two E1 interconnections are required between each BTS and BSC for the given site
configurations (provided they are in star configurations). Thus, a total of 20 * 2 = 40 E1 links
are required.
The number of E1s between the BSC and BTS is 40.
Number of LCF-RSLs required, assuming only GPROC3s are used, is given by:
GL3 =
C
n (1 + 0.35 S + 0.34 H (1 0.4 i) + 0.32 L)
+ (0.00075 PGSM + 0.004) B +
19.6 T
120
GL3
9-36
60
3540 (1 + 0.35 1.12 + 0.34 2.6 (1 0.4 0.6) + 0.32 2.4)
+ (0.00075 8 + 0.004) 20 +
=
19.6 100
120
68P02900W21-T
Jul 2010

Total Erlangs carried by the BSC with 20 sites, and 6/6/6 configuration is given by:
=20 * 3 * 48.70 = 2922 Erlangs
2946.
Number of pages per call is given by:
PPC = PGSM T/N = 8 120/2946 = 0.325

mentioned in Chapter 6 BSC planning steps and rules of this manual.
Maximum number of Erlangs supported by a C7 link is given by:
nlink =
nlink =
1000 U T
(40 + 47 S + 22 H (1 0.8 i) + 24 L + 9 PPC )
1000 0.35 120

= 311.65 Erlangs
(40 + 47 0.12 + 22 2.5 (1 0.8 0.6) + 24 2.4 + 9 0.325)
Maximum number of Erlangs supported by a GPROC3 supporting a C7 signaling link is given by:
n1LCFMTLGPROC =
20 T 1.7
(1 + 0.16 S + 0.5 H (1 0.6 i) + 0.42 L + PPC (0.005 B + 0.05))
20 120 1.7
(1 + 0.16 0.12 + 0.5 2.5 (1 0.6 0.6) + 0.42 2.4 + 0.325 (0.005 20 + 0.05))
= 1393.1 Erlangs
Hence, for GPROC3 only:
n1min = min (nLINK, n1LCF-MTL-GPROC3) = 312 Erlangs
Amount of traffic each logical link can hold is given by:
Nlogical = 2946/16 = 184.1 Erlangs

using an MTL load-sharing granularity of 16.
The number of logical links each MTL can handle:
312
184.1
The number of required MTLs:

mtls = Roundup (16/2) + R = 9
Check that this figure is within limits (<12).
68P02900W21-T
9-37
Jul 2010
The number of MTLs required = 9

If GPROC3s are used exclusively:
nMTLGPROC3 = Rounddown
n1LCF MTL GPROC3

nlmin
nMTLGPROC3 = Rounddown
nLCFGPROC3 = Rounddown
1393
12
=4
MTLs
nMTLGPROC3
=3
The number of LCFs for MTL processing = 3

XBL requirements
The required number of XBLs is given by:
XBM = [{(N/T) * (Mnewcall + Mhandovers + Hfr-hr) * LXBL * 8}/(64000 * UBSC-RXCDR)]
Number of 64 kbps XBLs required = 3 (6 with redundancy)
GSL requirements
N/A (signaling links between BSC and PCU is not considered in this example).
GPROC requirements
NGPROC = 2B + L + C + R
B = Number of BSP GPROC3s (x 2 for redundancy) = 3
NOTE
A total of 3 BSU shelves are required and each shelf must have at least one GPROC (x
2 for redundancy).
L = Total number of LCF GPROCs required = 3
C = Number of CSFP GPROCs (optional) = 1
R = Number of pool GPROCs (for redundancy) = 1
Total number of GPROC3s (exclusively) for BSC = (2 * 3 + 3 + 1 + 1) = 11
9-38
68P02900W21-T
Jul 2010
MSI requirements
NMSI =
NBSCRXCDR
2

NBSC-RXCDR = Number of E1 links required.
Number of E1 links required at the BSC for interconnecting with the RXCDR is:
NBSCRXCDR =
C + X + B64 + T (1 PHR ) + B16/4 (T PHR ) /8

31
9 + 2 + 3 + (2946 (1 0.18) /4) + ((2946 0.18) /4)

= 24.2
31
Hence the number of MSIs required for the BSC to RXCDR interface is 25/2 = 13.
Each BTS site in this example needs two E1 interconnections. Hence, the number of MSIs
required for BTSs is 20 * 2 / 2 = 20.
NOTE
The assumptions are that the system starts allocating AMR HR resources (for AMR
HR capable MSs through HO procedures) when certain congestion thresholds are
reached. Assuming that 50% of AMR-capable MSs are able to HO to HR (total about
18% MSs among all MSs).
DSW2 requirements
Extended subrate switching mode (8 kbps switching) is required, so DSW2s are used. Determine
the number of DSW2s (N) required:
N=
((G n) + RGDPXCDR 16) + REGDP 80 + (RGDP2 24) + (M 64)

1016
Where:
Is:
the number of GPROCs (11).
RGDPXCDR
N/A in this example.
REGDP
RGDP2
the number of MSIs (33).
Therefore the total number of timeslots required is:

11 * 16 + 33 * 64 = 2288
68P02900W21-T
9-39
Jul 2010
Each DSW2 provides 1016 TDM timeslots. Hence, 3 non-redundant DSW2s are required for this
configuration. For redundancy, 3 additional DSW2s are required.
Thus, total DSW2s required = 3 + 3 (redundant) = 6.
BSU shelves
Each BSU shelf can support up to 12 MSI cards. A total of 33 MSI cards are required, based on
the previous calculation. The total number of BSU shelves required is.
Roundup (33/12) = 3BSU shelves
Total GPROC3s = 11 and total MSIs = 33, split between 3 BSU shelves
Table 9-13 BSU Shelves

BSU 1
BSU 2
BSU 3
Check Limit
11
11
11
12
GPROCs
MSI cards
Ensure that the following is true for each shelf:

(G * n) + (M * 64) + (R * 16) 1016
That is,
(4 * 16) + (12 * 64) + (0 * 16) 1016
Consider KSWXs/DSWXs for this example as the configuration needs more than one shelf. The
KSWX/DSWX extends the TDM highway of a BSU to other BSUs and supplies clock signals to all
shelves in the multi-shelf configuration. The KSWX/DSWX can be used in expansion, remote
and local modes. 3 BSU shelves with 3 master/redundant KSWs/DSW2s are required, which
implies that 2 expansion shelves are required. The number of KSWXs/DSWXs required (NKX) is
the sum of KSWXDSWXE, KSWX/DSWXR, and KSWX/DSWXL.

NKXL = K + SE = 3
NKX = 6 + 0 + 3 = 9
NOTE
9-40
68P02900W21-T
Jul 2010
GCLK requirements
CLKX requirements
given by:

NCLKX = Roundup (3/6) (1 + 1) = 2

LANX requirements
NLANX = NBSU (1 + RF ) = 3 2 = 6
PIX requirements
Line interfaces
Number of T43s = RoundUp (Number of MSIs) /3)
Number of T43s = 33/3 = 11
The number of T43 boards required is 11
68P02900W21-T
9-41
Jul 2010
RXCDR planning
The following planning steps are performed (for this example):
The number of MSIs
The number of DSW2s
The number of RXU3 shelves
The number of GCLKs
The number of CLKXs
The number of LANXs
The number of PIXs
NBSCRXCDR =
(C + X + B64 + T (1 PHR ) + B16/4 + (T PHR )) /8

= 25
31
Determining the number of E1 links between the RXCDR and MSC

Where:
Is:
the number of MTL links required.
the number of OML links required.
the number of trunks between MSC and BSC.
NRXCDRMSC = (9 + 2 + 2946) /31 = 95.38

~ 96
9-42
68P02900W21-T
Jul 2010

Each XCDR/GDP/GDP2 card terminates 2 E1 links in the RXU3 shelf.
Hence, the number of non-redundant cards required = 96/2 = 48, which can be a mix of
XCDRs, GDPs and GDP2s.
NOTE
The GDP cards can be retained for the existing FR traffic. It is only required to
allocate enough GDP2 cards for the additional AMR HR traffic.
During the system planning exercise, it was observed that 31 AMR HR channels are required
to support AMR HR calls (among 2 carriers/6 carriers/cell). There are a total of 59 TCHs for
voice traffic among 6 carriers/cell.
Therefore, the number of GDP2 cards required to support AMR HR traffic is:
30/59 (% AMR HR TCH) * 2946 (total trunks in BSC) /60 (GDP2 carries 60 calls) = GDP2 = 25
Table 9-14

Total number needed
Number of E1s supported
GDP2 cards
25 (each GDP2 can offer 60

voice calls in RXU3 shelf
(with enhanced capacity
mode enabled) for AMR HR
or FR voice calls).
25 * 2 = 50
XCDR/GDP cards
46 (each card supports 30

FR voice traffic calls)
46 * 1 = 46
XCDR/GDP/GDP2
Total number of cards (mix)

Total E1s supported
71
96
GPROC3 requirements for RXCDR

Each shelf should have minimum of one GPROC3. Hence, 5 non-redundant GPROCs are
required. If the operator selects to use redundancy, 10 GPROC3s are required.
The number of GPROC3s required for RXCDR = 5 + 5 (for redundancy) = 10
interfaces 2 E1 links, hence, 13 MSI cards are required on the RXCDR.
DSW2 requirements for RXCDR
NOTE
No enhanced capacity mode is assumed as timeslot usage per shelf is not a limiting
factor in this configuration.
68P02900W21-T
9-43
Jul 2010
Number of TDM slots required for the GPROC3s, MSIs, and XCDRs is given by:
N= (G * n) (RGDPXCDR * 16) + (REGDP * 80) + (RGDP2 * 24) + (M * 64)
TDM timeslots required = 8 * 16 + 25 * 24 +13 * 64 = 2296
Each DSW2 provides 1016 timeslots on the TDM highway, hence, 3 non-redundant DSW2s are
required for RXCDR with this configuration.
DSW2s required for the RXCDR = 3 + 3 (redundant) = 6
RXU shelves
The number of RXU3 shelves required is given by (assuming that an NVM board is fitted):
NRXU =
13 + 17 + 1
M + R + NNVM
=
19
19
~5
Table 9-15 RXU3 shelves

RXU 1
RXU 2
RXU 3
RXU 4
RXU 5
MSIs / 2 E1s (M)
GDP2s (R)
GDPs (R)
10

N + (G * n) + (M * 64) + (R * 16) 1016
Hence, 5 RXU3 shelves are required to equip 71 transcoder cards and 13 MSI cards.
The number of RXU3 shelves required = 5
KSWX/DSWXL. The calculations imply two expansion and two extension shelves are required.
NKXE = K (K 1) = 3 (3 1) = 6
NKXR = SE = 2
9-44
68P02900W21-T
Jul 2010
NKXL = K + SE = 3 + 2 = 5
NKX = 6 + 2 + 5 = 13
NOTE
GCLK requirements
The generic clock generates all the timing reference signals required by the RXU3. One GLCK is
CLKX requirements
Provides expansion of GCLK timing to more than one RXU3:

Where:
Is:
RF
NCLKX = Roundup (4/6) (1 + 1) = 2

LANX requirements
NLANX = NRXU (1 + RF ) = 5 2 = 10
PIX requirements
68P02900W21-T
9-45
Jul 2010
Planning example 3
Line interfaces
Number of T43s = Number of E1s/6 = (25 + 96)/6 ~ 21
PSUs = 2 * RXU3s + RF * RXU3s = 2 * 5 + 1 * 5 = 15
One redundant PSU is required for each RXU3 shelf, hence total number of PSUs required = 15.
NVM= 1 (required in this example)
Planning example 3
GSM software release = GSR10
Number of sites 4/4/4 sites (BTS: MCell6) = 62
Without AMR
No LCS support
No fast call setup
9-46
Ratio of SMSs per call S = 2
Ratio of IMSI detaches per call I = 0.20
Location update factor L = 2.0 + 0.5 * 0.2 = 2.1
68P02900W21-T
Jul 2010
Planning example 3
Network termination option = T43/PT43
XBL link redundancy = NO
GSR 9 limitations (assuming huge BSC system)
Maximum BTS sites = 140
Maximum BTS cells = 250
Active RF carriers = 750
Trunks = 4800
HSP MTL links are used and they are connected with MSC directly (not pass through
RXCDR)
68P02900W21-T
9-47
Jul 2010
Planning example 3
Cell planning - control channel calculations (based on Erlang B models)

From Erlang B tables, the number of Erlangs supported by 32 TCHs (4-carrier cell) with GOS
of 2% is 23.72 Erlangs and the number of Erlangs supported by 48 TCHs (6-carrier cell) with
GOS of 2% is 38.39 Erlangs.
Total Erlangs offered by a 4/4/4 BTS = 3 * 23.72 = 71.16 Erlangs
Call arrival rate is given by:
call = e/T = 23.72/96 = 0.25

SMS rate is given by:
s = S e/T = 2 23.72/96 = 0.49

Location update rate is given by:
LU = L e/T = 2 23.72/96 = 0.49

AGCH = call + S + LU = 1.23

NPCH = PGSM / (4 4.25) = 60/ (4 4.25) = 3.53

NAGCH = AGCH / (2 4.25) = 0.014

Considering a non-combined BCCH with 9 CCCH blocks, 2 timeslots BCCH+CCCH are needed
here.
9-48
68P02900W21-T
Jul 2010
Planning example 3

average number of SDCCHs and NSDCCH, is given by the formula mentioned in Chapter 3
BSS cell planning.

= 10.07
To support an average number of busy SDCCHs of 10.07 Erlangs signaling traffic with less than
required to carry SDCCH signaling traffic is 3 with each timeslot offering a maximum of 8
SDCCHs.
Total number of signaling timeslots required for a 4-carrier configuration with the given call
SDCCHs each).
Therefore, the number of traffic channels per 4 carrier cell = 32 - 5 = 27.
Total channels/cell = 32
Control/signaling channels = 5
BSS planning
68P02900W21-T
9-49
Jul 2010
Planning example 3
The number of GCLKs
The number of CLKXs
The number of LANXs
The number of PIXs
RSL requirements
RSLGSM+GPRS@64K = Roundup (RSLGSM + RSLGPRS )
RSLGGSM =
(31 + 3 CBTS ) PGSM

n (59 S (25 + SM SSIZE 0.125) + 38 H + 24 L + 24 LCS )
+
8000 U
1000 U T
RSLGPRS =
5.5 GPRS RACH/sec

(32 + CBTS ) PGPRS
+
8000 U
1000 U
RSLGSM+GPRS@64K = Roundup (RSLGSM + RSLGPRS ) = Roundup (1.98 + 0)

~2
NBSCBTS =
nE
GPRS
i=0

+ L64
31

= (12 * 2 + 2)/31 = 1
Hence, 1 E1 interconnection is required between each BTS and BSC for the given site
configurations (provided they are in star configurations). Thus, a total of 62 * 1 = 62 E1 links
are required. The number of E1s between the BSC and BTS is 62.
9-50
68P02900W21-T
Jul 2010
Planning example 3

Number of LCF-RSLs required, assuming only GPROC3s are used, is given by:
GL3 =
n (1 + 0.35 S + 0.34 H (1 0.4 i) + 0.32 L)

C
+ (0.00075 PGSM + 0.004) B +
19.6 T
120

62 * 3 * 27 * (1+0.35 * 2 + 0.34 * 2.5 * (1-0.4 * 0.6) + 0.32 * 2.1) / (19.6 * 96) + (0.00075 * 60
+ 0.004) * 62 + 62 * 3/120 = 12.638 ~ 13
Total Erlangs offered by the BSC with 62 sites with 4/4/4 configuration:
= 62 * 3 * 19.26 = 3582.36 Erlang
Total Erlangs carried by the BSC with 62 sites with 4/4/4 configuration:
= 62 * 3 * 18.87 = 3510.71 Erlang
The number of trunks required to carry traffic on the A Interface with less than 1% blocking
is 3602 (using offered Erlangs to calculate).
mentioned in Chapter 6 BSC planning steps and rules or according to the Table 6-12(Number of
HSP MTL at 13% utilization) in 4 HSP MTLs are required (without redundancy).
Since one GPROC3-2 LCF can support one HSP MTL, the number of LCFs is equal to the
number of HSP MTLs.
N mtls LCF = the number of LCFs for 4 HSP MTLs is 4
XBL requirements
Refer to Table 6-12 in Chapter 6 BSC planning steps and rules.
Number of XBLs required = 4 (using N = 3602)
GSL requirements
N/A (signaling links between BSC and PCU)
GPROC requirements
To determine the number of GPROCs:
NGPROC = B + L + C + R
B = number of BSP GPROC3s/GPROC3-2s (include redundancy) = 3.
L = total number of LCF GPROCs required = 17. (Where the number of RSL LCF is 13, MTL
LCF is 4)
C = number of CSFP GPROCs (dedicated) = 1.
R = number of pool GPROCs (for redundancy) = 3.
68P02900W21-T
9-51
Jul 2010
Planning example 3
NOTE
For common pool, one GPROC3-2 is suggested.
For MTL-LCF, GPROC3-2 is required.
For high reliability and availability, 3 GPROCs are required. One is for RSL
LCF redundancy, the second one for MTL LCF redundancy and the third one
for other GPROC function redundancy.
Total number of GPROCs for BSC = 3 + 17 + 1 + 3 = 24

MSI requirements
NBSC-RXCDR = Number of E1 links required at the BSC for interconnecting with the RXCDR
If HSP MTLs are used (go to MSC directly) and non_AMR supported.
NBSC-RXCDR = C + (X + B64 + T/4)) /31 = 0 + (2 + 4 + 3602/4)/31 = 29.24 ~ 30
Where 2 OMLs, and 4 XBLs are required.
PHR in the equation is not considered in non-AMR cases.
Additional 4 E1s are required for HSP MTL.
Hence, the number of MSIs required for the BSC to RXCDR interface is (30 + 4)/2 = 17.
Each BTS site in this example needs 1 E1 interconnections. Hence, the number of MSIs
required for BTSs is 62 / 2 = 31.
Determine the number of KSWs/DSW2s (N) required (if enhanced capacity mode is not enabled):
N=
((G n) + RGDPXCDR 16) + REGDP 96 + (RGDP2 24) + (M 64) + (RPSI T)

1016
Where:
G
the number of GPROCs (11).
RPSI
RGDP2
M
9-52
Is:
the number of PSI (N/A in this example)

N/A in this example (RXCDR case).
the number of MSIs.
68P02900W21-T
Jul 2010
Planning example 3
NOTE
RGDPXCDR and REGDP are not considered in the equation.
24 * 32 + 48 * 64 = 3840
Each KSW/DSW2 provides 1016 TDM timeslots. Hence, 4 non-redundant KSWs/ DSW2s are
required for this configuration. For redundancy, 4 additional KSWs/ DSW2s are required.
Thus, total KSWs/DSW2s required (with redundancy) = 4 + 4 = 8.
BSU shelves
Each BSU shelf can support up to 12 MSI cards or 8 MSI with 4 PSI. A total of 48 MSI cards are
required, based on the previous calculation. The total number of BSU shelves required is:
Total GPROCs = 24 and total MSIs = 48, split between 4 BSU shelves.
GPROCs
MSI cards
BSU 1
BSU 2
BSU 3
BSU 4
Check Limit
12
12
12
12
12
Where BSU 1, 2, 3, 4 have KSW/DSW2 in shelf.

Ensure that the following is true for each expansion shelf.
(G * n) + (M * 64) + (R * 16) 1016
That is,
6 * 32 + 12 * 64 < 1016
Consider KSWXs/DSWXs for this example as the configuration needs more than one shelf. The
KSWX/DSWX extends the TDM highway of a BSU to other BSUs and supplies clock signals to all
shelves in the multi-shelf configuration. The KSWX/DSWX can be used in expansion, remote and
local modes. Four BSU shelves with four master/redundant KSWs/DSW2s are required, which
implies that four expansion shelves are required. The number of KSWXs/DSWXs required (NKX)
is the sum of KSWXDSWXE, KSWX/DSWXR, and KSWX/DSWXL:

NKXL = K + SE = 4
NKX = 12 + 4 = 16
68P02900W21-T
9-53
Jul 2010
Planning example 3
NOTE
GCLK requirements
CLKX requirements
given by:

NCLKX = Roundup (4/6) (2) = 2

LANX requirements
NLANX = NBSU (1 + RF ) = 4 2 = 8
PIX requirements
PIX number of BSUs = 8
Line interfaces
Number of T43s = RoundUp (Number of MSIs)/3)
Number of T43s = RoundUp (48/3) = 16
The number of T43 boards required is 16
PSUs = NBSU * (2 + RF)
9-54
68P02900W21-T
Jul 2010
Planning example 3
PSU = 4 * (2 + 1) = 12
NVM = 0 or 1
RXCDR planning
The number of MSIs
The number of RXU shelves
The number of GCLKs
The number of CLKXs
The number of LANXs
The number of PIXs

Where:
C is the number of HSP MTL links required. Assuming HSP MTLs go from BSC to MSC directly,
C is 0 in equation.
X is the number of OML links through MSC. If OML links do not pass through MSC, X is equal to
0. Then an additional E1 is needed between RXCDR and OMC-R.
68P02900W21-T
9-55
Jul 2010
Planning example 3
T is the number of trunks between MSC and BSC (3602).
NRXCDRMSC = (3602) /31 = 116.2

~ 117
Each XCDR/GDP/GDP2 terminates one E1 link (for the RXU shelf).
Hence, the number of non-redundant cards required is 3602/31 = 117, which can be a mix of
XCDRs, GDPs and GDP2s. The number of non-redundant XCDR/GDP/GDP2 cards = 117.
GPROC requirements for RXCDR
Each shelf should have minimum of one GPROC. Hence, eight non-redundant GPROCs are
required. If the operator selects to use redundancy, 16 GPROCs are required.
The number of GPROCs required for RXCDR = 8 + 8 (for redundancy) = 16
As calculated in MSI requirements, the number of BSC-RXCDR links is 30 and 1 E1 for BSCOMC-R. Each MSI card interfaces 2 E1 links, hence, 16 MSI cards are required on the RXCDR.
MSI requirements for RXCDR = 16.
TDM timeslots required = G * n + M * 64 + R * 16
16 * 16 + 15 * 64 + 117 * 16 = 3216
Each KSW/DSW2 provides 1016 timeslots on the TDM highway, hence, 4 non-redundant
KSWs/DSW2s required for the RXCDR = 4 + 4 (redundant) = 8
Table 9-16
MSIS
XCDRS/GDPS
GPROCS
RXU 1
RXU 2
RXU 3
RXU 4
RXU 5
RXU 6
RXU 7
RXU 8
14
14
15
15
15
15
15
14

N + (G * n) + (M * 64) + (R * 16) 1016
Hence, 8 RXU shelves are required to equip 117 XCDR/GDP/GDP2 cards and 16 MSI cards.
The number of RXU shelves required = 8.
9-56
68P02900W21-T
Jul 2010
Planning example 3
RXU shelves
The number of RXU shelves required is given by (assumes an NVM board is fitted):
NRXU =
Max (M/5, (R + NNVM )) /16

Max (16/5, (117 + 1))
=
=8
19
19

KSWX/DSWXL. The calculations imply that two expansion and two extension shelves are
required.

NKXE = K (K 1) = 4 3 = 12
NKXR = SE = 4
NKXL = K + SE = 4 + 4 = 8
NKX = 12 + 4 + 8 = 24
NKX = 12 + 4 + 8 = 24
If KSWXs and DSWXs are used in like pairs, that is, KSWX connected to KSWX and DSWX
connected to DSWX, they can be used together in a shelf.
GCLK requirements
CLKX requirements
Provides expansion of GCLK timing to more than one RXU:
68P02900W21-T
9-57
Jul 2010
Planning example 3
Where:
E
RF
Is:
NCLKX = Roundup (8/6) (1 + 0) = 2

LANX requirements
NLANX = NRXU (1 + RF ) = 8 2 = 16
PIX requirements
Line interfaces
Number of T43s = Number of E1s/6 = (117 + 30 + 4 + 1)/6 = 26
PSUs = 2 * RXUs+RF * RXUs = 2 * 8 + 1 * 8 = 24
One redundant PSU is required for each RXU shelf, hence total number of PSUs required = 24.
NVM= 1 (required in this example)
9-58
68P02900W21-T
Jul 2010
Planning example of BSS support for LCS provisioning
Planning example of BSS support for LCS provisioning

Use this example to plan the equipment of a BSC supporting a traffic model, with the parameters
listed in Table 9-17 and their typical values
This example is for 28 sites/BSC with 3 cells/BTS and 4 carriers/cell.
Table 9-17 Typical LCS call model parameter

Parameter
Value
MAXIMUM TRUNKS BETWEEN MSC AND

BSC
N = 3000
NUMBER OF BTSS PER BSS

NUMBER OF CELLS PER BSS
CALL DURATION
CALL RATE [CALL/SUB/BH]
LCS PENETRATION RATE [%]
LCS REQUEST RATE2: [REQ/SEC/BSC]
28 4 * 4 * 4 SITES
28 * 3
T = 75 S
CALL_SUB_RATE = 1
LCS = 5%
LCS_BSC_RATE = 2
LINK UTILIZATION FACTOR UMSC_BSC
0.35
LINK UTILIZATION FACTOR U BSC_BTS
0.25
LCS planning example calculations

Determine LCS architecture
BSS-based LCS architecture is supported.
68P02900W21-T
9-59
Jul 2010
Calculate MTLs (actually needed trunks number is 1812)
nlink bss =
1000 U T
(40 + 47 S + 22 H (1 0.8i) + 24 L + 31 LCS ) + 9 + PPC (1 + LC )
1000 0.37 75
(40 + 47 0.1 + 22 2.5 (1 0.8 0.6) + 24 2 + 31 0.05) + 9 + 0.124 (1 + 0.05)
n1LCF-MTL = (20 * T)/(1 0.16 * S 0.5 * H * (1 0.6 * i) 0.42 * L 0.45 * L) + PPC * (0.005 * B 0.05)
* (1 LCS))
= 20 * 75 / (1 0.6 * 0.1 0.5 * 2.5 * (1 0.6 * 0.6) 0.42 * 0.05) 0.124 * (0.005 * 56 0.05) * (1 0.05))
= 559.268
n1min = MIN (nllink, n1LCF-MTL)= 151.468
nllogical = N/Ng = (1812/64) = 28.31
nlog_per_mtl = RoundDown (n1min/Nlogical) = 5
Finally, the number of required MTLs with 64 logical links is:
mtls = RoundUp (Ng/ Nlog_per_mtl) = 13
Calculate MTL LCFs

NLCF-MTL = 13/2 = 6
Calculate RSLs
According to Chapter 3 BSS cell planning, TCHs per BTS is 29 * 3. Then,
RSLGSM@64K =
9-60
n (49 + 50 + S + 32 H + 25 L + LCS 24)

(27 + 3 C) PGSM (1 + LCS )
+
1000 U T
8000 U
87 (49 + 50 + 0.1 + 32 2.5 + 20 2 + 0.05 24)

(27 + 3 3) 3 (1 + 0.05)
+
= 0.87
1000 0.25 120
8000 0.25
68P02900W21-T
Jul 2010
Calculate RSL LCFs

Number of LCF-RSLs required when using GPROC2 boards are as follows:
n (1 + 0.54 S + 0.48 H (1 0.58 i) + 0.38 L + 0.35 LCS )

C
+ (0.00091 PGSM + 0.004) B +
(18.98 T)
118
3000 (1 + 0.54 0.1 + 0.48 2.5 (1 0.58 0.6) + 0.38 2 + 0.35 0.05)
=
(18.98 120)
28 3
+ (0.00091 3 + 0.004) 28 +
118
= 4.14
GL3 =
Number of LCF-RSLs required when using GPROC3s or GPROC3-2s boards are as follows:
n (1 + 0.54 S + 0.506 H (1 0.5 i) + 0.39 L + 0.35 LCS )

C
+ (0.00091 PGSM + 0.002) B +
(35.16 T)
214
3000 (1 + 0.54 0.1 + 0.506 2.5 (1 .5 0.6) + 0.39 2 + 0.35 0.05)
=
(35.16 120)
28 3
+ (0.00091 3 + 0.002) 28 +
214
= 2.11
GL3 =
Therefore, the RSL LCFs number is 5 when GPROC2s are used and 3 when GPROC3s or
GPROC3-2s are used.
Calculate LMTLs
LMTL = Roundup
= Roundup
LCS BSC Rate 19

1000 UBSC SM LC
2 19
1000 0.2
=1
Calculate LMTL LCFs

N
LCF _LSL
68P02900W21-T
=1
9-61
Jul 2010
Planning example for GSR10 with no (E)GPRS and high signaling
Planning example for GSR10 with no (E)GPRS and high

signaling
Dimension a network with following requirements:
GSM software release = GSR10.
Number of sites 8/8/8 sites (BTS: HIISC2-S) = 31.
Without HR.
With HSP MTLs which are directly connected to the MSC that are in use (that is, the
MTLs that do not pass through RXCDR).
No LCS support.
No FastCallSetup.
Following are the call model parameters:
9-62
Call duration T = 91.22 s.
Ratio of SMSs per call S = 13.76.
Ratio of location updates per call = 2.73.
Ratio of IMSI detaches per call I = 0.05.
Location update factor L = 2.73 + 0.5 * 0.05 = 2.75.
Number of handovers per call H = 3.54.
Ratio of intra-BSC handovers to all handovers i = 0.9.
Paging rate per second PGSM = 90.80 pages per second.
Number of cells at the BTS CBTS = 3.
MTL link utilization = 13% (0.13).
RSL link utilization U = 25% (0.25).
CCCH utilization UCCCH = 33% (0.33).
Probability of blocking TCH PB-TCH < 1%.
Probability of blocking SDCCH PB-SDCCH < 1%.
Probability of blocking on A Interface < 1%.
68P02900W21-T
Jul 2010
Other considerations:
Line interface type = E1.
Network termination option = T43/PT43.
Power voltage option = -48/-60 V dc.
Type of combining used = Hybrid (CBF).
Dedicated CSFP = YES.
CSFP redundancy = NO.
Redundancy for all other modules = YES.
MTL links redundancy = YES.
RSL link redundancy = NO.
XBL link redundancy = NO.
BTS connectivity = Star configuration.
IMSI/TMSI paging = TMSI.
MTL load balancing granularity = 16.
NVM board fitted at BSC and RXCDR.
Cell planning - control channel calculations

From Erlang B tables, the number of Erlangs supported by 64 TCHs (8 carrier cell) with GOS of
1% is 50.60 Erlangs.
Total Erlangs offered by a 8/8/8 BTS = 3 * 50.60 = 151.80 Erlangs.
4 carrier cell - determining the number of CCCHs
Call =
e
50.60
=
= 0.56
T
91.22
SMS rate is given by:
S =
Se
13.76 50.60
=
= 7.63
T
91.22
Location update rate is given by:
LU =
68P02900W21-T
Le
2.73 50.60
=
= 1.51
T
91.22
9-63
Jul 2010
AGCH = call + S + LU = 9.70

NPCU =
PGSM
90.80
=
= 5.34
(4 4.25)
(4 4.25)
NAGCH =
AGCH
9.70
=
= 1.14
(2 4.25)
(2 4.25)
NPAGCH =
(9.70 + 1.14)
(NAGCH + NPCH )
=
= 19.64
UCCCH
0.33
Considering a non-combined BCCH with 9 CCCH blocks, 3 timeslots BCCH+CCCH are needed
here.
Determine the number of SDCCHs per cell
Using the values calculated in the previous section and other call model parameters, the average
number of SDCCHs, NSDCCH, is given by the formula mentioned Chapter 3 BSS cell planning:
NSDCCH = Call Tc + LU (TL + TG ) + S (TS + TG ) = 91.18

The number of SDCCHs to support an average number of busy SDCCHs of 91.18 Erlangs
signaling traffic with less than 1% blocking as determined by use of Erlang B tables is 108.
Hence, the number of timeslots required to carry SDCCH signaling traffic is 14 with each
timeslot offering maximum 8 SDCCHs.
Total number of signaling timeslots required for an 8 carrier configuration with the given call
SDCCHs each).
The number of traffic channels per 8 carrier cell = 64 17 = 47.
Traffic offered by an 8-carrier cell is 35.22 Erlangs (47 traffic channels at 1% GOS).
Total channels/cell = 64
Control and/or signaling channels = 17
9-64
68P02900W21-T
Jul 2010
BSS planning
The number of RSL links between the BSC and BTSs.
The number of E1 links between the BSC and BTSs.
The number of LCFs for RSL processing.
The number of MTL links between the BSC and MSC.
The number of LCFs for MTL processing.
The number of XBL links between the BSC and RXCDR.
The number of GSL links between the BSC and RXCDR.
The number of GPROCs.
The number of XCDR/GDP/GDP2s.
The number of MSI cards.
The number of KSWs/DSW2s.
The number of BSU shelves.
The number of KSWXs/DSWXs.
The number of GCLKs.
The number of CLKXs.
The number of LANXs.
The number of PIXs.
The number of line interface cards (T43s).
The number of digital power supplies.
Check if an optional NVM board is fitted.
RSL requirements
The number of 64 kbit/s RSLs required with the given by:
68P02900W21-T
9-65
Jul 2010
RSLGSM-GPRS@64k = Roundup (RSLGSM + RSLGPRS)
RSLGSM =
n (59 + S (25 + SMSGSM 0.125) + 38 H + 24 L + 24 LCS )

(31 + 3 CBTS ) PGSM
+
(1000 U T)
(8000 U)
RSLGSM =
141 (59 + 13.76 (25 + 100 0.125) + 38 3.54 + 24 2.75)

(31 + 3 3) 90.80
+
= 6.61
(1000 0.25 91.22)
(8000 0.25)
GSLGPRS =
5.5 GPRS RACH/sec

(32 + CBTS ) PGPRS
+
(8000 U)
(1000 U)
RSLGSM + GPRS = Roundup (RSLGSM + RSLGPRS) = Roundup (6.61 + 0) = 7.
nEGP RS
RT F DSO COU N T i
i=0
+ (nCGPRS 4) + (nGGPRS 2) + L16/4 + L64
31

= (24 * 2 + 7)/31 = 2
Hence, one E1 interconnection is required between each BTS and BSC for the given site
configurations (provided they are in star configurations). There are total of 31 * 2 = 62 E1 links
needed. The number of E1s between the BSC and BTS is 62.
Number of LCF-RSLs required when using GPROC2 boards are as follows:
C
n (1 + 0.54 S + 0.48 H (1 0.58 i) + 0.38 L)
+ (0.00091 PGSM + 0.004) B +
(18.98 T )
118
31 3 47 (1 + 0.54 13.76 + 0.48 3.54 (1 0.58 0.9) + 0.38 2.75)
=
(18.98 91.22)
31 3
+ (0.00091 90.80 + 0.004) 31 +
118
= 29.45 30
GL3 =
9-66
68P02900W21-T
Jul 2010
Number of LCF-RSLs required when using GPROC3 or GPROC3-2 boards are as follows:
n (1 + 0.54 S + 0.506 H (1 0.5 i) + 0.39 L)

C
+ (0.00091 PGSM + 0.002) B +
(35.16 T)
214
31 3 47 (1 + 0.54 13.76 + 0.506 3.54 (1 0.5 0.9) + 0.39 2.75)
=
(35.16 91.22)
31 3
+ (0.00091 90.80 + 0.002) 31 +
214
= 17.35 18
GL3 =
The maximum number of LCFs supported is 25 so the expected load cannot be supported
by GPROC2 boards and GPROC3 or GPROC3-2 boards are required to support the LCFs for
RSL processing.
Total Erlangs offered by the BSC with 31 sites with 8/8/8 configuration:
= 31 * 3 * 35.22 = 3275.46 Erlang
Total Erlangs carried by the BSC with 31 sites with 8/8/8 configuration:
=31 * 3 * 34.52 = 3210.36 Erlang
The number of trunks required to carry traffic on the A Interface with less than 1% blocking
is 3297 (using offered Erlangs to calculate).
Using the call model parameters, the number of MTLs can be calculated using formula
mentioned in Chapter 6 BSC planning steps and rules. Or according to the Table 6-12(Number
of HSP MTL at 13% utilization) in Chapter 6 BSC planning steps and rules, 4 HSP MTLs are
required (without redundancy).
Since one GPROC3-2 LCF can support one HSP MTL, the number of required LCFs is the
number of HSP MTLs.
NLCF = mtls
The number of LCFs for 4 HSP MTLs is 4.
XBL requirements
Number of XBLs required = 4 (using N = 3297).
GSL requirements
N/A (signaling links between BSC and PCU)
GPROC requirements
To determine the number of GPROCs:
NGPROC = B + L + C + R
B = Number of BSP GPROC3s/GPROC3-2s (include redundancy) = 3.
68P02900W21-T
9-67
Jul 2010
C = Number of CSFP GPROCs (dedicated) = 1.

R = Number of pool GPROCs (for redundancy) = 3.
NOTE
For common pool, one GPROC3-2 is required.
For high reliability and availability, three GPROCs are required. The first is
for the RSL LCF redundancy, the second is for the MTL LCF redundancy, and
the third is for the GPROC function redundancy. For GPROC redundancy,
refer to Chapter 6 BSC planning steps and rules. GPROC3 or GPROC3-2s are
required for the RSL LCFs. It is recommended that the pool GPROCs are also
GPROC3s/GPROC3-2s.
L = Total number of LCF GPROCs required = 22 (where the number of RSL LCF is 18 and
MTL LCF is 4).
NOTE
For MTL-LCF, GPROC3-2 is required.
Total number of GPROCs for BSC = 3 + 22 + 1 + 3 = 29.
MSI requirements
NMSI =
NBSCRXCDR
2

NBSC-RXCDR = Number of E1 links required at the BSC for interconnecting with the RXCDR.
NBSCRXCDR =
C+X+B64+[T(1PHR )+N16]
4
31
(TPHR )
8
If HSP MTLs directly connected to the MSC are used and the HR is not supported:
NBSCRXCDR =
0 + (2 + 4 + 3297/4)
(C + (X + B64 + T/4))
=
= 26.78 27
31
31
Where 2 OMLs, and 4 XBLs are required.
9-68
68P02900W21-T
Jul 2010
NOTE
PHR in the previous equation is not considered in non-HR cases. Additional 4 E1s
are needed for HSP MTL.
Hence the number of MSIs required for the BSC to RXCDR interface is (27 + 4)/2 = 16.
Each BTS site in this example requires one E1 interconnection. Hence the number of MSIs
required for BTSs is 62 / 2 = 31.
Total number of MSIs required at the BSC = 31 + 16 = 47.
Determine the number of KSWs/DSW2s (N) required (if enhanced capacity mode is not enabled).
N = (G n) + (Rgdprxcdr 16) + (Regdp 2 24) + (M 64) + (Rpsi t) /1016

G = the number of GPROCs.
n = 16 or 32 (32 in this example).
Rgdp = N/A in this example (RXCDR case).
M = the number of MSIs.
Rpsi = the number of PSI (N/A in this example)
NOTE
RGDPXCDR and REGDP are not considered in the previous equation.
29 * 32 + 47 * 64 = 3936
Each KSW/DSW2 provides 1016 TDM timeslots. Hence, four non-redundant KSWs/ DSW2s are
required for this configuration, irrespective of the GPROC used for RSl LCF functionality. For
redundancy, four additional KSWs/ DSW2s are required.
Therefore, the total KSWs/DSW2s required (with redundancy) = 4 + 4 = 8.
BSU shelves
Each BSU shelf can support up to 12 MSI cards or 8 MSI with 4 PSI. A total of 47 MSI cards are
required, based on the previous calculation. The total number of BSU shelves required is:
Total GPROCs = 29 and total MSIs = 47, split between 4 BSU shelves:
GPROCs
MSI cards
BSU1
BSU2
BSU3
BSU4
Check Limit
12
12
12
11
12
Where BSU 1, 2, 3, 4 have KSW/DSW2 in shelf.

68P02900W21-T
9-69
Jul 2010
Ensure that the following is true for each expansion shelf:
(G * n) + (M * 64) + (R * 16) 1016
7 * 32 + 12 * 64 < 1016
Therefore, the number of BSU shelves required to accommodate the required hardware for this
configuration is NBSU = 4.
KSWXs/DSWXs should be considered for this example as the configuration requires more
than one shelf. The KSWX/DSWX extends the TDM highway of a BSU to other BSUs and
supplies clock signals to all shelves in the multi-shelf configuration. The KSWX/DSWX may be
used in expansion, remote, and local modes. Four BSU shelves with four master/redundant
KSWs/DSW2s, which implies four expansion shelves are required. The number of KSWXs/DSWXs
required (NKX) is the sum of KSWX/DSWXE, KSWX/DSWXR, and KSWX/DSWXL:
NKXE = K * (K-1) = 4 * 3 = 12 (K is the number of non-redundant KSWs).
NKXR = SE = 0 (SE is the number of extension shelves).
NKXL = K + SE = 4 + 0 = 4.
NKX = 12 + 4 = 16.
The number of KSWXs/DSWXs required (with redundancy) = 32.
NOTE
The maximum number of KSWX/DXWX slots per shelf 18. If KSWXs and DSWXs
are used in like pairs, that is, KSWX connected to KSWX and DSWX connected to
DSWX, they can be used together in a shelf.
GCLK requirements
The number of GCLKs required (with redundancy) = 2.
CLKX requirements
CLKX provides expansion of GCLK timing to more than one BSU. Number of CLKXs required is
given by:
NCLKX = Roundup
9-70

E
(1 + RF )
6
68P02900W21-T
Jul 2010
NCLKX = Roundup

4
2=2
6
The number of CLKXs required (with redundancy) = 2.

LANX requirements
NLANX = NBSU (1 + RF )
Where, RF is the redundancy factor.
NLANX = 4 2 = 8
Total number of LANXs required (with redundancy) = 8.
PIX requirements
PIX provides eight inputs and four outputs for site alarms:
Line interfaces
Number of T43s = RoundUp (Number of MSIs / 3)
Number of T43s = RoundUp (47/3) = 16
The number of T43 boards required is 16.

PSUs = NBSU (2 + RF )
PSU = 4 (2 + 1) = 12
Non volatile memory (NVM) board for BSC (optional)
RXCDR planning
The number of links between the RXCDR and BSC.
The number of E1 links between the RXCDR and MSC.
68P02900W21-T
9-71
Jul 2010
The number of XCDR/GDP2/GDP2s.
The number of MSIs.
The number of RXU shelves.
The number of GPROCs.
The number of KSWs/DSW2s.
The number of KSWXs/DSWXs.
The number of GCLKs.
The number of CLKXs.
The number of LANXs.
The number of PIXs.
The number of line interface boards (T43s).
The number of digital power supply units.
Check if an optional NVM board is fitted.

Refer to MSI requirements in BSS planning on page 9-65
Number of RXCDR to MSC links is given by the greater of the results for the following equations:
NRXCDRMSC = C2M +
NRXCDRMSC + C2M +
T
30
(X + T)
31
Where:
C2M is the number of HSP MTL links required. HSP MTLs go from BSC to MSC directly
so C is 0.
X is the number of OML links through MSC (2).
T is the number of trunks between MSC and BSC (3297).

NRXCDR-MSC = 3297/30 = 109.9 ~ 110
NRXCDR-MSC = (2 + 3297)/31 = 106.42 ~ 107
The number of E1 links between the RXCDR and MSC = 110.

Each GDP terminates one E1 link and each GDP2 can terminate one or two E1 links depending
on the RXU shelf used.
9-72
68P02900W21-T
Jul 2010
Hence, the number of non-redundant cards required based on GDP2s terminating two E1s
is (3297/30)/2 = 55.
MSI Requirements for RXCDR
interfaces two E1 links, hence, 14 MSI cards are required on the RXCDR.
RXU shelves
The number of RXU shelves required is given by (assuming that an NVM board is fitted):

14 (55 + 1)
(R + NNVM )
= Max
,
=4
NRXU = Max M/5,
16
5
16
GPROC requirements for RXCDR
Each shelf should have at least one GPROC. Hence, four non-redundant GPROCs are required.
If the operator chooses to use redundancy eight GPROCs are required.
The number of GPROCs required for RXCDR = 4 + 4 (for redundancy) = 8.
TDM timeslots required = G * n + M * 64 + R * 16 = 8 * 16 + 14 * 64 + 55 * 24 = 2344
Each KSW/DSW2 provides 1016 timeslots on the TDM highway, hence, three non-redundant
KSWs/DSW2s required for the RXCDR = 3 + 3 (redundant) = 6.
MSIs
GDP2s
GPROCs
RXU1
RXU2
RXU3
RXU4
14
14
14
13
N = (G n) + (M 64) + (R 24) 1016

Hence, four RXU shelves are required to equip 55 GDP2 cards and 14 MSI cards. The number of
RXU shelves required = 4.
KSWX/DSWXL. The above calculations imply that two expansion and two extension shelves are
required.

= K (K 1) = 4 3 + 12
68P02900W21-T
9-73
Jul 2010
NKXR + SE = 4
SEis the number of extension shelves.
NKXl = K + SE = 4 +4 = 8
NKX = 12 + 4 + 8 = 24
The number of KSWXs/DWSXs required = 24 + 24 (redundant) = 48.
NOTE
GCLK requirements
Number of GCLKs required = 1 + 1 (redundant) = 2.
CLKX requirements
CLKX provides expansion of GCLK timing to more than one RXU:
NCLKX = Roundup (E/6) (1 + RF ) = 2

Where:
E is the number of expansion/extension shelves.
RF is the redundancy factor.
NCLKX = Roundup (8/6) * (1 + 0) = 2

The number of CLKXs required = 2 + 2 (redundant) = 4.
LANX requirements
NLANX = NRXU (1 + RF ) = 8 2 = 16
Total number of LANXs required with redundancy = 16.
PIX requirements
PIX provides eight inputs and four outputs for site alarms:
PIX 2 * Number of RXUs = 2 * 8 = 16.
9-74
68P02900W21-T
Jul 2010
Therefore, 16 PIX cards are required for the RXCDR.

Line interfaces
Number of T43s = Number of E1s/6 = (55 + 30 + 4 + 1)/6 = 26.
The number of T43 boards required = 26.
PSUs = 2 * RXUs + RF * RXUs = 2 * 8 + 1 * 8 = 24.
One redundant PSU is required for each RXU shelf, hence total number of PSUs required = 24.
Non volatile memory (NVM) board for RXCDR (optional)
NVM = 1 (required in this example).
68P02900W21-T
Jul 2010
9-75
9-76
68P02900W21-T
Jul 2010
Chapter
10
Location area planning
This section provides a description of location area planning with an example. Each operator
should undertake this exercise to optimize the network configurations based on the paging load
on the BSC. The topics described here are as follows.
Location area planning considerations on page 10-2
Location area planning calculations on page 10-3
68P02900W21-T
Jul 2010
10-1
Location area planning considerations
Location area planning considerations
Before the GSR4 BSS software release, the traffic handled by the BSC was limited by the
number of BTSs and carriers that could be handled by the BSC. Increasing BSC capacities have
an impact on some of the call model parameters, especially the paging load on the BSC.
Since an MS is paged in a location area, paging rate depends on the number and size of BSCs in
that location area. If there are too many BSCs in a location area, each with large number of
BTS sites and high traffic handling capacity, it results in high paging load on each of the BSCs
in that location area. This leads to more hardware (LCF GPROCs) having to be equipped on
each BSC. Increasing the number of location areas increases the number of location updates
on the cells bordering the location area. Provision more SDCCHs for this increased signaling
on the border cells. Fewer channels are available for traffic.
A well-planned network should have similar paging loads in each location area. A small paging
load suggests that the location area is too small and could be combined with neighboring
location areas, minimizing location update activity, and reducing use of SDCCH resources. A
paging load too close to the theoretical maximum paging load (calculated using the number of
PCHs used and if mobile is paged using IMSI or TMSI) would suggest that the location area
is too large and should be split into multiple location areas, to avoid paging overload and the
need for extra hardware.
This exercise should be undertaken by each operator to optimize the network configurations
based on the paging load on the BSC. This topic is explained further, with an example, in the
following sections.
10-2
68P02900W21-T
Jul 2010
Location area planning calculations
Location area planning calculations
Example procedure
Assume a network with four BSCs under a location area (refer to Figure 10-1) each with call
model parameters as shown in Table 10-1.
Table 10-1
Example of values for the parameters for location area planning

Parameter
Call duration, T
sValue
90 s
Number of SMSs per call, S
Number of location updates per call (nonborder)
IMSI detaches per call, Id

Location update factor
Number of handovers per call, H
Number of intra-BSC handovers to all handovers, i
0.2 (type 2)
2 + 0.5 * 0.2 = 2.1
1.32
0.6
MTL link utilization
20%
RSL link utilization
25%
CCCH utilization
33%
Probability of blocking TCH PB-TCH
< 2%
Probability of blocking SDCCH PB-SDCCH
< 1%
Probability of blocking on A Interface
< 1%
Paging repetition
Ratio of incoming calls and SMSs to the total calls and SMSs
1.2
0.50
Further assume that each of the BSC handles about 1200 Erlangs (48 sites with 2/2/2
configurations and 2 sites with omni 2 configuration) of traffic.
68P02900W21-T
10-3
Jul 2010
Example procedure
Figure 10-1 Four BSCs in one LAC
MSC
LAC=1
BSC
BSC
BSC
BSC
ti-GSM-Four_BSCs_in_one_LAC-00146-ai-sw
The paging rate in the location area can be calculated using the following formula:
P = paging repetition % of incoming calls and SM S total calls and SM S in the LA per second
= 1.2 0.50 (4 1200) /96 (1 + 2)
= 90 pages per second
Now, calculate the number of GPROC LCF-RSLs required with this paging load using the
formula detailed in Chapter 6 BSC planning steps and rules.
(2044 (1 + 0.35 2 + 0.34 1.32 (1 0.4 0.6) + 0.32 2.1)) / (19.6 96) + (0.00075 90 + 0.004) 50+
146/120 = 7.74
The number of GPROC2s per BSC required for RSL is 8.
Since most of the cells in the BSC are non-border cells, the location updates per cell is around 2.
Based on this figure, calculate the number of SDCCHs required for each cell.
From Erlang B tables, the number of Erlangs supported by 16 TCHs (2 carrier cell) with GOS of
2% is 9.83 Erlangs.
call = e/T
Use the formulae provided in Chapter 3 BSS cell planning for control channel calculations
as follows:
10-4
68P02900W21-T
Jul 2010
Example procedure
Call arrival rate:
call = e/T = 9.83/96 = 0.1024

Ratio of SMSs to calls:
S = S e/T = 2 9.83/96 = 0.2048

Ratio of location updates to calls:
LU = L e/T = 2.1 9.83/96 = 0.215

The average number of SDCCHs, NSDCCH is given by:
NSDCCH = call TC + LU (TL + Tg ) + S (TS + Tg )

= 0.1024 5 + 0.215 (4 + 4) + 0.2048 (6 + 4)
= 4.28
The number of SDCCHs to support an average number of busy SDCCHs of 4.28, with less that
1% blocking as determined by use of Erlang B tables, is 10. Hence, the number of timeslots
required to carry SDCCH signaling traffic is 2 with each timeslot offering 8 SDCCHs.
The number of PCHs to support GSM CS paging only, is given by (assuming IMSI paging):
NP CH GSM = PGSM / NP ages/Block 4.25

= 90/ (2 4.25)
= 10.59
= 11
This means that it is likely that a maximum of 2 additional CCCH timeslots (or a minimum of 1)
are required to support this level of paging.
Now, use the same call model parameters and divide the location area so that each location
area contains two BSCs (refer to Figure 10-2). Dividing the location area into two location areas
increase the location updates on the border cells. Assume that 25% of the cells under a BSC
become border cells (a conservative estimate) and the number of location updates per call goes
up to 6 on cells on the location area border. The average number of location updates per call for
the BSC would approximately be equal to 3 (0.25*6 + 0.75*2).
68P02900W21-T
10-5
Jul 2010
Example procedure
Figure 10-2
Four BSCs divided into two LACs
MSC
LAC = 1
LAC = 2
BSC
BSC
BSC
BSC
ti-GSM-Four_BSCs_divided_into_two_LACs-00147-ai-sw
Location update factor:
L = 3 + 0.5 0.2 = 4
Since the location area now has two BSCs, the paging rate is given by:
P aging Rate = 1.2 0.5 (2 1200) /96 (1 + 2) = 45 pages/second

The number of GPROC LCFs required for RSL (using the formula) = 4.70 = 5
(2044 (1 + 0.35 2 + 0.34 1.32 (1 0.4 0.6) + 0.32 3.1)) / (19.6 96) + (0.00075 45 + 0.004) 50 + 146/120
= 6.399
= 7 GP ROC2 RSL LCF s
This simple expedient of reducing the number of BSCs in a LA has reduced the required number
of GPROC2 RSL-LCFs by 1 per BSC, and therefore 4 GPROC2s for the whole LA of 4 BSCs.
10-6
68P02900W21-T
Jul 2010
Example procedure
Call arrival rate:
call = e/T = 9.83/96 = 0.1024

Ratio of SMSs to calls:
S = S e/T = 2 9.83/96 = 0.2048

Ratio of location updates to calls:
LU = L e/T = 3.1 9.83/96 = 0.317

The average number of SDCCHs for border cells, NSDCCH is given by:
NSDCCH = call TC + LU (TL + Tg ) + LU (TS + Tg )

= 0.1024 5 + 0.317 (4 + 4) + 0.2048 (6 + 4)
= 5.096
The number of SDCCHs to support an average number of busy SDCCHs of 5.096 with less than
1% blocking as determined by use of Erlang B tables, is 11. Hence, the number of timeslots
required to carry SDCCH signaling traffic is 2, with each timeslot offering 8 SDCCHs.
The number of PCHs to support GSM CS paging only, is given by (assuming IMSI paging):

N P CH GSM = P GSM/ NP ages/Block 4.25 = 45/ (2 4.25) = 5.29 = 6
This means that a maximum of 1 additional CCCH timeslot (or a minimum of 0) is required to
support this level of paging.
This result shows that with the same number of timeslots for SDCCHs for this example, in
addition to reduced timeslots of CCCH (PCH), savings on equipment could be achieved by the
simple expedient of decreasing the number of BSCs per LA. The increase in SDCCHs due to
increased LA signaling is compensated by the decrease in PCHs.
If the network planner divides the location area such that not too much traffic crosses the border
of the location area (resulting in a lower number of location updates), even fewer resources
are required of the air interface for location update signaling.
68P02900W21-T
Jul 2010
10-7
Example procedure
10-8
68P02900W21-T
Jul 2010
Chapter
11
The derivation of call model parameter values from the GSM network statistics collected at the
OMC-R are described in this chapter. Most of the calculations used for equipment planning
use the standard call model parameters. Each network behaves in a unique way. Hence, the
operators must compute their own set of call model parameter values for a network based on
the performance statistics collected at the OMC-R. This helps to optimize the configurations
on a network.
All the statistics used for determining the call model parameters must be collected during the
busy hours and must be averaged over a reasonable time (three months or more).
The call model parameters calculated should be averaged over the entire network or at the
BSC level for equipment dimensioning purposes. This helps in averaging out the load from
the network entities.
The topic described here is Deriving call model parameters from network statistics.
68P02900W21-T
Jul 2010
11-1
Standard call model parameters

Table 11-1 lists the standard call model parameters.
Table 11-1 Typical parameters for BTS call planning

Parameter reference
Call duration
T = 83.27 seconds
S = 3.2
Number of handovers per call (Refer to NOTE)
H = 3.54
Ratio of location updates to calls: non-border

location area.
Ratio of location updates to calls: border location
area
l = 2I = 2.73
I = 0.05
Location update factor: non-border location area

(Refer to NOTE)
Location update factor: border location area (Refer
to NOTE)
L = 2L = 2.75
GSM circuit-switched paging rate in pages per

second
PGSM = 90.8
Ratio of intra-BSC handovers to all handovers (Refer

to NOTE)
i = 0.82
LCS = 0
LRMT = 0.95
LRMO = 0.05
Percent link utilization (MSC to BSS) for 64 k
U(MSC - BSS) = 0.20
Percent link utilization for HSP MTL
U(MSC - BSS) = 0.13
U(BSC - BTS) = 0.25
UBSC-RXCDR = 0.40
UBSC-SMLC = 0.40
UBSC-PCU = 0.25
Percent link utilization (BSS to SGSN)
UGBL = 0.40
UCCCH = 0.33
Block Rate for TCHs
B-TCHs
PB-Trunks = 0%
l = 2I = 7
L = 2L = 7.02
= 1%
Continued
11-2
68P02900W21-T
Jul 2010

Parameter reference
CBTS = 3
SMSSIZE = 100 bytes
BSCLA = 1
BHCAsub = 1.03

MNEWCALL = 1
Number of XBL messages per hr <-> fr handover
MHANDOVER = 1
LXBL = 50
Hhr-fr = 1
GPRS parameters
PKSIZE = 315.48
GPRS Traffic per sub/BH (kBytes/hr) - Uplink
ULRATE = 1.48
GPRS Traffic per sub/BH (kBytes/hr) - Downlink
DLRATE = 5.96
SMSSIZE = 100 bytes
PSATT/DETACH = 0.49
PDPACT/DEACT = 0.63
Routing area update
RAU = 1.4
PGPRS = 2.02
Coding scheme rates (CS1 to CS4) at the RLC/MAC

layer
CS1
CS2
CS3
CS4
Coding scheme usage (CS1 to CS4) at a BLER of 5%
CS1_usage_UL = 11%
CS1_usage_DL = 8%
CS3_usage_UL = 8%
CS3_usage_DL = 21%
Percentage GPRS coding scheme usage in total

traffic (Refer to NOTE)
CellUpdate = 0.33
= 9.2 kbps
= 13.6 kbps
= 15.8 kbps
= 21.8 kbps
EGPRS parameters
PKULSIZE = 130.75
PKDLSIZE = 485.9
EGPRS Traffic per sub/BH (kBytes/hr) - Uplink
ULRATE = 1.48
Continued
68P02900W21-T
11-3
Jul 2010

Parameter reference
EGPRS Traffic per sub/BH (kBytes/hr) - Downlink
DLRATE = 5.96
PSATT/DETACH = 0.49
PDPACT/DEACT = 0.63
Routing area update
RAU = 1.4
PGPRS = 2.02
Coding scheme rates (MCS1 to MCS9) at the

RLC/MAC layer
MCS1
MCS2
MCS3
MCS4
MCS5
MCS6
MCS7
MCS8
MCS9
Coding scheme usage (MCS1 to MCS9) at a BLER

of 12.02%
MCS1_usage_DL = 11%
MCS2_usage_UL = 2%
MCS2_usage_DL = 12%
MCS4_usage_DL = 7%
MCS5_usage_DL = 5%
MCS6_usage_DL = 19%
MCS7_usage_DL = 8%
MCS8_usage_DL = 8%
Percentage EGPRS coding scheme usage in total

traffic (Refer to NOTE)

(bytes) Uplink (Refer to NOTE)
PKULSIZE = 130.75

(bytes) Downlink (Refer to NOTE)
PKDLSIZE = 485.9
= 10.55 kbps
= 12.95 kbps
= 16.55 kbps
= 19.35 kbps
= 23.90 kbps
= 29.60 kbps
= 31.10 kbps
= 46.90 kbps
= 61.30 kbps
QoS parameters
11-4
GBRAVG_UL = 3.80
GBRAVG_DL = 5.59
GBRPEAK_UL = 9.64
GBRPEAK_UL = 12.69
68P02900W21-T
Jul 2010
Call duration (T)
NOTE
The handovers include 2G-3G handovers.
L is a function of I. It depends on the following message sequences used for IMSI

detach: short message sequence (type 1) and long message sequence (type 2)
and whether short message sequence (type 1) or long message sequence (type
2) is used for IMSI detach. Typically I = 0 (disabled), but when it is enabled:
Type 1: L = I + 0.2 * I
Type 2: L = I + 0.5 * I
The percentages represent the split of the traffic for GPRS and EGPRS traffic
mix, which is network-dependent. The percentages can be used to determine
the average traffic per sub/BH for a GPRS and EGPRS traffic mix as follows:
Traffic per sub/BH for GPRS and EGPRS mix (kBytes/hr) = (Percentage
GPRS coding scheme usage in total traffic * GPRS Traffic per sub/BH) +
(Percentage EGPRS coding scheme usage in total traffic * EGPRS Traffic
per sub/BH)
The average packet sizes for a GPRS and EGPRS traffic mix are based on the
GPRS and EGPRS percentage splits defined for this model.
The MS in the extended range has a lower coding scheme than in the normal
range due to the longer distance between the MS and BTS. For the cell with
extended PDCH, the lower coding scheme has a higher usage percentage value
than the corresponding typical usage percentage value given in Table 11-1
Call duration (T)

Average call duration for a network can be derived from the statistics BUSY_TCH_MEAN and
TOTAL_CALLS using the following formula:
T=
i=1
N
P
i=1
68P02900W21-T
N
P
Busy TCH MEAN stat interval in sec
TOTAL CALLS + ASSIGNMENT REDIRECTION
11-5
Jul 2010
Ratio of SMSs per call (S)
Where:
Is:
number of cells under the BSC.
BUSY_TCH_MEAN
average number of busy TCHs in the cell. It is updated each time an

allocation or de-allocation of a TCH occurs. It provides a mean value
indicating the average number of TCHs in use. The time recorded
for a TCH in use includes the guard time (T3111), which is the time
allowed between ending a call and starting another call.
TOTAL_CALLS
number of circuit-oriented calls that originate in the cell. It is

pegged only once per connection at the time of the first successful
TCH assignment procedure. Subsequent channel changes are not
counted.
ASSIGNMENT_
REDIRECTION
total number of assignments that were redirected to another cell,

due to redirected retry handover procedure, multiband band
reassignment procedure, or handover during assignment procedure.
stat_interval_in_sec
interval in which statistics are collected. It is 3600 if the statistic

interval is one hour and 1800 if the statistic interval is 30 minutes.
Call duration (T) in the formula is calculated for one cell and should be calculated as an average
of call durations of all the BSCs in the network.
Ratio of SMSs per call (S)

The number of SMSs per call can be calculated using the SMS-related statistics parameters
in the following formula:
N
P
S=
i=1
N
P
i=1
(SMS INIT ON SDCCH + SMS INIT ON TCH)
(TOTAL CALLS + ASSIGNMENT REDIRECTION)
Where:
N
SMS_INIT_ON_SDCCH
SMS_INIT_ON_TCH
Is:
number of times an SMS transaction occurs on an SDCCH.
number of times an SMS transaction occurs on a TCH.
TOTAL_CALLS
number of circuit-oriented calls that originate in the cell.

It is pegged only once per connection at the time of the
first successful TCH assignment procedure. Subsequent
channel changes are not counted.
ASSIGNMENT_REDIRECTION
total number of assignments that were redirected to

another cell, due to redirected retry handover procedure,
multiband band reassignment procedure, or handover
during assignment procedure.
The ratio of SMSs per call must be averaged over all the BSCs in the network.
11-6
68P02900W21-T
Jul 2010
Ratio of handovers per call (H)

Handovers can be inter-BSS, intra-BSS or intra-cell. Therefore, the number of handovers per
call can be calculated using the following formula:
H=
N
P
i=1
out inter bss req to msc + out intra bss ho atmp+

intra cell ho atmp
N
P
i=1
Where:
Is:
out_inter_bss_req_to_msc
number of outgoing inter-BSS handover requests to the MSC.
out_intra_bss_ho_atmpt
number of times the assignment command is sent to an MS to

initiate an outgoing intra-BSS handover attempt.
intra_cell_ho_atmpt
number of times an assignment command is sent to an MS, to

initiate an intra-cell handover attempt.
TOTAL_CALLS
number of circuit-oriented calls that originate in the cell. It

is pegged only once per connection at the time of the first
successful TCH assignment procedure. Subsequent channel
changes are not counted.
ASSIGNMENT
_REDIRECTION
total number of assignments that were redirected to another

cell, due to redirected retry handover procedure, multiband
band reassignment procedure, or handover during assignment
procedure.
H should be averaged over all the BSCs in the network.
NOTE
The TOTAL_CALLS parameter is the count of the total circuit-switched calls in a cell.
It should be summed for all the cells in the BSC, when used in the formula.
Ratio of intra BSS handovers to all handovers (i)

Using the statistics previously detailed, this ratio can be calculated for a cell as follows:
i=
i=1
N
P
i=1
68P02900W21-T
N
P
(out intra bss ho atmpt + intra call ho atmpt)
(out inter bss req to msc + out intra bss ho atmpt + intra cell ho atmpt)
11-7
Jul 2010
Ratio of location updates per call (I)
Where:
N
Is:
i should be averaged over all the cells in the network.
Ratio of location updates per call (I)

The ratio of location updates per call, for a cell, can be calculated using the following formula:
I=
N
P
i=1
N
P
i=1
OK ACC PROC [location update]
Where:
Is:
OK_ACC_PROC
[location_update]
counts the number of MS requests for location updates.
TOTAL_CALLS
number of circuit-oriented calls that originate in the cell.

It is pegged only once per connection at the time of the
first successful TCH assignment procedure. Subsequent
channel changes are not counted.
counts the total number of assignments that were

redirected to another cell, due to redirected retry
handover procedure, multiband band reassignment
procedure, or handover during assignment procedure.
The ratio I should be averaged over all the BSCs in the network.
Ratio of IMSI detaches per call (I)

IMSI detaches 0 if disabled. If enabled, it is calculated per cell as follows:
I=
i=1
N
P
i=1
11-8
N
P
(OK ACC PROC [imsi detach])
68P02900W21-T
Jul 2010
Where:
N
Is:
the number of cells under the BSC.
OK_ACC_PROC
[imsi_detach]
counts the number of MS requests for IMSI detach.
TOTAL_CALLS
the number of circuit-oriented calls that originate in

the cell. It is pegged only once per connection at the
time of the first successful TCH assignment procedure.
Subsequent channel changes are not counted.
counts the total number of assignments that were

redirected to another cell, due to redirected retry handover
procedure, multiband band reassignment procedure, or
handover during assignment procedure.
The ratio I should be averaged over all the BSCs in the network.

The location update factor is calculated using the ration of location updates per call (l) and the
ratio of IMSI detaches per call (I). For networks with IMSI detach disabled, the location update
factor equals the ratio of location updates per call (l).
If IMSI detach is enabled, L is calculated as follows depending on whether short message
sequence (type 1) or long message sequence (type 2) is used:
L = l (IMSI detach disabled, that is, I = 0)
L = l + 0.2* I (type 1)
L = l + 0.5* I (type 2)
IMSI detach types indicate the way the MSC clears the connection with the BSS after receiving
the IMSI detach. When using IMSI detach type 1, the MSC clears the SCCP connection, a
clearing procedure that involves only one uplink (average size of 42 bytes) and one downlink
message (average size of 30 bytes). When using IMSI detach type 2, the MSC sends the CLEAR
COMMAND and the BSS sends CLEAR COMPLETE, which involves three uplink (average
size of 26 bytes) and three downlink messages (average size of 30 bytes). A location update
procedure itself takes five downlink messages (average size of 30 bytes) and six uplink messages
(average size of 26 bytes).
Hence, an IMSI detach (type1) takes a total of 2/11 (approximately 0.2) of the total number of
messages as a location update and an IMSI detach (type 2) takes 6/11 (approximately 0.5) of
the messages of a location update.
Paging rate (PGSM)

PAGE_REQ_FROM_MSC counts the number of paging messages received by the BSS from
the MSC during the statistics time interval. The paging message is then sent to the BSS in
an attempt to locate a particular MS. Each message refers only to one MS. The BSS in turn
transmits a paging message over the PCH, which may include identities for more than one MS
(two MSs if paged using IMSI and four if using TMSI).
68P02900W21-T
11-9
Jul 2010
Pages per call (PPC)
An MS is paged in a location area, which encompasses multiple BSCs. It is also possible to

have multiple location areas within a BSC. The paging rate, therefore, is a summation of the
paging messages sent to each location area in a BSC, averaged over the interval period. Since
PAGE_REQ_FROM_MSC is kept on a per cell basis, the value of this counter for any cell in
that location area, for a given statistics interval, denotes the pages in the location area during
that statistics interval.
PGSM =
N
P
i=1
N
P
i=1
(PAGE REQ FROM MSC)
(stat interval in seconds ith location area in bsc)
Where:
Is:
PAGE_REQ_FROM_MSC
number of paging messages received from the MSC by the BSS.

This statistic is pegged when a paging message is received
pertaining to the cell in which the MS is paged.
Pages per call (PPC)

Pages per call for a BSC can be calculated as:
Ppc =
N
P
i=1
N
P
i=1
Where:
N
(PAGE REQ FROM MSC)
Is:
Alternatively, pages per call can be calculated using the formula:
PPC = PGSM (T/N)

Where:
Is:
number of MSC-BSC trunks.
call duration, in seconds.
PPC = PGSM (T/e)
11-10
Where:
Is:
BSC Erlang.
68P02900W21-T
Jul 2010
Percent link utilization MSC to BSS [U(MSC BSS)]
Percent link utilization MSC to BSS [U(MSC BSS)]

The percent link utilization MSC to BSS on the uplink and downlink can be calculated using the
following formulae:
U(MSCBSS) =
(MTP MSU TX 6) + MTP SIF SIO TX + (SIB TX 7)

MTP LINK INS MTL Rate 8
U(MSCBSS) =
(MTP MSU RX 6) + MTP SIF SIO RX + (SIB RX 7)

MTP LINK INS MTL RATE 8
Where:
Is:
MTP_MSU_RX
number of MSUs received over a link.
MTP_MSU_TX
number of MSUs transmitted on a link.
MTP_SIF_SIO_RX
number of SIFs and SIOs received over a link.
MTP_SIF_SIO_TX
number of SIFs and SIOs transmitted over a link.
SIB_RX
number of SIB LSSU messages received over a link.
SIB_TX
number of SIB LSSU messages transmitted over a link.
MTP_LINK_INS
MTL_Rate
length of time a signaling link is in service in milliseconds.

number of DS0 channels on E1 that are equipped as MTL. For
example, MTL_Rate = 1 means only one DS0 channel is equipped as
MTL, so the bandwidth of MTL is 1 * 64 kbps = 6 4 kbps. If MTL_Rate
= 31, it means the whole span of E1 is equipped as MTL.
Percent link utilization BSC to BTS [U(BSC BTS)]

The percent link utilization BSC to BTS on the uplink and downlink for 64 kbps RSLs can be
calculated using the following formulae:
U(BSCBTS) =
RSL TX OCTETS
100%
RSL LINKS INS RSL BANDWIDTH FACTOR 2
U(BSCBTS) =
RSL RX OCTETS
100%
RSL LINK INS RSL BANDWIDTH FACTOR 2
Where:
RSL_TX_OCTETS
the number of octets transmitted on a link.
RSL_RX_OCTETS
the number of octets received over a link.
RSL_LINK_INS
RSL_BANDWIDTH_FACTOR
68P02900W21-T
Is:
the length of time a signaling link is in service in

milliseconds.
A factor based on the rate of the RSL. It has a value of 1 for
16 kbps RSLs and a value of 4 for 64 kbps RSLs.
11-11
Jul 2010

The percent link utilization BSC to SMLC on the uplink and downlink may be calculated using
the following formulas:
U(BSC SMLC) =
N
P
(LMTP MSU TX 6) + LMTP SIF SIO TX + (LMTP SIB TX 7)
i=1
N
P
i=1
U(BSC SMLC) =
N
P
i=1
LMTP LINK INS 8
(LMTP MSU RX 6) + LMTP SIF SIO RX + (LMTP SIB RX 7)

N
P
i=1
LMTP LINK INS 8
Where:
Is:
number of LMTLs to the BSC.
LMTP_MSU_RX
number of MSUs received over a link.
LMTP_MSU_TX
number of MSUs transmitted on a link.
LMTP_SIF_SIO_RX
number of SIFs and SIOs received over a link.
LMTP_SIF_SIO_TX
number of SIFs and SIOs transmitted over a link.
LMTP_SIB_RX
number of SIB LSSU messages received over a link.
LMTP_SIB_TX
number of SIB LSSU messages transmitted over a link.
LMTP_LINK_INS
length of time a signaling link is in service in milliseconds.
Blocking for TCHs (PB TCHs)1

The TCH blocking rate is calculated using the following formula:
PB TCHs =
N ALLOC T CH F AIL T CH Q REM O V ED [assignment resource req]

P
i=1
T CH Q REM O V ED [ho req]

N
P
i=1
Where:
N
ALLOC_TCH_FAIL
ALLOC T CH + ALLOC T CH F AIL
T CH Q REM O V ED [assignment resource req]

T CH Q REM O V ED [ho req]
Is:
number of times a TCH is unsuccessfully allocated in a cell for
originations and hand ins.
Continued
11-12
68P02900W21-T
Jul 2010
GPRS CS1 uplink usage (CS1_usage_UL)
Where:
TCH_Q_REMOVED
[assignment_resource_req]
Is:
number of times a queued assignment request is allocated a
TCH.
TCH_Q_REMOVED[ho_req] number of times a queued handover request is allocated a TCH.

TCH_Q_REMOVED[ho_req] number of times a queued handover request is allocated a TCH.
ALLOC_TCH
number of times a TCH is successfully allocated in a call for call

originations, hand ins.

The coding scheme usage on the uplink for GPRS CS1 is calculated using the following formula:
U L RADIO B LKS 8P SK 1 T S CS 1 + U L RADIO B LKS 2 T S CS 1+

CSI usage UL =
U L RADIO BLKS GM SK 1 T S CS 1 + U L RADIO B LKS GM SK 2 T S CS 1

!
U L RADIO BLKS 8P SK 1 T S + U L RADIO BLKS 8P SK 2 T S+
100
U L RADIO BLKS GM SK 1 T S + U L RADIO BLKS GM SK 2 T S

Where:
Is:
UL_RADIO_BLKS_8PSK_1_TS_CS_1
number of radio blocks received in the UL for

CS1 from MSs capable of 8-PSK that support a
maximum of 1 TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS_CS_ 1

UL_RADIO_BLKS_GMSK_2_TS_CS_ 1
number of RLC radio blocks received in the UL

for CS1 from MSs capable of 8-PSK supporting a
UL_RADIO_BLKS_8PSK_1_TS
number of radio blocks received in the UL from

MSs capable of 8-PSK supporting a maximum of 1
TS in the UL.

TS in the UL.
UL_RADIO_BLKS_GMSK_1_TS

MSs capable of GMSK supporting a maximum of 1
TS in the UL.

TS in the UL.
68P02900W21-T
11-13
Jul 2010
GPRS CS1 downlink usage (CS1_usage_DL)

The coding scheme usage on the downlink for GPRS CS1 is calculated using the following
formula:
DL RADIO BLKS 1 T S CS 1 + DL RADIO BLKS 2 T S CS 1+

CS1 usage DL =
DL RADIO BLKS 3 T S CS 1 + DL RADIO BLKS 4 T S CS 1

!
DL RADIO BLKS 1 T S + DL RADIO BLKS 2 T S+
100
DL RADIO BLKS 3 T S + DL RADIO BLKS 4 T S
Where:
Is:
DL_RADIO_BLKS_1_TS_CS_1
number of radio blocks received in the DL for CS1 from

MSs supporting a maximum of 1 TS in the DL.



DL_RADIO_BLKS_1_TS
number of radio blocks received in the DL from MSs

supporting a maximum of 1 TS in the DL.
DL_RADIO_BLKS_2_TS

DL_RADIO_BLKS_3_TS

DL_RADIO_BLKS_4_TS


The coding scheme usage on the uplink for GPRS CS2 can be calculated using the following
formula:
U L RADIO BLKS 8P SK 1 T S CS 2 + U L RADIO BLKS 8P SK 2 T S CS 2+

CS2 usage UL =
U L RADIO BLKS GM SK 1 T S CS 2 + U L RADIO BLKS GM SK 2 T S CS 2

!
U L RADIO BLKS 8P SK 1 T S + U L RADIO BLKS 8P SKS 2 T S+
100
11-14
68P02900W21-T
Jul 2010
Where:
Is:
number of radio blocks received in the UL for CS2

from MSs capable of 8-PSK that support a maximum
of 1 TS in the UL.

of 2 TS in the UL.
UL_RADIO_BLKS_GMSK_1_TS_CS_2

of 1 TS in the UL.

number of radio blocks received in the UL from MSs

capable of 8-PSK supporting a maximum of 1 TS in
the UL.

capable of 8-PSK supporting a maximum of 2 TS in
the UL.

capable of GMSK supporting a maximum of 1 TS in
the UL.

capable of GMSK supporting a maximum of 2 TS in
the UL.

The coding scheme usage on the downlink for GPRS CS2 is calculated using the following
formula:
DL RADIO BLKS T S CS 2 + DL RADIO BLKS 2 T S CS 2+

CS2 usage DL =

!
100
Where:
Is:


Continued
68P02900W21-T
11-15
Jul 2010
Where:
Is:


DL_RADIO_BLKS_1_TS

DL_RADIO_BLKS_2_TS

DL_RADIO_BLKS_3_TS

DL_RADIO_BLKS_4_TS


U L RADIO BLKS 1 8P SK 1 T S CS 3 + U L RADIO BLKS 8P SK 2 T S CS 3+

CS3 usage UL =

!
100

Where:
Is:
the number of radio blocks received in the

UL for CS3 from MSs capable of 8-PSK that
support a maximum of 1 TS in the UL.

support a max of 2 TS in the UL.

support a max of 1 TS in the UL.
the number of RLC radio blocks received in

the UL for CS3 from MSs capable of 8-PSK
supporting a max of 2 TS in the UL.
the number of radio blocks received in the UL

from MSs capable of 8-PSK supporting a max
of 1 TS in the UL.

from MSs capable of 8-PSK supporting a max
of 2 TS in the UL.
Continued
11-16
68P02900W21-T
Jul 2010
Where:
Is:

from MSs capable of GMSK supporting a max
of 1 TS in the UL.

from MSs capable of GMSK supporting a max
of 2 TS in the UL.


CS3 usage DL =

!
100
Where:
Is:
number of radio blocks received in the DL for CS3 from MSs




DL_RADIO_BLKS_1_TS

DL_RADIO_BLKS_2_TS

DL_RADIO_BLKS_3_TS

DL_RADIO_BLKS_4_TS

68P02900W21-T
11-17
Jul 2010

U L RADIO BLKS 8P SK 1 T S CS 4 + U L RADIO BLKS 8P SK 2 T S CS 4+

CS4 usage UL =

!
100

Where:
11-18
Is:





TS in the UL.

TS in the UL.

MSs capable of GMSK supporting a maximum of
1 TS in the UL.

2 TS in the UL.
68P02900W21-T
Jul 2010


CS4 usage DL =

!
100
Where:
Is:




DL_RADIO_BLKS_1_TS

DL_RADIO_BLKS_2_TS

DL_RADIO_BLKS_3_TS

DL_RADIO_BLKS_4_TS
number of radio blocks received in the DL from MS.
EGPRS MCS1 uplink usage (MCS1_usage_UL)

The coding scheme usage on the uplink for EGPRS MCS1 is calculated using the following
formula:
U L RADIO BLKS 8P SK 1 T S M CS 1 + U L RADIO BLKS
8P SK 2 T S M CS 1 + U L RADIO BLKS GM SK 1 T S M CS 1 100
+ U L RADIO BLKS GM SK 2 T S M CS 1
MCSI usage UL =
U L RADIO BLKS 8P SK 1 T S + U L RADIO
BLKS 8P SK 2 T S + U L RADIO BLKS
GM SK 1 T S + U L RADIO BLKS GM SK 2 T S
68P02900W21-T
11-19
Jul 2010
Where:
Is:
UL_RADIO_BLKS_8PSK_1_TS_MCS_1

MCS1 from MSs capable of 8-PSK that support
a maximum of 1 TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS_MCS_1


MCS1 from MSs capable of 8-PSK supporting a

MSs capable of 8-PSK supporting a maximum
of 1 TS in the UL.

of 2 TS in the UL.

MSs capable of GMSK supporting a maximum
of 1 TS in the UL.

of 2 TS in the UL.

The coding scheme usage on the downlink for EGPRS MCS1 is calculated using the following
formula:
DL RADIO BLKS 1 T S M CS 1 + DL RADIO BLKS 2 T S M CS 1+

MCS1 usage DL =
DL RADIO BLKS 3 T S M CS 1 + DL RADIO BLKS 4 T S M CS 1

!
100
Where:
Is:
DL_RADIO_BLKS_1_TS_MCS_1
number of radio blocks received in the DL for MCS1

from MSs supporting a maximum of 1 TS in the DL.

Continued
11-20
68P02900W21-T
Jul 2010
Where:
Is:


DL_RADIO_BLKS_1_TS

DL_RADIO_BLKS_2_TS

DL_RADIO_BLKS_3_TS

DL_RADIO_BLKS_4_TS


formula:
MCS2 usage UL =
U L RADIO BLKS 8P SK 1 T S M CS 2 + U L RADIO
BLKS 2 T S M CS 2 + U L RADIO BLKS GM SK 1 100
T S M CS 2 + U L RADIO BLKS GM SK 2 T S M CS 2

U L RADIO BLKS GM SK 1 T S + U L RADIO BLKS 2 T S
Where:
Is:

MCS1 from MSs capable of 8-PSK that support a




TS in the UL.
Continued
68P02900W21-T
11-21
Jul 2010
Where:
Is:

TS in the UL.

TS in the UL.

TS in the UL.

formula:

MCS2 usage DL =

!
100
Where:
11-22
Is:




DL_RADIO_BLKS_1_TS

DL_RADIO_BLKS_2_TS

DL_RADIO_BLKS_3_TS

DL_RADIO_BLKS_4_TS

68P02900W21-T
Jul 2010

formula:
BLKS 8P SK 2 T S M CS 3 + U L RADIO BLKS GM SK 1 100
MCS3 usage UL =

Where:
Is:





TS in the UL.

TS in the UL.

1 TS in the UL.

2 TS in the UL.
68P02900W21-T
11-23
Jul 2010

formula:

MCS3 usage DL =

!
100
Where:
Is:




DL_RADIO_BLKS_1_TS

DL_RADIO_BLKS_2_TS

DL_RADIO_BLKS_3_TS

DL_RADIO_BLKS_4_TS


formula:
MCS4 usage UL =
11-24
68P02900W21-T
Jul 2010
Where:
Is:





TS in the UL.

TS in the UL.

TS in the UL.

TS in the UL.

formula:

MCS4 usage DL =

!
100
Where:
Is:


Continued
68P02900W21-T
11-25
Jul 2010
Where:
Is:


DL_RADIO_BLKS_1_TS

DL_RADIO_BLKS_2_TS

DL_RADIO_BLKS_3_TS

DL_RADIO_BLKS_4_TS


formula:
MCS5 usage UL =

Where:
Is:





TS in the UL.
Continued
11-26
68P02900W21-T
Jul 2010
Where:
Is:

TS in the UL.

1 TS in the UL.

2 TS in the UL.

formula:

MCS5 usage DL =

!
100
Where:
Is:




DL_RADIO_BLKS_1_TS

DL_RADIO_BLKS_2_TS

DL_RADIO_BLKS_3_TS

DL_RADIO_BLKS_4_TS

68P02900W21-T
11-27
Jul 2010

formula:
MCS6 usage UL =

Where:
11-28
Is:





of 1 TS in the UL.

of 2 TS in the UL.

of 1 TS in the UL.

of 2 TS in the UL.
68P02900W21-T
Jul 2010

formula:

MCS6 usage DL =

!
100
Where:
Is:




DL_RADIO_BLKS_1_TS

DL_RADIO_BLKS_2_TS

DL_RADIO_BLKS_3_TS

DL_RADIO_BLKS_4_TS


formula:
MCS7 usage UL =
68P02900W21-T
11-29
Jul 2010
Where:
Is:





TS in the UL.

TS in the UL.

1 TS in the UL.

2 TS in the UL.

formula:
MCS7 usage DL =
DL RADIO B LKS 1 T S M CS 7 + DL RADIO B LKS 2 T S M CS 7+

DL RADIO B LKS 3 T S M CS 7 + DL RADIO B LKS 4 T S M CS 7

DL RADIO B LKS 1 T S + DL RADIO B LKS 2 T S+
DL RADIO B LKS 3 T S + DL RADIO B LKS 4 T S
Where:
100
Is:


Continued
11-30
68P02900W21-T
Jul 2010
Where:
Is:


DL_RADIO_BLKS_1_TS

DL_RADIO_BLKS_2_TS

DL_RADIO_BLKS_3_TS

DL_RADIO_BLKS_4_TS


formula:
U L RADIO B LKS 8P SK 1 T S M CS 8 + U L RADIO

B LKS 8P SK 2 T S M CS 8 + U L RADIO B LKS GM SK 1 100
T S M CS 8 + U L RADIO B LKS GM SK 2 T S M CS 8

MCS8 usage UL =
U L RADIO B LKS 8P SK 1 T S + U L RADIO B LKS 8P SK 2 T S +
U L RADIO B LKS GM SK 1 T S + U L RADIO B LKS GM SK 2 T S
Where:
Is:





of 1 TS in the UL.

of 2 TS in the UL.
Continued
68P02900W21-T
11-31
Jul 2010
Where:
Is:

of 1 TS in the UL.

of 2 TS in the UL.

formula:
MCS8 usage DL =


Where:
11-32
100
Is:




DL_RADIO_BLKS_1_TS

DL_RADIO_BLKS_2_TS

DL_RADIO_BLKS_3_TS

DL_RADIO_BLKS_4_TS

68P02900W21-T
Jul 2010

formula:
U L RADIO B LKS 8P SK 1 T S M CS 9 + U L RADIO

B LKS 8P SK 2 T S M CS 9 + U L RADIO B LKS GM SK 1 100
T S M CS 9 + U L RADIO B LKS GM SK 2 T S M CS 9

MCS9 usage UL =
U L RADIO B LKS 8P SK 1 T S + U L RADIO B LKS 8P SK 2 T S +
U L RADIO B LKS GM SK 1 T S + U L RADIO B LKS GM SK 2 T S
Where:
Is:





of 1 TS in the UL.

of 2 TS in the UL.

of 1 TS in the UL.

of 2 TS in the UL.
68P02900W21-T
11-33
Jul 2010

formula:
MCS9 usage DL =


Where:
100
Is:
number of radio blocks received in the DL for MCS9 from




DL_RADIO_BLKS_1_TS

DL_RADIO_BLKS_2_TS

DL_RADIO_BLKS_3_TS

DL_RADIO_BLKS_4_TS

Sample statistic calculations

Table 11-2 shows a sample of the statistics collected for one BTS in the BSC for a one hour
interval.
Table 11-2 Sample statistics

Statistic Parameter
Cell 1
Cell 2
Cell 3
BUSY_TCH_MEAN
9.25
14.94
24.12
TOTAL_CALLS
571
927
1407
SMS_NO_BCAST_MSG
SMS_INIT_ON_SD- CCH
15
SMS_INIT_ON_TCH
531
1214
141
out_inter_bss_req_to_msc
Continued
11-34
68P02900W21-T
Jul 2010
Table 11-2 Sample statistics (Continued)

Statistic Parameter
out_intra_bss_ho_atm
intra_cell_ho_atmpt
OK_ACC_PROC [location_update]
OK_ACC_PROC [imsi_detach]
PAGE_REQ_FROM_MSC
Cell 1
Cell 2
Cell 3
512
747
1844
746
1056
268
28
49
76
43696
43696
43696
Using the formulae detailed in the previous sections, call model parameters can be calculated
as follows:
Call duration (T)

Call duration is given by:
T=
N
P
i=1
N
P
i=1
BUSY TCH MEAN stat interval in sec
T = (9.25 + 14.94 + 24.12) 3600/ (571 + 927 + 1407) + 0 + 0 + 0

The average call duration for this BSC = 59.86.
Likewise, call durations for all the cells in the BSC can be calculated. The call duration value
used for dimensioning purposes should be the average of the call durations over all the BSCs
in the network.
Number of SMSs per call (S)

The number of SMSs per call is given by:
S=
N
P
i=1
(SMS NO BCAST MSG + SMS INIT ON SDCCH + SMS INIT ON TCH)

N
P
i=1
S = [(0 + 0 + 0) + (0 + 15 + 2) + (0 + 5 + 0)] / (571 + 927 + 1407) = 0.075
68P02900W21-T
11-35
Jul 2010

The ratio of handovers per call is given by:
H=
N
P
i+1
(out inter bss req to msc + out intra bss ho attmpt + intra cell ho attmpt)
N
P
i=1
H = [(531 + 512 + 0) + (1214 + 747 + 0) + (141 + 1844 + 0)] / (571 + 927 + 1407 + 0 + 0 + 0) = 1.717
Ratio of intra-BSS handovers to all handovers (i)

Using the statistics previously detailed, this ratio can be calculated for a BSS as follows:
i=
N
P
i1
N
P
i=1
(out intra bss ho atmpt + out intra cell ho atmpt)
(out inter bss req to msc + out intra bss ho atmpt + intra cell ho atmpt)
[(512 + 0) + (747 + 0) + (1844 + 0)] / [(513 + 512 + 0) + (1214 + 747 + 0) + 141 + 1844 + 0] = 0.562
Number of location updates per call (l)

Location updates per call can be calculated as:
I=
N
P
i=1
N
P
i=1
(OK ACC PROC [location update])
I = (746 + 1056 + 268) / (571 + 927 + 1407) + 0 + 0 + 0 = 0.712
IMSI detaches per call (I)

The number of IMSI detaches per call is given by:
I=
N
P
i=1
N
P
i=1
(OK ACC PROC (imsi detach))
I = (28 + 49 + 76) / (571 + 927 + 1407 + 0 + 0 + 0) = 0.052
11-36
68P02900W21-T
Jul 2010

The location update is given by:
L = 1 + 0.5 I
L = 0.712 + 0.5 0.052 = 0.738
Paging Rate (PGSM) for a BSC

The paging rate for a BSC (with multiple location areas) can be calculated as:
PGSM =
(PAGE REQ FROM MSC)

stat interval in seconds ith location area
Since, in this case the BSC has only one location area, PGSM is given by:
PGSM = 43696/3600 = 12.13 pages per second

All call model parameters should be calculated by taking an average over all the BSCs in the
entire network. This example illustrates the computation of call model parameters from the
network statistics obtained from the OMC-R. As previously mentioned, it is recommended
that statistics collected at busy hours over a long period (a couple of months) are used for all
calculation purposes.
68P02900W21-T
Jul 2010
11-37
11-38
68P02900W21-T
Jul 2010
Chapter
12
Hardware and compatibility
68P02900W21-T
Jul 2010
12-1
Hardware configuration
Hardware configuration
Interconnection diagrams of the components and BTS site configurations are available in the
relevant hardware manuals:
Horizon II
68P02902W96 Service Manual: Horizon II macro
68P02902W97 Installation and Configuration: Horizon II macro
68P02903W21 Service Manual: Horizon II mini
68P02903W22 Installation and Configuration: Horizon II mini
68P02903W31 Service Manual: Horizon II micro
68P02903W32 Installation and Configuration: Horizon II micro
68P02903W25 Installation and configuration: Horizon II macro Outdoor Enclosure &

Horizon3G Outdoor Lite Enclosure
68P02903W26 Service Manual: Horizon II macro / Horizon 3G Outdoor Enclosure
Horizonmacro
68P02902W06 Service Manual: Horizonmacro indoor
68P02902W08 Installation & Configuration: Horizonmacro
68P02902W12 Service Manual: Horizonmacro outdoor
68P02902W66 Service Manual: Horizonmacro 12 carrier outdoor
68P02901W75 Service Manual: M-Cell2
68P02901W85 Service Manual: M-Cell6
M-Cell
12-2
68P02900W21-T
Jul 2010
Micro Base Transceiver Stations
Micro Base Transceiver Stations
68P02901W65 Service Manual: M-Cellaccess
68P02901W95 Service Manual: M-Cellcity and M-Cellcity+
68P02902W15 Service Manual: Horizoncompact
68P02902W36 Service Manual: Horizonmicro
68P02902W61 Service Manual: Horizonmicro2 and Horizoncompact2
BSC/RXCDR
68P02901W38 Service Manual: BSC/RXCDR
68P02902W76 Service Manual: BSC2/RXCDR2
68P02902W77 Installation and Configuration: BSC2/RXCDR2
68P02903W10 Service Manual: Packet Control Unit (PCU)
68P02903W12 Installation and configuration: PCU (legacy_cabinets)
68P02903W24 Installation and configuration: PCU (common data cabinet)
PCU
68P02900W21-T
Jul 2010
12-3
PCU
12-4
68P02900W21-T
Jul 2010
Index
Index
A
Acronyms . . . . . . . . . . .
Adaptive multi-rate (AMR) . .
Applications. . . . . . . . .
Capacity and coverage . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1-40
3-6
3-8
3-6
3-9
Adaptive multi-rate (AMR) (contd.)

Interoperability with GSM half
Introduction. . . . . . . . . .
Migration to AMR half rate . .
Quality of service . . . . . . .
rate .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
3-9
3-6
3-9
3-7
B
BSS equipment overview . . . . . . . . . . 1-4
System architecture. . . . . . . . . . . . 1-4
System components . . . . . . . . . . . . 1-5
BBU-E. . . . . . . . . . . . . . . . .
1-10
CTU . . . . . . . . . . . . . . . . . . . 1-7
CTU2 . . . . . . . . . . . . . . . . . . 1-7
CTU2D . . . . . . . . . . . . . . . . . 1-6
DTRX . . . . . . . . . . . . . . . . . . 1-8
Horizon II Site Controller . . . . . . . . 1-8
(R)CTU8m . . . . . . . . . . . . . . . 1-6
Site Controller-2 . . . . . . . . . . . . 1-9
TCU-m . . . . . . . . . . . . . . . . . 1-8
TCU/TCU-B . . . . . . . . . . . . . . . 1-8
BSS features . . . . . . . . . . . . . . .
1-11
96 MSIs . . . . . . . . . . . . . . . . .
1-26
Adaptive Multi-Rate (AMR) . . . . . . .
1-15
Addition of new BSC/PCU software (PXP) and
hardware (PSI2) to increase GPRS capacity
(ePCU) . . . . . . . . . . . . . . . . .
1-24
Advanced Speech Call Item (ASCI) . . .
1-19
BSC Reset Management (BRM) . . . . .
1-19
Code Storage Facility Processor
(CSFP) . . . . . . . . . . . . . . . . .
1-13
CTU2-D . . . . . . . . . . . . . . . . .
1-24
Diversity . . . . . . . . . . . . . . . .
1-12
Enhanced BSC capacity using DSW2 . .
1-24
Enhanced-GPRS (EGPRS) . . . . . . . .
1-14
Frequency hopping . . . . . . . . . . .
1-12
GSM half rate . . . . . . . . . . . . . .
1-16
High bandwidth interconnect between BSC and
PCU (PSI2) . . . . . . . . . . . . . . .
1-24
High Speed MTL . . . . . . . . . . . .
1-24
Horizon II Site Controller 2 . . . . . . .
1-28
Improved Timeslot Sharing (ITS) . . . .
1-23
Increase RSL-LCF capacity on
GPROC3/GPROC3-2 . . . . . . . . . . .
1-32
Increased Network Capacity (Huge
BSC) . . . . . . . . . . . . . . . . . .
1-23
68P02900W21-T
Jul 2010
BSS features (contd.)

LoCation Services (LCS) . . . . . . . .
1-17
PCU for GPRS upgrade . . . . . . . . .
1-14
Planning impacts . . . . . . . . . . . .
1-11
QoS2 . . . . . . . . . . . . . . . . . .
1-22
Quality of Service (QoS). . . . . . . . .
1-20
SGSN(Gb) interface using Ethernet (Gb over
IP) . . . . . . . . . . . . . . . . . . .
1-32
Short Message Service, Cell Broadcast (SMS
CB) . . . . . . . . . . . . . . . . . . .
1-13
Using PA bias feature in Horizon II sites with
mixed radios . . . . . . . . . . . . . .
1-33
VersaTRAU backhaul for EGPRS . . . .
1-20
BSS interfaces . . . . . . . . . . . . . . . 2-2
Introduction. . . . . . . . . . . . . . . . 2-2
BSS planning for GPRS/EGPRS . . . . . . . 8-2
Feature compatibility . . . . . . . . . . . 8-3
Gb over IP . . . . . . . . . . . . . .
8-12
Introduction. . . . . . . . . . . . . . . . 8-2
PCU to SGSN interface planning . . . . . 8-2
BSS planning overview . . . . . . . . . .
1-37
Background information . . . . . . . .
1-37
Introduction. . . . . . . . . . . . . . .
1-37
Planning methodology . . . . . . . . .
1-39
BSS-PCU hardware planning example for
EGPRS . . . . . . . . . . . . . . . . . .
8-79
BSS - PCU planning example for EGPRS . . . . . . . . . . . . . . . . . . .
8-79
BSS - PCU planning example for EGPRS with
QoS and QoS2 enabled . . . . . . . . .
8-93
BSS - PCU planning example for EGPRS with
QoS enabled, QoS2 not enabled. . . . .
8-86
Introduction. . . . . . . . . . . . . . .
8-79
BSS-PCU hardware planning example for
GPRS . . . . . . . . . . . . . . . . . . .
8-72
BSS - PCU planning example for GPRS. .
8-72
Introduction. . . . . . . . . . . . . . .
8-72
IX-1
Index
C
Calculations using alternative call models. . . . . . . . . . . . . . . . . . . . .
Introduction. . . . . . . . . . . . . . .
Planning example 3 . . . . . . . . . . .
Planning example 4 (using AMR) . . . .
Planning example 5 . . . . . . . . . . .
Call model parameters for capacity
calculations . . . . . . . . . . . . . . . .
Introduction. . . . . . . . . . . . . . .
Typical call parameters . . . . . . . . .
Control channel calculations . . . . . . .
Combined BCCH . . . . . . . . . . . .
Control channel configurations . . . . .
Introduction. . . . . . . . . . . . . . .
Number of CCCHs and PCCCHs per BTS
cell . . . . . . . . . . . . . . . . . . .
Number of SDCCHs per BTS cell . . . .
Planning considerations. . . . . . . . .
User data capacity on the PCCCH
timeslot . . . . . . . . . . . . . . . . .
CTU8m D4+ Link . . . . . . . . . . .

Link selection . . . . . . . . . . . .
Overview . . . . . . . . . . . . . .
Recommended D4+ configurations
(CTU8m) . . . . . . . . . . . . . .
1-3 CTU8m radios. . . . . . . . .
4-6 CTU8m radios (dual BBU-E) .
4-6 CTU8m radios (single BBU-E) .
Recommended D4+ configurations
(RCTU8m). . . . . . . . . . . . . .
1-3 RCTU8m radios (non-redundant) . . . . . . . . . . . . . . .
4-6 RCTU8m radios (dual BBU-E) .
4-6 RCTU8m radios (single BBU-E)
Supported topologies . . . . . . . .
Fiber redundancy . . . . . . . . .
General principles . . . . . . . .
Standard topologies. . . . . . . .
9-17
9-17
9-17
9-30
9-46
3-48
3-48
3-48
3-52
3-54
3-69
3-52
3-55
3-66
3-53
. .
. .
. .
5-44
5-51
5-44
.
.
.
.
.
.
.
.
5-55
5-55
5-57
5-57
. .
5-58
.
.
.
.
.
.
.
5-58
5-63
5-62
5-45
5-49
5-45
5-46
.
.
.
.
.
.
.
3-65
D
Deriving call model parameters from network
statistics . . . . . . . . . . . . . . . . .
11-2
Blocking for TCHs (PB TCHs) . . . . . 11-12
Call duration (T) . . . . . . . . . . . .
11-5
EGPRS MCS1 downlink usage (MCS1_usage_DL) . . . . . . . . . . . . . . . . . 11-20
EGPRS MCS1 uplink usage (MCS1_usage_UL) . . . . . . . . . . . . . . . . . 11-19
IX-2

statistics (contd.)
GPRS CS1 downlink usage (CS1_usage_DL) . . . . . . . . . . . . . . . . . 11-14
GPRS CS1 uplink usage (CS1_usage_UL) . . . . . . . . . . . . . . . . . 11-13
Location update factor (L) . . . . . . .
11-9
68P02900W21-T
Jul 2010
Index
Determine the hardware requirements

BSC . . . . . . . . . . . . . . . . . .
Introduction. . . . . . . . . . . . .
Summary . . . . . . . . . . . . . .
Determine the hardware requirements
RXCDR . . . . . . . . . . . . . . . .
CLKX requirement . . . . . . . . .
GCLK requirement . . . . . . . . .
GPROC requirement . . . . . . . .
KSW/DSW2 requirement . . . . . .
KSWX/DSWX requirement . . . . .
LANX requirement . . . . . . . . .
Link interface . . . . . . . . . . . .
MSI requirements. . . . . . . . . .
PIX requirement . . . . . . . . . .
Power supply . . . . . . . . . . . .
Summary . . . . . . . . . . . . . .
Transcoder requirement . . . . . .
DPROC board . . . . . . . . . . . . .
Introduction. . . . . . . . . . . . .
PXP planning considerations . . . .

statistics (contd.)
Percent link utilization BSC to BTS [U(BSC
BTS)] . . . . . . . . . . . . . . . . . . 11-11
Percent link utilization MSC to BSS [U(MSC
BSS)] . . . . . . . . . . . . . . . . . . 11-11
Ratio of handovers per call (H) . . . . .
11-7
Ratio of IMSI detaches per call (I) . . .
11-8
Ratio of intra BSS handovers to all handovers
(i) . . . . . . . . . . . . . . . . . . . .
11-7
Ratio of location updates per call (I) . .
11-8
Ratio of SMSs per call (S) . . . . . . . .
11-6
Sample statistic calculations . . . . . . 11-34
Standard call model parameters . . . .
11-2
Determine the hardware requirements for BTS
B . . . . . . . . . . . . . . . . . . . . . . 9-5
Cabinet . . . . . . . . . . . . . . . . . . 9-5
Summary . . . . . . . . . . . . . . . . . 9-6
Determine the hardware requirements for BTS
K . . . . . . . . . . . . . . . . . . . . . . 9-8
Cabinet . . . . . . . . . . . . . . . . . . 9-8
Introduction. . . . . . . . . . . . . . . . 9-8
Receiver requirements . . . . . . . . . . 9-8
Summary . . . . . . . . . . . . . . . . . 9-9
Transmitter combining requirements . . . 9-9
for the
. .
9-11
. .
9-11
. .
9-13
for the
. .
9-14
. .
9-15
. .
9-15
. .
9-15
. .
9-15
. .
9-15
. .
9-16
. .
9-15
. .
9-14
. .
9-15
. .
9-16
. .
9-16
. .
9-14
. .
8-25
. .
8-25
. .
8-25
. .
8-28
E
E1 link/ETH link provisioning for GPRS and
EGPRS . . . . . . . . . . . . . . . . . .
E1 interface provisioning . . . . . . . .
E1 Planning considerations . . . . . . .
Ethernet interface provisioning . . . . .
Exercises . . . . . . . . . . . . . . . . . .
Introduction. . . . . . . . . . . . . . . .
8-46
8-46
8-46
8-47
9-4
9-4
F
Frequency planning . . . . . . . . . . . .
Introduction. . . . . . . . . . . . . . .
Rules for BaseBand Hopping (BBH) . . .
3-38
3-38
3-42
Frequency planning (contd.)

Rules for Synthesizer Frequency Hopping
(SFH) . . . . . . . . . . . . . . . . . .
3-38
G
GPRS/EGPRS air interface planning
process . . . . . . . . . . . . . . . . . .
3-96
Configurable initial coding scheme . . . 3-117
Estimating the air interface traffic
throughput . . . . . . . . . . . . . . . 3-107
Estimating timeslot provisioning requirements . . . . . . . . . . . . . . . . . . 3-109
GPRS/EGPRS data rates . . . . . . . . 3-118
Influential factors in GPRS/EGPRS cell planning
and deployment . . . . . . . . . . . . .
3-96
68P02900W21-T
Jul 2010

(contd.)
Select a cell plan . . . . . . . . . . .
GPRS/EGPRS network traffic estimation
concepts . . . . . . . . . . . . . . . .
BSS timeslot allocation methods . . .
Carrier timeslot allocation examples .
Dynamic timeslot allocation . . . . . .
Introduction. . . . . . . . . . . . . .
. 3-108
and key
.
3-74
.
3-91
.
3-83
.
3-76
.
3-74
IX-3
Index
GSM half rate . . . . . . . . . .

Applications. . . . . . . . . .
Capacity and coverage . . . .
Interoperability with AMR half
Interoperability with EGPRS .
Introduction. . . . . . . . . .
Migration to half rate . . . . .
Quality of service . . . . . . .
GPRS/EGPRS network traffic estimation and key

concepts (contd.)
Recommendation for switchable timeslot
usage . . . . . . . . . . . . . . . . . .
3-93
Timeslot allocation process on carriers with
GPRS traffic. . . . . . . . . . . . . . .
3-95
GPRS/EGPRS traffic planning . . . . . . .
3-73
Determination of expected load . . . . .
3-73
Network planning flow . . . . . . . . .
3-73
. . .
. . .
. . .
rate .
. . .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3-10
3-11
3-10
3-12
3-12
3-10
3-12
3-11
Hardware . . . . . . . . . . . . . . . . .
Backhaul . . . . . . . . . . . . . . . .
Equipment descriptions . . . . . . . . .
4-26
4-28
4-26
H
Half rate utilization . . .
Description . . . . . .
Operational aspects . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4-17
4-17
4-23
4-17
I
Inter-radio access technology (2G-3G)
reselection and handovers . . . . . .
2G-3G handover description . . . .
Impact of 2G-3G handovers on GSM
architecture . . . . . . . . . . . . .
Introduction. . . . . . . . . . . . .
System consideration . . . . . . . .
Interconnecting the BSC and BTSs . .
Interconnection rules . . . . . . . .
cell
. .
3-44
. .
3-44
system
. .
3-45
. .
3-44
. .
3-46
. . . 2-4
. . . 2-4
Interconnecting the BSC and BTSs (contd.)

Introduction. . . . . . . . . . . . . .
AMR and GSM half rate interaction . .
AMR basic operation . . . . . . . . .
GSM half rate basic operation . . . .
Influencing factors . . . . . . . . . .
New hardware . . . . . . . . . . . .
Planning . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2-4
4-2
4-3
4-2
4-2
4-3
4-3
4-4
L
Location area planning calculations. . . .
Example procedure . . . . . . . . . . .
10-3
10-3
Location area planning considerations . .
10-2
M
General HDSL guidelines . .
Integrated HDSL interface .
Introduction. . . . . . . . .
Microcell system planning .
Manual overview . . . . . . .
Contents . . . . . . . . . .
Introduction. . . . . . . . .
Microcellular solution . . . . .
Combined cell architecture .
IX-4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2-24
.
2-26
.
2-24
.
2-24
.
2-27
. . 1-2
. . 1-2
. . 1-2
.
3-34
.
3-35
Microcellular solution (contd.)

Combined cell architecture structure
Expansion solution . . . . . . . . .
Layered architecture . . . . . . . .
Miscellaneous information . . . . . .
Circuit pooling . . . . . . . . . . .
Emergency call handling . . . . . .
MPROC board. . . . . . . . . . . . .
Introduction. . . . . . . . . . . . .
PSP planning considerations . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3-35
3-36
3-34
4-16
4-16
4-16
8-24
8-24
8-24
68P02900W21-T
Jul 2010
Index
N
Network topology . . . .
16 kbit/s XBL . . . . .
Aggregate Abis . . . .
Daisy chain planning .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . 2-6
.
2-20
.
2-10
. . 2-8
. . 2-8
Network topology (contd.)

Dynamic allocation of RXCDR to
(DARBC) . . . . . . . . . . . .
Introduction. . . . . . . . . . .
RTF path fault containment . . .
Star connection . . . . . . . . .
BSC circuits
. . . .
2-21
. . . . . 2-6
. . . .
2-15
. . . . . 2-7
O
Overcoming adverse propagation effects
64 kbit/s TRAU for EGPRS . . . . . . .
EGPRS channel coding schemes . . . .
Overcoming adverse propagation effects (contd.)

Link adaptation (LA) in GPRS/EGPRS . .
3-28
3-18
3-29
P
(Packet) Rear Transition Module . . . . .
8-31
Introduction. . . . . . . . . . . . . . .
8-31
8-31
PCU equipment redundancy and provisioning
goals . . . . . . . . . . . . . . . . . . .
8-32
PCU equipment redundancy planning. .
8-32
PRP/PICP configure . . . . . . . . . . .
8-33
PXP configuration . . . . . . . . . . . .
8-38
Support for equipment redundancy . . .
8-32
Upgrading the PCU . . . . . . . . . . .
8-43
PCU hardware layout . . . . . . . . . . .
8-21
PCU shelf (cPCI) . . . . . . . . . . . . .
8-22
Introduction. . . . . . . . . . . . . . .
8-22
8-22
PCU-SGSN: traffic and signal planning . .
8-63
Determining net Gb load . . . . . . . .
8-65
Frame relay parameter values . . . . .
8-67
Gb entities . . . . . . . . . . . . . . .
8-63
Gb link timeslots (for Frame relay Gb). .
8-66
PCU-SGSN: traffic and signal planning (contd.)

Gb signaling . . . . . . . . . . . . . .
8-65
General planning guidelines . . . . . .
8-64
Introduction. . . . . . . . . . . . . . .
8-63
Specific planning guidelines . . . . . .
8-65
Planning example of BSS support for LCS
provisioning . . . . . . . . . . . . . . . .
9-59
LCS planning example calculations . . .
9-59
Planning example for GSR10 with no (E)GPRS
and high signaling . . . . . . . . . . .
9-62
Typical parameter values . . . . . . . .
9-59
Planning tools . . . . . . . . . . . . . . . . 3-3
Introduction. . . . . . . . . . . . . . . . 3-3
PMC module . . . . . . . . . . . . . . .
8-30
Introduction. . . . . . . . . . . . . . .
8-30
8-30
Pre-requisites . . . . . . . . . . . . . . . . 9-2
Network topology . . . . . . . . . . . . . 9-3
Requirements . . . . . . . . . . . . . . . 9-2
Q
QoS capacity and QoS2 impact . . . . . .
8-49
Calculating average downlink EGBR . .
8-55
Calculating PRP board throughput . . .
8-54
CTU2D impact . . . . . . . . . . . . .
8-62
MTBR allocation . . . . . . . . . . . .
8-51
PRP-PDTCH QoS planning . . . . . . .
8-54
Quality and capacity . . . . . . . . . . . . 4-5
AMR Full Rate and AMR Half Rate speech
quality . . . . . . . . . . . . . . . . . . 4-5
68P02900W21-T
Jul 2010
Quality and capacity (contd.)

AMR voice quality improvement and
coverage . . . . . . . . . . . . . . .
Benefits of AMR. . . . . . . . . . . .
Benefits of GSM half rate . . . . . . .
Capacity increase due to half rate
usage . . . . . . . . . . . . . . . . .
GSM Half Rate speech quality . . . .
Timeslot usage . . . . . . . . . . . .
. . 4-9
. . 4-5
.
4-10
.
.
.
4-11
4-11
4-14
IX-5
Index
S
Subscriber environment.
Distribution . . . . . .
Environment . . . . .
Future planning . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3-30
3-31
3-30
3-33
Subscriber environment (contd.)

Hand portable subscribers . . . . . . .
Subscriber hardware . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . .
3-32
3-30
4-32
T
Traffic capacity . . . . . . . . . . . . . . .
Channel blocking . . . . . . . . . . . . .
Dimensioning . . . . . . . . . . . . . . .
IX-6
3-4
3-4
3-4
Traffic capacity (contd.)

Grade of service. . . . . . . . . . . . . .
Traffic flow . . . . . . . . . . . . . . . .
3-5
3-5
68P02900W21-T
Jul 2010

About AMR

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

About AMR

Uploaded by

Copyright:

Available Formats

BSS Equipment Planning

2010 Motorola, Inc. All Rights Reserved.

System Information: BSS Equipment Planning

Chapter 1: Introduction to planning

Enhanced BSC capacity using DSW2 . . . . . . . . . . . . .

Chapter 2: Transmission systems

Chapter 3: BSS cell planning

System Information: BSS Equipment Planning

Adaptive multi-rate (AMR) . . . . . . . . . . . . . . . . . . . . . . .

Number of SDCCHs per BTS cell . . . . . . . . . . . . . . . .

Chapter 4: AMR and GSM half-rate planning

Chapter 5: BTS planning steps and rules

System Information: BSS Equipment Planning

Chapter 6: BSC planning steps and rules

System Information: BSS Equipment Planning

Determining the number of LMTLs . . . . . . . . . . . . . . . . . . . .

Chapter 7: RXCDR planning steps and rules

System Information: BSS Equipment Planning

Enhanced capacity mode is enabled (non-extension shelf) . . . . . . . . .

Chapter 8: BSS planning for GPRS/EGPRS

Chapter 9: Planning examples

System Information: BSS Equipment Planning

Location area planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 10: Location area planning

Chapter 11: Call model parameters

EGPRS MCS4 uplink usage (MCS4_usage_UL). .

Chapter 12: Hardware and compatibility

1-1: BSS block diagram . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 3-20: Layered architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8-4: Provisioning goals (full redundancy) . . . . . . . . . . . . . . . . . . . .

1-1: Transceiver unit usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6-16: BSS configurations and their availability . . . . . . . . . . . . . . .

System Information: BSS Equipment

What is covered in this manual?

The following sections show the revision status of this document.

Includes GSM Software Release 8

Software release GSR9

Software release GSR10

Enhanced Horizon II Site Controller

Reduced number of LCFs

PA bias in mixed radio Horizon II sites

Resolution of Service Requests

Document banner definitions

Special key sequences

Press the Ctrl and C keys at the same time.

Press the Ctrl, Shift, and C keys at the same time.

Press the Alt and F keys at the same time.

Press the pipe symbol key.

Press the Return or Enter key.

Motorola appreciates feedback from the users of our documents.

Ordering documents and CD-ROMs

Questions and comments

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

Manual overview on page 1-2

BSS equipment overview on page 1-4

BSS features on page 1-11

BSS planning overview on page 1-37

Acronyms on page 1-40

OMC-R planning is beyond the scope of this manual.

For information on installing a new OMC-R, refer to 68P02901W47, Installation

Chapter 1: Introduction to planning