bss planning and ion

8/8/2019 BSS Planning and ion

1/85

401-380-312Issue 1.0

November 2000Lucent Technologies - Proprietary

This document contains proprietary informationof Lucent Technologies and is not to be disclosed or used

except in accordance with applicable agreements

Copyright 2000 Lucent TechnologiesUnpublished and Not for PublicationAll Rights Reserved

BSS Network Design Guide

GSM NR 9.1 and NR 9.2

Design and Dimensioning Document


2/85

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 LucentTechnologies), except in accordance with applicable agreements, contracts, or licensing, without theexpress written consent of the Customer Training and Information Products organisation and thebusiness management owner of the material.

NoticeEvery effort was made to ensure that the information in this information product was complete andaccurate at the time of printing. However, information is subject to change.


3/85

Issue 1.0 November 2000 Lucent Technologies ProprietarySee Notice on first page

iii

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


4/85

Contents BSS Network Design Guide

iv Lucent Technologies ProprietarySee Notice on first page

Issue 1.0 November 2000

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


5/85



v

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 SwitchedTraffic 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


6/85


vi Lucent Technologies ProprietarySee Notice on first page


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


7/85



vii

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


8/85


viii Lucent Technologies ProprietarySee Notice on first page


This page is intentionally left blank


9/85


1-1

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 itprovides a detailed understanding of the various aspects which need to be considered while preparinga network design. The detailed equipment configurations and calculations are also mentioned. All BSSequipment (except OMC) has been covered by the document. This document is based on the GSMnetwork 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 thescope of this document. New features like GPRS have been included in this document. The documentcovers the equipment impact due to GPRS and covers the calculations for equipment requirement forGPRS.

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 basisfor the tool and the tool can be used for the detailed network design.


10/85

Introduction BSS Network Design Guide

1-2 Lucent Technologies ProprietarySee Notice on first page


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 theentire radio equipment for one, two or three radio cells, each of which is characterised by a particularBase Station Identification Code (BSIC). The BTS family of equipment provides both indoor andoutdoor implementations and supports a wide range of site configurations and sizes. One BTS framehouses up to three cells. To provide a high quality radio connection for the handover process, the BTStakes 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 GSMrecommendation, implying that the speech transcoding and data rate adaptation functions arephysically separated from the central control function of the BSC. The BSC provided with the GSMsystem therefore consists of physically separate BSS Central equipment (BCF-2000) and transcodingequipment (STF-2000) components. It should be noted, however, that the transcoder may be locatedat 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 ofradio resources, radio channel management and local connection management are performed in theBCF-2000. It also provides switching of individual timeslots between the STF2000 and MSCcomponents. Finally, one of its key functions is control of the handover process, based on air interfacemeasurements received from the BTS(s).

STF-2000 (STF)

This provides the speech transcoding and submultiplexing functions. For speech signals, thetranscoding function provides the conversion between the standardised 64kbit/s data rate used at thenetwork 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 combinedonto a single 64kbit/s timeslot to realise a 4:1 saving in required transmission facilities to the BCF-2000and the BTSs. This is implemented in Lucents standard Type 6 configuration where the MSC andTRAU are co-located.

Operations & Maintenance Centre (OMC)

The OMC provides centralised operations & Maintenance functions for the GSM networks. It is basedon an open system hardware & software platform with proven application s/w that has object-orientedtechniques. Some of its functions are: Network performance analysis, fast and accurate faultdiagnosis, network quality indicators, on time fault correction procedures and timely network capacitymetrics


11/85



1-3

GPRS System Overview

GSM networks have reached a high level of maturity in handling voice calls and operators are lookinginto 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 equipmentconfiguration and network capacity. Also new networks have to be planned differently if GPRScapabilities 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 softwarerelease GSM 9.1 (GPRS Rel.1.5).

As shown in Figure 1, the GRPS part of the network comprises of GBS and GPRS-BSS.

Figure 1: GSM/GPRS System Overview

PLMN

Packet DataNetwork

GGSNGb

Gn

Gi

A/GbM/Gb

Abis

Abis

Abis

NSS

BSS

M/Gb

BCF

PCU

BCF

PCU

STF

MSC

SGSN


12/85






13/85


2-1

2 Um Interface

Scope

In a GSM network, the correct dimensioning of the control channels is as important as the trafficchannels to handle the signalling messages. A failure to correctly dimension the control channels mayresult in a failure to access the required resource resulting in, for example, a Blocked Call. Thischapter 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 theSDCCH that is considered as a bottleneck in GSM systems. If there is a heavy congestion on theSDCCH, the mobiles may be denied access to the call set-up process, even though there may beTCHs unoccupied.

Therefore, the probability of blocking for the SDCCH must be significantly less than that for the trafficchannels, 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.


14/85

Um Interface BSS Network Design Guide



Formula

SDCCH Traffic Per Cell = (A x Number of Subscribers in Cell) + Af

Where: A = SDCCH Traffic per subscriberAf = 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 theprocedures 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 cellbasis. We will consider each procedure that is performed on an SDCCH in a cell by using typicalvalues in a network:

Location Updating Type Normal

Every time an idle MS moves into a different location area, it must perform a Geographic LocationUpdate. This is done by using an SDCCH channel. The larger the Location Area, the fewer theLocation Updates. For inner cells, which are located far from the LAC boundaries, practically very littleLocation updating is done, unless there happens to be an Airport in such a cell. For border cells, thefrequency 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


15/85



2-3

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 areaserved 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. Asthe 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

LocationArea

boundary
http://en0033svr06.uk.lucent.com/npse/GSM%20eng_tools/GLAD/LAC_Tool.htmhttp://en0033svr06.uk.lucent.com/npse/GSM%20eng_tools/GLAD/LAC_Tool.htm


16/85




IMSI detach/attach

Following figures are assumed:

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.8SDCCH 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 accessrequest and move onto the SDCCH prior to receiving any data. Therefore the higher the ratio of SMSto traffic calls, greater the number of SDCCH that will be required.Following figures are assumed:

Number Mobile terminated traffic per hour per Subscriber 0.5Number 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


17/85



2-5

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 adistant 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 andthen 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 followingconfiguration:

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, thiscould 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 thatwill give 14. 03 Erlangs (Erlang-B table) and can serve 425 Subscribers.


18/85




For the SDCCHs with 5.58 mErlang per subscriber, 16 SDCCHs give 7.7 Erlangs which can serve1379 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 modeIn 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 ornon- 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


19/85



2-7

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 optimisedusing 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 cellwith 1 or 2 RTs, the operator could also use Non-combined BCCH configuration and allocate 8SDCCHs 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


20/85




This page intentionally left blank


21/85


3-1

3 BTS Configuration

Introduction

This chapter describes the planning options for dimensioning a BTS site. Most options will depend onthe location, the number of subscribers it has to support, type of combining etc. The following stepsattempt to guide the planner through a logical procedure to a final configuration. However, the order ofimportance of the various options may differ from BTS location to BTS location so the planning stepsmay 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


22/85

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 thenetwork 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 combininghas higher transmit losses than Filter combining.

Frequency hopping: Diplexers only Synthesiser and Baseband hoppingHybrid combining Synthesiser and Baseband hoppingFilter combining Baseband hopping only

1

Dual Band is not supported on the BTS-2000/2C within the same BTS cabinet. However, Dual Bandcan be configured by using 2 BTS-2000/2C cabinets, one per frequency band. If the BTS-2000/2Csintegral antennas are not used then four external antennas per RF coverage area would be required.


23/85



3-3

Select the number of TRXs required per cell:

The configuration chosen should be able to support the final number of TRXs required for the finalphase of the network implementation. Use the following table to select a configuration that supports thetotal quantity of TRXs:

TRXs per cell for Mono-Band operationDiplexer Hybrid combining Filter combiningBTS type

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 operationBTS 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 subscriberssupported by the total number of BTSs is calculated and that is then compared with the number ofsubscribers required to be supported by the network. The total number of BTSs are generally inputfrom 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 RFcoverage 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 1cabinet. By using BTS 2 cabinets per sector, 1 GSM900 and 1 GSM1800, dual-band coverage can beimplemented. A single Abis link (E1 employing LAPD signalling link concentration) can support 6 BTScabinets (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 3cells per cabinet and Network Release 9.2 supporting 6 cells per cabinet. This means that for NR 9.1Dual-Band coverage can only be realised for Omni (single sector) configurations (1 cell at 900MHz and1 cell at 1800MHz). With NR 9.2, 6 cells will give the capability of supporting dual-band for up to 3sectors (3 cells at 900MHz and 3 cells at 1800MHz).


24/85




Impact of GPRS on the BTS

To incorporate GPRS support at the BTS a certain amount of the traffic channels have to beconfigured 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 onthe down-link.

For the introduction of GPRS to the network it is recommended that the PDCHs be allocated to the firstTRX (0) in the cell. The advantages of this are that the last 2 restrictions will have no consequence asTRX 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-establishedalong 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 thestart-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 bepossible to reserve channels for GPRS service only. The configured GPRS channels can also be usedfor CS services in the event of all the other CS channels in the cell being occupied and provided thatthe 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 extraTRXs, 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 befollowed 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 maximumcapacity 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

(max. 8 PDCHs total/cell)

1

Max. Number combined PDCHs in down link persubscriber

4

Max. Number combined PDCHs in up link persubscriber

2

Table 13: BTS GPRS Capacity Limits


25/85



3-5

Standard Configuration

In discussion with several operators, a standard has been elaborated. This configuration is alsoreflected in the script files, which have been developed to support the GPRS network introduction. (Fordetails 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 theconfiguration 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 followingEngineering Guidelines:

BTS-2000 - EG18 vol. 2 - 401-380-368BTS-2000/2C - EG24 - 401-380-324

Flexent Macrocell - EG28 - 401-380-371

All are orderable from CIC in the usual way.


26/85






27/85


4-1

4 Abis Link Dimensioning

Calculating required number of Abislinks

The costs of providing Abis links can represent a significant proportion of the total running costs of acellular network. It is therefore important that the minimum number of Abis links are used within anetwork to minimise ongoing rental costs. This could be implemented in the use of Multi-dropconfigurations. However, the requirements for projected growth need to be considered in the planningof 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.

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


28/85

Abis Link Dimensioning BSS Network Design Guide



From our initial planning calculations we know (approximately) how many BTSs and configurationtypes (omni, sectored, TRXs per cell etc.) we require in the system. Using the above assumptions wecan calculate the number of Abis links required:

BTSsdardtansof.No2

BTSssmallof.NolinksAbis +

=

The above formula suggests that 2 small BTSs could be configured on a single multidrop A bis link anda standard BTS would require a single dedicated Abis connection. These assumptions are forguidance 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.


29/85



4-3

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:

[ ] TotalTotal CellTRXTimeslots += 3

Systems using LAPD signalling link concentration:

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 agiven number of TRXs and Cells on 1 Abis link.

Number of CellsTRXsper 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 197 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 2110 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 extrasignalling may be required. See GPRS support on the Abis interface later in this section.

[ ]

++= Total)upround( Cell

4

1cellperTRXs.NoAverage2TRXTimeslots Total


30/85




GPRS support on the Abis interface

With the first release of GPRS a maximum of 8 PDCHs can be allocated per cell. Typically, 4 PDCHwill be the expected figure. When dimensioning the Abis interface it will still be possible to concentratea 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.


31/85


5-1

5 BCF Planning

Introduction

This section allows the user to dimension and plan the number of BCFs required in their networks aftercalculating the number of BTSs. The NDT can be used for all the calculations that are described in thefurther sections.

BCF Planning Steps for Circuit Switch

Network

The following are the steps we have considered to calculate the number of BCFs required in thenetwork:

BCF subscriber capacity based on a traffic modelThis section explains how the capacity of the BCF can be calculated using a specific trafficmodel and the capacity of the BCF in Erlang is calculated as an end result. This capacity of theBCF should be then taken for further BCF calculations.

Calculation of number of BCFsThis section takes the input from the BTS calculations (TRX, cells, Abis, Erlangs) and then theMinimum 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 furthermentioned section should be referred to.

BTS BCF distributionThis section describes how to distribute the BTSs across the BCFs and how it is done in theNetwork 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 thisthe capacity for each BCF is also calculated.


32/85


33/85

BCF Planning BSS Network Design Guide


5-3

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

Procedures CPU loadper procedure on

COWS

CPU loadper procedure on

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 themaximum capacity of the BCF the maximum recommended number of CEWS should be 4 (plus oneredundant 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 COWTotal CPU Load on CEW = (Max. Number of users) x ( CPU load per user on eachCEW )+ 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 perUser 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 theCOWS 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 inthe 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


34/85




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 followingformula (Formula - 3):

Total number of users per BCF = MIN ((maximum desired COWS CPU load - Empty LoadCOWS)/CPU Load per User on COW; (maximum desired CEWS CPU load - Empty LoadCEWS)/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 thetraffic per user (E from Table 16)

Example

To calculate the maximum capacity of the BCF based on the subscriber traffic model given below weassume 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.6Number of cells per Location Area M 30

Table 18: Subscriber Traffic Model Parameters


35/85



5-5

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.001248744CPU 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 waybased on a certain traffic model. The NDT tool can be used for the same and the maximum Erlangsobtained 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 asmentioned later the B 180 servers increase the overall capacity by around 40%. Using the sametraffic 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. Thesubsequent sections explain the method to calculate the number of servers after distribution of theBTSs to the BCFs. The exact capacity of the BCF would then depend on the number of serverscalculated and the BCF Erlang capacity should then be recalculated taking into account the exactnumber of BCFs. For planning purposes, the steps mentioned in this chapter can be used and thesection below to calculate the number of servers from the number of users is for information only.


36/85




Calculate Number of Servers

The calculations for the number of servers mentioned here is from the perspective of one BCF basedon 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 calculationsmentioned in the subsequent sections.

The following approach should be taken if the task is to calculate the required number of cell serversgiven a total number of users to be supported by a particular BCF and a specified subscriber trafficmodel. This number of users may be determined by the air-interface capacity of the cell configurationallocated 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 mightbe for redundancy).

The number of Cell Servers (CEWS) is calculated and dependent upon the subscriber traffic modeland the Location Area configuration.

The number of CEWS required to support the subscriber traffic offered by all the BTS on the BCF canbe calculated as follows:

Number of CEWS = max [ 2, CPU Load per user on all CEWS * Total Number ofUsers/(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 allthe 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 informationwill be included in future issues of this document. In case of a mixed configuration the calculations forthe B 132 servers will have to be considered.


37/85



5-7

Network Dimensioning Tool (NDT)

The NDT provides the functionality to the user to input their own Traffic model and based on the abovecalculations 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 thenew test results are available from NTI as per the availability of the GSM release, so the tool can beused to calculate the capacity supported by BCF based on a particular traffic model. The tool can beused 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 SystemsAbis Links 60 60M-links 10 10Cells 180 180TRXs 256 256SDFUs 26 26

Table 19: BCF Limits

Note: Erlang capacity is calculated from the Traffic model as explained in the previoussection.

Limits per server:- Signalling channels = 124

- TRXs= 64

- Cells = 45

- Maximum Abis l inks = 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 supportthe 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 subscribersrequired by the customer to be supported.
http://en0033svr06.uk.lucent.com/npse/Network_Engineering/Dimension_Planning/Documentation/BSS_Eng/BSS_home_left_frame.htmhttp://gsm_eng_tools/NDT/eng_tools_home_NDT.htmhttp://en0033svr06.uk.lucent.com/npse/Network_Engineering/Dimension_Planning/Documentation/BSS_Eng/BSS_home_left_frame.htm


38/85




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

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 somerequirements and constraints. In the network design there should be a balanced BCF load, the link tothe BCF site should have a reasonable length and the design should consider moving traffic in a way itcreates the minimum of signalling. This is generally done after taking into account the traffic loads onthe various roads according to the terrain maps.

The LAC and Cell id is a 2-Octet number (0000-FFFF in Hexadecimal format). Valid decimal valuesrange between 0 and 65535. The LAC is assigned by Systems Engineering team. Detailed LACplanning 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 allocatesthe 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 BCFshould 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 attachedcapacity of the BCF and on looking at the table one can find out how much of the capacity is availableon the BCFs in the network.

Detailed location area planning documents should be referred to for proper planning purposes.

=

BCFperMaxAbis

Abis_tTo,

BCFperMaxCells

Cells_Tot,

BCFperMaxTRX

Trx_Tot,

BCFperlgMaxEr

lgEr_TotMaxBCF_Nb_Min


39/85



5-9

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/BSS_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, were able to calculate the number of servers.

Sig_Ch = Tot_Trx + Tot_Cells + Tot_Mlinks +1;

Cell_Servers = ]20

Abis_Tot,45

Cells_Tot,64

Trx_Tot,124

Ch_Sig_Tot,2[MAX

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 areredistributed to maintain maximum coverage.

The redundant workstation runs in a load sharing mode as CEWS providing spare capacity. No idlehardware is wasted for redundancy purposes. The types of workstations are only different fromapplication point of view, all have the same HW (They can be B 132 or B 180 servers). In all scenariosthe maximum number of servers in the BCF is always 6.

SDFU Calculations/Distribution

PurposeThis section provides an overview on how to calculate the number of SDFUs and their distributionwithin the SRS. For detailed description please refer to the BCF engineering guidelines EG 20.
http://en0033svr06.uk.lucent.com/npse/Network_Engineering/Dimension_Planning/Documentation/BSS_Eng/BSS_home_left_frame.htmhttp://en0033svr06.uk.lucent.com/npse/Network_Engineering/Dimension_Planning/Documentation/BSS_Eng/BSS_home_left_frame.htmhttp://en0033svr06.uk.lucent.com/npse/Network_Engineering/Dimension_Planning/Documentation/BSS_Eng/BSS_home_left_frame.htmhttp://en0033svr06.uk.lucent.com/npse/Network_Engineering/Dimension_Planning/Documentation/BSS_Eng/BSS_home_left_frame.htm


40/85




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 A bis E1/T1 links. SeeTable 20 for SDFU placements within the BCF shelves. The minimum configuration of 3 servers willsupport 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 SDFUcards as shown in Table 20. Server interfaces are either E1 or T1 links as per the M interface. MixedE1/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 arebrought in as required. The fourth server requires SDFU cards in slots 6, 11, 16 and 27. The fifthserver 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

Port 0 A32 A24 A16 M8 M5 A40 A1 M0 A8 M2 A45 A56 M6

Port 1A33 A25 A17 A51 A41 A2 A0 A9 A10 A46 A57

Port 2A34 A26 A18 A52 A42 A3 S2

port 0S2

Port 1A11 A47 A58

SDFUports

(shelf 0)

Port 3A35 A27 A19 S6

port 0S5

port 0S4

Port 0S3

port 0S1

port 0S1

Port 1S3

port 1S4

port 1S5

port 1S6

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

Port 0A36 A28 A20 S6

port 2S5

port 2S4

Port 2S3

port 2S1

port 2S1

Port 3S3

port 3S4

port 3S5

port 3S6

port 3

Port 1A37 A29 A21 A53 A43 A5 S2

port 2S2

Port 3A14 A48 A59

Port 2A38 A30 A22 A54 A44 A6 A4 A12 A15 A49

SDFUports

(shelf 1)

Port 3A39 A31 A23 M9 A55 M4 A7 M1 A13 M3 A50 M7

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. Theselinks now need to be allocated to specific BCFs. When assigning Abis links to a BCF, we have to beconstantly aware of its capacity limitations as each Abis is assigned. These limitations are shown in the

Rulesin the previous chapter. The Abis links should be evenly distributed across the BCFs.


41/85



5-11

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 GuidelineEG20. 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 theCS calculations need to be done again with the less number of servers as some BCFcapacity 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 themaximum 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 theredundant server for GPRS, but this would lead to increasing the downtime for theconnected BTSs in case of any failure.

If a BCF expansion is not possible, then an additional BCF with a minimum configuration of 4servers (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 withCS.

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 serversand 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 = 64kbit/s)

31

Table 21: Capacity Limits

The number 93 PDCH relates to the physical limitation of the BCF in GPRS release 1. The GPRSserver (=GWS) has 4 E1 interfaces. With 3 E1 lines used for the server connection to the BTSs wehave 3*31 TS (= 93) available. The fourth E1 line is used as Gb interface.


42/85




Now, you can have more than 93 data users connections (PDCHs) simultaneously. In theory up to1440 (180 cells * 8 TSs) data user connections and therefore 1440 PDCHs can be established. Thismeans we support 1440 PDCHs statically. However, the number of PDCHs supported dynamicallydepends on the data traffic generated by the established logical data connection. So it is suggested totalk about data throughput than about number of PDCHs supported

5.1) BCF Planning Steps for Combined Circuit and Packet SwitchNetwork:

In case of a network having both Circuit Switch and Packet Switch traffic, the BCF planning stepsshould be:

1 BCF capacity calculation

This section provides information on how to calculate the number of users per BCF for a combinedtraffic (CS and PS). The total number of BCFs required can then be calculated for the network ifthe total subscribers are known. So the Step 1 mentioned in the previous section - BCF planningsteps for Circuit Switch n/w, should be used and in addition the steps mentioned in this chapteralso 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 switchn/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 onthis the capacity for each BCF is also calculated


43/85



5-13

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 acombined traffic, for a certain number of CS and PS subscribers. Also it provides a procedure toestimate the maximum number of GPRS users a BCF can support, or, similarly, the number of GPRSpacket data channels needed to support a given number of subscribers per BCF. The capacityengineering 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-knownErlang-B formula. This formula assumes that the time between the arrival of new calls is exponentiallydistributed, while the length of time calls occupy a timeslot may have a general distribution. Themaximum 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 intonumber of users per cell.

The capacity of a network offering both circuit and packet switched services is more complex. Thenumber of subscribers a PDCH can support, for example, is dictated largely by the way GPRSsubscribers use the network. A PDCH used by mobile systems transferring a few megabytes of dataper hour, for example, will support fewer mobile systems than a PDCH used by mobile systemssending a kilobyte or less of data per hour.

The applications mobiles will use a GPRS network for is still a matter of speculation. The usagecharacteristics will be determined by the data transfer requirements of as-yet-undevelopedapplications, GPRS tariff rates, and other factors. The amount of data typically sent and received by amobile system after it has attached and activated PDP context, the length of time a mobile systemtypically remains attached, the characteristics of data transfer (periodic bursts of packets, or bulk datatransfer) are for the most part unknown. Yet all these factors influence the GPRS signalling load in acell 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 GPRSnetwork. This model will not capture the burstiness of data transfer, but will allow us to coarselydimension PDCH capacity.

Assumptions

Quick response times are important for many types of applications. As a rough rule-of-thumb, the delayperformance of the airlink will be unacceptable for many transaction-oriented applications at utilisationbeyond 80%. Hence, we assume that during the busy hour the maximum average utilisation of PDCHsis 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 cellconfigurations with the number of available timeslots and the figures for the offered CS traffic aregiven.

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 thatthe circuit switched calls could preempt the GPRS channels. Then the average amount of channels

available for packet data transfer can be calculated.


44/85




Uplink and downlink capacity

The system offers the same capacity in uplink and downlink direction. It is expected that the majority ofapplications will such as retrieving of email, credit card validation remote database access or webbrowsing will send more data downlink than uplink. However, there may be also applications, forexample 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 theGPRS:

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. Thisoverhead consists of additional airlink blocks carrying data originated by session and mobilitymanagement and signalling data for the handling of the user data transmission (RLC/MAC acks, TBFsetup/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 signallingoverhead in an accuracy, which is appropriate for sizing purposes, we distinguish between 3 differentgeneric 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. Dependingon the application the actual amount of data per user in kbyte has to be multiplied by the correspondingoverhead factor. Calculations have shown that there are two main categories of traffic that arecharacterised by different overhead factors.

Bulk data transfer:A number of applications may receive heavy volumes of application datausing IP packets carrying fairly large TCP data segments (536 bytes). This traffic profile is typicalof 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, telemetryapplications and credit card validation.

For every subscriber type the amount of uplink and downlink data per user for both categories have tobe specified. This data should contain already the TCP headers (40 bytes for the header per TCPpacket) and also take SNDCP compression into account if this is required (40 byte TCP header getscompressed down to 3 bytes).

Furthermore the assumed GMM and SM signalling behaviour of every user type - the number ofattaches/detaches, PDP context activations/deactivations and routing area updates - has to bespecified.


45/85


46/85




For the GMM and SM signalling procedure the following data overhead should be taken into account:

Downlink:

Procedure Total # RLC/MACblocks

Data per procedure[byte]

GPRS attach 16 400

GPRS detach 9 225

PDP context activation 18 450

PDP contextdeactivation

4 100

Routing area update 15 375

Table 25: Downlink

Uplink:

Procedure Total # RLC/MACblocks

Data per procedure[byte]

GPRS attach 21 525GPRS detach 12 300

PDP context activation 20 500

PDP contextdeactivation

5 125

Routing area update 19 475

Table 26: Uplink

Coding Scheme Usage

The selection of the coding schemes depends on the signal quality at the receiver. The currentnetworks are designed for circuit switched voice transmission. With the introduction of GPRS moreinterference 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 inputparameter in the airlink dimensioning.

The following amount of user data (LLC frames or parts of LLC frames) can be carried per RLC/MACblock 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 servicechannels will always be available for packet-switched use when requested.


47/85



5-17

This section describes how to calculate the average amount of channels available for GPRS in a cellfor 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 CScalls

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=*Tdenotes the average offered CS call load per cell in Erlangs. Circuit-switchedcalls arrive to a cell in accordance with a Poisson process with rate . Let c be the total number oftimeslots in the cell and m the number of dual service channels. Let P[i] denote the probability that itimeslots are occupied by voice calls. P[i] is given by the well known expression:

[ ]

=

=c

0j

j

i

!j

)/(

!i

)/(

iP 5-1

Then the average amount of channels available for GPRS in a cell, n, could be calculated by thefollowing formula

[ ] [ ]=

=c

0i

i,mminicPn 5-2

In order to achieve a good delay performance and to avoid a high variance in the packet delay times itshould not be calculated with the full number of dual service channels (m) since sometimes those willbe occupied by circuit-switched voice calls when a packet data channel is needed. If a high variation inthe packet delay time is not acceptable for the considered applications the number of assumed PDCHshould be only 1 and therefore the following formula should be used to calculate the average amountof available GPRS channels in a cell.

[ ] [ ]=

=c

0i

i,1minicPn 5-3

Therefore in a system where higher demands in GPRS data transfer are expected 'PS only' channelsshould be provided in order to avoid the delay of packet data due to CS channel usage and toguarantee certain delay time requirements.

A further aspect to be considered here is that there are at maximum only 93 parallel PDCHs currentlyavailable in the BCF for R 3.0. Thus the average amount of channels available for GPRS per BCF canbe at maximum 93. Since all the 93 channels may be allocated to a specific cell but some of them notfully loaded when a request to allocate a further PDCH arrives the maximum number of PDCH to becalculated with for sizing purposes for R3.0 should be less than 93. In this case the spare capacity ofthe allocated channels can not be used in the other cells. Further investigation is needed how muchspare capacity is wasted. For the time being we assume that a calculation with 80 PDCHs should give

enough margin.


48/85




Airlink data capacity per BCF

Variable Meaning

D total amount of data that can be transmitted during the busyhour

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 calculatedby multiplying the total available number of RLC/MAC blocks per hour per BCF by the average amountof data per RLC/MAC blocks [byte].

MAC/RLCMAC/RLC d*BD = 5-4

The total available number of RLC/MAC blocks per hour per BCF is given by the maximum PDCHutilisation times the total number of channels available for GPRS in the BSS divided by the duration ofa RLC/MAC block. The total number of GPRS channels is the sum over all cells of the averagenumber of channels available for GPRS in every single cell. The maximum number of available PDCHper BSS that should be calculated with is 80.

=cells_all

MAC/RLCMAC/RLC t/)n,80min(*B 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 isused, multiplied by the amount of data per RLC/MAC block for CS2.

30*20*d 2CS1CSMAC/RLC += 5-6


49/85



5-19

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 signalingprocedure

d_dlGMM/SM_proc amount of downlink signaling data for a certain GMM or SM signalingprocedure

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 ofthis type. The average amount of uplink data per user is given by the specified amount of uplink bulkdata multiplied by the overhead factor for the uplink bulk data transfer plus the amount of bursty uplinkdata multiplied by the corresponding overhead factor. Additionally the amount of uplink signalling dataper user for GMM and SM signaling has to be added. In the same way this has to be done for the totalaverage amount of downlink data per user.

SM/GMM

types_user_all

ul_burstyuserul_bulkuseruser ul_d))ov*ul_bursty_dov*ul_bulk_d(*(ul_d ++= 5-7

SM/GMM

types_user_all

dl_burstyuserdl_bulkuseruser dl_d))ov*dl_bursty_dov*dl_bulk_d(*(dl_d ++= 5-8The 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 aspecific signalling procedure is given by the amount of data per procedure multiplied by the number ofGMM/SM procedures per user

=procedures_SM/GMM_all

proc_SM/GMMproc_SM/GMMSM/GMM )p*ul_d(ul_d 5-9

= )475*())]125300(*())500525(*[( _/det_/_/ routingSMGMMachSMGMMattachSMGMM PPP ++++

Note: += )__(*_/ useruseruserroutingSMGMM PRAupRAupvP

Note:All values have been taken from Table 26: Uplink.


50/85




=procedures_SM/GMM_all

proc_SM/GMMproc_SM/GMMSM/GMM )p*dl_d(dl_d 5-10

= )375*())]100225(*())450400(*[( _/det_/_/ routingSMGMMachSMGMMattachSMGMM PPP ++++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 ofprocedures 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.

=types_user_all

proc_user_SM/GMMuserproc_SM/GMM )p*(p 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 30*20*d 2CS1CSMAC/RLC +=

2. =cells_all

MAC/RLCMAC/RLC t/)n,80min(*B blocks / hour

3 MACRLCMACRLCdBD

//*=

kbyte/h

4

achSMGMM

typesuserall

attachuserSMGMMuserattachSMGMM

p

pp

det_/

__

__/_/ )*(

=

==

5 += )__(*_/ useruseruserroutingSMGMM PRAupRAupvP

6 =procedures_SM/GMM_all

SM/GMMproc_SM/GMMSM/GMM )p*ul_d(ul_d

7 =procedures_SM/GMM_all

proc_SM/GMMproc_SM/GMMSM/GMM )p*dl_d(dl_d

8 SM/GMMtypes_user_all

ul_burstyuserul_bulkuseruser ul_d))ov*ul_bursty_dov*ul_bulk_d(*(ul_d ++= kbyte peruser per BH

9 SM/GMMtypes_user_all

dl_burstyuserdl_bulkuseruser dl_d))ov*dl_bursty_dov*dl_bulk_d(*(dl_d ++= kbyte peruser 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


51/85



5-21

Calculation Example

Corporate Sector

1 Downlink Bulk Data Transfer transaction per user30 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 / BHbursty traffic (email, WAP) 15.0 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 user35 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


52/85




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 2530*5.020*5.030*20*d 2CS1CSMAC/RLC =+=+= 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 = P GMM / 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 tocalculate 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 beused.


53/85


Issue

bss planning and ion

Documents