b9 bss arch serv guideline ed03it1

7/29/2019 B9 BSS Arch Serv GuideLine Ed03it1

1/135

Alcatel File Reference Date Edition PageB9_BSS_arch_serv_GuideLine_Ed03it1.doc 3DF019032911VAZZA June 05, 2007 03 1 / 135

Site

VlizyMobile Radio Division

Originator(s)

P. ChootapaE. Salomon

LM.Palumbo

B9: BSS Architecture Service Guideline

Domain : Network Architecture

Product : GSM B9

Division : Methods

Rubric : GSM/GPRS/EDGE

Type : Guidelines

Distribution codes Internal:

Pre-distribution:

NE Velizy NE Timisora NE Portugal NE Egypt

F.Colin E. Marza Thiago Dias Wessam Yanni

T.Plantier Joao Frade

M.Talayssat

Abstract: The aim of this document is to describe BSS architecture configuration rules &

dimensioning processes in Alcatel release B9. It is recommended to be the guideline for RNE

& TPM people who are involve in BSS architecture aspect.

Key words: BTS, BSC, TC, MFS/GPU/GP, Abis, AterMUX, A, and Gb; B9 release

Appraisal and approval authorities

NE Jerome Andres

DD-MM-YY: Signature: DD-MM-YY: Signature:

NE / GSM

Enginnering

Florent Colin

DD-MM-YY: Signature:

All Alcatel system details given in this document are for your comfort only. The

system information may not reflect the latest status of the equipment used in your

project. Please consult in addition to this document the latest product descriptions!


2/135

Alcatel File Reference Date Edition Page

B9_BSS_arch_serv_GuideLine_Ed03it1.doc 3DF019032911VAZZA June 05, 2007 03 2 / 135

Table of contents

1 INTRODUCTION..................................................................................13

2 OVERVIEW OF BSS ARCHITECTURE SERVICES ....................... 14

2.1 WHAT IS THE BSS ARCHITECTURE ? ........................................................................14

2.2 BSS ARCHITECTURE SERVICES ................................................................................17

2.3 BSS ARCHITETURE IMPACT IN B9.........................................................................24

3 DETAILED BSS ARCHITECTURE PROCESS ................................. 29

3.1 BTS........................................................................................................................29

3.1.1 BTS Configurations.......................................................................................29

3.1.1.1 Cell Configuration....................................................................................32

3.1.1.2 SDCCH Configuration ..............................................................................32

3.1.2 Determination of BTS configuration .................... ..........................................34

3.1.3 Cell dimensioning..........................................................................................35

3.1.3.1 SDCCH Dimensioning ..............................................................................35

3.1.3.2 TCH/PDCH Dimensioning .............................. ..........................................37

3.2 ABIS INTERFACE......................................................................................................43

3.2.1 Abis Configuration..................................................................... ...................43

3.2.1.1 Abis Network Topology ............................................................................43

3.2.1.2 Abis Channels ...........................................................................................45

3.2.1.3 Abis Link Capacity................................................................. ...................47

3.2.1.4 Signaling Sub-Multiplexing Schemes ........................................................47

3.2.1.4.1 No Multiplexing......................................................................................................................... 48

3.2.1.4.2 16K Static Multiplexing............................................................................................................. 48

3.2.1.4.3 64K Statistical Multiplexing ...................................................................................................... 49

3.2.1.4.4 16K Statistical Multiplexing ...................................................................................................... 52

3.2.1.5 Secondary Abis Link ................................................................................53

3.2.2 Abis Dimensioning ..................................................................... ...................54

3.2.2.1 Case #1: B8 with No GPRS/EDGE B9 with EDGE ..............................55

3.2.2.2 Case #2: B8 with GPRS/EDGE B9 with EDGE....................................55

3.2.2.3 Case #3: B9 with EDGE........... .................................................................61


3/135



3.3 BSC........................................................................................................................68

3.3.1 G2 BSC Configuration ..................................................................................68

3.3.1.1 BSC Capacity ............................................................................................69

3.3.1.2 Abis TSU ..................................................................................................69

3.3.1.3 Ater TSU...................................................................................................72

3.3.2 BSC Evolution Configuration .............................. ..........................................73

3.3.2.1 BSC Capacity ............................................................................................74

3.3.2.2 Delta BSC Evolution versus G2 BSC ........................................................75

3.3.2.3 CCP board.................................................................................................75

3.3.2.4 LIU shelf...................................................................................................76

3.3.3 BSC Dimensioning ..................................................................... ...................77

3.3.3.1 Design BSC area .......................................................................................78

3.3.3.2 Parenting Abis ports of the BSC ................................................................79

3.3.4 LA Dimensioning................................................. ..........................................81

3.3.5 RA Dimensioning ..........................................................................................85

3.3.6 Summary of LA/RA dimensioning process......................................................87

3.4 ATERMUX AND A INTERFACES ...............................................................................89

3.4.1 AterMUX configuration.................................................................................90

3.4.1.1 AterMUX CS and A .................................................................................91

3.4.1.2 AterMUX PS.............................................................................................92

3.4.1.3 AterMUX CS/PS.......................................................................................94

3.4.2 AterMUX Dimensioning ................................................................................96

3.4.2.1 AterMUX CS ............................................................................................96

3.4.2.1.1 SS7 Dimensioning ..................................................................................................................... 97

3.4.2.1.2 A Dimensioning:...................................................................................................................... 101

3.4.2.2 AterMUX PS...........................................................................................102

3.4.2.2.1 Process description .................................................................................................................. 102

3.4.2.2.2 GSL Dimensioning .................................................................................................................. 106

3.4.2.2.3 GCH/AterMUX-PS Dimensioning .......................................................................................... 110

3.4.2.3 AterMUX CS/PS.....................................................................................113

3.5 TC ........................................................................................................................114

3.5.1 G2 TC Configuration...................................................................................114

3.5.2 G2.5 TC Configuration................................................................................115

3.5.3 TC Dimensioning ........................................................................................116

3.6 MFS .....................................................................................................................117


4/135



3.6.1 The 1st

MFS generation (A9135 MFS) .........................................................117

3.6.1.1 GPRS Processing Unit (GPU)................................................. .................118

3.6.1.2 Multiple GPU per BSS ............................................................................118

3.6.1.3 Capacity ..................................................................................................119

3.6.2 MFS Evolution (A9130 MFS) .............................. ........................................119

3.6.2.1 Configurations and Capacity....................................................................120

3.6.2.2 Delta MFS Evolution versus the 1st

MFS generation................................120

3.6.3 GPU/GP Dimensioning and AterMux PS dimensioning (user traffic) ..........121

3.6.3.1 Required GCH traffic estimation in case of stable network ......................123

3.6.3.2 Required GCH estimation in anticipation of feature activation.................126

3.6.3.2.1 Increase_factor estimation ..................................................................................................... 126

3.6.3.3 GPU/GP GCH capacity estimation ..........................................................127

3.6.3.4 GPU/GP limitations................................................................ .................129

3.7 GB INTERFACE .......................................................................................................133

3.7.1 Gb Configuration ........................................................................................133

3.7.2 Gb Dimensioning ........................................................................................134


5/135



INDEX OF FIGURES

Figure 1: BSS Architecture...................................................................................................14

Figure 2: TRX configuration on Um interface.......................................................................15

Figure 3: Abis configuration.................................................................................................15

Figure 4: AterMUX configuration Dedicated AterMUX for CS traffic...............................16

Figure 5: A interface configuration.......................................................................................16

Figure 6: BSS Architecture Services.....................................................................................17

Figure 7: Network Architecture Setup and Evolution process ...............................................18

Figure 8: BSC/LAC/RAC (re) design - example ...................................................................19

Figure 9: Abis TSU port (re) design......................................................................................21

Figure 10: Network architecture assessment process.............................................................22

Figure 11: EGCH link in B8 vs M-EGCH link in B9 ............................................................24

Figure 12: Wasted Abis nibbles case in B8 ..........................................................................26

Figure 13: Enhance transmission resource management........................................................26

Figure 14: AterMUX TS reserved by GPU/GP Ater TS margin ............................................27

Figure 15: Better transmission resource usage with DL retransmission in the BTS ...............28

Figure 16: BTS generation/type supported in B9................................................................29

Figure 17: Determination of BTS configuration....................................................................34

Figure 18: SDCCH dimensioning process.............................................................................36

Figure 19: TCH/PDCH dimensioning process.......................................................................39

Figure 20: TCH/PDCH dimensioning assessment.................................................................42

Figure 21: Abis Chain (Multi-drop) Topology ......................................................................43


6/135



Figure 22: Abis Star Topology..............................................................................................44

Figure 23: Abis Ring (Closed loop) Topology ......................................................................44

Figure 24: Secondary Abis Topology....................................................................................45

Figure 25: TRX - Abis mapping ...........................................................................................46

Figure 26: Example of Abis TS usage for 1 BTS/4 TRX No Multiplexing.........................48

Figure 27: Example of Abis TS usage for 1 BTS/4 TRX 16K Static Multiplexing .............49

Figure 28: 64K Statistical Multiplexing MCB 64/1 mapping .............................................50



Figure 31: Example of Abis TS usage for 1 BTS/4 TRX 64K Statistical Multiplexing.......51


Figure 33: Example of Abis TS usage for 1 BTS/4 TRX 16K Statistical Multiplexing.......52

Figure 34: Abis TS configuration on primary and secondary links ..................... ...................53

Figure 35: Abis dimensioning process, from B8 with GPRS/EDGE to B9 with EDGE.........56

Figure 36: BTS configuration example of Abis dimensioning from B8 with EDGE to

B9 with EDGE...............................................................................................................57

Figure 37: MCS link adaptation vs. radio condition C/I ........................................................59

Figure 38: Abis dimensioning process Method 1................................................................62

Figure 39: Abis dimensioning process Method 2................................................................66

Figure 40: Abis method algorithm ........................................................................................66

Figure 41: Abis dimensioning process ........... .......................................................................67

Figure 42: G2 BSC (A9120 BSC) Architecture.....................................................................68

Figure 43: G2 BSC Cabinet layout .......................................................................................69


7/135



Figure 44: Abis TSU G2 BSC............................................................................................70

Figure 45: Ater TSU G2 BSC............................................................................................72

Figure 46: BSC Evolution (A9130 BSC) HW Architecture...................................................73

Figure 47 Abis and Ater allocationon LIU boards / BSC capacity..................... ...................77

Figure 48: BSC dimensioning process ........... .......................................................................77

Figure 49: BTS position & configuration design BSC area step 1 ................... ...................78

Figure 50: Transmission planning & BSC position design BSC area step 2........................79

Figure 51: BSC area definition design BSC area step 3......................................................79

Figure 52: Transmission load checking.................................................................................80

Figure 53: BTS / Abis parenting on BSC done by AMT.NET ..........................................81

Figure 54: LA dimensioning assessment...............................................................................84

Figure 55: Subdivision of a LA in GPRS routing areas (RA) ................................................85

Figure 58: AterMUX and A relationship...............................................................................89

Figure 59: AterMUX interface structure ...............................................................................90

Figure 60: AterMUX CS interface configuration G2 BSC..................................................91

Figure 61: Channel mapping between AterMUX CS and A..................................................92

Figure 62: AterMUX PS interface configuration - GPU........................................................93

Figure 63: Sharing AterMUX links.......................................................................................94

Figure 64: AterMUX CS/PS Timeslot configuration.............................................................95

Figure 65: AterMUX-CS dimensioning process....................................................................97

Figure 66: Difference between Exact busy hour, RNO busy hour and Peak traffic ................98

Figure 67 AterMux-PS dimensioning process at BSC level.................................................103


8/135



Figure 68 AterMux PS process at GPU/GP level ................................................................104

Figure 69 GSL usage factor .........................................................................................109

Figure 70: TC dimensioning process...................................................................................116

Figure 71: The 1st

MFS generation (A9135 MFS) Architecture...........................................117

Figure 72: Multiple GPU per BSS ......................................................................................118

Figure 73: GPU/GP dimensioning process..........................................................................122

Figure 74 AterMux PS dimensioning process based on user traffic.................... .................123

Figure 75 Example of GCH/PDCH traffic relationship in case of AterMux PS

underdimensioning.......................................................................................................125

Figure 76 GCH vs PDCH traffic relationship: example.......................................................125

Figure 77 GCH vs PDCH evolution in case of EDGE/CS3/CS4 activation .........................126

Figure 78 GPU_for_Power_Limitation due to PMU CPU load...........................................131

Figure 79 GPU_for_Power_Limitation due to DSP CPU load ............................................131

Figure 80: Gb interface connections ...................................................................................133

Figure 81: Gb dimensioning process...................................................................................134


9/135



INDEX OF TABLES

Table 1: BSC-MFS/GPU/GP-TC (re) design .............................. ..........................................20

Table 2: GCH consumption B8 vs. B9 ...............................................................................25

Table 3: Congifuration G1 BTS MKII with DRFU ............................................................29

Table 4: Configuration G2 BTS.........................................................................................29

Table 5: Configuration Evolium BTS ................................................................................30

Table 6: Configuration Evolium Evolution .............................. ..........................................31

Table 7: BTS HW Capability in B9 ......................................................................................31

Table 8: Cell Types ..............................................................................................................32

Table 9: Frequency Hopping supported in B9.......................................................................32

Table 10: Recommended SDCCH configuration for a standardcell only FR TRXs...........34

Table 11: Counter list - SDCCH dimensioning .................................................. ...................35

Table 12: Counter list - TCH dimensioning ..........................................................................37

Table 13: Counter list - PDCH dimensioning........................................................................38

Table 14: RLC data block size for each (M) CS....................................................................41

Table 15: Abis Channel Types..............................................................................................47

Table 16: Number of TS available in one Abis link .................... ..........................................47

Table 17: Counter list MCS distribution ............................................................................61

Table 18: Counter list - Abis dimensioning Method 1...........................................................62

Table 19: Counter list - Abis dimensioning Method 2.1 ........................................................65

Table 20: G2 BSC Capacity..................................................................................................69

Table 21: TSL/TCU Mapping...............................................................................................71


10/135



Table 22: BSC Evolution Capacity .......................................................................................75

Table 23: Counter list LA dimensioning ........... .................................................................81

Table 24: Counter list RA dimensioning........... .................................................................85

Table 27: Max number of AterMUX CS interfaces G2 BSC ..............................................91

Table 28: Max number of A interfaces G2 BSC.................................................................92

Table 29: Max number of AterMUX PS G2 BSC ...............................................................93

Table 30: Ratio of Mixing CS and PS Traffic in Atermux.....................................................95

Table 31: Counter list AterMUX-CS dimensioning............................................................96

Table 32: Counter list GSL dimensioning ........................................................................106

Table 33: Counter list GSL dimensioning ........................................................................108

Table 34: G2 TC/ G2.5 TC capabilities...............................................................................114

Table 35: G2 TC configuration...........................................................................................114

Table 36: G2.5 TC configuration........................................................................................115

Table 37: G2.5 TC capacity................................................................................................115

Table 38: The 1st

MFS generation (A9135 MFS) Capacity .................................................119

Table 40: Counter list - GPU/GP dimensioning ................................................. .................122

Table 43: Counter list - Gb dimensioning ...........................................................................134


11/135



History:

Edition Date Originator Comments

Draft 15-Feb-06 Pancharat Chootapa

Eric Salomon

Creation

Ed01 30-Mar-06 Pancharat Chootapa Update Abis, Ater-PS, GPU dimensioning

Ed02 5-Sep-06 Pancharat Chootapa Abis dimensioning CS & PS traffic

Gb dimensioning Erlang C

GPU capacity with PDCH/GCH limitation

GSL dimensioning

Ed03it1 05-June-07 LM.Palumbo B9MR4 Specific:

TWIN TRX

GP capacity improvement withrespect to GPU capacity

Other modifications:

AterMux dimensioning update

GPU dimensioning update

GSL dimensioning update

References:

[1] 3BK 17422 5000 PGZZA B9 BSS Configuration Rules release B9 from MR3

[2]3BK 10204 0608 DTZZA Enhanced Transmission Resource Management

Release B9

[3] 3BK 17025 0062 DSZZAIntroduction of DRFU on G1 MK II BTS Principle

of Method

[4] 3BK 17025 0061 DSZZAIntroduction of DRFU on G2 BTS Principle of

Method

[5] 3BK 11210 0157 DSZZA G3 BTS Architecture and Principles

[6] 3BK 11210 0328 DSZZA BTS G4 Architecture and Principles

[7] 3DC 21083 0001 TQZZAEVOLIUM A9100 Base Station Productdescription

[8] 3BK 10204 0511 DTZZA SFD: Dynamic SDCCH allocation

[9] 3DF 01903 2810 PGZZA 01BSS B8 Dimensioning Rules

Configuration Description


12/135



[10] 3DC 20003 0025 UZZZADimensioning Rules for CS and PS traffic with BSS

Software Release B9

[11] 3DC 21150 0323 TQZZAGSM/GPRS/EDGE Radio Network Design Process

for ALCATEL BSS Release B9

[12] 3DC 21016 0005 TQZZA A9135 MFS Product Description

[13] 3DF 00995 0005 UAZZA GPRS/E-GPRS Radio Network Planning Aspects

[14] 3BK 11203 0100 DSZZA GPRS resource usage and dimensioning B8 release

[15] 3BK 09722 JAAA DSZZA GPRS management functional specification


13/135



1 INTRODUCTION

The aim of this document is to describe BSS architecture configuration rules &

dimensioning processes in Alcatel release B9.

It is recommended to be the guideline for RNE (Radio Network Engineer) & TPM

(Techinical Project Manager) people who are involve in BSS architecture aspect.

This document is organised as below:

Part I: Overview of BSS Architecture Service

The purpose of this part is to give the reader the overview of the architecture

service for the BSS network which consists of: -

- The global picture of BSS network architecture together with the short

definition for each network elements and interfaces

- Describing overall processes for each BSS architecture service

- The short presentation about B8/B9 impacts to BSS architecture. The main

impacts are linked to several new features introduced in release B9.

Part II: Detailed BSS Architecture Processes

This part describes in the details of the main network configuration rules in

release B9 and the dimensioning processes, which are related to counter analysis.

It covers the following BSS network elements and interfaces:

- BTS

- BSC- MFS/GPU/GP

- TC

- Abis interface

- AterMUX interface

- A interface

- Gb interface


14/135



2 Overview of BSS Architecture Services

This section gives an overview of the BSS architecture. It describes briefly all the

components in the BSS together with their key functions and the global BSS architecture

processes.

2.1 What is the BSS Architecture ?

Figure 1: BSS Architecture

BSS stands for Base Station Subsystem.

The main role of the BSS is to provide and support both bi-directional signaling and CS

traffic channels (respectively PS traffic channels) between the Mobile Station andNetwork SubSystem or NSS (respectively GPRS SubSystem or GSS).

As presented in the Figure 1, the BSS consists of several network elements and

interfaces.

BSS Network Elements

BTS (Base Transceiver Station): providing radio links between theMobile Stations and the BSC.

BSC (Base Station Controller): controlling several BTSs.

TC (TransCoder): providing speech conversion between the 16 kbits/schannel (from/to BSC side) and the 64 kbits/s channel (from/to the

MSC 1).

MFS (Multi-BSS Fast packet Server): To be able to support PS traffic,

a MFS is introduced in the BSS in order to manage data packets.

1MSC (Mobile Switching Center) is a main network element of the NSS having connection to the BSS.

BTS

BTS

BTS

BSC

MFS

TC

NSS

(CS traffic)

GSS

PS traffic

Um Abis

AterMUX CS

Gb

A

BSS (CS+PS traffic)

AterMUX PS

AterMUX CS/PS


15/135



BSS Interfaces

Um (air or radio) interface: connecting between MS and BTS

It consists of a group of TRXs and the group size is based on the BTS traffic.

Figure 2: TRX configuration on Um interface

Each TS of a TRX can provide a channel with various throughputs i.e. FR, EFR,

HR and AMR available for CS traffic while GPRS CS 1-4 and EDGE MCS 1-9

available for PS traffic.

As a radio TS is dynamically allocated to serve either CS or PS traffic, the TS is

called as TCH while it supports CS traffic; otherwise called as PDCH while it

supports PS traffic.

Abis interface: connecting between BTS and BSC

It is usually a 2 Mbps link (64kbps * 32 TSs). Max. 2 links are possible for 1 BTS.

Figure 3: Abis configuration

Each TS contains 4 16kbps-channels or nibbles.

Based on the corresponding radio TS; at one moment, a given nibble can be called

either as TCHif its corresponding radio TS is TCH; or as GCHif its corresponding

radio TS is PDCH.

Other Abis TSs can carry signaling (RSL and OML), or extra TS.

AterMUX interface: providing connections between:

- - BSC and TC

- BSC and MFS

- MFS and TC (in case of AterMUX transporting mixed Traffic CS & PS)

TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7

TRX

Abis

CH# 1 CH# 2 CH# 3 CH# 4

TS 0

TS 1

:

:

TS 26

TS 27

TS 28 TCH / GCH TCH / GCH TCH / GCH TCH / GCH

TS 29 TCH / GCH TCH / GCH TCH / GCH TCH / GCH

TS 30

TS 31

TS : 64 Kbits/sec

Channel or Nibble : 16 Kbits/sec

TS 0 Transparency

OML

RSL

Extra TS

Extra TS

:

:

Free

Mapping to 1 TRX

of Um Interface


16/135



In general, the AterMUX is also a 2 Mbps link (64kbps * 32 TSs). However,

differently from Abis, every nibbles on AterMUX are already defined to be TCH or

GCH or signaling channels.

Figure 4: AterMUX configuration Dedicated AterMUX for CS traffic

A interface: connecting between TC and MSC

It is supported by 2 Mbps PCM links (64kpbs * 32 TSs).

One 64 kbps channel on A is corresponding to one 16 kbps channel on AterMUX

TC is responsible for this channel speed conversion.

Figure 5: A interface configuration

The A trunk can carry up to 31 traffic channels identified by a CIC (CIC: Circuit

Identification Code)

Gb interface: connecting between MFS and SGSN2

It is supported by 2 Mbps PCM links (64kpbs * 32 TSs), which can be based on

Frame Relay Network.

-----------------------------------------------------------------------------------------------------------------2

SGSN (Serving GPRS Support Node) is a main network element of the GSS having connection to the BSS.

A Interface

TS 0

TS 1

TS 2

TS 3

:

:

:

:

TS 30

TS 31

TS : 64 Kbits/sec

CIC 1

CIC 2

CIC 3

:

:

:

:

CIC 30

Frame Synchronization

CIC 31

AterMUX CS

CH# 1 CH# 2 CH# 3 CH# 4

TS 0

TS 1 TCH TCH TCH TCH


:

:

TS 14 Qmux TCH TCH TCH

TS 15

TS 16



:

:


TS 31

TS : 64 Kbits/sec

Channel or Nibble : 16 Kbits/sec

Frame Synchronization

Alarm octet

SS7

X25

:

:

:

:


17/135



2.2 BSS Architecture Services

Scope:

The BSS architecture services cover the main tasks to be performed for designing the

BSS network topology and for dimensioning the BSS network elements and interfaces.

Goal:

It is to define the BSS capacity and topology, which is appropriate and necessary to be

able to support the real network traffic or to fit new requirements for network evolution.

Category:

According to different network states, the BSS architecture services can be classified

into:

1) Network Architecture SETUP

This service is providing the BSS architecture design for a new network.

2) Network Architecture ASSESSMENT

For an existing network, it is important to perform this service to check periodically

the network performance from architecture point of view.

3) Network Architecture EVOLUTION

The BSS architecture should be re-designed in case of some network evolutions

e.g. network extension (to be adapted to a forecasted traffic scenario) and new

network feature activation (GPRS CS 3-4 or EDGE, for instance).

Figure 6: BSS Architecture Services

Network Architecture

Evolution


Assessment


SetupInitial

Steady

Developing

BSS Architecture Services Network State


18/135



Process:

There are 2 different processes defined, one for supporting the services network

architecturesetup andevolution, and the other one for supporting the service network

architectureassessment.

I) Process for Network Architecture SETUP and EVOLUTION

It is considered the same process can be applied for these two BSS architecture services;

see the process diagram below.

Figure 7: Network Architecture Setup and Evolution process

START

(1) Gathering Data

(2) Design/Re-design

(2b) BSC/MFS (GPU/GP)/TC Configuration

(2d) Parenting Abis TSU/LIU ports of the BSC

(2a) BSC/LAC/RAC Areas

(2c) Number of interfaces: Abis, AterMUX, A and Gb

(3) Operational Implementation, according to (2)

FINISH

NW Configuration Rules


19/135



Step (1) Gathering data

The first step is to gather the architecture data from the network:

NE specifications i.e. type of BTS, BSC, MFS, TC.

NE locations. Current BSS network topology (architecture) available in case of

network evolution.

Defined configuration e.g. TRX configuration (BCCH combined or

non-combined and number of SDCCH).

-

Step (2) Design / Re-design

This step will be considered as design in case of network setup but re-design in case of

network evolution of which current design already existed.

The architecture (re)-design should be performed for each BSS network elements and

interfaces, based on the data from Step 1 and also strictly respected to Networkconfiguration rules for more details, please refer to [1].(2a) BSC/LAC/RAC Areas

Since the data about TRX configuration and BTS location are known (from step 1),

the (re)-design will start with defining the BSC/LAC/RAC area based on

geographical point of view.

The following is the example of BSC/LAC/RAC (re) design.

Figure 8: BSC/LAC/RAC (re) design - example

Fore more details, please refer to section 3.3.3.1 for BSC area design, section 3.3.4 for

LAC design and section 1.1.1 for RAC design.


20/135



(2b) BSC/MFS (GPU/GP)/TC Configuration

BSC:

An appropriate type and configuration has to be chosen for each BSCs in order to

provide the sufficient capacity to support their resource usage (e.g. number of TRX,

BTS, Abis, etc. is required for a BSC), which is related to the BSC area in theprevious (re)-design.

MFS (GPU/GP) and TC:

According to the defined BSC configuration and the CS traffic (respectively PS

traffic), we can continue to design the configuration of TC (respectively

MFS/GPU/GP).

Therefore, the outcome of (re)-design should provide the following information.

BSC MFS/GPU/GP TC

Type A9120 BSC,

A9130 BSC, etc

A9135 MFS, A9130

MFS, etc

G2 TC, A9125

Compact TC, etc

Configuration - Config 1, 2, 3,

4, 5 or 6 for

A9120 BSC

- Stand Alone /

Rack shared

Configuration

with 200TRX,

400TRX,

600TRX for

A9130 BSC

- Nb of GPU/GP

boards dedicated to

each BSC

- Nb of MFS racks

- Nb of TC boards

dedicated to

each BSC

- Nb of TC racks

Table 1: BSC-MFS/GPU/GP-TC (re) design

Fore more details, please refer to section 3.3 for BSC configuration, section 3.5 for TC

configuration, and section 3.6 for MFS configuration.

(2c) Number of interfaces; Abis, AterMUX, A and Gb

After the configuration of all BSS network elements is defined, it comes to the step to

design interfaces connecting them.

In general, we have to design the numberof needed interface links.

However, additional characteristic has to be designed for some interfaces:


21/135



- Abis: Type of signalling sub-multiplexing schemes, BTS in multidrop and

number of extra Abis TS (in case of supporting GPRS CS3-4 and EDGE).

- AterMUX: Type of Traffic i.e. CS, PS or Mixed CS/PS.

- Gb: Number of 64 kbits/s TSs configured in a link

Fore more details, please refer to section 3.2 for Abis, section 3.4 for AterMUX & A,and section 0 for Gb.

(2d) Parenting Abis TSU ports of the BSC

The final (re)-design is to assign the dedicated Abis TSU (at BSC side) for each Abis

link (from BTS side).

To perform parenting Abis TSU, please refer the Abis TSU configuration rules in

section 3.3.1.2.

However, ARO/ACC has developed the archiecture management tool, so calledAMT.NET, which assists the radio network engineer to design efficiently the

parenting Abis TSU in the convenient way.

For more details, please refer to websitehttp://pcs.tm.alcatel.ro/Amt)Below is an example of parenting Abis TSU, which is done by AMT.NET tool.

Figure 9: Abis TSU port (re) design

Step (3) Operational Implementation

According to the results from all architecture (re)-designs in step 2, the operational

implementation should include the following activities:


22/135



The extension of Network elements i.e. new configuration and/or new

resources.

BTS Cutover, either intra BSC (i.e. change the connected Abis TSU

port within the same BSC) or inter BSC (different BSC).

Parameter modification.

II) Process for Network Architecture ASSESSMENT

The aim of the process is

- To analyze traffic flows in the network at different levels (NE & Interfaces).

- To assess the actual flows versus the installed BSS architecture capacity: over

dimensioning implies over investment, under dimensioning implies bottlenecks,

congestion and unbalanced investments.-

- The process diagram for network assessment is presented below.

Figure 10: Network architecture assessment process

Step (1) Gathering data

The first step is to gather 2 different kinds of data from the network:

FINISH

START

(1) Gathering DataNW Configuration Rules

Recommendation/Threshold

(2) Applying Dimensioning MethodsCounters/Indicators vs. Configuration analysis

for each Network Elements and Interfaces

(3) Assessment

- Identify bottle necks

- Identify need of new resources / new configuration


23/135



Traffic data: relevant counters or indicators retrived from OMC-R or

NPA/RNO machines.

BSS network topology data: the existing number, location and

configuration of each BSS network elements and interfaces.

Step (2) Applying dimensioning methods

It is the process to analyse the traffic counters (or indicators) by applying the defined

dimensioning methods and the Network configuration rules. The traffic analysis

should be done individually at different level of NE and interfaces.

BSS network elements:

CELL dimensioning (for more details, please refer to section 3.1.3)

BSC dimensioning (for more details, please refer to section 3.3.3)

TC dimensioning (for more details, please refer to section 3.5.3)

GPU/GP dimensioning (for more details, please refer to section 3.6.3)

BSS interfaces:

Abis dimensioning (for more details, please refer to section 3.2.2)

AterMUX dimensioning (for more details, please refer to section 3.4.2)

A dimensioning (for more details, please refer to section 3.4.2.1)

Gb dimensioning (for more details, please refer to section 3.7.2)

Step (3) Assessment

This is the last process to assess the installedcapacity versus usedcapacity (refer to

the traffic analysis results from step 2), based on the recommendation and given

thresholdat all levels of the BSS.

The assessment can identify the existing bottleneck that implies the lack of resources

or unbalanced resource usage.

Therefore, the proposed solutions should be implementing new resources and/or new

configuration and probably parameter modification.


24/135



2.3 BSS Architeture Impact in B9

In B9 release: there is high improvement in term of architecture point of view,

especially for the transmission resource (Abis & AterMUX) management, due to the

benefits from the introduction of some new features.

B9 features brought the architecture gains include:

M-EGCH Statistical Multiplexing

In order to carry PS-related data, a bi-directional link needs to be established between

the MFS and the BTS (through the BSC).

In B9 release, that link is called M-EGCH link (M standing for Multiplexed) for

Evolium BTS. Contrary to B8 release where an EGCH link was defined per radio TS,

an M-EGCH link is defined per TRX.

Figure 11: EGCH link in B8 vs M-EGCH link in B9

As M-EGCH concept presented in Figure 11, the M-EGCH Statistical Multiplexing

feature allows the reduction of the consumption of GCH resources (especially on Ater)

by multiplexing the blocks of all the PDCHs of a TRX on a single transmission link (M-

EGCH link), instead of using a single EGCH link per PDCH.

In Table 2, there is the summary showing the GCH usage gain in B9 - thanks to M-EGCH compared to B8 for each coding scheme (except no gain for MCS8, because

MCS8 (corresponding to TRX class 4) in B8 does not support in UL whereas it is

possible in B9 and basically more GCH is used in UL). For instance, to support MCS 9,

there are 40 GCHs per TRX needed in B8 but only 36 GCHs per TRX needed in B9.


25/135



Table 2: GCH consumption B8 vs. B9

M-EGCH Statistical Multiplexing is mandatory feature (automatically enabled) in B9.

For more details, please refer to [2].

Dynamic Abis Allocation

This feature enables to dynamically allocate Abis nibbles among the different TREs

used for PS traffic in a given BTS. Compared to B8, it allows a higher average Abis

bandwidth per PDCH, the BSC capacity in terms of TREs is increased, and in some

BTS configurations it may avoid to deploy a second Abis link.

In B9 release, the concept of pool of Abis nibbles is introduced:

A pool of Abis nibbles is a set of basic and extra Abis nibbles, which can be

dynamically allocated among the M-EGCHs of some TREs.

So, the pool of Abis nibbles is at a higher level of sharing than the M-EGCH (whose

sharing is at TRX level), however, the level of sharing of the pool of Abis nibbles

depends on the type of Abis resources:

- The basic Abis nibbles mapped to a PDCH currently available for PS traffic or

mapped to a MPDCH can be shared at the cell (BTS sector) level. In case of cell split

over 2 BTSs, the share can be done only for one of the two BTS sectors of the cell. This

means that only one of the BTS sectors of the cell will be PS capable (new O&M

constraint in B9 release).-

- The bonus basic Abis nibbles currently used for BCCH or static SDCCH channelscan be shared at the BTS level. It means that they can be shared between the different

sectors of the same BTS cabinet.-

- The extra Abis nibblescan be shared at the BTS level. It means that they can be

shared between the different sectors of the same BTS cabinet.

GCH per RTS GCH per TRX GCH per RTS GCH per TRX

CS1 1 8 0.73 6CS2 1 8 1.00 8CS3 2 16 1.25 10

CS4 2 16 1.64 14MCS1 1 8 0.89 8MCS2 1 8 1.00 8MCS3 2 16 1.33 11MCS4 2 16 1.50 12MCS5 2 16 1.86 15MCS6 3 24 2.36 19MCS7 4 32 3.49 28MCS8 4 32 4.14 34MCS9 5 40 4.49 36

Coding

Schemes

B8 (w/o stat mux) B9 (with M-EGCH stat Mux)


26/135



Figure 12: Wasted Abis nibbles case in B8

In Figure 12, there is a noticeable waste of Abis resources in B8 release linked to static

Abis allocation but it can be improved in B9 with dynamic Abis allocation feature

which can manage to use basic Abis nibbles mapping to signalling channels i.e. BCCH

and SDCCH (so called bonus basic nibbles) and all extra Abis nibbles for PS traffic

so no more wasted Abis nibbles in B9.

Dynamic Abis allocation is mandatory feature (automatically enabled) in B9.


Enhance Transmission Resource Management

The Enhanced transmission resource management feature can be seen on top of the the

M-EGCH Statistical Multiplexing and Dynamic Abis allocation features.

Indeed, it assumes that the M-EGCH Statistical Multiplexing feature is implemented in

RLC/MAC layers, and it relies on the Dynamic Abis allocation feature which offers a

means to dynamically adjust (increase or decrease) the M-EGCH link size of the TRXs.

Figure 13: Enhance transmission resource management


27/135



The main goals of the Enhanced transmission resource management feature are the

following:

- Determine the M-EGCH link size of all the TRXs and the nature of their GCHs.

- Create/release the M-EGCH links of the TRXs, add/remove/preempt some GCHs over

the M-EGCH links of the TRXs.

- Manage the Abis congestion situations at BTS leveland the Ater congestion situations

at GPU/GP level by applying some equity rules.

- Ensure GPRS access in all the cells.-

Enhanced transmission resource management is mandatory feature (automatically

enabled) in B9. For more details, please refer to [2].

Ater Resource Management

The Ater Resource Management in a given GPU is based on two complementary

mechanisms:

- GPU/GP Ater TS margin

Goal: Ensure that GPRS access never be blocked in a cell due to lack of Ater

resources in the GPU.

Mean: Reserve at least N_ATER_TS_MARGIN_GPU (O&M parameter) timeslots

in GPU/GP to serve only new prioritary TBF establishment.

Figure 14: AterMUX TS reserved by GPU/GP Ater TS margin

-

- High Ater usage handling

It is the way to manage the Ater resource when Ater usage enters high state

determined by the parameter Ater_Usage_Threshold.

If Ater usage is high, the target number of GCH associated to TRXs of the GPU/GP

will be reduced according to GCH_RED_FACTOR_HIGH_ATER_USAGE (O&M

parameter). However, this reduction factor is only applied on PDCHs newly open.

Ater Resource Management is mandatory feature (automatically enabled) in B9. For

more details, please refer to [2].

Atermux PCM link

64 kbit/s timeslot # 0

64 kbit/s timeslot # 1

.64 kbit/s timeslot # n

...

0 1 2 3

N_ATER_TS_MARGIN_GPU

Ater TS Reserved in GPU for prioritary request


28/135



DL retransmission in the BTS

The principle of this feature is to store, in the memory of the TREs of the BTSs, the DL

RLC data blocks transmitted by the MFS to the MS. This avoids consuming

transmission resources (Abis + Ater) in case of DL RLC data block retransmissions.

Figure 15: Better transmission resource usage with DL retransmission in the BTS

Without DL Retransmission in the BTS, the RLC/MAC layer shall retransmit the

complete DL RLC data block to the TRE when retransmission needed so called

complete retransmission B8 case.

If DL Retransmission in the BTS is activated, the RLC/MAC layer may take the benefitto store RLC data block by TRE in the BTS. In this case, the RLC/MAC layer may

retransmit to the TRE only RLC/MAC header and ask the TRE to add RLC data block

before transmission to the MS so called reduced retransmission B9 case.

DL Retransmission in the BTS is optional feature, which can be enabled/disabled at

TRX/TRE level. In order to save transmission resource, it is recommended to activate

this feature.



29/135



3 Detailed BSS Architecture Process

This section describes in details of the BSS architecture process in release B9. Several

sub-sections are created to focus on each network elements and interfaces.

3.1 BTSThe area covered by a BSS is divided into cells and each cell is managed by a BTS.

Each BTS consists of radio transmission and reception devices including antennae and

signal processing equipment for the Air Interface.

3.1.1 BTS Configurations

The following diagram presents the BTS generations, which are supported in release B9.

Figure 16: BTS generation/type supported in B9

G1 BTS - First BTS Generation

Only MKII with DRFU is supported in B9. It stays at B7.2 functionality and its

configuration is presented in Table 3.

Data in this table, based on [9]

Table 3: Congifuration G1 BTS MKII with DRFU

For more details, please refer to [1] and [3]

G2 BTS - Second BTS Generation

Only G2 BTSwith DRFUis supported in B9 with following the rule: the FUMO in G2

BTS must be replaced by DRFU before B7/B8 release migration.

G2 BTS stays at B7.2 functionality and its configuration is presented in Table 4.


Table 4: Configuration G2 BTS


Type Characteristic Nb of sectors Nb of TRX GSM 900MKII Std + DRFU 1 8 x

Extension / Reduction

Physical LogicalMin Max

G2 1 TRE 1 Sector: 8 TRE 1 TRE 1 TRE

ConfigurationBTS

Min

BTS

Generation

Evolium EvolutionG1 BTS Evolium BTSG2 BTS

- G1 BTS MK II

with DRFU

- G2 BTS DRFU - G3 BTS

- M4M

- G4 BTS -G5BTS

- M5M


30/135



Evolium BTS - Third BTS Generation

The Evolium BTS is designed with some improvements as compared to the previous

BTS generation (G2). The main changes (related to architeture design) are:

- Support Abis Statistical Multiplexing (64 kbps and 16 kbps).

- Secondary Abis link (except micro BTS M4M)

- GPRS CS-3, CS-4 is available.

- Support TWIN TRX modules (B9MR4 only)

With B9 support, Evolium BTSs include G3 BTS, G3.5 BTS (which is G3 BTS with

new power supply modules) and micro BTS M4M. See their configurations in Table 5.

Extension/ReductionConfiguration

Physical LogicalBTS

Min Max MinEvolium BTS

(G3 / G3.5)

1 TRE - Up to 12 TRE (1 to 6

sectors) (before

B9MR4)

- Up to 18 TRE (1 to 6

sectors) (B9MR4)

1 TRE TRE

M4M

(micro BTS)


sectors)

2 TRE 1 TRE


Table 5: Configuration Evolium BTS


Evolium Evolution - Fourth BTS Generation

Further evolutions (from Evolium BTSs) introduce new main features:

- G4 BTS platform is ready for EDGE and E-GPRS.

- GSM 900 output power has been increased to 45W.

- The new architecture of the Transceiver module (digital & analog parts on the

same board) brings the possibility to develop a low power TRE that would allow

achieving a 18 TRX capacity in one rack.

With B9 support, Evolium Evolution BTSs include:

- G3.8 BTS, which is G3.5 BTS with SUMA, ANC, new power supply modules.

- G4.2 BTS, which introdues a new TRE with EDGE HW Capability.

- Micro BTS M5M.

- TWIN TRX modules (B9MR4 only)

Their configurations are presented in Table 6.


31/135



Extension/ReductionConfiguration

Physical LogicalBTS

Min Max Min

Evolium BTS

(G3.8 / G4.2)


sectors) (before

B9MR4)

- Up to 18 TRE (1 to 6

sectors) (B9MR4)

1 TRE 1 TRE

Evolium BTS

(G5)


sectors) (B9MR4)

1 TRE 1 TRE

M5M

(micro BTS)


sectors)

2 TRE 1 TRE


Table 6: Configuration Evolium Evolution

N.B. In case of BTS housing TWIN TRA modules and G3 TRX a maximum number

of 12 TRX is allowed.

For more details, please refer to [1], [6], [7]

Summary BTS Hardware Capability B9 release

As shown in Table 7:


Table 7: BTS HW Capability in B9

G1BTS G2BTSG1 BTS MKII

DRFU G2 BTS DRFU G3 BTS M4M G4 BTS M5M

No Multiplexing x x x x x x

16K Static Multiplexing x x x x x

64K Statistical Multiplexing x x x x

16K Statistical Multiplexing x x x x

2nd Abis access x x x

FR x x x x x x

DR x x x x x x

AMR x x x x x x

EFR x x x x x x

GPRS (CS-1, CS-2) x x x x x x

GPRS (CS-3, CS-4) x x x x

EGPRS (MCS-1 to MCS-9) x x

GSM 850 x x

GSM 900 x x x x x x

GSM 1800 x x x x x

GSM 1900 x x x x

850/1800 x x x

850/1900 x x x

900/1800 x x x x

900/1900 x x x

Multi

band

Evolium BTS Evolium EvolutionB9 release

Abis

feature

Voice

Traffic

Data

Traffic

Mono

band


32/135



3.1.1.1 Cell Configuration

Cell Types: the following table describes all the cell types (with profile type

parameters) available in B9.


Table 8: Cell Types

Extended Cell:

Its configuration is a BTS with up to 4 TRX in the inner cell and up to 4 TRX in the

outer cell.

M4M and M5M do not support extended cell configurations.

Only one extended cell per BTS is possible.

Shared Cell:

A cell shared by several BTSs is possible to support up to 16 TRX.

Only the A9100 Evolium BTS (G3 BTS & G4 BTS) support shared cell.

The BTSs in a shared cell must be clock synchronized.

M4M and M5M do not support a shared cell because they cannot be clocksynchronized.

Frequency Hopping:

The Table 9 shows the hopping types supported in B9.


* RH works only with M1M and M2M that are now obsolete.

Table 9: Frequency Hopping supported in B9

3.1.1.2 SDCCH Configuration

Since B8 release, the dynamic SDCCH allocation feature is a new mechanism that

provides automatic (the optional number of) SDCCH in the cell, which translates as

Hopping Type Supported in B9Non Hopping (NH) x

Base Band Hopping (BBH) x

Radio Hopping (RH) * -

Non Hopping / Radio Hopping (NH/RH) x

NH/RH with Pseudo Non Hopping TRX x

BBH with Pseudo Non Hopping TRX x

Dimension Coverage Partition Range

Micro Micro Overlaid Normal NormalSingle Macro Single Normal NormalMini Macro Overlaid Normal NormalExtended Macro Single Normal ExtendedUmbrella Macro Umbrella Normal NormalConcentric Macro Single Concentric NormalUmbrella-Concentric Macro Umbrella Concentric NormalIndoor Micro Micro Indoor Normal Normal

Profile Type Parameters

Cell Type


33/135



a set of dynamic SDCCH/8 TS, used for TCH traffic or for SDCCH traffic,

depending on the requirement.

Principle:

Static SDCCH sub-channels are defined to handle normal SDCCH traffic.

Dynamic SDCCH sub-channels are defined to handle high SDCCH traffic.

Main Rules:

- At least one static SDCCH/8 or SDCCH/4 timeslot on BCCH TRX must be

configured in a cell.

- Combined SDCCHs (SDCCH/4 + BCCH) are always static.

- The total number of SDCCH sub-channels configured on static or dynamic

SDCCH TS or on a BCCH/CCCH TS (CCCH combined case) must not exceed

24 sub-channels per TRX and 88 sub-channels per cell.

- In order to avoid incoherent allocation strategies between SDCCH and PDCH, adynamic SDCCH/8 TS cannot be a PDCH.

- BTS with DRFU do not support dynamic SDCCH allocation.

- In A9130 BSC Evolution it is not allowed more than one SDCCH TS per TRX.

Recommended SDCCH configuration:

In a cell, the number of SDCCHs is defined variously, based on:

- Location Update (LU) signaling traffic: 1 LU/call for standard cell

- SMS signaling traffic: 0.5 SMS/call for standard cell

- Number of TRXs

Recommended default number of SDCCHs and configuration are presented in Table

10.


Total SDC SDD

1 Yes 12 4 82 Yes 12 4 82 No 24 8 163 No 24 8 164 No 32 8 245 No 32 8 24

6 No 32 8 247 No 40 16 248 No 40 16 249 No 48 16 32

10 No 48 16 3211 No 48 16 3212 No 56 16 4013 No 56 16 4014 No 64 24 4015 No 72 24 4816 No 72 24 48

Number of TRXs BCCH CombinedNumber of SDCCH sub-channels


34/135



Table 10: Recommended SDCCH configuration for a standardcell only FR TRXs

Remarks:

1) SDC means Static SDCCH, SDD means Dynamic SDCCH, and Max presents

the maximum number of SDCCHs (SDC+SDD) that may be allocated in a cell.

2) Up to16 TRXs are possible to be configured for a cell thanks to shared cell

feature.

3) For one TRX, dynamic SDCCH are over-dimensioned because of the

granularity of 8. According to Alcatel traffic model, all dynamic SDCCH will

not be used.

4) An additional dynamic SDCCH/8 must be provided for each DR TRX (these

are expected mainly on small cells).

5) For some particular cells with high (LU and/or SMS) signaling load, the

operator will probably need to customize the number of SDCCHs (different

from the recommendation) according to his requirements; otherwise the

SDCCH dimensioning should be applied (please refer to section 3.1.3.1).


3.1.2 Determination of BTS configuration

For each sites, it is necessary to define the number of required BTSs, which depends

on the total number of required TRXs and cells and maximum capacity of the given

BTS (refer to section 3.1.1).

To determine the number of required TRXs, the cell dimensioning (refer to section

3.1.3) is needed to start first, and then the following processes to determine BTS

configuration will be performed afterwards as shown in Figure 17.

Figure 17: Determination of BTS configuration

Nb ofrequired TRXs

Nb ofrequired cells

Max. Capacity of

the given BTS

Assessment

(comparision)

OKUnder-dimensioning

Increase installed BTSs

Required >

Required =

Required


35/135



3.1.3 Cell dimensioning

The number of required TRXs can be derived from the combination of several kinds of

radio timeslots:

- BCCH TS: 1 TS

- SDCCH TS: to be defined based on SDCCH traffic, more details in section

3.1.3.1

- TCH/PDCH TS: to be defined based on CS/PS traffic, more details in section

3.1.3.2-

And a TRX consists of 8 radio timeslots.

So,

3.1.3.1 SDCCH Dimensioning

Target: To estimate the number of SDCCH resources needed at Cell level.

Gathered Counters:

Counter Name Indicator Name Definition

MC400 SDTRT Cumulated time during which the SDCCH subchannels

belonging to the related static or dynamic SDCCH timeslots are

busy.

MC04 SDNACGN Number of unsuccessful SDCCH subchannel selection (allSDCCH subchannels are busy or Out of Service).

MC148 SDNACAN Number of SDCCH attempts for any other purpose than HO

(Channel Activation).

Table 11: Counter list - SDCCH dimensioning

Measured Object: Cell

Gathering periods: 7-day Busy Hour data, recommended

Otherwise, at least 2 working-day Busy Hour data

Note: Busy Hour means the hour gives the highest SDCCH traffic (i.e MC400) of the day.

Number of TRXs = (BCCH TS + SDCCH TS + TCH/PDCH TS) / 8


36/135



Erlang B

Required

SDCCH Traffic

GoS:

% SDCCH blocking

Nb of requiredSDCCH sub-

channels /

timeslots

INPUT OUTPUTMETHOD

Methodology:

The process of SDCCH dimensioning is presented in Figure 18.

Figure 18: SDCCH dimensioning process

INPUT

The required SDCCH traffic is computed as below formula.

%)30,_(%1

____Re

congSDCCHMin

trafficSDCCHMeasuredtrafficSDCCHquired

=

Note: 30% is defined as the max congestion rate to be considered because several congestions can be

re-produced from one given user trying to access the network several times.

Where:

3600

400__

MCtrafficSDCCHMeasured =

%10014804

04_%

+=

MCMC

MCcongSDCCH

The other input is Grade of Service (GoS), which is defined by the required SDCCH

congestion rate (pSDCCH). Normally GoS should be given or agreed by the Mobile

Operator.

The typical value for the required SDCCH congestion rate is 0.5%.

METHOD

Concerning only CS traffic, the statistical law Erlang B is used during the

dimensioning process to determine the necessary resources versus the traffic and the

target GoS.

As SDCCH is associated to CS traffic only, Erlang B can be applied to calculate the

required number of SDCCH sub-channels according to required SDCCH traffic and

the target congestion rate.


37/135



OUTPUT

Number of required SDCCH sub-channels

= Erlang B (Required_SDCCH_traffic, pSDCCH)

Then,

Number of required SDCCH Timeslots

Nb of required SDCCH sub-channels / 8; for non- BCCH combined cell

(Nb of required SDCCH sub-channels 4) / 8; for BCCH combined cell

Assessment:

When % SDCCH congestion (of any cell) > pSDCCH, the SDCCH re-dimensioning is

needed.

3.1.3.2 TCH/PDCH Dimensioning

Target: To estimate the number of TCH & PDCH resources needed at Cell level.

Gathered Counters: TCH


MC380a TCTRFT Time during which the TCH FR are busy

MC380b TCTRHT Time during which the TCH HR are busyMC812 TCNACGN Number of failures when switching from SDCCH to the TCH

(call establishment only) due to congestion on Air Interface

channels (RTCH).

MC703 TCNACAN Number of TCH successfully selected for any purpose other

than HO.

Table 12: Counter list - TCH dimensioning

Gathered Counters: PDCH


P451b ARPDCTDBUT Cumulative time during which a DL TBF uses on PDCH, for allPDCHs and for all the TBFs of the cell (established in GPRS

mode or EGPRS mode).

P451a ARPDCTUBUT Cumulative time during which a UL TBF uses on PDCH, for all

PDCHs and for all the TBFs of the cell (established in GPRS

mode or EGPRS mode).

P14 QRDTECGN Number of DL TBF establishment failures due to radio

congestion (no radio resource in the MFS at PDU life time

expiry). Applied to GPRS and EGPRS MS.

=


38/135



P27 QRUTECGN Number of uplink TBF establishment failures due to congestion

(no radio resource in the MFS).

P91a + P91b +

P91c + P91d +

P91e + P91f

TRDTERQN Number of DL TBF establishment requests per cell.

P62a + P62b +P62c - P438c

TRUTERQN Number of UL TBF establishment requests per cell.

P38e ARPDCUDBUT Cumulative time during which the slave PDCHs are established

and carry at least one DL TBF (established in GPRS mode or

EGPRS mode).

P38f ARPDCUUBUT Cumulative time during which the slave PDCHs are established

and carry at least one UL TBF (established in GPRS mode or

EGPRS mode).

P20x

(x = a,.. ,d)

QRPDDRxN

(x = 1,.. ,4)

In acknowledged mode, number of DL RLC blocks (except RLC

blocks containing LLC Dummy UI Commands only) on PDTCH

encoded in CS-x (i.e CS-1 (P20a) CS-4 (P20d)) retransmitted

due to unacknowledgement of the MS.

P21x

(x = a,.. ,d)

QRPDURxN

(x = 1,.. ,4)

In acknowledged mode, number of UL RLC blocks on PDTCH

encoded in CS-x (i.e CS-1 (P21a) CS-4 (P21d)) retransmitteddue to unacknowledgement of the MFS.

P20e QRPDDRMN In acknowledged mode, number of DL RLC data bytes (except

RLC blocks containing LLC Dummy UI Commands only) on

PDTCH encoded in MCS-x (with x = 1 to 9) retransmitted due to

unacknowledgement of the MS.

P21e QRPDURMN In acknowledged mode, number of UL RLC data bytes received

on PDTCH encoded in MCS-x (with x = 1 to 9) retransmitted due

to unacknowledgement of the MFS.

P55x

(x = a,.. ,m)

TRPDDCxN

(x = 1,.. ,4)

TRPDDMyN

(y = 1,.. ,9)

Number of useful DL RLC blocks sent in RLC acknowledged

mode on PDTCH encoded in (M) CS-x i.e. CS-1 (P55a) CS-4

(P55d) and MCS-1 (P55e) MCS-9 (P55m).

P57x

(x = a,.. ,m)

TRPDUCxN

(x = 1,.. ,4)

TRPDUMyN

(y = 1,.. ,9)

Number of useful UL RLC blocks received in RLC

acknowledged mode on PDTCH encoded in (M) CS-x i.e. CS-1

(P57a) CS-4 (P57d) and MCS-1 (P57e) MCS-9 (P57m).

Table 13: Counter list - PDCH dimensioning

Measured Object: Cell

Gathering periods: 7-day Busy Hour data, recommended

Otherwise, at least 2 working-day Busy Hour data

Note: Busy Hour means the hour gives the highest TCH & PDCH traffic of the day.

Methodology:

The process of TCH/PDCH dimensioning is presented below.


39/135



Kaufmann-

RobertAlgorithm

CS service

input data

PS service

input data

Total

required TSfor TCH and

PDCH

INPUT OUTPUTMETHOD

Figure 19: TCH/PDCH dimensioning process

INPUT

(1) CS service input data:

- CS Traffic Intensity in Erlang:

- The CS traffic intensity is calculated separately between Full Rate (FR) and

Half Rate (HR) Traffic.

- The calculation will take into account the real measured traffic and additional

margin from congestion rate.

- The way to calculate the congestion rate for FR and HR is presented below:-

- Per)Real_Cong_CSPerCongCS _%,30min(__ =

- Note: 30% is defined as the max congestion rate to be considered because several congestedcalls can be re-produced from one given user trying to access the network several times.

RequestnRTCH_Assig

CongnRTCH_Assigng_PerCS_Real_Co

_

_=

703812 MCMC

MC812

+=

As there is no specific counter to identify the type of congestion (from FR calls or

HR calls), below is the calculation to divide the global congestion rate into FR

congestion rate and HR congestion rate.

PerCongCSbMCaMC

aMCPerCongFR __

380380

380__

+=

- PerCongCSbMCaMC

bMC

PerCongHR __380380

380

__ +=

Then,

Full Rate CS traffic Intensity is:


40/135



-)__1(3600

380

__1

__

PerCongFR

aMC

PerCongFR

TrafficSuccessfulFR cellFR

=

=

Half Rate CS traffic Intensity is:

-)__1(3600

380__1__

PerCongHRbMC

PerCongHRTrafficSuccessfulHR cell

HR

=

=

--

- CS Bandwidth:

- 1 TS; for FR

- 0.5 TS; for HR

- CS GoS (as requirement): Blocking Probability rate = 2 %, for instance

(2) PS service input data:

- PS Traffic Intensity in Erlang:

The required PS traffic intensity is computed as below formula.

%)30,__(%1

____Re

congradioTBFMin

trafficPSMeasuredtrafficPSquired

=

Note: 30% is defined as the max congestion rate to be considered because several congestions

can be re-produced from one given user trying to access the network several times.

Where:

3600

451___

bPtrafficPSDLMeasured =

3600

451___

aPtrafficPSULMeasured =

%100919191919191

14___%

+++++=

fPePdPcPbPaP

PcongradioTBFDL

%100438626262

27___%

++=

cPcPbPaP

PcongradioTBFUL

-

- PS Bandwidth (minimum number of TS per a request on each direction):

- 1 / MAX_DL_TBF_SPDCH; for DL

- 1 / MAX_UL_TBF_SPDCH; for UL

Note: MAX_DL(UL)_TBF_SPDCH is the O&M parameter, which defines the maximum number

of Down (Up) link (E)GPRS TBFs per Slave PDCH.

=


41/135



-

- PS GoS (as requirement): Delay in seconds and Quantile in %-

- PS debit (throughput) in kbps:-

- For DL:

DLPSd _

n_Time_DLTransmisio

Data_DL=

eP

ePSizeBlockRLCPSizeBlockRLCPm

ax

xx

d

ax

xx

381024

20__55__208

++

=

==

For UL:

- ULPSd _ ULTimenTransmisio

ULData

__

_=

-

f

m

ax

xx

d

ax

xx

P

ePSizeBlockRLCPSizeBlockRLCP

381024

21__57__218

++

=

==

Where:

Table 14: RLC data block size for each (M) CS

Remark: PS throughput (in kbps) can also be defined by the target throughput perPDCH, which probably can be given by the operator e.g. 30 kbits/sec for DL & UL

(this information should also be provided in R_AVERAGE_GPRS and

R_AVERAGE_EGPRS parameters)

METHOD

In case of the TS sharing between two services (CS and PS), the Knapsack traffic

model with the Kaufmann-Robert algorithm is used to define the total number of

required TS for TCH/PDCH.

Channel Coding scheme RLC data block size in bytes

CS-1 22CS-2 32

CS-3 38

CS-4 52MCS-1 22MCS-2 28MCS-3 37MCS-4 44MCS-5 56MCS-6 74

MCS-7 (sent of 2 blocks) 2*56MCS-8 (sent of 2 blocks) 2*68MCS-9 (sent of 2 blocks) 2*74


42/135



Nb ofrequired

TCH/PDCH TSs

Nb of installed

TCH/PDCH TSs

Assesment

(comparision)

OKUnder-dimensioning

Increase installed TCH/PDCH

Required > Installed

Required = Installed

Required < Installed

Over-dimensioningDecrease installed TCH/PDCH

Thus, the output result of the TCH/PDCH dimensioning is only the number of TSs

needed for the mixed CS and PS traffic. It couldnt take into account configuration

parameters (MIN_PDCH, MAX_PDCH, and MAX_PDCH_High_Load) controlling

the sharing of radio resource between these two traffics.

However, we can apply the number of TSs needed (the result from this dimensioning

process) as a range of the zone [MIN_SPDCH, MAX_SPDCH]. Then, this result will

be added by numbers of TSs that operator wants to reserve for CS and for PS to get

the final number of TSs needed for CS and PS traffic in the cell.

Recommendation:

The method is complicated to apply manually, as it uses high level of mathematical

formulas & statistical laws. Therefore, please contact ARO/Architecture team

(http://aro.tm.alcatel.ro/) for related supports.

Assessment

The following diagram presents the TCH/PDCH assessment process.

Figure 20: TCH/PDCH dimensioning assessment

To adjust the number of the installed radio TSs according to the required ones, it

can happen the case of the low efficiency resource utilization, for example, one or

two additional TSs require one new TRX!

Thus, the RNE has to define the optimized number of required radio TSs to

trade-off between the returned gain and the investment cost.


43/135



3.2 Abis Interface

The Abis interface is standard ITU-T G.703 / G.704 interface. It is based on a frame

structure. The frame length is 256 bits grouped in 32 timeslots numbered from 0 to 31.

The rate of each timeslot is 64 kbits/s.

There are several media to transport Abis over networks:

- A terrestrial link referred to as PCM 2Mbits/s link (64 Kbits * 32 Time Slots = 2048

Kbits/s)

- A microwave link (same capacity or higher)

- Digital Cross-connect Network equipment, which concentrates 4, 16 or 64 PCM

2Mbit/s link

- A microwave hub equivalent to DCN

- A Satellite link (N.B. It is not possible to have Abis interface on satellite link if

AterMux interface is also on Satellite link)

3.2.1 Abis Configuration

3.2.1.1 Abis Network Topology

The following network topologies are defined for BTS to BSC connection.

Chain topology (or Multi-drop)

Several BTSs are connected to the same Abis interface. It means the Abis link is

statically shared.

Figure 21: Abis Chain (Multi-drop) Topology

Chain topology brings the gain to save number of Abis links but it is possible

only for the BTSs with small TRX configuration.

BSC

BTS

Abis Abis Abis

BTS BTS

Up to 15 BTSs

per

1 Abis Chain


44/135



Star topology

Each BTS is connected to the BSC directly. An Abis link is dedicated to a BTS.

Figure 22: Abis Star Topology

A star topology can be considered as a particular case of a chain topology with

only one BTS.

This topology is well suited to support BTSs with large configuration and is also

flexible for TRX expansion.

Ring topology (or Closed loop)

Several BTSs are connected to the same Abis interface. It means the Abis link is

statically shared. Moreover, the last BTS of the chain is connected to the BSC.

Compared to multi-drop, ring topology enhances security because the traffic

between any BTS and BSC is broadcast on two paths and the selection is based

on dedicated service bits and bytes.

Figure 23: Abis Ring (Closed loop) Topology

It is anyway more recommended to secure the transmission link rather than

wasting BSC connectivity resources by using this kind of topology.

BTS

BTS

BTSBTS

Abis

AbisAbis

Abis

BSC

BTSBTS BTS

BSC

Abis

AbisAbisAbis

Only 1 BTS

per

1 Abis Star

Up to 7 BTSs

per

1 Abis Ring


45/135



Secondary Abis topology

Since B8 (EDGE introduction), secondary Abis topology may be needed to

activate EDGE on some BTSs that have large TRX configuration.

There are two possible configurations for secondary Abis topology, supported in

release B9:

Figure 24: Secondary Abis Topology

Configuration # 1: Primary Abis connects only one BTS and for Secondary

Abis there can be BTSs multi-dropped to each other.

Configuration # 2: Primary Abis connects only one BTS and Secondary

Abis is looped back to BSC.

3.2.1.2 Abis Channels

Three types of channels are mapped onto an Abis link:

Qmux Channel only necessary for G1 and G2 BTS

It is used by TSC O&M transmission supervision for non-Evolium BTS (G1 and

G2 BTS).

In case of Evolium BTS, the functionality of Qmux can be managed through the

OML, via OML autodetection.

Ring Control Channel used in Ring topology only

This channel is used by the transmission equipment (BIE), which depends on the

TSC. There are two kinds of bits (R Ring control bits and S Sychronization

bits) containing in ring control channel.

Pri AbisBTS

BSC

Sec Abis

BTS

BTS

BTS

BSC

Sec Abis

Pri Abis

Configuration # 1

Configuration # 2


46/135



3 types of BTS Channels

1) TCH/GCH Channels: 8 Radio TS per TRX is mapping onto 2 Abis TS.

Figure 25: TRX - Abis mapping

For a given moment, a radio TS on a GPRS capable TRX can carry

- Either CS traffic, then it is called as TCHand the corresponding Abis

channel is also called as TCH,

- Or PS traffic, then it is called as PDCH and the corresponding Abis

channel(s) is/are called as GCH(s). Several GCHs per PDCH are used in

case of EDGE.

2) LAPD Channels: carry one or more LAPs (RSL and/or OML).

Only 1 RSL per TRX

Only 1 OML per BTS

The GSM Recommendation 08.52 defines 2 logical links between the BTS

and the BSC:

- The Radio Signaling Link (RSL) is used for supporting traffic

management procedures (MS to network communication).

- The Operation and Maintenance Link (OML) is used for supporting

networkmanagement procedures.For details about Abis resource management for RSL/OML, please refer to

section 3.2.1.4.

3) Extra Abis TS

On Abis interface, two types of 64 kbps TS are considered:

- Basic Abis TS: handle OML, RSL and traffic TS

- Extra Abis TS: handle only supplementary GPRS (CS-3/CS-4)

and EDGE (MCS-1 to MCS-9) nibbles when needed.

In release B9, the maximum number of extra Abis TS can be configured

through the new OMC parameterN_EXTRA_ABIS_TS.

Summary Abis Channels:

Abis

TS 0 TS 1 TS 2 TS 3

TS 4 TS 5 TS 6 TS 7

TRX

TS0

TS1

TS2

TS3

TS4

TS5

TS6

TS7


47/135



TS positionChannel type

TS0 usage TS0 transparencyPurpose

Qmux Channel

Qmux TS0 Other TS except TS0

Used by the BSC to manage Remot

b9 bss arch serv guideline ed03it1

Documents