BSS Planning and Ion

BSS Network Design Guide
GSM NR 9.1 and NR 9.2
Design and Dimensioning Document
401-380-312
Issue 1.0
November 2000
Lucent Technologies - Proprietary
This document contains proprietary information
of Lucent Technologies and is not to be disclosed or used
except in accordance with applicable agreements
Copyright  2000 Lucent Technologies

Unpublished and Not for Publication
All Rights Reserved
Copyright ©2000 by Lucent Technologies. All Rights Reserved.
This material is protected by the copyright laws of the United States and other countries. It may not be
reproduced, distributed, or altered in any fashion by any entity (either internal or external to Lucent
Technologies), except in accordance with applicable agreements, contracts, or licensing, without the
express written consent of the Customer Training and Information Products organisation and the
business management owner of the material.
Notice
Every effort was made to ensure that the information in this information product was complete and
accurate at the time of printing. However, information is subject to change.
Contents
1 INTRODUCTION 1-1
Scope 1-1
BSS Systems Overview 1-2
Base Transceiver Station (BTS) 1-2
Base Station Controller (BSC) 1-2
BCF-2000 (BCF) 1-2
STF-2000 (STF) 1-2
Operations & Maintenance Centre (OMC) 1-2
GPRS System Overview 1-3
2 UM INTERFACE 2-1
Scope 2-1
Introduction 2-1
Capacity Calculation 2-1
Formula 2-2
Total SDCCH Capacity Needed 2-2
Example SDCCH Dimensioning 2-2
Location Updating Type Normal 2-2
Periodic Location Update 2-3
IMSI detach/attach 2-4
Call set-up 2-4
SMS 2-4
Fax Set-up 2-4
Issue 1.0 – November 2000 Lucent Technologies – Proprietary iii

See Notice on first page
Contents BSS Network Design Guide
False accesses 2-5
Total SDCCH Capacity Needed 2-5
Cell Configuration Example 2-5
Configuration Rules 2-6
Configuration Constraints 2-6
Constraints in Case of SMSCB 2-6
Typical SDCCH Configuration in a cell 2-7
3 BTS CONFIGURATION 3-1
Introduction 3-1
Dimensioning per BTS site 3-1
Required input information 3-1
Steps 3-2
BTS2000/2C 3-3
Flexent Macrocell 3-3
Impact of GPRS on the BTS 3-4
Standard Configuration 3-5
Further Information 3-5
4 ABIS LINK DIMENSIONING 4-1
Calculating required number of Abis links 4-1
Dimensioning the Abis link 4-2
Rules 4-2
GPRS support on the Abis interface 4-4
Further Information 4-4
5 BCF PLANNING 5-1
Introduction 5-1
BCF Planning Steps for Circuit Switch Network 5-1
1) BCF Capacity based on a Subscriber Traffic Model (Only for Circuit Switch Traffic) 5-2
BCF Maximum Capacity Calculation 5-3
Example 5-4
iv Lucent Technologies – Proprietary Issue 1.0 –November 2000

Calculate Number of Servers 5-6
B180 Servers 5-6
Network Dimensioning Tool (NDT) 5-7
2) BCF Dimensioning 5-7
Rules 5-7
3) BTS - BCF distribution 5-8
4) Calculations of Cards 5-9
Number of HP Servers per BCF 5-9
Server Redundancy Concept 5-9
SDFU Calculations/Distribution 5-9
Purpose 5-9
SDFUs 5-10
Internal E1/T1 links 5-10
Distribution/Configuration of Abis links 5-10
5) GPRS 5-11
GPRS Impact on BCF 5-11
BCF Capacity Limits 5-11
5.1) BCF Planning Steps for Combined Circuit and Packet Switch Network: 5-12
Subscriber Capacity Calculation for Combined Circuit Switch and Packet Switched
Traffic 5-13
Simplified Capacity Estimation Model 5-13
Uplink and downlink capacity 5-14
BCF capacity constraints 5-14
Air Link Throughput 5-14
Signalling Overhead 5-15
Coding Scheme Usage 5-16
Calculation 5-16
Calculation Example 5-21
Issue 1.0 – November 2000 Lucent Technologies – Proprietary v

CPU Load per GPRS User 5-23
Input 5-23
Assumptions 5-23
CPU load generated for CCF on CEWS 5-23
CPU load generated for processing of data packets on GWS 5-25
BCF Maximum Capacity Calculation 5-26
Calculate the Number of BCFs required 5-29
BTS – BCF Distribution 5-30
Calculation for all the cards 5-30
6 M-LINK DIMENSIONING 6-1
Calculating required number of M-links 6-1
Scope 6-1
Rules 6-1
Calculate total network traffic 6-2
Calculate the number of M links per BCF for CS traffic 6-2
Impact of GPRS on M-link dimensioning 6-3
Calculate timeslots required for PS data 6-3
Steps 6-3
Signalling Link Dimensioning 6-4
Introduction 6-4
Example 6-5
Calculations 6-6
References 6-6
7 STF-2000 CABINET DIMENSIONING 7-1
Scope 7-1
System Dimensioning for Full Rate configurations 7-1
vi Lucent Technologies – Proprietary Issue 1.0 –November 2000

Required input information: 7-1
Cabinets 7-1
TSGs 7-1
TCUs 7-2
M Groups 7-2
Each M group requires 7-2
STUs 7-2
Steps 7-2
System Dimensioning for Dual Mode configurations 7-4
Rules 7-4
Steps 7-5
Impact of GPRS on the STF 7-6
STF Configurations for E1 systems 7-7
STF Configurations for T1 systems 7-8
8 A-LINK DIMENSIONING 8-1
Scope 8-1
Required Input information 8-1
Rules 8-1
Steps 8-2
Impact of GPRS on A-link dimensioning 8-2
9 APPENDIX 9-1
Erlang B tables 9-1
10 ACRONYMS 10-1
Acronyms 10-1
Issue 1.0 – November 2000 Lucent Technologies – Proprietary vii

This page is intentionally left blank
viii Lucent Technologies – Proprietary Issue 1.0 –November 2000

1 Introduction
Scope
This document is a combination of various engineering guidelines existing for each network element.
This can be used by the technical sales support teams (Pre & Post sales) to design the networks and it
provides a detailed understanding of the various aspects which need to be considered while preparing
a network design. The detailed equipment configurations and calculations are also mentioned. All BSS
equipment (except OMC) has been covered by the document. This document is based on the GSM
network release plan and currently it supports GSM Release 9.1/9.2.
The RF design guide need to be consulted separately for the RF designing aspects and are not the
scope of this document. New features like GPRS have been included in this document. The document
covers the equipment impact due to GPRS and covers the calculations for equipment requirement for
GPRS.
This document is intended for use by the following groups:
• Technical Pre and Post sales support

• In country Network Planning and Project teams
• RF Planning team
The Network Dimensioning Tool (NDT) is based on the BSS Network design guide. The tool is meant
for pre and post sales network planning. All the calculations mentioned in the document are the basis
for the tool and the tool can be used for the detailed network design.
Issue 1.0 – November 2000 Lucent Technologies – Proprietary 1-1

Introduction BSS Network Design Guide
BSS Systems Overview

The BSS portion of the GSM System consists of the Base Transceiver Station (BTS) and Base Station
Controller (BSC) system.
Base Transceiver Station (BTS)

The BTS is the physical interface between mobile Stations (MS) and the BSC; it comprises of the
entire radio equipment for one, two or three radio cells, each of which is characterised by a particular
Base Station Identification Code (BSIC). The BTS family of equipment provides both indoor and
outdoor implementations and supports a wide range of site configurations and sizes. One BTS frame
houses up to three cells. To provide a high quality radio connection for the handover process, the BTS
takes a series of measurements of the air interface from the MS and sends the results to the BSC.
This procedure ensures an uninterrupted cellular call as the MS moves from one cell to another.
Lucents’ BTS family consists of the BTS-2000 Macro BTS, the BTS-2000/2C Micro BTS and the
Flexent Macrocell BTS.
Base Station Controller (BSC)

The BSS 2000 series is implemented according to the Type 6 configuration as defined by the GSM
recommendation, implying that the speech transcoding and data rate adaptation functions are
physically separated from the central control function of the BSC. The BSC provided with the GSM
system therefore consists of physically separate BSS Central equipment (BCF-2000) and transcoding
equipment (STF-2000) components. It should be noted, however, that the transcoder may be located
at the BSC site.
BCF-2000 (BCF)
The BCF provides the intelligence and control part of the BSS as well as the interfaces to the BTS(s),
STF-2000 and OMC 2000. Key central control and radio processing functions such as management of
radio resources, radio channel management and local connection management are performed in the
BCF-2000. It also provides switching of individual timeslots between the STF2000 and MSC
components. Finally, one of its key functions is control of the handover process, based on air interface
measurements received from the BTS(s).
STF-2000 (STF)
This provides the speech transcoding and submultiplexing functions. For speech signals, the
transcoding function provides the conversion between the standardised 64kbit/s data rate used at the
network side of the system and the 13kbit/s signal transmitted across the air interface. It also provides
the submultiplexing function where four full rate traffic channels at the BCF-2000 side are combined
onto a single 64kbit/s timeslot to realise a 4:1 saving in required transmission facilities to the BCF-2000
and the BTSs. This is implemented in Lucent’s standard Type 6 configuration where the MSC and
TRAU are co-located.
Operations & Maintenance Centre (OMC)

The OMC provides centralised operations & Maintenance functions for the GSM networks. It is based
on an open system hardware & software platform with proven application s/w that has object-oriented
techniques. Some of its functions are: Network performance analysis, fast and accurate fault
diagnosis, network quality indicators, on time fault correction procedures and timely network capacity
metrics
1-2 Lucent Technologies – Proprietary Issue 1.0 – November 2000

GPRS System Overview

GSM networks have reached a high level of maturity in handling voice calls and operators are looking
into the new market segment of data services.
GPRS gives operators the ideal platform to offer wireless data services in a competitive way.
The introduction of GPRS functionality into existing network will have impact in the equipment
configuration and network capacity. Also new networks have to be planned differently if GPRS
capabilities are to be included.
The GPRS capacity of the Lucent system also depends on the software release used.
This document describes the dimensioning of the GPRS-BSS part of the system based on software
release GSM 9.1 (GPRS Rel.1.5).
As shown in Figure 1, the GRPS part of the network comprises of GBS and GPRS-BSS.
Packet Data
Network
Gi
BSS
SGSN
NSS Gn
Abis
Gb GGSN
Abis
A/Gb
M/Gb STF
BCF MSC
PCU
M/Gb
Abis
BCF
PCU
PLMN
Figure 1: GSM/GPRS System Overview


2 Um Interface
Scope
In a GSM network, the correct dimensioning of the control channels is as important as the traffic
channels to handle the signalling messages. A failure to correctly dimension the control channels may
result in a failure to access the required resource resulting in, for example, a Blocked Call. This
chapter provides guidelines to engineer the SDCCH signalling channels for an expected traffic model.
Introduction
Since so many different signalling and transmission activities take place on the SDCCH, it is often the
SDCCH that is considered as a bottleneck in GSM systems. If there is a heavy congestion on the
SDCCH, the mobiles may be denied access to the call set-up process, even though there may be
TCHs unoccupied.
Therefore, the probability of blocking for the SDCCH must be significantly less than that for the traffic
channels, so the GOS must be better.
GOS for SDCCH should be 5-6 times better than the GOS for Traffic
The following procedures must be taken into account when dimensioning the SDCCH channels:
• Radio Resource management procedures such as:

- Call set-up
- IMSI attach/detach
- Mobility management procedures such as Location Updating and Periodic registrations
• Subscriber services such as SMS and Fax
Capacity Calculation
To calculate the need for SDCCH capacity, the duration as well as the frequency of use for each of the
above procedures must be considered.

Um Interface BSS Network Design Guide
Formula
SDCCH Traffic Per Cell = (A x Number of Subscribers in Cell) + Af
Where:
A = SDCCH Traffic per subscriber
Af = SDCCH traffic due to false accesses
Total SDCCH Capacity Needed

The SDCCH capacity required per subscriber can be calculated by adding up traffic due to all the
procedures mentioned below:
Traffic due to Geographic LU LU/Sub x MHT

Traffic due to Periodic LU PLU/Sub x MHT
IMSI detach traffic Detach/Sub x MHT
IMSI attach traffic Attach/Sub x MHT
Busy Hour Call Attempts BHCA/Sub x MHT
SMS traffic SMS rate x MHT
Fax set-up traffic Fax rate x MHT
Table 1: SDCCH Traffic Per Subscriber
SDCCH Traffic per Subscriber = (LU/Sub x MHT + PLU/Sub x MHT + Detach/Sub x MHT +
Attach/Sub x MHT + BHCA/Sub x MHT + SMS Rate x MHT + Fax set-up traffic x MHT)
Example SDCCH Dimensioning

The following example will show the way an estimation of SDCCH capacity could be done on per cell
basis. We will consider each procedure that is performed on an SDCCH in a cell by using typical
values in a network:
Location Updating Type Normal

Every time an idle MS moves into a different location area, it must perform a Geographic Location
Update. This is done by using an SDCCH channel. The larger the Location Area, the fewer the
Location Updates. For inner cells, which are located far from the LAC boundaries, practically very little
Location updating is done, unless there happens to be an Airport in such a cell. For border cells, the
frequency is quite higher than average. The following figures are assumed:
Number of LUs per Subscriber per hour 0.5

SDCCH mean holding time per LU 3.6 sec
Table 2: Location Updating

Location
Area
boundary
Figure 2: Location Area Boundary Example.
Note: Cells on the Location Area Boundaries will use more SDCCH channels.
In GSM networks, Cells are grouped together and assigned a location area code or LAC. The area
served by these cells is known as Location Area. This helps to save the network its paging resources,
as the paging is carried out only in the cells with a particular LAC rather than in the whole network. As
the mobile moves from one Location area to another, it performs a Location Update.
For details on LAC engineering, please go to:
http://en0033svr06.uk.lucent.com/npse/GSM%20eng_tools/GLAD/LAC_Tool.htm
Periodic Location Update

Following figures are assumed:
The value of T-3212 is assumed here as 6 hour.
Number of PLUs per Subscriber 1 per 6 hours

SDCCH mean holding time 3.6 sec
Table 3: Periodic Location Update Features

IMSI detach/attach
Number of Detach messages per Subscriber per hour 1

SDCCH holding time per Detach 3 sec
Number of Attach messages per Subscriber per hour 1
SDCCH mean holding time per Attach 3.6 sec
Table 4: IMSI Detach/Attach Figures
Call set-up
Number of Mobile terminated calls per Subscriber per hour 0.3

SDCCH holding time per call setup 2.8 sec
Number of Mobile originated calls per Subscriber per hour 0.8
SDCCH mean holding time per call setup 2.8 sec
Table 5: Call Setup Figures
SMS
A mobile receiving an SMS message in idle mode, must access the system using a random access
request and move onto the SDCCH prior to receiving any data. Therefore the higher the ratio of SMS
to traffic calls, greater the number of SDCCH that will be required.
Number Mobile terminated traffic per hour per Subscriber 0.5

Number of Mobile originated traffic per hour per subscriber 0.5
SDCCH mean holding time per SMS 6.2 sec
Table 6: SMS Figures
Fax Set-up
Number of Mobile terminated and originated traffic per hour 0.006

SDCCH mean holding time 2.8 sec
Table 7: Fax Set-up Figures

False accesses
In the networks as dense as we see today, the frequency plans are often quite tight with a lot of re-use.
In these situations, there are a lot of cases when a channel request is responded to by a BTS from a
distant MS that is using a co-channel. If the BTS receives these false accesses, an SDCCH is
allocated and a certain time is passed before the network realises that it was due to interference and
then it releases the channel. It is assumed that there are 10% of those accesses per hour.
Total SDCCH Capacity Needed

The SDCCH capacity needed in a cell can be calculated by adding up all the traffic
Traffic due to Geographic LU LU/Sub x MHT (0.5)(3.6)

Traffic due to Periodic LU PLU/Sub x MHT (1/6)(3.6)
IMSI detach traffic Detach/Sub x MHT (1)(3)
IMSI attach traffic Attach/Sub x MHT (1)(3.6)
Busy Hour Call Attempts BHCA/Sub x MHT (1.1)(2.8)
SMS traffic SMS rate x MHT (1)(6.2)
Fax set-up traffic Fax rate x MHT (0.006)(2.8)
Traffic due to False accesses 10%
Table 8: SDCCH Traffic
Traffic per Subscriber on SDCCH ‘A’ = 5.08+ 0.508 = 5.58 mErlangs
(The above formula includes the extra 10% SDCCH capacity due to false accesses, as above)
SDCCH traffic per Cell = A x Number of Subscribers in Cell
Cell Configuration Example

To further the idea of what has been said above, let us consider an example of a cell with following
configuration:
• Number of RTs = 3
• Average Call Duration =120 seconds
• Traffic per subscriber = Average Call Duration / 3600 = 120/3600 = 33 mErlang
Case 1:
If we allocate 1 TS to SDCCH only, which means 8 SDCCHs, we will have 22 TCHs.
Assuming 2% GOS, from Erlang-B table, we get 14.896 Erlangs and at 33mErlang per subscriber, this
could serve a total of 451 Subscribers.
For the SDCCH with 5.58 mE per subscriber if we assume a GOS of 2/5= 0.4 %,
From Erlang-B table, 8 SDCCHs would give 2.5 Erlangs, which can only serve 448 Subscribers.
Hence the number of subscribers will be limited by SDCCH capacity.
Case 2:
If we configure the cell with 2 TSs for SDCCHs that is 16 SDCCH channels, we will have 21 TCHs that
will give 14. 03 Erlangs (Erlang-B table) and can serve 425 Subscribers.

For the SDCCHs with 5.58 mErlang per subscriber, 16 SDCCHs give 7.7 Erlangs which can serve
1379 subscribers.
Example Conclusion
By comparing the two alternatives, it can be seen that the second case can serve more subscribers,
even though at first glance we may think about it like a waste of traffic timeslots.
Configuration Rules
The SDCCH channel can be configured in either of the two ways:
• Combined mode
• Separate mode
In the combined mode, SDCCH is combined with the BCCH and CCCH in TS=0 as;
1 BCCH + 3 CCCH + 4 DCCH (4 SDCCH/SACCH)
In the separate mode, SDCCH uses the whole TS;
8 DCCH (SDCCH/SACCH)
Configuration Constraints
For BCF, the maximum values as per document SCG GSM9.0 - Um interface- V0.3 are:
• 72 SDCCH/* per Cell

• 4320 SDCCH per BSC
SDCCH/* refers to one SDCCH/4 as well as to one SDCCH/8.
Constraints in Case of SMSCB

In case of SMSCB services, there must be one channel configured as SDCCHCb in the combined or
non- combined mode.
For a combined configuration of BCCHCb we have:
BCCH + FCH + 3 CCH + SDCCH/3 + SDCCHCb
For the non- combined case, we have:
SDCCH/7 + SACCH/7 + SDCCHCb

Typical SDCCH Configuration in a cell
Number of RT 1 2 3 4 5 6 7 8
Number of TCH 7 15 22 30 37 45 52 60
Number of SDCCH 4 4 12 12 16 16 24 24
Table 9: Typical SDCCH Configuration In a Cell
The above table is a reference guide for initial cell configuration. The configuration should be optimised
using the guidelines provided in the earlier sections, according to the actual SDCCH requirements,
which could vary depending upon the Location update and SMS traffic in the cell. For example, in a cell
with 1 or 2 RT’s, the operator could also use Non-combined BCCH configuration and allocate 8
SDCCH’s to meet the additional signalling requirement due to SMS or location update traffic.
For more information, please refer to NCG document No. 401-380-014

This page intentionally left blank

3 BTS Configuration
Introduction
This chapter describes the planning options for dimensioning a BTS site. Most options will depend on
the location, the number of subscribers it has to support, type of combining etc. The following steps
attempt to guide the planner through a logical procedure to a final configuration. However, the order of
importance of the various options may differ from BTS location to BTS location so the planning steps
may differ from those shown here. This guideline shows the options available.
Dimensioning per BTS site
Required input information

• Type of BTS cabinet
• Number of cells at each BTS location
• Mono-band or dual-band coverage
• Number of TRXs in each cell
• Type of TRX combining (if used) or Diplexer only configurations
• Type of frequency hopping employed (if used)
• GPRS support

BTS Configuration BSS Network Design Guide
Steps
Select frequency band of operation:

• 900
• 1800
• Dual-Band
• 1900
Select RF coverage:
• Omni – rural locations
• Two sector – road or rail
• Three sector – Urban, suburban
• In building.
Select type of BTS:

• Indoor Flexent Macrocell
• Outdoor Flexent Macrocell
• BTS-2000/2C
For the BTS-2000 range of BTS equipment, refer to the BSS Network Design Guide for NR 8.6
The type of BTS cabinet chosen should depend upon the capacity required for the final phase of the
network implementation. Use the following table to check that the selected BTS type supports the
frequency band chosen:
BTS type Frequency band supported

900 1800 Dual Band 1900
Flexent Macrocell indoor Yes Yes Yes Yes
Flexent Macrocell outdoor Yes Yes Yes Yes
BTS-2000/2C Yes Yes No1 No
Table 10: Supported Frequency Band Per BTS Type
Select the type of combining

Consideration to the type of combining employed can depend on several factors. If frequency hopping
is required then the type of hopping needs to be considered. Power output may be important,
especially for rural locations where the cell may have a large RF coverage radius. Hybrid combining
has higher transmit losses than Filter combining.
Frequency hopping: Diplexers only – Synthesiser and Baseband hopping

Hybrid combining – Synthesiser and Baseband hopping
Filter combining – Baseband hopping only
1
Dual Band is not supported on the BTS-2000/2C within the same BTS cabinet. However, Dual Band
can be configured by using 2 BTS-2000/2C cabinets, one per frequency band. If the BTS-2000/2Cs
integral antennas are not used then four external antennas per RF coverage area would be required.

Select the number of TRXs required per cell:

The configuration chosen should be able to support the final number of TRXs required for the final
phase of the network implementation. Use the following table to select a configuration that supports the
total quantity of TRXs:
TRXs per cell for Mono-Band operation

BTS type Diplexer Hybrid combining Filter combining
900 1800 1900 900 1800 1900 900 1800 1900
Flexent Macro id 2 2 2 4, 6, 8 4, 6, 8 4 4, 6, 8 4, 6, 8 N/A
Flexent Macro od 2 2 2 4, 6, 8 4, 6, 8 4 4, 6, 8 4, 6, 8 N/A
BTS-2000/2C 2, 4 2, 4 N/A N/A N/A N/A N/A N/A N/A
Table 11: TRX Quantities Per Cell
TRXs per cell for Dual-Band operation

BTS type
Diplexer Hybrid combining Filter combining
Flexent Macro id & od Sector 1 Sector 2 Sector 3 Sector 1 Sector 2 Sector 3 Sector 1 Sector 2 Sector 3
3 cell support (NR 9.1) 2/2 N/A N/A 4/4 N/A N/A 4/4 N/A N/A
6 cell support (NR 9.2) 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2 2/2
Table 12: TRX Quantities Per Cell
NDT can be used for inputting the data for the type and number of BTSs. The number of subscribers
supported by the total number of BTSs is calculated and that is then compared with the number of
subscribers required to be supported by the network. The total number of BTSs are generally input
from the RF department. (ASSET RF tool can be used to input the data directly into NDT).
Dual Band
The term dual-band operation refers to the support of both GSM900 and GSM1800 within the same RF
coverage area (sector). GSM1900 is not included in this context.
For each frequency band per sector, 1 cell is required. Therefore for a 3 sectored BTS site, 6 cells will
be required to support dual-band.
BTS2000/2C
The BTS2000/2C, although housing 2 TRXs per BTS cabinet, cannot support dual-band within 1
cabinet. By using BTS 2 cabinets per sector, 1 GSM900 and 1 GSM1800, dual-band coverage can be
implemented. A single Abis link (E1 employing LAPD signalling link concentration) can support 6 BTS
cabinets (12 TRXs), configured as 1 GSM900 cabinet and 1 GSM1800 cabinet per sector.
Flexent Macrocell
Dual-band operation is supported on the Flexent Macrocell, with Network Release 9.1 supporting 3
cells per cabinet and Network Release 9.2 supporting 6 cells per cabinet. This means that for NR 9.1
Dual-Band coverage can only be realised for Omni (single sector) configurations (1 cell at 900MHz and
1 cell at 1800MHz). With NR 9.2, 6 cells will give the capability of supporting dual-band for up to 3
sectors (3 cells at 900MHz and 3 cells at 1800MHz).

Impact of GPRS on the BTS

To incorporate GPRS support at the BTS a certain amount of the traffic channels have to be
configured to function as GPRS channels.
For the first phase of GPRS the following restrictions apply:
• A maximum of 8 GPRS channels (PDCHs) can be configured per cell.
• These 8 PDCHs must be on the same TRX.
• A dual-service timeslot can be used for PS and CS traffic.
• Frequency Hopping cannot be used on the channels carrying dual service traffic.
• For CS traffic normal GSM power control is applied.
• For PS traffic, open loop power control is used on the up-link, while no power control is used on
the down-link.
For the introduction of GPRS to the network it is recommended that the PDCHs be allocated to the first
TRX (0) in the cell. The advantages of this are that the last 2 restrictions will have no consequence as
TRX 0 carries the BCCH as power control cannot be implemented on the BCCH carrier anyway. Also,
with the “BCCH Reconfiguration” feature, loss of TRX 0 will result in the PDCHs being re-established
along with the BCCH and thus PS functionality is not lost.
The downside to this option is that a maximum of only 7 PDCHs can be assigned per cell, but in the
start-up phase of GPRS it is expected that 4 PDCHs will be more than sufficient.
Currently, the system treats CS and GPRS calls equally, without priorities. In release 1 it will not be
possible to reserve channels for GPRS service only. The configured GPRS channels can also be used
for CS services in the event of all the other CS channels in the cell being occupied and provided that
the GPRS channels are idle. Therefore the degradation of the CS capacity will depend on the amount
of PS traffic.
To maintain the network capacity, for the worst case traffic scenario, it is recommended to add extra
TRXs, where possible, to compensate for the potential loss of CS capacity.
When increasing the BTS capacity to compensate for PS traffic, the configuration rules are to be
followed and the increased Abis link capacity has to be taken into consideration.
To configure the BTS, several capacity limits have to be taken into consideration. The maximum
capacity is reached when any of the limits mentioned below are reached:
Capacity Description Rel. 1

Max. Number of PDCHs/Cell 8
Max. Number of TRXs with PDCHs/Cell 1
(max. 8 PDCHs total/cell)
Max. Number combined PDCHs in down link per 4
subscriber
Max. Number combined PDCHs in up link per 2
subscriber
Table 13: BTS GPRS Capacity Limits

Standard Configuration
In discussion with several operators, a standard has been elaborated. This configuration is also
reflected in the script files, which have been developed to support the GPRS network introduction. (For
details about the Time Slot and Channel settings, please refer to the documents: Network
Configuration Guidelines GSM9.0/GSM9.1)
The proposed standard configuration shown in the following table, consists of 4 PDCH, but the
configuration can easily be enlarged to 6.
Channel
TRX 0 1 2 3 4 5 6 7
0 BCCH SDCCH or SDCCHCB DS * DS * DS * DS * TCH or DS * TCH or DS *
1 TCH TCH TCH TCH TCH TCH TCH TCH
2 SDCCH TCH TCH TCH TCH TCH TCH TCH
3 TCH TCH TCH TCH TCH TCH TCH TCH
* DS = Dual Service timeslot (CS or PS as required)

Table 14: Proposed Standard Configuration
Further Information
For further information on RF configurations and antenna couplings please refer to the following
Engineering Guidelines:
BTS-2000 - EG18 vol. 2 - 401-380-368

BTS-2000/2C - EG24 - 401-380-324
Flexent Macrocell - EG28 - 401-380-371
All are orderable from CIC in the usual way.


4 Abis Link Dimensioning
Calculating required number of Abis

links
The costs of providing Abis links can represent a significant proportion of the total running costs of a
cellular network. It is therefore important that the minimum number of Abis links are used within a
network to minimise ongoing rental costs. This could be implemented in the use of Multi-drop
configurations. However, the requirements for projected growth need to be considered in the planning
of the network.
To calculate the total number of Abis links required in a new network requires some initial information:
• The quantity of Star and Multi-Drop connections required.

• For the Multi-drop connections, the number of cells on the link.
• The number of cells per physical BTS location.
• Number of TRXs per cell.
• Whether LAPD signalling link concentration is used or not.
• E1 or T1 transmission.
Generally, the following assumptions can be made:
• LAPD signalling link concentration will be employed.

• For small BTS sites1, Multi-drop connections used for an average of 1 link per 2 BTSs.
• For standard BTS sites2 star connections used: 1 link per standard BTS site.
1
The reference “small BTS” refers to BTS sites typically of up to 4 TRXs.
2
The term “standard BTS” used here refers to BTS sites typically containing between 4 and 12 TRXs

Abis Link Dimensioning BSS Network Design Guide
From our initial planning calculations we know (approximately) how many BTSs and configuration
types (omni, sectored, TRXs per cell etc.) we require in the system. Using the above assumptions we
can calculate the number of Abis links required:
 No. of small BTSs 

Abis links =   + No. of s tan dard BTSs
 2 
The above formula suggests that 2 “small” BTSs could be configured on a single multidrop Abis link and
a “standard” BTS would require a single dedicated Abis connection. These assumptions are for
guidance only.
Dimensioning the Abis link
Required input information:
• Number of Cells on the link (CellTotal).

• Number of TRXs on link (TRXTotal).
• Transmission link: E1 or T1.
• With or without LAPD signalling link concentration.
• Support for GPRS
Rules
• There are 32 64kbit/s timeslots on an E1 Abis link.
• There are 24 64kbit/s timeslots on an T1 Abis link.
• TS 0 on an E1 Abis link is reserved for timing and synchronisation use (FAS).
• Maximum timeslots available for signalling and traffic on an E1 link = 31.
• Maximum timeslots available for signalling and traffic on a T1 link = 24.
• Total Abis links supported per BTS:
- BTS-2000/2C: 1 x uplink, 1 x downlink

- BTSs fitted with MRIF: 2 x uplinks, 1 x downlink
- BTSs fitted with MRIF2: 3 x links, each configurable as an uplink or a downlink.
• A cell cannot be split across Abis links.
• Timeslots required without using LAPD signalling link concentration:
- 2 timeslots per TRX for traffic/data.

- 1 timeslot per TRX for TRX signalling.
- 1 timeslot per cell for BTC signalling.

• Timeslots required using LAPD signalling link concentration:
- 2 timeslots per TRX for traffic/data.

- 1 timeslot for signalling for 4 TRXs or 3 TRXs + 1 BTC (all must be within the same cell)3
Calculate timeslots required

Systems not using LAPD signalling link concentration:
Timeslots = [TRXTotal × 3] + CellTotal
Systems using LAPD signalling link concentration:
  Average No.TRXs per cell + 1  

Timeslots = [TRX Total × 2 ] +   ( round up ) × Cell Total 
 
 4  
where: TRXTotal is the total number of TRXs in all cells on the link.
CellTotal is the total number of cells on the link. Table 15 shows the number of timeslots required for a
given number of TRXs and Cells on 1 Abis link.
TRXs Number of Cells

per cell 1 2 3 4 5 6 7 8 9 10
Without LAPD Timeslots required (bracketed figures for E1 only)
1 4 8 12 16 20 24 (28)
2 7 14 21 (28)
3 10 20 (30)
4 13 (26)
5 16
6 19
7 22
8 (25)
9 (28)
10 (31)
With LAPD Timeslots required (bracketed figures for E1 only)

1 3 6 9 12 15 18 21 24 (27) (30)
2 5 10 15 20 (30)
3 7 14 21 (28)
4 10 20 (30)
5 12 24
6 14 (28)
7 16
8 19
9 21
10 23
11 (25)
12 (28)
Table 15: Single Abis Link Capacity Figures
3
This rule applies to circuit Switched Traffic. For Packet Switched traffic or for Dual Circuit traffic extra
signalling may be required. See GPRS support on the Abis interface later in this section.

GPRS support on the Abis interface

With the first release of GPRS a maximum of 8 PDCHs can be allocated per cell. Typically, 4 PDCH
will be the expected figure. When dimensioning the Abis interface it will still be possible to concentrate
a maximum of 4 RT signalling channels on a 64kbit/s timeslot for up to 6 PDCHs. For configurations of
7 or 8 PDCHs per cell a maximum of 3 RT signalling channels can be configured per 64kbit/s timeslot.
Further Information
For further information on the Abis interface and its dimensioning refer to document number 401-380-
349, Engineering Guideline EG19. This can be ordered from CIC in the normal way.

5 BCF Planning
Introduction
This section allows the user to dimension and plan the number of BCFs required in their networks after
calculating the number of BTSs. The NDT can be used for all the calculations that are described in the
further sections.
BCF Planning Steps for Circuit Switch

Network
The following are the steps we have considered to calculate the number of BCFs required in the
network:
• BCF subscriber capacity based on a traffic model

This section explains how the capacity of the BCF can be calculated using a specific traffic
model and the capacity of the BCF in Erlang is calculated as an end result. This capacity of the
BCF should be then taken for further BCF calculations.
• Calculation of number of BCFs
This section takes the input from the BTS calculations (TRX, cells, Abis, Erlangs) and then the
Minimum quantity required for the BCF is calculated. The capacity limits of the BCF are taken
into account as per the BCF release plan.
The section calculates the BCF required for Circuit switched traffic. For GPRS traffic the further
mentioned section should be referred to.
• BTS – BCF distribution
This section describes how to distribute the BTSs across the BCFs and how it is done in the
Network design tool.
• Calculation for all the cards (SDFU, TCU, etc.)
The cards required for the BCFs are calculated accordingly as mentioned in this section. Based on this
the capacity for each BCF is also calculated.

BCF Planning BSS Network Design Guide
If the network has a combined Circuit switched and Packet switched traffic then the steps mentioned in
the next section should be followed (Section 5.1)
1) BCF Capacity based on a Subscriber Traffic

Model (Only for Circuit Switch Traffic)
The following sections describe the procedure to calculate the number of users that can be supported
by a BCF (containing HP B132 servers) and the maximum traffic a BCF can handle (In Erlangs)
depending on the subscriber traffic behaviour. This information is often required for Green-Field
planning and for preparation of bids. The calculations shown here can also be used for calculating the
capacity of existing BCFs in live networks.
The following parameters should be provided as input to the BCF Capacity calculation model:
Subscriber Traffic Model Parameters
A BHCA per subscriber

B SMS per subscriber per BH
C Fraction of voice calls (BHCA) that are mobile terminated
D Fraction of SMS calls that are mobile terminated
E Traffic per subscriber [Erlang]
F BSC-controlled handover per call
G MSC-controlled handover per call
H Location Updates per subscriber per BH
I IMSI detaches per subscriber per BH
J Fraction of Call Attempts that lead to a TCH Establishment
K Paging Index
L Paging Repetition Factor
M Number of cells per Location Area
Table 16: BCF Capacity Parameters
The maximum operational configuration of the BCF is assumed for the purpose of these calculations.
Here it is assumed that the BCF is equipped with 1 COW, 4 CEWs and 1 redundant CEW.
Note: The percentage CPU load (HP B132 server) for each procedure within the BCF is provided
by NTI and is BCF Release specific.

The following data was provided for the BCF R3.0 by NTI.
Procedures CPU load CPU load

per procedure on per procedure on
COWS CEWS
BHCA 0,0007000 0,0012500

SMS 0,0005480 0,0009446
BSC-controlled handover 0,0001800 0,0004100
MSC-controlled handover 0,0008100 0,0004300
Location Update and IMSI Detach 0,0003600 0,0005900
Paging 0,0000230 0,0002300
Sending of Paging Cmds on Abis –Link - 0,0000072
Measurements Reports (per Erlang) - 0,2600000
CPU load empty 22 20
Table 17: BCF R3.0 Percentage CPU Load
BCF Maximum Capacity

Calculation
The maximum capacity of the BCF is given by the minimum of the capacity on the COW and CEWs.
The bottleneck could be either the CPU load on the COW or on the CEW. Also, to calculate the
maximum capacity of the BCF the maximum recommended number of CEWS should be 4 (plus one
redundant CEW).
So to calculate the CPU load on the COW and each CEW:
Total CPU Load on COW = (Max. Number of users) x (CPU load per user on COW )
+ Empty load on COW
Total CPU Load on CEW = (Max. Number of users) x ( CPU load per user on each
CEW )
+ Empty load on CEW
To calculate the CPU load per user on COWS (Formula - 1):
CPU load per user on COWS = SUM over all Procedures (Number of Procedures per
User per BH x CPU Load per Procedure on COWS)
To calculate the CPU load per user on each CEW (Formula - 2):
CPU load per user on CEWS = SUM over all Procedures (Number of Procedures per
User per BH x CPU load per Procedure on CEWS)/number of CEWS
Note: With BCF R3.0 we distinguish between the load for the importing of the pagings coming from the
COWS and the load for sending out paging command messages on the Abis side
Then, the CPU load per procedure for the COWS and the CEWs is given in Table 17 above. The
(Number of Procedures per User per BH) is either taken directly from Table 16 or can be calculated in
the following way:
• BHCA procedures per user: = A

• SMS procedures per user: = B
• BSC-controlled HO procedures per user = A*J*F
• MSC-controlled HO procedures per user = A*J*G

• Location Update procedures per user = H

• IMSI detaches procedures per user = I
• Paging (on A-Link) procedures per user = (( A * C ) + ( B * D)) * ( K * L )
• Sending of Paging Cmds on Abis-Link procedures per user = (( A * C ) + ( B * D)) * ( K * L * M )
The total number of users that can be supported per BCF can then be calculated by the following
formula (Formula - 3):
Total number of users per BCF = MIN ((maximum desired COWS CPU load - Empty Load
COWS)/CPU Load per User on COW; (maximum desired CEWS CPU load - Empty Load
CEWS)/CPU Load per User on CEW)
The empty Load of the COW and CEW is given in Table 16
Based on operational experience the desired loads on the CPUs should not exceed the following rates:
Maximum desired COWS CPU load = 80%

Maximum desired CEWS CPU load = 90%.
The maximum traffic per BCF can easily be calculated by multiplying the total number of users by the
traffic per user (E from Table 16)
Example
To calculate the maximum capacity of the BCF based on the subscriber traffic model given below we
assume that the BCF is fully equipped with 4 + 1 CEW configuration.
Subscriber Traffic Model Parameters
BHCA per subscriber A 0.6

SMS per subscriber per BH B 0.3
Fraction of voice calls (BHCA) that are mobile terminated C 35%
Fraction of SMS calls that are mobile terminated D 12.5%
Traffic per subscriber [Erlang] E 0.015
BSC-controlled handover per call F 0.8
MSC-controlled handover per call G 0.2
Location Updates per subscriber per BH H 1.5
IMSI detaches per subscriber per BH I 0.1
Fraction of Attempts that lead to a Call Establishment J 75%
Paging Index K 2
Paging Repetition Factor L 1.6
Number of cells per Location Area M 30
Table 18: Subscriber Traffic Model Parameters

Calculate the CPU Load per User on the COW and CEWS using formulas (1) & (2).
CPU Load per User on COW =

A * 0.0007000% [BHCA]
+ B * 0.0005480% [SMS]
+ A * J * F * 0.0001800% [BSC-HO]
+ A * J * G * 0.0008100% [MSC-HO]
+ (H + I) * 0.0003600% [LU + DET]
+ ((A * C) + (B * D)) * K * L * 0.0000230% [PAGING] =
0.001248744
CPU Load per User per CEW =

(A * 0.0012500% [BHCA]
+ B * 0.0009446% [SMS]
+ A * J * F * 0.0004100% [BSC-HO]
+ A * J * G * 0.0004300% [MSC-HO]
+ (H + I) * 0.0005900% [LU + DET]
+ ((A * C) + (B * D)) * K * L * M * 0.0000072% [Sending PAGING_CMDs]
+ E * 0.26) / Number of CEWs [MES.REP]
+ ((A * C) + (B * D)) * K * L *0.0002300 [PAGING]
= 0.0017175605
Calculate the total number of users that can be supported by the BCF using formula (3):
Total Number of Users= MIN ((80% - 22%) / 0.0012487%; (90% - 20%) /0.0017175605) = MIN
(46447; 40755) = 40755
Calculate the Maximum Traffic per BCF from the traffic per User in the Traffic Model:
Maximum Traffic per BCF = (Total Number of Users) * E= 40755 * 0.015 = 611 Erlangs
The maximum number of Erlangs supported by the BCF can be obtained in the above way
based on a certain traffic model. The NDT tool can be used for the same and the maximum Erlangs
obtained are used as a limiting factor for the BCF calculations.
Note: The current values mentioned in the example are based on the B 132 servers and as
mentioned later the B 180 servers increase the overall capacity by around 40%. Using the same
traffic model we would get for B 180 servers the capacity of the BCF = 855 Erlangs.
Note: The BCF capacity in Erlangs is calculated with maximum configuration i.e with 6 servers. The
subsequent sections explain the method to calculate the number of servers after distribution of the
BTSs to the BCFs. The exact capacity of the BCF would then depend on the number of servers
calculated and the BCF Erlang capacity should then be recalculated taking into account the exact
number of BCFs. For planning purposes, the steps mentioned in this chapter can be used and the
section below to calculate the number of servers from the number of users is for information only.

Calculate Number of Servers

The calculations for the number of servers mentioned here is from the perspective of one BCF based
on a traffic model. For planning purposes the calculations mentioned in the subsequent sections
should be used. NDT calculates the Number of servers for each BCF based on the calculations
mentioned in the subsequent sections.
The following approach should be taken if the task is to calculate the required number of cell servers
given a total number of users to be supported by a particular BCF and a specified subscriber traffic
model. This number of users may be determined by the air-interface capacity of the cell configuration
allocated to the BCF and the expected traffic per subscriber.
Every BCF has a minimum of 3 servers; one common server and two cell servers (one of them might
be for redundancy).
The number of Cell Servers (CEWS) is calculated and dependent upon the subscriber traffic model
and the Location Area configuration.
The number of CEWS required to support the subscriber traffic offered by all the BTS on the BCF can
be calculated as follows:
Number of CEWS = max [ 2, CPU Load per user on all CEWS * Total Number of
Users/(Maximum CPU Load on CEW - Empty CPU Load on CEW ) ] + 1 Redundant CEWS
The CPU Load on all CEWS is based on the Traffic model in Table 16 and calculated as follows:
CPU Load per user on all CEWS =

(A * 0.0012500% [BHCA]
+ B * 0.0009446% [SMS]
+ A * J * F * 0.0004100% [BSC-HO]
+ A * J * G * 0.0004300% [MSC-HO]
+ (H + I) * 0.0005900% [LU + DET]
+ ((A * C) + (B * D)) * K * L *0.0002300 [PAGING]
+ ((A * C) + (B * D)) * K * L * M * 0.0000072% [Sending PAGING_CMDs]
+ E * 0.26) [MES.REP]
The total number of users can be obtained from the planned number of subscribers to be served by all
the BTSs linked to the BCF.
The maximum CPU Load on CEW is 90%. Empty CPU Load on CEW can be obtained from Table 17.
(Maximum CPU Load on CEW – Empty CPU Load on CEW) = (90% - 20%) = 70%
B180 Servers
With the introduction of the B180 server, load tests have shown an increase in capacity by 40%.
The final results have still to come, along with a new traffic model and the test results. This information
will be included in future issues of this document. In case of a mixed configuration the calculations for
the B 132 servers will have to be considered.

Network Dimensioning Tool (NDT)

The NDT provides the functionality to the user to input their own Traffic model and based on the above
calculations the number of Erlangs supported by the BCF are calculated which are then used as a
factor when calculating the number of BCFs required in the network. The tool is updated as when the
new test results are available from NTI as per the availability of the GSM release, so the tool can be
used to calculate the capacity supported by BCF based on a particular traffic model. The tool can be
used for network design for new as well as growth for old networks and can be found at:
http://en0033svr06.uk.lucent.com/npse/GSM_eng_tools/NDT/eng_tools_home_NDT.htm
2) BCF Dimensioning
This section explains how to dimension the number of BCFs required in a network.
We get the number of BTSs and the number of subscribers are given as input by the user.
Rules
• Limits per BCF:
E1 Systems T1 Systems
Abis Links 60 60
M-links 10 10
Cells 180 180
TRXs 256 256
SDFUs 26 26
Table 19: BCF Limits
Note: Erlang capacity is calculated from the Traffic model as explained in the previous
section.
• Limits per server:

- Signalling channels = 124
- TRXs = 64
- Cells = 45
- Maximum Abis links = 20
• 1 timeslot is required on one M-link per BCF for OMC connection.
• A minimum of 2 M-links per BCF for redundancy.
• An SDFU can interface up to 4 E1/T1 links
• 2 to 8 SSC7 signalling links (64 to 725 messages per second)
Calculate the number of BCFs required.

Once we have the BTS network, we can calculate the minimum number of BCFs needed to support
the BTSs.
• The user inputs the values for total Number of BTSs, cells, TRX.
• The number of subscribers, Tot_Subs, used in the calculation, is the total number of subscribers
required by the customer to be supported.

Tot_Erlg = Tot_Subs * Erlg_Per_Sub
Input information required:
• Tot_Erlg Total number of Erlangs to be supported

• Tot_Trx Total number of TRXs required
• Tot_Cells Total number of cells required
• Tot_Abis Total number of Abis links
 Tot _ Er lg Tot _ Trx Tot _ Cells To t _ Abis 

Min _ Nb _ BCF = Max  , , , 
 MaxEr lg per BCF MaxTRX per BCF MaxCells per BCF MaxAbis per BCF 
Min_Nb_BCF = Minimum Number of BCFs
Note: MaxErlg per BCF should be taken from the value calculated for the Erlang capacity of the BCF in
the BCF traffic model section (Section 1).
3) BTS - BCF distribution

The Homing plan and LAC (Location area code) plans are used for the network connectivity design.
The homing plan refers to the assigning of BTSs to a BCF. This has to be done according to some
requirements and constraints. In the network design there should be a balanced BCF load, the link to
the BCF site should have a reasonable length and the design should consider moving traffic in a way it
creates the minimum of signalling. This is generally done after taking into account the traffic loads on
the various roads according to the terrain maps.
The LAC and Cell id is a 2-Octet number (0000-FFFF in Hexadecimal format). Valid decimal values
range between 0 and 65535. The LAC is assigned by Systems Engineering team. Detailed LAC
planning guidelines should be referred to for the network design.
The NDT can be used to do an equal distribution of the BTSs to the BCF. This automatically allocates
the number of BTSs in the network to the total number of BCFs in the network.
Once the BTSs are distributed across the BCFs in the network, the attached capacity of the BCF
should be tracked.
The attached capacity of the BCF is given for the following parameters:
• TRX
• Cells
• Erlangs
• TCH
• M links
• Abis links
• BHCAs
These figures should be checked as when the network is grown. The NDT helps to track the attached
capacity of the BCF and on looking at the table one can find out how much of the capacity is available
on the BCFs in the network.
Detailed location area planning documents should be referred to for proper planning purposes.

One of the documents describing the Location area design rules can be found at the link below.
http://en0033svr06.uk.lucent.com/npse/Network_Engineering/Dimension_Planning/Documentation/BS
S_Eng/BSS_home_left_frame.htm
4) Calculations of Cards
Number of HP Servers per BCF

The maximum number of servers in the BCF are 6. Out of that 1 server is the Common Workstation
(COWS) and the rest are Cell workstations (CEWS).
Once we know the cell configuration linked to the BCF, we’re able to calculate the number of servers.
Sig_Ch = Tot_Trx + Tot_Cells + Tot_Mlinks +1;
Tot _ Sig _ Ch Tot _ Trx Tot _ Cells Tot _ Abis

Cell_Servers = MAX[2, , , , ]
124 64 45 20
Nb_Server = Cell_Servers +1
Nb_Server= Number of servers
If we choose to have redundancy in the BCF then the total number of servers will be:
Number of Servers = Nb_Server + 1
Server Redundancy Concept
Redundancy increases the availability of the system. In case of a server crash, the processes are
redistributed to maintain maximum coverage.
The redundant workstation runs in a load sharing mode as CEWS providing spare capacity. No idle
hardware is wasted for redundancy purposes. The types of workstations are only different from
application point of view, all have the same HW (They can be B 132 or B 180 servers). In all scenarios
the maximum number of servers in the BCF is always 6.
SDFU Calculations/Distribution
Purpose
This section provides an overview on how to calculate the number of SDFUs and their distribution
within the SRS. For detailed description please refer to the BCF engineering guidelines EG 20.

SDFUs
The number of SDFUs required depends upon:
• The number of internal E1/T1 links.
• Number of Abis links.
• Number of M-links.
Each SDFU can support up to 4 interfaces. These can be internal, M-links or Abis E1/T1 links. See
Table 20 for SDFU placements within the BCF shelves. The minimum configuration of 3 servers will
support up to 16 Abis and 4 M-links and requires 8 SDFUs.
Internal E1/T1 links

Internal server interfaces, Abis and M-interfaces have defined positions in the SRS on particular SDFU
cards as shown in Table 20. Server interfaces are either E1 or T1 links as per the M interface. Mixed
E1/T1 links are not supported. Four links are required per server.
The minimum three servers require SDFUs in slots 7, 8, 9, 10, 23, 24, 25 and 26. Further SDFUs are
brought in as required. The fourth server requires SDFU cards in slots 6, 11, 16 and 27. The fifth
server requires SDFU cards in slots 5, 12, 21 and 28, and the sixth server requires SDFUs in slots 4,
13, 20 and 29.
Distribution/Configuration of Abis links

The first 16 Abis links are assigned to SDFUs in the above 8 slots. They can be assigned in any order.
For further Abis links extra SDFU cards are then introduced into slots in the following order 3, 19, 2, 18,
1, 17, 6, 16, 11, 27, 5, 15, 12, and 28. Refer to Table 20.
SDFU slots
Dec 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
Hex 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
A32 A24 A16 M8 M5 A40 A1 M0 A8 M2 A45 A56 M6
Port 0
SDFU
A33 A25 A17 A51 A41 A2 A0 A9 A10 A46 A57
ports Port 1
(shelf 0)
A34 A26 A18 A52 A42 A3 S2 S2 A11 A47 A58
Port 2
port 0 Port 1
A35 A27 A19 S6 S5 S4 S3 S1 S1 S3 S4 S5 S6
Port 3
port 0 port 0 Port 0 port 0 port 0 Port 1 port 1 port 1 port 1 port 1
Dec 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Hex 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
A36 A28 A20 S6 S5 S4 S3 S1 S1 S3 S4 S5 S6
Port 0
port 2 port 2 Port 2 port 2 port 2 Port 3 port 3 port 3 port 3 port 3
SDFU
A37 A29 A21 A53 A43 A5 S2 S2 A14 A48 A59
ports Port 1
port 2 Port 3
(shelf 1)
A38 A30 A22 A54 A44 A6 A4 A12 A15 A49
Port 2
A39 A31 A23 M9 A55 M4 A7 M1 A13 M3 A50 M7
Port 3
Key
A Abis interface S Server connection M M interface Not used
Table 20: SDFU Card Placements
Allocation of Abis links to the BCFs

From earlier calculations we have the number of Abis links to be supported within the network. These
links now need to be allocated to specific BCFs. When assigning Abis links to a BCF, we have to be
constantly aware of its capacity limitations as each Abis is assigned. These limitations are shown in the
Rules in the previous chapter. The Abis links should be evenly distributed across the BCFs.

Calculate the number of TCUs required.

2 TCUs are required per BCF.
Further Information
For further information on the BCF refer to document number 401-380-350, Engineering Guideline
EG20. This can be ordered from CIC in the normal way.
5) GPRS
GPRS Impact on BCF

• A dedicated server is required for GPRS
• One of the existing servers used for CS can be reconfigured and used for GPRS, but then the
CS calculations need to be done again with the less number of servers as some BCF
capacity will be lost due to the server being configured for GPRS.
• If the CS capacity is to be maintained, a server has to be added. This is possible, provided the
maximum number of 6 server per BCF at the final configuration is not been exceeded.
• In case the BCF has been configured with redundancy, another possibility is to use the
redundant server for GPRS, but this would lead to increasing the downtime for the
connected BTSs in case of any failure.
• If a BCF expansion is not possible, then an additional BCF with a minimum configuration of 4
servers (1 common server, 2 cell server, 1 GPRS server) has to be added.
• On the M-links, dedicated GPRS time slots (TS) are needed. These TS are not shared with
CS.
• To compensate this loss of link capacity, additional M-links might be required.
• An expansion is only possible provided that in total 10 M-links per BCF is not exceeded.
• Impact on the Cell servers. Due to TBF, extra signalling messages are sent on the Cell servers
and that leads to an impact on the CPU load on the Cell servers.
BCF Capacity Limits

To configure the system correctly, several capacity limits are to be taken into consideration.
The maximum capacity is reached if any of the below mentioned limits is reached first.
Capacity Description Rel. 1
BCF:
Max. Number of GPRS server per BCF 1
Max. Number of simultaneous PDCH connections per BCF 93
Max. Number of installed PDCHs per BCF 1440
Max. Number of GPRS Time Slots on M-links/BCF (1 TS = 64 31
kbit/s)
Table 21: Capacity Limits
The number 93 PDCH relates to the physical limitation of the BCF in GPRS release 1. The GPRS
server (=GWS) has 4 E1 interfaces. With 3 E1 lines used for the server connection to the BTSs we
have 3*31 TS (= 93) available. The fourth E1 line is used as Gb interface.

Now, you can have more than 93 data users connections (PDCHs) simultaneously. In theory up to
1440 (180 cells * 8 TSs) data user connections and therefore 1440 PDCHs can be established. This
means we support 1440 PDCHs statically. However, the number of PDCHs supported dynamically
depends on the data traffic generated by the established logical data connection. So it is suggested to
talk about data throughput than about number of PDCHs supported
5.1) BCF Planning Steps for Combined Circuit and Packet Switch
Network:
In case of a network having both Circuit Switch and Packet Switch traffic, the BCF planning steps
should be:
1 BCF capacity calculation
This section provides information on how to calculate the number of users per BCF for a combined
traffic (CS and PS). The total number of BCFs required can then be calculated for the network if
the total subscribers are known. So the Step 1 mentioned in the previous section - BCF planning
steps for Circuit Switch n/w, should be used and in addition the steps mentioned in this chapter
also need to be considered to get the BCF capacity.
2 Calculation for Number of BCF required
This section explains how to calculate the final number of BCFs required for the network.
3 BTS – BCF Distribution
This section is the same as mentioned in the previous chapter. (BCF planning for Circuit switch
n/w). The routing area planning information is also included in this section.
4 Calculation of cards
The cards required for the BCF are calculated accordingly as mentioned in this section. Based on
this the capacity for each BCF is also calculated

Subscriber Capacity Calculation for Combined

Circuit Switch and Packet Switched Traffic
The objective of this chapter is to describe a procedure to calculate the number of BCFs required for a
combined traffic, for a certain number of CS and PS subscribers. Also it provides a procedure to
estimate the maximum number of GPRS users a BCF can support, or, similarly, the number of GPRS
packet data channels needed to support a given number of subscribers per BCF. The capacity
engineering guidelines given here are adequate for sizing "best effort" data services.
The capacity of a network offering circuit switched services can be calculated using the well-known
Erlang-B formula. This formula assumes that the time between the arrival of new calls is exponentially
distributed, while the length of time calls occupy a timeslot may have a general distribution. The
maximum offered traffic in Erlang/cell could be calculated, given the required call blocking probability
(typically 2%). If the average generated traffic per user is known this value can be translated into
number of users per cell.
The capacity of a network offering both circuit and packet switched services is more complex. The
number of subscribers a PDCH can support, for example, is dictated largely by the way GPRS
subscribers use the network. A PDCH used by mobile systems transferring a few megabytes of data
per hour, for example, will support fewer mobile systems than a PDCH used by mobile systems
sending a kilobyte or less of data per hour.
The applications mobiles will use a GPRS network for is still a matter of speculation. The usage
characteristics will be determined by the data transfer requirements of as-yet-undeveloped
applications, GPRS tariff rates, and other factors. The amount of data typically sent and received by a
mobile system after it has attached and activated PDP context, the length of time a mobile system
typically remains attached, the characteristics of data transfer (periodic bursts of packets, or bulk data
transfer) are for the most part unknown. Yet all these factors influence the GPRS signalling load in a
cell and the amount of mobiles a cell can support.
In this section we introduce a capacity model which can be used to estimate GPRS system capacity.
Simplified Capacity Estimation Model

For sizing purposes, we will use a crude model of a mobile systems interaction with the GPRS
network. This model will not capture the burstiness of data transfer, but will allow us to coarsely
dimension PDCH capacity.
Assumptions
Quick response times are important for many types of applications. As a rough rule-of-thumb, the delay
performance of the airlink will be unacceptable for many transaction-oriented applications at utilisation
beyond 80%. Hence, we assume that during the busy hour the maximum average utilisation of PDCHs
is 60%, reserving a 20% margin to account for peak loads.
Shared resources TCH/PDCH

We assume that the busy hour for GPRS is at the same time as the busy hour CS. The cell
configurations with the number of available timeslots and the figures for the offered CS traffic are
given.
All the PDCHs will be dual service channels and therefore also candidates for circuit switched use.
Since there is no model for the arrival of PDCH requests and releases we assume the worst case that
the circuit switched calls could preempt the GPRS channels. Then the average amount of channels
available for packet data transfer can be calculated.

Uplink and downlink capacity

The system offers the same capacity in uplink and downlink direction. It is expected that the majority of
applications will such as retrieving of email, credit card validation remote database access or web
browsing will send more data downlink than uplink. However, there may be also applications, for
example telemetry, where the uplink could be the bottleneck.
BCF capacity constraints

There are 2 main constraints to take into account to calculate the maximum capacity of the BCF for the
GPRS:
• Air link throughput

• CPU load due to combined traffic
Air Link Throughput
Subscriber Traffic Model

The total amount of data to be transmitted comprises the actual user data plus the signalling overhead.
The signalling overhead depends strongly on how the GPRS users will be using the network. This
overhead consists of additional airlink blocks carrying data originated by session and mobility
management and signalling data for the handling of the user data transmission (RLC/MAC acks, TBF
setup/teardown). The latter part is dependent on how many packets are transmitted per transaction,
the packet size and the time between the arrival of the packets. In order to account for this signalling
overhead in an accuracy, which is appropriate for sizing purposes, we distinguish between 3 different
generic user types.
• Type 1: Corporate Sector

• Type 2: Consumer Sector
• Type 3: Specialist Sector
The signalling overhead is incorporated into the capacity calculation by overhead factors. Depending
on the application the actual amount of data per user in kbyte has to be multiplied by the corresponding
overhead factor. Calculations have shown that there are two main categories of traffic that are
characterised by different overhead factors.
• Bulk data transfer: A number of applications may receive heavy volumes of application data
using IP packets carrying fairly large TCP data segments (536 bytes). This traffic profile is typical
of FTP file transfers and the downlink traffic generated by mobile subscribers browsing the web.
• Bursty data traffic: A few small application messages are sent during these transactions.
Typical applications that fall into this category are email, remote access to databases, telemetry
applications and credit card validation.
For every subscriber type the amount of uplink and downlink data per user for both categories have to
be specified. This data should contain already the TCP headers (40 bytes for the header per TCP
packet) and also take SNDCP compression into account if this is required (40 byte TCP header gets
compressed down to 3 bytes).
Furthermore the assumed GMM and SM signalling behaviour of every user type - the number of
attaches/detaches, PDP context activations/deactivations and routing area updates - has to be
specified.

Percentage of total GPRS %

customers
Average Data per Subscriber – Uplink

bulk data transfer (WWW, FTP) kbytes / BH
bursty traffic (email, WAP) kbytes / BH
Average Data per Subscriber – Downlink
bulk data transfer (WWW, FTP) kbytes / BH
bursty traffic (email, WAP) kbytes / BH
Table 22: Framework for user traffic behaviour in the GPRS airlink dimensioning
GPRS Attaches per Subscriber num/sub/BH

GPRS Detaches per Subscriber num/sub/BH
Routing Area Updates per User (RAup_user) num/sub/BH
Periodic Routing Area Updates per User (PRAup_user) num/sub/BH
Table 23: GMM and SM Signalling:
Signalling Overhead
Overhead factors will be used to account for the overhead due to LLC and RLC/MAC headers and
additional RLC/MAC blocks for the TBF handling (establishments, tear-downs, polling,
acknowledgements).
The overhead factors for the different transaction types have been calculated for the uplink and
downlink direction separately by the following formula.
Overhead factor = total number of RLC/MAC blocks carried per transaction * amount of data per
RLC/MAC block/total amount of carried user data per transaction.
The following average overhead factors for the uplink and downlink direction should be used to
calculate the actual amount of data to be transmitted per user excluding the GMM and SM signaling
data.
Bursty Bulk Data Transfer Telemetry
Traffic
Overhead Factor 1,5 1,15 2,50
Downlink
Overhead Factor Uplink 2,5 1,25 2,00
Table 24: Overhead Factors

For the GMM and SM signalling procedure the following data overhead should be taken into account:
Downlink:
Procedure Total # RLC/MAC Data per procedure
blocks [byte]
GPRS attach 16 400
GPRS detach 9 225
PDP context activation 18 450
PDP context 4 100
deactivation
Routing area update 15 375
Table 25: Downlink
Uplink:
Procedure Total # RLC/MAC Data per procedure
blocks [byte]
GPRS attach 21 525
GPRS detach 12 300
PDP context 5 125
deactivation
Table 26: Uplink
Coding Scheme Usage

The selection of the coding schemes depends on the signal quality at the receiver. The current
networks are designed for circuit switched voice transmission. With the introduction of GPRS more
interference will occur and therefore it is expected that CS 1 will often be selected.
For well designed networks it can be assumed that CS1 and CS2 are used both for 50% of time.
The assumptions for the percentage of time a coding scheme is used have to be entered as an input
parameter in the airlink dimensioning.
The following amount of user data (LLC frames or parts of LLC frames) can be carried per RLC/MAC
block depending on the coding scheme:
CS1 - 20 byte CS2 - 30 byte
Calculation
GPRS channel availability
In a system with shared resources for GPRS and circuit-switched traffic not all the dual service
channels will always be available for packet-switched use when requested.

This section describes how to calculate the average amount of channels available for GPRS in a cell
for a system with only shared resources for packet switched use.
Parameter Meaning
T average channel holding time
a offered CS call load per cell in Erlang
λ CS call arrival rate
c total number of timeslots per cell
CS call termination rate
m number of dual service timeslots per cell
n average number of channels available for GPRS
P[i] probability that i timeslots are occupied by CS
calls
Table 27: Overview of Parameters
We assume that the length of time a channel is occupied by a CS call is generally distributed with the
mean T. The term a=λ*T denotes the average offered CS call load per cell in Erlangs. Circuit-switched
calls arrive to a cell in accordance with a Poisson process with rate λ. Let c be the total number of
timeslots in the cell and m the number of dual service channels. Let P[i] denote the probability that i
timeslots are occupied by voice calls. P[i] is given by the well known expression:
(λ / µ ) i
P[i] = c i! j 5-1
(λ / µ )
∑j= 0 j!
Then the average amount of channels available for GPRS in a cell, n, could be calculated by the
following formula
c
n = ∑ P[c − i ]∗ min[m, i] 5-2
i =0
In order to achieve a good delay performance and to avoid a high variance in the packet delay times it
should not be calculated with the full number of dual service channels (m) since sometimes those will
be occupied by circuit-switched voice calls when a packet data channel is needed. If a high variation in
the packet delay time is not acceptable for the considered applications the number of assumed PDCH
should be only 1 and therefore the following formula should be used to calculate the average amount
of available GPRS channels in a cell.
c
n = ∑ P[c − i]∗ min[1, i] 5-3
i =0
Therefore in a system where higher demands in GPRS data transfer are expected 'PS only' channels
should be provided in order to avoid the delay of packet data due to CS channel usage and to
guarantee certain delay time requirements.
A further aspect to be considered here is that there are at maximum only 93 parallel PDCHs currently
available in the BCF for R 3.0. Thus the average amount of channels available for GPRS per BCF can
be at maximum 93. Since all the 93 channels may be allocated to a specific cell but some of them not
fully loaded when a request to allocate a further PDCH arrives the maximum number of PDCH to be
calculated with for sizing purposes for R3.0 should be less than 93. In this case the spare capacity of
the allocated channels can not be used in the other cells. Further investigation is needed how much
spare capacity is wasted. For the time being we assume that a calculation with 80 PDCHs should give
enough margin.

Airlink data capacity per BCF
Variable Meaning
D total amount of data that can be transmitted during the busy
hour
BRLC/MAC total available number of RLC/MAC blocks per hour per BCF
dRLC/MAC average data per RLC/MAC block [byte]
maximum PDCH utilisation
tRLC/MAC duration of a RLC/MAC block
CS fraction of a specific coding scheme is used
n average amount of channels available for GPRS in the cell
Table 28: Variables

The total amount of data that can be transmitted during the busy hour per BCF [byte] can be calculated
by multiplying the total available number of RLC/MAC blocks per hour per BCF by the average amount
of data per RLC/MAC blocks [byte].
D = B RLC / MAC * d RLC / MAC 5-4
The total available number of RLC/MAC blocks per hour per BCF is given by the maximum PDCH
utilisation times the total number of channels available for GPRS in the BSS divided by the duration of
a RLC/MAC block. The total number of GPRS channels is the sum over all cells of the average
number of channels available for GPRS in every single cell. The maximum number of available PDCH
per BSS that should be calculated with is 80.
B RLC / MAC = η * min(80, ∑ n) / t

all _ cells
RLC / MAC 5-5
The average amount of data per RLC/MAC block in bytes, is given by the fraction of time CS1 is used,
multiplied by the amount of data per RLC/MAC block for CS1 (20 bytes) plus the fraction of time CS2 is
used, multiplied by the amount of data per RLC/MAC block for CS2.
d RLC / MAC = ν CS1 * 20 + ν CS 2 * 30 5-6

Total average amount of data per user
Variable Meaning
d_ul total average amount of uplink data per user
user fraction of users of a specific type
d_bulk_uluser amount of uplink bulk data per user
d_bursty_uluser amount of bursty uplink data per user
ovbulk_ul overhead factor for uplink bulk data transfer
ovbursty_ul overhead factor for bursty uplink data transfer
d_ulGMM/SM amount of uplink signaling data for GMM and SM signaling
d_dl total average amount of downlink data per user
d_bulk_dluser amount of downlink bulk data per user
d_bursty_dluser amount of bursty downlink data per user
ovbulk_dl overhead factor for downlink bulk data transfer
ovbursty_dl overhead factor for bursty downlink data transfer
d_dlGMM/SM amount of downlink signaling data for GMM and SM signaling
d_ulGMM/SM_proc amount of uplink signaling data for a certain GMM or SM signaling
procedure
d_dlGMM/SM_proc amount of downlink signaling data for a certain GMM or SM signaling
procedure
pGMM/SM_proc number of GMM or SM signaling procedures of a certain type per user
RAup_user Routing Area Updates per user
PRAup_user Periodic Routing Area Updates per user
Table 29: Average Amount of Data Per User
To calculate the total average amount of uplink data per user we have to sum over all user types the
average amount of uplink data of every single user type weighted by the fraction of users that are of
this type. The average amount of uplink data per user is given by the specified amount of uplink bulk
data multiplied by the overhead factor for the uplink bulk data transfer plus the amount of bursty uplink
data multiplied by the corresponding overhead factor. Additionally the amount of uplink signalling data
per user for GMM and SM signaling has to be added. In the same way this has to be done for the total
average amount of downlink data per user.
d _ ul = ∑ (ν user
all _ user _ types
* (d _ bulk _ ul user * ov bulk _ ul + d _ bursty _ ul user * ov bursty _ ul )) + d _ ul GMM / SM
5-7
d _ dl = ∑ (ν user
all _ user _ types
* (d _ bulk _ dl user * ov bulk _ dl + d _ bursty _ dl user * ov bursty _ dl )) + d _ dl GMM / SM
5-8
The total amount of uplink and downlink GMM and SM signaling data per user is equal to the sum of
the amount of data for all single GMM and SM signaling procedures. The total amount of data for a
specific signalling procedure is given by the amount of data per procedure multiplied by the number of
GMM/SM procedures per user
d _ ul GMM / SM = ∑ (d _ ul GMM / SM _ proc

all _ GMM / SM _ procedures
* p GMM / SM _ proc ) 5-9
= [( PGMM / SM _ attach * (525 + 500)) + ( PGMM / SM _ det ach * (300 + 125))] + ( PGMM / SM _ routing * 475)
Note: PGMM / SM _ routing = ∑ vuser * ( RAup _ user + PRAup _ user )
Note: All values have been taken from Table 26: Uplink.

d _ dl GMM / SM = ∑ (d _ dl GMM / SM _ proc

* p GMM / SM _ proc ) 5-10
Note: All values have been taken from Table 25: Downlink
The number of GMM/SM procedures per user can be calculated by summing up the number of
procedures per user of a type over all user types weighted by the fraction of users of this type.
This has to be done for all the different GMM and SM procedures.
p GMM / SM _ proc = ∑ (ν user
all _ user _ types
* p GMM / SM _ user _ proc ) 5-11
Total number of users per BCFair = Total amount of data that can be transmitted during the busy hour/
MAX (Total average amount of up-link data per user; Total average amount of down-link data per user)
The sequence of the steps would be:

1 dRLC / MAC = ν CS1 * 20 + ν CS 2 * 30
2. BRLC / MAC = η * min(80, ∑ n) / t

all _ cells
RLC / MAC blocks / hour
D = BRLC / MAC * d RLC / MAC

3 kbyte/h
pGMM / SM _ attach = ∑ (ν user

all _ user _ types
* p GMM / SM _ user _ attach ) =
4
= pGMM / SM _ det ach
5 PGMM / SM _ routing = ∑ vuser * ( RAup _ user + PRAup _ user )
6 d _ ul GMM / SM = ∑ (d _ ul GMM / SM _ proc

* p GMM / SM )
7 d _ dlGMM / SM = ∑ (d _ dl GMM / SM _ proc

* p GMM / SM _ proc )
8 d _ ul = ∑ (ν user
all _ user _ types
* ( d _ bulk _ ul user * ov bulk _ ul + d _ bursty _ ul user * ov bursty _ ul )) + d _ ul GMM / SM kbyte per
user per BH
9 d _ dl = ∑ (ν user
all _ user _ types
* (d _ bulk _ dluser * ov bulk _ dl + d _ bursty _ dluser * ov bursty _ dl )) + d _ dl GMM / SM kbyte per
user per BH
10 Total number of users per BCFair = D / max(d_ul, d_dl)
11 # BCFair = Total number of users/(# of users per BCF)air

Calculation Example
Corporate Sector
1 Downlink Bulk Data Transfer transaction per user

30 Lightweight Client –Server transactions per user
Percentage of total GPRS customers 30%
Average Data per Subscriber - Uplink

bulk data transfer (WWW, FTP) - Kbytes / BH
bursty traffic (email, WAP) 3.8 Kbytes / BH
Average Data per Subscriber - Downlink
bulk data transfer (WWW, FTP) 11.3 Kbytes / BH
GMM and SM signalling:
GPRS Attaches per Subscriber 0.8 num/sub/BH

GPRS Detaches per Subscriber 0.8 num/sub/BH
Routing Area Updates per Subscriber 3 num/sub/BH
Periodic Routing Area Updates per Subscriber 0.4 num/sub/BH
Consumer Sector
0.3 Downlink Bulk Data Transfer Transaction per user

35 Lightweight Client-Server transaction per user
Percentage of total GPRS customer 50%

bulk data transfer (WWW, FTP) - Kbytes / BH
bulk data transfer (WWW, FTP) 3.4 Kbytes / BH
GMM and SM signalling:
GPRS Attaches per Subscriber 0.6 num/sub/BH

GPRS Detaches per Subscriber 0.6 num/sub/BH
Routing Area Updates per Subscriber 1 num/sub/BH
Periodic Routing Area Updates per Subscriber 0.1 num/sub/BH

Specialist Sector
8 Telemetry Transactions per user
Percentage of total GPRS customers 20%

Telemetry Applications 4 Kbytes / BH
Telemetry Applications 1.5 Kbytes / BH
GPRS Attaches per Subscriber 4 num/sub/BH

GPRS Detaches per Subscriber 4 num/sub/BH
Routing Area Updates per Subscriber - num/sub/BH
Periodic Routing Area Updates per Subscriber - num/sub/BH
System Parameters:
Number of available PDCHs 80
Maximum PDCH utilisation 60%
Percentage of time CS1 is used 50%

Percentage of time CS2 is used 50%
1 d RLC / MAC = ν CS1 * 20 + ν CS 2 * 30 = 0.5 * 20 + 0.5 * 30 = 25 byte
2 BRLC/MAC = (0.6 * 80 / 0.02) * 3600 = 8640000 blocks / hour
3 D = 8640000 * 25 / 1024 = 210937 Kb/H
4 PGMM / SM_attach = (0.8 * 0.3) + (0.6 * 0.5) + (4*0.2)= 1.34 = PGMM / SM_detach
5 PGMM/SM_routing = 0.3* (3+0.4) + 0.5 (1+0.1)+0.2(0) = 1.57
6 d_ul GMM / SM = 1.34 * 1025 + 1.34 * 425 + 1.57 * 475= 2688.75 bytes/ Hour
7 d_dl GMM / SM = 1.34 * 850 + 1.34 * 325 + 1.57 * 375 = 2163.25bytes/ Hour
8 d_ul = 0.3 * (0 * 1.25 + 3.8 * 2.5) + 0.5 * (0 * 1.25 + 4.4 * 2.5) + 0.2 * (4 * 2) + 2688.75/1024 =
12.57 kb/H
9 d_dl = 0.3 *(11.3 * 1.15+ 15 * 1.5) +0.5 * (3.4 * 1.15 +17.5 * 1.5) + 0.2 * (1.5 * 2.5) + 2163.25/ 1024
= 28.59 kb/H
10 Total number of users per BCFair = 7377
CPU performance point of view

As GPRS is introduced in the network there is an impact on the CPU load on the BCF, so we need to
calculate the number of BCFs required for the network with mixed traffic from this aspect as well. So
for this approach we use the same traffic model and the following mentioned calculations have to be
used.

CPU Load per GPRS User

Input
• GPRS user traffic behavior (frame work) as in the previous section (Airlink throughput)
• ratio of GPRS users to CS users
Assumptions
• No PDCH establishment/release is considered since it is assumed that the time a PDCH will be
allocated in a cell should be much longer than the duration of a TBF and therefore messaging
load due to this will be negligible
• A new TBF has to be established for every LLC frame to be transmitted
• Application models as specified in the proposal for a Lucent GPRS traffic model
CPU load generated for CCF on CEWS
Number of TBFs per GMM/SM procedure

Assumption - GPRS attach and Routing area update include TMSI reallocation, authentication and
ciphering
Number of UL TBF Number of DL TBF

TBF_ulGMM/SM_proc TBF_dlGMM/SM_proc
GPRS Attach 6 5
GPRS detach 3 3
PDP context deactivation 1 1
Routing Area Update 8 7
Paging 1 -
Table 30: Number of TBFs Per GMM/SM Procedure
Number of TBFs per application

Total amount of Average Number of Number of DL
data (UL+DL) packet size UL TBF TBF
including LLC- (LLC frame TBF_ulappl TBF_dlappl
Overhead size)
[byte] [byte]
bulk data transfer 12600 (d_bulk) 315 20 20
bursty traffic (corresponds 748 (d_bursty) 180 2 2
to lightweight client-server
transaction)
telemetry 721 (d_telem) 240 1 2
Table 31: Number of TBFs Per Application

1. Calculate number of uplink and downlink TBFs per GPRS user
TBFs for GMM/SM signaling
TBF _ ul GMM / SM = ∑ (TBF _ ul

GMM / SM _ proc * p GMM / SM _ proc )
TBF _ dl GMM / SM = ∑ (TBF _ dl

GMM / SM _ proc * p GMM / SM _ proc )
p GMM / SM _ proc = ∑ (ν user

all _ user _ types
* p GMM / SM _ user _ proc ) ,
where pGMM/SM_proc denotes the average number of GMM or SM signalling procedures per user
(pGMM/SM_user_proc is given by the traffic model).
TBFs for data transfer
TBF _ ul = ∑ (ν user
all _ user _ types
* (d _ bulk user / d _ bulk * TBF _ ulbulk + d _ bursty user / d _ bursty * TBF _ ulbursty +
+ d _ telemuser / d _ telem * TBF _ ulTelem )) + TBF _ ulGMM / SM
TBF _ dl = ∑ (ν user
all _ user _ types
* (d _ bulk user / d _ bulk * TBF _ dl bulk + d _ bursty user / d _ bursty * TBF _ dl bursty +
+ d _ telem user / d _ telem * TBF _ dl Telem )) + TBF _ dl GMM / SM
where d_bulkuser= d_bulk_uluser + d_bulk_dluser, d_burstyuser= d_bursty_uluser + d_bursty_dluser and

d_telemuser= d_telem_uluser + d_telem_dluser
For the calculation of the number of transactions of each application type the amount of uplink and
downlink data has to be added since it will be later divided also be the total amount of data per
transaction. The model assumes a fixed number of uplink and downlink TBFs for every transaction.
The fractions of the different user types and the amount of data for every application for a particular
user type are given by the GPRS subscriber traffic model input.
2. Calculate the number of messages to be handled by the CCF
Total number of paging messages

Number of Paging messages = average number of pagings per user * average number of cells per
routing area* paging index * paging repetition factor
(Note that the average number of cells per routing area includes only those cells that also belong
to the BCF-area)
All the above values would be part of the traffic model.

Total Number of messages per user to be handled by the CCF for GPRS
M1 = TBF_ul * 4 + TBF_dl * 2
M2 = 2 * number of paging messages
(An uplink TBF generates 4 messages to be imported or exported on the CEWS whereas a
downlink TBF requires only 2 messages. A paging message has to be imported and exported
therefore the factor of 2 is applied here)
3. Calculate CPU load per user for GPRS CCF on CEWS
GPRS CPU load per user per CEWS = (M1 * 0,001 * 100%/Number of CEWS ) + M2 * 0.001
*100%
(The measured CPU load in BCF R2.0 for importing or exporting a message is 1ms, i.e. 0.1%)

CPU load generated for processing of data packets on GWS

1. Calculate total GPRS data throughput per user
The Maximum Throughput calculations should include the amount of LLC/SM/MM signalling data
added to the amount of user data since the BCF maximum throughput capacity has been measured for
the LLC layer.
User Data per subscriber (including LLC-Overhead), denoted by d LLC :

 d_bulk_ul user + d_bursty_ul user + d_telem_ul user + 
d LLC = ∑   ⋅ν user
 + d_bulk_dl user + d_bursty_dl user + d_telem_dl user 
user
Signalling per user, denoted by d GMM / SM :

d GMM / SM = d _ ul GMM / SM + d _ dl GMM / SM
d _ ul GMM / SM = ∑ (d _ ul GMM / SM _ proc

Note: All the values have been taken from Table 32 mentioned below.
Note: PGMM / SM _ routing = ∑ vuser * ( RAup _ user + PRAup _ user )
(RAup_user and PRAup_user are explained in Table 11)
d _ dl GMM / SM = ∑ (d _ dl GMM / SM _ proc

Note: All the values have been taken from Table 32 mentioned below.
(The number of GMM or SM signaling procedures per user is given by the traffic model input)
Procedure Total downlink data per Total uplink data per signalling
signalling procedure procedure [byte]
[byte] d_ulGMM/SM_proc
d_dlGMM/SM_proc
GPRS attach 206 274
GPRS detach 91 110
PDP context 33 47
deactivation
Table 32: The number of GMM or SM Signaling Procedures Per User

Data Rate per user:
Tuser = (d LLC + d GMM / SM ) kbps
2. GPRS CPU load per user on GWS = Tuser * 0.15 %

BCF Maximum Capacity Calculation
CPU Base Load COWS - 22% Maximum desired CPU load on COWS - 80%
CPU Base Load CEWS - 20% Maximum desired CPU load on CEWS - 90%
CPU Base Load GWS - 20% Maximum desired CPU load on GWS - 80%
Total CPU load per user on COWS = CS CPU load per user on COWS
The total CS CPU load per user on the COWS should be calculated as described in the previous
section (BCF capacity based on traffic model for CS) of this document.
Total CPU load per user per CEWS = CS CPU load per user on CEWS * fraction of users that are CS
users + GPRS CPU load per user per CEWS * fraction of users that are GPRS users
The total CS CPU load per user on the CEWS should be calculated as described in the previous
section (BCF capacity based on traffic model for CS) of this document and the total GPRS CPU load
per user on the CEWS as described above.
Total CPU load per user on GWS = GPRS CPU load per user on GWS
Total Number of Users per BCF:
Max. number of users on COWS =

= ((80%-22%) / Total CPU load per user on COWS) / Fraction of users that are CS users
Max. number of users per CEWS = (90%-20%) / Total CPU load per user on CEWS
Max. number of users on GWS =

= ((80%-20%) / Total CPU load per user on GWS) / Fraction of users that are GPRS users
Total number of users per BCF =

= MIN (Max. number of users on COWS, Max. number of users per CEWS,
Max. number of users on GWS)
Calculation Example
Using the same traffic model as mentioned in the previous example, we get the following values.
CPU Load generated for CCF on CEWS
TBF for GMM/SM signalling

Using values from Table 30
TBF_ul(GMM/SM)=1.34*(6+2) + 1.34*(3+1)+1.57*8
=10.72+5.36+12.56
= 28.64 TBF/BH
1.34 is the value for P(GMM/SM)attach/detach

1.57 is the value for P(GMM/SM) routing
These values are shown in this document in the Airlink calculations example.
TBF_dl(GMM/SM)=1.34*(5+2)+1.34(3+1)+1.57*7
= 9.38+5.36+10.99
= 25.73 TBF/BH
TBF_ul = 0.3((11571.2/12600)*20 + (19251.2/748)*2)
+ 0.5 ((3481.6/12600) * 20 +(22425.6/748)*2)

+0.2((5632/721)*1)+TBF_ul(GMM/SM)
= 0.3((.918*20) +(25.73*2)) +0.5((0.276*20) +(29.98*2))

+0.2(7.81*1)+TBF_ul(GMM/SM)
= 0.3(18.36+51.46)+0.5(5.52+59.96)+0.2(7.81)+TBF_ul(GMM/SM)
= 0.3(69.82) +0.5(65.48) +0.2(7.81)+TBF_ul(GMM/SM)
= 20.946+32.74+1.562+TBF_ul(GMM/SM)
= 55.25 +TBF_ul(GMM/SM)
= 55.25 +28.64
= 83.89 TBF/BH
=0.0233027 TBF/Second
TBF_dl =0.3 (69.82) +0.5(64.48) +0.2 (2*7.81) + TBF_dl(GMM/SM)

= 20.946 +32.24+3.124+TBF_dl(GMM/SM)
= 56.81 + 25.73
= 82.54 TBF/BH
= 0.0229277 TBF/Second
Calculate the number of messages to be handled by the CCF

The values taken for the pagings per user, number of cells per routing area,
paging index, paging repetition factor are examples and the exact values
should be taken from the given traffic model
Number of Pagings per user per BH =
0.3 – Corporate User

0.1 – Consumer User
8 – Specialist User
Average number of pagings per user = 0.3 * fraction of Corporate user + 0.1*
fraction of Consumer user+ 8 * fraction of Specialist
= 0.3*0.3 + 0.1*0.5 + 8*0.2 = 1.74
Paging index = 1.5

Paging repetition factor = 1.6
Av. number of cells per routing area = 50
Number of paging messages per user per BH = 1.74*50*1.5*1.6 = 208.8
Number of paging messages per user per second = 0.058
M1= 0.0233027*4 + 0.0229277*2

M1= 0.0932108 + 0.0458554 M1 = 0.1390819 messages/second
M2= 2 * 0.058
M2 = 0.116
GPRS CPU load per user per CEWS = (M1*0.001*100/number of CEWS )+ M2

0.001* 100%
(Assuming Number of CEWS = 4)
= (0.1390819* 0.001*100/4) + 0.116 *0.001
=0.003477 + 0.000116= 0.003593%
CPU load generated for processing of data packets on GWSCalculate total GPRS
data throughput per user
dLLC = 0.3*(11.3+15+0+3.8)+ 0.5(3.4+17.5+0+4.4) + 0.2(1.5+4)

= 22.78 Kb/H
=23326.72 b/H

PGMM/SM_routing = 0.3* (3+0.4) + 0.5 (1+0.1)+0.2(0)

= 1.57
d_ulGMM/SM = [(1.34*(274+328))+ (1.34*(110+47))] + (1.57*272)

= 1444.1 b/H
d_dlGMM/SM = [(1.34*(206+337))+ (1.34*(91+33))] + (1.57*214)

= 1229.7 b/H
d GMM/SM= d_ulGMM/SM + d_dlGMM/SM

= 1444 + 1229.7 = 2673.86 b/H
Data Rate per user:
Tuser = (dLLC + dGMM/SM) Kbps

= 23326.72 + 2673.86
= 26000.58 b/H
= 0.0564249 Kbps
GPRS CPU load per user on GWS = Tuser * 0.15%
= 0.0564249 * 0.15%
= 0.0084637%
Total CPU load per user on COWS = CS CPU load per user on COWS
= 0.001248744(From the BCF capacity for
CS section)
Assuming CS users to be 90% and GPRS users to be 10%

CS CPU load per user on CEWS = .0017175605(From the BCF capacity for CS section)
Total CPU load per user per CEWS = CS CPU load per user per CEWS * fraction of users
that are CS users + GPRS CPU load per user per CEWS * fraction of users that are GPRS
users
= 0.0017175605*0.9 + 0.003593 *0 .1
= 0.00154580445 + 0.0003593
= 0.0019051094%
Total CPU load per user on GWS = GPRS CPU load per user on GWS = 0.0084637%
Max. Number of users on COWS

= ((80%-22%) / Total CPU load per user on COWS)/ Fraction of users that are CS
users
= 58/0.001248744/0.9
= 51607

Max. No. of users per CEWS=

= (90% -20%) / Total CPU load per user on CEWS
= 70/ 0.0019051094= 36743
Max. No. of users on GWS

= ((80% - 20%) / Total CPU load per user on GWS)/Fraction of users that are
GPRS users
= 60/0.0084637/0.1
= 70890
Total number of users per BCFperf = Min( Max. number of users on COWS, Max number of users per
CEWS, max. number of users on GWS)
Total Number of BCFs required (BCFperf)= Total users/Total No. of users per BCFperf
So, overall number of BCFs required: #BCF= max(BCFair ; BCFperf)
Note: The BCF capacity release plan summary document (sent via LINC) gives the maximum GPRS
Data Throughput (T) plan through the different network releases and also it provides information on the
increase in BCF capacity as per the network release. The document should be referred for BCF
capacity values for the future releases.
Coding Schemes
In GPRS different coding schemes (CS) have been defined.
Already in Rel 1.5 the coding schemes CS1 and CS2 will be available.
CS3 and CS4 are in preparation and foreseen for releases after Rel. 2.
Calculate the Number of BCFs required

The minimum number of BCFs (Min_Nb_BCF) required should be calculated from the given number of
BTSs. All calculations would be same as mentioned in Step 2 for the BCF calculations for CS traffic.
The Final number of BCFs required would be Max (#BCF;Min_Nb_BCF)
Where #BCF= Number of BCF required due to combined traffic (By comparing the BCFperf and BCFair)
Min_Nb_BCF= Minimum Number of BCFs required after taking into account the Number of BTS, cells,
TRX, PDCH.

BTS – BCF Distribution
With GPRS introduction in the network, we also need to consider the Routing area planning, in addition
to the details mentioned in the BTS-BCF distribution for CS network.
Routing Area Code Planning
Similar to the Location Area Code (LAC) planning in the CS network, a routing for the paging of GPRS
subscribers has to be planned.
For GPRS, this plan has two parts, the
- Routing Area Code (RAC) plan

- Routing Area Color Code (RACC)
A Routing Area (RA) described by RAC can be of the same area size or a sub-area of a Location Area
(LA) described by LAC, meaning that an RA cannot span more than one LA. Each Routing Area has
an RAC and an RACC.
The RAC consists of 8 bits. A RAC is only unique when presented together with the Location Area
Identifier (LAI), giving together the Routing Area Identity (RAI).
- RAI = RAC + LAI

- LAI = MCC + MNC + LAC
The RACC can be reused in the network and is 3 bits long, but adjacent Routing Areas have to have
different Routing Area Color Codes (RACC).
If the mobile detects a change of RACC a RA-update is sent out.

This document does not provide detailed information on the Routing area planning, separate
documents need to be referred to for the topic.
Calculation for all the cards
All calculations for the cards are same as that in the section for BCF planning for CS. The only change
would be for the calculations for total number of servers.
In case of GPRS, one server is dedicated for GPRS, so total number of servers will be:
Number of servers = Common server + Cell servers + GPRS server + Redundant server (if required)
The maximum limit of the BCF is the same i.e. 6 servers and the minimum recommended number of
servers for GPRS configuration is 4.

6 M-link Dimensioning
Calculating required number of M-

links
Scope
The purpose of this section is to show how to calculate the required number of M-links on a per BCF
basis.

• Output from the BCF planning/dimensioning stage
Rules
1. E1:
First M link - 29 T/S (116 TCH) plus: 1 x SS7 SDL ,1 x FAS, 1 x OMC X.25 link = 32 timeslots
Remaining M links - 30 T/S (120 TCH) plus: 1 x SS7 SDL, 1 x FAS = 32 timeslots
T1:
First M link - 22 T/S (88 TCH) plus: 1 x SS7 SDL , 1 x OMC X.25 link = 24 timeslots
Remaining M links - 23 T/S (92 TCH) plus: 1 x SS7 SDL = 24 timeslots
2. The OMC X.25 connection requires 1 x 64 Kbit timeslot.
3. A BCF should have a minimum of 2 SDLs carried on 2 M-links (1 per M-link), for redundancy.
4. The maximum number of SDLs that a BCF can support is 8.
5. Each SDL occupies 1 x 64kbit/s timeslot.

M-Link Dimensioning BSS Network Design Guide
Calculate total network traffic

To calculate the number of M-links required in a network there are 2 approaches that can be taken:
1. We can take the total number of Erlangs that are required to be supported across all the BCFs
in the system and apply this figure to Erlang B tables. This will give the total number of TCHs
needed across the M interface. We can then go on to calculate an approximate figure for the
number of M-links needed in a total system.
or
2. We can calculate the individual M-link requirements per BCF based on the individual Erlang
figures. Referring to our Erlang B tables we can ascertain individual BCF TCHs figures and
then calculate the required number of M-links per BCF.
The first method can only be used to give rough figures that may be acceptable for generating pre-
sales figures. This method does not take account the actual allocation of BCFs to STFs that would be
determined by the countries topology and network Homing Plan.
The second method would be used where BCF to STF allocations had been determined. The M-links
needed per BCF can now be accurately determined. The total required number of M-links required in
the complete network is the sum of all the individual BCF calculations.
Note: A minimum of 2 M-links should be allocated per BCF (for redundancy)
Calculate the number of M links per BCF for CS traffic

The OMC link is normally configured on the first M link on the BCF on timeslot 31. For E1 systems the
first M-link will have 29 timeslots available, supporting 116 traffic channels. The remaining M-links will
have each 30 timeslots available, supporting 120 traffic channels.
For T1 systems the first M-link on the BCF will have 22 timeslots available supporting 88 traffic
channels with one timeslot reserved for the OMC X.25 connection. The remaining M-links will have 23
timeslots available, supporting 92 traffic channels.
For the first M-link in E1 systems:
 TCHTotal 
 4  + 1 (OMC connection )
Mlink = 
Total
 ( rounded up to next int eger )
30
For subsequent E1 M-links:
MlinkTotal = TCHTotal ( rounded up to next int eger )

120
For the first M-link in T1 systems:

 TCHTotal 
 4  + 1 (OMC connection )
MlinkTotal =   ( rounded up to next int eger )
23

For subsequent T1 M-links:
MlinkTotal = TCHTotal ( rounded up to next int eger )

92
Where: MlinkTotal = The minimum required number of M-links required per BCF cabinet.
TCHTotal = The number of traffic channels to be supported per BCF (after M-link
BlockingFactor has been applied).
The above equations allow for FAS and SS7 requirements.
Note: The maximum number of SS7 SDLs that can be supported per BCF is 8, the minimum should
be 2 (for redundancy). Each M link can carry only one SS7 signalling SDL.
Impact of GPRS on M-link

dimensioning
With BSS NR 9.1 Gb interfaces between the BCF and SGSN will not be supported. Therefore GPRS
Packet Switched traffic will routed from the BCF, through the STF to the MSC/GPRS backbone via the
M and A links. Therefore, a certain amount of capacity will need to be allocated on the these links for
Packet Switched traffic. These allocated timeslots for PS data will be not be dual-service.
Calculate timeslots required for PS data

To calculate the required number of timeslots for PS data the following inputs are required:
• Number of PS subscribers.
• Data throughput per subscriber per second (Tuser [kbit/s]).
• TBF_ul and TBF_dl.
These figures for 2 and 3 will have already been calculated in the BCF planning section on pages 5-24
to 5-25. The number of subscriber for PS will be obtained from the network operator.
Total number of LLC frames per user per BH = TBF_ul + TBF_dl
For Frame Relay, Network services and BSSGP layer the following overhead needs to be taken into
account:
Bytes per LLC frame = 6+4+20 = 30 bytes
Steps
The steps detailed below can be applied across entire networks or to individual BCFs. The later will
yield more accurate results when individual BCF calculations are totalled up.
1. Calculate Gb interface throughput per user per second:

× (TBF _ ul + TBF _ dl)× 30 × 8 [kbit / s]
1
Guser = Tuser +
3600
2. Calculate the total Gb interface throughput per second:
Gtot = No. of users × Guser [kbit / s]

3. Calculate throughput per second:
Assuming a maximum Gb interface utilisation of 80%, then the required throughput is:
Greq =
1
× Gtot = 1.25 × Gtot [kbit / s]
0.8
4. Calculate required number of timeslots on M-links:
Greq
Timeslotsreq =
64
Signalling Link Dimensioning
Introduction
The outband exchange of signalling information between BSS and MSC is realised via the SS7
timeslots on the M-interface. Each of these timeslots has a capacity of 64.000 bits/s in case of the E1
PCM 30-link type. In SS7 terms these timeslots are also called SDL (Signalling DatA-link), because
they represent a dedicated signalling data-link. One or more SDLs manage the signalling for a trunk
group (TG). In case of a BSS the trunk group is defined by all traffic carrying links between BSS and
MSC (all M-links or all A-links).
The relation of traffic capacity and signalling capacity is not fixed like in case of an inband signalling
system, but depends on the characteristics of the carried traffic. Some of these are:
• Number of messages per call

• Number of trunks per trunk group
• The call holding time
• The call rate (BHCA)
The SS7 system works as a connectionless system. Like in the internet the signalling information is
transmitted via packets which can have variable length depending on their content. One group of these
message packets are called MSU (Message Signalling Units). They carry user information
(=messages).
Typical sizes for a GSM network are:
Avg. MSU size

(octets)
BSS (A- 60
link)
PSTN 80
Table 33: Typical Sizes For a GSM Network

The following formula gives the relation between SDL capacity and MSU size:
 
 SDL occupancy × SDL rate 
 MSU 
SDL Capacity =  
 s 
 average MSU size × 8 bit 
 
 octet 
The SDL occupancy is defined by the operator requirement, but should be in the range of 20%..40%
[ITU-T E.733] due to the burst nature of a connectionless signalling system.
The next step in link dimensioning is calculating the expected signalling value:
Average_MSU
BHCA ×
MSU Call Attempt
Expected =
s s
3,600
h
Typical values for the number of MSU per call attempt in GSM networks are:
Avg. #MSU per Call Attempt

BSS (A-link) 25
PSTN 10
Table 34: Typical Values For the Number of MSUs Per Call Attempt in GSM Networks
These values are an average over all signalling processes and not only for the call setup phase.
The value for the BHCA can be derived from the MSC or BSS performance measurements. It must be
calculated for the complete trunk group.
Now it is possible to calculate the required number of SDLs:
 MSU 
 Expected 
Required # SDL =  s 
 SDL capacity 
 
 
Example
Calculate the required number of SDLs for a BSS.
Where:
BHCA/BSS 25000
Capacity of SDL 64000 Kbit/s
Wanted SDL occupancy 20%
Avg. MSU size 60 octets
Avg. #MSU/call attempt 25

Calculations
Step 1: Calculate SDL Capacity:
   bit 
 SDL occupancy × SDL rate   20% × 64000 
SDL Capacity =   =  s  = 26,6 MSU
 average MSU size × 8 bit   60octet × 8 bit  s
   
 octet   octet 
Step 2: Calculate expected MSU/s:
Average MSU
BHCA ×
MSU Call Attempt 25000 × 25 MSU
Expected = = = 173,6
s s 3600 s
3,600
h
Step 3: Calculate number of required SDLs:
 MSU  MSU
 Expected 173, 6
Required # SDL =  s = s = 6,53 ⇒ 7 SDL required
 MSU
 SDL capacity  26,6
  s
The result has to be double-checked with the number of available M-links since each M-link can carry
one and only one SDL.
References
Further details can be found in document number 401-380-357, EG27: 5ESS® Mobile Switching
Centre. This is orderable from CIC in the usual way.

7 STF-2000 Cabinet
Dimensioning
Scope
The purpose of this section explains how to calculate the required number of TCU, DFU and STU
cards on a per STF basis. This section also covers Full Rate and Dual-Mode options, E1 and T1
systems, STU/1 and STU/2 cards and cabinet layout drawings.
System Dimensioning for Full Rate

configurations
Required input information:

TCH capacity to be supported on the M-links (TCHTotal).
The M-link TCH capacity and the number of M links required to support this traffic will have been
determined in the BCF and M-link dimensioning calculations and will have blocking applied. Note that
the TCH figure mentioned here is not the TCH figures to be supported on the Um interface or the
TCHs at the BTSs.
Rules:
Cabinets
• Each cabinet supports 3 TSGs.
TSGs
• Each TSG supports up to 4 M groups.
• Each TSG must have 2 TCUs (for redundancy).
• All M-links of a TSG should be connected to one BCF.

STF-2000 Cabinet Dimensioning BSS Network Design Guide
TCUs
M Groups
Each M group requires

• 1 M interface and up to 4 A interfaces (E1 and/or T1).
• 5 DFUs per 2 M groups.
• Up to 4 STUs for E1 and up to 3 STUs for T1.
• Up to 120 E1 TCHs or 92 T1 TCHs.
STUs
• One STU is required per 30 E1 TCHs or 30.667 T1 TCHs1 (averaged) (i.e. 4 STUs for 120 E1
TCHs, 3 for 92 T1 TCHs).
Steps
Calculate required number of M-links (MlinkTotal):

TCHTotal
For E1 systems : MlinkTotal = ( rounded up to next integer)
120
TCHTotal
For T1 systems : MlinkTotal = ( rounded up to next integer)
92
Where TCHTotal is the traffic channels required on the M-interface after the blocking factor has
been applied at the BCF. There is 1-M link per M-group.
Calculate number of A-links required (AlinkTotal)

TCHTotal
For E1 systems : AlinkTotal = (rounded up to next integer)
30
TCHTotal
For T1 systems : AlinkTotal = (rounded up to next integer)
23
There are up to 4 A-links per M group.
Calculate number of DFU cards required (DFUTotal):

 AlinkTotal − MlinkTotal 
DFUTotal = MlinkTotal +   ( round up to next int eger )
 2 
1
FR STU cards can support 32 TCHs per card. The TCHs are allocated 32 to the first STU and 28
TCHs to the second STU, with 4 transcoders not used. This is repeated for STUs 3 and 4. This gives
an average of 30 TCHs per STU (120/4 = 30). For T1, 3 STUs are required, again with TCH
assignments of 32, 28 and 32. This gives an average of 30.667 TCHs per STU (92/3 = 30.667).

Table 35 provides a quick reference for the maximum capacities for E1 and T1 links for 1 or 2 M
groups.
E1 T1
M group
TCH/F ccts. Qty. of DFUs Qty. of STUs TCH/F ccts. Qty. of DFUs Qty. of STUs
30 1 1 23 1 1
60 2 2 46 2 2
1
90 2 3 69 2 3
120 3 4 92 3 3
150 4 5 115 4 4
180 4 6 138 4 5
1 and 2
210 5 7 161 5 6
240 5 8 184 5 6
Table 35: STF/2 cabinet FR capacities
Calculate number of STU cards required (STUTotal):

TCHTotal
For E1 systems : STUTotal = ( round up to next int eger )
30
For T1 systems : STUTotal = TCH Total
( round up to next int eger )
30.667
Calculate the number of TSGs required (TSGTotal):
M linkTotal
TSGTotal = ( round up to next int eger )
4
Calculate the number of TCU cards required (TCUTotal):
TCUTotal = TSGTotal × 2
Calculate number of STF cabinets required (STFTotal):

TSGTotal
STFTotal = ( round up to next int eger )
3
Table 36 provides a quick summary of an STF cabinet’s maximum FR capacities.
System # TSGs M-links A-links Qty. TCUs Max. qty. DFUs Max. qty. STUs Max. TCHs
E1 2 12 48 4 30 48 1440
T1 2 12 48 4 30 36 1104
Table 36: Maximum STF/1 Cabinet FR Capacities

System Dimensioning for Dual

Mode configurations
• TCH capacity to be supported on the M-links (TCHTotal)
• % of EFR penetration required.
The M-link TCH capacity and the number of M links required to support this traffic will have been
determined in the BCF and M-link dimensioning calculations and will have blocking applied. Note that
the TCH figure mentioned here is not the TCH figures to be supported on the Um interface or the
TCHs at the BTSs.
Rules
Cabinets:
• Each cabinet supports 3 TSGs.
TSGs:
• Each TSG supports up to 4 M groups.

• All M-links of a TSG should be connected to one BCF.
TCUs:
M Groups
Each M group requires:
• 1 M interface and up to 4 A interfaces (E1 or T1).

• Either 2 or 3 DFUs2.
• Up to 4 STU-Fs for E1 and up to 3 STU-Fs for T1.
• Up to 120 E1 TCHs or 92 T1 TCHs.
DFU cards:
• One DFU card can terminate 2 E1/T1 links which can be either 1 M-link and 1 A-link, or 2 A-
links.
2
Odd numbered M groups have 3 DFUs and even numbered M groups have 2 DFUs. The first A-link interface for even
rd
numbered M groups resides on the DFU in the 3 slot of every FR TSG shelf

STU cards:3
• One STU/1 card is required per 30 E1 TCHs or 30.667 T1 TCHs (averaged)4. (i.e. 4 STU cards
for 120 E1 TCHs, 3 STU cards for 92 T1 TCHs).
• One STU/2 card provides support for 32 EFR TCHs, this is applicable for E1 or T1.
Steps
Calculate required number of M-links (MlinkTotal):

TCHTotal
For E1 systems : MlinkTotal = ( rounded up to next integer)
120
TCHTotal
For T1 systems : MlinkTotal = ( rounded up to next integer)
92
Where TCHTotal is the traffic channels required on the M-interface after the blocking factor has been
applied at the BCF. There is 1-M link per M-group.
Calculate number of A-links required (AlinkTotal)

TCHTotal
For E1 systems : AlinkTotal = (rounded up to next integer)
30
TCHTotal
For T1 systems : AlinkTotal = (rounded up to next integer)
23
There are up to 4 A-links per M group.
Calculate number of DFUs required (DFUTotal):

 AlinkTotal − MlinkTotal 
DFUTotal = MlinkTotal +   ( round up to next int eger )
 2 
Calculate the number of STU-Fs required (STU-FTotal):

For E1 systems : STU − FTotal = TCHTotal ( round up to next int eger )
30
TCHTotal
For T1 systems : STU − FTotal = ( round up to next int eger )
30.667
Calculate the number of STU-Ps required (STU-PTotal):

TCHTotal × EFR%
For E1 and T1 systems : STU − PTotal = ( round up to next int eger )
32 × 100
3
An STU card has 2 functions depending upon where it is located. An STU-F resides on shelf 0 of each TSG and processes
Full Rate traffic. STU-Ps reside in shelf 1 and form the STU pool for EFR traffic. They are the same cards, just performing
different roles. The pool shelf is populated left to right.
4
STUs located in even numbered slots support 32 TCH/F; STUs located in odd numbered slots carry 28
TCH/F. For planning purposes assume an average of 30 TCH/F per STU-F for E1 and 30.667 TCH/F per STU-F for T1.

Calculate the number of TSGs required (TSGTotal):

Mgroup Total
TSGTotal = (round up to next int eger )
4
Calculate the number of TCU cards required(TCUTotal):
TCUTotal = TSGTotal × 2
Calculate number of STF cabinets required (STFTotal):

TSGTotal
STFTotal = ( round up to next int eger )
3
Table 37 provides a quick summary of an STF/2 cabinet’s DM capacities.
# TSGs Max. M-links Max. A-links Qty. TCUs Max. DFUs Max. STU-Fs Max. STU-Ps Max. TCHs (100% EFR)
E1 3 6 24 6 15 24 24 720
T1 3 6 24 6 15 18 18 576
Table 37: Maximum STF/2 DM Cabinet Capacities
Impact of GPRS on the STF

• On the M- and A-links, dedicated GPRS time slots (TS) have to be configured to support the CS
traffic.
• Although the GPRS TSs are switched transparently though, the GPRS call is routed through the
transcoder and FR STU cards, using FR transcoder channel capacity
• Gb connections between the STFs and the SGSNs are not currently supported in Rel 1.
• With NR 9.x the Gb interface is connected via embedded ("nailed-up") 64kbit/sec connections
within M-link and A-link to the MSC. The STF is transparent to this data. Between MSC and
SGSN you establish dedicated E1 lines for implementing the Gb interface. So, you concentrate
the GPRS traffic coming from different BCFs within the MSC.
• With NR10.0 we will be able to have dedicated Gb connections (E1 lines) between BCF and
MSC.
• In the case of dual mode (e.g. FR/EFR) configuration, no additional FR STUs are needed. The
STU pool is not affected by GPRS.
Further Information
Further details can be found in document number 401-380-351, STF-2000 Engineering Guideline. This
is orderable from CIC in the usual way.

STF Configurations for E1 systems
STF 2.0 STF 2.0 STF 2.0
T DDDSSS S S S S S DD T DDDSSS S S S S S DD T DDDSSS S S S S SDD

CF F F T T T T T T T T F F CF F F T T T T T T T T F F TSG0 C F F F T T T T T T T T F F TSG0
UUUUUUU U U U U U UU UUUUUUU U U U U U UU UUUUUUU U U U U UUU
TSG0
/ / / / / / / / / / / / / / / / / / / / / / / /
50% 100%
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
480 EFR EFR
T DDDSSS S S S S S DD T SSSSSS S S S S S S S SS T SSSSSS S S
TCH
CF F F T T T T T T T T F F CT T T T T T T T T T T T T T T CT T T T T T T T
240 240
UUUUUUU U U U U U UU UUUUUUU U U U U U U U UU UUUUUUU U U
/ / / / / / / / / / / / / / / / / / / / / / / TCH / / / / / / / / TCH
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2
TSG1
/ / / / / / / / / / / / / / / / 25% / / / / / / / / 50%
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 EFR 1 1 1 1 1 1 1 1 EFR
480
T DDDSSS S S S S S DD T SSSSSS S S T SSSS
TCH
CF F F T T T T T T T T F F CT T T T T T T T 240 CT T T T 240
UUUUUUU U U U U U UU UUUUUUU U U TCH U U U U U TCH
/ / / / / / / / / / / / / / / / / / / /
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2
/ / / / / / / / TSG2 / / / / / / / / / / / / / / / /
0% 0%
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
EFR EFR
T DDDSSS S S S S S D D 480 T T
CF F F T T T T T T T T F F TCH C C
240 240
UUUUUUU U U U U U UU U U
/ / / / / / / / TCH TCH
1 1 1 1 1 1 1 1
Figure 3: STF/2 Full Rate Figure 4: STF/2 Dual-Mode Figure 5: STF/2 Dual-Mode
Maximum capacities: Maximum capacities: Maximum capacities:
6 TCUs 6 TCUs 6 TCUs

30 DFUs 15 DFUs 15 DFUs
48 STUs 69 STUs (24 STU-F, 45 STU-P) 48 STUs (24 STU-F, 24 STU-P)
3 TSGs 3 TSGs 3 TSGs
12 M groups (12 M-links) 6 M groups (6 M-links) 6 M groups (6 M-links)
48 A-links 24 A-links 24 A-links
1440 TCHs * 720 TCHs * 720 TCHs *
Max EFR penetration = 50% Max EFR penetration = 100%
*Note: The above maximum TCH figures do not allow for an OMC connection. The OMC X.25 O&M
connection to the BCF is normally made via T/S 31 on its first M-link, which means that this T/S is not
available for speech/data traffic. Therefore these figures should be reduced by 4 for each OMC
connection.
Key:
T S S D S
Speech Speech Speech
C T T F T
Transcoding Unit Transcoding Unit Digital Facilities Transcoding Unit
U Traffic control Unit U U U U
used as a FR used as a AMR Unit used as an EFR
codec codec codec

STF Configurations for T1 systems
STF 2.0 STF 2.0 STF 2.0
T DDDSSS S S S DD T DDDSSS S S S S S DD T DDDSSS S S S DD

CF F F T T T T T T F F CF F F T T T T T T T T F F TSG0 C F F F T T T T T T F F TSG0
UUUUUUU U U U UU UUUUUUU U U U U U UU UUUUUUU U U U UU
TSG0
/ / / / / / / / / / / / / / / / / / / /
50% 100%
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
384 EFR EFR
T DDDSSS S S S DD T SSSSSS S S S S S S S SS T SSSSSS
TCH
CF F F T T T T T T F F CT T T T T T T T T T T T T T T CT T T T T T
192 192
UUUUUUU U U U UU UUUUUUU U U U U U U U UU UUUUUUU
/ / / / / / / / / / / / / / / / / / / / / TCH / / / / / / TCH
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2
TSG1
/ / / / / / / / / / / / / / 25% / / / / / / 50%
1 1 1 1 1 1 1 1 1 1 1 1 1 1 EFR 1 1 1 1 1 1 EFR
384
T DDDSSS S S S DD T SSSSSS S S T SSS
TCH
CF F F T T T T T T F F CT T T T T T T T 192 CT T T 192
UUUUUUU U U U UU UUUUUUU U U TCH U U U U TCH
/ / / / / / / / / / / / / / / / /
1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2
/ / / / / / TSG2 / / / / / / / / / / / / / /
0% 0%
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
EFR EFR
T DDDSSS S S S D D 384 T T
CF F F T T T T T T F F TCH C C
192 192
UUUUUUU U U U UU U U
/ / / / / / TCH TCH
1 1 1 1 1 1
Figure 6: STF/2 Full Rate Figure 7: STF/2 Dual-Mode Figure 8: STF/2 Dual-Mode
Maximum capacities: Maximum capacities: Maximum capacities:
6 TCUs 6 TCUs 6 TCUs

30 DFUs 15 DFUs 15 DFUs
36 STUs 63 STUs (18 STU-F, 45 STU-P) 36 STUs (18 STU-F, 18 STU-P)
3 TSGs 3 TSGs 3 TSGs
12 M groups (12 M-links) 6 M groups (6 M-links) 6 M groups (6 M-links)
48 A-links 24 A-links 24 A-links
1104 TCHs * 552 TCHs * 552 TCHs *
Max EFR penetration = 65% Max EFR penetration = 100%
*Note: The above maximum TCH figures do not allow for an OMC connection. The OMC X.25 O&M
connection to the BCF is normally made via T/S 31 on its first M-link, which means that this T/S is not
available for speech/data traffic. Therefore these figures should be reduced by 4 for each OMC
connection.

8 A-link Dimensioning
Scope
This section describes the steps required to calculate the minimum number of A-links required per STF
for a given TCH load on the M-links and STF.
Required Input information

• Number of M-links per STF cabinet
• Number of TCHs on each M-link
Rules
E1: Each E1 link contains 32 x 64kbit/s timeslots (2.048Mbit/sec). These timeslots are organised as:
• 1 timeslot (TS 0) for synchronisation (FAS)

• 1 timeslot (TS 16) for SS7 signalling
• 30 timeslots for traffic
T1: Each T1 link contains 24 x 64kbit/sec timeslots (1.536Mbit/sec). When additional framing bits are
added the bit rate becomes 1.544Mbit/sec. These timeslots are organised as:
• 1 timeslot (TS 16) for SS7 signalling
• 23 timeslots for traffic
Maximum of 4 A-links required per M-link.

A-Link Dimensioning BSS Network Design Guide
Steps
The precise number of A-links needed per STF cabinet will depend upon the number of M links per
STF cabinet and the Traffic Channels on each of these M-links.
Depending upon how the network has been designed and allowing for future system growth, an A-link
(or M-link) may not be used to its maximum capacity. This may then require more links than the
theoretical minimum required. Therefore, within the scope of the document, it is only possible to
calculate for the theoretical minimum number of A-links.
To calculate the minimum number of A-links required:
TCHTotal
For E1 systems : AlinkTotal = ( round up to next int eger )
30
TCHTotal
For T1 systems : AlinkTotal = ( round up to next int eger )
23
Where: TCHTotal = Total number of traffic channels to be supported by the STF
Signalling requirements do not need to be included in the above equations as these are automatically
accounted for. Note that one BCF requires between 2 and 8 SDLs.
Impact of GPRS on A-link

dimensioning
With BSS NR 9.1 Gb interfaces between the BCF and SGSN will not be supported. Therefore GPRS
Packet Switched traffic will routed from the BCF, through the STF to the MSC/GPRS backbone via the
M and A links. Therefore, a certain amount of capacity will need to be allocated on the these links for
Packet Switched traffic. The amount of capacity required will depend various factors, including:
• The number of PDCHs supported at the BTSs (initially, this will be between 4 and 8 per cell).
• The average user data throughput per busy hour.
Realistic data traffic figures can only be realised from actual system data or using traffic models based
on this data. At present these figures are not available, however, as a starting point, we can look to the
T-Mobil system in Germany where they have allocated 2 64kbit/sec timeslots on each M interface. This
will therefore also require 2 64kbit/sec timeslots out of the 120 T/S of the 4 associated A-links.

9 Appendix
Erlang B tables
Offered traffic in Erlangs at blocking level of:
Circuits
0.1% 0.2% 0.5% 1% 2% 3% 5%
1 0.001 0.002 0.005 0.010 0.020 0.031 0.053
2 0.046 0.065 0.105 0.153 0.223 0.282 0.381
3 0.194 0.249 0.349 0.455 0.602 0.715 0.899
4 0.439 0.535 0.701 0.869 1.092 1.259 1.525
5 0.762 0.900 1.132 1.361 1.657 1.875 2.218
6 1.146 1.325 1.622 1.909 2.276 2.543 2.960
7 1.579 1.798 2.157 2.501 2.935 3.250 3.738
8 2.051 2.311 2.730 3.128 3.627 3.987 4.543
9 2.557 2.855 3.333 3.783 4.345 4.748 5.370
10 3.092 3.427 3.961 4.461 5.084 5.529 6.216
11 3.651 4.022 4.610 5.160 5.842 6.328 7.076
12 4.231 4.637 5.279 5.876 6.615 7.141 7.950
13 4.831 5.270 5.964 6.607 7.402 7.967 8.835
14 5.446 5.919 6.663 7.352 8.200 8.803 9.730
15 6.077 6.582 7.376 8.108 9.010 9.650 10.633
16 6.722 7.258 8.100 8.875 9.828 10.505 11.544
17 7.378 7.946 8.834 9.652 10.656 11.368 12.461
18 8.046 8.644 9.578 10.437 11.491 12.238 13.385
19 8.724 9.351 10.331 11.230 12.333 13.115 14.315
20 9.411 10.068 11.092 12.031 13.182 13.997 15.249
21 10.108 10.793 11.860 12.838 14.036 14.885 16.188
22 10.812 11.525 12.635 13.651 14.896 15.778 17.132
23 11.524 12.265 13.416 14.470 15.761 16.675 18.080
24 12.243 13.011 14.204 15.295 16.631 17.577 19.031
25 12.969 13.763 14.997 16.125 17.505 18.483 19.985
26 13.701 14.522 15.795 16.959 18.383 19.392 20.943
27 14.439 15.285 16.598 17.797 19.265 20.305 21.904
28 15.182 16.054 17.406 18.640 20.150 21.221 22.867
29 15.930 16.828 18.218 19.487 21.039 22.140 23.833
30 16.684 17.606 19.034 20.337 21.932 23.062 24.802
31 17.442 18.389 19.854 21.191 22.827 23.987 25.773
32 18.205 19.176 20.678 22.048 23.725 24.914 26.746
34 19.743 20.761 22.336 23.772 25.529 26.776 28.698
35 20.517 21.559 23.169 24.638 26.435 27.711 29.677
36 21.296 22.361 24.006 25.507 27.343 28.647 30.657

Appendix BSS Network Design Guide

Circuits
0.1% 0.2% 0.5% 1% 2% 3% 5%
37 22.078 23.166 24.846 26.378 28.254 29.585 31.640
38 22.864 23.974 25.689 27.252 29.166 30.526 32.624
39 23.652 24.785 26.534 28.129 30.081 31.468 33.609
40 24.444 25.599 27.382 29.007 30.997 32.412 34.596
41 25.239 26.415 28.232 29.888 31.916 33.357 35.584
42 26.037 27.235 29.085 30.771 32.836 34.305 36.574
43 26.837 28.057 29.940 31.656 33.758 35.253 37.565
44 27.641 28.882 30.797 32.543 34.682 36.203 38.557
45 28.447 29.708 31.656 33.432 35.607 37.155 39.550
46 29.255 30.538 32.517 34.322 36.534 38.108 40.545
47 30.066 31.369 33.381 35.215 37.462 39.062 41.540

48 30.879 32.203 34.246 36.109 38.392 40.018 42.537
49 31.694 33.039 35.113 37.004 39.323 40.975 43.534
50 32.512 33.876 35.982 37.901 40.255 41.933 44.533
51 33.332 34.716 36.852 38.800 41.189 42.892 45.533
52 34.153 35.558 37.724 39.700 42.124 43.852 46.533
53 34.977 36.401 38.598 40.602 43.060 44.813 47.534
54 35.803 37.247 39.474 41.505 43.997 45.776 48.536
55 36.630 38.094 40.351 42.409 44.936 46.739 49.539
56 37.460 38.942 41.229 43.315 45.875 47.703 50.543
57 38.291 39.793 42.109 44.222 46.816 48.669 51.548
58 39.124 40.645 42.990 45.130 47.758 49.635 52.553
59 39.959 41.498 43.873 46.039 48.700 50.602 53.559
60 40.795 42.353 44.757 46.950 49.644 51.570 54.566
61 41.633 43.210 45.642 47.861 50.589 52.539 55.573
62 42.472 44.068 46.528 48.774 51.534 53.508 56.581
63 43.313 44.927 47.416 49.688 52.481 54.478 57.590
64 44.156 45.788 48.305 50.603 53.428 55.450 58.599
65 45.000 46.650 49.195 51.518 54.376 56.421 59.609
66 45.845 47.513 50.086 52.435 55.325 57.394 60.619
67 46.691 48.378 50.978 53.353 56.275 58.367 61.630
68 47.540 49.243 51.872 54.272 57.226 59.341 62.642
69 48.389 50.110 52.766 55.191 58.177 60.316 63.654
70 49.239 50.979 53.661 56.112 59.129 61.291 64.667
71 50.091 51.848 54.558 57.033 60.082 62.267 65.680
72 50.944 52.718 55.455 57.956 61.036 63.244 66.694
73 51.799 53.590 56.354 58.879 61.990 64.221 67.708
74 52.654 54.463 57.253 59.803 62.945 65.199 68.723
75 53.511 55.337 58.153 60.728 63.900 66.177 69.738
76 54.369 56.211 59.054 61.653 64.857 67.156 70.753
77 55.227 57.087 59.956 62.579 65.814 68.136 71.769
78 56.087 57.964 60.859 63.506 66.771 69.116 72.786
79 56.948 58.842 61.763 64.434 67.729 70.096 73.803
80 57.810 59.720 62.668 65.363 68.688 71.077 74.820
81 58.673 60.600 63.573 66.292 69.647 72.059 75.838
82 59.537 61.480 64.479 67.222 70.607 73.041 76.856
83 60.402 62.362 65.386 68.152 71.568 74.024 77.874
84 61.268 63.244 66.294 69.084 72.529 75.007 78.893
85 62.135 64.127 67.202 70.016 73.490 75.990 79.912
86 63.003 65.011 68.111 70.948 74.452 76.974 80.932
87 63.872 65.896 69.021 71.881 75.415 77.959 81.952
88 64.742 66.782 69.932 72.815 76.378 78.944 82.972
89 65.612 67.669 70.843 73.749 77.342 79.929 83.993
90 66.484 68.556 71.755 74.684 78.306 80.915 85.014
91 67.356 69.444 72.668 75.620 79.271 81.901 86.035
92 68.229 70.333 73.581 76.556 80.236 82.888 87.057
93 69.103 71.222 74.495 77.493 81.201 83.875 88.079
94 69.978 72.113 75.410 78.430 82.167 84.862 89.101
95 70.853 73.004 76.325 79.368 83.133 85.850 90.123
96 71.729 73.895 77.241 80.306 84.100 86.838 91.146
97 72.606 74.788 78.157 81.245 85.068 87.826 92.169
98 73.484 75.681 79.074 82.184 86.035 88.815 93.193


Circuits
0.1% 0.2% 0.5% 1% 2% 3% 5%
99 74.363 76.575 79.992 83.124 87.003 89.804 94.216
100 75.242 77.469 80.910 84.064 87.972 90.794 95.240
101 76.122 78.364 81.829 85.005 88.941 91.784 96.265
102 77.003 79.260 82.748 85.946 89.910 92.774 97.289
103 77.884 80.157 83.668 86.888 90.880 93.765 98.314
104 78.766 81.054 84.588 87.830 91.850 94.756 99.339
105 79.649 81.951 85.509 88.773 92.821 95.747 100.364
106 80.532 82.850 86.431 89.716 93.791 96.738 101.390
107 81.416 83.748 87.353 90.660 94.763 97.730 102.415
108 82.301 84.648 88.275 91.604 95.734 98.722 103.441
109 83.186 85.548 89.198 92.548 96.706 99.715 104.468
110 84.072 86.448 90.121 93.493 97.678 100.708 105.494
111 84.959 87.350 91.045 94.438 98.651 101.701 106.521
112 85.846 88.251 91.970 95.384 99.624 102.694 107.548
113 86.734 89.154 92.895 96.330 100.597 103.688 108.575
114 87.622 90.056 93.820 97.277 101.571 104.682 109.602
115 88.511 90.960 94.746 98.223 102.545 105.676 110.630
116 89.401 91.864 95.672 99.171 103.519 106.670 111.658
117 90.291 92.768 96.599 100.118 104.493 107.665 112.685
118 91.181 93.673 97.526 101.066 105.468 108.660 113.714
119 92.073 94.578 98.454 102.015 106.443 109.655 114.742
120 92.964 95.484 99.382 102.964 107.419 110.651 115.771
121 93.857 96.391 100.310 103.913 108.395 111.646 116.799
122 94.750 97.297 101.239 104.862 109.371 112.642 117.828
123 95.643 98.205 102.168 105.812 110.347 113.639 118.857
124 96.537 99.113 103.098 106.762 111.323 114.635 119.887
125 97.431 100.021 104.028 107.713 112.300 115.632 120.916
126 98.326 100.930 104.958 108.664 113.278 116.629 121.946
127 99.222 101.839 105.889 109.615 114.255 117.626 122.976
128 100.117 102.749 106.820 110.566 115.233 118.623 124.006
129 101.014 103.659 107.752 111.518 116.211 119.621 125.036
130 101.911 104.569 108.684 112.470 117.189 120.619 126.066
131 102.808 105.480 109.616 113.423 118.167 121.617 127.097
132 103.706 106.392 110.549 114.376 119.146 122.615 128.128
133 104.604 107.303 111.482 115.329 120.125 123.614 129.159
134 105.503 108.216 112.416 116.282 121.104 124.612 130.190
135 106.402 109.128 113.349 117.236 122.084 125.611 131.221
136 107.302 110.041 114.283 118.190 123.063 126.610 132.252
137 108.202 110.955 115.218 119.144 124.043 127.610 133.284
138 109.102 111.869 116.153 120.099 125.023 128.609 134.315
139 110.003 112.783 117.088 121.054 126.004 129.609 135.347
140 110.904 113.697 118.023 122.009 126.984 130.609 136.379
141 111.806 114.612 118.959 122.964 127.965 131.609 137.411
142 112.708 115.528 119.895 123.920 128.946 132.609 138.443
143 113.611 116.444 120.832 124.876 129.928 133.610 139.476
144 114.514 117.360 121.769 125.832 130.909 134.610 140.508
145 115.417 118.276 122.706 126.789 131.891 135.611 141.541
146 116.321 119.193 123.643 127.746 132.873 136.612 142.574
147 117.225 120.110 124.581 128.703 133.855 137.613 143.606
148 118.130 121.028 125.519 129.660 134.837 138.615 144.640
149 119.035 121.946 126.457 130.618 135.820 139.616 145.673
150 119.940 122.864 127.396 131.576 136.803 140.618 146.706
151 120.846 123.783 128.334 132.534 137.786 141.620 147.739
152 121.752 124.702 129.274 133.492 138.769 142.622 148.773
153 122.659 125.621 130.213 134.451 139.752 143.624 149.807
154 123.566 126.541 131.153 135.409 140.736 144.627 150.840
155 124.473 127.461 132.093 136.368 141.720 145.629 151.874
156 125.381 128.381 133.033 137.328 142.704 146.632 152.908
157 126.288 129.302 133.974 138.287 143.688 147.635 153.943
158 127.197 130.223 134.915 139.247 144.672 148.638 154.977
159 128.105 131.144 135.856 140.207 145.657 149.641 156.011
160 129.014 132.065 136.797 141.167 146.641 150.644 157.046


Circuits
0.1% 0.2% 0.5% 1% 2% 3% 5%
161 129.924 132.987 137.739 142.128 147.626 151.648 158.080
162 130.833 133.910 138.681 143.088 148.611 152.651 159.115
163 131.743 134.832 139.623 144.049 149.596 153.655 160.150
164 132.654 135.755 140.565 145.010 150.582 154.659 161.185
165 133.564 136.678 141.508 145.972 151.567 155.663 162.220
166 134.475 137.601 142.451 146.933 152.553 156.667 163.255
167 135.387 138.525 143.394 147.895 153.539 157.672 164.291
168 136.298 139.449 144.338 148.857 154.525 158.676 165.326
169 137.210 140.373 145.281 149.819 155.511 159.681 166.361
170 138.123 141.298 146.225 150.781 156.498 160.686 167.397
171 139.035 142.223 147.169 151.744 157.484 161.690 168.433
172 139.948 143.148 148.114 152.707 158.471 162.695 169.469
173 140.861 144.073 149.058 153.669 159.458 163.701 170.504
174 141.775 144.999 150.003 154.633 160.445 164.706 171.540
175 142.689 145.925 150.948 155.596 161.432 165.711 172.576
176 143.603 146.851 151.894 156.559 162.419 166.717 173.613
177 144.517 147.777 152.839 157.523 163.407 167.723 174.649
178 145.432 148.704 153.785 158.487 164.395 168.728 175.685
179 146.347 149.631 154.731 159.451 165.382 169.734 176.722
180 147.262 150.558 155.677 160.416 166.370 170.740 177.758
181 148.178 151.486 156.624 161.380 167.358 171.747 178.795
182 149.093 152.414 157.570 162.345 168.347 172.753 179.832
183 150.010 153.342 158.517 163.310 169.335 173.759 180.869
184 150.926 154.270 159.464 164.275 170.323 174.766 181.905
185 151.843 155.198 160.412 165.240 171.312 175.773 182.942
186 152.760 156.127 161.359 166.205 172.301 176.779 183.980
187 153.677 157.056 162.307 167.171 173.290 177.786 185.017
188 154.594 157.985 163.255 168.136 174.279 178.793 186.054
189 155.512 158.915 164.203 169.102 175.268 179.800 187.091
190 156.430 159.845 165.151 170.068 176.258 180.808 188.129
191 157.348 160.775 166.100 171.035 177.247 181.815 189.166
192 158.267 161.705 167.048 172.001 178.237 182.822 190.204
193 159.185 162.635 167.997 172.968 179.226 183.830 191.241
194 160.105 163.566 168.946 173.934 180.216 184.838 192.279
195 161.024 164.497 169.896 174.901 181.206 185.845 193.317
196 161.943 165.428 170.845 175.868 182.196 186.853 194.355
197 162.863 166.359 171.795 176.835 183.187 187.861 195.393
198 163.783 167.291 172.745 177.803 184.177 188.869 196.431
199 164.703 168.223 173.695 178.770 185.168 189.878 197.469
200 165.264 169.155 174.64 179.738 186.158 190.886 198.507

10 Acronyms
Acronyms
BCCH Broadcast Common Control Channel

BCF Base station Controller Frame
BHCA Busy Hour Call Attempts
BSC Base Station Controller
BSIC Base Station Identity Code
BSS Base Station System
BTS Base Transceiver Station
CEWS Cell Workstation
COWS Common Workstation
CPU Central Processing Unit
CS Circuit Switched
DFU Digital Facilities Unit
DM Dual Mode
EFR Enhanced Full Rate
EIR Equipment Identity Register
FH Frequency Hopping
FR Full rate
FTP File Transfer Protocol
GBS GPRS Backbone System
GGSN GPRS Gateway Support Node
GOS Grade of Service

Acronyms BSS Network Design Guide
GPRS General Packet Radio Service

HLR Home Location Register
HO Hand Over
IMSI International Mobile Subscriber Identity
IP Internet Protocol
LA Location Area
LAC Location Area Code
LAPD Link Access Protocol Type D
LU Location Update
MAC Medium Access Control
MHT Mean Holding Time
MRIF(2) Mini Rack InterFace
MS Mobile Station
MSC Mobile Switching Centre
MSU Message Signal Unit
NDT Network Dimensioning Tool
OMC Operations and Maintenance Centre
PDCH Packet Data Channel
PDP Packet Data Protocol
PLMN Public Land Mobile Network
PLU Periodic Location Update
PPP Peripheral Pre-Processor
PS Packet Switched
PSTN Public Switched Telephone Network
RLC Radio Link Control
SACCH Slow Associated Control Channel
SDCCH Stand-alone Dedicated Control Channel
SDFU Sub-rate Digital Facilities Unit
SDL Signalling Data Link
SGSN Serving GPRS Support Node
SMS Short Message Service
SMS-CB Short Message Service - Cell Broadcast
SS7 ITU-T Standardised outband signalling system based on 64kbit/s links
STF Speech Transcoding Frame
STU Speech Transcoding Unit
TBF Temporary Block Flow
TCH Traffic Channel
TCP Traffic Control Protocol

TCU Traffic service group Control Unit

TG Trunk Group
TRX Transmitter/Receiver
TS Time Slot
TSG Traffic Service Group
VLR Visitor Location Register


Type in your fax number:
Lucent Technologies GmbH
Fax: (0911) 526-3545 (Deutschland)
+49 911 526-3545 (International)
How are we doing?

Affected Network Element: BSS Network
Name of Subject of Document: BSS Network Design Guide
Type of Document: Engineering Guideline
401-380-312 Issue Number: 1.0 Date Issued: November 2000
1. Please rate the effectiveness of this Information Product in the following areas:
Excellent Good Fair Poor Not Applicable
Ease of use
Clarity
Completeness
Accuracy
Organisation
Appearance
Examples
Illustrations
Overall Satisfaction
2. Please place a tick against any improvement that could be made to this Information Product:
Improve the overview/introduction Make it more concise/brief
Improve the table of contents Add more step-by-step procedures/tutorials
Improve the organisation Add more troubleshooting information
Include more figures Make it less technical
Add more examples Add more/better quick reference aids
Add more detail Improve the index
Please provide details for the suggested improvement
3. What did you like most about this Information Product?
4. Feel free to write any further comments below, or on a further sheet.
If we may contact you concerning your comments, please complete the following:
Name: Telephone number:
Company/Organization: Date:
Address:

BSS Planning and Ion

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

BSS Planning and Ion

Загружено:

Авторское право:

Доступные форматы

BSS Network Design Guide

GSM NR 9.1 and NR 9.2

Design and Dimensioning Document

Copyright  2000 Lucent Technologies

BSS Systems Overview 1-2

Base Transceiver Station (BTS) 1-2

Base Station Controller (BSC) 1-2

BCF-2000 (BCF) 1-2

STF-2000 (STF) 1-2

Operations & Maintenance Centre (OMC) 1-2

GPRS System Overview 1-3

Capacity Calculation 2-1

Total SDCCH Capacity Needed 2-2

Example SDCCH Dimensioning 2-2

Location Updating Type Normal 2-2

Periodic Location Update 2-3

IMSI detach/attach 2-4

Call set-up 2-4

Fax Set-up 2-4

Issue 1.0 – November 2000 Lucent Technologies – Proprietary iii

False accesses 2-5

Total SDCCH Capacity Needed 2-5

Cell Configuration Example 2-5

Configuration Rules 2-6

Configuration Constraints 2-6

Constraints in Case of SMSCB 2-6

Typical SDCCH Configuration in a cell 2-7

3 BTS CONFIGURATION 3-1

Dimensioning per BTS site 3-1

Required input information 3-1

Flexent Macrocell 3-3

Impact of GPRS on the BTS 3-4

Standard Configuration 3-5

Further Information 3-5

4 ABIS LINK DIMENSIONING 4-1

Calculating required number of Abis links 4-1

Dimensioning the Abis link 4-2

GPRS support on the Abis interface 4-4

Further Information 4-4

5 BCF PLANNING 5-1

BCF Planning Steps for Circuit Switch Network 5-1

BCF Maximum Capacity Calculation 5-3

iv Lucent Technologies – Proprietary Issue 1.0 –November 2000

Calculate Number of Servers 5-6

B180 Servers 5-6

Network Dimensioning Tool (NDT) 5-7

2) BCF Dimensioning 5-7

3) BTS - BCF distribution 5-8

4) Calculations of Cards 5-9

Number of HP Servers per BCF 5-9

Server Redundancy Concept 5-9

SDFU Calculations/Distribution 5-9

Internal E1/T1 links 5-10

Distribution/Configuration of Abis links 5-10

GPRS Impact on BCF 5-11

BCF Capacity Limits 5-11

Simplified Capacity Estimation Model 5-13

Uplink and downlink capacity 5-14

BCF capacity constraints 5-14

Air Link Throughput 5-14

Signalling Overhead 5-15

Coding Scheme Usage 5-16