Motorola B2B Collateral Branding UK Manual Cover insert A4 Text Field Template (02/10/07)

Sign o� ........................................ date ................ Sht no 1 of 1 ag-UK-Manual Cover insert A4 Text Fields Template-00001-v02-ai-sw

Customer Documetation UK 2007

BSS Equipment Planning

68P02900W21-T

System Information

GSR10

Using this template follow these procedures.

1. Complete all the text fields using provided spreadsheet and specification information2. Save file using appropriate naming title/convention in PDF format

© 2010 Motorola, Inc. All Rights Reserved.

Accuracy

While reasonable efforts have been made to assure the accuracy of this document, Motorola, Inc. assumes noliability resulting from any inaccuracies or omissions in this document, or from use of the information obtainedherein. 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 contenthereof with no obligation to notify any person of revisions or changes. Motorola, Inc. does not assume any liabilityarising out of the application or use of any product, software, or circuit described herein; neither does it conveylicense under its patent rights or the rights of others. It is possible that this publication may contain references to, orinformation about Motorola products (machines and programs), programming, or services that are not announcedin your country. Such references or information must not be construed to mean that Motorola intends to announcesuch Motorola products, programming, or services in your country.

Copyrights

This document, Motorola products, and 3rd Party Software products described in this document may includeor describe copyrighted Motorola and other 3rd Party supplied computer programs stored in semiconductormemories or other media. Laws in the United States and other countries preserve for Motorola, its licensors, andother 3rd Party supplied software certain exclusive rights for copyrighted material, including the exclusive rightto 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 theMotorola 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 purchaseof Motorola products shall not be deemed to grant either directly or by implication, estoppel, or otherwise, anylicense 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 aproduct.

Restrictions

Software and documentation are copyrighted materials. Making unauthorized copies is prohibited by law. No partof the software or documentation may be reproduced, transmitted, transcribed, stored in a retrieval system, ortranslated into any language or computer language, in any form or by any means, without prior written permissionof Motorola, Inc.

License Agreements

The software described in this document is the property of Motorola, Inc and its licensors. It is furnished by expresslicense 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 NOTdesigned, manufactured, or intended for use as on-line control equipment in the following hazardous environmentsrequiring fail-safe controls: the operation of Nuclear Facilities, Aircraft Navigation or Aircraft CommunicationSystems, 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 servicenames are the property of their respective owners.

The CE mark confirms Motorola, Inc. statement of compliance with EU directives applicable to this product. Copiesof the Declaration of Compliance and installation information in accordance with the requirements of EN50385 canbe 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 CustomerNetwork Resolution Center contact information. Alternatively if you do not have access to CNRC or theinternet, contact the Local Motorola Office.

Jul 2010

Tableof

Contents

Contents■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

■

■

System Information: BSS Equipment PlanningRevision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Version information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Release information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Resolution of Service Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

General information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Cross references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Document banner definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Text conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Contacting Motorola . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524–hour support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Ordering documents and CD-ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Questions and comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Chapter 1: Introduction to planningManual overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

BSS equipment overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4System components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

BSS features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11Planning impacts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11Diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12Frequency hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12Short Message Service, Cell Broadcast (SMS CB) . . . . . . . . . . . . . . . . . . . . . . 1-13Code Storage Facility Processor (CSFP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13PCU for GPRS upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14Enhanced-GPRS (EGPRS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14Adaptive Multi-Rate (AMR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15GSM half rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16LoCation Services (LCS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17IOS (Intelligent Optimization Service)/OPL (Optimization Link) . . . . . . . . . . . . . . . 1-18BSC Reset Management (BRM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19Advanced Speech Call Item (ASCI). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19VersaTRAU backhaul for EGPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20QoS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22Increased Network Capacity (Huge BSC) . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23Improved Timeslot Sharing (ITS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23

68P02900W21-T i

Jul 2010

Contents

Enhanced BSC capacity using DSW2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24High Speed MTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24Addition of new BSC/PCU software (PXP) and hardware (PSI2) to increase GPRS capacity(ePCU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24High bandwidth interconnect between BSC and PCU (PSI2). . . . . . . . . . . . . . . . . 1-24CTU2–D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2496 MSIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26Support usage of idle TCH for burst packet traffic . . . . . . . . . . . . . . . . . . . . . . 1-26Extended Range Cell for Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-27Horizon II Site Controller-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28CTU8m and RCTU8m feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-29CTU8m and RCTU8m 8 carrier support . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-31Increase RSL-LCF capacity on GPROC3/GPROC3-2 . . . . . . . . . . . . . . . . . . . . . 1-32SGSN(Gb) interface using Ethernet (Gb over IP). . . . . . . . . . . . . . . . . . . . . . . 1-32PA bias feature in Horizon II sites with mixed radios. . . . . . . . . . . . . . . . . . . . . 1-33BBU-E 8/8/8 CTU8m HR EPG impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-34Support large site 12/12/12 for GSR program . . . . . . . . . . . . . . . . . . . . . . . . 1-34Increased Network Capacity (1000TRX BSC) enhancement . . . . . . . . . . . . . . . . . 1-35EGPRS Enhancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35Porting Horizon II Site Controller 2 to GSR9. . . . . . . . . . . . . . . . . . . . . . . . . 1-36

BSS planning overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-37Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-37Background information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-37Planning methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-39

Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-40Acronym list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-40

Chapter 2: Transmission systemsBSS interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2Interconnecting the BSC and BTSs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4Interconnection rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6Star connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7Daisy chain connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8Daisy chain planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8Aggregate Abis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10RTF path fault containment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1516 kbps XBL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20Dynamic allocation of RXCDR to BSC circuits (DARBC) . . . . . . . . . . . . . . . . . . . 2-21

Managed HDSL on micro BTSs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24Integrated HDSL interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24General HDSL guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26Microcell system planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27

Chapter 3: BSS cell planningPlanning tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3Traffic capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4

Dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4Channel blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4Traffic flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5Grade of service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5

ii 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Contents

Adaptive multi-rate (AMR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6Capacity and coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6Quality of service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8Migration to AMR half rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9Interoperability with GSM half rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9Interoperability with EGPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9

GSM half rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10Capacity and coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10Quality of service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11Migration to half rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12Interoperability with AMR half rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12Interoperability with EGPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12

Channel coding schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13Channel coding scheme 1 (CS1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13Channel coding scheme 2 (CS2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14Channel coding scheme 3 (CS3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15Channel coding scheme 4 (CS4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1616/32 kbps TRAU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17EGPRS channel coding schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1864 kbps TRAU for EGPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28Link adaptation (LA) in GPRS/EGPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29

Subscriber environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30Subscriber hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31Hand portable subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32Future planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33

Microcellular solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34Layered architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34Combined cell architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35Combined cell architecture structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35Expansion solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36

Frequency planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38Rules for Synthesizer Frequency Hopping (SFH) . . . . . . . . . . . . . . . . . . . . . . 3-38Rules for BaseBand Hopping (BBH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-42

Inter-radio access technology (2G-3G) cell reselection and handovers . . . . . . . . . . . . . . 3-44Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-442G-3G handover description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44Impact of 2G-3G handovers on GSM system architecture . . . . . . . . . . . . . . . . . . 3-45System consideration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-46

TD-SCDMA and GSM interworking feature . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-47Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-47Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-47Limitations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-47

Call model parameters for capacity calculations . . . . . . . . . . . . . . . . . . . . . . . . . 3-48Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48Typical call parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48

Control channel calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-52Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-52Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53Combined BCCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-54Number of CCCHs and PCCCHs per BTS cell . . . . . . . . . . . . . . . . . . . . . . . . 3-55User data capacity on the PCCCH timeslot . . . . . . . . . . . . . . . . . . . . . . . . . 3-65

68P02900W21-T iii

Jul 2010

Contents

Number of SDCCHs per BTS cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-66Control channel configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-69

GPRS/EGPRS traffic planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-73Determination of expected load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-73Network planning flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-73

GPRS/EGPRS network traffic estimation and key concepts . . . . . . . . . . . . . . . . . . . 3-74Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-74Dynamic timeslot allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-76Carrier timeslot allocation examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-83BSS timeslot allocation methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-91Recommendation for switchable timeslot usage . . . . . . . . . . . . . . . . . . . . . . . 3-93Timeslot allocation process on carriers with GPRS traffic . . . . . . . . . . . . . . . . . . 3-95

GPRS/EGPRS air interface planning process . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-96Influential factors in GPRS/EGPRS cell planning and deployment . . . . . . . . . . . . . . 3-96Estimating the air interface traffic throughput. . . . . . . . . . . . . . . . . . . . . . . . 3-107Select a cell plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-108Estimating timeslot provisioning requirements . . . . . . . . . . . . . . . . . . . . . . . 3-109Configurable initial coding scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-117GPRS/EGPRS data rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-118

Chapter 4: AMR and GSM half-rate planningIntroduction to AMR and GSM planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

AMR basic operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2GSM half rate basic operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2AMR and GSM half rate interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3New hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3Influencing factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4

Quality and capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5Benefits of AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5AMR Full Rate and AMR Half Rate speech quality . . . . . . . . . . . . . . . . . . . . . . 4-5AMR voice quality improvement and coverage. . . . . . . . . . . . . . . . . . . . . . . . 4-9Benefits of GSM half rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10GSM Half Rate speech quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11Capacity increase due to half rate usage. . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11Timeslot usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14

Miscellaneous information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16Emergency call handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16Circuit pooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16

Half rate utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17Parameter descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17Operational aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23

Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26Equipment descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26Backhaul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28

Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32

Chapter 5: BTS planning steps and rulesBTS planning overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2Outline of planning steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3

Macrocell cabinets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4Horizon II macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4Horizonmacro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5Horizoncompact and Horizoncompact2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6

iv 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Contents

M-Cell6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6M-Cell2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7

Microcell enclosures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8Horizon II mini. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8Horizonmicro and Horizonmicro2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9Horizon II micro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9

Receive configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11

Transmit configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14Transmit planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17

EGPRS enabled CTU2/CTU2D configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18EGPRS enabled CTU2/CTU2D configuration limitations . . . . . . . . . . . . . . . . . . . 5-18EGPRS general configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18BaseBand Hopping (BBH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18Broadcast Control CHannel (BCCH) RTF configuration . . . . . . . . . . . . . . . . . . . 5-19

Carrier equipment (transceiver unit). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20Restrictions in CTU2s usage in Horizonmacro BTSs . . . . . . . . . . . . . . . . . . . . . 5-21CTU/CTU2 power supply considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23Transceiver planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24

Micro base control unit (microBCU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25MicroBCU planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25

Network interface unit (NIU) and site connection . . . . . . . . . . . . . . . . . . . . . . . . 5-26Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26NIU planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-28

BTS main control unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30Planning considerations – Horizon II macro/Horizon II mini as expansion cabinet . . . . . . 5-31Planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-32

Cabinet interconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34Horizon II mini. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34Planning considerations - Horizon II macro as master cabinet . . . . . . . . . . . . . . . . 5-36Planning considerations - Horizon II mini as master cabinet . . . . . . . . . . . . . . . . . 5-37XMUX/FMUX/FOX planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37Site expansion board planning actions (Horizon II macro only) . . . . . . . . . . . . . . . 5-37

Battery back-up provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-38Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-38Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-38

External power requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39Power planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40

Network expansion using macro/microcell BTSs . . . . . . . . . . . . . . . . . . . . . . . . . 5-41Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-41Expansion considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-41Mixed site utilization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-41

Line interface modules (HIM-75, HIM-120) . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-42Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-42

68P02900W21-T v

Jul 2010

Contents

Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-42HIM-75/HIM-120 planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-42

DRI/Combiner operability components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-43Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-43DRI and combiner relationship. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-43

CTU8m D4+ Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-44Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-44Supported topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-45Link selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-51Recommended D4+ configurations (CTU8m) . . . . . . . . . . . . . . . . . . . . . . . . 5-55Recommended D4+ configurations (RCTU8m). . . . . . . . . . . . . . . . . . . . . . . . 5-58

Chapter 6: BSC planning steps and rulesBSC planning overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3Mixing of equipment types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3Outline of planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4

Capacity calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6Remote transcoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6

BSC system capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7System capacity summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7Scalable BSC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9Enhanced BSC capacity option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10Huge BSC capacity option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10LCS option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10

Determining the required BSS signaling link capacities . . . . . . . . . . . . . . . . . . . . . 6-11BSC signaling traffic model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11Typical parameter values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14Assumptions used in capacity calculations . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18Link capacities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20

Determining the number of RSLs required. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22Determining the number of RSLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23One phase access and enhanced one phase . . . . . . . . . . . . . . . . . . . . . . . . . 6-24Standard traffic model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24Non-standard traffic model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27With one phase access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27With enhanced one phase access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28BSC to BTS E1 interconnect planning actions . . . . . . . . . . . . . . . . . . . . . . . . 6-31BSC to BTS E1 interconnect planning example . . . . . . . . . . . . . . . . . . . . . . . 6-32Determining the number of LCF GPROCs for RSL and GSL processing BSC to BTS E1interconnect planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-33

Determining the number of MTLs required . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-37Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-37Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-37Standard traffic model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-38Non-standard traffic model for 64 k MTL . . . . . . . . . . . . . . . . . . . . . . . . . . 6-40Non-standard traffic model for HSP MTL . . . . . . . . . . . . . . . . . . . . . . . . . . 6-41Calculate the number of LCFs for MTL processing. . . . . . . . . . . . . . . . . . . . . . 6-43LCFs for 64 k MTL links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-43LCFs for HSP MTL links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-44MSC to BSC signaling over a satellite link . . . . . . . . . . . . . . . . . . . . . . . . . . 6-44

Determining the number of LMTLs required . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-45Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-45Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-45

vi 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Contents

Determining the number of LMTLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-45BSC to SMLC interconnection planning actions . . . . . . . . . . . . . . . . . . . . . . . 6-46Calculate the number of LCFs for LMTL processing . . . . . . . . . . . . . . . . . . . . . 6-46

Determining the number of XBLs required. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-47Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-47Determining the number of XBLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-47Standard traffic model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-48Non standard traffic model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-49

Determining the number of GSLs required. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-50Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-50Load balancing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-52

Generic processor (GPROC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-53GPROC nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-53Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-53GPROC functions and types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-53GPROC3/GPROC3-2 planning assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6-55BSC types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-55Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-56Cell broadcast link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-58Optimizations Link (OPL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-58OMF GPROC required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-58Code storage facility processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-59GPROC redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-59GPROC planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-62

Transcoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-63GDP/XCDR/EGDP/GDP2 planning considerations . . . . . . . . . . . . . . . . . . . . . . 6-64EGDP provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-65Planning actions for transcoding at the BSC . . . . . . . . . . . . . . . . . . . . . . . . . 6-67

Multiple serial interface (MSI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-70Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-70Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-70MSI planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-71

Packet Subrate Interface (PSI2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-72Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-72Planning consideration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-72PSI2 planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-72

Kiloport switch (KSW) and double kiloport switch (DSW2). . . . . . . . . . . . . . . . . . . . 6-73Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-73Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-73KSW/DSW2 planning actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-75

BSU shelves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-77Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-77Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-77BSU shelf planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-77

Kiloport switch extender (KSWX) and double kiloport switch extender (DSWX) . . . . . . . . . 6-80Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-80Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-80KSWX/DSWX planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-81

Generic clock (GCLK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-82Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-82Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-82GCLK planning actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-82

Clock extender (CLKX). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-83Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-83Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-83CLKX planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-84

Local area network extender (LANX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-85Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-85

68P02900W21-T vii

Jul 2010

Contents

Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-85LANX planning actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-85

Parallel interface extender (PIX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-86Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-86Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-86PIX planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-86

Line interface boards (BIB/PBIB, T43/PT43) . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-87Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-87Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-87(P)BIB/(P)T43 planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-88

Digital shelf power supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-89Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-89Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-89Power supply planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-89

Non Volatile Memory (NVM) board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-90Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-90Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-90NVM planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-90

Verifying the number of BSU shelves and BSSC cabinets . . . . . . . . . . . . . . . . . . . . 6-91Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-91

Chapter 7: RXCDR planning steps and rulesOverview of remote transcoder planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2Outline of planning steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

RXCDR system capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4System capacity summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4

RXCDR to BSC connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5

RXCDR to BSC links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6E1 interconnect planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7

RXCDR to MSC links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8E1 interconnect planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8

Generic processor (GPROC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9GPROC nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9

Transcoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10XCDR/GDP/EGDP/GDP2 planning considerations . . . . . . . . . . . . . . . . . . . . . . 7-12EGDP provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13Planning actions for transcoding at the RXCDR . . . . . . . . . . . . . . . . . . . . . . . 7-15

Multiple serial interface (MSI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17MSI planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18

Kiloport switch (KSW) and double kiloport switch (DSW2). . . . . . . . . . . . . . . . . . . . 7-19Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19KSW/DSW2 planning actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20

RXU shelves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22RXU shelf planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-23

viii 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Contents

Enhanced capacity mode is enabled (non-extension shelf) . . . . . . . . . . . . . . . . . . 7-24Enhanced capacity mode is enabled (extension shelf) . . . . . . . . . . . . . . . . . . . . 7-24

Kiloport switch extender (KSWX) and double kiloport switch extender (DSWX) . . . . . . . . . 7-25Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-25Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-25KSWX/DSWX planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-26

Generic clock (GCLK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-28Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-28Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-28GCLK planning actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-28

Clock extender (CLKX). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-29Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-29Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-29CLKX planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-29

LAN extender (LANX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-31Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-31Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-31LANX planning actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-31

Parallel interface extender (PIX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-32Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-32Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-32PIX planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-32

Line interfaces (BIB, T43) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-33Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-33Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-33BIB/T43 planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-34

Digital shelf power supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-35Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-35Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-35Power supply planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-35

Non Volatile Memory (NVM) board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-36Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-36Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-36NVM planning actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-36

Verify the number of RXU shelves and BSSC cabinets . . . . . . . . . . . . . . . . . . . . . . 7-37Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-37

Chapter 8: BSS planning for GPRS/EGPRSBSS planning for GPRS/EGPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2

Introduction to BSS planning for GPRS/EGPRS . . . . . . . . . . . . . . . . . . . . . . . 8-2PCU to SGSN interface planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2Feature compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3

PCU hardware layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-21PCU shelf (cPCI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22

MPROC board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24PSP planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24

DPROC board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-25Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-25PICP or PRP planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-25PXP planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-28

PMC module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30

(Packet) Rear Transition Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-31

68P02900W21-T ix

Jul 2010

Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-31Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-31

PCU equipment redundancy and provisioning goals . . . . . . . . . . . . . . . . . . . . . . . 8-32Support for equipment redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32PCU equipment redundancy planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32PRP/PICP configure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-33PXP configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-38Upgrading the PCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-43

E1 link/ETH link provisioning for GPRS and EGPRS . . . . . . . . . . . . . . . . . . . . . . . 8-46E1 interface provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-46E1 Planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-46Ethernet interface provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-47

QoS capacity and QoS2 impact. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-49MTBR allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-51PRP-PDTCH QoS planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-54Calculating PRP board throughput. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-54Calculating average downlink EGBR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-55CTU2D impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-62

PCU-SGSN: traffic and signal planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-63Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-63Gb entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-63General planning guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-64Specific planning guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-65Gb signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-65Determining net Gb load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-65Gb link timeslots (for Frame relay Gb) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-66Frame relay parameter values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-67Gb link (for Ethernet Gb) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-69

BSS-PCU hardware planning example for GPRS . . . . . . . . . . . . . . . . . . . . . . . . . 8-72Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-72BSS - PCU planning example for GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-72

BSS-PCU hardware planning example for EGPRS . . . . . . . . . . . . . . . . . . . . . . . . 8-79Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-79BSS - PCU planning example for EGPRS . . . . . . . . . . . . . . . . . . . . . . . . . . 8-79BSS - PCU planning example for EGPRS with QoS enabled, QoS2 not enabled . . . . . . . 8-86BSS - PCU planning example for EGPRS with QoS and QoS2 enabled . . . . . . . . . . . . 8-93

Chapter 9: Planning examplesPre-requisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2Network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3

Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4

Determine the hardware requirements for BTS B . . . . . . . . . . . . . . . . . . . . . . . . 9-5Cabinet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6

Determine the hardware requirements for BTS K . . . . . . . . . . . . . . . . . . . . . . . . 9-8Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8Cabinet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8Receiver requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8Transmitter combining requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9

Determine the hardware requirements for the BSC . . . . . . . . . . . . . . . . . . . . . . . 9-11Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13

Determine the hardware requirements for the RXCDR. . . . . . . . . . . . . . . . . . . . . . 9-14MSI requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14

x 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Contents

Transcoder requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14Link interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15GPROC requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15KSW/DSW2 requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15KSWX/DSWX requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15GCLK requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15CLKX requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15PIX requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15LANX requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16Power supply. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16

Calculations using alternative call models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17Planning example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17Planning example 2 (using AMR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-30Planning example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-46

Planning example of BSS support for LCS provisioning . . . . . . . . . . . . . . . . . . . . . 9-59Typical parameter values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-59LCS planning example calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-59Planning example for GSR10 with no (E)GPRS and high signaling . . . . . . . . . . . . . . 9-62

Chapter 10: Location area planningLocation area planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2Location area planning calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3

Example procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3

Chapter 11: Call model parametersDeriving call model parameters from network statistics . . . . . . . . . . . . . . . . . . . . . 11-2

Standard call model parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2Call duration (T) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5Ratio of SMSs per call (S) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6Ratio of handovers per call (H). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7Ratio of intra BSS handovers to all handovers (i) . . . . . . . . . . . . . . . . . . . . . . 11-7Ratio of location updates per call (I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-8Ratio of IMSI detaches per call (I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-8Location update factor (L) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-9Paging rate (PGSM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-9Pages per call (PPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-10Percent link utilization MSC to BSS [U(MSC – BSS)] . . . . . . . . . . . . . . . . . . . . . . . 11-11Percent link utilization BSC to BTS [U(BSC – BTS)] . . . . . . . . . . . . . . . . . . . . . . . 11-11Percent Link Utilization BSC to SMLC (U(BSC – SMLC)) . . . . . . . . . . . . . . . . . . . . . 11-12Blocking for TCHs (PB – TCHs)1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12GPRS CS1 uplink usage (CS1_usage_UL) . . . . . . . . . . . . . . . . . . . . . . . . . . 11-13GPRS CS1 downlink usage (CS1_usage_DL) . . . . . . . . . . . . . . . . . . . . . . . . . 11-14GPRS CS2 uplink usage (CS2_usage_UL) . . . . . . . . . . . . . . . . . . . . . . . . . . 11-14GPRS CS2 downlink usage (CS2_usage_DL) . . . . . . . . . . . . . . . . . . . . . . . . . 11-15GPRS CS3 uplink usage (CS3_usage_UL) . . . . . . . . . . . . . . . . . . . . . . . . . . 11-16GPRS CS3 downlink usage (CS3_usage_DL) . . . . . . . . . . . . . . . . . . . . . . . . . 11-17GPRS CS4 uplink usage (CS4_usage_UL) . . . . . . . . . . . . . . . . . . . . . . . . . . 11-18GPRS CS4 downlink usage (CS4_usage_DL) . . . . . . . . . . . . . . . . . . . . . . . . . 11-19EGPRS MCS1 uplink usage (MCS1_usage_UL). . . . . . . . . . . . . . . . . . . . . . . . 11-19EGPRS MCS1 downlink usage (MCS1_usage_DL) . . . . . . . . . . . . . . . . . . . . . . 11-20EGPRS MCS2 uplink usage (MCS2_usage_UL). . . . . . . . . . . . . . . . . . . . . . . . 11-21EGPRS MCS2 downlink usage (MCS2_usage_DL) . . . . . . . . . . . . . . . . . . . . . . 11-22EGPRS MCS3 uplink usage (MCS3_usage_UL). . . . . . . . . . . . . . . . . . . . . . . . 11-23EGPRS MCS3 downlink usage (MCS3_usage_DL) . . . . . . . . . . . . . . . . . . . . . . 11-24

68P02900W21-T xi

Jul 2010

Contents

EGPRS MCS4 uplink usage (MCS4_usage_UL). . . . . . . . . . . . . . . . . . . . . . . . 11-24EGPRS MCS4 downlink usage (MCS4_usage_DL) . . . . . . . . . . . . . . . . . . . . . . 11-25EGPRS MCS5 uplink usage (MCS5_usage_UL). . . . . . . . . . . . . . . . . . . . . . . . 11-26EGPRS MCS5 downlink usage (MCS5_usage_DL) . . . . . . . . . . . . . . . . . . . . . . 11-27EGPRS MCS6 uplink usage (MCS6_usage_UL). . . . . . . . . . . . . . . . . . . . . . . . 11-28EGPRS MCS6 downlink usage (MCS6_usage_DL) . . . . . . . . . . . . . . . . . . . . . . 11-29EGPRS MCS7 uplink usage (MCS7_usage_UL). . . . . . . . . . . . . . . . . . . . . . . . 11-29EGPRS MCS7 downlink usage (MCS7_usage_DL) . . . . . . . . . . . . . . . . . . . . . . 11-30EGPRS MCS8 uplink usage (MCS8_usage_UL). . . . . . . . . . . . . . . . . . . . . . . . 11-31EGPRS MCS8 downlink usage (MCS8_usage_DL) . . . . . . . . . . . . . . . . . . . . . . 11-32EGPRS MCS9 uplink usage (MCS9_usage_UL). . . . . . . . . . . . . . . . . . . . . . . . 11-33EGPRS MCS9 downlink usage (MCS9_usage_DL) . . . . . . . . . . . . . . . . . . . . . . 11-34Sample statistic calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-34

Chapter 12: Hardware and compatibilityHardware configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2

Horizon II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2Horizonmacro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2M-Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2Micro Base Transceiver Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3BSC/RXCDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3PCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3

xii 68P02900W21-T

Jul 2010

Listof

Figures

List of Figures■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

■

■

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

68P02900W21-T xiii

Jul 2010

List of Figures

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

xiv 68P02900W21-T

Jul 2010

List of Figures

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

68P02900W21-T xv

Jul 2010

List of Figures

xvi 68P02900W21-T

Jul 2010

Listof

Tables

List of Tables■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

■

■

Table 1-1: Transceiver unit usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5Table 1-2: Acronym list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-40Table 2-1: BSS interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2Table 2-2: RTF types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17Table 3-1: Coding parameters for GPRS coding schemes . . . . . . . . . . . . . . . . . . . . 3-17Table 3-2: Coding parameters for EGPRS coding schemes . . . . . . . . . . . . . . . . . . . . 3-28Table 3-3: Frequency and parameter setting plan . . . . . . . . . . . . . . . . . . . . . . . . 3-41Table 3-4: RTF-DRI mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-43Table 3-5: Typical parameters for BTS call planning . . . . . . . . . . . . . . . . . . . . . . . 3-48Table 3-6: Control channel configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-59Table 3-7: Example Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-69Table 3-8: Control channel configurations for non-border location area . . . . . . . . . . . . . 3-70Table 3-9: Control channel configurations for border location area . . . . . . . . . . . . . . . 3-71Table 3-10: MM state model of MS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-75Table 3-11: Capping settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-78Table 3-12: Output power capacity of (R)CTU8m for GMSK and 8-PSK . . . . . . . . . . . . . 3-78Table 3-13: CTU2D output power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-79Table 3-14: DRI-RTF Mapping functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-79Table 3-15: Arrangement of packet data timeslots for example 1 . . . . . . . . . . . . . . . . 3-84Table 3-16: Arrangement of packet data timeslots for example 2 . . . . . . . . . . . . . . . . 3-85Table 3-17: Arrangement of packet data timeslots for example 3 . . . . . . . . . . . . . . . . 3-86Table 3-18: Arrangement of packet data timeslots for example 4 . . . . . . . . . . . . . . . . 3-87Table 3-19: Arrangement of packet data timeslots for example 5 . . . . . . . . . . . . . . . . 3-88Table 3-20: Arrangement of packet data timeslots for example 6 . . . . . . . . . . . . . . . . 3-89Table 3-21: Arrangement of packet data timeslots for example 7 . . . . . . . . . . . . . . . . 3-89Table 3-22: Arrangement of packet data timeslots for example 8 . . . . . . . . . . . . . . . . 3-90Table 3-23: Arrangement of packet data timeslots for example 9 . . . . . . . . . . . . . . . . 3-91Table 3-24: Arrangement of packet data timeslots for example 10 . . . . . . . . . . . . . . . . 3-91Table 3-25: Typical TCP throughput against RLC/MAC throughput at zero block error rate . . . 3-102Table 3-26: r for various transfer delays at GBR 15 kbps or less . . . . . . . . . . . . . . . . . 3-103Table 3-27: r for transfer delay = 500 ms at GBR greater than 15 kbps . . . . . . . . . . . . . 3-104Table 3-28: r for transfer delay = 250 ms at GBR greater than 15 kbps . . . . . . . . . . . . . 3-105Table 3-29: ARP mobile selection (ARP Rank) order . . . . . . . . . . . . . . . . . . . . . . . 3-106Table 3-30: BSS ARP configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 3-107Table 3-31: Percentage of code utilization in a 4x3 non-hopping re-use pattern at 20% BLER . . 3-108Table 3-32: MTBR Mix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-112Table 3-33: MTBR Constant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-113Table 3-34: THP Weight Mix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-113Table 3-35: THP Weight Constant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-113Table 3-36: QoS Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-113Table 3-37: QoS Disabled; Capacity: 18 users, DL Throughput per MS: 0.33 (6/18) TS . . . . . 3-114Table 3-38: QoS Enabled; Capacity: 11 users, DL Throughput per MS: 0.54 (6/11) TS. . . . . . 3-116Table 3-39: GPRS downlink data rates (kbps) with TCP (CS1) . . . . . . . . . . . . . . . . . . 3-120Table 3-40: GPRS downlink data rates (kbps) with TCP (CS2) . . . . . . . . . . . . . . . . . . 3-120Table 3-41: GPRS downlink data rates (kbps) with TCP (CS3) . . . . . . . . . . . . . . . . . . 3-120

68P02900W21-T xvii

Jul 2010

List of Tables

Table 3-42: GPRS downlink data rates (kbps) with TCP (CS4) . . . . . . . . . . . . . . . . . . 3-121Table 3-43: GPRS downlink data rates (kbps) with UDP (CS1) . . . . . . . . . . . . . . . . . . 3-121Table 3-44: GPRS downlink data rates (kbps) with UDP (CS2) . . . . . . . . . . . . . . . . . . 3-121Table 3-45: GPRS downlink data rates (kbps) with UDP (CS3) . . . . . . . . . . . . . . . . . . 3-122Table 3-46: GPRS downlink data rates (kbps) with UDP (CS4) . . . . . . . . . . . . . . . . . . 3-122Table 3-47: EGPRS downlink data rates (kbps) with TCP (MCS1) . . . . . . . . . . . . . . . . 3-122Table 3-48: EGPRS downlink data rates (kbps) with TCP (MCS2) . . . . . . . . . . . . . . . . 3-123Table 3-49: EGPRS downlink data rates (kbps) with TCP (MCS3) . . . . . . . . . . . . . . . . 3-123Table 3-50: EGPRS downlink data rates (kbps) with TCP (MCS4) . . . . . . . . . . . . . . . . 3-123Table 3-51: EGPRS downlink data rates (kbps) with TCP (MCS5) . . . . . . . . . . . . . . . . 3-124Table 3-52: EGPRS downlink data rates (kbps) with TCP (MCS6) . . . . . . . . . . . . . . . . 3-124Table 3-53: EGPRS downlink data rates (kbps) with TCP (MCS7) . . . . . . . . . . . . . . . . 3-124Table 3-54: EGPRS downlink data rates (kbps) with TCP (MCS8) . . . . . . . . . . . . . . . . 3-125Table 3-55: EGPRS downlink data rates (kbps) with TCP (MCS9) . . . . . . . . . . . . . . . . 3-125Table 3-56: EGPRS downlink data rates (kbps) with UDP (MCS1) . . . . . . . . . . . . . . . . 3-125Table 3-57: EGPRS downlink data rates (kbps) with UDP (MCS2) . . . . . . . . . . . . . . . . 3-126Table 3-58: EGPRS downlink data rates (kbps) with UDP (MCS3) . . . . . . . . . . . . . . . . 3-126Table 3-59: EGPRS downlink data rates (kbps) with UDP (MCS4) . . . . . . . . . . . . . . . . 3-126Table 3-60: EGPRS downlink data rates (kbps) with UDP (MCS5) . . . . . . . . . . . . . . . . 3-127Table 3-61: EGPRS downlink data rates (kbps) with UDP (MCS6) . . . . . . . . . . . . . . . . 3-127Table 3-62: EGPRS downlink data rates (kbps) with UDP (MCS7) . . . . . . . . . . . . . . . . 3-127Table 3-63: EGPRS downlink data rates (kbps) with UDP (MCS8) . . . . . . . . . . . . . . . . 3-128Table 3-64: EGPRS downlink data rates (kbps) with UDP (MCS9) . . . . . . . . . . . . . . . . 3-128Table 4-1: AMR potential coverage gains . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10Table 4-2: Backhaul configuration based on parameter settings . . . . . . . . . . . . . . . . . 4-29Table 4-3: Call placement on terrestrial backhaul . . . . . . . . . . . . . . . . . . . . . . . . 4-29Table 4-4: Voice call mapping on the backhaul for a 64 k RTF . . . . . . . . . . . . . . . . . . 4-29Table 5-1: Specifications for CTU8m in Horizon II macro . . . . . . . . . . . . . . . . . . . . 5-4Table 5-2: Transmit configurations – pre-CTU8m radio . . . . . . . . . . . . . . . . . . . . . 5-15Table 5-3: Transmission configurations – CTU8m in 4-carrier mode . . . . . . . . . . . . . . . 5-16Table 5-4: Transmission configurations – CTU8m in 6-carrier mode . . . . . . . . . . . . . . . 5-16Table 5-5: Transmission configurations – CTU8m in 8-carrier mode . . . . . . . . . . . . . . . 5-16Table 5-6: BBH capability for Horizon II macro Site Controller . . . . . . . . . . . . . . . . . 5-19Table 5-7: BBH capability for Horizonmacro Site Controller . . . . . . . . . . . . . . . . . . . 5-19Table 5-8: CTU/CTU2 power requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21Table 5-9: CTU/CTU2 power requirements for M-Cell cabinets . . . . . . . . . . . . . . . . . 5-23Table 5-10: Site connection requirements for M-Cell2 and M-Cell6 . . . . . . . . . . . . . . . 5-27Table 5-11: Horizon II macro XMUX expansion requirements . . . . . . . . . . . . . . . . . . 5-34Table 5-12: Horizon II mini only network XMUX expansion requirements . . . . . . . . . . . . 5-35Table 5-13: Horizon II macro as master - Horizon II mini as expansion XMUX requirements . . 5-35Table 5-14: Horizonmacro as master - Horizon II mini as expansion XMUX/FMUXrequirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35Table 5-15: Horizonmacro as master - Horizonmacro as expansion FMUX requirements . . . . 5-36Table 6-1: BSC maximum capacities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7Table 6-2: BSC configuration capacities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8Table 6-3: Typical call parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14Table 6-4: Other parameters used in determining GPROC and link requirements . . . . . . . . 6-18Table 6-5: Signaling message procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18Table 6-6: BTS support for 64kbit/s RSL or 16 kbps RSLs . . . . . . . . . . . . . . . . . . . . 6-23Table 6-7: Number of BSC to BTS signaling links (without LCS) . . . . . . . . . . . . . . . . . 6-25Table 6-8: Backhaul requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-31Table 6-9: Number of MSC and BSC signaling links without LCS (20% utilization) . . . . . . . 6-39Table 6-10: Number of MSC and BSC signaling links without LCS (40% utilization) . . . . . . . 6-39Table 6-11: Number of MSC and BSC signaling links without LCS (13% utilization) . . . . . . . 6-40Table 6-12: Number of BSC to RXCDR signaling links . . . . . . . . . . . . . . . . . . . . . . 6-48Table 6-13: Typical call parameters relating to XBLs . . . . . . . . . . . . . . . . . . . . . . 6-48Table 6-14: GPROC type/function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-54Table 6-15: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-61

xviii 68P02900W21-T

Jul 2010

List of Tables

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

68P02900W21-T xix

Jul 2010

List of Tables

xx 68P02900W21-T

Jul 2010

AboutThisManual

System Information: BSS EquipmentPlanning

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

■

■

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 includingHorizon and M-cell range of equipment, a BSC including the scenario when an LCS is used, anRXCDR 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 theOMC-R. This manual also deals with standard BSS, Horizon BTS, and M-Cell BTS configurations.

68P02900W21-T 1

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

R Jan 2005 Includes GSM Software Release 8

S Mar 2009 Software release GSR9

T Jul 2010 Software release GSR10

Release information

This section describes the changes in this document in release GSR10. The following featureshave 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:

ServiceRequest CMBP Number Remarks

N/A N/A

2 68P02900W21-T

Jul 2010

General information

General information■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Purpose

Motorola documents provide the information to operate, install, and maintain Motorolaequipment. It is recommended that all personnel engaged in such activities be properly trainedby Motorola.

Motorola disclaims all liability whatsoever, implied or expressed, for any risk of damage, loss orreduction 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 byMotorola. They can be used to supplement and enhance the knowledge gained through suchtraining.

NOTEIf this document was obtained when attending a Motorola training course, it is notupdated or amended by Motorola. It is intended for TRAINING PURPOSES ONLY. If itwas supplied under normal operational circumstances, to support a major softwarerelease, then Motorola automatically supplies corrections and posts on the Motorolacustomer 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 arenot numbered, but are individually named at the top of each page, and are listed in the table ofcontents.

Document banner definitions

A banner indicates that some information contained in the document is not yet approved forgeneral customer use. A banner is oversized text on the bottom of the page, for example,PRELIMINARY — UNDER DEVELOPMENT

68P02900W21-T 3

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 orCTRL+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.

4 68P02900W21-T

Jul 2010

Contacting Motorola

Contacting Motorola■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Motorola appreciates feedback from the users of our documents.

24–hour support

If you have problems regarding the operation of your equipment, contact the Customer NetworkResolution Center (CNRC) for immediate assistance. The 24–hour telephone numbers are listedat https://mynetworksupport.motorola.com. Select Customer Network Resolution Centercontact information. Alternatively if you do not have access to CNRC or the internet, contactthe Local Motorola Office.

Ordering documents and CD-ROMs

With internet access available, to view, download, or order documents (original or revised), visitthe Motorola customer web page at https://mynetworksupport.motorola.com, or contact yourMotorola account representative.

Without internet access available, order hard-copy documents or CD-ROMs from your MotorolaLocal Office or Representative.

If Motorola changes the content of a document after the original printing date, Motorolapublishes 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) andprovide 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 5

Jul 2010

Errors

6 68P02900W21-T

Jul 2010

Chapter

1

Introduction to planning■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

■

■

An overview of this manual and the various elements of a BSS and the BSS planningmethodology are provided here. Included is information about BSS system architecture,components, and features that can affect the planning stage together with information requiredbefore 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

• OMC-R planning is beyond the scope of this manual.

• For information on installing a new OMC-R, refer to 68P02901W47, Installationand Configuration: OMC-R Clean Install. For information on upgrading anexisting OMC-R for this software release, refer to 68P02901W74, SoftwareRelease Notes: OMC-R System.

68P02900W21-T 1-1

Jul 2010

Manual overview Chapter 1: Introduction to planning

Manual overview■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The manual contains information about planning a GSM network, and utilizing a combination ofHorizon 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 rangeof 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 formulaeprovided 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

System Information: BSS Equipment Planning Contents

• Chapter 11 Call model parameters

Provides the planning steps and rules for deriving call model parameters from networkstatistics collected at the OMC-R.

• Chapter 12 Hardware and compatibility

Provides diagrams of the logical interconnections of the components in various standardBSS and Horizon BTS site configurations.

68P02900W21-T 1-3

Jul 2010

BSS equipment overview Chapter 1: Introduction to planning

BSS equipment overview■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

System architecture

The architecture of the Motorola Base Station System (BSS) is versatile, and allows severalpossible configurations for a given system. The BSS is a combination of digital and RFequipment that communicates with the Mobile Switching Center (MSC), the Operations andMaintenance Center Radio (OMC-R), and the Mobile Stations (MS) as shown in Figure 1-1.

Figure 1-1 BSS block diagram

MS MSMSMS

BTS 1

BTS 2 BTS 6

BTS 7

BTS nBTS 8BTS 5

BTS 4

BTS 3

AIR INTERFACE

ABIS INTERFACE

A INTERFACE

BSS

BSS

ti-GSM-BSS_block_diagram-00001-ai-sw

. . . . . .

. . .

MSC LRs

SGSN

PCU

RXCDR

OMC-R

O & M

BSC

1-4 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 allthe other BTSs as shown in Figure 1-1.

System components

The BSS is divided into a Base Station Controller (BSC), Remote Transcoder (RXCDR), PacketControl Unit (PCU), and one or more Base Transceiver Stations (BTSs). These componentscan be in-built or externally located Horizon II macro, Horizonmacro, or M-Cell BTS cabinetsor enclosures.

The Transcoder (XCDR) or Generic Digital Processor (GDP, EGDP, or GDP2) provides 4:1multiplexing of the traffic, and can be located at the BSC or between the BSC and MSC. Whenhalf rate is in use, it is possible to achieve a greater reduction (refer to the transcoding sectionsof Chapter 6 BSC planning steps and rules and Chapter 7 RXCDR planning steps and rulesfor a detailed description).

When the XCDR/GDP/EGDP/GDP2 is located at the MSC, it reduces the number ofcommunication links to the BSC. When transcoding is not performed at the BSC, the XCDR isreferred to as a remote transcoder (RXCDR). The RXCDR is part of the BSS but can servemore than one BSS.

In the Motorola BTS product line, the radio transmit and receive functions are provided aslisted in Table 1-1:

Table 1-1 Transceiver unit usage

Transceiver unit Where used

{34371G} Compact Transceiver Unit8multi ((R)CTU8m)

Horizon II macro, Horizon II micro, Horizon II mini,Horizon II extension (but connect the fiber link backto the BBU at the master cabinet).

Compact Transceiver Unit 2-D(CTU2D)

Horizon II macro, Horizon II micro, Horizon II mini,and Horizon II extension of the H2 master cabinet.

Compact Transceiver Unit 2D-CPI(CTU2-D-CPI)

Horizon II macro, Horizon II micro, Horizon II mini,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 withCTU2 Adapter.

Compact Transceiver Unit (CTU) Horizonmacro

Dual Transceiver Module (DTRX) Horizonmicro, Horizonmicro2, Horizoncompact andHorizoncompact2.

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 Chapter 1: Introduction to planning

NOTEExcept for the TCU, which is backwards compatible by switching from TCU to SCU onthe front panel, all other transceiver units are compatible only with the equipmentlisted.

(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 IImacro, Horizon II micro, Horizon II mini, the transceiver functions are provided by the in-cabinetCTU8ms 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 andplanning rules for the (R)CTU8m are provided in Chapter 5 BTS planning steps andrules of this manual. Configuration diagrams are shown in Chapter 12 Hardware andcompatibility. The (R)CTU8m receivers can support 2 branch receive diversity (donot support 4 branch receive diversity).

CTU2D

In Horizon II family, which includes Horizon II macro, Horizon II micro, Horizon II mini, andHorizon II extension of the H2 master cabinet, the CTU2D provides the transceiver functions. Itcan be configured to operate in single or double density mode.

CTU2D retains the behavior of CTU2 and extends to support two simultaneous carriers forEGPRS (Carrier B UL GMSK limited). The main reason for CTU2D not supporting unrestrictedEDGE on both carriers is MIPS constraints of the host processor. CTU2D radio can support thefollowing working modes:

• CTU2D single density mode: This mode is identical in operation to the existing CTU2single density mode.

• CTU2D double density power mode: This mode is also known as ITS Mode whereby theCTU2 and CTU2D operations are identical.

• CTU2D double density capacity mode: Of the two carriers, carrier A is fullyEDGE-capable, while carrier B supports GPRS/TCH. TS blanking is not required. Themaximum 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 EDGEcapable, while carrier B supports EDGE on the DL and GMSK (EDGE) on the UL. Themaximum 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*.

1-6 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning System components

NOTEThe output powers listed are for 900 MHz frequency. For all other frequencies, theoutput 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 onecell. Description and planning rules for the CTU2 are provided in Chapter 5 BTS planning stepsand rules of this manual. Configuration diagrams are shown in Chapter 12 Hardware andcompatibility. The receivers can support receive diversity.

CTU2

In Horizon II macro, the CTU2 provides the transceiver functions, which can be configuredto operate in single or double density mode.

The Horizonmacro can use this CTU2 as a CTU replacement with restrictions. Depending on thenumber of CTU/CTU2s in the Horizonmacro cabinet, there are output power restrictions thatneeds a mandatory third power supply installed in the Horizonmacro cabinet. This can affect thebattery hold-up module in ac-powered cabinets, as the location for the third power supply. Thatis, 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 requiresup to three power supplies when used with CTU2s. The M-Cell2 cabinet requires up to twopower supplies when used with CTU2s.

Description and planning rules for the CTU2 are provided in Chapter 5 BTS planning stepsand rules of this manual. Configuration diagrams are shown in Chapter 12 Hardware andcompatibility. The receivers can support receive diversity.

NOTECTU2s do not support the use of CCBs. A CTU2 cannot be CCB equipped and doesnot act as a full replacement or swap for the CTU. The CTU2 only acts as a CTUreplacement in the non-controller or standby controller mode. Contact the MotorolaLocal Office for details. When installed in Horizonmacro, the CTU2 only supportsbaseband hopping in single density mode.

CTU

The CTU provides the transceiver functions in Horizonmacro. Description and planningrules 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 receiverscan support receive diversity.

68P02900W21-T 1-7

Jul 2010

System components Chapter 1: Introduction to planning

DTRX

The dual transceiver module (DTRX) provides the transceiver functions in Horizonmicro,Horizonmicro2, Horizoncompact, and Horizoncompact2. System planning is described inChapter 2 Transmission systems and configuration diagrams are shown in Chapter 12 Hardwareand 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 planningsteps and rules of this manual. Configuration diagrams are shown in Chapter 12 Hardware andcompatibility. The receivers can support receive diversity.

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 functionspreviously handled on the legacy MCUF, FMUX, and BPSM modules in the Horizonmacrocabinet, are all integrated on a site controller board. Depending on the call load, siteconfiguration, and type of site controller, it is possible that the site controller can be the limitingfactor in defining the system capacity. A high level description of the different types of sitecontroller board available is now provided.

Horizon II Site Controller

The HIISC in Horizon II equipment provides all the site processing functions (except for theCTU2 RF functions). The functionality of the separate, legacy MCUF, NIU, FMUX, and BPSMmodules 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 additionalHorizon II equipment (with double density GSM or single density EGPRS transceivers)or legacy Horizonmacro cabinets (with single/double density GSM or single densityEGPRS 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 theother links connected to it such as the transceiver links, network links, redundancylinks, or processor links.

1-8 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning System components

• Front Panel Interfaces support:

Compact Flash card interface.The card can be used to support onsite codeloading or copying of code objects fromthe 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 ofsite processing functions offered by the HIISC. The HIISC-2 uses a hardware architecturethat is more powerful in terms of available memory, raw MIPS, and flexibility, which supportsmore aggressive call loads.

In addition, it supports:

• {33851} An automated clock calibration feature, in addition to the earlier manualcalibration method.

• A front panel Ethernet port that allows a fast local codeload and copy back facility as wellas a fast and secure MMI/TTY access to the processors.

This Front Panel Ethernet port-based feature combined with the fixed onboardnon-volatile memory replaces the Horizon II Site Controller Compact Flashfunctionality.

• 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 Chapter 1: Introduction to planning

HIISC2-S and HIISC2-E

The HIISC2-S and HIISC2-E in Horizon II equipment provides the same set of site processingfunctions offered by the HIISC, using a hardware architecture that is significantly more powerfulin terms of available memory, raw MIPs and flexibility, enabling it to support more aggressivecall 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 asfast and secure MMI/TTY access to the processors.

This Front Panel Ethernet port based feature combined with fixed onboardnon-volatile memory replaces the legacy H2SC Compact Flash functionality.

• Support for redundancy when paired with another HIISC2-S or HIISC2-E.

• Redundancy when paired with a HIISC is not supported.

HIISC2-E also provides an additional processor dedicated to support future packetized backhaulfeatures.

BBU-E

This board supports the same feature set as the HIISC2-S but an additional mezzanine cardis fitted to support (R)CTU8m radios and an additional processor dedicated to support futurepacketized backhaul features.

• Support for redundancy when paired with another BBU-E.

• Redundancy when paired with a HIISC is not supported.

{34371-34374} Refer to CTU8m and RCTU8m feature on page 1-29 for further details regardingthe BBU.

NOTEMixed pair of HIISC2-S/E and BBU-E for redundancy is supported technically, but itis not recommended due to its restricted application.

1-10 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSS features

BSS features■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Planning impacts

This section provides a description of the software features that might affect the requiredequipment before planning the actual equipment. Check with the appropriate Motorola salesoffice 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

• CTU2–D on page 1-24

• 96 MSIs on page 1-26

68P02900W21-T 1-11

Jul 2010

Diversity Chapter 1: Introduction to planning

• 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 uncorrelatedreceive signals to the transceiver. Each transceiver unit includes two receivers, whichindependently 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 inimproved interference protection. Two Rx antennas are required for each sector. Equivalentoverlapping antenna patterns and sufficient physical separation between the two antennas arerequired to obtain the necessary de-correlation.

Frequency hopping

There are two methods of providing frequency hopping synthesizer hopping and basebandhopping. Each method has different hardware requirements.

The main differences are as follows:

• 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, whilesynthesizer hopping does not.

1-12 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Short Message Service, Cell Broadcast (SMS CB)

Synthesizer hopping

Synthesizer hopping uses the frequency agility of the transceiver to change frequencies on atimeslot basis for both receive and transmit. The transceiver calculates the next frequency andre-programs its synthesizer to move to the new frequency. There are three important points tonote 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 withcoverage requirements.

• It is only necessary to provide as many transceivers as required by the traffic. Onetransceiver 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 transmitdirection. Baseband signals for a particular call are switched to a different transceiver at eachTDM frame to achieve frequency hopping. There are three important points to note when usingthis 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 andCTU2D in double density, CTU8m, or (R)CTU8m) or hybrid combiners is acceptable. TheHorizon 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 unilaterallytransmitting data to MSs on a per cell basis. A Cell Broadcast Channel (CBCH) providesthis 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-Rdownloads 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 theappropriate 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 CSFPallows preloading of a new software release while the BSS is operational. When BTSs areconnected to the BSC, a CSFP is required at the BSC and a second CSFP is equipped forredundancy as required.

68P02900W21-T 1-13

Jul 2010

PCU for GPRS upgrade Chapter 1: Introduction to planning

PCU for GPRS upgrade

The PCU hardware provides GPRS functionality and is part of the BSS equipment. GPRSplanning is fundamentally different to the planning of circuit-switched networks. One of thereasons for the difference is that a GPRS network allows the queuing of data traffic instead ofblocking a call when a circuit is unavailable. Consequently, the use of Erlang B tables forestimating the number of trunks or timeslots required is not a valid planning approach forthe GPRS packet data provisioning process.

Enhanced-GPRS (EGPRS)

The Enhanced Data Rates for Global Evolution (EDGE) enhances the data throughput of theGPRS to enable the Enhanced-GPRS (EGPRS) system. The planning guide takes into accountthe 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 RadioService (GPRS) feature, and the Coding Scheme 3/Coding Scheme 4 feature. This means thata network supporting EGPRS also provides support for the GSM voice and GPRS data. Thefollowing are some of the features included with EGPRS:

• EGPRS employs a new set of GSM modulation and channel coding techniques that increasea packet data throughput of the user from a maximum of 21.4 kbps per air timeslot withGPRS to a maximum of 59.2 kbps per air timeslot with EGPRS.

• The maximum data throughput for a multi-slot mobile is significantly increased comparedto that in GPRS.

• The initial release of EGPRS provides support for a multi-slot mobile using four downlinkand two uplink air timeslots. The EDMAC feature allows the support of mobiles classes11 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 using5 downlink air timeslots. Extension of the EDMAC feature allows the support of mobilesclasses 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 isthe 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 producedby these new data rates.

NOTEThe data rates used here are theoretical values.

1-14 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Adaptive Multi-Rate (AMR)

Adaptive Multi-Rate (AMR)

The AMR feature provides enhanced speech quality by adapting the speech and channel codingrates according to the quality of the radio channel. It provides increased capacity by allocatinghalf 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 combinationof speech quality and system capacity. The network user tunes this feature, on a cell-by-cellbasis to obtain the best balance between quality and capacity.

Due to the increased processing requirements of AMR, the existing GDP (which currentlysupports 30 voice channels and data services) only supports 15 AMR voice channels. However,two GDPs are paired to support a full E1’s worth of channels (30). This results in an overallreduction 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 cabinetutilize the added capacity.

NOTE

• When using the GDP2 within the extension RXU3 shelf in a non-MSI slot, enablethe enhanced capacity mode to access the second E1.

• The GDP2 can be used to full capacity in the existing BSU shelf, which hasno 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 havean additional two 64 kbps timeslots equipped to fully utilize all 16 half rate channels. Theexisting hardware also supports 16 kbps switching on the backhaul between the BSC andRXCDR, requiring 16 kbps per voice channel.

The Double Kiloport Switch (DSW2) has been introduced to address the problem. The DSW2supports double the number of ports (enhanced capacity mode) when used in the RXCDR, aswell as subrate switching capability down to 8 kbps (extended subrate switching mode). With 8kbps switching between the BSC and BTS, a half rate voice stream can be carried in an 8 kbpssubchannel, rather than the 16 kbps subchannel required with KSWs. This eliminates theneed for the two additional 64 kbps timeslots required per half rate capable RTF. There is oneexception, that is, when the 7.95 kbps half rate codec mode is included in the half rate ActiveCodec 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 (referredto as the Ater interface) required 16 kbps Ater channels, which were assigned duringinitialization/reconfiguration. With AMR, when a half rate traffic channel is assigned, the voicestream utilizes an 8 kbps channel (depending upon the codec modes employed). The DSW2benefit of 8 kbps subrate switching allows this capability to be realized. Dynamic assignmentof BSC to RXCDR channels is employed to maximize Ater channel usage. The BSC assigns an8 kbps or 16 kbps channel as required, based upon the backhaul in use across the BSC-BTSinterface. This allows the operator to equip fewer channels than previously possible, with theassumption that some calls are utilizing half rate backhaul.

68P02900W21-T 1-15

Jul 2010

GSM half rate Chapter 1: Introduction to planning

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 thatan 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 proportionof mobiles within a coverage area that supports half rate. An air timeslot is split into twosubchannels, each containing a half rate channel. Speech quality is considered inferior to otherspeech codecs but has a high penetration level (of GSM HR capable mobiles) due to its earlyintroduction 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 60channels of transcoding capability, respectively. The old RXU shelf has only one E1 connectionper transcoder slot, the GDP2 supports 30 channels when used in this configuration. The RXU3shelf 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 (8k) switching is present at the BSC.

The existing hardware only supports 16 kbps switching on the backhaul between the BSC andBTS. Therefore, when using the existing switching hardware, each half rate equipped RTF musthave an additional two 64 kbps timeslots equipped to fully utilize all 16 half rate channels. Theexisting hardware also supports only 16 kbps switching on the backhaul between the BSC andRXCDR, 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 kbpssubchannel, rather than the 16 kbps subchannel required with KSWs. This eliminates the needfor 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) onthe terrestrial resource from the BSC to the RXCDR, rather than the 16 kbps timeslot requiredfor full rate calls. If a percentage of the active calls is assumed to be half rate, the efficiencycan 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. Dynamicassignment of BSC to RXCDR channels is employed to maximize Ater channel usage. The BSCcan assign an 8 kbps or 16 kbps channel as required, based upon the backhaul in use across theBSC–BTS interface. This allows the user to equip fewer channels than previously possible, withthe assumption that some calls are utilizing half rate backhaul. This dynamic allocation is anenhancement to the existing Auto Connect mode feature, referred to as Enhanced Auto Connectmode. Enhanced Auto Connect is applicable to both AMR and GSM half rate.

Extended range cells

GSM half rate is only supported on the normal range timeslots and not on extended rangetimeslots (it is envisaged that the C/I ratio in the extended range portion of an extended rangecell does not support a half rate call).

1-16 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning LoCation Services (LCS)

LoCation Services (LCS)

LCS provides a set of capabilities that determine location estimates of mobile stations andmakes that information available to location applications. Applications requesting locationestimates from LCS can be located in the MS, the network, or external to the PLMN. LCS isnot classified as a supplementary service and can be subscribed to without subscribing to abasic telecommunication service. LCS is applicable to any target MS, whether the MS supportsLCS. However, there are restrictions on choice of positioning method or notification of a locationrequest to the MS user when the LCS or individual positioning methods respectively are notsupported 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 purposeof the request is to obtain an estimate of the location of the client MS, either for the clientMS 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 thePLMN 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 PLMNentities currently serving the target MS. In this case, the LCS client is also within theLCS server. Examples of a NI-LR include a location request required for supplementaryservices, 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. TheMSC 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 SMLCand BSC goes directly between the two entities.

68P02900W21-T 1-17

Jul 2010

IOS (Intelligent Optimization Service)/OPL (Optimization Link) Chapter 1: Introduction to planning

IOS (Intelligent Optimization Service)/OPL (Optimization Link)

The Intelligent Optimization Service (IOS) is a network-based system which collects itsdata from OPL. It involves analyzing large volumes of subscriber generated data regardingthe current network configuration and conditions. The operator uses the data to producerecommendations for neighbor topology and frequency plan changes.

The Optimization Link (OPL) is used to carry measurement report data out of the BSC. Thelink is a dedicated HDLC link between the BSC and IOS platform. It is a 64 kbps link that isequipped to a E1 timeslot on an existing MMS. Operator commands indicate which LCF hasto be used for the data stream and indicates which data is required. If OPL is equipped inthe BSS system, it impacts on LCF and MSI planning in BSC. For detailed information, referChapter 6 BSC planning steps and rules.

Figure 1-2 Intelligent Optimization Service

BTS1

MS

MS

MS

BTS2

BTSn

BSC

OMLX.25

OPL(64k HDLC)

OMC-R

DATA COLLECTION

SYSTEM

DATA ANALYSIS SYSTEM

LAN

LAN

INTELLIGENT OPTIMIZATION SERVICE

RSL

RSL

RSL

ti-GSM-IOS_OPL-00260-ai-sw

1-18 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSC Reset Management (BRM)

BSC Reset Management (BRM)

BSC Reset Management (BRM) provides the option for fast failover of the BSC, for certain typesof equipment failure. This minimizes the BSS outage, reducing the downtime from 10 minutesto 20 minutes to less than two minutes for most occurrences.

NOTEEquip the BSC with a redundant secondary BSP GPROC3/GPROC3-2 to utilize thisfeature.

Advanced Speech Call Item (ASCI)

The Advanced Speech Call Item (ASCI) feature includes the enhanced Multi-Level Precedenceand Preemption (eMLPP) feature.

Enhanced Multi-level Precedence and Preemption

With the enhanced Multi-level Precedence and Preemption (eMLPP) feature, operators canprovide preferential services to special users with higher priority such as police and medicalpersonnel 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 AInterface priority levels and procedures as defined in 3GPP TS 48.008. Enhancementsbased on priority are also provided. Resources of lower priority calls can be preemptedto allow higher priority calls to go through. Preemption is supported in the followingprocedures:

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 asingle failure on the linkset between an RXCDR-BSC or due to MSC indicatedCIC 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 Chapter 1: Introduction to planning

VersaTRAU backhaul for EGPRS

VersaTRAU reduces EGPRS backhaul costs by taking advantage of statistical multiplexing. Thisis achieved when packing variable size radio blocks to be sent over PDTCHs on a carrier, intoone large TRAU frame associated with the carrier. Analysis of the RF conditions of currentGPRS networks and predictions for EGPRS indicate that the average maximum throughput perEGPRS 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 dynamicallyprovisioned in terms of 64 kbps terrestrial timeslots (DS0s).

• Statistics are provided to the operator to measure the backhaul utilization for an EGPRScapable 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 oneor more terrestrial timeslots associated with this carrier. Versachannel is defined asthe portion of the backhaul associated with an RTF that is used to carry TRAU framesassociated with the air timeslots configured as a PDTCH. TRAU frame formats carry themultiplexed data blocks over the Versachannel.

All EGPRS capable carriers use VersaTRAU frame formats on the backhaul after introduction ofVersaTRAU. If half rate (GSM/AMR) is enabled on an EGPRS carrier, in order to maximize thebackhaul utilization, the 16 kbps switching format for the half rate calls is not supported on thebackhaul 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 ofService Level agreements with end users that guarantee both different probabilities of access tothe network and different throughputs once the network is accessed. Admission and retentioncontrol based Allocation/Retention priority (ARP), is provided for Interactive and Backgroundtraffic classes. QoS for conversational and streaming traffic classes is not supported, however,conversational and streaming traffic is allowed into the GPRS network and downgraded toInteractive class and is not subject to further downgrade or preemption.

The QoS feature allows operators to charge premium rates for the highest quality of serviceclasses 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 possibleservice specific to the types of applications used and specific to the type of tariff selected.

1-20 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 levelsof 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 PFCcharacteristics. 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 implementingdifferentiation of service among interactive and background traffic classes. Requests to createpacket 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 thestreaming 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 correspondingACKs and NACKs. In addition, the support for optional PFI IE in UL_UNITDATA andDL_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 QoSdesign to allow QoS to reserve the appropriate amount of throughput per cell. The updatedequations provide the cell with appropriate amount of throughput for QoS subscribersbased on the input to the formulas.

68P02900W21-T 1-21

Jul 2010

QoS2 Chapter 1: Introduction to planning

• PDTCH assignment to PRP

The formula for assigning PDTCHs to a PRP has been updated to allow subscribers withQoS to have the necessary throughput reserved at the PRP. The formulas use the userconfigurable parameters for MTBR for each Traffic Class and Coding Scheme usage todetermine 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 initialcoding scheme).

Support for Streaming Traffic Class allows the operator to specify a service requiring constraintson delay and jitter as well as minimum bit rate. Support for PFCs requesting streaming trafficclass can be enabled/disabled using the streaming_enabled BSS parameter. If support forstreaming traffic class is disabled, the BSS tries to admit the streaming traffic classes as oneof the matching interactive traffic classes (determined based on the MTBR settings, detailsdefined in the GSR8 QoS implementation).

Guaranteed Bit Rate as per the 3GPP specification is defined as the guaranteed number of bitsdelivered at an SAP within a period (if there is data to deliver), divided by the duration ofthe period. For the GPRS RAN, the guaranteed bit rate is defined as the bit rate at the LLClayer. QoS introduced the internal BSS concept of an MTBR (Minimum Throughput BudgetRequirement) associated with each PFC. The Guaranteed Bit Rate for each PFC is an extensionof 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 GBRmeasurements exclude any RLC retransmissions.

Transfer Delay (definition as per 23.107) indicates maximum delay for 95th percentile of thedistribution of delay for all delivered SDUs during the lifetime of a bearer service, where delayfor an SDU is defined as the time from a request to transfer an SDU at one SAP to its deliveryat 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 transferdelay for Radio Access Bearer can be smaller than the overall requested transfer delay, astransport through the core network uses a part of the acceptable delay. Transfer delay as allother 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 thesame TBF over the air interface to transfer data for the PFCs. LLC scheduling within the TBFis enhanced, and real-time service is prioritized appropriately over the non real-time serviceswhere 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

System Information: BSS Equipment Planning Increased Network Capacity (Huge BSC)

Maximum Bit Rate enforcement allows the BSS to throttle the throughput of the user to themaximum bit - rate stated in the QoS parameters (ABQP) even if there is capacity to providethe user a higher throughput. The main purpose of the maximum bit rate enforcement from auser’s perspective is to limit the delivered bit rate to the applications or external networks andto allow maximum required or permitted bit rate to be defined for applications able to operatewith 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, ifstream_downgrade_enabled is disabled and the idle resource is not enough, RT service isrejected.

Increased Network Capacity (Huge BSC)

The optional feature, Increased Network Capacity enhances the network capacity and supportsdatabase 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 from27 to 42.

This feature has an impact on the collection and dispatch of the additional statistics due to theincreased number of managed objects. The upload and collection of statistics to the OMC takesplace 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 retainhardware changes of the CTU2. The BSS software and Horizon II firmware allow each CTU2to be able to switch rapidly between Double Density modulation (GMSK) and Single Densitymodulation (8-PSK). The power output is not affected for GMSK and 8-PSK. Thus, the EGPRSPDTCH can only be configured on Carrier A of DD CTU2 while the corresponding timeslots onthe paired Carrier B have to be blanked out. Although the feature of ITS does not double thevoice capacity per CTU2, compared with EGPRS on single Density Mode CTU2, it offers morechannels to service voice users with EGPRS service in parallel.

68P02900W21-T 1-23

Jul 2010

Enhanced BSC capacity using DSW2 Chapter 1: Introduction to planning

Enhanced BSC capacity using DSW2

This feature expands (double) the TDM timeslots in the BSC from 1024 TSs to 2048 TSs in oneswitch cage using bank 0/1 extension mode. When this switch cage has one or more extensioncages, the switch cage uses 1024 TSs (BANK0), and other extension cages share the rest of the1024 TSs (BANK1). When up to 4 switch cages are configured, the maximum capacity is 8192 x64 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 BSCconfigurations by increasing the capacity of MTL from 64 k to 2M. The BSC supports HighSpeed MTL (HSP MTL) link utilization to a maximum of 13%. This feature utilizes and needs theGPROC3-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 capabilityfor high-capacity operations. The U-DPROC2 is configured as a PXP, which combines thefunctionality of the PICP and PRP on the same board. The PXP is connected to the PSI2 board inthe 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 interfacefrom the card is a 1000BASE-T over four pairs of copper wire. This connection can also beoperated in 100BASE-TX mode of operation, utilizing two pairs of copper wire. The standardbackplane 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 topof the BSC cabinet allows a single RJ45 Ethernet connection instead of two span lines for oneof the supported MSI positions. This link is referred as the Ethernet Link unless it is requiredto specify 100BASE-TX or 1000BASE-T modes of operation.

CTU2–D

The CTU2-D radios support both SD and DD EDGE architectures in addition to the variousmodes supported by the existing CTU2 radios. The previous CTU-2 Carrier A/B definitions andnomenclature also apply to the CTU2D. The following EDGE modes are supported:

1-24 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning CTU2–D

• CTU2–D SD

This mode is identical in operation to the existing CTU2 SD and is only included forreference.

• CTU2–D PWR

This mode is also known as ITS Mode whereby the CTU2 and CTU2-D operations areidentical. Of the two carriers, if the TS on carrier A is supporting an EDGE TS, then thecorresponding TS on carrier B is blanked, that is, it does not support anything. The CarrierB TS is capable of supporting only TCH or GPRS PDs while the corresponding TS oncarrier A does not have an EDGE TS. The maximum output power of both carriers whetherin GMSK or 8-PSK mode is 20 W* as shown in Figure 1-3.

Figure 1-3 CTU2–D PWR

ti-GSM-CTU2D_PWR-00002-ai-sw

E E

X T/G

A

B

DD 20 W

CTU2D PWR/CTU2 ITS

E E T T T T

X X X T/G T/G T/G

• 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 is10 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

ti-GSM-CTU2D_CAP-00003-ai-sw

E

T/G

A

B T/G T/GT/GT/GT/GNo E

T/GCTU2D CAPDD 10 Wor T or G

T/G

E EE E E E E

68P02900W21-T 1-25

Jul 2010

96 MSIs Chapter 1: Introduction to planning

• CTU2D ASYM

Of the two carriers, carrier A is fully EDGE-capable, while carrier B supports EDGE onthe DL and GMSK (EDGE) on the UL. The maximum output power of carrier A in 8-PSKmode is 10 W* and GMSK mode is 20 W*. The maximum output power of carrier B inGMSK mode is 20 W* as shown in Figure 1-5.

Figure 1-5 CTU2D ASYM

EA

B

CTU2D ASYMDD 10 Wor T or G

E EE E E E E

E E E E E E E E

or T or G

All PDCHs on this carrier do not support 8 PSK in UL (aka are GMSK restriction)

NOTEThe output powers listed are for 900 MHz frequency. For all other frequencies, theoutput power varies.

96 MSIs

This feature expands the number of MSIs supported from 56 to 96 and allows for additional E1sbetween 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 perBSC 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-serviceuntil the full enhanced capacity mode is re-enabled.

The OML controls the BSC in OMC side. An algorithm configures the MSI with theOML with priority in the database to ensure the availability of MSI in either singlerate or enhanced capacity mode.

Support usage of idle TCH for burst packet traffic

This feature provides a mechanism which allocates additional switchable PDTCH resource whenthere is GPRS traffic congestion in this cell, and returns these PDTCH resources back to TCHresources when GPRS traffic congestion is relieved. The additional switchable PDTCH resourcesin this feature are defaulted as TCH resources which have no impact to normal voice call, andis converted to switchable PDTCH when GPRS is congested.

1-26 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 thefeature 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 congestedin the cell level and the feature is enabled. These additional channels are configured asswitchable PDTCH which share the PCU resource in GPRS congestion status, but areconfigured as TCH resource when GPRS congestion is relieved. The PCU processingcapability has to be planned considering these additional timeslots may be processedduring 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 congestedin the cell level and the feature is enabled. The additional switchable PDTCH during GPRScongestion uses the additional GDS TRAU resources. The additional 64 k PDTCH sharesthe RTF backhaul with the existing 64 k PDTCHs. Therefore, the additional GDS resourceand 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 specialrequirements 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 insparsely populated areas. A normal GSM/ GPRS cell covers a radius of 35 km. An extendedrange GSM cell can cover up to 121 km radius. In the normal range, the maximum timingadvance value of an MS can only go up to 63 bits. To accommodate the additional propagationdelay in the extended range, an extended range timeslot needs to support a timing advancevalue of up to 219 bits. An extended range timeslot is created by coupling two regular TDMAtimeslots to support the extended timing advance, see Figure 1-6. Only the even-numberedtimeslot in an extended range pair is operational over the air.

68P02900W21-T 1-27

Jul 2010

Horizon II Site Controller-2 Chapter 1: Introduction to planning

Figure 1-6 Normal and extended range timeslots

0 1 2 3

N ormal range

0 1 2 3

E xtended R ange

TD MA Frame w ith normal tim ing advance range

TD MA Frame w ith extended range tim ing advance

4 5 6 7

4 5 6 7

ti-GSM-TD MA frame_normal_extented_tim ing 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, theGPRS/EGPRS channel type (that is, PDCH) can also be supported on extended timeslots of CTU2and CTU2D radios. Extended timeslots can also be supported on a 64 k carrier, besides theoriginal 16 k/32k carrier. Extended PDCH can only be configured on one carrier per cell. An MSin the extended range can only be allocated on an extended PDCH, while an MS in the normalrange 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 functionsoffered by the Horizon II SC. The HIISC-2 uses a hardware architecture that is more powerful interms of available memory, raw MIPS, and flexibility, which supports more aggressive call loads.

1-28 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning CTU8m and RCTU8m feature

Planning impact

Updated information is available in the following chapters:

• Chapter 1 Introduction to planning

• Chapter 5 BTS planning steps and rules

• Chapter 6 BSC planning steps and rules

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 .

CTU8m and RCTU8m feature

{34371G}

The new Horizon II BBU (R)CTU8m radio platform radically changes the traditional architectureof Motorola GSM BTS product by separating the baseband and RF functionalities. The basebandand RF functionalities are combined on traditional radio units, across a new dedicated basebandunit (BBU) processing board and an in-cabinet (CTU8m) and out-of-cabinet ((R)CTU8m) variantsof RF units.

The GSM BBU module is a mezzanine baseband processing card attached to the Horizon II SiteController 2 (forming the BBU-E) within the GSM Horizon-II BTS family. It is responsible formost digital baseband processing for multiple radio units (for example, channel coding/decoding,filtering, demodulation, equalization, modem control loops, and so on), and the RadioSub-System (RSS). The RF unit deals with all the remaining radio functionalities between the RFside input/output of a CTU-type radio and the over-sampled digital interface to the BBU. Thisfunctionality 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 RFsolutions 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 andSite Controller) card as a whole. Figure 1-7 shows the architecture diagram of (R)CTU8m.

68P02900W21-T 1-29

Jul 2010

CTU8m and RCTU8m feature Chapter 1: Introduction to planning

Figure 1-7 Architecture diagram of (R)CTU8m

Ala

rm B

oar

d

Fans

PSU

Site Exp.

BBU BBU CTU2D CTU8m CTU8m CTU8m CTU2D CTU2D

PSU

PSU

Circuit Breakers

PSU Site Exp.

E1Site IO

RCTU8m RCTU8mRCTU8m

RCTU8m RCTU8m

Horizon II Cabinet

D4+ Links

D4+ Links

RF Modules

ti-GSM-Architecture diagram (R)CTU4-00003.a-ai-sw

The features are:

• 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).

1-30 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning CTU8m and RCTU8m 8 carrier support

Planning impact

Updated information is available in the following chapters:

• Chapter 1 Introduction to planning

• Chapter 3 BSS cell planning

• Chapter 5 BTS planning steps and rules

• Chapter 8 BSS planning for GPRS/EGPRS

Key planning impacts and feature constraints are:

• 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 and1800 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. Upto eight carriers are supported in both the in-cabinet and remote radio units operating in the900MHz and 1800MHz bands.

Planning impact

Updated information is available in the following chapters:

• Chapter 1 Introduction to planning

• Chapter 5 BTS planning steps and rules

Key planning impact and feature constraint is

BSC capacity limits increased

NOTEThe 7 or 8 carriers per each (R)CUT4 radio can only be deployed in countriesaccepting 3GPP multicarrier class 2 specifications (3GPP TS 45.008).

68P02900W21-T 1-31

Jul 2010

Increase RSL-LCF capacity on GPROC3/GPROC3-2 Chapter 1: Introduction to planning

Increase RSL-LCF capacity on GPROC3/GPROC3-2

{34282}

This feature increases the capacity of LCFs on GPROC3 and GPROC3-2 boards that aresupporting RSLs and can be used to reduce the number of LCFs required for RSL processing. Areduction in the number of LCFs required for RSL processing frees capacity at the BSC whichcan be used to provide TDM timeslots for other devices at the BSC, or to support an increasedcall load. The feature impacts planning for LCF GPROCs for RSL processing as the GPROC typehas to be considered due to different capabilities of GPROC2 and GPROC3/GPROC3-2 boards.

Planning impact

Updated information is available in the following chapters:

• Chapter 1 Introduction to planning

• Chapter 6 BSC planning steps and rules

• Chapter 9 Planning examples

Key planning impacts and feature constraints are:

• GPROC3/GPRC3-2 capacity impact

• Number of LCF GPROC calculation

NOTEIt is recommended that all the pool GPROCs are GPROC3/GPROC3-2 when the LCFssupporting RSLs have been planned based on the capabilities of GPROC3/GPROC3-2.If BSC configurations have mixture of GPROCs which include GPROC2s, there willbe 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 backhauloptions than E1. This would provide an alternative connection to the current E1 using framerelay.

The option of supporting Gb interfaces over IP backhaul provides a lower cost (OPEX andCAPEX) alternative to using Frame Relay over E1 for the Gb links. This also has the additionalbenefits of an IP-based network such as flexibility, more standardization, better productpositioning, 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 anEthernet interface on front panel that is necessary to support IP.

1-32 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 Gbover IP and GDS/GSL over IP traffic simultaneously. Such PXPs require two Ethernet ports. OneEthernet port is physically used to transport Gb traffic and the other Ethernet port is physicallyused to transport GDS/GSL traffic. The GDS Ethernet link between a PXP to a PSI in the BSC ispoint to point. The PPROC mounted on these PXPs is capable of processing both GDS and Gbtraffic 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 theoperators IP backbone which provides the necessary telecom security and QoS environment, forexample, VPN, IPSec, access control, attack protection, QoS networking.

Planning impact

Updated information is available in the following chapters:

• Chapter 1 Introduction to planning

• Chapter 2 Transmission systems

• Chapter 8 BSS planning for GPRS/EGPRS

Key planning impacts and feature constraint is

Number of Ethernet GBL link calculation

NOTEThe Ethernet GBL is supported only on the PXP U-DPROC2 board, and is thereforenot supported on the PICP and PRP boards. The Gb over IP feature is thereforedependant 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 trafficallocation algorithm identifies the power-saving capabilities of different radios and concentratestraffic on those that cannot be turned into sleep mode, so that the remaining radios in the BTScan 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-allocatingtraffic 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 Chapter 1: Introduction to planning

Planning impact

Updated information is available in the following chapters:

• Chapter 1 Introduction to planning

• Chapter 3 BSS cell planning

• Chapter 5 BTS planning steps and rules

Key planning impacts and feature constraint is

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/and8PSK modulation (including half rate, full rate, GPRS and EDGE carriers).

Updated Chapters

• Chapter 5: BTS planning steps and rules

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-Esand 6 (R)CTU8m is configurated, the maximum RF carriers per site is supported up to 36.

Updated chapters

• Chapter 1: Introduction to planning

• Chapter 5: BTS planning steps and rules

• Chapter 6: BSC Planning Steps and Rules

Key EPG impact and feature constraints

• BTS planning impact

• GPROC planning impact

1-34 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Increased Network Capacity (1000TRX BSC) enhancement

Increased Network Capacity (1000TRX BSC) enhancement

GSR10 supports 1000TRX per BSC with the Increased Network Capacity (Huge BSC) featureenabled. It requires that all the GPROCs in the BSC are GPROC3 or GPROC3-2.

Planning impact

Updated information is available in the following chapters:

• Chapter 6 BSC planning steps and rules

• Chapter 7 RXCDR planning steps and rules

Key planning impacts and feature constraint is

BSC capacity limits increased

NOTEThe E1 limitation (up to 192 E1s in total in BSC) may be reached before the numberof carriers limit is reached in some situations. Methods of reducing the requiredE1 resource on BSC are:

• Upgrade from PCU to ePCU feature, which replaces E1 links with Ethernet linkssaving a number of BSC E1 ports (MSI slots).

• Applying daisy chaining and/or applying half rate Ater channels based on callmodel 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 downlinkair timeslots, and extension of the EDMAC feature increases uplink throughput of a mobile.

Planning impact

Updated information is available in the following chapters:

• Chapter 1 Introduction to planning

• Chapter 3 BSS cell planning

• Chapter 8 BSS planning for GPRS/EGPRS

Key planning impacts and feature constraint is

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 Chapter 1: Introduction to planning

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 processingfunctions offered by the H2SC, using a hardware architecture that is significantly morepowerful in terms of available memory, raw MIPs, and flexibility, enabling it to support moreaggressive call loads.

1-36 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 Chapter 1: Introduction to planning

eMLPP impact on BSS equipment and capacity calculations

With eMLPP feature, preferential service is provided for higher priority calls by preempting theresource from lower priority calls when the system is under congestion. When planning radioand terrestrial resources, the adequate resources require to be planned by treating all callsequal without considering preemption. That is, BSS planning focuses on providing planningsteps and rules under normal traffic load without congestion, with certain capacity marginplanned 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 equipmentcalculation 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, ErlangB 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.

• Diversity requirement. Diversity doubles the number of Rx antennas and associatedequipment.

1-38 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning methodology

• Redundancy level requirements (determined for each item).

• Supply voltage.

Planning methodology

A GSM digital cellular system consists of several BSSs. The planning cycle begins with definingthe 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 satisfiestraffic, interference, and growth requirements.

• Plan all the BTS sites as follows:

Use an appropriate RF planning tool to determine the geographical location of sitesand 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 subsequenthardware implementation.

• Plan the Packet Control Unit (PCU) for the desired packet data capacity for the system.

68P02900W21-T 1-39

Jul 2010

Acronyms Chapter 1: Introduction to planning

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 Busy hour call attempts

BIB 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

System Information: BSS Equipment Planning 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) BSSGP virtual circuit (identifier)

C/I 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 CTU2D double density asymmetric mode

{34371G}CTU8m Compact transceiver unit 4

{34371G}D4+ The Motorola defined fiber link standard

DARBC Dynamic allocation of RXCDR to BSC circuits

dB Decibel

DCD Duty Cycle Distortion

DCF Duplexed combining bandpass filter

Continued

68P02900W21-T 1-41

Jul 2010

Acronym list Chapter 1: Introduction to planning

Table 1-2 Acronym list (Continued)

Acronym Meaning

DDF Dual stage duplexed combining filter

DCS Digital cellular system

DECT Digital enhanced cordless telephony

DD 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 Diversity radio control unit

DRI Digital radio interface

DRIM 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 Dynamic network

e Erlang

E1 32 channel 2.048 Mbps span line

EAC Enhanced auto-connect

EDGE Enhanced data rates for global evolution

EDMAC Enhanced Dynamic Allocation Medium Access Mode

EFR Enhanced full rate

EGDP Enhanced generic digital processor

EGPRS Enhanced-GPRS

EGSM Enhanced global system for mobile communication

ELM EGSM layer management

E-OTD Enhanced observed time difference

Continued

1-42 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Acronym list

Table 1-2 Acronym list (Continued)

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 Fiber optic multiplexer (Horizonmacro)

FN Frame number

FOX 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) Gb link

GCLK Generic clock

GDP(2) Generic digital processor (2)

GDS GPRS data stream

GGSN Gateway GPRS support node

GMLC Gateway mobile location centre

GMM GPRS mobility management

GMSK Gaussian minimum shift keying

GOS Grade of service

GPROC(n) 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 Chapter 1: Introduction to planning

Table 1-2 Acronym list (Continued)

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) Kiloport switch (extender)

LA Link adaptation

LAC 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

System Information: BSS Equipment Planning Acronym list

Table 1-2 Acronym list (Continued)

Acronym Meaning

MAC Medium access control

MAP Mobile application part

MBR Maximum bit rate

MCAP Motorola cellular advanced processor bus

MCBTS Multi-Carrier Base Transceiver Station

{34371G}MCPA Multi-carrier power amplifier

MCU Main control unit

MCUF Main control unit with dual FMUX

MIB Management information base

MLC Mobile location centre

MMI Man machine interface

MPROC Master processor

MS Mobile station

MSC Mobile switching centre

MSI (-2) Multiple serial interface (2)

MTBR 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 Chapter 1: Introduction to planning

Table 1-2 Acronym list (Continued)

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 Packet broadcast control channel

PBIB Packet BIB

PCCCH Packet common control channel

PCH Paging channel

PCI Peripheral component interconnect

PCM Pulse code modulation

PCMCIA 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

System Information: BSS Equipment Planning Acronym list

Table 1-2 Acronym list (Continued)

Acronym Meaning

PSTN 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 Remote compact transceiver unit 4

RDB 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) Receive

RXCDR Remote transcoder

RXU Remote transcoder unit

SACCH Slow access control channel

SB Stealing bit

{33254}SC-2 Horizon II site controller-2

SCC 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 Chapter 1: Introduction to planning

Table 1-2 Acronym list (Continued)

Acronym Meaning

SCU Slim channel unit

SD Single Density

SDCCH 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 Serving mobile location centre

SMS Short message service

SNDCP Sub network dependent convergence protocol

SS7 CCITT signaling system number 7

STNNT Short-term non-negotiated traffic

STP Shielded twisted pair

SURF Sectorized universal receiver front end (Horizonmacro)

SURF2 Sectorized universal receiver front end 2 (Horizon II macro)

TBF Temporary block flow

TCCH 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 Transcoder rate adaptation unit

TS Timeslot

TSW Timeslot switch

TX (or Tx) Transmit

U-DPROC2 Universal DPROC2

UE User equipment

UL Uplink

Continued

1-48 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Acronym list

Table 1-2 Acronym list (Continued)

Acronym Meaning

UMTS Universal mobile telecommunication system

USF Uplink state flag

UTP Unshielded twisted pair

UTRAN UMTS radio access network

VersaTRAU 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)

68P02900W21-T 1-49

Jul 2010

Acronym list Chapter 1: Introduction to planning

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 2-1

Jul 2010

BSS interfaces Chapter 2: Transmission systems

BSS interfaces■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

Figure 2-1 and Table 2-1 indicate the type of interface, rates, and transmission systems used toconvey information around the various parts of the BSS system.

Figure 2-1 BSS interfaces

OMC-R

OMLX.25(LAPB)

Gb OPTION B

MSC

Air interface Abis interface A interfaceMS (LAPDm) BTS

RSL (LAPD)BSC

MTL (C7), XBL(LAPD)OML (X.25)

RXCDRSGSN

GDS

Gb OPTION A

PCUGb OPTION C

CBLX.25(LAPB)

CBC

ti-GSM-BSS_interfaces-00005-ai-sw

Gb OPTION D(Ethernet/IP)

Table 2-1 BSS interface

Interface From/To Signaling by Rate Using

Air MS - BTS RACH, SDCCH,SACCH, FACCH

LAPDm

E1links

Abis (Mobis) BTS - BSC RSL 16/64 kbps LAPD

Continued

2-2 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Introduction

Table 2-1 BSS interface (Continued)

Interface From/To Signaling by Rate Using

A BSS - MSC MTL (OML, CBL) 64 kbps or2048 kbps*

C7

A 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/1000MEthernet**

Frame Relay orEthernet

GDS PCU - BSC GSL 64 kbps LAPD

NOTE

• * The HSP MTL feature enables BSS support of 2048 kbps high speed signalinglink, that is, a whole E1 signaling link.

• **The Gb over IP feature allows the choice of the Gb interface as either framerelay E1 or 100M/1000M Ethernet. The Gb over IP feature only applies forOption C as shown in Figure 2-1

68P02900W21-T 2-3

Jul 2010

Interconnecting the BSC and BTSs Chapter 2: Transmission systems

Interconnecting the BSC and BTSs■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

Network topology is specified in terms of the paths between the BSC and the BTS sites. Apath is determined by E1 circuits, and possible intervening BTS sites are used to provide theconnection. Transcoding is performed at the BSC or RXCDR.

Interconnection rules

The following rules must be observed while interconnecting a BSC and BTSs:

• The BSC shares MSI boards between BTSs. When there are two or more E1 circuits, atleast 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 configuredas half rate capable, which means it can support AMR half rate and/or GSM half rate. Oncean RTF is configured as AMR half rate capable, and if AMR half rate is enabled, the 7.95kbps half rate codec mode is included in the Half Rate Active Codec Set or (for either AMRhalf rate or GSM half rate), 8 kbps subrate switching is not available. For example, if 16kbps is used for the backhaul, then the carrier unit assigned to that RTF needs four 64kbps timeslots on the E1 circuit (Refer to the NOTE).

• In a redundant connection, each carrier unit needs two 64 kbps timeslots on two differentE1 circuits. If the half rate exception case applies four 64 kbps timeslots are required. TheAMR half rate exception case is defined as - A carrier which is assigned an RTF configuredas (AMR or GSM) half rate capable, and 8 kbps subrate switching is not available (forexample, 16 kbps is used for the backhaul), or (for AMR) the 7.95 kbps half rate codecmode 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 aclosed loop daisy chain, two E1 circuits are required. To provide redundancy, the two E1circuits must be terminated on different MSIs.

• In a closed loop daisy chain, the primary RSLs for all BTS sites are routed in the samedirection with the secondary RSLs routed in the opposite direction. The primary RSLat each BTS site in the daisy chain is always equipped on the multiple serial interfacelink (MMS) equipped in CAGE 15, slot 16, port A. The secondary RSL at each BTS site isequipped 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.

2-4 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Interconnection rules

NOTEWhen discussing the BSC or RXCDR, cage is a term previously used in BSScommands that is replaced by shelf in this manual. That is, cage and shelfmean the same thing.

• Additional backhaul bandwidth is required to support GPRS traffic using CS3/CS4 codingschemes. Each timeslot, on a CS3/CS4 capable carrier, needs 32 kbps for a total of four 64kbps timeslots on the E1 circuit, irrespective of the speech coding.

• Additional backhaul bandwidth is required to support EGPRS traffic using MCS1-MCS9coding schemes. Each non-signaling timeslot, shares the Versachannel backhaul associatedwith the particular carrier. Backhaul is provisioned based on expected EGPRS usage andrecommendation in Table 8-1 of Chapter 8 BSS planning for GPRS/EGPRS. Versachannelis defined as the portion of the RTF backhaul that is used to carry the data for the airtimeslots 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 Chapter 2: Transmission systems

Network topology■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The operator can specify the traffic that is to use a specific path. A direct route between anytwo adjacent sites in a network can consist of one or more E1 circuits. Figure 2-2 shows apossible network topology.

Figure 2-2 Possible network topology

BSC

BTS 2

BTS 3

BTS 4

BTS 10

BTS 11

BTS 5

BTS 6

BTS 7 BTS 9

BTS 8

BTS 1

ti-GSM-Network_topologies-00006-ai-sw

Each BTS site in the network must obey the following maximum restrictions:

• 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/HIISC2-E/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).

2-6 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Star connection

An alternative path is reserved for voice/data traffic in the case of path failure. This is knownas 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 arerequired, and the signaling is load shared over these links. If a path fails, the traffic can bererouted, 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, asshown in Figure 2-3.

Figure 2-3 Star connection

BTS 1

BTS 2BTS 3

BTS 4

BTS 5

BTS 9

BTS 7

BTS 8

MSC

BSC

ti-GSM-Star_connection-00007-ai-sw

A star connection requires more MSI cards at the BSC than daisy chaining, for the same numberof BTS sites. The star connection allows for a greater number of carrier units per BTS site. AnE1 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 thesecarriers if VersaTRAU is enabled) or

• Some proportionate mix of GSM, GPRS, and EGPRS

68P02900W21-T 2-7

Jul 2010

Daisy chain connection Chapter 2: Transmission systems

NOTE

• The number of carriers on an E1 circuit is reduced by 1 for each carrier to whichthe half rate exception case applies.

• The half rate exception case is defined in the section Interconnecting the BSCand BTSs on page 2-4.

Daisy chain connection

Daisy chaining multiple BTS sites together can better utilize the 64 kbps timeslots of one E1circuit from the BSC. Daisy chaining the sites together provides for the efficient utilization ofthe 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

ti-GSM-Closed_loop_open_ended_daisy_chain-00008-ai-sw

BTS 1

BTS 2

BTS 3BTS 4

BTS 5

BTS 9BTS 7

BTS 8

MSC

BSC

BTS 10

BTS 6

BTS 11

BRANCH OF THE DAISY CHAIN

DAISY CHAIN CLOSED LOOP

DAISY CHAIN CLOSED LOOP

SINGLE MEMBER DAISY CHAIN, A STAR

The closed loop version provides for redundancy while the open ended version does not.

NOTELonger 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 networktopology. Since the network can contain multiple E1 circuits, branches, multiple paths over thesame E1 circuit, and closed loop interconnections, each E1 circuit is planned individually.

2-8 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Daisy chain planning

Simple daisy chain

A daisy chain without branches and with a single E1 circuit between each of the BTSs isreferred to as a simple daisy chain. The maximum capacity supported in this connection islimited by the capacity of the connection between the BSC and the first BTS in the chain. Asimple daisy chain is shown in Figure 2-5.

Figure 2-5 Simple daisy chain

ti-GSM-Simple_daisy_chain-00009-ai-sw

BSC BTS 1 BTS 2

BTS 3 BTS 4

RxTx

Rx

Tx Rx

RxTx

TxRx TxRxRx

Tx

TxRx

BTS X

RxTx

TxRx

USED IN CLOSED LOOP CONNECTION ONLY

Tx

The capacity of a closed loop single E1 circuit daisy chain is the same as a daisy chain. Theclosed loop daisy chain has redundant signaling links for each BTS, although they transverse thechain in opposite directions back to the BSC.

The following equation determines the number of E1s required for a daisy chain:

NBSC−BTS =

[(nEGPRS∑i=0

RTF−DSO−COUNTi

)+ (nCGPRS ∗ 4) + (nTGPRS ∗ 2) + TAHRE ∗ 4

]+ b

31

Where: Is:

NBSC−BTS minimum number of E1 links required (rounded up to an integer).

nEGPRS total number of carriers in the daisy chain with EGPRS enabled.

nCGPRS total number of carriers in the daisy chain with GPRS CS3 and CS4enabled.

nTGPRS total number of carriers in the daisy chain with GPRS CS1 and CS2enabled, and GSM voice only carriers, where the half rate exceptioncase does not apply.

RTF−DSO−COUNTi value of rtf_ds0_count for the RTF.

nTAHRE total number of GSM voice only carriers in the daisy chain wherethe half rate exception applies.

b number of BTS sites in the chain.

68P02900W21-T 2-9

Jul 2010

Aggregate Abis Chapter 2: Transmission systems

Example

Consider a daisy chain with three BTSs, each with 1 GSM voice carrier, 1 CS3/4 enabled carrierand 1 EGPRS enabled carrier for which the half rate exception case does not apply. The numberof E1s required (assuming VersaTRAU is restricted - RTF_DS0_COUNT = 8 for each EGPRS RTFand all EGPRS RTFs are non-BCCH) is shown:

[(3 ∗ 8) + (3 ∗ 4) + (3 ∗ 2) + (0 ∗ 4) + 3]31

= 1.45E1s

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 thelinks between the BSC and the site from which the branch originates, as these are used for thepath to the branched site.

Figure 2-6 Daisy chain with branch

ti-GSM-Daisy_chain_with_branch-00010-ai-sw

BSC BTS 1 BTS 2

BTS 3 BTS 4

RxTx

Rx

Tx Rx

RxTx

TxRx TxRxRx

Tx

TxRx

BTS X

RxTx

TxRx

USED IN CLOSED LOOP CONNECTION ONLY

Tx

BTS YRx

Tx

A branch can have multiple BTS sites on it. A branch can be closed, in which case there areredundant signaling links on different E1 circuits. In a closed loop, which needs redundantsignaling links for each BTS site, with an open branch, the E1 circuit to the branch has to carryredundant signaling links.

Aggregate Abis

This is an option designed to allow greater flexibility while planning the network. It can alsohelp reduce leasing costs of E1 links by optimizing link usage over the greatest distancebetween a BSC and a BTS.

2-10 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Aggregate Abis

This is achieved by the introduction of third-party multiplexer equipment enabled by Motorolasoftware. This equipment allows timeslots on one E1 link to be multiplexed to more than oneBTS. Therefore, if the situation arises where several single carrier BTSs each need their owndedicated 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 ispossible to initially send all the traffic channels for every site over one E1 link to the third-partymultiplexer 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 insignificant leasing cost savings compared to the original configuration. There are two diagramsillustrating 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 USED26x64 kbit/s TIMESLOTS UNUSED

BTS

TWO CARRIER ONE RSL

BTS

TWO CARRIER ONE RSL

BTS

TWO CARRIER ONE RSL

5x64 kbit/s TIMESLOTS USED26x64 kbit/s TIMESLOTS UNUSED

5x64 kbit/s TIMESLOTS USED26x64 kbit/s TIMESLOTS UNUSED

ti-GSM-Low_capacity_BSC/BTS_configuration-00011-ai-sw

68P02900W21-T 2-11

Jul 2010

Aggregate Abis Chapter 2: Transmission systems

Figure 2-8 Example using a switching network

ti-GSM-switching_network-00012-ai-sw

BSC

5x64 kbit/s TIMESLOTS USED26x64 kbit/s TIMESLOTS UNUSED

BTS

TWO CARRIER ONE RSL

BTS

TWO CARRIER ONE RSL

BTS

TWO CARRIER ONE RSL

20x64 kbit/s TIMESLOTS USED11x64 kbit/s TIMESLOTS UNUSED

5x64 kbit/s TIMESLOTS USED26x64 kbit/s TIMESLOTS UNUSED

E1 MULTIPLEXER

10x64 kbit/s TIMESLOTS USED21x64 kbit/s TIMESLOTS UNUSED

BTS

TWO CARRIER ONE RSL

5x64 kbit/s TIMESLOTS USED26x64 kbit/s TIMESLOTS UNUSED

MORE EFFICIENT USE OF LONGEST E1 LINK

Another advantage of introducing the multiplexer is the improvement in the timeslot mappingonto the Abis interface.

Currently they are allocated from timeslot 1 upwards for RSLs and timeslot 31 downwards forRTF traffic channels. Most link providers lease timeslots in contiguous blocks (that is, there areno gaps between timeslots). Under the existing timeslot allocation scheme this often meansleasing a whole E1 link for a few timeslots. There is a new algorithm for allocating timeslotson the Abis interface. This is only used on the links that are directly connected to the newaggregate 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 andthe RTF timeslots next, with each site being equipped consecutively, thus allowing contiguousblocks of timeslots to be leased.

It is important that the sites are equipped in the order that they are presented. Also, RSLsmust be equipped first on a per site basis to coincide with the default timeslots for softwaredownloads to the BTSs. Figure 2-9 is an example of timeslot allocation in a network using anaggregate service, with links to the aggregate service and links bypassing it.

NOTEWhile it is possible to equip Horizon II macro BTSs supporting either theHIISC2-S/E or BBU-E, with up to 12 RSLs, there are certain non-standard RSL PATHconfigurations (the default RSL timeslots are not configured as RSL) that couldlead to only ten of these 12 RSLs being available (that is, enter the B-U state) forcodeloading to the BTS. Once the codeloading is complete, the remaining two RSLswill be INS for normal Mobis signaling traffic. It is recommended to configure all thethree 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

System Information: BSS Equipment Planning Aggregate Abis

Figure 2-9 Timeslot allocation using new and old algorithms

ti-GSM-Timeslot_allocation-00013-ai-sw

BSC

BTS 2

ORIGINAL ALGORITHM

BTS 3

NEW ALGORITHM

BTS 1

TWO CARRIER ONE RSL

E1 MULTIPLEXER

BTS 4

ALLOCATION UNAFFECTED

ORIGINAL ALGORITHM

ALLOCATION UNAFFECTED

NEW ALGORITHM12345

RSL1RTF1RTF1RTF2RTF2

1112131415

RSL3RTF5RTF5RTF6RTF6

6789

10

RSL2RTF3RTF3RTF4RTF4

1617181920

RSL4RTF7RTF7RTF8RTF8

ALLOCATION AFFECTED

NEW ALGORITHM

ALLOCATION AFFECTED

ALLOCATION AFFECTED

12345

RSL1RTF1RTF1RTF2RTF2 1

2345

RSL2RTF3RTF3RTF4RTF4

131302928

RSL3RTF5RTF5RTF6RTF6

12345

RSL3RTF5RTF5RTF6RTF6

678910

RSL4RTF7RTF7RTF8RTF8

131302928

RSL4RTF7RTF7RTF8RTF8

ALLOCATION AFFECTED

NEW ALGORITHM

Similar problems are encountered while equipping redundant RSL devices onto paths containingaggregate services. The new method of allocating timeslots when connecting to an aggregateservice is from timeslot 1 upwards, so it is not possible to reserve the default download RSLtimeslot. This gives rise to a situation where the default RSL timeslot is already allocated toanother device, for example RTF.

To avoid this situation, the primary and redundant RSLs can be equipped first (in an order thatresults in the correct allocation of default RSL timeslots), or reserve the default download RSLtimeslot 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 thelinks, it is possible to reserve the timeslots required for the expansion so that they can bemade 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 athird-party switching network and is taken out-of-service, the BTS reports the local alarm, butthe 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 theRSL to go out-of-service with no link alarms generated by GSM network entities (BTS, BSC). Inthese cases, it is the responsibility of the third-party aggregate service provider to inform theusers 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 Chapter 2: Transmission systems

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

BTS

E1 MULTIPLEXER

E1 MULTIPLEXER

E1

BTS BTS

BTS BTS

BTS BTS

BTS BTS

MULTIPLEXER

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 pseudosite, the aggregate service is counted as a site in the path. Hence, the number of BTSs that canbe present in a path is reduced from ten to nine.

GCLK synchronization functions, but any BTS sites connected downlink from a switchingnetwork synchronizes to it and not to the uplink GSM network entity (BTS, BSC).

2-14 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning RTF path fault containment

RTF path fault containment

Each transceiver at a BTS needs a receive/transmit function to be enabled which notifies thetransceiver 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 halfrate exception case) 64 kbps timeslots, assigned to the transceiver from the E1 link, take toget 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 pathsto one RTF fail, the entire cell is taken out of call processing, regardless of whether there areother 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 theprevious paragraphs. If there are available timeslots, any call in progress on the failed path ishanded over to the remaining RTFs in the same cell. If timeslots are unavailable, the call isreleased. In addition, the timeslots on the transceiver of the failed path are barred from trafficuntil 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 thecell is barred from traffic.

Advantages

This feature reduces timeslot, and removes redundant paths, that are normally equipped tomanage path failure. Figure 2-11 shows the conventional redundant set-up, which needs fourextra 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 withreduced capacity. This configuration only needs four timeslots instead of eight, as requiredfor Figure 2-11.

NOTEDouble the number of timeslots required for RTFs to which the half rate exceptioncase applies.

If an RTF path fails, the cost saving advantages of the alternative configuration has to bebalanced against the reduced capacity.

68P02900W21-T 2-15

Jul 2010

RTF path fault containment Chapter 2: Transmission systems

Figure 2-11 A configuration with a BTS equipped with two redundant RTFs

ti-GSM-BTS_with_two_redundant_RTFs-00015-ai-sw

RTF1 EQUIPPED ON PATH 1

(2 TIMESLOTS)

RTF2 EQUIPPED ON PATH 1 (2 TIMESLOTS)

RTF2 EQUIPPED ON PATH 2 (2 TIMESLOTS)

RTF1 EQUIPPED ON PATH 2 (2 TIMESLOTS)

BTS 3 BTS 1

BSC

BTS 2

Figure 2-12 A configuration with a BTS equipped with two non-redundant RTFs

ti-GSM-BTS_with_two_non_redundant_RTFs-00016-ai-sw

RTF2 EQUIPPED ON PATH 1 (2 TIMESLOTS)

RTF1 EQUIPPED ON PATH 2 (2 TIMESLOTS)

BTS 3 BTS 1

BSC

BTS 2

2-16 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning RTF path fault containment

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 kbpstimeslots, one for the 64 kbps RSL and two for the 16 kbps traffic channels. The two 64 kbpstimeslots 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 kbpstimeslots. The reason being that, in the case of a single carrier site, the carrier is the BCCHcarrier 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 fromthe 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 isunused and is available to carry the signaling traffic. Therefore one 16 kbps subchannel remainsunused 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 subchannelbecause the RSL is not transmitting on the air interface. The advantage is that it frees up one 64kbps timeslot on the Abis interface, reducing the requirement to serve a single carrier system toonly 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 (8kbps switching is unavailable or the 7.95 codec rate for AMR is included in the half rate activecodec set for that cell), this feature reduces the number of required E1 64 kbps timeslots fromfive 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 ofRTF which are possible using the previously described options. They are listed in Table 2-2.

Table 2-2 RTF types

Type Options

1 A fully equipped BCCH RTF with an associated 16 kbps RSL.

2 A fully equipped BCCH RTF with no associated 16 kbps RSL.

3 A fully equipped non-BCCH RTF with an associated 16 kbps RSL.

4 A fully equipped non-BCCH RTF with no associated 16 kbps RSL.

5 A sub-equipped BCCH RTF with an associated 16 kbps RSL.

6 A sub-equipped BCCH RTF with no associated 16 kbps RSL.

7 A sub-equipped non-BCCH RTF with an associated 16 kbps RSL.

8 A sub-equipped non-BCCH RTF with no associated 16 kbps RSL.

68P02900W21-T 2-17

Jul 2010

RTF path fault containment Chapter 2: Transmission systems

Fully equipped RTF

Figure 2-13 Fully equipped RTF

ti-GSM-Fully_equipped_RTF-00017-ai-sw

NO ASSOCIATED 16 kbit/s RSL

ASSOCIATED 16 kbit/s RSL

NON-BCCH

FULLY EQUIPPED RTF

NO ASSOCIATED 16 kbit/s RSL

ASSOCIATED 16 kbit/s RSL

BCCH

Timeslot X

Timeslot Y

KEY

Configuration 1 2 3 4

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.

16 kbit/s BTS only

16 kbit/s BTS only

2-18 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning RTF path fault containment

Sub-equipped RTF

Figure 2-14 Sub-equipped RTF

ti-GSM-Sub_equipped_RTF-00018-ai-sw

NO ASSOCIATED 16 kbit/s RSL

ASSOCIATED 16 kbit/s RSL

NON-BCCH

SUB-EQUIPPED RTF

NO ASSOCIATED 16 kbit/s RSL

ASSOCIATED 16 kbit/s RSL

BCCH

Timeslot X

Timeslot Y

KEY

Configuration

16 kbit/s sub-channel used for 16 kbit/s RSL.

16 kbit/s sub-channel available for voice traffic.

16 kbit/s BTS only

16 kbit/s BTS only

5 6 7 8

68P02900W21-T 2-19

Jul 2010

16 kbps XBL Chapter 2: Transmission systems

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 16kbps 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 timeslotfor BSU-based sites.

• An associated 16 kbps RSL is supported on redundant RTF paths where one exists on theprimary path.

16 kbps XBL

The 16 kbps XBL provides a lower-cost solution by reducing the interconnect costs betweenan RXCDR and BSC.

This is achieved by reducing the XBL data rate from the current 64 kbps to 16 kbps. Thisfrees three 16 kbps subchannels on the E1 64 kbps timeslot and enables them to be used asTCHs. A BSC can interconnect up to ten RXCDRs. A total of 20 XBL links are deployed in anyconfiguration. 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 canbe two different rates at the same BSC to RXCDR, although this is not considered a typicalconfiguration. As a result of the introduction of the 16 kbps RSL, there is no reduction in theprocessing capacity of the BSC or the RXCDR.

2-20 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Dynamic allocation of RXCDR to BSC circuits (DARBC)

Figure 2-15 demonstrates XBL utilization.

Figure 2-15 XBL utilization

ti-GSM-XBL_utilization-00019-ai-sw

BSC 1

BSC 2

BSC 9

BSC 10

BSC 3RXCDR

XBL XBL

XBL XBL

XBL XBL

XBL XBL

XBL XBL

NOTE

• In Figure 2-15 a maximum of two XBLs can be utilized between the BSC andXCDR of either 64 kbps or 16 kbps on the E1 link.

• A maximum of ten BSCs and RXCDR can be interconnected.

Dynamic allocation of RXCDR to BSC circuits (DARBC)

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 providesfor validation of the CIC and Ater channel provisioning between the BSC and RXCDR to ensurethat calls are placed on the correct circuit between the BSC and the MSC. Without this featurein place, fault management of the Ater channels is not possible. All Ater and CIC informationmust 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 backwardscompatibility mode. These modes are managed on a per AXCDR basis.

68P02900W21-T 2-21

Jul 2010

Dynamic allocation of RXCDR to BSC circuits (DARBC) Chapter 2: Transmission systems

Auto-connect mode

The operator can select this mode. This mode refers to a BSC in which Ater channels areallocated and released dynamically as resources are provisioned, unprovisioned, or whilehandling a fault condition. Auto-connect mode provides fault tolerance along with the callprocessing efficiency of the backwards compatibility mode. This is the recommended modeof operation for the BSC.

Backward compatibility mode

NOTEBackward compatibility mode cannot be used in conjunction with the AMR or GSMhalf 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 andCICs are statically switch connected. This mode does not provide any fault tolerance and CICvalidations. It is intended only to provide an upgrade path. Once both the BSC and RXCDR areupgraded, the use of auto-connect mode is recommended.

NOTEWhile upgrading the network, if the BSC is upgraded before the RXCDR, backwardscompatibility mode must be used for the corresponding AXCDR.

Before the introduction of this feature, all Ater channels were statically assigned and use ofXBL links was not mandatory. Currently, if an operator decides to use the auto-connect, it isnecessary to equip XBL links on the RXCDR and BSC. If XBLs are not equipped, and the AXCDRis operating in the auto-connect mode, all CICs at the BSC associated with that AXCDR areblocked 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 aresome issues that the operator must consider when planning and provisioning the BSC/RXCDRnetwork.

EAC mode is part of the AMR feature and also applies to the GSM half rate feature. It takesadvantage of the use of half rate traffic channels where only 8 kbps backhaul to the RXCDRis required. EAC mode is user enabled across a BSC - RXCDR interface and only providesbenefits when the RXCDR is equipped with any number of EGDPs or GDP/GDP2s, and the BSCand RXCDR are populated exclusively with DSW2s (no KSWs).

2-22 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Dynamic allocation of RXCDR to BSC circuits (DARBC)

When in EAC mode, a CIC no longer has a fixed position on the Ater interface. Rather, a CICcan be considered as belonging to a pool of CICs where a separate pool is maintained for eachRXCDR connected to the BSC. When a call is assigned to a CIC, the BSC allocates an Aterchannel that goes to the same RXCDR as the assigned CIC. One implication of such a poolingis that the number of CICs equipped that go through the RXCDR may not be the same as thenumber of Ater channels from the BSC to the RXCDR. XBL links are required between theBSC and RXCDR as in the auto-connect mode.

Equipping less than 16 kbps in Ater capacity per equipped CIC relies upon a percentage of thecalls to be utilizing half rate backhaul. If that assumption proves to be false, some capacity islost as CICs are unusable due to a lack of Ater resources [if CIC - Ater provisioning is equal (16kbps Ater capacity per CIC), EAC mode is not required and the system automatically reverts toauto-connect mode even if EAC is enabled]. EAC mode also needs XBL bandwidth. Use of EACmode (specifically the provisioning of fewer Ater channels than CICs) is best considered whenBSC - RXCDR backhaul costs are a concern.

If the operator chooses to equip a higher number of CICs than can be handled by the Aterchannels, there is a possibility that a call assignment may fail because Ater channels areunavailable. To prevent such assignments from failing, the BSC provides a facility thatautomatically blocks at the MSC, all idle CICs that go through a particular RXCDR when thenumber of available Ater channels to RXCDR reaches a configurable threshold. The operatorcontrols such thresholds through the cic_block_thresh and cic_unblock_thresh values. Thesethresholds are used to maintain Ater resources, to ensure that resources are available when afault occurs and also to balance the call load.

NOTEFor AMR, when the 7.95 kbps half rate codec mode is included in the Half Rate ActiveCodec Set, 16 kbps backhaul is required. This is provisioned on a per cell basis andshould be taken into consideration when provisioning Ater resources.

68P02900W21-T 2-23

Jul 2010

Managed HDSL on micro BTSs Chapter 2: Transmission systems

Managed HDSL on micro BTSs■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

Managed HDSL brings the benefits of full OMC-R management to those products that supportintegrated HDSL technology. Specifically, it allows remote configuration, status, control, andquality of service information to be handled by the OMC-R. External HDSL modems configuredas slave devices can also be managed by the same mechanism as long as they are connected toan integrated master HDSL port.

This enables such an HDSL link to be managed entirely from the OMC-R. Following theintroduction of this feature, the initial basic version of the product is no longer supported.

NOTEHorizonmicro2 microcell BTSs (and Horizoncompact2 macrocell BTSs) shippedafter 31st December 2001 are not fitted with an internal HDSL modem. A suitableexternal HDSL modem must be used if an HDSL link to the BSC is required for theseBTSs. The local Motorola office can provide assistance before purchasing an HDSLmodem 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 asa 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 arecorrectly installed, and the guidelines for selection and installation are observed.

2-24 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 withHDSL but since it is not twisted, it provides little immunity from noise, and is thereforenot recommended.

• An information cable which is typically made of non-twisted, multicore construction, forexample, ribbon cable, is not recommended.

HDSL cable installation

If cabling does not exist between two end sites, the guidelines to be followed for the installationof 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 SELVvoltage levels).

• The isolation between the tip and earth should be greater than 1 M ohm (at SELV voltagelevels).

• The isolation between the ring and earth should be greater than 1 M ohm (at SELV voltagelevels).

68P02900W21-T 2-25

Jul 2010

General HDSL guidelines Chapter 2: Transmission systems

HDSL range

HDSL range is affected by many factors, which should be taken into account when planningthe system.

• Microcell systems can have longer distances, typically 2 km or so, because of theirdifferent 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.

NOTEHowever, if unshielded from each other standard E1 traffic affects (and is affectedby) 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 amicrosite. 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 ispurchased (not available for Horizonmicro2 after December 2001), the links are automaticallyconfigured as either E1 or HDSL through a combination of database settings and auto-detectionmechanisms. The setting of master/slave defaults can be changed by database settings for thosescenarios, such as a closed loop daisy chain, where the defaults are not appropriate.

2-26 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Microcell system planning

Figure 2-16 Conversion of E1 to HDSL links by modem and microsite

ti-GSM-Conversion_of_E1_to_HDSL_links-00020-ai-sw

BSC

EXTERNAL MODEM

M

M - MASTER

EXTERNAL MODEM

E1 LINK HDSL

HDSL

HDSL

E1 LINK

E1 LINK

Horizonmacro

SLAVE

MSLAVE

S M S M M

M SM SHDSL

HDSL

HDSL

E1 LINK

E1 LINK

BTS

Horizonmicro2

Horizonmicro2 Horizonmicro2 Horizonmicro2

Horizonmicro2 Horizonmicro2 Horizonmicro2

S - SLAVE

Microcell system planning

Network configurations from the BSC can be a combination of daisy chain and star. Links can beeither 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 slaveport to the master port of the Horizonmicro2. The slave port of the Horizonmicro2 connects tothe next Horizonmicro2 master port, and so on, until the last Horizonmicro2 port is connected.

Figure 2-17 Microcell daisy chain network configuration

ti-GSM-Microcell_daisy_chain_network-ooo21-ai-sw

M - MASTER

EXTERNAL MODEM

HDSL MSLAVE MS MSBSCHDSL HDSLE1 LINK

Horizonmicro2 Horizonmicro2 Horizonmicro2

S - SLAVE

68P02900W21-T 2-27

Jul 2010

Microcell system planning Chapter 2: Transmission systems

Star configuration

Figure 2-18 shows a BSC which is connected to an external modem, which then connects fromits slave port to the master port of a Horizonmicro2. In this configuration, an external modem isused every time a link to a Horizonmicro2 is used, hence the star formation.

Figure 2-18 Microcell star network configuration

ti-GSM-Microcell_star_network_configuration-00022-ai-sw

BSC

EXTERNAL MODEM

M

M - MASTER

EXTERNAL MODEM

M

EXTERNAL MODEM

MSLAVE

E1 LINK HDSL

HDSL

HDSL

E1 LINK

E1 LINK

SLAVE

SLAVE

Horizonmicro2

Horizonmicro2

Horizonmicro2

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 canbe at any BTS, in either direction.

Figure 2-19 Microcell configuration using E1/HDSL links

ti-GSM-Microcell_configuration_using_E1/HDSL_links-00023-ai-sw

M - MASTERS - SLAVE

M S MS

BSC

E1 LINK HDSLHDSL

Horizonmicro2 Horizonmicro2 Horizonmicro2

2-28 68P02900W21-T

Jul 2010

Chapter

3

BSS cell planning■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

■

■

When planning a mobile telephone system, the aim is to create a communications network thatfulfills 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 operatingnetwork is always a solution achieved through compromise. The cost of different networkconfigurations can vary considerably. From an engineering point of view, it would be worthwhileto use efficient solutions despite high costs. However, a mobile telephone network is so hugean investment that the financial factors are always going to limit the possibilities. The effectof limited funds is obvious during the first stage of the network. Consequently, economicalplanning is a condition for giving the best possible service from the onset.

The use of the GSM900, EGSM900, and DCS1800 frequency bands create manypropagation-based problems. As the channel characteristics are not fixed, design challengesand impairments arise. These impediments must be dealt with to protect MS telephone usersfrom 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 areain 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 describedin 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 3-1

Jul 2010

Microcell system planning Chapter 3: BSS cell planning

• 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

3-2 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning tools

Planning tools■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

It is essential to make many calculations at regular intervals from the BTS to predict the signalstrength in a cell area. The smaller the interval, the more accurate is the propagation model. Inaddition, calculations should be performed at regular distances along each radial arm from theBTS, 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 timeconsuming, 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 ofthe propagation paths of the cell.

Several planning tools are available in the market, such as Netplan or Planet, and it is up tothe operators to select the required tools that suit them best.

Check the figures by practical measurements after the calculation and implementation of thecell. This is because, with all the variable factors in propagation modeling, an accuracy of80% is considered excellent.

68P02900W21-T 3-3

Jul 2010

Traffic capacity Chapter 3: BSS cell planning

Traffic capacity■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Dimensioning

One of the most important steps in cellular planning is system dimensioning. Some idea of theprojected usage of the system must be obtained (for example, the number of people wishing touse 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 individualsimultaneous calls. The traffic flow is defined as the average number of concurrent calls carriedin the cell. The unit of traffic intensity is the Erlang. The traffic defined in this way can bethought of as a measure of the voice load carried by the cell. The maximum carried traffic in acell 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 theaverage carried traffic, in Erlangs, is t/T. The total traffic carried by the cell is the sum of thetraffic carried by each channel. The mean call holding time is the average time a channel isserving a call.

Channel blocking

The standard model used to dimension a system is the Erlang B model, which models thenumber of traffic channels or trunks required or a given grade of service and given offeredtraffic. 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. Ifblocking occurs, then the carried traffic is less than the offered traffic. If a call is blocked, thecaller 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 blockingprobability is small, ignore the effect of repeated call attempts and assume that the blockedcalls are abandoned.

The number of calls handled during a 24-hour period varies considerably with time. There aretwo peaks during weekdays, although the pattern can change from day to day. Across thetypical day, the variation is such that a one-hour period shows greater usage than any otherdoes. From the hour with the least traffic to the hour with the greatest traffic, the variation canexceed 100:1.

There can also be unpredictable peaks caused by a wide variety of events (for example, theweather, natural disasters, conventions, sports events). In addition to this, system growthshould be taken into account. There are a set of common definitions to describe this busyhour traffic loading.

Busy Hour: The busy hour is a continuous period during which traffic volume or number ofcall 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 whichthe average traffic volume or call attempts count is greatest over the days under consideration.

3-4 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Traffic flow

Busy Season Busy Hour: The engineering period where the grade of service criteria is appliedfor 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 trunkgroups and always has a grade of service criteria applied. For example, for the Average BusySeason Busy Hour load, a call requiring a circuit in a trunk group should not encounter AllTrunks Busy (ATB) no more than 1% of the time. Peak loads are of more concern than averageloads 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 theduration 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:

C the calling rate per hour.

T 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 is120, then the traffic flow would be 120 x 1.5 = 180 call minutes or 3 call hours. One Erlangof traffic intensity on one traffic channel means a continuous occupancy of that particulartraffic channel.

Considering a group of traffic channels, the traffic intensity in Erlangs is the number ofcall-seconds per second or the number of call-hours per hour. For example, if there are a groupof 10 traffic channels, which had a call intensity of 5 Erlangs, then half of the circuits would bebusy at the time of measurement.

Grade of service

One measure of the quality of service is how many times a subscriber is unsuccessful in settingup a call (blocking). Blocking data states what grade of service is required. It is given as apercentage of the time that the subscriber is unable to make a call. Typical blocking for theMS-BSC link is 2% with 1% being acceptable on the BSC-MSC link. There is a direct relationshipbetween the grade of service required and the number of channels. The desired grade of servicehas a direct effect on the number of channels required in the network.

68P02900W21-T 3-5

Jul 2010

Adaptive multi-rate (AMR) Chapter 3: BSS cell planning

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 providea 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 speechquality) is selected as channel quality deteriorates, leading to an increase in the sensitivity ofthe transceivers, thus providing optimum performance.

The half rate (hr) ability of AMR, which allows for two calls per timeslot, provides the largestincrease in capacity, but at a cost of a decrease in voice quality. Initially the AMR capable MSpenetration rate may be low; suggesting that in circumstances where capacity is paramount andvoice quality is secondary then GSM half rate is employed as an alternative. For details aboutGSM half rate, see GSM half rate on page 3-10. With AMR operating in full rate mode, or in amix of full rate and half rate where handovers between the modes are permitted, a capacity gaincan be realized as a result of being able to operate at a lower C/I threshold. This can result inhigher 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 dependentupon other factors (for example, propagation conditions) and any improvement gained by areplanning 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 technicalaspects 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. Thisis achieved by halving the air interface necessary to support a single voice call using AMR halfrate. On the backhaul, it is possible to support 8 voice calls per E1 timeslot instead of 4 when 8kbps backhaul is used (refer to Figure 3-1).

3-6 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Quality of service

Figure 3-1 AMR half rate capacity increase

AMR Full Rate, Enhanced Full Rateand Full Rate coverage area AMR Half Rate coverage area

AMR Full Rate

AMR Half Rate

2 X voice calls supportedper timeslot in AMR Half Ratecoverage area

8 kbit/s

Timeslot 1 Timeslot 2 Timeslot 3

1 2 3 4

5 6 7 8

1 2 3 4 4

4441

1

112 22

2

3 3 3

3

5 56 67 78 8

16 kbit/s

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 highquality in poorer signaling conditions:

• AMR full rate offers higher quality voice communications in poor radio environmentssuch as corporate and urban buildings where no dedicated in-building coverage has beenprovided.

• AMR full rate improves voice quality across the entire network, by supporting high-qualityvoice 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 intelligentlyselecting the best from a selection of codecs in various radio environments. Figure 3-2 showsthe different profiles of these codecs.

68P02900W21-T 3-7

Jul 2010

Applications Chapter 3: BSS cell planning

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 OpinionScore (MOS)of voicequality

5.0

4.0

3.0

2.0

1.0No Errors C/I=16 dB C/I=13 dB C/I=10 dB C/I=7 dB C/I=1 dBC/I=4 dB

Conditions

EFR12.210.27.957.46.75.95.154.75

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 marginalradio environments (C/I = 13 dB to 4 dB). This enables operators to offer high voice qualityin radio environments that does not support EFR. This improvement is paramount in urbanenvironments, 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 meetspecific network and service needs. Some of the potential application scenarios are identifiedtogether 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 toGSM 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 celledge, coverage holes, and so on). Some capacity advantage is also derived from the improvedresilience under low C/I conditions. It supports tighter frequency re-use.

Potential service applications - Suitable for operators who do not require to increase capacitythrough 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 capacityadvantage. Potential service applications - Suitable for operators who need the greatest capacityenhancement from half rate operation. Some loss of quality at high channel error rates and inbackground noise can be expected.

3-8 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 ahalf rate channel to help ease the congestion. This provides a tuneable trade-off between callquality and capacity. Potential service applications - Suitable for operators who want to combinespeech quality and capacity improvements.

Migration to AMR half rate

When migrating, care should be taken to ensure that the call capacity rating of the variouscomponents of the system are not exceeded. Use of AMR HR improves the spectral efficiencyover the air interface (and potentially the backhaul), but from a load perspective a half ratecall 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. Onesubrate 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 maximizethe VersaTRAU backhaul utilization, only 8 kbps switching on the backhaul is supported.

68P02900W21-T 3-9

Jul 2010

GSM half rate Chapter 3: BSS cell planning

GSM half rate■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

GSM half rate offers enhanced capacity over the air interface, corresponding to the proportionof mobiles within a coverage area that supports GSM half rate. An air timeslot is split into twosubchannels, each containing a half rate channel. Although the speech quality is consideredinferior to other speech codecs, GSM half rate capable mobiles have a high penetration leveldue to its early introduction into the standards and hence it is considered a viable option forhigh-density areas.

Capacity and coverage

GSM half rate doubles the number of voice calls that can be supported over the air interface aswith AMR half rate, thus allowing up to double the number of subscribers that are supportedby a base station. This is achieved by halving the air interface capacity necessary to support asingle voice call using GSM half rate. On the backhaul, it is possible to support 8 voice calls perE1 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 Rateand Full Rate coverage area GSM Half Rate coverage area

Full Rate

GSM Half Rate

2 X voice calls supportedper timeslot in GSM Half Ratecoverage area

8 kbit/s

Timeslot 1 Timeslot 2 Timeslot 3

1 2 3 4

5 6 7 8

1 2 3 4 4

4441

1

112 22

2

3 3 3

3

5 56 67 78 8

16 kbit/s

ti-GSM-GSM_half_rate_capacity_increase-00129-ai-sw

3-10 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Quality of service

Quality of service

The GSM half rate codec does not perform as well as the AMR half rate codec. Figure 3-4shows 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 qualityagainst 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 applicationscenarios are identified together with the advantages offered and the types of networks towhich they are suited.

NOTEGSM half rate can be controlled at the cell level and is suitable to deal with highuser density clusters.

Half rate

The GSM half rate codec can be operated in half rate channel mode to gain maximum capacityadvantage. All qualifying calls are placed on a half rate channel.

Potential service applications - Suitable for operators who need the greatest capacityenhancement from half rate operation. A reduction in speech quality is expected.

68P02900W21-T 3-11

Jul 2010

Migration to half rate Chapter 3: BSS cell planning

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 ratechannels. The operator also specifies a handover of half rate capable mobiles from a full ratechannel to a half rate channel to help ease the congestion. This provides a tuneable trade-offbetween call quality and capacity.

Potential service applications - Suitable for operators who want to combine speech qualityand capacity improvements.

Migration to half rate

When migrating, care should be taken to ensure that the call capacity rating of the variouscomponents of the system are not exceeded. Use of GSM half rate improves the spectralefficiency over the air interface (and potentially the backhaul), but from a load perspective ahalf 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. Onesubrate is operating as GSM half rate, the other as AMR half rate.

Interoperability with EGPRS

When GSM half rate is enabled on an EGPRS capable carrier (pkt_radio_type = 3) to maximizethe VersaTRAU backhaul utilization, only 8 kbps switching on the backhaul is supported.

3-12 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 theencoding of the user data (160 bits RLC data block, segmented LLC PDUs) and the RLC/MACheader (24 bits) for downlink. In the first stage of coding, these 184 bits are protected accordingto Fire code using extra 40 bits (BCS) for error detection (used in ARQ). The subsequent 224bits are then convolutionally coded followed by interleaving over four bursts. CS1 provides auser data rate (excluding RLC/MAC header) of 8 kbits/s.

Figure 3-5 GPRS channel coding scheme 1 (CS1)

RLC/MAC Header BCSUSF

Block interleaving over 4 bursts

Puncturing

Rate 1/2 convolutional coding

Block coded

3 bits 21 bits 160 bits 40 bits

4 bits

224 bits

456 bits

TB

456 bits

114 bits 114 bits 114 bits 114 bits

3 bits 3 bits57 bits26 bits

TBBSBSBT TS

Data

Mapped to 4 TDMA bursts; coding scheme signalled through 8 stealing bits (2 per burst)

Header & data Header & data

1 bit1 bit57 bitsti-GSM-GPRS_channel_coding_scheme_1-00172-ai-sw

68P02900W21-T 3-13

Jul 2010

Channel coding scheme 2 (CS2) Chapter 3: BSS cell planning

Channel coding scheme 2 (CS2)

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

Figure 3-6 GPRS channel coding scheme 2 (CS2)

RLC/MAC Header BCSUSF

Block interleaving over 4 bursts

Puncturing

Rate 1/2 convolutional coding

Block coded

6 bits(pre-coded) 28 bits 240 bits 16 bits

4 bits

290 bits

588 bits

TB

456 bits

114 bits 114 bits 114 bits 114 bits

3 bits 3 bits57 bits26 bits

TBBSBSBT TS

Data

Mapped to 4 TDMA bursts; coding scheme signalled through 8 stealing bits (2 per burst)

Header & data Header & data

1 bit1 bit57 bitsti-GSM-GPRS_channel_coding_scheme_2-00173-ai-sw

3-14 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Channel coding scheme 3 (CS3)

Channel coding scheme 3 (CS3)

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 provideadditional protection. In the first stage of coding, these 318 bits are protected according to theFire code using extra 16 bits for (BCS) for error detection (used in ARQ). The subsequent 334bits are then convolutionally coded, punctured, and interleaved over four bursts. CS3 provides auser data rate (excluding RLC/MAC header) of 14.4 kbits/s.

Figure 3-7 GPRS channel coding scheme 3 (CS3)

RLC/MAC Header BCSUSF

Block interleaving over 4 bursts

Puncturing

Rate 1/2 convolutional coding

Block coded

6 bits(pre-coded) 24 bits 288 bits 16 bits

4 bits

344 bits

676 bits

TB

456 bits

114 bits 114 bits 114 bits 114 bits

3 bits 3 bits57 bits26 bits

TBBSBSBT TS

Data

Mapped to 4 TDMA bursts; coding scheme signalled through 8 stealing bits (2 per burst)

Header & data Header & data

1 bit1 bit57 bitsti-GSM-GPRS_channel_coding_scheme_3-00174-ai-sw

68P02900W21-T 3-15

Jul 2010

Channel coding scheme 4 (CS4) Chapter 3: BSS cell planning

Channel coding scheme 4 (CS4)

CS4 is the least robust GPRS coding scheme and it has no FEC capability. Figure 3-8 shows theencoding of the user data (400 bits RLC data block, segmented LLC PDUs) and the RLC/MACheader (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) overfour bursts. CS4 provides a user data rate (excluding RLC/MAC header) of 20 kbits/s.

Figure 3-8 GPRS channel coding scheme 4 (CS4)

RLC/MAC Header BCSUSF

Block interleaving over 4 bursts

No puncturing

No convolutional coding

Block coded

12 bits(pre-coded) 28 bits 400 bits 16 bits

456 bits (0 bits TB)

456 bits

456 bits

114 bits 114 bits 114 bits 114 bits

3 bits 3 bits57 bits26 bits

TBBSBSBT TS

Data

Mapped to 4 TDMA bursts; coding scheme signalled through 8 stealing bits (2 per burst)

Header & data Header & data

1 bit1 bit57 bitsti-GSM-GPRS_channel_coding_scheme_4-00175-ai-sw

All control channels except for the PRACH use CS1. Two types of packet random access burstare transmitted on the PRACH: an 8 information bits random access burst, or an 11 informationbits random access burst (called the extended packet random access burst). The mobile mustsupport both random access burst types.

3-16 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 16/32 kbps TRAU

GPRS traffic channels use scheme CS1, CS2, CS3, or CS4. This allows the coding scheme tobe dynamically adapted to the channel conditions and thereby maximizing throughput andoptimizing the performance.

USF is the Uplink State Flag, which is transmitted on the downlink and is an invitation to an MSto transmit. The BCS is Block Check Sequence, which is used for the detection of errors andsubsequent 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

Effective Code rate after 1/2 convolutional coding andpuncturing

1/2 2/3 3/4 1

USF 3 3 3 3

Pre-coded USF 3 6 6 12

RLC/MAC header/bits 21 28 24 28

User bits (RLC blocks; segmented LLC PDUCs) 181 268 312 428

BCS 40 16 16 16

Tail 4 4 4 -

Coded bits 456 588 676 456

Punctured bits 0 132 220 0

User Data rate at RLC/MAC kbps 8 12 14.4 20

16/32 kbps TRAU

In the BSS architecture, the link, which the GPRS data traverses from the channel coders inthe BTS to the PCU, is currently implemented using 16 kbps TRAU-like links. These links arecarried over subrate switched E1 timeslots, which have some signaling included to ensure thatthe link is synchronized between the channel coders and the PCU. However, Table 3-1 showsthat there is not enough bandwidth available on a 16 kbps link to carry CS3 and CS4, thereforethe 32 kbps TRAU is required.

The method used is to combine two component 16 kbps TRAU channels to create a 32 kbpsTRAU channel. The two 16 kbps channels are referred to as the left and right channels. Theleft channel is the primary channel, which is currently used for all GPRS traffic. The right (orauxiliary) channel is used for the larger CS3 and CS4 GPRS TRAU-like frames.

NOTEOnly 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 Chapter 3: BSS cell planning

EGPRS channel coding schemes

Nine different coding schemes have been defined for EGPRS, MCS-1 to MCS-9. MCS-1 toMCS-4 coding schemes use GMSK and MCS-5 to MCS-9 coding schemes use 8-PSK. Themother code used is a 1/3 rate convolutional coder applied to all the coding schemes followedby various puncturing schemes leading to various effective code rates. The following apply toall nine coding schemes:

• User data (RLC data block, segmented LLC PDUs), RLC/MAC header and the USF bitsare coded independently.

• The USF bits (3) are block coded, resulting in 12 bits and 36 bits for GMSK and 8-PSKcoding schemes respectively. In case of MCS-1 to MCS-4, USF block coding is identicalto CS-4. This facilitates multiplexing of GPRS and EGPRS on the same timeslot (GPRSmobiles 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 aboutthe coding and puncturing scheme, used for a block. Header type 1 is used for MCS-7 toMCS-9, header type 2 is used for MCS-5 and MCS-6, and header type 3 is used for MCS-1to MCS-4.

• Eight stealing bits (SBs) are used to signal which header type should be used to extractvarious information.

• Coding schemes MCS-7 to MCS-9 are interleaved over two bursts and coding schemesMCS-1 to MCS-6 are interleaved over four bursts.

• Two or three puncturing schemes per coding scheme are used enabling IncrementalRedundancy (IR); the code combining process of radio blocks in error thus providingadditional coding gain, particularly for higher code rates.

• There are three code families, A, B, and C. The code families facilitate re-segmentationof erroneous radio blocks into more robust coding schemes for re-transmission. Codingschemes 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.

NOTEHybrid ARQ type I is not supported.

These are described in the following sections.

3-18 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning EGPRS channel coding schemes

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 LLCPDUs), the RLC/MAC header (28 bits, header type 3) for downlink. Extra 12 bits (BCS) for errordetection (used in ARQ) protect the user data. The subsequent 196 bits (including tail bits, FBIand E bits) are then convolutionally coded, punctured, and interleaved over four bursts. Extra8 bits (HCS) for error detection protect the header data. The subsequent 36 bits are thenconvolutionally coded, punctured, and interleaved over four bursts. MCS1 provides a user datarate (excluding RLC/MAC header) of 8.8 kbits/s.

Figure 3-9 EGPRS channel coding scheme 1 (MCS-1)

RLC/MAC Header

Rate 1/3 convolutional codingBlockcoded

Puncturing

2P1P

BCSUSF

3 bits 28 bits 8 bits 12 bits

588 bits

372 bits

3 bits 3 bits57 bits26 bits

TBBSBSBT Header & data Header & dataTS

2 bits 176 bits 6 bits

196 bits

108 bits12 bits

372 bits68 bits12 bitsSB = 12

Data TBHCS FBI E

Burst 1 Burst 2 Burst 3 Burst 4

57 bits 1 bit 1 bit

ti-GSM-EGPRS_channel_coding_scheme_1-00176-ai-sw

68P02900W21-T 3-19

Jul 2010

EGPRS channel coding schemes Chapter 3: BSS cell planning

Channel coding scheme MCS-2

MCS-2 coding scheme is less robust than MCS-1. Figure 3-10 shows the encoding of the userdata (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 (includingtail bits, FBI and E bits) are then convolutionally coded, punctured, and interleaved over fourbursts. Extra 8 bits (HCS) for error detection protect the header data. The subsequent 36 bitsare then convolutionally coded, punctured, and interleaved over four bursts. MCS2 provides auser data rate (excluding RLC/MAC header) of 11.2 kbits/s.

Figure 3-10 EGPRS channel coding scheme 2 (MCS-2)

RLC/MAC Header

Rate 1/3 convolutional codingBlockcoded

Puncturing

2P1P

BCSUSF

3 bits 28 bits 8 bits 12 bits

672 bits

372 bits

3 bits 3 bits57 bits26 bits

TBBSBSBT Header & data Header & dataTS

2 bits 224 bits 6 bits

244 bits

108 bits12 bits

372 bits68 bits12 bitsSB = 12

Data TBHCS FBI E

Burst 1 Burst 2 Burst 3 Burst 4

57 bits 1 bit 1 bit

ti-GSM-EGPRS_channel_coding_scheme_2-00177-ai-sw

3-20 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning EGPRS channel coding schemes

Channel coding scheme MCS-3

MCS-3 coding scheme is less robust than MCS-1 and MCS-2. Figure 3-11 shows the encoding ofthe user data (296 bits), the RLC/MAC header (28 bits, header type 3) for downlink. Extra 12bits (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 interleavedover four bursts. Extra 8 bits (HCS) for error detection protect the header data. The subsequent36 bits are then convolutionally coded, punctured, and interleaved over four bursts. MCS-3provides a user data rate (excluding RLC/MAC header) of 14.8 kbits/s.

Figure 3-11 EGPRS channel coding scheme 3 (MCS-3)

RLC/MAC Header

Rate 1/3 convolutional codingBlockcoded

Puncturing

2P1P

BCSUSF

3 bits 28 bits 8 bits 12 bits

672 bits

372 bits

3 bits 3 bits57 bits26 bits

TBBSBSBT Header & data Header & dataTS

2 bits 224 bits 6 bits

244 bits

108 bits12 bits

372 bits68 bits12 bitsSB = 12

Data TBHCS FBI E

Burst 1 Burst 2 Burst 3 Burst 4

57 bits 1 bit 1 bit

ti-GSM-EGPRS_channel_coding_scheme_3-00178-ai-sw

372 bits

Puncturing

3P

68P02900W21-T 3-21

Jul 2010

EGPRS channel coding schemes Chapter 3: BSS cell planning

Channel coding scheme MCS-4

MCS-4 coding scheme is the least robust GMSK modulated coding scheme; it has no FECcapability. 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 thenconvolutionally coded, punctured, and interleaved over four bursts. Extra 8 bits (HCS) for errordetection 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 (excludingRLC/MAC header) of 17.6 kbits/s.

Figure 3-12 EGPRS channel coding scheme 4 (MCS-4)

RLC/MAC Header

Rate 1/3 convolutional codingBlockcoded

Puncturing

2P1P

BCSUSF

3 bits 28 bits 8 bits 12 bits

1116 bits

372 bits

3 bits 3 bits57 bits26 bits

TBBSBSBT Header & data Header & dataTS

2 bits 352 bits 6 bits

372 bits

108 bits12 bits

372 bits68 bits12 bitsSB = 12

Data TBHCS FBI E

Burst 1 Burst 2 Burst 3 Burst 4

57 bits 1 bit 1 bit

ti-GSM-EGPRS_channel_coding_scheme_4-00179-ai-sw

372 bits

3P

Puncturing

3-22 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning EGPRS channel coding schemes

Channel coding scheme MCS-5

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, headertype 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 theheader data. The subsequent 33 bits are then convolutionally coded, punctured, and interleavedover four bursts. MCS-5 provides a user data rate (excluding RLC/MAC header) of 22.4 kbits/s.

Figure 3-13 EGPRS channel coding scheme 5 (MCS-5)

RLC/MAC Header

Rate 1/3 convolutional codingBlockcoded

Puncturing

1P

BCSUSF

3 bits 25 bits 8 bits 12 bits

1404 bits

1248 bits

9 bits 9 bits57 bits78 bits

TBBSBSBT Data DataTS

2 bits 448 bits 6 bits

468 bits

99+1 spare bits36 bits

100 bits36 bitsSB = 8

Data TBHCS FBI E

Burst 1 Burst 2 Burst 3 Burst 4

156 bits 1 bit 1 bit

ti-GSM-EGPRS_channel_coding_scheme_5-00180-ai-sw

No puncturing

1248 bits

2P

H U

12 bits

5bits

HU

4bits

13 bits

68P02900W21-T 3-23

Jul 2010

EGPRS channel coding schemes Chapter 3: BSS cell planning

Channel coding scheme MCS-6

MCS-6 coding scheme is less robust than MCS-5. Figure 3-14 shows the encoding of the userdata (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 (includingtail bits, FBI, and E bits) are then convolutionally coded, punctured, and interleaved over fourbursts. Extra 8 bits (HCS) for error detection protect the header data. The subsequent 33 bitsare then convolutionally coded, punctured, and interleaved over four bursts. MCS-6 provides auser data rate (excluding RLC/MAC header) of 29.6 kbits/s.

Figure 3-14 EGPRS channel coding scheme 6 (MCS-6)

RLC/MAC Header

Rate 1/3 convolutional codingBlockcoded

Puncturing

1P

BCSUSF

3 bits 25 bits 8 bits 12 bits

1836 bits

1248 bits

9 bits 9 bits57 bits78 bits

TBBSBSBT Data DataTS

2 bits 592 bits 6 bits

612 bits

99+1 spare bits36 bits

100 bits36 bitsSB = 8

Data TBHCS FBI E

Burst 1 Burst 2 Burst 3 Burst 4

156 bits 1 bit 1 bit

ti-GSM-EGPRS_channel_coding_scheme_6-00181-ai-sw

No puncturing

1248 bits

2P

H U

12 bits

5bits

HU

4bits

13 bits

3-24 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning EGPRS channel coding schemes

Channel coding scheme MCS-7

MCS-7 coding scheme is less robust than MCS-5 and MCS-6. It also carries two radio blocks per20 ms. Figure 3-15 shows the encoding of the user data, which consists of two separate userdata blocks, 448 bits each, the RLC/MAC header (37 bits, header type 1) for downlink. Extra12 bits (BCS) for error detection (used in ARQ) protect each user data block. The subsequent468 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 theheader data. The subsequent 45 bits are then convolutionally coded, punctured, and interleavedover four bursts. MCS-7 provides a user data rate (excluding RLC/MAC header) of 44.8 kbits/s.

Figure 3-15 EGPRS channel coding scheme 7 (MCS-7)

RLC/MACHeader

USF

3bits

37bits

8bits

12bits

1404 bits

612 bits

9bits

153 bits 15 bits

1bit

78bits

TB

2bits

448bits

6bits

468 bits

135 bits36 bits

124 bits36 bitsSB = 8

5bits

1bit

4bits

16bits

153 bits 9 bits

2bits

448bits

12bits

6bits

1404 bits

Data TBHCS FBI E

Rate 1/3 convolutional codingBlockcoded

Puncturing

Burst 1 Burst 2 Burst 3 Burst 4

Puncturing

BCS Data TBFBI E BCS

Puncturing

P1 P2 P3 P1 P2 P3

612 bits 612 bits 612 bits 612 bits 612 bits

Data DataH U SB TS SB U H TB

ti-GSM-EGPRS_channel_coding_scheme_7-00182-ai-sw

68P02900W21-T 3-25

Jul 2010

EGPRS channel coding schemes Chapter 3: BSS cell planning

Channel coding scheme MCS-8

MCS-8 coding scheme carries two user data blocks like MCS-7. Figure 3-16 shows the encodingof 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 datablock. The subsequent 564 bits per radio block (including tail bits, FBI and E bits) are thenconvolutionally coded, punctured, and interleaved over two bursts. Extra 8 bits (HCS) for errordetection 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 (excludingRLC/MAC header) of 54.4 kbits/s.

Figure 3-16 EGPRS channel coding scheme 8 (MCS-8)

RLC/MACHeader

USF

3bits

37bits

8bits

12bits

1692 bits

612 bits

9bits

153 bits 15 bits

1bit

78bits

TB

2bits

544bits

6bits

564 bits

135 bits36 bits

124 bits36 bitsSB = 8

5bits

1bit

4bits

16bits

153 bits 9 bits

2bits

544bits

12bits

6bits

1692 bits

Data TBHCS FBI E

Rate 1/3 convolutional codingBlockcoded

Puncturing

Burst 1 Burst 2 Burst 3 Burst 4

Puncturing

BCS Data TBFBI E BCS

Puncturing

P1 P2 P3 P1 P2 P3

612 bits 612 bits 612 bits 612 bits 612 bits

Data DataH U SB TS SB U H TB

ti-GSM-EGPRS_channel_coding_scheme_8-00183-ai-sw

3-26 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning EGPRS channel coding schemes

Channel coding scheme MCS-9

MCS-9 coding scheme carries two user data blocks like MCS-7 and 8. Figure 3-17 shows theencoding 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 eachuser data block. The subsequent 612 bits per radio block (including tail bits, FBI and E bits) arethen convolutionally coded, punctured, and interleaved over two bursts. The puncturing resultsin MCS-9 with having no FEC protection. Extra 8 bits (HCS) for error detection protect theheader data. The subsequent 45 bits are then convolutionally coded, punctured, and interleavedover four bursts. MCS-9 provides a user data rate (excluding RLC/MAC header) of 59.2 kbits/s.

Figure 3-17 EGPRS channel coding scheme 9 (MCS-9)

RLC/MACHeader

USF

3bits

37bits

8bits

12bits

1836 bits

612 bits

9bits

153 bits 15 bits

1bit

78bits

TB

2bits

592bits

6bits

612 bits

135 bits36 bits

124 bits36 bitsSB = 8

5bits

1bit

4bits

16bits

153 bits 9 bits

2bits

592bits

12bits

6bits

1836 bits

Data TBHCS FBI E

Rate 1/3 convolutional codingBlockcoded

Puncturing

Burst 1 Burst 2 Burst 3 Burst 4

Puncturing

BCS Data TBFBI E BCS

Puncturing

P1 P2 P3 P1 P2 P3

612 bits 612 bits 612 bits 612 bits 612 bits

Data DataH U SB TS SB U H TB

ti-GSM-EGPRS_channel_coding_scheme_9-00184-ai-sw

EGPRS traffic channels use coding schemes MCS-1 to MCS-9. This allows the coding schemeto be dynamically adapted to the channel conditions like GPRS through the (LA) process (seeLink 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 Chapter 3: BSS cell planning

optimizing the performance. The IR feature of EGPRS also allows the LA process to be moreaggressive in terms of BLER on the first transmissions and thereby increasing the utilization ofhigher 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 8 7 6 5 4 3 2 1

Effective Coderate after 1/2convolutional codingand puncturing

1.0 0.92 0.76 0.49 0.37 1.0 0.85 0.66 0.53

Effective HeaderCode rate after 1/2convolutional codingand puncturing

0.36 0.36 0.36 1/3 1/3 0.53 0.53 0.53 0.53

Modulation 8-PSK GMSK

RLC blocks per RadioBlock (20 ms)

2 2 2 1 1 1 1 1 1

Raw Data within oneRadio Block

2x592 2x544 2x448 592 448 352 296 224 176

Family A A B A B C A B C

BCS 2x12 12

Tail payload 2x6 6

HCS 8

User Data rate atRLC/MAC kb/s

59.2 54.4 44.8 29.6 22.4 17.6 14.8 11.2 8.8

64 kbps TRAU for EGPRS

In the BSS architecture, the link, which the EGPRS data traverses from the channel coders inthe BTS to the PCU, is currently implemented using 16 kbps TRAU-like links. These links arecarried over subrate switched E1 timeslots, which have some signaling included to ensure thelink is synchronized between the channel coders and the PCU. In case of GPRS, 32 kbits/s TRAUis used to carry CS3 and CS4. In case of EGPRS, Table 3-2 shows that there is not enoughbandwidth available on a 32 kbps link to carry MCS- 7 to 9, therefore VersaTRAU frame formatsare used to statistically multiplex the data for each air timeslot configured as a PDTCH on theRTF backhaul available for use as Versachannel.

For EGPRS, any enabled carrier has a certain amount (ranging from 3 to 8 DS0s) of terrestrialbackhaul configured and a portion of this backhaul is used as the Versachannel to carry the datafor the air timeslots configured as PDTCHs. The EGPRS feature needs additional backhaul toprovision EGPRS carriers. The additional backhaul is either 7 DS0s to implement EGPRS on aBCCH carrier or 8 DS0s to implement EGPRS on a non-BCCH carrier, if VersaTRAU featureis restricted. If VersaTRAU feature is unrestricted, the backhaul for an EGPRS carrier can beconfigured using the rtf_ds0_count parameter.

3-28 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 byadapting the highest coding scheme to the prevailing radio channel condition. The developmentof LA algorithm is generally based on maximizing user or system throughput, under theconstraint of keeping the operating BLER of the system within an acceptable bound. Thisensures that the overall throughput performance is not degraded due to the operation of higherlayers protocols.

The implementation of LA is manufacturer dependant and is also mandatory. The standardsprovide sufficient information and guidelines to facilitate the development of proprietaryalgorithms. This is achieved through specific information elements in the various header andcontrol messages communicated between the BTS and MS. In addition, there are variousmeasurement reports produced by the MS that can be used as inputs to the LA process. Theactual implementation is generally based on guidelines provided by the standards and theboundaries specified in the standards.

The LA impact in improving the system performance is greater in EGPRS compared to GPRSdue 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 perpacket downlink Ack/Nack period. In Motorola’s implementation, a code change is applied toall the blocks and timeslots. In addition, IR is the only mode used in EGPRS, and appropriatemeasures are taken to comply with the constraints specified in the standards.

68P02900W21-T 3-29

Jul 2010

Subscriber environment Chapter 3: BSS cell planning

Subscriber environment■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Subscriber hardware

Perceived system quality (for example, voice quality), system access, and grade of service arethe most significant factors in the success of a cellular network. The everyday subscriberneither knows nor really cares about the high level of technology incorporated into a cellularnetwork. 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 ofequipment they wish to use on the network. It is up to the network provider to satisfy thesubscriber, whatever they choose. The output power of the mobile subscriber is limited in aGSM system to a maximum of 8 W for a mobile and a minimum of 0.8 W for a hand portable. Fora DCS1800 system, the mobile subscriber is restricted to a maximum of 1 W and a minimumof 250 mW hand portable.

Environment

Not only does the network designer have to plan for the choice of phone of subscribers, thedesigner 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 limitedto on street, high density urban or low capacity rural coverage areas. During the early stagesof cellular system implementation, the major concern was trying to provide system coverageinside tunnels.

However, with the advances in technology the hand portable subscriber unit is now firmlyestablished. With this introduction came new problems for the network designer. The portablesubscriber unit provides the user far more freedom of use but the subscriber still expected thesame service. The subscriber now wants quality service from the system at any location. Thislocation can be on a street or any floor of a building whether it is the basement or the penthouseand even in lifts (see Figure 3-18). Thus, greater freedom of use for the subscriber gives thenetwork designer even greater problems when designing and implementing a cellular system.

3-30 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Distribution

Figure 3-18 Subscriber environment

URBAN/CITYENVIRONMENTS

BUILDINGS

LIFTS

RURAL AREAS

TUNNELS

ti-GSM-Subscriber_environment-00188-ai-sw

Distribution

Not only do network designers have to identify the types of subscriber that use the cellularnetwork now and in the future, but also at what location these subscribers are attemptingto use their phones.

Dense urban environments need an entirely different design approach, due to considerationsmentioned earlier in this chapter, than the approach used to design coverage for a sparselypopulated 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 whilethe subscriber is using the network. Even in urban areas, the network designer must be awarethat traffic is not necessarily evenly distributed. As Figure 3-19 illustrates, an urban area cancontain sub-areas of uneven distribution such as a business or industrial district, and has to planfor a seasonal increase of traffic due to, for example, a convention center. It is vitally importantthat the traffic distribution is known and understood before network design, to ensure that asuccessful quality network is implemented.

68P02900W21-T 3-31

Jul 2010

Hand portable subscribers Chapter 3: BSS cell planning

Figure 3-19 Subscriber distribution

RURAL

URBAN

ROAD/RAIL NETWORK

40%

20%10%

EXHIBITIONS

BUSINESS AREAS

INDUSTRIAL

30%RESIDENTIAL

HIGH SPEED MOBILES (RAILWAYS)

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 forthe most demanding subscriber. This is the hand portable subscriber. The hand portable nowrepresents the vast majority of all new subscriber units introduced into cellular networks. Soclearly the network users, and hence the network designers, must recognize this.

Before commencing the network design based around hand portable coverage, the networkdesigner must first understand the limitations of the hand portable unit and second, what thehand portable actually needs from the network.

The hand portable phone is a small lightweight unit, which is easy to carry and has the abilityto be used from any location. The ability of the unit to be used at any location means that thenetwork must be designed with the provision of good in-building coverage as an essentialelement.

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 RFpropagation limitations.

For practical purposes, the actual transmit power of the hand portable should be kept as low aspossible during operation. This helps from not only an interference point of view, but also helpsto extend the available talk time of the subscriber unit, which is limited by battery life.

3-32 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Future planning

Future planning

Normal practice in network planning is to select one point of a well-known re-use model as astarting point. Even at this early stage, the model must be improved because any true trafficdensity 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 trafficwhen leaving city areas. It is uneconomical to build the whole network using a standard cellsize; it becomes necessary to use cells of varying sizes.

Connecting areas with different cell sizes bring about new problems. In principle, it is possibleto use cells of different size side-by-side, but without careful consideration, this leads to awasteful frequency plan. This is because the re-use distance of larger cells is greater than thatof smaller cells. The situation is often that the borders are so close to the high-density areasthat the longer re-use distances mean decreased capacity. Another solution, offering betterfrequency 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 becompleted before it is time to start approaching the next concentration, by gradually decreasingthe cell size. This is why the practical network is not a regular cluster composition, but a groupof directional cells of varying size. Besides this need for cells of different size, the unevennessof the traffic distribution also causes problems in frequency planning. Theoretical frequencydivision methods applicable to homogenous clusters cannot be used. It is rare that two or moreneighboring cells need the same quantity of channels. It must always be kept in mind that thevalues calculated for future traffic distribution are only crude estimates and that the real trafficdistribution always deviates from these estimates. In consequence, the network plan should beflexible 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 experimentingand reiterating. By comparing different alternatives, the network designers should find a planthat both fulfills the given requirements and keeps within practical limitations. When makingnetwork plans, the designers should always remember that every location in a network has itsown conditions, and all local problems must be tackled and solved on an individual basis.

68P02900W21-T 3-33

Jul 2010

Microcellular solution Chapter 3: BSS cell planning

Microcellular solution■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Layered architecture

The basic term layered architecture is used in the microcellular context to explain howmacrocells overlay microcells. It is worth noting that when talking of the traffic capacity of amicrocell 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 cellgives almost total coverage for all the MSs within its area.

Figure 3-20 Layered architecture

TOP VIEW

MACROCELL

SIDE VIEW MACROCELL

MICROCELL A MICROCELL B

MICROCELL A MICROCELL B

ti-GSM-Layered_architecture-00191-ai-sw

3-34 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Combined cell architecture

Combined cell architecture

A combined cell architecture system, as illustrated in Figure 3-21, is a multi-layer system ofmacrocells and microcells. The simplest implementation contains two layers. The bulk of thecapacity in a combined cell architecture is provided by the microcells. Combined cell systemscan 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 fallbackservice for coverage of holes and pockets of interference in the microcell layer. Macrocellsform an umbrella over the smaller microcells.

Microcells: Microcells handle the traffic from slow-moving MSs. The microcells can givecontiguous 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 contiguouscoverage. This structure is shown in Figure 3-22.

68P02900W21-T 3-35

Jul 2010

Expansion solution Chapter 3: BSS cell planning

Figure 3-22 Combined cell architecture structure

SYSTEM 1 = OVERLAY SYSTEM SYSTEM 2 = UNDERLAY SYSTEM

MACROCELL COVERAGE

MICROCELLCOVERAGE

BSC B

BTS 1

BSC A

MSC

BTS 2

BTS 3 BTS 4

BTS 5SYSTEM 1 MACROCELL

SYSTEM 2 MICROCELL

LINK TO IMPLEMENT MICROCELLS AS A SEPARATE SYSTEM

ALTERNATIVE SYSTEM (MICROCELLS CONTROLLED BY THE SAME BSC AS MACROCELLS)

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 oftraffic.

• Microcells can be underlaid into existing networks.

Expansion solution

As the GSM network evolves and matures, its traffic loading increases as the number ofsubscribers grow. Eventually a network reaches a point of traffic saturation. The use ofmicrocells can provide high traffic capacity in localized areas.

3-36 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Expansion solution

The expansion of a BTS site past its original designed capacity can be a costly exercise andthe frequency re-use implications require to be planned carefully (co-channel and adjacentchannel interference). The use of microcells can alleviate the increase in congestion; themicrocells could be stand-alone cells to cover traffic hotspots or a contiguous cover of cells ina combined architecture.

68P02900W21-T 3-37

Jul 2010

Frequency planning Chapter 3: BSS cell planning

Frequency planning■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The ultimate goal of frequency planning in a GSM network is attaining and maintaining thehighest possible C/I ratio everywhere within the network coverage area. A general requirementis 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, andso on) and there is no universal textbook plan that suits every network. Nevertheless, somepractical 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 900MHz and 1800 MHz band per (R)CTU8m. The starting frequency point of the (R)CTU8m workingbandwidth is specified by the CTU8m parameter lowest_arfcn. The (R)CTU8m works from thelowest_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 BCCHand TCH, as shown in Figure 3-23.

Figure 3-23 Separating BCCH and TCH bands

Guard Band

BCCH TCH

n channels m channels

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 issuggested.

3-38 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Rules for Synthesizer Frequency Hopping (SFH)

Figure 3-24 Band usage for macrocells with microcells

Macro BCCH

Micro TCH

Micro Macro TCH

(SFH)BCCH

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 the900 MHz or 1800 MHz band per (R)CTU8m. The serving RF bandwidth during Synthesizerhopping 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 operatingenvironment.

• 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 allocationof 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 (orcarrier-to-frequency ratio). A theoretical maximum of 50% is permitted in 1x3 SFH. Anyvalue higher than 50% would practically result in unacceptable quality. Some commonlyused 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 factor)

• 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 asite.

68P02900W21-T 3-39

Jul 2010

Rules for Synthesizer Frequency Hopping (SFH) Chapter 3: BSS cell planning

NOTE

• Mobile Allocation (MA) is the set of frequencies that the mobile or BTSis allowed to hop over. Two timeslots on the same transceiver of a cell areconfigured to operate on different MAs. MA is the subset of the total allocatedspectrum for the GSM user and the maximum number of frequencies in a MA listis limited to 64 by GSM recommendations.

• Mobile Allocation Index Offset (MAIO) is an integer offset that determineswhich frequency within the MA is the operating frequency. If there are Nfrequencies in the MA list, then MAIO = {0, 1, 2, … N-1}.

• Hopping Sequence Number (HSN) is an integer parameter that determineshow the frequencies within the MA list are arranged. There are 64 HSNs definedby GSM. HSN = 0 sets a cyclical hopping sequence where the frequencies withinthe MA list are repeated in a cyclical manner.

HSN = 1 to 63 provides a pseudo random hopping sequence. The pseudo randompattern repeats itself after every hyperframe, which is equal to 2,715,648 (26 x51 x 2048) TDMA frames, or about 3 hours 28 minutes and 54 seconds.

• Motorola defines a Frequency Hopping Indicator (FHI) that is made up ofthe three GSM defined parameters. Up to 4 different FHIs can be defined for acell in a Motorola BSS and every timeslot on a transceiver can be independentlyassigned one of the defined FHI. MAI is an integer that points to the frequencywithin a MA list, where MAI = 0 and MAI = N-1 being the lowest and highestfrequencies in the MA list of N frequencies. MAI is a function of the TDMAframe 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

Macro BCCH

Micro TCH (SFH)

8 channels

BCCH

Micro Macro TCH

27 channels12 channelsti-GSM-Frequency_split_for_TCH_re-use_planning_example-00196-ai-sw

3-40 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Rules for Synthesizer Frequency Hopping (SFH)

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 hoppingfrequencies per cell. Thus, a total of 27 channels are required for the hopping TCH layer. Theremaining 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 thesame site. The interference (co or adjacent channel) between sites still exists but it is reducedby 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 thehopping frequencies is low. With careful planning, it can be used in high traffic areas aswell.

• BCCH re-use plan: 4X3 or 5X3, depending on the bandwidth available and operatingenvironment.

• The allocation of TCH frequencies to each sector is recommended to be in a regular orcontinuous 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 andco-channel interference between the carriers. Repeated or adjacent MAIOs are not tobe used within the same site to avoid co-channel and adjacent channel interferencerespectively.

• A maximum loading factor of 1/6 or 16.7% is inherent in a continuous sequence offrequency allocation. Since adjacent MAIOs are restricted, the maximum number ofMAIOs permitted is:

MaxMAIOs =12∗ (Total allocated channels)

• 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) Chapter 3: BSS cell planning

Figure 3-26 Avoiding co-channel and adjacent channel interference

Different MAIOs to avoid co-channel interference

Non adjacent MAIOs to avoid adjacent channel interference

HSN = 1HSN = 1

HSN = 1

1 7 13

5 11 173 9 15

ti-GSM-Avoiding_co-channel_and_adjacent_channel_interference-00197-ai-sw

Rules for BaseBand Hopping (BBH)

All the rules outlined for SFH are generally applicable to BBH. As the BCCH is in the hoppingfrequency 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

BBH channels and micro TCH

Micro BCCH

ti-GSM-BBH_frequency_spectrum_allocation-00198-ai-sw

If the ITS feature is unrestricted and enabled, the baseband hopping characteristic is restrictedon the DD CTU2 DRIs of which Carrier A is EGPRS capable. These DRIs do not join the BBHeven if in the database their corresponding ARFCNs are configured in the MA list.

3-42 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Rules for BaseBand Hopping (BBH)

For effective utilization of the ITS feature and to maintain stability, it is recommended to use theparameter re_rtf_id to map the DD CTU2 Carrier A to 64 k RTF and exclude these ARFCNsfrom 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 asymmetricfeature. The element enables or disables support of asymmetric EGPRS for CTU2D on per SITEbasis. The use of this functionality needs that the system remaps its internal TDM allocationsresulting in the removal of BBH support for EDGE (in any mode) for the entire Site. As thisonly impacts Baseband hopping and does not need wholesale configuration changes, the systemsimply 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 thecarrier B, that is, for BBH the system supports hopping for GMSK carriers assigned to Carrier Birrespective 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 BBHhopping group, using the PA bias feature in Horizon II sites with mixed radios will not deliverthe expected power savings.

{34371G} The non-CTU8m and (R)CTU8m radios cannot be mixed in the same BBH hoppinggroup. The non-(R)CTU8m (for example, CTU/CTU2/CTU2D, and so on) radios may reside in thesame cell as CTU8m / RCTU8m radios, but must use their own hopping group, that is, differentFHI groups for legacy and CTU8m/RCTU8m radios.

{34371G} There is an RF bandwidth constraint of 20 MHz contiguous coverage in either the900 MHz or 1800 MHz band per (R)CTU8m. The serving RF bandwidth during the basebandhopping 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 includesf3, 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 MHzlimitation. For CTU8m #2, the software ensures that (<f3, f4, f5, f6>, f7, f8) are within the20 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 boththe 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 (bysetting preferred RTF in DRI equipage) as given in the following table to enable hopping.

Table 3-4 RTF-DRI mapping

CTU8m #1 CTU8m #2

<f3, f4, f5, f6> f1, f2, f7, f8

68P02900W21-T 3-43

Jul 2010

Inter-radio access technology (2G-3G) cell reselection and handovers Chapter 3: BSS cell planning

Inter-radio access technology (2G-3G) cell reselectionand handovers

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

An optional feature is supported for handovers and cell reselection between different RadioAccess Technology (RAT) networks in the circuit and packet switched domain. The RAT canbe 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 isdescribed here. For further information on UMTS, refer to System Information: UMTSEquipment Planning, 68P02905W22.

2G-3G handover description

The 2G-3G handover feature supports handovers between different RAT networks. The RAT canbe either 2G/2.5G (GSM/GPRS/EDGE) or 3G (UMTS).

Current evolving 3G UMTS networks soon allow operators to provide UMTS coverage alongwith GSM/GPRS/EGPRS coverage in their networks.

This feature enables a multi-RAT MS (a mobile station that can function in multiple RadioAccess Networks RANs) to either reselect or handover between a GSM RAN(GERAN) and aUMTS 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 withinlarger GSM coverage areas. In such an environment the call would drop when a UMTSsubscriber goes out of a UMTS coverage area and into a GSM coverage area.

3-44 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Impact of 2G-3G handovers on GSM system architecture

Congestion in the smaller UMTS areas could become a problem when the traffic in the UMTScoverage area is high. A GSM subscriber may wish to access a service with specific QoScharacteristic (for example, high bit rate data service) that may not be supported in the GSMsystem.

To avoid these problems the operator may wish to configure their network such that handoverand cell reselection between UMTS and GSM is possible. The GSM BSS inter-RAT handoverfunction provides a solution to these problems by allowing a multi-RAT MS to perform cellreselection 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

GSM Core Network (MSC/GSN)

BSS

BSC

GSM/GPRS UTRAN

UMTS Core Network (3G MSC/SGSN)

PCU

BTS BTS

Abis

Multi-RAT MS

Iub

Node B

RNS RNS

RNC RNC

Node B

Iur

Iub

E-Interface

Gn-Interface

Um

Gb-InterfaceA-Interface Iu-Cs-Interface

Iu-Ps--Interface

Uu

ti-GSM-GSM_and_UMTS_system_nodes_and_interfaces-00199-ai-sw

68P02900W21-T 3-45

Jul 2010

System consideration Chapter 3: BSS cell planning

System consideration

Existing 2G CoreNetwork (CN) nodes must be able to interact with the 3G CN nodes throughMAP 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:

• 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.

3-46 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 andsupports the following functions:

• GSM/GPRS to TD-SCDMA cell reselection in circuit-switched idle mode and packet idlemode by broadcasting TD-SCDMA neighbor list and corresponding 3G measurementparameters 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 fromthe OMC-R. A GSM cell can have up to 16 TD-SCDMA neighbors. The total TDD-ARFCN per GSMcell 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 enabledin an Incell cabinet.

Limitations

This feature can be enabled only if the Inter-RAT Handover and Enhanced 2G/3G Inter-RAThandover features are restricted.

68P02900W21-T 3-47

Jul 2010

Call model parameters for capacity calculations Chapter 3: BSS cell planning

Call model parameters for capacity calculations■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

This section provides information on how to determine the number of control channels requiredat a BTS. This information is required for the sizing of the links to the BSC, and is required whencalculating 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; typicalcall 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

Number of handovers per call H = 3.54

Ratio of location updates to calls: non-borderlocation area

l = 2.73

Ratio of location updates to calls: borderlocation area

l = 7

Ratio of IMSI detaches to calls I = 0.05

Location update factor: non-border locationarea using IMSI type 2

L = l + 0.5I = 2.75

Location update factor: border location areausing IMSI type

2 L = l + 0.5I = 7.02

GSM circuit-switched paging rate in pages persecond

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) forGPROC2/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

System Information: BSS Equipment Planning Typical call parameters

Table 3-5 Typical parameters for BTS call planning (Continued)

Busy hour peak signaling traffic model 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 <-> frhandover

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 (persub/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 theRLC/MAC layer

CS1 = 9.2 kbpsCS2 = 13.6 kbpsCS3 = 15.8 kbpsCS4 = 21.8 kbps

Continued

68P02900W21-T 3-49

Jul 2010

Typical call parameters Chapter 3: BSS cell planning

Table 3-5 Typical parameters for BTS call planning (Continued)

Busy hour peak signaling traffic model Parameter reference

Coding scheme usage (CS1 to CS4) at a BLERof 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%CS4_usage_UL = 45.5%CS4_usage_DL = 35.5%

Percentage GPRS coding scheme usage intotal 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 toMCS-9) at the RLC/MAC layer

MCS1 = 10.55 kbpsMCS2 = 12.95 kbpsMCS3 = 16.55 kbpsMCS4 = 19.35 kbpsMCS5 = 23.90 kbpsMCS6 = 29.60 kbpsMCS7 = 31.10 kbpsMCS8 = 46.90 kbpsMCS9 = 61.30 kbps

Coding scheme usage (MCS1 to MCS9) at aBLER of 12.02%

MCS1_usage_UL = 0.5%MCS1_usage_DL = 11%MCS2_usage_UL = 2%MCS2_usage_DL = 12%MCS3_usage_UL = 4.5%MCS3_usage_DL = 8.5%MCS4_usage_UL = 5.5%MCS4_usage_DL = 7%MCS5_usage_UL = 15.5%MCS5_usage_DL = 5%MCS6_usage_UL = 47.75%MCS6_usage_DL = 19%MCS7_usage_UL = 3.5%MCS7_usage_DL = 8%MCS8_usage_UL = 8.5%MCS8_usage_DL = 8%MCS9_usage_UL = 12.25%MCS9_usage_DL = 21.5%

Percentage EGPRS coding scheme usage intotal traffic

CSuse_UL_EGPRS = 12.1%CSuse_DL_EGPRS = 9.9%

Continued

3-50 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Typical call parameters

Table 3-5 Typical parameters for BTS call planning (Continued)

Busy hour peak signaling traffic model Parameter reference

Average packet size for GPRS and EGPRStraffic mix (bytes) – Uplink

PKULSIZE = 130.75

Average packet size for GPRS and EGPRStraffic 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 handoversinclude 2G-3G handovers.

• The percentages represent the split of the traffic between the GPRS and EGPRStraffic mix which is network-dependent. The percentages can be used todetermine the average traffic per sub/BH for a GPRS and EGPRS traffic mix asfollows:

Traffic per subscriber/BH for GPRS and EGPRS mix (kBytes/hr) =(Percentage GPRS coding scheme usage in total traffic * GPRS Trafficper 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 theGPRS and EGPRS percentage splits defined for this model.

• An MS in the extended range has a lower coding scheme than in the normalrange due to the longer distance between the MS and BTS. For the cell withextended PDCH, the lower coding scheme has a higher usage percentage valuethan 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 ratioof IMSI detaches to calls (I) and whether the short message sequence (type 1) or long messagesequence (type 2) is used for IMSI detach; typically I = 0 (that is IMSI detach is disabled) as inthe first formula given . When IMSI detach is enabled, the second or third of the formulas givenshould 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 Chapter 3: BSS cell planning

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/EGPRSrelease.

• 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 eitheruplink or downlink directions.

Packet Data Traffic CHannel (PDTCH)

A PDTCH corresponds to the resource allocated to a single MS on one physical channel foruser data transmission.

3-52 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 isperforming a packet transfer.

• Packet Timing advance Control CHannel (PTCCH/U)

Uplink channel, used to transmit random access bursts. The transceiver uses these burststo 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 sametime.

Planning considerations

In planning the GSM/GPRS/EGPRS control channel configuration, the network planner mustconsider 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, theuplink 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 andGPRS/EGPRS occur on the CCCH. When PCCCH is enabled, control signaling for GPRS/EGPRSoccurs on the PCCCH instead of the CCCH. Thus, CCCH signaling decreases when PCCCH isenabled. 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 theplanner decides to use paging coordination (also called Network Operation Mode I), then an MSonly needs to monitor the paging channel on the PCCCH, and receives circuit-switched pageson the PACCH when it has been assigned a PDTCH. If the planner decides not to use pagingcoordination (called Network Operation Mode III), the MS that needs to receive pages forboth circuit-switched and packet-switched services should monitor paging channels on bothPCCCH and CCCH.

NOTENetwork Operation Mode II is currently not supported in the Motorola BSS.

68P02900W21-T 3-53

Jul 2010

Combined BCCH Chapter 3: BSS cell planning

CCCH and PCCCH decision tree

Figure 3-29 summarizes the decisions used to determine which planning steps should be used todetermine the CCCH and PCCCH signaling capacity requirements.

Figure 3-29 CCCH and PCCCH decision tree

(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.pccch_enabled = 0

pccch_enabled = 1

ti-GSM-CCCH_and_PCCCH_decision_tree-00201ai-sw

Combined BCCH

This planning guide provides the planning rules that enable the network planner to evaluatewhether a combined BCCH can be used, or if a non-combined BCCH is required. The decisionto use a non-combined BCCH is a function of the number of CCCH channels required and thenumber of SDCCH channels required.

The use of a combined BCCH is desirable because it permits the use of only one timeslot ona carrier that is used for signaling. A combined BCCH can offer four more SDCCH blocks foruse by the GSM circuit-switched signaling traffic. If more than an average of three CCCHblocks, or more than four SDCCH blocks, are required to handle the signaling load, morecontrol channel timeslots are required.

The planning approach for GPRS/EGPRS/GSM control channel provisioning is to determinewhether a combined BCCH is possible, given the load on the CCCH control channel. When morethan three and less than nine CCCH blocks are required to handle the combined load, the use ofa combined BCCH is not possible. When more than nine CCCH blocks are needed, one or moretimeslots are required to handle the CCCH signaling. In this case, it is advantageous to use acombined BCCH again, depending on the CCCH and SDCCH load.

The determination of how many CCCH and SDCCH blocks are required to support thecircuit-switched GSM traffic is deferred to the network planning that is performed with the aidof the relevant planning information for GSM. The network planning that is performed using theplanning information determines how many CCCH and SDCCH blocks are required, and thenhow many timeslots in total are required to support the CCCH and SDCCH signaling load.

3-54 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Number of CCCHs and PCCCHs per BTS cell

Number of CCCHs and PCCCHs per BTS cell

The following factors should be considered when calculating the number of CCCHs per BTS cellare 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/EGPRScontrol signaling from the CCCH. Further, if paging coordination is also enabled, GSM CSpaging 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 controlchannels are added, in order, on timeslots 2, 4, and 6 of the BCCH carrier, thus creatingcells with 18, 27, and 36 CCCH blocks. These configurations would only be required forhigh 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 is4.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 is4.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 rejectmessages for GSM MSs and, if PCCCH is not enabled, GPRS/EGPRS MSs. Each AGCHimmediate assignment message can convey channel assignments for up to two MSs. EachAGCH immediate assignment reject message can reject channel requests from up to fourMSs.

• The PCH is used to send GSM paging messages and, if PCCCH is not enabled, GPRS/EGPRSpaging messages. Each PCH paging message can contain pages for up to four MSsusing TMSI or two MSs using IMSI. If no paging messages are to be sent in a particularCCCH block, then an immediate assignment or immediate assignment reject messagecan be sent instead.

68P02900W21-T 3-55

Jul 2010

Number of CCCHs and PCCCHs per BTS cell Chapter 3: BSS cell planning

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 immediateassignment reject messages are sent on that CCCH subchannel. Hence the option toreserve CCCH channels for AGCH.

• It can normally be assumed that sufficient capacity exists on the uplink CCCH (RACH) oncethe 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 onlyneeds to listen to the PCH subchannel corresponding to that group. Paging group sizeis 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, butas a consequence it takes longer to page that MS, resulting in slower call set-upas 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 minimizingthe interruptions of uplink data flow in GPRS/EGPRS networks due to a frequent releaseand establishment of uplink TBF. According to the principle of Extended Uplink TBF, thisfeature decreases the amount of RACH for uplink applications session like uplink FTP. Ifthe uplink application is rare, total amount of decreased RACH is small. Thus the impact ofRACH decrement can be ignored, if the uplink application is booming and total amount ofdecreased RACH is huge, otherwise the impact of RACH decrement cannot be ignored andRACH decrement is taken into account for CCCHs calculation.

• Precise determination of the CCCH requirements is difficult. However, some statistics canbe collected (for example ACCESS_PER_PCH, ACCESS_PER_AGCH) by the BSS and can beused 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 CCCHis 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 isperformed by adding the estimated GPRS/EGPRS and GSM paging blocks for the BTS cell tothe estimated number of GPRS/EGPRS and GSM access grant blocks for the BTS cell, anddividing that sum by the CCCH utilization factor.

3-56 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Number of CCCHs and PCCCHs per BTS cell

NOTEIntroducing the GPRS/EGPRS feature into a cell may cause noticeable delays forpaging in that cell. Motorola advises operators to re-check the NPAGCH and NPCHequations provided here when adding GPRS/EGPRS to a cell. Enable PCCCH incells with heavy paging.

The following planning actions are required:

NOTEIn the following paragraphs, GPRS notation represents GPRS/EGPRS.

Determine the number of CCCHs per BTS. The average number of blocks required to supportAGCH and PCH is given by the following equation:

NPCH−AGCH−NCH = NPCH +NAGCH +NNCH

The average number of blocks required to support AGCH and PCH is given by the followingequation:

NPCH+AGCH =NAGCH +NPCH

UCCCH

The average number of blocks required to support AGCH only is given by the following equation:

NAGCH = +NAGCH GSM +NAGCH GPRS

The average number of blocks required to support AGCH for GSM traffic is given by thefollowing equation:

NPCH+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 givenby the following equation:

NAGCH GPRS =RACHAArrivals/Sec ∗ 1.1

4.25

68P02900W21-T 3-57

Jul 2010

Number of CCCHs and PCCCHs per BTS cell Chapter 3: BSS cell planning

Where:

RACHA−Arrivals−per−sec =GPRS−Users ∗Avg−Sessions−per−user

3600

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 ∗ eT

The SMS rate (SMSs per hour) is given by the following equation:

λS = S ∗ eT

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:

NPCH = +NPCH GSM +NPCH GPRS

The average number of blocks required to support GSM CS paging only is given by the followingequation:

NPCH GSM =PGSM

NPages/Block ∗ 4.25

The number of pages per paging PCH block depends on whether paging is performed usingTMSI 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:

NPCH GPRS =PGPRS ∗ 1.2

4.25

3-58 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Number of CCCHs and PCCCHs per BTS cell

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 average number of sessions originated by user per busy hour(this includes the sessions for signaling).

lcall call arrival rate per second.

lL location update rate per second.

lS number of SMSs per second.

e number of Erlangs per cell.

T average call length, in seconds.

PGSM number of GSM circuit-switched traffic pages transmitted toa BTS cell per second.

PGPRS number of GPRS or EGPRS pages transmitted to a BTS cellper 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 timeslotmay or may not be required, dependingon the support of circuit-switched trafficwhere 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, 9CCCH

Non-combined BCCH. This is an exampleof one extra timeslot of CCCHs addedin support of GPRS traffic. The value ofN 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 becomesrelevant 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 bothGSM 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 thePCCCH. Hence, the following planning rules should be used.

The average number of blocks required to support AGCH and PCH is given by the followingequation:

NPCH+AGCH = (NAGCH +NPCH)1

UCCCH

68P02900W21-T 3-59

Jul 2010

Number of CCCHs and PCCCHs per BTS cell Chapter 3: BSS cell planning

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

The access grant rate is given by the following equation:

λAGCH = λCALL + λL + λS + λLCS

The access grant rate is given by the following equation:

λcall =e

T

The location update rate (LU per hour) is given by the following equation:

λL = L ∗ eT

The SMS rate (SMSs per hour) is given by the following equation:

λS = S ∗ eT

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 pagingcoordination in the cell. If paging coordination is not enabled then the average number of blocksrequired to support GSM CS paging is given by the following equation:

NPCH =PGSM

NPages/Block ∗ 4.25

If paging coordination is enabled, the average number of blocks required to support GSMCS paging is given by the following equation:

NPCH =

[NGSM Only MS

NGSM Capable MS

]∗ PGSM

NPages/Block ∗ 4.25

The number of pages per paging PCH block depends on whether paging is performed usingTMSI or IMSI.

3-60 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Number of CCCHs and PCCCHs per BTS cell

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 thefollowing equation:

NPCH GPRS =PGPRS ∗ 1.2

4.25

Where: Is:

UCCCH CCCH utilization.

lAGCH access grant rate (per second).

P paging rate per second.

lcall call arrival rate per second.

lL location update rate per second.

lS number of SMSs per second.

e number of Erlangs per cell.

T average call length, in seconds.

PGSM the number of GSM circuit-switched traffic pages transmitted toa 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 mobilesin the system minus the number of GPRS/EGPRS-only mobilesin the system.

The network planner can provision up to 1 PCCCH timeslot per BTS cell. If the PCCCH isenabled, then the PCCCH occupies a reserved PDTCH timeslot on the BCCH carrier. Theuse_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 isused, the PCCCH/PBCCH can be enabled if BCCH carrier is part of the hopping system andTS1 of the BCCH carrier is a non-hopping timeslot. Hopping can be enabled on TS2 to TS7of the BCCH carrier while PCCCH/PBCCH is enabled and TS1 is configured or allocated asPCCCH/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 cell’s bs_prach_blks parameter. Any uplink PCCCHblocks 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 logicalchannels: PBCCH, PPCH, PAGCH, and PDTCH. Allocation among these channels is a trade-offbetween the following factors:

• The PPCH and PAGCH capacity required for the cell.

• The delay required for mobiles to acquire PBCCH system information upon entering thecell. This delay is directly related to the delay before a mobile can start a data sessionfollowing cell selection.

• The PDTCH capacity available on the PCCCH timeslot.

68P02900W21-T 3-61

Jul 2010

Number of CCCHs and PCCCHs per BTS cell Chapter 3: BSS cell planning

PBCCH blocks are reserved using the bs_pbcch_blks parameter. PAGCH blocks can bereserved using the bs_ag_blks_res parameter. All other downlink PCCCH blocks can be usedfor the PPCH, but there is no parameter to reserve PPCH blocks. Nevertheless, the networkplanner should calculate the number of PPCH blocks required in a BTS cell to determine howmany blocks can be allocated to PBCCH blocks.

Any downlink PCCCH blocks that are not reserved for PBCCH, can be used for user datatransmission when not being utilized for control signaling. The PCCCH timeslot is used for userdata for up to 2 mobiles.

For the subsequent calculations, the message capacity for each PCCCH block is 1 message per0.240 second.

Calculating the number of PRACH blocks per BTS cell

The network planner should use the average number of blocks necessary to support PRACHto set the cell’s bs_prach_blks parameter.

NOTEIn the following paragraphs, GPRS notation represents GPRS/EGPRS.

bs_prach_blk = Roundup(NPRACH)

The average number of blocks required to support PRACH is given by the following equation:

NPRACH =GPRS−RACH/Sec ∗ 0.24

UPCCCH

The average number of PRACH arrivals per second is given by the following equation:

GPRS−RACH/Sec =GPRS−Users ∗Avg−Sessions−per−user

3600

Where: Is:

UCCCH desired PCCCH utilization.

GPRS_RACH/sec GPRS/EGPRS random access rate (per second).

GPRS_Users number of GPRS and EGPRS users on a cell.

Avg_Sessions_per_user average number of sessions originated by user per busy hour(this includes the sessions for signaling).

3-62 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Number of CCCHs and PCCCHs per BTS cell

Calculating the number of PAGCH blocks per BTS cell

The network planner should use the average number of blocks necessary to support PAGCHto set the cell’s 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:

NPAGCH =GPRS−RACH/Sec ∗ 1.1 ∗ 0.24

UPCCCH

The average number of RACH arrivals per second is given by the following equation:

GPRS−RACH/Sec =GPRS−Users ∗Avg−Sessions−per−user

3600

Where: Is:

UCCCH desired PCCCH utilization.

GPRS_RACH/sec GPRS/EGPRS random access rate (per second).

GPRS_Users number of GPRS and EGPRS users on a cell.

Avg_Sessions_per_user average number of sessions originated by user per busy hour(this includes the sessions for signaling).

Calculating the number of PPCH blocks per BTS cell

The average number of blocks required to support PPCH is given by:

NPPCH =NPPCH−GSM +NPPCH−GPRS

UPCCCH

NOTEIn the following paragraphs, GPRS notation represents GPRS/EGPRS.

If paging coordination is not enabled in the network, then the average number of PPCH blocksrequired to support GSM CS paging only is zero:

NPPCH−GSM = 0

68P02900W21-T 3-63

Jul 2010

Number of CCCHs and PCCCHs per BTS cell Chapter 3: BSS cell planning

If paging coordination is enabled, then the average number of blocks required to support PPCHis given by the following equation:

NPPCH−GSM =NGSM−GPRS MS

NALL−MS∗ PGSM ∗ 0.24

The average number of PPCH blocks required to support GPRS/EGPRS paging only is givenby the following equation:

NPPCH−GSM = PGPRS ∗ 1.2 ∗ 0.24

Where: Is:

UCCCH desired PCCCH utilization.

NGSM_GPRS_MS number of mobiles in the system that are capable of both GSM andGPRS/EGPRS services.

NALL_MS total number of mobiles in the system.

PGSM number of GSM circuit-switched traffic pages transmitted to a BTS cell persecond PGPRS number of GPRS/EGPRS pages transmitted to a BTS cell persecond.

NOTEWhen GSM CS paging load becomes heavy and paging coordination is enabled, thePPCH 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 downlinkPCCCH by setting the cell’s bs_pbcch_blks parameter.

An allocation of 4 PBCCH blocks minimizes the time required for the mobile to acquire theGPRS/EGPRS broadcast system information of the cell. In turn, this minimizes the delay beforethe mobile can start data transmission upon cell selection or reselection. An allocation of1 PBCCH block minimizes the radio resources consumed by PBCCH, freeing up more radioresources for PAGCH, PPCH, and user data transmission. Thus choosing the number of PBCCHblocks per BTS cell is a trade-off between the data transmission delay following cell selection orreselection 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 (NPAGCH)−Roundup (NPPCH)

3-64 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning User data capacity on the PCCCH timeslot

So, the network planner must select the number of PBCCH block (NPBCCH) such that it doesnot exceed the blocks available (maximum of 4 blocks). The network planner must also considerthe trade-off with PDTCH capacity on the PCCCH timeslot.

It is recommended that the network planner maximize the PBCCH blocks instead of PDTCHcapacity on the PCCCH timeslot. The PCCCH timeslot is only used for PDTCHs during conditionsof cell congestion. Therefore, the network planner can improve the user experience more bymaximizing the PBCCH blocks and consequently minimizing data transmission delay followingcell selection or reselection. The network user chooses to prioritize PDTCH capacity when onlya 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 radioblocks 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. Theformulas given can be use to estimate the raw data capacity of the PCCCH timeslot. The rawdata 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−NPBCCH −NPAGCH −NPPCH

12∗ TS Data Rate

The raw uplink PDTCH capacity is given by the following equation:

Uplink Capacity =12−Roundup (NPRACH)

12∗ TS Data Rate

Where: Is:

TS_Data_Rate average data rate of the PCCCH timeslot based on the expected radioconditions 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 carrierso that CS4 is used 80% of the time and CS3 is used 20% of the time. The network planner alsocalculates the following when dimensioning the PCCCH:NPAGCH = 2NPPCH = 3NPBCCH = 4

68P02900W21-T 3-65

Jul 2010

Number of SDCCHs per BTS cell Chapter 3: BSS cell planning

In this case, the average data rate is calculated as follows:

TS Data Rate = 0.80 ∗ 20 + 0.2 ∗ 14.6 = 18.92Kbits/s

So the raw data capacity for the downlink PCCCH can be calculated using the following equation:

Downlink Capacity =12− 4− 2− 3

12∗ 18.92 = 4.73Kbits/s

Number of SDCCHs per BTS cell

Determining the SDCCH requirement is an important part of the planning process. The SDCCHis where a large portion of signaling and data messaging takes place for SMS, location updateand call set-up. As the number of calls taking place in a BTS increases, greater demand is placedon 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 onthe establishment cause. That is, TCH directly to the MS if the MS intends to make aspeech call, or SDCCH if the MS intends to send an SMS. The user configurable parameterTCH_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 thisfeature off.

By reviewing the collected network statistics GTTP_UL_LLC and GTTP_DL_LLC on a continuousbasis, the network planner can tune the Max_Lapdm parameter, as well as the SDCCHconfiguration. Based on the analysis, the GTTP has only minor impact on SDCCH planning.

NOTEConsidering the impact to voice quality from GTTP signaling, set Max_Lapdmparameter to the default value of 5.

The following factors should be considered when calculating the number of SDCCH per BTS cell:

• To determine the required number of SDCCHs for a given number of TCHs per cell, thecall, location update, and SMS (point to point) rates must be determined. A TCH is directlyallocated to the MS for a speech call when the Fast Call Setup feature is turned on. TheSDCCH usage drops require to be accounted for. Refer to the equations for information oncalculating these rates. Once these rates are determined, the required number of SDCCHsfor the given number of TCHs can be determined. Refer to the equations for informationon 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 thenetwork is configured to send SMS over GPRS, SMS does not need the use of an SDCCH.

3-66 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Number of SDCCHs per BTS cell

• 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 arecombined 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 supportedby a given cell, based on the number of TCHs in that cell. To determine the number ofErlangs supported by a cell, use Erlang B.

• The number of TCHs in a cell vary depending upon the number of carriers that are (AMR orGSM) half rate capable. The number of calls that use the half rate capable carriers variesdepending upon such factor as cell loading, mobile penetration and so on. In Table 3-8and Table 3-9, a worst case scenario is assumed, where all half rate capable carriersare used as half rate.

NOTENot 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 callduration).

• Use Erlang B (on the value of NSDCCH) to determine the required number of SDCCHsnecessary 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

LOCATION AREA

BORDER BTS =

INNER BTS =

ti-GSM-Location_area_diagram-00202-ai-sw

68P02900W21-T 3-67

Jul 2010

Number of SDCCHs per BTS cell Chapter 3: BSS cell planning

Calculating the number of SDCCHs per BTS cell

Determine the number of SDCCHs per BTS cell. The average number of SDCCHs is givenby the following equation:

NSDCCH = λCall ∗ Tc ∗ Tu + λL ∗ (TL + Tg) + λS ∗ (TS + Tg) + λLCS ∗ (TLCS + Tg)

Where: Is:

NSDCCH average number of SDCCHs.

lcall call arrival rate per second.

Tc time duration for call set-up.

Tu the Fast Call Setup component. This is set to 1 if Fast Call Setup is disabledor 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 number of SMSs per second.

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 onthe following parameter settings:

• Per carrier db parameter sd_priority: The parameter sd_priority takes a value in therange 0 to 250, and this assigns a priority value to the carrier (RTF); the lower the prioritythe higher the possibility to get an SDCCH in the carrier (RTF).

• PBCCH: If PBCCH is configured, the NON BCCH carrier has preference over the BCCHcarrier.

• Number of available TCH barred timeslots: Available TCH barred timeslots are TCH barredtimeslots which are not configured as SDCCH timeslots yet. TCH or PDTCH cannot beconfigured on a TCH barred timeslot since it does not have a terrestrial backhaul. It canonly 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 ifthe RTF can carry GPRS/EDGE or not. Carriers with lower pkt_radio_type are preferredover carriers with higher pkt_radio_type.

• Half Rate: Non Half Rate carriers are preferred over Half Rate capable carriers.

3-68 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Control channel configurations

• SDCCH loading (Not the db parameter sd_load, but the actual number of SDCCHtimeslots configured). Carriers with fewer sdcch loading are selected over carriers withhigher sdcch loading so that SDs get distributed among carriers with identical SD-relatedparameters. The db parameter sd_load determines the number of timeslots in the carrierthat can be SDCCH. This can take a value of 0 through 8; that is, up to 8 timeslots can beconfigured as SDCCH in a single carrier.

• Carrier id: Carrier id is used as a tie breaker among two carriers. Carrier with lowercarrier 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 TSis allowed on the BCCH Carrier. This can be achieved by setting sd_load parameter for BCCHRTF to 1. A maximum of 3 SDCCH TS on other carriers are recommended, though 2 SDCCH TSis 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 systeminitialization time.

When channel_reconfiguration_switch is enabled, then based on SDCCH usage, the TCH inthe 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 begreater 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 ofSDCCH/ cell

SDCCHon BCCHcarrier

SDCCHon secondcarrier

SDCCH onthird carrier

SDCCHon fourthcarrier

SDCCH onfifth carrier

SDCCHon sixthcarrier

60 12 16 16 16 - -

64 8 16 16 16 8 -

92 12 16 16 16 16 16

Control channel configurations

Table 3-8 and Table 3-9 give typical control channel configurations based on the typical BTSplanning parameters given in Table 3-5. Due to the many combinations of half rate capableRTFs, only a partial listing is depicted.

68P02900W21-T 3-69

Jul 2010

Control channel configurations Chapter 3: BSS cell planning

Control channel configurations for non-border location area

Table 3-8 shows the configurations for non-border location area cell, where the ratio of locationupdates to calls is 2.

Table 3-8 Control channel configurations for non-border location area

Number ofRTFs

Number ofTCHs

Number ofErlangs

Number ofSDCCHs Timeslot utilization

Timeslot 0 Other timeslots

1 fr 7 2.94 4 1 BCCH +3 CCCH+4 SDCCH

N/A

1 hr 12 6.61 8 1 BCCH + 9 CCCh 8 SDCCH

2 fr 14 8.20 9 1 BCCH + 3 CCCH+4SDCCH

8 SDCCH

1 fr1 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 fr1 hr

29 21.03 16 1 BCCH + 9 CCCH 2 * 8 SDCCH

1 fr2 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 fr1 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 fr1 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

System Information: BSS Equipment Planning Control channel configurations

Table 3-8 Control channel configurations for non-border location area (Continued)

Number ofRTFs

Number ofTCHs

Number ofErlangs

Number ofSDCCHs Timeslot utilization

Timeslot 0 Other timeslots

6 fr 44 34.7 24 1 BCCH + 9 CCCH 3 * 8 SDCCH

5 fr1 hr

51 41.2 28 1 BCCH + 9 CCCH 4 * 8 SDCCH

3 fr3 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

NOTEThe 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 oflocation updates to calls is 7.

Table 3-9 Control channel configurations for border location area

Timeslot utilizationNumberof RTFs

Numberof TCHs

Number ofErlangs

Number ofSDCCHs Timeslot 0 Other

timeslots

1 fr 6 2.28 7 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 fr1 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 fr1 hr

27 19.3 27 1 BCCH + 9 CCCH 4 * SDCCH

1 fr2 hr

34 25.5 34 1 BCCH + 9CCCH 5 * 8 SDCCH

Continued

68P02900W21-T 3-71

Jul 2010

Control channel configurations Chapter 3: BSS cell planning

Table 3-9 Control channel configurations for border location area (Continued)

Timeslot utilizationNumberof RTFs

Numberof TCHs

Number ofErlangs

Number ofSDCCHs 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 fr1 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 fr1 hr

49 39.3 48 1 BCCH + 9 CCCH 6 * 8 SDCCH

3 fr3 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 tolowest value and set sd_load to 0 for both carrier A and B.

3-72 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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) tothe system. The next step is to determine the effective load to the system by weighing theapplied load by network operating parameters. These parameters consist of the expectedBLock Error Rate (BLER) based on the cell RF plan, the protocol overhead (GPRS/EGPRSprotocol stack, that is TCP/IP, LLC, SNDCP, RLC/MAC), the expected advantage from V.42biscompression, SIP signaling compression and TCP/IP header compression, and the multislotoperation of the mobiles and infrastructure.

The effective load at a cell is used to determine the number of GPRS timeslots required toprovision a cell. The provisioning process can be performed for a uniform load distributionacross 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 BSSprovisioning 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, andGSN (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 usesswitchable timeslots that can be shared by both the GSM circuit-switched infrastructureand by the GPRS/EGPRS infrastructure, much of the content is dedicated to the discussionof this topic.

• GPRS/EGPRS air interface planning process

This provides a table of inputs that can serve as a guide in the planning process. Insubsequent planning sections, references are made to parameters in this table of inputs. Akey piece of information that is required for the planning process is the RF cell plan. Thissubsection discusses the impact of different cell plans on the GPRS/EGPRS provisioningprocess, and how to use this information to determine the number of GPRS/EGPRStimeslots that are required on a per cell basis.

68P02900W21-T 3-73

Jul 2010

GPRS/EGPRS network traffic estimation and key concepts Chapter 3: BSS cell planning

GPRS/EGPRS network traffic estimation and keyconcepts

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

NOTEPacket data notation is interchangeably used in this section.

The GPRS/EGPRS network planning is fundamentally different from the planning ofcircuit-switched networks. One of the fundamental reasons for the difference is that aGPRS/EGPRS network allows the queuing of data traffic instead of blocking a call when acircuit is unavailable. Consequently, the use of Erlang B tables for estimating the number oftrunks or timeslots required is not a valid planning approach for the GPRS/EGPRS packetdata provisioning process.

The GPRS/EGPRS traffic estimation process starts by looking at the per cell GPRS/EGPRSdata traffic profile such as fleet management communications, E-mail communications, webbrowsing, audio/video playing, PoC service and large file transfers. Once a typical data trafficprofile mix is determined, the required network throughput per cell can be calculated asmeasured in kbps. The desired network throughput per cell is used to calculate the number ofGPRS/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 delaybetween 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 fileof 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 GSMcircuit-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 istransporting voice or data. In idle mode, the network knows where the MS is, but there isno circuit assigned. In GPRS/EGPRS mode, a subscriber uses the infrastructure timeslotsfor carrying data only when there is data to be sent. However, the GPRS/EGPRS subscriber

3-74 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Introduction

can be attached and not sending data, and this still presents a load to the GSN part of theGPRS/EGPRS system, which must be accounted for when provisioning the GPRS infrastructurein state 2 as explained.

The GPRS/EGPRS mobile states and conditions for transferring between states are provided inTable 3-10 and shown in Figure 3-31 to specify when infrastructure resources are being used totransfer data. The comment column specifies what the load is on the infrastructure equipmentfor 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 theGPRS/EGPRS network that is in state 2, than there is bandwidth available to simultaneouslytransfer data. One of the more significant input decisions for the network planning process isto determine and specify how many of the attached MSs are actively transmitting data in theReady state 3. In the Standby state 2, no data is being transferred but the MS is using networkresources to notify the network of its location. The infrastructure has equipment limits as tohow many MSs can be in state 2. When the MS is in state 1, the only required infrastructureequipment support is the storage of MS records in the HLR.

Network provisioning needs planning for traffic channels and for signaling channels, alsoreferred to as control channels. The BSS combines the circuit-switched and GPRS controlchannels together as BCCH/CCCH. The software provides the option of configuring thePBCCH/PCCCH for GPRS/EGPRS control channels.

Table 3-10 MM state model of MS

Presentstate

number

Presentstate Next state Condition for state

transfer Comments (present state)

1 READY(3) IDLE GPRS/EGPRS Attach Subscriber is not monitoredby the infrastructure that isnot attached to GPRS/EGPRSMM, and therefore does notload the system other thanthe HLR records.

2 READY(3) STANDBY PDU Transmission Subscriber is attached toGPRS/EGPRS MM and isbeing actively monitored bythe infrastructure that isMS and SGSN establish MMcontext for subscriber IMSI,but no data transmissionoccurs in this state.

3 IDLE(1)S READY GPRS/EGPR Detach Data transmission throughthe infrastructure occurs inthe Ready state.

3 STANDBY(2) READY Ready timer expiryor force to Standby(network or the MScan send a GMMsignaling messageto invoke force toStandby).

The ready timer (T3314)default time is 32 seconds.The timer value can bemodified during the signalingprocess by MS request.2 - 60s in 2 s increments or 61 -1800 s in 60 s increments.

The MS and SGSN state models are illustrated in Figure 3-31.

68P02900W21-T 3-75

Jul 2010

Dynamic timeslot allocation Chapter 3: BSS cell planning

Figure 3-31 MM state models for MS and SGSN

orCancel Location

GPRS Attach

READY timer expiryorForce to STANDBY

STANDBY timerexpiry

GPRS Detach GPRS Attach

PDU reception

GPRS Detachor

Cancel Location

MM State Model of MS MM State Model of SGSN

IDLE

READY

STANDBY

IDLE

READY

STANDBY

READY timer expiryorForce to STANDBYorAbnormal RLC condition

STANDBY timer expiry

PDU transmission

ti-GSM-MM_state_models_for_MS_and_SGSN-00203-ai-sw

Dynamic timeslot allocation

This section proposes a network planning approach when utilizing dynamic timeslot modeswitching of timeslots on a carrier with GPRS/EGPRS timeslots. The radio interface resourcescan be shared dynamically between the GSM circuit-switched services and GPRS/EGPRS dataservices as a function of service load and user preference.

The timeslots on any carrier can be reserved for packet data use, for circuit-switched useonly, or allocated as switchable. Motorola uses the term switchable to describe a timeslotthat can be dynamically allocated for packet data service or for circuit-switched service. Idlecircuit-switched timeslots can be used as switchable PDTCHs for packet traffic when GPRS iscongested in the cell.

The timeslot allocation is performed such that the GPRS/EGPRS reserved timeslots are allocatedfor GPRS/EGPRS use before switchable timeslots. GSM circuit-switched timeslots are allocatedto the circuit-switched calls before switchable timeslots. The switchable timeslots are allocatedwith 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 allocatedbefore 32 kbps TRAU, 32 kbps TRAU are allocated before 16 kbps TRAU. In addition, TRAUtypes are given priority over the BCCH carrier.

3-76 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Dynamic timeslot allocation

For cell extended PDCH configuration, the extended PDCH is always allocated before thenormal PDCH.

For EGPRS, 64 kbps terrestrial timeslots are required on the link between the BTS and BSC tosupport the backhaul required for EGPRS coding schemes MCS-1 to MCS-9. This is a single 64kbps and not adjacent 16 kbps subrate timeslots. For Non-BCCH carriers all timeslots shouldhave 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 switchableterrestrial backing under high load conditions and, in effect, block GPRS access to theswitchable timeslots at the BTS. In addition, the reserved GPRS pool of backing resourcescan 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 ofnon-reserved resources.

Background and discussion

Multiple carriers per cell can be configured with GPRS/EGPRS timeslots by the operator forpacket data traffic handling capability. By doing so, it can meet the expanding base of packetdata 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 withthe capability to configure all the reserved and switchable GPRS/EGPRS timeslots in a cellcontiguously to maximize performance. The contiguous GPRS/EGPRS timeslots configuredon a carrier in a cell provide ease in scheduling packet data and the capability to servicemultiple timeslot GPRS mobiles.

• User specified

This provides the flexibility to configure reserve and switchable GPRS/EGPRS timeslotson a per carrier basis in a cell.

Depending on hardware configuration at a cell, there maybe some limitations on how timeslotsare allocated to EGPRS on a carrier.

EGPRS is available on Horizon macro II through software upgrade. It is also available onHorizon macro through CTUII upgrade. Since 8-PSK modulated signals do not posses a constantenvelope, linearity requirement on the power amplifier is increased to maintain the out-of-bandradiation to a minimum. The Compact transceiver unit (CTUII) can operate in two modes: HighPower Mode (HPM) or Normal Power Mode (NPM). Each have two sub-modes of operations asfar 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 outputpower in GMSK mode (irrespective of whether in EGPRS, GPRS, or voice) can be similar orhigher than the output power in 8-PSK mode, depending on whether operating in NPM or HPMrespectively. CTUII produces the same average output power in EGPRS 8-PSK mode as thatof GSM (GMSK) when GSM is configured in DDM. However, when GSM is in SDM, its outputpower can be up to 5 dB higher than EGPRS. There is a settable capping of the output power toequalize the average output power in GMSK and 8-PSK modes, if required. To support EGPRSon DDM CTU2 and retain no HW changes of CTU2, each CTU2 is able to rapidly switch betweenDouble Density modulation (GMSK) and Single Density modulation (8-PSK). The power output isnot affected by the ITS feature for GMSK and 8-PSK. The capping works in 4 steps by settinga data base parameter to the values as shown in Table 3-11.

68P02900W21-T 3-77

Jul 2010

Dynamic timeslot allocation Chapter 3: BSS cell planning

Table 3-11 Capping settings

Step Data base parameter value

0 5 dB higher

1 2 dB higher

2 1 dB higher

> 2 0 dB difference

Therefore, depending on the configuration of a cell, it is possible that GMSK signals can be setto have, on average, higher power than 8-PSK signals. The following are the scenarios in whichthere 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 powersare on timeslot by timeslot basis.

• On the same timeslot allocated to EGPRS, operators can operate on MCS-1 to MCS-4and MCS-5 to MCS-9.

However, as a general deployment rule the GMSK and 8-PSK signal power levels should beset equally (data base parameter value > 2).

{34371G} Compliance of the (R)CTU8m output power capacity for both the GMSK and 8-PSKis 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 perRF transmission port

GMSK 40 W, 8PSK 30W -0/+2 dB

E/PGSM900 (R)CTU8m @ 2 carriers perRF transmission port

GMSK 20 W, 8PSK 15W -0/+2 dB

E/PGSM900 (R)CTU8m @ 3 carriers perRF transmission port

GMSK 10 W, 8PSK 8.5W -0/+2 dB

{35200G} E/PGSM900 (R)CTU8m @ 4carriers per RF transmission port

GMSK 8 W, 8PSK 6W-0/+2 dB

DCS1800 (R)CTU8m @ 1 carriers per RFtransmission port

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

DCS1800 (R)CTU8m @ 2 carriers per RFtransmission port

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

DCS1800 (R)CTU8m @ 3 carriers per RFtransmission port

GMSK 8 W, 8PSK 6.8W -0/+2 dB

{35200G} DCS1800 (R)CTU8m @ 4carriers 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

System Information: BSS Equipment Planning Dynamic timeslot allocation

Table 3-13 CTU2D output power

GMSK 8-PSK

EGSM900 SD 63 W -0/+2dB

20 W -0/+2 dB

EGSM900DD

20 W -0/+2dB 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, ITSMode)

DCS1800 SD 50 W -0/+2dB

16 W -0/+2 dB

DCS1800 DD 16 W -0/+2dB

8-PSK 16 W - 0/+2 dB (Timeslot Blanking, that is, ITS Mode8-PSK 8 W - /+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 kbpsTRAU) are mapped to SDM or DDM equipped CTUII radios if possible. If the ITS feature isunrestricted and enabled, it is not recommended to map user preferred 64 k RTF to improperDRI because it would invalidate the ITS feature. If no single-density or double-density CTUIIsare 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) andenhanced capabilities (CAP and ASTM mode) which are summarized in the following table:

Table 3-14 DRI-RTF Mapping functionality

DRI-RTF Mapping functionality 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)orCTU2D GMSK Carrier B with CAP-A (ASYM not supported– Level3)

Where: 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 withTimeslot 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).

68P02900W21-T 3-79

Jul 2010

Dynamic timeslot allocation Chapter 3: BSS cell planning

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 mappedto CTU-2/CTU2D DRI than non-CTU2/CTU2D DRI, since the extended PDCH can only besupported on CTU2/CTU2D radios. And for the BTS with extended PDCH, asymmetric modeshall be disabled.

During site initialization, RTF-DRI mapping preference for 64 k RTF with extended PDCHshall 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 PDCHshall be:

• 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 orfree 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

3-80 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Dynamic timeslot allocation

Due to the importance of the BCCH carrier, the BCCH is remapped onto an available DRI, evenif that DRI is unable to support EGPRS. In the event that the BCCH RTF is remapped onto a DRIthat 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 primarilycomes into play post-initialization when the BCCH RTF fails. The BSS software attempts to bothmaintain EGPRS service and keep the BCCH on a CTUII if at all possible. If the BCCH RTF isconfigured for EGPRS and there is only one SDM CTUII available, the BCCH RTF is mappedonto 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 onlyone 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 muchas possible. Thus, the BSS software attempts to assign EGPRS carriers onto EGPRS-capablehardware first, and then assign carriers to the rest of the hardware in its usual fashion. IfPBCCH/PCCCH is enabled in the cell, the BSS ignores the pkt_radio_type value of the BCCHcarrier.

The minimum backhaul requirement is determined to be 3 DS0s since a minimum of 2 DS0s arerequired to support voice traffic if all 8 timeslots on a carrier are configured as TCH and theadditional third DS0 provides the bare minimum backhaul required for configurations when 1 to3 timeslots on the carrier are configured as PDTCHs. The third DS0 also helps in reducing thetime required to start servicing the first PDTCH timeslot by keeping this backhaul synchronizedbetween the BTS and the PCU even when there are no PDTCHs active on a carrier (providedthere are enough GDS resources available across the cell).

The RTF allow_32k_trau and use_bcch_for_gprs attributes were replaced with a newparameter pkt_radio_type. pkt_radio_type also accommodates the 64 k backhaul necessaryto support EGPRS and makes it possible to configure RTFs on which GPRS data is specificallydisallowed. Technical Description: BSS Implementation (68PO2901W36) provides a completedescription of these commands.

Depending on the restrictions imposed on GPRS (32 kbps TRAU) and EGPRS (enabled ordisabled), 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 attributertf_ds0_count. If the VersaTRAU feature is unrestricted, the operator can configure the RTFbackhaul 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. Thesum 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 andGPRS traffic. There are three provisioning choices combined with timeslot configuration optionsselected:

• Reserved GPRS/EGPRS timeslots allocated only for packet data use.

• Switchable timeslots dynamically allocated for either GSM circuit-switched traffic orGPRS/EGPRS traffic (designated as switchable timeslots by Motorola).

• Remaining timeslots on the carrier with GPRS/EGPRS timeslots, if any, only forcircuit-switched use. Idle circuit-switched timeslots can be used as switchable PDTCHs forpacket traffic when GPRS is congested in the cell.

{34416} If radios with power-saving radios are mixed with non-power-saving radios in thesame BBH hopping group, using PA bias feature in Horizon II sites with mixed radios willnot deliver as the expected power savings.

It is also recommended that the least-preferred RTFs are mapped onto power-saving radios tomaximize power savings.

68P02900W21-T 3-81

Jul 2010

Dynamic timeslot allocation Chapter 3: BSS cell planning

Planning goals - reserved against switchable timeslots

The network planner can consider the following network planning goals when trying todetermine when to use reserved timeslots against when to use switchable timeslots:

• Use reserved timeslots to guarantee a minimum quality of service (QoS) for packet datausers.

• Use switchable timeslots to provide low circuit mode blocking and high packet datathroughput when the voice busy hour and the GPRS busy hour do not coincide.

• Use switchable timeslots to provide higher packet data throughput without increasingthe circuit-switched blocking rate. If all the GPRS/EGPRS timeslots are provisionedas switchable, the last available timeslot is not given to a circuit-switched call untiltransmission 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 timeslotbecomes free.

• Use switchable timeslots to provide some GPRS/EGPRS service coverage in low GPRStraffic volume areas.

• Use switchable timeslots to provide extra circuit-switched capacity in spectrum limitedareas. 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. Theproposal in this planning guide is to drive the allocation of switchable timeslots andreserved 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 trafficlevel, as measured in Erlangs. Once the circuit-switched information is known, the potentialimpact on switchable timeslots can be analyzed. The GPRS/EGPRS QoS can be planned bycounting the number of available reserved GPRS/EGPRS timeslots, and by evaluating theexpected utilization of the switchable timeslots by the circuit-switched part of the networkduring the GPRS/EGPRS busy hour.

The priority of timeslot allocation takes into account the factors in the following list. The highestpriority 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

System Information: BSS Equipment Planning 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 kcarrier B is less preferred for 32 k PDCH placement.

With the removal of timeslot blanking for CAP configurations of CTU2D (CAP mode), bothCarrier 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 ofEDGE/GPRS PDs. When CTU2D is configured in ASYM mode, 64 k Carrier A is preferred to 64 kCarrier 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-CTU8mcarriers.

For cell extended PDCH configuration, the extended PDCH is always allocated before thenormal PDCH.

Carrier timeslot allocation examples

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 whenconfiguring the timeslots on an EGPRS capable carrier (pkt_radio_type set to 3) with aconfigurable 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 orderin 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

Carrier timeslot allocation examples Chapter 3: BSS cell planning

Example 1

There are 15 switchable GPRS/EGPRS timeslots and 10 reserved GPRS/EGPRS timeslots ina 5 carrier cell.

This example assumes that the VersaTRAU feature is not purchased. In this case, the RTFbackhaul for an RTF with pkt_radio_type set to 3 (64 k) is defaulted to 7 DS0s if it is the BCCHRTF 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 asillustrated. The GPRS/EGPRS timeslots are configured contiguously for performance. Thepacket data timeslots are arranged as shown in the table . The BCCH RTF is mapped to CTUIIand all the reserved timeslots are EGPRS capable. The non-BCCH 32 k carriers are used forGPRS CS1 to CS4. The remaining switchable timeslots are mapped to one of the non-BCCH 16k carrier.

Table 3-15 Arrangement of packet data timeslots for example 1

Carrier TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7

BCCH 64 k (CTUII) B 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 T T T T T T

3-84 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Carrier timeslot allocation examples

Example 2

There are 15 switchable GPRS/EGPRS timeslots and 10 reserved GPRS/EGPRS timeslots ina 5 carrier cell.

This example assumes that the VersaTRAU feature is not purchased. In this case, the RTFbackhaul for an RTF with pkt_radio_type set to 3 (64 k) is defaulted to 7 DS0s if it is theBCCH RTF or 8 DS0s if it is a non-BCCH RTF.

The following are assumed:

• pkt_radio_type is set to:

BCCH RTF: None (0)

1 non-BCCH carrier: 64 k (3)

2 non-BCCH carriers: 32 k (2)

non-BCCH carrier: 16 k (1)

• One CTUII and four non-CTUII

• GPRS 32 k and EGPRS unrestricted

The GPRS/EGPRS timeslots are configured contiguously for performance. The packet datatimeslots are arranged as shown in the table. The BCCH RTF is mapped to non-CTUII DRIand all the circuit-switched timeslots are allocated to it. The EGPRS and GPRS timeslots areallocated to non-BCCH carriers as shown.

Table 3-16 Arrangement of packet data timeslots for example 2

Carrier TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7

BCCH 16 k (non-CTUII) B SD T T T T T T

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

Non-BCCH 32 k(non-CTUII)

SG SG SG SG SG SG SG

Non-BCCH 16 k(non-CTUII)

T T T T T

68P02900W21-T 3-85

Jul 2010

Carrier timeslot allocation examples Chapter 3: BSS cell planning

Example 3

There are 8 switchable GPRS/EGPRS timeslots and 4 reserved GPRS/EGPRS timeslots in a 5carrier cell.

This example assumes that the VersaTRAU feature is not purchased. In this case, the RTFbackhaul for an RTF with pkt_radio_type set to 3 (64 k) is defaulted to 7 DS0s, if it is the BCCHRTF 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) 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

One CTUII and four non-CTUII

GPRS 32 k and EGPRS unrestricted

• max_gprs_ts_carrier = 4

Assuming sd_load of 2 for all the carriers, preferred number of SDCCH being 64, PBCCH isenabled (BSS level and cell level, and at the carrier level hr_allowed) the timeslot allocation isshown in Table 3-17.

Table 3-17 Arrangement of packet data timeslots for example 3

Carrier TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7

BCCH 64 k (CTUII) B P T T RE RE RE RE

Non-BCCH 32 k(non-CTUII)

SD1 SD3 T T SG SG SG SG

Non-BCCH 32 k(non-CTUII)

SD2 SD4 T T SG SG SG SG

Non-BCCH(non-CTUII)

SD7 SD8 T T T T T T

Non-BCCH(non-CTUII)

SD5 SD6 T T T T T T

3-86 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Carrier timeslot allocation examples

Example 4

There are 14 switchable GPRS/EGPRS timeslots and 10 reserved GPRS/EGPRS timeslots ina 5 carrier cell.

This example assumes that the VersaTRAU feature is not purchased. In this case, the RTFbackhaul for an RTF with pkt_radio_type set to 3 (64 k) is defaulted to 7 DS0s, if it is the BCCHRTF or 8 DS0s if it is a non-BCCH RTF. The following are assumed:

• pkt_radio_type is set to:

BCCH RTF: None (0)

2 non-BCCH carriers: 64 k (3)

1 non-BCCH carrier: 32 k (2)

1 non-BCCH carrier: None (0)

• Two CTUII and three non-CTUII

• GPRS 32 k and EGPRS unrestricted

• 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 isnot capable of supporting EGPRS. Additionally, the non-BCCH carrier configured with 64 kbackhaul 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 tocircuit-switch TCH only. The following table shows the timeslot allocation.

Table 3-18 Arrangement of packet data timeslots for example 4

Carrier TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7

BCCH (CTUII) B SD P T T T T T

Non-BCCH 64 k(CTUII)

RE RE RE RE RE RE RE RE

Non-BCCH 64 k(non-CTUII)

T T T T T T T T

Non-BCCH 32 k(non-CTUII)

SG SG SG SG SG SG

Non-BCCH(non-CTUII)

T T T T T T T T

68P02900W21-T 3-87

Jul 2010

Carrier timeslot allocation examples Chapter 3: BSS cell planning

Example 5

There are 12 switchable GPRS/EGPRS timeslots and 10 reserved GPRS/EGPRS timeslots ina 6 carrier cell.

This example assumes that the VersaTRAU feature is not purchased. In this case, the RTFbackhaul for an RTF with pkt_radio_type set to 3 (64 k) is defaulted to 7 DS0s if it is the BCCHRTF or 8 DS0s if it is a non-BCCH RTF. The following are assumed:

• pkt_radio_type is set to:

BCCH RTF: 64 k (3)

1 non-BCCH carrier: 64 k (3)

1 non-BCCH carrier: 32 k (2)

3 non-BCCH carriers: None (0)

• Three CTUII and three non-CTUII

• GPRS 32 k and EGPRS unrestricted

• Two (AMR or GSM) half-rate enabled carriers

The following table shows the timeslot allocation.

Table 3-19 Arrangement of packet data timeslots for example 5

Carrier TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7

BCCH 64 k (CTUII) B SD P RE RE RE RE RE

Non-BCCH 64 k (CTUII) 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)

T T T T T T T T

Non-BCCH 16 k (hrenabled) (non-CTUII)

T T T T T T T T

Non-BCCH 16 k (hrenabled) (non-CTUII)

T T T T T T T T

Example 6

There are 4 switchable EGPRS timeslots and 4 reserved EGPRS timeslots in a 4 carrier cell.The following are assumed:

• pkt_radio_type set to BCCH RTF 64 k (3)

• 3 non-BCCH carrier: 64 k (3)

• 3 CTUIIs

• EGPRS unrestricted

3-88 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Carrier timeslot allocation examples

Table 3-20 shows the timeslot allocation.

Table 3-20 Arrangement of packet data timeslots for example 6

Carrier TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7

BCCH 64 k (CTUII) B SD SE SE RE RE RE RE

Non-BCCH 64 k (CTUII) SE SE SE SE RE RE RE RE

Non-BCCH 64 k (CTUII) T T T T T T T T

Non-BCCH 64 k (CTUII) T T T T T T SE SE

Example 7

There are 10 switchable GPRS/EGPRS timeslots and 12 reserved GPRS/EGPRS timeslots in a6 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

1 non-BCCH carrier: 32 k (2)

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

The following table shows the timeslot allocation.

Table 3-21 Arrangement of packet data timeslots for example 7

Carrier TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7

BCCH 64 k (CTUII) B SD RE RE RE RE RE RE

Non-BCCH 64 k (CTUII) SE SE RE RE RE RE RE RE

Non-BCCH 32 k (CTUII) SG SG SG SG SG SG SG SG

Non-BCCH (non-CTUII) T T T T T T T T

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

T T T T T T T T

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

T T T T T T T T

68P02900W21-T 3-89

Jul 2010

Carrier timeslot allocation examples Chapter 3: BSS cell planning

Example 8

There are 5 switchable GPRS/EGPRS timeslots and 4 reserved GPRS/EGPRS timeslots in a 2carrier cell.

The following are assumed:

• 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

The following table shows the timeslot allocation.

Table 3-22 Arrangement of packet data timeslots for example 8

Carrier TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7

BCCH 64 k (CTUII DD Carrier A) B SD P T RE RE RE

Non-BCCH 64 k (CTUII DDCarrier)

SG SG X SG X X X X

Non-BCCH 64 k are downgraded to 32 k. The maximum PDs configuration for two carriers ofDD CTU2 is 8 if Carrier A has EGPRS PDs. The requested 9 PDs cannot be all met.

Example 9

There are 8 switchable GPRS/EGPRS timeslots and 4 reserved GPRS/EGPRS timeslots in a 4carrier cell. The CTU2D Asymmetric feature is unrestricted and ASYM mode is enabled for thesite on which these 4 carriers are configured. PBCCH is enabled and the preferred number ofSDCCH is 80. The sd_priority = 2 and sd_load = 3 for all the carriers.

• 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

3-90 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSS timeslot allocation methods

Table 3-23 Arrangement of packet data timeslots for example 9

Carrier TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7

BCCH 64 k (CTU2DCAP A)

B 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) T SE SE SE

Non-BCCH 32 k(CTU2D PWR B)

SD(10) T T T T T T T

Example 10

There are 3 switchable GPRS/EGPRS channel and 1 reserved GPRS/EGPRS channel in a 3carrier 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.

Table 3-24 Arrangement of packet data timeslots for example 10

Carrier TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7

BCCH 64 k (CTU2DSD)

B Ext SD Ext T T SE SE

Non-BCCH 16 k(CTU2D SD)

T Ext T Ext SG Ext RG Ext

Non-BCCH 32 k(CTU2D SD)

T T T T T T T T

BSS timeslot allocation methods

The BSS algorithm that is used to determine allocation of switchable timeslots gives priorityto circuit-switched calls. Consequently, if a switchable timeslot is being used by a packetdata mobile and a circuit-switched call is requested after all other circuit-switched timeslotsare used, the BSS takes the timeslot away from the packet data mobile and gives it to thecircuit-switched mobile, except when the switchable timeslot to be stolen is the last packet datatimeslot in the cell and the protect_last_ts element is enabled.

68P02900W21-T 3-91

Jul 2010

BSS timeslot allocation methods Chapter 3: BSS cell planning

The switchable timeslot is re-allocated back to the packet data mobile when the circuit-switchedcall ends. The number of reserved packet data timeslots can be changed by the operator toguarantee a minimum number of dedicated packet data timeslots at all times. The operatorprovisions the packet data timeslots on a carrier by selecting the number of timeslots that areallocated 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 tostrongly favor circuit-switched calls from a network provisioning perspective. By setting the idleparameter to 0, this capability is turned off.

When a circuit-switched call ends on a switchable packet data timeslot and the number of idlecircuit-switched timeslots is greater than a user-defined threshold, the BSS re-allocates theborrowed timeslot for packet data service. When the number of idle timeslots is less than orequal to a programmable threshold, the BSS does not allocate the timeslot back for packet dataservice, 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 switchabletimeslot to be stolen is the last packet data timeslot in the cell and the protect_last_ts elementis enabled.

When a switchable timeslot needs to be stolen for use by a CS call, the switchable timeslot to bestolen 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 notprotected from being stolen for use by circuit-switched calls.

The BSS supports dynamic switching between switchable timeslots and circuit-switchedtimeslots.

Switchable packet data timeslots are stolen starting with the lowest numbered GPRS timesloton a carrier to maintain continuous packet data timeslots.

The BSS selects which switchable packet data timeslot is stolen based on an algorithm thattakes 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 orstatically computed in other cases depending on the pkt_radio_type) and the number ofswitchable or reserved timeslots already on the carrier. A rank order based on the backhaulto PDTCH ratio is established at the time of the initial air timeslot allocation. This rank orderis also used at the time of allocating the reserved and switchable timeslots in the cell. Theswitchable timeslots are the ones that result in the least degradation in the backhaul to PDTCHratio 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 canbe stolen only if there is no normal PDCH available. When the MS is in the extended range, onlythe extended PDCH can be stolen.

When (AMR or GSM) half rate is enabled on one or more (RTFs assigned to) carriers in a cell andsome number of timeslots are reserved for half rate usage (hr_res_ts), then the BSS attemptsto ensure that the last timeslots to be allocated within a cell are half rate capable. Thereforeswitchable 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 raterequest is the last GPRS/EGPRS timeslot, and the protect last ts functionality is enabled).

3-92 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Recommendation for switchable timeslot usage

When the ITS feature is unrestricted and enabled and a voice call steals one EGPRS PD timesloton a DD CTU2 Carrier A, the corresponding blanked-out timeslot on Carrier B comes back intoservice. If the stolen EGPRS timeslot on DD CTU2 comes back to PDCH, the correspondingblanked-out timeslot on Carrier B is configured back to OOS. CTU2D PWR mode is treated thesame as the ITS mode whereby the stolen operation is identical.

Contiguous timeslots

Multislot mobile operation needs that contiguous timeslots are available. The BSS takes thelowest numbered switchable timeslot in such a manner as to maintain contiguous GPRS/EGPRStimeslots for multislot GPRS/EGPRS operation and at the same time maintain an optimum ratioof PDTCH/available backhaul per carrier across the cell. The BSS attempts to allocate as manytimeslots as requested in multislot mode, and then backoff from that number as timeslots arenot 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 aswitchable timeslot from GPRS/EGPRS mode to circuit-switched mode, the BSS assigns timeslot3 before it assigns timeslot 4 for circuit-switched mode. Figure 3-32 provides timeslot allocationwith reserved and switchable timeslots.

Figure 3-32 Carrier with reserved and switchable GPRS/EGPRS timeslots

R R RS

TS0

S

TS7

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 carriesthe 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 canbe stolen for emergency call only if there is no normal PDCH available. When the MS is in theextended range, only the extended PDCH can be stolen for emergency call.

Recommendation for switchable timeslot usage

The following recommendation is offered when using switchable timeslots. It is important todetermine the GOS objectives for circuit-switched traffic and QoS objectives for packet datatraffic before selecting the number of switchable timeslots to deploy.

68P02900W21-T 3-93

Jul 2010

Recommendation for switchable timeslot usage Chapter 3: BSS cell planning

During the circuit-switched busy hour, potentially all switchable timeslots are occasionally usedby the circuit-switched calls. The circuit-switched timeslot allocation mechanism continues toassign switchable timeslots as circuit-switched timeslots as the circuit-switched packet datacontinues 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 theexpected packet data traffic. This ensures that there is a minimum guaranteed network capacityfor the data traffic during the circuit-switched busy hour.

During the non-busy hours, the switchable timeslots are considered as available for use by thepacket data network. Therefore, in the circuit-switched off busy hours, potentially all switchabletimeslots could be available for the packet data network traffic. The BSS call statistics shouldbe inspected to determine the actual use of the switchable timeslots by the circuit-switchedservices.

The circuit-switched busy hour and the packet data busy hour should be monitored to see ifthey overlap when switchable timeslots are in use. If the busy hours overlap, an adjustment ismade to the number of reserved timeslots allocated to the packet data portion of the networkto guarantee a minimum packet data quality of service (QoS) as measured by packet datathroughput and delay. Furthermore, one or more circuit-switched carriers require to be addedto the cell being planned or replanned so that the switchable timeslots are not required to offerthe desired circuit-switched grade of service.

Assume that switchable timeslots are occasionally unavailable for packet data traffic duringthe circuit-switched portion of the network busy hour. Provision enough reserved timeslots forpacket data traffic during the circuit-switched busy hour to meet the desired minimum packetdata QoS objectives, as measured by packet data throughput.

When CS and PS busy hour coincide, it is recommended that RES TS are configured tobe sufficient to service the mean PS load, particularly if QoS is enabled, since CS trafficautomatically preempts any PS traffic on SW TS. In these networks, the difference betweenthe mean and peak traffic (as evidenced by the mean_load_factor parameter), can then beserviced by SW TS. Any TS configured as RES TS reduces the CS call capacity. More flexibilityis envisaged with QoS disabled and if the operator does not have a strong commitment (forexample, 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 dependson the degree of overlap of the CS and PS load. In general, the rule is where there is moreoverlap than more RES TS is required. If there is no overlap whatsoever, that is, most TSsare assumed to be available to PS users during the PS busy hour, then a majority SW TSconfiguration is acceptable.

For example, if 8 PDCHs are required for mean_load_traffic, and it is assumedmean_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 minimumconfiguration 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 arerequired, the detailed value is decided according to statistics.

The TCH packet burst traffic feature supports allocation of additional switchable PDTCH fromidle TCH resource for packet traffic use only when the GPRS is congested at the cell level. Thisbenefits the handling of the packet burst traffic with low voice traffic load. This feature isavailable only for the EDGE enabled cell (at least one 64 k PDTCH should be available in thecell). The number of additional switchable PDTCHs are calculated based on the EDGE carrierconfiguration.

3-94 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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

1 Estimate reserved timeslot requirement:

Determine the number of reserved GPRS/EGPRS timeslots are required ona per cell basis to satisfy a packet data throughput QoS. The use of PBCCHin a cell needs at least one reserved GPRS/EGPRS timeslot in that cell. TheGPRS/EGPRS reserved timeslots should equal the sum of the active andstandby timeslots that are allocated to a carrier.

2 Allocate switchable timeslots:

Determine the number of reserved GPRS/EGPRS timeslots are required ona per cell basis. If the traffic is staggered in time, the use of switchabletimeslots can potentially offer increased capacity to both the GPRS/EGPRSand circuit-switched traffic.

3 Add an extra circuit-switched carrier:

If there is a requirement to use some timeslots on the carrier with onlyGPRS/EGPRS timeslots to satisfy the circuit-switched GOS objectives and thetimeslot requirement overlaps with the number of reserved GPRS/EGPRStimeslots, consider adding another circuit-switched carrier to the cell.

4 Monitor network statistics:

After deploying the GPRS/EGPRS timeslots on the cell, review the collectednetwork statistics on a continuous basis to determine whether thereserved GPRS/EGPRS timeslots, switchable GPRS/EGPRS timeslots, andcircuit-switched timeslots are truly serving the GOS and QoS objectives.As previously discussed, the use of switchable timeslots can offer networkcapacity advantages to both circuit-switched traffic and packet data traffic aslong as the demand for these timeslots is staggered in time.

68P02900W21-T 3-95

Jul 2010

GPRS/EGPRS air interface planning process Chapter 3: BSS cell planning

GPRS/EGPRS air interface planning process■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Influential factors in GPRS/EGPRS cell planning anddeployment

The planning and dimensioning of a system containing packet data users is not asstraightforward as a system populated with only circuit-switched users. Sophisticated tools arerequired to properly model the behavior of packet data users and dimension the requiredbandwidth for a given service mix. In GSM, the issues are further complicated when EGPRS isintroduced in an existing GSM network which also supports GPRS.

A generic planning and dimensioning process is shown in Figure 3-33. The main objectivesare to minimize the number of sites and timeslots (spectrum) to support a given packet datausers load at an acceptable QoS without compromising the QoS of voice users. AcceptableQoS for the packet data users with best effort type service is qualified by the bitrate or delayexperienced. This should be at least like those experienced while using the normal wired lineanalog modems. The QoS feature allows the system to differentiate between subscribers basedon 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

Input parameters Planning tools Output parameters

Traffic characterisationRF cell planningBTS dimensioningTS dimensioningBSS dimensioningInterface dimensioning

Cell sizesNumber of cellsTS requirementsBSS requirementsInterface requirements

Number of subscribers (GPRS/EGPRS split)Area to cover coverage requirementsRF InformationTraffic Profile and Service mixQoS requirementsBandwidth availableNetwork configurationsRLC/MAC overheads

ti-GSM-Generic_planning_and_dimensioning_process-00208-ai-sw

3-96 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Influential factors in GPRS/EGPRS cell planning and deployment

At a higher level, the cell planning and deployment can be broken down into two activities, whichbecome inter-related depending on the traffic volumes supported and bandwidth available.These are cell coverage and cell dimensioning. In addition, there are some deployment rulesthat are applied if there is sufficient flexibility in the choice of carrier and segregation oftimeslots, this depends on the network configuration. Issues and influential factors that shouldbe 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. Thesecond 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 adequatecoverage 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 severalfactors including:

• Spectrum availability.

• Re-use patterns: hopping or non-hopping.

• Environment: As the radio conditions change the subsequent C/I (C/N) requirements at agiven 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 followingfactors are to be considered:

• When the QoS feature is not enabled, the system employs the best effort packet dataservices (no high QoS requirements are supported) with RLC acknowledge mode (ARQ).The choice of operating BLER point is flexible within a certain range. In Motorola’simplementation, acceptable BLER operating point is embedded in the LA algorithms forGPRS and EGPRS.

• When the QoS feature is enabled, the BSS is able to assign an MTBR per PFC. Thisallows 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 enforceMBR for a PFC. It provides a more optimistic coding scheme for admission.

68P02900W21-T 3-97

Jul 2010

Influential factors in GPRS/EGPRS cell planning and deployment Chapter 3: BSS cell planning

• For the cell with extended PDCH, when the QoS feature is enabled, the MS in the extendedrange is always admitted with MTBR = 0.

• CS1 and MCS-1 have been designed such that they match the voice coverage footprint. Inaddition, 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 consequenceson system capacity and as such impacts the number of users that can be supported. InMotorola’s implementation, the LA algorithm attempts to maximize the throughput whilekeeping implicitly the BLER operating regions within an acceptable bound in order not todegrade the overall system performance.

• The PA output power capability does not impact the EGPRS availability at cell borderssince 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 impactsthe system capacity.

• Frequency re-planning is required not so much to guarantee GPRS/EGPRS coverage butmore to eliminate possible coverage degradation for voice users. In a conventional GSMvoice network, the frequency planning of the traffic carriers are based on assuming certainactivity factors (DTX). When GPRS/EGPRS are introduced, the level of interference goes upbecause of the following factors:

Higher activity: This depends on how the timeslot dimensioning is carried outto account for packet data users. If timeslots are driven hard, then the level ofactivity can be higher than that assumed for the voice only system. Also due tobehavior of packet data users being different, data flow control throughout thenetwork, 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 topacket data users needs scaling.

8-PSK signal peak to average ratio (PAR): due to 8-PSK envelop variation, the GMSKsymbols are occasionally hit with higher interference than usual when averagepower of GMSK and 8-PSK signals are set to be the same. However, the level ofdegradation should be considered within the context of the likely degradation thatmay encounter otherwise as a result of having a lower average power in the 8-PSKmode (thus reducing the impact of PAR). It is envisaged that the impact of loweraverage power prevails the impact of PAR, and the average powers in GMSK and8-PSK modes should be set equal.

Cell/timeslot dimensioning

The following factors influence cell/TS dimensioning since they impact throughput per TS aswell as the apparent throughput seen by a user, that is, pipe size:

• 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).

3-98 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Influential factors in GPRS/EGPRS cell planning and deployment

• 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 ordisabled.

• 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 needdetailed investigation, through simulation, to fully quantify their impacts. The following shedlight on some of the issues that are encountered:

• If QoS is enabled, the number of PDTCHs required to support the MTBR specified isdifferent than when QoS is disabled. The BSS treats all mobiles equally when schedulingthe air interface in a QoS disabled environment.

• If QoS2 feature is enabled, PDCHs required to support real-time service are more thanQoS2 disabled. BSS provide more bandwidth and higher priority for real-time service toensure that transfer delay is met.

• Volume of data has varying impacts on system capacity. Short messages do not benefitfrom higher code rates for those users in good radio conditions since LA process needstime to converge to higher code rates. Moreover, RLC protocols, such as TBF holdingtime, degrade the capacity for short messages. As a general rule, the throughput seenin practice is lower than the ideal throughput for short messages and is closer to theideal throughput for long messages.

• Up to four users can be multiplexed on a timeslot. Depending on system loading theapparent bit pipe seen by a user is subsequently reduced as in Figure 3-34. In addition, thiscould impact the throughput per timeslot since the LA process suffers due to variation ofradio channel conditions between scheduling opportunities. Thus, even for long messagesthe ideal throughput is hardly achieved. In Motorola’s implementation, there is anintelligent load management algorithm in the PCU that attempts to balance the load acrossresources allocated to the packet data users. This improves the overall system and QoSperformance of the operators depending on the bandwidth provisioned for the packet datausers. 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 impactis a slight degradation in maximum achievable throughput for EGPRS users in the DL. Thisis 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 reportsand Ack/Nack status of the transmitted blocks), RLC Ack/Nack window size, impacts thethroughput per timeslot and as such number of users that can be supported. If ExtendedUplink TBF feature is enabled, the TBF holding time is longer than that when the feature isdisabled.

• If the PFC is in Ack mode, it is possible that the transfer delay for the LLC frame exceedsthe 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 forTD guarantee.

68P02900W21-T 3-99

Jul 2010

Influential factors in GPRS/EGPRS cell planning and deployment Chapter 3: BSS cell planning

• 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 consequenceson system capacity and as such impacts the number of users that can be supported. Forexample, although IR enables MCS-9 throughput to be like other coding schemes atlow C/I values, but the corresponding BLER is high. This from system viewpoint couldhave detrimental effects due to the RLC protocol operation such as those in the lastbullet points. In Motorola’s implementation, the LA algorithm attempts to maximize thethroughput while keeping implicitly the BLER operating regions within an acceptablebound in order not to degrade the system performance.

• If PCCCH is enabled, timeslot dimensioning for packet data traffic should consider theblocks used for control signaling.

Figure 3-34 Multiplexing 4 TBFs on an air timeslot

Time

80ms

User 1

User 2User 3

User 4

4 TBFs/TS

20ms block

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:

• Delay

• Throughput

3-100 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Influential factors in GPRS/EGPRS cell planning and deployment

In R99 and beyond, four traffic classes are defined to accommodate the need for different levelsof these factors for different applications. These are:

• Conversational

• Streaming

• Interactive

• Background

The BSS has internally defined additional traffic classes created by grouping similar PFCcharacteristics. 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 streamingservice when QoS2 is unrestricted and streaming_enabled is enabled. Requests to createpacket flows for conversational mode are treated as streaming. the BSS does not make anyguarantee regarding strict parameter for conversational traffic.

Traffic handling priority (THP)

Three priorities are defined in the standards for handling the traffic pertaining to the interactivetraffic class only. For the BSS, these priorities determine relative throughput assigned to aparticular Packet Flow Context (PFC). This is achieved by applying relative weights for eachpriority, 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 bythe BSS for the background and best effort traffic classes respectively. The assigned weights forthese internally defined THPs act relative to the three THPs that are defined for the interactivetraffic class by the standards.

THP provides a mechanism to differentiate services among different PFCs that may or may notbelong to the same user.

Minimum Throughput Budget Requirement (MTBR)

A Minimum Throughput Budget Requirement (MTBR) is non-standards based BSS parameterassociated with each PFC. The MTBR of a given TBF is the sum of MTBRs of all the PFCs thatare multiplexed on that TBF. MTBR allows the BSS to admit each PFC if a minimum budget forresources 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 theuplink and downlink directions separately.

For the cell with extended PDCH, when QoS feature is enabled, the MS in the extended range isalways admitted with MTBR = 0.

68P02900W21-T 3-101

Jul 2010

Influential factors in GPRS/EGPRS cell planning and deployment Chapter 3: BSS cell planning

MTBR is measured as raw air throughput at the RLC/MAC layer without factoring in the BlockError Rate (BLER) and unsolicited retransmissions. It is not a guaranteed bitrate. MTBR ismerely a budgeting guideline for the admission control mechanism. This helps to ensure that nomore 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 interms of throughput at the RLC/MAC layer. Throughputs at the application layer are lower thanthe RLC/MAC throughput due to overhead consumed by the headers and retransmissions at theintermediate layers and the application layer. Table 3-25 shows typical TCP throughput for each10 kbps of RLC/MAC throughput at zero block error rate. The TCP throughput depends uponthe 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 errorrate

RLC/MACthroughput (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 streamingand conversational PFC. The GBR is a negotiable parameter. The EGBR is the additionalthroughput that is allocated to a user that is sufficient to service the GBR and the transfer delayrequirements of the streaming service. The TABR of a given TBF is the sum of MTBRs andEGBRs of all the PFCs that are multiplexed on that TBF. The GBR in the uplink and downlinkdirections have different values.

EGBR is defined as GBR/r, where r is a value between 0 and 1. To find the average downlinkEGBR 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 thestreaming service. The minimum transfer delay that the PCU supports is user configurable. Forplanning 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 streamingservice.

To determine the value of r to use, first obtain the weighted average GBR per service in thenetwork. This is obtained by multiplying the frequency of the service in the network by theGBR of the service.

3-102 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Influential factors in GPRS/EGPRS cell planning and deployment

AverageGBR =

N

ΣGBRi ∗ FSi/STRii = 1

Where: Is:

N the number of streaming service types in the network.

GBRi the GBR of streaming service i.

FSi the percentage of streaming service i in service mix of subscribers in a givenPCU.

STRi the percentage of total streaming service in service mix of subscribers in agiven 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 delaysupported in the PCU, in networks where the majority of streaming services have GBR of 15kbps or lower, for example, PoC. If an application does not need a stringent transfer delay thenthe 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 Transferdelay (ms) ρ Minimum Transfer

delay (ms) ρ Minimum Transferdelay (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

Influential factors in GPRS/EGPRS cell planning and deployment Chapter 3: BSS cell planning

Table 3-26 ρ for various transfer delays at GBR 15 kbps or less (Continued)

Minimum Transferdelay (ms) ρ Minimum Transfer

delay (ms) ρ Minimum Transferdelay (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, thefollowing 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 than500 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 thenetwork 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 beevaluated 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

System Information: BSS Equipment Planning Influential factors in GPRS/EGPRS cell planning and deployment

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

Influential factors in GPRS/EGPRS cell planning and deployment Chapter 3: BSS cell planning

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, meaningnon-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. ARPRank 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

1 6 6 6 6 3

2 5 5 5 5 2

3 4 4 4 4 1

Admission Control determines which PFCs get access to the system and which PFCs getpreempted 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 8BSS 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 IIFeature. The BSS uses ARP to determine which PFCs have priority access to the system. TheBSS provides the user the same level of configurability using the attributes shown in the tablefor the cases where the BSS does not receive the ARP IE attribute from the SGSN (SGSN maynot be R6 compatible or may not include the optional ARP IE in the CREATE-BSS-PFC message).

3-106 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Estimating the air interface traffic throughput

Table 3-30 BSS ARP configuration Parameters

Traffic Class

PrecedenceClass

Streaming orConversational

Interactive or BestEffort Background

0 arp_streaming_1 arp_i_be_1 arp_bg_1

1 arp_streaming_2 arp_i_be_2 arp_bg_2

2 arp_streaming_3 arp_i_be_3 arp_bg_3

Admission Control determines which PFCs get access to the system and which PFCs getpreempted 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 8BSS 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 uponthe Poisson process for determining the GPRS/EGPRS mobile packet transfer arrivals to thenetwork and for determining the size of GPRS/EGPRS data packets generated or received bythe GPRS/EGPRS mobiles.

Some wired LAN/WAN traffic studies have shown that packet interarrival rates are notexponentially distributed. Recent work argues that LAN traffic is much better modeled usingstatistically self-similar processes instead of Poisson or Markovian processes. Self-similartraffic pattern means that the interarrival rates appear the same, regardless of the timescaleat which it is viewed (in contrast to Poisson process, which tends to be smoothed around themean in a larger timescale). The exact nature of wireless GPRS traffic pattern is not known dueto 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 afactor of 200% to account for the burstiness of GPRS/EGPRS traffic. When mean_load_factorparameter is assumed 200%, it means the peak traffic is twice of mean traffic. This parameterimpacts 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 thedelay can be considered a constant value for the purposes of calculating the time totransfer a file of arbitrary size.

LAN/WAN wireline studies have also shown that even when statistically valid studies areperformed, the results come out different in follow-up studies. It turns out that web trafficpatterns are difficult to predict accurately and, therefore, it is highly recommended that thenetwork 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 Chapter 3: BSS cell planning

The results depend on the choices made in sections Select a cell plan on page 3-108 andEstimating 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 atthe GPRS/EGPRS data rates. The cell plan that is selected for GPRS/EGPRS can be determinedby the plan currently in use for the GSM circuit-switched part of the network. However, it isnecessary to change an existing cell plan used for GSM circuit-switched to get better BLERperformance for the GPRS/EGPRS part of the network.

The PCU dynamically selects the best coding scheme to maximize the data throughput ona per mobile basis. The coding scheme rate selection is performed periodically during thetemporary block flow (TBF). When planning frequency, it is required that there are no more than48 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 showsthe percentage utilization of GPRS and EGPRS coding schemes at a fixed operating BLERof 20% in a 4x3 BCCH (non-hopping) re-use pattern, and under a TU channel condition. Ifnon-regular patterns are used, a specific simulation study is required to match the particularcell 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 dueto the longer distance between the MS and BTS. For the cell with extended PDCH, the lowercoding scheme will have a higher utilization percentage value than the corresponding typicalutilization percentage value in the following table.

NOTEWhen the QoS feature is enabled, the timeslot zone and PRP board level headroomcompensate for BLER.

Table 3-31 Percentage of code utilization in a 4x3 non-hopping re-use pattern at20% 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

System Information: BSS Equipment Planning Estimating timeslot provisioning requirements

Table 3-31 Percentage of code utilization in a 4x3 non-hopping re-use pattern at20% 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

Estimating timeslot provisioning requirements

Here, the number of GPRS/EGPRS timeslots that require to be provisioned on a per cell basis isdetermined. Timeslot provisioning is based on the expected per cell mean GPRS/EGPRS trafficload, as measured in kbps. The packet data traffic load includes all SMS traffic routed throughthe GSN. The SMS traffic is handled by the GPRS/EGPRS infrastructure in the same manneras all other GPRS traffic originating from the PDN. The cell BLER and CS rate characteristicsselected, provide the required information for evaluating the following equation (totallysegregated EGPRS and GPRS timeslots):

No−PDTCH−TS = Roundup

(Mean−traffic−load−GPRS ∗Mean−load−factor

TS−Data−Rate−GPRS

)

(Mean−traffic−load−EGPRS ∗Mean−load−factor

TS−Data−Rate−EGPRS

)+

68P02900W21-T 3-109

Jul 2010

Estimating timeslot provisioning requirements Chapter 3: BSS cell planning

NOTE

• The equation is based on the DL traffic load and it is assumed that the DLprovisioning would be sufficient to handle UL traffic, without additionalprovisioning.

• The Mean_load_factor of 200% has been applied to the traffic load for systemswithout the QoS feature enabled to account for any surges in the data trafficand to carry packet switched signaling traffic. For example, assuming a trafficload with normal distribution, given a mean traffic load of M, the 99th-percentilepeak traffic load, P, could be calculated as P = M + 3*√M. The Mean_load_factorfor networks with that traffic distribution is then P/M*100%. For systems withthe QoS feature enabled the Mean_load_factor can be used to take into accountwhen multiple QoS enabled mobiles are in a cell at the same instance. Trafficclass, GBR and MTBR mix, relative THP, mobiles multi-slot capability, localtimeslot zone (cell level), and PRP board level headroom are considered in theMean_load_factor. Higher the Traffic Class, the MTBR required and the relativeTHP weight would be higher which has a direct effect on Mean_load_factor. Ifthere are more numbers of higher multi-slot capable mobiles in the traffic theMean_load_factor is further increased. If more headroom is reserved for localtimeslot zone/PRP board level the number of PDCH provisioned should be moreto 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 hasthe 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 calculatedusing the following formulae:

Mean traffic load GPRS =Avg sessions per sub ∗Data per sub per session ∗GPRS sub per cell

3600

Mean traffic load EGPRS =Avg sessions per sub ∗Data per sub per session ∗ EGPRS sub per cell

3600

For systems with the QoS feature enabled, Mean_traffic_load for each cell can be calculatedusing the following formulae:

Mean−traffic−load−GPRS = (STR−EGBR ∗%subs−STR+ I1−MTBR ∗%subsI1)

+ (I2−MTBR ∗%subs−I2 + I3−MTBR ∗%subs−I3 +BG−MTBR ∗%subs−BG)

+ (BE−MTBR ∗%subs−BE) ∗GPRS−subs−per−cell/3600

Mean−traffic−load−EGPRS = (STR−EGBR ∗%subs−STR+ I1−MTBR ∗%−subsI1)

+ (I2−MTBR ∗%subs−I2 + I3−MTBR ∗%subs−I3 +BG−MTBR ∗%subs−BG)

+ (BE−MTBR ∗%subs−BE) ∗ EGPRS−subs−per−cell/3600

3-110 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Estimating timeslot provisioning requirements

NOTEThe unit for Data_per_sub_per_session is kbyte/hr.

For systems without the QoS feature enabled:

TS Data Rate GPRS =1

100

4

Σ CSi%Codeutilization ∗ CSiUserData Rate ∗ (1−BLER)

i = 1

TS Data Rate EGPRS =1

100

4

Σ MCSi%Codeutilization ∗MCSiUserData Rate ∗ (1−BLER)

i = 1

For systems with the QoS feature enabled:

TS Data Rate GPRS =1

100(SUM from CSI to egprs−init−cs (CS Codeutilization ∗ CS UserData rate))

+SUMfrom egprs−init−cs to max−egprs−cs (CS Codeutilization ∗ CS UserData Rate for gprs−init−cs )

TS Data Rate EGPRS =1

100(SUM fromMCSI to egprs−init−cs (CS Codeutilization ∗ CS UserData rate))

+SUMfrom egprs−init−cs to max−egprs−cs (CS Codeutilization ∗ CS UserData Rate for gprs−init−cs )

For systems with the QoS2 feature enabled, default coding scheme is CS2 and MCS3 (referto 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

Estimating timeslot provisioning requirements Chapter 3: BSS cell planning

Number of timeslots

The number of PDTCH timeslots calculated in the section Estimating timeslot provisioningrequirements on page 3-109, denotes the number of timeslots that need to be provisioned on thecell to carry the mean traffic load on the cell.

It is important to differentiate between the required number of timeslots processed at anyinstance in time and the total provisioned timeslots because it directly affects the provisioningof the communication links and the PCU hardware. The active timeslots are timeslots that aresimultaneously carrying data being processed by the PRP on the PCU at any instance in time. Itis possible, however, to transfer packet switched data on each of the 1080 timeslots of a PCUsimultaneously (assuming that all 9 PRPs are configured), The PCU rapidly multiplex all thetimeslots with a maximum of 270 timeslots at any instance in time. For example, if there areMSs on each of 1080 timeslots provisioned on the air interface, the PCU processes timeslots in 4sets of 270 timeslots, with switching between sets occurring every block period.

The use of timeslots processed at any instance and total provisioned timeslots enables severalcells to share the PCU resource. While one cell is experiencing a high load condition, usingall eight packet data timeslots for instance, another cell operating its mean load averagesout the packet data traffic load at the PCU.

If the feature Support the usage of idle TCH for the packet burst traffic is used, idlecircuit-switched timeslots can be used as switchable PDTCHs for packet traffic when GPRS iscongested in the cell. These additional channels will be configured as switchable PDTCH whichshare the PCU resource in GPRS congestion status, but will be configured as TCH resourcewhen GPRS congestion is relieved. If this feature is enabled, the PCU processing capabilityshould be planned considering these additional timeslots may be processed during GPRScongestion status.

The E1s between the BTS and BSC must be provisioned to handle the number of timeslotscalculated 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 theexamples given. Refer to the examples to determine a refined number of PDTCHs to supportQos/QoS2 with a given set of configuration parameters.

Table 3-32 MTBR Mix

MTBR Mix

Qos Type DL UL

Streaming 16 2

I1 14 2

I2 10 2

I3 4 2

BG 2 2

BE 2 2

3-112 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Estimating timeslot provisioning requirements

Table 3-33 MTBR Constant

MTBR Constant

Qos Type DL UL

Streaming 2 2

I1 2 2

I2 2 2

I3 2 2

BG 2 2

BE 2 2

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

Number of PFCs admitted (Validfor MTBR/THP mix only)

QOS PDTCHs THPweight

MobileMulti-slotclass

TrauType

Subs-criberMix

MTBR

Subscr-iber

allowedon

carrierStreaming I1 I2 I3 BG BE

NoQoS

6 NA 4 16/32 NoMTBR

NA 18 - - - - - -

QoS 2 Constant 4 64 3DL/1UL Mix 14 - 1 1 1 1 -

Continued

68P02900W21-T 3-113

Jul 2010

Estimating timeslot provisioning requirements Chapter 3: BSS cell planning

Table 3-36 QoS Configuration Examples (Continued)

Number of PFCs admitted (Validfor MTBR/THP mix only)

QOS PDTCHs THPweight

MobileMulti-slotclass

TrauType

Subs-criberMix

MTBR

Subscr-iber

allowedon

carrierStreaming I1 I2 I3 BG BE

QoS 3 Constant 4 64 3DL/1UL Mix 7 - - 1 1 1 4

QoS 4 Constant 4 16/32 3DL/1UL Mix 5 - - 1 2 1 1

QoS 5 Constant 4 16/32 3DL/1UL Mix 4 - 1 1 1 1 -

QoS 5 Constant 4 16/32 3DL/1UL Mix 9 - - 1 2 1 5

QoS 6 Constant 10 16/32 4DL/1UL Mix 8 - - - - - -

QoS 6 Constant 4 16/32 3DL/1UL Constant 11 - - - - - -

QoS 6 Constant 10 16/32 3DL/2UL Constant 12 - - - - - -

QoS 6 Mix 10 16/32 4DL/1UL Constant 8 - 1 3 4 - -

QoS 6 Mix 10 64 4DL/1UL Constant 8 - 1 3 4 - -

QoS 6 Constant 4 16/32 3DL/1UL Mix 10 - 1 1 1 1 6

QoS 6 Mix 10 16/32 4DL/1UL Mix 4 - 1 1 1 1 -

QoS 6 Mix 10 64 4DL/1UL Mix 10 - 1 1 1 3 4

QoS 7 Constant 10 16/32 4DL/1UL Constant 10 - - - - - -

QoS 7 Constant 10 16/32 3DL/2UL Constant 12 - - - - - -

QoS 8 Constant 9 16/32 3DL/2UL Constant 12 - - - - - -

QoS2 6 Constant 10 16 4DL/1UL Mix 6 1 4 1 - - -

QoS2 6 Constant 10 32 4DL/1UL Mix 5 1 4 - - - -

QoS2 6 Constant 10 64 4DL/1UL Mix 6 1 4 1 - - -

Comparison: Number of Class 4 Mobiles in a Cell with 6 PDTCHs; TRAU = 16 k, all THPweight = 40, MTBR = 2.

Table 3-37 and Table 3-38 show the impact of QoS on the number of PDTCHs required tosupport a given traffic mix. The colored cells highlight the additional mobile being added forthe specified time period.

Table 3-37 QoS Disabled; Capacity: 18 users, DL Throughput per MS: 0.33 (6/18) TS

Mobiles 2 3 4 5 6 7 Link MS per TS

0 0 0 33 33 33 DL 0.501

0 0 0 0 100 0 UL

33 33 33 33 33 33 DL 1.002

0 100 0 0 100 0 UL

33 33 33 333 83 83 DL 1.333

0 100 0 0 100 100 UL

Continued

3-114 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Estimating timeslot provisioning requirements

Table 3-37 QoS Disabled; Capacity: 18 users, DL Throughput per MS: 0.33 (6/18)TS (Continued)

Mobiles 2 3 4 5 6 7 Link MS per TS

33 33 83 83 83 84 DL 1.674

0 100 0 100 100 100 UL

133 33 83 83 83 83 DL 1.835

100 100 0 100 100 100 UL

133 133 83 83 83 83 DL 2.006

100 200 0 100 100 100 UL

133 133 183 83 83 83 DL 2.177

100 200 100 100 100 200 UL

133 133 183 83 183 83 DL 2.338

100 200 100 100 200 200 UL

133 133 183 183 183 83 DL 2.509

100 200 100 200 200 200 UL

133 133 183 183 183 183 DL 2.6710

100 200 100 200 200 300 UL

233 133 183 183 183 183 DL 2.8311

200 200 100 200 200 300 UL

233 233 183 183 183 183 DL 3.0012

200 300 100 200 200 300 UL

233 233 283 183 183 183 DL 3.1713

200 300 200 200 200 300 UL

233 233 283 183 283 183 DL 3.3314

200 300 200 200 300 300 UL

233 233 283 283 283 183 DL 3.5015

200 300 200 300 300 300 UL

233 233 283 283 283 283 DL 3.6716

200 300 200 300 300 400 UL

333 233 283 283 283 283 DL 3.8317

300 300 200 300 300 400 UL

333 333 283 283 283 283 DL18

300 400 200 300 300 400 UL

333 333 283 283 283 283 DL19

300 400 200 300 300 400 UL

333 333 283 283 283 283 DL20

300 400 200 300 300 400 UL

Continued

68P02900W21-T 3-115

Jul 2010

Estimating timeslot provisioning requirements Chapter 3: BSS cell planning

Table 3-37 QoS Disabled; Capacity: 18 users, DL Throughput per MS: 0.33 (6/18)TS (Continued)

Mobiles 2 3 4 5 6 7 Link MS per TS

333 333 283 283 283 283 DL21

300 400 200 300 300 400 UL

333 333 283 283 283 283 DL22

300 400 200 300 300 400 UL

333 333 283 283 283 283 DL23

300 400 200 300 300 400 UL

Table 3-38 QoS Enabled; Capacity: 11 users, DL Throughput per MS: 0.54 (6/11) TS

Mobiles 2 3 4 5 6 7 Link MS per TS

1 0 0 0 33 33 33 DL 0.50

0 0 0 0 100 0 UL

2 33 33 33 33 33 33 DL 1.00

0 100 0 0 100 0 UL

3 33 33 67 67 67 33 DL 1.50

0 100 0 100 100 0 UL

4 83 83 67 67 67 333 DL 1.83

100 0 0 100 100 0 UL

5 83 83 67 67 117 83 DL 2.17

100 100 0 100 100 100 UL

6 83 117 100 100 117 83 DL 2.67

100 100 100 100 100 100 UL

7 83 117 150 150 117 83 DL 3.00

100 100 100 200 100 200 UL

8 83 117 150 150 167 133 DL 3.33

100 100 100 200 100 200 UL

9 133 167 150 150 167 133 DL 3.67

100 200 100 200 100 200 UL

10 133 167 150 150 167 233 DL 3.83

100 200 100 200 100 300 UL

11 233 167 150 150 167 233 DL 4.00

200 200 100 200 100 300 UL

12 233 167 150 150 167 233 DL

200 200 100 200 100 300 UL

Continued

3-116 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Configurable initial coding scheme

Table 3-38 QoS Enabled; Capacity: 11 users, DL Throughput per MS: 0.54 (6/11)TS (Continued)

Mobiles 2 3 4 5 6 7 Link MS per TS

13 233 167 150 150 167 233 DL

200 200 100 200 1200 300 UL

14 233 167 150 150 167 233 DL

200 200 100 200 100 300 UL

15 233 167 150 150 167 233 DL

200 300 100 200 100 300 UL

16 233 167 150 150 167 233 DL

200 200 100 200 100 300 UL

17 233 167 150 150 167 233 DL

200 200 100 200 100 300 UL

18 233 167 150 150 167 233 DL

200 200 100 100 100 300 UL

19 233 167 150 150 167 233 DL

200 200 100 200 100 300 UL

20 233 167 150 150 167 233 DL

200 200 100 200 100 300 UL

21 233 167 150 150 167 233 DL

200 200 100 200 100 300 UL

22 233 167 150 150 167 233 DL

200 200 100 200 100 300 UL

23 233 167 150 150 167 233 DL

200 200 100 200 100 300 UL

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 codingschemes, such as microcells. CS2 is still used to start when the carrier or PDTCHs assigned forthe 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 codingscheme.

QoS2 has default value of CS-2 and MCS3. If the coding scheme configured is lower, thebudgeted throughput per TS is lower.

In CTU2D ASYM mode, Carrier B’s UL TS is always restricted to GMSK (CS 1 to CS 4, or MCS 1to MCS 4). Therefore when the egprs_init_ul_cs is configured higher than MCS4 it is restrictedto MCS3 when admitting a new mobile on Carrier B.

68P02900W21-T 3-117

Jul 2010

GPRS/EGPRS data rates Chapter 3: BSS cell planning

For the cell with extended PDCH, lower initial coding scheme is configured as per the cellcoverage and radio condition, and not higher than default database value CS-2 and MCS3.

GPRS/EGPRS data rates

NOTE

• The information provided is for reference only. If required, it is also used tocalculate timeslot data rates at each layer. These are theoretical calculatedvalues, based on the protocol overheads at each layer. They do not necessarilyrepresent the data rates that the system can support.

• The final throughput at application layer is less than those quoted in the tablesdue to various protocol overheads and the behavior of various layers in responseto 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 signalingoverhead to acknowledge LLC frames. In practice, the LLC acknowledged mode imposesrelatively significant overhead at RLC/MAC level due to additional signaling requiredover the user data channel.

• V42.bis data compression is disabled (if V42.bis is enabled, the data rate is highly variabledepending 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, perfectTCP response is assumed. In practice, this imposes additional overhead since the channelis not fully utilized for certain portion of time.

• Increased efficiencies gained from lowered overhead, as a result of using higher numbersof 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

System Information: BSS Equipment Planning GPRS/EGPRS data rates

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 ofvarious coding schemes, user and header encoding procedures).

• LLC: Error free user data rate excluding RLC/MAC header, that is, LLC broken into RLCblocks (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 compressionis 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

Burst 1

Convolutional encoding (dictates code rate), Puncturing and Interleaving

Burst 2 Burst 3 Burst 4

Header RLC data Tail

Segment Segment Segment

LLC frame

Transmission across the radio link

LLClayer

RLC/MAC layer

Radio link layer

RLC block

ti-GSM-LLC_PDU_to_TDMA_bursts-00211-ai-sw

68P02900W21-T 3-119

Jul 2010

GPRS/EGPRS data rates Chapter 3: BSS cell planning

Table 3-39 through Table 3-64 provide illustrations of the data rates by application at eachlayer 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

RLC/MAC 20 18.4 27.6 36.8

Physical layer 33.86 67.72 101.58 135.44

Table 3-40 GPRS downlink data rates (kbps) with TCP (CS2)

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

LLC 12 24 36 48

RLC/MAC 13.6 27.1 40.65 54.2

Physical layer 33.86 67.72 101.58 135.44

Table 3-41 GPRS downlink data rates (kbps) with TCP (CS3)

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. userrate

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

Physical layer 33.86 67.72 101.58 135.44

3-120 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning GPRS/EGPRS data rates

Table 3-42 GPRS downlink data rates (kbps) with TCP (CS4)

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

Physical layer 33.86 67.72 101.58 135.44

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

Physical layer 33.86 67.72 101.58 135.44

Table 3-44 GPRS downlink data rates (kbps) with UDP (CS2)

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

LLC 12 24 36 48

RLC/MAC 13.6 27.1 40.65 54.2

Physical layer 33.86 67.72 101.58 135.44

68P02900W21-T 3-121

Jul 2010

GPRS/EGPRS data rates Chapter 3: BSS cell planning

Table 3-45 GPRS downlink data rates (kbps) with UDP (CS3)

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

Physical layer 33.86 67.72 101.58 135.44

Table 3-46 GPRS downlink data rates (kbps) with UDP (CS4)

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

LLC 20 40 60 80

RLC/MAC 21.6 43.1 64.7 86.2

Physical layer 33.86 67.72 101.58 135.44

Table 3-47 EGPRS downlink data rates (kbps) with TCP (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.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

3-122 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning GPRS/EGPRS data rates

Table 3-48 EGPRS downlink data rates (kbps) with TCP (MCS2)

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

Table 3-49 EGPRS downlink data rates (kbps) with TCP (MCS3)

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

Table 3-50 EGPRS downlink data rates (kbps) with TCP (MCS4)

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

GPRS/EGPRS data rates Chapter 3: BSS cell planning

Table 3-51 EGPRS downlink data rates (kbps) with TCP (MCS5)

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

Physical layer 101.58 203.16 304.74 406.32

Table 3-52 EGPRS downlink data rates (kbps) with TCP (MCS6)

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

Physical layer 101.58 203.16 304.74 406.32

Table 3-53 EGPRS downlink data rates (kbps) with TCP (MCS7)

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

Physical layer 101.58 203.16 304.74 406.32

3-124 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning GPRS/EGPRS data rates

Table 3-54 EGPRS downlink data rates (kbps) with TCP (MCS8)

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

Physical layer 101.58 203.16 304.74 406.32

Table 3-55 EGPRS downlink data rates (kbps) with TCP (MCS9)

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

Physical layer 101.58 203.16 304.74 406.32

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

GPRS/EGPRS data rates Chapter 3: BSS cell planning

Table 3-57 EGPRS downlink data rates (kbps) with UDP (MCS2)

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 EGPRS downlink data rates (kbps) with UDP (MCS3)

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 EGPRS downlink data rates (kbps) with UDP (MCS4)

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.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

3-126 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning GPRS/EGPRS data rates

Table 3-60 EGPRS downlink data rates (kbps) with UDP (MCS5)

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

Physical layer 101.58 203.16 304.74 406.32

Table 3-61 EGPRS downlink data rates (kbps) with UDP (MCS6)

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

Physical layer 101.58 203.16 304.74 406.32

Table 3-62 EGPRS downlink data rates (kbps) with UDP (MCS7)

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

Physical layer 101.58 203.16 304.74 406.32

68P02900W21-T 3-127

Jul 2010

GPRS/EGPRS data rates Chapter 3: BSS cell planning

Table 3-63 EGPRS downlink data rates (kbps) with UDP (MCS8)

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

Physical layer 101.58 203.16 304.74 406.32

Table 3-64 EGPRS downlink data rates (kbps) with UDP (MCS9)

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

Physical layer 101.58 203.16 304.74 406.32

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 featureand their operation within the Motorola system. The GSM half rate and the half rate portion ofAMR are similar. Hence, the information here covers both features.

The benefits of the features are outlined, and performance discussed. The manual gives anunderstanding of how AMR and GSM half rate works and how they are configured. The variousparameters controlling AMR operation are discussed. However, not all of the commands andparameters 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 4-1

Jul 2010

Introduction to AMR and GSM planning Chapter 4: AMR and GSM half-rate planning

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 bestbalance 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 primarylevels 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 channelconditions for best speech quality.

• Optimization of channel and codec control algorithms to meet specific user needs andnetwork 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 capablemobiles is high. However, the speech quality is poor when compared to the half rate mode ofAMR (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 orfull rate (fr) channel according to channel quality and the traffic load on the cell. Handoversbetween hr and fr channels vary according to traffic demands.

The best examples of applying the codec are:

• hr only for maximum capacity advantage.

• Mixed hr/fr operation allowing a trade-off between quality and capacity.

4-2 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 andAMR (full rate and/or half rate) simultaneously. The parameters that govern half rate operationhave 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. Thisequipment, with the supporting software and firmware, provides the capabilities necessary toexploit 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 asefficiently (this is discussed later in the chapter).

NOTEWithout 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 whichAMR 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 Chapter 4: AMR and GSM half-rate planning

NOTE

• It is assumed that an AMR-capable handset or mobile includes both fr and hrcapability.

• 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 halfrate, and what combination of new and old equipment is to be utilized. Other decisions, suchas codec rates and backhaul, must also be made. Utilization of the half rate capability of AMRand/or GSM half rate must also be made. Quality and capacity on page 4-5 describes thebenefits of the AMR codecs and how AMR Full Rate and AMR Half Rate compare to the existingGSM codecs. The GSM Half Rate codec is compared to the other GSM codecs. Also discussedare the benefits in coverage of AMR Full Rate. The capacity increases made possible with halfrate are discussed, with examples showing the potential gains under a variety of configurationsand (half rate) capable handset penetration.

The information in Quality and capacity on page 4-5 can be used to help determine how AMRfull rate and AMR/GSM half rate is utilized. As stated earlier, there are three primary methodsof AMR usage, two of which apply to GSM half rate:

• AMR full rate only (AMR only): This has the advantage of providing better voice qualityunder a broad range of channel conditions. This method is robust but provides no capacityadvantage per carrier. It is particularly suited to areas where adverse propagationconditions prevail.

• Forced half rate: This is used when capacity is paramount. Voice quality is sacrificedto carry more calls per carrier. It is used in severely congested areas, or where voicequality 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 coverageuntil congestion is reached. This capacity on-demand configuration is well suited forenvironments with varying traffic patterns. The information contained in Half rateutilization on page 4-17 can be used to help configure the system to maximum effectivenesswhen half rate is used.

Miscellaneous information on page 4-16 provides information on emergency call handlingand circuit pooling. Hardware on page 4-26 contains a description of the new hardware andwhat advantages it delivers.

4-4 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Quality and capacity

Quality and capacity■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Benefits of AMR

The ability of the AMR codec to change dynamically the allocation of source and channel codingbits provides a high level of speech quality. The overall improvements are dependant uponchannel quality (C/I). As channel quality deteriorates, a codec with a higher level of errorprotection (and a corresponding decrease in speech quality) is selected, leading to an increasein 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. Thiscan 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 handoversbetween the modes are permitted, a capacity gain can be realized because of the ability tooperate 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 codecsand 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-codingrate and a high level of error protection, is selected. This allows good speech quality to bemaintained under conditions 6 dB worse than the corresponding level for EFR. This translates toan improvement in terminal or BTS sensitivity, but is subject to the limit of robustness of thesignaling channels (presumed to be at least 2 dB, and possibly as high as 4 dB or 6 dB). Thiscan be exploited for range extension, or improved coverage in buildings. Range extension isdiscussed further in AMR voice quality improvement and coverage on page 4-9 later in thischapter.

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 shownfor comparative purposes. Mean Opinion Scores (MOS) are subjective. Test conditions affectMOS. However, the relative performance of the codecs to each other is reliable. The conditionsused in the tests are no background impairments, static channel conditions, and ideal frequencyhopping.

NOTEThe graphs in Figure 4-1 to Figure 4-4 and the accompanying information areextracted from GSM 06.75 (v. 7.2.0), Performance Characterization of the GSMAdaptive Multi-Rate (AMR) speech codec.

68P02900W21-T 4-5

Jul 2010

AMR Full Rate and AMR Half Rate speech quality Chapter 4: AMR and GSM half-rate planning

AMR Full Rate

In Figure 4-1, AMR FR speech quality (best AMR codec) is compared with EFR and performancerequirements under a range of channel conditions.

Figure 4-1 AMR FR/clean speech versus EFR versus performance requirements

ti-GSM-AMR_FR_clean_speech_versus_EFR-00112-ai-sw

1.0

2.0

3.0

4.0

5.0

Conditions

MOS

Sel. Requirements

AMR-FR

EFR

Sel. Requirements 4.01 4.01 4.01 3.65

AMR-FR 4.06 4.06 4.13 4.08 3.96 3.59 2.66

EFR 4.01 4.01 3.65 3.05 1.53

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

Figure 4-2 shows the individual codec modes for AMR FR/clean speech, as illustrated inFigure 4-1.

4-6 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning AMR Full Rate and AMR Half Rate speech quality

Figure 4-2 AMR FR/clean speech codec modes

ti-GSM-AMR_FR_clean_speech_codec_modes-00113-ai-sw

1.0

2.0

3.0

4.0

5.0

Conditions

MOS

EFR12.210.27.957.46.75.95.154.75

EFR 4.01 4.01 3.65 3.05 1.53

12.2 4.01 4.06 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

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

AMR half rate

Figure 4-3 and Figure 4-4 show performance curves for AMR HR speech quality compared toEFR as well as GSM FR and HR under the same range of channel conditions as the AMR FRcomparison shown in Figure 4-1 and Figure 4-2.

68P02900W21-T 4-7

Jul 2010

AMR Full Rate and AMR Half Rate speech quality Chapter 4: AMR and GSM half-rate planning

Figure 4-3 AMR HR/clean speech versus EFR versus GSM FR versus GSM HR versusperformance requirements

ti-GSM-AMR_HR_EFR_GSM_FR_GSM_HR_versus_perform_reqnts-00114-ai-sw

1.0

2.0

3.0

4.0

5.0

Conditions

MOS

Sel. Requirements

AMR-HR

EFRFRHR

Sel. Requirements 3.99 3.99 3.99 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

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-8 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning AMR voice quality improvement and coverage

Figure 4-4 AMR HR/clean speech codec modes

1.0

2.0

3.0

4.0

5.0

Conditions

MOS

EFR7.957.46.75.95.154.75FRHR

EFR

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

5.9

5.15

4.75

FR

HR

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 4.21 3.74 3.74 1.58

3.94 3.90 3.53 3.10 2.22 1.21

1.33

1.84

2.00

1.50

1.92

2.57

2.85

3.10

2.74

2.80

3.19

3.38

3.30

3.14

3.24

3.50

3.42

3.60

3.723.82

3.60

3.46

3.68

3.70

3.59

3.50

3.35

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 GSMFR/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 Chapter 4: AMR and GSM half-rate planning

A study has been done to quantify the potential coverage gains. The following assumptionsare used:

• System is interference-limited (the impact of thermal noise is negligible compared withthe level of interference).

• System is 100% loaded: all the available physical resources are used (this is the worst-caseassumption - coverage gains increase with less loading).

• Path loss exponent assumed to be 3.76, and the shadowing lognormal standard deviationis 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 thefrequency reuse patterns. The link budget improvement can potentially lead to an increasein cell areas around 27%.

This type of increase in coverage applies to existing networks where site spacing can bemodified 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-usepattern

Coverage at15 dB

Coverage at13 dB

Gain in coverage(increase in cell

radius)

Gain incoverage 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%

NOTEFirst 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 proportionof mobiles within a coverage area that supports Half Rate. GSM half rate has a high penetrationlevel (of GSM HR capable mobiles) due to its early introduction into the standards. Due to theselarge penetration levels, it is considered a viable option for high-density areas.

4-10 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 ofspeech 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 additionaltransceiver boards or carriers. The use of half rate can be tied to congestion at the cell levelto 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. MeanOpinion Scores (MOS) are subjective and can be affected by test conditions. However, therelative performance of the codecs to each other is reliable. The conditions used in the tests areno background impairments, static channel conditions, and ideal frequency hopping.

In conclusion, the GSM Half Rate codec voice quality performance is inferior to the othercodecs. This suggests a deployment strategy of using fr mode until capacity limitations forcecalls to utilize hr mode, at which time some fr calls can also be moved to hr. An hr call is alsomoved to a fr channel through an interference-based handover, depending on the congestionstate of the cell and system parameter settings, as well as a quality-based handover when noviable candidate neighbor cells exist.

The Motorola system supports this configuration, as well as many others, including forcing allcalls 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 carryingcapacity is typically less than 100% due in part to the penetration level of half rate capablehandsets. 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 ofcarrier configurations. For each configuration, the capacity increase is shown as a functionof 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 isassigned to an hr-capable carrier.

• Preference is at call establishment to assign an hr-capable handset an idle subchannel on atimeslot 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 carriersand hr-capable MS penetration and do not take into account any control channels. The actualcarried Erlangs can be slightly less than the Erlangs in the graphs.

68P02900W21-T 4-11

Jul 2010

Capacity increase due to half rate usage Chapter 4: AMR and GSM half-rate planning

Figure 4-5 3 carriers, only one hr-capable carrier

0.000

5.000

10.000

15.000

20.000

25.000

AMR Capable MS Penetration

Carried Erlangs(at ~2% blocking)

ti-GSM-3_carriers_only_one_hr_capable_ carrier-00116-ai-sw

0.00 0.200.10 0.30 0.40 0.50 0.60 0.70 0.80 0.90 1.00

Figure 4-6 3 carriers, all hr-capable

0.000

5.000

10.000

15.000

20.000

25.000

30.000

35.000

40.000

AMR Capable MS Penetration

Carried Erlangs(at ~2% blocking)

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

System Information: BSS Equipment Planning Capacity increase due to half rate usage

Figure 4-7 5 carriers, only one hr-capable carrier

0.000

5.000

10.000

15.000

20.000

25.000

30.000

35.000

40.000

AMR Capable MS Penetration

Carried Erlangs(at ~2% blocking)

0.00 0.20 0.40 0.60 0.80 1.00

ti-GSM-5_carriers_only_one_hr_capable_carrier-00118-ai-sw

Figure 4-8 5 carriers, only 3 hr-capable carriers

0.000

10.000

20.000

30.000

40.000

50.000

60.000

AMR Capable MS Penetration

Carried Erlangs(at ~2% blocking)

0.00 0.200.10 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 Chapter 4: AMR and GSM half-rate planning

Figure 4-9 5 carriers, all hr-capable carriers

0.000

10.000

20.000

30.000

40.000

50.000

60.000

70.000

80.000

AMR Capable MS Penetration

Carried Erlangs(at ~2% blocking)

0.00 0.200.10 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 amaximum capacity configuration, more carrier equipment should be configured as hr-capablewhen hr capable handset penetration raises. For example, in a 5 carrier cell with a 50% handsetpenetration rate, there is not much difference in Erlang capacity between a 3 hr-capablecarrier configuration and a 5 (all) hr-capable carrier configuration. The 5 hr-capable carrierconfiguration is better able to utilize the extra capacity that hr offers as the handset penetrationrises. 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 ofthe various components of the system have not exceeded. Use of hr improves the spectralefficiency over the air interface (and potentially the backhaul), but from a load perspective, ahalf 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 fewerhr-capable carriers. Figure 4-5 to Figure 4-9 demonstrates how even adding one hr-capablecarrier 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. Infull rate, each voice call occupies one timeslot. In half rate, the timeslot is split into twosubchannels, each of which is capable of supporting one hr call. A fr call cannot be carriedwithin 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 tohave fragmented hr usage. That is, it is best to use both subchannels of a single timeslot ratherthan one subchannel on two timeslots. This frees up contiguous subchannels for use in a fr call.

4-14 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Timeslot usage

The Motorola algorithm attempts first to assign new calls to timeslots that have one subchannelin use before using a timeslot with both subchannels idle. This provides a large degree ofconcentration. Some degree of fragmenting is unavoidable as calls begin and end and thealgorithm attempts to fill in the holes as new calls arrive. This applies to all arriving calls (forexample, originations, handovers, and so on).

It was also considered whether to further pack hr calls together through intra-cell handoverwhenever fragmenting reaches a level where a fr call can be blocked. Simulations have beencarried out under a variety of configurations and conditions, and it was determined that thenegative aspects of performing the otherwise unnecessary handover outweigh the slightcapacity gain. Although the results varied according to penetration rate and configuration, ingeneral, additional blocking of 1.5% or less resulted for the fr only handsets (as compared withthe hr-capable handsets). Limiting the number of hr capable carriers in a cell can reduce thisdisparity.

68P02900W21-T 4-15

Jul 2010

Miscellaneous information Chapter 4: AMR and GSM half-rate planning

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, acall of a lower priority is preempted. When selecting a call to preempt, the software attempts tominimize the disruption by choosing first a fr call of lower priority. Failing that, a lower prioritysingle occupancy hr call (the other subchannel is idle) is searched for, followed by a timeslotcarrying 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 fordifferent combinations of bearer capabilities. This can be realized in practice by grouping thecircuits into pools supporting the same channel types. The MSC holds this information as routedata. If the MSC allocates an A Interface circuit, it should only ask for resources from the BSSthat 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 selectedtaking 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, andAMR. The GDP2 supports FR, GSM HR, EFR, and AMR. The older XCDR card only supportsGSM full rate.

When a mix of transcoding equipment (GDP, EGDP/GDP2) is used with AMR being enabled, theMSC must select a CIC, which is attached to an EGDP or GDP2, if AMR is the only option allowedin the Channel Type element of the Assignment Request or Handover Request messages. IfAMR is one of the possible options (FR or EFR being the others) then the MSC should select anEGDP/GDP2 CIC. If the call is not AMR possible, the MSC should select a GDP CIC. If AMR isindicated 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 EGDPCIC. The ability of the MSC to select a CIC based on the available channel types is called circuitpooling. The BSC does not support the option to do the CIC selection, nor the circuit pool andcircuit pool list elements. Therefore, it is incumbent upon the MSC to do the selection. The MSCvendors (Alcatel, Siemens, Nokia, and Nortel) support circuit pooling. (Specifically it was askedabout 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 andrules, 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 SwitchingCenter - Base Station System (MSC - BSS) interface; Layer 3 specification.

4-16 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Half rate utilization

Half rate utilization■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Description

Some parameters associated with the usage of half rate (hr) allow the operator to tailor theirsystem to suit their needs. Brief descriptions of these parameters and their impact to systemoperation 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 MSCchannel type preference is overridden whenever possible. The parameter is checked uponarrival 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 aBSS 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 cellcongestion (that is, busy traffic channels). When triggered, the MSC channel type preference isoverridden whenever possible and the call is setup as the GSM hr or AMR hr depending on thespeech 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 levelof cell congestion (that is, busy traffic channels) allowing calls to be targeted at the AMR hrat a lower level of congestion than calls targeted at the GSM hr. When triggered, if the callhas AMR hr as the first permitted hr speech version, the MSC channel type preference isoverridden whenever possible and the call is setup as the AMR hr depending on the speechversion capability and the hr speech version preferences.

The parameters are checked upon arrival of a new call entering the system and for allhandovers. The parameter new_calls_amr_hr has no effect when the value is higher than thevalue of new_calls_hr since congestion relief is triggered based on the new_calls_hr whichtargets AMR hr and GSM hr.

68P02900W21-T 4-17

Jul 2010

Parameter descriptions Chapter 4: AMR and GSM half-rate planning

For multi-zone cells, the BSS considers only outer zone resources when establishing whetherthe threshold has been exceeded. Both the fr and hr resources within the outer zone are usedfor 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 isdisabled 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 ofthe existing congestion relief feature set; in particular, directed retry and advanced congestionrelief. These features must be enabled for those particular hr capabilities to operate properly. Abrief 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 acell basis that can trigger the handover of some calls to neighboring cells to reduce congestionin the triggering cell.

There are two sets of thresholds defined within a cell that control the triggering ofcongestion-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 reliefprocedure is initiated. The mb_tch_congest_thres parameter specifies the level at which aMultiBand MS is redirected to the preferred band. mb_tch_congest_thres must be less than orequal to tch_congest_prevent_thres.

When the congestion exceeds the relief threshold (tch_congest_prevent_thres), the BSSbehaves 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

System Information: BSS Equipment Planning Parameter descriptions

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 congestionin that cell. When the reconfig_fr_to_amr_hr threshold is exceeded, some fr calls with AMRhr as the first permitted hr speech version within a cell are reconfigured (by handover) tothe AMR hr on an hr channel within the same cell to reduce congestion in that cell. Theparameter reconfig_fr_to_amr_hr has no effect when the value is higher than the valueof reconfig_fr_to_hr since congestion relief is triggered based on reconfig_fr_to_hr whichtargets AMR hr and GSM hr.

This mechanism works in conjunction with the congestion relief feature, and needs congestionrelief to be enabled (within the cell). The threshold is calculated upon arrival of a new callentering the system and all handovers.

NOTEThe BSS applies qualification criteria to the half rate capable full rate calls beforeallowing the reconfiguration to a half rate traffic channel. The qualification isbased upon the existing congestion relief (directed retry alternatives) criteria forcongestion-based inter-cell handovers. The criteria identify calls, which are at theextremities of the cell by using a power budget calculation involving the neighborhandover congestion margin. The BSS does not perform reassignment to a halfrate traffic channel for a call, which is identified by the existing congestion reliefcalculations as being at the extremities of the cell. This qualification is performed inan attempt to ensure that the operator is provided with adequate QoS when the call isreassigned to a half rate traffic channel.

For multi-zone cells, the BSS considers only outer zone resources when establishing whetherthe threshold has been exceeded. Both the fr and hr resources within the outer zone are usedfor 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 (currentlyusing 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 isdisabled and is the default value. It is configurable on a cell basis.

68P02900W21-T 4-19

Jul 2010

Parameter descriptions Chapter 4: AMR and GSM half-rate planning

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 ofthe outer zone only within a cell.

Both concentric cells and dual band cells are multi-zone cells. The situation can occur where theinner zone has low usage but the outer zone is congested such that the reconfig_fr_to_hr orreconfig_fr_to_amr_hr threshold is exceeded. The BSS attempts to trigger full rate to halfrate intra-cell handovers for the calls that qualify. If some of the calls that qualify reside withinthe inner zone, the BSS attempts to reconfigure these half rate capable full rate calls to halfrate when the inner zone is not congested.

A similar situation can occur when the new_calls_hr or new_calls_amr_hr threshold isexceeded and new calls are assigned. To prevent these situations from occurring, an additionalthreshold 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 callsassigned to the inner zone, when the usage of the inner zone is low. The inner_hr_usage_thresand inner_amr_hr_usage_thres are applied when the utilization of half rate is triggered byreconfig_fr_to_hr and reconfig_fr_to_amr_hr are being exceeded and when new_calls_hr andnew_calls_amr_hr are exceeded.

If the threshold reconfig_fr_to_hr has been exceeded, half rate capable full rate calls residingon the inner zone are eligible as candidates for reconfiguration from full rate to half rate if theinner_hr_usage_thres has also been exceeded. If the threshold reconfig_fr_to_amr_hr hasbeen exceeded, full rate calls with AMR hr as the first permitted hr speech version residing onthe inner zone will only be eligible as candidates for reconfiguration from full rate to half rate ifinner_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 beassigned directly to half rate channels within the inner zone if the inner_hr_usage_thres hasalso been exceeded. If the threshold new_calls_amr_hr has been exceeded, calls with AMRhr as the first permitted hr speech version is only eligible to be assigned directly to half ratechannels within the inner zone if inner_hr_usage_thres or inner_amr_hr_usage_thres hasalso been exceeded

The range for both parameters is 0-101 in steps of 1%. The value of 101 indicates no halfrate usage in the inner zone and is the default value. The parameters are configurable on acell basis. The parameter inner_amr_hr_usage_thres has no effect when the value is higherthan the value of inner_hr_usage_thres since congestion relief is triggered based on theinner_hr_usage_thres which targets AMR hr and GSM hr.

4-20 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Parameter descriptions

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 reconfigurationthreshold), the hr resources must be available for the mechanism to work properly. This isnormally accounted for by setting reconfig_fr_to_hr, new_calls_hr, new_calls_amr_hr, andreconfig_fr_to_amr_hr such that when they are triggered, there are sufficient resourcesavailable for the half rate calls. However, in multi-zone cells, inner zone resources could beexhausted before any congestion thresholds are reached (the thresholds only consider outerzone resources).

To ensure that there are half rate resources available, the operator has the option to allow theBSS 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 arehalf rate capable resources available within the inner zone to allow half rate utilization-relatedprocedures to be employed. When only the reserved timeslots are left within an inner zone, afull rate resource is sought in the outer zone before the reserved timeslots in the inner zoneare considered.

The reserved timeslots are applied to the inner zone only, although it is configurable on all cellsand 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_tsby the BSS. The BSS limits the hr_res_ts for the inner zone if the BSS detects that theinner_hr_usage_thres or inner_amr_hr_usage_thres is not able to exceed if the hr_res_tselement is left as the user-defined. hr_res_ts is also limited by the number of half rate capableresources 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 numberof actual HR slots reserved by the inner_hr_usage_thres or inner_amr_hr_usage_thresparameters is always higher than hr_res_ts. This automatic adjustment ensures thatinner_hr_usage_thres or inner_amr_hr_usage_thres parameters will never get suppresed byhr_res_ts.

This parameter range is 0-255 in steps of one timeslot. The default value is 2 timeslots (eachtimeslot is capable of supporting two hr calls). It is configurable on a cell basis.

68P02900W21-T 4-21

Jul 2010

Parameter descriptions Chapter 4: AMR and GSM half-rate planning

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 tohow 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-basedhandovers within a period (hop_count_timer). If the hop_count is exceeded within thehop_count_timer period, the BSS triggers an inter-cell quality-based handover for the call. Ifso many intra-cell interference-based handovers are performed in a short period, it indicatesthat the cell is experiencing problems with bad interference and the call would be best servedby the network by being moved to another cell.

A similar mechanism is employed for intra-cell half rate interference handovers. All intra-cellhalf rate interference handovers contribute to the existing hop_count. The hr_fr_hop_countparameter is provided to limit the number of intra-cell interference-based handovers from hrto fr.

The BSS does not allow an intra-cell congestion handover to be performed by a call for whichthe hr_fr_hop_count is met and the hop_count_timer has not expired. This allows a callexperiencing repeated high interference levels to remain on a hr channel rather than fr duringcongestion. An inter-cell handover is not triggered by hr_fr_hop_count, for this functionalitythe existing hop_count parameter is used. The hop count timer (hop_count_timer) is anexisting parameter, used to qualify the new hr (hr_fr_hop_count) element and the existingelement (hop_count).

This parameter range is 0-255 in steps of 1. The default value is 1 hop. It is configurable on acell 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 handoversfor half rate channels. The element has 4 possible values, which take effect when an hr intra-cellhandover is triggered by the BSS. For interference-based handovers it further specifies thepossible target channel types - full and/or half rate. Quality-based handovers always target afull rate channel when handovers are enabled. The force_hr_usage element overrides anypreference 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 requiredis sent to MSC, then the control for this hr intra-cell handover is passed to the MSC by sending aHandover 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 noHandover Required is sent to MSC, then hr intra-cell handovers are not supported within thecell. The intra-cell handover request is ignored by the BSS.

4-22 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 onlyallowed, the BSS attempts to allocate a fr channel as a target resource for the hr intra-cellinterference or quality-based handover.

If hr_intracell_ho_allowed is set such that hr intra-cell handovers are enabled and hris allowed, the BSS attempts to allocate an hr or fr target resource for the hr intra-cellinterference-based handover, based on the congestion levels within the cell, the MSC preferenceand 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:

0 Half-rate intra-cell handovers are not initiated by the BSS. Handover Requiredsent to MSC.

1 Half-rate intra-cell handovers are disabled. Handover Required not sent toMSC.

2 Half-rate intra-cell handovers are enabled. Full-rate only allowed.

3 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 thehalf rate (AMR or GSM) strategy of the network. Where half rate is being used to maximizecapacity gains by half rate, with call quality of secondary concern, then a value of 3 should beused. Where half rate is being used to provide capacity gains using half rate but with moreemphasis 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 byenabling the force AMR hr usage parameter (force_hr_usage). This forces all hr-capable MSsto be placed on an available hr capable carrier, provided it is possible (that is MSC allows AMRhr 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 (dueprimarily to the lower MOS of hr) and to a lesser extent the prohibiting of hr to fr intra-cellhandovers). As an alternative to using force_hr_usage, new_calls_hr can be set low andhr_intracell_ho_allowed used to control intra-cell handovers. hr_intracell_ho_allowed canthen 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 voicequality (fr) level until cell congestion reaches a configurable threshold, at which point newhr-capable calls are assigned to hr channels (hr-capable means that the MSC allows AMR and/orGSM hr, the CIC is capable of the transcoding, an hr channel is available, and so on).

68P02900W21-T 4-23

Jul 2010

Operational aspects Chapter 4: AMR and GSM half-rate planning

By using the existing congestion relief feature and the cell reconfiguration threshold, additionalcapacity can be attained. As described earlier, the congestion relief feature can be used toidentify calls most likely to benefit from a switch to another, less congested, cell, and perform ahandover to move them. When this mechanism is employed, the operator can then use the cellreconfiguration 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 alltimeslots (not counting control channels). The inner zone utilization threshold is used inmulti-zone cells and prevents unnecessary inner zone reconfigurations. The configuration ofparameters 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 congestionrelief feature is enabled, then the cell reconfiguration threshold is set at a level at which it wishesto 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, ascalls qualifying for congestion relief are not candidates for fr to hr reconfiguration. If voicequality (that is, fr) is the primary concern, then congestion relief handover should be performedfirst. In addition, the reconfiguration threshold must not be set lower than the congestionthreshold for hr usage (new_calls_hr) and AMR hr usage (new_calls_amr_hr), otherwise callscould be assigned fr and immediately reconfigured to hr. For multi-zone cells, an inner zoneutilization threshold is selected. In many cases, the criteria for inner zone hr utilization is thesame as the outer zone. In these cases, the inner zone utilization threshold can be set the sameas 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 relief treshold

CONGESTION

HIGH

LOW

reconfig_fr_to_hr

new_calls_hr and inner_hr_usage_thres

ti_GSM-Congestion_threshold_settings_for_AMR_half-rate-00122-ai-sw

new_calls_amr_hr and inner_amr_hr_usage_thres

recongig_fr_to_amr_hr

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 toor less than the hop_count parameter. The hop count timer (hop_count_timer) is also set tothe desired value. The level of support of hr intra-cell handovers (hr_intracell_ho_allowed) isconfigured. The value of these settings is particular to the system being optimized.

4-24 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 enabledin the BSS and in a cell, half rate-enabled carriers are capable of supporting both AMR andGSM calls. The selection of AMR or GSM is dependent upon the MSC preferences (indicatedin the Channel Type element of the Assignment Request or Handover Request messages) andthe capabilities of the selected CIC.

68P02900W21-T 4-25

Jul 2010

Hardware Chapter 4: AMR and GSM half-rate planning

Hardware■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Equipment descriptions

New hardware (and associated software) has been developed to enhance the operation of AMRand/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 subrateswitching (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 BSCand (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 kbpsswitching, each half rate call needs a full 16 kbps backhaul bearer, or four 64 kbps timeslotsper carrier. With 8 kbps switching, the same backhaul as is required for full rate (two 64 kbpstimeslots) 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 andBSC. For every connected RXCDR with ESS enabled, 8 kbps backhaul can be used betweenthe BSC and that RXCDR.

Use of ESS mode needs all DSW2s to be used (within the BSC or RXCDR). KSWXs and DSWXsare used (exclusively or mixed), with the restriction that a KSWX cannot be connected to aDSWX or vice-versa. EC mode is available in the RXCDR and can be used to increase the numberof timeslots available. Each device (that is MSIs, GDPs, EGDPs, and GDP2s) needs a specificnumber of timeslots. By increasing the number of timeslots available across two shelves, morecombinations of equipment are possible. This capability is likely to be used in conjunction withthe RXU3 shelf, which provides for additional E1 connectivity. (More detailed information isavailable 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 connectedto a DSWX or vice-versa.

4-26 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Equipment descriptions

EGDP and GDP2

The current GDP can terminate 30 terrestrial circuits and handle the transcoding for GSMFull Rate (FR), Enhanced Full Rate (EFR) and GSM Half Rate (HR). It takes up one slot andconnects to a single E1 span line.

Due to the added processor burden required by AMR, the GDP cannot support 30 channelsbeyond FR/EFR/HR. Two cards however, operating in a tandem configuration through afirmware upgrade, can support two GDPs and 30 channels of FR/EFR/AMR. This arrangement oftwo GDPs is called an EGDP. It occupies two card slots and can terminate one E1 span line.

NOTEEGDP cannot support GSM HR.

A more efficient solution is provided through a new development, the GDP2. With itsupgraded DSP and other enhancements, the GDP2 is capable of transcoding 60 channels ofFR/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-RXU3shelf) 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 oneE1 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 ofMSIs 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 theextension RXCDR shelf, enhanced capacity mode must be enabled to access the second E1when GDP2s are used.

Within the BSC, the BSU shelf contains 12 MSI slots, of which up to 6 slots are used for thetranscoder function. All slots support the connectivity for two E1 terminations per card slot,allowing GDP2s to be used to capacity.

NOTEThese 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 twoof the earlier shelves. To accommodate the additional shelf capacity, the BSSC3 cabinet hasbeen developed which can terminate up to 76 E1 span lines. This is accomplished by adding 6additional 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 alternativeconfigurations available for the BSSC3.

68P02900W21-T 4-27

Jul 2010

Backhaul Chapter 4: AMR and GSM half-rate planning

NOTEEarlier BSUs/RXUs were used in the BSSC3 cabinet instead of or with the BSU2/RXU3.

Figure 4-11 Alternative configurations for the BSSC3 cabinet

BSU2 BSU2

BSU2

BSU2

RXU3

RXU3 RXU3

RXU3

Basic BSC2 With expansion shelf, or as 2 separate BSC2s

BSC2 with transcoding

BasicRXCDR2

RXCDR2 with expansion shelf

BSC2 Configuration RXCDR2 Configuration

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 aremapped to terrestrial resources at the RTF. Table 4-2 shows how the amount of backhaulconfigured 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:

• 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)

4-28 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Backhaul

Table 4-2 Backhaul configuration based on parameter settings

hr_enabled pkt_radio_type

allow_8 k_trau

0 = voiceonly

1 = 16 k dataand voice

2 = 32 kdata andvoice

3 = 64 k data and voice

0 - 16 k 16 k 32 k VersaTRAU

1 0 32 k 32 k (datauses only16 k)

32 k Not Supported (allow_ 8k_trau cannot be set to 0if pkt_radio_ type is 3)

1 1 16 k 16 k 32 k VersaTRAU

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_8k

_trau

0 = voiceonly

1 = 16 kdata andvoice

2 = 32 k dataand voice 3 = 64 k data and voice

0 - Full ratecall on 16k

Full rate call on leftmost 16 k subrategroup of the 32 k(duplicated on both 16k in the UL)

Full rate call on 16 k subratecorresponding to the airtimeslot - see Table 4-4.

1 0 2 half rate calls on separate16 k subrates

Not supported.

1 1 2 half rate calls share one16 k subrate

Half rate with 8 k switchingassigns the two half ratevoice channels to the two bitsallocated to an air timeslot.The first half rate voicechannel is allocated bit 0.The second half rate voicechannel is allocated bit 1.For example, air timeslot Bhas the first half rate channelassigned to B0 and the secondhalf rate channel assigned toB1 – see Table 4-4.

Table 4-4 Voice call mapping on the backhaul for a 64 k RTF

VersaTRAUsubchannel

DS0 Bit0

DS0 Bit1

DS0 Bit2

DS0 Bit3

DS0 Bit4

DS0 Bit5

DS0 Bit6

DS0 Bit7

0 A0 A1 B0 B1 C0 C1 D0 D1

1 E0 E1 F0 F1 G0 G1 H0 H1

2

68P02900W21-T 4-29

Jul 2010

Backhaul Chapter 4: AMR and GSM half-rate planning

Key: A - H are air timeslots 0 - 7 respectively.

NOTE

• The VersaTRAU Subchannel2 and any higher numbered VersaTRAU Subchannelsare always used to carry the multiplexed data for all the PDCHs configured onthis carrier.

• The tables give sample configurations for 16 kbps, 32 kbps, and 64 kbpsbackhaul. 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 inFigure 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

CIC CIC16 kbit/s Ater-CIC connection

RXCDR Switch

RXCDR Switch

16 kbit/s Ater allocated

16 kbit/s Ater allocated

BSCSwitch

BSCSwitch

16 kbit/s Abis backhaul backhaul

BTSSwitch

BTSSwitch

AMR fr call over air interface

hr call over air interface(w / 7.95 kbit/s)

EGDP/GDP2 EGDP/GDP2

CCUCCU

16 kbit/s Abis

16 kbit/sAfter-CICconnection

ti-GSM-AMR_backhaul_paths-00124-ai-sw

4-30 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Backhaul

For a connected AMR hr call not requiring the 7.95 codec rate or a GSM hr call, if ESS modeis enabled in the BSC, but not in the RXCDR, then the backhaul path shown on the left inFigure 4-13 results. For the same call, if ESS mode is enabled in the BSC and the RXCDR thenthe path is shown on the right in Figure 4-13 results. (The idle tone insertion is used internallyto fill the 16 kbps timeslot.)

Figure 4-13 hr backhaul paths - ESS mode enabled

16 kbit/s Ater-CIC connection

EGDP / GDP2

RXCDR Switch

BSCSwitch

BTSSwitch

CCU

CIC CIC

EGDP / GDP2

8 kbit/s Ater-CIC connection

RXCDR Switch

BSCSwitch

BTSSwitch

CCU

16 kbit/s Ater allocated

8 kbit/s Ater allocated

8 kbit/s idle tone

8 kbit/s Abis backhaul

8 kbit/s Abis backhaul

8 kbit/s idle tone

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 Chapter 4: AMR and GSM half-rate planning

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 ofFR/EFR/AMR per card slot) of what is currently supported for the GDP (30 channels FR/EFR/HRper 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 connectivityof only one E1 per card slot (for most slots). The RXU3 shelf provides 2 x E1 connectivity for allcard slots (enhanced capacity mode must be enabled to access the second E1 when GDP2s areused in non–MSI slots in the extension shelf). The earlier BSU shelf provides two E1 connectorsper card slot, for local transcoding configurations.

The BSSC2 cabinet provides for 48 E1 terminations. To use the RXU3 shelves to capacity, theBSSC3 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 theBSC and RXCDR, when hr is used. Additionally, within the RXCDR, use of DSW2s/DSWXscan support a greater number of timeslots, which translates to more combinations of cardtypes, 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 themicrocell. The planning steps and rules for the BSC are provided in Chapter 6 BSC planningsteps and rules, and that for the remote transcoder (RXCDR) are in Chapter 7 RXCDR planningsteps 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 5-1

Jul 2010

BTS planning overview Chapter 5: BTS planning steps and rules

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 methodand antenna configuration provides sufficient output power. Alternatives include changingcombiner types or using more than one transmitting antenna. Duplexers can be used toreduce 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 offsbetween 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 locationswhere there are no equipment shelters. Macro or microcell should be included whererooftop mounting or distributed RF coverage is required or where space and access arerestricted.

• 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

5-2 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Outline of planning steps

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 onpage 5-8.

• For receiver configuration (including planning for Dual Band), refer to the section Receiveconfigurations 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/CTU2Dconfiguration 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 basecontrol unit (microBCU) on page 5-25.

• For the number of network interface units required, refer to the section Network interfaceunit (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 controlunit on page 5-29.

• For the number of FOX and FMUX boards required, refer to the section Cabinetinterconnection on page 5-33.

• For battery back-up provisioning, refer to the section Battery back-up provisioning onpage 5-38.

• For external power supply requirements, refer to the section External power requirementson page 5-39.

• For using CTU8m/RCTU8m radios, the location of the CTU8m/RCTU8m radio in relationto the cabinet, the desired D4+/BBU-E redundancy level, refer to CTU8m D4+ Link onpage 5-44 .

68P02900W21-T 5-3

Jul 2010

Macrocell cabinets Chapter 5: BTS planning steps and rules

Macrocell cabinets■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Horizon II macro

Horizon II macro is the next generation replacement for Horizonmacro. Horizon II macro andHorizonmacro 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 reducingthe amount of E1 spans needed at a site that needs more than two RSLs. Horizonmacro andM-Cell BTSs currently support two RSLs per E1.

A Horizon II macro cabinet (indoor or outdoor) can support 12 carriers when populated fullywith six CTU2s/CTU2Ds, used in double density mode, or can support six carriers when the sixCTU2s/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 cabinetneeds additional cabinets. The maximum RF carriers supported per Horizon II macro SiteController (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 twoBBU-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 upto 6 CTU8ms or out-of-cabinet RCTU8ms or mixed configuration. The maximum RF carrierssupported is 24 carriers in one Horizon II macro cabinet. The Base Band Unit (BBU-E) isrequired to support (R)CTU8ms. The Horizon II macro can support up to two BBU-Es. Thecircuit 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 -48VDC and 220V AC 800W PSU and new 1600W PSU can be used for CTU8m in the Horizon IImacro cabinet with below recommendation:

Table 5-1 Specifications for CTU8m in Horizon II macro

Non-redundant mode Redundant modeNumber ofRadios

Number ofCTU2D

Number ofCTU8m

Number of800W PSUrequired

Number of1600W PSUrequired

Number of800W PSUrequired

Number of1600W PSUrequired

1 0 1 1 2 21

0 1 1 1 2 2

2 0 1 1 2 2

1 1 1 1 2 22

0 2 2 1 3 2

3 0 2 1 3 2

2 1 2 1 3 2

1 2 2 1 3 23

0 3 2 1 3 2

Continued

5-4 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Horizonmacro

Table 5-1 Specifications for CTU8m in Horizon II macro (Continued)

Non-redundant mode Redundant modeNumber ofRadios

Number ofCTU2D

Number ofCTU8m

Number of800W PSUrequired

Number of1600W PSUrequired

Number of800W PSUrequired

Number of1600W PSUrequired

4 1 2 1 3 2

3 2 2 1 3 2

2 3 2 1 3 2

1 4 3 2 4 3

4

0 4 3 2 4 3

5 0 3 2 4 3

4 1 3 2 4 3

3 2 3 2 4 3

2 3 3 2 4 3

1 4 3 2 4 3

5

0 5 3 2 4 3

6 0 3 2 4 3

5 1 3 2 4 3

4 2 3 2 4 3

3 3 3 2 4 3

2 4 3 2 4 3

1 5 4 2 N/A 3

6

0 6 4 2 N/A 3

The Horizon II macro outdoor is a Horizon II macro indoor along with an outdoor enclosure thatincorporates heat management. The Horizon II macro outdoor can operate in the temperaturerange from -40 °C to 50 °C.

NOTEThe Horizon II macro does not support the use of CCBs.

Horizonmacro

A Horizonmacro cabinet (indoor or outdoor) can support six carriers (CTUs). Expansion beyondsix carriers needs additional cabinets. The Horizonmacro 12 carrier outdoor is, in effect, anoutdoor enclosure which can accommodate either one or two indoor cabinets for 6 or 12 carrieroperation.

NOTECCBs cannot be used with the Horizonmacro indoor cabinet if the cabinet is to beinstalled in the 12 carrier outdoor enclosure.

68P02900W21-T 5-5

Jul 2010

Horizoncompact and Horizoncompact2 Chapter 5: BTS planning steps and rules

All Horizonmacro cabinets/enclosures incorporate heat management systems. TheHorizonmacro outdoor can operate at ambient temperatures up to 50 °C. The Horizonmacro 12carrier outdoor can operate at ambient temperatures up to 45 °C.

Horizoncompact and Horizoncompact2

The Horizoncompact and the Horizoncompact2 are an integrated cell site, designed primarilyfor 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 isthat the latter can be expanded to support two additional BTSs.

• In this document, future references to Horizoncompact2 also includeHorizoncompact 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 beyondthis needs additional cabinets. Outdoor cell sites are provided with an ancillary cabinet anda side cabinet.

The M-Cell6 HMS has the following options:

• 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.

5-6 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning M-Cell2

M-Cell2

The M-Cell2 cabinet can support two carriers (CTU2 Adapter in EGPRS configuration) orfour carriers (CTU2 Adapter in non-EGPRS configuration). The M-Cell2 outdoor cabinetaccommodates all the elements in an indoor cabinet. It also provides limited accommodation forLTUs and battery backup. A fan within the cabinet provides cooling. Unlike M-Cell6 outdoorcabinets where the antenna terminations are in a side cabinet, M-Cell2 terminations areon 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 Chapter 5: BTS planning steps and rules

Microcell enclosures■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Horizon II mini

The Horizon II mini BTS satisfies the Horizon II macro requirements, and adds significantfunctionality 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 IImini operates like a Horizon II macro cabinet. The Mini BTS can be expanded from theHorizon II macro, Horizonmacro, and M-Cell6. The Horizon II mini enclosure can house twoCTU2s/CTU2Ds that can be configured in both single density and double density mode. If theCTU2D Capacity feature is unrestricted, the mode capacity can be configured for CTU2D. As aresult, the carrier capacity is 1-4 carriers, for a maximum network configuration of 16 to 24carriers per site dependent on cabinet capacity.

{34371G} A Horizon II mini cabinet when fully populated can support up to 2 CTU8ms. Themaximum RF carriers that can be supported in one Horizon II mini cabinet is 16 carriers usingCTU8m at 8 carriers mode, 12 carriers using CTU8m at 6 carriers mode, or 8 carriers usingCTU8m at 4 carriers mode.

A Horizon II mini cabinet can support up to 6 out-of-cabinet (R)CTU8ms. The maximum RFcarriers 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 cansupport 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 DCand 220V AC 800W PSU and new 1600W PSU can be used for CTU8m in the Horizon II minicabinet. 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, orreconstituted stone, with or without rendering.

Software parameters are added to distinguish Horizon II mini cabinets to allow easierconfiguration. 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 forredundancy hardware.

Horizon II mini can only be equipped with CTU2/CTU2D radios and, therefore, supports EGPRS.

NOTEThe Horizon II mini uses E1 links for both TRAU and RSL and can be expanded from aHorizonmacro family BTS or be used as a network of Horizon II mini cabinets.

5-8 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Horizonmicro and Horizonmicro2

SDH feature

Horizon II mini also supports an auxiliary power supply or an optional third-party SDH modulerequiring 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.

NOTEThe outdoor enclosure configuration cannot be expanded in a network, as thecommunications 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 foroutdoor operation and consist of a single small two-carrier BTS unit. The Horizonmicro andHorizonmicro2 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 thatthe latter can be expanded to support two additional BTSs.

• In this document, future references to Horizonmicro2 also include Horizonmicrounless stated otherwise.

Horizon II micro

The Horizon II micro is an integrated cell site, designed for indoor, and outdoor microcellularapplications and consists of a single small two carrier BTS (CTU2/CTU2D) unit. It can beconfigured for two carriers in double density mode for GSM/GPRS or one carrier in SingleDensity mode for EGPRS. If ITS is unrestricted and enabled, double density mode can be usedfor EGPRS. If the CTU2D Capacity feature is unrestricted, the mode capacity can be configuredfor 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 targetapplications in both 900 MHz and 1800 MHz bands.

{34371G} The Horizon II micro cabinet can support the RCTU8m only. A Horizon II microcabinet can support up to six out-of-cabinet RCTU8ms. The maximum RF carriers that can besupported 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 Chapter 5: BTS planning steps and rules

Cooling is by natural convection or by an internal fan. The unit can operate at ambienttemperatures up to 50 °C.

5-10 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Receive configurations

Receive configurations■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The receiver equipment provides the termination and distribution of the received signalsfrom the Rx antennas. Receiver equipment is required for each Rx signal in every cabinet orenclosure 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 singleantenna. 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 onDCS1800 frequencies.

Planning considerations

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 inthe BTS cabinet. With RCTU8m radios, the antennas for a sector are directly connected to theRCTU8m radio and no other receiver equipment is required.

The RCTU8m radio has two antenna ports that can be connected directly to one or two antennaswithout additional receive equipment. The RCTU8m also supports 2-way diversity using theseantennas. 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 whenplanning 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 installedto provide 4-branch diversity.

NOTE

• 4 branch receive diversity is not supported with the CTU8m radio.

• For Horizon II macro only, an optional SURF2 dual-band adapter allowsa 900 MHz SURF2 and a 1800 MHz SURFs to be installed in the samecabinet, thus providing dual band capability.

68P02900W21-T 5-11

Jul 2010

Planning considerations Chapter 5: BTS planning steps and rules

Receive antennas can be extended across Horizon II macro/Horizon II mini cabinets byusing 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 SURFexpansion 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 expansionports to feed an IADU in another cabinet.

DCS1800

GSM carriers can be supported using remote RCTU8m radios, or through the radios located inthe BTS cabinet. With RCTU8m radios the antennas for a sector are directly connected to theRCTU8m radio and no other receiver equipment is required.

The RCTU8m radio has two antenna ports that can be connected directly to one or two antennaswithout additional receiver equipment. The RCTU8m also supports 2-way diversity using theseantennas. 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 whenplanning 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 inseparate cabinets. For Horizon II macro only, a second (optional) 1800 MHz SURF2 canbe installed to provide 4-branch diversity.

NOTE4 branch receive diversity is not supported with the CTU8m radio.

Receive antennas can be extended across Horizon II macro/Horizon II mini cabinets byusing the 1800 SURF2 expansion ports to feed a SURF2 in another cabinet.

• Horizonmacro BTSs need one 1800 MHz SURF for each cabinet. Receive antennas canbe extended across Horizonmacro cabinets by using the 1800 SURF expansion ports tofeed a SURF in another cabinet.

NOTETwo types of 1800 SURF are available: One is 1800 MHz single band and theother is 1800 MHz/900 MHz dual band.

• M-Cell2 and M-Cell6 BTSs need one LNA for each sector. Receive antennas can beextended across M-Cell6 cabinets by using the LNA expansion ports to feed an LNAin another cabinet.

5-12 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning considerations

DCS1800 and GSM900

It should be considered that Horizon II macro dual band capable cabinets need one 1800 MHzSURF2, 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 configurationis 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 SURF2controls 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 physicalconfiguration.

Dual-band configurations can also be created using the RCTU8m radio which is not subject tothe restrictions above. The 900 MHz and 1800 MHz RCTU8m radios can be mixed remotelyfor the Horizon II cabinets, as each RCTU8m radio is connected to its own antennas to receivethe signal.

Receiver planning actions

The following planning actions are required:

• Determine the number of cells.

• Determine the number of cells which have {34371G}CTU8m CTU2s/CTU2Ds/CTUs/TCUsin 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

• {34371G}When using CTU2s/CTU8m, in high-density mode, all carriers shouldbe in the same sector. Disabling one carrier does not affect other CTU2/CTU8mcarriers.

• All carriers supported on a CTU8m or RCTU8m radio must be in the same sectorand frequency band. Dropping one carrier does not impact the other carrierson that radio.

68P02900W21-T 5-13

Jul 2010

Transmit configurations Chapter 5: BTS planning steps and rules

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 andM-Cell6 cabinets, a TxBPF is required for each antenna.

NOTE

• Horizonmicro2 and Horizon II micro are two-carrier only, combined to a singleantenna.

• 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 2carriers per Tx output).

• The 6-carrier mode supports the 3GPP Release 8 MCBTS Class 2 specification (1 to 3carriers per Tx output).

• The 8-carrier mode supports the 3GPP Release 8 MCBTS Class 2 specification (1 to 4carriers per Tx output).

Different countries may restrict the use of the radios operating to the 3GPP Release 8 MCBTSClass 1 or 2 specifications. If a country does not license the use of the 3GPP Release 8 MCBTSClass 1 equipment, then CTU8m/RCTU8m radios cannot be deployed in that country. If thecountry permits the use of 3GPP Release 8 MCBTS Class 1 equipment but restricts the useof 3GPP Release 8 MCBTS Class 2 equipment, then the CTU8m/RCTU8m radio may only beoperated in 4-carrier mode.

As a CTU8m radio provides two transmit outputs per radio slot in the cabinet, a new hybridcombining duplexer (HCD) combines these two outputs and also provides a duplexer function ina device.

CTU8m radios must be compatible with newer duplexers or HCDs to meet the earlier discussedMCBTS classes. Older duplexers supplied before the GSR10 release must not be used with theCTU8m radios (use SVLF9150G or later). The latest GSR10 duplexers are backward compatible.

Planning considerations

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

System Information: BSS Equipment Planning Planning considerations

Table 5-2 Transmit configurations – pre-CTU8m radio

Number of Carriers BTS TypesCabinet Transmit

Configurations WideBand Combining

Cabinet TransmitConfigurations Cavity

Combining

1 M-Cell2 andM-Cell6

1 TxBPF Not available

1 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 (Bowtie-Combiner)

Not available

2 M-Cell2 andM-Cell6

1 HCOMB + 1 TxBPF 1 CCB output

2 Horizonmacro 1 DCF 1 CCB output

3 M-Cell6 2 HCOMB + 1 TxBPF 1 CCB output

3 Horizonmacro 2 DCF or 1 DDF 1 CCB output

3 or 4 Horizon II macro DUP + 1 HCU or 2DUP and Air

CCBs not supported

3 or 4 Horizon II mini 2 DUP (Bowtie-Combiner) and Air

CCBs not supported

4 M-Cell6 2 HCOMB + 1 TxBPF 1 CCB output + 1CCB extension

4 Horizonmacro 1 DDF + 1 HCU 1 CCB output + 1CCB extension

5 M-Cell6 HCOMB + 1 TxBPF 1 CCB output + 1CCB extension

5 Horizonmacro 2 DDF and Air 1 CCB output + 1CCB extension

6 M-Cell6 4 HCOMB + 1 TxBPF 1 CCB output + 1CCB extension

6 Horizonmacro 2 DDF and Air 1 CCB output + 1CCB extension

6 Horizon II macro 1 DUP + 1 DHU or 2DUP + 1 HCU and Air

CCBs not supported

NOTEA CCB output includes a TxBPF, but a CCB extension does not include it.

68P02900W21-T 5-15

Jul 2010

Planning considerations Chapter 5: BTS planning steps and rules

With the CTU8m radio, the supported configurations per BTS depend on whether the radio isoperated in 4, 6, or 8 carrier mode. Table 5-3 shows the per-sector transit configurations ofthe CTU8m in 4-carrier mode. Table 5-4 shows the alternative configurations with CTU8moperating in the 6-carrier mode and 8-carrier mode respectively.

NOTE

• Cavity combining is not supported with the CTU8m radio.

• The CTU8m radio is supported only by the Horizon II macro and Horizon IImini BTSs.

Table 5-3 Transmission configurations – CTU8m in 4-carrier mode

Number ofCarriers BTS Type

Cabinet TransmissionConfigurations – Wide

Band CombiningNotes

4Horizon II macroHorizon II mini

1 HCD or 2 DUP and Air

6Horizon II macroHorizon II mini

1 DHU + 1 DUP or 1 HCD +1 DUP and Air

Using one CTU8m with oneCTU2D

8 Horizon II macro 2 HCD + 2 DUP and Air Using 2 CTU8ms

10Horizon II macro 1 HCD + 1 DHU + 1 DUP

and AirUsing 2 CTU8ms with oneCTU2D

12 Horizon II macro 2 DHU + 2 DUP and Air Using 3 CTU8ms

Table 5-4 Transmission configurations – CTU8m in 6-carrier mode

Number ofCarriers BTS Type

Cabinet TransmissionConfigurations – Wide

Band CombiningNotes

6Horizon II macroHorizon II mini 1 HCD or 2 DUP and Air

12 Horizon II macro 2 HCD and Air Using 2 CTU8ms

Table 5-5 Transmission configurations – CTU8m in 8-carrier mode

Number ofCarriers BTS Type

Cabinet TransmissionConfigurations – Wide Band

CombiningNotes

8Horizon II macroHorizon II mini 1 HCD or 2 DUP and Air

If more than six duplexers/combiner units are required to support the radios in a single HorizonII macro cabinet, a duplexer expansion frame may be fitted above the Horizon II macro cabinetto provide 12 duplexer/combiner bays.

The RCTU8m radio has two antenna ports which are connected directly to the antennas bysuitable cables. No additional RF hardware is required.

5-16 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Transmit planning actions

CTU2D, CTU8m, and RCTU8m radios may be used together to support carriers that are inthe same cell. However, the cables from each radio to the antennas must not differ in lengthby 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 EMCshielding.

68P02900W21-T 5-17

Jul 2010

EGPRS enabled CTU2/CTU2D configuration Chapter 5: BTS planning steps and rules

EGPRS enabled CTU2/CTU2D configuration■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

EGPRS enabled CTU2/CTU2D configuration limitations

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

EGPRS general configuration

The EGPRS feature needs additional backhaul to provision EGPRS carriers. The additionalbackhaul is either seven DS0s to implement EGPRS on a BCCH carrier or eight DS0s toimplement EGPRS on a non- BCCH carrier, if VersaTRAU feature is restricted. If VersaTRAUfeature is unrestricted, the backhaul for an EGPRS carrier can be configured using thertf_ds0_count parameter.

If VersaTRAU is restricted, the maximum number of EGPRS carriers that can be equipped for athree sector site is 21. The total number of E1s available at a Horizonmacro or Horizon II macrosite 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 mustbe 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-caseconfiguration when every possible timeslot is configured as an EGPRS carrier in a three-sectorsite 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 sameconfiguration can be up to 24. If the recommended non-aggressive backhaul of five DS0s perEGPRS carrier is used, six EGPRS carriers (using 30 DS0s) can be configured on each E1. Thiswould need four E1s for the 24 EGPRS carriers leaving the remaining four DS0s availablefor RSLs.

BaseBand Hopping (BBH)

There are several restrictions for an EGPRS enabled CTU2/CTU2D.

5-18 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Broadcast Control CHannel (BCCH) RTF configuration

Baseband hopping (BBH) is only allowed with other EGPRS enabled CTU2 radios in the samehopping group. Table 5-6 and Table 5-7 show the restrictions for the Horizon II macro SiteController and the Horizonmacro Site Controller respectively. In ITS mode, EGPRS doubledensity carrier A and its pair are excluded for BBH. For BBH restriction aspect, CTU2D PWRmode and ITS mode are identical. In CTU2D CAP mode, the BBH restrict ion on carrier A isthe same as PWR mode, and GMSK carrier B supports for BBH. In CTU2D ASYM mode, all theEGPRS carriers (in SD/DD/Capacity mode) within the site are removed from BBH system.

For the cell with extended PDCH, BBH is disabled.

NOTETable 5-6 indicates that BBH is not permitted with EDGE enabled CTU2s whenHorizonmacro is the Master Site Controller. BBH is only permitted with EDGE enabledCTU2s 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 (SDEGPRS)

CTU2 (DDGSM)

CTU2 (SDGSM) CTU (SD GSM)

CTU2 (SD EGPRS) 4 6 6 6

CTU2 (DD GSM) 6 4 4 4

CTU2 (SD GSM) 6 4 4 4

CTU (SD GSM) 6 4 4 4

Table 5-7 BBH capability for Horizonmacro Site Controller

CTU2 (SDEGPRS) CTU2 (DDGSM) CTU2 (SD

GSM) CTU (SD GSM)

CTU2 (SD EGPRS) 6 6 6 6

CTU2 (DD GSM) 6 6 6 6

CTU2 (SD GSM) 6 6 4 4

CTU (SD GSM) 6 6 4 4

Broadcast Control CHannel (BCCH) RTF configuration

The Broadcast control channel (BCCH) Radio Transceiver Function (RTF) should be configuredas a 64 k carrier. For EGPRS, the only radio that supports 64 k is the CTU2/CTU2D. It is notnecessary 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 mixedradios, to maximize power savings, the BTS software prefers to allocate the BCCH carrier tonon-power-saving radios. Power savings delivered by this feature increase with the number ofTCHs in the BCCH available for traffic allocation, providing priority of the BCCH carrier in trafficallocation (for example, chan_alloc_priority) is configured to be higher than any other carriers.

68P02900W21-T 5-19

Jul 2010

Carrier equipment (transceiver unit) Chapter 5: BTS planning steps and rules

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 (singlecarrier) 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.

NOTECCBs are not supported by the CTU2/CTU2D (refer to Chapter 1 Introduction toplanning for more information of CTU2D configuration).

The CTU8m/RCTU8m has two transmission ports and each port can be configured to operateup to {35200G} 4 carriers mode. The RCTU8m is a remote radio head, it can be deployed amaximum of 1000 m away per hop.

NOTEThe 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 bythe 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 anenhancement 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, exceptfor 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

System Information: BSS Equipment Planning 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 Horizonmacroindoor 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 anoptional 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 losingthe internal battery backup facility. In cases where battery backup is required, an externalbattery backup unit (BBS) needs to be added. In addition, where a third (redundant) PSM isalready installed, redundancy is lost. Table 5-8 lists the CTU/CTU2 combinations and powersupply requirements in Horizonmacro and Horizon II macro cabinets. This table applied toboth GPRS and the EGPRS feature overlay.

NOTETable 5-8 does not include Horizon II mini, as Horizon II mini needs only one powersupply as minimum/maximum.

Table 5-8 CTU/CTU2 power requirements

Horizonmacro Horizon II macro

Number ofCTUs

Number ofCTU2s

Number of powersupplies required

Number ofCTU2s

Number of powersupplies required

6 0 2 6 3

5 1 3 5 3

4 1 2 4 3

3 1 2 3 2

2 1 2 2 2

1 1 1 1 1

Continued

68P02900W21-T 5-21

Jul 2010

CTU/CTU2 power supply considerations Chapter 5: BTS planning steps and rules

Table 5-8 CTU/CTU2 power requirements (Continued)

Horizonmacro Horizon II macro

Number ofCTUs

Number ofCTU2s

Number of powersupplies required

Number ofCTU2s

Number of powersupplies required

0 1 1

4 2 3

3 2 2

2 2 2

1 2 2

0 2 2

3 3 3

2 3 3

1 3 2

0 3 2

2 4 3

1 4 3

0 4 2

1 5 3

0 5 3

0 6 3

NOTEThe Horizon II macro always has a spare fourth power supply slot available for eithera 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 andM-Cell2 cabinets. This table is independent of the CTU2 operating mode or feature overlay. Thistable assumes that slots that do not use CTU2 adapters are populated with TCUs.

5-22 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning considerations

Table 5-9 CTU/CTU2 power requirements for M-Cell cabinets

Number of CTU2 Adapters Number of power supplies required

M-Cell6 AC Indoor:

1–6 5

M-Cell6 AC Outdoor:

1–4 3

5–6 4

M-Cell6 DC Indoor:

1–4 2

5–6 2 (add one more for redundancy)

M-Cell2 AC Indoor and M-Cell2AC Outdoor:

1 1

2 1 (add one more for redundancy)

Planning considerations

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 howto determine the number of control channels required is in the Control channel calculationson page 3-52 section in Chapter 3 BSS cell planning.

• One transceiver unit is required to provide each RF carrier. However, with the introductionof the CTU2/CTU2D this is no longer true. The CTU2/CTU2D is capable of single anddouble density operation for GSM/GPRS; one CTU2/CTU2D can support one RF carrier orbe configured to support two RF carriers. The exception to this is for EGPRS. An EGPRSenabled CTU2 can only be configured in single density mode (that is, one CTU2 percarrier). If ITS feature is unrestricted and enabled, an EGPRS enabled CTU2 can also beconfigured in double density mode but with timeslot blanking on the paired carrier. Withthe introduction of CTU2D more modes, that is, CAP and ASYM, can support EGPRS withdouble density without timeslot blanking.

• Include redundancy requirements. Redundancy can be achieved by installing excesscapacity in the form of additional transceiver units.

• Plan the number of power supplies required in accordance with the number of transceiversrequired.

68P02900W21-T 5-23

Jul 2010

Transceiver planning actions Chapter 5: BTS planning steps and rules

• {34416} Traffic packing for power saving. The amount of power saved by the feature isproportional to the number of TSs re-allocated from power-saving radios onto the BCCHand the non-power-saving radios. Power savings delivered by this feature increase with thetraffic 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 radiosis 50%. Adding more power-saving radios beyond this only generates power savings fromtheir sleeping capabilities in idle state.

Transceiver planning actions

Determine the number of transceivers required and the number of power supplies requiredto power the transceivers.

5-24 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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.

Planning considerations

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 ithas a built-in digital module shelf. However, unlike Horizonmacro, the NIU is integratedon the HII Site Controller (HIISC or HIISC2-S or HIISC2-E) and external FMUXs andBPSMs are not required. The digital module shelf can be equipped for redundancy and/oradditional 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 theHorizonmacro equivalent of M-Cell6 microBCU cage functionality.

The digital module shelf can be equipped for redundancy and/or additional E1 link capacitywith 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 equippedfor 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 beequipped for redundancy and/or additional E1 link capacity. Additional cabinets do notneed 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 Chapter 5: BTS planning steps and rules

Network interface unit (NIU) and site connection■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The NIU provides the interface for the Horizon II macro, Horizonmacro or M-Cell2/6 BTSto the terrestrial network.

NOTE

• M-Cellcity and M-Cellcity+ are fitted with a single NIU-m only.

• The equivalent modules in Horizoncompact2 and Horizonmicro2 areRHINO/DINO.

Planning considerations

Depending on the BTS equipment installed, the following factors should be considered whenplanning the NIU complement:

Horizon II macro/Horizon II mini

• Both Horizon IImacro and Horizon IImini require a Horizon II site controller (either theHIISC or either the HIISC2-S or HIISC2-E).

• NIU functionality is integrated into the Horizon II site controller (either the HIISC or eitherthe HIISC2-S or HIISC2-E). From a functional standpoint, the Integrated NIU functions thesame as the standalone NIU with the exception that support for 4 RSL links per E1 and amaximum 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 orHIISC2-E) is required in the master cabinet for each Horizon II macro BTS site. Horizon IImini does not support hardware redundancy.

• For a Horizon II macro master cabinet, redundancy for the NIU functionality depends on amatching redundant Horizon II site controller (either the HIISC or either the HIISC2-Sor BBU-E). If a redundant HIISC is installed, a redundant site expansion board is alsorequired. Slave Horizon II macro cabinets connected to the master cabinet also requireredundant site expansion boards and redundant XMUXs.

5-26 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning considerations

NOTEFor Horizon II macro only: The integrated NIU within the redundant Horizon IIsite controller (HIISC or HIISC2-S or HIISC2-E) has connectivity to all the E1 linksfor that site through the use of relays and switches. The redundant Horizon II sitecontroller (HIISC or HIISC2-S or HIISC2-E) can be switched automatically to becomethe main Horizon II site controller, taking over all duties of the main Horizon II sitecontroller (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) caninterface 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 ownequipment, and that of other sites, which are connected to it by the drop and insert (daisychain) 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. Inthe drop and insert (daisy chain) configuration, every site needs its own 64 kbpslink 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 asingle 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 numberof NIU required

Number of μBCUcages required Notes

1 1 1 M-Cell2 and M-Cell6

2 1 1 M-Cell2 and M-Cell6

3 2 1 M-Cell6

3 2 2 M-Cell2 and M-Cell6

Continued

68P02900W21-T 5-27

Jul 2010

NIU planning actions Chapter 5: BTS planning steps and rules

Table 5-10 Site connection requirements for M-Cell2 and M-Cell6 (Continued)

Number of E1 links Minimum numberof NIU required

Number of μBCUcages required Notes

4 2 2 M-Cell2 and M-Cell6

5 3 2 M-Cell6 only

6 4 2 M-Cell6 only

NOTEOnly 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

System Information: BSS Equipment Planning 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 unitused depends on the BTS equipment:

• Both Horizon II macro and Horizon II mini use a Horizon II macro site controller (HIISC orHIISC2-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 inM-Cell6 and M-Cell2 BTSs.

• Horizon II mini is a new small macro BTS and the HIISC (or HIISC2-S orHIISC2-E) used within can support a maximum of 24 RF carriers acrossthe sites.

• The HIISC (or HIISC2-S or HIISC2-E) used in Horizon II macro can alsosupport 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 tothe Horizon II Site Controller 2 (HIISC2) within the GSM Horizon II BTS family. It is responsiblefor majority of the digital baseband processing for multiple radio units (for example, channelcoding/decoding, some filtering, demodulation, equalization, modem control loops, and soon) and the Radio Sub-System processing.

The BBU-E has three D4+ SFP ports to connect to the (R)CTU8ms using fiber links or electricalcables. (The electrical cable is capable only inside the cabinet).

68P02900W21-T 5-29

Jul 2010

Planning considerations Chapter 5: BTS planning steps and rules

Planning considerations

Horizon II macro

The following factors should be considered when planning the HII site controller (either HIISCor 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 orHIISC2-S or HIISC2-E).

• For redundancy, add a second matching site controller in the digital module shelf of themaster cabinet. This also provides redundancy for the NIU and XMUX as well, sincethey are integrated in the site controller.

NOTEThis redundancy configuration also needs a redundant site expansion board inall 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). TheHIISC (or HIISC2-S or HIISC2-E) used can support a maximum of 24 RF carriers acrossthe sites.

• There is no accommodation for redundancy in this BTS.

Horizonmacro

The following factors should be considered when planning the MCUF complement for aHorizonmacro 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-Cell6or M-Cell2 site:

• 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.

5-30 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planningconsiderations – Horizon II macro/Horizon II mini as expansion cabinet

BBU-E

{34371G}

The BBU-E can be equipped only in the master Horizon II cabinet. The CTU8m can be populatedin both master and slave cabinet, but must be connected back to the BBU-E SFP ports in themaster cabinet.

The BBU-E used in the Horizon II can support up to 24 RF carriers, which can be a mixtureof CTU/CTU2/CTU2D and (R)CTU8ms, {9810G} in any combination of GMSK or/and 8PSKmodulation (including half rate, full rate, GPRS and EDGE carriers).

NOTEAll the carriers on one CTU8m/RCTU8m radio can only be allocated to one BBU-Eboard. This constraint should be considered during the CTU8m/RCTU8m and BBU-Eplanning.

The proper topologies for the BBU-E(s) and (R)CTU8m (specified in CTU8m D4+ Link on page5-44 and Chapter 12 Hardware and compatibility) should be selected to ensure the abovecapacity and redundancy is achieved.

Planning considerations – Horizon II macro/Horizon II mini asexpansion cabinet

This information describes the factors that require to be taken into account if Horizon II macrocabinets 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 beinstalled.

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 Chapter 5: BTS planning steps and rules

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 toaccommodate the use of the CTU2 transceiver from a code storage standpoint. If the site isequipped with a redundant MCUF, the PCMCIA is also mandatory for the redundant MCUF.

M-Cell6 master BTS planning considerations

NOTEDue to expansion limitations, M-Cell2 BTSs cannot be used with Horizon II macro (orHorizonmacro) cabinets.

• Only the master cabinet needs an MCU.

• A 20 MB PCMCIA memory card running CSFP must be installed in the MCU toaccommodate the use of the CTU2 transceiver from a code storage standpoint.If the site is equipped with a redundant MCU, the PCMCIA is also mandatoryfor the redundant MCU.

• The master cabinet must have an FMUX installed to communicate with theHorizon II macro BTS.

Planning actions

Horizon II macro/Horizon II mini

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

System Information: BSS Equipment Planning Cabinet interconnection

Cabinet interconnection■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

Horizon II macro

The XMUX multiplexes and demultiplexes full duplex transceiver links between a site expansionboard 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 expansionboard 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 HorizonII micro, all Horizon BTSs, or M-Cell6 through an expansion board such as the Horizon IImacro – Site I/O.

Horizonmacro

The FMUX multiplexes and demultiplexes full duplex transceiver links between an MCUFand up to six CTUs.

M-Cell6 and M-Cell2

The FOX provides the bidirectional electrical to optical interface between an MCU and FMUXand up to six TCUs.

The FMUX multiplexes and demultiplexes electrical connections for up to six TCUs or CTU2Adapters onto a single fiber optic connection operating at the rate of 16.384 Mbps.

NOTEIn slave cabinets with CTU8m only, Site Expansion/XMUX cards are not required.

68P02900W21-T 5-33

Jul 2010

Planning considerations Chapter 5: BTS planning steps and rules

Planning considerations

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 isintegrated 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 everyexpansion cabinet in the Horizon II macro BTS site when expansion is required (seeTable 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 Expansion 3

0 (master) None

1 1 site expansionboard only

1 XMUX + 1 siteexpansion board

2 1 site expansionboard only

1 XMUX + 1 siteexpansion board

1 XMUX + 1 siteexpansion board

3 1 site expansionboard only

1 XMUX + 1 siteexpansion board

1 XMUX + 1 siteexpansion board

1 XMUX + 1 siteexpansion board

Horizon II mini

The following factors should be considered when planning the XMUX complement:

• 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 integratedon 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 forthe master and every expansion cabinet in the Horizon II macro BTS site when expansionis required (see Table 5-12 to Table 5-14).

5-34 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Horizon II mini

Table 5-12 Horizon II mini only network XMUX expansion requirements

Cabinet Master Expansion 1 Expansion 2 Expansion 3

0 (master) None

1 1 site expansionboard only

1 XMUX + 1 siteexpansion board

2 1 site expansionboard only

1 XMUX + 1 siteexpansion board

1 XMUX + 1 siteexpansion board

3 1 site expansionboard only

1 XMUX + 1 siteexpansion board

1 XMUX + 1 siteexpansion board

1 XMUX + 1site expansionboard

Table 5-13 Horizon II macro as master - Horizon II mini as expansion XMUXrequirements

Cabinet Master Expansion 1 Expansion 2 Expansion 3

0 (master) None

1 1 site expansionboard only

1 XMUX + 1 siteexpansion board

2 1 site expansionboard only

1 XMUX + 1 siteexpansion board

1 XMUX + 1 siteexpansion board

3 1 site expansionboard only

1 XMUX + 1 siteexpansion board

1 XMUX + 1 siteexpansion board

1 XMUX + 1 siteexpansion board

Table 5-14 Horizonmacro as master - Horizon II mini as expansion XMUX/FMUXrequirements

Cabinet Master Expansion 1 Expansion 2 Expansion 3

0 (master) None

1 None 1 XMUX + 1 siteexpansion board

2 None 1 XMUX + 1 siteexpansion board

1 XMUX + 1 siteexpansion board

3 1 FMUX 1 XMUX + 1 siteexpansion board

1 XMUX + 1 siteexpansion board

1 XMUX + 1 siteexpansion board

NOTEThe Horizon II mini is a micro family BTS and the HII site controller (HIISC orHIISC2-S or HIISC2-E) used has RF limitations of 24 carriers per site in a Horizon IImini network.

68P02900W21-T 5-35

Jul 2010

Planning considerations - Horizon II macro as master cabinet Chapter 5: BTS planning steps and rules

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 Expansion 3

0 (master) None

1 None 1 FMUX

2 None 1 FMUX 1 FMUX

3 1 FMUX 1 FMUX 1 FMUX 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 FMUXin the first cabinet.

• Redundancy needs duplication of all FOX and FMUX boards and associated MCU andmicroBCU cages.

Planning considerations - Horizon II macro as master cabinet

NOTEDue to expansion limitations, M-Cell2 BTSs cannot be used with Horizon II macrocabinets.

The following factors should be considered while planning to use a Horizon II macro as a mastercabinet with Horizonmacro or M-Cell6 expansion cabinets:

• A site expansion board is required in the Horizon II macro master cabinet.

5-36 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 theMCUF/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 slavecabinet needs an additional FMUX, and each M-Cell6 slave cabinet needs an additionalFMUX and FOX.

Planning considerations - Horizon II mini as master cabinet

NOTEHorizon II mini as a Master cabinet and Macro family BTS as expansions areconsidered 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.

NOTEM-Cell2 BTSs are not supported as an expansion to Horizon II macro or Horizonmacrocabinets.

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 boardsrequired.

68P02900W21-T 5-37

Jul 2010

Battery back-up provisioning Chapter 5: BTS planning steps and rules

Battery back-up provisioning■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The Horizon II outdoor enclosure can be provisioned to have battery back-up in case of powerfailure at the site.

Planning considerations

The following factors influence the planning for battery back-up for a Horizon II outdoorenclosure.

• 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 weight110 kg when empty, 590 kg with 16 SBS C11 batteries included. This cabinet can houseup to 16 Hawker SBS C11 battery cells (8 strings) or equivalent. Two string sets canprovide a battery back-up for about one hour; a full cabinet can provide battery back-upfor about four hours.

• The intermediate battery back-up solution consists of a frame fixed to the ground housingthe 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 weightis 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 2batteries) which provides 1 hour back-up power.

NOTEThe back-up times for the internal, intermediate, and external battery backup are fora fully loaded system in a worst case scenario. Longer back-up times are achievedunder a typical load.

There is a visual display of outdoor battery voltages.

5-38 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning External power requirements

External power requirements■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

Macrocell cabinets and Microcell enclosures can operate from a variety of power supplies.

Planning considerations

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

NOTEOnly -48 V dc indoor cabinets can be installed in the 12 carrier outdoor.

68P02900W21-T 5-39

Jul 2010

Power planning actions Chapter 5: BTS planning steps and rules

• Horizonmicro2 and Horizoncompact2

The Horizonmicro2 and Horizoncompact2 enclosures operate from 88 V ac to 265 V acpower 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/-60V 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 230V/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 powersource.

• 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

System Information: BSS Equipment Planning 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 canbe any of those specified in Chapter 2 Transmission systems of this manual. A macro/microcellBTS can occupy any position in a network.

Expansion considerations

The following factors should be considered when expanding an existing network usingmacro/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 inTable 5-10 of this chapter.

• The rules governing the number of MSIs required at the BSC are given in the Multipleserial 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 appropriatemodules, until the cabinets are full.

• To expand a previous generation site, the equipment in the previous generation cabinetmust 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 theexisting 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 andinstall it to serve the third sector.

68P02900W21-T 5-41

Jul 2010

Line interface modules (HIM-75, HIM-120) Chapter 5: BTS planning steps and rules

Line interface modules (HIM-75, HIM-120)■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The line interface modules, HDSL interface module, 75 ohm (HIM-75), and HDSL interfacemodule, 120 ohm (HIM-120), provide impedance matching for E1, and HDSL links.

Planning considerations

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

The following planning actions are required:

• Determine the number to be deployed.

• Determine the number of HIM-75s or HIM-120s required.

Minimum number of HIM − 75s or HIM − 120s =Number of PCUs

2

5-42 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning DRI/Combiner operability components

DRI/Combiner operability components■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Overview

This enhancement improves the operability of the Digital Radio Interface (DRI) and combinerdevices 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

Second controlling

DRI

DRI 0 0 DRI 0 1

ti-GSM-DRI_and_combiner_relationship-00126-ai-sw

68P02900W21-T 5-43

Jul 2010

CTU8m D4+ Link Chapter 5: BTS planning steps and rules

CTU8m D4+ Link■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Overview

The Horizon II CTU8m/RCTU8m radio unit implements a separation of the RF radio aspectsand the digital baseband components of the air-interface. The digital baseband aspects of theair-interface are located on the BBU-E card located in the Horizon II macro, Horizon II miniand Horizon II micro cabinets. The RF radio aspects are located within the CTU8m/RCTU8mradio. The CTU8m radio may be located in a Horizon II macro or a Horizon II mini cabinet. TheRCTU8m radio can be located outside a Horizon II cabinet. The BBU-E and CTU8m/RCTU8mradio are connected by the D4+ interface link.

Figure 5-2 Relationship of the D4+ interface to the CTU8m radio and BBU-E

RCTU8m

BBU-E

CTU8m

RCTU8m

Horizon II cabinet (master) Horizon II cabinet (slave)

CTU8m

D4+ Link

D4+ Link D4+

Link

D4+ Link

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 independentof 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 allequivalent. In a D4+ daisy-chain configuration some D4+ links could go to an in-cabinet CTU8mradio 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 theRCTU8m to be later upgraded to support LTE traffic without requiring a visit to the radio head.

5-44 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Supported topologies

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 planningprocess. It is recommended that the RF configuration of the BTS site is first determined beforeselecting a D4+ interface configuration to service the CTU8m/RCTU8m radios in that BTSconfiguration.

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 portsmay be swapped compared to the topology diagram). The DRI configuration must reflectthe actual D4+ connections deployed.

• Up to 6 CTU8m/RCTU8m radios may exist in a single daisy-chain configuration from asingle 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 berestricted by the particular D4+ media type used (for example, electrical link, single-modefiber link, multimode fiber link).

• D4+ optical fiber link connections should be point to point, that is, direct connectiononly. 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 provideprotection from BBU-E or D4+ link failure.

In dual BBU-E configurations a BBU-E–BBU-E link that is sometimes employed which permitsone BBU-E to communicate with CTU8m/RCTU8m radios connected to the other BBU-E. It alsopermits the BTS to load-share the carriers over both BBU-Es for those CTU8m/RCTU8m radioswith a communication path that connects to both BBU-Es.

68P02900W21-T 5-45

Jul 2010

Supported topologies Chapter 5: BTS planning steps and rules

NOTEThe BBU-E–BBU-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 carriershosted on BBU-E #1 to simultaneously use this link to talk to a CTU8m unit throughBBU-E #0.

Standard topologies

This section describes the key supported D4+ link topologies. An RCTU8m radio canbe substituted for any CTU8m radio in the following description. Though the maximumconfiguration possible per topology is shown, real implementations may have fewerCTU8m/RCTU8m employed.

The simplest D4+ topology supported is to have a single D4+ link from each BBU-E to oneCTU8m/RCTU8m radio. This topology limits the impact of a single D4+ link or CTU8m/RCTU8mradio failure. However, without the BBU-E–BBU-E D4+ link it is not possible to load-sharecarriers across the two BBU-Es.

Figure 5-3 D4+ Star topology (Single BBU-E)

ti-GSM-D4+_star_topology-00126.b-ai-sw

#0

#1

#2

BBU #0

CTU8m CTU8m CTU8m

5-46 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Supported topologies

Figure 5-4 D4+ Star topology (Dual BBU-E)

#0

#1

#2

BBU #0

#3

#4

#5

BBU #1

ti-GSM-D4+_star_topology-00126.b-1-ai-sw

CTU8m CTU8m CTU8m CTU8m CTU8m CTU8m

In situations where there are 1-3 CTU8m/RCTU8m radios, a second BBU-E can be deployedand a redundant D4+ link per CTU8m radio deployed. Carriers may be load-shared acrossboth 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, insome unexpected situation, not all CTU8m DRIs can be INS due to the BBU-Ecapability limitation. So the D4+ redundant-star topology is not recommendedfor CTU8m in 8 carrier mode.

Figure 5-5 D4+ Redundant-star topology

#0 #1 #2

BBU-E #0 BBU-E #1

ti-GSM-D4+_redundant_star_topology-00126.c-ai-sw

CTU8mCTU8mCTU8m

68P02900W21-T 5-47

Jul 2010

Supported topologies Chapter 5: BTS planning steps and rules

In situations where there are more than three CTU8m/RCTU8m units per BBU-E, or wherethere 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 unitmay traverse intermediate CTU8m radios or a BBU-E. This configuration is sensitive to D4+ linkor CTU8m/RCTU8m radio failures, which can impact several radios.

Figure 5-6 D4+ Daisy-chain topology

#0 #1 #2 #3 #4 #5

BBU-E #0

#0 #1 #2 #3 #4 #5

BBU-E #1 BBU-E #0

ti-GSM-D4+daisy-chain_topolpgy-00126.d-ai-sw

CTU8m CTU8m CTU8m CTU8m CTU8m CTU8m CTU8m CTU8m CTU8m CTU8m CTU8m CTU8m

D4+ daisy-chain configurations may be mixed with a D4+ star configuration to provide a simplemeans of supporting more than three CTU8m/RCTU8m radios per BBU-E, with failures havingminor consequences than the pure daisy-chain configuration.

Figure 5-7 D4+ Star/daisy-chain topology

CTU8m #0 #1 #2 #3 #4 #5

BBU-E #0

ti-GSM-D4+_star_daisy_topol-00126.e-ai-sw

CTU8m CTU8m CTU8m CTU8m CTU8m

5-48 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Supported topologies

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 aredundant D4+ link may be installed, D4+ ports at each end of this link must be disabled inthe BTS configuration. With this arrangement the redundant D4+ link is not visible to thesystem in normal operation, and the D4+ system behaves as one of the topologies described inStandard topologies on page 5-46.

The following diagrams describe the supported topologies where a redundant D4+ link can bedeployed 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 D4+ Dual star topology (redundant D4+ link)

ti-GSM-D4+_dual star_topol_rdn_fibr-00126.f-ai-sw

#0

#1

#2

#3

#4

#5

BBU #0

BBU #1

CTU8m CTU8m CTU8m CTU8m CTU8m CTU8m

Figure 5-9 D4+ Daisy-chain topology (redundant D4+ link)

#0 #1 #2 #3 #4 #5

BBU-E #0

#0 #1 #2 #3 #4 #5

BBU-E #1 BBU-E #0

ti-GSM-D4+_dual daisy-chain_topol_rdn_fibr-00126.g-ai-sw

CTU8m CTU8m CTU8mCTU8mCTU8mCTU8mCTU8mCTU8mCTU8mCTU8mCTU8mCTU8m

68P02900W21-T 5-49

Jul 2010

Supported topologies Chapter 5: BTS planning steps and rules

If the BTS suffers a failure in the normal D4+ topology, the operator has the option to use thedeployed redundant D4+ link. The operator must manually reconfigure the D4+ topology towork around the point of failure. Links that have failed must have the D4+ ports at each end ofthe link disabled to avoid accidentally creating an active D4+ ring configuration.

5-50 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 onthe units at each end of the link.

An exception to this are the in-cabinet electrical D4+ links where the SFP modules are partof the link assembly.

NOTE

• Motorola supplied SFP connector modules are mandatory for D4+ optical fiberlink connections.

• The optical fiber used for the D4+ link connectivity should be compliant withITU-T G.652.D fiber specifications.

In GSM, the D4+ link operates at 3.072 Gbit/s and the standard SFP modules are rated todrive the fiber-optic cable at this speed. However, the customer may choose to deploy SFPmodules capable of operating at 6.144 Gbit/s. These faster SFPs allow a GSM CTU8m/RCTU8mradio to be later converted to support LTE without replacing the fiber or SFPs supporting thatCTU8m/RCTU8m unit. The following table lists the types of D4+ interconnection that may beemployed in a site:

Case Interconnections Link Length Link Type

1 BBU-E to BBU-E Intra-cabinet D4+ Link #1

2 BBU-E to CTU8m Intra-cabinet D4+ Link #1

3 BBU-E to CTU8m Inter-cabinet D4+ Link #2

4 CTU8m to CTU8m Intra-cabinet D4+ Link #1

5 CTU8m to CTU8m Inter-cabinet D4+ Link #2

6 BBU-E to RCTU8m ≤ 100m D4+ Link #3

7BBU-E to RCTU8m >100m or custom

cableD4+ Link #5

8 CTU8m to RCTU8m ≤ 100m D4+ Link #3

9CTU8m to RCTU8m >100m or custom

cableD4+ Link #5

10 RCTU8m to RCTU8m ≤ 100m D4+ Link #4

11RCTU8m to RCTU8m >100m or custom

cableD4+ Link #5

68P02900W21-T 5-51

Jul 2010

Link selection Chapter 5: BTS planning steps and rules

Figure 5-10 D4+ link types (illustrative)

ti-GSM-D4+ link types (illustrative)-00126.g-1-ai-sw

Horizon II Master Cabinet

BBU-E

RCTU8m

Horizon II Slave Cabinet

Case #5 D4+ Link #2

BBU-E

Case #6 D4+ Link #3

Case #8 D4+ Link #3

Case #10 D4+ Link #4

Case #11 D4+ Link #5

Case #9 D4+ Link #5

Case #7 D4+ Link #5

Case #1 D4+ Link #1

Case #4 D4+ Link #1

Case #4 D4+ Link #1

Case #2 D4+ Link #1

Case #3 D4+ Link #2

CTU8m CTU8m CTU8m CTU8m CTU8m

RCTU8m RCTU8m RCTU8m RCTU8m RCTU8m

D4+ Link #1: Electrical intra-cabinet D4+ link

This D4+ cable is used to interconnect BBU-E cards and CTU8m radios located within thesame Horizon II cabinet. Motorola supplies an electrical cable for this link that is suppliedpre-terminated with an SFP transceiver module at each end. This cable supports both the GSM3.072 Gbit/s and LTE 6.144 Gbit/s D4+ data rates.

NOTETo prevent EMC interference issues, these electrical cables must not be used tomake 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 MotorolaBBU-CTU8m multi-mode fiber used must be matched to Motorola multi-mode fiber SFPs atthe BBU-E / CTU8m units.

5-52 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 areavailable 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 HorizonII cabinet to the RCTU8m radio. This cable is supplied with a weather sealing cable glandat the RCTU8m end.

The RCTU8m–RCTU8m cable supports connections between two RCTU8m radios. This cable isprovided 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 Motorolamulti-mode SFP transceiver module. The SFP in the CTU8m/RCTU8m radio may be a 3.072Gbit/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 lengthrequired is 80 m. For link lengths greater than 80 m, a single-mode optical fiber should bedeployed (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 theOrder Guide. These cables will include a weather sealing cable gland at the ends connecting tothe RCTU8m radio.

Motorola SFPs, supporting this single-mode fiber, must be employed at the unit connected toeach end of the D4+ link. These SFPs may be a 3.072 Gbit/s GSM-capable SFP or a 6.144Gbit/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. Thisfiber must be fitted with a weather sealing cable gland at the ends connecting to the RCTU8mradio and terminated with LC-type connectors.

The fiber link, including connections, must deliver a bit error ratio performance better than10-12 when used with these SFP modules at the 3.072 Gbit/s line rate. The fiber-optic linkbudget should be computed for these links, as described in the next section, to ensure correctoperation.

D4+ Link Optical Budget

For short-range D4+ links using multi-mode fiber and SFPs supplied by Motorola it is notnecessary to perform a fiber-optic link power budget calculation. However, with D4+ links usingcustom 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 checkedto obtain the following key parameter values:

68P02900W21-T 5-53

Jul 2010

Link selection Chapter 5: BTS planning steps and rules

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 lossmust be obtained by calculation or measurement.

Parameter Description Typical value

Pfibre Optical fiber attenuation including splices 0.4 dB / km

The optical link is subjected to a number of factors that degrades the received signal. Thesefactors 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 computedusing the specifications of the optical-fiber and the SFPs employed. However, for planning 1 kmD4+ 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 calculationto ensure that the system continues to operate satisfactorily through the lifetime of the BTSdeployment.

The following table indicates typical values for the discussed factors:

Parameter Description Typical value

Ppen Transmission penalties (RIN, jitter, and so on) 2 dB

Pcon Connector losses 0.5 dB / connector

Pmargin Engineering margin to guarantee reliability 3 dB

For short fiber runs it is necessary to ensure that the maximum SFP transmitter power cannotoverload the SFP receiver at the other end of the link.

Pmax − Pfibre ≤ Psat

The following equations compute the optical power budget for the D4+ link.

Plink = (Ptx − Pfibre − Ppen − Pcon)− Prx

5-54 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Recommended D4+ configurations (CTU8m)

To ensure reliability of the link, this optical power budget should exceed the specifiedengineering margin:

Plink ≥ Pmargin

The following example shows the calculation for a typical 1 km link:

Parameter Description Value

Ptx SFP average optical output power -7.2 dBm

Pfibre Fiber losses (included splices): 1km @ 0.4 dB/km 0.4 dB

Ppen Transmission penalties (RIN, jitter, etc.) 2 dB

Pcon Connector losses: 2 connectors at 0.5dB/connector

1 dB

Prx SFP receiver sensitivity @ 10-12 BER -15.4 dBm

Plink Link margin: Plink = (Ptx − Pfibre − Ppen − Pcon) −Prx

4.8 dB

Recommended D4+ configurations (CTU8m)

The following are recommended D4+ interconnection configurations for signal cabinet CTU8mdeployments (Electrical D4+ links are used in all configurations). The deployments dependon the number of CTU8m radios.

1-3 CTU8m radios

For configurations involving one to three CTU8m radios, D4+ star configurations arerecommended. Each CTU8m radio is provided with a dedicated point-to-point D4+ link to aBBU-E interface port.

68P02900W21-T 5-55

Jul 2010

Recommended D4+ configurations (CTU8m) Chapter 5: BTS planning steps and rules

Figure 5-11 D4+ configuration for 3 CTU8m radios (non-redundant)

EMPTYEMPTYEMPTY

5 4 3 2 1 0

CTU8m

D4+ 1

D4+ 0

01

EMPTY BBU-E

LINK

D4+

0

1

2

Horizon II macro CABINET

CTU8m

D4+ 1

D4+ 0

CTU8m

D4+ 1

D4+ 0

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 aredundant solution tolerant to single points of failure.

Figure 5-12 D4+ configuration for 3 CTU8m radios (redundant)

5 4 3 2 1 0

CTU8m

D4+ 1

D4+ 0

01

BBU-E

LINK

D4+

0

1

2

Horizon II macro CABINET

CTU8m

D4+ 1

D4+ 0

CTU8m

D4+ 1

D4+ 0

CTU2DCTU2D CTU2D BBU-E

LINK

D4+

0

1

2

ti-GSM-D4+ config_3 CTU4 radios (rdndnt)-00126.i-ai-sw

5-56 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Recommended D4+ configurations (CTU8m)

4-6 CTU8m radios (single BBU-E)

When there is only one BBU-E installed in the Horizon II cabinet, the D4+ star arrangementmust be extended to create two daisy-chained CTU8m radios as required on each link from theBBU-E. It is recommended that the second CTU8m in the daisy-chain link hosts carriers for adifferent sector, not the first CTU8m radio in the daisy-chain. This helps to limit the chances oflosing all carriers in a sector when the first CTU8m radio becomes unavailable.

Figure 5-13 D4+ configuration for 6 CTU8m radios (single BBU-E)

5 4 3 2 1 0

CTU8m

D4+ 1

D4+ 0

01

EMPTY BBU-E

LINK

D4+

0

1

2

Horizon II macro CABINET

CTU8m

D4+ 1

D4+ 0

CTU8m

D4+ 1

D4+ 0

CTU8m

D4+ 1

D4+ 0

CTU8m

D4+ 1

D4+ 0

CTU8m

D4+ 1

D4+ 0

Same Sector Same Sector Same Sector

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 configurationto 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 theCTU8m radios. If there are two or more CTU8m units serving a single sector, at least one ofthe CTU8m radios should have a D4+ connection to a different BBU-E to the other CTU8mradios 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 incase of D4+ link or BBU-E failure.

68P02900W21-T 5-57

Jul 2010

Recommended D4+ configurations (RCTU8m) Chapter 5: BTS planning steps and rules

Figure 5-14 D4+ configuration for 6 CTU8m radios (dual BBU-E)

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

5 4 3 2 1 0 0 1

BBU

LINK

D4+

0

1

2

Horizon II macro CABINET

CTU8m 1800 MHz

D4+ 1

D4+ 0

BBU

LINK

D4+

0

1

2

CTU8m 900 MHz

D4+ 1

D4+ 0

CTU8m 1800 MHz

D4+ 1

D4+ 0

CTU8m 900 MHz

D4+ 1

D4+ 0

CTU8m 1800 MHz

D4+ 1

D4+ 0

CTU8m 900 MHz

D4+ 1

D4+ 0

Same Sector Same Sector Same Sector

Recommended D4+ configurations (RCTU8m)

The following are the recommended D4+ interconnection configurations for RCTU8mdeployments where the radio may be located at some distance from the Horizon II cabinet. Thebest configuration to be used for a particular BTS deployment is influenced by the cost of layingfiber optic D4+ interface cables in the location of the BTS deployment.

NOTEThe D4+ links used to connect RCTU8m radios use a fiber-optic media type. However,the electrical D4+ cable is used for the BBU-E–BBU-E D4+ link.

1-3 RCTU8m radios (non-redundant)

When the D4+ cable run length is relatively short, the simplest configuration is a directpoint-to-point fiber-optic link from each BBU-E D4+ port to each RCTU8m radio.

5-58 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Recommended D4+ configurations (RCTU8m)

Figure 5-15 D4+ star configuration for 1-3 RCTU8m radios (non-redundant)

01

BBU-E

LINK

D4+

0

1

2

Horizon II CABINET

RCTU8m

D4+ 1

D4+ 0

RCTU8m

D4+ 1

D4+ 0

RCTU8m

D4+ 1

D4+ 0

EMPTY

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 runlength, or when additional RCTU8m radios may be deployed in the future beside the originalRCTU8ms, which use a D4+ daisy-chain topology. Although only one D4+ link is requiredbetween the RCTU8m and the BBU-E, it is recommended that a second physical D4+ link isprovisioned in a disabled state, creating a physical fiber-optic ring running as a daisy-chainD4+ topology.

68P02900W21-T 5-59

Jul 2010

Recommended D4+ configurations (RCTU8m) Chapter 5: BTS planning steps and rules

Figure 5-16 D4+ daisy-chain configuration for 1-3 RCTU8m radios (non-redundant)

01

BBU-E

LINK

D4+

0

1

2

Horizon II CABINET

RCTU8m

D4+ 1

D4+ 0

RCTU8m

D4+ 1

D4+ 0

RCTU8m

D4+ 1

D4+ 0

Optional (Disabled)

EMPTY

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. TheBBU-E–BBU-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 recommendedthat a second physical D4+ link is provisioned in a disabled state, creating a physical fiber-opticring running as daisy-chain D4+ topology.

5-60 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Recommended D4+ configurations (RCTU8m)

Figure 5-17 D4+ daisy-chain configuration for 1-3 RCTU8m radios (redundant)

01

BBU-E

LINK

D4+

0

1

2

Horizon II CABINET

RCTU8m

D4+ 1

D4+ 0

RCTU8m

D4+ 1

D4+ 0

RCTU8m

D4+ 1

D4+ 0

BBU-E

LINK

D4+

0

1

2

Optional (Disabled)

ti-GSM-D4+ daisy-chain config 1-3 RCTU4 radios (rdndnt)-00126.n-ai-sw

68P02900W21-T 5-61

Jul 2010

Recommended D4+ configurations (RCTU8m) Chapter 5: BTS planning steps and rules

4-6 RCTU8m radios (single BBU-E)

The daisy-chain D4+ topology is recommended when more than three RCTU8m radios are to besupported. Although only one D4+ link is required between the RCTU8m and the BBU-E, itis recommended that a second physical D4+ link is provisioned in a disabled state, creating aphysical fiber-optic ring running as a daisy-chain D4+ topology.

Figure 5-18 D4+ configuration for 4-6 RCTU8m radios (single-BBU-E)

01

BBU-E

LINK

D4+

0

1

2

Horizon II CABINET

RCTU8m

D4+ 1

D4+ 0

RCTU8m

D4+ 1

D4+ 0

RCTU8m

D4+ 1

D4+ 0

RCTU8m

D4+ 1

D4+ 0

RCTU8m

D4+ 1

D4+ 0

RCTU8m

D4+ 1

D4+ 0

Optional (Disabled)

EMPTY

ti-GSM-D4+ config 4-6 RCTU4 radios (single-BBU-E)-00126.o-ai-sw

5-62 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Recommended D4+ configurations (RCTU8m)

4-6 RCTU8m radios (dual BBU-E)

When two BBU-Es are deployed, to support the required capacity or to provide BBU-Eredundancy, the daisy-chain topology is deployed with a BBU-E–BBU-E D4+ link. It isrecommended that a second physical D4+ link is provisioned between the BBU-Es and theRCTU8ms, configured in a disabled state. This creates a physical fiber-optic ring running asdaisy-chain D4+ topology.

Figure 5-19 D4+ configuration for 4-6 RCTU8m radios (dual-BBU-E)

ti-GSM-D4+ config 4-6 RCTU4 radios (single-BBU-E)-00126.p-ai-sw

0 1

BBU

LINK

D4+

0

1

2

Horizon II CABINET

RCTU8m

D4+ 1

D4+ 0

RCTU8m

D4+ 1

D4+ 0

RCTU8m

D4+ 1

D4+ 0

RCTU8m

D4+ 1

D4+ 0

RCTU8m

D4+ 1

D4+ 0

RCTU8m

D4+ 1

D4+ 0

BBU

LINK

D4+

0

1

2 Option al (Disabled)

68P02900W21-T 5-63

Jul 2010

Recommended D4+ configurations (RCTU8m) Chapter 5: BTS planning steps and rules

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 thischapter. 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 6-1

Jul 2010

Recommended D4+ configurations (RCTU8m) Chapter 6: BSC planning steps and rules

• 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

6-2 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSC planning overview

BSC planning overview■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

Information pertaining to the NEs must be known to plan the equipage of a BSC. The NEconfiguration 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 ofcells 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 BSUand RXU shelves at a BSC. This needs using the information contained in this chapter (for theBSC) and those in Chapter 7 RXCDR planning steps and rules (for the RXCDR), as the RXU shelfis 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 theRXU3 shelf or shelves are used.

68P02900W21-T 6-3

Jul 2010

Outline of planning Chapter 6: BSC planning steps and rules

Outline of planning

Planning a BSC involves the following steps:

• Plan the number of RSL links between the BSC and BTS site(s). Refer to the sectionDetermining 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 toBTS E1 interconnect planning actions on page 6-31.

• Plan the number of MTL links between the BSC and MSC. Refer to the section Determiningthe number of MTLs required on page 6-37.

• Plan the number of XBL links required between the BSC and AXCDR. Refer to the sectionDetermining the number of XBLs required on page 6-47.

• Plan the number of GSL links required between the BSC and the PCU. Refer to Determiningthe 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 Transcodingon page 6-63.

• Plan the number of LMTL links required between the BSC and the SMLC, if LCS isenabled in the BSS and if BSS-based LCS architecture is supported. Refer to the sectionDetermining the number of LMTLs required on page 6-45. Ignore this if the BSS supportsonly the NSS-based LCS architecture.

• Plan the number of E1 links between the BSC and SMLC if LCS is enabled in the BSS and ifBSS-based LCS architecture is supported. Refer to the section Determining the numberof LMTLs required on page 6-45. Ignore this if the BSS supports only the NSS-basedLCS 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 Kiloportswitch (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 page6-82.

• Plan the number of CLKXs required. Refer to the section Clock extender (CLKX) on page6-83.

• Plan the number of LANXs required. Refer to the section Local area network extender(LANX) on page 6-85.

6-4 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 shelvesand BSSC cabinets on page 6-91.

68P02900W21-T 6-5

Jul 2010

Capacity calculations Chapter 6: BSC planning steps and rules

Capacity calculations■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The throughput capacities of the BSC processing elements (for example, GPROC) and thethroughput 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 processthe signaling information associated with these TCHs.

The following sections, discussed, provide information on how to calculate processorrequirements, 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 possibleto have multiple RXCDRs connected to a single BSC, and vice-versa. This is especially usefulfor 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 ofthe BSC to handle calls.

BSC and RXCDRs support nine interconnections between them. The level of connectivity isconstrained by the number of XBLs supported. The connectivity is limited to 20 at each BSC andRXCDR (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 BSCconnect to four RXCDRs. System size, capacity, and cost are the major factors in deciding theconfiguration.

6-6 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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

Item 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 3 1 1

GSLs 180c 60c 60c

MMS 112 112e 112e

PATHs 250 250 250

DHPs 232 232 232

LCFs 25 25h 38h

Cabinets 190 190 300I

Trunks (see NOTE ) 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

Maximum busy hourcall attempts

120,000 180,000d 194,500

68P02900W21-T 6-7

Jul 2010

System capacity summary Chapter 6: BSC planning steps and rules

Where: Is:

a The capacity can be increased to 512 carriers and 3200 trunks if the optionalenhanced BSC capacity feature is enabled. The maximum DRIs is 512.

bIt is mandatory to deploy GPROC3/GPROC3-2s in active and/or standby BSPslots in the BSC in any potential BSP slots on a site. For example, slot 20 andslot 24 in shelf 0 and slot 20 in shelf 1.

c

180 for 3xPCU, 60 per PCU in GSR8 and GSR9, BSS can support 60 GSLs withthe 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 traffichandling capacity reduces in direct proportion to the timeslots configuredfor GPRS traffic.

dThe capacity can be increased to 140 BTS sites, 750 carriers, and 4800trunks, if the optional huge BSC capacity feature is enabled. The maximumnumber of DRIs is 750.

e With 96 MSI feature, a BSC site can support 192 MMSs.

fA 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 MMSnumber and E1 links decrease accordingly.

g

The BSC configuration of the 1000 carriers with the huge BSC capacityfeature enabled. The enhanced capacities are listed in Table 6-2 BSCconfiguration capacities.The BHCA can be different depending on the callduration parameter. Under a given call model, the required equipment iscalculated based on the call model (including BHCA 8i) using the formulaprovided in the following sub-sections in this chapter. The BHCA limit shouldbe checked after planning and should not be exceeded to ensure that thestability and performance of the system are maintained.

h 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 1

GSLs 60

MMS 192

PATHs 250

DHPs 232

LCFs 38

Continued

6-8 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Scalable BSC

Table 6-2 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)

NOTEI - The maximum of 190 cabinets can be equipped per BSS, which is the sum of thecabinets 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 versionused. The first element to reach its limit sets the capacity of the BSC. For example, whendimensioning a BSC with a specific non-standard call model, there is a possibility that the LCFor 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 diverserequirements of network users in terms of BSC size are addressed by a single platform that canbe efficiently configured in small, medium, or large models.

Before GSR7, the move to a scalable BSC is enabled through the migration of the processingboards within the BSC to use the GPROC2 throughout. Now, GPROC2s can be replaced bythe 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 scalableBSC where minimal incremental hardware is required to be added as the networks grow. FromGSR8, it is mandatory to deploy GPROC3s in active and/or standby BSP slots in the BSC in anypotential BSP slots on a site (that is, slot 20 and slot 24 in shelf 0 and slot 20 in shelf 1). Beingable to expand capacity within a BSC is beneficial from an operational viewpoint, because thereis less time and effort involved than compared with having to move sites from one BSC toanother, 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 sectorsand 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 40sites of three sectors and two carriers per sector. At GSR4, the capacity is increased to allow theoperator 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 singleBSC 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 andmemory of the GPROC. The maximum capacity is increased as shown in Table 6-1.

68P02900W21-T 6-9

Jul 2010

Enhanced BSC capacity option Chapter 6: BSC planning steps and rules

This increased capacity is achieved through the deployment of GPROC2s orGPROC3s/GPROC3-2s for each function at the BSC, including Base Station Processor (BSP)and Link Control Function (LCF).

NOTEThe 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 normalBSC maximum capacity of 384 RF carriers, and 2400 trunks (see Table 6-1). If the feature isunrestricted, 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.

NOTEGPROC3s 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 BSCmaximum capacity of 100 BTS sites, 384 RF carriers, and 2400 trunks (see Table 6-1). If thefeature is unrestricted, the BSC maximum capacity is increased to 140 BTS sites, 750 RFcarriers, 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 MTLlink 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 isprovided. If the feature is unrestricted, the BSS supports the Network Sub-System (NSS) basedServing Mobile Location Center (SMLC) architecture or the BSS-based SMLC architecture, andthe 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 positioningmethod for LCS is provided for NSS-based and BSS-based LCS architectures respectively inthe following sections.

6-10 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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, dependsupon the assumed traffic model used in the network design or operation. Traffic models arefundamental to some planning actions.

The capacity of the BSC as a whole, or the capacity of a particular GPROC, depends on itsability to process information transported through signaling links connecting it to the othernetwork elements. These elements include MSC, BTSs, and the OMC-R. Depending on its devicetype and BSC configuration, a GPROC controls signaling links to one or more other networkelements. A capacity figure can be stated for each GPROC device type in terms of a staticcapacity such as the number of physical signaling links supported, and a dynamic capacity suchas processing throughput.

In general telephony environments, processing and link throughput capacities can be stated interms of the offered call load. To apply this for the GSM BSC, all signaling information to beprocessed by the BSC is related to the offered call load (the amount of traffic offered/generatedby subscribers). When calls are blocked due to all trunks or all TCHs being busy, most of thesignaling associated with call set up and clearing still takes place, even though few or no trunkresources are utilized. Therefore, the offered call load (which includes the blocked calls) shouldbe 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, adequatesignaling resources should be planned to handle the potential carried traffic. The trunk countcan 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 thegreater of the following:

• Offered load

• Potential load

The number of trunks or the offered call load in Erlangs (whichever is greater) should be usedto determine the link and processing requirements of the BSC.

BSC capacity planning needs a model that takes into consideration the signaling generated fromall the pertinent GSM procedures: call setup and clearing, handover, location updating, andpaging, to the offered call load. To establish the relationship between all the procedures, thetraffic model expresses processing requirements for these procedures as ratios to the numberof call attempts processed. The rate at which call attempts are processed is a function of theoffered call load and the average call hold time.

68P02900W21-T 6-11

Jul 2010

BSC signaling traffic model Chapter 6: BSC planning steps and rules

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 thereal call parameters (described in Chapter 11 Call model parameters) from thelive network to ascertain the true network call model.

• Future planning should then be based on this actual (non-standard) call modelinstead of the standard call model. Past studies have shown that the actual callmodel in some networks differs considerably from the standard call model, andthis has a direct impact on dimensioning requirements.

Figure 6-1 graphically depicts various factors that should be taken into account when planning aBSS.

6-12 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSC signaling traffic model

Figure 6-1 BSS planning diagram

MSC

TRANSCODER

A INTERFACE (TERRESTRIAL LINKS)-C7 SIGNALLING LINKS-X.25 CONTROL LINK *-REQUIRED TRUNKS

WITH SUBMULTIPLEXING TRANSCODING AT MSC1 x 64 KBIT/S CIRCUIT/C7 SIGNALLING LINK1 x 64 KBIT/S CIRCUIT/X.25 SIGNALLING LINK *1 x 64 KBIT/S CIRCUIT/ XBL1 x 64 KBIT/S CIRCUIT/4 TRUNKS1 x 64 KBIT/S CIRCUIT/8 TRUNKS(HALF RATE WITH 8 KBIT/S SUBMULTIPLEXING ENABLED)

WITH SUBMULTIPLEXING TRANSCODING AT BSC1 x 64 KBIT/S CIRCUIT/C7 SIGNALLING LINK1 x 64 KBIT/S CIRCUIT/X.25 SIGNALLING LINK*1 x 64 KBIT/S CIRCUIT/TRUNK

GBL

GDS INTERFACE **- GDS TRAU CHANNELS- GSL LINKS

BSC TO PCU GDS-TRAU CIRCUITSTHE # OF GSLsTHE # OF GBLs

PCU

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 -

1 x 16 KBIT/S CIRCUIT/GPRS TIMESLOT FOR CS1 AND CS22 x 16 KBIT/S CIRCUIT/GPRS TIMESLOTS FOR CS3 AND CS41 x 64 KBIT/S GSL LINK RTF_DS0_COUNT x 64 KBIT/S FOR EACH EGPRS RTF

THE # OF XBL LINKS - PLUS -THE # OF GSL LINKS

BSC

MOTOROLA BSC/BTS INTERFACE NON-BLOCKING

1 x 64 KBIT/S OF 1 x 16 KBIT/S RTF CIRCUIT/LAPD SIGNALLING LINK2 x 64 KBIT/S CIRCUITS/RTF4 x 64 KBIT/S CIRCUITS/RTF (SEE NOTE)

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 RATEMANDATED) 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 MSC8 pt. left aligned textTCH = TRAFFIC CHANNEL TS = TIMESLOT

USING TRAFFIC, TO DETERMINE THE E1 LINK INTERCONNECTHARDWARE 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 Chapter 6: BSC planning steps and rules

NOTE4 x 64 kbps circuits/RTF for a (AMR or GSM) HR RTF and 8 kbps switching is notprovisioned, or (for AMR only) the 7.95 kbps half rate codec mode is included inthe Half Rate Active Codec Set.

Besides the factors described in Figure 6-1, when LCS is enabled in the BSS, the followingfactors require to be taken into account when planning a BSS:

• MTL link provisioning to support LCS signaling between the MSC and BSC for eitherNSS-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.

Typical parameter values

The parameters required to calculate BSC processing and signaling link capacities are listed inTable 6-3 with their typical values.

Two methods for determining the BSC link capacity are given. The first method is based on thetypical call parameters given in Table 6-3 and simplifies planning to look up tables, or the simpleformulae indicated in the standard traffic model planning steps. When the call parameters beingplanned differ significantly from the standard traffic model, more complex formulae must beused 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

Ratio of SMSs per call S = 3.2

Number of handovers per call 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 IMSItype 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

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 64 k U(MSC – BSS) = 0.20

Continued

6-14 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Typical parameter values

Table 6-3 Typical call parameters (Continued)

Busy hour peak signaling traffic parameter Reference parameter

Percent link utilization (MSC to BSC) for HSP MTL U(MSC – BSC) = 0.13

Percent link utilization (BSC to BTS) U(MSC – BTS) = 0.25

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 (BSC 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 sub/BH (bytes/hr) – Uplink ULRATE = 1.48

GPRS Traffic per sub/BH (bytes/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 = 9.2 kbpsCS2 = 13.6 kbpsCS3 = 15.8 kbpsCS4 = 21.8 kbps

Continued

68P02900W21-T 6-15

Jul 2010

Typical parameter values Chapter 6: BSC planning steps and rules

Table 6-3 Typical call parameters (Continued)

Busy hour peak signaling traffic parameter Reference parameter

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%CS4_usage_UL = 45.5%CS4_usage_DL = 35.5%

Percentage GPRS coding scheme usage in total traffic (seeNOTE)

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 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

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 (MSC1-MSC9) at the RLC/MAC layer MCS1 = 10.55MCS2 = 12.95MCS3 = 16.55MCS4 = 19.35MCS5 = 23.90MCS6 = 29.60MCS7 = 31.10MCS8 = 46.90MCS9 = 61.30

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_UL = 4.5%MCS3_usage_DL = 8.5%MCS4_usage_UL = 5.5%MCS4_usage_DL = 7%MCS5_usage_UL = 15.5%MCS5_usage_DL = 5%MCS6_usage_UL = 47.75%MCS6_usage_DL = 19%MCS7_usage_UL = 3.5%MCS7_usage_DL = 8%

Continued

6-16 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Typical parameter values

Table 6-3 Typical call parameters (Continued)

Busy hour peak signaling traffic parameter Reference parameter

MCS8_usage_UL = 8.5%MCS8_usage_DL = 8%MCS9_usage_UL = 12.25%MCS9_usage_DL = 21.5%

Percentage EGPRS coding scheme usage in total traffic CSuse_UL_EGPRS = 12.1%CSuse_DL_EGPRS = 9.9%

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

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: These include 2G-3G handovers.

• Percentage GPRS coding scheme usage: These percentages representthe split of the traffic between for GPRS and EGPRS traffic mix, which isnetwork-dependent. The percentages can be used to determine the averagetraffic per sub/BH for a GPRS and EGPRS traffic mix as follows:

Traffic per sub/BH for GPRS and EGPRS mix (kBytes/hr) = (PercentageGPRS coding scheme usage in total traffic * GPRS Traffic per sub/BH) +(Percentage EGPRS coding scheme usage in total traffic * EGPRS Trafficper sub/BH)

• Average packet size for GPRS and EGPRS traffic mix (bytes): These are theaverage packet sizes for a GPRS and EGPRS traffic mix based on the GPRS andEGPRS 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 ratioof IMSI detaches to calls (I) and whether the short message sequence (type 1) or long messagesequence (type 2) is used for IMSI detach; typically I = 0 (that is IMSI detach is disabled) as inthe first formula given . When IMSI detach is enabled, the second or third of the formulas givenshould 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 Chapter 6: BSC planning steps and rules

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 N

Number of BTSs per BSS B

Number of cells per BSS C

Pages per call PPC = PGSM * (T/N)

LCS request rate (req/sec/BSC) LCS_BSC_Rate = (N/T) * LCS

Assumptions used in capacity calculations

Signaling message sequence and size assumptions

Certain signaling message sequence patterns and message sizes have been assumed to calculatelink and processing capacity values for the various procedures included in the signaling trafficmodel. These assumptions translate into specific formula coefficients and include a margin ofsafety. As they are dependent on call procedures, they are recalculated for every major softwarerelease. Link utilization should be monitored to detect significantly different behavior. Theprocedures 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 andoutgoing

Handover, incoming andoutgoing

N/A

Location update Location update N/A

SMS - P to P SMS - P to P N/A

IMSI detach (type 1) IMSI detach (type 1) N/A

IMSI detach (type 2)PagingN/A

IMSI detach (type 2)PagingOne phase access andEnhanced one phase access

N/AN/AN/A

Continued

6-18 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Assumptions used in capacity calculations

Table 6-5 Signaling message procedures (Continued)

MSC - BSC BSC - BTS SMLC - BSC

NOTEEnhanced OnePhase is notsupported withEGPRS carriers.

LCS LCS LCS

The BSS software uses a new small message header (compact header) for delivering messagesbetween the BSC/PCU and the BTS. The new message header contains the minimum informationnecessary to deliver the messages between the processes. The size of the message header is 8bytes. 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 theprocedures not included in the traffic model are considered to have a negligible effect.

NOTESupplementary Service (SS) messaging has not been taken into account. This couldcontribute 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 (orLAI) only. Paging by LAC only, is the recommended method. Paging by LAC and cell ID is notnecessary, and has two major disadvantages:

• The paging method is controlled by the MSC and is signaled to the BSC through thesetting of the Cell Identification Discriminator in the BSSMAP paging message. The BSCcan determine from its Configuration Management database the cells that require to bepaged from the location area code only. Therefore, the MSC does not require to send alist of each individual cell identity. Paging by LAC and Cell ID increases the length of theBSSMAP paging considerably and significantly increases the C7 signaling load betweenthe MSC and BSC.

• Paging by LAC only reduces the possibility of paging channel overload on the air interfacecaused by any database mismatch between the BSC and MSC. If the BSC receives a cellidentity in the paging message from the MSC that does not exist in its ConfigurationManagement database, it defaults to paging all cells in the BSS for safety reasons. Thiscan cause overload of the paging channel on the radio interface.

68P02900W21-T 6-19

Jul 2010

Link capacities Chapter 6: BSC planning steps and rules

Half rate assumptions

A (AMR or GSM) half rate enabled carrier is capable of carrying two half rate calls in eachtimeslot, for 16 (half rate) TCHs. The actual number in use at a given instance depends uponsuch 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, thatnumber can be used when considering equipment planning. Otherwise, it is recommended thata worst case approach be taken. For example, when determining the RSL signaling link capacityrequired, and half rate usage is expected to be no more than 50%, and there are two (both halfrate 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 28TCHs. 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 capableand the 7.95 kbps half rate codec mode is included in the Half Rate Active Codec Set, then thecarrier unit assigned to that RTF needs four 64 kbps timeslots on the E1 circuit (regardless ofhow they are utilized). For an EGPRS capable RTF (pkt_radio_type set to 3), 16 kbps switchingon the backhaul is not supported and allow_8k_trau has to be enabled if half rate is supported.

NOTEAMR 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 thathas more links running at a lower message rate can have the advantage of offering betterfault 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 reducedqueuing delays for signaling messages. A design that utilizes fewer links at a higher messagerate, reduces the number of 64 kbps circuits required for signaling, and potentially reduces thenumber of resources (processors, data ports) required in the MSC. It is recommended that theC7 links be designed to operate at no more than 40% utilization when the MTL/LMTL is runningon a GPROC2 or GPROC3. Before use of the 40% utilization for GPROC2 or GPROC3, it isimperative that the operator verifies that the MSC/SMLC vendor can also support 40% utilizationat 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) becomeoverloaded.

NOTEOverloading GPROCs can cause the BSC to become unstable. Links must bemonitored closely to ensure that link utilization does not exceed the maximum. If linkutilization is regularly approaching the maximum, additional capacity should beadded to reduce the possibility of overloading the GPROCs.

6-20 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Link capacities

The protocol C7, used for the MSC to BSC links and SMLC to BSC links, allows for the signalingtraffic from the failed link to be redistributed among the remaining functioning links. Both theMSC-BSC and SMLC-BSC C7 link set officially have at least two and at most 16 links. Thefailure of links, for any reason, causes the signaling to be shared across the remaining membersof the link set. Therefore, the design must plan for reserve link and processing capacity tosupport a certain number of failed signaling links.

68P02900W21-T 6-21

Jul 2010

Determining the number of RSLs required Chapter 6: BSC planning steps and rules

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 totalnumber of LCFs can be determined for the BSC.

Planning considerations

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 everyBTS site. One link can support multiple collocated cells. As the system grows, additionalsignaling links are required. Refer to the section Determining the required BSS signalinglink 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 withPCCCH 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 thePCCCH. 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 RSLon page 2-17 in Chapter 2 Transmission systems for further details. 64 kbps RSLs must beused when allowable numbers are exceeded.

Extended Uplink TBF is the feature enhances uplink data performance by minimizing theinterruptions of uplink data flow in GPRS/EGPRS networks due to a frequent release andestablishment of uplink TBF. According to the principle of Extended Uplink TBF, this featuredecreases the amount of RACH for uplink applications session like uplink FTP, and so on. Ifthe uplink application is rare, the total amount of decreased RACH is small. Thus, the impactof RACH decrement can be ignored. If the uplink applications are booming, total amount ofdecreased RACH is huge. Therefore the impact of RACH decrement cannot be ignored, andRACH decrement is taken into account for RSL calculation.

6-22 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 kbpsRSLs Supported

A BSU-based BTS 6

Horizon II macro and Horizonmacro 6

Horizon II macro (mini/micro)with HorizonII SC-2/E or /BBU-E

12

Horizonmicro2 / Horizoncompact2 2

M-Cell6 6

M-Cell2 4

M-Cellmicro and M-Cellcity 2

NOTE

• Horizon II macro BTSs support 4 x RSLs per E1, whereas Horizonmacroand M-Cell BTSs only support 2 x RSLs per E1. This should be taken intoconsideration when determining the number of E1s required to support thecalculated RSLs per site.

• While it is possible to equip Horizon II macro BTSs supporting either theHIISC2-S/E or BBU-E, with up to 12 RSLs, there are certain non-standardRSL PATH configurations (the default RSL timeslots are not configured asRSL defined in the database) that could lead to only 10 of these 12 RSLsbeing available (that is, enter the B-U state) for codeloading to the BTS. Oncecodeloading is complete, the remaining 2 RSLs come INS for normal Mobissignaling traffic. It is recommended to configure all the three default RSLtimeslots (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 someGPROC3 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 theshortest downloading duration, the number of GPROC3 or GPROC3-2 in BSCshould 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 asfollows:

RSLGPRS+GSM = RSLGPRS +RSLGSM

This is evaluated for 16 kbps RSLs or for 64 kbps RSLs. The interface between the BTS and BSCdoes not permit mixing the two RSL rates.

68P02900W21-T 6-23

Jul 2010

One phase access and enhanced one phase Chapter 6: BSC planning steps and rules

Where: Is:

RSLGPRS+GSM the combined number of RSL signaling links on a per BTS site basisoperating 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 numberand size of code objects. Codeload time is an additional RSL-related planningconsideration.

Initial estimates suggest that raw RSL codeloading rates (exclude time todistribute and Codeload objects to the various DRIs at a site) can be increasedalmost linearly with the number of RSLs.

RSLGPRS the number of RSL signaling links required to serve the GPRS part ofthe network at 16 kbps or at 64 kbps.

RSLGSM the number of RSL signaling links required to serve the GSM part ofthe 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 toestablish 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 theRACH with an Immediate Assignment message containing an uplink assignment. The MS movesto the assigned PDTCH and begins its uplink data transfer. This procedure allows the MS togain 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 accessprocedure even further. The enhanced one phase access procedure allows the PCU to assignresources for a one phase uplink TBF, allowing the BTS to react quickly to a one phase RACHwithout forwarding the RACH to the PCU and incurring excessive RSL delay and increasingRSL load. Depending on the RSL load, the RACH to Immediate Assignment delay reducesby approximately 60 ms or more.

Standard traffic model

The number of BSC to BTS signaling links (RSLs) must be determined for each BTS. This numberdepends on the number of TCHs and PDTCHs at the BTS. Table 6-7 gives the number of RSLsrequired (rounded up to the nearest integer value) for a BTS to support the given number ofTCHs and PDTCHs, based on the typical call parameters given in the standard traffic modelcolumn 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

System Information: BSS Equipment Planning Standard traffic model

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 PhaseAccess With One Phase Access

#TCHs/BTS(n)

#PDTCHs/BTS (Ngprs)

# 64 kbpsRSLs

# 16 kbpsRSLs # 64 kbps RSLs # 16 kbps RSLs

0 3 10 3 10

15 3 10 3 10

30 3 10 3 10

45 3 10 3 10

60 3 10 3 10

75 3 10 3 10

≤30

90 3 10 3 10

0 3 12 3 12

15 3 12 3 12

30 3 12 3 12

45 3 12 3 12

60 3 12 3 12

75 3 12 3 12

31 to 60

90 3 12 3 12

0 4 14 4 14

15 4 14 4 14

30 4 14 4 14

45 4 14 4 14

60 4 14 4 14

75 4 14 4 14

61 to 90

90 4 14 4 14

Continued

68P02900W21-T 6-25

Jul 2010

Standard traffic model Chapter 6: BSC planning steps and rules

Table 6-7 Number of BSC to BTS signaling links (without LCS) (Continued)

With Enhanced One PhaseAccess With One Phase Access

#TCHs/BTS(n)

#PDTCHs/BTS (Ngprs)

# 64 kbpsRSLs

# 16 kbpsRSLs # 64 kbps RSLs # 16 kbps RSLs

0 5 17 5 17

15 5 17 5 17

30 5 17 5 17

45 5 17 5 17

60 5 17 5 17

75 5 17 5 17

91 to 120

90 5 17 5 17

0 5 19 5 19

15 5 19 5 19

30 5 19 5 19

45 5 19 5 19

60 5 19 5 19

75 5 19 5 19

121 to 150

90 5 19 5 19

0 6 21 6 21

15 6 21 6 21

30 6 21 6 21

45 6 21 6 21

60 6 21 6 21

75 6 21 6 21

151 to 180

90 6 21 6 21

0 6 23 6 23

15 6 23 6 23

30 6 23 6 23

45 6 23 6 23

60 6 23 6 23

75 6 23 6 23

181 to 210

90 6 23 6 23

6-26 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Non-standard traffic model

NOTE

• The RSL calculations assume PGPRS = 0 for cells in which NGPRS = 0. This is notnecessarily true. If the BSC has GPRS timeslots, even if the cells do not havetraffic channels configured as PDTCHs, it may have paging traffic.

• RACH_Arrivals/sec figures have been calculated using Avg_Sessions_per_useras in the call model table. GPRS_Users_BTS has been calculated based on thenumber of timeslots configured on the cell.

• A BTS can support either 64 kbps RSLs or 16 kbps RSLs, but not both. Thenumber of 16 kbps RSLs allowable is dependent on the hardware platform andsome 16 kbps values in the tables may not be valid. 64 kbps RSLs must be usedif the allowable number of 16 kbps RSLs is exceeded.

Non-standard traffic model

64 kbps RSLs

If the call parameters differ significantly from those given in Table 6-3, use the following formulato 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 thefollowing 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 + SMSSIZE ∗ 0.125) + 38 ∗H + 24 ∗ L+ 24 ∗ LCS)

(1000 ∗ U ∗ T )

+ ((31 + 3 ∗ CBTS) ∗ PGSM/ (8000 ∗ U)) ∗(NGSM−only−MS/NGSM−Capable−MS

)

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 phaseaccess or a Motorola proprietary enhanced one phase mechanism.

With one phase access

RSLGPRS@64K =(32 + CBTS) ∗ PGPRS

8000 ∗ U ∗ (PCCCH−BTS) +5.5 ∗GPRS−RACH/sec

1000 ∗ U ∗(1−RPCCCH−Cells−in−BTS

)

68P02900W21-T 6-27

Jul 2010

With enhanced one phase access Chapter 6: BSC planning steps and rules

With enhanced one phase access

NOTEEnhanced One Phase is not supported with EGPRS carriers.

RSLGPRS@64K =(32 + CBTS) ∗ PGPRS

8000 ∗ U ∗ (PCCCH−BTS) +7.5 ∗GPRS−RACH/sec

1000 ∗ U ∗(1−RPCCCH−Cells−in−BTS

)

Therefore, the total number of 64 kbps RSLs required is:

RSLGSM+GPRS@64K = Roundup (RSLGSM@64k +RSLGPRS@64k)

NOTEWhen 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 formulato 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 thefollowing 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 PCCCHenabled (pccch_enabled = 1):

RSLGSM@16K =

(n) ∗ (59 + S ∗ (25 + SMSSIZE ∗ 0.125) + 38 ∗H + 24 ∗ L + 24 ∗ LCS)

(1000 ∗U ∗ T) +(

(31+3∗CBTS)∗PGSM(8000∗U)

)∗(

NGSM only MSNGSM Capable −MS

)

∗ 4

With one phase access

RSLGPRS@16K =[

(32 + CBTS) ∗ PGPRS8000 ∗ U ∗ (PCCCH−BTS) +

GPRS−RACH/sec

1000 ∗ U ∗(1−RPCCCH−Cells−In−BTS

)]∗ 4

6-28 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning With enhanced one phase access

With enhanced one phase access

NOTEEnhanced One Phase is not supported with EGPRS carriers.

RSLGPRS@16K =[

(32 + CBTS) ∗ PGPRS8000 ∗ U ∗ (PCCCH −BTS) +

7.5 ∗GPRS −RACH/sec1000 ∗ U ∗ (1−RPCCCH−Cells−In−BTS)

]∗4

Therefore, the total number of 16 kbps RSLs required is:

RSLGSM+GPRS@16k = Round up (RSLGSM@16K + RSLGPRS@16k)

NOTEWhen 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:

GPRS−RACH/sec =GPRS−Users−BTS ∗Avg−Session−per−user

3600

NOTERACH/sec depends on the traffic profile on the network. For the same amount ofdata transferred per user in a busy hour, if the traffic is predominantly WAP, thenthe number of RACH arrivals is high compared to what is observed when the datatraffic is predominantly FTP transfers. The traffic profile should be calculated basedon the applications running on the network. With interleaving, TBFs it is possible tohave multiple MSs on each timeslot. This should be considered when estimating thesessions for the formula.

In the equations:

Where: Is:

RSLGSM + GPRS the number of BSC-BTS signaling links.

n the greater number of TCH and Eralang supported at the BTS.

S the ratio of SMSs to calls.

SMSSIZE the average size of the SMS message (payload only).

H the number of handovers per call.

Continued

68P02900W21-T 6-29

Jul 2010

With enhanced one phase access Chapter 6: BSC planning steps and rules

Where: Is:

L the location update factor

LCS the number of LCSs per call.

U the percent link utilization (example 0.25).

T 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. Thisincludes the sessions required for signaling (attach, detach, PDPcontext 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 cellsat the BTS with PCCCH enabled divided by the total number ofcells 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 Busy Hour Call Attempts Per Sub

RAU routing area update

PDPACT/DEACT PDP context activation/deactivation (per sub/BH)

PSATT/DETACH PS attach/detach rate (per sub/BH)

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 securesa portion of the bandwidth on the RSL for Circuit Switched (CS) traffic. The default value of thisparameter is 55%, which means that GPRS traffic cannot utilize more than 45% of the total RSLbandwidth, 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 theRSL. 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, whereunexpected sustained surge occurs. Assuming that during a surge of traffic (much higher thanthe planned 25%) the ratio of CS to GPRS traffic is maintained, the default value (55%) forpercent_traf_cs can be adjusted to reflect it.

6-30 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSC to BTS E1 interconnect planning actions

Take an example where total RSL MEAN utilization is 25%, and the ratio of CS to GPRS traffic4 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%, meaningthat 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 linksare added. To determine the impact of different coding schemes on interconnect planning,use the following equation:

NBSC−BTS =

(nEGPRS∑i=0

RTF−DSO−COUNTi

)+ (nCGPRS ∗ 4) + (nGGPRS ∗ 2) + (L16/4) + L64

31

Where: Is:

NBSC-BTS the minimum number of E1 links required (rounded up to aninteger).

nEGPRS the number of carriers with EGPRS enabled.

nCGPRS the number of carriers with GPRS CS3 and CS4 enabled and GSMvoice only carriers where the half rate exception case applies.

nGGPRS the number of carriers with GPRS CS1 and CS2 enabled and GSMvoice 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.

NOTEThis 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 VersaTRAU backhaul

GSM Voice only carrieswhere the half rateexception case does notapply.

GSM Voice only carrierswhere the half rate exceptioncase does apply.

EGPRS capable carriers(MCS1-MCS9).

Carriers with only GPRSCS1 and CS2 enabled.

Carriers with only GPRS CS1,CS2, CS3, and CS4 enabled.

68P02900W21-T 6-31

Jul 2010

BSC to BTS E1 interconnect planning example Chapter 6: BSC planning steps and rules

NOTEAll EGPRS carriers (pkt_radio_type = 3) use VersaTRAU frame formats on thebackhaul between BTS and PCU to carry the data for PDTCHs on this carrierirrespective 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:

Number of E1s ={[(3 ∗ 8) + (12 ∗ 4) + (9 ∗ 2) + 0] + 1}

31= 3

In this example, 3 E1s are required to backhaul this BTS to the BSC. To find out the totalnumber of E1s required for a BSC, all of the BTSs backhaul requirements would require to becalculated and then added together.

Refer to the network configuration to determine if backhaul from multiple BTSs could bemultiplexed 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 3sector 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, and CS4.

• 1 carrier of EGPRS, VersaTRAU is unrestricted and RTF backhaul is set to 5.

6-32 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Determining the number of LCFGPROCs for RSL and GSL processing BSC to BTS E1 interconnect planning actions

The number of E1s is calculated as follows:

Number of E1s ={[(3 ∗ 5) + (12 ∗ 4) + (9 ∗ 2) + 0] + 1}

31= 3

In this example, 3 E1s are required to backhaul this BTS to the BSC. To find out the totalnumber of E1s required for a BSC, all the BTSs backhaul requirements would require to becalculated and then added.

Determining the number of LCF GPROCs for RSL and GSLprocessing BSC to BTS E1 interconnect planning actions

Determine the number of GPROCs required to support the layer 3 call processing.

NOTEGPROC2, GPROC3, and GPROC3-2 or a combination of the three can perform layer3 call processing for GSM and GPRS, but GPROC3 and GPROC3-2 have a greatercapacity than GPROC2. If an LCF is allocated to a GPROC2, BSC configurations witha mix of GPROCs which includes GPROC2s are not recommended when the LCFssupporting RSLs have been planned based on the capabilities of GPROC3s/GPROC3-2sdue to the risk of overloading. Refer to Generic processor (GPROC) on page 6-53later in this chapter.

The calculations are performed separately for the number of GPROCs required for GSM trafficand for GPRS traffic.

The LCF GPROCs can simultaneously handle signaling traffic from both the GSM and GPRSparts of the network. It is possible to calculate the GPRS/EGPRS part of the signaling load forthe LCF GPROCs in fractional increments. The GPRS/EGPRS LCF GPROC requirements canbe directly added to the GSM requirements to determine the total number of LCF GPROCs toequip at a BSC.

GSM layer 3

There are two methods for calculating this number. The first is used when the call parametersare like those listed in Table 6-3 (standard traffic model). The second method is used whenthe call parameters differ significantly from those listed in the tables (that is, non-standardtraffic 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 Chapter6: BSC planning steps and rules

• LCFs using GPROC2 boards:

GL3 =n

308.66+

B9.29

+C87

• LCFs using GPROC3 or GPROC3-2 boards:

GL3 =n

363.35+

B18.32

+C

396

Where: Is:

GL3 the number of LCF GPROCs required to support the layer 3 call processing.

n the number of TCHs at the BSC (see Half rate assumptions on page 6-20earlier in this chapter).

B the number of BTS sites.

C the number of cells.

Non-standard traffic model

If the call parameters differ significantly from those given in Table 6-3, the alternative formulagiven should be used to determine the recommended number of LCFs based on the typeof GPROC.

LCFs using GPROC2 boards:

GL3 = n ∗ [1 + 0.35 ∗ S + 0.35 ∗H ∗ (1− 0.43 ∗ i) + 0.30 ∗ L + 0.35 ∗ Lcs](13.89 ∗ T)

+ (0.00113 ∗ PGSM + 0.0005) ∗ B +C87

LCFs using GPROC3 or GPROC3-2 boards:

GL3 = n ∗ [1 + 0.42 ∗ S + 0.5 ∗H ∗ (1− 0.5 ∗ i) + 0.42 ∗ L + 0.35 ∗ Lcs](34.72 ∗ T)

+ (0.00059 ∗ PGSM + 0.0001) ∗ B +C

396

6-34 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Determining the number of LCFGPROCs for RSL and GSL processing BSC to BTS E1 interconnect planning actions

Where: Is:

GL3 the number of LCF GPROCs required to support the layer 3 call processing.

n the number of TCHs under the BSC (see Half rate assumptions on page 6-20earlier in this chapter).

S the ratio of SMSs to calls.

H the number of handovers per call.

i the ratio of intra-BSC handovers to all handovers.

L the location update factor.

T the average call duration.

PGSM the GSM paging rate in pages per second.

B the number of BTS sites.

C the number of cells.

LCS the number of LCSs per call.

T the average call duration.

B the number of BTS sites.

C the number of cells.

Having calculated the LCF GPROCs for RSLs, ensure that the traffic is evenly distributed acrossthe LCFs. This can be difficult in cases where large sites are being used, and in such casesadditional LCFs are required. Alternatively, use the formula for traffic channels on each LCF. Ifthe calculated value exceeds 1, the sites should be redistributed on the other available LCFs, oradditional LCFs should be equipped.

GPRS layer 3

The MSC can send GSM alerting pages to a GPRS/EGPRS mobile that operates in class A orclass B modes. The significance of this is that GPRS/EGPRS mobile stations capable of classA and B operation create a larger population of GSM capable mobile stations that should beconsidered when provisioning the LCF GPROCs. The planning information provided here shouldbe used for this provisioning.

GL3−GPRS = 0.002 ∗ Total−RACH/sec ∗(1−RPCCCH−Cells

)+ 0.00075 ∗B ∗ PGPRS ∗ PCCCH−BSS

Where:

Total−Rach/sec =GPRS−subs−per−PCU ∗Avg−session−per−subs

3600

68P02900W21-T 6-35

Jul 2010

Determining the number of LCF GPROCs for RSL and GSL processing BSC to BTS E1 interconnect planning actions Chapter6: BSC planning steps and rules

Where: Is:

GL3_GPRS the sum of all GPRS RACH arrivals at the BSC.

Total_RACH/sec the number of TCHs under the BSC (see Half rate assumptions onpage 6-20 earlier in this chapter).

RPCCCH_Cells the ratio of PCCCH-enabled ‘cells (the number of cells in the BSSwith PCCCH enabled divided by the total number of cells in the BSS.

B the number of BTS sites.

PCCCH_BSS 0 if all cells in the BSS have PCCCH enabled, otherwise = 1.

PGPRS 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).

NOTEFor GSR10, it is advantageous to use GPROC3/GPROC3-2s LCF while introducingsites using the HIISC-2/E with BBU-E. The greater on-board memory of theGPROC3/3-2s LCF compared with GPROC2 LCF in certain scenarios enable fastercodeloading to these BTS sites using the HIISC-2/E with BBU-E.

6-36 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 and2 Mbps. The number of required MTLs depends upon the BSS configuration size and trafficmodel. 64 kbps MTLs are carried on E1 links between the MSC and BSC, which are also usedfor traffic. HSP MTLs are only supported on E1 links.

NOTE

• HSP MTL (High Speed MTL) is part of Huge BSC feature to provide 2M MTLcapacity. 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.

Planning considerations

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 thefollowing methods:

Multiply the number of subscribers expected to use the BSC by the average trafficper subscriber.

or

Total the traffic potential of each BTS under the BSC, determined by the number ofTCHs available, the number of TCHs required or the subscriber potential.

• Determine the number of trunks to support the traffic requirements of the BSC usingErlang B tables at the required blocking rate.

• Determine the MTL loadshare granularity to be used for the BSC. MTL loadsharegranularity 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 evendistribution of traffic across the MTL links. This feature allows a more gradual increase inthe number of MTLs required with the increased traffic load on the BSC.

68P02900W21-T 6-37

Jul 2010

Standard traffic model Chapter 6: BSC planning steps and rules

• Determine if LCS is enabled in the BSS and which LCS architecture is supported bythe BSC. The BSC can support either NSS-based LCS architecture or BSS-based LCSarchitecture, 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 to16, if using a granularity of 0. When using a granularity of 1, only 10 64 k MTLs arerequired. This results from the enhanced load sharing of 64 k MTLs and illustrates thedifference between setting the load share granularity to 0 and 1 respectively. Table 6-9and Table 6-10 illustrate the difference between setting the load share granularity to 0and 1 for 64 k MTL. Table 6-11 and Table 6-12 illustrate the difference between settingthe load share granularity to 0 and 1 for HSP MTL. Load share granularity of 0 means 16logical links mapped to equipped physical MTL links. Load share granularity of 1 means64 logical links mapped to equipped physical MTL links.

These calculations are for the MTLs required from the BSS perspective, using theBSS planning rules. If the MSC vendor supplies their own planning rules for a givenconfiguration, the more conservative MTL provisioning figures should be used. If the MSCvendor 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 theMSC to load share the signaling links from the MSC to BSC.

Standard traffic model

The number of MSC to BSC signaling links (MTL) required depends on the desired linkutilization, the type, and capacity of the GPROCs controlling the MTLs and the MTL load sharegranularity. 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 HSPMTL per GPROC3-2 board.

CCITT C7 uses a 4-bit number, the Signaling Link Selection (SLS), generated by the upperlayer to load share message traffic among the in-service links of a link set. When the numberof in-service links is not a power of 2, some links experience a higher load. The BSS supportsdistribution of signaling in the uplink direction, over 64 logical links. The BSS evenly distributesthe 64 logical links over the active MTLs. The number of MTLs is a function of the numberof MSC to BSC trunks or the offered call load and signaling for the call load. Table 6-9 andTable 6-10 give the recommended minimum number of MSC to BSC signaling links based on thetypical 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 blockingincreases, 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

System Information: BSS Equipment Planning Standard traffic model

NOTEBefore setting the load share granularity to 1, it is recommended that confirmation isgained from the Motorola local contact, or local office, that the switch is compatiblewith 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 numberof MSC-BSC trunks or theoffered load from the BTSs

Number of MTLs with 16logical links

Number of MTLs with 64logical links

Minimumrequired

Withredundancy

Minimumrequired

Withredundancy

N ≤ 85 8 9 6 7

85 < N ≤ 170 8 9 8 8

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 numberof MSC-BSC trunks or theoffered load from the BTSs

Number of MTLs with 16logical links

Number of MTLs with 64logical links

Minimumrequired

Withredundancy

Minimumrequired

Withredundancy

N ≤ 85 4 5 3 4

85 < N ≤ 170 4 5 4 5

170 < N ≤ 350 6 7 5 6

350 < N ≤ 520 8 9 7 8

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

68P02900W21-T 6-39

Jul 2010

Non-standard traffic model for 64 k MTL Chapter 6: BSC planning steps and rules

Table 6-11 shows how to estimate the number of 2M HSP MTLs to be used for the BSC, with13% link utilization.

Table 6-11 Number of MSC and BSC signaling links without LCS (13% utilization)

N=the greater of numberof MSCBSC trunks or theoffered load from the BTSs

Number of MTLs with 16logical links

Number of MTLs with 64logical links

Minimumrequired

Withredundancy

Minimumrequired

Withredundancy

N ≤ 482 2 3 2 3

483 < N ≤ 1966 4 5 4 5

1966 < N ≤ 2956 6 7 5 6

2956 < N ≤ 3315 6 7 5 6

3315 < N ≤ 4800 8 9 7 8

4800 < N ≤ 6200 8 9 8 9

The capacities shown in Table 6-9 , Table 6-10 and Table 6-11 are based on the standard trafficmodel shown in Table 6-3.

It is recommended that the C7 links be designed to operate at no more than 40% utilizationwhen 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 ifthe MSC vendor can also support 40% utilization at the MSC end. If not, then only 20% linkutilization 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 procedureis used to determine the required number of 64 k DS0 MSC to BSC signaling links:

• Use the formula to determine the maximum number of Erlangs supported by a C7 signalinglink (nlink).

nlink =1000 ∗ U ∗ T

40 + S ∗ (26 + 0.125 ∗ SMSSIZE) + 24 ∗H ∗ (1− 0.83 ∗ i) + 24 ∗ L+ CICS ∗ LCS + 9 ∗ PPC

• Use the formula to determine the maximum number of Erlangs supported by a GPROC(LCF-MTL) supporting a C7 signaling link (nlLCF-MTL).

nLCF−MTL =20 ∗ T

(1 + 0.16 ∗ S + 0.5 ∗H ∗ (1− 0.6 ∗ i) + 0.42 ∗ L+ 0.45 ∗ LCS + PPC ∗ (0.005 ∗B + 0.05))

• The maximum amount of traffic an MTL (a physical link) can handle (nlmin) is the smallerof the two numbers from:

nlmin = MIN(nlink, nlLCF−MTL

)

6-40 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Non-standard traffic model for HSP MTL

• Signaling over the A Interface is uniformly distributed over some logical links. The numberof 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 MTLsignaling is load shared. Hence, the total amount of traffic that a logical link would hold, iscalculated as:

Nlogical =N

Ng

• Next determine the number of logical links each MTL (physical link) can handle

nlog−per−mtl = rounddown

(nlminNlogical

)

• 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 aGPROC (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 thissection). Suggest to maintain the mean utilization of GPROCs at or 70%.

Non-standard traffic model for HSP MTL

If the call parameters differ significantly from those given in Table 6-3, the following procedureis used to determine the required number of MSC to BSC HSP signaling links:

• Use the formula to determine the maximum number of Erlangs supported by a C7 signalinglink (nlink).

nlink =31000 ∗ U ∗ T

40 + S ∗ (26 + 0.125 ∗ SMSSIZE) + 24 ∗H ∗ (1− 0.83 ∗ i) + 24 ∗ L+ CICS ∗ LCS + 9 ∗ PPC

• 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−MTL =56∗T

(1 + 0.53∗S + 0.5∗H∗ (1− 0.92∗i) + 0.52∗L+ 0.92∗LCS + PPC ∗ (0.006∗B + 0.10))

68P02900W21-T 6-41

Jul 2010

Non-standard traffic model for HSP MTL Chapter 6: BSC planning steps and rules

• The maximum amount of traffic an MTL (a physical link) can handle (nlmin) is the smallerof the two numbers from the previous two formulae.

nlmin = MIN(nlink, nlLCF−MTL

)

• Signaling over the A Interface is uniformly distributed over some logical links. The numberof 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 MTLsignaling is load shared. Hence, the total amount of traffic that a logical link would hold, iscalculated as:

Nlogical =N

Ng

• Next determine the number of logical links each MTL (physical link) can handle

nlog−per−mtl = rounddown

(nlinkNlogical

)

• Finally, the number of required MTLs (mtls) is:

mtls = roundup

(Ng

nlog−per−mtl

)+R ≤ 16

6-42 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Calculate the number of LCFs for MTL processing

Where: Is:

U the percent link utilization (for example 0.13).

T call hold time.

S the ratio of SMSs per call

SMSSIZE the average size of the SMS message (payload only).

H the number of handovers per call.

i the ratio of intra-BSC handovers to all handovers.

L the location update factor.

Clcs 26 for NSS-based architecture. 31 for BSS-based architecture.

LCS the number of LCSs per call.

PPC the number of pages per call.

B the number of BTSs supported by the BSC.

mtls the number of MTLs required

round up round up to the next integer.

round down round down to the next integer.

MIN the minimum of two values.

N the number of MSC-BSC trunks.

Ng the number of logical links (16 or 64).

R 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 MTLprocessing. 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 notpermitted 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 Chapter 6: BSC planning steps and rules

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 thenumber of HSP MTLs.

NLCF = mtls

Where: Is:

NLCF the number of LCF GPROCs required.

ROUND UP rounding up to the next integer.

mtls calculated in the previous section.

nlink calculated in the previous section.

nlLCF-MTL calculated in the previous section.

MSC to BSC signaling over a satellite link

The BSC supports Preventive Cyclic Retransmission (PCR) to interface to the MSC over asatellite link. PCR retransmits unacknowledged messages when there are no new messages tobe sent. This puts an additional processing load on the GPROC (LCF-MTLs) controlling the C7signaling links. It is recommended that when PCR is used, that the number of MTLs (and thusthe number of LCF-MTLs) be doubled from the number normally required.

6-44 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 applicablefor 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.

Planning considerations

The following factors require to be considered when planning the number of LMTL links fromthe 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. SeeTable 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 upto the next integer):

LLMTL = Roundup

(LCS−BSC−Rate ∗ 19

1000 ∗ UBSC−SMLC

)

Where: Is:

LLMTL 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 rounding up to the next integer.

68P02900W21-T 6-45

Jul 2010

BSC to SMLC interconnection planning actions Chapter 6: BSC planning steps and rules

BSC to SMLC interconnection planning actions

Determine the number of E1 links required to connect to an SMLC. Redundant links are added,if required.

NBSC−SMLC = Roundup

(LLMTL

31

)

Where: Is:

NBSC-SMLC the minimum number of E1 links required (rounded up to an integer).

ROUND UP rounding up to the next integer.

NOTEThe 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. Forthe LCF GPROC, one dedicated LCF-LMTL is required for processing LMTLs.

NOTE

• Both GPROC2 and GPROC3 or a combination of the two can perform LMTLprocessing. Refer to Generic processor (GPROC) on page 6-53 later in thischapter. 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.

6-46 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 requireddepends upon the number of CICs and/or the number of Ater interface channels.

Planning considerations

The following factors require to be considered when planning the number of XBL links from theBSC to the RXCDR:

• Determine the traffic requirements of the BSC and/or the number of trunks (CICs) usedbetween the BSC and RXCDR.

• Determine the mode (backward compatibility or auto-connect/ enhanced auto connect) inwhich the BSC and RXCDR operate. See Chapter 2 Transmission systems for a descriptionof 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 andwhether 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 trunksbetween the BSC and RXCDR, with auto-connect mode or enhanced auto-connect mode.

68P02900W21-T 6-47

Jul 2010

Standard traffic model Chapter 6: BSC planning steps and rules

Table 6-12 Number of BSC to RXCDR signaling links

No redundancy With redundancyN = number ofredundancy MSCto BSC trunks

Number of 64kbps XBLs

Number of 16kbps XBLs

Number of 64kbps XBLs

Number of 16kbps XBLs

N ≤ 1200 1 4 2 8

1200 < N ≤2400

2 8 4 16

2400 < N ≤3200

3 11 6 22*

3200 < N ≤4800

4 16 8 32*

4800 < N ≤6200

5 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 todouble the capacity (to 80%) under fault conditions (in some configurations). 80% utilization,queuing delays could become substantial. Although both auto-connect mode and enhancedauto-connect mode apply a load, it is the enhanced auto-connect mode load that can varydepending on system configuration. When operating in this mode, the XBL link utilizationshould be monitored to determine if additional capacity is required. The number of XBL links asshown is a minimum number that are required, regardless of measured utilization. This is dueto 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.

Standard traffic model

The minimum number of XBL links required as given in Table 6-12 was verified using a standardset of call parameters. These are given in Table 6-13.

Table 6-13 Typical call parameters relating to XBLs

Parameter Value

Link utilization 40%

Call duration 83.27 s

Average XBL message size 50 bytes

XBL messages per new call * 1

XBL messages per full rate <-> half ratehandover

1

Full rate <-> half rate handovers per call 1

* Mobile origination, mobile termination, hand-in from MSC.

6-48 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Non standard traffic model

Non standard traffic model

If the call parameters differ significantly from those given in Table 6-13, use the followingformula to determine if the required number of 64 kbps XBLs (rounded up to the next integer)should be adjusted:

XBL =(N/T ) ∗ (Mnewcell +Mhandover ∗Hfr−hr) ∗ LXBL ∗ 8

64000 ∗ UBSC−RXCDBC

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

XBL =[

(N/T ) ∗ (Mnewcell +Mhandover ∗Hfr−hr) ∗ LXBL ∗ 864000 ∗ UBSC−RXCDBC

]∗ 4

Where: Is:

XBL the number of BSC to RXCDR signaling links.

N the number of MSC-BSC trunks.

T 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 formulaand the number given in Table 6-12.

68P02900W21-T 6-49

Jul 2010

Determining the number of GSLs required Chapter 6: BSC planning steps and rules

Determining the number of GSLs required■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Planning considerations

The connection between PCU and BSC can be E1 and/or Ethernet link. Ethernet links and E1links can be equipped simultaneously in the system.

When only E1 is used, PCU needs one E1 to carry GSL signaling, and a second E1 forredundancy. In this configuration, PCU can support up to 30 primary GSL 64 kbps timeslots and30 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 oneEthernet link. In the following configuration, up to 60 GSL 64 kbps timeslots can be supportedin 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 GSLis lightly loaded. GSL provision should be load-balanced over multiple links, as the mechanismfor providing resiliency against link failures. The number of GSLs required is calculatedas follows:

GSL = MAX(GSLrun−time, GSLinit−time

)

The requirement for the number of GSLs during system initialization (GSLinit_time) is 6. EachGSL message consists of three parts: LAPD protocol, BSS executive header protocol, and theapplication message carrying actual signaling information. The LAPD and BSS protocol partscan be considered messaging overhead. In addition, in a similar manner to RSL, the GSL trafficdepends on the access mechanism used on the Air interface. The calculation for the requirednumber of GSL links during runtime (after the system stabilizes) is as shown.

GSLrun−time = GSLPaging +GSLRACH

With one phase access

GSLRACH =

(1−RPCCH−Cells

)∗ Total−RACH/sec ∗ 5.5

1000 ∗ U

6-50 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning considerations

With enhanced one phase access

NOTEEnhanced One Phase is not supported with EGPRS carriers.

GSLRACH =

(1−RPCCH−Cells

)∗ Total−RACH/sec ∗ 7.5

1000 ∗ U

Where:

Total−RACH/sec =GPRS−subs−per−PCU ∗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. TheGSL requirement for GPRS paging is given by the following:

GSLPaging =8.5 ∗ PGPRS ∗No−LCFs−for−RSL ∗ PCCCH−BSS

1000 ∗ U

Where: Is:

GSL 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 the GPRS paging rate in pages per second.

Total_RACH/sec the sum of all GPRS RACH arrivals on the BSC.

U 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 (thisincludes sessions for signaling).

RPCCCH_Cells the ratio of PCCCH-enabled cells (the number of cells with PCCCHenabled divided by the total number of all cells in the BSS).

No_LCFs_for_RSL the number of LCF boards in the BSC that terminate RSL links.

PCCCH_BSS = 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 Chapter 6: BSC planning steps and rules

Where: Is:

H 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 cell updates (per sub/BH).

T 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 balancedover all GSLs. Furthermore, should more than one GSL terminate on an LCF, the load isbalanced over these GSLs. The general rule of thumb is to terminate at least one GSL on a SITELCF in a heavily loaded system to avoid unnecessary LAN traffic.

In sysgen, the gsl_lcf_mapping parameter determines if the BSS automatically distributes theGSLs 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 thesystem 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 modeof gsl_lcf_mapping is only valid in sysgen. Outside of sysgen, gsl_lcf_mapping is alwaysset to Manual.

Should the operator require to specify LCFs outside of sysgen mode or wish to configure thesystem manually, the GSLs should be evenly distributed among the LCFs that terminate theRSLs.

The operator can choose to distribute manually the GSLs. Use a similar approach to evenlydistribute among LCFs carrying RSL traffic. Although it is not necessary, the operator canchoose to consider the total count of PDTCHs on each LCF and assign more GSLs to thoseLCFs having more PDTCHs.

6-52 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Generic processor (GPROC)

Generic processor (GPROC)■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

GPROC nomenclature

For the purposes of this manual only and to avoid confusion between different versions of thegeneric 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 controlprocessor.

This section describes the BSC GPROC types and their functions. The BSC configuration typeand GPROC device type are essential factors for BSC planning.

The GPROC3/GPROC3-2 is a high performance direct replacement for GPROC2s. Thisallows for any combination of GPROC types to be installed except in the BSP slots wherea 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 theprocessing platform for the BSC. By using multiple GPROCs, software tasks can be distributedacross GPROCs to provide greater capacity. The set of tasks that a GPROC is assigned, dependsupon the configuration and capacity requirements of the BSC. Although every GPROC of thesame type is similar from a hardware standpoint, when a group of tasks are assigned to aGPROC, it is considered to be a unique GPROC device type or function in the BSC configurationmanagement scheme.

There are a limited number of defined task groupings in the BSC, which result in the naming offour unique GPROC device types for the BSC. The processing requirement of a particular BSCdetermines the selection and quantity of each GPROC device type.

68P02900W21-T 6-53

Jul 2010

GPROC functions and types Chapter 6: BSC planning steps and rules

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

SoftwareRelease BSP MTL-LCF LMTLLCF RSL-LCF OMF CSFP

GSR 8 GPROC3 GPROC2or

GPROC3

GPROC2or

GPROC3

GPROC2or

GPROC3

GPROC2or

GPROC3

GPROC2or

GPROC3

GSR9 GPROC3or

GPROC3-2

GPROC2or

GPROC3or

GPROC3- 2

GPROC2or

GPROC3or

GPROC3- 2

GPROC2or

GPROC3or

GPROC3- 2

GPROC2or

GPROC3or

GPROC3- 2

GPROC3or

GPROC3-2

GSR 10 GPROC3or

GPROC3-2

GPROC2 orGPROC3 orGPROC3- 2

GPROC2 orGPROC3 orGPROC3- 2

GPROC2 orGPROC3 orGPROC3- 2

GPROC2 orGPROC3 orGPROC3- 2

GPROC3 orGPROC3-2

NOTE

• It is mandatory for a GPROC3/GPROC3-2 to be installed in BSP capable slotsat the BSC. A GPROC3-2 is required for hosting HSP MTL LCFs. For the 1000carriers BSC configuration, GPROC3 or GPROC3-2 is required for the otherGPROC functions.

• GPROC3/3-2 is mandatory for OMF when large_site_support is enabled, whichextends the support carriers up to 36 per site when equipping two BBU-Es with6 (R)CTU8m is configurated.

6-54 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 BSCas a board level replacement. Replacement is not mandatory for these functions. TheGPROC3/GPROC3-2 does not provide any capacity and performance improvements interms of number of links or sites supported. In GSR10 and onwards it can be used toincrease the capacity of LCFs used to RSLs and BTSs. The only difference from otherboard 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 theRXCDR.

• 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 extendsthe support carriers up to 36 per site when equipping two BBU-Es with 6 (R)CTU8m isconfigurated.

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 andmaintenance functionalities.

Link control processor (LCF)

Running the radio-signaling link (RSL) and layer 3 processing or MTL/LMTL (C7signaling link) communications links. It also runs the GSLs for GPRS signalingbetween the BSC and PCU.

68P02900W21-T 6-55

Jul 2010

Planning considerations Chapter 6: BSC planning steps and rules

• BSC type 2

Master GPROC

Running the BSP

LCF

OMF

Running the O&M, including statistics collection, and OML link (X.25 control linksto the OMC-R.

Planning considerations

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, bothactive 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 issupported).

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 anadditional GPROC3/GPROC3-2 to provide redundancy for the signaling LCFs. Wheremultiple shelves exist, each shelf should have a minimum of two GPROCs to provideredundancy within that shelf.

Link control function

The following factors should be considered when planning the number of LCFs:

6-56 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning considerations

• 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 RSLsvaries 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-2LCF can process up to 1620 active calls. The default value is 80, meaning that the1297th 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 canprocess 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 TechnicalDescription: BSS Command Reference (68P02901W23) for further details.

• For optimum performance, the GSL handling should be distributed among the LCFs thatterminate RSLs. (Refer to Load balancing on page 6-52).

NOTE

• Combining MTL and RSL processing on a single GPROC is notrecommended.

• BSC configurations with a mix of GPROCs which includes GPROC2s are notrecommended when the LCFs supporting RSLs have been planned basedon the capabilities of GPROC3s/GPROC3-2s due to the risk of overloading ifan 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 thelink utilization is higher, the actual number of MTLs supported per LCF depends on theErlangs supported per LCF and MTL for that particular call model. A single GPROC3-2supports one HSP MTL working at 13% link utilization.

• If any LCF does not satisfy the criteria, either rebalancing of sites on the available LCFGPROCs at the BSC is required or additional LCF GPROCs are required to be equipped atthe 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 GPROCmax_gsls parameter.

• Up to 38 LCFs can be supported.

68P02900W21-T 6-57

Jul 2010

Cell broadcast link Chapter 6: BSC planning steps and rules

• A maximum of 31 BTS sites can be controlled by a single LCF. All RSLs (LAPD links) forthe BTSs terminate on the same GPROC, so if return loops are used, then the maximumnumber of BTS sites is 15 (if GPROC_slots = 32). If GPROC_slots is set to 16 then at themost 15 RSLs may exist which would support up to 7 BTS sites, and if GPROC_slots is setto 24 then at the most 23 RSLs may exist, supporting up to 11 BTS sites.

NOTEThe number of serial links per GPROC must be determined. The current valuesare 16, 24, or 32 with 16 being the default value. One link is reserved for eachboard (for GPROC test purposes) so the number of available serial links is15, 23, or 31. However, when the links are running at high load, the GPROCexperiences some performance problems when terminating 31 links. Hence, theuse of more than 23 links per board is not recommended.

• Setting GPROC_slots = 24 allows for additional LAPD links up to the recommendedmaximum without the timeslot under-utilization associated with a GPROC_slots settingof 32.

Cell broadcast link

The cell broadcast link (CBL) connects the BSC to the cell broadcast center. For typicalapplications (less than ten messages per second), this link can exist on the same LCF as thatused to control BTSs. The CBL should not be controlled by an LCF MTL (a GPROC controllingan MTL).

Optimizations Link (OPL)

The OPL is used to carry measurement reports out of the BSC to the IOS (IntelligentOptimization Service). The link is as an HDLC stream of UI frames. The source of the data isthe RSS Handover and Power Control (HDPC) process. Operator commands indicate whichdata is required. Operator commands also indicate which LCF GPROC is used for the OPL. Itis recommended to use the LCF which is least utilized. To minimize the HDLC configurationssupported, 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 interfaceto the OMC-R from the BSP. One of the major functions offloaded from the BSP is the centralstatistics process. It is recommended to equip an OMF, especially with the introduction of theBSP highload Protection mechanism feature in GSR 9.

GPROC3/3-2 is mandatory for OMF when large_site_support is enabled, which extends thesupport carriers up to 36 per site when equipping two BBU-Es with 6 (R)CTU8m.

6-58 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Code storage facility processor

Code storage facility processor

The BSS supports a GPROC acting as the code storage facility processor (CSFP). The CSFPallows 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, anadditional GPROC is required.

When Horizon II macro, Horizonmacro or M-Cell BTSs are connected to the BSC, a dedicatedCSFP 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 isimplemented using the configure_csfp command and works as follows:

The system can borrow certain devices and temporarily convert them into a CSFP, and whenthe CSFP functionality is no longer required the device can be converted back into its previousdevice. 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 pooledGPROC3-2 in service to execute a command from the OMC-R to borrow the device and convertit into a CSFP. The operator can then download the new software load or database and execute aCSFP swap. Once the swap has been completed and verified as successful, the operator canreturn the CSFP back to the previous redundant or pooled device type through a separatecommand from the OMC-R.

See Technical Description: BSS Command Reference (68P02901W23) for more details on theconfigure_csfp command.

GPROC redundancy

BSP redundancy

A failure of the BSP GPROC3/GPROC3-2 causes a system outage. If the BSC is equipped with aredundant BSP GPROC3/GPROC3-2, the system restarts under the control of the redundant BSPGPROC3s. If the BSC is not equipped with a redundant BSP and the BSP GPROC3/GPROC3-2was to fail, the BSC would be inoperable.

The BSC Reset Management feature is enabled by default. This feature provides fast switchoverbetween master and redundant BSP processors in the event of a BSP failure. This reduces theoutage 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 additionalGPROCs for spares, if an LCF or the OMF GPROC were to fail, the system software automaticallyactivates a spare GPROC from the GPROC pool to replace the failed GPROC. It is recommendedthat all the pooled GPROCs are GPROC3/GPROC3-2 when the LCFs supporting RSLs have beenplanned based on the capabilities of the GPROC3/GPROC3-2.

68P02900W21-T 6-59

Jul 2010

GPROC redundancy Chapter 6: BSC planning steps and rules

GPROC preemption

The GPROC preemption function searches for a Busy-Unlocked (B-U) GPROC running a lowerpriority function when a GPROC hosting a higher priority function goes out-of-service and thereare no Enabled- Unlocked (E-U) GPROCs to host the higher priority function. If such a GPROC isfound, 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 arebrought into service. The order of function type is OMF first, LCF second, and BTF third. Thefunction 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 priorityscheme 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, thatfunction is preempted. In the case of a preempted LCF, the LCF with the highest function id ispreempted. OMF can preempt LCF.

Value = 2: Intra function level preemption. OMF cannot preempt LCF. If a function of lowerpriority is running on a GPROC, that function is preempted. If a GPROC running an LCF goesout-of-service and there is no lower priority function type (for example BTF) running on a poolGPROC, 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 moreimportant than the LCF id. The priority order is as follows:

• OMF: When OMF needs to preempt or camp on other GPROCs, it selects the GPROCbased 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 onGPROC 3-2.

• Standard LCF (LCF when configured with max_mtls = 0, 1, or 2). This can be MTL LCF orLCF for SITEs.

• BTF

When GPROC preemption occurs, service on lower priority GPROC should be terminated. Tominimize service interruption, following are suggested for GPROC planning:

• Equip redundant GPROC for pooled GPROC.

• Assign lowest priority to LCF which serves least traffic.

• Equip HSP MTL LCF before other Standard LCF.

6-60 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning GPROC redundancy

From GSR10 FP2, high capacity RSL-LCF is introduced, which is decided by customer accordingto the number of total carriers being attached on. The HC LCF has a higher priority to bemapped on to GPROC3/3-2 than normal RSL-LCF, also the pre-emption algorithm is altered asbelow, that the priority of high capacity RSL-LCF is lower than HSP MTL LCF but higher thannormal LCF. The normal RSL-LCF cannot pre-empt the HC RSL-LCF, but can be pre-empted byHC RSL-LCF when the intra-function pre-emption is being enabled.

Table 6-15

Function Type Priorities Priorities within FunctionType

Highestpriority

OMF N/A

HSP MTL LCF Lowest ID to Highest ID

High capacity RSL-LCF Lowest ID to Highest ID

LowestPriority

LCF supporting RSLs,DS0/64K MTLs or GSLs **

Lowest ID to Highest ID

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 resourcepools with over provisioning for both LCFfunctionalities, that is, both the MTL-LCF andRSL-LCF pool have their own extra GPROC boardsto provide the best resilience to the pool. Theseextra boards are kept active to load-balance theirrespective pool load. The CSFP, OML, and LMTLactive/standby configurations share a commonspare. Hence, four spare GPROC boards arerequired in this configuration: 1 GPROC3/GPROC3-2for BSP, 1 GPROC3-2 for MTL-LCF and 2 GPROCsfor the other functions (when the LCFs supportingRSLs have been planned based on the capabilities ofGPROC3/GPROC3-2 it is recommended that thesepool GPROCs are GPROC3/GPROC3-2).

Alternative 2 Represents an intermediate solution were a commonspare is provided as backup of the CSFP, OML,LMTL, MTL-LCF pool, and RSL-LCF pool. Becauseof the MTL-LCF computational requirements, thiscommon spare board should be a GPROC3-2 board.

Alternative 3 Represents the worst-case scenario, the onlyredundant component is the BSP.

68P02900W21-T 6-61

Jul 2010

GPROC planning actions Chapter 6: BSC planning steps and rules

Table 6-14 lists availability predictions for three distinct redundant alternatives for a hugeBSC configuration.

Table 6-16 BSS configurations and their availability

BSC Configurations Availability

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/SbyCSFP, 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: Is:

NGPROC the total number of GPROCs required.

B the number of BSP GPROC3s/GPROC3-2.

L the number of LCF GPROCs.

C the number of CSFP GPROC3s/GPROC3-2.

R the number of pool GPROCs (for redundancy).

NOTE

• If dedicated GPROCs are required for either the CSFP or OMF functions thenthey should be provisioned separately.

• GPROC3/3-2 is mandatory for OMF when large_site_support is enabled, whichextends the support carriers up to 36 per site when equipping two BBU-Eswith 6 (R)CTU8m.

6-62 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Transcoding

Transcoding■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Transcoding reduces the number of cellular subscriber voice/data trunks required by a factor offour. When (AMR or GSM) half rate is in use and 8 kbps subrate switching is available and (forAMR 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 isused only for part of the time, thus yielding a reduction factor of less than eight. If transcodingtakes place at the switch using an RXCDR, the number of links between the RXCDR and the BSCis reduced to approximately one quarter (less when half rate is employed under the conditionsdescribed) of the number of links between the RXCDR and the MSC. The GDP2 can process 60channels of FR, EFR, AMR, GSM HR, and Phase 2 data services and is capable of terminatingtwo 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), genericdigital 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 bettersolution of the transcoding function for larger commercial systems. The GDP2 is used to 60channel 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 whenGDP2s are used). The existing RXU shelf has only one E1 per transcoder slot, therefore theGDP2 cannot be used to its full capacity in the existing RXU shelf (the GDP2 supports only 30channels when used in the RXU shelf). Refer to Overview of remote transcoder planning onpage 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 additionaltranscoding requirements of AMR, each of the 15 DSPs on the GDP board is only capable ofsupporting 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 spanline to the MSC, enhanced GDPs are equipped as pairs, each providing half of the transcodingresources. This results in an overall reduction in capacity - equivalent to 30 channels per GDPpair. Use of an EGDP is practical only when used in conjunction with AMR. The EGDP does notsupport GSM half rate. The EGDP can also terminate one Abis E1 link, thus reducing thenumber of MSIs boards required (see EGDP provisioning on page 6-65). Due to the ability of theGDP2 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 (forexample, 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. Itsends the BSC a preference-ordered list, based on such factors as MS capabilities and userconfiguration. When the MSC is capable of choosing the MSC-RXCDR trunk (CIC) based uponthe preferred codec type, a mix of transcoding equipment can be used. If this capability (calledcircuit pooling) is not present, then some equipment combinations can result in non-optimalbehavior.

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 Chapter 6: BSC planning steps and rules

When AMR is employed and both XCDR/GDPs and EGDP/GDP2s are present (and circuit poolingis present at the MSC), there must be sufficient GDP2 and EGDP equipment available to handlethe expected AMR traffic. The proportion of AMR capable transcoding circuits versus non-AMRcapable transcoding circuits should be no less than the proportion of AMR capable MSs versusnon-AMR capable MSs. A safety factor of no less than 20% is recommended (20% allows forsome variation in the actual number and allows for a period of growth in AMR capable MSpenetration before having to add more AMR transcoding ability). Each AMR half rate callneeds one (AMR) transcoder circuit. Lack of an available AMR circuit could cause a call to bedowngraded 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 similarsituation 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 particularvoice channel, circuit pooling is rendered ineffective, as there is no way to predict which mobilesrequire GSM half rate. It becomes necessary to update all transcoding to support GSM HR toguarantee GSM half rate can be used when needed. Without this upgrade, calls on non-GSM HRcapable 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 ismost effective when choosing AMR CICs (EGDP, GDP2) for AMR capable mobiles, and theremaining CICs for non- AMR capable mobiles. Ideally, for AMR capable mobiles the MSC wouldfirst select a CIC attached to an EGDP, followed by one attached to a GDP2. For a non-AMRcapable mobile the MSC would first select a CIC attached to a GDP, followed by one attachedto a GDP2. The selection of the proper CIC (circuit pool) is dependent upon the capability ofthe connected MSC.

GDP/XCDR/EGDP/GDP2 planning considerations

The following factors should be considered when planning the GDP/XCDR/EGDP/GDP2complement:

• 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 capableof terminating one E1 link from the MSC.

• An EGDP consists of a pair of GDP cards, a primary and a secondary. Each EGDP canprocess 30 channels of GSM FR, EFR, AMR (FR and HR) speech and Phase 2 data services,and terminates one E1 link from the MSC.

NOTEGSM HR is not supported on an EGDP.

• 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 EGDPprovisioning on page 6-65.

6-64 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning EGDP provisioning

• The GDP2 can process 60 channels of FR, EFR, AMR (FR and HR), GSM HR, and Phase 2data services and is capable of terminating two E1 links from the MSC. It can also functionas 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 theOMC-R. The master MSI slot contains an XCDR/GDP/EGDP (see NOTE) /GDP2, if theOML goes through the MSC.

• The A Interface must terminate on the XCDR/GDP/EGDP (either the primary or secondary)/GDP2.

NOTEAn XCDR card is incompatible with a GPROC3/GPROC3-2 in the BSP slots. XCDRsmust be replaced with GDP/GDP2s.

EGDP provisioning

The secondary GDP of an EGDP can use the E1 connection to terminate an Abis link. Thisreduces 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 intoaccount in site (MSI) planning.

Figure 6-2 and Figure 6-3 show the EGDP used in configurations with and without the additionalE1 termination in use respectively.

68P02900W21-T 6-65

Jul 2010

EGDP provisioning Chapter 6: BSC planning steps and rules

Figure 6-2 EGDP configuration with the additional E1 termination in use

E1 Spanto MSC

PrimaryGDP

15DSPs

TDM Bus

15DSPs

SecondaryGDP

E1 Spanfrom an RXCDRto a BSC or froma BSC to a BTS

ti-GSM-EGDP_configuration_with_the_additional_E1_termination_in_use-00128-ai-sw

6-66 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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)

Subratechannelscarried ontothe TDM bus(TRAU framesusing 16Kbps)

RXCDR: Staticor dynamic callconnectionsbetween CICsfor GDP pairand afterchannels(TRAU framesusing 16Kbps)

E1 Spanfrom an RXCDRto a BSC or froma BSC to a BTS

MSI

TDM Bus

PrimaryGDP

15DSPsE1 Span

to MSC

SecondaryGDP

15DSPs

BSC: Dynamic callconnections betweenCICs for a GDP pairand Abis channels(TRAU framesusing 16Kbps)

ti-GSM-EGDP_configuration_without_the_additional_E1_termination_in_use-00129-ai-sw

Planning actions for transcoding at the BSC

Planning transcoding at the BSC must always be performed as it determines the number ofE1 links for the A Interface. This text should be read in conjunction with the BSS planningdiagram, Figure 6-1.

68P02900W21-T 6-67

Jul 2010

Planning actions for transcoding at the BSC Chapter 6: BSC planning steps and rules

Using E1 links

The minimum number of E1 links required for the A Interface is the greater of the twocalculations 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

NOTE2M MTL and 64 kbps MTL cannot be supported simultaneously.

Where: Is:

N 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) tothe MSC.

X the number of OML links (X.25 control links to the OMC-R) throughthe MSC.

T the number of trunks between the MSC and the BSC (see Figure 6-1).

O the number of OPL links.

NOTEThe OPL (Optimization Link) is used to carry measurement reports out of the BSCto the IOS (Intelligent optimization Service). In a normal operation, the OPL isequipped up on a spare TS on the E1 link from the BSC to the RXCDR. From there itis nailed (along with other BSCs OPL links connected to the RXCDR) to another E1link on route to the collection.

Each XCDR/GDP/EGDP can terminate one E1 link. Each GDP2 can terminate two E1 links (whenused in a BSU or RXU3 shelf (enhanced capacity mode must be enabled within the RXCDR toaccess 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

System Information: BSS Equipment Planning Planning actions for transcoding at the BSC

Where: Is:

N 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. Ifnecessary, adjust the number of EGDP/GDP2s. The following formula is used to determine thepercentage of AMR capable circuits:

%AMRcircuits =GDP2 ∗ 60 + EGDP ∗ 30

GDP2 ∗ 60 + EGDP ∗ 30 +XCDR ∗ 30 +GDP ∗ 30∗ 100

NOTECount primary and secondary EGDPs as one EGDP in the equation.

68P02900W21-T 6-69

Jul 2010

Multiple serial interface (MSI) Chapter 6: BSC planning steps and rules

Multiple serial interface (MSI)■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

A multiple serial interface provides the interface for the links between a BSSC cabinet and othernetwork entities in the BSS, BSC to BTS, and BSC to RXCDR. An MSI can interface only E1 links.

Planning considerations

The following factors should be considered when planning the transcoder complement:

• Each MSI can interface two E1 links.

NOTEAn 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 connectedto 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 theE1 link carrying the OML link to the OMC-R. These E1 links do not require to go directly to theOMC-R, they can go to another network element for concentration. With the introduction of the96 MSI feature, the MSI with OML can be configured with priority in the database to make surethat 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 takeninto account. There are two connected modes. In the first connection mode, the E1 links goto the MSC through the RXCDR. The impact of this mode of connection on the RXCDR can befound in Chapter 7 RXCDR planning steps and rules. In the second connection mode, the E1links go to the MSC directly. Both the modes impact E1 planning in BSC.

6-70 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning MSI planning actions

MSI planning actions

If local transcoding is used then the NBSC-RXCDR element in the following equations can beignored, otherwise refer to Chapter 7 RXCDR planning steps and rules for the determination ofthe NBSCRXCDR element.

With E1 links

Determine the number of MSIs required.

Without LCS:

NMSI =(∑NBSC−BTS +NBSC−RXCDR +NGDS−TRAU +NGSL−E1)

2

With LCS for BSS-based LCS architecture:

NMSI =(∑NBSC−BTS +NBSC−RXCDR +NBSC−SMLC +NGDS−TRAU +NGSL−E1)

2

NOTEThe upper limit of the E1 backhaul per BSC is 96*2=192, as up to 96 MSI boards canbe hosted by BSC. When the planned E1 cables per BSC exceed the limit, use thefollowing methods to reduce the required MSI boards:

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 betweenBSC and PCU.

68P02900W21-T 6-71

Jul 2010

Packet Subrate Interface (PSI2) Chapter 6: BSC planning steps and rules

Packet Subrate Interface (PSI2)■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The PSI2 card is used to connect BSC to PCU with Ethernet connectivity. The physical interfacefrom the card is a 1000 BASE-T over four pairs of copper wire. This same connection can beoperated in 100 BASE-TX mode of operation as well. The standard backplane connections canbe used, with a PBIB or PT43 board replacing the BIB or T43 board, respectively, at the top ofthe cabinet. The new interconnect board (PBIB or PT43) at the top of the BSC cabinet allows asingle 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 anEthernet 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 areused 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_Blocksplanning in KSW/DSW2 planning actions on page 6-75.

• Redundancy for PSI2 depends on the provisioning of redundant Ethernet links connectedwith PXP in PCU.

PSI2 planning actions

The number of PSI2 cards required is dependent on planning of the PXP boards in PCU (refer toChapter 8 BSS planning for GPRS/EGPRS).

6-72 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 thenumber of ports (enhanced capacity mode), as well as extended subrate switch capability of8 kbps (extended subrate switching capability). Use of 8 kbps subrate switching can reducebackhaul costs when used in conjunction with the AMR or GSM half rate feature.

Planning considerations

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 kbpsports or 4096 x 16 kbps ports, which can be expanded by adding up to three additionalKSW/DSW2s, giving a total switching capacity of 4096 x 64 kbps ports or 16384 x 16kbps ports.

• When operating in enhanced capacity mode, the DSW2 has a capacity of 2048 x 64 kbpsports or 8192 x 16 kbps ports, which can be expanded by adding up to three additionalDSW2s, 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 tothree 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, theDSW2 can further switch 16384 x 8 kbps ports which can be expanded by adding up tothree additional DSW2s, giving a total switching capacity of 65536 x 8 kbits/s ports.

• Eight (64 kbps) timeslots per KSW/DSW2 are reserved by the system for test purposes andare not available for use.

• A mix of KSWs and DSW2s needs that the DSW2s are not operated in the enhancedcapacity 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

Planning considerations Chapter 6: BSC planning steps and rules

• Verify that each KSW or DSW2 that is not in enhanced capacity mode uses no more than1016 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.

NOTEWith gproc_slots = 24, a value of 32 should be used for calculating TDMtimeslot 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).

NOTEThe tdm_ts_blocks is a database parameter used to set the number ofTDM timeslot blocks for each PSI2. One block contains 32 TDM timeslots.When the PXP (the partner of PSI2) works in prp_fanout_mode 1 (referto PXP planning considerations on page 8-28 in Chapter 8 BSS planningfor GPRS/EGPRS), 10 blocks are recommended. When the PXP works inprp_fanout_mode2, 5 blocks are recommended. In situations where thetotal 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_blocksto the recommended value), it is recommended that the tdm_ts_blocksnumber for PSI2 is set to the highest value possible within the constraints.However, in such situations TDM resource limitations can reduce thenumber of supportable PDCHs. The general rule for tdm_ts_blocksplanning is to provide each PDCH with one TDM timeslot regardless ofwhat type it is, 16 k, 32 k, or 64 k. In addition, one TDM timeslot isprovided for each GSL TS on the PSI2/PXP connectivity.

• There is one additional consideration with regard to timeslot usage, which is related to thetimeslot allocation policy employed. Timeslots are grouped in 32 blocks of 32 timeslotseach. Generally, groups of 16 (the first 16 or last 16) can be allocated within a block.

NOTEThe GDP2 is a special case, as it requires 24 timeslots, a group of 16 and another8 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 GDP2sthen 8 timeslots are unusable.

• The number of TDM timeslots is given by:

N = (G ∗ n) + (RGDPXCDR ∗ 16) + (REGDP ∗ 96) + (RGDP2 ∗ 24) + (M ∗ 64) + (RPSI2 ∗ t)

6-74 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning KSW/DSW2 planning actions

Where: Is:

N the number of timeslots required.

G the number of GPROCs.

n 16 or 32 (depending on the value of the gproc_slots databaseparameter)

RGDPXCDR the number of GDP/XCDRs.

REGDP the number of EGDPs.

RGDP2 the number of GDP2s.

M the number of MSI.

RPSI2 the number of PSI2s

t 64 ~ 320 (depending on the value of the tdm_ts_blocksdatabase parameter, t = tdm_ts_blocks * 32).

Any BSC site, which contains a DRIM, has 352 timeslots allocated to DRIMs, irrespective of thenumber of DRIMs equipped.

KSW/DSW2 planning actions

Calculate the minimum number of KSWs/DSW2s required per BSC:

• Use this formula when enhanced capacity mode is not enabled:

N = ((G ∗ n) + (RGDPXCDR ∗ 16) + (REGDP ∗ 96) + (RGDP2 ∗ 24) + (M ∗ 64) + (RPSI2 ∗ t)) /1016

• Use this formula when enhanced capacity mode is enabled:

N = ((G ∗ n) + (RGDPXCDR ∗ 16) + (REGDP ∗ 96) + (RGDP2 ∗ 24) + (M ∗ 64) + (RPSI2 ∗ t)) /2040

NOTEIn the above two formulae, if the number of required GDP2s is odd, additional 8timeslots need to be added.

68P02900W21-T 6-75

Jul 2010

KSW/DSW2 planning actions Chapter 6: BSC planning steps and rules

Where: Is:

N the number of KSWs/DSW2s required.

G the number of GPROCs.

n 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 GDP2s.

M the number of MSIs.

RPSI2 the number of GDP2s.

t 64 ~ 320 (depending on the value of the tdm_ts_blocks databaseparameter, t = tdm_ts_blocks * 32)

Each KSW/DSW2 has to serve the boards in its shelf and the boards of any extension shelfconnected to its shelf by its TDM highway of 1016 available timeslots (or 2040 when operatingin enhanced capacity mode).

In case of multiple expansion shelves, the TDM highways of each shelf do not merge into acommon unique TDM highway across all shelves, that is, a KSW/DSW2 in one shelf cannot serveboards in other expansion shelves.

For example, in the case of a BSC consisting of two shelves each having 32 unused timeslots perKSW/DSW2 free, an additional MSI board CANNOT be added even if an MSI slot is free at eachshelf, (but one GPROC per shelf can be added if one GPROC slot per shelf is free).

6-76 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSU shelves

BSU shelves■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The number of BSU shelves is normally a function of the number of GPROCs, MSIs, andXCDR/GDP/EGDP/GDP2s required.

Planning considerations

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 numberof slots available, an additional BSU shelf is required.

• Each expansion shelf is allocated to a single KSW/DSW2 and extension shelves aredifferentiated by the presence of the KSW/DSW2. Extension shelves are those, which donot contain a primary KSW/DSW2. Shelves containing a KSW/DSW2 are called expansionshelves.

• 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 timeslotsto that of the additional KSW/DSW2.

• The following capacities depend on timeslot usage. Refer to Kiloport switch (KSW) anddouble kiloport switch (DSW2) on page 6-73 for information on how to determine timeslotusage.

A BSU shelf can support up to 12 MSI boards.

A BSU shelf can support up to six XCDR/GDP/EGDP/GDP2s (reducing the numberof 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 BSPslots. XCDRs must be replaced with GDP/GDP2s.

BSU shelf planning actions

Determine the number of BSU shelves required.

68P02900W21-T 6-77

Jul 2010

BSU shelf planning actions Chapter 6: BSC planning steps and rules

The number of BSU shelves required is the highest value result of the following threecalculations (fractional values should be rounded up to the next integer value):

BS =G

8

BS =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.

G the number of GPROCs.

M the number of MSIs.

R the number of XCDR/GDP/EGDP/GDP2s (see NOTE).

P 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 procedureis like Planning considerations (the KSW/DSW2 timeslot validation prevents a shelf fromexceeding the timeslot limit) and is repeated here for completeness.

(G ∗ n) + (RGDPXCDR ∗ 16) + (REGDP ∗ 96) + (RGDP2 ∗ 24) + (M ∗ 64) + (RPSI2 ∗ t) ≤ 1016

Where: Is:

G the number of GPROCs in the shelf.

n 16, 24, or 32 (depending on the value of the gproc_slots databaseparameter).

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 the number of MSIs in the shelf.

RPSI2 the number of PSI2s

t 64~320 (depending on the value of the tdm_ts_blocks databaseparameter, t = tdm_ts_blocks *32).

6-78 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSU shelf planning actions

When enhanced capacity mode is not enabled (non-extension shelf):

(G ∗ n) + (RGDPXCDR ∗ 16) + (REGDP ∗ 96) + (RGDP2 ∗ 24) + (M ∗ 64) + (RPSI2 ∗ t) ≤ 1016

When enhanced capacity mode is enabled (extension shelf):

(G ∗ n) + (RGDPXCDR ∗ 16) + (REGDP ∗ 96) + (RGDP2 ∗ 24) + (M ∗ 64) + (RPSI2 ∗ t) ≤ 1024

If the result of the equation exceeds the value quoted, the configuration of MSIs, GPROCs, andGDPs and PSI2s can be adjusted, or an additional shelf or shelves is required.

NOTE

• The number of shelves should be larger if an attempt to reduce the number ofKSWs/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 andeach of up to 4 BSU shelves can support 12 MSIs, adding one extension shelfdoes not provide additional capacity for the extra 8 MSIs.

• With {22169}: The BSC can support 96 MSIs with 12 MSIs in each of the8 cages.

68P02900W21-T 6-79

Jul 2010

Kiloport switch extender (KSWX) and double kiloport switch extender (DSWX) Chapter 6: BSC planning steps and rules

Kiloport switch extender (KSWX) and double kiloportswitch extender (DSWX)

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The KSWX extends the TDM highway of a BSU to other BSUs and supplies clock signals to allshelves in multi-shelf configurations. The KSWX is required whenever a network elementexpands beyond a single shelf. The DSWX performs the same function as the KSWX when usedin 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).

Planning considerations

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 orextension is not required).

• For redundancy, duplicate all KSWX/DSWX boards (needs redundant KSW/DSW2). In mixedconfigurations (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 siteswith multiple KSWs/DSW2s.

KSWX/DSWXR (Remote) is required in shelves with KSWs/DSW2s to drive the TDMhighway in shelves that do not have KSWs/DSW2s.

KSWX/DSWXL (Local) are used in shelves that have KSWs/DSW2s to drive the clockbus in that shelf and in shelves that do not have KSWs/DSW2s to drive both the localTDM 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).

NOTEThe fiber optic cables, which are used to extend/expand the TDM highway fromone BSU to another BSU, must be of the same length to limit the risk of TDMhighway extension/expansion errors.

6-80 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning KSWX/DSWX planning actions

KSWX/DSWX planning actions

The number of KSWXs/DSWXs required is the sum of the KSWX/DSWXE, KSWX/DSWXL andKSWX/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.

K 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 1 2 3 4

0 0 4 9 16

1 3 6 11 18

2 5 8 13 20

3 7 10 15 22

4 9 12 17 24

Table 6-18 KSWX/DSWX (redundant)

KSW/DSW2 (redundant)

Extension shelves 1 2 3 4

0 0 8 18 32

1 6 12 22 36

2 10 16 26 40

3 14 20 30 44

4 18 24 34 48

68P02900W21-T 6-81

Jul 2010

Generic clock (GCLK) Chapter 6: BSC planning steps and rules

Generic clock (GCLK)■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The generic clock (GCLK) generates all the timing reference signals required by a BSU.

Planning considerations

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

System Information: BSS Equipment Planning Clock extender (CLKX)

Clock extender (CLKX)■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

A clock extender (CLKX) board provides expansion of GCLK timing to more than one BSU.

Planning considerations

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 expandingbeyond 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).

• 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).

• The maximum number of CLKX slots per shelf is six. (The CLKX uses six of the redundantKSWX slots.)

• With a CLKX, a KSWX/DSWXL is required to distribute the clocks in the master and each ofthe 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 othershelves and itself at a site must be of the same length to maintain site synchronizationintegrity.

68P02900W21-T 6-83

Jul 2010

CLKX planning actions Chapter 6: BSC planning steps and rules

CLKX planning actions

Determine the number of CLKXs required.

NCLKX = ROUNDUP

(E

6

)∗ (1 +RF )

Where: Is:

NCLKX the number of CLKXs required.

ROUND UP rounding up to the next integer.

E the number of expansion/extension shelves.

RF redundancy factor (1 if redundancy is required (recommended), 0 for noredundancy).

6-84 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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.

Planning considerations

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.

NLANX = NBSU ∗ (1 +RF )

BSU ≤ 14

Where: Is:

NLANX the number of LANXs required.

NBSU the number of BSU shelves.

RF redundancy factor (1 if redundancy is required (recommended), 0for no redundancy).

68P02900W21-T 6-85

Jul 2010

Parallel interface extender (PIX) Chapter 6: BSC planning steps and rules

Parallel interface extender (PIX)■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The PIX board provides eight inputs and four outputs for site alarms.

Planning considerations

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.

PIX ≤ 2 ∗ number of BSUs

or

PIX ≤ 8

6-86 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 impedancematching for E1 links. The PBIB and PT43 provide an Ethernet link in addition to impedancematching for E1links.

Planning considerations

The following factors should be considered when planning the line interface complement:

• Use a BIB or PBIB to match a balanced 120-ohm (E1 2.048 Mbps) or balanced 110-ohm 3V (peak pulse) line.

• Use a T43 Board (T43) or PT43 board to match a single ended unbalanced 75 ohm (E12.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 BSCcabinet 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 onone 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.

NOTEA BSSC3 cabinet can have up to seven (P)BIBs or (P)T43s per shelf mounted, butin the BSU configuration this additional connectivity is not needed.

68P02900W21-T 6-87

Jul 2010

(P)BIB/(P)T43 planning actions Chapter 6: BSC planning steps and rules

(P)BIB/(P)T43 planning actions

The following planning actions are required:

• 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.

6-88 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Digital shelf power supply

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 dcpower source.

NOTEIn this manual, BSSC is a generic term that means both BSSC2 and/or BSSC3.

Planning considerations

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 Chapter 6: BSC planning steps and rules

Non Volatile Memory (NVM) board■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The optional non volatile memory board provides the BSC with an improved recovery facilityfollowing a total power loss. With the NVM board installed, data is retrieved from the NVMboard rather than from the OMC-R during recovery from a total power loss.

Planning considerations

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 theOMC-R and downloaded to the BSC.

NVM planning actions

The NVM board is optional.

6-90 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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.

• 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 behosted by BSC. When the planned E1 cables per BSC exceed the limit, use the followingmethods 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 BSCand PCU.

• The number of XCDR/GDP/EGDP/GDP2s ≤ 6 * number of shelves.

• The number of PSI2s ≤4 per shelf and 12 per site.

NOTEFor 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 Chapter 6: BSC planning steps and rules

• LCFs ≤38

• Erlangs ≤2250

NOTE

• With the Enhanced BSC feature enabled, up to 140 BTS sites, 512 carriersand 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 and5900 Erlangs are supported, otherwise the upper limits are 750 carriersand 4500 Erlangs.

• If necessary, extra BSU shelves may need to be added. Each BSSC cabinetsupports two BSU shelves.

6-92 68P02900W21-T

Jul 2010

Chapter

7

RXCDR planning steps and rules■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

■

■

This chapter provides an overview of the manual. It also provides information on variouselements of BSS, BSS planning methodology, and BSS system architecture, components, andfeatures.

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 7-1

Jul 2010

Overview of remote transcoder planning Chapter 7: RXCDR planning steps and rules

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 numberof slots required at the RXCDR.

NOTEEach EGDP comprises two GDP cards.

• The use of E1 links.

• The use of balanced or unbalanced E1.

Outline of planning steps

Follow Procedure 7-1 to plan an RXCDR.

Procedure 7-1 Planning an RXCDR

1 Plan the number of links between the XCDR and BSC sites by referring to thesection Overview of remote transcoder planning on page 7-2.

2 Plan the number of E1 links between the RXCDR and MSC sites by referringto the section RXCDR to MSC links on page 7-8.

3 Plan the number of GPROCs required by referring to the section Genericprocessor (GPROC) on page 7-9.

4 Plan the number of XCDR/GDP/EGDP/GDP2s required by referring to thesection Transcoding on page 7-10.

5 Plan the number of MSIs required by referring to the section Multiple serialinterface (MSI) on page 7-17.

Continued

7-2 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Outline of planning steps

Procedure 7-1 Planning an RXCDR (Continued)

6 Plan the number of KSWs/DSW2s and timeslots required by referring to thesection Kiloport switch (KSW) and double kiloport switch (DSW2) on page7-19.

7 Plan the number of RXU shelves by referring to the section RXU shelveson page 7-22.

8 Plan the number of KSWXs/DSWXs required by referring to the sectionKiloport switch extender (KSWX) and double kiloport switch extender (DSWX)on page 7-25.

9 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 interfaceextender (PIX) Parallel interface extender (PIX) on page 7-32.

13 Plan the number of BIB or T43s required by referring to the section Lineinterfaces (BIB, T43) on page 7-33.

14 Plan the power requirements by referring to the section Digital shelf powersupply on page 7-35.

15 Decide whether an NVM board is required by referring to the section NonVolatile Memory (NVM) board on page 7-36.

16 Verify the planning process by referring to the section Verify the number ofRXU shelves and BSSC cabinets on page 7-37.

68P02900W21-T 7-3

Jul 2010

RXCDR system capacity Chapter 7: RXCDR planning steps and rules

RXCDR system capacity■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

System capacity summary

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

GPROCs per shelf 2 2 2

CIC 2400a 2400ab 2400ab

OMLs 1 1 1

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

System Information: BSS Equipment Planning 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 thefollowing 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 lossof 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 isconstrained 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 bewasted. Larger BSCs should not be connected to only one RXCDR. Each BSC should connectto four RXCDRs. System size, capacity, and cost are the major influences on the selectedconfiguration.

With the introduction of advanced transcoding capabilities (that is, AMR), care should betaken when distributing the functions across multiple RXCDRs. For optimum redundancy,each RXCDR should have an appropriate mix of transcoder capability. For example, in a fourBSC, four RXCDR configuration where all are interconnected and there are a limited numberof transcoder cards capable of AMR (for example, GDP2s), optimally the cards are distributedequally among the RXCDRs.

68P02900W21-T 7-5

Jul 2010

RXCDR to BSC links Chapter 7: RXCDR planning steps and rules

RXCDR to BSC links■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

Refer to Figure 6-1 for the RXCDR to BSC links. The number of E1 links between the RXCDRand 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 onequarter of the number of links between the RXCDR and the MSC when 16 kbps backhaul isused. When (AMR or GSM) half rate is in use, 8 kbps subrate switching is available and (forAMR only) the 7.95 kbps half rate codec mode is not included in the Half Rate Active CodecSet, the reduction factor for the half rate calls becomes eight.

NOTEIn most configurations, half rate is likely to be used only a part of the time, thusyielding 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 ratecodec mode is not included in the Half Rate Active Codec Set, and 8 kbps subrate switchingis in use.

If a percentage of the active calls is assumed to be half rate, the efficiency can be increased byreducing the number of terrestrial resources between the BSC and RXCDR. This is possible onlyif the BSC can dynamically allocate a timeslot to a CIC. This dynamic allocation is performedacross a trunked interface between the BSC and a remote transcoder (RXCDR). This interface iscalled 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 RXCDRand 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 acombination of factors, which includes (AMR or GSM) capable mobile penetration, whetherforced half rate usage is enabled and/or tied in with congestion, and MSC preferences. It isrecommended 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 beaccounted. There are two connected modes. One is the E1 links go to MSC by RXCDR. Anotheris the E1 links go to MSC directly. For the first connected mode, MSIs are required to terminateHSP MTL at RXCDR (A HSP MTL from MSC is terminated at one port of an MSI and nailed toBSC from another MSI port) whereas for the second connected mode (E1 links go from BSC toMSC directly), there is no impact on RXCDR planning.

NOTE4 x 64 kbps circuits/RTF for a (AMR or GSM) HR RTF and 8 kbps switching is notprovisioned, or, (for AMR only) the 7.95 kbps half rate codec mode is included inthe Half Rate Active Codec Set.

7-6 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning E1 interconnect planning actions

E1 interconnect planning actions

Determine the number of E1 links required. If HSP MTLs are deployed and they pass throughRXCDR:

NBSC−RXCDR = C2M + {C64k +X +B64 +O ∗+ [T ∗ (1− PHR) +B16] /4 + (T ∗ PHR) /8} /31

Where: Is:

NBSC-RXCDR 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 number of OML links (X.25 control links to the OMC-R) through theRXCDR.

B64 number of 64 kbps XBL links.

T 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.

O number of OPL links.

NOTEPHR is zero if Enhanced Auto Connect mode is not in use.

The OPL (Optimization Link) is used to carry measurement reports out of the BSCto IOS (Intelligent optimization Service). In normal operation, the OPL is equippedup on a spare TS on the E1 link from BSC to the RXCDR. From there it would benailed (along with other BSCs OPL links connected to the RXCDR) to another E1link 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 halfrate) trunks without a signaling link.

NOTEThe half rate numbers are only possible with all calls using half rate. HSP MTL and64 kbps MTL cannot be supported simultaneously.

Redundant E1 links carrying extra trunks can be added. If HSP MTLs go to MSC directly (notthrough RXCDR), C2M is 0 in the equation.

68P02900W21-T 7-7

Jul 2010

RXCDR to MSC links Chapter 7: RXCDR planning steps and rules

RXCDR to MSC links■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The number of E1 links between the RXCDR and the MSC is the number required to supportthe A Interface from the RXCDR to the MSC.

E1 interconnect planning actions

Determine the number of E1 links required.

The minimum number of E1 links required for the A Interface is the greater of the two followingcalculations (fractional values should be rounded up to the next integer value):

NRXCDR−MSC = C2M + T/30

NRXCDR−MSC = C2M + (C64k +X + T ) /31

Where: Is:

NRXCDR-MSC minimum number of E1 links required.

C64k number of 64 kbps C7 signaling links to the MSC.

C2M number of HSP MTL links.

X number of OML links (X.25 control links to the OMC-R) through theMSC.

T number of trunks between the MSC and the BSC (Refer to Figure 7-1).

NOTE

• When HSP MTL feature is used and the E1 links go to MSC by RXCDR, MSIsare required to terminate HSP MTL at RXCDR. If the HSP MTLs go from theBSC to the MSC directly, there is no impact on RXCDR planning and C2M is 0in the equation.

• HSP MTL and 64 kbps MTL cannot be supported simultaneously.

7-8 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Generic processor (GPROC)

Generic processor (GPROC)■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

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 controlprocessor. The GPROC3/GPROC3-2 is a high performance direct replacement for GPROC2s.This allows for any combination of GPROC types to be installed.

Planning considerations

The following factors should be considered when planning the GPROC complement at theRXCDR:

• 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

NOTEFor RXCDR, both GPROC2 and GPROC3s/GPROC3-2s can be in the BSP slots.

68P02900W21-T 7-9

Jul 2010

Transcoding Chapter 7: RXCDR planning steps and rules

Transcoding■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

Transcoders (XCDR/GDP/EGDP/GDP2s) provide the interface for the E1 links between theMSC and the BSC.

The XCDR/GDP/EGDP/GDP2s perform the transcoding/rate adaptation function, whichcompresses 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 codecmode is not included in the Half Rate Active Codec Set (AMR)] the reduction factor for the halfrate calls becomes eight.

NOTEIn most configurations, half rate is used only a part of the time, thus yielding areduction 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 linksbetween the RXCDR and the MSC.

The GDP2 can process 60 channels of FR, EFR, AMR, GSM HR, and Phase 2 data services, andis capable of terminating two E1 links from the MSC. It can also function as a replacement forthe GDP. Within the RXCDR, enhanced capacity mode must be enabled to access the secondE1 when GDP2s are used.

An EGDP is a new configuration of the GDP board, which is used to support AMR. Due to theadditional transcoding requirements of AMR, each of the 15 DSPs on the GDP board is onlycapable 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 usingthe same E1 span line to the MSC, EGDPs are equipped as pairs, each providing half of thetranscoding resources.

NOTEThis results in an overall reduction in transcoding shelf capacity, which is equivalentto 30 channels per GDP pair.

Use of an EGDP is practical only when used with AMR. The EGDP does not support GSM halfrate. The EGDP can also terminate one Ater E1 link, thus reducing the number of MSI boardsrequired (Refer to EGDP provisioning on page 7-13). The GDP2 can function as GDP and henceit can replace one or both the GDPs in the EGDP configuration. This is not an optimal use of theGDP2 and occurs in emergency situations (for example, board replacement). As a result, it isnot considered in the planning procedures.

7-10 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Introduction

The MSC recommends a particular codec type or types to be used on a call by call basis. Itsends the BSC a preference-ordered list, based on factors such as MS capabilities and userconfiguration. When the MSC is capable of selecting the MSC-RXCDR trunk (CIC) based uponthe preferred codec type, a mix of transcoding equipment can be used. If this circuit poolingcapability 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, GDP2sor 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 poolingis present at the MSC), there must be sufficient GDP2 and EGDP equipment available to handlethe expected AMR traffic. The proportion of AMR-capable transcoding circuits versus non-AMR-capable transcoding circuits should not be less than the proportion of AMR-capable MSsversus non -AMR-capable MSs. A safety factor of no less than 20% is recommended (20% allowsfor some variation in the actual number and allows for a period of growth in AMR-capable MSpenetration before having to add more AMR transcoding ability). Each AMR half rate callneeds one (AMR) transcoder circuit. Lack of an available AMR circuit could cause a call to bedowngraded to another codec type or possibly blocked.

When GSM half rate is employed and a mix of XCDRs and GDP/GDP2s are present, a similarsituation 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 particularvoice channel, circuit pooling is rendered ineffective, as there is no way to predict whichmobiles need GSM half rate. It becomes necessary to update all transcoding to support GSMHR to guarantee that GSM half rate can be used when required. Without this upgrade, callson 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 ismost effective when selecting AMR CICs (EGDP, GDP2) for AMR capable mobiles, and theremaining CICs for non- AMR capable mobiles. Ideally, for AMR capable mobiles the MSC wouldfirst select a CIC attached to an EGDP, followed by one attached to a GDP2. For a non-AMRcapable mobile the MSC would first select a CIC attached to a GDP, followed by one attachedto a GDP2. The selection of the proper CIC (circuit pool) is dependent upon the capability ofthe connected MSC.

• Each trunk needs a quarter (1/4th) (or an eighth (1/8th) in some cases for AMR half rate asdescribed ) 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 theoption 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 Chapter 7: RXCDR planning steps and rules

Figure 7-1 Sub-multiplexing and speech transcoding at the RXCDR

RXCDR

ONE RF CARRIER

MSI/MSI2

HIISC

MSI/MSI2

KSW/DSW2

XCDR/GDP/GDP2

MSC

8 x 22.8 kbit/s TIMESLOTS OR16 x 11.4 kbit/s TIMESLOTSTHE 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.

64 kbit/s 4 OR 8 TCHs

THE KSW (DSW2) SUBRATE SWITCHES 16 kbit/s (8 kbit/s) TIMESLOTS.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.

64 kbit/s A-LAW TRUNKS

MSI/MSI2

CTU2

NIU

4 TO 8 TRUNKS PER64 kbit/s CIRCUIT

KSW/DSW2

BSC Horizon II macro BTS

ti-GSM-Sub_multiplexing_and_speech_transcoding_at_the_RXCDR-00130-ai-sw

NOTEIn Figure 7-1, the CTU2 operates in single density mode (one carrier), although itcan 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/GDP2complement:

• 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 capableof terminating one E1 link from the MSC.

• An EGDP consists of a pair of GDP cards, a primary and a secondary. Each EGDP canprocess 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.

7-12 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning EGDP provisioning

• The secondary GDP of an EGDP may terminate an E1 interface to the BSC. Refer to EGDPprovisioning on page 7-13.

• The GDP2 can process 60 channels of FR, EFR, AMR (FR and HR), GSM HR, and Phase 2data services and is capable of terminating two E1 links from the MSC. It can also functionas a replacement for the GDP.

• The GDP2 is used to terminate 2 E1s (that is, 60 voice channels) only in the RXU3 shelfand BSSC3 cabinet (enhanced capacity mode must be enabled to access the second E1when GDP2s are used). The current RXU shelf has only one E1 per transcoder slot, and thecurrent BSSC2 cabinet does not have space for additional line interface boards. The GDP2supports 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 theOMC-R. The master MSI slot can contain an XCDR/GDP/EGDP (either the primary or thesecondary) /GDP2, if the OML goes through the MSC.

• The A Interface must terminate on the XCDR/GDP/EGDP (either the primary or thesecondary) /GDP2.

• Slot 24 (XCDR 0) in the RXU shelf 0 (master) is lost if an optional NVM board is required.

NOTEAn 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 reducesthe need for MSIs and makes more efficient use of the available TDM timeslots.

NOTEThe secondary GDP has one E1 interface (instead of two for an MSI), which must betaken into account in site (MSI) planning.

Figure 7-2 and Figure 7-3 show the EGDP used in configurations with and without the additionalE1 termination in use, respectively.

68P02900W21-T 7-13

Jul 2010

EGDP provisioning Chapter 7: RXCDR planning steps and rules

Figure 7-2 EGDP configuration with the additional E1 termination in use

ti-GSM-EGDP_configuration_with_the_additional_E1_termination_in_use-00131-ai-sw

E1 Spamto MSC

PrimaryGDP

TDM Bus

15DSPs

15DSPs Secondary

GDP

E1 Spanfrom an RXCDRto a BSC or froma BSC to a BTS

7-14 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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)

Subratechannelscarried ontothe TDM bus(TRAU framesusing 16Kbps)

RXCDR: Staticor dynamic callconnectionsbetween CICsfor GDP pairand afterchannels(TRAU framesusing 16Kbps)

E1 Spanfrom an RXCDRto a BSC or froma BSC to a BTS

MSI

TDM Bus

PrimaryGDP

15DSPs

E1 Spanto MSC

SecondaryGDP

15DSPs

BSC: Dynamic callconnections betweenCICs for a GDP pairand Abis channels(TRAU framesusing 16Kbps)

ti-GSM-EGDP_configuration_without_the_additional_E1_termination_in_use-00132-ai-sw

Planning actions for transcoding at the RXCDR

The number of transcoders at the RXCDR is proportional to the number of E1 links betweenthe RXCDR and the MSC.

Using E1 links

Each XCDR/GDP/EGDP can terminate one E1 link. Each GDP2 can terminate two E1 links [whenused in an RXU3 shelf with enhanced capacity mode enabled (when GDP2s are used)].

Plan the equipment according to the following formula:

XGE + 2 ∗G2 = NRXCDR−MSC

68P02900W21-T 7-15

Jul 2010

Planning actions for transcoding at the RXCDR Chapter 7: RXCDR planning steps and rules

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 RXCDRto MSC links on page 7-8).

Verify that the number of AMR circuits is sufficient to handle the expected AMR traffic. Ifnecessary, adjust the number of EGDP/GDP2s. Use the following formula to determine thepercentage of AMR-capable circuits:

%AMR Circuits =(GDP2 ∗ 60 + EGDP2 ∗ 30)

(GDP2 ∗ 60 + EGDP2 ∗ 30 +XCDR ∗ 30 +GDP ∗ 30)∗ 100

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 requiredto terminate HSP MTLs between RXCDR and MSC (refer to the section RXCDRto BSC links on page 7-6).

XGE + 2 ∗G2 = NRXCDR−MSC − C2M

• In the equation, C2M is the number of HSP MTLs.

7-16 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Multiple serial interface (MSI)

Multiple serial interface (MSI)■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

A multiple serial interface provides the interface for the links between an RXCDR site and othernetwork entities, RXCDR to OMC-R and RXCDR to BSC.

Planning considerations

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 connectedto the site.

• When one remote transcoder site supports multiple BSCs, each BSC needs its own E1interface 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 forHSP 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 managementcommunications. Refer to Service Manual: BSC/RXCDR (68P02901W38) for furtherdetails.

• The master MSI slots should always be populated to enable communication with theOMC-R.

If the OML links go directly to the MSC, the master slot should be filled with anXCDR/GDP/EGDP (primary or secondary) /GDP2, else the slot should be filled with anMSI that terminates the E1 link carrying the OML link to the OMC-R. These E1 linksshould not require to go directly to the OMC-R, they can go to another network elementfor concentration.

68P02900W21-T 7-17

Jul 2010

MSI planning actions Chapter 7: RXCDR planning steps and rules

MSI planning actions

With E1 links

Use the following equation to determine the number of MSIs required:

NMSI = NBSC−RXCDR/2

Where: Is:

NMSI number of MSIs required.

NBSC-RXCDR number of E1 links required (as N calculated in RXCDR to BSC linkson page 7-6).

7-18 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 doublethe number of ports (enhanced capacity mode), as well as extended subrate switching capabilitydown to 8 kbps (extended subrate switching mode). Use of 8 kbps subrate switching can reducebackhaul costs when used with the AMR or GSM half rate feature.

Planning considerations

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 x64 kbps ports or 4096 x 16 kbps ports, which can be expanded by adding up to threeadditional KSW/DSW2s, giving a total switching capacity of 4096 x 64 kbps ports or 16384x 16 kbps ports.

• When operating in enhanced capacity mode, the DSW2 has a capacity of 2048 x 64 kbpsports or 8192 x 16 kbps ports, which can be expanded by adding up to three additionalDSW2s, 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 tothree 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, theDSW2 can further switch 16384 x 8 kbps ports which can be expanded by adding up tothree additional DSW2s, giving a total switching capacity of 65536 x 8 kbits/s ports.

• Eight (64 kbps) timeslots per KSW/DSW2 are reserved by the system for test purposes andare not available for use.

• A mix of KSWs and DSW2s needs that the DSW2s are not operated in the enhancedcapacity 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 1016ports, or that each DSW2 in enhanced capacity mode uses no more than 2040 ports (8ports 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

KSW/DSW2 planning actions Chapter 7: RXCDR planning steps and rules

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) + (RGDPXCDR ∗ 16) + (REGPD ∗ 96) + (REDP2 ∗ 24) + (M ∗ 64)

Where: Is:

N number of timeslots required.

G number of GPROCs.

n 16 or 32 (depending on the value of the gproc_slots database parameter).

RGDPXCDR number of GDPs/XCDRs.

REGDP number of EGDPs.

REDP2 number of GDP2s.

M number of MSIs.

KSW/DSW2 planning actions

Use the following formula to determine the number of KSWs or DSW2s required when enhancedcapacity mode is not enabled:

N = [(G ∗ n) + (RGDPXCDR ∗ 16) + (REGPD ∗ 96) + (REDP2 ∗ 24) + (M ∗ 64)] /1016

Use this formula when enhanced capacity mode is enabled:

N = [(G ∗ n) + (RGDPXCDR ∗ 16) + (REGPD ∗ 96) + (REDP2 ∗ 24) + (M ∗ 64)] /2040

Where: Is:

N number of KSWs/DSW2s required.

G number of GPROCs.

n 16 or 32 (depending on the value of the gproc_slots database parameter).

RGDPXCDR number of GDPs/XCDRs.

REGDP number of EGDPs.

REDP2 number of GDP2s.

M number of MSIs

7-20 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning KSW/DSW2 planning actions

Each KSW/DSW2 has to serve the boards in its shelf along with the boards of any extension shelfconnected to its shelf by its TDM highway of 1016 available timeslots (or 2040 when operatingin enhanced capacity mode). In case of multiple expansion shelves, the TDM highways of eachshelf do not merge into a common unique TDM highway across all shelves, that is, a KSW/DSW2in 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 timeslotsper KSW/DSW2 free, an additional MSI board cannot be added even if an MSI slot is free ateach 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 Chapter 7: RXCDR planning steps and rules

RXU shelves■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The number of RXU shelves is a function of the number of MSIs and XCDR/GDP/EGDP/GDP2srequired.

Planning considerations

The following factors should be considered when planning the number of RXU shelves:

• Each expansion shelf is allocated to a single KSW/DSW2 and shelves are differentiatedby the presence of the KSW/DSW2. Extension shelves are those, which do not contain aprimary 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 timeslotsto that of the additional KSW/DSW2.

• The number of devices that can be served by a KSW/DSW2 is governed by the TDMtimeslot allocation required for each device. This is discussed previously in the KSW/DSW2planning considerations. The number and type of shelves can then be determined fromthe devices required.

• For example, two shelves, each equipped with three MSIs and 16 GDP/XCDRs, can beserved by a single KSW.

• If each shelf has five MSIs with 14 GDP/XCDRs, the KSW can serve only one shelf, andtwo KSWs are required.

• The existing RXU shelf has connectivity for up to five MSIs (2 x E1 connections). Theremaining 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 forXCDR/GDP/EGDP/GDP2s and MSIs.

• The GDP2 can be used to terminate 2 x E1s (that is, 60 voice channels), only in the RXU3shelf and BSSC3 cabinet (enhanced capacity mode must be enabled to access the secondE1 when GDP2s are used). The current RXU shelf has only one E1 per transcoder slot, andthe current BSSC2 cabinet does not have space for additional line interface boards. TheGDP2 supports only 30 channels when used in the RXU shelf and/or BSSC2 cabinet.

7-22 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning RXU shelf planning actions

• If all the XCDR slots in the RXU shelf 0 (master) are required, an NVM board cannot beinstalled.

NOTEAn XCDR card is incompatible with a GPROC3 in the BSP slots. XCDRs mustbe replaced with GDP/GDP2s.

RXU shelf planning actions

Use the appropriate formula (fractional values should be rounded up to the next integer) todetermine the number of RXU shelves required:

For the current generation RXU shelf:

RX = max ((M/5) + (R+NNVM ) /16)

For the new generation RXU3 shelf:

RX3 = (M +R+NNVM ) /19

Where: Is:

RX minimum number of RXU shelves required.

RX3 minimum number of RXU3 shelves required.

M number of MSIs.

R number of XCDR/GDP/EGDP/GDP2s.

NNVM number of optional NVM boards (0 or 1).

NOTEFor EGDPs, both the primary and the secondary must be counted.

The number of timeslots equipped to each shelf must be verified using the appropriate equationgiven.

68P02900W21-T 7-23

Jul 2010

Enhanced capacity mode is enabled (non-extension shelf) Chapter 7: RXCDR planning steps and rules

Enhanced capacity mode is not enabled

The verification procedure is like the KSW/DSW2 planning consideration.

(G ∗ n) + (RGDPXCDR ∗ 16) + (REGDP ∗ 96) + (RGDP2 ∗ 24) + (M ∗ 64) ≤ 1016

Where: Is:

G number of GPROCs in the shelf.

n 16 or 32 (depending on the value of the gproc_slots databaseparameter).

RGDPXCDR number of GDP/XCDRs in the shelf.

REGDP number of EGDPs in the shelf.

RGDP2 number of GDP2s in the shelf.

M number of MSIs in the shelf.

Enhanced capacity mode is enabled (non-extension shelf)

(G ∗ n) + (RGDPXCDR ∗ 16) + (REGDP ∗ 96) + (RGDP2 ∗ 24) + (M ∗ 64) ≤ 1016

Enhanced capacity mode is enabled (extension shelf)

(G ∗ n) + (RGDPXCDR ∗ 16) + (REGDP ∗ 96) + (RGDP2 ∗ 24) + (M ∗ 64) ≤ 1016

If the result of using the appropriate equation exceeds the value quoted, the configuration ofMSIs, GPROCs and GDPs can be adjusted, or an additional shelf or shelves are required.

7-24 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Kiloport switchextender (KSWX) and double kiloport switch extender (DSWX)

Kiloport switch extender (KSWX) and double kiloportswitch extender (DSWX)

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The KSWX extends the TDM highway of an RXU to other RXUs and supplies clock signals toall shelves in multi-shelf configurations. The KSWX is required whenever a network elementgrows beyond a single shelf. The DSWX performs the same function as the KSWX. It isnecessary when enhanced capacity mode (2048 timeslot capability) is used (but not in extendedsubrate switching mode).

Planning considerations

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 orextension 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 andvice-versa.

• KSWXs/DSWXs are used in three modes:

KSWX/DSWXE (Expansion) are required to interconnect the KSWs/DSW2s for siteswith multiple KSWs/DSW2s.

KSWX/DSWXR (Remote) are required in shelves with KSWs/DSW2s to drive the TDMhighway in shelves that do not have KSWs/DSW2s.

KSWX/DSWXL (Local) are used in shelves that have KSWs/DSW2s to drive the clockbus in that shelf and in shelves that do not have KSWs/DSW2s to drive both the localTDM 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 beused with like pairs, that is, DSWXs with DSWXs and KSWXs with KSWXs.

68P02900W21-T 7-25

Jul 2010

KSWX/DSWX planning actions Chapter 7: RXCDR planning steps and rules

• Operation in enhanced capacity mode needs the use of all DSWXs (and DSW2s).

NOTEThe fiber optic cables, which are used to extend/expand the TDM highway fromone RXU to another RXU, must be of the same length to limit the risk of TDMhighway extension/expansion errors.

KSWX/DSWX planning actions

The number of KSWXs/DSWXs required is the sum of the KSWX/DSWXE, KSWX/DSWXL andKSWX/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.

NKXL number of KSWX/DSWXL.

K the number of non-redundant KSWs/DSW2s.

SE the number of extension shelves.

7-26 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning KSWX/DSWX planning actions

For example:

Table 7-2 KSWX/DSWX (non-redundant)

Extension shelves KSW/DSW2 (non redundant)

1 2 3 4

0 0 4 9 16

1 3 6 11 18

2 5 8 13 20

3 7 10 15 22

4 9 12 17 24

Table 7-3 KSWX/DSWX (redundant)

Extension shelves KSW/DSW2 (redundant)

1 2 3 4

0 0 8 18 32

1 6 12 22 36

2 10 16 26 40

3 14 20 30 44

4 18 24 34 48

68P02900W21-T 7-27

Jul 2010

Generic clock (GCLK) Chapter 7: RXCDR planning steps and rules

Generic clock (GCLK)■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The generic clock (GCLK) generates all the timing reference signals required by an RXU.

Planning considerations

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

System Information: BSS Equipment Planning Clock extender (CLKX)

Clock extender (CLKX)■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

A clock extender (CLKX) board provides expansion of GCLK timing to more than one RXU.

Planning considerations

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 expansionbeyond 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 only allows 14 shelves in a single network element).

• The maximum number of CLKX slots per shelf is six.

NOTEThe 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 ofthe 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 othershelves and itself at a site, must be of the same length to maintain site synchronizationintegrity.

CLKX planning actions

Use the following formula to determine the number of CLKXs required:

NCLKX = ROUNDUP

(E

6

)∗ (1 +RF )

68P02900W21-T 7-29

Jul 2010

CLKX planning actions Chapter 7: RXCDR planning steps and rules

Where: Is:

NCLKX the number of CLKXs required.

ROUND UP rounding up to the next integer.

E number of shelves.

RF redundancy factor (1 if redundancy is required (recommended), 0for no redundancy).

7-30 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning LAN extender (LANX)

LAN extender (LANX)■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The LANX provides a LAN interconnection for communications among all GPROCs at a site.

Planning considerations

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:

NLANX = NRXU ∗ (1 +RF )

Where: Is:

NLANX number of LANXs required.

NRXU number of RXU shelves (RXU ≤ 14).

RF redundancy factor (1 is the recommended value if redundancy isrequired, 0 for no redundancy).

68P02900W21-T 7-31

Jul 2010

Parallel interface extender (PIX) Chapter 7: RXCDR planning steps and rules

Parallel interface extender (PIX)■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The PIX provides eight inputs and four outputs for site alarms.

Planning considerations

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

System Information: BSS Equipment Planning Line interfaces (BIB, T43)

Line interfaces (BIB, T43)■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The line interfaces, balanced-line interface board (BIB) and T43 board (T43), provide impedancematching for E1 links.

Planning considerations

The following factors should be considered when planning the line interface complement:

• Use a BIB to match a balanced 120 ohm (E1 2.048 Mbps) or balanced 110 ohm 3 V (peakpulse) 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 thecabinet, 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

• When fully equipping two RXU3 shelves with 38 E1s each, there are four unusedE1 links on two of the BIB/T43s.

• GDP2s must be used to utilize fully two E1s per slot.

68P02900W21-T 7-33

Jul 2010

BIB/T43 planning actions Chapter 7: RXCDR planning steps and rules

BIB/T43 planning actions

The following planning actions are required:

• 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.

7-34 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Digital shelf power supply

Digital shelf power supply■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

A BSSC cabinet can be supplied to operate from either a +27 V dc or -48/-60 V dc power source.

Planning considerations

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:

PSMS = 2 ∗Number of RXUs+RF ∗Number of RXUs

Where RF = is the Redundancy factor (recommended value is 1 if redundancy is required, 0for no redundancy).

68P02900W21-T 7-35

Jul 2010

Non Volatile Memory (NVM) board Chapter 7: RXCDR planning steps and rules

Non Volatile Memory (NVM) board■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The non volatile memory board provides the Remote Transcoder with an improved recoveryfacility following a total power loss. With the NVM board installed, data is retrieved from theNVM board rather than from the OMC-R during recovery from a total power loss.

Planning considerations

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 boardis already occupying that slot, the XCDR board and associated interface cabling can bemoved from slot 24 to the spare slot. If there are no spare slots, then remove the XCDRboard occupying slot 24 to accommodate the NVM board, with a subsequent reduction incapacity of the RXCDR.

• Load the appropriate software required to support the NVM board at the OMC-R anddownload it to the RXCDR.

NVM planning actions

The NVM board is optional.

7-36 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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.

• Each extension shelf supports extension of a single KSW/DSW2.

• The number of KSWXs/DSWXs, LANXs, CLKXs, and GPROCs is correct.

• The number of (MSIs + XCDRs + GDPs + 2*EGDPs + GDP2s + NVM) ≤ 19 * number ofshelves (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 7-37

Jul 2010

Verification Chapter 7: RXCDR planning steps and rules

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 isprovided:

• 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 8-1

Jul 2010

BSS planning for GPRS/EGPRS Chapter 8: BSS planning for GPRS/EGPRS

BSS planning for GPRS/EGPRS■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction to BSS planning for GPRS/EGPRS

The BSS planning process for GPRS/EGPRS involves adding additional BSS equipment andsoftware to the BSS, in addition to the PCU hardware and software. The extent of the additionalBSS equipment depends on the amount of traffic expected to be carried over the GPRS/EGPRSpart of the network and the coding schemes used on the air interface.

NOTEThis section contains planning for both GPRS and EGPRS and notes differenceswhere appropriate.

The section GPRS/EGPRS network traffic estimation and key concepts in Chapter 3 BSS cellplanning is intended to provide the network planner with the rules to determine the number ofGPRS/EGPRS timeslots that are to be provisioned at the BTS, later provisioned in PCU hardwarewith communication links.

The BSS planning process described here focuses on the provisioning of the PCU hardwarewithin the BSS. Refer to BSS-PCU hardware planning example for GPRS on page 8-72 andBSS-PCU hardware planning example for EGPRS on page 8-79. Its purpose is to unite theinformation 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 theBSS PCU to the GPRS SGSN. Motorola supports 3 Gb interface options (options A, B, andC), as shown in Figure 8-1.

8-2 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Feature compatibility

Figure 8-1 PCU to SGSN interface planning

BTS1 BTS2

MSC

RXCDR

BSC

OMC-R

SGSN

Gb Option A

Gb

Option B

Option C

Gb

For Option A and B

PCU

A interface

O tion Dp

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 inoption 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 Dprovides the Ethernet/IP connection between the PCU and the SGSN, for more information referto {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 isconnected directly to the BSC E1 interfaces and the BSC is configured to provide the E1 masterclock. If the PCU is connected to a GSN that does not have a master clock source, use someinterface equipment that has a master clock source (such as DACs). The Motorola BSC andRXCDR 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 optionB, respectively, additional equipment provisioning of these network elements are required tosupport the PCU E1 interfaces. This is in accordance with the provisioning rules for adding E1interfaces to the RXCDR and BSC network elements.

Feature compatibility

Alarms consolidation

No additional BSS, GPRS, or EGPRS network planning is required. PCU device alarms impactonly PCU functional unit severity, and not the cell functional unit severities. Therefore, theimpact is to the following PCU devices: DPROC and PCU System Processor (PSP).

68P02900W21-T 8-3

Jul 2010

Feature compatibility Chapter 8: BSS planning for GPRS/EGPRS

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 terrestrialbacking between the GPRS data traffic and the Circuit-Switched (CS) traffic. The terrestrialbacking between the BTS and BSC should have enough capacity to carry the radio timeslotsassigned to both GPRS and circuit switched traffic. If there is not enough capacity, becausethere are not enough physical channels, the BSC allocates the backing to CS first. Theremaining capacity is assigned to GPRS (reserved GPRS timeslots first, and then to switchableGPRS timeslots).

Any terrestrial backing resources not used by circuit-switched calls are allocated for switchableuse. However, circuit-switched calls can take resources away from the switchable pool whentraffic 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 sothat 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 (variablebandwidth in terms of a configurable rtf_ds0_count if VersaTRAU is unrestricted), respectivelyon backhaul, have been designed to work mutually exclusively with the BSC-BTS dynamicallocation 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 handlingnetwork capability for GSM voice and circuit data traffic. Additional loading on the BSSelements 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 andpacket data channels. Hence, the BSS need not be provisioned to simultaneously handle thecall processing and signaling for both circuit-switched traffic and GPRS/EGPRS packet dataservices on a per subscriber basis.

Therefore, the BSS part of the network supports the simultaneous attachment, activation andmonitoring 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 considersswitchable GPRS/EGPRS timeslots as idle TCHs.

8-4 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Feature compatibility

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 switchableGPRS/EGPRS timeslots, but it cannot reconfigure the reserved GPRS/EGPRS timeslots underany circumstance.

Directed retry

No additional BSS or GPRS/EGPRS network planning is required.

The BSC uses directed retry to relieve cell congestion by redistributing traffic across cells. Forthe GPRS/EGPRS traffic part of the BSS, the BSC treats switchable GPRS/EGPRS timeslotslike idle TCHs.

Emergency call preemption

No additional BSS or GPRS/EGPRS network planning is required.

The BSS can configure any GPRS and/or EGPRS timeslot to carry out emergency calls. If anemergency call has to be made within a cell with a GPRS or EGPRS carrier, the BSS selects theair 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 thefollowing 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 alow priority and preemption vulnerability to the emergency call occupying the TCH.

68P02900W21-T 8-5

Jul 2010

Feature compatibility Chapter 8: BSS planning for GPRS/EGPRS

For cell with extended PDCH, when an MS is in the normal range, if there is no normal PDCHavailable. the extended PDCH can be stolen for emergency call only. When the MS is in theextended range, only the extended PDCH can be stolen for emergency call.

NOTEBefore any EGPRS timeslots are assigned switchable, all GPRS timeslots, if available,is assigned to be switchable first.

Extended range cells

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 kmup to a maximum range of 121 km (depending on limiting factors). For the cell with extendedPDCH, this range extension is also supported for GPRS or EGPRS carrier. Only one carrier canbe 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 thenumber of active users. The GPRS/EGPRS timeslots assigned to the uplink and downlinkchannels must have the same frequency parameters. GPRS/EGPRS timeslots can have adifferent timeslot activity factor to voice, and hence cause the cell C/I performance to changefrom a GSM-only system.

The frequency redefinition feature extends the GSM 4.08 capabilities to GPRS and EGPRS.

Global reset

No additional BSS or GPRS/EGPRS network planning is required.

The global reset procedure initializes the BSS and MSC in the event of a failure. A global resetdoes 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 theGDS link.

The PCU does not support a high bit-rate subscriber line (HDSL) between the PCU and theBSC. However, if an E1 is used for the connection, the BSC can use an MSI board (with HDSLcapabilities) 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 multibandhandovers.

8-6 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Feature compatibility

Over the air flow control for circuit-switched mobiles

No additional BSS, GPRS, or EGPRS network planning is required.

The BSC treats switchable GPRS/EGPRS timeslots like idle TCHs in the case of over the air flowcontrol for the circuit-switched mobiles feature.

RTF path fault containment

The BSC uses a switchable GPRS/EGPRS timeslot for a Cell Broadcast CHannel (CBCH) or aStandalone Dedicated Control CHannel (SDCCH).

The RTF path fault feature converts TCHs to SDCCH when an RTF path fault occurs. TheRTF 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 RTFpath fault is cleared.

SMS cell broadcast

The CBCH can reside on a switchable GPRS/EGPRS timeslot. Therefore, switchableGPRS/EGPRS timeslots can be reconfigured as SDCCHs. However, GPRS/EGPRS reservedtimeslots cannot be reconfigured as SDCCHs.

SD placement prioritization

A GPRS/EGPRS carrier cannot be configured such that the sum of the number of allowedSDCCHs and the number of GPRS/EGPRS timeslots exceed the capacity of the carrier.

GPRS seamless cell reselection

No additional BSS, GPRS, or EGPRS network planning is required.

Seamless cell reselection alleviates heavy performance degradation in the GPRS/EGPRSs systemdue to frequent cell reselections by performing the cell change procedure at the RLC/MAClayer rather than at a higher layer.

VersaTRAU backhaul

VersaTRAU backhaul feature allows the operator to configure the backhaul required for anEGPRS capable RTF using the rtf_ds0_count parameter associated with the RTF. Plan thebackhaul per RTF based on the number of reserved and switchable timeslots in the cell andexpected RF conditions.

Table 8-1 summarizes the recommended VersaTRAU backhaul for a given number of configuredPDTCHs per carrier. The recommendations are based on the achievement of average codingscheme of at least MCS6.

68P02900W21-T 8-7

Jul 2010

Feature compatibility Chapter 8: BSS planning for GPRS/EGPRS

Table 8-1 VersaTRAU backhaul recommendations for a given number of PDTCHs

Number ofPDTCH

Recommended aggressive VersaTRAUbackhaul (average 28 kbps)

Recommended non-aggressiveVersaTRAU backhaul

Number ofDS0 Average kbps (effective MCS) Number of

DS0Average kbps(effective MCS)

8 4 28 kbps (MCS5) 5 34 kbps (MCS6)

7 3 24 kbps (MCS5) 4 31 kbps (MCS6)

6 3 28 kbps (MCS5) 4 37 kbps (MCS6)

5 3 33 kbps (MCS6) 3 33 kbps (MCS6)

4 2 28 kbps (MCS5) 3 41 kbps (MCS6)

3 2 37 kbps (MCS6) 2 37 kbps (MCS6)

2 1 28 kbps (MCS5) 1 28 kbps (MCS5)

1 1 59 kbps (MCS9) 1 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 to8 PDTCHs per carrier (non- BCCH carrier). The next row shows the number of DS0s formingthe VersaTRAU frame (Versachannel), the expected throughput and coding scheme with thegiven VersaTRAU backhaul. The rows further down the table indicate the number of DS0sconstructing the VersaTRAU frame and throughputs after 1, 2, 3, 4, and 5 TSs are stolen forvoice. In this table, the recommended backhaul for the Versachannel is conservative, andgenerally results in MCS6 (if all PDTCHs on the given carrier are carrying active data transfersat the same time. If other timeslots on the carrier are idle due to the benefits of the statisticalmultiplexing, higher coding schemes on individual timeslots can be reached).

Table 8-3 is more aggressive and shows the recommended number of DS0s forming theVersaTRAU, which generally results in MCS5.

Table 8-2 Expected throughput/TS and coding schemes (conservative)

# of PD/carrier 8 7 6 5 4 3 2 1

# DS0 forVersaTRAUincluding voice

5 5 5 4 4 4 3 3

VersaTRAU %saving versusToday

38 38 38 50 50 50 63 63

#TRAU 0 5 4 4 3 3 2 1 1

# PDs left 8 7 6 5 4 3 2 1

Averagedatarate/TS

34 31 37 33 41 37 28 59

CS used MCS6 MCS6 MCS6 MCS6 MCS6 MCS6 MCS9 MCS9

Continued

8-8 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Feature compatibility

Table 8-2 Expected throughput/TS and coding schemes (conservative) (Continued)

#TRAU 1 4 4 4 3 2 2 2

# PDs left 7 6 5 4 3 2 1

Averagedatarate/TS

31 37 44 41 37 59 59

CS used MCS6 MCS6 MCS6 MCS6 MCS6 MCS9 MCS9

#TRAU 2 4 4 4 2 2 1

# PDs left 6 5 4 3 2 1

Averagedatarate/TS

37 44 59 37 59 59

CS used MCS6 MCS6 MCS9 MCS6 MCS9 MCS9

#TRAU 3 4 4 3 2 2

# PDs left 5 4 3 2 1

Averagedatarate/TS

44 59 59 59 59

CS used MCS6 MCS9 MCS9 MCS9 MCS9

#TRAU 4 4 3 3 2

# PDs left 4 3 2 1

Averagedatarate/TS

59 59 59 59

CS used MCS9 MCS9 MCS9 MCS9

#TRAU 5 3 3 3

# PDs left 3 2 1

Averagedatarate/TS

59 59 59

CS used MCS9 MCS9 MCS9

Table 8-3 Expected throughput/TS and coding schemes (aggressive)

# of PD/carrier 8 7 6 5 4 3 2 1

# DS0 forVersaTRAUincluding voice

4 4 4 4 4 3 3 3

VersaTRAU %saving versus.

Today

50 50 50 50 50 63 63 63

#TRAU 0 4 3 3 3 2 2 1 1

# PDs left 8 1 6 5 4 3 2 1

Averagedatarate/TS

28 24 28 33 28 37 28 59

CS used MCS5 MCS5 MCS5 MCS6 MCS5 MCS6 MCS5 MCS9

Continued

68P02900W21-T 8-9

Jul 2010

Feature compatibility Chapter 8: BSS planning for GPRS/EGPRS

Table 8-3 Expected throughput/TS and coding schemes (aggressive) (Continued)

#TRAU 1 3 3 3 3 2 2 2

# PDs left 1 6 5 4 3 2 1

Averagedatarate/TS

24 28 33 41 37 59 59

CS used MCS5 MCS5 MCS6 MCS6 MCS6 MCS9 MCS9

#TRAU 2 3 3 3 2 2 1

# PDs left 6 5 4 3 2 1

Averagedatarate/TS

28 33 41 37 59 59

CS used MCS6 MCS6 MCS6 MCS6 MCS9 MCS9

#TRAU 3 3 3 3 2 2

# PDs left 5 4 3 2 1

Averagedatarate/TS

33 41 37 59 59

CS used MCS6 MCS6 MCS6 MCS9 MCS9

#TRAU 4 3 2 2 2

# PDs left 4 3 2 1

Averagedatarate/TS

44 39 59 59

CS used MCS6 MCS6 MCS9 MCS9

#TRAU 5 2 2 2

# PDs left 3 2 1

Averagedatarate/TS

37 59 59

CS used MCS7 MCS9 MCS9

If the feature Support the usage of idle TCH for the packet burst traffic is used, idlecircuit-switched timeslots can be used as switchable PDTCHs for packet traffic when GPRS iscongested in the cell. The additional 64k PDTCH shares the RTF backhaul with existing 64kPDTCHs. Therefore, the RTF backhaul resource per carrier (rtf_ds0_count) for 64k EDGEcarrier should be sufficient to ensure the additional switchable PDTCH allocated by this featureat 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 capabilityfor high-capacity operations. The U-DPROC2 is configured as a PXP, which combines thefunctionality of the PICP and PRP on the same board. The PXP is connected to the PSI2 board inthe BSC through an Ethernet link.

8-10 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Feature compatibility

PXP can provide PDCH capacity of 280/70 or 140/140 (Total Fanout/Throughput, refer NOTE). Acombination of PXP, PICP, and PRP can be configured in the PCU. It allows network users toreuse existing DPROC hardware in PCU. Figure 8-2 is an example of mixed configuration inwhich 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 areplacement of DPROC.

• U-DPROC2 boards are configured as PXPs. The PCU can be fully configured with 12U-DPROC2 boards functioning as PXP.

NOTE

• The Increase throughput of PRP with the PCU feature, provides an optionto increase PRP/PXP throughput in terms of mobiles that can be admittedby reducing the PRP/PXP capacity. For prp_fanout_mode1, a maximum of Xtimeslots per PRP/PXP (X:30 for PRP, and 70 for PXP) are served at a 20 msblock period. For prp_fanout_mode2, all timeslots assigned to a PRP/PXP areserved at a 20 ms block period.

68P02900W21-T 8-11

Jul 2010

Feature compatibility Chapter 8: BSS planning for GPRS/EGPRS

• More GPRS TSs can be set up in the database than the PRP/PXPs can supportwithout being rejected. MMI commands are accepted with a warning message.

• It can save CAPEX of the operator, especially at the initial stage of GPRSdeployment and in the location only requiring GPRS coverage. At least, onePDCH is assigned to a cell. The coverage has higher priority than capacity.Enough PDCH resources/PRP should still be available when cell capacity isrequired.

Gb over IP

{26638}

The Gb interface between the PCU and SGSN may be optionally provisioned over an IPsub-network as an alternative connection to the current E1 using frame relay. Gb interfacesover IP backhaul do not require expensive leased E1 lines/timeslots. They also provide thebenefits of an IP-based network such as lower cost, flexibility, more standardization, betterproduct positioning, and so on. This IP connection is available only on Ethernet connectionsfrom the PCU.

NOTEMixed mode Gb interface (supporting both Frame Relay and IP Gb links to the samePCU) 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 asthe network service for the Gb interface for a particular PCU, and not both. The IPaddresses used for Gb traffic should be IPv4 and of static configuration only. Staticconfiguration of NSVC is supported instead of dynamic configuration.

The Gb over IP feature enables the Ethernet port on PMC card (PPROC) in front of theU-DPROC2 board while the U-DPROC2 is configured as PXP. The PPROC mounted on the PXP isthen capable of processing both Gb traffic and GDS while the baseboard of the PXP is capable ofprocessing the GDS traffic.

One Gb Ethernet port per PXP is supported. Therefore, maximum 12 Gb Ethernet links per PCUare supported. The Gb Ethernet port is in 100/1000 Mbps auto negotiation mode.

NOTETo avoid Ethernet duplex mode mismatch, it is mandatory that the duplex modeof the Ethernet port to be set to auto negotiation mode at both PCU side and thenode directly connected to the PCU, which could be an SGSN or an intermediatedswitch/router.

The Gb over IP feature is based on the ePCU deployment configuration, the U-DPROC2 andPSI board are necessary for the Gb over IP feature deployment. Only when the U-DPROC2 isconfigured as PXP, it supports the Ethernet GBL. The GDS has to be configured on the PXPboard to make the PXP Gb ETH and GBL in service. If the U-DPROC2 is configured as PICPor 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 Gbover IP and Gb over Frame Relay with same traffic load. However, Gb over IP provides biggerthroughput capacity than Gb over Frame Relay.

8-12 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Feature compatibility

Although the Ethernet Gb bandwidth is more in comparison to the E1 Gb, the capacity of the PCUdoes not increase due to the constraint of the U-DPROC2 capability. The end-to-end performanceis kept at the same level compared with the Gb over Frame relay under the condition of theexternal IP network. Security can be guaranteed. IP intrusion detection and prevention can beprovided 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 boardsincreases. It is recommended to optimize PCU system after the deployment especially whenthe PRPs are configured with DPROC boards. There are two key statistics, CPU_Usage andPRP_LOAD, which should be used to monitor the CPU utilization and replan accordingly. Referto 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 theBSC, BTS, and RXCDR.

Table 8-4 BSS upgrade in support of GPRS/EGPRS

Equipment Additional element BSS upgrade

BSC Chassis (optional)

Software upgrade

Add KSWs/DSW2s, LCFGPROC2s/GPROC3s/GPROC3-2s,BSP GPROC3s/GPROC3-2s, MSIsper BSC as needed in support ofthe Gb (where Gb is connectedthrough the BSC), RSL, BSC-BTStraffic carrying E1 links. PSI2 orMSI needed for GDS TRAU, GDSLAPD (GSL). PT43/PBIB-ES whenPSI2 cards used.

BTS (Horizon II macro,Horizonmacro, M-Cell6,M-Cell2)

CTU2 Transceiver, withEGPRS Firmware upgrade(M-Cell6 and M-Cell2 needthe CTU Adapter with theCTU2s)

EGPRS enabled CTU2 radios arerequired.

CTU2D radios on Horizon II macroalso support EGPRS.{34371G} CTU8m and RCTU8msupport EGPRS.

PCU Software upgrade UDPROC-2s can replace DPROCs.

Continued

68P02900W21-T 8-13

Jul 2010

Feature compatibility Chapter 8: BSS planning for GPRS/EGPRS

Table 8-4 BSS upgrade in support of GPRS/EGPRS (Continued)

Equipment Additional element BSS upgrade

For high capacity PCUs wheremore than 24 E1s are needed, it isnecessary to add a second T43 orBIB patch panel to the PCUs. Theupgrade kit includes a patch panel(75 ohm or 120 ohm) and two cablemanagement brackets.

Besides E1, ETH is also used forGDS TRAU and GSL link whenPXP/U-DPROC2 is used. The GbETH is also used as an optionalsubstitution of the frame relay E1for the Gb interface with the SGSNwhen PXP/U-DPROC2 is used.

OMC-R Software upgrade forEGPRS 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 perRXCDR as needed to support theGb interface shown as option A inFigure 8-1.

NOTEOMC-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 parametervalues in support of GPRS and EGPRS per BSS network element.

Table 8-5 Recommended maximum BSS network parameter values (part A)

Network Element Network Parameter Maximum Value

PCU (PRP) Air interface timeslotsprocessing per PRP

prp_fanout_mode1- 30 at any instance intime; 120 total timeslots.

prp_fanout_mode2- 48 at any instance intime; 48 total timeslots.

Continued

8-14 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Feature compatibility

Table 8-5 Recommended maximum BSS network parameter values (part A)(Continued)

Network Element Network Parameter Maximum Value

PCU (PXP) Air interface timeslotsprocessing per PXP

prp_fanout_mode1- 70 at any instance intime; 280 total timeslots.

prp_fanout_mode2- 140 at any instance intime; 140 total timeslots.

PCU (PICP) PCU-SGSN (Gb)interface (E1 GBL)

4 Gb E1 to carry frame relay channelized ornon- channelized GPRS traffic deployed overthe BSC to PCU interface. The Gb E1 carriesboth data and signaling traffic between thePCU and SGSN.

PCU (PXP) PCU-SGSN (Gb)interface (ETH GBL)

If the Gb over IP feature is unrestricted andthe Gb mode is a static IP, 1 Gb ETH per PXPis deployed to carry the GPRS traffic over theBSS/PCU to SGSN interface. The Gb ETH IPcarries both data and signaling traffic betweenthe PCU and SGSN.

PCU Maximum PSPMPROCs

2 (for redundancy)1 (no redundancy)

PCU Maximum PICPDPROCs

4*

PCU Maximum PRPDPROCs

9*

PCU Maximum PXPDPROCs

12*

PCU Number of cellssupported

250*****

PCU Number of BTS sitessupported

140*****

E1 numbers forGSL (PICP)

Maximum physicalE1s between BSC andPCU (one primary E1and one redundant)

2

ETH links for GSL(PXP)

Maximum physicalETH links betweenBSC and PCU

12***

ETH links for GBL(PXP)

Maximum physical GbETH links betweenPCU&SGSN

12******

Continued

68P02900W21-T 8-15

Jul 2010

Feature compatibility Chapter 8: BSS planning for GPRS/EGPRS

Table 8-5 Recommended maximum BSS network parameter values (part A)(Continued)

Network Element Network Parameter Maximum Value

Maximum numberper E1 link (E1corresponds to aquantity of thirty 64kbps LAPD channels)

30LAPD-type GDSlinks (GSL)

Maximum per ETHlink

30

Maximum number ofE1s per PCU

36**TRAU-type GDSlinks

Maximum number ofETHs 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 cansupport 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/1000Mbps.

• ***** The number can be reached when Huge BSC is unrestricted (refer toChapter 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 percell

12/21* /24**

BSS (BTS) Timeslots per carrier (GSM,GPRS and EGPRS)

8

BSS (BTS) Users per timeslot in eachdirection

4

BSS (BTS) Timeslots per active userDL

4

BSS (BTS) Timeslots per active userUL

2 or 4

BSS (BTS) GPRS/EGPRS timeslots percell (total of switchable andreserved)

30

BSS (BSC) PCU per BSC 1

Continued

8-16 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Feature compatibility

Table 8-6 Recommended maximum BSS parameter values (part B) (Continued)

Network Element Network Parameter Maximum Value

BSS (PCU) Air interface timeslotsprocessed at any instance intime (with redundancy forPRP/PICP configuration).

prp_fanout_mode1 - 30 * 8 = 240

prp_fanout_mode2 - 48 * 8 = 384See Figure 8-3.

BSS (PCU) Air interface timeslotsprocessed at any instancein time (with redundancyfor PXP configuration).

prp_fanout_mode1 - 70 * 11 = 770

prp_fanout_mode2 - 140 * 11 = 1540See Figure 8-6.

BSS (PCU) Total air interface timeslots(with redundancy forPRP/PICP configuration)

prp_fanout_mode1 - 120 * 8 = 960

prp_fanout_mode2 - 48 * 8 = 384See Figure 8-3.

BSS (PCU) Total air interface timeslots(with redundancy for PXPconfiguration)

prp_fanout_mode1 - 280 * 11 = 3080

prp_fanout_mode2 - 140 * 11 = 1540See Figure 8-6.

BSS (PCU) Air interface timeslotsprocessed at any instancein time (for PRP/PICPconfiguration)

prp_fanout_mode1 - 30 * 9 = 270

prp_fanout_mode2 - 48 * 9 = 432See Figure 8-4.

BSS (PCU) Air interface timeslotsprocessed at any instance intime (for PXP configuration)

prp_fanout_mode1 - 70 * 12 = 840

prp_fanout_mode2 - 140 * 12 = 1680See Figure 8-7.

BSS (PUCK) Total air interfacetimeslots (for PRP/PICPconfiguration)

prp_fanout_mode1 - 120 * 9 = 1080

prp_fanout_mode2 - 48 * 9 = 432See Figure 8-4.

BSS (PCU) Total air interface timeslots(for PXP configuration)

prp_fanout_mode1 - 280 * 12 = 3360

prp_fanout_mode2 - 140 * 12 = 1680See Figure 8-7.

NOTE

• * Maximum when all carriers at a BTS are EGPRS enabled.

• ** If VersaTRAU feature is unrestricted then the maximum number of carrierswhen 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 capacitycombination of PRP and PXP.

In the field environment, there are two key statistics, CPU_Usage and PRP_LOAD, whichfurther help in optimizing the PRP/PXP planning. These statistics are collected for an extendedamount of time (representative of peak hour, during holidays, and so on) such that the trafficpatterns can be studied and the PRP/PXP planning can be optimized.

68P02900W21-T 8-17

Jul 2010

Feature compatibility Chapter 8: BSS planning for GPRS/EGPRS

CPU_USAGE

Observing the CPU utilization of all PRP/PXPs in the PCU is an important avenue in determiningwhether the boards are overloaded. In a system with multiple PRP/PXPs, the load is balancedacross all PRP/PXPs and the CPU utilization is also similar. If the CPU utilization on any of thePRP/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 servicemix. Compared to fanout mode 2, more CPU_Usage can be seen in fanout mode 1, as moremobiles/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 GBLconfigured 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 consistentbasis, 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 trafficpatterns in the system. This statistic reports a mean value by default. In order to determinea change in traffic volume over time, it is important to configure the individual bins to get afiner resolution on the traffic.

The value of this parameter is relevant to PRP/PXP fan out mode 1. For fanout mode 2, thevalue is always less or equal to 100.

For the PRP on the DPROC, it is recommended that PRP_LOAD does not exceed a mean of100 during the busy hour when QoS is critical. A mean value greater than 100 implies thatmore 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 acell level is moderate.

For a MEAN PRP_LOAD exceeding 160, consider adding a PRP. Maintaining a MEANPRP_LOAD over 160 results in poor throughput for the end-users as well as the trigger ofrebalancing of cells across PRPs.

For the PRP on U-DPROC2, the CPU usage may be low even at high PRP_LOAD. High PRP_LOADvalue implies the operator can see non-optimal throughput. The same guideline as describedfor DPROC PRP is recommended.

For the PXP, the field data is required for the analysis of the right value of PRP_LOAD forPXP planning.

8-18 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Feature compatibility

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 2

Gb frame relay frameoctet 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 necessaryto add a second T43 patch panel to the PCUs. This number is less if VersaTRAUis unrestricted and not all EGPRS carriers are provisioned with a backhaul of8 DS0s, and PRPs are used.

• *** If the Gb interface used is Ethernet/IP, the maximum IP packet octet issuggested as 1500 bytes.

The fact that all of the timeslots of a cell are allocated to the same PRP or PXP board affectsthe total number of air interface timeslots supported by the PCU. Allocation of a part of theGPRS/EGPRS timeslots for a cell to one PRP/PXP and another part of the GPRS/EGPRS timeslotsof the same cell to a different PRP/PXP is not supported. This fragmentation of the cells acrossPRP and PXP boards result in not all GPRS/EGPRS timeslots for a cell being assigned to aPRP/PXP and may even result in not all cells being assigned to a PRP/PXP. When planningthe BSS, if the number of GPRS+EGPRS timeslots in the BSS does not exceed max_GPRS ormax_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

Feature compatibility Chapter 8: BSS planning for GPRS/EGPRS

Where: Is:

max_GPRS/max_EGPRSTSg

maximum number of GPRS/EGPRS timeslots per PCUguaranteed 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 theBSS with the most GPRS timeslots.

prp_fanout_mode a database parameter indicating the options of PRPfanout in the PCU. All the PRP/PXPs should have thesame 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 containsup to 4 x T43 boards. To support a maximum of 24 E1 s for a fully configured PCU, 4 x T43boards require to be populated.

With EGPRS carriers, if the number of E1s is greater than 24 then a second interconnect panelcan be added.

The number of T43 boards in the second interconnect panel is dependent on the number of E1srequired.

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 patchcable. 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 thePMC front panel of the U-DPROC2 board. The port is ETH RJ45 and uses a standard Category 5epatch cable. The cable can be used for direct or indirect connection between the PCU and SGSN.

NOTELimit the Cat 5e cable to a maximum distance of 100 m (328 ft) for the Ethernetnetwork direct connection.

8-20 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1

DPROC

DPROC

DPROC

DPROC

DPROC

DPROC

MPROC

A

MPROC

B

DPROC

DPROC

DPROC

DPROC

DPROC

DPROC

Default LAPD Link To BSC

DPROCRTM

DPROCRTM

DPROCRTM

DPROCRTM

DPROCRTM

DPROCRTM

HSCA

MPROCBRTM

HSCB

MPROCARTM

DPROCRTM

DPROCRTM

DPROCRTM

DPROCRTM

DPROCRTM

DPROCRTM

Default LAPD Link To BSC

ti-GSM-PCU_shelf_layout-00135-ai-sw

NOTE

• 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 newRTMs are incompatible, and must match the DPROC type installed in the sloton 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 frontpanel of the U-DPROC2/PXP.

• Any of the two available default LAPD link slots is used.

68P02900W21-T 8-21

Jul 2010

PCU shelf (cPCI) Chapter 8: BSS planning for GPRS/EGPRS

PCU shelf (cPCI)■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The PCU cabinet can hold up to three PCU (cPCI) shelves; only two PCU shelves can be fittedwhen 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 terminationtype, balanced 120 ohm, or unbalanced 75 ohm terminations with 1500 volt lightning protectionper E1.

Planning considerations

Consider the following factors when planning the cPCI complement:

• The maximum number of timeslots that can be processed at any instance in time per PCUin 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 fullyredundant 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 powersupply unit is not fitted, a minimum of two power supply units are required, with a fan-onlyunit 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 isnot required for normal PCU operation, but is necessary for the PCU to achieve highavailability.

• Each MPROC board needs one bridge board and one transition module for a redundantMPROC 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 auxiliaryequipment such as tape drives, CD-ROM drives, and hard disks. The PCU is configuredwithout any auxiliary equipment. This area of the shelf is covered with blank panels.

Table 8-8 Maximum number of timeslots that can be processed

Board prp_fanout_mode = 1 prp_fanout_mode = 2

DPROC/PRPs orU-DPROC2/PRPs

30 * 8 = 240 48 * 8 = 384

U-DPROC2/PXPs 70 * 11 = 770 140 * 11 = 1540

8-22 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning considerations

Table 8-9 Maximum number of timeslots that can be provisioned

Board prp_fanout_mode=1 prp_fanout_mode=2

DPROC/PRPs orU-DPROC2/PRPs

120 * 8 = 960 48 * 8 = 384

U-DPROC2/PXPs 280 * 11 = 3080 140 * 11 = 1540

NOTE

• If E1 connectivity is used, additional T43 modules and interconnect cables arerequired for the PCU cage. These cables support 18 GDS TRAU links for GPRSand 36 GDS TRAU links for EGPRS.

• If ETH connectivity is used, no additional interconnects are required for GDS. Ifmore than 24 Gb E1 links are required use additional interconnects.

68P02900W21-T 8-23

Jul 2010

MPROC board Chapter 8: BSS planning for GPRS/EGPRS

MPROC board■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The PCU planning process determines the type and number of MPROC boards to populatein the PCU. The PCU provisioning requirements take the MPROC redundancy solution intoconsideration.

PSP planning considerations

The MPROC board is used for PSP purposes. The PSP is the PCU system processor, which isa master system processor board. The PSP controls compact PCI bus synchronization andarbitration. 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 theMPROC cards in slot 7 and 9 (see Figure 8-2). An MPROC (PSP 0) card is inserted into slot 7and the other MPROC (PSP 1) is inserted into slot 9. The MPROC (PSP 0) in slot 7 is paired witha hot swap controller/bridge module in slot 10. The MPROC (PSP 1) in slot 9 is paired with a hotswap 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 bothMPROCs are present but redundancy is not desired or the equip flag is disabled, then theMPROC 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 TMCP700transition module.

8-24 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning DPROC board

DPROC board■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The PCU planning process determines the type and number of DPROC boards to populate in thePCU. The PCU provisioning requirements use the number of GPRS timeslots as the planningrule input. The estimation process for determining the number of GPRS timeslots is provided inGPRS/EGPRS network traffic estimation and key concepts on page 3-74 in Chapter 3 BSS cellplanning.

PICP or PRP planning considerations

DPROC board slots can be used for either PICP or PRP purposes. Each DPROC has an E1transition 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 PICPsoftware. The DPROC can be configured as a PRP with either one or two E1 PMC modules, andwith PRP software. The cPCI shelf supports a total of 16 cards. The redundancy MPROC boardswith 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 twobackplanes 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 theMPROC processor board. Therefore, the first PICP would occupy board slot 1, PICP 2 wouldoccupy 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 betweenthe 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 Gblinks (GBL). But GSL and GBL cannot be resident in the same MSI.

PRP board

Consider the following factors when planning the complement PRP board:

• The PCU can support up to 10 PRP boards with the recommended maximum being 9 PRPboards. When 9 PRP boards are populated, there are three slots available for the PICPboards.

68P02900W21-T 8-25

Jul 2010

PICP or PRP planning considerations Chapter 8: BSS planning for GPRS/EGPRS

• PRP boards with PMCs can terminate one GDS TRAU E1 per PMC module for GPRS andtwo 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 doesnot terminate any GDS TRAU E1s has no function (PRP is always OOS when no GDSis equipped, or PRP loses normal function when all associated GDSs are OOS). All PDshandled 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 48air 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 aPRP 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 toequally distribute the timeslots across PRPs.

• In prp_fanout_mode2, the maximum number of air timeslots that can be assigned to aPRP 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 toequally distribute the timeslots across PRPs.

NOTE

• The actual distribution of timeslots can be slightly different from that shownhere depending on cell configurations. For example, all timeslots for a singlecell must terminate on a single PRP, which can lead to slight imbalances whenmultiple 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, PRPcapacity, load, and related TRAU GDS resource. Sometimes when the plannednumber of air timeslots or GDS resource is close to the maximum capacityof the PRP and its GDS, the PRP may not reach its maximum capacity withnon-optimum configuration. The adequacy and evenly distribution of TRAU GDSis 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. Thereare two key statistics, CPU_Usage, and PRP_LOAD, which further help in optimizing thePRP planning. These statistics are collected for an extended amount of time (representativeof peak hour, during holidays, and so on) such that the traffic patterns can be studied andthe PRP planning can be optimized.

CPU usage

Observing the CPU utilization of all PRPs in the PCU is an important means in determiningwhether the boards are overloaded. In a system with multiple PRPs, the load is balanced acrossall PRPs and the CPU utilization is similar as well. If the CPU utilization on any of the PRPsconsistently exceeds 90% (mean usage) during peak hours, consider adding a PRP in a PCU asa general rule.

8-26 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning PICP or PRP planning considerations

This statistic reports three values for a given time interval - MIN, MAX, and MEAN. Although theMAX value can reach 100%, (for a fraction of a second at a time), this condition should neverbe used as the criteria for the load on the board. In fact, the MEAN value should be the onlyindicative of the PRP utilization. In addition, consider several days worth of data (or evenweeks) to make a consistent decision. CPU utilization plots versus time can help observe apattern in increased CPU utilization.

NOTEWith QoS enabled, the CPU utilization of DPROC increases. The level of increase isdependent on the traffic split between DL and UL (higher with symmetrical), typeof 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 CPUis consistently higher than 90% (mean usage), then either add more PRPs to thedistribute load or replace DPROC with U-DPROC2. It is also recommended to addU-DPROC2 instead of DPROC and configure as PXP instead of PRP since U-DPROC2has more power than DPROC and PXP configure has much bigger capacity thanPRP configure. If there is no room in a PCU to add new board, replace DPROC withU-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 tounderstand the traffic patterns in the system. For instance, when the majority of the GPRStraffic 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 toproduce a PRP_LOAD value in the range of 5-10. However, the PRP_LOAD is higher whenthe PRP handles actual data transfer (WAPs, FTPs, and so on).

This statistic reports a MEAN value by default. However, to determine a change of trafficvolume over time when QoS is critical, it is important to configure the individual bins to get afiner resolution on the traffic. A mean value greater than 100 implies that more than 30 TS arepending service, which generally indicates a non-optimal throughput. However, PRP_LOADMEAN figures of 101-160 can be acceptable if the traffic density per PDTCH on a cell level ismoderate. A traffic density per PDTCH is considered moderate good throughputs.

For a MEAN PRP_LOAD exceeding 160, consider adding a PRP. Maintaining a MEANPRP_LOAD over 160 results in poor throughput for the end-users as well as the trigger ofrebalancing of cells across PRPs.

PDTCH planning

As a general guideline for a new network, configure at least 4 PDTCH/cell on the BCCCHcarrier. This action optimizes the throughput of multi-slot mobiles that are capable of 4 TS onthe DL (downlink). Configuring more than 4 TS/cell normally, assumes the expectancy of highvolumes 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, CellUpdates, RAUs), monitor the several statistics to determine whether the addition of PDTCHs ina cell is required. In networks where GPRS subscriber base is widely enabled but the generaldata usage per subscriber is low, special consideration is required. The following statistics areuseful in determining the PDTCH requirements for a cell.

68P02900W21-T 8-27

Jul 2010

PXP planning considerations Chapter 8: BSS planning for GPRS/EGPRS

DL_BUSY_PDTCH

This statistic measures the MEAN, MAX, and MIN number of occupied PDTCH carryingdownlink packet traffic. Normally, observing the MEAN value should be indicative of how thePDTCHs are utilized in the cell. For a more detailed PDTCH occupancy distribution, this statisticcan also be configured to report ten bins. By default, bin 0 is pegged every block period (20ms) when no TBFs are allocated on any of the PDTCHs on the cell. Bin 1 is pegged when 1 to 2PDTCHs are busy; bin 2 is pegged when 3 to 4 PDTCHs are busy, and so on. For example, a cellconfigured with 10 PDTCHs, with a MEAN value reported as 9.2 implies that all 10 configuredPDTCHs are being utilized. However, if the MEAN is 5, the configured PDTCHs are probablyunder utilized and the number of PDTCHs can be reduced. Before reducing the number ofPDTCHs, 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 beconfigured as switchable, carrying voice traffic during CS busy hour and data traffic duringGPRS 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 thereforeneeds 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 voicecall. This condition indicates that GPRS service is not available at this time on the cell and needsa 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 datasent across the network that does not result from signaling traffic.

PXP planning considerations

U-DPROC2 boards are inserted in DPROC slots, which can be used for PICP, PRP or PXPpurposes. DPROC board can be referred to when U-DPROC2 board is configured as PRP orPICP. The U-DPROC2 board has exactly one E1 module (not configurable). It supports up to 4E1 links providing the same connectivity as the DPROC board with 2 E1 PMC modules. Thesoftware automatically maps E1 PMC modules and span identifiers onto the correct spansof the U-DPROC2 board.

When a U-DPROC2 board is configured as PXP, and the Gb over IP feature is restricted ordisabled, it has one ETH connection for the GDS (GSL and TRAU Frame), and can be used toconnect up to 3 E1 cables for Frame relay Gb connections.

8-28 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning PXP planning considerations

When a U-DPROC2 board is configured as PXP and the Gb over IP feature is unrestrictedand enabled, it can use the U-DPROC2 PPROC ETH port for IP-based GBL. This ETH port isconnected from the U-DPROC2 PMC front panel to the SGSN or IP backbone. Each PXP cansupport only 1 Gb ETH port for the GBL.

Each PXP board must terminate only one GDS TRAU. A PXP board that does not terminate anyGDS TRAU has no PRP function (PXP is always in OOS status and the GBL cannot be INSwhen no GDS is equipped).

When the PXP ETH port carries Gb traffic, the CPU_usage of the PPROC is expected to increasedue to the increased throughput. The throughput capacity of the Ethernet GBL is determined bythe PPROC average CPU usage not exceeding 70% and assumption of 2:1 peak/mean throughputratio. Thus, one Ethernet GBL on the PXP board can provide the average throughput of 5 Mbpsin downlink and 1.5 Mbps in uplink for prp_fanout_mode 1, and 4.9 Mbps in downlink and 1.4Mbps in uplink for prp_fanout_mode 2. Therefore, the traffic model of 4:1 ratio of Downlinkload/uplink load can be supported.

The cPCI shelf supports a total of 16 cards. The redundant MPROC boards with bridgecapability occupy 4 slots, leaving 12 slots for PXPs, PRPs, and PICPs. To describe the maximumconfiguration, 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 ofair timeslots that can be served at a given time interval is 70. The assignment of timeslot toavailable PXP is load balanced by software.

Up to 140 air timeslots can be terminated on one PXP in prp_fanout_mode2. All the timeslotsprovisioned by a PXP can be served at any given time interval. The timeslot assignment toavailable PXP is load balanced by software.

NOTE

• The actual distribution of timeslots can be slightly different from that shownhere depending on cell configurations, that is, all timeslots for a single cell mustterminate on a single PXP, which can lead to slight imbalances when multipletimeslots 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, PXPcapacity, load, and related GDS resource (tdm_ts_bloacks). Sometimes when theplanned 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 anadditional PXP is needed.

• The statistics used for PRP planning are also applied for PXP planning.

68P02900W21-T 8-29

Jul 2010

PMC module Chapter 8: BSS planning for GPRS/EGPRS

PMC module■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The number of PMC modules installed depends on the number of PICP /PRP configured boardsin the PCU.

For the PXP (U-DPROC2), one E1 PMC module is always attached and there is no require tofurther consider the number of E1 PMCs fitted.

Planning considerations

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 modulein a PRP board. LAPD-type GDS (GSL) and Gb E1 (GBL) links terminate on a PMC modulein 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 otherE1 termination on the PMC module cannot be used. For EGPRS, the PRP can support twoPMC modules when configured with EGPRS air timeslots, each with up to two TRAU-typeGDS 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-32bit/s TRAU and 62-64 kbps (each individual DS0 that is part of a Versachannel is a single64 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 thenumber of air timeslots and the number of DS0s required on the backhaul so use the number ofDS0s 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 supporthalf as many 32 kbps TRAU, or one full span. With the channelized subrate insert/extractionremoved 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 NIBcan support an arbitrary combination of 16 kbps and 64 kbps (VersaTRAU) TRAU channels, orchannels with channelized subrate insertion/extraction and those without, trading off at a ratioof two 16 kbps timeslots to one 64 kbps timeslot. When mixed traffic is used, the two spans onthe PMC NIB are not fully utilized.

8-30 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning (Packet) Rear Transition Module

(Packet) Rear Transition Module■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

The number of rear transition modules installed depends on the number of PICP/PRP/PXPboards configured in the PCU.

Planning considerations

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 cardslot in the front of the shelf.

68P02900W21-T 8-31

Jul 2010

PCU equipment redundancy and provisioning goals Chapter 8: BSS planning for GPRS/EGPRS

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 3fan 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 seamlessredundancy. The GSL and GBL use a routing algorithm to dynamically balance the loadacross all available links. The individual GSL and GBL links can be distributed acrossthe available PICPs/PXPs. If a PICP/PXP fails, the remaining PICP(s)/PXP(s) if equippedwill process the signaling load.

With the {26638} Gb over IP feature unrestricted and enabled, the PCU distributes the NSSDUs traffic in equal proportion to the relative weights among the available IP endpointson the Gb interface (GBL/NSVC). The use of weighted load sharing also provides the upperlayer seamless service upon failure by re-negotiating the NS SDU traffic between theremaining IP endpoints. Each NSE uses the weighted load sharing function to determinethe local IP endpoint associated with all NS SDU traffic related to an MS. The remote IPendpoint is initially determined by the load sharing function that distributes the traffic inequal 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 PCUautomatically balances the number of air timeslots across the available PRP/PXPs. If a GDSlink fails, the BSC and PCU attempt to move the air timeslots to another available GDSlink. If a PRP/PXP fails, all the air timeslots on the failed PRP/PXP are moved to otherPRP/PXPs if adequate resources are available.

PCU equipment redundancy planning

Three configurations are supported: PRPs/PICPs, PXPs only, or a combination of PRP/PICPand PXPs.

8-32 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning PRP/PICP configure

PRP/PICP configure

For redundant PCU operation, plan the PCU such that there are sufficient boards provisioned asshown in Figure 8-4, that is, only eight PRP boards and two PICP boards are required to handlethe expected maximum GPRS traffic load. The ninth PRP board and third PICP board offer theextra capacity to provide redundancy in the event of a PRP or PCIP failure. The third PICP boardprovides 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 boardsrequired and then adding an additional PRP board. The GSL E1 link redundancy is obtained byprovisioning a second GSL E1. The PCU load-balances across the LAPD GSL links. If a PRP orPICP 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 linkresiliency is obtained by adding an additional two Gb E1s and load balancing across all of the GbE1s. 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 otherboards. Lock the DPROC before removal and unlock after board insertion. The PRP and PICPboards have associated transition module boards. There is an associated redundant transitionmodule board with each redundant PRP and PICP board.

The PCU shelf hardware allows for N+1 MPROC board redundancy. This N+1 redundancycapability is subject to MPROC redundancy software availability. The MPROC board(s) and theMPROC bridge boards are not shown in Figure 8-4 or Figure 8-5, but the redundant MPROChas an associated redundant bridge board.

The PCU shelf comes with N+1 power supply/fan redundancy. The power supplies are hotswappable. 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 andFigure 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-6for EGPRS).

Table 8-10 summarizes the provisioning goals demonstrated with Figure 8-4, Figure 8-5, andFigure 8-6.

68P02900W21-T 8-33

Jul 2010

PRP/PICP configure Chapter 8: BSS planning for GPRS/EGPRS

Figure 8-4 Provisioning goals (full redundancy)

Redundant GBL

PMC

PRP8

GSL

To...

CHANNEL124@16K / GDS TRAU

Redundant

GDS

GDS

GDS

GDS

GDS

GDS

GSL

BSC SGSNPMC

PMC

PMC

PMC

PMC

PMC

PMC

PMC

PMC

PMC

PMC

PRP1mode1: 30/120mode2: 48/48

mode1: 30/120mode2: 48/48

PRP9mode1: 30/120mode2: 48/48

Redundant GBL

GBL

P1 CP1

P1 CP2

30 LAPD

30 LAPD

TS MAX

P1 CP2

TS MAX

30 LAPDTS MAX

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 PCUprovisioning.

8-34 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning PRP/PICP configure

Figure 8-5 Provisioning goals (Maximum coverage)

To

Redundant GBL

PMC

PMC

PMC

PMC

PMC

PMC

PMC

PMC

GDS

GDS

GDS

GDS

GDS

GDS

PMC

PMC

GSL

GSLRedundant

124@16K / GDS TRAUCHANNEL

BSC SGSNPRP1

PRP2

mode1: 30/120mode2: 48/48

mode1: 30/120mode2: 48/48

PRP9mode1: 30/120mode2: 48/48

P1 CP1

P1 CP2

30 LAPDTS MAX

30 LAPDTS MAX

GBL

ti-GSM-Provisioning_goals_Maximum_coverage-00137-ai-sw

Refer to Table 8-10 for a matrix of provisioning goals achieved with this instance of PCUprovisioning.

NOTEFigure 8-5 shows 18 GDSs, as required for CS3/CS4. Only 9 GDSs are required forCS1/CS2.

68P02900W21-T 8-35

Jul 2010

PRP/PICP configure Chapter 8: BSS planning for GPRS/EGPRS

Figure 8-6 EGPRS maximum throughput and coverage, full redundancy not required

GBL

To...

EG

PR

S

124@16K / GDS TRAUCHANNEL

BSC SGSNGDS

GDS

GDS

GDS

GDS

GDS

GBL

GBL

GBL

PMC

PMC

PMC

PMC

PMC

PMC

PMC

PMC

PMC

PMC

PMC

PRP1mode1: 30/120mode2: 48/48

PRP8mode1: 30/120mode2: 48/48

mode1: 30/120mode2: 48/48

P1 CP130 LAPDTS MAX

P1 CP230 LAPDTS MAX

P1 CP3

EG

PR

SE

GP

RS

PRP9

PMC

ti-GSM-EGPRS_maximum_throughput_and_coverage_full_redundancy_not_required-00138-ai-sw

NOTEThe number of GDS links per PRP is decreased to 2 for PRP fanout mode 2.

Refer to Table 8-10 for a matrix of provisioning goals achieved with this instance of PCUprovisioning.

Table 8-10 Provisioning goals (per PCU)

Metric Goal

GPRS maximumcoverage withredundantconfiguration(Figure 8-4).

GPRS maximumcoverage, redundancynot required(Figure 8-5).

EGPRS maximumcoverage,redundancy notrequired(Figure 8-6).

Continued

8-36 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning PRP/PICP configure

Table 8-10 Provisioning goals (per PCU) (Continued)

Metric Goal

Number of timeslotsprocessed at anyinstance in time

Mode 1: 240(30*8)

Mode 2: 384(48*8)

Mode 1: 270(30*9)

Mode 2: 432(48*9)

Mode 1: 270(30*9)

Mode 2: 432(48*9)

Total numberof provisionedtimeslots at a BSS

Mode 1: 960(120*8)

Mode 2: 384(48*8)

Mode 1: 1080(120*9)

Mode 2: 432(48*9)

Mode 1: 1080(120*9)

Mode 2: 432(48*9)

Number of MPROCs 2 1 1

Number of PRPs 8 9 9

Number of PICPs 2 2 3

Number ofTRAU-Type GDSE1s

18 18 36**

Number ofLAPD-Type GDS(GSL)E1s

2 2 2

Number of Gb E1s 4 4 8

MPROC boardredundancy

Yes No No

PRP boardredundancy

Yes No No*

PICP boardredundancy

Yes No No*

GDS TRAU E1redundancy

Yes No No*

GSL E1 redundancy Yes Yes Yes

Gb E1 redundancy Yes Yes Yes

NOTE

• * Capacity does not meet calculated maximums in the event of a failure. Thiscan or cannot affect the usage dependent on the current load of the system.

• ** The maximum number of GDS resources can be less if VersaTRAU isunrestricted and EGPRS carriers are equipped with less than 8 DS0s of backingon the backhaul.

• When EDGE and VersaTRAU are enabled, to ensure that sufficient GDSresources are planned/configured for all EDGE configured cells to provide EDGEservice, GDS resources for 64 k enabled RTFs (pkt_radio_type = 3) shouldbe planned as follows.

68P02900W21-T 8-37

Jul 2010

PXP configuration Chapter 8: BSS planning for GPRS/EGPRS

On per 64 k carrier basis:

If the carrier backhaul configured (rtf_ds0_count) is less than or equal tothe number of 64 k PDTCH configured (including switchable TCH/PDTCHtimeslots), then the GDS DS0 requirement is rtf_ds0_count.

If the carrier backhaul configured (rtf_ds0_count) is greater than thenumber of 64 k PDTCH configured (including switchable TCH/PDTCHtimeslots), then the GDS DS0 requirement is the number of 64 k PDTCHsconfigured (including switchable TCH/PDTCH timeslots).

PXP configuration

For PXP configuration, an additional board is recommended for load balanced in normaloperation and for redundancy in the event of a PXP failure. For example, plan the PCU suchthat there are sufficient boards provisioned as shown in Figure 8-7, that is, only 11 PXP boardsare required to handle the expected maximum GPRS traffic load. The 12th PXP board offersthe 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 isobtained by equipping one more PXP board than the number of PXP boards required. If aPXP 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 connectivitybetween the PCU and SGSN. Equip one more PXP board for ETH Gb than the number of PXPboards required for the N+1 redundancy purpose. If a PXP board fails, the PCU automaticallyre-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 linkresiliency 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 haveassociated packet rear transition module boards not shown in the figures. There is an associatedredundant 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 Etherlink resiliency is obtained by adding an additional PXP and load balancing across all the IP-basedGb 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/PICPconfigure on page 8-33.

The PCU architecture offers a considerable degree of provisioning flexibility. Figure 8-7 andFigure 8-8 (Figure 8-8 is for ETH Gb), and Figure 8-9 and Figure 8-10 (Figure 8-10 is for ETHGb) 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 andFigure 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

System Information: BSS Equipment Planning PXP configuration

Figure 8-7 Provisioning goals (full redundancy)

PXP12mode1: 70/280mode2: 140/140

BSC SGSN

.

.

.

GDS TRAU CHANNELS can beGPRS or EGPRS

GBL

To

GBL

GBL

Redundant GBL

Redundant

PMC*2

PXP11mode1: 70/280mode2: 140/140

GDS+GSLETH*1

*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

PMC*2

GDS+GSLETH*1

PMC*2

PXP1mode1: 70/280mode2: 140/140

GDS+GSLETH*1

PMC*2

PXP2mode1: 70/280mode2: 140/140

GDS+GSLETH*1

Refer to Table 8-11 for a matrix of provisioning goals achieved with this instance of PCUprovisioning.

68P02900W21-T 8-39

Jul 2010

PXP configuration Chapter 8: BSS planning for GPRS/EGPRS

Figure 8-8 Provisioning goals (maximum coverage)

.

.

.

R edundant

BSC SGSN

GDS TRAU CHANNELS can beGPRS or EGPRS

GDS+GSL

GDS+GSL

GDS+GSL

GDS+GSL

Redundant GBL

GBL

GBL

GBL

PXP1mode1: 70/280

mode2: 140/140

PXP2mode1: 70/280

mode2: 140/140

PXP11mode1: 70/280

mode2: 140/140

PXP12mode1: 70/280

mode2: 140/140

ETH*1

ETH*2

ETH*1

ETH*1

ETH*1

ETH*2

ETH*2

ETH*2

*1: One ETH can support 30 GSL, and GDS TRAU is not restricted by ETH

ti-GSM-Provisioning_goals_maximum_coverage-00140-ai-sw

To

*2: ETH on the UDPROC2 front panel

8-40 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning PXP configuration

Figure 8-9 Provisioning goals achieved with instance of PCU provisioning

BSC SGSN

.

.

.

GDS TRAU CHANNELS can beGPRS or EGPRS

GBL

To

GBL

GBL

GBL

PMC*2

PXP11mode1: 70/280mode2: 140/140

GDS+GSLETH*1

*1: One ETH can support 30 GSL, and GDS TRAU is not restricted by ETH*2: PMC supports max 3 GBLs

PMC*2

PXP12mode1: 70/280mode2: 140/140

GDS+GSLETH*1

PMC*2

PXP1mode1: 70/280mode2: 140/140

GDS+GSLETH*1

PMC*2

PXP2mode1: 70/280mode2: 140/140

GDS+GSLETH*1

ti-GSM-Provisioning_goals_achivd_instance_PCU provisioning-00141-ai-sw

68P02900W21-T 8-41

Jul 2010

PXP configuration Chapter 8: BSS planning for GPRS/EGPRS

Figure 8-10 Provisioning goals achieved with instance of PCU provisioning (ET Gb)

.

.

.

R edundant

BSC SGSN

GDS TRAU CHANNELS can beGPRS or EGPRS

GDS+GSL

GDS+GSL

GDS+GSL

GDS+GSL

Redundant GBL

GBL

GBL

GBL

PXP1mode1: 70/280

mode2: 140/140

PXP2mode1: 70/280

mode2: 140/140

PXP11mode1: 70/280

mode2: 140/140

PXP12mode1: 70/280

mode2: 140/140

ETH*1

ETH*2

ETH*1

ETH*1

ETH*1

ETH*2

ETH*2

ETH*2

*1: One ETH can support 30 GSL, and GDS TRAU is not restricted by ETH

To

*2: ETH on the UDPROC2 front panel

ti-GSM-Provisioning_goals_achivd_instance_PCU provisioning(ET-Gb)-00141.a-ai-sw

Refer to Table 8-11 for a matrix of provisioning goals achieved with this instance of PCUprovisioning.

Table 8-11 Provisioning goals (per PCU)

Metric Goal

GPRS maximumcoverage with redundantconfiguration(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

System Information: BSS Equipment Planning Upgrading the PCU

Table 8-11 Provisioning goals (per PCU) (Continued)

Metric Goal

Number of timeslotsprocessed at any instance intime

prp_fanout_mode1- 770(70*11)

prp_fanout_mode2- 1540(140*11)

prp_fanout_mode1-840(70*12)

prp_fanout_mode2-1680(140*12)

Total number of provisionedtimeslots at a BSS

prp_fanout_mode1-3080(280*11)

prp_fanout_mode2-1540(140*11)

prp_fanout_mode1-3360(280*12)

prp_fanout_mode2-1680(140*12)

Number of MPROCs 2 1

Number of PXPs 11 12

Number of TRAU-LAPD GDSETHs*

11 12

Number of Gb E1s 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

NOTE* Capacity does not meet calculated maximums in the event of a failure. This may ormay 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 upgradescenarios 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 theCPU utilization impact is far lower on the U-DPROC2 due to its higher processing power. Whenupgrading PCU, it is recommended to add U-DPROC2 instead of DPROC and configure it asPXP instead of PRP to gain more capacity.

NOTETable 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 Chapter 8: BSS planning for GPRS/EGPRS

Table 8-12 Upgrade scenarios for PRP configuration

No. of airtimeslots

No. ofPRP

No. ofPICP No. of GDS No. of

GBLNo. ofGSL Total links Remarks

Mode 1-120Mode 2-48

1 1 Mode 1-4Mode 2-2

2 2 Mode 1-8Mode 2-6

Minimum.configuration,noredundancy

Mode 1-240Mode 2-96

2 1 Mode 1-8Mode 2-4

2 2 Mode 1-12Mode 2-8

No Gbredundancy

Mode 1-240Mode 2-96

2 2 Mode 1-8Mode 2-4

6 2 Mode 1-16Mode 2-12

Withredundantlinks

Mode 1-360Mode 2-144

3 2 Mode 1-12Mode 2-6

6 2 Mode 1-20 Withredundantlinks

Mode 1-480Mode 2-192

4 2 Mode 1-16Mode 2-8

6 2 Mode 1-24Mode 2-16

Withredundantlinks

Mode 1-600Mode 2-240

5 1 Mode 1-20Mode 2-10

2 2 Mode 1-24Mode 2-14

No Gbredundancy

Mode 1-600Mode 2-240

5 2 Mode 1-20Mode 2-10

6 2 Mode 1-28Mode 2-18

Withredundantlinks

Mode 1-720Mode 2-288

6 3 Mode 1-24Mode 2-12

10 2 Mode 1-36Mode 2-24

Withredundantlinks

Mode 1-840Mode 2-336

7 3 Mode 1-28Mode 2-14

10 2 Mode 1-40Mode 2-26

Withredundantlinks

Mode 1-960Mode 2-384

8 3 Mode 1-32Mode 2-16

10 2 Mode 1-44Mode 2-28

Withredundantlinks

Mode 1-1080Mode 2-432

9 3 Mode 1-36Mode 2-18

10 2 Mode 1-48Mode 2-30

Withredundantlinks

NOTE

• * All air timeslots are assumed to be EGPRS capable and assumed to have abacking 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 numberof DS0s equipped for each EGPRS RTF on the backhaul.

• When EDGE and VersaTRAU are enabled, to ensure that sufficient GDSresources are planned/configured for all EDGE configured cells to provide EDGEservice, GDS resources for 64 k enabled RTFs (pkt_radio_type = 3) shouldbe planned as follows.

8-44 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Upgrading the PCU

On per 64 k carrier basis:

If the carrier backhaul configured (rtf_ds0_count) is less than or equal tothe number of 64 k PDTCH configured (including switchable TCH/PDTCHtimeslots), then the GDS DS0 requirement is rtf_ds0_count.

If the carrier backhaul configured (rtf_ds0_count) is greater than thenumber of 64 k PDTCH configured (including switchable TCH/PDTCHtimeslots), then the GDS DS0 requirement is the number of 64 k PDTCHsconfigured (including switchable TCH/PDTCH timeslots).

Table 8-13 shows maximum configurations for all DPROC boards configured into PXP. All thePXPs in the PCU should have the same setting of prp_fanout_mode.

Table 8-13 Upgrade scenarios for PXP configuration

Number of airtimeslots

Number ofPXP

Number ofGDS(TRAU_LAPD)

Number ofGBL Remarks

Mode 1-280Mode 2-140

1 1 3 Minimum configuration,no redundancy

Mode 1-560Mode 2-280

2 2 6 With redundant links

Mode 1-840Mode 2-420

3 3 9 With redundant links

Mode 1-1120Mode 2-560

4 4 12 With redundant links

Mode 1-1400Mode 2-700

5 5 15 With redundant links

Mode 1-1680Mode 2-840

6 6 18 With redundant links

Mode 1-1960Mode 2-980

7 7 21 With redundant links

Mode 1-2240Mode 2-1120

8 8 24 With redundant links

Mode 1-2520Mode 2-1260

9 9 27 With redundant links

Mode 1-2800Mode 2-1400

10 10 30 With redundant links

Mode 1-3080Mode 2-1540

11 11 33 With redundant links

Mode 1-3360Mode 2-1680

12 12 36 With redundant links

NOTE* For mixed configuration using PRP as well as PXP, consider the capacities of PRPand PXP when upgrading for the additional capacity.

68P02900W21-T 8-45

Jul 2010

E1 link/ETH link provisioning for GPRS and EGPRS Chapter 8: BSS planning for GPRS/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 shouldmeet 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 isconnected directly to the BSC E1 interfaces and the BSC is configured to provide the E1 masterclock. If the PCU attaches to a GSN that does not have a master clock source, use an interfacepiece of equipment, such as a Digital Cross Connect switch (DACs) that does have a master clocksource. 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 areequipped as PRP/PICP.

GDS TRAU E1

On the PMC NIB, the PCU can support an arbitrary mixture of 124 16 kbps TRAU, 62 32 kbpsTRAU, 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

• All PDTCHs of one 64k RTF are required to be mapped to one GDS E1. Whenthe remaining DS0 of one GDS cannot satisfy one 64k RTF required, part ofDS0s required by the RTF is in intrans state even though the total GDS resourceis enough. In this situation, additional GDS E1s or PRP board are required toaccount for this limit.

• Based on the design of Cell Balance (CB) algorithm, the TRAU GDS resource isone of factors which affect the air timeslots allocation on PRP. The adequacy andevenly distribution of GDS TRAU are recommended.

• When GPRS is configured, each PMC on a PRP supports one E1 link. If EGPRSis configured, each PMC can support two E1 links.

• There may be up to 18 TRAU-type GDS E1 links per PCU for GPRS. There maybe up to 36 TRAU-type GDS E1 links per PCU for EGPRS.

8-46 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Ethernet interface provisioning

• When EDGE and VersaTRAU are enabled, to ensure that sufficient GDSresources are planned/configured for all EDGE configured cells to provide EDGEservice, GDS resources for 64 K enabled RTFs (pkt_radio_type = 3) shouldbe planned as follows.

On per 64 K carrier basis:

If the carrier backhaul configured (rtf_ds0_count) is less than or equal tothe number of 64 K PDTCH configured (including switchable TCH/PDTCHtimeslots), then the GDS DS0 requirement is rtf_ds0_count.

If the carrier backhaul configured (rtf_ds0_count) is greater than thenumber of 64 K PDTCH configured (including switchable TCH/PDTCHtimeslots), then the GDS DS0 requirement is the number of 64 K PDTCHsconfigured (including switchable TCH/PDTCH timeslots).

• 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 packettraffic when GPRS is congested in the cell. The additional switchable PDTCHduring GPRS congestion uses the additional GDS TRAU resources. Therefore,theGDS TRAU resource should be configured to have some additional margin toensure 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. ForLAPD-type GDS resiliency, two E1s are recommended, regardless of the number of LAPDchannels required. For example, if only one channel is required to carry the expected signalingload, use two E1s with one LAPD channel per E1. The MPROC load balancing softwaredistributes 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.

Ethernet interface provisioning

High bandwidth interconnection between the BSC and PCU provides Ethernet connectivitybetween 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 in1000 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 canbe supported in the PCU. These links can be run in 100BaseTx/1000BaseT auto-negotiationmode on the peer SGSN side.

68P02900W21-T 8-47

Jul 2010

Ethernet interface provisioning Chapter 8: BSS planning for GPRS/EGPRS

PCU GDS (TRAU-LAPD)

With ETH link, a new type of GDS (TRAU-LAPD) can be equipped. This GDS can carry bothTRAU 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 onePXP is 280 for prp_fanout_mode1 and 140 for prp_fanout_mode2. Consider the parametertdm_ts_blocks for PSI2 for TRAU-LAPD GDS planning. Refer to the tdm_ts_blocks planningguideline 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. Whenmultiple 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. Ifone (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 forresiliency.

PCU Gb (Ethernet)

Each PXP can support one Gb Ethernet link. There can be up to 12 Gb Ethernet links per PCU. Itis 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-typelinks can be provisioned at the PCU. The LAPD links can be distributed on the LCF automatically,based on the capacity available on the LCFs.

NOTEEither the GPROC2 or the GPROC3/GPROC3-2 can perform LAPD-type linkprocessing.

8-48 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning QoS capacity and QoS2 impact

QoS capacity and QoS2 impact■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

The QoS feature retains the 120 mobile per PRP board limit from previous loads. However, thisfeature can affect the overall capacity of the PRP and PXP board. Each PRP/PXP board has acapacity in terms of MTBR. When that capacity is reached, no more non-STNNT mobiles orPFCs can be admitted without preempting other PFCs first. There is a trade-off between thenumber of mobiles being serviced and the MTBR of the PFCs of the mobiles being serviced. Ifthe MTBR of the various traffic classes are set to high values, or there are multiple PFCs permobile, 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 ahigh ARP value PFC is allocated a single timeslot of MTBR (calculated from coding schemeand MTBR) for its use. Additional non-STNNT PFCs of equal or lower ARP value cannot beassigned to that timeslot without compromising the service of the first high ARP value PFC andare later rejected. Four mobiles can be allocated on each PDTCH provided there is sufficientavailable throughput.

When the BSS is managing its pool of MTBR resources, it reserves headroom (16.7%), that is, itdoes not allocate 100% of its resources in terms of MTBR commitments. The purpose of theheadroom is to reserve some throughput in the system so that each PFC has a high probabilityof meeting its MTBR regardless of coding scheme changes and to allow short-term PFCs (suchas 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 alocal zone of timeslots such that coding scheme changes by any mobile within that localzone 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 theirMTBR requirements.

• The second level of headroom is at the PRP/PXP board. This is headroom on the ability ofthe PRP/PXP board to service 30/70 timeslots per block period of throughput (assume itis mode1). Some of this throughput is reserved for coding scheme changes, and STNNTand PAP mobiles.

When admitting a new mobile, the BSS verifies that there is sufficient headroom at both ofthese levels. If there is insufficient headroom to admit the new mobile, other mobiles can bedowngraded 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 afunction of the number of mobiles scheduled on that timeslot. In the maximum case, 8 kbps ofMTBR can be allocated for GPRS and 14 kbps for EGPRS per timeslot. This maximum valueis used for all the capacity calculations. The bandwidth can be obtained from configurableparameters (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. Themost 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 PRPboard for the downlink and the uplink as well as the corresponding summation of the MTBRthroughputs (or committable throughput) of all the timeslot zones on the PRP board.

68P02900W21-T 8-49

Jul 2010

QoS capacity and QoS2 impact Chapter 8: BSS planning for GPRS/EGPRS

It is important to note that for these calculations it is assumed there are multislot class 1mobiles (each using a single uplink and downlink timeslot) and class 4 mobiles scheduled pertimeslot (allowing 8 kbps committable bandwidth per slot). The local timeslot zone headroomis a function of the coding scheme in use but the MTBR throughput of the PRP board isindependent of the coding schemes used.

Table 8-14 takes the coding schemes allowed on a timeslot (for all timeslots) and calculates aLocal Timeslot Zone Level MTBR throughput summed over all timeslots equipped on the PRPboard. 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 thisrestriction is calculated. It is clear from this example that the Local Timeslot Zone LevelHeadroom, when there are 120 timeslots equipped on the board and mobiles with only 1timeslot and 2 kbps MTBR requirements, are not the restricting factor as the 120 mobile perboard 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 is48/48(140/140).

Table 8-14 Local Timeslot Zone Level capacity 4MS/PDTCH

Coding schemeParameter

CS-1/2 CS-3/4 EGPRS

Peak throughput per TS(bit/s)

12000 20000 59200

Local timeslot zone MTBRthroughput per TS (bit/s)

8000 8000 8000

Local timeslot zone totalheadroom (%)

33.3 60.0 86.5

Number of timeslotsequipped

120 120 120

Summation of local timeslotzone level MTBR throughputover PRP (bit/s)

960000 960000 960000

Theoretical limitation basedsolely on local timeslot zonerestriction Max MS at 2kbps/MS

480 480 480

Local timeslot zoneMaximum MS at 2 kbps/MS

120 120 120

Table 8-15 shows the PRP board service headroom and corresponding PRP board service levelMTBR throughput. The PRP board service headroom and corresponding PRP board servicethroughputs are both a function of the actual coding schemes of the mobiles on the board atthe moment (that is, the MTBR or committable throughput of the board is higher when highercoding schemes are in use on the board). It is important to note that for these calculationsit is assumed there are multislot class 1 mobiles (each using a single uplink and downlinktimeslot) and class 4 mobiles scheduled per timeslot (allowing 8 kbps committable bandwidthper slot). CS-1 is the worst case.

8-50 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning MTBR allocation

Table 8-15 PRP Board Service Level Capacity 4MS/PDTCH

Coding schemeParameter

CS-1 CS-1/2 CS-3/4 EGPRS

Peak throughput per TS (bit/s) 8000 11200 15360 25120

Number of PDCH every blockperiod (PRP board, 30/120mode)

30 30 30 30

Local timeslot zone MTBRthroughput

240000 336000 460800 753600

Local timeslot zone totalheadroom (%)

16.7 16.7 16.7 16.7

Summation of local timeslotzone level MTBR throughputover PRP (bit/s)

200000 280000 384000 628000

Theoretical limitation basedsolely on local timeslot zonerestriction Maximum MS at 2kbps/MS

100 140 192 314

Local timeslot zone MaximumMS at 2 kbps/MS

100 120 120 120

Table 8-15 takes the current throughput per timeslot and calculates a PRP board service levelMTBR based on the requisite headroom. By dividing the PRP Board Service level MTBRthroughput (the maximum committable bandwidth) by the commitment per mobile (2 kbpsMTBR), a theoretical maximum limitation is calculated. In all but the worst-case scenario (allmobiles experiencing CS-1), the board level Service Capacity is not the limiting factor in thenumber of mobiles supported per board. The 120 mobile per board limit is the constrainingfactor. While considering the overall PRP capacity, the PRP service level headroom usually limitsthe number of mobiles on the PRP board, that is, as long as there are multiple cells on the PRPboard. For example, if the MTBR is set to 6 kbps in both uplink and downlink for all trafficclasses, interleaving is limited to one mobile per timeslot in the uplink and mobiles with multipleslots 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 beadmitted to the PRP board. With a combination of 20% CS-1 and 80% CS-2, 70 mobiles can beadmitted. 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 ARPValue. In other words, PFCs of a higher ARP Value are more likely to get access to the systemand get their requested MTBR.

The BSS attempts to ensure the ARP Value ordering of MTBR commitments throughdowngrading and preemption.

68P02900W21-T 8-51

Jul 2010

MTBR allocation Chapter 8: BSS planning for GPRS/EGPRS

Per timeslot commitment

The BSS commits a maximum of 6 kbps of MTBR in the downlink and in the uplink per GPRStimeslot on the air interface (and 12 kbps per EGPRS timeslot) when there are less than fourmobiles allocated on the timeslot. This maximum commitment per timeslot is independent of thetype of backhaul or the current coding schemes of the mobiles. The remaining throughput onthe timeslot the commitment is headroom and is allocated to the mobiles according to theirTHP weights. For timeslots that are configured as PCCCH timeslots, the BSS commits 0 kbps ofMTBR. PCCCH timeslots share both user data and control signaling. Therefore, the BSS doesnot make any MTBR commitments on the PCCCH timeslot. There could be a large amount ofcontrol signaling transmitting (which has higher priority than user data) that would not allowthe BSS to maintain MTBR on this timeslot.

To admit 4 mobiles per timeslot (required to satisfy 120 mobiles per PRP board), some of theheadroom on each timeslot can be used to admit a fourth mobile on to a timeslot, effectivelyincreasing the committable bandwidth on that GPRS timeslot to 8 kbps (and 14 kbps per EGPRStimeslot). This increase only occurs to admit a fourth mobile and is not done for any othernumber of mobiles on the timeslot, as using this headroom allows individual PFCs to operatefurther 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 allowsthe MTBR commitments to be maintained regardless of any coding scheme changes madeby the mobile.

Each traffic class has an associated MTBR that is configurable by the operator, or is fixedat zero. Within the interactive traffic class, each THP has its own associated MTBR that isconfigurable 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 3must 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 MTBRcan be fit into a single timeslot allocation no matter how the MTBR is set. This guarantees thatthese classes are not rejected by the system when timeslots are idle in the cell and availablethroughput exists on the PRP board.

Within the interactive traffic class, the THP 3 class has a maximum MTBR that can be fit into asingle timeslot allocation no matter how the MTBR is set. This means that a THP 3 is notrejected by the system when timeslots are idle in the cell and available throughput exists on thePRP board. THP 1 and THP 2 both support a maximum MTBR of 24 kbps in the downlink and 6kbps in the uplink. THP 1 and THP 2 are downgradable to THP3 so that they can be fit into asingle timeslot and thus are not rejected by the system when timeslots are idle in the cell andavailable 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 ofsupporting. 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. mstands 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

System Information: BSS Equipment Planning MTBR allocation

Table 8-16 Maximum MTBR in UL/DL per multislot capability

Mobile multislotclass

Multislot classsupported Possible configure Maximum MTBR

(uplink)Maximum MTBR

(downlink)

1 1 1 uplink timeslot1 downlink timeslot

m m

2 2 1 uplink timeslot2 downlink timeslots

m 2m

4 4 1 uplink timeslot3 downlink timeslots

m 3m

5 5 2 uplink timeslots2 downlink timeslots

m 2m

6 6 2 uplink timeslots2 downlink timeslots

or1 uplink timeslot3 downlink timeslots

m 2m

8 8 1 uplink timeslot4 downlink timeslots

m 4m

9 9 2 uplink timeslots3 downlink timeslots

m 3m

10 10 1 uplink timeslot4 downlink timeslots

or2 uplink timeslots3 downlink timeslots

m 3m

11 11 Class 10 or3 uplink timeslots2 downlink timeslots

m 2m

12 12 Class 10 or4 uplink timeslots1 downlink timeslot

m m

30 30 5 downlink timeslots1 uplink timeslot

m 5m

31 31 4downlink timeslots2 uplink timeslot

m 4m

32 32 3 downlink timeslots3 uplink timeslot

m 3m

33 33 2 downlink timeslots4 uplink timeslot

m 2m

Downlink timeslotUplink timeslot

For the cell with extended PDCH, when the QoS feature is enabled, the MS in the extendedrange is always admitted with MTBR = 0.

68P02900W21-T 8-53

Jul 2010

PRP-PDTCH QoS planning Chapter 8: BSS planning for GPRS/EGPRS

Biasable mobile commitment

The BSS limits its MTBR commitment to a biasable mobile (multislot classes 6 and 10, and anythat map to these classes) to the maximum MTBR allowed per timeslot multiplied by the numberof 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 atmost 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 downlinkand in the uplink per timeslot in that timeslot zone unless a fourth mobile is scheduled on thattimeslot. When scheduling the fourth mobile on a timeslot, the BSS allows a commitment to be 8kbps 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 eitherdirection. The remaining five timeslots are reserved as headroom for STNNT and PAP mobilesand for coding scheme changes. The total committable bandwidth is a function of the codingschemes 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 QoScapacity and QoS2 impact is calculated using the following steps:

• Calculate the PRP board throughput based on coding schemes used while subtractingPRP board headroom.

• Calculate the average downlink MTBR to determine the amount to reserve for each QoSsubscriber.

• Divide the PRP board throughput by the average downlink MTBR to determine theMAX_QOS_PDTCHS_PER_PRP.

Calculating PRP board throughput

PRP board throughput is calculated as follows:

8-54 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Calculating average downlink EGBR

PRPBOARDTHROUGHPUT = THRUPUT−TS∗{(8000 ∗%CSI−USAGE)+(12000∗%CS2−USAGE)+

(14400∗%CS3−USAGE) + ...... (20000∗%CS4−USAGE) + (8800∗%MCS1−USAGE) +(11200∗%) (MCS2−USAGE) + ...... (14800∗%MCS3−USAGE) + (17600∗%MCS4−USAGE) +(22400∗%) (MCS5−USAGE) + ...... (29600∗%MCS6−USAGE) + (44800∗%MCS7−USAGE) +(54400∗%) (MCS8−USAGE) + ...... (59200∗%MCS9−USAGE)} (1− 16.7)

Where: Is:

THRUPUT_TS the maximum TS worth of throughput that can besupported per PRP/PXP depending on deploymentand 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 schemeis used by subscribers in the cells attached to agiven PCU.

An MS in the extended range has a lower coding scheme than in the normal range due to thelonger distance between the MS and BTS. For the cell with extended PDCH, the lower codingscheme has a higher usage percentage value than the corresponding typical usage percentagevalue for a cell without extended PDCH.

Calculating average downlink EGBR

The EGBR is the additional throughput that is allocated to an operator that is sufficient toservice 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 downlinkEGBR first find the minimum value for r.

Average downlink Streaming EGBR is calculated as follows:

STR−EGBR = Average−GBR/p∗ (1 +BLER)

BLER is typically 10%-15%. The value of r is dependent on the transfer delay parameter for thestreaming service. The minimum transfer delay that the PCU supports is user configurable. Forplanning 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 streamingservice. The minimum transfer delay that the PCU supports is user configurable. For planningpurposes, 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 thenetwork.

68P02900W21-T 8-55

Jul 2010

Calculating average downlink EGBR Chapter 8: BSS planning for GPRS/EGPRS

This is obtained by multiplying the frequency of the service in the network by the GBR of theservice.

AverageGBR =N∑

i=1

GBRi∗FSi/STRi

Where: Is:

N the number of streaming services types in the network.

GBRi the GBR of streaming service i.

FSi the percentage of streaming service i in service mix of subscribers in a givenPCU.

STRi the percentage of total streaming service in service mix of subscribers ina 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 thePCU, in networks where the majority of streaming services have GBR of 15 kbps or lower, forexample, PoC. In practice, where an application does not need a stringent transfer delay, r islarger for that application, resulting in less EGBR required for a particular GBR. The defaultminimum 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 Transferdelay (ms) ρ Min Transfer

delay (ms) ρ Min Transferdelay (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

System Information: BSS Equipment Planning Calculating average downlink EGBR

Table 8-17 ρ for various transfer delays at GBR 15 kbps or less (Continued)

Min Transferdelay (ms) ρ Min Transfer

delay (ms) ρ Min Transferdelay (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 and250 ms. In networks where the configured minimum transfer delay parameter has been set tobe greater than 500 ms, use the table for the transfer delay of 500 ms. First determine the GBRfor 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 evaluatethe two closest GBR values and select the value resulting in the lower r value.

68P02900W21-T 8-57

Jul 2010

Calculating average downlink EGBR Chapter 8: BSS planning for GPRS/EGPRS

Table 8-18 ρ for Transfer delay = 500 ms at GBR greater than 15 kbps

Min Transferdelay (ms) ρ Min Transfer

delay (ms) ρ Min Transferdelay (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

8-58 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Calculating average downlink EGBR

Table 8-19 ρ for Transfer delay = 250 ms at GBR greater than 15 kbps

Min Transferdelay (ms) ρ Min Transfer

delay (ms) ρ Min Transferdelay (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 EGBR Chapter 8: BSS planning for GPRS/EGPRS

Calculating average downlink MTBR

Average downlink MTBR is calculated as follows:

AV ERAGEDOWNLINKMTBR = (STR−EGBR∗%subs−STR) + (I1MTBR∗%subs−I1) +(I2MTBR∗%subs−I2) + .... (I3−MTBR∗%subs−I3) + (BG−MTBR∗%subs−BG) +(BE−MTBR∗%subs−BE)

Where: Is:

STR_EGBR the throughput required to guarantee downlink GBR and averagetransfer delay for the streaming traffic class.

I1_MTBRI2_MTBRI3_MTBRBG_MTBRBE 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 inthe system based on subscription or by default based on no QoSsubscription or roaming subscribers entering the system and havingtheir QoS attributes negotiated to a traffic class.

NOTEThe MTBR values are defined at the cell level. The values to use for this equation areeither the average MTBRs for each traffic class across all cells connected to a PCU orthe 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 (whichneeds large EGBR), it is advisable that the PRP/PXP operates in mode 2. This is because mode2 maximizes throughput rather than coverage, whereas mode 1 increases coverage at theexpense of throughput. It is anticipated that in networks where QoS is enabled, data servicesare no longer in the initial deployment stage and hence the option that maximizes throughputis most appropriate.

However, before deciding on the mode, verify the MS per PRP number that can be supportedversus maximizing coverage for mode 1 and mode 2. This information enables to decide uponthe 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 mode2 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

System Information: BSS Equipment Planning Calculating average downlink EGBR

NOTE240 kbps is determined from 8 kbps (CS1) * 30 TS and 384 kbps is determined from 8kbps (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 of72 mobiles. Therefore, the PRP board places the limit on the number of supported mobiles to 72mobiles over the 48 TS of coverage. In this example, mode 1 can support more mobiles thanmode 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 8kbps then in mode 1, only 30 mobiles (240/8) can be simultaneously supported over 120 TS andfor mode 2, 48 mobiles can be simultaneously supported. Mode2 support more mobiles thanmode1, achieving a PRP board throughput of 384 kbps (48×8), and therefore in this situationmode 2 operation is preferred.

This approach can be summarized in the following manner: If the planned average bit rate permobile is R kbps then for mode 1: mobile numbers = Min (240/R, 120); for mode 2: mobilenumbers = Min (384/R, 72). This relationship is plotted for the two modes in the followinggraph. 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 Chapter 8: BSS planning for GPRS/EGPRS

CTU2D impact

When CTU2D is configured in ASYM mode LA algorithms and when admitting a mobile, BSSlimits 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 whenadmitting a new mobile on Carrier B. MCS3 is selected since it offers a reasonable compromiseof throughput versus link performance, whereas MCS4 is uncoded (code rate = 1) and thereforeit is only appropriate in favorable channel conditions.

8-62 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 thepoint-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 reservedfor E1 synchronization. Each timeslot uses a rate of 64kbps.

Frame relay bearer channel(FR BC)

The bearer channel allows the frame relay protocol tomap its resources to the E1 layer.

Permanent virtual circuit (PVC) A frame relay virtual circuit. This allows the packetswitched FR network to act as a circuit-switchednetwork by guaranteeing an information rate and timedelay for a specific PVC.

Data link connection identifier(DLCI)

A unique number assigned to a PVC end point in a framerelay network.

IP endpoint An endpoint is defined by its IP address and the UDPport. An IP endpoint can be a data endpoint and/or asignaling endpoint.

Continued

68P02900W21-T 8-63

Jul 2010

General planning guidelines Chapter 8: BSS planning for GPRS/EGPRS

Table 8-20 Gb entities and identifiers (Continued)

Gb Entity and Identifier Description

Data traffic The data traffic for an IP Sub-Network is defined as NSSDUs for PTP and PTM functional entities (BVCI ≥ 1). InMotorola GB Over IP load sharing algorithm, the Datatraffic refers to NS SDUs that need to be load sharedby the ULC.

Signaling traffic The signaling traffic for an IP Sub-Network is defined asNS SDUs for signaling functional entities(BVCI = 0) and all PDUs for IP Sub-Network ServiceControl. In Motorola GB Over IP load sharing algorithm,the signaling traffic refers to the NS SDUs that need tobe load shared by the GBM and FBM.

Network service entity (NSE) An instance of the NS layer. Typically, one NSE is usedfor each PCU being served by an SGSN. The NSE hassignificance across the network, and is therefore thesame at the SGSN and PCU.

Network service entityidentifier (NSEI)

Uniquely identifies an NSE.

Network Service Virtual Circuit(NSVC)

A logical circuit that connects the NSE peers betweenthe SGSN and PCU. The NSVC has significance acrossthe network. Therefore, it is configured identically atthe SGSN and PCU.

Network Service Virtual CircuitIdentifier (NSVCI)

Uniquely identifies an NSVC. There is a one-to-onemapping between the NSVCI and DLCI.

BSSGP virtual circuit (BVC) A logical circuit that connects the BSSGP peers betweenthe BSS and SGSN. It is only configured in the PCU. ThePCU contains one point-to-point BVC per an activelyserving cell.

BSSGP Virtual Circuit Identifier(BVCI)

Uniquely identifies a BVC.

General planning guidelines

These are the general planning guidelines:

• 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 dynamicallyconfigured at the SGSN.

• There are multiple NSVCs serving one NSE.

• There is a one-to-one mapping between Frame relay NSVCIs and DLCIs.

8-64 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Specific planning guidelines

• There is a one-to-one mapping between the IP-based NSVCI with the PCU IP/UDP portand the SGSN IP/UDP port pair.

• Multiple DLCIs can share the same bearer channel, and therefore the same timeslotgrouping. A bearer channel can be mapped between one and 31 DS0s, depending on thethroughput 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 linkcapacity limitations in each Gb link plan.

Gb protocol signaling

The GPRS/EGPRS Mobility Management (GMM/EGMM) signaling procedures that contribute touplink 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 netload that must be delivered to each PCU served by the SGSN.

68P02900W21-T 8-65

Jul 2010

Gb link timeslots (for Frame relay Gb) Chapter 8: BSS planning for GPRS/EGPRS

Base formulae

Use the following base formulae to determine the load expected on the Gb interface:

Signaling−Data−Rate (bytes/s) =

(21∗Cellupdate + 312∗PSAttach/Detach + 125∗RAU + 172∗PDPAct/deact

)

∗ Subscribers−per−PCU3600

+ 89∗PGPRS

User−Data−Rate (bytes) =

{(Subscribers−per−PCU ∗Data−Subscriber∗1000)

(1 + 71

PKSIZE

)}

3600Total−Date−Rate (bytes/s) = Signaling−Data−Rate+ User−Data−Rate

Where: Is:

Total Data Rate the required bandwidth (bit/s) for GPRS/EGPRS data transmissionover a GBL interface between the PCU and SGSN after all of theprotocol and signaling overhead is accounted for.

Signaling_Data_Rate the required rate (bytes/s) for GPRS/EGPRS signalingtransmission over a GBL interface between the PCU and SGSNafter all of the protocol.

User Data Rate the required rate (bytes/s) for GPRS/EGPRS user applicationdata over a GBL interface between the PCU and SGSN, includingprotocol 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

PKSIZE

the GPRS paging rate (per sec).

the average packet size, in bytes.

Subscribers_per PCU the average number of GPRS/EGPRS subscribers supported ona 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.

NOTETo simplify Gb planning, the Signaling_Data_Rate can be ignored since it isinsignificant 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 ofrequired 64 kbps Gb link timeslots can be calculated using the equation given. Each E1 cancarry up to 31 timeslots. When fewer than 31 timeslots are needed on an E1, specifying afractional E1 is more cost effective.

8-66 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Frame relay parameter values

No−GBL−TS = Total−Data−Rate/ (8000∗UGRI)

NPCU−SGSN = No−GBL−TS/31

Where: Is:

No_GBL_TS the number of timeslots to provision on the GBL E1 between the PCUand SGSN. This value can be used to specify a fractional E1.

Total_Data_Rate defined by the equation in the previous section, and represents therequired bandwidth (bps) for GPRS/EGPRS data transmission over aGBL interface between the PCU and SGSN after all the protocol andsignaling overhead is accounted for.

UGBL the link utilization.

NPCU-SGSN the E1 link between the PCU and SGSN.

Frame relay parameter values

The network planner should specify the values for the following three frame relay interfaceparameters:

• 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 andillustrated in Figure 8-12.

Figure 8-12 Frame relay parameters

ti-GSM-Frame_relay_parameters-00142-ai-sw

68P02900W21-T 8-67

Jul 2010

Frame relay parameter values Chapter 8: BSS planning for GPRS/EGPRS

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 PCUdistributes the use of all the NSVCs by the subscribers evenly in a round-robin manner. Theround-robin algorithm continuously assigns subscribers to the next NSVC in a sequentialmanner when a subscriber PDP context is established. If an NSVC becomes unavailable, it isskipped over, and the next available NSVC in the round-robin is used. The BSSGP featureinherently provides load sharing over all available NSVCs. The BSSGP high-level protocol layerprovides 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, halfthe cumulative information rate of the active timeslots routed to the NSVC. This mapping isdetermined 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 numberof timeslots planned for the busy hour traffic load.

The recommended frame relay network CIR value is calculated as follows:

CIR−V alue =F ∗Total−Data−Rate

∗8Num−NSV C

Where: Is:

CIR_Value the committed Information rate per NSVC (PVC).

F the CIR provisioning factor, equal to 0.5.

Total_Data_Rate defined in Determining net Gb load on page 8-65, and representsthe required bandwidth (bit/s) for GPRS data transmission over aGBL interface between the PCU and SGSN after all the protocol andsignaling overhead is accounted for.

By using half the number of timeslots in the CIR calculation, the load of all the timeslots isserved by the combination of the CIR and Bc frame relay network rated capacity. This strategyuses the overload carrying capacity of the frame relay network when more than half of theplanned timeslots are in use.

When a cell uses all of its provisioned timeslots as active timeslots (that is, timeslots beingprocessed by the PCU at that instance in time), other cells must use fewer of their timeslotsbeing processed for the overall PCU Gb interface bandwidth allocation to be within configuredframe relay network interface parameter (CIR, Bc, Be) values. The BSS attempts to utilize asmany 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, undernormal conditions, during a time interval Tc.

Configure the Bc value such that if one of the provisioned E1 links fails, the remaining E1 linkscan carry the load of the failed link, by operating in the Bc region. For example, with three E1links provisioned, if any one of the three should fail, the other two should have the capacity tocarry the load of the failed link on the remaining two links, by operating in the Bc region.

8-68 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 framerelay network can attempt to deliver, during a time interval Tc. The network treats Be dataas discardable.

Gb link (for Ethernet Gb)

The Ethernet Gb link can carry both the data traffic and NS signaling. The number of required100M/1000M Ethernet Gb links are calculated using the principle that average throughput ofeach Ethernet GBL does not lead the 70% of PPROC CPU_usage exceeded under the standardcall model and with the PRP function of the PPROC is fully loaded. Assume the traffic model ofdownlink load/uplink load is 4:1, and use the downlink load only to calculate the required GbEthernet links. The required Gb link NPCU-SGSNis calculated using the following equation:

NPCU−SGSN =Total−Data−Rate ∗ 8

GBL−Throughput−ETH+ 1

+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 page8-66. It represents the required bandwidth (bps) forGPRS/EGPRS data transmission over a GBL interfacebetween the PCU and SGSN after the protocol andsignaling overhead per call model is accounted for.

GBL_Throughput_ETH This indicates the average downlink throughputon one Ethernet GBL without exceeding 70% ofthe PPROC CPU_usage, while the PXP baseboard,PPROC, and all PRP functions are fully loaded. Tosupport the peak/mean throughput ratio of 2:1 andassume 4:1 traffic model of downlink load/uplink load,GBL_Throughput_ETH is 5 Mbps for prp_fanout_mode1 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/NSVCparameters:

• 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

Gb link (for Ethernet Gb) Chapter 8: BSS planning for GPRS/EGPRS

• The NS_VC load sharing function for the IP sub-network determines the local IP endpointand 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 therelative weights assigned by the peer NSE. Both signaling-weights and data-weights havea value range of 0 to 255.

• Outgoing BVCI = 0 NS-SDUs are sent to a remote IP endpoint according to the signalingweight assigned by the peer NSE. The sending NSE distributes these messages in equalproportion 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 asthe IP endpoint (A).

• If the IP endpoint (A) has signaling weight = 10 and the IP endpoint (B) has signalingweight = 10, IP endpoint (A) and IP endpoint (B) are selected as the signaling IP endpointis on an equal basis.

• If the IP endpoint (A) has a signaling weight = 0, IP endpoint (A) is not selected as thesignaling IP endpoint.

For each BVCI>0 NS-SDU, the PCU selects a remote IP endpoint based on the LSP for sendingthe NS-SDU to the peer NSE. Remote IP endpoints are selected in equal proportion to thedata-weights assigned to the endpoints of the peer NSE. A data weight of 0 assigned to an IPendpoint indicates that the load sharing function is not initially associated with this remote IPendpoint to an LSP. However, if an LSP is already associated with a remote IP endpoint, NSSDUs associated with the LSP are sent to this remote IP endpoint regardless of their dataweight, that is, even when the data weight has a value of 0. (This association of the LSP to theIP endpoint with a data weight of 0 may have been requested by the remote NSE through theResource 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, theendpoint (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 equalbasis.

• If the IP endpoint (A) has a data weight = 0, the IP endpoint (A) is selected for initialassociation with an LSP. However, the IP endpoint (A) may be associated with an LSP usingthe peer NSE of the Resource Distribution Function.

Once a remote IP endpoint is selected for the LSP, the NSE maintains a link between the LSPand the remote IP endpoint so that NS SDUs with the same LSP are directed to the same remoteIP endpoint. If a remote IP endpoint associated with an LSP is taken OOS, another remote IPendpoint is selected according to the data-weights assigned by the peer NSE and the associatedLSP. The association of an LSP to a remote IP endpoint can be changed by the peer NSE usingthe Resource Distribution function.

8-70 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Gb link (for Ethernet Gb)

As the signaling NSVC may share the same local socket, physical Ethernet port and IP routeas data traffic along the path to the SGSN, configure the data and signaling NSVCs differentGBL/ETH links. For example, configure one NSVC with non-zero signaling weight and zerodata weight, so this NSVC can be guaranteed for NS signaling traffic overcoming the priorityhandling problem for signaling traffic during periods of high data traffic. However, this willexhaust more GBL/ETH port resource, so it is important to balance the resource betweensignaling and data traffic. With the above configuration, however, there may be situationswhere GPRS becomes OOS due to either all signaling or all data NSVC being OOS. During sucha situation, PCU will trigger the appropriate NSVC failure alarm and block all BVCs underthis BSS/PCU. For signaling and data, NSVCs are separated in different GBL/ETH links. N+1GBL/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 meshconnectivity (any IP endpoint in an NSE is capable of communicating with any IP endpoint inits peer NSE as shown in Figure 8-13) between the PCU and SGSN is necessary. The numberof NSVCs required for full mesh connectivity between the PCU and SGSN is the product ofthe number of IP endpoints supported on each side. It is recommended to configure thesignaling/data weight to each remote IP endpoint with the consistent value for the full meshconnection.

Figure 8-13 Gb over IP full mesh connectivity between PCU and SGSN

SGSN

IP Endpoint

PPROCBASE

Weight = 1 Weight = 2 Weight = 3

PCU

ETHport

ETHport

PXPPXP

BASE PPROC

IP Endpoint IP Endpoint

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 Chapter 8: BSS planning for GPRS/EGPRS

BSS-PCU hardware planning example for GPRS■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

This section provides an example of the PCU hardware provisioning process and the linkprovisioning process associated with adding a PCU to the BSC as shown in Figure 8-14. Forthe provisioning of the BSC hardware, the network planner should follow the relevant planningrules 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 featureis not enabled.

Figure 8-14 PCU equipment and link planning for GPRS

BSC

BTS

PCU SGSN

GDS+GSL

E1 or ETH

GSM GPRS E1

GBL

E1 or ETH

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 percell, 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

PS attach/detach rate (per sub/BH) PSattach/detach = 0.5

Continued

8-72 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSS - PCU planning example for GPRS

Table 8-21 GPRS call mode (Continued)

Item Value

PDP context activation/deactivation (persub/BH)

PDPact/deact = 0.4

Routing area update RAU = 1.4

Cell Updates CellUpdate = 0.33

GPRS paging rate in pages per second PGPRS = 18.73

GPRS users per cell 200

Average sessions per user per hourGSM circuit-switched paging rate(pages/second)

0.45

PGSM = 60

Ratio of LCSs per call LCS = 0.1

Mobile terminated LCS ratio LRMT = 0.95

Ratio of mobiles in the system that are bothGSM 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 Distribution Rate

CS1 20% 8 kbps

CS2 45% 12 kbps

CS3 25% 14.4 kbps

CS utilization

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 andBLER 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 additionalcontrol channel load for the GPRS data traffic with the existing circuit-switched traffic load ontothe CCCH. On the other hand, when pccch_enabled = 1 at the cell, GPRS does not add anyadditional control channel load on the CCCH. In this case, however, PCCCH reduces the GSMcircuit-switched signaling load on the CCCH.

68P02900W21-T 8-73

Jul 2010

BSS - PCU planning example for GPRS Chapter 8: BSS planning for GPRS/EGPRS

The network planner is required to consider paging coordination, the expected paging rate andthe access grant rate to calculate the number of CCCH blocks needed. Perform this calculationusing the guidelines given in the Control channel calculations on page 3-52 section of Chapter 3BSS 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 cellbasis. To use this equation, the network planner should have the expected cell load in kbps.

Mean−traffic−load =GPRS−Users

∗Data−rate−per−sub−downlink∗80bits/byte

3600= 200∗90.73∗8/3600 = 40.32kbit/s

TS−Data−Rate =1

100

4∑

i=1

Csi−ERate∗CSi−Utilization =

(8∗20 + 12∗45 + 14.4∗25 + 20∗10)100

= 12.6kbit/s

No−PDCH−TS = Roundup

(Mean−Traffic−load

∗Mean−load−factor

TS−Data−Rate+NPBCCH +NPAGCH +NPPCH

12

)

= Roundup

(40.32∗2

12.6+

4 + 0.0264 + 38.7112

)= 11

Calculating the number of active timeslots

Assuming that coverage is to be provided to at least half of the timeslots at any instance, thenumber of mean 11/2 = 6 PDTCHs (from Determining the number of GPRS carrier timeslots ateach 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), thenumber 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 standbytimeslots per cell.

Compute the number of GDS TRAU E1 channels required for the air interface timeslots requiredto carry the traffic. Remember:

• Each CS1/CS2 timeslot requires 16k TRAU channel, CS3/CS4 timeslots requires 32k TRAUon GDS TRAU interface.

8-74 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSS - PCU planning example for GPRS

• CS3/CS4 is enabled on a carrier hence all the GPRS timeslots for that carrier wouldrequire 32k TRAU.

Using the conservative provisioning rule of one GDS TRAU E1 per PRP, 4 GDS TRAU E1s areprovisioned.

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 theBSS planning rule for LCF provisioning in the following equation.

GL3−GPRS = 0.002∗Total−RACH/sec∗(1−RPCCH−Cells

)+ 0.00075∗B∗P ∗

GPRS PCCCH−BSS

= 0.002∗(200∗20∗5

5) ∗ (1− 0.5) + (0.00075∗10) ∗ (18.73∗1) = 0.146

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 GSMcircuit-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∗PSAttach/Detach + 125∗RAU + 172∗PDP ∗

Act/Deact

Subscribers−per−PCU

3600+ 89∗PGPRS

= (21∗0.33+312∗0.5+125∗1.4+172∗0.4)∗20∗2003600 + 89∗18.73

= 2119bytes/sUser−Data−Rate =

(GPRS−Users−PCU

∗Data−rate−per−sub∗1000

3600

)+(

1 + 71PKSIZE

)

=(

200∗20∗90.73∗10003600

)∗(1 + 71

310.08

)= 123894 bytes/s

No−GBL−TS = Roundup(Signaling−Data−Rate+User−Data−RateData−Rate−Per−GBL∗UtilizationGBL

)

= Roundup( 2119+123894

8000∗0.25

)= 63

NPCU−SGSN = No−GBL−TS31 = 63

31 = 2.03

Hence, 3 Gb links have to be provisioned.

If the ETH GBL is used as the Gb over IP feature enabled, then:

NPCU−SGSN = Roundup[

(2119 + 123894) ∗ 8GBL−Throughput−ETH

]+ 1

Considered the “GBL_Throughput_ETH” is 5 Mbps, hence, provide 2 Gb links.

68P02900W21-T 8-75

Jul 2010

BSS - PCU planning example for GPRS Chapter 8: BSS planning for GPRS/EGPRS

Calculating the number of GSL links

Use the following equation to calculate how many 64 kbits/s GSL links are required. For thisexample, the number of users on a PCU is 5000. It assumes that all 20 cells parented to a singleLCF card in the BSC, after performing this step. Evaluating this equation and the supportingexpressions results in one 64 kbps GSL link being required, assuming that enhanced one phaseis 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 planningsteps and rules for further details on the following equations.

Total−RACH/sec =Total−cells

∗GPRS−users−per−cell∗Averagesessions

3600

=(20∗200) ∗ (0.45)

3600= 0.5/s

RPCCH−Cells =number−of−PCCCH − enabled−cellstotal−number−of−cells−in−BSS

= 10/20 = 0.5

GSLRACH =(1− 0.5) ∗ 0.5 ∗ 7.5

1000 ∗ 0.25= 0.075

GSLPaging =8.5∗18.73∗1∗1

1000∗0.25= 0.64

The number of GSL TSs for run time is represented by:

GSLrun−time = GSLPaging +GSLRACH = ROUND−UP (0.64 + 0.075) = 1

The number of GSLs required is:

GSL = MAX(GSLrun−time, GSLinit−time

)= MAX (1, 6) = 6

Calculating the PCU hardware to support the PCU traffic

To calculate the PCU hardware for supporting the PCU traffic, consider the followingrequirements.

• 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 boardfor 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 PRPboards.

• 1 PCU cabinet per 3 PCU shelves (cages).

After calculating the number of GDS, GBL and GSL E1 links, ensure that there are sufficientnumber of PICP boards to cover the GBL and GSL E1 links. The PCU hardware calculationcalculates 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 PICPboards for the GBL and GSL E1 links. A PICP board can terminate both GBL and GSL links onthe board, but not on the same PMC module. Each PICP has two PMC modules.

8-76 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSS - PCU planning example for GPRS

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 upto 2 E1 GSL links and up to 12 GSL 64 kbps timeslots distributed over two E1s.

NOTEThere is a limit of 2 GSL E1s per PCU. Therefore, 1/4 of a PICP is required for theGSL E1 link.

The GBL and GSL E1 link requirements show that 2 PICPs are sufficient to process the linkprovisioning requirements.

Calculating the increased data traffic load on the E1s between the BSCand BTSs

It is assumed that the GPRS traffic is in addition to the existing circuit-switched traffic. Sixtimeslots are required for the GPRS timeslot traffic on a per cell basis. Therefore, an additional12 x 16 kbits/s timeslots (CS1/CS2) or 32 kbps timeslots (CS3/CS4) are required on a per BTSsite 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 orswitchable. GSM circuit-switched statistics can be used to decide about the allocation. Refer toDynamic timeslot allocation on page 3-76 in Chapter 3 BSS cell planning.

Calculating the changes in signaling traffic load (RSL load) on the E1sbetween the BSC and BTSs

For cells without PCCCH (pccch_enabled = 0), the BTS combines the additional signalingload for the GPRS data traffic with the existing circuit-switched traffic load. This results in anadditional 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 andother supporting equations.

Refer to Determining the number of RSLs required on page 6-22 in Chapter 6 BSC planningsteps and rules for further details on the following equation.

RSLGPRS +GSM = RSLGPRS +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. ForBSC 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 insupport of the additional GPRS traffic over the BTS to BSC interface. In this example, 4 E1swere added for the GDS links and 3 E1s added for the GSL link.

68P02900W21-T 8-77

Jul 2010

BSS - PCU planning example for GPRS Chapter 8: BSS planning for GPRS/EGPRS

BTS provisioning impact

GPRS has no impact on the hardware provisioning of a Horizon II macro, Horizonmacro orM-Cell BTS.

8-78 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSS-PCU hardware planning example for EGPRS

BSS-PCU hardware planning example for EGPRS■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

NOTEThis section builds upon the previous example shown in BSS-PCU hardware planningexample 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

BSC

BTS

PCU SGSN

GDS+GSL

E1 or ETH

GSM EGPRS E1

GBL

E1 or ETH

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.

NOTERefer to BSS - PCU planning example for GPRS on page 8-72 to compare theGPRS/EGPRS call model parameters.

68P02900W21-T 8-79

Jul 2010

BSS - PCU planning example for EGPRS Chapter 8: BSS planning for GPRS/EGPRS

Use this example to provision a BSS with 10 sites consisting of 20 cells, one GPRS carrier percell, 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

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

GPRS and EGPRS Traffic per sub/BH (kBytes/hr) -downlink

Data rate_per sub = 92.38

PS attach/detach rate (per sub/BH) PSATT/DETACH = 0.5

PDP context activation/deactivation (per sub/BH) PDPACT/DEACT = 0.4

Routing area update RAU = 1.4

Cell Updates CellUpdate = 0.33

GPRS paging rate in pages per second PGPRS = 18.73

GPRS/EGPRS users per cell 250

Average sessions per user per hour 0.45

GSM circuit-switched paging rate (pages/second) PGSM = 60

Ratio of LCSs per call LCS = 0.1

Mobile terminated LCS ratio LRMT = 0.95

Ratio of mobiles in the system that are both GSM andGPRS capable

NGSM GPRS MS/NAU MS = 100%

Percentage of mobiles that are EGPRS capable 5%

Continued

8-80 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSS - PCU planning example for EGPRS

Table 8-22 EGPRS call model (Continued)

Item Value

Total number of cells in the BSS 20

CS Distribution Rate

CS1 10% 8

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

CS utilization

Total 100%

Selecting a cell RF plan

Use the 4 x 3 non-hopping table (Table 3-16 in Chapter 3 BSS cell planning) to determine thevalues 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 additionalcontrol channel load for the GPRS data traffic with the existing circuit-switched traffic load ontothe CCCH. On the other hand, when pccch_enabled = 1 at the cell, GPRS does not add anyadditional control channel load on the CCCH. In this case, however, PCCCH reduces the GSMcircuit-switched signaling load on the CCCH with paging coordination. The network planner isrequired to consider paging coordination, the expected paging rate, and the access grant rate tocalculate the number of CCCH blocks needed.

Perform this calculation using the guidelines given in Control channel calculations on page3-52 in Chapter 3 BSS cell planning.

68P02900W21-T 8-81

Jul 2010

BSS - PCU planning example for EGPRS Chapter 8: BSS planning for GPRS/EGPRS

Determining number of GPRS and EGPRS carrier timeslots at each BTS cell

Use the equation to determine the number of GPRS timeslots that are required on a per cellbasis. To use this equation, the expected cell load in kbps should be known.

Mean−Traffic−Load =GPRS−Users

∗Data−rate−per−sub∗8 bits/byte

3600

=250∗92.38∗8

3600= 51.32kbit/s

TS−Data−Rate =1

100

(i=4∑

i=1

Csi−Rate∗Csi−distribution+

9∑

i=1

MCsi−Rate∗MCSi−distribution

)

17.41 kbit/s

No−PDCH−TS = Roundup

{Mean−Traffic−load

∗Mean−Load−factor

TS−Data−Rate

}

= Roundup

{51.32∗217.41

}= 6

Therefore, provide 6 timeslots on the cell. If the number of users, Mean_traffic_load andTS_Data_Rate has increased with the EGPRS capabilities, the timeslots calculation does notincrease as per the GPRS calculation. The new equation provides 6 timeslots but these aredivided between GPRS and EGPRS. In this example, l has 8 GPRS timeslots configured asswitchable or packet data from the original GPRS carrier and 8 timeslots defined as packet datafor the new EGPRS carrier for a total of 16 data capable timeslots per cell. This is a total of320 data capable timeslots.

Calculating the number of active timeslots

For prp_fanout_mode1, a PRP board can be assigned up to 120 timeslots but only 30 can beserviced (active) at any given time. A PXP board can be assigned up to 280 timeslots but only 70can be serviced (active) at any given time. For prp_fanout_mode2, 48 timeslots provisionedby a PRP can be served at any given time interval. 140 timeslots provisioned by a PXP can beserved at any given time interval. The PRP/PXP algorithms handle the scheduling of timeslotsefficiently, 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 andEGPRS, 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

System Information: BSS Equipment Planning BSS - PCU planning example for EGPRS

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 thenumber 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.

NOTEEach PXP must terminate one GDS TRAU_LAPD ETH link and the timeslots of anentire 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_Blocksfor each GDS ETH link. But considering the capacity enhancement in the future and thesituation one PXP failure, 10 tdm_ts_blocks is recommended.

Calculating the BSC LCF impact to support GPRS traffic

The volume of GPRS and EGPRS signaling traffic increases the BSC LCF GPROC2 processorload. Use the BSS planning rule for LCF provisioning in the following equation.

GL3−GPRS =[

0.002∗Total−RACH/sec∗(1−RPCCCH−Cells

)+ 0.00075∗B∗

P ∗GPRS PCCCH−BSS

]

= 0.002∗(

250∗20∗0.453600

)∗ (1− 0.5) + 0.00075∗10∗18.73∗1 = 0.14

An additional LCF GPROC2 can be added or the GSM circuit-switched provisioning can beexamined to check if an existing LCF GPROC2 can process this additional load.

68P02900W21-T 8-83

Jul 2010

BSS - PCU planning example for EGPRS Chapter 8: BSS planning for GPRS/EGPRS

Calculating the number of GBL links

Using the standard traffic model and Gb formulae:

Signaling−Data−Rate =

(21∗CellUpdate + 312∗PSAttach/Detach + 125∗RAU + 172∗PDPACT/Deact

)

∗ Subscribers−per−PCU3600

+ 89∗PGPRS

=(21∗0.33 + 312∗0.5 + 125∗1.4 + 172∗0.4) ∗20∗250

3600+ 89∗18.73

= 2649 bytes/s

User−Data−Rate =(GPRS−Users−PCU

∗Data−rate−per−sub∗1000

3600

)∗(

1 +71

PKSIZE

)

=(

250∗20∗92.38∗10003600

)∗(

1 +71

435.97

)= 149200.77 bytes/s

No−GBL−TS =Total−Data−rate

8000∗UGRI=

2649 + 149200.778000∗0.25

= 75.92

NPCU−SGSN = No−GBL−TS/31 = 75.92/31 = 2.45

Hence, provide 3 Gb links.

If the ETH GBL is used s the Gb over IP feature enabled:

NPCU−SGSN = Roundup[

(2119 + 123894) ∗ 8GBL−Throughput−ETH

]+ 1

Considered the “GBL_Throughput_ETH” is 4.9 Mbps in prp_fanout_mode 2, hence, provide2 Ethernet GBL link.

Calculating the number of GSL links

Use the following equation to calculate the number of 64 kbits/s GSL links required. In thisexample, the number of users on a PCU is 5000. It assumes that all 20 cells are attached to asingle LCF card in the BSC. Evaluating this equation and the supporting expressions resultsin one 64 kbps GSL link being required, assuming that preload is enabled, after rounding upto the nearest integer value (but not including redundancy).

Refer to Determining the number of GSLs required on page 6-50 in Chapter 6 BSC planningsteps and rules for further details on the following equations:

Total−RACH/sec = 20∗250∗0.45/3600 = 0.625

GSLRACH = (1− 0.5) ∗0.625∗5.5/ (1000∗0.25) = 0.006875

GSLPaging = 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 +GSLPaging = Roundup (0.006875 + 0.64) = 1

8-84 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSS - PCU planning example for EGPRS

The number of GSL required is

GSL = MAX(GSLrun−time,GSLinit−time

)= 6

Calculating the PCU hardware to support the PCU traffic

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 12PXP 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 sufficientnumber of PXP boards to cover the GBL and GSL links. Both GBL and GDS TRAU_LAPD linkscan terminate on a PXP board. Each PXP has two PMC modules supporting 2 GBL and 1 RJ45port supporting 1 ETH link.

Calculating the increased data traffic load on the E1s between the BSCand BTSs

It is assumed that the EGPRS traffic is in addition to the existing circuit-switched traffic andGPRS traffic already available in the system. In Determining the number of CCCHs at each BTScell on page 8-88, it was determined that 8 timeslots would be required for the EGPRS requiredon 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 EGPRScarrier timeslots. When EGPRS enabled, all reserved and switchable timeslots are backhauledfrom the BTS through the BSC to the PCU. The physical link calculations must take thisinto account. The CPU processing equations require to take into account the percentage ofbackhauled timeslots that are active at a given time interval. If GSM circuit-switched statisticsare available, they could be reviewed to aid in this decision. Refer to Dynamic timeslot allocationon page 3-76 in Chapter 3 BSS cell planning.

Calculating the changes in signaling traffic load (RSL load) on the E1sbetween the BSC and BTSs

For cells without PCCCH (pccch_enabled = 0), the BTS combines the additional signaling loadfor the EGPRS data traffic with the existing circuit-switched traffic load. This results in anadditional 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.

68P02900W21-T 8-85

Jul 2010

BSS - PCU planning example for EGPRS with QoS enabled, QoS2 not enabled Chapter 8: BSS planning for GPRS/EGPRS

The new load on the RSL for GPRS is based on the evaluation of the following equation andother supporting equations. Refer to Determining the number of GSLs required on page 6-50 inChapter 6 BSC planning steps and rules for further details on the following equation.

RSLGPRS+GSM = RSLGPRS +RSLGSM

Perform the GSM RSL calculation with 64 kbps RSL to be consistent with the EGPRS calculation.

BSC link provisioning impact

The BSC can need additional hardware to support the addition of the EGPRS network traffic. ForBSC 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 toBSC 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 - PCUplanning example for EGPRS on page 8-79 except that the QoS feature is enabled. Specify newcall model parameters based on QoS usage as the QoS requirement.

NOTERefer to BSS - PCU planning example for EGPRS on page 8-79 to compare theGPRS/EGPRS call model parameters.

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 andEGPRS traffic mix (bytes)

PKULSIZE = 188.71

Average packet size for GPRS andEGPRS traffic mix (bytes)

PKDLSIZE = 435.97

GPRS and EGPRS Traffic per sub/BH(kBytes/hr) - uplink

ULRATE = 35.59

GPRS and EGPRS Traffic per sub/BH(kBytes/hr) - downlink

Data rate_per sub = 92.38

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

PS attach/detach rate (per sub/BH) PSATT/DETACH = 0.5

PDP context activation/deactivation (persub/BH)

PDPACT/DEACT = 0.4

Routing area update RAU = 1.4

Cell Updates CellUpdate = 0.33

GPRS paging rate in pages per second PGPRS = 18.73

GPRS/EGPRS users per cell 250

GSM circuit-switched paging rate(pages/second)

PGSM = 60

Ratio of LCSs per call LCS = 0.1

Mobile terminated LCS ratio LRMT = 0.95

Ratio of mobiles in the system that areboth GSM and GPRS capable

NGSM GPRS MS/NAU MS = 100%

Percentage of mobiles that are EGPRScapable

5%

Total number of cells in the BSS 20

I1_MTBR 14

I2_MTBR 10

I3_MTBR 4

BG_MTBR 2

BE_MTBR 2

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

BSS - PCU planning example for EGPRS with QoS enabled, QoS2 not enabled Chapter 8: BSS planning for GPRS/EGPRS

Table 8-23 EGPRS with QoS enabled call model (Continued)

Item Value

CS Distribution Rate

CS1 10% 8

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

CS distribution

Total 100%

Selecting a cell RF plan

The PRP board headroom compensates the BLER required for QoS. The CS coding schemesare set as pre-defined values determined by the QoS feature. For GPRS, the maximum rate is 8k and for EGPRS the maximum rate is 14 k.

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 additionalcontrol channel load for the GPRS data traffic with the existing circuit-switched traffic load ontothe CCCH. On the other hand, when pccch_enabled = 1 at the cell, GPRS does not add anyadditional control channel load on the CCCH. In this case, however, PCCCH reduces the GSMcircuit-switched signaling load on the CCCH with paging coordination.

The network planner requires to consider paging coordination, the expected paging rate, andthe access grant rate to calculate the number of CCCH blocks needed. Perform this calculationusing the guidelines given in Control channel calculations on page 3-52 in Chapter 3 BSS cellplanning.

8-88 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSS - PCU planning example for EGPRS with QoS enabled, QoS2 not enabled

Determining number of GPRS and EGPRS carrier timeslots at each BTS cell

Use the equation to determine the number of GPRS timeslots that are required on a per cellbasis. To use this equation, the n expected cell load in kbps should be known.

Mean−traffic−load =GPRS−Users

∗Data−rate−per−sub∗8 bits/bytes

3600

=250∗92.38∗8

3600= 51.32 kbit/s

TS−Data−Rate =1

100

(i=4∑

i=1

CSi−Rate∗CSi−distribution+

9∑

i=1

MCSi−Rate∗MCSi−distribution

)

17.41 kbit/s

No−PDCH−TS = Roundup

{Mean−traffic−load

∗Mean−load−factor

TS−Data−Rate

}

= Roundup

{51.32∗217.41

}= 6

The equation takes into account the amount of local timeslot headroom to allow to the requiredMTBR. The mean load factor is set to 2 to accommodate peak data scenarios since the meantraffic load is based on averages. The defined timeslot throughput and the PRP board headroomallocated by the QoS feature cover the signaling peak periods.

Calculating the number of active timeslots

A PRP board can be assigned up to 120 timeslots but only 30 are serviced (active) at any giventime. The PRP algorithms handle the scheduling of timeslots efficiently, depending on theavailable resources. The QoS feature provides further guidelines on the number of timeslots toassign to a PRP to achieve the requested MTBR per subscriber.

68P02900W21-T 8-89

Jul 2010

BSS - PCU planning example for EGPRS with QoS enabled, QoS2 not enabled Chapter 8: BSS planning for GPRS/EGPRS

PRP board throughput is calculated as follows:

PRP BOARD THROUGHPUT = THRUPUT−TS∗ {(8000 ∗%CSI−USAGE) +

(12000∗%CS2−USAGE) + (14400∗%CS3−USAGE) + ...... (20000∗%CS4−USAGE)

+ (8800∗%MCS1−USAGE) + (11200∗%MCS2−USAGE) + ......

(14800∗%MCS3−USAGE) + (17600∗%MCS4−USAGE) + (22400∗%MCS5−USAGE)

+...... (29600∗%MCS6−USAGE) + (44800∗%MCS7−USAGE) + (54400∗%MCS8−USAGE)

+...... (59200∗%MCS9−USAGE)} (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 ERAGEDOWNLINKMTBR = (STR−EGBR ∗%subs) + (IIMTBR ∗%subs)

+ (12MTBR ∗%subs) + ...... (13−MTBR ∗%subs) + (BG−MTBR ∗%subs)

+ (BE−MTBR ∗%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 forthe calculated 6 timeslots. The new equation also provides 6 timeslots but these are dividedbetween GPRS and EGPRS. The new EGPRS carrier provides 8 timeslots of data capacity that isthe required 6. In this example, there are 8 GPRS timeslots configured as switchable or packetdata from the original GPRS carrier and 8 timeslots defined as packet data for the new EGPRScarrier 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 requiredto carry the traffic. Remember:

• Each CS1/CS2 timeslot requires 16k TRAU channel,CS3/CS4 timeslots requires 32kTRAU,MCS1 through MCS9 require a variable VersaTRAU backhaul in units of 64k DS0son the GDS TRAU interface.

8-90 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSS - PCU planning example for EGPRS with QoS enabled, QoS2 not enabled

NOTEThe example here assumes that each EGPRS RTF is equipped with a backhaul of8 DS0s (rtf_ds0_count = 8). This is the worst case. Typical configuration mayrequire less GDS resources.

• CS3/CS4 is enabled on a carrier hence all the GPRS timeslots for that carrier wouldrequire 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 andhalf with 64k TRAU, 2 GDS E1s for every PRP and 8 GDS E1s to 4 PRPs. Refer to the appropriatesection of this chapter for the PCU provisioning rules.

Calculating the BSC LCF impact to support GPRS traffic

The volume of GPRS and EGPRS signaling traffic increases the BSC LCF GPROC2 processorload. Use the BSS planning rule for LCF provisioning in the following equation.

GL3−GPRS = 0.002∗Total−RACH/sec∗(1−RPCCCH−Cells

)+ 0.00075∗B∗

P ∗GPRS PCCCH−BSS

= 0.002∗(

250∗20∗53600

)∗ (1− 0.5) + 0.00075∗10∗1.4∗1 = 0.017

An additional LCF GPROC2 can be added or the GSM circuit-switched provisioning can beexamined to check whether an existing LCF GPROC2 can process this additional load.

Calculating the number of GBL links

Using the standard traffic model and Gb formulae:

User−Data−Rate =(GPRS−Users−PCU

∗Data−rate−per−sub∗1000

3600

)∗(

1 +71

PKsize

)

=(

250∗20∗92.38∗10003600

)∗(

1 +71

435.97

)= 149200 bytes/s

No−GBL−TS =Total−Data−rate

8000∗UGRI=

2649 + 1492008000∗0.25

= 75

NPCU−SGSN = No−GBL−TS/31 = 75/31 = 2.42

Hence, 3 Gb links are required.

Calculating the number of GSL links

Use the following equation to calculate the number of 64 kbps GSL links required. In thisexample, the number of users on a PCU is 5000. It assumes that all 20 cells are parented to asingle LCF card in the BSC. Evaluating this equation and the supporting expressions resultsin one 64 kbps GSL link being required, assuming that preload is enabled, after rounding upto the nearest integer value (but not including redundancy).

68P02900W21-T 8-91

Jul 2010

BSS - PCU planning example for EGPRS with QoS enabled, QoS2 not enabled Chapter 8: BSS planning for GPRS/EGPRS

Refer to Determining the number of GSLs required on page 6-50 in Chapter 6 BSC planningsteps and rules, for further details on the following equations.

Total−RACH/sec = (20∗250) ∗ (5 + 2.86 + 0.78 + 1) /3600 = 13.39/s

RPCCCH−Cells =(number of PCCCH − 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

GSLPaging = 8.5∗0.32∗1∗1/ (1000∗0.25) = 0.01

The number of GSL TS for run time is represented by:

GSLrun−time = GSLRACH +GSLPaging = Round Up (0.147 + 0.01) = 1

The number of GSL required is

GSL = MAX(GSLrun−time, GSLinit−time

)= MAX (1, 6) = 6

Calculating the PCU hardware to support the PCU traffic

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 processthe GBL traffic.

• 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 9 PRPboards.

• 1 PCU cabinet, 1 PCU cabinet per 3 PCU shelves.

After calculating the number of GDS, GBL and GSL E1 links, ensure that there are a sufficientnumber of PICP boards to cover the GBL and GSL E1 links. The PCU hardware calculation givesthe number of PICP boards based only on the ratio of PICP boards to PRP boards. The followingcalculation takes into account the number of E1 links terminated on the PICP boards for theGBL and GSL E1 links. A PICP board can terminate both GBL and GSL links on the board, butnot 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 4GBL 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). EachPICP can terminate up to 2 E1 GSL links and up to 60 GSL 64 kbps timeslots distributed overtwo E1s. There is a limit of 2 GSL E1s per PCU. Therefore, 1/4 of a PICP is required for theGSL E1 link. Due to the limitation that a PMC cannot share a GSL and GBL, a second PICP isrequired. The GBL and GSL E1 link requirements show that one PICP is sufficient to processthe link provisioning requirements.

8-92 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSS - PCU planning example for EGPRS with QoS and QoS2 enabled

Calculating the increased data traffic load on the E1s between the BSCand BTSs

It is assumed that the EGPRS traffic is in addition to the existing circuit-switched traffic andGPRS traffic already available in the system. 8 timeslots would be required for the EGPRStimeslot traffic on a per cell basis. Therefore, to carry the GPRS traffic, additional 16 x 16 kbits/stimeslots (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. WhenEGPRS is enabled, all reserved and switchable timeslots are backhauled from the BTS throughthe BSC to the PCU. The physical link calculations must take this into account. The CPUprocessing equations require to take into account the percentage of backhauled timeslots thatare active at a given time interval. If GSM circuit-switched statistics are available, they can beused. 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 E1sbetween the BSC and BTSs

For cells without PCCCH (pccch_enabled = 0), the BTS combines the additional signalingload for the EGPRS data traffic with the existing circuit-switched traffic load. This results inan additional load on the existing RSL links between each BTS and the BSC. For cells withPCCCH, EGPRS does not add significant additional control channel load on the RSL. In thiscase, however, PCCCH reduces the GSM circuit-switched signaling load on the RSL with pagingcoordination. The new load on the RSL for GPRS is based on the evaluation of the followingequation and other supporting equations.

Refer to Determining the number of GSLs required on page 6-50 in Chapter 6 BSC planningsteps and rules for further details on the following equation.

RSLGPRS+GSM = RSLGPRS +RSLGSM

To be consistent with the EGPRS calculation perform the GSM RSL calculation with 64 kbps RSL.

BSC link provisioning impact

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 insupport of the additional EGPRS traffic over the BTS to BSC interface. In this example, eightE1s were added for the GDS links and one E1 added for the GSL link.

BSS - PCU planning example for EGPRS with QoS and QoS2enabled

This example uses the same base call model parameters as those used in BSS - PCU planningexample for EGPRS on page 8-79 except that the QoS feature is enabled. QoS requires newcall model parameters to be specified based on QoS usage.

68P02900W21-T 8-93

Jul 2010

BSS - PCU planning example for EGPRS with QoS and QoS2 enabled Chapter 8: BSS planning for GPRS/EGPRS

NOTESee BSS - PCU planning example for EGPRS on page 8-79 to compare theGPRS/EGPRS call model parameters.

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

Average packet size for GPRS and EGPRStraffic mix (bytes)

PKULSIZE = 188.71

Average packet size for GPRS and EGPRStraffic mix (bytes)

PKDLSIZE = 435.97

GPRS and EGPRS Traffic per sub/BH(kBytes/hr) - uplink

ULRATE = 35.59

GPRS and EGPRS Traffic per sub/BH(kBytes/hr) - downlink

Data rate_per sub = 92.38

PS attach/detach rate (per sub/BH) PSATT/DETACH = 0.45

PDP context activation/deactivation (persub/BH)

PDPACT/DEACT = 0.4

Routing area update RAU = 1.4

Cell Updates CellUpdate = 0.33

GPRS paging rate in pages per second PGPRS = 18.73

GPRS/EGPRS users per cell 250

Average sessions per user per hour 0.45

GSM circuit-switched paging rate(pages/second)

PGSM = 60

Ratio of LCSs per call LCS = 0.1

Mobile terminated LCS ratio LRMT = 0.95

Ratio of mobiles in the system that are bothGSM and GPRS capable

NGSM GPRS MS/NAU MS = 100%

Percentage of mobiles that are EGPRScapable

5%

Number of PCCCH-enabled cells in the BSS 10

Total number of cells in the BSS 20

STR_GBR1 (PoC) 8 kbps

STR_GBR2 (Audio) 10 bit/s

Continued

8-94 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSS - PCU planning example for EGPRS with QoS and QoS2 enabled

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 4

BG_MTBR 2

BE_MTBR 2

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 Rate

CS1 10% 8

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

CS distribution

Total 100%

Selecting a cell RF plan

The PRP board headroom compensates the BLER required for QoS. The CS coding schemesare set as pre-defined values determined by the QoS feature. For GPRS, the maximum rate is 8k and for EGPRS the maximum rate is 14 k.

68P02900W21-T 8-95

Jul 2010

BSS - PCU planning example for EGPRS with QoS and QoS2 enabled Chapter 8: BSS planning for GPRS/EGPRS

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 controlchannel load for the GPRS data traffic with the existing circuit-switched traffic load ontothe CCCH. On the other hand, when pccch_enabled = 1 at the cell, GPRS does not add anyadditional control channel load on the CCCH. In this case, however, PCCCH reduces the GSMcircuit-switched signaling load on the CCCH with paging coordination.

To calculate the number of CCCH blocks required take into account the paging coordination, theexpected paging rate and the access grant rate. Perform this calculation using the guidelinesgiven in Control channel calculations in Chapter 3 BSS cell planning.

Determining number of GPRS and EGPRS carrier timeslots at each BTS cell

Use the equation to determine the number of GPRS timeslots that are required on a per cellbasis. To use this equation, the expected cell load in kbps should be known.

Mean−traffic−load =GPRS−Users

∗Data−rate−per−sub∗8 bits/byte

3600

=250∗92.38∗8

3600= 51.32kbps

TS−Data−Rate =1

100(1=4∑

i=1

CSi−Rate∗CSi−distribution+

9∑

i=1

MCSi−Rate∗MCSi−Distribution)

= 17.41kbps

= No−PDCH−TS = Roundup

(Mean−traffic−Load

∗Mean−Load−factor

TS−Data−Rate

)

+(NPBCCH +NPAGCH +NPPCGH

12

)= Roundup

(51.32∗217.41

)= 6

The equation takes into account the amount of local timeslot headroom to allow to the requiredMTBR. The mean load factor is set to 2 to accommodate peak data scenarios since the meantraffic load is based on averages. The defined timeslot throughput and the PRP board headroomallocated by the QoS feature cover the signaling peak periods.

8-96 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSS - PCU planning example for EGPRS with QoS and QoS2 enabled

Calculating the number of active timeslots

A PRP board can be assigned up to 120 timeslots but only 30 are serviced (active) at anygiven time. The PRP algorithms handle the scheduling of timeslots efficiently, depending onresources available.

The QoS feature provides further guidelines on the number of timeslots to assign to a PRP toachieve the requested MTBR per subscriber. PRP board throughput is calculated as follows:

Assuming initial coding scheme is CS2 and MCS3:

PRP BOARD THROUGHPUT = THRUPUT−TS∗{(8000∗CS1−USAGE) + 12000∗

(%CS2−USAGE + CS3−USAGE + CS4−USAGGE)}+ {(8800∗%MCS1−USAGE) + (11200∗%)

(MCS2−USAGE) + 14800∗ (%MCS3−USAGE +MCS4−USAGE +MCS5−USAGE+)

(%MCS6−USAGE + %MCS7−USAGE + %MCS8−USAGE + %MCS9−USAGE)} ∗ (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

STR−EGBR = (10.09kbit/s, 500ms, rho = 0.62) / (1 +BLER) = 10.09/0.62∗1.1 = 17.9 kbit/s

AV ERAGEDOWNLINKMTBR = (STR−EGBR∗%subs) + (IIMTBR∗%subs) +

(12MTBR∗%subs) + ...... (13−MTBR∗%subs) + (BG−MTBR∗%subs) + (BE−MTBR∗%subs)

= (17.9∗22%) + (14∗3%) + (10∗10%) + (4∗25%) + (2∗15%) + (2∗25%) = 7.16 kbit/s

Therefore:

MAX−QOS−PDCHS−PER−PRP = 324270/ (7.16∗1000) = 45

If one PXP board (70TS), mode 1 is used, then

MAX−QOS−PDCHS−PER−PRP = (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 forthe calculated 6 timeslots. The new equation also provides 6 timeslots but these are dividedbetween GPRS and EGPRS. The new EGPRS carrier provides 8 timeslots of data capacity that isabove the required 6. In this example, there are 8 GPRS timeslots configured as switchable orpacket data from the original GPRS carrier and 8 timeslots defined as packet data for the newEGPRS carrier for a total of 16 data capable timeslots per cell.

68P02900W21-T 8-97

Jul 2010

BSS - PCU planning example for EGPRS with QoS and QoS2 enabled Chapter 8: BSS planning for GPRS/EGPRS

This is a total of 320 data capable timeslots.

320 PDTCHs/45MAX per board = 8 PRP boards

If PXP board is used,

320 PDTCHs/105MAX per board = 4 PRP boards

The provisioning of the 8 GDS E1s to 9 PRPs is required.

NOTEEach PRP must terminate at least one GDS TRAU E1 and the timeslots of an entirecell must terminate on the same PRP.

Calculating the BSC LCF impact to support GPRS traffic

The volume of GPRS and EGPRS signaling traffic increases the BSC LCF GPROC2 processorload. Use the BSS planning rule for LCF provisioning in the following equation.

GL3−GPRS = 0.002∗Total−RACH/sec∗(1−RPCCCH−Cells

)+ 0.00075∗B∗

P ∗GPRS PCCCH−BSS

= 0.002∗(

250∗20∗53600

)∗ (1− 0.5) + 0.00075∗10∗1.4∗1 = 0.017

An additional LCF GPROC2 can be added or the GSM circuit-switched provisioning can beexamined to check whether an existing LCF GPROC2 could process this additional load.

Calculating the number of GBL links

Using the standard traffic model and Gb formulae:

User−Data−Rate =(GPRS−Users−PCU

∗Data−rate−per−sub∗1000

3600

)∗(

1 +71

PKsize

)

=(

250∗20∗92.38∗10003600

)∗(

1 +71

435.97

)= 149200 bytes/s

No−GBL−TS =Total−Data−rate

8000∗UGRI=

2649 + 1492008000∗0.25

= 75

NPCU−SGSN = No−GBL−TS/31 = 75/31 = 2.42

Hence, 3 Gb links are required.

8-98 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning BSS - PCU planning example for EGPRS with QoS and QoS2 enabled

Calculating the number of GSL links

Use the following equation to calculate the number of 64 kbits/s GSL links required. For thisexample, the number of users on a PCU is 5000. It assumes that all 20 cells are parented to asingle LCF card in the BSC. Evaluating this equation and the supporting expressions resultsin one 64 kbps GSL link being required, assuming that preload is enabled, after rounding upto the nearest integer value (but not including redundancy).

Refer to Determining the number of GSLs required on page 6-50 in Chapter 6 BSC planningsteps and rules for further details on the following equations.

Total−RACH/sec = (20∗250) ∗ (5 + 2.86 + 0.78 + 1) /3600 = 13.39/s

RPCCCH−Cells = (number of PCCCH − 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

GSLPaging = 8.5∗0.32∗1∗1/ (1000∗0.25) = 0.01

The number of GSL TS for run time is represented by:

GSLrun−time = GSLRACH +GSLPaging = Round Up (0.147 + 0.001) = 1

The number of GSL required is

GSL = MAX(GSLrun−time, GSLinit−time

)= MAX (1, 6) = 6

Calculating the PCU hardware to support the PCU traffic

The following hardware is required:

• 4 PXP boards, 4 ETH links (GDS) timeslot balanced across the PRPs.

• 3 Gb links.

• 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 9 PRPboards.

• 1 PCU cabinet, 1 PCU cabinet per 3 PCU shelves.

After calculating the number of GDS, GBL, and GSL E1 link, ensure that there are a sufficientnumber of PICP boards to cover the GBL and GSL E1 links. The PCU hardware calculationcalculates 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 PICPboards for the GBL and GSL E1 links. A PICP board can terminate both GBL and GSL links onthe 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 4GBL 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). EachPICP can terminate up to 2 E1 GSL links and up to 60 GSL 64 kbps timeslots distributed over twoE1s. There is a limit of 2 GSL E1s per PCU. Therefore, 1/4 of a PICP is required for the GSL E1link. Due to the limitation that a PMC cannot share a GSL and GBL, a second PICP is required.

68P02900W21-T 8-99

Jul 2010

BSS - PCU planning example for EGPRS with QoS and QoS2 enabled Chapter 8: BSS planning for GPRS/EGPRS

The GBL and GSL E1 link requirements show that one PICP is sufficient to process the linkprovisioning requirements.

Calculating the increased data traffic load on the E1s between the BSCand BTSs

It is assumed that the EGPRS traffic is in addition to the existing circuit-switched traffic andGPRS traffic already available in the system. 8 timeslots are required for the EGPRS timeslottraffic on a per cell basis. Therefore, an additional 16 x 16 kbits/s timeslots (MCS1 - MCS9) arerequired 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. WhenEGPRS is enabled, all reserved and switchable timeslots are backhauled from the BTS throughthe BSC to the PCU. The physical link calculations must take this into account. The CPUprocessing equations require to take into account the percentage of backhauled timeslotsthat are active at a given time interval. If GSM circuit-switched statistics are available, theycould be reviewed to aid in this decision. Refer to Dynamic timeslot allocation on page 3-76 inChapter 3 BSS cell planning.

Calculating the changes in signaling traffic load (RSL load) on the E1sbetween the BSC and BTSs

For cells without PCCCH (pccch_enabled = 0), the BTS combines the additional signaling loadfor the EGPRS data traffic with the existing circuit-switched traffic load. This results in anadditional 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 andother supporting equations.

Refer to Determining the number of RSLs required on page 6-22 in Chapter 6 BSC planningsteps and rules for further details on the following equation.

RSLGPRS+GSM = RSLGPRS +RSLGSM

To be consistent with the EGPRS calculation perform the GSM RSL calculation with 64 kbps RSL.

BSC link provisioning impact

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 andrules.

The BSC requires more E1 terminations in support of the additional E1 links to the PCU and insupport of the additional EGPRS traffic over the BTS to BSC interface. In this example, eightE1s 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 andformulae. 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 notcovered. Refer to the Motorola local office for assistance in ensuring that all necessary itemsare 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 9-1

Jul 2010

Pre-requisites Chapter 9: Planning examples

Pre-requisites■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Requirements

In the area of interest, a demand analysis has identified the requirement for 11 BTSs with thebusy 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 parametersfor capacity calculations on page 3-48 section of Chapter 3 BSS cell planning, provides themaximum Erlang capacity for a given number of carriers at 2% blocking. The third column ofTable 9-1 provides the number of carriers (RTFs) required.

NOTEIf 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 inTable 3-7 and Table 3-8 in the Call model parameters for capacity calculations on page 3-48section of Chapter 3 BSS cell planning can be found by reference to standard Erlang B tables forthe equivalent number of traffic channels at the required blocking factor.

Table 9-1 Busy hour demand and number of carriers

BTS identification Erlangs Antenna configuration

A 6 Omni 2

B 5 Omni 2

C 2 Omni 1

D 5 Omni 2

E 14 Omni 3

F 10 Omni 3

G 5 Omni 2

H 2 Omni 1

J 5 Omni 2

K 20/20/20 Sector 4/4/4

L 5 Omni 2

Total 119 32 carriers

9-2 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Network topology

Network topology

Using a frequency-planning tool, assigns adequate frequencies to support the BTS antennaconfigurations of Table 9-1. Based on this, initial planning of the network gives the topologyshown in Figure 9-1.

Figure 9-1 Network topology

BSC

BTS B

BTS C

BTS D

BTS K

BTS L

BTS E

BTS F

BTS G BTS J

BTS H

BTS A

RXCDR MSC

OMC-R

ti-GSM-Network_topology-00145-ai-sw

68P02900W21-T 9-3

Jul 2010

Exercises Chapter 9: Planning examples

Exercises■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Introduction

To illustrate the planning steps, the individual hardware requirements for BTS B and BTS K iscalculated, followed by the calculation to produce the hardware requirements for the BSC, andRXCDR. 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 BSScell planning and Chapter 6 BSC planning steps and rules. Half rate usage is not specifiedfor this exercise.

9-4 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 omniconfiguration to carry a peak demand of five Erlangs.

Cabinet

From the site requirements and the potential future expansion it can be determined that thissite should be built using an M-Cell6 indoor cabinet. For the cabinet and any of the followingitems, 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

Contact the Motorola local office if part numbers are required.

Power redundancy

Contact the Motorola local office if part numbers are required.

Duplexing

Only two antennas are used on this site, so specify duplexing. Contact the Motorola localoffice 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. Contactthe Motorola local office if part numbers are required.

68P02900W21-T 9-5

Jul 2010

Summary Chapter 9: Planning examples

Database option

Contact the Motorola local office if part numbers are required.

Summary

The equipment required and an example of customer order creation for an M-Cell6 indoor (900MHz) 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 dc110/240 V ac

How many cells are required? 123

How many carriers are required per cell? (RFconfiguration)

1 2345678

How many cabinets are required for the RFconfiguration?

1234

What type of combining is required? CBF (Hybrid)CCB (Cavity)3 I/PCBF 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? YesNo

Is digital redundancy required? YesNo

Is power redundancy required? YesNo

Is duplexing required? YesNo

Is a high-power duplexer shelf or external rack required? YesNo

Are 16-way alarm inputs required? YesNo

Is a memory card required? YesNo

Continued

9-6 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Summary

Table 9-3 Customer ordering guide 900 MHz (M-Cell6 indoor) (Continued)

Question Options

Is database required? (Provided by local office) YesNo

Is ac battery backup required? YesNo

Select ac battery box options? YesNo

Is -48 V power supply module (APSM) required? YesNo

Is Comms Power Supply Module (CPSM) required? YesNo

68P02900W21-T 9-7

Jul 2010

Determine the hardware requirements for BTS K Chapter 9: Planning examples

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 sectorconfiguration 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 thissite is included in two or three Horizonmacro cabinets.

Alternatively, the site can be included is a better word in a single Horizon II macro indoorcabinet.

Receiver requirements

A single Horizon II macro cabinet solution, a two cabinet Horizonmacro solution and a threecabinet 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 modeto 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 beinstalled in the same cabinet, thus providing dual band capability. A maximum of 3 CTU2s perband can be accommodated for 2/2/2 and 2/2/2 configuration. Refer to Chapter 12 Hardwareand 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 SURFmodules support the four carriers in each sector. The shared sector is supported byinterconnecting 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

System Information: BSS Equipment Planning 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 mastercabinet 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 cabinetHorizon II macro indoor (1800 MHz) configuration, to implement BTS K is listed in Table 9-4and Table 9-5.

Table 9-4 Customer ordering guide 1800 MHz (Horizon II macro indoor)

Question Compulsory

Voltage used +27 V dc-48 V/60 V dc240 V ac

How many cells are required? 123

How many carriers are required per cell? (RF configuration) 12345678

One carrier (single density) or two carriers (double density)required per CTU2?

12

How many cabinets are required for the RF configuration? 1234

Continued

68P02900W21-T 9-9

Jul 2010

Summary Chapter 9: Planning examples

Table 9-4 Customer ordering guide 1800 MHz (Horizon II macro indoor) (Continued)

Question Compulsory

What type of combining is required? DUP and AirDUP and HCUDUP and DHU

DUP, HCU and Air DUP,DHU and Air DUP,HCU, DHU, and Air

What line interface is required? T43 (E1) (75 ohm)BIB (E1) (120 ohm)

Table 9-5 Customer ordering guide 1800 MHz (Horizon II macro indoor)

Questions Options

Is digital redundancy required? YesNo

Is power redundancy required? YesNo

Is an extra line interface required? YesNo

Are 16-way alarm inputs required? YesNo

Is a compact flash (memory) card required? YesNo

Is a stacking bracket required? YesNo

Is battery backup required? YesNo

Is database required? (Provided by local office) YesNo

9-10 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 in13 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 trafficchannels. One OML link, one XBL link, and one C7 signaling link are required. The number oftrunks 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 Chapter 9: Planning examples

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 1

LCFs for RSLs 1

Optional GPROC requirements

Redundant BSP (GPROC3), CSFP 1

Redundant LCP 1

Total GPROC3s 1+1

Total GPROC2s/GPROC3s 2+1

NOTEThe 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

System Information: BSS Equipment Planning 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 LANneeds one additional LANX per cabinet.

Power supply

Depending on the power supply voltage, two EPSM plus one for redundancy or two IPSMplus 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 1

BSU shelf 1

MSI 3

BIB or T43 1

GPROC3 1+1

GPROC2/GPROC3 2+1

KSW/DSW2 1+1

GCLK 1+1

PIX (provides up to 8 external alarms) 1

LANX 1

EPSM/IPSM (+27 V) (-48 V) 2+1

NOTEThe 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 Chapter 9: Planning examples

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 thetraffic 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 canbe 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 RXCDRmust 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 that138 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

NOTEEnhanced capacity mode must be enabled within the RXCDR to access the second E1when GDP2s are used in non-MSI slots. XCDR, GDP, and GDP2s are mixed within ashelf.

Use the RXU3 shelf in the GDP2. The BSSC3 cabinet with two RXU3 shelves can interface up to76 E1 links. The BSSC2 cabinet can interface only up to 48 E1 link.

9-14 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Link interface

Link interface

From the MSI requirements, it can be seen that, two E1 links to the BSC and one to the OMC-Rare required. From the transcoder requirements it can be seen that a further five E1 links arerequired. 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 oftimeslots 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 Chapter 9: Planning examples

LANX requirement

An adequate number of LANXs are provided for non-redundant operation. A redundant LANneeds one additional LANX per cabinet.

Power supply

Depending on the power supply voltage, two EPSMs plus one for redundancy or two IPSMsplus 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 1

RXU or RXU3 shelf 1

MSI 2

XCDR/GDP-E1 5

BIB or T43 2

GPROC2/GPROC3 1+1

KSW or DSW2 1+1

GCLK 1+1

PIX (provides up to 8 external alarms) 1

LANX 1

EPSM/IPSM (+27 V) (-48 V) 2+1

NOTEThe notation n + m means that n the items required plus m the redundancy.

9-16 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 5BTS planning steps and rules, Chapter 6 BSC planning steps and rules and Chapter 7 RXCDRplanning steps and rules are inappropriate. Where this is the case, the various planning tablesthat are used in the previous example in this chapter is not correct and the actual values requireto be derived using the formulae given in Chapter 5 BTS planning steps and rules, Chapter 6BSC planning steps and rules and Chapter 7 RXCDR planning steps and rules. The necessarycalculations 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 Chapter 9: Planning examples

• 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 of2% 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

System Information: BSS Equipment Planning 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 blocksrequired 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 requiredto 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 besupported using a non-combined BCCH with 9 CCCH timeslots. Reserve 3 CCCH blocks foraccess grant messages.

Determining the number of SDCCHs per cell

Using the values calculated in the previous section and other call model parameters, theaverage number of SDCCHs and NSDCCH is given by the formula mentioned in Chapter 3BSS 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 that1% blocking is 14 as determined by use of Erlang B tables. Hence, the number of timeslotsrequired 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 callmodel parameters is 3 (1 non-combined BCCH timeslot with 9 CCCHs and 2 timeslots with 8SDCCHs each).

68P02900W21-T 9-19

Jul 2010

Planning example 1 Chapter 9: Planning examples

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:

• 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

9-20 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 =

n ∗ (95 + 67 ∗ S + 35 ∗H + 25 ∗ L)1000 ∗ U ∗ T

+(47 + 3 ∗ CBTS) ∗ PGSM + (52 + CBTS) ∗ PGPRS

8000 ∗ U +

6 ∗Mean−TBF−Rate ∗NGPRS1000 ∗ U

Where n is the number of TCHs under the BTS. Hence, for a 6/6/6 site (no GPRS):

RSLGGSM+GPRS@64K = 45 ∗ 3 ∗ (95 + 67 ∗ 0.12 + 35 ∗ 2.5 + 25 ∗ 2.4)1000 ∗ .25 ∗ 120

+(47 + 3 ∗ 3) ∗ 10 + (52 + 3) ∗ 8

8000 ∗ 0.25+

6 ∗ 01000 ∗ 0.25

= 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:

NBSC−BTS =

{[(nEGPRS∑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)) + 231

= 1.22

Hence, 2 E1 interconnections are required between each BTS and BSC for the given siteconfigurations (provided they are in star configurations). There are total of 20 * 2 = 40 E1links 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 =[

n ∗ (1 + 0.35 ∗ S + 0.34 ∗H ∗ (1− 0.4 ∗ i) + 0.32 ∗ L)19.6 ∗ T

+ (0.00075 ∗ PGSM + 0.004) ∗ B +C

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)19.6 ∗ 100

+ (0.00075 ∗ 8 + 0.004) ∗ 20 +60120

]

68P02900W21-T 9-21

Jul 2010

Planning example 1 Chapter 9: Planning examples

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 is2165 (using offered Erlangs to calculate). Verify that this figure is within limits (< 3200 for ahuge 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 formulaementioned in Chapter 6 BSC planning steps and rules of this manual.

Maximum number of Erlangs supported by a C7 link is given by:

nlink =1000 ∗U ∗ T

(40 + 47 ∗ S + 22 ∗H ∗ (1− 0.8 ∗ i) + 24 ∗ L + 9 ∗ PPC)

nlink =1000 ∗ 0.35 ∗ 120

(40 + 47 ∗ 0.12 + 22 ∗ 2.5 ∗ (1− 0.8 ∗ 0.6) + 24 ∗ 2.4 + 9 ∗ 0.44)= 310 Erlangs

Maximum number of Erlangs supported by GPROC supporting a C7 signaling link is given by:

n1LCF−MTL =20 ∗ T

(1 + 0.16 ∗ S + 0.5 ∗H ∗ (1− 0.6 ∗ i) + 0.42 ∗ L + PPC ∗ (0.005 ∗ B + 0.05))

n1LCF−MTL =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

nlLCF−MTL

)= 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:

nlog−per−mtl = rounddown(

310135.31

)

The number of required MTLs.

Check that this figure is within limits (<16).

9-22 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 < nlLCF−MTL

NLCF = roundup(

92

)= 5

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

NOTEA total of 3 BSU shelves are required and each shelf must have at least one GPROC (x2 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 =NBSC−RXCDR

2

NMSI = Number of MSIs required.

NBSC-RXCDR = Number of E1 links required.

68P02900W21-T 9-23

Jul 2010

Planning example 1 Chapter 9: Planning examples

Number of E1 links required at the BSC for interconnecting with the RXCDR is:

NBSC−RXCDR =C + X + B64 + T ∗ (1− PHR) + N16/4 (T ∗ PHR) /8

31

=9 + 2 + 2 + (2165/4)

31= 17.9

~ 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 MSIsrequired 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:

G the number of GPROCs.

n 16 or 32 (16 in this example).

RGDP2 N/A in this example (RXCDR case).

M the number of MSIs (29).

NOTERGDPXCDR 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 arerequired 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

System Information: BSS Equipment Planning Planning example 1

Table 9-10 BSU Shelves

BSU 1 BSU 2 BSU 3 Check Limit

GPROCs 4 4 4 ≤8

MSI cards 12 9 8 ≤12

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 neededfor 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 clocksignals to all shelves in the multi-shelf configuration. The KSWX/DSWX can be used inexpansion, remote and local modes. Three BSU shelves are required with 3 master/redundantKSWs/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:

NKX = NKXE + NKXR + NKXL

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 KSWXand 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 isrequired at each BSC.

The number of GCLKs required (with redundancy) = 2

68P02900W21-T 9-25

Jul 2010

Planning example 1 Chapter 9: Planning examples

CLKX requirements

Provides expansion of GCLK timing to more than one BSU. Number of CLKXs required isgiven 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

System Information: BSS Equipment Planning 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 GPROCs

• The number of MSIs

• The number of KSWs/DSW2s

• The number of RXU 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 boards (T43s)

• The number of digital power supply units

• Check if an optional NVM board is fitted

Determining the number of E1 links between the RXCDR and BSC

Number of RXCDR to MSC links is given by:

NRXCDR−MSC = (C + X + T) /31

Where: Is:

C the number of MTL links required.

X the number of OML links required.

T the number of trunks between MSC and BSC.

NRXCDR−MSC = (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 Chapter 9: Planning examples

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 cardinterfaces 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-redundantKSWs/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 1 2 2 2 2

XCDRs/GDPs 7 7 7 7 7

GDP2s 7 7 7 7 8

GPROCs 2 2 2 2 2

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

System Information: BSS Equipment Planning Planning example 1

The number of KSWXs/DSWXs required is the sum of KSWX/DSWXE, KSWX/DSWXR, andKSWX/DSWXL. The calculations imply 2 expansion and 2 extension shelves are required.

NKX = NKXE +NKXR +NKXL

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

NOTEIf KSWXs and DSWXs are used in like pairs, that is, KSWX connected to KSWX andDSWX 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 isrequired 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: Is:

E the number of expansion/extension shelves.

RF 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) Chapter 9: Planning examples

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 provides eight inputs and four outputs for site alarms.

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

Digital power supply requirements

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)

Planning example 2 (using AMR)

Dimension a network with the following requirements:

• 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

9-30 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example 2 (using AMR)

• 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

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)

• 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

68P02900W21-T 9-31

Jul 2010

Planning example 2 (using AMR) Chapter 9: Planning examples

• 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

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

TotalCarriers

AMR HR/Carriers

TotalTCH

Signaling/ ControlTCH

TotalVoiceTCH

TotalTCH

Signaling/ControlTCH

TotalVoiceTCH

AMRHR TCH

AMRHRTCH%

6 1 / 6 48 3 45 56 3 53 16 30.2

6 2 / 6 48 3 45 64 4 60 32 53.3

6 3 / 6 48 3 45 72 4 68 48 70.6

6 4 / 6 48 3 45 80 4 76 64 84.2

6 5 / 6 48 3 45 -88 -4 -84 -80 95.2

6 6 / 6 48 3 45 96 4 88 88 100

For planning purposes, it is assumed that the AMR-capable MSs use AMR FR channels, and thathr is used under conditions of congestion. The estimated AMR penetration rate is 35%, of whichhalf of those calls are in half rate mode due to congestion (as given in the assumptions), yieldingabout 18% of the calls in half rate mode. From the pre-calculated table, it is seen that 1 half rateenabled carrier would provide about 30% AMR half rate channels. However, to allow for futuregrowth in the penetration level and to allow for a greater margin of safety, 2 half rate enabledcarriers can be assumed for the remainder of this exercise.

9-32 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example 2 (using AMR)

6-carrier cell - determining the number of CCCHs

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

Access grant rate is given by:

λAGCH = λcall + λS + λLU = 1.567

From the call model parameters, the paging rate P is 8, so the average number of CCCH blocksrequired to support paging only is given

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.184

Using a CCCH utilization figure (UCCCH) of 0.33, the average number of CCCH blocks requiredto support both PCH and AGCH is given by:

NPAGCH = (NAGCH + NPCH) /UCCCH = (0.184 + 0.471) /0.33 = 1.985

Assuming 1% blocking, the Erlang B tables show that seven CCCHs are required. This can besupported using a non-combined BCCH with 9 CCCH timeslots. Reserve 2 CCCH blocks foraccess grant messages.

Determining the number of SDCCHs per cell

Using the values calculated in the previous section and other call model parameters, theaverage number of SDCCHs and NSDCCH is given by the formula mentioned in Chapter 3BSS cell planning.

NSDCCH = λcall ∗ Tc + λLU ∗ (TL + Tg) + λs ∗ (Ts + Tg)

= 11.31

68P02900W21-T 9-33

Jul 2010

Planning example 2 (using AMR) Chapter 9: Planning examples

To support an average number of busy SDCCHs of 11.31 Erlangs signaling traffic with less than1% blocking is 18 as determined by use of Erlang B tables. Hence, the number of timeslotsrequired to carry SDCCH signaling traffic is 3, with each timeslot offering a maximum of 8SDCCHs.

Determining the number of TCHs

Total number of signaling timeslots required for a 6-carrier configuration, with the given callmodel parameters is 4 (1 non-combined BCCH timeslot with 9 CCCHs and 3 timeslots with 8SDCCHs each).

Therefore, the number of traffic channels per 6 carrier cell (4 fr carriers + 2 hr carriers)

= 4 * 8 + 16 * 2 – 4 = 60

Hence, traffic offered by a 6-carrier cell is 49.64 Erlangs (60 traffic channels at 2% GOS).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

The number of trunks required to carry traffic on the A Interface with less than 1% blocking is3003. 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 apercent or so), it can be considered negligible and planning can continue. However, there is analternative approach, particularly for the half rate usage, which is discussed here. In fact, it isassumed 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 halfrate enabled carriers would, at worst case, be handling all AMR half rate calls. However, giventhat the AMR-capable mobile penetration is 35%, it is unlikely that all the AMR half rate enabledcarriers are carrying all half rate traffic. Certainly, exclusive (forced) AMR half rate usage couldhave 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 thetrunking 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 1FR 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

The number of trunks required to carry traffic on the A Interface with less than 1% blocking is2946.

9-34 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example 2 (using AMR)

This alternatively calculated number (2946) can be used for the remainder of the calculationsin this section.

# of sites (BTS) per BSC: 20

# of cells per BTS: 3

# of carriers per cell: 6

# TCHs per carrier: 63 (AMR HR, AMR FR, GSM FR/EFR, and so on)

# Control channels per carrier: 4

# 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 major steps for planning the BSC system include:

• 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

• The number of line interface cards (T43s)

68P02900W21-T 9-35

Jul 2010

Planning example 2 (using AMR) Chapter 9: Planning examples

• 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 =

n ∗ (95 + 67 ∗ S + 35 ∗H + 25 ∗ L)1000 ∗ U ∗ T

+(47 + 3 ∗ CBTS) ∗ PGSM + (52 + CBTS) ∗ PGPRS

8000 ∗ U +

6 ∗Mean−TBF−Rate ∗NGPRS1000 ∗ 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 = 59 ∗ 3 ∗ (95 + 67 ∗ 0.12 + 35 ∗ 2.5 + 25 ∗ 2.4)1000 ∗ .25 ∗ 120

+(47 + 3 ∗ 3) ∗ 8 + (52 + 3) ∗ 8

8000 ∗ 0.25+

01000 ∗ 0.25

= Roundup (1.70)

The number of RSLs required per 6/6/6 site (with 2 carriers of AMR HR) = 2

BSC to BTS E1 interconnect planning

Number of E1 links required between a BSC and BTS is given by:

NBSC−BTS =

{[(nEGPRS∑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:

= [((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 siteconfigurations (provided they are in star configurations). Thus, a total of 20 * 2 = 40 E1 linksare required.

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, assuming only GPROC3s are used, is given by:

GL3 =[

n ∗ (1 + 0.35 ∗ S + 0.34 ∗H ∗ (1− 0.4 ∗ i) + 0.32 ∗ L)19.6 ∗ T

+ (0.00075 ∗ PGSM + 0.004) ∗ B +C

120

]

Where n is the number of TCHs under a BSC:

GL3 =[

3540 ∗ (1 + 0.35 ∗ 1.12 + 0.34 ∗ 2.6 ∗ (1− 0.4 ∗ 0.6) + 0.32 ∗ 2.4)19.6 ∗ 100

+ (0.00075 ∗ 8 + 0.004) ∗ 20 +60120

]

9-36 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example 2 (using AMR)

Determining the number of MTLs

Total Erlangs carried by the BSC with 20 sites, and 6/6/6 configuration is given by:

=20 * 3 * 48.70 = 2922 Erlangs

The number of trunks required to carry traffic on the A Interface with less than 1% blocking is2946.

Number of pages per call is given by:

PPC = PGSM ∗ T/N = 8 ∗ 120/2946 = 0.325

Using the call model parameters, the number of MTLs can be calculated using formulaementioned in Chapter 6 BSC planning steps and rules of this manual.

Maximum number of Erlangs supported by a C7 link is given by:

nlink =1000 ∗U ∗ T

(40 + 47 ∗ S + 22 ∗H ∗ (1− 0.8 ∗ i) + 24 ∗ L + 9 ∗ PPC)

nlink =1000 ∗ 0.35 ∗ 120

(40 + 47 ∗ 0.12 + 22 ∗ 2.5 ∗ (1− 0.8 ∗ 0.6) + 24 ∗ 2.4 + 9 ∗ 0.325)= 311.65 Erlangs

Maximum number of Erlangs supported by a GPROC3 supporting a C7 signaling link is given by:

n1LCF−MTL−GPROC =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:

nlog−per−mtl = rounddown(

312184.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

Planning example 2 (using AMR) Chapter 9: Planning examples

The number of MTLs required = 9

Determining the number of LCFs for MTL processing

If GPROC3s are used exclusively:

nMTL−GPROC3 = Rounddown(

n1LCF−MTL−GPROC3

nlmin

)

nMTL−GPROC3 = Rounddown(

139312

)= 4

nLCF−GPROC3 = Rounddown(

MTLsnMTL−GPROC3

)= 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)]

Referring to Table 6-12 in Chapter 6 BSC planning steps and rules,

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

NOTEA total of 3 BSU shelves are required and each shelf must have at least one GPROC (x2 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

XCDR/GDP/GDP2 requirements

N/A (no local RXCDR).

9-38 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example 2 (using AMR)

MSI requirements

Each MSI interfaces two E1 links.

NMSI =NBSC−RXCDR

2

NMSI = Number of MSIs required.

NBSC-RXCDR = Number of E1 links required.

Number of E1 links required at the BSC for interconnecting with the RXCDR is:

NBSC−RXCDR =C + X + B64 + T ∗ (1− PHR) + B16/4 (T ∗ PHR) /8

31

=9 + 2 + 3 + (2946 ∗ (1− 0.18) /4) + ((2946 ∗ 0.18) /4)

31= 24.2

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 MSIsrequired for BTSs is 20 * 2 / 2 = 20.

NOTEThe assumptions are that the system starts allocating AMR HR resources (for AMRHR capable MSs through HO procedures) when certain congestion thresholds arereached. Assuming that 50% of AMR-capable MSs are able to HO to HR (total about18% MSs among all MSs).

Total number of MSIs required at the BSC = 13 + 20 = 33

DSW2 requirements

Extended subrate switching mode (8 kbps switching) is required, so DSW2s are used. Determinethe number of DSW2s (N) required:

N =((G ∗ n) + RGDPXCDR ∗ 16) + REGDP ∗ 80 + (RGDP2 ∗ 24) + (M ∗ 64)

1016

Where: Is:

G the number of GPROCs (11).

n 16 or 32 (16 in this example).

RGDPXCDR N/A in this example.

REGDP N/A in this example.

RGDP2 N/A in this example.

M the number of MSIs (33).

Therefore the total number of timeslots required is:

11 * 16 + 33 * 64 = 2288

68P02900W21-T 9-39

Jul 2010

Planning example 2 (using AMR) Chapter 9: Planning examples

Each DSW2 provides 1016 TDM timeslots. Hence, 3 non-redundant DSW2s are required for thisconfiguration. 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 onthe 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

GPROCs 4 4 3 ≤ 8

MSI cards 11 11 11 ≤ 12

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 neededfor this configuration is NBSU = 3.

KSWX/DSWX requirements

Consider KSWXs/DSWXs for this example as the configuration needs more than one shelf. TheKSWX/DSWX extends the TDM highway of a BSU to other BSUs and supplies clock signals to allshelves in the multi-shelf configuration. The KSWX/DSWX can be used in expansion, remoteand local modes. 3 BSU shelves with 3 master/redundant KSWs/DSW2s are required, whichimplies that 2 expansion shelves are required. The number of KSWXs/DSWXs required (NKX) isthe sum of KSWXDSWXE, KSWX/DSWXR, and KSWX/DSWXL.

NKX = NKXE + NKXR + NKXL

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 KSWXand DSWX connected to DSWX, they can be used together in a shelf.

9-40 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example 2 (using AMR)

GCLK requirements

The generic clock generates all the timing reference signals required by a BSU. One GLCK isrequired at each BSC.

The number of GCLKs required (with redundancy) = 2

CLKX requirements

Provides expansion of GCLK timing to more than one BSU. Number of CLKXs required isgiven 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 + 1) = 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 = 33/3 = 11

The number of T43 boards required is 11

Digital power supply requirements

The number of PSUs required is given by:

One redundant PSU is required for each BSU shelf, hence the total number of PSUs required is:

The total number of PSUs required is 9.

Non-volatile memory (NVM) board for BSC (optional)

An NVM board is required in this example, so NVM = 1.

68P02900W21-T 9-41

Jul 2010

Planning example 2 (using AMR) Chapter 9: Planning examples

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 GPROCs

• The number of MSIs

• The number of DSW2s

• The number of RXU3 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 boards (T43s)

• The number of digital power supply units

• Check if an optional NVM board is fitted

Determining the number of E1 links between the RXCDR and BSC

NBSC−RXCDR =(C + X + B64 + T ∗ (1− PHR) + B16/4 + (T ∗ PHR)) /8

31= 25

Determining the number of E1 links between the RXCDR and MSC

Number of RXCDR to MSC links is given by:

NRXCDR−MSC = (C + X + T) /31

Where: Is:

C the number of MTL links required.

X the number of OML links required.

T the number of trunks between MSC and BSC.

NRXCDR−MSC = (9 + 2 + 2946) /31 = 95.38

~ 96

9-42 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example 2 (using AMR)

The number of E1 links between the RXCDR and MSC = 96

Determining the number of XCDR/GDP/GDP2 cards

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 ofXCDRs, GDPs and GDP2s.

NOTEThe GDP cards can be retained for the existing FR traffic. It is only required toallocate enough GDP2 cards for the additional AMR HR traffic.

During the system planning exercise, it was observed that 31 AMR HR channels are requiredto support AMR HR calls (among 2 carriers/6 carriers/cell). There are a total of 59 TCHs forvoice 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 Determining the number of XCDR/GDP/GDP2 cards

XCDR/GDP/GDP2 Total number needed Number of E1s supported

GDP2 cards 25 (each GDP2 can offer 60voice calls in RXU3 shelf(with enhanced capacitymode enabled) for AMR HRor FR voice calls).

25 * 2 = 50

XCDR/GDP cards 46 (each card supports 30FR voice traffic calls)

46 * 1 = 46

Total number of cards (mix) 71

Total E1s supported 96

GPROC3 requirements for RXCDR

Each shelf should have minimum of one GPROC3. Hence, 5 non-redundant GPROCs arerequired. If the operator selects to use redundancy, 10 GPROC3s are required.

The number of GPROC3s required for RXCDR = 5 + 5 (for redundancy) = 10

MSI requirements for RXCDR

As calculated in MSI requirements, the number of BSC-RXCDR links is 25. Each MSI cardinterfaces 2 E1 links, hence, 13 MSI cards are required on the RXCDR.

MSI requirements for RXCDR = 13

DSW2 requirements for RXCDR

NOTENo enhanced capacity mode is assumed as timeslot usage per shelf is not a limitingfactor in this configuration.

68P02900W21-T 9-43

Jul 2010

Planning example 2 (using AMR) Chapter 9: Planning examples

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 arerequired 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 =M + R + NNVM

19=

13 + 17 + 119

~ 5

Table 9-15 RXU3 shelves

RXU 1 RXU 2 RXU 3 RXU 4 RXU 5

MSIs / 2 E1s (M) 3 3 2 2 3

GDP2s (R) 5 5 5 5 5

GDPs (R) 9 9 9 9 10

Ensure that the following is true for each shelf:

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/DSWX requirements for RXCDR

The number of KSWXs/DSWXs required is the sum of KSWX/DSWXE, KSWX/DSWXR, andKSWX/DSWXL. The calculations imply two expansion and two extension shelves are required.

NKX = NKXE + NKXR + NKXL

NKXE = K ∗ (K− 1) = 3 ∗ (3− 1) = 6

K is the number of non-redundant KSWs/DSW2s.

NKXR = SE = 2

9-44 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example 2 (using AMR)

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

NOTEIf KSWXs and DSWXs are used in like pairs, that is, KSWX connected to KSWX andDSWX connected to DSWX, they can be used together in a shelf.

GCLK requirements

The generic clock generates all the timing reference signals required by the RXU3. One GLCK isrequired at each RXCDR.

Number of GCLKs required = 1 + 1 (redundant) = 2

CLKX requirements

Provides expansion of GCLK timing to more than one RXU3:

NCLKX = Roundup (E/6) ∗ (1 + Rf)

Where: Is:

E the number of expansion/extension shelves.

RF the redundancy factor.

NCLKX = Roundup (4/6) ∗ (1 + 1) = 2

The number of CLKXs required = 1 + 1 (redundant) = 2

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 provides eight inputs and four outputs for site alarms.

PIX ≤ 2 * Number of RXUs = 2 * 5 = 10

Hence, 10 PIX cards are required for the RXCDR.

68P02900W21-T 9-45

Jul 2010

Planning example 3 Chapter 9: Planning examples

Line interfaces

Number of T43s = Number of E1s/6 = (25 + 96)/6 ~ 21

The number of T43 boards required = 15

Digital power supply requirements

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.

Non-volatile memory (NVM) board for RXCDR (optional)

NVM= 1 (required in this example)

Planning example 3

Dimension a network with the following requirements:

• GSM software release = GSR10

• Number of sites 4/4/4 sites (BTS: MCell6) = 62

• Without AMR

• No LCS support

• No fast call setup

Call model parameters

• Call duration T = 96 s

• Ratio of SMSs per call S = 2

• Ratio of location updates per call = 2.0

• Ratio of IMSI detaches per call I = 0.20

• Location update factor L = 2.0 + 0.5 * 0.2 = 2.1

• Number of handovers per call H = 1.32

• Ratio of intra-BSC handovers to all handovers i = 0.6

• Paging rate per second PGSM = 60 pages per second

• Number of cells at the BTS CBTS = 3

• MTL link utilization = 20% (0.20)

• RSL link utilization U = 25% (0.25)

9-46 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example 3

• 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/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

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 throughRXCDR)

68P02900W21-T 9-47

Jul 2010

Planning example 3 Chapter 9: Planning examples

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 GOSof 2% is 23.72 Erlangs and the number of Erlangs supported by 48 TCHs (6-carrier cell) withGOS of 2% is 38.39 Erlangs.

Total Erlangs offered by a 4/4/4 BTS = 3 * 23.72 = 71.16 Erlangs

4-carrier cell - determining the number of CCCHs

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

Access grant rate is given by:

λAGCH = λcall + λS + λLU = 1.23

From the call model parameters, the paging rate P is 60, so the average number of CCCH blocksrequired to support paging only is:

NPCH = PGSM/ (4∗4.25) = 60/ (4∗4.25) = 3.53

The average number of CCCH blocks required to support AGCH only is given by:

NAGCH = λAGCH/ (2∗4.25) = 0.014

Using a CCCH utilization figure (UCCCH) of 0.33, the average number of CCCH blocks requiredto support both PCH and AGCH is given by:

NPAGCH = (NAGCH + NPCH) /UCCCH = (3.53 + 0.014) /0.33 = 10.74

Considering a non-combined BCCH with 9 CCCH blocks, 2 timeslots BCCH+CCCH are neededhere.

9-48 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example 3

Determining the number of SDCCHs per cell

Using the values calculated in the previous section and other call model parameters, theaverage number of SDCCHs and NSDCCH, is given by the formula mentioned in Chapter 3BSS cell planning.

NSDCCH = λcall ∗ Tc + λLU ∗ (TL + Tg) + λs ∗ (Ts + Tg)

= 10.07

To support an average number of busy SDCCHs of 10.07 Erlangs signaling traffic with less than1% blocking is 18 as determined by use of Erlang B tables. Hence, the number of timeslotsrequired to carry SDCCH signaling traffic is 3 with each timeslot offering a maximum of 8SDCCHs.

Determining the number of TCHs

Total number of signaling timeslots required for a 4-carrier configuration with the given callmodel parameters is 5 (2 non-combined BCCH timeslot with 9 CCCHs and 3 timeslots with 8SDCCHs each).

Therefore, the number of traffic channels per 4 carrier cell = 32 - 5 = 27.

Hence, traffic offered by a 4-carrier cell is 19.26 Erlangs (27 traffic channels at 2% GOS).Carried Erlangs is 18.87 Erlangs.

Total channels/cell = 32

Total traffic channels (voice) = 27

Control/signaling channels = 5

BSS planning

The major steps for planning the BSC system include:

• 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

68P02900W21-T 9-49

Jul 2010

Planning example 3 Chapter 9: Planning examples

• 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 kbps RSLs required is given by:

RSLGSM+GPRS@64K = Roundup (RSLGSM + RSLGPRS)

RSLGGSM = n ∗ (59 ∗ S ∗ (25 + SMSSIZE ∗ 0.125) + 38 ∗H + 24 ∗ L+ 24 ∗ LCS)1000 ∗ U ∗ T

+(31 + 3 ∗ CBTS) ∗ PGSM

8000 ∗U

RSLGPRS =(32 + CBTS) ∗ PGPRS

8000 ∗U+

5.5 ∗GPRS−RACH/sec1000 ∗U

Where n is the number of TCHs under the BTS. Hence, for a 4/4/4 site (no GPRS):

RSLGSM+GPRS@64K = Roundup (RSLGSM + RSLGPRS) = Roundup (1.98 + 0)

~ 2

The number of RSLs required per 4/4/4 site is 2.

BSC to BTS E1 interconnect planning

Number of E1 links required between a BSC and BTS is given by:

NBSC−BTS =

{[(nEGPRS∑i=0

RTF−DSO−COUNT)

+ (nCGPRS ∗ 4) + (nGGPRS ∗ 2) + L16/4]}

+ L64

31

Number of E1 links required between each 4/4/4 BTS and BSC:

= (12 * 2 + 2)/31 = 1

Hence, 1 E1 interconnection is required between each BTS and BSC for the given siteconfigurations (provided they are in star configurations). Thus, a total of 62 * 1 = 62 E1 linksare required. The number of E1s between the BSC and BTS is 62.

9-50 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example 3

Determining the number of LCF GPROCs for RSL processing

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)19.6 ∗ T

+ (0.00075 ∗ PGSM + 0.004) ∗ B +C

120

]

Where n is the number of TCHs under a BSC:

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

Determining the number of MTLs

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% blockingis 3602 (using offered Erlangs to calculate).

Using the call model parameters, the number of MTLs can be calculated using formulaementioned in Chapter 6 BSC planning steps and rules or according to the Table 6-12(Number ofHSP MTL at 13% utilization) in 4 HSP MTLs are required (without redundancy).

Determining the number of LCFs for MTL processing

Since one GPROC3-2 LCF can support one HSP MTL, the number of LCFs is equal to thenumber 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, MTLLCF 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 Chapter 9: Planning examples

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 RSLLCF redundancy, the second one for MTL LCF redundancy and the third onefor other GPROC function redundancy.

Total number of GPROCs for BSC = 3 + 17 + 1 + 3 = 24

XCDR/GDP/GDP2 requirements

N/A (no local RXCDR).

MSI requirements

Each MSI interfaces two E1 links.

NMSI = Number of MSIs required.

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 MSIsrequired for BTSs is 62 / 2 = 31.

Total number of MSIs required at the BSC = 31 + 17 = 48

KSW/DSW2 requirements

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: Is:

G the number of GPROCs (11).

n 16 or 32 (32 in this example).

RPSI the number of PSI (N/A in this example)

RGDP2 N/A in this example (RXCDR case).

M the number of MSIs.

9-52 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example 3

NOTERGDPXCDR and REGDP are not considered in the equation.

Therefore the total number of timeslots required is:

24 * 32 + 48 * 64 = 3840

Each KSW/DSW2 provides 1016 TDM timeslots. Hence, 4 non-redundant KSWs/ DSW2s arerequired 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 arerequired, based on the previous calculation. The total number of BSU shelves required is:

Roundup (48/12) = 4 BSU shelves

Total GPROCs = 24 and total MSIs = 48, split between 4 BSU shelves.

BSU 1 BSU 2 BSU 3 BSU 4 Check Limit

GPROCs 6 6 6 6 ≤ 8

MSI cards 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

Therefore, the number of BSU shelves required to accommodate all the hardware neededfor this configuration is NBSU = 4.

KSWX/DSWX requirements

Consider KSWXs/DSWXs for this example as the configuration needs more than one shelf. TheKSWX/DSWX extends the TDM highway of a BSU to other BSUs and supplies clock signals to allshelves in the multi-shelf configuration. The KSWX/DSWX can be used in expansion, remote andlocal modes. Four BSU shelves with four master/redundant KSWs/DSW2s are required, whichimplies that four expansion shelves are required. The number of KSWXs/DSWXs required (NKX)is the sum of KSWXDSWXE, KSWX/DSWXR, and KSWX/DSWXL:

NKX = NKXE + NKXR + NKXL

NKXE = K * (K-1) = 4 * 3 = 12 (K is the number of non-redundant KSWs/DSW2s)

NKXR = SE = 0 (SE is the number of extension shelves)

NKXL = K + SE = 4

NKX = 12 + 4 = 16

The number of KSWXs/DSWXs required (with redundancy) = 32

68P02900W21-T 9-53

Jul 2010

Planning example 3 Chapter 9: Planning examples

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 KSWXand 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 isrequired at each BSC.

The number of GCLKs required (with redundancy) = 2

CLKX requirements

Provides expansion of GCLK timing to more than one BSU. Number of CLKXs required isgiven by:

NCLKX = Roundup (E/6) ∗ (1 + RF)

Where E is the number of expansion/extension shelves and RF is the redundancy factor.

NCLKX = Roundup (4/6) ∗ (2) = 2

The number of CLKXs required (with redundancy) = 2

LANX requirements

NLANX = NBSU ∗ (1 + RF) = 4 ∗ 2 = 8

Total number of LANXs required (with redundancy) = 8

PIX requirements

PIX provides eight inputs and four outputs for site alarms.

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

Digital power supply requirements

The number of PSUs required is given by:

PSUs = NBSU * (2 + RF)

9-54 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example 3

One redundant PSU is required for each BSU shelf, hence the total number of PSUs required is:

PSU = 4 * (2 + 1) = 12

The total number of PSUs required is 12.

Non-volatile memory (NVM) board for BSC (optional)

NVM = 0 or 1

An NVM board is required in this example, so NVM = 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 GPROCs

• The number of MSIs

• The number of RXU shelves

• 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

Determining the number of E1 links between the RXCDR and MSC

Number of RXCDR to MSC links is given by:

NRXCDR−MSC = (C + X + T) /31

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 to0. Then an additional E1 is needed between RXCDR and OMC-R.

68P02900W21-T 9-55

Jul 2010

Planning example 3 Chapter 9: Planning examples

T is the number of trunks between MSC and BSC (3602).

NRXCDR−MSC = (3602) /31 = 116.2

~ 117

The number of E1 links between the RXCDR and MSC = 117

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 3602/31 = 117, which can be a mix ofXCDRs, 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 arerequired. If the operator selects to use redundancy, 16 GPROCs are required.

The number of GPROCs required for RXCDR = 8 + 8 (for redundancy) = 16

MSI requirements for RXCDR

As calculated in MSI requirements, the number of BSC-RXCDR links is 30 and 1 E1 for BSC-OMC-R. Each MSI card interfaces 2 E1 links, hence, 16 MSI cards are required on the RXCDR.MSI requirements for RXCDR = 16.

MSI requirements for RXCDR = 13

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

16 * 16 + 15 * 64 + 117 * 16 = 3216

Each KSW/DSW2 provides 1016 timeslots on the TDM highway, hence, 4 non-redundantKSWs/DSW2s are required for RXCDR with this configuration.

KSWs/DSW2s required for the RXCDR = 4 + 4 (redundant) = 8

Table 9-16 KSW/DSW2 requirements

RXU 1 RXU 2 RXU 3 RXU 4 RXU 5 RXU 6 RXU 7 RXU 8

MSIS 2 2 2 2 2 2 2 2

XCDRS/GDPS 14 14 15 15 15 15 15 14

GPROCS 2 2 2 2 2 2 2 2

Ensure that the following is true for each shelf:

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

System Information: BSS Equipment Planning 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

19=

Max (16/5, (117 + 1))19

= 8

KSWX/DSWX requirements for RXCDR

The number of KSWXs/DSWXs required is the sum of KSWX/DSWXE, KSWX/DSWXR, andKSWX/DSWXL. The calculations imply that two expansion and two extension shelves arerequired.

NKX = NKXE +NKXR +NKXL

NKXE = K ∗ (K − 1) = 4 ∗ 3 = 12

K is the number of non-redundant KSWs/DSW2s.

NKXR = SE = 4

SE is the number of extension shelves.

NKXL = K + SE = 4 + 4 = 8

NKX = 12 + 4 + 8 = 24

NKX = 12 + 4 + 8 = 24

The number of KSWXs/DWSXs required = 24 + 24 (redundant) = 48

If KSWXs and DSWXs are used in like pairs, that is, KSWX connected to KSWX and DSWXconnected 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 isrequired 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)

68P02900W21-T 9-57

Jul 2010

Planning example 3 Chapter 9: Planning examples

Where: Is:

E the number of expansion/extension shelves.

RF the redundancy factor.

NCLKX = Roundup (8/6) ∗ (1 + 0) = 2

The number of CLKXs required = 2 + 2 (redundant) = 4

LANX requirements

Number of LANXs required is given by:

NLANX = NRXU ∗ (1 + RF) = 8 ∗ 2 = 16

Where RF it the redundancy factor.

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

Hence, 16 PIX cards are required for the RXCDR.

Line interfaces

Number of T43s = Number of E1s/6 = (117 + 30 + 4 + 1)/6 = 26

The number of T43 boards required = 26

Digital power supply requirements

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)

9-58 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example of BSS support for LCS provisioning

Planning example of BSS support for LCS provisioning■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Typical parameter values

Use this example to plan the equipment of a BSC supporting a traffic model, with the parameterslisted 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 ANDBSC

N = 3000

NUMBER OF BTSS PER BSS 28 4 * 4 * 4 SITES

NUMBER OF CELLS PER BSS 28 * 3

CALL DURATION T = 75 S

CALL RATE [CALL/SUB/BH] CALL_SUB_RATE = 1

LCS PENETRATION RATE [%] LCS = 5%

LCS REQUEST RATE2: [REQ/SEC/BSC] 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

LCS planning example calculations Chapter 9: Planning examples

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 =n ∗ (49 + 50 + S + 32 ∗H + 25 ∗ L + LCS ∗ 24)

1000 ∗U ∗ T+

(27 + 3 ∗ C) ∗ PGSM ∗ (1 + LCS)8000 ∗U

=87 ∗ (49 + 50 + 0.1 + 32 ∗ 2.5 + 20 ∗ 2 + 0.05 ∗ 24)

1000 ∗ 0.25 ∗ 120+

(27 + 3 ∗ 3) ∗ 3 ∗ (1 + 0.05)8000 ∗ 0.25

= 0.87

9-60 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning LCS planning example calculations

Calculate RSL LCFs

Number of LCF-RSLs required when using GPROC2 boards are as follows:

GL3 =n ∗ (1 + 0.54 ∗ S + 0.48 ∗H ∗ (1− 0.58 ∗ i) + 0.38 ∗ L + 0.35 ∗ LCS)

(18.98 ∗ T)+ (0.00091 ∗ PGSM + 0.004) ∗ B +

C118

=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)

+ (0.00091 ∗ 3 + 0.004) ∗ 28 +28 ∗ 3118

= 4.14

Number of LCF-RSLs required when using GPROC3s or GPROC3-2s boards are as follows:

GL3 =n ∗ (1 + 0.54 ∗ S + 0.506 ∗H ∗ (1− 0.5 ∗ i) + 0.39 ∗ L + 0.35 ∗ LCS)

(35.16 ∗ T)+ (0.00091 ∗ PGSM + 0.002) ∗ B +

C214

=3000 ∗ (1 + 0.54 ∗ 0.1 + 0.506 ∗ 2.5 ∗ (1− .5 ∗ 0.6) + 0.39 ∗ 2 + 0.35 ∗ 0.05)

(35.16 ∗ 120)

+ (0.00091 ∗ 3 + 0.002) ∗ 28 +28 ∗ 3214

= 2.11

Therefore, the RSL LCFs number is 5 when GPROC2s are used and 3 when GPROC3s orGPROC3-2s are used.

Calculate LMTLs

LMTL = Roundup(LCS−BSC−Rate ∗ 19

1000 ∗ UBSC−SMLC

)

= Roundup( 2 ∗ 19

1000 ∗ 0.2

)= 1

Calculate LMTL LCFs

N LCF _LSL = 1

68P02900W21-T 9-61

Jul 2010

Planning example for GSR10 with no (E)GPRS and high signaling Chapter 9: Planning examples

Planning example for GSR10 with no (E)GPRS and highsignaling

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, theMTLs that do not pass through RXCDR).

• No LCS support.

• No FastCallSetup.

Following are the call model parameters:

• 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%.

9-62 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example for GSR10 with no (E)GPRS and high signaling

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 of1% 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 =eT

=50.6091.22

= 0.56

SMS rate is given by:

λS =S ∗ e

T=

13.76 ∗ 50.6091.22

= 7.63

Location update rate is given by:

λLU =L ∗ e

T=

2.73 ∗ 50.6091.22

= 1.51

68P02900W21-T 9-63

Jul 2010

Planning example for GSR10 with no (E)GPRS and high signaling Chapter 9: Planning examples

Access grant rate is given by:

λAGCH = λcall + λS + λLU = 9.70

From the call model parameters, the paging rate P is 60, so the average number of CCCH blocksrequired to support paging only is:

NPCU =PGSM

(4 ∗ 4.25)=

90.80(4 ∗ 4.25)

= 5.34

The average number of CCCH blocks required to support AGCH only is given by:

NAGCH =λAGCH

(2 ∗ 4.25)=

9.70(2 ∗ 4.25)

= 1.14

Using a CCCH utilization figure (UCCCH) of 0.33, the average number of CCCH blocks requiredto support both PCH and AGCH is given by:

NPAGCH =(NAGCH + NPCH)

UCCCH=

(9.70 + 1.14)0.33

= 19.64

Considering a non-combined BCCH with 9 CCCH blocks, 3 timeslots BCCH+CCCH are neededhere.

Determine the number of SDCCHs per cell

Using the values calculated in the previous section and other call model parameters, the averagenumber 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 Erlangssignaling 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 eachtimeslot offering maximum 8 SDCCHs.

Determining the number of TCHs

Total number of signaling timeslots required for an 8 carrier configuration with the given callmodel parameters is 17 (3 non-combined BCCH timeslot with 9 CCCHs and 14 timeslots with 8SDCCHs 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).Carried Erlangs is 34.52 Erlangs.

Total channels/cell = 64

Total traffic channels (voice) = 47

Control and/or signaling channels = 17

9-64 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example for GSR10 with no (E)GPRS and high signaling

BSS planning

The major steps for planning the BSC system include:

• 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

Planning example for GSR10 with no (E)GPRS and high signaling Chapter 9: Planning examples

RSLGSM-GPRS@64k = Roundup (RSLGSM + RSLGPRS)

RSLGSM =n ∗ (59 + S ∗ (25 + SMSGSM ∗ 0.125) + 38 ∗H + 24 ∗ L + 24 ∗ LCS)

(1000 ∗U ∗ T)+

(31 + 3 ∗ CBTS) ∗ PGSM

(8000 ∗U)

RSLGSM =141 ∗ (59 + 13.76 ∗ (25 + 100 ∗ 0.125) + 38 ∗ 3.54 + 24 ∗ 2.75)

(1000 ∗ 0.25 ∗ 91.22)+

(31 + 3 ∗ 3) ∗ 90.80(8000 ∗ 0.25)

= 6.61

GSLGPRS =(32 + CBTS) ∗ PGPRS

(8000 ∗U)+

5.5 ∗GPRS−RACH/sec(1000 ∗U)

Where n is the number of TCHs under the BTS. Hence, for a 8/8/8 site (no GPRS):

RSLGSM + GPRS = Roundup (RSLGSM + RSLGPRS) = Roundup (6.61 + 0) = 7.

The number of RSLs required per 8/8/8 site is 7.

BSC to BTS E1 interconnect planning

Number of E1 links required between a BSC and BTS is given by:

nEGPRS∑

RTF DSO COUNTi

i = 0

+ (nCGPRS ∗ 4) + (nGGPRS ∗ 2) + L16/4

+ L64

31

Number of E1 links required between each 4/4/4 BTS and BSC:

= (24 * 2 + 7)/31 = 2

Hence, one E1 interconnection is required between each BTS and BSC for the given siteconfigurations (provided they are in star configurations). There are total of 31 * 2 = 62 E1 linksneeded. The number of E1s between the BSC and BTS is 62.

Determining the number of LCF GPROCs for RSL processing

Number of LCF-RSLs required when using GPROC2 boards are as follows:

GL3 =n ∗ (1 + 0.54 ∗ S + 0.48 ∗H ∗ (1− 0.58 ∗ i) + 0.38 ∗ L)

(18.98 ∗ T )+ (0.00091 ∗ PGSM + 0.004) ∗ B +

C

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)

+ (0.00091 ∗ 90.80 + 0.004) ∗ 31 +31 ∗ 3118

= 29.45 ∼ 30

9-66 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example for GSR10 with no (E)GPRS and high signaling

Number of LCF-RSLs required when using GPROC3 or GPROC3-2 boards are as follows:

GL3 =n ∗ (1 + 0.54 ∗ S + 0.506 ∗H ∗ (1− 0.5 ∗ i) + 0.39 ∗ L)

(35.16 ∗ T)+ (0.00091 ∗ PGSM + 0.002) ∗ B +

C214

=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)

+ (0.00091 ∗ 90.80 + 0.002) ∗ 31 +31 ∗ 3214

= 17.35 ∼ 18

The maximum number of LCFs supported is 25 so the expected load cannot be supportedby GPROC2 boards and GPROC3 or GPROC3-2 boards are required to support the LCFs forRSL processing.

Determining the number of MTLs

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% blockingis 3297 (using offered Erlangs to calculate).

Using the call model parameters, the number of MTLs can be calculated using formulamentioned in Chapter 6 BSC planning steps and rules. Or according to the Table 6-12(Numberof HSP MTL at 13% utilization) in Chapter 6 BSC planning steps and rules, 4 HSP MTLs arerequired (without redundancy).

Determining the number of LCFs for MTL processing

Since one GPROC3-2 LCF can support one HSP MTL, the number of required LCFs is thenumber of HSP MTLs.

NLCF = mtls

The number of LCFs for 4 HSP MTLs is 4.

XBL requirements

Referring to Table 6-12 in Chapter 6 BSC planning steps and rules,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

Planning example for GSR10 with no (E)GPRS and high signaling Chapter 9: Planning examples

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 isfor the RSL LCF redundancy, the second is for the MTL LCF redundancy, andthe third is for the GPROC function redundancy. For GPROC redundancy,refer to Chapter 6 BSC planning steps and rules. GPROC3 or GPROC3-2s arerequired for the RSL LCFs. It is recommended that the pool GPROCs are alsoGPROC3s/GPROC3-2s.

L = Total number of LCF GPROCs required = 22 (where the number of RSL LCF is 18 andMTL LCF is 4).

NOTEFor MTL-LCF, GPROC3-2 is required.

Total number of GPROCs for BSC = 3 + 22 + 1 + 3 = 29.

XCDR/GDP/GDP2 requirements

N/A (no local RXCDR).

MSI requirements

Each MSI interfaces two E1 links.

NMSI =NBSC−RXCDR

2

NMSI = Number of MSIs required.

NBSC-RXCDR = Number of E1 links required at the BSC for interconnecting with the RXCDR.

NBSC−RXCDR =

{C+X+B64+[T∗(1−PHR)+N16]

4 + (T∗PHR)8

}

31

If HSP MTLs directly connected to the MSC are used and the HR is not supported:

NBSC−RXCDR =(C + (X + B64 + T/4))

31=

0 + (2 + 4 + 3297/4)31

= 26.78 ∼ 27

Where 2 OMLs, and 4 XBLs are required.

9-68 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example for GSR10 with no (E)GPRS and high signaling

NOTEPHR in the previous equation is not considered in non-HR cases. Additional 4 E1sare 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 MSIsrequired for BTSs is 62 / 2 = 31.

Total number of MSIs required at the BSC = 31 + 16 = 47.

KSW/DSW2 requirements

Determine the number of KSWs/DSW2s (N) required (if enhanced capacity mode is not enabled).

N = (G ∗ n) + (Rgdprxcdr ∗ 16) + (Regdp2 ∗ 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)

NOTERGDPXCDR and REGDP are not considered in the previous equation.

Therefore the total number of timeslots required is:

29 * 32 + 47 * 64 = 3936

Each KSW/DSW2 provides 1016 TDM timeslots. Hence, four non-redundant KSWs/ DSW2s arerequired for this configuration, irrespective of the GPROC used for RSl LCF functionality. Forredundancy, 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 arerequired, based on the previous calculation. The total number of BSU shelves required is:

Roundup (47/12) = 4 BSU shelves

Total GPROCs = 29 and total MSIs = 47, split between 4 BSU shelves:

BSU1 BSU2 BSU3 BSU4 Check Limit

GPROCs 7 7 7 8 ≤ 8

MSI cards 12 12 12 11 ≤ 12

Where BSU 1, 2, 3, 4 have KSW/DSW2 in shelf.

68P02900W21-T 9-69

Jul 2010

Planning example for GSR10 with no (E)GPRS and high signaling Chapter 9: Planning examples

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 thisconfiguration is NBSU = 4.

KSWX/DSWX requirements

KSWXs/DSWXs should be considered for this example as the configuration requires morethan one shelf. The KSWX/DSWX extends the TDM highway of a BSU to other BSUs andsupplies clock signals to all shelves in the multi-shelf configuration. The KSWX/DSWX may beused in expansion, remote, and local modes. Four BSU shelves with four master/redundantKSWs/DSW2s, which implies four expansion shelves are required. The number of KSWXs/DSWXsrequired (NKX) is the sum of KSWX/DSWXE, KSWX/DSWXR, and KSWX/DSWXL:

NKX = NKXE + NKXR + NKXL

• 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.

NOTEThe maximum number of KSWX/DXWX slots per shelf ≤ 18. If KSWXs and DSWXsare used in like pairs, that is, KSWX connected to KSWX and DSWX connected toDSWX, 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 isrequired at each BSC.

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 isgiven by:

NCLKX = Roundup(

E6

)∗ (1 + RF)

9-70 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example for GSR10 with no (E)GPRS and high signaling

Where E is the number of expansion/extension shelves and RF is the redundancy factor.

NCLKX = Roundup(

46

)∗ 2 = 2

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:

PIX ≤ Number of BSUs = 8

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.

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:

PSU = 4 ∗ (2 + 1) = 12

Non volatile memory (NVM) board for BSC (optional)

An NVM board is required in this example, so NVM = 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.

68P02900W21-T 9-71

Jul 2010

Planning example for GSR10 with no (E)GPRS and high signaling Chapter 9: Planning examples

• 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.

Determining the number of E1 links between the RXCDR and BSC

Refer to MSI requirements in BSS planning on page 9-65

Determining the number of E1 links between the RXCDR and MSC

Number of RXCDR to MSC links is given by the greater of the results for the following equations:

NRXCDR−MSC = C2M +(

T30

)

NRXCDR−MSC + C2M +(X + T)

31

Where:

• C2M is the number of HSP MTL links required. HSP MTLs go from BSC to MSC directlyso 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.

Determining the number of XCDR/GDP/GDP2 cards

Each GDP terminates one E1 link and each GDP2 can terminate one or two E1 links dependingon the RXU shelf used.

9-72 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Planning example for GSR10 with no (E)GPRS and high signaling

Hence, the number of non-redundant cards required based on GDP2s terminating two E1sis (3297/30)/2 = 55.

MSI Requirements for RXCDR

As calculated in MSI requirements, the number of BSC-RXCDR links is 27. Each MSI cardinterfaces 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):

NRXU = Max(

M/5,(R + NNVM)

16

)= Max

(145,

(55 + 1)16

)= 4

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.

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 = 8 * 16 + 14 * 64 + 55 * 24 = 2344

Each KSW/DSW2 provides 1016 timeslots on the TDM highway, hence, three non-redundantKSWs/DSW2s are required for RXCDR with this configuration.

KSWs/DSW2s required for the RXCDR = 3 + 3 (redundant) = 6.

RXU1 RXU2 RXU3 RXU4

MSIs 4 4 3 3

GDP2s 14 14 14 13

GPROCs 2 2 2 2

Ensure that the following is true for each shelf:

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 ofRXU shelves required = 4.

KSWX/DSWX requirements for RXCDR

The number of KSWXs/DSWXs required is the sum of KSWX/DSWXE, KSWX/DSWXR, andKSWX/DSWXL. The above calculations imply that two expansion and two extension shelves arerequired.

NKX = NKXE + NKXR + NKXL

= K ∗ (K− 1) = 4 ∗ 3 + 12

68P02900W21-T 9-73

Jul 2010

Planning example for GSR10 with no (E)GPRS and high signaling Chapter 9: Planning examples

K is the number of non-redundant KSWs/DSW2s.

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.

NOTEIf KSWXs and DSWXs are used in like pairs, that is, KSWX connected to KSWX andDSWX 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 isrequired at each RXCDR.

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

Number of LANXs required is given by:

NLANX = NRXU ∗ (1 + RF) = 8 ∗ 2 = 16

Where RF it the redundancy factor.

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

System Information: BSS Equipment Planning Planning example for GSR10 with no (E)GPRS and high signaling

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.

Digital power supply requirements

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 9-75

Jul 2010

Planning example for GSR10 with no (E)GPRS and high signaling Chapter 9: Planning examples

9-76 68P02900W21-T

Jul 2010

Chapter

10

Location area planning■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

■

■

This section provides a description of location area planning with an example. Each operatorshould undertake this exercise to optimize the network configurations based on the paging loadon 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 10-1

Jul 2010

Location area planning considerations Chapter 10: Location area planning

Location area planning considerations■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Before the GSR4 BSS software release, the traffic handled by the BSC was limited by thenumber of BTSs and carriers that could be handled by the BSC. Increasing BSC capacities havean 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 inthat location area. If there are too many BSCs in a location area, each with large number ofBTS sites and high traffic handling capacity, it results in high paging load on each of the BSCsin that location area. This leads to more hardware (LCF GPROCs) having to be equipped oneach BSC. Increasing the number of location areas increases the number of location updateson the cells bordering the location area. Provision more SDCCHs for this increased signalingon the border cells. Fewer channels are available for traffic.

A well-planned network should have similar paging loads in each location area. A small pagingload suggests that the location area is too small and could be combined with neighboringlocation areas, minimizing location update activity, and reducing use of SDCCH resources. Apaging load too close to the theoretical maximum paging load (calculated using the number ofPCHs used and if mobile is paged using IMSI or TMSI) would suggest that the location areais too large and should be split into multiple location areas, to avoid paging overload and theneed for extra hardware.

This exercise should be undertaken by each operator to optimize the network configurationsbased on the paging load on the BSC. This topic is explained further, with an example, in thefollowing sections.

10-2 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 callmodel parameters as shown in Table 10-1.

Table 10-1 Example of values for the parameters for location area planning

Parameter sValue

Call duration, T 90 s

Number of SMSs per call, S 2

Number of location updates per call (nonborder) 2

IMSI detaches per call, Id 0.2 (type 2)

Location update factor 2 + 0.5 * 0.2 = 2.1

Number of handovers per call, H 1.32

Number of intra-BSC handovers to all handovers, i 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 1.2

Ratio of incoming calls and SMSs to the total calls and SMSs 0.50

Further assume that each of the BSC handles about 1200 Erlangs (48 sites with 2/2/2configurations and 2 sites with omni 2 configuration) of traffic.

68P02900W21-T 10-3

Jul 2010

Example procedure Chapter 10: Location area planning

Figure 10-1 Four BSCs in one LAC

MSC

BSC BSC BSC BSC

LAC=1

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 SMS ∗ total calls and SMS 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 theformula 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 of2% is 9.83 Erlangs.

λcall = e/T

Use the formulae provided in Chapter 3 BSS cell planning for control channel calculationsas follows:

10-4 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 that1% blocking as determined by use of Erlang B tables, is 10. Hence, the number of timeslotsrequired 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):

NPCH−GSM = PGSM/(N ∗Pages/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 locationarea contains two BSCs (refer to Figure 10-2). Dividing the location area into two location areasincrease the location updates on the border cells. Assume that 25% of the cells under a BSCbecome border cells (a conservative estimate) and the number of location updates per call goesup to 6 on cells on the location area border. The average number of location updates per call forthe BSC would approximately be equal to 3 (0.25*6 + 0.75*2).

68P02900W21-T 10-5

Jul 2010

Example procedure Chapter 10: Location area planning

Figure 10-2 Four BSCs divided into two LACs

MSC

BSC BSC BSC BSC

LAC = 1 LAC = 2

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:

Paging 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

= 7GPROC2RSL LCFs

This simple expedient of reducing the number of BSCs in a LA has reduced the required numberof GPROC2 RSL-LCFs by 1 per BSC, and therefore 4 GPROC2s for the whole LA of 4 BSCs.

10-6 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 than1% blocking as determined by use of Erlang B tables, is 11. Hence, the number of timeslotsrequired 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):

NPCH−GSM = PGSM/(N ∗Pages/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 tosupport this level of paging.

This result shows that with the same number of timeslots for SDCCHs for this example, inaddition to reduced timeslots of CCCH (PCH), savings on equipment could be achieved by thesimple expedient of decreasing the number of BSCs per LA. The increase in SDCCHs due toincreased 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 borderof the location area (resulting in a lower number of location updates), even fewer resourcesare required of the air interface for location update signaling.

68P02900W21-T 10-7

Jul 2010

Example procedure Chapter 10: Location area planning

10-8 68P02900W21-T

Jul 2010

Chapter

11

Call model parameters■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

■

■

The derivation of call model parameter values from the GSM network statistics collected at theOMC-R are described in this chapter. Most of the calculations used for equipment planninguse the standard call model parameters. Each network behaves in a unique way. Hence, theoperators must compute their own set of call model parameter values for a network based onthe performance statistics collected at the OMC-R. This helps to optimize the configurationson a network.

All the statistics used for determining the call model parameters must be collected during thebusy 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 theBSC level for equipment dimensioning purposes. This helps in averaging out the load fromthe network entities.

The topic described here is Deriving call model parameters from network statistics.

68P02900W21-T 11-1

Jul 2010

Deriving call model parameters from network statistics Chapter 11: Call model parameters

Deriving call model parameters from network statistics■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Standard call model parameters

Table 11-1 lists the standard call model parameters.

Table 11-1 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

Number of handovers per call (Refer to NOTE) H = 3.54

Ratio of location updates to calls: non-borderlocation area.Ratio of location updates to calls: border locationarea

l = 2I = 2.73

l = 2I = 7

Ratio of IMSI detaches to calls I = 0.05

Location update factor: non-border location area(Refer to NOTE)Location update factor: border location area (Referto NOTE)

L = 2L = 2.75

L = 2L = 7.02

GSM circuit-switched paging rate in pages persecond

PGSM = 90.8

Ratio of intra-BSC handovers to all handovers (Referto NOTE)

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 64 k 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

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 B-TCHs = 1%

Block Rate for MSC-BSS trunks PB-Trunks = 0%

Continued

11-2 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Standard call model parameters

Table 11-1 Typical parameters for BTS call planning (Continued)

Busy hour peak signaling traffic model Parameter reference

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 sub/BH (kBytes/hr) - Uplink ULRATE = 1.48

GPRS Traffic per sub/BH (kBytes/hr) - Downlink DLRATE = 5.96

Average sessions per subscriber (per BH) Avg_Sessions_per_sub = 0.026

Average SMS message size (payload only) SMSSIZE = 100 bytes

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/MAClayer

CS1 = 9.2 kbpsCS2 = 13.6 kbpsCS3 = 15.8 kbpsCS4 = 21.8 kbps

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%CS4_usage_UL = 45.5%CS4_usage_DL = 35.5%

Percentage GPRS coding scheme usage in totaltraffic (Refer to NOTE)

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

Continued

68P02900W21-T 11-3

Jul 2010

Standard call model parameters Chapter 11: Call model parameters

Table 11-1 Typical parameters for BTS call planning (Continued)

Busy hour peak signaling traffic model Parameter reference

EGPRS Traffic per sub/BH (kBytes/hr) - Downlink DLRATE = 5.96

Average sessions per subscriber (per BH) Avg_Sessions_per_sub = 0.026

Avg_Sessions_per_sub = 0.64 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 (MCS1 to MCS9) at theRLC/MAC layer

MCS1 = 10.55 kbpsMCS2 = 12.95 kbpsMCS3 = 16.55 kbpsMCS4 = 19.35 kbpsMCS5 = 23.90 kbpsMCS6 = 29.60 kbpsMCS7 = 31.10 kbpsMCS8 = 46.90 kbpsMCS9 = 61.30 kbps

Coding scheme usage (MCS1 to MCS9) at a BLERof 12.02%

MCS1_usage_UL = 0.5%MCS1_usage_DL = 11%MCS2_usage_UL = 2%MCS2_usage_DL = 12%MCS3_usage_UL = 4.5%MCS3_usage_DL = 8.5%MCS4_usage_UL = 5.5%MCS4_usage_DL = 7%MCS5_usage_UL = 15.5%MCS5_usage_DL = 5%MCS6_usage_UL = 47.75%MCS6_usage_DL = 19%MCS7_usage_UL = 3.5%MCS7_usage_DL = 8%MCS8_usage_UL = 8.5%MCS8_usage_DL = 8%MCS9_usage_UL = 12.25%MCS9_usage_DL = 21.5%

Percentage EGPRS coding scheme usage in totaltraffic (Refer to NOTE)

CSuse_UL_EGPRS = 12.1%CSuse_DL_EGPRS = 9.9%

Average packet size for GPRS and EGPRS traffic mix(bytes) – Uplink (Refer to NOTE)

PKULSIZE = 130.75

Average packet size for GPRS and EGPRS traffic mix(bytes) – Downlink (Refer to NOTE)

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_UL = 12.69

11-4 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 IMSIdetach: short message sequence (type 1) and long message sequence (type 2)and whether short message sequence (type 1) or long message sequence (type2) 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 trafficmix, which is network-dependent. The percentages can be used to determinethe 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) = (PercentageGPRS coding scheme usage in total traffic * GPRS Traffic per sub/BH) +(Percentage EGPRS coding scheme usage in total traffic * EGPRS Trafficper sub/BH)

• The average packet sizes for a GPRS and EGPRS traffic mix are based on theGPRS and EGPRS percentage splits defined for this model.

• The MS in the extended range has a lower coding scheme than in the normalrange due to the longer distance between the MS and BTS. For the cell withextended PDCH, the lower coding scheme has a higher usage percentage valuethan 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 andTOTAL_CALLS using the following formula:

T =

N∑i=1

Busy−TCH−MEAN ∗ stat−interval−in−sec

N∑i=1

TOTAL−CALLS + ASSIGNMENT−REDIRECTION

68P02900W21-T 11-5

Jul 2010

Ratio of SMSs per call (S) Chapter 11: Call model parameters

Where: Is:

N number of cells under the BSC.

BUSY_TCH_MEAN average number of busy TCHs in the cell. It is updated each time anallocation or de-allocation of a TCH occurs. It provides a mean valueindicating the average number of TCHs in use. The time recordedfor a TCH in use includes the guard time (T3111), which is the timeallowed between ending a call and starting another call.

TOTAL_CALLS number of circuit-oriented calls that originate in the cell. It ispegged only once per connection at the time of the first successfulTCH assignment procedure. Subsequent channel changes are notcounted.

ASSIGNMENT_REDIRECTION

total number of assignments that were redirected to another cell,due to redirected retry handover procedure, multiband bandreassignment procedure, or handover during assignment procedure.

stat_interval_in_sec interval in which statistics are collected. It is 3600 if the statisticinterval 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 averageof 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 parametersin the following formula:

S =

N∑i=1

(SMS−INIT−ON−SDCCH + SMS−INIT−ON−TCH)

N∑i=1

(TOTAL−CALLS + ASSIGNMENT−REDIRECTION)

Where: Is:

N number of cells under the BSC.

SMS_INIT_ON_SDCCH number of times an SMS transaction occurs on an SDCCH.

SMS_INIT_ON_TCH 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 thefirst successful TCH assignment procedure. Subsequentchannel changes are not counted.

ASSIGNMENT_REDIRECTION total number of assignments that were redirected toanother cell, due to redirected retry handover procedure,multiband band reassignment procedure, or handoverduring assignment procedure.

The ratio of SMSs per call must be averaged over all the BSCs in the network.

11-6 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Ratio of handovers per call (H)

Ratio of handovers per call (H)

Handovers can be inter-BSS, intra-BSS or intra-cell. Therefore, the number of handovers percall can be calculated using the following formula:

H =

N∑i=1

(out−inter−bss−req−to−msc+ out−intra−bss−ho−atmp+

intra−cell−ho−atmp

)

N∑i=1

(TOTAL−CALLS + ASSIGNMENT−REDIRECTION)

Where: Is:

N number of cells under the BSC.

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 toinitiate an outgoing intra-BSS handover attempt.

intra_cell_ho_atmpt number of times an assignment command is sent to an MS, toinitiate an intra-cell handover attempt.

TOTAL_CALLS number of circuit-oriented calls that originate in the cell. Itis pegged only once per connection at the time of the firstsuccessful TCH assignment procedure. Subsequent channelchanges are not counted.

ASSIGNMENT_REDIRECTION

total number of assignments that were redirected to anothercell, due to redirected retry handover procedure, multibandband reassignment procedure, or handover during assignmentprocedure.

H should be averaged over all the BSCs in the network.

NOTEThe 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 =

N∑i=1

(out−intra−bss−ho−atmpt + intra−call−ho−atmpt)

N∑i=1

(out−inter−bss−req−to−msc + out−intra−bss−ho−atmpt + intra−cell−ho−atmpt)

68P02900W21-T 11-7

Jul 2010

Ratio of location updates per call (I) Chapter 11: Call model parameters

Where: Is:

N number of cells under the BSC.

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∑i=1

OK−ACC−PROC [location−update]

N∑i=1

(TOTAL−CALLS + ASSIGNMENT−REDIRECTION)

Where: Is:

N number of cells under the BSC.

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 thefirst successful TCH assignment procedure. Subsequentchannel changes are not counted.

ASSIGNMENT_REDIRECTION counts the total number of assignments that wereredirected to another cell, due to redirected retryhandover procedure, multiband band reassignmentprocedure, 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 =

N∑i=1

(OK−ACC−PROC [imsi−detach])

N∑i=1

(TOTAL−CALLS + ASSIGNMENT−REDIRECTION)

11-8 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Location update factor (L)

Where: Is:

N 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 inthe cell. It is pegged only once per connection at thetime of the first successful TCH assignment procedure.Subsequent channel changes are not counted.

ASSIGNMENT_REDIRECTION counts the total number of assignments that wereredirected to another cell, due to redirected retry handoverprocedure, multiband band reassignment procedure, orhandover during assignment procedure.

The ratio I should be averaged over all the BSCs in the network.

Location update factor (L)

The location update factor is calculated using the ration of location updates per call (l) and theratio of IMSI detaches per call (I). For networks with IMSI detach disabled, the location updatefactor equals the ratio of location updates per call (l).

If IMSI detach is enabled, L is calculated as follows depending on whether short messagesequence (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 receivingthe IMSI detach. When using IMSI detach type 1, the MSC clears the SCCP connection, aclearing procedure that involves only one uplink (average size of 42 bytes) and one downlinkmessage (average size of 30 bytes). When using IMSI detach type 2, the MSC sends the CLEARCOMMAND and the BSS sends CLEAR COMPLETE, which involves three uplink (averagesize of 26 bytes) and three downlink messages (average size of 30 bytes). A location updateprocedure 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 ofmessages as a location update and an IMSI detach (type 2) takes 6/11 (approximately 0.5) ofthe messages of a location update.

Paging rate (PGSM)

PAGE_REQ_FROM_MSC counts the number of paging messages received by the BSS fromthe MSC during the statistics time interval. The paging message is then sent to the BSS inan attempt to locate a particular MS. Each message refers only to one MS. The BSS in turntransmits 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) Chapter 11: Call model parameters

An MS is paged in a location area, which encompasses multiple BSCs. It is also possible tohave multiple location areas within a BSC. The paging rate, therefore, is a summation of thepaging messages sent to each location area in a BSC, averaged over the interval period. SincePAGE_REQ_FROM_MSC is kept on a per cell basis, the value of this counter for any cell inthat location area, for a given statistics interval, denotes the pages in the location area duringthat statistics interval.

PGSM =

N∑i=1

(PAGE−REQ−FROM−MSC)

N∑i=1

(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 receivedpertaining 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∑i=1

(PAGE−REQ−FROM−MSC)

N∑i=1

(TOTAL−CALLS + ASSIGNMENT−REDIRECTION)

Where: Is:

N number of cells under the BSC.

Alternatively, pages per call can be calculated using the formula:

PPC = PGSM ∗ (T/N)

Where: Is:

N number of MSC-BSC trunks.

T call duration, in seconds.

PPC = PGSM ∗ (T/e)

Where: Is:

e BSC Erlang.

11-10 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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 thefollowing formulae:

U(MSC−BSS) =(MTP−MSU−TX ∗ 6) + MTP−SIF−SIO−TX + (SIB−TX ∗ 7)

MTP−LINK−INS ∗MTL−Rate ∗ 8

U(MSC−BSS) =(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 length of time a signaling link is in service in milliseconds.

MTL_Rate number of DS0 channels on E1 that are equipped as MTL. Forexample, MTL_Rate = 1 means only one DS0 channel is equipped asMTL, 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 becalculated using the following formulae:

U(BSC−BTS) =RSL−TX−OCTETS

RSL−LINKS−INS ∗ RSL−BANDWIDTH−FACTOR ∗ 2∗ 100%

U(BSC−BTS) =RSL−RX−OCTETS

RSL−LINK−INS ∗ RSL−BANDWIDTH−FACTOR ∗ 2∗ 100%

Where: Is:

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 the length of time a signaling link is in service inmilliseconds.

RSL_BANDWIDTH_FACTOR A factor based on the rate of the RSL. It has a value of 1 for16 kbps RSLs and a value of 4 for 64 kbps RSLs.

68P02900W21-T 11-11

Jul 2010

Percent Link Utilization BSC to SMLC (U(BSC – SMLC)) Chapter 11: Call model parameters

Percent Link Utilization BSC to SMLC (U(BSC – SMLC))

The percent link utilization BSC to SMLC on the uplink and downlink may be calculated usingthe following formulas:

U(BSC−SMLC) =

N∑i=1

(LMTP−MSU−TX ∗ 6) + LMTP−SIF−SIO−TX + (LMTP−SIB−TX ∗ 7)

N∑i=1

LMTP−LINK−INS ∗ 8

U(BSC−SMLC) =

N∑i=1

(LMTP−MSU−RX ∗ 6) + LMTP−SIF−SIO−RX + (LMTP−SIB−RX ∗ 7)

N∑i=1

LMTP−LINK−INS ∗ 8

Where: Is:

N 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∑i=1

ALLOC−TCH−FAIL− TCH−Q−REMO V ED [assignment−resource−req]

− TCH−Q−REMO V ED [ho−req]

N∑i=1

ALLOC−TCH +ALLOC−TCH−FAIL

− TCH−Q−REMO V ED [assignment−resource−req]

− TCH−Q−REMO V ED [ho−req]

Where: Is:

N number of cells under the BSC.

ALLOC_TCH_FAIL number of times a TCH is unsuccessfully allocated in a cell fororiginations and hand ins.

Continued

11-12 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning GPRS CS1 uplink usage (CS1_usage_UL)

Where: Is:

TCH_Q_REMOVED[assignment_resource_req]

number of times a queued assignment request is allocated aTCH.

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 calloriginations, hand ins.

GPRS CS1 uplink usage (CS1_usage_UL)

The coding scheme usage on the uplink for GPRS CS1 is calculated using the following formula:

CSI−usage−UL =

(UL−RADIO−B LKS−8PSK−1−TS−CS−1 + UL−RADIO−B LKS−2−TS−CS−1+

UL−RADIO−BLKS−GMSK−1−TS−CS−1 + UL−RADIO−B LKS−GMSK−2−TS−CS−1

)∗ 100

(UL−RADIO−BLKS−8PSK−1−TS + UL−RADIO−BLKS−8PSK−2−TS+

UL−RADIO−BLKS−GMSK−1−TS + UL−RADIO−BLKS−GMSK−2−TS

)

Where: Is:

UL_RADIO_BLKS_8PSK_1_TS_CS_1 number of radio blocks received in the UL forCS1 from MSs capable of 8-PSK that support amaximum of 1 TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS_CS_1 number of radio blocks received in the UL forCS1 from MSs capable of 8-PSK that support amaximum of 2 TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS_CS_ 1 number of radio blocks received in the UL forCS1 from MSs capable of 8-PSK that support amaximum of 1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS_CS_ 1 number of RLC radio blocks received in the ULfor CS1 from MSs capable of 8-PSK supporting amaximum of 2 TS in the UL.

UL_RADIO_BLKS_8PSK_1_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximum of 1TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximum of 2TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximum of 1TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximum of 2TS in the UL.

68P02900W21-T 11-13

Jul 2010

GPRS CS1 downlink usage (CS1_usage_DL) Chapter 11: Call model parameters

GPRS CS1 downlink usage (CS1_usage_DL)

The coding scheme usage on the downlink for GPRS CS1 is calculated using the followingformula:

CS1−usage−DL =

(DL−RADIO−BLKS−1−TS−CS−1 +DL−RADIO−BLKS−2−TS−CS−1+

DL−RADIO−BLKS−3−TS−CS−1 +DL−RADIO−BLKS−4−TS−CS−1

)∗ 100

(DL−RADIO−BLKS−1−TS +DL−RADIO−BLKS−2−TS+

DL−RADIO−BLKS−3−TS +DL−RADIO−BLKS−4−TS

)

Where: Is:

DL_RADIO_BLKS_1_TS_CS_1 number of radio blocks received in the DL for CS1 fromMSs supporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS_CS_1 number of radio blocks received in the DL for CS1 fromMSs supporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS_CS_1 number of radio blocks received in the DL for CS1 fromMSs supporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS_CS_1 number of radio blocks received in the DL for CS1 fromMSs supporting a maximum of 4 TS in the DL.

DL_RADIO_BLKS_1_TS number of radio blocks received in the DL from MSssupporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS number of radio blocks received in the DL from MSssupporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS number of radio blocks received in the DL from MSssupporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS number of radio blocks received in the DL from MSssupporting a maximum of 4 TS in the DL.

GPRS CS2 uplink usage (CS2_usage_UL)

The coding scheme usage on the uplink for GPRS CS2 can be calculated using the followingformula:

CS2−usage−UL =

(UL−RADIO−BLKS−8PSK−1−TS−CS−2 + UL−RADIO−BLKS−8PSK−2−TS−CS−2+

UL−RADIO−BLKS−GMSK−1−TS−CS−2 + UL−RADIO−BLKS−GMSK−2−TS−CS−2

)∗ 100

(UL−RADIO−BLKS−8PSK−1−TS + UL−RADIO−BLKS−8PSKS−2−TS+

UL−RADIO−BLKS−GMSK−1−TS + UL−RADIO−BLKS−GMSK−2−TS

)

11-14 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning GPRS CS2 downlink usage (CS2_usage_DL)

Where: Is:

UL_RADIO_BLKS_8PSK_1_TS_CS_2 number of radio blocks received in the UL for CS2from MSs capable of 8-PSK that support a maximumof 1 TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS_CS_2 number of radio blocks received in the UL for CS2from MSs capable of 8-PSK that support a maximumof 2 TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS_CS_2 number of radio blocks received in the UL for CS2from MSs capable of 8-PSK that support a maximumof 1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS_CS_2 number of RLC radio blocks received in the ULfor CS2 from MSs capable of 8-PSK supporting amaximum of 2 TS in the UL.

UL_RADIO_BLKS_8PSK_1_TS number of radio blocks received in the UL from MSscapable of 8-PSK supporting a maximum of 1 TS inthe UL.

UL_RADIO_BLKS_8PSK_2_TS number of radio blocks received in the UL from MSscapable of 8-PSK supporting a maximum of 2 TS inthe UL.

UL_RADIO_BLKS_GMSK_1_TS number of radio blocks received in the UL from MSscapable of GMSK supporting a maximum of 1 TS inthe UL.

UL_RADIO_BLKS_GMSK_2_TS number of radio blocks received in the UL from MSscapable of GMSK supporting a maximum of 2 TS inthe UL.

GPRS CS2 downlink usage (CS2_usage_DL)

The coding scheme usage on the downlink for GPRS CS2 is calculated using the followingformula:

CS2−usage−DL =

(DL−RADIO−BLKS−TS−CS−2 +DL−RADIO−BLKS−2−TS−CS−2+

DL−RADIO−BLKS−3−TS−CS−2 +DL−RADIO−BLKS−4−TS−CS−2

)∗ 100

(DL−RADIO−BLKS−1−TS +DL−RADIO−BLKS−2−TS+

DL−RADIO−BLKS−3−TS +DL−RADIO−BLKS−4−TS

)

Where: Is:

DL_RADIO_BLKS_1_TS_CS_2 number of radio blocks received in the DL for CS2 fromMSs supporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS_CS_2 number of radio blocks received in the DL for CS2 fromMSs supporting a maximum of 2 TS in the DL.

Continued

68P02900W21-T 11-15

Jul 2010

GPRS CS3 uplink usage (CS3_usage_UL) Chapter 11: Call model parameters

Where: Is:

DL_RADIO_BLKS_3_TS_CS_2 number of radio blocks received in the DL for CS2 fromMSs supporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS_CS_2 number of radio blocks received in the DL for CS2 fromMSs supporting a maximum of 4 TS in the DL.

DL_RADIO_BLKS_1_TS number of radio blocks received in the DL from MSssupporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS number of radio blocks received in the DL from MSssupporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS number of radio blocks received in the DL from MSssupporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS number of radio blocks received in the DL from MSssupporting a maximum of 4 TS in the DL.

GPRS CS3 uplink usage (CS3_usage_UL)

The coding scheme usage on the uplink for GPRS CS3 is calculated using the following formula:

CS3−usage−UL =

(UL−RADIO−BLKS−1−8PSK−1−TS−CS−3 + UL−RADIO−BLKS−8PSK−2−TS−CS−3+

UL−RADIO−BLKS−GMSK−1−TS−CS−3 + UL−RADIO−BLKS−GMSK−2−TS−CS−3

)∗ 100

(UL−RADIO−BLKS−8PSK−1−TS + UL−RADIO−BLKS−8PSK−2−TS+

UL−RADIO−BLKS−GMSK−1−TS + UL−RADIO−BLKS−GMSK−2−TS

)

Where: Is:

UL_RADIO_BLKS_8PSK_1_TS_CS_3 the number of radio blocks received in theUL for CS3 from MSs capable of 8-PSK thatsupport a maximum of 1 TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS_CS_3 the number of radio blocks received in theUL for CS3 from MSs capable of 8-PSK thatsupport a max of 2 TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS_CS_3 the number of radio blocks received in theUL for CS3 from MSs capable of 8-PSK thatsupport a max of 1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS_CS_3 the number of RLC radio blocks received inthe UL for CS3 from MSs capable of 8-PSKsupporting a max of 2 TS in the UL.

UL_RADIO_BLKS_8PSK_1_TS the number of radio blocks received in the ULfrom MSs capable of 8-PSK supporting a maxof 1 TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS the number of radio blocks received in the ULfrom MSs capable of 8-PSK supporting a maxof 2 TS in the UL.

Continued

11-16 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning GPRS CS3 downlink usage (CS3_usage_DL)

Where: Is:

UL_RADIO_BLKS_GMSK_1_TS the number of radio blocks received in the ULfrom MSs capable of GMSK supporting a maxof 1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS the number of radio blocks received in the ULfrom MSs capable of GMSK supporting a maxof 2 TS in the UL.

GPRS CS3 downlink usage (CS3_usage_DL)

The coding scheme usage on the uplink for GPRS CS3 is calculated using the following formula:

CS3−usage−DL =

(DL−RADIO−BLKS−1−TS−CS−3 +DL−RADIO−BLKS−2−TS−CS−3+

DL−RADIO−BLKS−3−TS−CS−3 +DL−RADIO−BLKS−4−TS−CS−3

)∗ 100

(DL−RADIO−BLKS−1−TS +DL−RADIO−BLKS−2−TS+

DL−RADIO−BLKS−3−TS +DL−RADIO−BLKS−4−TS

)

Where: Is:

DL_RADIO_BLKS_1_TS_CS_3 number of radio blocks received in the DL for CS3 from MSssupporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS_CS_3 number of radio blocks received in the DL for CS3 from MSssupporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS_CS_3 number of radio blocks received in the DL for CS3 from MSssupporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS_CS_3 number of radio blocks received in the DL for CS3 from MSssupporting a maximum of 4 TS in the DL.

DL_RADIO_BLKS_1_TS number of radio blocks received in the DL from MSssupporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS number of radio blocks received in the DL from MSssupporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS number of radio blocks received in the DL from MSssupporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS number of radio blocks received in the DL from MSssupporting a maximum of 4 TS in the DL.

68P02900W21-T 11-17

Jul 2010

GPRS CS4 uplink usage (CS4_usage_UL) Chapter 11: Call model parameters

GPRS CS4 uplink usage (CS4_usage_UL)

The coding scheme usage on the uplink for GPRS CS4 is calculated using the following formula:

CS4−usage−UL =

(UL−RADIO−BLKS−8PSK−1−TS−CS−4 + UL−RADIO−BLKS−8PSK−2−TS−CS−4+

UL−RADIO−BLKS−GMSK−1−TS−CS−4 + UL−RADIO−BLKS−GMSK−2−TS−CS−4

)∗ 100

(UL−RADIO−BLKS−8PSK−1−TS + UL−RADIO−BLKS−8PSK−2−TS+

UL−RADIO−BLKS−GMSK−1−TS + UL−RADIO−BLKS−GMSK−2−TS

)

Where: Is:

UL_RADIO_BLKS_8PSK_1_TS_CS_4 number of radio blocks received in the UL forCS4 from MSs capable of 8-PSK that support amaximum of 1 TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS_CS_4 number of radio blocks received in the UL forCS4 from MSs capable of 8-PSK that support amaximum of 2 TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS_CS_4 number of radio blocks received in the UL forCS4 from MSs capable of 8-PSK that support amaximum of 1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS_CS_4 number of RLC radio blocks received in the ULfor CS4 from MSs capable of 8-PSK supporting amaximum of 2 TS in the UL.

UL_RADIO_BLKS_8PSK_1_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximum of 1TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximum of 2TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximum of1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximum of2 TS in the UL.

11-18 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning GPRS CS4 downlink usage (CS4_usage_DL)

GPRS CS4 downlink usage (CS4_usage_DL)

The coding scheme usage on the uplink for GPRS CS3 is calculated using the following formula:

CS4−usage−DL =

(DL−RADIO−BLKS−1−TS−CS−4 +DL−RADIO−BLKS−2−TS−CS−4+

DL−RADIO−BLKS−3−TS−CS−4 +DL−RADIO−BLKS−4−TS−CS−4

)∗ 100

(DL−RADIO−BLKS−1−TS +DL−RADIO−BLKS−2−TS+

DL−RADIO−BLKS−3−TS +DL−RADIO−BLKS−4−TS

)

Where: Is:

DL_RADIO_BLKS_1_TS_CS_4 number of radio blocks received in the DL for CS4 fromMSs supporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS_CS_4 number of radio blocks received in the DL for CS4 fromMSs supporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS_CS_4 number of radio blocks received in the DL for CS4 fromMSs supporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS_CS_4 number of radio blocks received in the DL for CS4 fromMSs supporting a maximum of 4 TS in the DL.

DL_RADIO_BLKS_1_TS number of radio blocks received in the DL from MSssupporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS number of radio blocks received in the DL from MSssupporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS number of radio blocks received in the DL from MSssupporting a maximum of 3 TS in the DL.

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 followingformula:

MCSI−usage−UL =

UL−RADIO−BLKS−8PSK−1−TS−MCS−1 + UL−RADIO−BLKS−

8PSK−2−TS−MCS−1 + UL−RADIO−BLKS−GMSK−1−TS−MCS−1

+ UL−RADIO−BLKS−GMSK−2−TS−MCS−1

∗ 100

UL−RADIO−BLKS−8PSK−1−TS + UL−RADIO−

BLKS−8PSK−2−TS + UL−RADIO−BLKS−

GMSK−1−TS + UL−RADIO−BLKS−GMSK−2−TS

68P02900W21-T 11-19

Jul 2010

EGPRS MCS1 downlink usage (MCS1_usage_DL) Chapter 11: Call model parameters

Where: Is:

UL_RADIO_BLKS_8PSK_1_TS_MCS_1 number of radio blocks received in the UL forMCS1 from MSs capable of 8-PSK that supporta maximum of 1 TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS_MCS_1 number of radio blocks received in the UL forMCS1 from MSs capable of 8-PSK that supporta maximum of 2 TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS_MCS_1 number of radio blocks received in the UL forMCS1 from MSs capable of 8-PSK that supporta maximum of 1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS_MCS_1 number of radio blocks received in the UL forMCS1 from MSs capable of 8-PSK supporting amaximum of 2 TS in the UL.

UL_RADIO_BLKS_8PSK_1_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximumof 1 TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximumof 2 TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximumof 1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximumof 2 TS in the UL.

EGPRS MCS1 downlink usage (MCS1_usage_DL)

The coding scheme usage on the downlink for EGPRS MCS1 is calculated using the followingformula:

MCS1−usage−DL =

(DL−RADIO−BLKS−1−TS−MCS−1 +DL−RADIO−BLKS−2−TS−MCS−1+

DL−RADIO−BLKS−3−TS−MCS−1 +DL−RADIO−BLKS−4−TS−MCS−1

)∗ 100

(DL−RADIO−BLKS−1−TS +DL−RADIO−BLKS−2−TS+

DL−RADIO−BLKS−3−TS +DL−RADIO−BLKS−4−TS

)

Where: Is:

DL_RADIO_BLKS_1_TS_MCS_1 number of radio blocks received in the DL for MCS1from MSs supporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS_MCS_1 number of radio blocks received in the DL for MCS1from MSs supporting a maximum of 2 TS in the DL.

Continued

11-20 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning EGPRS MCS2 uplink usage (MCS2_usage_UL)

Where: Is:

DL_RADIO_BLKS_3_TS_MCS_1 number of radio blocks received in the DL for MCS1from MSs supporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS_MCS_1 number of radio blocks received in the DL for MCS1from MSs supporting a maximum of 4 TS in the DL.

DL_RADIO_BLKS_1_TS number of radio blocks received in the DL from MSssupporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS number of radio blocks received in the DL from MSssupporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS number of radio blocks received in the DL from MSssupporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS number of radio blocks received in the DL from MSssupporting a maximum of 4 TS in the DL.

EGPRS MCS2 uplink usage (MCS2_usage_UL)

The coding scheme usage on the uplink for EGPRS MCS2 is calculated using the followingformula:

MCS2−usage−UL =

UL−RADIO−BLKS−8PSK−1−TS−MCS−2 + UL−RADIO−

BLKS−2−TS−MCS−2 + UL−RADIO−BLKS−GMSK−1−

TS−MCS−2 + UL−RADIO−BLKS−GMSK−2−TS−MCS−2

∗ 100

(UL−RADIO−BLKS−8PSK−1−TS + UL−RADIO−BLKS−8PSK−2−TS+

UL−RADIO−BLKS−GMSK−1−TS + UL−RADIO−BLKS−2−TS

)

Where: Is:

UL_RADIO_BLKS_8PSK_1_TS_MCS_2 number of radio blocks received in the UL forMCS1 from MSs capable of 8-PSK that support amaximum of 1 TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS_MCS_2 number of radio blocks received in the UL forMCS1 from MSs capable of 8-PSK that support amaximum of 2 TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS_MCS_2 number of radio blocks received in the UL forMCS1 from MSs capable of 8-PSK that support amaximum of 1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS_MCS_2 number of radio blocks received in the UL forMCS1 from MSs capable of 8-PSK supporting amaximum of 2 TS in the UL.

UL_RADIO_BLKS_8PSK_1_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximum of 1TS in the UL.

Continued

68P02900W21-T 11-21

Jul 2010

EGPRS MCS2 downlink usage (MCS2_usage_DL) Chapter 11: Call model parameters

Where: Is:

UL_RADIO_BLKS_8PSK_2_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximum of 2TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximum of 1TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximum of 2TS in the UL.

EGPRS MCS2 downlink usage (MCS2_usage_DL)

The coding scheme usage on the downlink for EGPRS MCS2 is calculated using the followingformula:

MCS2−usage−DL =

(DL−RADIO−BLKS−1−TS−MCS−2 +DL−RADIO−BLKS−2−TS−MCS−2+

DL−RADIO−BLKS−3−TS−MCS−2 +DL−RADIO−BLKS−4−TS−MCS−2

)∗ 100

(DL−RADIO−BLKS−1−TS +DL−RADIO−BLKS−2−TS+

DL−RADIO−BLKS−3−TS +DL−RADIO−BLKS−4−TS

)

Where: Is:

DL_RADIO_BLKS_1_TS_MCS_2 number of radio blocks received in the DL for MCS2from MSs supporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS_MCS_2 number of radio blocks received in the DL for MCS2from MSs supporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS_MCS_2 number of radio blocks received in the DL for MCS2from MSs supporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS_MCS_2 number of radio blocks received in the DL for MCS2from MSs supporting a maximum of 4 TS in the DL.

DL_RADIO_BLKS_1_TS number of radio blocks received in the DL from MSssupporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS number of radio blocks received in the DL from MSssupporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS number of radio blocks received in the DL from MSssupporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS number of radio blocks received in the DL from MSssupporting a maximum of 4 TS in the DL.

11-22 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning EGPRS MCS3 uplink usage (MCS3_usage_UL)

EGPRS MCS3 uplink usage (MCS3_usage_UL)

The coding scheme usage on the uplink for EGPRS MCS3 is calculated using the followingformula:

MCS3−usage−UL =

UL−RADIO−BLKS−8PSK−1−TS−MCS−3 + UL−RADIO−

BLKS−8PSK−2−TS−MCS−3 + UL−RADIO−BLKS−GMSK−1−

TS−MCS−3 + UL−RADIO−BLKS−GMSK−2−TS−MCS−4

∗ 100

(UL−RADIO−BLKS−8PSK−1−TS + UL−RADIO−BLKS−8PSK−2−TS+

UL−RADIO−BLKS−GMSK−1−TS + UL−RADIO−BLKS−GMSK−2−TS

)

Where: Is:

UL_RADIO_BLKS_8PSK_1_TS_MCS_3 number of radio blocks received in the UL forMCS3 from MSs capable of 8-PSK that support amaximum of 1 TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS_MCS_3 number of radio blocks received in the UL forMCS3 from MSs capable of 8-PSK that support amaximum of 2 TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS_MCS_3 number of radio blocks received in the UL forMCS1 from MSs capable of 8-PSK that support amaximum of 1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS_MCS_3 number of radio blocks received in the UL forMCS3 from MSs capable of 8-PSK supporting amaximum of 2 TS in the UL.

UL_RADIO_BLKS_8PSK_1_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximum of 1TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximum of 2TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximum of1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximum of2 TS in the UL.

68P02900W21-T 11-23

Jul 2010

EGPRS MCS3 downlink usage (MCS3_usage_DL) Chapter 11: Call model parameters

EGPRS MCS3 downlink usage (MCS3_usage_DL)

The coding scheme usage on the downlink for EGPRS MCS3 is calculated using the followingformula:

MCS3−usage−DL =

(DL−RADIO−BLKS−1−TS−MCS−3 +DL−RADIO−BLKS−2−TS−MCS−3+

DL−RADIO−BLKS−3−TS−MCS−3 +DL−RADIO−BLKS−4−TS−MCS−3

)∗ 100

(DL−RADIO−BLKS−1−TS +DL−RADIO−BLKS−2−TS+

DL−RADIO−BLKS−3−TS +DL−RADIO−BLKS−4−TS

)

Where: Is:

DL_RADIO_BLKS_1_TS_MCS_3 number of radio blocks received in the DL for MCS3from MSs supporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS_MCS_3 number of radio blocks received in the DL for MCS3from MSs supporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS_MCS_3 number of radio blocks received in the DL for MCS3from MSs supporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS_MCS_3 number of radio blocks received in the DL for MCS3from MSs supporting a maximum of 4 TS in the DL.

DL_RADIO_BLKS_1_TS number of radio blocks received in the DL from MSssupporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS number of radio blocks received in the DL from MSssupporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS number of radio blocks received in the DL from MSssupporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS number of radio blocks received in the DL from MSssupporting a maximum of 4 TS in the DL.

EGPRS MCS4 uplink usage (MCS4_usage_UL)

The coding scheme usage on the uplink for EGPRS MCS3 is calculated using the followingformula:

MCS4−usage−UL =

UL−RADIO−BLKS−8PSK−1−TS−MCS−4 + UL−RADIO−

BLKS−8PSK−2−TS−MCS−4 + UL−RADIO−BLKS−GMSK−1−

TS−MCS−4 + UL−RADIO−BLKS−GMSK−2−TS−MCS−4

∗ 100

(UL−RADIO−BLKS−8PSK−1−TS + UL−RADIO−BLKS−8PSK−2−TS+

UL−RADIO−BLKS−GMSK−1−TS + UL−RADIO−BLKS−GMSK−2−TS

)

11-24 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning EGPRS MCS4 downlink usage (MCS4_usage_DL)

Where: Is:

UL_RADIO_BLKS_8PSK_1_TS_MCS_4 number of radio blocks received in the UL forMCS4 from MSs capable of 8-PSK that support amaximum of 1 TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS_MCS_4 number of radio blocks received in the UL forMCS4 from MSs capable of 8-PSK that support amaximum of 2 TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS_MCS_4 number of radio blocks received in the UL forMCS4 from MSs capable of 8-PSK that support amaximum of 1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS_MCS_4 number of radio blocks received in the UL forMCS4 from MSs capable of 8-PSK supporting amaximum of 2 TS in the UL.

UL_RADIO_BLKS_8PSK_1_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximum of 1TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximum of 2TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximum of 1TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximum of 2TS in the UL.

EGPRS MCS4 downlink usage (MCS4_usage_DL)

The coding scheme usage on the downlink for EGPRS MCS3 is calculated using the followingformula:

MCS4−usage−DL =

(DL−RADIO−BLKS−1−TS−MCS−4 +DL−RADIO−BLKS−2−TS−MCS−4+

DL−RADIO−BLKS−3−TS−MCS−4 +DL−RADIO−BLKS−4−TS−MCS−4

)∗ 100

(DL−RADIO−BLKS−1−TS +DL−RADIO−BLKS−2−TS+

DL−RADIO−BLKS−3−TS +DL−RADIO−BLKS−4−TS

)

Where: Is:

DL_RADIO_BLKS_1_TS_MCS_4 number of radio blocks received in the DL for MCS4from MSs supporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS_MCS_3 number of radio blocks received in the DL for MCS4from MSs supporting a maximum of 2 TS in the DL.

Continued

68P02900W21-T 11-25

Jul 2010

EGPRS MCS5 uplink usage (MCS5_usage_UL) Chapter 11: Call model parameters

Where: Is:

DL_RADIO_BLKS_3_TS_MCS_3 number of radio blocks received in the DL for MCS4from MSs supporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS_MCS_3 number of radio blocks received in the DL for MCS4from MSs supporting a maximum of 4 TS in the DL.

DL_RADIO_BLKS_1_TS number of radio blocks received in the DL from MSssupporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS number of radio blocks received in the DL from MSssupporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS number of radio blocks received in the DL from MSssupporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS number of radio blocks received in the DL from MSssupporting a maximum of 4 TS in the DL.

EGPRS MCS5 uplink usage (MCS5_usage_UL)

The coding scheme usage on the uplink for EGPRS MCS5 is calculated using the followingformula:

MCS5−usage−UL =

UL−RADIO−BLKS−8PSK−1−TS−MCS−5 + UL−RADIO−

BLKS−8PSK−2−TS−MCS−5 + UL−RADIO−BLKS−GMSK−1−

TS−MCS−5 + UL−RADIO−BLKS−GMSK−2−TS−MCS−5

∗ 100

(UL−RADIO−BLKS−8PSK−1−TS + UL−RADIO−BLKS−8PSK−2−TS+

UL−RADIO−BLKS−GMSK−1−TS + UL−RADIO−BLKS−GMSK−2−TS

)

Where: Is:

UL_RADIO_BLKS_8PSK_1_TS_MCS_5 number of radio blocks received in the UL forMCS5 from MSs capable of 8-PSK that support amaximum of 1 TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS_MCS_5 number of radio blocks received in the UL forMCS5 from MSs capable of 8-PSK that support amaximum of 2 TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS_MCS_5 number of radio blocks received in the UL forMCS5 from MSs capable of 8-PSK that support amaximum of 1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS_MCS_5 number of radio blocks received in the UL forMCS5 from MSs capable of 8-PSK supporting amaximum of 2 TS in the UL.

UL_RADIO_BLKS_8PSK_1_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximum of 1TS in the UL.

Continued

11-26 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning EGPRS MCS5 downlink usage (MCS5_usage_DL)

Where: Is:

UL_RADIO_BLKS_8PSK_2_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximum of 2TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximum of1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximum of2 TS in the UL.

EGPRS MCS5 downlink usage (MCS5_usage_DL)

The coding scheme usage on the downlink for EGPRS MCS5 is calculated using the followingformula:

MCS5−usage−DL =

(DL−RADIO−BLKS−1−TS−MCS−5 +DL−RADIO−BLKS−2−TS−MCS−5+

DL−RADIO−BLKS−3−TS−MCS−5 +DL−RADIO−BLKS−4−TS−MCS−5

)∗ 100

(DL−RADIO−BLKS−1−TS +DL−RADIO−BLKS−2−TS+

DL−RADIO−BLKS−3−TS +DL−RADIO−BLKS−4−TS

)

Where: Is:

DL_RADIO_BLKS_1_TS_MCS_5 number of radio blocks received in the DL for MCS5from MSs supporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS_MCS_5 number of radio blocks received in the DL for MCS5from MSs supporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS_MCS_5 number of radio blocks received in the DL for MCS5from MSs supporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS_MCS_5 number of radio blocks received in the DL for MCS5from MSs supporting a maximum of 4 TS in the DL.

DL_RADIO_BLKS_1_TS number of radio blocks received in the DL from MSssupporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS number of radio blocks received in the DL from MSssupporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS number of radio blocks received in the DL from MSssupporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS number of radio blocks received in the DL from MSssupporting a maximum of 4 TS in the DL.

68P02900W21-T 11-27

Jul 2010

EGPRS MCS6 uplink usage (MCS6_usage_UL) Chapter 11: Call model parameters

EGPRS MCS6 uplink usage (MCS6_usage_UL)

The coding scheme usage on the uplink for EGPRS MCS6 is calculated using the followingformula:

MCS6−usage−UL =

UL−RADIO−BLKS−8PSK−1−TS−MCS−6 + UL−RADIO−

BLKS−8PSK−2−TS−MCS−6 + UL−RADIO−BLKS−GMSK−1−

TS−MCS−6 + UL−RADIO−BLKS−GMSK−2−TS−MCS−6

∗ 100

(UL−RADIO−BLKS−8PSK−1−TS + UL−RADIO−BLKS−8PSK−2−TS+

UL−RADIO−BLKS−GMSK−1−TS + UL−RADIO−BLKS−GMSK−2−TS

)

Where: Is:

UL_RADIO_BLKS_8PSK_1_TS_MCS_6 number of radio blocks received in the UL forMCS6 from MSs capable of 8-PSK that supporta maximum of 1 TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS_MCS_6 number of radio blocks received in the UL forMCS6 from MSs capable of 8-PSK that supporta maximum of 2 TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS_MCS_6 number of radio blocks received in the UL forMCS6 from MSs capable of 8-PSK that supporta maximum of 1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS_MCS_6 number of radio blocks received in the UL forMCS6 from MSs capable of 8-PSK supporting amaximum of 2 TS in the UL.

UL_RADIO_BLKS_8PSK_1_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximumof 1 TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximumof 2 TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximumof 1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximumof 2 TS in the UL.

11-28 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning EGPRS MCS6 downlink usage (MCS6_usage_DL)

EGPRS MCS6 downlink usage (MCS6_usage_DL)

The coding scheme usage on the downlink for EGPRS MCS6 is calculated using the followingformula:

MCS6−usage−DL =

(DL−RADIO−BLKS−1−TS−MCS−6 +DL−RADIO−BLKS−2−TS−MCS−6+

DL−RADIO−BLKS−3−TS−MCS−6 +DL−RADIO−BLKS−4−TS−MCS−6

)∗ 100

(DL−RADIO−BLKS−1−TS +DL−RADIO−BLKS−2−TS+

DL−RADIO−BLKS−3−TS +DL−RADIO−BLKS−4−TS

)

Where: Is:

DL_RADIO_BLKS_1_TS_MCS_6 number of radio blocks received in the DL for MCS6from MSs supporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS_MCS_6 number of radio blocks received in the DL for MCS6from MSs supporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS_MCS_6 number of radio blocks received in the DL for MCS6from MSs supporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS_MCS_6 number of radio blocks received in the DL for MCS6from MSs supporting a maximum of 4 TS in the DL.

DL_RADIO_BLKS_1_TS number of radio blocks received in the DL from MSssupporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS number of radio blocks received in the DL from MSssupporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS number of radio blocks received in the DL from MSssupporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS number of radio blocks received in the DL from MSssupporting a maximum of 4 TS in the DL.

EGPRS MCS7 uplink usage (MCS7_usage_UL)

The coding scheme usage on the uplink for EGPRS MCS7 is calculated using the followingformula:

MCS7−usage−UL =

UL−RADIO−BLKS−8PSK−1−TS−MCS−7 + UL−RADIO−

BLKS−8PSK−2−TS−MCS−7 + UL−RADIO−BLKS−GMSK−1−

TS−MCS−7 + UL−RADIO−BLKS−GMSK−2−TS−MCS−7

∗ 100

(UL−RADIO−BLKS−8PSK−1−TS + UL−RADIO−BLKS−8PSK−2−TS+

UL−RADIO−BLKS−GMSK−1−TS + UL−RADIO−BLKS−GMSK−2−TS

)

68P02900W21-T 11-29

Jul 2010

EGPRS MCS7 downlink usage (MCS7_usage_DL) Chapter 11: Call model parameters

Where: Is:

UL_RADIO_BLKS_8PSK_1_TS_MCS_7 number of radio blocks received in the UL forMCS7 from MSs capable of 8-PSK that support amaximum of 1 TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS_MCS_7 number of radio blocks received in the UL forMCS7 from MSs capable of 8-PSK that support amaximum of 2 TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS_MCS_7 number of radio blocks received in the UL forMCS7 from MSs capable of 8-PSK that support amaximum of 1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS_MCS_7 number of radio blocks received in the UL forMCS7 from MSs capable of 8-PSK supporting amaximum of 2 TS in the UL.

UL_RADIO_BLKS_8PSK_1_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximum of 1TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximum of 2TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximum of1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximum of2 TS in the UL.

EGPRS MCS7 downlink usage (MCS7_usage_DL)

The coding scheme usage on the downlink for EGPRS MCS7 is calculated using the followingformula:

MCS7−usage−DL =

(DL−RADIO−B LKS−1−TS−M CS−7 +DL−RADIO−B LKS−2−TS−M CS−7+DL−RADIO−B LKS−3−TS−M CS−7 +DL−RADIO−B LKS−4−TS−M CS−7

)∗ 100

(DL−RADIO−B LKS−1−TS +DL−RADIO−B LKS−2−TS+DL−RADIO−B LKS−3−TS +DL−RADIO−B LKS−4−TS

)

Where: Is:

DL_RADIO_BLKS_1_TS_MCS_7 number of radio blocks received in the DL for MCS7from MSs supporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS_MCS_7 number of radio blocks received in the DL for MCS7from MSs supporting a maximum of 2 TS in the DL.

Continued

11-30 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning EGPRS MCS8 uplink usage (MCS8_usage_UL)

Where: Is:

DL_RADIO_BLKS_3_TS_MCS_7 number of radio blocks received in the DL for MCS7from MSs supporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS_MCS_7 number of radio blocks received in the DL for MCS7from MSs supporting a maximum of 4 TS in the DL.

DL_RADIO_BLKS_1_TS number of radio blocks received in the DL from MSssupporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS number of radio blocks received in the DL from MSssupporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS number of radio blocks received in the DL from MSssupporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS number of radio blocks received in the DL from MSssupporting a maximum of 4 TS in the DL.

EGPRS MCS8 uplink usage (MCS8_usage_UL)

The coding scheme usage on the uplink for EGPRS MCS8 is calculated using the followingformula:

MCS8−usage−UL =

UL−RADIO−B LKS−8PSK−1−TS−M CS−8 + UL−RADIO−

B LKS−8PSK−2−TS−M CS−8 + UL−RADIO−B LKS−GMSK−1−TS−M CS−8 + UL−RADIO−B LKS−GMSK−2−TS−M CS−8

∗ 100

(UL−RADIO−B LKS−8PSK−1−TS + UL−RADIO−B LKS−8PSK−2−TS +

UL−RADIO−B LKS−GMSK−1−TS + UL−RADIO−B LKS−GMSK−2−TS

)

Where: Is:

UL_RADIO_BLKS_8PSK_1_TS_MCS_8 number of radio blocks received in the UL forMCS8 from MSs capable of 8-PSK that supporta maximum of 1 TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS_MCS_8 number of radio blocks received in the UL forMCS8 from MSs capable of 8-PSK that supporta maximum of 2 TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS_MCS_8 number of radio blocks received in the UL forMCS8 from MSs capable of 8-PSK that supporta maximum of 1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS_MCS_8 number of radio blocks received in the UL forMCS8 from MSs capable of 8-PSK supporting amaximum of 2 TS in the UL.

UL_RADIO_BLKS_8PSK_1_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximumof 1 TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximumof 2 TS in the UL.

Continued

68P02900W21-T 11-31

Jul 2010

EGPRS MCS8 downlink usage (MCS8_usage_DL) Chapter 11: Call model parameters

Where: Is:

UL_RADIO_BLKS_GMSK_1_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximumof 1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximumof 2 TS in the UL.

EGPRS MCS8 downlink usage (MCS8_usage_DL)

The coding scheme usage on the downlink for EGPRS MCS8 is calculated using the followingformula:

MCS8−usage−DL =

(DL−RADIO−BLKS−1−TS−M CS−8 +DL−RADIO−BLKS−2−TS−M CS−8+DL−RADIO−BLKS−3−TS−M CS−8 +DL−RADIO−BLKS−4−TS−M CS−8

)∗ 100

(DL−RADIO−BLKS−1−TS +DL−RADIO−BLKS−2−TS+DL−RADIO−BLKS−3−TS +DL−RADIO−BLKS−4−TS

)

Where: Is:

DL_RADIO_BLKS_1_TS_MCS_8 number of radio blocks received in the DL for MCS8from MSs supporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS_MCS_8 number of radio blocks received in the DL for MCS8from MSs supporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS_MCS_8 number of radio blocks received in the DL for MCS8from MSs supporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS_MCS_8 number of radio blocks received in the DL for MCS8from MSs supporting a maximum of 4 TS in the DL.

DL_RADIO_BLKS_1_TS number of radio blocks received in the DL from MSssupporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS number of radio blocks received in the DL from MSssupporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS number of radio blocks received in the DL from MSssupporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS number of radio blocks received in the DL from MSssupporting a maximum of 4 TS in the DL.

11-32 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning EGPRS MCS9 uplink usage (MCS9_usage_UL)

EGPRS MCS9 uplink usage (MCS9_usage_UL)

The coding scheme usage on the uplink for EGPRS MCS9 is calculated using the followingformula:

MCS9−usage−UL =

UL−RADIO−B LKS−8PSK−1−TS−M CS−9 + UL−RADIO−

B LKS−8PSK−2−TS−M CS−9 + UL−RADIO−B LKS−GMSK−1−TS−M CS−9 + UL−RADIO−B LKS−GMSK−2−TS−M CS−9

∗ 100

(UL−RADIO−B LKS−8PSK−1−TS + UL−RADIO−B LKS−8PSK−2−TS +

UL−RADIO−B LKS−GMSK−1−TS + UL−RADIO−B LKS−GMSK−2−TS

)

Where: Is:

UL_RADIO_BLKS_8PSK_1_TS_MCS_9 number of radio blocks received in the UL forMCS9 from MSs capable of 8-PSK that supporta maximum of 1 TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS_MCS_9 number of radio blocks received in the UL forMCS9 from MSs capable of 8-PSK that supporta maximum of 2 TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS_MCS_9 number of radio blocks received in the UL forMCS9 from MSs capable of 8-PSK that supporta maximum of 1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS_MCS_9 number of radio blocks received in the UL forMCS9 from MSs capable of 8-PSK supporting amaximum of 2 TS in the UL.

UL_RADIO_BLKS_8PSK_1_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximumof 1 TS in the UL.

UL_RADIO_BLKS_8PSK_2_TS number of radio blocks received in the UL fromMSs capable of 8-PSK supporting a maximumof 2 TS in the UL.

UL_RADIO_BLKS_GMSK_1_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximumof 1 TS in the UL.

UL_RADIO_BLKS_GMSK_2_TS number of radio blocks received in the UL fromMSs capable of GMSK supporting a maximumof 2 TS in the UL.

68P02900W21-T 11-33

Jul 2010

EGPRS MCS9 downlink usage (MCS9_usage_DL) Chapter 11: Call model parameters

EGPRS MCS9 downlink usage (MCS9_usage_DL)

The coding scheme usage on the downlink for EGPRS MCS9 is calculated using the followingformula:

MCS9−usage−DL =

(DL−RADIO−BLKS−1−TS−M CS−9 +DL−RADIO−BLKS−2−TS−M CS−9+DL−RADIO−BLKS−3−TS−M CS−9 +DL−RADIO−BLKS−4−TS−M CS−9

)∗ 100

(DL−RADIO−BLKS−1−TS +DL−RADIO−BLKS−2−TS+DL−RADIO−BLKS−3−TS +DL−RADIO−BLKS−4−TS

)

Where: Is:

DL_RADIO_BLKS_1_TS_MCS_9 number of radio blocks received in the DL for MCS9 fromMSs supporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS_MCS_9 number of radio blocks received in the DL for MCS9 fromMSs supporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS_MCS_9 number of radio blocks received in the DL for MCS9 fromMSs supporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS_MCS_9 number of radio blocks received in the DL for MCS9 fromMSs supporting a maximum of 4 TS in the DL.

DL_RADIO_BLKS_1_TS number of radio blocks received in the DL from MSssupporting a maximum of 1 TS in the DL.

DL_RADIO_BLKS_2_TS number of radio blocks received in the DL from MSssupporting a maximum of 2 TS in the DL.

DL_RADIO_BLKS_3_TS number of radio blocks received in the DL from MSssupporting a maximum of 3 TS in the DL.

DL_RADIO_BLKS_4_TS number of radio blocks received in the DL from MSssupporting a maximum of 4 TS in the DL.

Sample statistic calculations

Table 11-2 shows a sample of the statistics collected for one BTS in the BSC for a one hourinterval.

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 0 0 0

SMS_INIT_ON_SD- CCH 0 15 5

SMS_INIT_ON_TCH 0 2 0

out_inter_bss_req_to_msc 531 1214 141

Continued

11-34 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Sample statistic calculations

Table 11-2 Sample statistics (Continued)

Statistic Parameter Cell 1 Cell 2 Cell 3

out_intra_bss_ho_atm 512 747 1844

intra_cell_ho_atmpt 0 0 0

OK_ACC_PROC [location_update] 746 1056 268

OK_ACC_PROC [imsi_detach] 28 49 76

PAGE_REQ_FROM_MSC 43696 43696 43696

ASSIGNMENT_REDIRECTION 0 0 0

Using the formulae detailed in the previous sections, call model parameters can be calculatedas follows:

Call duration (T)

Call duration is given by:

T =

N∑i=1

BUSY−TCH−MEAN ∗ stat−interval−in−sec

N∑i=1

(TOTAL−CALLS + ASSIGNMENT−REDIRECTION)

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 valueused for dimensioning purposes should be the average of the call durations over all the BSCsin the network.

Number of SMSs per call (S)

The number of SMSs per call is given by:

S =

N∑i=1

(SMS−NO−BCAST−MSG + SMS−INIT−ON−SDCCH + SMS−INIT−ON−TCH)

N∑i=1

(TOTAL−CALLS + ASSIGNMENT−REDIRECTION)

S = [(0 + 0 + 0) + (0 + 15 + 2) + (0 + 5 + 0)] / (571 + 927 + 1407) = 0.075

68P02900W21-T 11-35

Jul 2010

Sample statistic calculations Chapter 11: Call model parameters

Ratio of handovers per call (H)

The ratio of handovers per call is given by:

H =

N∑i+1

(out−inter−bss−req−to−msc + out−intra−bss−ho−attmpt + intra−cell−ho−attmpt)

N∑i=1

(TOTAL−CALLS + ASSIGNMENT−REDIRECTION)

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∑i−1

(out−intra−bss−ho−atmpt + out−intra−cell−ho−atmpt)

N∑i=1

(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∑i=1

(OK−ACC−PROC [location−update])

N∑i=1

(TOTAL−CALLS + ASSIGNMENT−REDIRECTION)

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∑i=1

(OK−ACC−PROC (imsi−detach))

N∑i=1

(TOTAL−CALLS + ASSIGNMENT−REDIRECTION)

I = (28 + 49 + 76) / (571 + 927 + 1407 + 0 + 0 + 0) = 0.052

11-36 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning Sample statistic calculations

Location update factor (L)

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 theentire network. This example illustrates the computation of call model parameters from thenetwork statistics obtained from the OMC-R. As previously mentioned, it is recommendedthat statistics collected at busy hours over a long period (a couple of months) are used for allcalculation purposes.

68P02900W21-T 11-37

Jul 2010

Sample statistic calculations Chapter 11: Call model parameters

11-38 68P02900W21-T

Jul 2010

Chapter

12

Hardware and compatibility■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

■

■

68P02900W21-T 12-1

Jul 2010

Hardware configuration Chapter 12: Hardware and compatibility

Hardware configuration■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

Interconnection diagrams of the components and BTS site configurations are available in therelevant 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

M-Cell

• 68P02901W75 Service Manual: M-Cell2

• 68P02901W85 Service Manual: M-Cell6

12-2 68P02900W21-T

Jul 2010

System Information: BSS Equipment Planning 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

PCU

• 68P02903W10 Service Manual: Packet Control Unit (PCU)

• 68P02903W12 Installation and configuration: PCU (legacy_cabinets)

• 68P02903W24 Installation and configuration: PCU (common data cabinet)

68P02900W21-T 12-3

Jul 2010

PCU Chapter 12: Hardware and compatibility

12-4 68P02900W21-T

Jul 2010

Index

Index■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

■

■

A

Acronyms . . . . . . . . . . . . . . . . . 1-40Adaptive multi-rate (AMR) . . . . . . . . . 3-6Applications. . . . . . . . . . . . . . . . 3-8Capacity and coverage . . . . . . . . . . 3-6Interoperability with EGPRS . . . . . . . 3-9

Adaptive multi-rate (AMR) (contd.)Interoperability with GSM half rate . . . . 3-9Introduction. . . . . . . . . . . . . . . . 3-6Migration to AMR half rate . . . . . . . . 3-9Quality of service . . . . . . . . . . . . . 3-7

B

BSS equipment overview . . . . . . . . . . 1-4System architecture. . . . . . . . . . . . 1-4System components . . . . . . . . . . . . 1-5BBU-E. . . . . . . . . . . . . . . . . 1-10CTU. . . . . . . . . . . . . . . . . . . 1-7CTU2 . . . . . . . . . . . . . . . . . . 1-7CTU2D . . . . . . . . . . . . . . . . . 1-6DTRX . . . . . . . . . . . . . . . . . . 1-8Horizon II Site Controller . . . . . . . . 1-8(R)CTU8m . . . . . . . . . . . . . . . 1-6Site Controller-2 . . . . . . . . . . . . 1-9TCU-m . . . . . . . . . . . . . . . . . 1-8TCU/TCU-B . . . . . . . . . . . . . . . 1-8

BSS features . . . . . . . . . . . . . . . 1-1196 MSIs . . . . . . . . . . . . . . . . . 1-26Adaptive Multi-Rate (AMR) . . . . . . . 1-15Addition of new BSC/PCU software (PXP) andhardware (PSI2) to increase GPRS capacity(ePCU) . . . . . . . . . . . . . . . . . 1-24Advanced Speech Call Item (ASCI) . . . 1-19BSC Reset Management (BRM) . . . . . 1-19Code Storage Facility Processor(CSFP) . . . . . . . . . . . . . . . . . 1-13CTU2-D . . . . . . . . . . . . . . . . . 1-24Diversity . . . . . . . . . . . . . . . . 1-12Enhanced BSC capacity using DSW2 . . 1-24Enhanced-GPRS (EGPRS) . . . . . . . . 1-14Frequency hopping . . . . . . . . . . . 1-12GSM half rate . . . . . . . . . . . . . . 1-16High bandwidth interconnect between BSC andPCU (PSI2) . . . . . . . . . . . . . . . 1-24High Speed MTL . . . . . . . . . . . . 1-24Horizon II Site Controller 2 . . . . . . . 1-28Improved Timeslot Sharing (ITS) . . . . 1-23Increase RSL-LCF capacity onGPROC3/GPROC3-2. . . . . . . . . . . 1-32Increased Network Capacity (HugeBSC) . . . . . . . . . . . . . . . . . . 1-23

BSS features (contd.)LoCation Services (LCS) . . . . . . . . 1-17PCU for GPRS upgrade . . . . . . . . . 1-14Planning impacts . . . . . . . . . . . . 1-11QoS2 . . . . . . . . . . . . . . . . . . 1-22Quality of Service (QoS). . . . . . . . . 1-20SGSN(Gb) interface using Ethernet (Gb overIP) . . . . . . . . . . . . . . . . . . . 1-32Short Message Service, Cell Broadcast (SMSCB) . . . . . . . . . . . . . . . . . . . 1-13Using PA bias feature in Horizon II sites withmixed radios . . . . . . . . . . . . . . 1-33VersaTRAU backhaul for EGPRS . . . . 1-20

BSS interfaces . . . . . . . . . . . . . . . 2-2Introduction. . . . . . . . . . . . . . . . 2-2

BSS planning for GPRS/EGPRS . . . . . . . 8-2Feature compatibility . . . . . . . . . . . 8-3Gb over IP . . . . . . . . . . . . . . 8-12

Introduction. . . . . . . . . . . . . . . . 8-2PCU to SGSN interface planning . . . . . 8-2

BSS planning overview . . . . . . . . . . 1-37Background information . . . . . . . . 1-37Introduction. . . . . . . . . . . . . . . 1-37Planning methodology . . . . . . . . . 1-39

BSS-PCU hardware planning example forEGPRS . . . . . . . . . . . . . . . . . . 8-79BSS - PCU planning example for EG-PRS . . . . . . . . . . . . . . . . . . . 8-79BSS - PCU planning example for EGPRS withQoS and QoS2 enabled . . . . . . . . . 8-93BSS - PCU planning example for EGPRS withQoS enabled, QoS2 not enabled. . . . . 8-86Introduction. . . . . . . . . . . . . . . 8-79

BSS-PCU hardware planning example forGPRS . . . . . . . . . . . . . . . . . . . 8-72BSS - PCU planning example for GPRS. . 8-72Introduction. . . . . . . . . . . . . . . 8-72

68P02900W21-T IX-1

Jul 2010

Index

C

Calculations using alternative call mod-els. . . . . . . . . . . . . . . . . . . . . 9-17Introduction. . . . . . . . . . . . . . . 9-17Planning example 3 . . . . . . . . . . . 9-17Planning example 4 (using AMR) . . . . 9-30Planning example 5 . . . . . . . . . . . 9-46Call model parameters for capacitycalculations . . . . . . . . . . . . . . . . 3-48Introduction. . . . . . . . . . . . . . . 3-48Typical call parameters . . . . . . . . . 3-48Control channel calculations . . . . . . . 3-52Combined BCCH . . . . . . . . . . . . 3-54Control channel configurations . . . . . 3-69Introduction. . . . . . . . . . . . . . . 3-52Number of CCCHs and PCCCHs per BTScell . . . . . . . . . . . . . . . . . . . 3-55Number of SDCCHs per BTS cell . . . . 3-66Planning considerations. . . . . . . . . 3-53User data capacity on the PCCCHtimeslot . . . . . . . . . . . . . . . . . 3-65

CTU8m D4+ Link . . . . . . . . . . . . . 5-44Link selection . . . . . . . . . . . . . . 5-51Overview . . . . . . . . . . . . . . . . 5-44Recommended D4+ configurations(CTU8m) . . . . . . . . . . . . . . . . 5-551-3 CTU8m radios. . . . . . . . . . . 5-554-6 CTU8m radios (dual BBU-E) . . . 5-574-6 CTU8m radios (single BBU-E). . . 5-57

Recommended D4+ configurations(RCTU8m). . . . . . . . . . . . . . . . 5-581-3 RCTU8m radios (non-redun-dant) . . . . . . . . . . . . . . . . . 5-584-6 RCTU8m radios (dual BBU-E) . . . 5-634-6 RCTU8m radios (single BBU-E) . . 5-62

Supported topologies . . . . . . . . . . 5-45Fiber redundancy . . . . . . . . . . . 5-49General principles . . . . . . . . . . 5-45Standard topologies. . . . . . . . . . 5-46

D

Deriving call model parameters from networkstatistics . . . . . . . . . . . . . . . . . 11-2Blocking for TCHs (PB – TCHs) . . . . . 11-12Call duration (T) . . . . . . . . . . . . 11-5EGPRS MCS1 downlink usage (MCS1_us-age_DL) . . . . . . . . . . . . . . . . . 11-20EGPRS MCS1 uplink usage (MCS1_us-age_UL) . . . . . . . . . . . . . . . . . 11-19EGPRS MCS2 downlink usage (MCS2_us-age_DL) . . . . . . . . . . . . . . . . . 11-22EGPRS MCS2 uplink usage (MCS2_us-age_UL) . . . . . . . . . . . . . . . . . 11-21EGPRS MCS3 downlink usage (MCS3_us-age_DL) . . . . . . . . . . . . . . . . . 11-24EGPRS MCS3 uplink usage (MCS3_us-age_UL) . . . . . . . . . . . . . . . . . 11-23EGPRS MCS4 downlink usage (MCS4_us-age_DL) . . . . . . . . . . . . . . . . . 11-25EGPRS MCS4 uplink usage (MCS4_us-age_UL) . . . . . . . . . . . . . . . . . 11-24EGPRS MCS5 downlink usage (MCS5_us-age_DL) . . . . . . . . . . . . . . . . . 11-27EGPRS MCS5 uplink usage (MCS5_us-age_UL) . . . . . . . . . . . . . . . . . 11-26EGPRS MCS6 downlink usage (MCS6_us-age_DL) . . . . . . . . . . . . . . . . . 11-29EGPRS MCS6 uplink usage (MCS6_us-age_UL) . . . . . . . . . . . . . . . . . 11-28EGPRS MCS7 downlink usage (MCS7_us-age_DL) . . . . . . . . . . . . . . . . . 11-30

Deriving call model parameters from networkstatistics (contd.)EGPRS MCS7 uplink usage (MCS7_us-age_UL) . . . . . . . . . . . . . . . . . 11-29EGPRS MCS8 downlink usage (MCS8_us-age_DL) . . . . . . . . . . . . . . . . . 11-32EGPRS MCS8 uplink usage (MCS8_us-age_UL) . . . . . . . . . . . . . . . . . 11-31EGPRS MCS9 downlink usage (MCS9_us-age_DL) . . . . . . . . . . . . . . . . . 11-34EGPRS MCS9 uplink usage (MCS9_us-age_UL) . . . . . . . . . . . . . . . . . 11-33GPRS CS1 downlink usage (CS1_us-age_DL) . . . . . . . . . . . . . . . . . 11-14GPRS CS1 uplink usage (CS1_us-age_UL) . . . . . . . . . . . . . . . . . 11-13GPRS CS2 downlink usage (CS2_us-age_DL) . . . . . . . . . . . . . . . . . 11-15GPRS CS2 uplink usage (CS2_us-age_UL) . . . . . . . . . . . . . . . . . 11-14GPRS CS3 downlink usage (CS3_us-age_DL) . . . . . . . . . . . . . . . . . 11-17GPRS CS3 uplink usage (CS3_us-age_UL) . . . . . . . . . . . . . . . . . 11-16GPRS CS4 downlink usage (CS4_us-age_DL) . . . . . . . . . . . . . . . . . 11-19GPRS CS4 uplink usage (CS4_us-age_UL) . . . . . . . . . . . . . . . . . 11-18Location update factor (L) . . . . . . . 11-9

IX-2 68P02900W21-T

Jul 2010

Index

Deriving call model parameters from networkstatistics (contd.)Percent link utilization BSC to BTS [U(BSC –BTS)] . . . . . . . . . . . . . . . . . . 11-11Percent link utilization MSC to BSS [U(MSC –BSS)] . . . . . . . . . . . . . . . . . . 11-11Ratio of handovers per call (H) . . . . . 11-7Ratio of IMSI detaches per call (I) . . . 11-8Ratio of intra BSS handovers to all handovers(i) . . . . . . . . . . . . . . . . . . . . 11-7Ratio of location updates per call (I) . . 11-8Ratio of SMSs per call (S) . . . . . . . . 11-6Sample statistic calculations . . . . . . 11-34Standard call model parameters . . . . 11-2Determine the hardware requirements for BTSB . . . . . . . . . . . . . . . . . . . . . . 9-5Cabinet . . . . . . . . . . . . . . . . . . 9-5Summary . . . . . . . . . . . . . . . . . 9-6Determine the hardware requirements for BTSK . . . . . . . . . . . . . . . . . . . . . . 9-8Cabinet . . . . . . . . . . . . . . . . . . 9-8Introduction. . . . . . . . . . . . . . . . 9-8Receiver requirements . . . . . . . . . . 9-8Summary . . . . . . . . . . . . . . . . . 9-9Transmitter combining requirements . . . 9-9

Determine the hardware requirements for theBSC . . . . . . . . . . . . . . . . . . . . 9-11Introduction. . . . . . . . . . . . . . . 9-11Summary . . . . . . . . . . . . . . . . 9-13

Determine the hardware requirements for theRXCDR . . . . . . . . . . . . . . . . . . 9-14CLKX requirement . . . . . . . . . . . 9-15GCLK requirement . . . . . . . . . . . 9-15GPROC requirement . . . . . . . . . . 9-15KSW/DSW2 requirement . . . . . . . . 9-15KSWX/DSWX requirement . . . . . . . 9-15LANX requirement . . . . . . . . . . . 9-16Link interface . . . . . . . . . . . . . . 9-15MSI requirements. . . . . . . . . . . . 9-14PIX requirement . . . . . . . . . . . . 9-15Power supply . . . . . . . . . . . . . . 9-16Summary . . . . . . . . . . . . . . . . 9-16Transcoder requirement . . . . . . . . 9-14

DPROC board . . . . . . . . . . . . . . . 8-25Introduction. . . . . . . . . . . . . . . 8-25PICP or PRP planning considerations . . 8-25PXP planning considerations . . . . . . 8-28

E

E1 link/ETH link provisioning for GPRS andEGPRS . . . . . . . . . . . . . . . . . . 8-46E1 interface provisioning . . . . . . . . 8-46E1 Planning considerations . . . . . . . 8-46Ethernet interface provisioning . . . . . 8-47

Exercises . . . . . . . . . . . . . . . . . . 9-4Introduction. . . . . . . . . . . . . . . . 9-4

F

Frequency planning . . . . . . . . . . . . 3-38Introduction. . . . . . . . . . . . . . . 3-38Rules for BaseBand Hopping (BBH). . . 3-42

Frequency planning (contd.)Rules for Synthesizer Frequency Hopping(SFH) . . . . . . . . . . . . . . . . . . 3-38

G

GPRS/EGPRS air interface planningprocess . . . . . . . . . . . . . . . . . . 3-96Configurable initial coding scheme . . . 3-117Estimating the air interface trafficthroughput . . . . . . . . . . . . . . . 3-107Estimating timeslot provisioning require-ments . . . . . . . . . . . . . . . . . . 3-109GPRS/EGPRS data rates . . . . . . . . 3-118Influential factors in GPRS/EGPRS cell planningand deployment . . . . . . . . . . . . . 3-96

GPRS/EGPRS air interface planning process(contd.)Select a cell plan . . . . . . . . . . . . 3-108

GPRS/EGPRS network traffic estimation and keyconcepts . . . . . . . . . . . . . . . . . 3-74BSS timeslot allocation methods . . . . 3-91Carrier timeslot allocation examples . . 3-83Dynamic timeslot allocation. . . . . . . 3-76Introduction. . . . . . . . . . . . . . . 3-74

68P02900W21-T IX-3

Jul 2010

Index

GPRS/EGPRS network traffic estimation and keyconcepts (contd.)Recommendation for switchable timeslotusage . . . . . . . . . . . . . . . . . . 3-93Timeslot allocation process on carriers withGPRS traffic. . . . . . . . . . . . . . . 3-95GPRS/EGPRS traffic planning . . . . . . . 3-73Determination of expected load . . . . . 3-73Network planning flow . . . . . . . . . 3-73

GSM half rate . . . . . . . . . . . . . . . 3-10Applications. . . . . . . . . . . . . . . 3-11Capacity and coverage . . . . . . . . . 3-10Interoperability with AMR half rate . . . 3-12Interoperability with EGPRS . . . . . . 3-12Introduction. . . . . . . . . . . . . . . 3-10Migration to half rate . . . . . . . . . . 3-12Quality of service . . . . . . . . . . . . 3-11

H

Half rate utilization . . . . . . . . . . . . 4-17Description . . . . . . . . . . . . . . . 4-17Operational aspects . . . . . . . . . . . 4-23Parameter descriptions . . . . . . . . . 4-17

Hardware . . . . . . . . . . . . . . . . . 4-26Backhaul . . . . . . . . . . . . . . . . 4-28Equipment descriptions . . . . . . . . . 4-26

I

Inter-radio access technology (2G-3G) cellreselection and handovers . . . . . . . . 3-442G-3G handover description . . . . . . 3-44Impact of 2G-3G handovers on GSM systemarchitecture. . . . . . . . . . . . . . . 3-45Introduction. . . . . . . . . . . . . . . 3-44System consideration . . . . . . . . . . 3-46Interconnecting the BSC and BTSs . . . . . 2-4Interconnection rules . . . . . . . . . . . 2-4

Interconnecting the BSC and BTSs (contd.)Introduction. . . . . . . . . . . . . . . . 2-4

Introduction to AMR and GSM planning . . 4-2AMR and GSM half rate interaction . . . . 4-3AMR basic operation . . . . . . . . . . . 4-2GSM half rate basic operation . . . . . . 4-2Influencing factors . . . . . . . . . . . . 4-3New hardware . . . . . . . . . . . . . . 4-3Planning . . . . . . . . . . . . . . . . . 4-4

L

Location area planning calculations. . . . 10-3Example procedure . . . . . . . . . . . 10-3

Location area planning considerations . . 10-2

M

Managed HDSL on micro BTSs . . . . . . 2-24General HDSL guidelines . . . . . . . . 2-26Integrated HDSL interface . . . . . . . 2-24Introduction. . . . . . . . . . . . . . . 2-24Microcell system planning . . . . . . . 2-27Manual overview . . . . . . . . . . . . . . 1-2Contents . . . . . . . . . . . . . . . . . 1-2Introduction. . . . . . . . . . . . . . . . 1-2Microcellular solution . . . . . . . . . . . 3-34Combined cell architecture . . . . . . . 3-35

Microcellular solution (contd.)Combined cell architecture structure . . 3-35Expansion solution . . . . . . . . . . . 3-36Layered architecture . . . . . . . . . . 3-34

Miscellaneous information . . . . . . . . 4-16Circuit pooling . . . . . . . . . . . . . 4-16Emergency call handling . . . . . . . . 4-16

MPROC board. . . . . . . . . . . . . . . 8-24Introduction. . . . . . . . . . . . . . . 8-24PSP planning considerations . . . . . . 8-24

IX-4 68P02900W21-T

Jul 2010

Index

N

Network topology . . . . . . . . . . . . . . 2-616 kbit/s XBL . . . . . . . . . . . . . . 2-20Aggregate Abis . . . . . . . . . . . . . 2-10Daisy chain connection . . . . . . . . . . 2-8Daisy chain planning . . . . . . . . . . . 2-8

Network topology (contd.)Dynamic allocation of RXCDR to BSC circuits(DARBC) . . . . . . . . . . . . . . . . 2-21Introduction. . . . . . . . . . . . . . . . 2-6RTF path fault containment . . . . . . . 2-15Star connection . . . . . . . . . . . . . . 2-7

O

Overcoming adverse propagation effects64 kbit/s TRAU for EGPRS . . . . . . . 3-28EGPRS channel coding schemes . . . . 3-18

Overcoming adverse propagation effects (contd.)Link adaptation (LA) in GPRS/EGPRS . . 3-29

P

(Packet) Rear Transition Module . . . . . 8-31Introduction. . . . . . . . . . . . . . . 8-31Planning considerations. . . . . . . . . 8-31PCU equipment redundancy and provisioninggoals . . . . . . . . . . . . . . . . . . . 8-32PCU equipment redundancy planning. . 8-32PRP/PICP configure . . . . . . . . . . . 8-33PXP configuration . . . . . . . . . . . . 8-38Support for equipment redundancy . . . 8-32Upgrading the PCU . . . . . . . . . . . 8-43PCU hardware layout . . . . . . . . . . . 8-21PCU shelf (cPCI) . . . . . . . . . . . . . 8-22Introduction. . . . . . . . . . . . . . . 8-22Planning considerations. . . . . . . . . 8-22PCU-SGSN: traffic and signal planning . . 8-63Determining net Gb load . . . . . . . . 8-65Frame relay parameter values . . . . . 8-67Gb entities . . . . . . . . . . . . . . . 8-63Gb link timeslots (for Frame relay Gb). . 8-66

PCU-SGSN: traffic and signal planning (contd.)Gb signaling . . . . . . . . . . . . . . 8-65General planning guidelines . . . . . . 8-64Introduction. . . . . . . . . . . . . . . 8-63Specific planning guidelines . . . . . . 8-65

Planning example of BSS support for LCSprovisioning. . . . . . . . . . . . . . . . 9-59LCS planning example calculations . . . 9-59Planning example for GSR10 with no (E)GPRSand high signaling . . . . . . . . . . . 9-62Typical parameter values . . . . . . . . 9-59

Planning tools . . . . . . . . . . . . . . . . 3-3Introduction. . . . . . . . . . . . . . . . 3-3

PMC module . . . . . . . . . . . . . . . 8-30Introduction. . . . . . . . . . . . . . . 8-30Planning considerations. . . . . . . . . 8-30

Pre-requisites . . . . . . . . . . . . . . . . 9-2Network topology . . . . . . . . . . . . . 9-3Requirements . . . . . . . . . . . . . . . 9-2

Q

QoS capacity and QoS2 impact . . . . . . 8-49Calculating average downlink EGBR . . 8-55Calculating PRP board throughput . . . 8-54CTU2D impact . . . . . . . . . . . . . 8-62MTBR allocation . . . . . . . . . . . . 8-51PRP-PDTCH QoS planning . . . . . . . 8-54Quality and capacity . . . . . . . . . . . . 4-5AMR Full Rate and AMR Half Rate speechquality . . . . . . . . . . . . . . . . . . 4-5

Quality and capacity (contd.)AMR voice quality improvement andcoverage . . . . . . . . . . . . . . . . . 4-9Benefits of AMR. . . . . . . . . . . . . . 4-5Benefits of GSM half rate . . . . . . . . 4-10Capacity increase due to half rateusage . . . . . . . . . . . . . . . . . . 4-11GSM Half Rate speech quality . . . . . 4-11Timeslot usage . . . . . . . . . . . . . 4-14

68P02900W21-T IX-5

Jul 2010

Index

S

Subscriber environment. . . . . . . . . . 3-30Distribution . . . . . . . . . . . . . . . 3-31Environment . . . . . . . . . . . . . . 3-30Future planning. . . . . . . . . . . . . 3-33

Subscriber environment (contd.)Hand portable subscribers . . . . . . . 3-32Subscriber hardware . . . . . . . . . . 3-30

Summary . . . . . . . . . . . . . . . . . 4-32

T

Traffic capacity . . . . . . . . . . . . . . . 3-4Channel blocking . . . . . . . . . . . . . 3-4Dimensioning . . . . . . . . . . . . . . . 3-4

Traffic capacity (contd.)Grade of service. . . . . . . . . . . . . . 3-5Traffic flow . . . . . . . . . . . . . . . . 3-5

IX-6 68P02900W21-T

Jul 2010