B9 BSS Arch Serv GuideLine Ed03it1

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

Site
Vlizy
Mobile Radio Division
Originator(s)
P. Chootapa
E. 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!


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


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


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


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


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


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


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 standard cell 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


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 1
st
MFS generation (A9135 MFS) Capacity .................................................119
Table 40: Counter list - GPU/GP dimensioning ..................................................................122
Table 43: Counter list - Gb dimensioning ...........................................................................134


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 with
respect 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 DSZZA
Introduction of DRFU on G1 MK II BTS Principle
of Method
[4] 3BK 17025 0061 DSZZA
Introduction 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 TQZZA
EVOLIUM A9100 Base Station Product
description
[8] 3BK 10204 0511 DTZZA SFD: Dynamic SDCCH allocation
[9] 3DF 01903 2810 PGZZA 01
BSS B8 Dimensioning Rules
Configuration Description


[10] 3DC 20003 0025 UZZZA
Dimensioning Rules for CS and PS traffic with BSS
Software Release B9
[11] 3DC 21150 0323 TQZZA
GSM/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


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


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 and
Network 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 the
Mobile Stations and the BSC.
BSC (Base Station Controller): controlling several BTSs.
TC (TransCoder): providing speech conversion between the 16 kbits/s
channel (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.

1
MSC (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


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 TCH if its corresponding radio TS is TCH; or as GCH if 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


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

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
Alarm octet
SS7
X25
:
:
:
:


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
Setup
Initial
Steady
Developing
BSS Architecture Services
Network State


Process:
There are 2 different processes defined, one for supporting the services network
architecture setup and evolution, and the other one for supporting the service network
architecture assessment.

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


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 Network
configuration 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.


(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 the
previous (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 number of needed interface links.

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


- 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 called
AMT.NET, which assists the radio network engineer to design efficiently the
parenting Abis TSU in the convenient way.
For more details, please refer to website http://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:


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 Data
NW Configuration Rules
Recommendation/Threshold
(2) Applying Dimensioning Methods
Counters/Indicators vs. Configuration analysis
for each Network Elements and Interfaces
(3) Assessment
- Identify bottle necks
- Identify need of new resources / new configuration


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 installed capacity versus used capacity (refer to
the traffic analysis results from step 2), based on the recommendation and given
threshold at 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.


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.


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 channels
can 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 nibbles can 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 6
CS2 1 8 1.00 8
CS3 2 16 1.25 10
CS4 2 16 1.64 14
MCS1 1 8 0.89 8
MCS2 1 8 1.00 8
MCS3 2 16 1.33 11
MCS4 2 16 1.50 12
MCS5 2 16 1.86 15
MCS6 3 24 2.36 19
MCS7 4 32 3.49 28
MCS8 4 32 4.14 34
MCS9 5 40 4.49 36
Coding
Schemes
B8 (w/o stat mux) B9 (with M-EGCH stat Mux)


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


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


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 benefit
to 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.


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 BTS
The 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 BTS with DRFU is 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 900
MKII Std + DRFU 1 8 x
Extension / Reduction
Physical Logical
Min Max
G2 1 TRE 1 Sector: 8 TRE 1 TRE 1 TRE
Configuration
BTS
Min
BTS
Generation
Evolium Evolution G1 BTS Evolium BTS G2 BTS
- G1 BTS MK II
with DRFU
- G2 BTS DRFU

- G3 BTS
- M4M
- G4 BTS -G5BTS
- M5M


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/Reduction
Configuration
Physical Logical BTS
Min Max Min
Evolium 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.


Extension/Reduction
Configuration
Physical Logical BTS
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
G1 BTS G2 BTS
G1 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
M
u
l
t
i
b
a
n
d
Evolium BTS Evolium Evolution
B9 release
A
b
i
s
f
e
a
t
u
r
e
V
o
i
c
e
T
r
a
f
f
i
c
D
a
t
a
T
r
a
f
f
i
c
M
o
n
o
b
a
n
d


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 clock
synchronized.

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 B9
Non 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 Normal
Single Macro Single Normal Normal
Mini Macro Overlaid Normal Normal
Extended Macro Single Normal Extended
Umbrella Macro Umbrella Normal Normal
Concentric Macro Single Concentric Normal
Umbrella-Concentric Macro Umbrella Concentric Normal
Indoor Micro Micro Indoor Normal Normal
Profile Type Parameters
Cell Type


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, a
dynamic 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 8
2 Yes 12 4 8
2 No 24 8 16
3 No 24 8 16
4 No 32 8 24
5 No 32 8 24
6 No 32 8 24
7 No 40 16 24
8 No 40 16 24
9 No 48 16 32
10 No 48 16 32
11 No 48 16 32
12 No 56 16 40
13 No 56 16 40
14 No 64 24 40
15 No 72 24 48
16 No 72 24 48
Number of TRXs BCCH Combined
Number of SDCCH sub-channels


Table 10: Recommended SDCCH configuration for a standard cell 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 of required TRXs
Nb of required cells
Max. Capacity of
the given BTS

Assessment
(comparision)
OK
Under-dimensioning
Increase installed BTSs
Required >
Required =
Required <
Over-dimensioning
Decrease installed BTSs
Nb of installed BTSs Nb of required BTSs


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 (all
SDCCH 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


Erlang B
Required
SDCCH Traffic
GoS:
% SDCCH blocking
Nb of required
SDCCH sub-
channels /
timeslots
INPUT OUTPUT METHOD
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
cong SDCCH Min
traffic SDCCH Measured
traffic SDCCH quired
=
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
_ _
MC
traffic SDCCH Measured =
% 100
148 04
04
_ %
+
=
MC MC
MC
cong SDCCH

The other input is Grade of Service (GoS), which is defined by the required SDCCH
congestion rate (p
SDCCH
). 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.


OUTPUT

Number of required SDCCH sub-channels
= Erlang B (Required_SDCCH_traffic, p
SDCCH
)
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) > p
SDCCH
, 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 busy
MC812 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 all
PDCHs 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.
=


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

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.


Kaufmann-
Robert
Algorithm
CS service
input data
PS service
input data
Total
required TS
for TCH and
PDCH
INPUT OUTPUT METHOD

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_ CS Per Cong CS _ %, 30 min( _ _ =
- Note: 30% is defined as the max congestion rate to be considered because several congested
calls can be re-produced from one given user trying to access the network several times.
Request n RTCH_Assig
Cong n RTCH_Assig
ng_Per CS_Real_Co
_
_
=
703 812 MC MC
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.
Per Cong CS
b MC a MC
a MC
Per Cong FR _ _
380 380
380
_ _
+
=
- Per Cong CS
b MC a MC
b MC
Per Cong HR _ _
380 380
380
_ _
+
=

Then,

Full Rate CS traffic Intensity is:


-
) _ _ 1 ( 3600
380
_ _ 1
_ _
Per Cong FR
a MC
Per Cong FR
Traffic Successful FR
cell
FR

=
=

Half Rate CS traffic Intensity is:
-
) _ _ 1 ( 3600
380
_ _ 1
_ _
Per Cong HR
b MC
Per Cong HR
Traffic Successful HR
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
cong radio TBF Min
traffic PS Measured
traffic PS quired
=
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
_ _ _
b P
traffic PS DL Measured =

3600
451
_ _ _
a P
traffic PS UL Measured =
% 100
91 91 91 91 91 91
14
_ _ _ %
+ + + + +
=
f P e P d P c P b P a P
P
cong radio TBF DL
% 100
438 62 62 62
27
_ _ _ %
+ +
=
c P c P b P a P
P
cong radio TBF UL
-
- 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.
=


-
- PS GoS (as requirement): Delay in seconds and Quantile in %
-
- PS debit (throughput) in kbps:
-
- For DL:
DL PS
d
_

n_Time_DL Transmisio
Data_DL
=

e P
e P Size Block RLC P Size Block RLC P
m
a x
x x
d
a x
x x
38 1024
20 _ _ 55 _ _ 20 8
\
|
+ +
=

= =

For UL:
-
UL PS
d
_

UL Time n Transmisio
UL Data
_ _
_
=
-
f
m
a x
x x
d
a x
x x
P
e P Size Block RLC P Size Block RLC P
38 1024
21 _ _ 57 _ _ 21 8
\
|
+ +
=

= =

Where:

Table 14: RLC data block size for each (M) CS
Remark: PS throughput (in kbps) can also be defined by the target throughput per
PDCH, 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 22
CS-
2 32
CS-
3 38
CS-
4 52
MCS-
1 22
MCS-
2 28
MCS-
3 37
MCS-
4 44
MCS-
5 56
MCS-
6 74
MCS-
7
(sent of
2
blocks)
2
*
56
MCS-
8
(sent of
2
blocks)
2
*
68
MCS-
9
(sent of
2
blocks)
2
*
74


Nb of required
TCH/PDCH TSs
Nb of installed
TCH/PDCH TSs
Assesment
(comparision)
OK
Under-dimensioning
Increase installed TCH/PDCH
Required > Installed
Required = Installed
Required < Installed
Over-dimensioning
Decrease 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.


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


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

BTS

BTS

Abis

Abis

Abis

Abis

BSC

BTS

BTS

BTS

BSC

Abis

Abis

Abis

Abis

Only 1 BTS
per
1 Abis Star
Up to 7 BTSs
per
1 Abis Ring


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 Abis
BTS

BSC

Sec Abis
BTS

BTS

BTS

BSC

Sec Abis
Pri Abis
Configuration # 1
Configuration # 2


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 TCH and 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 parameter N_EXTRA_ABIS_TS.
Summary Abis Channels:
Abis
TS 0 TS 1 TS 2 TS 3
TS 4 TS 5 TS 6 TS 7
TRX
TS 0 TS 1 TS 2 TS 3 TS 4 TS 5 TS 6 TS 7


TS position
Channel type
TS0 usage TS0 transparency
Purpose
Qmux Channel
Qmux TS0 Other TS except TS0
Used by the BSC to manage Remote
Transmission Network Elements.
Ring control Channel used in Ring topology only
Ring control R bits
Other TS
except TS0
Other TS except TS0
(Qmux)
Supervision of Ring continuity
Synchronisation controls S bits TS0 Included with Qmux Direction of clock synchronisation
BTS Channels
TCH/GCH Other TS except TS0 GSM (GPRS CS-1/CS-2) traffic
LAPD channel for BTS (1 OML per BTS)
LAPD Other TS except TS0
LAPD channel for TRX (1 RSL per TRX)
Extra Abis TS Other TS except TS0 To support GPRS CS-3/CS-4 and EDGE
Table 15: Abis Channel Types

Remarks : There are two TS 0 modes:
TS 0 Usage: It means that TS 0 carries Qmux.
TS 0 transparency: The Qmux is carried by any other TS from TS1 to TS31 (TS 0
does not carry Qmux). TS 0 transparency is strongly recommended.

3.2.1.3 Abis Link Capacity
The following table lists the number of TS available in one Abis link to use for TCH
(or GCH), for signaling channels, and for extra Abis TS.

Chain & Star Topology Ring Topology
G1 or G2 BTS EVOLIUM BTS (*) G1 BTS (**) G2 or EVOLIUM BTS
TS0 TRANSPARENCY 30 31 28 29
TS0 USAGE 31 31 30 30

Table 16: Number of TS available in one Abis link

From Table 16, one Abis link capcity depends on:
- Type of Abis network topology
- TS 0 mode (TS 0 usage or TS 0 transparency)
- BTS generations
3.2.1.4 Signaling Sub-Multiplexing Schemes
(*) Improvement with EVOLIUM BTS: In case all BTSs of a chain are EVOLIUM BTSs, and if TS0 transparency is used, then the
time-slot used for transmission supervision (QMUX) can be saved (because the OML of EVOLIUM BTS supports also the transmission
supervision information).
(**) This column applies even if there is only one G1 BTS in a closed multidrop where other BTSs are not G1 BTSs.


The signaling sub-multiplexing schemes offer improvement in terms of required
PCM time slots for the signaling channels i.e. RSL and OML on the Abis interface.
This leads to substantial savings in terms of Abis interface resources.
There are 4 types of signaling sub-multiplexing schemes:
No Multiplexing
16K Static Multiplexing
64K Statistical Multiplexing
16K Statistical Multiplexing

3.2.1.4.1 No Multiplexing
Without multiplexing, the signaling channels will consume Abis TS as below.

1 RSL: 1 Abis TS (64 kbit/s)
1 OML: 1 Abis TS (64 kbit/s)

The following figure shows the example of Abis timeslot consumption for 1 BTS
with 4 TRXs when no multiplexing is applied.

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

3.2.1.4.2 16K Static Multiplexing
The RSL of a FR TRX requires only 16 kbit/s. It is therefore possible to pack up to
four RSL into one 64 kbit/s Abis time slot.
However, the OML is still carried on a full 64 kbit/s Abis time slot.
That means:
Nibble 1 Nibble 2 Nibble 3 Nibble 4
TS 0
TS 1 TRX 1 - TS 0 TRX 1 - TS 1 TRX 1 - TS 2 TRX 1 - TS 3
TS 3
TS 6
TS 9
TS 12
TS 13
:
:
:
TS 31
:
:
Abis Configuration
OML
TRX 2 - RSL
TRX 3 - RSL
TRX 4 - RSL
TS 0 Usage / Transparency
TRX 1 - RSL
:
13 TS required
in case of
No Multiplexing


Up to 4 RSL: 1 Abis TS (64 kbit/s)
1 OML: 1 Abis TS (64 kbit/s)

with 4 TRX when 16K Static multiplexing is applied.

Figure 27: Example of Abis TS usage for 1 BTS/4 TRX 16K Static Multiplexing
Rules:
- 16K Static Multiplexing is used only in a BSS with Evolium BTS and G2
BTS with DRFU, whereby each TRX carries a maximum of 8 SDCCH.
- Not compatible with the Half-Rate mode.
- BTS should be connected to a G2 BSC.

3.2.1.4.3 64K Statistical Multiplexing
The Abis channels for this multiplexing scheme may be seen as a group of MCB
(Multiplexed Channel Block).
Three types of MCB have then been defined in accordance to the number of TRX.
1) MCB 64/1 64K Statistical Multiplexing for 1 TRX
It is used for FR or DR TRX with high signaling load.
3 Abis TS per TRX

TS 0
TS 9
TS 10
:
:
:
TS 31
:
TRX 1 - RSL / TRX 2 - RSL / TRX 3 - RSL / TRX 4 - RSL
OML
:
:
Abis Configuration
10 TS required
in case of
16K Static
Multiplexing
TS 0
TS 3
Abis Configuration
TRX 1 - RSL / OML


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

It is used for FR TRX with high signaling load or DR TRX with normal
signaling load.
2.5 Abis TS per TRX


It is used for only FR TRX with normal signaling load.
2.25 Abis TS per TRX

with 4 TRX when 64K Statstical multiplexing is applied.

TS 0
TS 9
:
:
:
TS 31
:
Abis Configuration
TRX 1 - RSL / TRX 2 - RSL / TRX 3 - RSL / TRX 4 - RSL / OML
:
:
9 TS required
in case of
64K Statistical
Multiplexing
TS 0
TS 5
Abis Configuration
TRX 1 - RSL / TRX 2 - RSL / OML
TS 0
TS 9
Abis Configuration
TRX 1 - RSL / TRX 2 - RSL / TRX 3 - RSL / TRX 4 - RSL / OML


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

Rules:
-
- 64k Statistical Multiplexing is used only with Evolium BTS
- A BTS with N FR TRE configured with 64K statistical multiplexing requires:
I. (N/4) MCB 64/4
II. One MCB 64/1 when N mod 4 = 1 (BTS with 1, 5, 9 or 13 TREs)
III. One MCB 64/2 when N mod 4 = 2 (BTS with 2, 6, 10 or 14 TREs)
IV. One MCB 64/1 and one MCB 64/2 when N mod 4 = 3 (BTS with 3, 7, 11 or
15 TREs). This configuration is used instead of MCB 64/3 to allow a better
usage of TCU resources at the BSC. It consists of splitting the last 3 RSL
into 2 Abis-TS. The 2 fractions can be mapped on 2 different TCUs
Number of FR
TRE per BTS (per
Abis link)
List of physical
MCBs
Max SDCCH
weight per MCB
1 64/1 24
2 64/2 32
3 64/2; 64/1 32; 24
4 64/4 32
5 64/4; 64/1 32; 24
6 64/4; 64/2 32; 32
7 64/4; 64/2; 64/1 32; 32; 24
8 64/4; 64/4 32; 32
9 64/4; 64/4; 64/1 32; 32; 24
10 64/4; 64/4; 64/2 32; 32; 32
11 64/4; 64/4; 64/2;
64/1
32; 32; 32; 24
12 64/4; 64/4; 64/4 32; 32; 32
13 64/4; 64/4; 64/4;
64/1
32; 32; 32; 24
14 64/4; 64/4; 64/4;
64/2
32; 32; 32; 32
15 64/4; 64/4; 64/4;
64/2, 64/1
32; 32; 32; 32; 24


TS 0
TS 1 TRX1-RSL/OML TRX 1 - TS 1 TRX 1 - TS 2 TRX 1 - TS 3
Abis Configuration
- A BTS with N DR TRE configured with 64K statistical multiplexing includes
((N-1)/2)+1 MCBs of which:
I. (N/2) MCB 64/2
II. (N mod 2) MCB 64/1
Dual rate attribute is now introduced per TRE and not anymore per BTS. As a
result, only the TRXs using the DR mode must follow the rules concerning DR
TRXs in particular the possibility to connect 2 TRXs-DR per TCUC.
3.2.1.4.4 16K Statistical Multiplexing
The basic Abis nibble corresponding to the radio timeslot 0 of each TRX
encompasses the RSL of this TRX and eventually the OML of the BTS.
This multiplexing requires that no traffic, but only signaling (BCCH or SDCCH), is
affected on timeslot 0 of each TRX. In this case no additional timeslot is required
on the A-bis for signaling.
As for 64K statistical multiplexing, Abis transmission can be seen as a sequence of
MCB 16/1, see below.


with 4 TRX when 16K Statstical multiplexing is applied.

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

Rules:
TS 0
TS 1 TRX1-RSL/OML TRX 1 - TS 1 TRX 1 - TS 2 TRX 1 - TS 3
TS 3 TRX2 - RSL TRX 2 - TS 1 TRX 2 - TS 2 TRX 2 - TS 3
TS 5 TRX3 - RSL TRX 3 - TS 1 TRX 3 - TS 2 TRX 3 - TS 3
TS 7 TRX 4 - RSL TRX 4 - TS 1 TRX 4 - TS 2 TRX 4 - TS 3
:
:
:
TS 31
Abis Configuration
:
:
:
8 TS required
in case of
16K Statistical
Multiplexing


- 16K Statistical Multiplexing is used only with Evolium BTS.
- Not compatible with the Half-Rate mode.
- Not compatible with dynamic SDCCH allocation.
- TS 0 of each TRX must not be assigned to Traffic channel (but to a signaling
channel:BCCH/CCCH, SDCCH).

3.2.1.5 Secondary Abis Link
If EDGE is to be introduced in a BTS configuration or if the BTS configuration in
terms of number of supported TRX is increased (i.e. thanks to Twin TRX
introduction), and if there are not enough Abis TS on one Abis link to carry all basic
TS (TCH), signaling TS (RSL & OML) and extra TS, a second Abis link can be
attached to the BTS.
In release B9:
- The basic TS can be mapped to the primary or the secondary Abis link
contrary to B8 where the basic TS can be only on the primary link. For details,
please refer to [2]
- The extra TS can be mapped to the primary or the secondary Abis link.

Figure 34: Abis TS configuration on primary and secondary links

For a BTS with two Abis links, the operator defines the parameter:
MAX_EXTRA_TS_PRIMARY that is the maximum number of extra timeslots the
system is allowed to allocate on the first Abis for this BTS.
To keep the maximum free timeslots on the secondary Abis, the allocation of extra
timeslots is done in priority on the first Abis until this Abis is full or
MAX_EXTRA_TS_PRIMARY is reached.
B
S
C
B
T
S
ET ET ET ET OML RSL BT BT RSL BT BT
RSL BT BT RSL BT BT
ET ET ET ET ET ET ET ET
Primary Abis Link
Secondary Abis Link
BT: Basic Timeslot ET: Extra Timeslots
B
S
C
B
T
S
ET ET ET ET ET ET ET ET OML RSL BT BT OML RSL BT BT RSL BT BT RSL BT BT
RSL BT BT RSL BT BT RSL BT BT RSL BT BT
ET ET ET ET ET ET ET ET ET ET ET ET ET ET ET ET
Primary Abis Link
Secondary Abis Link
BT: Basic Timeslot ET: Extra Timeslots


In the same time operator has to define the parameters MAX_DR_TRE_PRIMARY
and MAX_FR_TRE_PRIMARY which give the maximum number of DR (resp. FR)
TRE to be mapped on first Abis when a second Abis is attached.

The primary and secondary Abis links of a BTS can be on different Abis TSU of different
BSC racks.

Rules:
- OML is always mapped on the first Abis link
- TCH and RSL of a TRX are always mapped on the same Abis link
- Only EVOLIUM BTS with SUMA board or M5M supports the 2
nd
Abis link.
- It is not possible to have the primary Abis link on terrestrial link and the
secondary one on satellite link.
- An EVOLIUM BTS with SUMP board has to be upgraded. An EVOLIUM
BTS can manage only 2 termination points - this implies that it is not possible
to:
- i) Connect a BTS in chain after a BTS with two Abis
- ii) Change the Abis from chain to ring if there is a BTS with two Abis
- iii) Attach a second Abis to a BTS that is not at the end of an Abis chain

3.2.2 Abis Dimensioning
The capacity of one Abis link is fixed at 32 TSs; however, only 31 TSs are actually
available because 1 TS (TS#0) is always used for frame synchronization. If the
number of needed TSs is greater than 31, the secondary Abis link is required.
Thus, the aim of Abis dimensioning is to define how many Abis links (max. 2 links
per BTS since B8) is sufficient to support the needed TSs.

The number of needed Abis TSs is based on:
Type of Abis Topology
Chain (Star) or Ring
TS0 mode
TS 0 usage or TS 0 transparency
Qmux usage
Used or Not used
Type of signaling sub-multiplexing schemes
No mux, Static mux(16K), Statistical mux(16K or 64K)
Number of TRX
2 Abis TSs are needed to support 1 TRX.

Static
number of
needed
Abis TSs


Extra Abis TS
New type of Abis TS, introduced since B8, to support
GPRS CS3-CS4 and EDGE services because 1 basic
Abis TS is not enough to transport the high data
throughput of those services.
1 Extra Abis TS contains 4 GCHs (nibbles).
Various number of required GCH is based on
modulation & coding scheme (MCS or CS), please
refer to Table 2
Less GCH consumption in B9 thanks to M-EGCH
and dynamic Abis allocation
Max number of extra Abis TS is limited by parameter
N_EXTRA_ABIS_TS

It is simple to define the number of needed Abis TSs for conditions of topology, TS0
mode, Qmux usage, signaling sub-mux and number of TRX because each of them
requires the certain number of TSs.
The most complicated part of Abis dimensioning in B9 release is how to define the
number of extra Abis TSs per BTS, as this kind of TS is allocated dynamically on
Abis link when needed by traffic demand and it can be shared among the BTS sector.
The following presents the Abis dimensioning processes to define the needed extra
Abis TSs based on the counter analysis.

3.2.2.1 Case #1: B8 with No GPRS/EDGE B9 with EDGE
In case of a B8 network without GPRS/EDGE going to B9 network with EDGE, the
Abis dimensioning should be performed according to only the operators assumption
& requirement (e.g. target PS subscribers, PS traffic types, etc.) because there is no PS
traffic counters available.
Please contact Network Design division for Abis dimensioning case#1.

3.2.2.2 Case #2: B8 with GPRS/EDGE B9 with EDGE
For this case, B9 Abis dimensioning can be performed according to the current
situation of B8 network with GPRS/EDGE and the new requirement e.g. new target
MCS from MCS8 in B8 (TRX class 4) to MCS9 in B9.
The process of Abis dimensioning case#2 is presented below:

Dynamic
number of
needed Abis
TSs


M-EGCH
statistical
mux
Dynamic
Abis
allocation
Nb of PDCH
used per Cell
Target MCS
e.g. MCS9
INPUT OUTPUT METHOD
Nb of required
extra Abis Nibbles

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

INPUT

Number of PDCH used per Cell: this input can be derived from 3 different
ways.
1) Based on B8 PDCH traffic counter measurement
%) 30 , _ (% 1
_ _
_ _ Re
cong PDCH Min
used PDCH Measured
used PDCH quired
=

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
38
_ _ _
b P
used PDCH Nb Avg =
) _ _ ,% _ _ (% _ % cong PDCH UL cong PDCH DL Max cong PDCH =
Where :
% 100
3600
13
_ _ % =
P
cong PDCH DL
% 100
3600
26
_ _ % =
P
cong PDCH UL

P38b (P38 in
B8)

ARPDCUST Cumulated time during which the slave PDCHs carry at least
one UL or DL TBF (TBF established in GPRS mode or EGPRS
mode).
P13 QRDTECGT Time during which the DL PDCH establishment is congested
P26 QRUTECGT Time during which the UL PDCH establishment is congested


2) Given by the operator
It is also possible that the operator defines the required number of used
PDCH based on his own assumption.
3) Based on the same assumption as in B8 situtation (please refer to example
below)

Target MCS: this input usually is defined by the operator e.g. MCS9.

METHOD
The method is simply applied with taking into account two new B9 features:
M-EGCH statistical multiplexing
The feature allows the set of GCHs can be shared among PDCHs. Thus,
number of required GCH for each MCS does not need to be rounded-up, for
example, 4.49 GCH required for MCS 9 in B9, but 5 GCH in B8.
Please more details of this feature in section 2.3
Dynamic Abis allocation
The feature introduces the new concept of Abis nibbles, which for instance
allows Bonus basic, & Extra Abis TS can be shared among BTS sectors.
Please more details of this feature in section 2.3

OUTPUT
Please find below the example of Abis dimensioning with the number of used PDCH
based on B8 situation (number of TRX class).

Example: Abis dimensioning for a BTS having one TRX class 5 for each sector in B8
and having Max MCS MCS9 in B9. See details of BTS configuration in below figure.

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


So the inputs are:
Number of used PDCH per Cell = 7
This is based on B8 situation as in each cell, only TRX#2 can support
GPRS/EDGE as the parameter TRX_PREF_MARK = 0, so max PDCH group size
is 7 PDCHs per cell.
Target MCS = MCS9

Abis Timeslot Usage Calculation:

Abis TS Usage Number of TS (s)
TS0: for Frame Synchronization 1
Basic Abis TS 12
(2 Abis TS per TRX * 6 TRX)
RSL & OML Abis TS 2
(In case of 64K Statistical Multiplexing,
please refer to section 3.2.1.4.3)
Max required Extra Abis TS 17
(*)
Total 32
Only 1 Abis link enough!
(*)
Max required Extra Abis TS calculation:
Number of used PDCH per cell = 7.
Max MCS = MCS-9
In B9 with M-EGCH link, MCS-9 requires only 4.49 GCH per PDCH (whereas 5
GCH per PDCH in B8).
Therefore,
Total GCH = 7 PDCH * 3 Cells * 4.49 GCH = 94.3 GCH
Total Abis Nibbles = 94.3 GCH( = 95 Abis Nibbles
Then,
Total Abis Nibbles = Basic Abis Nibbles + Add. Abis Nibbles
95 = 21 + Add. Abis Nibbles
(7 PDCH per cell: 7 basic nibbles per cell or 21 basic nibbles perBTS)
Add. Abis Nibbles = 74 Nibbles
And,
Add. Abis Nibbles = Max required Extra Abis Nibbles + Bonus Basic Nibble
74 = Max required Extra Abis Nibbles + 9
(3 bonus basic nibbles / cell from BCCH and SDCCH in TRX#1 and from SDCCH in TRX#2)
Max required Extra Abis Nibbles = 65 Nibbles


Max required Extra Abis Timeslots = 65/4( = 17 TS.

Remark:
(i) The number of used PDCH can be changed to another value probably given by
the operator or derived from counter (P38) measurement (recommended), but
Abis TS calculation process remains the same.
(ii) This dimensioning method gives the maximum number of required extra Abis
TS, which fits to the assumption: simultaneously all GPRS and/or EDGE
Timeslots having the maximum declared (M)CS - however, this case is very rare.
To get more accurate results, it is commended to check the real obtained MCS
distribution that is based on radio conditions linked to how good the radio
network planning is.
2 different ways to get MCS distribution:
From network planning data
The used MCS is assigned according to the radio condition i.e. C/I.
Basically, the high MCS will be used in case of good radio condition
corresponding to high C/I value and low MCS is used for bad radio
condition, low C/I value.
Below is the figure showing the MCS link adaptation based on radio
condition (C/I).
Figure 37: MCS link adaptation vs. radio condition C/I

From above figure, it is able to derive the Proper Max MCS corresponding to
C/I. And if the BTS in the example has given C/I distribution as below:

0
10
20
30
40
50
60
0 5 10 15 20 25 30 35 40
C/I dB
K
b
i
t
s
/
s
MCS-9 MCS-8
MCS-7 MCS-6
MCS-5 MCS-4
MCS-3 MCS-2
MCS-1 Ideal LA


C/I (dB)
Proper Max MCS
(cf. C/I)
Required GCH
(cf. MCS)
% C/I distribution
( For example BTS)
Avg Required GCH
(cf. C/I distribution)
x > 26 MCS9 4.49 20% 0.898
24<x<=26 MCS8 4.14 30% 1.242
18<x<=24 MCS7 3.49 20% 0.698
12<x<=18 MCS6 2.36 10% 0.236
8<x<=12 MCS5 1.86 10% 0.186
x < 8 MCS1 to MCS4 1.5 10% 0.15
100% 3.41

Then, we can change the calculation of Maximum M-EGCH link size:
From
7 PDCH per Cell * 4.49 GCH = 31.43( = 32 GCH
To
7 PDCH per Cell * 3.41 GCH = 23.87( = 24 GCH
And finally we will get lower number of Max. required Extra Abis nibbles
which are 42 nibbles (11 extra Abis TS).
The C/I distribution information should be available in the network-planning
database.
From counter measurement
The MCS distribution can be retrived from the following counters:

P55e / (P55e +
P55f + P55g +
P55h + P55i +
P55j + P55k +
P55l + P55m)
TRPDDM1O Ratio of useful DL RLC blocks encoded in MCS 1
P55f / (P55e +
P55f + P55g +
P55h + P55i +
P55j + P55k +
P55l + P55m)
P55g / (P55e +
P55f + P55g +
P55h + P55i +
P55j + P55k +
P55l + P55m)
P55h / (P55e +
P55f + P55g +
P55h + P55i +
P55j + P55k +
P55l + P55m)


P55i / (P55e +
P55f + P55g +
P55h + P55i +
P55j + P55k +
P55l + P55m)
P55j / (P55e +
P55f + P55g +
P55h + P55i +
P55j + P55k +
P55l + P55m)
P55k / (P55e +
P55f + P55g +
P55h + P55i +
P55j + P55k +
P55l + P55m)
P55l / (P55e +
P55f + P55g +
P55h + P55i +
P55j + P55k +
P55l + P55m)
P55m / (P55e
+ P55f + P55g
+ P55h + P55i
+ P55j + P55k
+ P55l + P55m)
Table 17: Counter list MCS distribution

It is more accurate to get MCS distribution via the above indicators if all of MCS are
available in B8 i.e. TRX class 5 already implemented. This statistic represents the real
obtained MCS not only concerning in radio condition but also concerning in the traffic
location distribution.
In case only some MCS available (for example TRX class 2 only max. MCS 5), we
have to use the network planning data to predict the distribution of higher MCSs
(MCS 6 to MCS9) if we need to perform Abis dimensioning from existing B8 to B9
with max. MCS-9.

3.2.2.3 Case #3: B9 with EDGE
In case of B9 network with already EDGE, we can perform the Abis dimensioning
based on the counter measurement.
There are 2 different methods approaching the Abis dimensioning:

Method 1: Abis dimensioning based on PS traffic only (bonus & extra Abis
nibble traffic)

Target: To estimate the number of Extra Abis Timeslots needed at BTS level.
Gathered Counters:


P466 ABGCHUSEBT Cumulated time during which extra and bonus Abis nibbles are
used in the cell, cumulated over all extra and bonus Abis
nibbles.
P105i QRDTECBN Number of DL establishment failures due to congestion of Abis.
P105j QRUTECBN Number of UL establishment failures due to congestion of Abis.
P91a + P91b +
P91c + P91d +
P91e + P91f
P62a + P62b +
P62c - P438c
Table 18: Counter list - Abis dimensioning Method 1

Measured Object: BTS
Note: Busy Hour means the hour gives the highest extra & bonus Abis nibble traffic (i.e P466) of
the day.
Methodology:
The process of Abis dimensioning is presented in Figure 38.

Figure 38: Abis dimensioning process Method 1

INPUT

The required extra & bonus Abis traffic is computed as below formula.

%) 30 , _ _ (% 1
_ _ & _
_ _ & _ Re
cong Abis TBF Min
traffic Abis bonus extra Measured
traffic Abis bonus extra quired
=
Where:
Erlang C
Required extra
& bonus Abis
nibble Traffic
GoS:
% Quantile of x
delay sec
Nb of required
extra & bonus Abis
Nibbles
INPUT OUTPUT METHOD
Nb of required
extra Abis Nibbles


3600
466
_ _ & _
P
traffic Abis bonus extra Measured =
) _ _ _ ,% _ _ _ (% _ _ % cong Abis TBF UL cong Abis TBF DL Max cong Abis TBF =
Where :
% 100
91 91 91 91 91 91
105
_ _ _ %
+ + + + +
=
f P e P d P c P b P a P
i P
cong Abis TBF DL
% 100
438 62 62 62
105
_ _ _ %
+ +
=
c P c P b P a P
j P
cong Abis TBF UL

The other input is Grade of Service (GoS), which is defined by %Quantile of x delay
second (p
ABIS
). Since the MFS always tries to assign TBFs as soon as the request is
received, we usually dimension for 0sec delay. Normally GoS should be given or
agreed by the Mobile Operator.
On Abis interface, the recommended value is 95% quantile of 0 delay sec.

METHOD

Concerning only PS traffic, the statistical law Erlang C is used during the
target GoS.
As extra & bonus Abis nibles are associated to PS traffic only, Erlang C can be
applied to calculate the required number of extra & bonus Abis nibles according to
required PS traffic and % quantile of delay time.

OUTPUT

Number of required extra & bonus Abis nibbles
= Erlang C (Required_extra&bonus_Abis_traffic, p
ABIS
)

However, the number of bonus Abis nibbles is fixed according to the total number of
BCCH & SDCCH TS in the BTS i.e.1 BCCH (SDCCH) TS gives 1 bonus Abis
nibble.
Then,
Number of required extra Abis nibbles
= Number of required extra & bonus Abis nibbles Nb of bonus Abis nibbles

And
Number of required extra Abis TS
= Number of required extra Abis nibbles / 4
Remark: 1 Abis TS contains 4 Abis nibble


Assessment:
In order to assess the Abis dimensioning, it is suggested to monitor if there is any
impact caused by Abis congestion afterward.
The major degradations due to Abis congestion are:
TBF establishment failures due to Abis congestion:
% 1 , 0 _ _ _ % > cong Abis TBF
The radio throughput reduction: a method for throughput degradation is under
study.

Method 2: Abis dimensioning based on CS & PS traffic
The main purpose of this method development is to provide Abis dimensioning based
on both CS and PS traffic while method 1 is only taking into account PS traffic on
bonus & extra nibbles. As in B9 with the new feature Autonomous Packet Resource
Allocation, the number of basic nibbles mapped at one given moment to radio timeslot
available for PS traffic is evaluated, according to the whole BSS load (CS and PS
loads). The amount of available basic nibbles for PS is related to the needed extra
nibbles. The more basic nibbles for PS are available, the less extra nibbles are
required.
There are two different indicators which are possible to represent PS traffic:
- MCS traffic
- GCH traffic
-
Gathered Counters:
P100c AAGCHUST Cumulative time during which a GCH is busy in a cell. The
counter is integrated over all the GCH available in the cell.
P90a + P90b +
P90c + P90d +
P90e + P90f
TRDTESUN Number of DL TBF establishment successes per cell
P30a + P30b +
P30c
TRUTESUN Number of UL TBF establishment successes per cell
P105i QRDTECBN Number of DL establishment failures due to congestion of Abis.
P105j QRUTECBN Number of UL establishment failures due to congestion of Abis.
P91a + P91b +
P91c + P91d +
P91e + P91f
P62a + P62b +
P62c - P438c


P20x
(x = a,.. ,d)
QRPDDRxN
(x = 1,.. ,4)
In acknowledged mode, number of DL RLC blocks (except
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
P20e QRPDDRMN In acknowledged mode, number of DL RLC data bytes (except
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
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).
P160 QRDTES1N Number of DL TBF establishment requests requesting 1 slot
which are satisfied at once by the initial allocation.
P162 QRDTES3N Number of DL TBF establishment requests requesting 2 or 3
slots which are satisfied at once by the initial allocation.
P164 QRDTES5N Number of DL TBF establishment requests requesting 4 or 5
P161 QRUTES1N Number of UL TBF establishment requests requesting 1 slot
which is satisfied at once by the initial allocation.
P163 QRUTES3N Number of UL TBF establishment requests requesting 2 or 3
P165 QRUTES5N Number of UL TBF establishment requests requesting 4 or 5
Table 19: Counter list - Abis dimensioning Method 2.1
Measured Object: BTS
Note: Busy Hour means the hour gives the highest CS & PS traffic (i.e MC380a + MC380b +
P100c) of the day.


Methodology:

Figure 39: Abis dimensioning process Method 2
Abis method is specifically developed by using an iterative algorithm to calculate the number
of extra nibbles needed. With this algorithm, the number of extra and bonus nibbles is started
at 0; for each value we calculate GoS of services in all cells and compare them to GoS
requirement. Loops of the algorithm continue till GoS of all services are satisfied in all cells.
The algorithm is shown in the following figure:

Figure 40: Abis method algorithm
In addition, Abis method can be internally categorized into 2 different ways,
depending on the representative indicators for PS traffic.
- PS traffic = MCS traffic
- Only Knapsack statical law is applied in Abis method.
Abis Method
with Knapsack
or with Knapsack
+ Erlang C
PS traffic (MCS or GCH)
CS traffic
Cell configuration:
- Nb of Basic nibbles
Parameters:
- Min_PDCH
- Max_PDCH_High_load
- Max_PDCH
INPUT OUTPUT METHOD
Nb of required
extra Abis Nibbles
GoS reached in all
cell for all services?
Calculate GoS of all
services in each cell
Compare calculated
GoSs to required ones
Nb extra and bonus = 0
Nb extra and bonus
Nb extra
and bonus ++
True

False
False


- PS traffic = GCH traffic
- Knapsack and Erlang C statical laws are applied in Abis method.
Recommendation to apply this Abis method:
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.

Comments on two methods for Abis dimensioning:

- Method 1 : Simple application but limited accurate results
This method is simple by using only small number of counters and one statistical
law required i.e. Erlang C, thus it is possible to apply the method manually
without specific tool need. However, the accuracy of this method should be
limited as it considers on only extra & bonus nibble traffic not basic nibble.

- Method 2 : More accurate results but complicated application
This is advanced method to take into account CS & PS load by using several
counters and statistical laws required i.e. Knapsack and Erlang C. So, this method
should provide more accurate results for Abis dimensioning. However, a tool
support is needed to apply the method due to its complexity (difficult to perfom it
manually).
These two methods should be used together in a complementary way in order to
compute the optimized value for the N_EXTRA_ABIS_TS parameter. The
recommended process is described hereafter:

Figure 41: Abis dimensioning process
Extra & Bonus method
MCS method
For ALL BTS
Extra nibbles
Needed ?
Extra nibbles
Needed ?
Select minimumm between theoretically
missing resources, according to the method
described in . . . , and the minimum
between extra & bonus / MCS method results
yes
yes
No
No
For each BTS
Needing additional
Resources according
to Extra & Bonus method
/
Round up
N_EXTRA_ABIS_TS
N_EXTRA_ABIS_TS=
Extra & Bonus method
MCS method
For ALL BTS
Extra nibbles
Needed ?
Extra nibbles
Needed ?
Select minimumm between theoretically
missing resources, according to the method
described in . . . , and the minimum
between extra & bonus / MCS method results
yes
yes
No
No
For each BTS
Needing additional
Resources according
to Extra & Bonus method
/
Round up
N_EXTRA_ABIS_TS
N_EXTRA_ABIS_TS=


3.3 BSC
Two generation of BSC are supported in B9:
- G2 BSC
- BSC Evolution, relying on Advanced Telecom Computer Architecture (ATCA).

3.3.1 G2 BSC Configuration
The G2 BSC or A9120 BSC consists of 3 Terminal Sub-Units (TSU), responsible for
specific functions, plus Group Switches realising the connections between TSUs
connected to the BTSs and TSUs connected to the Transcoder or MFS.

Figure 42: G2 BSC (A9120 BSC) Architecture

From Figure 42, the BSC is basically divided in three building blocks:
4) Abis TSU: For Abis interface management functions towards the Base
Stations (BTS), see details in section 3.3.1.2
5) Ater TSU: For Ater interface management functions towards the Core
Network (Circuit and Packet), see details in section 3.3.1.3
6) Common TSU: For all central functions of the equipment;


3.3.1.1 BSC Capacity
The following figure presents the cabinet layout of maximum BSC configuration
(Conf. 6). The smaller configurations consist of fewer racks or half filled racks.

Figure 43: G2 BSC Cabinet layout

In release B9, six configurations of G2 BSC are offered:

Table 20: G2 BSC Capacity

3.3.1.2 Abis TSU
Config 1 Config 2 Config 3 Config 4 Config 5 Config 6
Capacity FR 32 128 192 288 352 448
DR 14 62 92 140 170 218
32 120 192 240 264 264
23 95 142 214 255 255
6 6 6 6 6 6
4 6 10 12 16 16
454 686 1148 1380 1842 2074
Nb of TSU 1 4 6 9 11 14
2 3 5 6 8 9
Nb of E1 6 24 36 54 66 84
4 6 10 12 16 18
Erlang Traffic 160 627 1074 1300 1700 1900
G2 BSC (A9120 BSC)
Configuration
Abis
Ater (CS&PS)
on A interface (1:4 Mux)
Nb TRX
Nb Cell
Nb BTS
Nb GPU
Nb SS7 links
Nb CICs
Abis TSU
Ater TSU


The Abis TSU is a functional entity terminating the interfaces carrying the
speech/data traffic and signaling to and from the BTS. It includes the following
boards:

Figure 44: Abis TSU G2 BSC

1 BIUA: Base Station Interface Unit type A
BIUA is submultiplexing and cross-connect module, which provides six Abis
PCM connections.
Rules:
- 6 Abis connection of a BIUA can support the following Abis
configuration:
- Maximum 3 Ring configurations
- Maximum 6 Chain/Star configurations
- The primary and the secondary Abis links of a BTS can be on different
TSUs (or BIUA) and also on different BSC racks.
- All TRXs of all BTSs of a same Abis multidrop must be connected to a
single Abis TSU.
-
8 TCUCs: Terminal Control Unit type C
The TCUC performs the telecommunication function and the O&M functions
required to connect the BSC and the BTS.
Rules:
- Each TCUC can handle 6 LAPD signaling links LAPD (i.e. RSL, OML
and TSL) that allows:
- 4 RSL+ 2 OML
- 3 RSL+ 3 OML


- For the TSL/TCU mapping is fixed as below table:

Table 21: TSL/TCU Mapping

- Each TCUC can handle 32 Traffic channels which allows:
- 4 Full Rate TRXs
- 2 Dual Rate TRXs
- 8 Extra Abis TSs
- (First Abis TSU of each rack can only support 14 DR TRXs)
-
- Each TCUC handle either Full Rate or Dual Rate traffic but not both.
- FR TCUC can handle a mix of FR & Extra Abis TS.
- DR TCUC does not support extra Abis.
- Each TCUC can handle 32 SDCCH channels. However, in case of 16K
Signaling Multiplexing (Static or statistical 16kbit/s) each TRX can carry 8
SDCCH channels maximum.
- One TCUC shall not handle more than 2 BCCH in case of GPRS cell, this
rule is a warning but it is not checked by the SW.
- For 16K Static multiplexing, all RSLs of a given 64 kbit/s Abis time-slot
must be handled by the same TCUC.
- For Statistical Multiplexing, all multiplexed RSL and OML are processed
on the same TCU.
- Mix of the different signaling multiplexing and not multiplexed signaling
on the same TCU is allowed for Full Rate.

2 AS: Access Switch
It allows TCUC to gain access to Group Switch.

For more Abis TSU rules, please refer to [1]

BIUA number
(BSC-Adapt SBL nbr)
TSL 1 (first rack) 1 1
TSL 2 (second rack) 6 41
TSL 3 (third rack) 11 81
TSL links G2 BSC TCU number


3.3.1.3 Ater TSU
The Ater TSU is a functional entity terminating the interfaces to and from
thetranscoder and/or the MFS.
It includes the following boards:
2 ASMB: providing multiplexing 16 Kbit/s from 4 tributaries to 1
highway.
8 DTCC: one DTCC can handle up to 30 circuits when no TS are used
for Qmux, X25 or SS7.
2 access switches

Figure 45: Ater TSU G2 BSC

DTC Rules:
- Any of the first DTCs in each group of 4 supporting an Atermux interface
(among the 16 first Ater Mux) can terminate an SS7 signaling link if the Ater
Mux is CS.
- There are 6 potential BSC synchronization sources (one from each Atermux in
the first rack). If the Atermux is used, then the first DTC attached to that ASMB
recovers a synchronization reference signal and sends this to the BSC central
clock.
- DTCC can be dedicated for SS7-MTP (supporting a physical SS7 link), GSL
(supporting a physical GSL), BSSAP/GPRSAP (higher layers of SS7 and GSL)
or TCHRM (TCH allocation)
- One DTCC TCH-RM pair can handle up to 60 cells and the number of TRX
per TCH-RM is limited to 90.

For more Ater TSU rules, please refer to [1]


3.3.2 BSC Evolution Configuration
The architecture of the BSC Evolution (or A9130 BSC) relies on the Advanced
Telecom Computing Architecture (ATCA), re-using the same software as the G2
BSC.
A virtual CPU approach has been developed: each control module (CCP or OMCP)
supports several software processes corresponding to the TCUC, DTCC, TSCA or
CPRC processor modules of the previous generation G2 BSC.
The following figure shows the BSC Hardware (HW) architecture on an ATCA
platform.

Figure 46: BSC Evolution (A9130 BSC) HW Architecture

The main elements of the BSC Evolution are:
Telecom sub-racks: there is one or two sub-racks per BSC Evolution
cabinet but a BSC can use only 1 sub-rack (in future software releases,
we may support BSC Evolution configurations relying on two sub-
racks). This means we may have 2 BSCs per cabinet. Each sub-rack
can accommodate up to 14 boards.
Boards: four types of boards are defined:
- CCP board: the Call Control Processing board, in charge of all the
telecom functions of the BSC, except the TCH Resource Management. There
are 1 to 5 active CCP board per BSC, i.e. per sub-rack, and 1 board for
redundancy. Each CCP board can manage up to 200 TRXs.


- OMCP board: the O&M Control Processing board, in charge of all the
O&M functions of the BSC and TCH Resource Management. There are 2
OMCP boards per BSC, i.e. per subrack, including 1 for redundancy.
- SSW board: this board allows exchanges between all the elements of the
platform and external IP/Ethernet equipment. It support IP Layer 3 functions
and is based on Gigabit Ethernet. There are two SSW boards per shelf, 1
active and 1 for redundancy
- TP board: this board is in charge of the transmission processing functions
of the BSC. It mainly processes the Abis timeslots and decides whether to
send them back directly towards the LIU shelf (case of extra Abis timeslots,
which explains why the extra Abis timeslots have no impact on the BSC
Evolution) or towards one of the CCP boards.

LIU shelf: This module is in charge of the physical E1 connections, i.e.
Abis, AterCS and AterPS.

3.3.2.1 BSC Capacity
In release B9, three configurations of BSC Evolution are offered:

Configuration
BSC Evolution (A9130BSC)
200TRX 400TRX 600TRX
Capacity FR 200 400 600

Nb TRX
DR 100 200 300
FR 200 264 264

Nb Cell
DR 100 200 264
FR 150 255 255

Nb BTS
DR 100 200 255
Nb GPU/GP 6 6 6
Nb SS7 links 8 16 16
Nb CICs 1024 2068 3112
Nb Active
CCP
In the ATCA
shelf
1 2 3
Nb TCU 50 100 150
Nb DTC CS 40 80 120
Nb DTC PS 24 48 72
Nb of E1 Abis 96 96 176
Ater CS 10 20 30
Ater PS 6 12 18


Nb of Extra
Abis TS
717 717 717
Erlang Traffic On A interface (Erlang) 900 1800 2600

Data in this table, based on [1] and [11]
Table 22: BSC Evolution Capacity

3.3.2.2 Delta BSC Evolution versus G2 BSC

.

For more details, please refer to [1]
3.3.2.3 CCP board

A CCP board contains several VTCUs and VDTC that corresponds respectively to TCU and
DTC software.
Thanks to the TCU allocation Evolution feature, several constraints existing in G2 BSC are
removed in A9130 BSC Evolution: all the VTCUs are managed as a pool where any Abis
signaling TS allocation can be routed to any TCU across CCPs boards.
The feature considers the removal of TSU concept where in A9120 BSC during any
extension/reduction of a TRE/BTS, the TCU allocation for RSL/OML was done within a TSU
i.e. set of 8 TCUs. With this feature TCU resource candidate is extended to all the TCUs
irrespective of the CCP baords i.e. not limited to 8 TCUs per TSU/BIUA as in A9120 BSC.
This also means that mapping between Abis & TCU will be replaced with free mapping of
any TRE to any TCU as per new TCU allocation algorithm
We have the following benefits as far as removing this constraint is concerned:
TCU resource allocation will become more flexible
No need to perform reshuffling in any of the cases i.e. TCU compact &
SDCCH hot spot.

In A9130 BSC Evolution, TCU allocation will only involve the mapping of
signaling channels i.e. RSL/OML on a TCU. Since traffic will be switched within
TPGSM so it does not make sense to map TCHs & EXTS on to the TCU.
Moreover TCU allocation algorithm for signaling links will be highly flexible as
we can allocated any available TCU from the TCU pool from configuration point
view i.e. all TCUs across CCP boards will belong to one pool.

Different Behaviors:
TSU is removed
No more SDCCH limitation per
TCU (32)
Higher capacity max. 600 TRX
Abis/Ater fixed mapping to LIU
boards
Same Behaviors
No change in logical model of the
BSC
No change in radio configuration
mechanisms
Same set of radio parameters
Same set of PM counters/indicators
as A9120 BSC.


1000 TRX
200 TRX
LIU 1 LIU 2 LIU 3 LIU 4 LIU 5 LIU 6 LIU 7 LIU 8 LIU 9 LIU 10 LIU 11 LIU 12 LIU 13 LIU 14 LIU 15 LIU 16
1 1 17 33 49 65 81 97 113 129 145 161 41 31 21 2 1
2 2 18 34 50 66 82 98 114 130 145 162 42 32 22 4 3
3 3 19 35 51 67 83 99 115 131 147 163 43 33 23 6 5
4 4 20 36 52 68 84 100 116 132 148 164 44 34 24 8 7
5 5 21 37 53 69 85 101 117 133 149 165 45 35 25 10 9
6 6 22 38 54 70 86 102 118 134 150 166 46 36 26 12 11
7 7 23 39 55 71 87 103 119 135 151 167 47 37 27 14 13
8 8 24 40 56 72 88 104 120 136 152 168 48 38 28 16 15
9 9 25 41 57 73 89 105 121 137 153 169 x 39 29 18 17
10 10 26 42 58 74 90 106 122 138 154 170 x 40 30 20 19
11 11 27 43 59 75 91 107 123 139 155 171 x 24 18 12 11
12 12 28 44 60 76 92 108 124 140 156 172 x 23 17 10 9
13 13 29 45 61 77 93 109 125 141 157 173 28 22 16 8 7
14 14 30 46 62 78 94 110 126 142 158 174 27 21 15 6 5
15 15 31 47 63 79 95 111 127 143 159 175 26 20 14 4 3
16 16 32 48 64 80 96 112 128 144 160 176 25 19 13 2 1
Abis ports (max 176)
Ater CS (max 48)
Ater PS (max 28)
200 TRX
400 TRX 400 TRX
1000 TRX
600 TRX 600 TRX
800 TRX 800 TRX
2
0
0
4
0
0
4
0
0
2
0
0
Abis ports
Ater Ports
Rules

A VTCU can handle a maximum of :
4 FR TREs (4 RSLs) or
2 FR + 1 DR TREs (3 RSLs) or
2 DR TREs (2 RSLs).
==> In other words TCU can handle maximum of 4 Eq. FR RSLs
TCU can handle maximum of 3 OMLs.

3.3.2.4 LIU shelf
The LIU shelf is in charge of the mapping of Abis towards Ater interface if the signal is
not routed to a CCP board. The Abis/Ater allocation and mapping realized by LIU boards is
fixed and it is shown in Figure 47.


Figure 47 Abis and Ater allocationon LIU boards / BSC capacity
N.B. Just configurations supporting 200, 400, 600 TRX are managed in B9.

3.3.3 BSC Dimensioning
The BSC dimensioning is based on the configuration & connectivity aspect, not
directly on the traffic counter analysis because the traffic analysis is already taken into
account at the lower NE layer i.e BTS and Abis.

Thus, the main priniple of BSC dimensioning is to define which BTSs together with
their Abis are connected towards the BSC in accordance to the BSC configuration
limitations and the BTS & transmission location constraints.

The below diagram shows the BSC dimensioning process:

Figure 48: BSC dimensioning process

In Figure 48, basically the BSC dimensioning consists of two following parts:
BTS inputs
Configurations
Location
BSC dimensioning process
BSC inputs
Software release
Available configurations
Architecture Constraints
Access transmissionNetwork topology
Core transmission network topology
Definition of sets of BTSs (BSC Area)
satisfying the archi tecture constraints
For each BSC area, choose a BSC
configuration
Check BSC border with RNP team
OK ?
No
Check Abis connectivity
Yes
OK ?
No
Choose an other BSC configuration,
if possibl e ?
No Yes
Check Ater connectivity
OK ?
No
Yes
Yes
Outputs
BSC configurations
BSC Areas
BTS inputs
Configurations
Location
BSC dimensioning process
BSC inputs
Software release
Available configurations
Architecture Constraints
Access transmissionNetwork topology
Core transmission network topology
Definition of sets of BTSs (BSC Area)
satisfying the archi tecture constraints
For each BSC area, choose a BSC
configuration
Check BSC border with RNP team
OK ?
No
Check Abis connectivity
Yes
OK ?
No
Choose an other BSC configuration,
if possibl e ?
No Yes
Check Ater connectivity
OK ?
No
Yes
Yes
Outputs
BSC configurations
BSC Areas


Design BSC area
Parenting Abis TSU ports of the BSC

3.3.3.1 Design BSC area
As the design of BSC area is mainly based on the BTS and Transimission locations,
it is recommended to perform this design by mean of a geographical program e.g
Mapinfo or other equivalent programs.

There are three steps to complete designing the BSC area:

1) Get BTS position & Configuration
BTS positions are important to create a set of BTS as BSC area in the same
geographical area.

Moreover, the BTS configuration that includes: -
- Number of TRX per cell (Full rate and Dual Rate)
- Maximum number of extra TS defined by the O&M parameter
N_EXTRA_ABIS_TS at BTS level
- Number of Abis links defined for this BTS (eventual use of 2
nd
Abis link)
gives the TRX & Abis load that this BTS will have at BSC level.

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

2) Get transmission planning & BSC positions


Then, transmission plan is gathered to allow & verify BTS physical connection
to BSC planned location (several BSCs may be colocalised)

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

3) BSC area definition
The aggregation of TRX, cell, BTS, Abis loads at BSC level is used to defined
BSC configuration (please refer to Table 20).
It is recommended not to overcome 80% TRX load at BSC level, to allow for
network extension.

Figure 51: BSC area definition design BSC area step 3
3.3.3.2 Parenting Abis ports of the BSC


It consists of two following steps:
1) Transmission load checking
The number of Abis links used from one geographical location to another
depends on: -
- Number of BTS in that location
- Number of Abis used per each BTS
- Eventual multidrops defined between several BTS (on the same location
and/or on different ones)
- Number of E1
This number of Abis used between each geographical location has to be
checked with the actual available nb of E1 links which will be implemented in
the network.

This task is usually performed by the transmission team.

Figure 52: Transmission load checking

2) BTS / Abis parenting on BSC
Each Abis used in a given BSC area has to be mapped to a given AbisTSU
board & port of this BSC, taking into account the corresponding Abis TSU
configuration rules described in section 3.3.1.2 (In case of MxBSC, no explicit
BTS/Abis parenting is needed: just LIU shelf engineering rules for Abis ports
allocation, described in section 3.3.2.4, must be respected).
It is highly recommended to have an evenly spreaded load on each AbisTSU
boards to forecast the possibility for network evolution i.e adding TRX,
changing TRX configuration from FR to DR, adding ExtraAbis TS, etc.


The picture below gives an example of such a topology, using the AMT .NET
tool.
Figure 53: BTS / Abis parenting on BSC done by AMT.NET

3.3.4 LA Dimensioning
Definition: A location area (LA) is the area in which a normal page for a particular mobile,
registered in this LA, will be broadcasted.
Too large LAs may lead to a too high paging load in the BTS resulting in congestion and lost
pages.
Smaller LAs reduce the paging load in the BTSs as well as in the BSCs. However, small LA
also means a larger number of LA border cells. Each time a mobile crosses the boarder
between two LAs, a location updating is performed. The LA updatings has an effect on the
load on the signaling subchannels, SDCCH, in the LA border cells.

Target: The aim of LA dimensioning is to define the appropriate size of a Location Area,
which is mainly driven by the maximum number of paging the LA can handle, i.e. by the
traffic seen on this Location Area.

Gathered Counters:

MC8a CCPGRQN Number of Paging message seen on Abis interface (PCH usage).
Table 23: Counter list LA dimensioning


Note: the MC8a values for each cell in the same LA should be identical. However sometimes it was observed
(from the counter of live networks) that some cells in the same LA have the different MC8a value for this case,
the most frequency value will be chosen to be represented the paging traffic of the LA.

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

Methodolgy:
The maximum number of paging per Location Area is derived from the paging limitations at
Um interface, Abis Interface and BSC sides as following details.

Um interface Limitation Combined cells
There are 3 CCCH blocks per M51 frame for combined cells.
Among those 3 blocks, 3 minus BS_AG_BLK_RES are reserved for paging
(BS_AG_BLK_RES = 1 as an usual default value for combined cells).
A 2.5 Paging/PCH value has been used to derive the maximum paging load per Location
Area.

A value of 3 paging or even 4 paging per PCH can be reached if and only if:
- High PCH load (> 80%). The (safe) engineering limit taken later makes likely that
this load is not reached. Indeed the CCCH capacity is not a linear function because of
the paging request encoding method. Real time simulations performed internally show
that when the 3 Paging/PCH ratio is reached we usually have a high blocking rate on
PCH (about 5%), which will induce repetition by the MSC.
- Very good distribution of MS among all paging groups. This depends on the IMSI
distribution.

Therefore;
Available blocks for paging per hour:
2 PCH blocks/Multiframe * (3600s/ 235ms) = 30,638 PCH blocks/ hour
Note: 235 ms is the period of 51 Multiframe
Maximum paging per hour:
2.5 paging/Block * 30,638 Blocks = 76,595 paging/hour (100%load)

When 60% engineering limit is applied Alcatel recommemdation
Recommended max paging per hour: 45,957 paging/hour
Recommended max paging per second: 12,76 paging/second


Um interface Limitation Non-combined cells
There are 9 CCCH blocks per 51 Multiframe for non-combined cells.
Among those 9 blocks, 9 minus BS_AG_BLK_RES are reserved for paging
(BS_AG_BLK_RES = 4 as an usual default value for non-combined cells).
The calculation is similar to the one related to combined cell above. The only difference is a
higher number of paging blocks per 51 Multiframe.

Therefore;
Available blocks for paging per hour:
5 PCH blocks/Multiframe * (3600s / 235 ms) = 76,595 PCH / hour
Maximum paging per hour:
2.5 paging/Block x 76,595 Blocks = 191,489 paging/hour (100%load)

When 60% engineering limit is applied Alcatel recommemdation
Recommended max paging per hour: 114,893 paging/hour
Recommended max paging per second: 31,91 paging/second

Abis Interface Limitation
The Abis limitation is determined by the maximum amount of paging commands that can be
sent through the Abis interface to the cell.
An Abis can carry a paging load of 33 paging commands per second.
Or

Maximum paging per hour: 118,800 paging/hour

G2 BSC Limitation
The BSC limit is 70 paging/sec on the A interface (Alcatel traffic model).


MxBSC Limitation
The BSC limit is 95 paging/sec on the A interface (Alcatel traffic model).



The paging on the A interface is the sum of the paging on all Location Area which are
configured on a BSC. So it depends on the Paging rate on Location Area and on the number
of Location Areas in a BSC.

Limitation Factor
The minimum value from those four limitations is therefore given by the Um interface, which
is 45,957 pagings/hour if the Location area contains some combined cells or is 114,893
pagings/hour if the Location area contains only non-combined cells.

This conclusion holds true as long as there are max 5 Location Areas covered by the BSC
(252,000/45,957 = 5.5) (which should always be the case but it is probably worth to mention
also about it).
In case of non-combined cells, 2 Location Areas may be covered by one BSC
(252,000/114,893 = 2.19).

Assessment:
Below figure shows the LA dimensioning assessment.

Figure 54: LA dimensioning assessment

Total MC8a > 252000
(Total MC8a of all LA in the BSC)
Re-Design LA, and/or
Reduce nb of LA per BSC
All Cells in a LA are non-combined
MC8a > 45,957 MC8a > 114893
Yes
No
No
No
No Yes Yes
Yes
OK
OK
Re-Design LA Change to non-combined
Re-Design LA
Check BSC Limitation
Check Um Limitation


In , the assessment is to perform checking measured paging traffic versus the paging
limitation at the different levels:
- BSC limitation
- Um limitation
For checking Abis limitation: it is not significant, because Um limitation (45957 paging,
combined and 114893 paging, non-combined) is lower than Abis one (118800 paging).
Therefore, Um limitation is usually triggered first.

3.3.5 RA Dimensioning
A Routing Area (RA) is a sub-set of one LA and identifies one or several cells in a location
area.
In case of a mobile terminating call in GSM, the MS in idle mode will be paged in all cells
belonging to the LA, which the MS is present.
For PS services, the SGSN pages the MS in STANDBY state, in case of a downlink TBF. It
means additional signalling effort (for GPRS/EDGE) will be produced in the network: at each
DL TBF establishment the MS will be paged in the RA if the MS is in the GMM Standby
state

Introducing RA, which should be smaller than LA, the signalling effort for paging is
now more focused to a smaller area, the signalling load for the cells being reduced.

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

Target: To estimate the number of RA per LA.
Gathered Counters:

P53a TRPCHPAN Number of (BSCGP) PAGING REQUEST for PS paging sent to
the MS (through the BSC which manages the PCH resource).
MC8a CCPGRQN Number of Paging message seen on Abis interface (PCH usage).
Table 24: Counter list RA dimensioning
Note: the P53a (respectively MC8a) values for each cell in the same RA (respectively LA) should be identical.
However sometimes it was observed (from the counter of live networks) that some cells in the same RA


(respectively LA) have the different P53a (respectively MC8a) value for this case, the most frequency value
will be chosen to be represented the paging traffic of the RA (respectively LA).

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

Methodology:

Main rule: RA size must be smaller than or equal to the LA size

It is not possible to define a RA across a LA border (e.g. one cell from LA1 and two cells
from LA2).

Other rules:
- One RA can contain one or several cells
- One cell cannot belong to two RA
- Cells from one BTS can be allocated to different RA
- The maximum number of RA in a LA is 256 (0, 1, 2... 255)

Some general remarks apply:
If the timer t_ready = high, MS doesnt need to be paged too often so RA size can be as big as
the LA size.
But if t_ready = low, RA size needs to be smaller than LA size

The simple RA dimensioning, that is the RA size equals to LA size, is usually applied for the
initial RA area design.
However, it is recommended to perform afterward the RA dimensioning based on the GPRS
paging traffic counter. The main idea is to check whether the RA size is appropriate and not
create the high ratio of GPRS paging traffic (P53a) when compared to the global paging
(MC8a); otherwise, the smaller RA size may be needed to reduce the global paging load and
to avoid PCH resource overload due to GPRS.
Note: GSM and GPRS services share the PCH (CCCH) resources (if the master channel feature is
not activated) in order to transport the paging traffic.

GPRS paging load ratio = P53a / MC8a

If this ratio is greater than 20% during the day hours, the solution to reduce global paging load
may be spliting RA into several RAs for a corresponding LA (one LA: several RA).


Assessment:
The limited GPRS paging load ratio can be modified.
If the measured GPRS paging load ratio is over the given limit, the re-design RA area
(implying to have the smaller RA size) is triggered.
3.3.6 Summary of LA/RA dimensioning process
As master PDCH is not applicable, CS & PS pagings uses the same radio channel i.e. PCH, so
LA and RA dimensioning should be performed together.

Below is summary of LA/RA dimensioning process:

1) Observe firstly only MC8a (CS + PS paging) @ busy hour for every LA.

2) Compute the paging load by MC8a / Max # pagings
Whereas Max # pagings equals to:-
- 191,489 pagings/hour: for non-combined cells
- 76,595 pagings/hour: for at least one combined cell in a LA

3) Assess whether any LA has the current paging load exceeding 60%.
If not, it is OK => no LA/RA re-dimensioning required
If yes, continue to 4)

4) Check GPRS paging load ratio = P53a / MC8a
Note: P53a = PS paging while MC8a = total Paging (CS&PS).
If this ratio is greater than 20%, the solution to reduce global paging load may be splitting
RA into several RAs for a corresponding LA (one LA: several RA).
If this ratio is low, the solution should be introducing a new LA/RA and/or LA/RA re-
dimensioning. In addition, if there is any combined cell in a LA, it is recommended to change
to non-combined cell in order to increase the Max # paging of the LA.

Example:
If there is one LA which has one RA (LA size = RA size), and at busy hour MC8A = 120,000
and P53a = 36,000. All cells in the LA are non-combined.
Then:


- Paging load of 1 LA with 1 RA = 120000/191489 = 62.6% !! (> 60%)
- CS Paging load = (120000-36000)/191489 = 43.8%
- PS Paging load = 36000/191489 = 18.8%
- GPRS paging load ratio = 36000/120000 = 30%
- As GPRS paging load ratio > 20%, we may try to reduce paging load by spliting
RA into several RAs for this LA as below examples:
- Estimated Paging load of 1 LA with 2 RA = 43.8% + 18.8%/2 = 53.2%


3.4 AterMUX and A interfaces

AterMUX interface:
The AterMUX interface is both the interface between the BSC and the TC, and between
the BSC and the MFS.
The AterMUX interface may transport pure circuit, and then it is
called AterMUX CS.
When it transports packet traffic, it is called AterMUX PS.
It is possible to mix PS and CS traffic on one single AterMUX link, and
then it is called AterMUX CS/PS.
On the AterMUX CS interface, a 64 kb/s timeslot transmits information for 4 Circuit
Switch calls (whatever they use FR or HR codecs).
On the AterMUX PS interface, a 64 kb/s timeslot supports 4 GCHs.

A interface:
The A interface is a set of 2 Mbit/s PCM links carrying CS traffic between the TC and
the MSC.
One 64 kbps channel on A is corresponding to one 16 kbps channel on AterMUX.

AterMUX interface versus A interface:

Figure 58: AterMUX and A relationship

Since release B7.2, it is possible only 4:1 multiplexing at BSC side and 4:1 de-
multiplexing at TC side.
Therefore, the number of A interface links is four times of the number of AterMUX CS
interface links. That is:

TC BSC MSC
AterMUX A
N AterMUX CS Links 4*N A Links


3.4.1 AterMUX configuration
The AterMUX interface is supported by 2 Mbps PCM links (64kpbs * 32 TSs) with
the structure as shown below.

Figure 59: AterMUX interface structure

In Figure 59, AterMUX consists of the following channels:
TS 0 transparency: used for frame synchronization
Traffic Channels: TCH in case of CS traffic but GCH for PS traffic
Signaling Channels: 5 types of signalling
- Qmux: always carried in the first nibble of TS 14. One Qmux exists on the
2 AterMUX of the first Ater TSU of each rack of the BSC.
- Alarm octet: reporting technical hitches on any DTC so it must be
conveyed on each PCM of each Ater TSU.
- SS7: carrying the signaling information about call control and mobility
management between BSS and MSC. There are a maximum of 16 SS7 links.
This TS is unused for AterMUX PS but cannot be used for GCH.
- X.25: If X.25 is used, it is implemented on the 2 PCM of the first Ater TSU
of the first rack of the BSC.
- GSL: It handles signaling for GPRS paging and for all synchronization
between the BSC and the MFS (TS 28). Each GPU/GP requires at least one
GSL channel (depending on the traffic), so there can be 0 or 1 GSL per
AterMUX. For security reasons, it is recommennded to have 2 GSL channels
per GPU/GP.
AterMUX CS AterMUX PS
CH# 1 CH# 2 CH# 3 CH# 4 CH# 1 CH# 2 CH# 3 CH# 4
TS 0 TS 0
TS 1 TCH TCH TCH TCH TS 1 GCH GCH GCH GCH
TS 14 Qmux TCH TCH TCH TS 14 GCH GCH GCH GCH
TS 15 TS 15
TS 16 TS 16
TS 28 TCH TCH TCH TCH TS 28
TS 31 TS 31 GCH GCH GCH GCH
TS 0 Transparency
Alarm octet
SS7 (not used)
GSL
Alarm octet
SS7
X25
TS 0 Transparency


3.4.1.1 AterMUX CS and A

AterMUX CS:
Referring to AterMUX CS structure (in Figure 59), below figure presents the
AterMUX CS configurations that depend on the G2 BSC configuration.

Figure 60: AterMUX CS interface configuration G2 BSC
In Figure 60, the number of TCHs is different for each AterMUX link as it depends
on the appearance of signaling channels.
Remark: with BSC configuration 6 Ater TSU 9 PCM 1 & 2 do not convey SS7
links; however, TS 16 is left unused and does not convey any traffic channels, so
total TCH remains 116 not 120.
For G2 BSC, the maximum number of AterMUX CS interfaces is summarized in
below table.

Table 27: Max number of AterMUX CS interfaces G2 BSC

For BSC evolution (A9130 BSC), the maximum number of AterMUX links for CS
traffic (from BSC to TC) is 30 and they are addressed by Ater-Hway-TP from 1 to
30.
A interface:
X25 Qmux Alarm SS7 TCH Number
PCM 1 (x) x x x 111
PCM 2 (x) x x x 111
PCM 1 x x 116
PCM 2 x x 116
PCM 1 x x 116
PCM 2 x x 116
X25 Qmux Alarm SS7
PCM 1 x x x 115
PCM 2 x x x 115
PCM 1 x x 116
PCM 2 x x 116
PCM 1 x x 116
PCM 2 x x 116
X25 Qmux Alarm SS7
PCM 1 x x x 115
PCM 2 x x x 115
PCM 1 x x 116
PCM 2 x x 116
PCM 1 x 116
PCM 2 x 116
Total TCH 2074
Ater TSU 9
BSC Rack 1
BSC Rack 2
BSC Rack 3
Ater TSU 5
Ater TSU 6
Ater TSU 7
Ater TSU 8
Ater TSU 1
Ater TSU 2
Ater TSU 3
Ater TSU 4
G2 BSC Nb of Ater TSU Max nb of AterMUX CS
Configuration 1 2 4
Configuration 2 3 6
Configuration 3 5 10


The channel mapping between AterMUX CS interface and A interface is presented
below:

Figure 61: Channel mapping between AterMUX CS and A

The A channel is known as CIC (Circuit Identification Code).
Each 16kbits/sec TCH of AterMUX CS is mapped on one 64kbits/sec CIC of A
interface. So, one AterMUX CS link requires four A links to complete the channel
mapping.
Table 28 presents the maximum number of A interfaces in case of G2 BSC.

Table 28: Max number of A interfaces G2 BSC
3.4.1.2 AterMUX PS
AterMUX CS
CH# 1 CH# 2 CH# 3 CH# 4
TS 0
TS 1
TCH TCH TCH TCH
TS 2
TCH TCH TCH TCH
:
:
TS 14 Qmux TCH TCH TCH
TS 15
TS 16
TS 17
TCH TCH TCH TCH
TS 18
TCH TCH TCH TCH
:
:
TS 30
TCH TCH TCH TCH
TS 31
TS : 64 Kbits/sec
Alarm octet
SS7
X25
:
:
:
:
A Interface
TS 0
TS 1
TS 2
TS 3
TS 4
TS 5
:
:
:
:
:
:
:
TS 30
TS 31
TS : 64 Kbits/sec
CIC 31
CIC 4
CIC 5
:
:
:
:
:
:
CIC 30
CIC 1
CIC 2
CIC 3
:
G2 BSC Nb of Ater TSU Max nb of AterMUX CS Max nb of A
Configuration 1 2 4 16


Referring to AterMUX PS structure (in Figure 59), below figure presents an example of
AterMUX PS configuration for a GPU.

Figure 62: AterMUX PS interface configuration - GPU
Notes:
- One GPU can support max. 480 GCH (a GPU has 4 DSPs one of which
supports 120 GCH).
- One GP can support max. 960 GCH (a GPU has 4 DSPs one of which supports
240 GCH).
- 5 AterMUX PS are needed to support 480 GCH (9 AterMUX PS are needed to
support 960 GCH)
- Note: The max capacity of 5 AterMUX PS is 572 GCH, which is enough to support 480 GCH
refer to Figure 59.
- At least one GSL is required for a GPU/GP, but it is recommended to have 2
GSLs per GPU/GP as the security reason is concerned.
- Maximum 1 GSL is possible for an AterMUX PCM link (TS 28).

For G2 BSC, the maximum number of AterMUX PS (BSC-MFS) is depended on BSC
configuration as shown in Table 29.

Table 29: Max number of AterMUX PS G2 BSC

For BSC evolution (A9130 BSC), the maximum number of AterMUX links
dedicated for PS traffic (from BSC only to MFS) is 18 and they are addressed by
Ater-Hway-TP from 31 to 48.

One GPU
G2 BSC Max nb of AterMUX PS
Configuration 1 4
Configuration 2 6
Configuration 3 10
Configuration 4 12
Configuration 5 16
Configuration 6 18
GSL Alarm SS7 GCH Number
PCM 1 x x x 112
PCM 2 (x) x x 112
PCM 3 x x 116
PCM 4 x x 116
PCM 5 x x 116
Total GCH 572


3.4.1.3 AterMUX CS/PS
The following information describes GPRS and GSM traffic on the Atermux of the
BSS .
Sharing AterMUX PCM Links

Figure 63: Sharing AterMUX links

From

Figure 63: - X is the number of AterMUX between BSC and GPU/GP.
- Y is the number of AterMUX between GPU/GP and TC.
- Z is the number of Gb between GPU/GP and SGSN.

Rule of sharing AterMUX Link:

The maximum number of E1 links depends on the BSC/MFS platform and can be
summarised in the following way:
- For legacy MFS: 16
- For Mx MFS: 10/12/14/16 depending on the configuration. For more details,
please refer to section 3.6.2.1.
Sharing AterMUX PCM Timeslots
For mixed GPRS/CS Atermux links (or AterMUX CS/PS), the traffic TS can be used
12.5% or 25% or 50% or 75% or 100% for GPRS, with or without GSL LAPD see
Table 30.

BSC
GPU
(MFS)
TC
SGSN
X
Y
Z
1) X+Y+Z <= Maximum nb of E1 links

2) When the AterMUX transports mixed traffic: X=Y


PS Traffic Ratio 1/8 1/4 1/2 3/4 Full
TS 0
TS 1 TCH TCH TCH TCH GCH
TS 8 TCH TCH TCH GCH GCH
TS 15
TS 16
TS 17 TCH TCH GCH GCH GCH
TS 24 TCH GCH GCH GCH GCH
TS 28 GCH GCH GCH GCH GCH
AterMUX CS/PS
TS 0 Transparency
Alarm octet
SS7
CS Nb of TCH PS Nb of GCH
Full 116 Null 0
7/8 100 1/8 16
3/4 84 1/4 32
1/2 56 1/2 60
1/4 28 3/4 88
Null 0 Full 116

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

The Figure 64 presents details of Timeslot sharing between CS (TCH) and PS (GCH):

Figure 64: AterMUX CS/PS Timeslot
configuration
Notes:
- The TS numbers are a maximum value, and depend on the presence (or not) of
signaling links.
- The use of GSL on a given Ater Mux takes the place of 4GCH nibbles on this
link. See Figure 59.
- The Atermux channels located on the same Atermux TS as the Qmux (TS14)
cannot be used for GPRS (they are kept as CICs).
- TS 15 is always occupied for N7, even if it is not used.

However, when there is enough PS traffic to fill 2 or more PCMs, there is an advantage
to dedicate complete PCMs to PS (AterMUX PS) rather than mixing PS with CS traffic


AterMUX CS/PS). Indeed, doing so avoids connecting the MFS to the Transcoder, with
AterMUX PCMs not fully devoted to CS traffic, and thus avoids wasting transcoder
resource. So, the minimum usage of mixed AterMUX (CS + PS) is recommended.

3.4.2 AterMUX Dimensioning
The purpose of the dimensioning is to define the number of required AterMUX links
based on the measured traffic.
According to previous sections, there are 3 types of AterMUX interfaces i.e. one
dedicated for CS traffic, one dedicated for PS traffic, and the last one with mixed
(CS&PS) traffic.
The different dimensioning methods for each AterMUX type are presented in the
following sub-sections.

3.4.2.1 AterMUX CS
Target: To estimate the number of AterMUX-CS links per BSC.
Gathered Counters:

MC400 SDTRT Cumulated time during which the SDCCH subchannels
belonging to the related static or dynamic SDCCH timeslots are
busy.
Table 31: Counter list AterMUX-CS dimensioning

Measured Object: BSC

Note: 2 Busy Hours will be defined:
- Busy Hour is the hour gives the highest TCH traffic (i.e MC380a+MC380b) of the day.
- Busy Hour is the hour gives the highest SDCCH traffic (i.e MC400) of the day.
Methodology:
The process of AterMUX-CS dimensioning is presented below.


Erlang B
GoS:
% TCH
blocking
Nb of
required SS7
per BSC
INPUT OUTPUT METHOD
Signalling Traffic
User Traffic
Required
SDCCH
Traffic
Required
TCH
Traffic
GoS:
% SS7
blocking
Erlang B
Nb of
required TCH
per BSC
Nb of
required
AterMUX-CS
links per BSC
Nb of
required
AterMUX-CS
links per BSC
Choose
Max value
Final nb of
required
AterMUX-CS
links per BSC

Figure 65: AterMUX-CS dimensioning process

From Figure 65, the AterMUX-CS dimensioning is based on 2 different kinds of
traffic i.e. signaling & user traffic. After applying the methods, each of traffic may
need the different number of AterMUX-CS link, and then the final number of required
AterMUX-CS link will be the maximum number.

Signalling Traffic (please refer to SS7 dimensioning)
3.4.2.1.1 SS7 Dimensioning
INPUT

The required SDCCH traffic is computed as below formula.

in m traffic SDCCH Measured traffic SDCCH quired arg % 15 _ _ _ _ Re + =

Where:

3600
400
_ _
MC
traffic SDCCH Measured =


Remark: a 15% margin is added to the traffic in order to take into account two
phenomena:
- Measurements have been retrieved for limited periods
- The counter busy hour average effect: RNO indicators do not provide an
instantaneous value of the number of channels occupied but the traffic
measured during one hour. Moreover, the busy hour is not determined via a
sliding window but by selecting the maximum of the measure realized each
hour (please see graph below)

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

The other input is Grade of Service (GoS), which is defined by the required SS7
congestion rate (p
SS7
). Normally GoS should be given or agreed by the Mobile
Operator.
GoS: Required blocking probability p
SS7

The typical maximum blocking rate at AterMUX interface is 0.1%

METHOD

The dimensioning of SS7 links in the Alcatel BSS is linked to three issues:
SCCP traffic
Processor load
Physical link load
This section will explain here the SCCP traffic issue without going in the detailed of
processor load and physical link load.

Time (H)
8H00 9H00 10H00 11H00 12H00 13H00 14H00
RNO traffic measurements
Exact Busy hour
Peak traffic
N
u
m
b
e
r

o
f

o
c
c
u
p
i
e
d

C
h
a
n
n
e
l
s


For each scenario, a dedicated SCCP connection is open between the BSS and the
MSC, for the duration of the scenario. It will carry all the signaling pertaining to that
scenario.
Therefore, there is one SCCP connection open for:
Speech calls, for a duration approximately equal to the SDCCH + TCH
holding time
External handover, for a duration equal to the overlap time, during
which the TCH resources in the old and the new BSC are
simultaneously activated
Location updates, for a duration approximately equal to the SDCCH
holding time
SMS and other services, for a duration approximately equal to the
SDCCH holding time
As seen above, the most traffic on SCCP connections (or SS7 links) is related to the
SDCCH traffic

So, the SS7 dimensioning will define the number of required SS7 links according to
the measured SDCCH traffic at BSC level.

Below is the important configuration rule to be concerned for SS7 dimensioning.

Since B7.2,
The Alcatel BSS with G2 BSC provides 256 SCCP connections per SS7 link.
According to CCITT recomandations a maximum load of 40% must be
accepted on a SS7 link 103 SCCP connections can be supported per SS7 link
There is one SS7 link per AterMUX CS link.

As SS7 is associated to signaling CS traffic only, Erlang B can be applied to calculate
the required number of SCCP connections according to required signaling (SDCCH)
traffic and the target congestion rate.

OUTPUT

Number of required SCCP Channels/Connections:
= Erlang B (Required_SDCCH_traffic, p
SS7
)

Number of required SS7 Links:
This can be derived from the total number of required SCCP connections, as we
know that 103 SCCP connections are available for one SS7 link. That is;
(
(
(
=
103
_ _ _
_ 7 _ _
s Connection SCCP required Nb
links SS required Nb


Number of required AterMUX-CS Links (1)
= Number of required SS7 Links

For example:
If the total number of required SCCP connections of BSC x is 1000.
Then, the number of required SS7 links of BSC x is 10 links.
Identically to the number of SS7 links, the number of needed AterMUX-CS links
is 10.

User traffic
INPUT

The required TCH traffic is computed as below formula.

in m traffic TCH Measured traffic TCH quired arg % 15 _ _ _ _ Re + =

Where:

3600
380 380
_ _
b MC a MC
traffic TCH Measured
+
=
Note: a 15% margin is added to the required traffic - see more explanation in Figure
66

The other input is Grade of Service (GoS), which is defined by the required
AterMUX-CS congestion rate (p
AterMuxCS
). Normally GoS should be given or agreed
by the Mobile Operator.
Required blocking probability p
AterMuxCS

The typical maximum blocking rate at AterMUX-CS interface is 0.1%.

METHOD

Concerning only CS traffic, the statistical law Erlang B is used during the
target GoS.
As AterMUX-CS is associated to CS traffic only, Erlang B can be applied to calculate
the required number of TCH channels according to required TCH traffic and the target
congestion rate.
OUTPUT
Number of required TCH:
= Erlang B (Rquired_TCH_traffic, p
AterMuxCS
)


Number of required AterMUX CS Links (2):
This can be derived from comparing the total number of AterMUX CS channels
(TCH) with AterMUX CS link capacity, which is shown in Figure 60.
For example:
If the total number of TCH per BSC x is 1200 TCHs.
Then, the number of required AterMUX-CS links of BSC x is 11 links.
Note:
From Figure 60, the total capacity of 11 AterMUX CS links is:
111TCH(link#1) + 111TCH(link#2) + 116TCH(link#3) + 116TCH(link#4) +
116TCH(link#5) + 116TCH(link#6) + 115TCH(link#7) + 115TCH (link#8) +
116TCH(link #9) + 116TCH(link #10) + 116TCH(link #11)
= 1264 TCHs > 1200 TCHs

Then,

Final number of required AterMUX CS Links:
= Max (Required AterMUX CS Links (1), Required AterMUX CS Links (2))

3.4.2.1.2 A Dimensioning:

According to Figure 61, basically the number of required A interfaces depends on the
number of AterMUX-CS links connected to the transcoder as following relation;

Number of required A Links = Number of required AterMUX CS links * 4

For example;
If the total number of required AterMUX CS links of TC x is 40.
Then, the number of required A links of TC x is 160 links (40*4).


3.4.2.2 AterMUX PS
AterMUX-PS dimensioning is based, like AterMux-CS dimensioning, on 2 different
kinds of traffic i.e. signaling & user traffic. After applying corresponding methods,
each of traffic may need a different number of AterMUX-PS link, and then the final
number of required AterMUX-PS link will be the maximum number.
Dimensioning methods for Signaling traffic are described in section 3.4.2.2.2
- Dimensioning methods for User traffic are described in section 3.6.3
- Section 3.4.2.2.1 presents a global view on the AterMux-PS dimensioning process:
1. At which network element level it is applied
2. How the output of dimensioning methods for signaling traffic and for user
traffic are combined together in order to obtain the final recommandation

3.4.2.2.1 Process description
AterMux-PS dimensioning process must be executed at:
BSC level (doing the hypothesis of a well balanced traffic distribution among the
GPU/GP boards connected to the BSC)
AND
GPU/GP level (in case of multi-GPU configuration and if no additional GPU/GP
resource adding found through the method application at BSC level) in order to
handle congestion situations due to unbalanced traffic/cell distribution/mapping on
GPU/GP boards connected to the BSC. In this case:
a reshuffling operation should be done, before adding GPU/GP/Atermux
resources, if needed, in order to be sure about the congestion root cause
If the reshuffling does not solve the congestion situation, additional resources,
according to the dimensioning method result, should be added
N.B. If, running the dimensioning assessment method, more than 1 GPU/GP
board are identified as under-dimensioned (i.e. they are not able to handle the
required traffic) the adding of GPU/GP boards will be done in an iterative way
(1 GPU/GP at once) monitoring the consequent impact on the AterMux PS
interface.

In Figure 67 the process for AterMux PS dimensioning that must be applied at BSC
level, is presented:


AterMux dimensioning
Assessment for GSL traffic
Assessment for user traffic
GPU/GP dimensioning
Assessment
# Needed
GCH
max
# AterMux PS per GPU/GP
2 (for security reason)
# Needed
GSL links
# GPU/GP
# GSL links
(at least 2 per GPU/GP)
Aterlink
GCH_Capacity
# AterMux PS
# AterMux PS per GPU

(user traffic)

(GSL traffic)
GPU/GP dimensioning
Assessment
# Needed
GCH
max
max
# Needed
GSL links
# GPU/GP
# GSL links
# GPU/GP
# GSL links
Aterlink
GCH_Capacity
# AterMux PS

(user traffic)

(user traffic)

(GSL traffic)

(GSL traffic)
GPU/GP dimensioning
Assessment
# Needed
GCH
max
# AterMux PS per GPU (esti mated at
BSC level)
# Needed
GSL links
# GSL links
Aterlink
GCH_Capacity
# AterMux PS

(user traffic)

(GSL traffic)
If #GPU/GP=1
2
max

(user traffic)

(GSL traffic)
# AterMux PS
at BSC level
# Needed
GSL links
at BSC level
New #GPU/GP at BSC level
If #GPU/GP>1 then 1 GPU/GP
must be added and the
#AterMux PS per GPU/GP (for all
GPU/GPs)
must be estimated as:
GPU/GP dimensioning
Assessment
# Needed
GCH
max
# AterMux PS per GPU (esti mated at
BSC level)
# Needed
GSL links
# GSL links
Aterlink
GCH_Capacity
# AterMux PS

(user traffic)

(user traffic)

(GSL traffic)

(GSL traffic)
If #GPU/GP=1
2
max

(user traffic)

(GSL traffic)
# AterMux PS
at BSC level
# Needed
GSL links
at BSC level
GPU/GPs)
2
max

(user traffic)

(GSL traffic)
# AterMux PS
at BSC level
# Needed
GSL links
at BSC level
GPU/GPs)

Figure 67 AterMux-PS dimensioning process at BSC level

On the other hand, the process that is applied at GPU/GP level, if the output of the process
applied at BSC level does not recommend the adding of additional GPU/GP resources , is
described in Figure 68:


Figure 68 AterMux PS process at GPU/GP level
If, applying the dimensioning method at one GPU/GP, the result is that 1 board is enough
in order to support the required traffic, the number of needed AterMux PS links for this
GPU/GP will be assessed.
Otherwise, if the board is overloaded, 1 additional GPU/GP board will be recommended to
be added and the number of AterMux PS links per GPU/GP will be re-assessed at BSC level.
Some examples on the different possible scenarios are presented hereafter:
Example 1:
- BSC level (current #GPU/GP=2 w/ 2 AterMux links per GPU/GP):
- #Needed GCH = 500
- #Needed GPU/GP = 2
- #AterMux PS per BSC = 500/112 = 5
- #AterMux PS per GPU/GP = 5 / 2 = 3
- GPU/GP level
- GPU1
- #Needed GCH GPU1 = 200
- #AterMux PS per GPU/GP = Max (200 / 112, 3) = 3
- GPU2
- #AterMux PS per GPU/GP = Max ( 300 / 112, 3) = 3
1. Reshuffle operation is done in order to try to balance traffic between the two GPUs
2. Add 1 AterMux PS links on both GPUs


Example 2
- #Needed GCH = 400
- #AterMux PS per BSC = 400/112 = 4
- GPU/GP level
- GPU1
- GPU2
2. If the reshuffle operation has not the wanted effect, add 1 AterMux PS to GPU2.

Example 3:
- #Needed GCH = 500
- #AterMux PS per BSC = 500 / 112 = 5
- GPU/GP level
- GPU1
- GPU2
2. If Reshuffle has not the wanted effect:
- #Needed GCH at BSC = 500
- #AterMux PS per BSC = 500 / 112 = 5


3.4.2.2.2 GSL Dimensioning
Target: To estimate the number of AterMUX-PS links needed per GPU/GP,
according to signaling traffic.

GSL dimensioning process is composed of two dimensioning methods that allow to
asses the GSL load in terms of:
- channel bandwidth
- number of messages per second sent by the MFS to the BSC (the opposite
direction, BSC to MFS, being considered as less critical in terms of GSL load)
-
-
-
-

3.4.2.2.2.1 GSL dimensioning method based on bandwidth

Gathered Counters:

P41 TALAPDLN Number of kilo bytes sent to the BSC on the LapD link.
P42 TALAPULN Number of kilo bytes received from the BSC on the LapD link.
Table 32: Counter list GSL dimensioning

Measured Object: LAPD
Note: Busy Hour means the hour gives the highest signaling traffic i.e max (P41, P42) of the day.

Methodology:
Calculate GSL (signaling) traffic for each AterMUX-PS link
28800
) 42 , 41 (
_ _
P P Max
traffic GSL Measured = Erlangs
Note: 1 Erlang = [Gb TS speed (64Kbits/s) * 3600] / 8 =28800 K bytes.

Assessment based
on GSL bandwidth
Assessment based
on the number of
GSL messages per second
max
2
(for security reason)
# GSL links
Assessment based
on GSL bandwidth
Assessment based
on the number of
GSL messages per second
max
2
(for security reason)
# GSL links


BSC
GPU
K_GSL
GSL messages
buffer
GSL_round_trip_delay
A message is kept in the buffer
during GSL_round_trip_delay
BSC
GPU
K_GSL
GSL messages
buffer
BSC
GPU
K_GSL
GSL messages
buffer
Estimate capacity of one GSL per AterMUX-PS link = 0.42 Erlangs
Note: 0.42 Erlang is derived by applying reverse-Erlang C law of 4*16kbps channel
(equivalent to 1 GSL 64kbps channel) with GoS 99.9% quantile 0 delay second.

Calculate GSL load
% 100
) 42 . 0 ( _
_ _
_
=
=
Erlangs Capacity GSL
traffic GSL Measured
load GSL

GSL load on a given GPU/GP should not exceed 80%
It is recommended to increase the number of GSL per GPU/GP if GSL load is
greater than 80%
The number of GSL equals to the number of AterMUX-PS link, as only one
GSL can be defined per AterMUX-PS link.
At least two GSLs are recommended to be defined per GPU/GP due to security
reason.
Up to four GSLs can be defined per GPU/GP.
3.4.2.2.2.2 GSL dimensioning method based on the number of treated messages
The goal of this dimensioning method is to compute the number of needed GSL
links depending on the number of messages to be treated per second on GSL
interface in the direction MFS to BSC (being the opposite direction less critical).
The messages to be sent on GSL are queued in a buffer having a maximum
dimension provided by the parameter K_GSL (MFS) and they are kept in the buffer
during the time needed in order to receive the message acknowledgement reception
by BSC. Therefore one message will be kept in the queue during the round trip
delay of MFS-BSC interface.
The method can be run both at BSC and GPU/GP level but, in case of specific
assessment focus only on GSL interface, it is recommended to apply the method at
GPU/GP level.

Gathered Counters:

[P62a + P62b +
P62c - P438c]
TRUTERQN Number of UL TBF establishment -requests per cell.
[P91a + P91b +
P91c + P91d +
P91e + P91f]
TRDTERQN Number of DL TBF establishment -requests


Retrieve indicators and
Cells GPUs mapping
(if method applied to 1 GPU/GP)
GSL traffic condition
Calculation [2]
# GSL links
#GSL msg/sec due to
RAE4 traffic calculation [3]
#GSL msgs/sec due
to PS traffic calculation [3]
(*) QoS evaluation to be done
by QoS expert
75% x GSL_Link_Max_Capacity [4]
+
QoS acceptable ?* [1]
(i.e. UL TBF estab success rate >80%)
Yes
Retrieve data on a different
Period or on an updated
configuration with better QoS*
Select hours with acceptable QoS *
(i.e. for 90% of cells)
Compare PS traffic in the selected hours
with traffic observed on a similar BSC
(reference BSC)
Estimate PS traffic at busy hours on the basis
of the reference BSC (through a simple proportion
based on the respective number of cells)
No
OR
START
PS
Traffic data
CHECK
Calculation
If the method is applied at BSC level, the
total capacity (for all GPU/GP) must be kept
Retrieve indicators and
Cells GPUs mapping
(if method applied to 1 GPU/GP)
GSL traffic condition
Calculation [2]
# GSL links
#GSL msg/sec due to
RAE4 traffic calculation [3]
#GSL msgs/sec due
to PS traffic calculation [3]
(*) QoS evaluation to be done
by QoS expert
75% x GSL_Link_Max_Capacity [4]
+
QoS acceptable ?* [1]
(i.e. UL TBF estab success rate >80%)
Yes
Retrieve data on a different
Period or on an updated
configuration with better QoS*
Select hours with acceptable QoS *
(i.e. for 90% of cells)
Compare PS traffic in the selected hours
with traffic observed on a similar BSC
(reference BSC)
Estimate PS traffic at busy hours on the basis
of the reference BSC (through a simple proportion
based on the respective number of cells)
No
OR
START
PS
Traffic data
CHECK
Calculation
If the method is applied at BSC level, the
total capacity (for all GPU/GP) must be kept
[P30a + P30b +
P30c]
TRUTESUN Number of UL TBF establishment -successes (seized by the
mobile).
[P90a + P90b +
P90c + P90d +
P90e + P90f]
TRDTESUN Number of DL TBF establishment -successes (seized by the
mobile)
P62b TRUTRV5N Number of UL TBF establishment requests per cell (seized by
the mobile) when MS is in packet transfer mode DL.
P160 QRDTES1N Number of DL TBF establishment requests requesting 1 slot
which are satisfied.
P383a QAGALCTT Time during which AterMux interface (GICs) for this GPU is
congested (at least one PDCH group impacted).
P391a TRPCHPAGPN Number of PS paging requests processed by the GPU.
P391b TRPCHCIGPN Number of CS paging requests processed by the GPU.
Table 33: Counter list GSL dimensioning
Measured Object: Cell (consolidated at BSC or GPU/GP level) / GPU
Gathering periods: 7-day hourly data, recommended
Otherwise, at least 2 working-day hourly data
Note: Busy Hour is computed as the hour with the highest number of GSL messages of the day.
Methodology:

[1] QoS Acceptable ? Since the method uses the number of TBF establishment
requests, the result can be impacted a lot in case of abnormal degradation or in case
of AterMux interface on satellite link. Indeed in this latter case the indicators
related to TBF establishment show always an important degradation (even without
impact on end user) due to the fact that the answer to mobile RACH is sent too late
with respect to the mobile waiting time before sending a new request; the


3.5 2.5 Low
5 3.5 High Available
GCH
Low High
PS traffic
(TBF req)
Nb of Msg on GSL
3.5 2.5 Low
5 3.5 High Available
GCH
Low High
PS traffic
(TBF req)
Nb of Msg on GSL
consequence of this issue is an abnormal increase of TBF establishment requests. In
order to be able to anyway handle GSL dimensioning assessment the suggested
solution, in case of not acceptable QoS, is to choose a reference BSC that should
have the same PS traffic amount per cell as the analysed BSC and to estimate the
PS traffic in this latter doing a simple proportion based on the number of cells of
the reference / target BSC.
[2] GSL traffic condition. The amount of GSL messages exchanged because of the PS
traffic in terms of UL/DL TBF establishment can be estimated multiplying the
number of TBF establishments by a factor that can have three possible value [2,5-
3,5-5]. The factor is chosen on the basis of the rule described in the below figure.

Figure 69 GSL usage factor

[3] #GSL messages/sec calculation.

1) Msg on GSL due to RAE4 mechanism 0.3 Msg/sec x Nb_cell

2) Msg on GSL due to PS traffic:

2.1) Msg on GSL due to PS/CS paging 1 x (Nb_PS_paging/sec+ Nb_CS_paging/sec)

2.2) Msg on GSL due to PS data traffic (TBF requests):

TBF (UL & DL) corresponding to RA update 1.7 x Nb_TBF_Sig_req/sec

UL TBF without sig on GSL 0 x Nb_UL_TBF_req_noGSL/sec
(eg. ACK of FTP DL transfer)

TBF (UL & DL) corresponding to PS data (3 cases)
Low GSL usage (eg. Ping 5 sec) 2.5
Medium GSL usage 3.5 x Nb_TBF_Data_req/sec
High GSL usage (worst case) 5

[3] GSL_Link_Max_Capacity. In order to compute the GSL interface capacity, the
following formulas apply:

In case of AterMux on terrestrial links:
Ater congestion observed
#TBF request/sec < 20
++
Nb GSL messages / sec


K_GSL * (1000ms/GSL_round_trip_delay) * number of configured GSL links per
GPU/GP if GSL_round_trip_delay < 500ms (default value for
GSL_round_trip_delay is 60ms)

In case of AterMux on satellite links:
K_GSL * (1000ms/GSL_round_trip_delay) * * number of configured GSL links
per GPU/GP if GSL_round_trip_delay >= 500ms (default value for
GSL_round_trip_delay is 500ms)

N.B. The factor is due to FR 3BKA20FBR202481 that should be corrected in
B10 release.

If the GSL link capacity is computed at BSC level the capacity of all GPU/GPs
must be summed.

Calculate GSL load (in terms of treated messages)
% 100
_ _ _
sec _ _ _
_ =
Capacity Max Link GSL
per messages GSL Nb
load GSL
For the computation of Nb_GSL_messages_per_sec and
GSL_Link_Max_Capacity see the previous Methodology description.
GSL load in terms of treated messages per second on a given GPU/GP
should not exceed 75%
It is recommended to increase the number of GSL per GPU/GP if GSL load is
greater than 75%.

3.4.2.2.3 GCH/AterMUX-PS Dimensioning
Target: To estimate the number of AterMUX-PS links needed per GPU/GP,
according to user traffic.
The main principle is to have roughly same number of AterMUX-PS links per
GPU/GP (at least 2 links per GPU/GP) for all the GPU/GPs connected to the
same BSC.
N.B. This will not assure a balanced load distribution among the GPU/GP
boards connected to the BSC, because the AterMux interface capacity is not
directly taken into account in the cell distribution criteria in MFS. For more
details on cell mapping on GPU/GP boards, please refer to [15].

In order to estimate the number of AterMux-PS links per GPU/GP, analyzing the
whole BSC, two main data must be estimated:
Number of required GCH per BSC
Number of required GPU/GP per BSC


Please find details on the method allowing to estimate the number of GCH (per
BSC or per GPU) in the section 3.6.3.1 and 3.6.3.2.
Please find details of GPU/GP dimensioning in the section 3.6.3

Having the number of required GCH and the number of GPU/GP board, the
Number of AterMUX-PS links per BSC
= Number of required GCH per BSC / 112 GCH
Remark: 112 GCH is generally applied in case of with GSL configuration, otherwise 116 GCH may
be applied as well. See details in Figure 62 and also refer to section 0 GSL dimensioning.

Number of AterMUX-PS links per GPU/GP (based on user traffic)
= Number of AterMUX-PS links per BSC / Number of required GPU/GP per
BSC
Finally,

Number of AterMUX-PS links per GPU/GP (based on signaling + user traffic)
= Max (Number of required GSL per GPU/GP, Number of AterMUX-PS links per
GPU/GP based on user traffic, 2)

Remark: it is highly recommended to have at least 2 AterMUX-PS links per GPU/GP due to security
reason.

Example:
If Number of required GCH per BSC = 330
Number of required GPU/GP per BSC = 2
Number of required GSL per GPU/GP = 2
How many AterMUX-PS links per GPU/GP are required?

- Determine Number of AterMUX-PS links per GPU/GP based on user traffic
Number of AterMUX-PS links per BSC = 330/112 = 3 links
Number of AterMUX-PS links per GPU/GP = 3 / 2 = 2 links

- Determine Number of AterMUX-PS links per GPU/GP based on signaling +
user traffic
= Max (Number of required GSL per GPU/GP, Number of AterMUX-PS links
per GPU/GP based on user traffic, 2)
= Max (2, 2, 2)
= 2 links

Assessment:


AterMUX-PS re-dimensioning is required when:
GSL load in terms of bandwidth is exceeding 80%.
GSL load in terms of number of treated messages per second is exceeding
75%.
GPU/GP Ater time congestion rate exceeding 0.1 % can be observed regularly.
GPU/GP re-dimensioning is performed.

Warning:
It could happen that, because of unbalanced traffic distribution among the GPU/GP
boards connected to one BSC, one GPU/GP board is more loaded than others. This can
be discovered applying the AterMux-PS dimensioning process at GPU/GP level. Some
examples are provided in 3.4.2.2.1.


3.4.2.3 AterMUX CS/PS
Target: To estimate the number of AterMUX-CS/PS links needed per BSC (or
GPU/GP).
GPU/GP & AterMUX-CS dimensionings are pre-requisite to be perfomed in order to
provide input data for AterMUX-PS dimensioning.
Please find details of GPU/GP dimensioning in the section 3.6.3
Please find details of AterMUX-CS dimensioning in the section 3.4.2.1

The input data for AterMUX-CS/PS dimensioning are:
Number of required TCH per BSC taken from AterMUX-CS dimensioning
Number of required GCH per BSC taken from GPU/GP dimensioning

Example of AterMUX-CS/PS dimensioning:
If Number of required TCH per BSC = 250 TCHs
Number of required GCH per BSC = 50 GCHs
Then
From 250 TCH, 222 TCHs can be fit into 2 AterMUX-CS links
Note: From Figure 60, the total capacity of AterMUX-CS links is:
111TCH(link#1) + 111TCH(link#2) = 222 TCHs

So, 250 222 = 28 TCHs are remaining
But 28 remaining TCHs and 50 GCHs can be fit into 1 AterMUX-CS/PS links
with 50% sharing, see Table 30

Therefore, based on this example, we need 2 AterMUX-CS links and 1 AterMUX-
CS/PS links.
Remark: the minimum usage of mixed AterMUX CS/PS is recommended.

Assessment:
AterMUX-CS/PS re-dimensioning is required when:
The increase of TCH traffic
GPU/GP Ater time congestion rate exceeding 0.1 % can be observed regularly.
GPU/GP re-dimensioning is performed.


3.5 TC
There are two transcoder (TC) generations, supported in B9:
G2 TC
G2.5 TC
The main architecture of transcoder is the Sub-Unit (TCSU), which is compounded by:
- One Sub-Multiplexing Unit (SMU)
- One or more Transcoding Units (TRCU)
In the case of G2.5 TC, these units are combined on one single board, the MT120,
offerring an Atermux connection to a BSC and up to 4 A-trunk connections to the MSC.
The MT120 can also be installed in the place of the ASMC in the G2 TC, and replaces 1
ASMC, 4 ATBX and 8 DT16 boards.
Here after summary of technical data overall generation transcoder.

Data in this table, based on [1] and [9]
Table 34: G2 TC/ G2.5 TC capabilities

3.5.1 G2 TC Configuration
There are 2 types of G2 TC:
G2 TC equipped with ASMC and TRCU
G2 TC equipped with ASMC/TRCU + MT120 boards (in the case of an
extension). This TC type can be applied according to following rules:
- It must contain at least 2 (ASMC + 4 TRCUs)
- When a new TC rack is needed (G2 TC full equipped, 3 racks), the extension
is performed by a G2.5 TC rack.

Table 35: G2 TC configuration
G2 TC G2.5 TC
Rack Up to 3 1
AterMux per rack 6 48
A interfaces 24 192
CIC 24*29 192*29
SMU ASMC
TRCU ATBX DT16
MT120
Extension / Reduction
Physical Logical
Min Max
G2 TC 2 AterMux 6 AterMux 1 AterMux 1 AterMux
SU 2 6 1 1
ASMC 2 6 1 1
TRCU SM 4:1 4 24 4 4
MT120 - 4 1 1
TC
Configuration
Min


3.5.2 G2.5 TC Configuration
The G2.5 TC (or A9125 Compact TC) can be equipped with up to 48 sub-units
(referred to as MT120 boards). Each MT120 offers one Atermux connection to a BSC
and up to 4 A trunk connections to the MSC, so that the G2.5 TC offers up to 192
Atrunk connections to MSC.
The G2.5 TC can be shared between several G2 BSCs. One MT120 board in any slot
of any subrack can be allocated to any Atermux of a G2 BSC. These BSC can belong
to several OMC-R.
The following tables describe the G2.5 TC configurations.

Table 36: G2.5 TC configuration

And, the capacity in terms of MT120 boards is summed up in Table 37.

Table 37: G2.5 TC capacity

Rules:
- Each BSC must be connected to at least two MT120 boards for redundancy
purposes, refer to Table 36.
- Each AterMux CS or mixed link requires one MT120 board.
- Each BSC rack can have up to 6 AterMux links and therefore up to 6 MT120
boards: these boards form a cluster inside TC and have all to be in the same TC
rack (but may be in different subracks).
- The AterMux CS and mixed links are gathered in groups of 6 in order to form
a complete cluster handled by one TC; the rest of the links are grouped together
and will form a cluster too, potentially connected to another TC.
- A TC rack can handle several BSCs.
-

Extension / Reduction step
Physical Logical
Min Max
MT120 2 48 1 1
G2.5 TC
Configuration per Rack
(AterMux)
Min
Configuration 1 subrack 2 subracks 3 subracks 4 subracks
Max MT120 modules 12 24 36 48


3.5.3 TC Dimensioning
The TC dimensioning is based on the connectivity aspect rather than counter (or
traffic) point of view.
The concerned connectivity is the total number of required AterMUX CS links coming
from all BSCs toward to the TC.
Also, the used TC type (either G2 TC or G2.5 TC) has to be taken into account
because each type provides different configuration and capacity.

The below figure presents the process of TC dimensioning.

Figure 70: TC dimensioning process

For example;
If a small network consists of 4 BSCs with following required AterMUX CS links;
BSCa: 10 AterMUX CS links
BSCb: 12 AterMUX CS links
BSCc: 6 AterMUX CS links
BSCd: 8 AterMUX CS links
and the chosen TC type is G2.5 TC.

Then,
Refer to section 3.5.2; we know that each AterMUX link needs one MT120
board of G2.5 TC. Therefore,
BSCa needs 10 MT120 boards
BSCb needs 12 MT120 boards
BSCc needs 6 MT120 boards
BSCd needs 8 MT120 boards

As 36 MT 120 boards are needed, this required one G2.5 TC with 3
subracks refer to Table 37.
Total = 36 MT 120 boards
# AterMUX CS links from BSC1
# AterMUX CS links from BSC2
# AterMUX CS links from BSCn
Used TC type
(G2 TC or G2.5 TC)
Total
links
Needed TC
Configuration
(Nb of boards)
:
:
:
:
:
:
+


3.6 MFS
The MFS provides resource and equipment management facilities for the packet-
switched system (GPRS) in the BSS. It has 2 main functions: the PCU function and Gb
interface management.
Each MFS can support multiple BSCs, and can be connected to several SGSNs. Several
MFSs can be connected to the same OMC-R.
Two generations of MFS are supported in B9:
The 1
st
MFS generation or A9135 MFS
MFS Evolution or A9130 MFS

3.6.1 The 1
st
MFS generation (A9135 MFS)
It was introduced on the market in year 2000 together with the first GPRS release of
Alcatel (release B6). The following figure presents A9135 MFS architecture.

Figure 71: The 1
st
MFS generation (A9135 MFS) Architecture

The A9135 MFS comprises 3 sub-systems:
- Control Sub-System (CSS): built from 2 DECAlpha AS800 or COMPAQ
DS10 servers, one of which is active and one of which is standby, referred to
as the Control Station
- Telecom Sub-System (TSS): a set of GPU and JBETI boards
- Hub subsystem: consisting of duplicated 100 Mbit/s Ethernet networks for
interconnection.


3.6.1.1 GPRS Processing Unit (GPU)
The GPU supports the Packet Control Unit (PCU), as defined by GSM. The PCU
handles Gb-related functions, Radio Resource Allocation functions and protocol
exchanges with the Mobile Stations.
Each GPU consists of 4 DSPs, which are in charge of the RLC/MAC functions as
well as the EGCH protocol exchanges with the BTSs.
Each DSP supports 120 GCH but the GPU should handle less than 480 (120
GCH * 4 DSP) GCH to avoid blocking the DSP.
A GPU board is linked to one BSC.
There are a maximum of 16 PCM links (AterMux & Gb) per GPU board.

3.6.1.2 Multiple GPU per BSS
In order to increase the GPRS capacity of the BSS in terms of the number of PDCH,
it is possible to connect several GPUs boards to the BSC to support the PCU
function.
The GPUs linked to same BSS do not need to be in same MFS subrack.
Cell Mapping means that a cell is associated with a GPU. The mapping of cells onto
GPU is performed by the MFS control station, which defines the mapping of cells
onto LXPU (logical GPU, which represent either the primary GPU, or the spare
GPU in the case of a switchover). All the GPRS traffic of one cell is handled by one,
and only one GPU.

The following figure shows the BSC connection for mulit-GPU per BSS.

Figure 72: Multiple GPU per BSS
BSC
GPU1
GPU2
GPU3
GPU4
MFS
GSL1
GSL2
cell15
cell14
cell1
cell2
cell3
cell4
Sub-BSS 1
cell5
cell7
cell6
Sub-BSS2
Sub-BSS4
cell8
cell10
cell11
cell9
cell12 cell13
Sub-BSS3 GSL3
GSL4
GPU1: cell1, cell2, cell3, cell4
GPU2: cell5, cell6, cell7
GPU3: cell8, cell9, cell10, cell11 cell12, cell13
GPU4: cell14, cell15


3.6.1.3 Capacity
The following table describes the A9135 MFS capacity for DS10.

Table 38: The 1
st
MFS generation (A9135 MFS) Capacity


3.6.2 MFS Evolution (A9130 MFS)
It is a brand new MFS introduced on the market in 2005, relying on the Advanced
Telecom Computing Architecture (ATCA).

The MFS Evolution is composed of the main following elements:
Telecom sub-racks: there is one or two sub-racks per MFS Evolution
cabinet. Each subrack can accommodate up to 14 boards. The sub-
racks are in fact ATCA shelves.
Boards: three types of boards are defined:
- GP board: the equivalent of the GPU board from the MFS 1st generation.
Only 1 GP board is needed for redundancy for the whole MFS, irrespective
of the number of shelves.
- SSW board: this board allows exchanges between all the elements of the
platform and external IP/Ethernet equipment. It support IP Layer 3 functions
and is based on Gigabit Ethernet. There are two SSW boards per shelf, 1
active and 1 for redundancy.
- OMCP board: this board is in charge of managing the whole platform from
an O&M standpoint. It provides the logical interface to the Operation and
Maintenance Centre (OMC). There are two OMCP boards per MFS, 1 active
and 1 for redundancy.
LIU shelf: This module is in charge of physical E1 connections for BSC
and MFS applications.

A9135 MFS Configuration Standard Standard Pre-equipped
Nb of telecom subracks 1 2
Min GPU per MFS + One GPU for redundancy 1+1 1+1
Max GPU per MFS + One GPU for redundancy 15+1 2 * (15+1)
Max GPRS GCH per MFS 3600 or (240*15) 7200 or (240*30)
Max BSC per MFS 15 22
Max GPU per BSC 6 6
Max BSC per GPU 1 1
Max PCM links (AterMux + Gb) per GPU 16 16


SA12 SA12 RS16 RS16 SA12 SA12 RS16 RS16
3.6.2.1 Configurations and Capacity
The following figure describes the A9130 MFS possible configurations:

Currently allowed configurations for MFS Evolution can be summerized as follow:
Stand-Alone
- 1 shelf: up to 9 GP
- 2
nd
shelf extension possible: up to 21 GP
- Maximum 12 E1/GP:
- In centralized synchronization mode: up to 10 E1/GP
- In autonomous synchronization mode: up to 12 E1/GP
Rack-shared
- MFS with 1 shelf, up to 8 GP, up to 16 E1/GP:
- In centralized synchronization mode: up to 14 E1/GP
- In autonomous synchronization mode: up to 16 E1/GP
- Collocated BSC & MFS in one rack:
- Either with O&M over IP
- Or with O&M over Ater
- Additional capacity rules:
- One A9130 MFS is able to manage up to 3000 cells (legacy MFS was able to
manage up to 2000 cells)
- One A9130 MFS is able to control up to 21 BSCs.
3.6.2.2 Delta MFS Evolution versus the 1
st
MFS generation
The main change/unchanged between those two MFS generation are below:



3.6.3 GPU/GP Dimensioning and AterMux PS dimensioning (user traffic)
Target: To estimate the number of GPU/GP needed per BSC.
Gathered Counters:

P100c AAGCHUST Cumulative time during which a GCH is busy in a cell. The
counter is integrated over all the GCH available in the cell.
P383a QAGALCTT Time during which AterMux interface (GICs) for this GPU is
congested (at least one PDCH group impacted).
P384 QRGPUCDT Time during which a DSP enters the congestion state.
P101 AAGCHAVT Cumulative time during which a GCH resource (16k channel)
is available in the GPU.
Cumulative time over all the GCH resources configured in the
GPU.
P474 AAGCHAVANT Cumulated time per GPU during which Ater nibbles are free
over the granularity period.
They are nibbles not currently used in a GCH.
P201 TRGPULDLT Time during which at least a DSP is in CPU load state
P202 TRGPULDOLT Time during which at least a DSP is in CPU overload state
P76a TRGPUPBA_MA Average PMU CPU power budget observed. Consolidated in
Day/Week/Month with the MAX value
P77a TRGPUPBM_MA Maximum PMU CPU power budget observed. Consolidated in
Day/Week/Month with the MAX value.
P402 TRGPUOT Time during which the GPU stays in the PMU CPU coverload
state due to PMU CPU power limitations.
P106 TRXTESUGPN Number of UL and DL TBF establishment successes per GPU.
P104 TRGPULPN Number of LLC PDU transferred (UL + DL)
P107 TRXTERQGPN Number of DL and UL TBF establishment requests per GPU
P392b TRGPUM_MA Maximum number of active contexts of MS (inRRM)
observed. Consolidated in Day/Week/Month with the MAX
value.
Different Behaviors:
The GP replaces the current GPU
No spare physical GP (still N+1
protection scheme)
Control stations are replaced by the
OMCP board
In the A9130 MFS, there are only 12
ports per GP

Same Behaviors
No change in the radio configuration
mechanisms, and same parameters are
used
No change in the PM mechanisms, same
counters/indicators
No change in the Ater/Gb transmission
configuration and display


Number
of GPU
GPU_GCH_Capacity
GPU_for_MS_context_handling (=0/1)
Needed
GCHs +
GPU_for_Power_Limitation (=0/1)
+
Number
of GPU
GPU_GCH_Capacity
GPU_for_MS_context_handling (=0/1)
Needed
GCHs +
GPU_for_Power_Limitation (=0/1)
+
ERLANG C
Counters
Required_GCH_Traffic
Needed
GCHs
With
quantile=99,9%
Feature
activation
Traffic
evolution
Stable
Network
estimation
ERLANG C
Counters
Needed
GCHs
With
quantile=99,9%
Feature
activation
Traffic
evolution
Stable
Network
estimation
Feature
activation
Traffic
evolution
Stable
Network
estimation
( [P62a + P62b
+ P62c - P438c]
- ( ( [P105d] +
[P105f]) +
[P27] + [P105h]
+ [P105j] +
[P105l] +
[P204] - [P66] -
[P28] - [P30a +
P30b + P30c])
QRUTEBPN Number of UL TBF estab -failures due to BSS problem per
cell.
Reference: number of UL TBF estab -requests
[P62a + P62b +
P62c - P438c]
TRUTERQN Number of UL TBF establishment -requests.
P383b TRGPUCOT_MA Time (cumulated over a granularity period) during which the
GPU remains in "high" Ater usage.
Table 40: Counter list - GPU/GP dimensioning

Measured Object: BSC
Note: Busy Hour means the hour gives the highest GCH traffic (i.e P100c) of the day.

Methodology:
The process of GPU/GP dimensioning is presented below.

Figure 73: GPU/GP dimensioning process
As the main input for the estimation of the number of GPU/GP boards is represented
by the estimated number of needed GCHs (at BSC or GPU/GP level), before being
able to apply the GPU/GP dimensioning process, another process for the assessment
of the AterMux PS interface on the basis of the target user traffic must be executed.


Figure 74 AterMux PS dimensioning process based on user traffic

The required GCH traffic can be computed in different ways depending on the
scenario:
1. Stable Network (see 3.6.3.1)
2. Feature Activation (see 3.6.3.2)

target GoS.
As GCH resources are associated to PS traffic only, Erlang C can be applied to
calculate the required number of GCH according to required PS traffic and the grade
of service.
The Grade of Service (GoS) is defined by %Quantile of x delay second (p
GPU/GP
).
Since the MFS always tries to assign TBFs as soon as the request is received, we
usually dimension for 0sec delay. Normally GoS should be given or agreed by the
Mobile Operator.
The recommended value is 99.9% quantile of 0 delay sec.

OUTPUT

Number of required GCH = Erlang C (Required_GCH_traffic, p
GPU/GP
)

Number of required GPU/GP = Number of required GCH /
GPU_GCH_Capacity + GPU_for_MS_context_handling +
GPU_for_Power_Limitation

Being:
GPU_GCH_Capacity the maximum number of GCHs that the GPU can handle (see
3.6.3.3 for details on the estimation of this variable)
GPU_for_Ms_context_handling a quantity equal to 1 if a GPU memory limitation
due to a too big number of MS contexts is observed (issue no more observed from
B9MR1ed6QD2) and no additional GPU/GP boards needed because of GPU GCH
capacity limitation (see 3.6.3.4 for details on the estimation of this variable)
GPU_For_Power_Limitation a quantity equal to 1 if a GPU power limitation is
observed, no additional GPU/GP boards needed because of GPU GCH capacity
limitation and GPU_for_Ms_context_handling equal to 0 (see 3.6.3.4 for details on the
estimation of this variable).

3.6.3.1 Required GCH traffic estimation in case of stable network
Two methods have been elaborated in order to estimate the required GCH traffic in case of
stable network:
Method 1: driven by GCH traffic and congestion observation


Method 2: driven by GCH and PDCH traffic observation
Both methods should provide very close result in case of low high Ater usage time percentage
and in case of limited (less than 30%) congestion.

Method 1:
%) 30 , _ (% 1
_ _
_ _ Re
cong GCH Min
traffic GCH Measured
traffic GCH quired
=
Where:
3600
100
_ _
c P
traffic GCH Measured =
{ }
{ } overload CPU load DSP Cong DSP Cong Ater Max
Limitation GPU Congestion Ater Max cong GCH
_ ,% _ ,% _ ,% _ %
_ , _ _ % = =

Where :
% 100
3600
383
_ _ % =
a P
cong Ater GCH
% 100
3600
384
_ _ % =
P
cong DSP GCH
% 100
3600
) 202 , 201 (
_ % x
P P Max
load DSP =
% 100
3600
402
_ % x
P
overload CPU =
Remark: Before starting GPU/GP dimensioning, it is recommended to check the
reliability of P100c (cf. details in FR no. 3BKA20FBR181618) by comparing P100c
value with P101 & P474 as:
P100c P101 P474
If P100c value is far different than P101 P474, P100c is not reliable. The proposed
workaround is GPU/GP reset and after that check counter values again.
N.B. If the method is applied at BSC level the congestion will be evaluated as the
maximum congestion over all the connected GPU/GP boards.

Method 2:

The Method 2 is based on the relationship between GCH and PDCH traffic. Indeed it
has been observed that in normal good conditions (no congestion and not relevant high
ater usage time percentage) the relathionship between these two quantities (that
depends on the traffic profile, on parameter configuration, on the available resources)
is quasi-linear. On the other hand, in case of GCH usage reduction (due to congestion


y = 5,3905x + 21,057
0
112
224
336
448
0 10 20 30 40 50 60 70 80
Measured PDCH traffic
Measured
GCH traffic
Resources
saturation
y = 5,3905x + 21,057
0
112
224
336
448
0 10 20 30 40 50 60 70 80
Measured
GCH traffic
Resources
saturation
y = 5,3905x + 21,057
0
112
224
336
448
560
0 10 20 30 40 50 60 70 80
Measured
GCH traffic
Following the
4th link adding
ERLANG C
Needed_GCH
y = 5,3905x + 21,057
0
112
224
336
448
560
0 10 20 30 40 50 60 70 80
Measured
GCH traffic
Following the
4th link adding
ERLANG C
Needed_GCH
or to the high Ater usage handling condition) the relationship between GCH and
PDCH traffic clearly shows a saturation aroud the available resource limit:

Figure 75 Example of GCH/PDCH traffic relationship in case of AterMux PS underdimensioning
In order to estimate the required GCH traffic in case of no GCH reduction, an extrapolation
of the linear relationship observed for low PDCH traffic must be done. In this way the
required GCH traffic will be the GCH traffic related to the maximum observed PDCH traffic.
N.B. This method does not allow to distinguish between a GCH usage reduction, with
respect to the target number of GCH per PDCH (i.e. on the basis of the MAX_GPRS_CS or
MAX_EGPRS_MCS), due to Abis or Ater congestion. Since the major limitation observed up
to now in the analysed networks is linked to Ater and not to Abis, the assumption that the
GCH reduction is due to Ater underdimensioning is done.
An example of the evolution of GCH vs PDCH traffic relationship following the adding of
1 AterMux Ps link is provided in Figure 76.

Figure 76 GCH vs PDCH traffic relationship: example
Assessment


The assessment of the Required_GCH_traffic must be done when:
- Congestion is observed to be regularly greater than 0,1% (i.e. P383a/3600>0,1%)
- High Ater usage is observed to be regularly greater than 30% (i.e. P383b/3600>30%)
3.6.3.2 Required GCH estimation in anticipation of feature activation
Some optional feature activation can lead to an increase of the GCH usage (at Abis and
Ater level). In order to be able to handle this traffic increase a method for the estimation of the
final required_GCH_traffic has been defined. The following feature activation have been
taken into account:
- EDGE activation
- CS3/CS4 activation
- The goal of the method is to estimate the increase_factor to apply to the
estimated required_GCH_traffic in stable conditions. Afterwards this increase_factor
will be used in the following way:
- Required_GCH_traffic
after_feature_activation
= Required_GCH_traffic
stable_network
*
increase_factor
- The target GCH traffic can also be estimated, estimating the target relationship
between GCH and PDCH traffic. The proposed rule in order to obtain the target linear
relationship is described below (see Figure 77):
-
-

Figure 77 GCH vs PDCH evolution in case of EDGE/CS3/CS4 activation
3.6.3.2.1 Increase_factor estimation
If one or several reference BSC exist, the increase_factor can be simply equal to the
increase_factor measured on these BSCs.
If no reference exists, the increase_factor can be estimated knowing which is the
theoretical average target number of GCH per PDCH in the initial and final condition:
Increase_factor = average_target_nb_GCH_per_PDCH
final
/
average_target_nb_GCH_per_PDCH
initial

The increase_factor in case of EDGE/CS3/CS4 activation depends on the type of
transition that must be supported and on the penetration of the activated service:

Before EDGE/CS3/CS4
After EDGE/CS3/CS4
Y=a
2
x + b
2
Y=a
1
x + b
1
a
2
= a
1
* Increase_Factor and b
2
= b
1
(approximation !)
PDCH traffic
GCH traffic
Before EDGE/CS3/CS4
After EDGE/CS3/CS4
Y=a
2
x + b
2
Y=a
1
x + b
1
a
2
= a
1
* Increase_Factor and b
2
= b
1
(approximation !)
PDCH traffic
GCH traffic


CS1/CS2
CS3/CS4
CS3/CS4
&
EDGE
EDGE
a
b
c
d
e
CS1/CS2
CS3/CS4
CS3/CS4
&
EDGE
EDGE
a
b
c
d
e
[(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS
*1,64)]/ 1,64
d
(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS*
1,64)/(%_PDCH_EGPRS*4,49)+(%_PDCH_
GPRS*1)
e
*1,64)]/1
a
[1,64]/1
b
*1)]/1
c
Increase_Factor Transition type
*1,64)]/ 1,64
d
(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS*
1,64)/(%_PDCH_EGPRS*4,49)+(%_PDCH_
GPRS*1)
e
*1,64)]/1
a
[1,64]/1
b
*1)]/1
c
Increase_Factor Transition type

Being:
%PDCH_EGPRS the % of Radio Resources (PDCH) supporting at least one TBF
established in EGPRS mode on a cell with MAX_EGPRS = MCSx
%PDCH_GPRS the % of Radio Resources (PDCH) supporting only TBF established in
GPRS mode on a cell with MAX_GPRS = Csy
Avg_target_nb_GCH_per_PDCH = (%_PDCH_EGPRS *
nb_GCH_per_PDCH_MCSx) + (%_PDCH_GPRS*nb_GCH_per_PDCH_Csy)

The increase_factor will have the following values, depending on the type of transition:

N.B. The recommended default value for %PDCH_EGPRS is 30%.

3.6.3.3 GPU/GP GCH capacity estimation
In order to estimate the maximum number of GCH a GPU/GP board is able to handle,
first of all the maximum theoretic capacity of the board must be taken into account:
B9MR1: 480 GCH
B9MR4:
480 GCH (for legacy MFS)
1560 GCH (for Mx MFS)
This theoretic capacity is then adapted to the BSS configuration and the traffic profile
where the GPU/GP is used, in the following way:


GPRS
Max CS
GPU (A9135) &
GP (A9130) up
to B9MR1
GP (A9130)
from B9MR4
Case 10 E1
links per GP
GP (A9130) from
B9MR4
Case 12 E1
links per GP
GP (A9130) from
B9MR4
Case 16 E1
links per GP
CS1 240 896 960 960
CS2 240 896 960 960
CS3 224 716 892 892
CS4 200 544 684 804
Max nb of PDCH per GPU/GP
EGPRS
Max MCS
GPU (A9135) &
GP (A9130) up
to B9MR1
GP (A9130)
from B9MR4
Case 10 E1
links per GP
GP (A9130)
from B9MR4
Case 12 E1
links per GP
GP (A9130) from
B9MR4
Case 16 E1 links
per GP
MCS1 224 860 860 860
MCS2 224 836 836 836
MCS3 208 672 796 796
MCS4 200 596 748 776
MCS5 184 480 604 704
MCS6 172 380 476 664
MCS7 136 256 320 452
MCS8 116 216 272 380
MCS9 108 200 252 352
Max nb of PDCH per GPU/GP
1,60 1,64 CS-4
1,22 1,25 CS-3
1,00 1,00 CS-2
0,73 0,73 CS-1
DL UL CS
1,60 1,64 CS-4
1,22 1,25 CS-3
1,00 1,00 CS-2
0,73 0,73 CS-1
DL UL CS
4,39 4,49 MCS-9
4,00 4,14 MCS-8
3,39 3,49 MCS-7
2,31 2,36 MCS-6
1,81 1,86 MCS-5
1,47 1,50 MCS-4
1,28 1,33 MCS-3
1,00 1,00 MCS-2
0,86 0,89 MCS-1
DL UL MCS
Number of required GCHs
4,39 4,49 MCS-9
4,00 4,14 MCS-8
3,39 3,49 MCS-7
2,31 2,36 MCS-6
1,81 1,86 MCS-5
1,47 1,50 MCS-4
1,28 1,33 MCS-3
1,00 1,00 MCS-2
0,86 0,89 MCS-1
DL UL MCS
Number of required GCHs
The N_ATER_TS_MARGIN_GPU resources must not be taken into account in the
GPU/GP capacity. Therefore the maximum theoretical number of GCH per GPU/GP
becomes:
B9MR1: 480 N_ATER_TS_MARGIN_GPU*4
B9MR4:
480 N_ATER_TS_MARGIN_GPU*4 (for legacy MFS)
1560 N_ATER_TS_MARGIN_GPU*4 (for Mx MFS)
The fact that the maximum number of PDCH per GPU/GP is dynamic depending on
the used coding schemes must be taken into account:

the fact that the maximum number of GCH is also dynamic because the number of
GCH per PDCH depends on the used coding scheme must be taken into account.

Therefore the maximum number of GCHs that the GPU/GP will be able to handle can
be obtained knowing the:


(M)CS distribution of the analysed network (P55x & P57y counters)
The maximum number of PDCH per coding scheme
The maximum number of GCH per PDCH per coding scheme
In DL direction the maximum number of GCHs that a GPU/GP will be able to handle
is defined as:

Max_DL_GCH_GPU = (%CS1 * max_PDCH_CS1 * max_DL_GCH_CS1)+
(%CS2 * max_PDCH_CS2 * max_DL_GCH_CS2)+ (on all coding schemes)

In UL direction the maximum number of GCHs that a GPU/GP will be able to handle
is defined as:

Max_UL_GCH_GPU = (%CS1 * max_PDCH_CS1 * max_UL_GCH_CS1)+ )+
(%CS2 * max_PDCH_CS2 * max_DL_GCH_CS2)+ (on all coding schemes)

GPU_GCH_Capacity will be defined in the following way:

Where:
Max_Capacity is equal to 480 or 1560 depending on the limitation described above.
% (M)CSx in DL direction = P55x/sum of P55y for all coding schemes
% (M)CSx in UL direction = P57x/sum of P57y for all coding schemes

Assessment:
It is recommended to monitor the GPU GCH congestion through indicators, GPU/GP Ater
congestion (P383a/3600) and GPU/GP DSP congestion (P384/3600). If we can see the GCH
congestion occurring regularly e.g > 0.1% congestion, GPU/GP re-dimensioning is required.

3.6.3.4 GPU/GP limitations
Apart from GPU/GP GCH capacity, some limitations due to GPU/GP memory or
processor capacity must also be taken into account; the consequence of these limitations can
be the adding of 1 GPU/GP resource in order to reduce the memory/processor load.
Two types of limitations have been identified as critical in B9:
1. The capacity in terms of MS contexts (1000 for a GPU and 4000 for a GP
board while in B8 the limit for GPU and GP was fixed at 2500)
2. The capacity in terms of PMU or DSP CPU load

{ }

4 * _ _ _ _ _ , _ _ _ , _ _ _ GPU MARGIN TS ATER N Capacity Max GPU GCH UL Max GPU GCH DL Max Min


0
200
400
600
800
1000
1200
2
1
/
1
0
/
2
0
0
6

:

0
0
h
0
3
h
0
6
h
0
9
h
1
2
h
1
5
h
1
8
h
2
1
h
2
2
/
1
0
/
2
0
0
6

:

0
0
h
0
3
h
0
6
h
0
9
h
1
2
h
1
5
h
1
8
h
2
1
h
2
3
/
1
0
/
2
0
0
6

:

0
0
h
0
3
h
0
6
h
0
9
h
1
2
h
1
5
h
1
8
h
2
1
h
2
4
/
1
0
/
2
0
0
6

:

0
0
h
0
3
h
0
6
h
0
9
h
1
2
h
1
5
h
1
8
h
2
1
h
2
5
/
1
0
/
2
0
0
6

:

0
0
h
0
3
h
0
6
h
0
9
h
1
2
h
1
5
h
1
8
h
2
1
h
0,0%
10,0%
20,0%
30,0%
40,0%
50,0%
60,0%
UL TBF BSS
Failure rate
Average number
MS context (P392a)
Max number MS
context (P392b)
0
200
400
600
800
1000
1200
2
1
/
1
0
/
2
0
0
6

:

0
0
h
0
3
h
0
6
h
0
9
h
1
2
h
1
5
h
1
8
h
2
1
h
2
2
/
1
0
/
2
0
0
6

:

0
0
h
0
3
h
0
6
h
0
9
h
1
2
h
1
5
h
1
8
h
2
1
h
2
3
/
1
0
/
2
0
0
6

:

0
0
h
0
3
h
0
6
h
0
9
h
1
2
h
1
5
h
1
8
h
2
1
h
2
4
/
1
0
/
2
0
0
6

:

0
0
h
0
3
h
0
6
h
0
9
h
1
2
h
1
5
h
1
8
h
2
1
h
2
5
/
1
0
/
2
0
0
6

:

0
0
h
0
3
h
0
6
h
0
9
h
1
2
h
1
5
h
1
8
h
2
1
h
0,0%
10,0%
20,0%
30,0%
40,0%
50,0%
60,0%
UL TBF BSS
Failure rate
Average number
MS context (P392a)
Max number MS
context (P392b)
Retrieve indicators
for 5 working days
P392b
BSC
=1000
during at least 12% of
The observed period
NO
YES
P392b
BSC
= 1000 when BSS_fail_rate
max
Observed for all days with at least two occurrences of P392b
BSC
= 1000
Observed QoS acceptable
for the customer ?
YES
YES
NO
NO
GPU_for_MS_context_handling=0
Retrieve indicators
for 5 working days
P392b
BSC
=1000
The observed period
NO
YES
P392b
BSC
= 1000 when BSS_fail_rate
max
Observed for all days with at least two occurrences of P392b
BSC
= 1000
Observed QoS acceptable
for the customer ?
YES
YES
NO
NO
Capacity in terms of MS contexts (GPU_for_MS_context_handling variable
estimation)

In B9MR1, before B9MR1Ed6, it was observed that when the maximum number of
allowed MS contexts was reached an abnormal increase of UL TBF establishment
failure due to BSS cause was observed:

In order to detect this problem the following methodology was defined:

N.B. In B9MR4 the observation of the number of MS context (through P392a and
P392b) should no more represent a limitation in itself but a useful indication
about the GPU/GP load.

Capacity in terms of PMU/DSP CPU load (GPU_for_Power_Limitation variable
estimation)


Retrieve indicators
for 5 working days
Max(P201,P202)/3600 >0,1%
The observed period
NO
YES
Max(P201,P202)/3600 >0,1% and (max(P203/P204) > 1% OR GPU reboots
Observed during the CPU loaded hours)
YES
NO
GPU_for_Power_Limitation=0
Retrieve indicators
for 5 working days
Max(P201,P202)/3600 >0,1%
The observed period
NO
YES
Max(P201,P202)/3600 >0,1% and (max(P203/P204) > 1% OR GPU reboots
Observed during the CPU loaded hours)
YES
NO
In B9 release a big increase of CPU load has been observed (due to new B9
algorithms) leading, sometimes, to very critical situations (i.e. GPU reboots). Even if
in most of the analysed cases the overload was due to an abnormal increase of events
to be managed, the workaround for avoiding blocking conditions could be the adding
of 1 additional GPU board. In order to determine GPU_for_Power_Limitation, two
methodologies have been built (but not tested on field) in order to detect an overload
at PMU CPU (see Figure 78) or DSP CPU (see Figure 79) level.

Figure 78 GPU_for_Power_Limitation due to PMU CPU load
N.B. In the specific case of B8 to B9 migration the following additional condition must be
checked for GPU_for_Power_Limitation variable estimation. Indeed
GPU_for_Power_Limitation = 1 if the observed board is a GPU and if the B8 measured PMU
CPU average load is greater than 40%. This recommendation is the result of ALU simulations
about the CPU power budget increase from B8 to B9.

Figure 79 GPU_for_Power_Limitation due to DSP CPU load

Retrieve indicators
for 5 working days
P402/3600 >0,1%
The observed period
NO
YES
P402/3600 >0,1% and (max(P105e/P105f) > 1% OR GPU reboots
observed during the CPU loaded hours)
YES
NO
Retrieve indicators
for 5 working days
P402/3600 >0,1%
The observed period
NO
YES
P402/3600 >0,1% and (max(P105e/P105f) > 1% OR GPU reboots
observed during the CPU loaded hours)
YES
NO


WARNING: since the methods described for GPU power limitation detection have
not yet been validated on a real network, they could evolve following B9MR4 release
generalization.

Assessment:
It is recommended to monitor the PMU and DSP load through the counters (P201, P202,
P402, P76a, P77a). If we can see that Max(201,202)/3600 or P402/3600 is regularly > 0.1%,
GPU/GP re-dimensioning is required.


3.7 Gb interface
The Gb interface connects between the MFS and the SGSN or between the MSC and
the SGSN, in order to exchange the PS signaling and traffic data.
The Gb interface is based on Frame Relay protocol, whether or not an actual Frame
Relay network is set.
On the physical layer, the Gb interface is supported by 2MBit/s PCM links of 32 TS at
64Kbit/s.

3.7.1 Gb Configuration
There are 3 possible ways to connect the MFS and the SGSN via the Gb interface:
- Through a Frame Relay network
- Direct MFS-SGSN connections: this is the most chosen case of Gb connections.
- Through NSS transmission network

The figure below displays the different types of Gb connections between the MFS and
the SGSN.

Figure 80: Gb interface connections

The maximum number of E1 links handled by a GPU/GP board is 16: these links
have to be shared between AterMux and Gb interfaces.
The maximum number of Gb links from one GPU/GP board to the SGSN is 8.
The minimum number of Gb links from one GPU/GP board to the SGSN is 2. At
least 2 Gb links per GPU/GP is recommended for security reason.

For more details, please refer to [1] and [10].
1) Through a FR Network MFS
2) Direct MFS - SGSN connections MFS
3) Through NSS transmission network MFS MSC/VLR MSC/VLR
SGSN
Frame Relay
Netwok
Gb
Gb
Gb
Gb Gb


3.7.2 Gb Dimensioning
Target: To estimate the number of Gb TS for each Gb link.
Gathered Counters:

P45
TGPVCDLN
Number of kilobytes received from the SGSN at SNS sublayer.
P46
TGPVCULN
Number of kilobytes sent to the SGSN.
Table 43: Counter list - Gb dimensioning

Measured Object: Gb
Note: Busy Hour means the hour gives the highest Gb traffic (i.e Max (P45, 46)) of the day.

Methodology:
The process of Gb dimensioning is presented below.

Figure 81: Gb dimensioning process

INPUT

The required Gb traffic is computed as below formula.

in m traffic Gb Measured traffic Gb quired arg % 15 _ _ _ _ Re + =
Note: a 15% margin is added to the required traffic - see more explanation in Figure 66
Where:
28800
) 46 , 45 (
_ _
P P Max
traffic Gb Measured =
Note: 1 Erlang = [Gb TS speed (64Kbits/s) * 3600] / 8 =28800 K bytes.
Erlang C
Required Gb
Traffic
GoS:
% Quantile of x
delay sec
Nb of required Gb
Timeslot per link
INPUT OUTPUT METHOD


The other input is Grade of Service (GoS), which is defined by %Quantile of x delay
second (p
Gb
). Since the MFS always tries to assign TBFs as soon as the request is
received, we usually dimension for 0sec delay. Normally GoS should be given or
agreed by the Mobile Operator.
At high network element level Gb interface, the recommended value is 99.9% quantile
of 0 delay sec.

METHOD

target GoS.
As Gb resources are associated to PS traffic only, Erlang C can be applied to
calculate the required number of Gb TS according to required PS traffic and %
quantile of delay time.

OUTPUT

Number of required Gb TS per link
= Erlang C (Required_Gb_traffic, p
Gb
)

Notes:
- Minimum 2 Gb links are required for one GPU/GP due to security reason
- Maximum 31 Gb TS (TS no. 1 to 31) can be configured per one Gb link. TS0
cannot be used as it is reserved for specific usages e.g. frame synchronization.
- In general, around 4 to 8 Gb TS are configured per one Gb link.

END OF DOCUMENT

B9 BSS Arch Serv GuideLine Ed03it1

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

B9 BSS Arch Serv GuideLine Ed03it1

Caricato da

Copyright:

Formati disponibili

Alcatel File Reference Date Edition Page

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

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

Potrebbero piacerti anche