B10 BSS Arch Serv GuideLine Ed2

Site
Mobile Radio Division
Vlizy
Originator(s)
A. Rezzoug
B10: BSS Architecture Service Guideline
E. Marza
Domain
: Network Architecture
Product
: GSM B10
Division
: Methods
Rubric
: GSM/GPRS/EDGE
Type
: Guidelines
Distribution codes Internal:
Pre-distribution:
NE Velizy
NE Timisora
NE Portugal
NE Egypt
F. Colin
Cristian I. Inta
Pedro Henriques
Maged Sayed
T. Plantier
E. Marza
Joo Frade
M. Talayssat
LM. Palumbo
Abstract: The aim of this document is to describe BSS architecture configuration rules &
dimensioning processes in Alcatel release B10. It is recommended to be the guideline for
RNE & TPM people who are involve in BSS architecture aspect.
Key words: BTS, BSC, TC, MFS/GP(U), Abis, AterMUX, A, and Gb; B10 release
Appraisal and approval authorities

GSM TIS
DD-MM-YY:
Signature:
DD-MM-YY:
Network Engineering
Florent Colin
DD-MM-YY:
Signature:
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!
Alcatel File
Reference
Date
Edition
Page
B10_BSS_arch_serv_GuideLine_Ed2.doc
3DF 0190 329 8010 VAZZA 02
February 18, 2009
1 / 162
Table of contents
1
INTRODUCTION.................................................................................. 14
OVERVIEW OF BSS ARCHITECTURE SERVICES ....................... 15

2.1
WHAT IS THE BSS ARCHITECTURE ? ........................................................................15
2.1.1
BSS Network Elements ..................................................................................15
2.1.2
BSS Interfaces ...............................................................................................16
2.1.2.1 Um (air or radio) interface .........................................................................16

2.1.2.2 Abis interface ............................................................................................16
2.1.2.3 AterMUX interface....................................................................................16
2.1.2.4 A interface.................................................................................................17
2.1.2.5 Gb interface...............................................................................................17
2.2
BSS ARCHITECTURE SERVICES ................................................................................18
2.2.1
Scope.............................................................................................................18
2.2.2
Goal ..............................................................................................................18
2.2.3
Category .......................................................................................................18
2.2.4
Process..........................................................................................................19
2.2.4.1 Process for Network Architecture SETUP and EVOLUTION....................19

2.2.4.2 Process for Network Architecture ASSESSMENT.....................................22
2.3
BSS ARCHITECTURE IMPACT IN B10 .....................................................................25
2.3.1
Multiple CCCH .............................................................................................25
2.3.2
Gb over IP.....................................................................................................26
2.3.3
Capacity Improvements .................................................................................27
2.3.3.1 Optimized HR connectivity .......................................................................28

2.3.3.2 HSL functionality ......................................................................................28
2.3.4
STM-1 transmission in 9125 Transcoder .......................................................29
2.3.5
Ater optimization...........................................................................................29
DETAILED BSS ARCHITECTURE PROCESS ................................. 30

3.1
BTS ........................................................................................................................30
3.1.1
BTS Configuration.........................................................................................30
3.1.1.1 Cell Configuration .....................................................................................34

3.1.1.2 SDCCH Configuration ..............................................................................35
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
2 / 162
3.1.2
Determination of BTS configuration ..............................................................37
3.1.3
Cell dimensioning..........................................................................................37
3.1.3.1 SDCCH Dimensioning ..............................................................................38

3.1.3.2 TCH/PDCH Dimensioning ........................................................................40
3.2
ABIS INTERFACE ......................................................................................................46
3.2.1
Abis Configuration ........................................................................................46
3.2.1.1 Abis Network Topology ............................................................................46

3.2.1.2 Abis Channels ...........................................................................................48
3.2.1.3 Abis Link Capacity....................................................................................50
3.2.1.4 Signalling Sub-Multiplexing Schemes .......................................................50
3.2.1.4.1
No Multiplexing......................................................................................................................... 51
3.2.1.4.2
16K Static Multiplexing............................................................................................................. 51
3.2.1.4.3
16K Statistical Multiplexing ...................................................................................................... 52
3.2.1.4.4
64K Statistical Multiplexing ...................................................................................................... 53
3.2.1.5 Secondary Abis Link .................................................................................58

3.2.2
Abis Dimensioning ........................................................................................61
3.2.2.1 Case #1: B9 with No GPRS/EDGE B10 with EDGE ............................62

3.2.2.2 Case #2: B10 with EDGE ..........................................................................62
3.3
BSC........................................................................................................................68
3.3.1
G2 BSC Configuration ..................................................................................68
3.3.1.1 BSC Capacity ............................................................................................69

3.3.1.2 Abis TSU ..................................................................................................70
3.3.1.3 Ater TSU...................................................................................................72
3.3.2
BSC Evolution Configuration ........................................................................72
3.3.2.1 BSC Capacity ............................................................................................74

3.3.2.2 Delta BSC Evolution versus G2 BSC ........................................................75
3.3.2.3 TP GSM board ..........................................................................................75
3.3.2.4 CCP board.................................................................................................76
3.3.2.5 LIU shelf ...................................................................................................77
3.3.2.6 SS7 transport .............................................................................................77
3.3.2.7 HSL usage.................................................................................................78
3.3.3
BSC Dimensioning ........................................................................................80
3.3.3.1 Design BSC area .......................................................................................81

3.3.3.2 Parenting Abis ports of the BSC ................................................................83
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
3 / 162
3.3.4
LA Dimensioning...........................................................................................85
3.3.4.1 LA Definition and Capacity.......................................................................85

3.3.5
RA Dimensioning ..........................................................................................89
3.3.6
Summary of LA/RA dimensioning process......................................................91
3.3.7
CCCH dimensioning......................................................................................92
3.4
ATERMUX AND A INTERFACES................................................................................94
3.4.1
General .........................................................................................................94
3.4.1.1 AterMUX interface....................................................................................94

3.4.1.2 A interface.................................................................................................94
3.4.1.3 AterMUX interface versus A interface.......................................................94
3.4.2
AterMUX configuration.................................................................................95
3.4.2.1 AterMUX CS and A interfaces ..................................................................96

3.4.2.2 AterMUX PS.............................................................................................98
3.4.2.3 AterMUX CS/PS .......................................................................................99
3.4.3
SS7 Signalling mode....................................................................................101
3.4.3.1 LSL and HSL modes ...............................................................................101

3.4.3.2 SS7 Dimensioning...................................................................................101
3.4.4
AterMUX Dimensioning ..............................................................................108
3.4.4.1 AterMUX CS ..........................................................................................108

3.4.4.1.1
A Dimensioning....................................................................................................................... 111
3.4.4.2 AterMUX PS...........................................................................................112

3.4.4.2.1
Process description .................................................................................................................. 112
3.4.4.2.2
GSL Dimensioning .................................................................................................................. 115
3.4.4.2.3
GCH/AterMUX-PS Dimensioning .......................................................................................... 120
3.4.4.3 AterMUX CS/PS .....................................................................................122

3.5
TC ........................................................................................................................123
3.5.1
G2 TC Configuration...................................................................................124
3.5.2
G2.5 TC Configuration................................................................................124
3.5.2.1 New MT120-xB boards available ............................................................125

3.5.3
TC Dimensioning ........................................................................................126
3.5.4
STM-1 in TC................................................................................................127
3.5.4.1 Functional Requirements .........................................................................127

3.5.4.2 Overall description ..................................................................................127
3.5.4.3 TC Configuration ....................................................................................128
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
4 / 162
3.6
MFS .....................................................................................................................129
3.6.1
The 1st MFS generation (A9135 MFS) .........................................................129
3.6.1.1 GPRS Processing Unit (GPU)..................................................................130

3.6.1.2 Multiple GPU per BSS ............................................................................130
3.6.1.3 Capacity ..................................................................................................131
3.6.2
MFS Evolution (A9130 MFS) ......................................................................131
3.6.2.1 Configurations and Capacity....................................................................132

3.6.2.2 Delta MFS Evolution versus the 1st MFS generation................................133
3.6.2.3 Delta B10 versus B9................................................................................134
3.6.3
GP(U) Dimensioning and AterMux PS dimensioning (user traffic) ..............135
3.6.3.1 Required GCH traffic estimation .............................................................138

3.6.3.2 GP(U) GCH capacity estimation..............................................................140
3.6.3.3 GP(U) limitations ....................................................................................142
3.7
GB INTERFACE .......................................................................................................147
3.7.1
Gb configuration .........................................................................................149
3.7.2
Gb Dimensioning ........................................................................................151
ANNEX 1: BSS ARCHITECTURE IMPACT FROM B9 ................. 155
5
ANNEX 2: PRE-REQUISITES FOR MXBSC CAPACITY
IMPROVEMENTS ...................................................................................... 160
5.1
CIC CODE LIMITATION ...........................................................................................160
5.2
HSL LIMITATION ...................................................................................................160
5.3
GBOIP LIMITATION ................................................................................................161
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
5 / 162
INDEX OF FIGURES
Figure 1: BSS Architecture...................................................................................................15
Figure 2: TRX configuration on Um interface.......................................................................16
Figure 3: Abis configuration.................................................................................................16
Figure 4: AterMUX configuration Dedicated AterMUX for CS traffic...............................17
Figure 5: A-interface configuration.......................................................................................17
Figure 6: BSS Architecture Services.....................................................................................18
Figure 7: Network Architecture Setup and Evolution process ...............................................19
Figure 8: BSC/LAC/RAC (re) design - example ...................................................................20
Figure 9: Abis TSU port (re) design......................................................................................22
Figure 10: Network architecture assessment process.............................................................23
Figure 11: mCCCH mapping on Beacon TRX ......................................................................25
Figure 12: MFS capacity ......................................................................................................27
Figure 13: B10 BSC capacity improvements.........................................................................27
Figure 14: BSC - MSC connectivity with HSL mode............................................................28
Figure 15: BTS generation/type supported in B10..............................................................30
Figure 16: Determination of BTS configuration....................................................................37
Figure 17: SDCCH dimensioning process.............................................................................38
Figure 18: TCH/PDCH dimensioning process.......................................................................41
Figure 19: TCH/PDCH dimensioning assessment .................................................................44
Figure 20: Abis Chain (Multi-drop) Topology ......................................................................46
Figure 21: Abis Star Topology..............................................................................................47
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
6 / 162
Figure 22: Abis Ring (Closed loop) Topology ......................................................................47

Figure 23: Secondary Abis Topology....................................................................................48
Figure 24: TRX - Abis mapping ...........................................................................................48
Figure 25: Example of Abis TS usage for 1 BTS/4 TRX No Multiplexing .........................51
Figure 26: Example of Abis TS usage for 1 BTS/4 TRX 16K Static Multiplexing .............52
Figure 27: 16K Statistical Multiplexing MCB 16/1 mapping .............................................52
Figure 28: Example of Abis TS usage for 1 BTS/4 TRX 16K Statistical Multiplexing .......53
Figure 32: Example of Abis TS usage for 1 BTS/4 TRX 64K Statistical Multiplexing .......54
Figure 33: Abis TS configuration on primary and secondary links ........................................58
Figure 34: BTS with 24 TRX mapped on both Abis links .....................................................58
Figure 35: Example of topology with two BTS chained ........................................................59
Figure 36: Two Abis links filling examples. .........................................................................59
Figure 37: Abis dimensioning process Method 1................................................................63
Figure 38: Abis dimensioning process Method 2................................................................65
Figure 39: G2 BSC (A9120 BSC) Architecture.....................................................................68
Figure 40: G2 BSC Cabinet layout .......................................................................................69
Figure 41: Abis TSU G2 BSC............................................................................................70
Figure 42: Ater TSU G2 BSC ............................................................................................72
Figure 43: BSC Evolution (A9130 BSC) HW Architecture...................................................73
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
7 / 162
Figure 44: Abis and Ater allocation on LIU boards / BSC capacity.......................................77
Figure 45: BSC dimensioning process ..................................................................................80
Figure 46: BTS position & configuration design BSC area step 1 ......................................81
Figure 47: Transmission planning & BSC position design BSC area step 2........................82
Figure 48: BSC area definition design BSC area step 3......................................................82
Figure 49: Transmission load checking.................................................................................83
Figure 50: BTS / Abis parenting on BSC done by AMT.NET ............................................84
Figure 51: LA dimensioning assessment...............................................................................88
Figure 52: Subdivision of a LA in GPRS routing areas (RA) ................................................89
Figure 53: AterMUX and A relationship...............................................................................94
Figure 54: AterMUX interface structure ...............................................................................95
Figure 55: AterMUX CS interface configuration G2 BSC..................................................96
Figure 56: Channel mapping between AterMUX CS and A ..................................................97
Figure 57: AterMUX PS interface configuration - GPU ........................................................98
Figure 58: Sharing AterMUX links.......................................................................................99
Figure 59: AterMUX CS/PS Timeslot configuration...........................................................100
Figure 60: SS7 message length (in bytes) according to GSM event.....................................102
Figure 61: Difference between Exact busy hour, NPO busy hour and Peak traffic...............104
Figure 62: AterMUX-CS dimensioning process..................................................................109
Figure 63 AterMux-PS dimensioning process at BSC level.................................................113
Figure 64 AterMux-PS dimensioning process at GP(U) level..............................................113
Figure 65 GSL usage factor ................................................................................................119
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
8 / 162
Figure 66: TC G2 architecture with mixed configuration ....................................................123

Figure 67: TC G2.5 architecture .........................................................................................124
Figure 68: TC dimensioning process...................................................................................126
Figure 69: The BSS Architecture with STM-1 on TC side ..................................................128
Figure 70: The 1st MFS generation (A9135 MFS) Architecture...........................................129
Figure 71: Multiple GPU per BSS ......................................................................................130
Figure 72: MFS Evolution (A9130 MFS) HW Architecture................................................132
Figure 73: MFS capacity ....................................................................................................133
Figure 74: GP(U) dimensioning process .............................................................................136
Figure 75 AterMux PS dimensioning process based on user traffic .....................................137
Figure 76: Example of GCH/PDCH traffic relationship in case of AterMux PS
underdimensioning.......................................................................................................139
Figure 77 GCH vs. PDCH traffic relationship: example......................................................140
Figure 78 GPU_for_MS_context_handling due to PMU memory limitation .......................143
Figure 79 GPU_for_Power_Limitation due to PMU CPU load ...........................................144
Figure 80 GPU_for_Power_Limitation due to DSP CPU load ............................................145
Figure 81: Gb interface configuration (from 3BK 09559 LAAA EBZZA) ..........................148
Figure 82: Gb interface connections ...................................................................................149
Figure 83: GboIP End-to-End architecture .......................................................................150
Figure 84: Gb dimensioning process...................................................................................151
Figure 85: EGCH link in B8 vs. M-EGCH link in B9 .........................................................155
Figure 86: Wasted Abis nibbles case in B8 .........................................................................157
Figure 87: Enhance transmission resource management......................................................157
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
9 / 162
Figure 88: AterMUX TS reserved by GP(U) Ater TS margin..............................................158

Figure 89: Better transmission resource usage with DL retransmission in the BTS .............159
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
10 / 162
INDEX OF TABLES
Table 1: BSC-MFS/GP(U)-TC (re) design............................................................................21
Table 2: Configuration G1 BTS MKII with DRFU ............................................................30
Table 3: Configuration G2 BTS .........................................................................................31
Table 4: Configuration Evolium BTS ................................................................................31
Table 5: Configuration Evolium Evolution ........................................................................32
Table 6: BTS HW Capability in B10 ....................................................................................33
Table 7: TRX HW capability since G3 BTS generation ........................................................34
Table 8: Cell Types ..............................................................................................................34
Table 9: Frequency Hopping supported in B10 .....................................................................35
Table 10: Recommended SDCCH configuration for a standard cell only FR TRXs...........36
Table 11: Counter list - SDCCH dimensioning .....................................................................38
Table 12: Counter list - TCH dimensioning ..........................................................................40
Table 13: Counter list - PDCH dimensioning........................................................................41
Table 14: RLC data block size for each (M) CS....................................................................45
Table 15: Abis Channel Types..............................................................................................49
Table 16: Number of TS available in one Abis link ..............................................................50
Table 17: Abis occupation according to the number of FR TRX ...........................................55
Table 18: Counter list - Abis dimensioning Method 1...........................................................62
Table 19: Counter list - Abis dimensioning Method 2. ..........................................................65
Table 20: G2 BSC Capacity..................................................................................................69
Table 21: TSL/TCU Mapping...............................................................................................71
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
11 / 162
Table 22: BSC Evolution Capacity .......................................................................................74

Table 23: Counter list LA dimensioning ............................................................................85
Table 24: Counter list RA dimensioning ............................................................................89
Table 25: Max number of AterMUX CS interfaces G2 BSC ..............................................97
Table 26: Max number of A-interfaces G2 BSC.................................................................98
Table 27: Max number of AterMUX PS G2 BSC ...............................................................99
Table 28: Ratio of Mixing CS and PS Traffic in AterMUX.................................................100
Table 29: Counter list AterMUX-CS dimensioning..........................................................103
Table 32: Counter list GSL dimensioning ........................................................................116
Table 33: Counter list GSL dimensioning ........................................................................117
Table 34: G2 TC/ G2.5 TC capabilities...............................................................................123
Table 35: G2 TC configuration...........................................................................................124
Table 36: G2.5 TC configuration ........................................................................................125
Table 37: G2.5 TC capacity ................................................................................................125
Table 38: The 1st MFS generation (A9135 MFS) Capacity .................................................131
Table 39: Counter list - GP(U) dimensioning......................................................................136
Table 40: Counter list - Gb dimensioning ...........................................................................151
Table 41: GCH consumption B8 vs. B9 ...........................................................................156
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
12 / 162
History:
Edition
Draft
Date
05/11/07
Originator
Abdesselem Rezzoug
Comments
Creation from B9 version
Ed1P2
10/01/08
Eugen Marza
Correction from NE comments
Ed1
05/02/08
Abdesselem Rezzoug
Additonnal corrections and updates
Ed2
05/02/09
Eugen Marza
Additonnal corrections and updates
References:
[1]
3BK 17430 5000 PGZZA
BSS Configuration Rules release B10
[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
BSS B8 Dimensioning Rules
[10]
3DC 20003 0019 UZZZA
Dimensioning Rules for CS and PS traffic with BSS

Software Release B10
[11]
3DC 21150 0323 TQZZA
GSM/GPRS/EDGE Radio Network Design Process for

ALCATEL BSS Release B10
[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
[16]
3BK 11206 0476 DSZZA
BSC abbreviations Release B9
[17]
3DF 019032911 VAZZA
B9: BSS Architecture Service Guideline
[18]
3DC 21144 0120 TQZZA
Gb over IP in Release B10
[19]
3BK 10204 0028 DTZZA
Multiple CCCH
Abbreviations:
Refer to [16].
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
13 / 162
1 INTRODUCTION
The aim of this document is to describe BSS architecture configuration rules &
dimensioning processes in Alcatel release B10.
It is recommended to be the guideline for RNE (Radio Network Engineer) & TPM
(Technical 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 B9/B10 impacts to BSS architecture.
The main impacts are linked to the new features introduced in B10 release.
Part II: Detailed BSS Architecture Processes

This part describes in the details of the main network configuration rules in release
B10 and the dimensioning processes, which are related to counter analysis.
It covers the following BSS network elements and interfaces:
-
BTS
BSC
MFS/GP(U)
TC
Abis interface
AterMUX interface
A interface
Gb interface
The dimensioning method due to migration from B8 to B9 release is not detailed in this
document (please refer to [17] document).
Nevertheless, a short presentation about BSS architecture impacts with the introduction
of new B9 features is presented in Annex.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
14 / 162
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 ?

BSS stands for Base Station Subsystem.
The main role of the BSS is to provide and support both bi-directional signalling and CS
traffic channels (respectively PS traffic channels) between the Mobile Station and
Network SubSystem or NSS (respectively GPRS SubSystem or GSS).
Um
Abis
NSS
BTS
(CS traffic)
AterMUX CS
BSC
BTS
AterMUX CS/PS
AterMUX PS
TC
MFS
Gb
GSS
BTS
(PS traffic)
BSS (CS+PS traffic)

Figure 1: BSS Architecture
As presented in shown in Figure 1, the BSS consists of several network elements and
interfaces.
2.1.1 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 16kbps channel
(from/to BSC side) and the 64kbps channel (from/to the MSC1 ).
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.
MSC (Mobile Switching Center) is a main network element of the NSS having connection to the BSS.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
15 / 162
2.1.2 BSS Interfaces

2.1.2.1 Um (air or radio) interface
The UM interface is the radio interface connecting the MS with the BTS. It consists of a
group of TRXs and the group size is based on the BTS traffic.
TS0
TS1 TS2
TS3
TS4
TS5
TS6 TS7
TRX
Figure 2: TRX configuration on Um interface
Each TS of a TRX can provide a channel with different codec rates (FR, EFR, HR and AMR)
available for CS traffic, while GPRS CS1/CS4 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.
2.1.2.2 Abis interface

The Abis interface is connecting the BTS with their parent BSC. It is usually a 2Mbps link
(64kbps * 32 TS). A BTS can handle maximum two links and each TS contains four 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 signalling (RSL and OML) or extra TS.
A bis
CH# 1
TS
TS
:
:
TS
TS
TS
TS
TS
TS
0
1
CH# 2
CH# 3
T S 0 T ra ns p a re n cy
CH# 4
F ree
:
:
E xtra TS
26
27
28
29
30
31
E xtra TS
T C H / GC H
TCH / G CH
TCH / GCH
TCH / GCH
T C H / GC H
TCH / G CH TCH / GCH

R SL
TCH / GCH
Mapping to 1 TRX
of Um Interface
O ML
T S : 6 4 K bits /s e c
C h a nn e l o r N ibb le : 1 6 K bits /se c
Figure 3: Abis configuration
2.1.2.3 AterMUX interface

The AterMUX interfaces provide connections between:
-
BSC and TC
BSC and MFS
MFS and TC (in case of AterMUX transporting mixed Traffic CS & PS)
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
16 / 162
In general, the AterMUX is also a 2Mbps PCM link (64kbps * 32 TS).

However, differently from Abis, every nibbles on AterMUX are already defined to be TCH or
GCH or signalling channels.
TS
TS
TS
:
:
TS
TS
TS
TS
TS
:
:
TS
TS
0
1
2
AterMUX CS
CH# 1
CH# 2
CH# 3
CH# 4
Frame Synchronization
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
:
:
14
15
16
17
18
Qmux
TCH
Alarm octet
SS7
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
:
:
30
31
TCH
TCH
X25
TS : 64 Kbits/sec
Channel or Nibble : 16 Kbits/sec
Figure 4: AterMUX configuration Dedicated AterMUX for CS traffic
2.1.2.4 A interface
This interface, connecting TC and MSC, is supported by 2Mbps PCM links (64kbps * 32 TS).
One 64kbps channel on A is corresponding to one 16kbps channel on AterMUX TC is
responsible for this channel speed conversion.
The A trunk carries up to 31 traffic channels identified by a CIC (Circuit Identification Code).
A Interface
TS
TS
TS
TS
0
1
2
3
:
:
:
:
CIC 1
CIC 2
CIC 3
:
:
:
:
TS 30
TS 31
CIC 30
CIC 31
TS : 64 Kbits/sec
Figure 5: A-interface configuration
2.1.2.5 Gb interface
The Gb interface connects the MFS with the SGSN2 (Serving GPRS Support Node), which is
a main network element of the GSS having connection to the BSS.
When using Frame Relay stack, the Gb interface (GboFR) is supported by 2Mbps PCM links
(64kpbs * 32 TS).
When using UDP/IP/Ethernet stack, the Gb interface (GboIP) is supported by a Gigabit
Ethernet link (GE).
2
SGSN (Serving GPRS Support Node) is a main network element of the GSS having connection to the BSS.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
17 / 162
2.2 BSS Architecture Services

2.2.1 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.
2.2.2 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.
2.2.3 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).
BSS Architecture Services
Network State
Network Architecture
Setup
Initial
Assessment
Steady
Evolution
Developing
Figure 6: BSS Architecture Services
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
18 / 162
2.2.4 Process
Two different processes are defined, one supporting the services network architecture setup
and evolution, and the other one supporting the service network architecture assessment.
2.2.4.1 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.
START
(1) Gathering Data
NW Configuration Rules
(2) Design/Re-design
(2a) BSC/LAC/RAC Areas
(2b) BSC/MFS (GPU/GP)/TC Configuration
(2c) Number of interfaces: Abis, AterMUX, A and Gb
(2d) Parenting Abis TSU/LIU ports of the BSC
(3) Operational Implementation, according to (2)
FINISH
Figure 7: Network Architecture Setup and Evolution process
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).
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
19 / 162
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 3.3.5 for RAC design.
(2b) BSC/MFS (GP(U))/TC Configuration

BSC:
An appropriate type and configuration has to be chosen for each BSC 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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
20 / 162
MFS (GP(U)) 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/GP(U)).
Therefore, the outcome of (re)-design should provide the following information.
BSC
MFS/GP(U)
TC
Type
A9120 BSC, A9130 BSC
A9135 MFS, A9130

MFS
Configuration
- Conf 1, 2, 3, 4, 5 or 6 for
A9120 BSC
Nb of GP(U) boards - Nb of TC boards

dedicated to each dedicated to each BSC
BSC
- Nb of TC racks
Nb of MFS racks
- Stand Alone / Rack shared

configuration with 200, 400,
600, 800 or 1000 TRX for
A9130 BSC
G2 TC, G2.5 TC
(A9125 Compact TC)
Table 1: BSC-MFS/GP(U)-TC (re) design
Fore more details, please refer to section 3.3 for BSC configuration, section 3.5 for TC
configuration, and section Erreur ! Source du renvoi introuvable. 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 64kbps TSs for GboFR
Minimum throughput of IP network (QoS, Delay) for GboIP
Fore more details, please refer to section 3.2 for Abis, section 3.4 for AterMUX & Ainterface and section 3.7 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).
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
21 / 162
To perform parenting Abis TSU, please refer to the Abis TSU configuration rules in
section 3.3.1.2.
However, Network Engineering service has developed the architecture 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
The operation of parenting Abis TSU is required only in case of G2 BSC. For MxBSC it
has no meaning.
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.
2.2.4.2 Process for Network Architecture ASSESSMENT

The aim of the process is:
- To analyze traffic flows in the network at different levels (NE & Interfaces).
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
22 / 162
- 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.

START
(1) Gathering Data
NW Configuration Rules
(2) Applying Dimensioning Methods

Counters/Indicators vs. Configuration analysis
for each Network Elements and Interfaces
Recommendation/Threshold
(3) Assessment
-
Identify bottle necks

Identify need of new resources / new configuration
FINISH
Figure 10: Network architecture assessment process
Step (1) Gathering data

The first step is to gather 2 different kinds of data from the network:
Traffic data: relevant counters or indicators retrieved from OMC-R or NPO
machines.
BSS network topology data: the existing number, location and
configuration of each BSS network elements and interfaces.
Step (2) Applying dimensioning methods
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
23 / 162
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)
GP(U) 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.4)
A dimensioning (for more details, please refer to section 3.4.4.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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
24 / 162
2.3 BSS Architecture Impact in B10

In B10 release, there are several improvements in term of architecture point of view.
These improvements are related to the introduction of new features as follows:
Multiple CCCH (B10MR1)

Gb over IP (B10MR2)
Capacity Improvements (4000Erl in B10MR1, 4500Erl in B10MR2)
Optimized HR connectivity (B10MR1)
HSL functionality (B10MR1)
2.3.1 Multiple CCCH

The multiple CCCH (mCCCH) feature is required to support the increasing signalling load on
the common channels, due to either big CS cells with high peak throughput or to PS traffic
when no master PDCH is configured.
The 3GPP defines up to 4 Time Slots (TS0, TS2, TS4 & TS6) to carry the CCCH information
on the beacon TRX of one cell.
From B10 MR1, the optional mCCCH feature allows to define a second CCCH TS: only TS0
and TS2 on beacon TRX will be used, while TS0 is foreseen for single CCCH timeslot.
Beacon
TRX
Figure 11: mCCCH mapping on Beacon TRX
The main benefits permit:
To handle high capacity cells

To handle cells with heavy traffic models (high BHCA, high HR usage)
To define larger Location Areas

Avoid master Channel (PBCCH/PCCCH) deployment
Anyway, it is also possible to use mCCCH feature when master PDCH is implemented.
The mCCCH feature that can be implemented in both G2 BSC and Mx BSC, and has impacts
for:

Telecom: main impact on Paging and Access Control entity

O&M: impacts include the introduction of a new channel type CCH (BCCH +
CCCH) and change of the TRX mapping algorithm
In addition, TRE hardware limitation shall follow the below rules:
G3: maximum number of CCCH + SDCCH TS = 3

G4: maximum number of CCCH + SDCCH TS = 4
G5 (TWIN TRA): maximum number of CCCH + SDCCH TS = 4
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
25 / 162
The mCCCH feature has impacts in the Paging and Access Control entity.
On radio interface, the capacity of the PCH paging channel will allow about 63 paging/s.
The following set of rules applying for the configuration of mCCCH:
1)
2)
3)
4)
5)
6)
7)
CCH should be configured on TS2 of BCCH TRX

When BCCH is combined with SDCCH, CCH cannot be configured.
In BCCH TRX, when CCH is configured, only one Static SDCCH is allowed
In the cell with both BCC and CCH, the max number of SDCCH TS is extended to 22.
CBC and CBH are forbidden
Dynamic SDCCH is forbidden on BCCH TRX
Limitation rule on G2 TCU shall respect CCCH (BCCH) TS +SDCCH TS <= 4 TS
(one CCCH TS equal to one SDCCH TS in terms of signalling load)
8) The new channel type for CCCH is taken as bonus nibble in Abis interface.
Note:
CCH is the new channel type for BCCH + CCCH;

BCC is the channel type for FCCH + SCH + BCCH + CCCH.
2.3.2 Gb over IP
From B10 MR2 only, the Gb interface can be transported either on Frame Relay (GboFR) or
IP (GboIP) protocol stacks.
The feature Gb interface over IP (GboIP) is transported over a standardized protocol stack
according to 3GPP R6 (UDP/IP/Ethernet).
This feature is optional and allows the backhauling of Gb traffic over IP networks (IPv4); the
traffic flows from/to all GP(U) between MFS and SGSN can be aggregate in one single flow.
So the dimensioning of the IP network i.e. handling GboIP traffic shall be done MFS per
MFS instead of a per GP(U) dimensioning basis.
Indeed the IP bandwidth is dynamically shared between all GP(U) within one MFS, and there
is no service differentiation between handled traffic flows (signalling, streaming, best effort).
However, the IP network between SGSN and MFS shall provide enough bandwidth to pass all
aggregated flows.
The feature option, which has to be chosen per a BSC basis, is available and supported on:
A9130 MFS without any hardware impact (IP Ready)

A9135 MFS equipped with DS10 systems and the replacement of the switch rack by 2
new GE switches (OS-LS-6224).
There is no GboIP support for A9135 MFS with AS800 systems
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
26 / 162
As shown in the following figure, the mix of GboIP and GboFR is allowed within one MFS.
M FS
BSS1
BSSG P
NS
FR
BSS2
Fram e Relay Network
BSSG P
NS
FR
BSS3
SG SN
BSSG P
NS
U D P/IP
BSS4
BSSG P
NS
U DP/IP
IP Network
Gb
Figure 12: MFS capacity
2.3.3 Capacity Improvements

With B10 release, the capacity of the Mx BSC has been improved in terms of TRX, cells and
traffic mix load.
The Mx BSC will support up to 1000TRX with 5 CPP boards in one ATCA shelf, the number
of supported cells has been improved to reach the target of 500 cells.
Regardless these improvements, Mx BSC will allow a capacity of up to 324000 BHCA, about
575000 paging/hour and up to 4000Erl (B10 MR1).
In B10 MR1, the committed capacity will allow up to 4000Erl with TPGSMv1 board, and up
to 4500Erl in B10 MR2 with both the former TPGSMv1 and the new introduced TPGSMv3
board.
Five Mx BSC configuration types are defined based on the number of active CCP boards that
support 200 TRX each.
Without Optimized HR connectivity feature, the B9 rule is still applied.
The following table gives the configuration data of each MX BSC configuration type.
BSC Evo
Configuration
Max CS Load
(Erlang)
BTSs
Cells
Abis
E1
Ater-CS
E1
Ater-PS
E1
200 TRX
900
150
200
96
10
400 TRX
1800
255
264
96
20
12
600 TRX
2600 (B9)
2700 (B10)
255
264
176
30
18
800 TRX
3600 (B10)
255
500
176
40
24
1000 TRX
4000 (B10-MR1)
4500 (B10-MR2)
255
500
176
48
28
Figure 13: B10 BSC capacity improvements
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
27 / 162
2.3.3.1 Optimized HR connectivity

The Optimised half-rate connectivity feature is an optional feature that has been introduced
in B10 for BSC evolution capacity improvements.
Thanks to this feature, the TRX are no more weighted in terms of TRX equivalent, whether
FR or HR, and each CCP board can handle 200 TRX (e.g. 1 FR TRX = 1 HR TRX).
However, the CCP board is limited by a load of 1000 TCH simulaneously allocated.
This feature corresponds to the removal of HR connectivity constraints.
In case of half-rate usage, a maximum number of calls simultaneously established per CCP
board will be defined, so as to allow reaching 900Erl per CCP board, while not increasing the
external blocking.
2.3.3.2 HSL functionality

The ITU-T Recommendations have limited the amount of Signalling Links (SL) between two
adjacent Signalling Point (SP).
For Alcatel BSCs, there is a maximum of 16 SS7 signalling channels per BSC.
The signalling channel, called N7 channel, is carried over an individual 64kbps timeslot on
the AterMUX CS link; it is traditionally dimensioned with a 40% load.
In B9 release, Mx BSC was supporting up to 2600Erl that corresponds to a SS7 load of 60%.
To overcome the ITU-T limitation, High Speed Link (HSL) functionality has been introduced.
This HSL mode is only available with Mx BSC and it is used when Low Speed Link (LSL)
mode i.e. 64kbps SS7 channels is not sufficient for Mx BSC requiring a high SS7
signalling load or a high traffic mix model (1900Erl up to 4500Erl).
The HSL mode relies on the transport of SS7 signalling over a couple of 2Mbps PCM links:
Whatever the traffic load is

For redundancy and load sharing purposes
To double the BSC signalling throughput (for 4500Erl, the SS7 load is 33%)
HSL links are directly connected to MSC, without passing through TC

BSC
TC
ATERMUX
MSC
Interface A
HSL 1
HSL 2
Figure 14: BSC - MSC connectivity with HSL mode
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
28 / 162
2.3.4 STM-1 transmission in 9125 Transcoder

Transmission equipments usually represent a significant part of the Total Cost of
Ownership for a Network Operator. Traditionally based on E1 transport links, solutions for
the GSM transport network have evolved to other technologies, such as SDH.
In the Core Network as well, with introduction of NGN, SDH and IP networks have
become the common transport solutions.
As the first network element at the crossing between BSS and Core Network, and usually
located on Core Network site, the transcoder must support STM-1 connectivity.
Integrated STM-1 interface on the TC G2.5 is foreseen to:
reduce cost on interface equipment to SDH network;
reduce the cabling effort;
reduce the space needed for cables and distribution frames;
simplify cabling & assignment changes;
increase the reliability and availability.
By the insertion of an STM-1 interface board in the existing Transcoder cabinet, the 9125
Transcoder can offer 4 protected OC-3/STM-1 optical interfaces, in mono-mode/short-haul
type.
Each E1 link is transported transparently in one 2 Mbit/s VC12 container. One STM-1 link
can contain up to 63 VC12 containers.
2.3.5 Ater optimization

The Ater optimization is an optional B10 feature. It was introduce in order to globally
increase the ratio actual Gb throughput / Ater resources needed on the GPUs. The
optimization of the total amount of Ater resources needed on the GPU to support its PS
traffic will allow to reduce the number of Ater links of the GPUs.
An othe goal is to decrease the number of TBF establishment failures due to lack of Ater
resources (for a fixed amount of Ater resources available). This is because a non-optimal
usage of Ater resources can lead to failure/blocking situations for the incoming traffic on
the GPU due to the Ater congestion.
Some algorithmic changes were done. The intent of the technical corrections is to establish
(at most) n GCHs for each short TBF (short TBF meaning signalling or short data
transfer TBF), n being a low number.
The transfer of a given MS may have now 2 possible values: short data or data. An MS
transfer is considered to be short data as long as less than
N_DATA_BYTES_MAX_TRANS bytes have been transferred in both directions (since
the TBF establishment(s)). Else, if more than N_DATA_BYTES_MAX_TRANS bytes
have been transferred in at least one direction, the MS transfer is considered to be data.
A short data MS transfer is supposed to cover both the GMM traffic case (signalling
case) and the cases of short actual data (e.g. short blackberry terminal transfers).
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
29 / 162
3 Detailed BSS Architecture Process

This section describes in details of the BSS architecture process in release B10.
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 Configuration

The following diagram presents the BTS generations, which are supported in release B10.
BTS
Generation
G1 BTS
G2 BTS
Evolium BTS
Evolium Evolution
G1 BTS MK II
G2 BTS
G3 BTS
G4 BTS
with DRFU
DRFU
M4M
M5M
G5 BTS
Twin
GPRS
CS-1, CS-2
GPRS
CS-1, CS-2
GPRS
CS-1, CS-4
GPRS CS-1, CS-4

EDGE MCS-1, MCS-9
Figure 15: BTS generation/type supported in B10
G1 BTS 1st BTS Generation
Only MKII with DRFU is supported in B10. It stays at B7.2 functionality and its
configuration is presented in Table 2.
Type
MKII
Characteristic
Std + DRFU
Nb of sectors
1
Nb of TRX
8
GSM 900
x
Data in this table, based on [9]
Table 2: Configuration G1 BTS MKII with DRFU
For more details, please refer to [1] and [3]
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
30 / 162
G2 BTS 2nd BTS Generation
Only G2 BTS with DRFU is supported in B10 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 3.
Configuration
BTS
G2
Min
1 TRE
Max
1 Sector: 8 TRE
Extension / Reduction
Physical
Logical
Min
1 TRE
1 TRE
Table 3: Configuration G2 BTS
Evolium BTS 3rd BTS Generation
The Evolium BTS is designed with some improvements as compared to the previous
BTS generation (G2). The main changes (related to architecture design) are:
Support Abis Statistical Multiplexing (64kbps and 16kbps)
Secondary Abis link (except micro BTS M4M)
GPRS CS-3, CS-4 is available
Support TWIN TRX modules (since B9 MR4)
From 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 4.
Extension/Reduction
Physical Logical
Min
Configuration
BTS
Min
Evolium BTS
(G3 / G3.5)
M4M
(micro BTS)
Max
1 TRE
Up to 18 TRE (1 to 6 sectors) (since B9MR4)
1 TRE
TRE
2 TRE
Up to 6 TRE (1 to 6 sectors)
2 TRE
1 TRE
Table 4: Configuration Evolium BTS
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
31 / 162
Evolium Evolution 4th 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 & analogue parts on the
same board) brings the possibility to develop a low power TRE that would allow
achieving 18 TRX capacity in one rack.
Since 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 introduces a new TRE with EDGE HW Capability
Micro BTS M5M
TWIN TRX modules (since B9MR4)
Their configurations are presented in Table 5.

Extension/Reduction
Physical
Logical
Min
Configuration
BTS
Min
Evolium BTS
(G3.8 / G4.2)
Evolium BTS
(G5)
M5M
(micro BTS)
Max
1 TRE Up to 18 TRE (1 to 6 sectors) (since B9MR4)
1 TRE
1 TRE
1 TRE Up to 24 TRE (1 to 6 sectors) (since B9MR4)
1 TRE
1 TRE
2 TRE Up to 12 TRE (1 to 6 sectors)
2 TRE
1 TRE
Table 5: 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]
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
32 / 162
Summary BTS Hardware Capability B10 release
As shown in Table 6:
G1 BTS
Multi
band
Mono
band
Data
Traffic
Voice
Traffic
Abis
feature
B9 release
B10
release
No Multiplexing
16K Static Multiplexing
64K Statistical Multiplexing
2nd Abis access
FR
DR
AMR
EFR
GPRS (CS-1 , CS- 2)
GPRS (CS-3 , CS- 4)
EGPRS (MCS-1 to MCS-9)
GSM 850
GSM 900
GSM 1800
GSM 1900
850/1800
850/1900
900/1800
900/1900
G1 BTS MKII
DRFU
x
G2 BTS
G2 BTS DRFU
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Evolium BTS
G3 BTS
x
x
x
x
x
x
x
x
x
x
x
M4M
x
x
x
x
x
x
x
x
x
x
x
x
x
Evolium Evolution
x
x
x
x
x
x
G4 BTS
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
M5M
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Table 6: BTS HW Capability in B10
TRX hardware description
Three main types of Transceiver modules are implemented since G3 BTS generation;
the Evolium TRE, the EDGE TRA and the Twin TRX.
These Transceivers can cover either GSM band or DCS band.
The Evolium TRE, which is the first version of Evolium transceiver, do not allow
EDGE activation, however G3 BTS can offer EDGE services on each cell if one EDGE
TRA (or Twin TRX) module is implemented on that cells.
The operation that consists to replace an Evolium TRE module by an EDGE TRA /
Twin TRX is called a REFRESH (or NORIA) operation.
The EDGE TRA is the first Evolium transceiver that is EDGE capable.
The Twin TRX module is a module that can be used in two different modes
Capacity mode that generates two functional TRX (16 RTS), in the same or different
cells, with same radio performances as TRA Medium Power (45W GMSK in 900MHz),
Coverage mode (Tx Diversity mode) that generates a single functional TRX (8 RTS)
allowing either:
Higher Output Power due to Tx diversity ("air coupling") usage (113W to 175W
GMSK in 900MHz, and 88W to 136W GMSK in 1800MHz
Higher Sensitivity (-117.4 to -121dBm) due to 4Rx Uplink Diversity usage (2Rx
Diversity also possible)
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
33 / 162
The following table describes the transceiver hardware since G3 BTS generation.
Generation
MNEMO
EDGE
G3
TRX 900 35W DR-EFR 9100
TRX Type
TRGM
No
G3
TRX 1800 35W DR-EFR 9100
TRDM
No
G3
TRX 1800 60W DR-EFR 9100
TRDH
No
G4
A9100 TRX 900 EDGE COMPATIBLE
TRAG
Yes
G4
TRAD
Yes
G4
TRAL
Yes
G4
TRAP
Yes
G4
A9100 TRX 900 HP EDGE COMPATIBLE
TAGH
Yes
G4
A9100 TRX 1800 HP EDGE COMPATIBLE
TADH
Yes
G4
A9100 TRX 900 EDGE PLUS
TRAGE
Yes
G4
A9100 TRX 1800 EDGE PLUS
TRADE
Yes
G4
A9100 TRX 900 HP EDGE PLUS
TAGHE
Yes
G4
A9100 TRX 1800 HP EDGE PLUS
TADHE
Yes
G5
A9100 TRX 900 TWIN
TGT09
Yes
G5
A9100 TRX 1800 TWIN
TGT18
Yes
Table 7: TRX HW capability since G3 BTS generation
3.1.1.1 Cell Configuration

Cell Types: the following table describes all the cell types (with profile type
parameters) available in B10.
Cell Type
Micro
Single
Mini
Extended
Umbrella
Concentric
Umbrella-Concentric
Indoor Micro
Profile Type Parameters

Dimension
Coverage
Partition
Range
Micro
Macro
Macro
Macro
Macro
Macro
Macro
Micro
Overlaid
Single
Overlaid
Single
Umbrella
Single
Umbrella
Indoor
Normal
Normal
Normal
Normal
Normal
Concentric
Concentric
Normal
Normal
Normal
Normal
Extended
Normal
Normal
Normal
Normal
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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
34 / 162
Shared Cell:
A cell shared by several BTSs is possible to support up to 16 TRX (software limitation).
With Twin TRX, the 16 TRX limitation can be reached without using shared cell method.
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 B10.
Hopping Type
Non Hopping (NH)
Base Band Hopping (BBH)
Radio Hopping (RH) *
Non Hopping / Radio Hopping (NH/RH)
NH/RH with Pseudo Non Hopping TRX
BBH with Pseudo Non Hopping TRX
Supported in B9
x
x
x
x
x

* RH works only with M1M and M2M that are now obsolete.
Table 9: Frequency Hopping supported in B10
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 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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
35 / 162
Recommended SDCCH configuration:

In a cell, the number of SDCCHs is defined variously, based on:
-
Location Update (LU) signalling traffic: 1 LU/call for standard cell

SMS signalling traffic: 0.5 SMS/call for standard cell
Number of TRXs
Recommended default number of SDCCH and configuration are presented in Table 10.
Number of TRXs
BCCH Combined
1
2
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Yes
Yes
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Number of SDCCH sub-channels

Total
SDC
12
12
24
24
32
32
32
40
40
48
48
48
56
56
64
72
72
SDD
4
4
8
8
8
8
8
16
16
16
16
16
16
16
24
24
24
8
8
16
16
24
24
24
24
24
32
32
32
40
40
40
48
48
Table 10: Recommended SDCCH configuration for a standard cell only FR TRXs
Remarks:
1)
2)
3)
4)
5)
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.
Up to 16 TRXs are possible to be configured for a cell thanks to shared cell feature.
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.
An additional dynamic SDCCH/8 must be provided for each DR TRX (these are
expected mainly on small cells).
For some particular cells with high (LU and/or SMS) signalling 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).
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
36 / 162
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 16.
Nb of required TRXs
Nb of required cells
Max. Capacity of
the given BTS
Nb of installed BTSs
Nb of required BTSs
Required >
Assessment
(comparision)
Required <
Required =
Under-dimensioning
Increase installed BTSs
OK
Over-dimensioning
Decrease installed BTSs
Figure 16: Determination of BTS configuration
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 (2 TS in case of mCCCH)
SDCCH TS: to be defined based on SDCCH traffic (cf. section 3.1.3.1)
TCH/PDCH TS: to be defined based on CS/PS traffic (cf. section 3.1.3.2)
And a TRX consists of 8 RTS (Radio TimeSlots).

So,
Number of TRXs = roundup [(BCCH TS + SDCCH TS + TCH/PDCH TS) / 8]
When mCCCH feature is enabled, a second CCCH time slot shall be taken into consideration
when computing the required number of BCCH, SDCCH and TCH/PDCH timeslots.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
37 / 162
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
GSDTRT
Cumulated time during which the SDCCH sub-channels belonging

to the related static or dynamic SDCCH timeslots are busy.
MC04
GSDNACGN
Number of unsuccessful SDCCH sub-channel selection (all

SDCCH sub-channels are busy or Out of Service).
MC148
GSDNACAN
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.
Methodology:
The process of SDCCH dimensioning is presented in Figure 17.
INPUT
METHOD
OUTPUT
Required
SDCCH Traffic
Nb of required
SDCCH subchannels /
timeslots
Erlang B
GoS:
% SDCCH blocking
Figure 17: SDCCH dimensioning process
INPUT
The required SDCCH traffic is computed as below formula.
Re quired _ SDCCH _ traffic =
Measured _ SDCCH _ traffic

1 Min(%SDCCH _ cong , 30%)
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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
38 / 162
Where:
Measured _ SDCCH _ traffic =
% SDCCH _ cong =
MC 400
3600
MC 04
100%
MC 04 + MC148
The other input is Grade of Service (GoS), which is defined by the required SDCCH
congestion rate (pSDCCH).
Normally GoS should be given or agreed by the Mobile Operator.
The typical value for the required SDCCH congestion rate is 0.5%.
METHOD
Concerning only CS traffic, the statistical law Erlang B is used during the dimensioning
process to determine the necessary resources versus the traffic and the target GoS.
As SDCCH is associated to CS traffic only, Erlang B can be applied to calculate the
required number of SDCCH sub-channels according to required SDCCH traffic and the
target congestion rate.
OUTPUT
Number of required SDCCH sub-channels
= Erlang B (Required_SDCCH_traffic, pSDCCH)
Then,
Number of required SDCCH Timeslots
=
Nb of required SDCCH sub-channels / 8; for non- BCCH combined cell

(Nb of required SDCCH sub-channels 4) / 8; for BCCH combined cell
Assessment:
When % SDCCH congestion (of any cell) > pSDCCH, the SDCCH re-dimensioning is
needed.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
39 / 162
3.1.3.2 TCH/PDCH Dimensioning

Target: To estimate the number of TCH & PDCH resources needed at Cell level.
Gathered Counters: TCH
Counter Name
Indicator Name
Definition
MC380a
GTCTRFT
Time during which the TCH FR are busy
MC380b
GTCTRHT
Time during which the TCH HR are busy
MC812
GTCNACGN
Number of failures when switching from SDCCH to the TCH

(call establishment only) due to congestion on Air Interface
channels (RTCH).
MC703
GTCNACAN
Number of TCH successfully selected for any purpose other

than HO.
Table 12: Counter list - TCH dimensioning
Gathered Counters: PDCH

Counter Name
Indicator Name
Definition
P451b
GARPDCTDBUT
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
GARPDCTUBUT
Cumulative time during which a UL TBF uses on PDCH, for

all PDCHs and for all the TBFs of the cell (established in
P14
GQRDTECGN
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
GQRUTECGN
Number of uplink TBF establishment failures due to

congestion (no radio resource in the MFS).
P91a+P91b+P91c+
P91d+P91e+P91f+
P505
GTRDTERQN
Number of DL TBF establishment requests per cell.
P62a+P62b+P62cP438c + P507
GTRUTERQN
Number of UL TBF establishment requests per cell.
P38e
GARPDCUDBUT
Cumulative time during which the slave PDCHs are

established and carry at least one DL TBF (established in
P38f
GNPACUUBUT
Cumulative time during which the slave PDCHs are

established and carry at least one UL TBF (established in
P20x
(x = ad)
GQRPDDRxN
In acknowledged mode, number of DL RLC data blocks

(except RLC blocks containing LLC Dummy UI Commands
only) on PDTCH encoded in (M)CS-x (i.e. CS-1 (P20a)
CS-4 (P20d)) retransmitted due to unacknowledgement of the
MS.
(x = 1,.. ,4)
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
40 / 162
P20f+P20g+P20h+
P20i+P20j+...+P20n
(x = fn)
GQRPDDRMN
In acknowledged mode, number of DL RLC data bytes

encoded in all MCS-x and retransmitted due to
unacknowledgement of the MS. RLC blocks containing LLC
dummy UI commands are not counted.
P21x
(x = ad)
GQRPDURxN
In acknowledged mode, number of UL RLC data blocks on

PDTCH encoded in (M)CS-x (i.e CS-1 (P21a) CS-4
(P21d)) retransmitted due to unacknowledgement of the MFS.
P21f+P21g+P21h+
P21i+P21j++P21n
(x = fn)
GQRPDURMN
In acknowledged mode, number of UL RLC data bytes

encoded in all MCSx and retransmitted due to
unacknowledgement of the MFS.
P55x
(x = a,.. ,m)
GTRPDDCxN
(x = 1,.. ,4)
GTRPDDMyN
(y = 1,.. ,9)
GTRPDUCxN
(x = 1,.. ,4)
GTRPDUMyN
(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).
(x = 1,.. ,4)
P57x
(x = a,.. ,m)
Number of useful UL RLC blocks received in RLC

acknowledged mode on PDTCH encoded in (M) CS-x i.e. CS1 (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.
INPUT
METHOD
CS service
input data
PS service
input data
KaufmannRobert
Algorithm
OUTPUT
Total
required TS
for TCH and
PDCH
Figure 18: 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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
41 / 162
The way to calculate the congestion rate for FR and HR is presented below:
CS _ Cong _ Per = min( 30 %, CS _ Real_Cong_ Per)
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.
CS_Real_Cong_Per =
RTCH_Assign _ Cong
MC812
=
RTCH_Assign _ Request MC 812 + MC 703
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.
FR _ Cong _ Per =
MC 380a
CS _ Cong _ Per
MC 380a + MC 380 b
HR _ Cong _ Per =
MC 380 b
CS _ Cong _ Per
MC 380a + MC 380 b
Then,
Full Rate CS traffic Intensity is:
FR =
MC 380acell
FR _ Successful _ Traffic
=
1 FR _ Cong _ Per
3600 ( 1 FR _ Cong _ Per )
Half Rate CS traffic Intensity is:

HR =
MC380bcell
HR _ Successful _ Traffic
=
1 HR _ Cong _ Per
3600 ( 1 HR _ Cong _ Per )
CS Bandwidth:
1 TS; for FR
0.5 TS; for HR
CS GoS (as requirement): Blocking Probability rate = 2 %, for instance
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
42 / 162
(2) PS service input data:

PS Traffic Intensity in Erlang:
The required PS traffic intensity is computed as below formula.
Re quired _ PS _ traffic =
Measured _ PS _ traffic
1 Min(%TBF _ radio _ cong , 30%)
Where:
Measured _ DL _ PS _ traffic =
P 451b
3600
Measured _ UL _ PS _ traffic =
P 451a
3600
%DL _ TBF _ radio _ cong =
P14
100 %
P 91a + P 91b + P 91c + P 91d + P 91e + P 91f + P 505
%UL _ TBF _ radio _ cong =
P 27
100%
P 62a + P 62b + P 62c P 438c + P 507
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.
More acurate results can be obtained if the required bandwidth is computed as:
1/(Average Nb of DL TBF per PDCH) = P38e/P451b
1/(Average Nb of UL TBF per PDCH) = P38f/P451a
PS GoS (as requirement): Delay in seconds and Quantile in % (0.01s and 0.98%).
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.
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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
43 / 162
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.
Final agregation:
Total nb of RTCH =
= 1 TS for BCCH + 1 TS for CCCH (if case) +
+ Nb of Required SDCCH TSs +
+ Nb of Required TSs for FR, HR and DL PS,
coming from Kaufmann-Roberts algorithm.
or
+ Nb of Required TSs for FR, HR and UL PS,
if UL PS traffic is higher than DL.
Total nb of TRX = Roundup [(Total nb of RTCH)/8]

Recommendation:
The method is complicated to apply manually, as it uses high level of mathematical
formulas & statistical laws. Therefore, please contact Network Engineering service for
related supports.
Assessment
The following diagram presents the TCH/PDCH assessment process.
Nb of required
TCH/PDCH TSs
Nb of installed
TCH/PDCH TSs
Required > Installed
Assesment
(comparision)
Required < Installed
Required = Installed
Under-dimensioning
Increase installed TCH/PDCH
OK
Over-dimensioning
Decrease installed TCH/PDCH
Figure 19: TCH/PDCH dimensioning assessment
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
44 / 162
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.
PS throughput in kbps is used as additional information:
PS throughput in kbps:
For DL:
d PS _ DL =
Data_DL
Transmision_Time_DL
m
n
d
8 P 20 x RLC _ Block _ Sizex + P 55 x RLC _ Block _ Sizex + P 20 x

x =a
x =a
x =f
=
1000 P 38e
For UL:
d PS _ UL =
Data _ UL
Transmision _ Time _ UL
m
d
n
8 P 21x RLC _ Block _ Size x + P 57 x RLC _ Block _ Size x + P 21x
x =a
x =a
x =f
=
1000 P 38 f
Where:
Channel Coding scheme
RLC data block size in bytes
CS-1
CS-2
CS-3
CS-4
MCS-1
MCS-2
MCS-3
MCS-4
MCS-5
MCS-6
MCS-7 (sent of 2 blocks)
22
32
38
52
22
28
37
44
56
74
2*56
2*68
2*74
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. 30kbps for DL & UL (this information
should also be provided in R_AVERAGE_GPRS and R_AVERAGE_EGPRS parameters).
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
45 / 162
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 64kbps.
There are several media to transport Abis over networks:
A terrestrial link referred to as PCM 2Mbps link (64kbps * 32 TS = 2048kbps)
A microwave link (same capacity or higher)
Digital Cross-connect Network equipment, which concentrates 4, 16 or 64 PCM links
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.
Chain topology brings the gain to save number of Abis links but it is possible only for
the BTSs with small TRX configuration.
BTS
BTS
BTS
Abis
Abis
Up to 15 BTSs
per
1 Abis Chain
Abis
BSC
Figure 20: Abis Chain (Multi-drop) Topology
Star topology
Each BTS is connected to the BSC directly; an Abis link is dedicated to a BTS.
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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
46 / 162
BTS
BTS
Abis
BTS
Only 1 BTS
per
1 Abis Star
Abis
Abis
BTS
Abis
BSC
Figure 21: Abis Star Topology
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.
It is anyway more recommended to secure the transmission link rather than wasting
BSC connectivity resources by using this kind of topology.
BSC
BTS
BTS
Abis
Up to 7 BTSs
per
1 Abis Ring
BTS
Abis
Abis
Abis
Figure 22: Abis Ring (Closed loop) Topology
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 B10:
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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
47 / 162
BTS
Sec Abis
Pri Abis
Configuration # 1
BTS
BTS
BSC
BTS
Pri Abis
Configuration # 2
Sec Abis
BSC
Figure 23: Secondary Abis Topology
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 auto-detection.
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 Synchronization bits) containing in ring
control channel.
3 types of BTS Channels
1) TCH/GCH Channels: 8 Radio TS per TRX is mapping onto 2 Abis TS.

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
Figure 24: 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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
48 / 162
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:
Radio Signalling Link (RSL) is used for supporting traffic management

procedures (MS to network communication).
Operation & Maintenance Link (OML) is used for supporting network
management procedures.
For details about Abis resource management for RSL/OML, please refer to section 0.
3) Extra Abis TS
On Abis interface, two types of 64kbps TS are considered:
Basic Abis TS:
Extra Abis TS:
handle OML, RSL and traffic TS

handle only supplementary GPRS (CS-3/CS-4) and EDGE
(MCS-1 to MCS-9) nibbles when needed.
In B10 release, the maximum number of extra Abis TS can be configured through
the new OMC parameter N_EXTRA_ABIS_TS.
Summary Abis Channels:
TS position
Channel type
TS0 usage
TS0 transparency
TS0
Other TS except TS0
Purpose
Qmux Channel
Qmux
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
TS0
Included with Qmux
Direction of clock synchronisation
Synchronisation controls S bits
BTS Channels
TCH/GCH
Other TS except TS0
LAPD
Other TS except TS0
GSM (GPRS CS-1/CS-2) traffic

LAPD channel for BTS (1 OML per BTS)
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
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
49 / 162
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 signalling 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

(*) 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.
From Table 16, one Abis link capacity depends on:

- Type of Abis network topology
- TS 0 mode (TS 0 usage or TS 0 transparency)
- BTS generations
3.2.1.4 Signalling Sub-Multiplexing Schemes

The signalling sub-multiplexing schemes offer improvement in terms of required PCM time
slots for the signalling 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 signalling sub-multiplexing schemes:
No Multiplexing
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
50 / 162
3.2.1.4.1 No Multiplexing
Without multiplexing, the signalling channels will consume Abis TS as below.
1 RSL: one Abis TS (64kbps)
1 OML: one Abis TS (64kbps)
The following figure shows the example of Abis timeslot consumption for 1 BTS with 4 TRXs
when no multiplexing is applied.
Abis Configuration
Nibble 1
TS 0
TS 1
TS 2
TS 3
TS 4
TS 5
TS 6
TS 7
TS 8
TS 9
TS 10
TS 11
TS 12
TS 13
TRX 1 - TS 0
TRX 1 - TS 4
TRX 2 - TS 0
TRX 2 - TS 4
TRX 3 - TS 0
TRX 3 - TS 4
TRX 4 - TS 0
TRX 4 - TS 4
Nibble 2
Nibble 3
TS 0 Usage / Transparency
TRX 1 - TS 1
TRX 1
TRX 1 - TS 5
TRX 1
TRX 1 - RSL
TRX 2 - TS 1
TRX 2
TRX 2 - TS 5
TRX 2
TRX 2 - RSL
Nibble 4
- TS 2
- TS 6
TRX 1 - TS 3
TRX 1 - TS 7
- TS 2
- TS 6
TRX 2 - TS 3
TRX 2 - TS 7
TRX 3 - TS 1
TRX 3 - TS 2
TRX 3 - TS 5
TRX 3 - TS 6
TRX 3 - RSL
TRX 4 - TS 1
TRX 4 - TS 2
TRX 4 - TS 5
TRX 4 - TS 6
TRX 4 - RSL
TRX 3 - TS 3
TRX 3 - TS 7
13 TS required
in case of
No Multiplexing
TRX 4 - TS 3
TRX 4 - TS 7
OML
:
:
:
:
:
TS 31
Figure 25: 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 16kbps. It is therefore possible to pack up to four RSL
into one 64kbps Abis time slot.
However, the OML is still carried on a full 64kbps Abis time slot.
That means:
Up to 4 RSL: 1 Abis TS (64kbps)
1 OML:
1 Abis TS (64kbps)
The following figure shows the example of Abis timeslot consumption for 1 BTS with 4 TRX
when 16K Static multiplexing is applied.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
51 / 162
Abis Configuration
Nibble 1
TS 0
TS 1
TS 2
TRX 1 - TS 0
TRX 1 - TS 4
Nibble 2
Nibble 3
TRX 1 - TS 1
TRX 1 - TS 2
TRX 1 - TS 5
TRX 1 - TS 6
TRX 2 - TS 0
TRX 2 - TS 4
TS 7
TS 8
TRX 4 - TS 1
TRX 4 - TS 2
TRX 4 - TS 4
TRX 4 - TS 5
TRX 4 - TS 6
TRX 4 - TS 7
TRX 1 - RSL / TRX 2 - RSL / TRX 3 - RSL / TRX 4 - RSL
OML
TS 9
TS 10
TRX 2 - TS 2
TRX 1 - TS 3
TRX 1 - TS 7
TS 3
TS 4
TS 5
TS 6
TRX 3 - TS 0
TRX 3 - TS 4
TRX 4 - TS 0
TRX 2 - TS 1
TRX 2 - TS 5
TRX 3 - TS 1
TRX 3 - TS 5
Nibble 4
TRX 2 - TS 6
TRX 3 - TS 2
TRX 3 - TS 6
:
:
TRX 2 - TS 3
TRX 2 - TS 7
TRX 3 - TS 3
TRX 3 - TS 7
TRX 4 - TS 3
10 TS required
in case of
TS 31
Figure 26: 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 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 signalling (BCCH or SDCCH), is affected
on timeslot 0 of each TRX. In this case no additional timeslot is required on the Abis for
signalling.
As for 64K statistical multiplexing, Abis transmission can be seen as a sequence of MCB
16/1, see below.
Abis Configuration
Nibble 1
TS 0
TS 1
TS 2
Nibble 2
Nibble 3
TRX1-RSL/OML TRX 1 - TS 1
TRX 1 - TS 4
TRX 1 - TS 5
TRX 1 - TS 2
TRX 1 - TS 6
Nibble 4
TRX 1 - TS 3
TRX 1 - TS 7
Figure 27: 16K Statistical Multiplexing MCB 16/1 mapping
The following figure shows the example of Abis timeslot consumption for 1 BTS with 4 TRX
when 16K Statistical multiplexing is applied.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
52 / 162
Abis Configuration
Nibble 1
TS 0
TS 1
TS 2
TS 3
TS 4
TS 5
TS 6
TS 7
TS 8
Nibble 2
Nibble 3
TRX 1-RSL/OML TRX 1 - TS 1

TRX 1 - TS 4
TRX 1 - TS 5
TRX 2 - RSL
TRX 2 - TS 1
TRX 2 - TS 4
TRX 2 - TS 5
TRX 3 - TS 1
TRX 3 - RSL
TRX 3 - TS 4
TRX 3 - TS 5
TRX 1 - TS 2
TRX 4 - TS 1
TRX 4 - TS 5
TRX 4 - RSL
TRX 4 - TS 4
:
TS 31
Nibble 4
TRX 1 - TS 6
TRX 1 - TS 3
TRX 1 - TS 7
TRX 2 - TS 2
TRX 2 - TS 6
TRX 3 - TS 2
TRX 3 - TS 6
TRX 2 - TS 3
TRX 2 - TS 7
TRX 3 - TS 3
TRX 3 - TS 7
TRX 4 - TS 2
TRX 4 - TS 6
TRX 4 - TS 3
TRX 4 - TS 7
8 TS required
in case of
16K Statistical
Multiplexing
Figure 28: Example of Abis TS usage for 1 BTS/4 TRX 16K Statistical Multiplexing
Rules:
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 signalling channel
BCCH/CCCH, SDCCH).
3.2.1.4.4 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 signalling load.
3 Abis TS per TRX

Abis Configuration
TS
TS
TS
TS
0
1
2
3
Nibble 1
Nibble 2
Nibble 3
Nibble 4
TRX 1 - TS 0
TRX 1 - TS 4
TRX 1 - TS 1
TRX 1 - TS 2
TRX 1 - TS 5
TRX 1 - TS 6
TRX 1 - RSL / OML
TRX 1 - TS 3
TRX 1 - TS 7

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

Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
53 / 162
Abis Configuration
TS
TS
TS
TS
TS
TS
0
1
2
3
4
5
Nibble 1
Nibble 2
Nibble 3
Nibble 4
TRX 1 - TS 0
TRX 1 - TS 4
TRX 2 - TS 0
TRX 2 - TS 4
TRX 1 - TS 1
TRX 1 - TS 2
TRX 1 - TS 5
TRX 1 - TS 6
TRX 2 - TS 1
TRX 2 - TS 2
TRX 2 - TS 5
TRX 2 - TS 6
TRX 1 - RSL / TRX 2 - RSL / OML
TRX 1 - TS 3
TRX 1 - TS 7
TRX 2 - TS 3
TRX 2 - TS 7

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

Abis Configuration
Nibble 1
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
0
1
2
3
4
5
6
7
8
9
Nibble 2
Nibble 3
Nibble 4
TRX 1 - TS 0
TRX 1 - TS 1
TRX 1 - TS 2
TRX 1 - TS 3
TRX 1 - TS 4
TRX 1 - TS 5
TRX 1 - TS 6
TRX 1 - TS 7
TRX 2 - TS 0
TRX 2 - TS 1
TRX 2 - TS 2
TRX 2 - TS 3
TRX 2 - TS 4
TRX 2 - TS 5
TRX 2 - TS 6
TRX 2 - TS 7
TRX 3 - TS 0
TRX 3 - TS 1
TRX 3 - TS 2
TRX 3 - TS 3
TRX 3 - TS 4
TRX 3 - TS 5
TRX 3 - TS 6
TRX 3 - TS 7
TRX 4 - TS 0
TRX 4 - TS 1
TRX 4 - TS 2
TRX 4 - TS 3
TRX 4 - TS 4
TRX 4 - TS 5
TRX 4 - TS 6
TRX 4 - TS 7
TRX 1 - RSL / TRX 2 - RSL / TRX 3 - RSL / TRX 4 - RSL / OML
The following figure shows the example of Abis timeslot consumption for 1 BTS
with 4 TRX when 64K Statistical multiplexing is applied.
Abis Configuration
Nibble 1
TS 0
TS 1
TS 2
TS 3
TS 4
TS 5
TS 6
TS 7
TS 8
TS 9
:
TRX 1 - TS 0
TRX 1 - TS 4
TRX 2 - TS 0
TRX 2 - TS 4
TRX 3 - TS 0
TRX 3 - TS 4
Nibble 2
Nibble 3
TRX 1 - TS 1
TRX 1 - TS 5
TRX 2 - TS 1
TRX 2 - TS 5
TRX 3 - TS 1
TRX 1 - TS 2
TRX 1 - TS 6
TRX 2 - TS 2
TRX 2 - TS 6
TRX 3 - TS 2
Nibble 4
TRX 1 - TS 3
TRX 1 - TS 7
TRX 2 - TS 3
9 TS required
in case of
64K Statistical
Multiplexing
TRX 2 - TS 7
TRX 3 - TS 3
TRX 3 - TS 7
TRX 3 - TS 5
TRX 3 - TS 6
TRX 4 - TS 0
TRX 4 - TS 1
TRX 4 - TS 2
TRX 4 - TS 3
TRX 4 - TS 4
TRX 4 - TS 5
TRX 4 - TS 6
TRX 4 - TS 7
TRX 1 - RSL / TRX 2 - RSL / TRX 3 - RSL / TRX 4 - RSL / OML
:
TS 31
Figure 32: Example of Abis TS usage for 1 BTS/4 TRX 64K Statistical Multiplexing
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
54 / 162
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
A BTS with N DR TRE configured with 64K statistical multiplexing includes ((N1)/2)+1 MCBs of which:
I. (N/2) MCB 64/2
II. (N mod 2) MCB 64/1
Dual Rate attribute is introduced per TRE and not anymore per BTS; only the TRX
using the DR mode must follow the rules concerning DR TRX (possibility to connect
2 DR TRX per TCUC).
Number of FR
TRE per BTS
(per Abis link)
List of physical MCBs
Max SDCCH weight

per MCB
Needed Abis TS
reserved for
LapD
64/1
24
64/2
32
64/2; 64/1
32; 24
64/4
32
64/4; 64/1
32; 24
64/4; 64/2
32; 32
64/4; 64/2; 64/1
32; 32; 24
64/4; 64/4
32; 32
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
Table 17: Abis occupation according to the number of FR TRX
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
55 / 162
Important note:
A new parameter signaling load (low/high) entered by the operator at BTS level permits for
the BSC to determine the multiplexing scheme according to:
low: 4:1 (resp. 2:1) maximum multiplexing scheme for FR TRX (resp. for DR TRX)
high: 2:1 (resp. 1:1) maximum multiplexing scheme for FR TRX (resp. for DR TRX)
The operator gives the number of TRE per sector among the ones declared at BTS creation
have to be taken as DR TREs in each sector and, in case of multiband sector, in each band.
MCB 64/1 for FR or DR with High signaling load;
MCB 64/2 for FR with High signaling load or DR with Normal signaling load;
MCB 64/4 for FR only with Normal signaling load.
It is always recommended to use a High signaling load whenever there are enough Time
slots on the Abis to support it, in order to minimise the risk of RSL congestion.
Also, the mux rule can be applied:
Per BTS (Only one signalling load is defined for the whole BTS. RSLs of different
sectors can be multiplexed).
Per Sector (A signalling load is defined for each sector of the BTS. RSLs of different
sectors cannot be multiplexed).
It is preferable to avoid the grouping of TRXs from different sectors in the same MCB, in
particular for cells with more than 4 TRXs, as this prevents the case of MCBs with more than
one BCCH. Of course, this solution is acceptable only if it is affordable in terms of Abis Time
Slots. This rule could be by passed for small cells (in order to avoid incomplete MCBs) but, in
this case, it is highly recommended to set the Signalling load (at BTS level) to High to avoid
MCBs with 3 or even 4 BCCHs.
MCB load
The OMC is not able to check the number of SDCCHs per Multiplexed Channel Block
(MCB). For this reason the following configuration rules should be verified to keep the
Signalling Flow for Statistical Multiplexing on 64 Kbps channel inside the capacity limit:
If mCCCH feature is not activated:
MCB signalling load = Number of SDCCH sub-channels in MCB
+ 4 x Number of combined BCCH in MCB
+ 8 x Number of non-combined BCCH in MCB.
Normal signalling load option with 4 FR TRX:
TRX 1 = 1 BCCH + 16 SDCCH + 5 TCH
TRX 2 = 16 SDCCH + 6 TCH
TRX 3 = 8 TCH
= > MCB load = 48 (sub-channels).
High signalling load option with 2 FR TRX:
TRX 1 = 1 BCCH + 16 SDCCH + 5 TCH
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
56 / 162
If mCCCH feature is activated:

MCB signalling load = Number of SDCCH sub-channels in MCB
+ 8 x Number of non-combined BCCH in MCB
+ 8 x Number of CCCH in MCB.
Normal signalling load option with 4 FR TRX:
TRX 1 = 1 BCCH + 8 SDCCH + 1 CCCH + 5 TCH
TRX 3 = 8 TCH
High signalling load option with 2 FR TRX:
TRX 1 = 1 BCCH + 8 SDCCH + 1 CCCH + 5 TCH
Method for RSL traffic assessment
LAPD efficiency (in DL):
Needed counters
Conter Type: 7
Measured Object: LAPD
Conter L1.1 (NB_LAPD_INFO_FRAME_SENT)
Number of Information frames transmitted on the LapD link,
excluding the re-transmissions.
Conter L1.15 (NB_LAPD_INFO_FRAME_RESENT)
Number of Information frames re-transmitted on the LapD link.
Formula:
LAPD efficiency [%] = L1.1/( L1.1+L1.15)*100
Method for RSL congestion
LAPD congestion detection:
Conter L1.18 (TIME_LAPD_CONG)
Conter Type: 7
Time in seconds during which the LapD link is congested in
transmission in the BSC.
In case LAPD congestion is present, the MCB load must be reduced:
If the multiplexing rule is applied per BTS by changing at BTS level the
signaling load from normal to high;
If the load is already high by changing the multiplexing rule from per BTS
to per Sector with the same load options normal or high.
Note: These changes may impact the Abis TS usage.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
57 / 162
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), signalling TS (RSL &
OML) and extra TS, a second Abis link can be attached to the BTS.
B
S
C
Primary Abis Link

OML RSL BT
BT
RSL BT
BT
RSL BT
BT
RSL BT
BT
ET
ET
ET
ET
ET
ET
ET
ET
ET
B
T
S
Secondary Abis Link

ET
BT : Basic Timeslot
ET
ET
ET : Extra T imeslots
Figure 33: Abis TS configuration on primary and secondary links
From B9 release:
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 more details, please refer to [2]
The extra TS can be mapped to the primary or the secondary Abis link.
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.
For BTS with more than 12 TRX (up to 24), because of Twin TRX usage, it is possible to
limit the number of TRX in the first Abis link.
Primary link
TRX 1 to 12
+ extra PS TS
BTS 24TRX
BSC
Secundary link
TRX 13 to 24
+ extra PS TS
Figure 34: BTS with 24 TRX mapped on both Abis links
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
58 / 162
The primary and secondary Abis links of a BTS can be on different Abis TSU of different
BSC racks.
BTS 1
12 TRX
BTS 1
16TRX
BSC
BTS 2
6 TRX
BTS 2
6TRX
BTS 1
4 TRX
Figure 35: Example of topology with two BTS chained
MAX_FR_TRE_PRIMARY = 12
Maximum filling of
first Abis link
Second A-bis
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
First A-bis
OML+RSL1-4
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
The 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.
Equal filling of the

two Abis links
Second A-bis
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
First A-bis
MAX_FR_TRE_PRIMARY = 8
OML+RSL1-4
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
or
Figure 36: Two Abis links filling examples.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
59 / 162
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 2nd 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
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
60 / 162
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 TS is based on:

Type of Abis Topology
Chain (Star) or Ring

TS0 mode
Static
number of
needed
Abis TSs
TS 0 usage or TS 0 transparency
Qmux usage
Used or Not used

Type of signalling 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
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).
Dynamic
number of
needed Abis
TSs
Various number of required GCH is based on

modulation & coding scheme (MCS or CS), please
refer to 3.4.4.2.3.
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
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
61 / 162
It is simple to define the number of needed Abis TSs for conditions of topology, TS0 mode,
Qmux usage, signalling sub-mux and number of TRX because each of them requires the
certain number of TSs.
The most complicated part of Abis dimensioning from 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: B9 with No GPRS/EDGE B10 with EDGE

In case of a B9 network without GPRS/EDGE going to B10 network with EDGE, the Abis
dimensioning should be performed only according to 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: B10 with EDGE

In case of B10 network with already EDGE, we can perform the Abis dimensioning based on
the counter measurement.
For this case, Abis dimensioning is not impacted by the migration from B9 to B10 release.
There are 2 different methods approaching the Abis dimensioning:
Method 1: Abis dimensioning based on PS traffic (bonus & extra Abis nibble traffic)
Target: To estimate the number of Extra Abis Timeslots needed at BTS level.
Gathered Counters:
Counter Name
Indicator Name
Definition
P466
GABGCHUSEBT
Cumulated time during which extra and bonus Abis nibbles are
used in the cell, cumulated over all extra and bonus Abis
nibbles.
P105i
GQRDTECBN
Number of DL establishment failures due to congestion of

Abis.
P105j
GQRUTECBN
Number of UL establishment failures due to congestion of

Abis.
P91a + P91b +
P91c + P91d +
P91e + P91f +
P505
GTRDTERQN
P62a + P62b +
P62c - P438c +
P507
GTRUTERQN
Table 18: Counter list - Abis dimensioning Method 1
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
62 / 162
Measured Object: BTS

Note: Busy Hour means the hour gives highest extra & bonus Abis nibble traffic (P466) of the day.
Methodology:
The process of Abis dimensioning is presented in Figure 37.
INPUT
METHOD
Required extra
& bonus Abis
nibble Traffic
OUTPUT
Nb of required
extra & bonus Abis
Nibbles
Erlang C
GoS:
% Quantile of x
delay sec
Nb of required
extra Abis Nibbles
Figure 37: Abis dimensioning process Method 1
INPUT
The required extra & bonus Abis traffic is computed as below formula.
Re quired _ extra & bonus _ Abis _ traffic =
Measured _ extra & bonus _ Abis _ traffic

1 Min(%TBF _ Abis _ cong , 30%)
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:
Measured _ extra & bonus _ Abis _ traffic =
P 466
3600
%TBF _ Abis _ cong = Max (%DL _ TBF _ Abis _ cong ,%UL _ TBF _ Abis _ cong )
Where:
%DL _ TBF _ Abis _ cong =
P105i
100%
P 91a + P 91b + P 91c + P 91d + P 91e + P 91f + P 505
%UL _ TBF _ Abis _ cong =
P105 j
100 %
P 62a + P 62b + P 62c P 438 c + P 507
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
63 / 162
The other input is Grade of Service (GoS), which is defined by % quantile of x delay
second (pABIS).
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 Operator.
On Abis interface, the recommended value is 99% quantile of 0.01 delay sec.
METHOD
Concerning only PS traffic, the statistical law Erlang C is used during the dimensioning
As extra & bonus Abis nibbles are associated to PS traffic only, Erlang C can be
applied to calculate the required number of extra & bonus Abis nibbles 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, pABIS)
However the number of bonus Abis nibbles is fixed according to the total number of
BCCH & SDCCH TS in the BTS; i.e. one BCCH (SDCCH) TS gives one bonus Abis
nibble.
Then,
Number of required extra Abis nibbles
= Number of required extra & bonus Abis nibbles Nbr 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:
% _ TBF _ Abis _ cong > 0,1%

Radio throughput reduction: a method for throughput degradation is under

study
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
64 / 162
Method 2: Abis dimensioning based on PS traffic (GCH traffic)

The main purpose of this method development is to provide Abis dimensioning based
on total 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.
The indicators usable to represent PS traffic at Abis level: GCH traffic.
Gathered Counters:
Counter Name
Indicator Name
Definition
P100c
GAAGCHUST
Cumulative time during which a GCH is busy in a cell. The

counter is integrated over all the GCH available in the cell.
P105i
GQRDTECBN
Number of DL establishment failures due to congestion of

Abis.
P105j
GQRUTECBN
Number of UL establishment failures due to congestion of

Abis.
P91a+P91b+P91c+
P91d+P91e+P91f+
+ P505
GTRDTERQN
P62a+P62b+P62c-P438c+P507
GTRUTERQN
Table 19: Counter list - Abis dimensioning Method 2.
Measured Object: BTS

Note: Busy Hour means the hour giving the highest PS traffic
(i.e.P100c) of the day.
Methodology:
INPUT
OUTPUT
METHOD
Nb of required
Abis Nibbles
Required Data
Traffic on Abis
Erlang C
GoS:
% Quantile of x
delay sec
Nb of required
extra Abis Nibbles
Nb of basic &
bonus Abis Nibbles
Figure 38: Abis dimensioning process Method 2
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
65 / 162
INPUT
The required GCH Abis traffic is computed as below formula.
Re quired _ GCH _ traffic =
Measured _ GCH _ traffic

1 Min(%TBF _ Abis _ cong , 30%)
Where:
Measured _ GCH _ traffic =
P100c
3600
%TBF _ Abis _ cong = Max (%DL _ TBF _ Abis _ cong ,%UL _ TBF _ Abis _ cong )
Where:
%DL _ TBF _ Abis _ cong =
P105i
100%
P 91a + P 91b + P 91c + P 91d + P 91e + P 91f + P 505
%UL _ TBF _ Abis _ cong =
P105 j
100 %
P 62a + P 62b + P 62c P 438 c + P 507
The other input is Grade of Service (GoS), which is defined by % quantile of x delay
second (pABIS).
The recommended value is the same as for previous method.
METHOD
As GCH Abis nibbles are associated to PS traffic only, Erlang C can be applied to
calculate the required number of GCH Abis nibbles according to required PS traffic and
% quantile of delay time.
OUTPUT
Number of required Abis nibbles

= Erlang C (Required_GCH_traffic, pABIS)
However the number of bonus Abis nibbles is fixed according to the total number of
BCCH & SDCCH TS in the BTS; i.e. one BCCH (SDCCH) TS gives one bonus Abis
nibble.
Number of basic nibbles per cell can be equal to MAX_PDCH if busy hour for PS
traffic differs from busy hour for CS traffic, or to MAX_PDCH_HIGH_LOAD
(recommended value) if the two busy hours coincide.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
66 / 162
Then,
Number of required extra Abis nibbles

= Number of required Abis nibbles Nbr of basic&bonus Abis nibbles
And
Number of required extra Abis TS

= Roundup [Number of required extra Abis nibbles / 4]
Remark: 1 Abis TS contains 4 Abis nibble
Comments on two methods for Abis dimensioning:
Method 1:
This method is recommended in case of BTSs with 2 or more cells.
In such cases, only bonus and extra Abis nibbles available are shared for PS traffic at
BTS level. The basic nibbles are shared only at cell level.
Method 2:
This method is recommended in case of BTSs with only 1 cell.
In such cases, all the basic and bonus Abis nibbles available toghether with extra Abis
nibbles are used for the cell PS traffic.
Finally, for a complete Abis dimensioning process, based on results for Cell and Extra
Abis TS evaluations, we have to compute the total number of Abis TS needed:
Total Number of Abis TS =

= 2*Total nb of TRX +
+ Nb of TS for RSL and OML (depending on MCB type)
+ Nb of required Extra Abis TS,
and
Number of required Abis Links =

= Roundup[(Total Number of Abis Ts)/31].
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
67 / 162
3.3 BSC
Two generation of BSC are supported in B9:
G2 BSC
Mx BSC, also called A9130 BSC or 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.
Group Switch
8 Planes
2 Stages
self-routing, non-blocking
Abis TSU
6 E1
TCUC
Ater TSU
TCUC
6x
G.703
Abis
I/F
BIUA
DTCC
TCUC
DTCC
TCUC
DTCC
TCUC
DTCC
TCUC
DTCC
TCUC
DTCC
AS
TCUC
TSL
2 E1
DTCC
AS
ASMB
ASMB
2x
G.703
Ater
muxed
I/F
DTCC
Q1 bus
AS
TSCA
CPRC CPRC CPRC CPRC CPRC CPRC CPRC CPRC
Broadcast bus
Common Functions TSU
Figure 39: G2 BSC (A9120 BSC) Architecture
From Figure 39, the BSC is basically divided in three building blocks:
1) Abis TSU: For Abis interface management functions towards the Base
Stations (BTS), see details in section 3.3.1.2
2) Ater TSU: For Ater interface management functions towards the Core
Network (Circuit and Packet), see details in section 3.3.1.3
3) Common TSU: For all central functions of the equipment;
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
68 / 162
3.3.1.1 BSC Capacity

The following figure presents the cabinet layout of maximum BSC configuration. The smaller
configurations consist of fewer racks or half filled racks.
Figure 40: G2 BSC Cabinet layout
In release B10, six types of G2 BSC configurations are offered:

G2 BSC (A9120 BSC)
Capacity
FR
DR
Nb TRX
Nb of TSU
Nb of E1
Erlang Traffic
Nb Cell
Nb BTS
Nb GPU
Nb SS7 links
Nb CICs
Abis TSU
Ater TSU
Abis
Ater (CS&PS)
on A interface (1:4 Mux)
Configuration
Config 1 Config 2 Config 3 Config 4 Config 5 Config 6
32
128
192
288
352
448
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
1
4
6
9
11
14
2
3
5
6
8
9
6
24
36
54
66
84
4
6
10
12
16
18
160
627
1074
1300
1700
1900
Table 20: G2 BSC Capacity
For different G2 BSC config type, the max number of ExtraAbisTS which can be configured is
different due to fact that ExtraAbisTS must be mapped to FR TCU only, and max 8 EXTS mapped per
TCU are allowed.
G2 BSC
Config.1
Config.2
Config.3
Config.4
Config.5
Config.6
TCU number
32
48
72
88
112
Max EXTS
51
205
307
461
563
717
N.B. It is recommended to limit the BSC load in terms of FR TRXeq to 80%, being FR TRXeq defined as:
FR _ TRXeq = FR _ TRX + 2 DR _ TRX +
N _ EXTRA _ ABIS _ TSallBTS

2
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
69 / 162
3.3.1.2 Abis TSU

The Abis TSU is a functional entity terminating the interfaces carrying the speech/data traffic
and signalling to and from the BTS. It includes the following boards:
Figure 41: Abis TSU G2 BSC
1 BIUA: Base Station Interface Unit type A

BIUA is sub-multiplexing 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 signalling links LAPD (i.e. RSL, OML and TSL) that
allows:
4 RSL+ 2 OML
3 RSL+ 3 OML
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
70 / 162
For the TSL/TCU mapping is fixed as shown in next table:

TSL links G2 BSC
TSL 1 (first rack)
TSL 2 (second rack)
TSL 3 (third rack)
BIUA number
(BSC-Adapt SBL nbr)
TCU number
1
6
11
1
41
81
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 Signalling Multiplexing
(Static or Statistical 16kbps) each TRX can carry 8 SDCCH channels maximum.
Each TCUC will respect the rule CCCH (BCCH) TS +SDCCH TS <= 4 TS when mCCCH
feature is enabled (one CCCH TS equal to one SDCCH TS in terms of signalling load).
One TCUC shall not handle more than 2 BCCH in case of GPRS cell, this rule is a
warning but the SW does not check it.
For 16K Static multiplexing, all RSLs of a given 64kbps 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 signalling multiplexing and not multiplexed signalling 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]
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
71 / 162
3.3.1.3 Ater TSU

The Ater TSU is a functional entity terminating the interfaces to and from the Transcoder
and/or the MFS.
It includes the following boards:
2
ASMB:
providing
multiplexing 16kbps 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 42: 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 signalling 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 Mx BSC (A9130) 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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
72 / 162
TPW
TPr
MUXr
CCP1
SSWW
Radio Network links
MUXW
SSW
E1
CCPy
LIU1
OMCPw
OMCPr
LIUn
LIU Shelf
ATCA Shelf (14 slots)
(21 slots)
External Ethernet Links
r
W
n and y
: Redundancy
: Working
: Network Element Capacity
Figure 43: 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 TRX.
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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
73 / 162
3.3.2.1 BSC Capacity

In release B10, five configurations of BSC Evolution are offered:
Configuration
Mx BSC
200 TRX
Mx BSC
400 TRX
Mx BSC
600 TRX
Mx BSC
800 TRX
Mx BSC
1000 TRX
Nbr of CCP boards
Nbr VTCU
50
100
150
200
250
Nbr VDTC CS
40
80
120
160
192
Nbr VDTC PS
24
48
72
96
112
Nbr of LIU boards
14
15
16
TRX
200
400
600
800
1000
Cells
200
400
500
500
500
BTS
150
255
255
255
255
Abis links
96
96
176
176
176
Ater CS
10
20
30
40 (*)
46 (*)
Ater PS
12
18
24
28
Erlang
900
1800
2700
3600
4500 (**)
BHCA
64 800
129 600
194 400
259 200
324 000
Nbr Extra Abis TS
2000
2000
2000
2000
2000
SS7 (load @ 40%)
8 LSL
16 LSL
HSL
HSL
HSL
SS7 (load @ 60%)
6 LSL
11 LSL
16 LSL
HSL
HSL
Data in this table, based on [1] and [11]
Table 22: BSC Evolution Capacity

Note: (*) In B10 MR1, the number of Ater CS is limited to 36 interfaces.
(**) In B10 MR1, a software limitation allows a capacity of 4000Erl and 288000 BHCA per BSC.
It is recommended to limit the BSC load to 95% of its maximal capacity
The BSC capacity is defined with the FR TRXeq parameter that is defined by the formula:
TRX = FR _ TRXeq = FR _ TRX + 2 DR _ TRX
When the Optimized HR connectivity feature is enabled, the TRX calculation become:
TRX = FR _ TRX + DR _ TRX
Note: In Mx BSC, the HDLC channel (High Level Data Link) transports the signalling link (OML
and/or RSL) of the BTS on a 64kbps Abis timeslot.
One HDLC channel is used per LAPD link (if 16K Statistical Signaling Multiplexing or No
Multiplexing mode is applied) or per group of multiplexed RSL and OML (i.e. when 16K Static
or 64K Statistical Signaling Multiplexing mode is applied).
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
74 / 162
Independently to the Mx BSC configuration, the TPGSMv1 board has a signalling limitation
of 512 HDLC channels, among which 441 are available for Abis signalling (RSL+OML).
Due to this limitation, an Mx BSC is not able to achieve the capacity of 1000 TRX in case a
lot of DR TREs are configured for that BSS.
With a normal signalling load, a HDLC channel handles 2 DR TRX or 4 FR TRX
=> 882 DR TRX per BSC
With a high signalling load, a HDLC channel handles 1 DR TRX or 2 FR TRX
=> 441 DR TRX or 882 FR TRX per BSC
In order to reach the maximal load of TRX supported by Mx BSC, it is recommended to use
largely the 64K Statistical Multiplexing RSL mode.
In B10 MR2, the BSC performances are improved with the introduction of new TPGSMv3
board. This board allows a capacity of 1024 HDLC channels (984 channels are available for
RSL and OML).
3.3.2.2 Delta BSC Evolution versus G2 BSC

Different Behaviors:
Same Behaviors
TSU is removed
No change in logical model of the BSC
Higher capacity: 1000 TRX / 500 cells
4500erl and SS7 High Speed Link
No change in radio configuration

mechanisms
No need of TCU to support extra Abis TS
Same set of radio parameters
Removal of HR connectivity constraints
Same set of PM counters/indicators as

A9120 BSC
Abis/Ater fixed mapping to LIU boards
Ater optimization
For more details, please refer to [1]
3.3.2.3 TP GSM board

TP GSM Transmission Processing board (JBXTP/JBXTP3) provides telecom transmission/
transport interfaces to the MX platform. There is one active and one redundant TP board and
per sub-rack (i.e per BSC) whatever the configuration.
BSS B10 MR1 only supports JBXTP (TPGSM V1).
BSS B10 from B10MR2 onwards supports both JBXTP and JBXTP3 (TPGSM V3).
Mx BSC supports only 512 HDLC with TP V1 (441 available for Abis LAPD) and
1024 HDLC with TP V3 (984 HDLC available for Abis LAPD).
Note: JBXTP3, also called TP-STM1 is ready for STM-1 and IPoE1, but these functions will
only be supported in a later release. For IPoE1 a daughterboard (JAXIP) is needed which can
only be added by upgrade in factory.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
75 / 162
3.3.2.4 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
signalling 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
boards 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 signalling
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 signalling 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.
Finally with the optional Optimized HR connectivity, the mapping constraints of DR TRX
are removed allowing full TRX connectivity at TCU level.
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
With Optimized HR connectivity, TCU handle 4 FR and/or DR RSL

TCU can handle maximum of 3 OMLs.
7 LAPD per VTCU (for G2 BSC the limit is 6 LAPD per TCUC)
With these rules up to 200 TREs can be mapped on a CCP.

It shall be always possible to map up to four TREs (FR and/or DR) per VTCU.
The maximum number of TCH a CCP can handle shall be limited to MAX_TCH_PER_CCP,
parameter which is currently set to 1000 TCH sub-channels.
When the limit of MAX_TCH_PER_CCP parameter is reached, the TCH channels are
rejected.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
76 / 162
The MC926 counter (TCH_Blocking_Occurrences_BSC) permits to detects the number of

rejected TCH if the CCP has reached its maximum processing capacity.
To avoid having unbalanced load between the CCP boards, it is requested to have a remapbts-on-ccp command at the OMC-R to spread the load between the CCPs boards.
3.3.2.5 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.
LIU 11
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
400
LIU 9 LIU 10
129
145
130
145
131
147
132
148
133
149
134
150
135
151
136
152
137
153
138
154
139
155
140
156
141
157
142
158
143
159
144
160
400
LIU 8
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
1000 TRX
800 TRX
600 TRX
400 TRX
200 TRX
LIU 12 LIU 13 LIU 14 LIU 15 LIU 16
69
59
21
2
1
70
60
22
4
3
71
61
23
6
5
72
62
24
8
7
73
63
25
10
9
74
64
26
12
11
75
65
27
14
13
76
66
28
16
15
x
67
29
18
17
x
68
30
20
19
x
54
48
42
41
x
53
47
40
39
58
52
46
38
37
57
51
45
36
35
56
50
44
34
33
55
49
43
32
31
200
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
1000 TRX
800 TRX
600 TRX
400 TRX
200 TRX
LIU 1 LIU 2 LIU 3 LIU 4 LIU 5 LIU 6 LIU 7
1
17
33
49
65
81
97
2
18
34
50
66
82
98
3
19
35
51
67
83
99
4
20
36
52
68
84
100
5
21
37
53
69
85
101
6
22
38
54
70
86
102
7
23
39
55
71
87
103
8
24
40
56
72
88
104
9
25
41
57
73
89
105
10
26
42
58
74
90
106
11
27
43
59
75
91
107
12
28
44
60
76
92
108
13
29
45
61
77
93
109
14
30
46
62
78
94
110
15
31
47
63
79
95
111
16
32
48
64
80
96
112
200
The Abis/Ater allocation and mapping realized by LIU boards is fixed and it is shown in
Figure 44.
Ater Ports
Abis ports
Abis ports (max 176)

Ater CS (max 48): BSC Atermux numbers 1-30,59-76
Ater PS (max 28): BSC Atermux numbers 31-58
Figure 44: Abis and Ater allocation on LIU boards / BSC capacity
3.3.2.6 SS7 transport

For BSC Evolution there are two options for the SS7 transport in B10:
LSL (Low Speed Links):

SS7 channels on 16 * 64 kbps TS
Available with BSC G2 and BSC Evolution
HSL (High Speed Links):

SS7 channels on 2 * 2Mbps links (for redundancy purpose, the 2 links are
required whatever the traffic is).
If more than 16 SS7 channels are needed.
Available only with BSC Evolution.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
77 / 162
3.3.2.7 HSL usage

The use of HSL is optional and may be used if this option is supported by the MSC. It is
the choice of the operator to decide whether the HSL links are used. The HSL can be used
on any MX BSC configuration type (whatever the number of Erlangs supported by the
MX BSC). The selection of the mode of operation (LSL or HSL) is exclusive (mixed
mode are not allowed).
In case HSL is not used, the capacity of the MX BSC is limited to approximately 3000
Erlangs via the overload mechanisms on the A interface. This maximum number of
Erlangs depends in fact of the maximum load on A interface we want to accept. 3000
Erlangs corresponds to a load of approximately 63 % on the A interface.
The migration from SS7 link with 16 * 64 Kbit/s time slots to SS7 link with 1.984 Mbit/s
links will be done with interruption of service (i.e. the on-going traffic is lost when the
migration is started).
The subset of MTP Level 2 and Level 3 requirements supported by the BSS is compliant
with 3GPP TS 48.006 (Rel-6). The implementation of MTP Level 2 is compliant with
ITU-T Q.703 (white book - 07/96). The implementation of MTP Level 2 for supporting
HSL links is compliant with ITU-T Q.703 Annex A (white book - 07/96). The
implementation of MTP Level 3 is compliant with ITU-T Q.704 (white book - 07/96).
MxBSC HSL configurations requirements:

The HSL can be used on any MX BSC configuration type (whatever the number of
Erlangs supported by the MX BSC).
Introduction of HSL (High Speed Signaling Link):
The HSL links are physically connected on two LIU ports, corresponding to Atermux CS;
The Atermux for HSL are directly cabled to MSC;
These two links will work on load sharing mode, not active/standby mode.
Mixed mode (LSL+HSL) is not allowed;
There is no Qmux configured on the Atermux for HSL
Any Atermux defined in the BSC configuration could be used to support HSL.
The BSC checks that these two Atermux:
Do not carry Qmux (Atermux 1 and 2, Atermux 7 and 8, )
Are configured for CS traffic only,
Are on two different LIU boards, and each LIU boards must be available in BSC.
HSL is always defined on the first Atrunk of the selected Atermux.

Feature activation prerequisite conditions
Parameter in OMC-R - EN_HSL - to activate/deactivate HSL.
LSL to HSL mode change is possible only if the operator has cabled direct PCM links
between the MSC and the BSC LIU.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
78 / 162
From BSC Terminal
Step1: Install the high speed links
Step2: Execute the command HSL_Activate giving as input the Atermux number for
HSL.
If HSL is actived, N7 can have 2 different frame formats:
Normal frame format (MSU contains 6 bytes as fix part + SIF&SIO as variable part).
Extended frame format (MSU contains 9 bytes as fix part + SIF&SIO as variable part).
Parameter: MTP_Sequence_Number_Format
Range / default value: (0 = Normal, 1 = Extended) / 0.
The MxBSC is supporting both formats. Extended format may not be used if HSL is not
activated.
To be checked which format is supported by MSC.

Important: HSL Connection must be supported at NSS level too.
The Alcatel-Lucent MSC version supporting the HSL feature:
RCP A8362M + Umax EP6 or above
NGN release W4.21
HSL impact on AterMux CS:

The MxBSC in 1000TRX configuration may have up to 46 AterMux CS [130],
[6176].
Atermux n59 and n60 cannot be used for CS traffic because only the Atermux n1&n2
mod(6) can be recognized as carrying Qmux and be the 1st of a cluster (TC constraint).
In the case of 1000 TRX Mx BSC, the Atermux n59 and n60 can therefore be used for
HSL or PS traffic.
So, the max number of AterMux CS is reduced to 45 links if one of Atermux n59 and 60
is used for HSL or to 44 links if other ports, except n59 and n60, are used for HSL.
Since B10 MR2 there is the possibility to have CS traffic on TS15/TS16 on AterMux CS
links in case of HSL usage.
Depending on the conditions (TC board type, N7 configuration), the MxBSC automatically
opens TS15/TS16 for traffic. This principle is valid for any Ater CS.
Regarding TC board:
- TS15 is ok for traffic from MT120 on (ie legacy MT120, MT120-WB, MT120-NB);
- TS16 is ok for traffic on new MT120 (MT120-WB, MT120-NB).
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
79 / 162
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 principle 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:
BTS inputs
BSC inputs
Architecture Constraints
Configurations
Software release
Access transmissionNetwork topology
Location
Available configurations
Core transmission network topology
BSC dimensioning process

Definition
Definition of
of sets
sets of
of BTSs
BTSs (BSC
(BSC Ar
Area
ea))
satisfying
satisfying th
thee archi
architectur
tecturee constraints
constraints
For
For each
each BSC
BSC ar
area,
ea, choose
choose a
a BSC
B SC
configuration
configuration
Check
Check BSC
BSC border
border with
with RNP
RNP tteam
eam
OK
OK ??
No
No
Yes
Yes
Check
Check Abis conn
connectivity
ectivity
OK
OK ??
Yes
Yes
No
No
No
No
Choose
SC configura
Choose an
an oth
other
er B
BSC
configuration,
tion,
if
if possibl
possiblee ??
Yes
Yes
Check
Check At
Ater
er connectivity
connec tivity
OK
OK ??
No
No
Yes
Yes
Outputs
BSC configurations
BSC Areas
Figure 45: BSC dimensioning process
In Figure 45, basically the BSC dimensioning consists of two following parts:
Design BSC area
Parenting Abis TSU ports of the BSC
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
80 / 162
3.3.3.1 Design BSC area

As the design of BSC area is mainly based on the BTS and Transmission 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
The 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 2nd Abis link) gives
the TRX & Abis load that this BTS will have at BSC level.
Figure 46: BTS position & configuration design BSC area step 1
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
81 / 162
2) Get transmission planning & BSC positions

Then, the transmission plan is gathered to allow & verify BTS physical connection to
BSC planned location (several BSCs may be colocalised).
Figure 47: 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 G2 BSC level, to allow future
network extensions.
Figure 48: BSC area definition design BSC area step 3
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
82 / 162
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 number of E1 links, which will be implemented in the network.
This task is usually performed by the Transmission team.
Figure 49: 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 MxBSC, no explicit BTS/Abis parenting is needed: just LIU shelf engineering rules
for Abis ports allocation, described in section 3.3.2.5, must be respected.
It is highly recommended to have an evenly spread load on each Abis TSU 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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
83 / 162
Figure 50: BTS / Abis parenting on BSC done by AMT.NET
In case of MxBSC, the BTS and Abis parenting to AbisTSU has no meaning.
It is a different way compared with G2 BSC.
It is allowed to connect an Abis link to any LIU (E1) port, and the RSL & OML mapping
to VTCU is done automatically.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
84 / 162
3.3.4 LA Dimensioning
3.3.4.1 LA Definition and Capacity
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 update has an
effect on the load on the signalling sub-channels, 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:
Counter Name
Indicator Name
Definition
MC8a
GCCPGRQN
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 counters 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.
Methodology:
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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
85 / 162
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 recommendation
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;
5 PCH blocks/Multiframe * (3600s / 235 ms) = 76,595 PCH / hour
2.5 paging/Block x 76,595 Blocks = 191,489 paging/hour (100%load)
114,893 paging/hour
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
86 / 162
Um interface Limitation Cells with 2 CCCH (mCCCH feature

activated)
There are 9 CCCH blocks per 51 Multiframe for each of the two timeslots for CCCH.
Therefore;
If BS_AG_BLKS_RES = 4 (4 AGCH blocks per multiframe as default configuration),
then there are 18 2*4 = 10 PCH blocks per cell.
10 PCH blocks/Multiframe * (3600s / 235 ms) = 153,190 PCH / hour
2.5 paging/Block x 153,190 Blocks = 382,975 paging/hour (100%load)
229,785 paging/hour
When two CCCH TS are devoted to the cell, the Um paging capacity is then the double
of the previous calculated value (almost 64 paging/s).
Only cells with the mCCCH capability offer such paging capacity, and only if the whole
LA is with cells having two-ccch configuration.
In addition, only one RSL is considered as enough to carry this paging load over the
Abis interface (it is recommended to used 64K statistic multiplexing).
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:
118,800 paging/hour
When mCCCH feature is enabled, the paging load on Abis is also doubled and
corresponds to 66 paging commands per second, or
237,600 paging/hour
G2 BSC Limitation
The BSC limit is 70 paging/sec on the A interface (Alcatel traffic model).
252,000 paging/hour
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
87 / 162
Mx BSC Limitation
The BSC limit is 120 paging/sec on the A interface, for BSC in configuration with 5+1
CCP boards / 1000TRX (Alcatel traffic model).
432,000 paging/hour
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
45957 pagings/hour if aLA contains at least one combined cell, or is 114893 pagings/hour if the
Location Area contains only non-combined cells (in case of G2 BSC).
This conclusion holds true as long as there are max 5 LAs (resp. 9 LAs) covered by the G2 BSC
(resp. Mx BSC), which should always be the case but it worst to mention it.
In case of non-combined cells, 2 LAs may be covered by one G2 BSC (252000/114893 = 2.19)
and 4 LAs are required by one Mx BSC (432000/114893 = 3.76).
Assessment:
Below figure shows the LA dimensioning assessment (for G2 BSC).
Check BSC Limitation
No
Yes
Total MC8a > 252000

(Total MC8a of all LA in the BSC)
Re-Design LA, and/or

Reduce nb of LA per BSC
Check Um Limitation
Yes
No
All Cells in a LA are non-combined
No
No
Yes
MC8a > 45,957
OK
Yes
MC8a > 114893
Change to non-combined
Re-Design LA
OK
Re-Design LA
Figure 51: LA dimensioning assessment
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
88 / 162
In Figure 51, the assessment is to perform checking measured paging traffic versus the
paging limitation at the different levels:
BSC limitation
Um limitation
It is not significant to check Abis limitation, because Um limitation is lower than the
Abis one. 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 LA.
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 52: Subdivision of a LA in GPRS routing areas (RA)
Target: To estimate the number of RA per LA.

Gathered Counters:
Counter Name
Indicator Name
Definition
P53a
GTRPCHPAN
Number of (BSCGP) PAGING REQUEST for PS paging sent to

the MS (through the BSC which manages the PCH resource).
MC8a
GCCPGRQN
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).
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
89 / 162
Measured Object:
Cell
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, the 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 splitting RA into several RAs for a corresponding LA (one LA:
several RA).
Assessment:
The limited GPRS paging load ratio can be modified.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
90 / 162
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 within G2 BSC:
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
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 redimensioning. 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.
Note: P53a = PS paging while MC8a = total Paging (CS&PS).
Example:
If there is one LA which has one RA (LA size = RA size), and at busy hour:
MC8A = 120,000
P53a = 36,000
Only non-combined cells are present in the LA. Then for G2 BSC dimensioning:
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 splitting
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%
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
91 / 162
3.3.7 CCCH dimensioning

With the introduction of mCCCH feature, the dimensioning of CCCH should be updated.
In one hand, the number of messages (i.e. capacity) is deduced from the available AGCH and
PCH blocks as detailed in LA dimensioning.
In the other hand, the requested AGCH and PCH blocks are deduced from the number of
messages per second.
The following table gives an indication about the offered capacity in terms of Paging and
Immediate Assignment messages according to the number and configuration of CCCH TS.
Nb CCCH TS BS_AG_BLKS_RES PCH blocks
1
1
1
2
2
2
2
3
4
5
3
4
5
6
6
5
4
12
10
8
6
AGCH blocks Max paging/s Max assign/s

at 60% load
at 60% load
3
38
7
4
32
10
5
25
12
6
76
15
8
63
20
10
51
25
12
38
31
If not all cells in LAC are with mCCCH activated, the paging capacity is like in cells with
single CCCH.
However for AGCH, the capacity in cells with mCCCH should be greater.
The needed number of PCH blocks is defined by Nb_Needed_PCH_Blocks, while the needed
number of AGCH blocks is defined by BS_AG_BLKS_RES=N2.
The need of a second CCCH is also related to the AGCH and PCH loads.
When the nominal cell load is higher than 60%, a re-dimensioning of the CCCH channel is
required or a second CCCH channel shall be allocated to that cell.
Counter Name
Indicator Name
Definition
(MC8B + MC8D) / (N2

* 3600 / 0.240)
GCCIARQO
Load on AGCH logical channel(s) in case of fixed AGCH

configuration
(MC8A / N4) / ((N3

N2) * 3600 / 0.240)
GCCPGRQO
Load on PCH logical channel(s) in case of fixed AGCH

configuration
N2 = 1 (combined mode) or 4 (non-combined mode)

N3 = 3 (combined BCCH mode) or 9 (non-combined BCCH mode)
N4 = average number of mobile identity sent within one PAGING REQUEST message:
N4 = 3 if Paging is performed using TMSI
N4 = 1.5 if Paging is performed using IMSI
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
92 / 162
Important notes for relation between paging rate at BSC level and CCCH configuration at cell
level:
There is no relationship between the BSC paging mechanism and CCCH
configuration.
The BSC has just the task of broadcasting paging messages per LAC.
If paging coming from MSC has a high rate, the BSC will send on Abis paging
commands at high speed, ignoring the fact that some cells are not able to send
it.
As a consequence, some paging commands shall be discarded by cells with
less radio capacity compared with BSC capacity for sending paging on Abis.
The Paging load must be assessed during busy hour.
If the paging rate on Abis doesnt exceed 33 paging/s, cells with 1 CCCH TS
may be used without loses.
If the paging rate is higher (up to 66 paging/s), all the cells in LAC should be
configured with 2 CCCH TS, to avoid paging messages to be discarded.
If the paging rate per LAC is higher than 66 paging/s, the LAC should be split.
New counters for CCCH assessment are available in B10:
MC925a = NB_AGCH_USEFUL_BLOCKS_SENT
MC925b = NB_PCH_USEFUL_BLOCKS_SENT
MC925c = NB_BUSY_RACH_SLOTS
MC925d = NB_CHANNEL_RQ_RADIO
MC925e = NB_ASSIGN_CMD_RECEIVED_ABIS
MC925f = NB_ASSIGN_CMD_DISCARDED
MC925g = NB_PAGING_CMD_RECEIVED_ABIS
MC925h = NB_PAGING_CMD_DISCARDED
MC930 = NB_ABIS_PAGING_MESSAGE_RECEIVED
The counter MC925f (resp. MC925h) may be recommended to follow the number of
Immediat Assignement (resp. Paging Command) received by the BTS on Abis and discarded
due to congestion.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
93 / 162
3.4 AterMUX and A interfaces

3.4.1 General
3.4.1.1 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 64kbps timeslot transmits information for 4 Circuit Switch
calls (whatever they use FR or HR codec).
On the AterMUX PS interface, a 64kbps timeslot supports 4 GCHs.
3.4.1.2 A interface
The A-interface is a set of 2Mbps PCM links carrying CS traffic between the TC and the
MSC.
One 64kbps channel on A interface is corresponding to one 16kbps channel on AterMUX.
3.4.1.3 AterMUX interface versus A interface
BSC
TC
AterMUX
MSC
Figure 53: 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:
N AterMUX CS Links 4*N A Links
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
94 / 162
3.4.2 AterMUX configuration

The AterMUX interface is supported by 2Mbps PCM links (64kpbs * 32 TS) with the
structure as shown below.
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
AterMUX CS
CH# 1
CH# 2
CH# 3
CH# 4
TS 0 Transparency
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
Qmux
TCH
TCH
TCH
Alarm octet
SS7
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
X25
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
AterMUX PS
CH# 1
CH# 2
CH# 3
CH# 4
TS 0 Transparency
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
Alarm octet
SS7 (not used)
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GSL
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
Figure 54: AterMUX interface structure
In Figure 54, 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
Signalling Channels: 5 types of signalling

Qmux: In A9120 BSC, there is one sub-channel (on timeslot 14) on the first two Ater
links (links N 1, 2, 7, 8, 13 & 14) that is dedicated to the Qmux protocol. Three
other sub-channels are used for TCH.
In A9130 BSC, there is one sub-channels (on timeslot 14) on the Ater links
N1, 7, 13, 19, 25 and 2, 8, 14, 20, 26 that is dedicated to the Qmux protocol.
The three other sub-channels are used for TCH.
Alarm octet: reporting technical hitches on any DTC so it must be conveyed on each
PCM of each Ater TSU.
SS7:
carrying the signalling 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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
95 / 162
O&M: In A9120 BSC, two additional time slots (TS31 on Ater links n1 & 2) must be
dedicated to O&M link from the BSC to the OMC-R if X.25 connection is used.
In A9130 BSC, the O&M information is transported to the OMC, with IP over
Ater, using the TS31 of the AterMUX 1 to N.
GSL: It handles signalling for GPRS paging and for all synchronization between the
BSC and the MFS (TS 28). Each GP(U) 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 recommended to have at least 2 GSL channels per GP(U).
3.4.2.1 AterMUX CS and A interfaces

AterMUX CS:
Referring to AterMUX CS structure (in Figure 54), the following figure presents the
AterMUX CS configurations that depend on the G2 BSC configuration.
A te r T S U 1
B SC R ack 1
A te r T S U 2
A te r T S U 3
A te r T S U 4
B SC R ack 2
A te r T S U 5
A te r T S U 6
P
P
P
P
P
P
CM
CM
CM
CM
CM
CM
1
2
1
2
1
2
P
P
P
P
P
P
CM
CM
CM
CM
CM
CM
1
2
1
2
1
2
P
P
P
P
P
P
CM
CM
CM
CM
CM
CM
1
2
1
2
1
2
X 25
(x)
(x)
Qmux
x
x
A l a rm
x
x
x
x
x
x
SS7
x
x
x
x
x
x
T C H N um b e r
111
111
116
116
116
116
X 25
Qmux
x
x
A l a rm
x
x
x
x
x
x
SS7
x
x
x
x
x
x
115
115
116
116
116
116
Qmux
x
x
A l a rm
x
x
x
x
x
x
SS7
x
x
x
x
X 25
A te r T S U 7
B SC R ack 3
A te r T S U 8
A te r T S U 9
115
115
116
116
116
116
T o ta l T C H
20 7 4
Figure 55: AterMUX CS interface configuration G2 BSC
In Figure 55, the number of TCHs is different for each AterMUX link as it depends
on the appearance of signalling 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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
96 / 162
G2 BSC
Configuration 1
Nb of Ater TSU
Max nb of AterMUX CS
Configuration 2
Configuration 3
10
Configuration 4
12
Configuration 5
16
18
Configuration 6
Table 25: Max number of AterMUX CS interfaces G2 BSC
For BSC Evolution, the maximum number of AterMUX links for CS traffic (from
BSC to TC) is 48 and are addressed by Ater-Hway-TP in the range [1-30] and [5976]. These links may be used for PS traffic also.
A-interface:
The channel mapping between AterMUX CS interface and A-interface is presented
below:
TS 0
TS 1
TS 2
:
:
TS 14
TS 15
TS 16
TS 17
TS 18
:
:
TS 30
TS 31
A Interface
AterMUX CS
CH# 1
CH# 2
CH# 3
CH# 4
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
:
:
Qmux
TCH
Alarm octet
SS7
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
:
:
TCH
TCH
TCH
TS 0
TS 1
TS 2
TS 3
TS 4
TS 5
:
:
:
:
:
:
:
TS 30
TS 31
TCH
X25
TS : 64 Kbits/sec
Channel or Nibble : 16 Kbits/sec
CIC 1
CIC 2
CIC 3
CIC 4
CIC 5
:
:
:
:
:
:
:
CIC 30
CIC 31
TS : 64 Kbits/sec
Figure 56: Channel mapping between AterMUX CS and A
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
97 / 162
A 64kbps channel on A interface is known as CIC (Circuit Identification Code).

Each 16kbps TCH of AterMUX CS is mapped on one 64kbps CIC of A-interface.
So, one AterMUX CS link requires four A-interfaces to complete the channel
mapping.
The Table 26 presents the maximum number of A-interfaces in case of G2 BSC.
G2 BSC
Configuration 1
Nb of Ater TSU
Max nb of AterMUX CS
Max nb of A
16
Configuration 2
24
Configuration 3
Configuration 4
10
40
12
48
Configuration 5
Configuration 6
16
64
18
72
Table 26: Max number of A-interfaces G2 BSC
3.4.2.2 AterMUX PS
Referring to AterMUX PS structure (Figure 54), the following figure presents an example of
AterMUX PS configuration for a GPU.
One GPU
PCM 1
PCM 2
PCM 3
PCM 4
PCM 5
GSL
x
(x)
Alarm
x
x
x
x
x
SS 7
x
x
x
x
x
GCH Number
112
112
116
116
116
Total GCH
572
Figure 57: 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. 1560 GCH (a GP 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
1960 GCH)
Note: The max capacity of 5 AterMUX PS is 572 GCH, which is enough to support
480 GCH refer to Figure 54
At least one GSL is required for a GP(U), but it is recommended to have 2 GSLs per
GP(U) as the security reason is concerned
Maximum 1 GSL is possible for an AterMUX PCM link (TS 28)
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
98 / 162
For G2 BSC, the maximum number of AterMUX PS (BSC-MFS) is dependent on BSC

configuration as shown in Table 27.
G2 BSC
Max nb of AterMUX PS
Configuration 1
Configuration 2
Configuration 3
10
Configuration 4
12
Configuration 5
16
Configuration 6
18
Table 27: Max number of AterMUX PS G2 BSC
For BSC Evolution, the maximum number of AterMUX links dedicated for PS traffic (from
BSC only to MFS) is 28 and they are addressed by Ater-Hway-TP from 31 to 58.
3.4.2.3 AterMUX CS/PS

The following information describes GPRS and GSM traffic on the AterMUX of the BSS .
Sharing AterMUX PCM Links
TC
Y
BSC
GPU
(MFS)
SGSN
Figure 58: Sharing AterMUX links

From Figure 58:
- X is the number of AterMUX between BSC and GP(U).

- Y is the number of AterMUX between GP(U) and TC.
- Z is the number of Gb between GP(U) and SGSN.
Rule of sharing AterMUX Link:
1) X+Y+Z <= Maximum nb of E1 links

2) When the AterMUX transports mixed traffic: X=Y
The maximum number of E1 links depends on the BSC/MFS platform and can be
summarised in the following way:
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
99 / 162
For legacy MFS: 16 E1 links
For Mx MFS: 10/12/14/16 E1 links 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 28.
Nb of TCH
PS
Full
CS
116
Null
Nb of GCH
0
7/8
3/4
100
16
84
1/8
1/4
1/2
56
1/2
60
1/4
28
3/4
88
Full
116
Null
32
Table 28: Ratio of Mixing CS and PS Traffic in AterMUX
The Figure 59 presents details of Timeslot sharing between CS (TCH) and PS (GCH):
PS Traffic Ratio
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
TS
AterMUX CS/PS
/
/
/
/
TS
Transparency
Full
TCH
TCH
TCH
TCH
GCH
TCH
TCH
TCH
TCH
GCH
TCH
TCH
TCH
TCH
GCH
TCH
TCH
TCH
TCH
GCH
TCH
TCH
TCH
TCH
GCH
TCH
TCH
TCH
TCH
GCH
TCH
TCH
TCH
TCH
GCH
TCH
TCH
TCH
GCH
GCH
TCH
TCH
TCH
GCH
GCH
TCH
TCH
TCH
GCH
GCH
TCH
TCH
TCH
GCH
GCH
TCH
TCH
TCH
GCH
GCH
TCH
TCH
TCH
GCH
GCH
TCH
TCH
TCH
GCH
GCH
Alarm octet
SS
TCH
TCH
GCH
GCH
GCH
TCH
TCH
GCH
GCH
GCH
TCH
TCH
GCH
GCH
GCH
TCH
TCH
GCH
GCH
GCH
TCH
TCH
GCH
GCH
GCH
TCH
TCH
GCH
GCH
GCH
TCH
TCH
GCH
GCH
GCH
TCH
GCH
GCH
GCH
GCH
TCH
GCH
GCH
GCH
GCH
TCH
GCH
GCH
GCH
GCH
TCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
Figure 59: AterMUX CS/PS Timeslot configuration
Notes:
The TS numbers are a maximum value, and depend on the presence (or not) of signalling
links.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
100 / 162
The use of GSL on a given Ater Mux takes the place of 4 GCH nibbles on this link. See
Figure 54.
The AterMUX channels located on the same AterMUX TS as the Qmux (TS14) cannot be
used for GPRS (they are kept as CICs).
The TS 15 is always reserved for N7 channel, 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.3 SS7 Signalling mode

3.4.3.1 LSL and HSL modes
As previously mentioned, there is a maximum of one SS7 64kbps channel per Ater link, and a
maximum of 16 SS7 signalling channels per BSC (ITU-T limitation).
This operation mode of SS7 signalling, called Low Speed Link (LSL) in B10, may not be
sufficient to allow the treatment of traffic above 1900Erl.
A new SS7 option has been introduced with B10 in order to allow the traffic management of
up to 4500Erl for BSC Evolution.
The High Speed Link mode, also called HSL, corresponds to a couple of PCM signalling
links configured in a load sharing and redundancy mode.
This optional mode is used on any MxBSC configuration type; whatever is the CS traffic
load. With HSL mode, the PCM links dedicated to SS7 are taken from the Ater CS pool of the
LIU board.
In this case, only 46 PCM will be allocated to AterMUX CS links.
In order to avoid excessive SS7 dimensioning, the number of BSS using HSL on a TC is
limited to 4 Mx BSC.
The choice of the signalling mode is based on the number of required SS7 64kbps channels.
The dimensioning of the SS7 channels depends on the Operator traffic mix.
3.4.3.2 SS7 Dimensioning

The SS7 load depends on the BHCA and other call mix parameters. The SS7 links are
traditionally dimensioned with 40% load (i.e. 0,4Erlang per signalling channel).
The SS7 load estimation on A-interface is depending on capacity and call mix parameters.
The following table indicates the required number of bytes per SS7 (event) messages.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
101 / 162
S cenario
MOC
MT C
IHO
E HO
LU
S MS -MO
S MS -MT
P aging R etry
T o MS C
352
341
38
183
203
0
254
0
F rom MS C
290
413
0
182
211
223
413
0
Figure 60: SS7 message length (in bytes) according to GSM event
With the total bytes for one call attempt from previous table and given BHCA, it is possible to
estimate the SS7 required throughput and corresponding number of SS7 links needed.
Required SS7 throughput (kbps) = BHCA /3600 x Total bytes for one call Attempt * 8/1000
The required SS7 throughput is estimated in the MSC to BSS direction (worst case, because
of paging load).
BSC type (*)
BHCA (**)
Nb of SS7 links
at 40% load
Nb of SS7 links
at 60% load
BSC-EV-200
64 800
BSC-EV-400
129 600
16
11
BSC-EV-600
194 400
HSL
16
BSC-EV-800
259 200
HSL
HSL
BSC-EV-1000
324 000
HSL
HSL
(**) The BHCA corresponds to B10-MR2 capacity. For MR1, the BHCA is limited to 288 000.
If the resulting number of links is above 16, then SS7 on 2Mbps link (HSL) is required.
So dimensioning SS7 links at 60% load is allowed with the Alcatel-Lucent BSS, if the MSC
can also allow it. This SS7 signalling load is possible as soon as there is a minimum of four
N7 links configured.
SS7 Dimensioning Method 1 (SCCP traffic)

This method is based on SCCP traffic assessment.
In this way we can take into account the full SCCP connection usage during out-of-call
signaling (SDCCH) and during the call signaling (TCH+FACCH/SACCH).
Target: To estimate the number of AterMUX-CS links per BSC based on signaling
traffic.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
102 / 162
Gathered Counters:
Counter Name
Indicator Name
Definition
MC400
GSDTRT
Cumulated time during which the SDCCH sub-channels

belonging to the related static or dynamic SDCCH timeslots
are busy.
MC390
GSDAHCAN
Number of SDCCH seizures.
MC01+MC02
GSDNASUN
Total number of SDCCH successfully seized by mobile for

any purpose (Originating or Terminating procedure):
Establish Indication received.
MC10
GSDHOSUN
Total number of SDCCH successfully seized by mobile for

handover: Handover complete or Assignment complete
received.
MC380a+MC380b
GTCTRT
Time during which the TCH are busy
Table 29: Counter list AterMUX-CS dimensioning
Methodology:
INPUT
The SS7 traffic is related to the SCCP traffic generated by Call and Signalling treatments
as detailed in the Method paragraph.
Re quired _ SCCP _ traffic = Measured _ SCCP _ traffic + 15%m arg in
Where:
Measured _ SCCP _ traffic =
=
( MC 400 / MC390 ) * ( MC 01 + MC02 + MC10 ) + ( MC380a + MC 380b )

TS
TS
TS
3600
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 (BH) average effect: NPO indicators do not provide an
instantaneous value of the number of channels occupied but the traffic measured during
one hour. Moreover, the BH period is not determined via a sliding window but by
selecting the maximum of the measure realized each hour (see graph below).
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
103 / 162
Number of occupied Channels
RNO traffic measurements
Peak traffic
Exact Busy hour
Time (H)
8H00
9H00
10H00 11H00 12H00 13H00 14H00
Figure 61: Difference between Exact busy hour, NPO busy hour and Peak traffic
The second input is the Grade of Service (GoS), which is defined by the required SS7
congestion rate (pSS7). Normally GoS should be given or agreed by the Mobile Operator.
GoS: Required blocking probability pSS7

The typical maximum blocking rate at AterMUX interface is 0.1%.
Note that the Measured SCCP Traffic should not exceed the BSC Erlang capacity.
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.
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 signalling pertaining to that scenario.
Therefore, there is one SCCP connection open for SDCCH and TCH request:
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 SDCCH holding time
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
104 / 162
For SDCCH duration, only real access onto SDCCH (C01, C02 and C10 counters) must be
taken into account because the only ones leading to SCCP connection opening.
The TCH traffic is the main traffic that generates SCCP connections on the SS7 links. The
cause distribution of SCCP traffic is dependent on the Call mix of the monitored network.
So, the SS7 dimensioning will define the number of required SS7 links according to the
measured SCCP traffic at BSC level.
Below is the important configuration rule to be concerned for SS7 dimensioning.
Since B7.2,
The Alcatel BSCs provide 256 SCCP connections per SS7 link.
According to ITU-T Recommendations 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 signalling CS traffic only, Erlang B can be applied to calculate the
required number of SCCP connections according to the required SCCP traffic
(SCCP_connection_erlang) and the target congestion rate.
OUTPUT
Number of required SCCP Channels/Connections:

= Erlang B (Required_SCCP_traffic, pSS7)
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;
Nb _ required _ SCCP _ Connections
Nb _ required _ SS 7 _ links =
103
Number of required AterMUX-CS Links (1)

= Number of required SS7 Links
For example:
If the total number of Ater CS of one BSC is equal to 10 interfaces, the number of
required SS7 links for that BSC is identical to the number of Ater CS (i.e. 10 links
offering up to 1030 SCCP connections).
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
105 / 162
SS7 Dimensioning Method 2 (SS7 data volume)

This method is based on SS7 volume of data transferred during busy hour.
Target: To estimate the number of SS7 TS required per BSC based on signaling
traffic expressed as volume of data transferred. Also SS7 link efficiency may be
evaluated.
Gathered Counters:
Counter
Name
Long Name
Definition
N3.1
NB_N7_SIF_SIO_SENT
Number of octets of Signalling Information

(SIF) and Service Information Octets (SIO)
transmitted on the N7 SL.
N3.3
NB_N7_MSU_SENT
Number of Message Signalling Units (MSU)

transmitted on the N7 SL.
N3.4
NB_N7_SIF_SIO_REC
Number of octets of Signalling Information

Field (SIF) and Service Information Octets
(SIO) received on the N7 SL.
N3.5
NB_N7_MSU_REC
Number of Message Signalling Units (MSU)

received on the N7 SL.
N3.10
NB_N7_MSU_DISC_DUE_CONG
Number Message Signalling Units (MSU)

discarded due to a message buffer overflow
caused by an extended period of Signalling Link
congestion.
Traffic evaluation in UL
Counter values must be aggregated for the link set.
Measured _ SS 7 _ traffic =
%SS 7 _ cong =
N 3 .1 + 6 * N 3 . 3
28800000
N 3.10
100%
N 3.3 + N 3.10
Re quired _ SS 7 _ traffic =
Measured _ SS 7 _ traffic
1 Min (%SS 7 _ cong ; 30%)
Nb of Re quired SS7 TS = InverseErlangB (Required_S S7_traffic ;0.1% )
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
106 / 162
Traffic evaluation in DL
Counter values must be aggregated for the link set
Measured _ SS 7 _ traffic =
N 3.4 + 6 * N 3.5
28800000
Re quired _ SS 7 _ traffic = Measured _ SS 7 _ traffic + 15%m arg in

Nb of Re quired SS7 TS = InverseErlangB (Required_S S7_traffic ;0.1% )
The final number of SS7 TSs (links) is the max value between the results for UL and DL.
If this number is greater than 16, HSL usage is mandatory.
The final number of SS7 TSs (links) is the max value between the results for UL and DL.
If this number is greater than 16, HSL usage is mandatory.
Additionaly, it is recommanded to check for each SS7 link:
N7 link efficiency based on couters (in UL). It may be obtained using Formula:
N7 efficiency [%] = N3.3/( N3.3+N3.10)*100
N7 link congestion detection:
N1.6 (NB_N7_LINK_FAIL_CONG), which represents the Number of N7 SL
failures due to congestion during an extended period of time
Same kind of checks may be done in case of HSL usage. Note that 31 TSs of 64Kbps
are available for one HSL link.
HSL case with Normal frame format
%N7 Utilization in UL = (N3.1 + (6 * N3.3)) / (3600*8,000*31)
%N7 Utilization in DL = (N3.4 + (6 * N3.5)) / (3600*8,000*31)
HSL case with Extended frame format
%N7 Utilization in UL = (N3.1 + (9 * N3.3)) / (3600*8,000*31)
%N7 Utilization in DL = (N3.4 + (9 * N3.5)) / (3600*8,000*31)
The load on one N7 link shall not exceed 40% (recommended).
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
107 / 162
3.4.4 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.4.1 AterMUX CS
Target: To estimate the number of AterMUX-CS links per BSC.
Gathered Counters:
Counter Name
Indicator Name
Definition
MC380a
GTCTRFT
Time during which the TCH FR are busy
MC380b
GTCTRHT
Time during which the TCH HR are busy
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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
108 / 162
INPUT
METHOD
OUTPUT
Signalling Traffic
Required
SDCCH
Traffic
Erlang B
Nb of
required SS7
per BSC
Nb of
required
AterMUX-CS
links per BSC
GoS:
% SS7
blocking
Choose
Max value
User Traffic
Required
TCH
Traffic
Erlang B
Nb of
required TCH
per BSC
Final nb of
required
AterMUX-CS
links per BSC
Nb of
required
AterMUX-CS
links per BSC
GoS:
% TCH
blocking
Figure 62: AterMUX-CS dimensioning process
From Figure 62, the AterMUX-CS dimensioning is based on 2 different kinds of

traffic i.e. signalling & 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
The SS7 traffic is partially related to traffic generated by CS Call as detailed in the
previous paragraph. In LSL mode, each SS7 link is carried by an AterMUX-CS
interface. In this case:
Number of required AterMUX-CS Links (1) = Number of required SS7 Links

As an example, if the total number of required SS7 links of one BSC is 10 links, the
number of needed AterMUX-CS will be equal to 10 links.
For SS7 link definition, please refer to SS7 dimensioning and HSL mode
User traffic
INPUT
The required TCH traffic is computed as below formula.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
109 / 162
Re quired _ TCH _ traffic = Measured _ TCH _ traffic + 15% m arg in

Where:
Measured _ TCH _ traffic =
MC 380a + MC 380b
3600
Note: a 15% margin is added to the required traffic - see more explanation in 3.4.3.2
The other input is Grade of Service (GoS), which is defined by the required
AterMUX-CS congestion rate (pAterMuxCS). Normally GoS should be given or agreed
by the Mobile Operator.
Required blocking probability pAterMuxCS

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
dimensioning process to determine the necessary resources versus the traffic and 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 (Required_TCH_traffic, pAterMuxCS)
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 55.
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 55, 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
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
110 / 162
Then,
Final number of required AterMUX CS Links:

= Max (Required AterMUX CS Links (1), Required AterMUX CS Links (2))
3.4.4.1.1 A Dimensioning
According to Figure 56, 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
In this case if there is 40 AterMUX CS links needed at TC level, then the number 160 Ainterface links (40*4) are required from TC to MSC.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
111 / 162
3.4.4.2 AterMUX PS
AterMUX-PS dimensioning is based, like AterMux-CS dimensioning, on 2 different kinds of
traffic i.e. signalling & user traffic. After applying corresponding methods, each of traffic
may need a different number of AterMUX-PS links, and then the final number of required
AterMUX-PS link will be the maximum number.
The dimensioning methods for Signalling traffic are described in section 3.4.4.2.2
The dimensioning methods for User traffic are described in section 3.6.3
Section 3.4.4.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 signalling traffic and for user
traffic are combined together in order to obtain the final recommendation
3.4.4.2.1 Process description

The AterMux-PS dimensioning process must be executed at:
BSC level (doing the hypothesis of a well balanced traffic distribution among the
GP(U) boards connected to the BSC)
AND
GP(U) level (in case of multi-GP(U) configuration and if no additional GP(U)

resource adding found through the method application at BSC level) in order to
handle congestion situations due to unbalanced traffic/cell distribution/mapping
on GP(U) boards connected to the BSC. In this case:
A reshuffling operation should be done, before adding GP(U)/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 GP(U) board are identified as underdimensioned (i.e. they are not able to handle the required traffic) the adding of GP(U) boards will be
done in an iterative way (1 GP(U) at once) monitoring the consequent impact on the AterMux PS
interface.
In Figure 63 the process for AterMux PS dimensioning that must be applied at BSC level, is
presented:
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
112 / 162
AterMux dimensioning
Assessment for GSL traffic
Assessment for user traffic
# Needed
GSL links
# Needed
GCH
GPU/GP dimensioning
Assessment
Aterlink
GCH_Capacity
# AterMux PS
# AterMux PS per GPU

(GSL traffic)

(user traffic)
max
2 (for security reason)
# GSL links
# GPU/GP
(at least 2 per GPU/GP)
# AterMux PS per GPU/GP

Figure 63 AterMux-PS dimensioning process at BSC level
On the other hand, the process that is applied at GP(U) level, if the output of the process
applied at BSC level does not recommend the adding of additional GP(U) resources, is
described in Figure 64:
Assessment for user traffic
# Needed
GSL links
# Needed
GCH
GPU/GP dimensioning
Assessment
If #GPU/GP>1 then 1 GPU/GP

must be added and the
Aterlink
#AterMux PS per GPU/GP (for all
GPU/GPs)
GCH_Capacity
must be estimated as:
New #GPU/GP at BSC level
# AterMux PS
If #GPU/GP=1

(GSL traffic)
# GSL links
# AterMux PS
at BSC level

(user traffic)
max
(at least 2 per GPU/GP)
# Needed
GSL links
at BSC level
# AterMux PS per GPU (estimated at

BSC level)

(GSL traffic)

(user traffic)
max

Figure 64 AterMux-PS dimensioning process at GP(U) level
If, applying the dimensioning method at one GP(U), the result is that one (01) board is enough
in order to support the required traffic; the number of needed AterMux PS links for this
GP(U) will be assessed.
Otherwise, if the board is overloaded, it is recommended to add one additional GP(U) board
and the number of AterMux PS links per GP(U) will be re-assessed at BSC level.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
113 / 162
Some examples on the different possible scenarios are presented hereafter:

Example 1:
BSC level (2 GP(U) with 2 AterMux links per GP(U)):
#Needed GCH = 500
#Needed GP(U) = 2
#AterMux PS per BSC = 500/112 = 5
#AterMux PS per GP(U) = 5 / 2 = 3
GP(U) level
GPU1
#Needed GCH GPU1 = 200
#Needed GP(U) = 1
#AterMux PS per GP(U) = Max (200 / 112, 3) = 3
GPU2
#Needed GP(U) = 1
#AterMux PS per GP(U) = Max ( 300 / 112, 3) = 3
1.
2.
Reshuffle operation is done in order to try to balance traffic between the two GPUs
Add 1 AterMux PS links on both GPUs
Example 2
BSC level (2 GP(U) with 2 AterMux links per GP(U)):
#Needed GCH = 400
#Needed GP(U) = 2
#AterMux PS per BSC = 400/112 = 4
GP(U) level
GPU1
#Needed GP(U) = 1
GPU2
#Needed GP(U) = 1
1.
2.
If the reshuffle operation has not the wanted effect, add 1 AterMux PS to GPU2.
Example 3:
BSC level 2 GP(U) with 2 AterMux links per GP(U)):
#Needed GCH = 500
#Needed GP(U) = 2
#AterMux PS per BSC = 500 / 112 = 5
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
114 / 162
GP(U) level
GPU1
#Needed GP(U) = 1
GPU2
#Needed GP(U) = 2
1.
2.
If Reshuffle has not the wanted effect:

#Needed GCH at BSC = 500
#Needed GP(U) = 3
#AterMux PS per BSC = 500 / 112 = 5
3.4.4.2.2 GSL Dimensioning
Target: To estimate the number of AterMUX-PS links needed per GP(U), according to
the signalling traffic.
GSL dimensioning process is composed of two dimensioning methods that allow to
assess 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)
Assessment based
on the number of
GSL messages per second
Assessment based
on GSL bandwidth
2
(for security reason)
max
# GSL links
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
115 / 162
3.4.4.2.2.1 GSL dimensioning method based on bandwidth
Gathered Counters:
Counter Name
Indicator Name
Definition
P41
GTALAPDLN
Number of kilobytes sent to the BSC on the LapD link.
P42
GTALAPULN
Number of kilobytes received from the BSC on the LapD link.
Table 32: Counter list GSL dimensioning

Note: Busy Hour means the hour gives the highest signalling traffic i.e. max (P41, P42) of the day.
Methodology:
Calculate GSL (signalling) traffic for each AterMUX-PS link
Measured _ GSL _ traffic =
Max( P 41, P 42)

Erlang
28800
Note: 1 Erlang = [Gb TS speed (64kbps) * 3600] / 8 =28800 Kbytes.
Estimate capacity of one GSL per AterMUX-PS link = 0.42 Erlang

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

GSL _ load =
Measured _ GSL _ traffic

100%
GSL _ Capacity (= 0.42 Erlangs )
GSL load on a given GP(U) should not exceed 80%

It is recommended to increase the number of GSL per GP(U) if GSL load is
greater than 80% (up to 4 GSLs can be defined per GP(U))
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 GP(U) due to security
reason.
Up to 18 GSL (resp. 24 GSL) links can be defined on G2 BSC (resp. Mx BSC).
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
116 / 162
3.4.4.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 GP(U) level but, in case of specific assessment focus
only on GSL interface, it is recommended to apply the method at GP(U) level.
GPU
GSL_round_trip_delay
K_GSL
BSC
A message is kept in th e buffer

during GSL_round_trip_delay
GSL messages
buffer
Gathered Counters:
Counter Name
Indicator Name
Definition
P62a + P62b +
P62c - P438c +
P507
GTRUTERQN
Number of UL TBF establishment -requests per cell.
P91a + P91b +
P91c + P91d +
P91e + P91f +
P505
GTRDTERQN
Number of DL TBF establishment -requests
P30a + P30b +
P30c + P508
GTRUTESUN
Number of UL TBF establishment -successes (seized by the

mobile).
P90a + P90b +
P90c + P90d +
P90e + P90f +
P506
GTRDTESUN
Number of DL TBF establishment -successes (seized by the

mobile)
P62b
GTRUTRV5N
Number of UL TBF establishment requests per cell (seized by

the mobile) when MS is in packet transfer mode DL.
P160
GQRDTES1N
Number of DL TBF establishment requests requesting 1 slot,

which are satisfied.
P383a
GQAGALCTT
Time during which AterMux interface (GICs) for this GPU is

congested (at least one PDCH group impacted).
P391a
GTRPCHPAGPN
Number of PS paging requests processed by the GPU.
P391b
GTRPCHCIGPN
Number of CS paging requests processed by the GPU.
Table 33: Counter list GSL dimensioning
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
117 / 162
Measured Object: Cell (consolidated at BSC or GP(U) 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:
START
Retrieve indicators and

Cells GPUs mapping
(if method applied to 1 GPU/GP)
(*) QoS evaluation to be done

by QoS expert
Retrieve data on a different
Period or on an updated
configuration with better QoS*
PS
Traffic data
CHECK
QoS acceptable ?* [1]
No
OR
(i.e. UL TBF estab success rate > 80%)
Yes
GSL traffic condition
Calculation [2]
#GSL msgs/sec due
to PS traffic calculation [3]
Calculation
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)
#GSL msg/sec due to

RAE4 traffic calculation [3]
75% x GSL_Link_Max_Capacity [4]
If the method is applied at BSC level, the
total capacity (for all GPU/GP) must be kept
# GSL links
[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 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 values [2,5-3,5-5]. The factor is
chosen on the basis of the rule described in the below figure.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
118 / 162
PS traffic
Nb of Msg on GSL
Available
#TBF request/sec < 20
(TBF req)
High
Low
High
3.5
Low
2.5
3.5
GCH
Ater congestion observed
Figure 65 GSL usage factor
[3] #GSL messages/sec calculation

0.3 Msg/sec x Nb_cell
1) Msg on GSL due to RAE4 mechanism
2) Msg on GSL due to PS traffic:
1 x (Nb_PS_paging/sec+ Nb_CS_paging/sec)
2.1) Msg on GSL due to PS/CS paging
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
(e.g. 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
High GSL usage (worst case)
x Nb_TBF_Data_req/sec
Nb GSL messages/s
[4] GSL_Link_Max_Capacity. In order to compute the GSL interface capacity, the

following formulas apply:
In case of AterMux on terrestrial links:
K_GSL * (1000ms/GSL_round_trip_delay) * number of configured GSL links per GP(U) 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 GP(U)
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 GP(U)
must be summed.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
119 / 162
Calculate GSL load (in terms of treated messages)

The computation of Nb_GSL_messages_per_sec and GSL_Link_Max_Capacity is
detailed in the previous Methodology description.
GSL _ load =
Nb _ GSL _ messages _ per sec

100%
GSL _ Link _ Max _ Capacity
GSL load in terms of treated messages per second on a given GP(U) should not
exceed 75%
It is recommended to increase the number of GSL per GP(U) if GSL load is greater
than 75%.
3.4.4.2.3 GCH/AterMUX-PS Dimensioning
Target: To estimate the number of AterMUX-PS links needed per GP(U),

according to user traffic.
The main principle is to have roughly same number of AterMUX-PS links per
GP(U) (at least 2 links per GP(U)) for all the GP(U) connected to the same BSC.
N.B. This will not assure a balanced load distribution among the GP(U) 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 GP(U) boards, please refer to [15].
In order to estimate the number of AterMux-PS links per GP(U), analyzing the
whole BSC, two main data must be estimated:
Number of required GCH per BSC

Number of required GP(U) 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 Erreur ! Source du renvoi
introuvable..
Please find details of GP(U) dimensioning in the section 3.6.3
Having the number of required GCH and the number of GP(U) 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 57 and also refer to section 3.4.4.2.2 GSL dimensioning.
Number of AterMUX-PS links per GP(U) (based on user traffic) =

Number of AterMUX-PS links per BSC / Number of required GP(U) per BSC
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
120 / 162
Finally,
Number of AterMUX-PS links per GP(U) (based on signalling + user traffic) =

Max (Number of required GSL per GP(U), Number of AterMUX-PS links per GP(U)
based on user traffic, 2)
Remark: it is highly recommended to have at least 2 AterMUX-PS links per GP(U) due to security
reason.
Example:
If
Number of required GCH per BSC = 330

Number of required GP(U) per BSC = 2
Number of required GSL per GP(U) = 2
How many AterMUX-PS links per GP(U) are required?

- Determine Number of AterMUX-PS links per GP(U) based on user traffic
Number of AterMUX-PS links per BSC = 330/112 = 3 links
Number of AterMUX-PS links per GP(U) = 3 / 2 = 2 links
- Determine Number of AterMUX-PS links per GP(U) based on signalling + user traffic
= Max (Number of required GSL per GP(U), Number of AterMUX-PS links per
GP(U) 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%.
GP(U) Ater time congestion rate exceeding 0.1 % can be observed regularly.
GP(U) re-dimensioning is performed.
Warning:
It could happen that, because of unbalanced traffic distribution among the GP(U)
boards connected to one BSC, one GP(U) board is more loaded than others.
This can be discovered applying the AterMux-PS dimensioning process at GP(U)
level. Some examples are provided in 3.4.4.2.1.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
121 / 162
3.4.4.3 AterMUX CS/PS

Target: To estimate the number of AterMUX-CS/PS links needed per BSC (or
GP(U)).
GP(U) & AterMUX-CS dimensioning are pre-requisite to be performed in order to
provide input data for AterMUX-PS dimensioning.
Please find details of GP(U) dimensioning in the section 3.6.3
Please find details of AterMUX-CS dimensioning in the section 3.4.4.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 GP(U) dimensioning
Example of AterMUX-CS/PS dimensioning:

Number of required TCH per BSC = 250 TCHs
Number of required GCH per BSC = 50 GCHs
If
Then
From 250 TCH, 222 TCHs can be fit into 2 AterMUX-CS links
Note: From Figure 55, 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 28
Therefore, based on this example, we need 2 AterMUX-CS links and 1 AterMUXCS/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
GP(U) Ater time congestion rate exceeding 0.1 % can be observed regularly.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
122 / 162
GP(U) re-dimensioning is performed.
3.5 TC
There are two transcoder (TC) generations supported in B10, called G2 TC and 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, offering 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.
Local
Qmux
ASMC
ATBX
DT16 DT16
TSC
Ater interfaces
MT120
+FAN
BSC
MSC
TC bus
ASMC
MT120
or
+FAN
MT120
Ater-mux interfaces
A interfaces
Figure 66: TC G2 architecture with mixed configuration
Here after summary of technical data overall generation transcoder.

Rack
AterMux per rack
A interfaces
CIC
SMU
TRCU
G2 TC
Up to 3
6
24
24*29
ASMC
ATBX DT16
G2.5 TC
1
48
192
192*29
MT120
Data in this table, based on [1] and [9]
Table 34: G2 TC/ G2.5 TC capabilities
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
123 / 162
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 case of

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.
Configuration
TC
Extension / Reduction
Physical
Min
2 AterMux
2
2
4
-
G2 TC
SU
ASMC
TRCU SM 4:1
MT120
Max
6 AterMux
6
6
24
4
Logical
Min
1 AterMux
1
1
4
1
1 AterMux
1
1
4
1
Table 35: G2 TC configuration
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).
A interface
Ater mux interface

(4:1 Mapping scheme)
MT120
MT120
BSC
TC G2.5
MFS
MSC
Figure 67: TC G2.5 architecture
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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
124 / 162
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.
G2.5 TC
MT120
Configuration per Rack

(AterMux)
Min
Max
2
48
Extension / Reduction step

Physical
Logical
Min
1
1
Table 36: G2.5 TC configuration
And, the capacity in terms of MT120 boards is summed up in Table 37.

Configuration
1 subrack
2 subracks
3 subracks
4 subracks
Max MT120 modules
12
24
36
48
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.
3.5.2.1 New MT120-xB boards available

9125 TC MT120-NB (Narrow Band) intends to replace the MT120 legacy for next
deliveries to networks in respect with SW compliancies (BSS from B9 MR4 + TCSW).
9125 TC MT120-WB (Wide Band) is available for customers from B10 MR2 ed3 on,
knowing that WB-AMR will be activable once first-off on this feature is completed.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
125 / 162
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.
# AterMUX CS links from BSC1
# AterMUX CS links from BSC2
:
:
:
:
:
:
Total
links
Used TC type
(G2 TC or G2.5 TC)
Needed TC
Configuration
(Nb of boards)
# AterMUX CS links from BSCn

Figure 68: 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
Total = 36 MT 120 boards
BSCd needs 8 MT120 boards
As 36 MT120 boards are needed, this required one G2.5 TC with 3 subracks
refer to Table 37.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
126 / 162
3.5.4 STM-1 in TC
SDH is used to provide a high density E1 connection to TC and BSC.
A TC can be pure STM-1, pure E1 or mixed.
A BSC can be pure STM-1, mixed E1/STM1 (In future release) or pure E1.
3.5.4.1 Functional Requirements

STM-1 (or SDH transport) is to be introduced for the GSM network elements BSC (BSC
evolution for future release) and transcoder (TC G2.5 IP).
The TC needs to be upgraded to TC G2.5 IP (but there is no need for IP transport
function).
SDH on MFS is currently not envisaged as the solution is technically more complex, and
the need is lower, especially with Gb over IP (no Gb over E1) and BSS IP transport (no Ater
over E1).
SDH interface is foreseen to
- reduce the cabling effort
- reduce the space needed for cables and distribution frames
- simplify cabling/assignment changes
- reduce cost on transmission equipment
- increase the reliability and availability
The GSM NE does not provide a SDH add/drop feature and are connected as terminating
equipment to the SDH network.
3.5.4.2 Overall description

STM-1 is a 155 Mbit/s interface, defined within the SDH family of interfaces (others are
STM-4, STM-16).
SDH is used for GSM solely for the transport of E1 links. The SDH is used in the so-called
channelized mode.
Each E1 link is transported transparently (using asynchronous mapping) in one VC12
container. One STM-1 link can contain up to 63 VC12 containers. A VC12 container is also
called VC12 tributary.
STM-1, SDH and the E1 transport in VC12 are defined in G.707.
Due to the high traffic per STM-1 link, protected access is usually used. Protection is done
by automatic protection switching (APS) with one active and one standby link.
From ITU, STM-1 physical interface is defined as either electrical interface or as optical
interface. On TC, only the optical interface is offered, in mono-mode / short distance type.
To be flexible in manufacturing and procurement, the suppliers of optical/electrical
converters have defined a standard for a plugable O/E converter, called SFP (for Small Form
Factor-Pluggable). It allows plugging the O/E converters in the field, during operation,
according to the need. A list of supported types has to be defined as an indication to the HW
designers. It shall be possible to connect new types in future (of course within certain limits).
Optical cables are connected to the front side of the TC. Laser safety requirements have to
be respected.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
127 / 162
TC has the SDH interfaces on a daughter board on TCIF, named JATC4S1, dedicated to
STM-1.
As the E1 links are transported transparently over SDH, there is no influence on E1
alarming and on E1 synchronization. Each E1 is transported separately and there is no clock
dependency between different E1 links.
The SDH clock system is completely separated from the E1 clock system.
SDH interfaces on a GSM NE are always clock slave to the SDH network equipment.
The transport of E1 over SDH vs. E1 over physical interface can be selected per E1
interface or per group of E1 interfaces at TC level:
For A-interface: per MT120 (i.e. 4 A links are either on physical E1 or on VC12)
For Ater interface: per MT120 (i.e. 1 Atermux link is either on physical E1 or on VC12))
3.5.4.3 TC Configuration
STM-1 is only available in a TC G2.5 rack with TCIF subrack, plugged TCIF boards and
activated HSI, also named TC G2.5 IP (but there is no need for IP transport function) or TC
G2.5 with TCIF. The plugged TCIF must have the STM1 daughter board connected on. But
the IP daughter board is not used to offer the STM1 function or the TC supervision. The
presence of the IP daughter board must be accepted even the TC is not in an IP configuration.
TC must be declared to the OMC to be supervised by supervising (G2 or Mx) BSSIM.
A TC can be full STM-1, full physical E1 or mixed.
The evolution from a TC pure E1 to a TC pure STM-1 (i.e STM1 on Ater and A interface)
or to a TC E1/STM-1 mixed must be supported.
A TC can be shared between two OMCs but it is a seldom configuration.
The following figure presents the BSS architecture with STM-1 in TC:
STM-1
STM-1
n*E1
SDH
BTS
subrack
Ater
MSC
TDM
TC
BSC
BTS
BTS
MFS
SGSN
Figure 69: The BSS Architecture with STM-1 on TC side
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
128 / 162
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 B10:
The 1st MFS generation or A9135 MFS
MFS Evolution or A9130 MFS
3.6.1 The 1st 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 70: The 1st 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: consists of duplicated 100Mbps Ethernet networks for interconnection.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
129 / 162
3.6.1.1 GPRS Processing Unit (GPU)

The GPU supports the Packet Control Unit (PCU), as defined by GSM. The PCU handles Gbrelated 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 GCH (120 GCH
* 4 DSP) 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.
Sub-BSS 1
cell1
cell2
cell4
cell3
MFS
BSC
Sub-BSS2
GSL1
GPU1
cell5
cell6
GSL2
cell7
GPU2
GSL3
Sub-BSS3
GPU3
cell8
cell10
cell9
GSL4
cell11
cell13
GPU4
cell12
cell14
cell15
GPU1: cell1, cell2, cell3, cell4

GPU2: cell5, cell6, cell7
GPU3: cell8, cell9, cell10, cell11 cell12, cell13
GPU4: cell14, cell15
Sub-BSS4
Figure 71: Multiple GPU per BSS
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
130 / 162
3.6.1.3 Capacity
The following table describes the A9135 MFS capacity for DS10.
A9135 MFS Configuration
Nb of telecom subracks
Standard
Min GPU per MFS + One GPU for redundancy
Standard Pre-equipped
1+1
15+1
3600 or (240*15)
1+1
2 * (15+1)
7200 or (240*30)
Max BSC per MFS
15
22
Max GPU per BSC
Max BSC per GPU
Max GPU per MFS + One GPU for redundancy

Max GPRS GCH per MFS

st
Table 38: The 1 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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
131 / 162
(duplicated)
Mux1
Radio Network links
GP1
SSWw
Muxr
SSWr
E1
GPn
LIU1
OMCPw
OMCPr
LIUn
LIU Shelf
ATCA Shelf (14 slots)
(21 slots)
External Ethernet Links
Figure 72: MFS Evolution (A9130 MFS) HW Architecture
3.6.2.1 Configurations and Capacity

The following figure describes the A9130 MFS possible configurations:
SA12
SA12
RS16
RS16
Currently allowed configurations for MFS Evolution can be summarized as follow:
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
132 / 162
Stand-Alone
1 shelf:
Rack-shared
MFS with 1 shelf,
up to 9 GP
up to 8 GP,
up to 16 E1per GP:
2nd shelf extension possible:
In centralized synchronization mode: up to 14 E1/GP

In autonomous synchronization mode: up to 16 E1/GP
up to 21 GP in total
Up to 12 E1per GP in MR2ed4*:
Collocated BSC & MFS in one rack:
In centralized synchronization mode: up to 9GP

In autonomous synchronization mode: up to 21GP
Either with O&M over IP

Or with O&M over Ater
(*) Before MR2ed4, there is a maximum allowed number of 10 E1 per GP board when MFS is in centralized mode.
Additional capacity rules:

One A9130 MFS is able to manage up to 4000 cells (up to 2000 cells for legacy MFS)
One A9130 MFS is able to control up to 21 BSCs
Per GPU
Per GP
Per MFS
(with DS10)
Equipment domain
Fabric
Extension
Cnx
PCM-TTP
PCM-port
TRX
0
2
8
8
448
NS
NSE
NS-VC
FR Bearer
PVC
Remote IP End
Points
1
1
10
10
10
16
Per MFS
(with AS800)
Per MFS
Evolution
20
21
1
40
160
160
9856
1
42
294
294
12600
1
20
200
200
200
320
1
21
210
210
210
336
30
0
1
2
60
14
240
14
240
600
9856
NS and Frame Relay domain
1
1
1
30
10
300
10
300
10
300
16
480
Figure 73: MFS capacity
Figures of above table is taken frome [3BK 10204 0034 DTZZA]. Note that Gb over IP is not supported
on the AS800.
3.6.2.2 Delta MFS Evolution versus the 1st MFS generation

The main change/unchanged between those two MFS generation are below:
Different Behaviors:
Same Behaviors
The GP replaces the current GPU
No spare physical GP (still N+1

protection scheme)
No change in the radio configuration

mechanisms, and same parameters are
used
Control stations are replaced by the

OMCP board
No change in the PM mechanisms, same

counters/indicators
In the A9130 MFS, there are only 12

ports per GP
No change in the Ater/Gb transmission

configuration and display
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
133 / 162
3.6.2.3 Delta B10 versus B9

MFS
Max Nb of cells in B9
Legacy MFS
2000 cells
2000 cells
MxMFS
3000 cells
4000 cells
GPU/GP
GPU
264 cells
264 cells
GP
264 cells
500 cells
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
134 / 162
3.6.3 GP(U) Dimensioning and AterMux PS dimensioning (user traffic)

Target: To estimate the number of GP(U) needed per BSC.
Gathered Counters:
Counter Name
Indicator Name
Definition
P100c
GAAGCHUST
Cumulative time during which a GCH is busy in a cell.

The counter is integrated over all the GCH available in the
cell.
P383a
GQAGALCTT
Time during which AterMux interface (GICs) for this

GPU is congested (at least one PDCH group impacted).
P384
GQRGPUCDT
P101
GAAGCHAVT
Time during which a DSP enters the congestion state.

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
GAAGCHAVANT
P201
GTRGPULDLT
Cumulated time per GPU during which Ater nibbles are

free over the granularity period.
They are nibbles not currently used in a GCH.
Time during which at least a DSP is in CPU load state
P202
GTRGPULDOLT
Time during which at least a DSP is in CPU overload state
P76a
GTRGPUPBA_MA
Average PMU CPU power budget observed. Consolidated

in Day/Week/Month with the MAX value
P77a
GTRGPUPBM_MA
Maximum PMU CPU power budget observed.

Consolidated in Day/Week/Month with the MAX value.
P402
GTRGPUOT
Time during which the GPU stays in the PMU CPU

overload state due to PMU CPU power limitations.
P106
GTRXTESUGPN
Number of UL and DL TBF establishment successes per

GPU.
P104
GTRGPULPN
Number of LLC PDU transferred (UL + DL)
P107
GTRXTERQGPN
Number of DL and UL TBF establishment requests per

GPU
P392b
GTRGPUM_MA
Maximum number of active contexts of MS (in RRM)

observed. Consolidated in Day/Week/Month with the
MAX value.
([P62a+P62b+ P62cP438c+P507]
(P105d + P105f +
P27 + P105h + P105j
+ P105l + P204 +
P512 - P66 - P28 [P30a + P30b +
P30c+P508])
MC927e
GQRUTEBPN
Number of UL TBF estab -failures due to BSS problem

per cell.
P62a + P62b + P62c

- P438c + P507
GTRUTERQN
Number of UL TBF establishment requests.
P105e
GQRDTECCN
Number of DL establishment failures due to CPU

processing power limitations of the GPU.
Reference: number of UL TBF estab -requests
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
135 / 162
P105f
GQRUTECCN
Number of UL establishment failures due to CPU

processing power limitations of the GPU.
P203
GQRDTELDN
Number of DL TBF establishment failures due to DSPs

that are in CPU load / overload state.
Note: This counter applies to GPRS and EGPRS MS.
P204
GQRUTELDN
Number of UL TBF establishment failures due to DSPs

that are in CPU load / overload state.
Note: This counter applies to GPRS and EGPRS MS.
P91a + P91b + P91c

+ P91d + P91e +
P91f + P505
GTRDTERQN
Number of DL TBF establishment requests.
P383b
GTRGPUCOT_MA
Time (cumulated over a granularity period) during which

the GPU remains in "high" Ater usage.
Table 39: Counter list - GP(U) dimensioning
Measured Object: BSC/GPU

Note: Busy Hour means the hour gives the highest GCH traffic (i.e. P100c) of the day.
Methodology:
As the main input for the estimation of the number of GP(U) boards is represented by
the estimated number of needed GCHs (at BSC or GP(U) level), before being able to
apply the GP(U) dimensioning process, another process for the assessment of the
AterMux PS interface on the basis of the target user traffic must be executed.
The process of GP(U) dimensioning is presented below.
GPU_for_MS_context_handling (=0/1)
GPU_GCH_Capacity
GPU_for_Power_Limitation (=0/1)
Needed
GCHs
Number
of GPU
Figure 74: GP(U) dimensioning process
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
136 / 162
Required_GCH_Traffic
estimation
Counters
Stable
Network
Feature
activation
Needed
GCHs
ERLANG C
Traffic
evolution
With
quantile=99,9%
Figure 75 AterMux PS dimensioning process based on user traffic
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 (pGP(U)). 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 Operator.
The recommended value is 99.9% quantile of 0 delay sec.
OUTPUT
Number of required GCH = Erlang C (Required_GCH_traffic, pGP(U))
Number of required GP(U) = 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.2
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 GP(U) boards needed because of GPU GCH capacity limitation (see 3.6.3.3
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 GP(U) boards needed because of GPU GCH capacity limitation and
GPU_for_Ms_context_handling equal to 0 (see 3.6.3.3 for details on the estimation of this
variable).
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
137 / 162
3.6.3.1 Required GCH traffic estimation

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:
Re quired _ GCH _ traffic =
Measured _ GCH _ traffic

1 Min(%GCH _ cong ,30%)
Where:
Measured _ GCH _ traffic =
P100c
, and
3600
%GCH _ cong = Max{Ater _ Congestion, GPU _ Limitation} =
Max{% Ater _ Cong ,% DSP _ Cong ,% DSP _ load ,%CPU _ overload }
Where:
%GCH _ Ater _ cong =
P383a
100%
3600
%GCH _ DSP _ cong =
P384
100%
3600
% DSP _ load =
Max( P 201, P 202)

x100%
3600
%CPU _ overload =
P 402
x100%
3600
N.B. If the method is applied at BSC level the congestion will be evaluated as the
maximum congestion over all the connected GP(U) boards.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
138 / 162
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 or to the high
Ater usage handling condition) the relationship between GCH and PDCH traffic
clearly shows a saturation aroud the available resource limit.
448
y = 5,3905x + 21,057
336
Measured
GCH traffic
Resources
saturation
224
112
0
0
10
20
30
40
50
60
70
80
Measured PDCH traffic
Figure 76: 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 distinguishing 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 77.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
139 / 162
Needed_GCH
Following the
4th link adding
560
ERLANG C
448
y = 5,3905x + 21,057
Measured
GCH traffic
336
224
112
0
0
10
20
30
40
50
60
70
80
Measured PDCH traffic

Figure 77 GCH vs. PDCH traffic relationship: example
Assessment
The assessment of the Required_GCH_traffic must be done when one of the following
conditions is observed:
-
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 GP(U) GCH capacity estimation

In order to estimate the maximum number of GCH a GP(U) board is able to handle, first of all
the maximum theoretic capacity of the board must be taken into account:
480 GCH for legacy MFS

1920 GCH for Mx MFS with GboIP (1560 GCH with GboFR)
This theoretic capacity is then adapted to the BSS configuration and the traffic profile where
the GP(U) is used, in the following way:
The N_ATER_TS_MARGIN_GPU resources must not be taken into account in the

GP(U) capacity. Therefore the maximum theoretical number of GCH per GP(U)
becomes:
480 N_ATER_TS_MARGIN_GPU*4 (for legacy MFS)

1560 N_ATER_TS_MARGIN_GPU*4 (for Mx MFS with GboFR)
1920 N_ATER_TS_MARGIN_GPU*4 (for Mx MFS with GboIP)
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
140 / 162
The fact that the maximum number of PDCH per GP(U) is dynamic depending on
the used coding schemes must be taken into account:
Max CS
GPU (A9135)
GP (A9130)
Case 16 E1
links per GP
Case 12 E1
links per GP
CS1
CS2
CS3
CS4
240
240
224
200
960
960
892
804
960
960
864
660
Max MCS
GPU (A9135)
GP (A9130)
GP (A9130)
Case 16 E1
links per GP
Case 12 E1
links per GP
856
836
796
772
704
660
448
380
348
856
836
796
720
584
460
312
264
244
MCS 1
MCS 2
MCS 3
MCS 4
MCS 5
MCS 6
MCS 7
MCS 8
MCS 9
GP (A9130)
232
224
208
200
184
172
136
116
108
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.
Number of required GCHs
CS
UL
DL
MCS
UL
DL
MCS-1
0,89
0,86
CS-1
0,73
0,73
MCS-2
1,00
1,00
CS-2
1,00
1,00
MCS-3
1,33
1,28
MCS-4
1,50
1,47
MCS-5
1,86
1,81
MCS-6
2,36
2,31
MCS-7
3,49
3,39
MCS-8
4,14
4,00
MCS-9
4,49
4,39
CS-3
1,25
1,22
CS-4
1,64
1,60
Therefore the maximum number of GCHs that the GP(U) 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
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
141 / 162
In DL direction the maximum number of GCHs that a GP(U) 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 GP(U) 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:

Min{ Max _ DL _ GCH _ GPU , Max _ UL _ GCH _ GPU , Max _ Capacity N _ ATER _ TS _ MARGIN _ GPU * 4}
Where,
Max_Capacity is equal to 480, 1560 or 1920 GCH 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, GP(U) Ater
congestion (P383a/3600) and GP(U) DSP congestion (P384/3600).
If we can see the GCH congestion occurring regularly e.g > 0.1% congestion, GP(U) redimensioning is required.
3.6.3.3 GP(U) limitations

Apart from GP(U) GCH capacity, some limitations due to GP(U) memory or processor
capacity must also be taken into account; the consequence of these limitations can be the
adding of 1 GP(U) 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)
2. The capacity in terms of PMU or DSP CPU load
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:
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
142 / 162
1200
Max number MS
context (P392b)
Average number
MS context (P392a)
60,0%
1000
50,0%
800
40,0%
600
30,0%
400
20,0%
200
10,0%
21h
18h
15h
12h
09h
06h
03h
21h
25/10/2006 : 00h
18h
15h
12h
09h
06h
03h
21h
18h
UL TBF BSS
Failure rate
24/10/2006 : 00h
15h
12h
09h
06h
03h
21h
18h
23/10/2006 : 00h
15h
12h
09h
06h
03h
21h
22/10/2006 : 00h
18h
15h
12h
09h
06h
03h
0,0%
21/10/2006 : 00h
In order to detect this problem the following methodology was defined:
Retrieve
Retrieveindicators
indicators
for 5 working days
P392bBSC=1000 and P392aBSC>900

during at least 12% of
the observed period
NO
GPU_for_MS_context_handling =0
YES
YES
Observed QoS acceptable

for the customer?
NO
Figure 78 GPU_for_MS_context_handling due to PMU memory limitation
For MxMFS, due to 4000 MS context limit, GP memory limitation from PMU (CPU)
may be detected if P392b = 4000 and P392a > 3600 for at least 12% of the observation
period.
N.B. In B10 the observation of the number of MS context (P392a and P392b) should no more
represent a limitation in itself but a useful indication about the GP(U) load.
Capacity in terms of PMU/DSP CPU load (GPU_for_Power_Limitation variable

estimation)
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).
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
143 / 162
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 79) or
DSP CPU (see Figure 80) level.
Retrieve indicators
for 5 working days
P402/3600 >0,1% OR P76a>70%

The observed period
NO
GPU_for_Power_Limitation=0
YES
(P402/3600 >0,1% OR P76a>70%) and cpu_cong_fail_rate > 1% OR GPU reboots
observed during the CPU loaded hours)
NO
YES
Figure 79 GPU_for_Power_Limitation due to PMU CPU load
In Figure 79,
cpu _ cong _ fail _ rate= Max (
P105f
P105e
;
)
P91a + P91b + P91c + P91d + P91e + P91f P62a + P62b + P62c - P438c
N.B. In In the specific case of B8 to B9MR4 migration the following additional condition
must bechecked 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 (average of maximum daily values of P76a) is greater
than 40%.
In the specific case of B9MR1 to B9MR4 migration, the average CPU load (average of
maximum daily values of P76a) for a GPU board in B9MR1 should not exceed 50% in
order to avoid overload in B9 MR4; otherwise an additional module should be added
(GPU_for_Power_Limitation = 1).
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
144 / 162
Retrieve indicators
for 5 working days
Max(P201,P202)/3600 >0,1%
The observed period
NO
YES
Max(P201,P202)/3600 >0,1% and dsp_load_fail_rate > 1% OR GPU reboots
Observed during the CPU loaded hours)
NO
YES
Figure 80 GPU_for_Power_Limitation due to DSP CPU load
In Figure 80,
dsp _ load _ fail _ rate = Max(
P 203
P 204
;
)
P91a + P91b + P91c + P91d + P91e + P91f P62a + P62b + P62c - P438c
Finaly, The number of required GPU/GP boards =

= Number of required GPU/GP board (from user traffic) +
+ MAX(PTU_Power_Limitation; PMU_Power_Limitation; MS_context_handling)
Assessment:
It is recommended to monitor the PMU and DSP load through the counters (P201, P202,
P402, P76a, P77a, P105e, P105f and P107). If we can see that
Max (P201, P202)/3600 or P402/3600 is regularly > 0.1%.
or
If P76a is regularly > 70% ,
then GPU/GP re-dimensioning is required.
Capacity in terms of TBF number at GP level:
Theorically, one GP board, in average, can manage up to 900 000 TBFs (establishment +
re-allocation) before triggering the GP overload mechanism (GPU limit is four times less).
Assessment:
The TBF load assessment is possible using the following indicators:

Counter
Indicator
Long Name
Definitions
P62a + P62b + P62c P438c + P507 + P91a

+ P91b + P91c +
GTRATERQN
GPRS_TBF_request
Number of UL and DL TBF

establishment request per
cell.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
145 / 162
P91d + P91e + P91f

+ P505
P403a + P403b +
P403c + P403d +
P404a + P404b +
P404c + P404d
GTRRRRQN
GPRS_TBF_realloc_request
Total number of UL+DL

TBF reallocation requests.
If the limit is exceeded, a new GP board must be added for the related BSC.
TBF per Cell limit at GPU/GP level:
Due to memory constraint, RRM limits the number of MSs making simultaneously UL or
DL transfer per cell to 250.
MS active means that at least, one tbf is established (UL only, DL only or UL+DL).
So, 250 is the limit of MS in transfer in the cell, with at least one tbf UL or DL. MS idle
contexts are not counted inside this limit.
Note: the MS context is kept 2 mn after the end of it transfer to preserve its RA
capabilities, and to optimize the restart of a potential transfer. When a new MS arrives in
the cell when 250 MS contexts are used in a cell, an MS preemption mechanism replaces
an Idle MS by the new MS.
Assessment:
The TBF per Cell limit assessment is possible using the following indicators:
Counter
Indicator
Long Name
Definitions
P35
GTRDTBM_MA
GPRS_DL_TBF_estab_max
Maximum number of DL TBF

simultaneously established over
the Granularity period.
P36
GTRDTBA_MA
GPRS_DL_TBF_estab_avg_max
Average number of DL TBF

P39
GTRUTBM_MA
GPRS_UL_TBF_estab_max
Maximum number of UL TBF

P40
GTRUTBA_MA
GPRS_UL_TBF_estab_avg_max
Average number of UL TBF

For (P35 > 200 or P39 > 200) and (P36 > 180 or P40 > 180), if PMU CPU overload
occurs, some actions, like cell splitting, must be taken to better distribute data traffic over
different cells.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
146 / 162
3.7 Gb interface
As explained previously, the Gb interface allows the exchange of PS signalling and traffic
data between MFS and SGSN.
The Gb interface is defined by the three main protocols:
BSSGP protocol
Network Service (NS) protocol
Physical Layer protocol
The BSSGP application layer is in charge of the processing of the packet traffic coming from
a set of radio cells. It manages the Gb interface and the BSSGP Virtual Connections (BVC).
The BVC is a virtual end-to-end path between BSSGP peer entities.
The BSSGP application layer relies on Network Service layer that manages the
communication paths between the Network Service Entity (NSE) of the SGSN and the MFS.
The Network Service layer is composed of two sub-layers:
Network Service Control (NSC) is independent from the intermediate transmission network
used on the Gb interface and is responsible for:NS PDU transfer between BSS and SGSN: PDU
-
order is kept, except under exceptional circumstances

Load-sharing (at the initiative of the sender)
NS Virtual Connections (NS-VC) management
Sub-Network Service (SNS) is dependent on the intermediate transmission network and

provides access to the intermediate network
The BVC is identified by a BVC Identifier (BVCI) that is unique in one Network Service
Entity (NSE).
An NSE, which is identified by a NSE Identifier (NSEI), is a group of communication paths
called NS-VC.
The NSEI is an end-to-end identifier and shall be unique within a SGSN.
The BVCI together with the NSEI uniquely identifies a BVC within a SGSN.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
147 / 162
The next figure describes the Gb protocol stack implemented at both MFS and SGSN sides.
It describes the logical context, i.e. protocol layers and entities, of the Gb interface.
-
In legacy GboFR architecture, NS-VC are built within FR Permanent Virtual Circuit
While in GboIP architecture, NS-VC are no more linked to a PVC and a BC but it is
made of a couple of IP Endpoints (i.e. MFS and SGSN IP endpoint)
The IP endpoint at GPU and SGSN level is identified by the UDP port and IP address.
B S S G P la y e r
G PU m
B S S G P la y e r
GPU n
BCV
BCV
BCV
BCV
SGSN
BCV
BCV
BVC = one
p e r c e ll
BVCI
N S la y e r
L o a d s h a r in g
NSE = one per G PU

NSE
N SC sub
la y e r
N S -V C
SN S sub
la y e r
N S -V C I o r R e m o te IP E n d p o in t
OR
R e m o te IP e n d p o in t
PVC
N S -V L
IP E n d p o in t
IP n e t w o r k
Layer 1
N S -V L F R b e a re r
F R n e tw o rk
Figure 81: Gb interface configuration (from 3BK 09559 LAAA EBZZA)
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
148 / 162
3.7.1 Gb configuration
The Gb interface is based on Frame Relay protocol, whether or not an actual Frame Relay
network is set.
From B10, a new transport option allows the Gb interface to be transported over IP protocol.
The intermediate transmission network used for the connection between MFS and SGSN is a
Frame Relay (FR) or an IP network.
In case of GboFR, only Permanent Virtual Connections (PVC) are used and supported by
one Bearer Channel (BC) defined as 64kbps PCM TS.
In case of GboIP, the NS-VL is mapped to a remote IP endpoint.
GboFR
The GboFR interface is supported by one or several Bearer Channels on 2Mbps PCM
links.
Three configurations may be used to connect the MFS with the SGSN as described in
the following figure:
Through a Frame Relay network

Direct MFS-SGSN connections: this is the most chosen case of Gb connections.
Through NSS transmission network
Gb
1) Through a FR Network
MFS
Frame Relay
Netwok
Gb
SGSN
Gb
2) Direct MFS - SGSN connections
MFS
Gb
3) Through NSS transmission network
MFS
Gb
MSC/VLR
MSC/VLR
Figure 82: Gb interface connections
For more details, please refer to [1] and [10].
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
149 / 162
GboIP
The GboIP is transported over a Gigabit Ethernet (GE) link.
Several configurations may be used to connect the MFS with the SGSN:
Direct point to point connection

Over a public IP network (security, QoS and delay not guaranteed)
Over a private IP network (security, QoS and delay guaranteed by the Operator)
Over the SGSN IP backbone (similar to private IP network)
Example of connection:
In the following figure, the MFS is connected to the SGSN through a private IP network.
The MFS is connected to Edge Routers through a redundant GE link.
The Edge Routers are seen as a single gateway IP address, which is a MFS requirement.
The Routers shall implement the VRRP protocol or an equivalent protocol like HSRP.
Ater(circuit)
E1
PDH/SDH network
TC
Ater(packet)
BSC
MSC
GE
MFS
GE
Gb
Full redundant architecture,
SGSN
Packet Switched Network
Seen as single gateway IP@
Figure 83: GboIP End-to-End architecture
Only the O&M one LAN configuration allows GboIP feature in B10 release.
The support of GboIP is based on IPv4 protocol only, and is defined with following
rules:
One IP EndPoint (UDP port, IP@) per NSEI (i.e. GP(U))

Up to 16 remote IP EndPoints per GP(U)
Weight assignment to remote IP EndPoint for load sharing
One single gateway IP address per MFS
For more details, please refer to [1] and [10].
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
150 / 162
3.7.2 Gb Dimensioning
The dimensioning of Gb interface is not impacted by any channel consideration or radio
condition and it only depends on BH average throughput (from carried volume at Busy Hour).
Target: To estimate the number Gb TS (GboFR) and average throughput (GboIP)
Gathered Counters:
Counter Name
Indicator Name
Definition
P45
GTGPVCDLN
Nbr of kilobytes received from the SGSN at SNS sublayer
P46
GTGPVCULN
Nbr of kilobytes sent to the SGSN.
P34
GAGPVCAVT
Time during which the PVC is not available.
P45a
GTGGIPDLN
Nbr of kilobytes received from the SGSN at SNS sublayer (GboIP)
P46a
GTGGIPULN
Nbr of kilobytes sent to the SGSN (GboIP)
P34a
GAGGIPAVT
Time during which the SGSN IP endpoint is not available.
Table 40: Counter list - Gb dimensioning
Measured Object: Gb (PVC for GboFR, IP Endpoint for GboIP)

Methodology:
The process of Gb dimensioning is presented below.

INPUT
METHOD
OUTPUT
Nb of required TS per
GboFR link
Required Gb
Traffic
Erlang C
Minimum Throughput
for GboIP link
GoS:
% Quantile of x
delay sec
Figure 84: Gb dimensioning process
INPUT
The required Gb traffic is computed as below formula.
Re quired _ GboFR _ traffic = Measured _ GboFR _ traffic + 15 %m arg in
Note: a 15% margin is added to the required traffic.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
151 / 162
The other input is Grade of Service (GoS), which is defined by %Quantile of x delay
second (pGb).
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
As Gb resources are associated to PS traffic only, Erlang C can be applied to calculate
the required number of GboFR TS and GboIP throughput according to required PS
traffic and % quantile of delay time.
OUTPUT
Gb over Frame Relay
For GboFR interface, the measured traffic corresponds to P45 and P46 counters.
Measured _ GboFR _ traffic =
Max ( P 45, P 46 )
28800
Then the required number of bearer channels (i.e. 64kbps TS) is as follows:
Number of required Gb TS per link
= Erlang C (Required_GboFR_traffic; pGb)
Notes:
1 Erlang = [Gb TS speed (64kbps) * 3600] / 8 =28800 K bytes
Minimum 2 Gb links are required for one GP(U) due to security reason
Maximum 31 Gb TS (TS no. 1 to 31) can be configured per one GboFR link. TS0
cannot be used as it is reserved for specific usages e.g. frame synchronization.
In general, around 4 to 8 TS are configured per one GboFR link.
For more detail, please see [19].
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
152 / 162
Additionaly, Data rate in DL (SGSN to MFS) and in UL (MFS to SGSN) may be

calculated at PVC level or aggregated at Gb link or GP level:
DL Data rate [Kbps] = 1.02*(P45*8)/(3600-P34)
UL Data rate [Kbps] = 1.02*(P46*8)/(3600-P34)
Note: 1.02 due to 2% overheads at NS and FR level (FR case overhead is of 6 bytes per
300 bytes of payload).
Gb over IP
The dimensioning must be performed at MFS level with all BSC involved in the
GboIP mode. Traffic assessment may be done also at SGSN IP endpoint level.
Compared to GboFR, GboIP induces an additional overhead to the Gb flow:
BSSGP/NS/UDP/IP/Ethernet header is 118 bytes, while
BSSGP/NS/Frame Relay header overhead is 54 bytes.
Because the used counters are implemented at NS level, the 48 bytes from BSSGP
must be ignored in calculations because the BSSGP header is inside the payload for
NS layer.
The overall overhead depends on the traffic flow characteristics (IP packets size).
As an average value, the estimated overhead is about 23.3% (70 bytes for an IP PDU
of 300 bytes).
When the GboIP interface is used, the traffic may be evaluated as maximum Data rate
in DL (SGSN to MFS) and in UL (MFS to SGSN) using P45a, P46a and P34a
counters.
At IP EndPoint level or aggregated at GP or MFS level:
DL Data rate [Kbps] = 1.233*(P45a*8)/(3600-P34a)
UL Data rate [Kbps] = 1.233*(P46a*8)/(3600-P34a)
When Gb traffic is transported over GboFR interface and then migrated over GboIP
interface (i.e. IP), the measured traffic is given by GboFR counters and then
converted in expected IP traffic:
Estimated DL IP Data rate [Kbps] = (370/306)*(P45*8)/(3600-P34)
Estimated UL IP Data rate [Kbps] = (370/306)*(P46*8)/(3600-P34)
The measured Gb data rate take into account the removal NS/FR header and the
addition of the NS/UDP/IP/Ethernet header:
Measured _ GboIP _ traffic = Measured _ GboFR _ traffic * (300 + 70 ) / (300 + 6 )
Notes: Overhead from GboFR to GboIP = [300 + 70] / [300 +6] = 120.9%.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
153 / 162
Comment:
The MFS SGSN IP link is done via Gb access routers.
Each switch module of the MFS is connected to a switch module of the Edge Router
through a GigaEthernet link (active standby configuration).
The traffic of all GP boards is agregated on one GigaEthernet link with a fixed capacity.
It is not possible to extend or reduce this capacity, but it is not expected to find
congestion at this level.
Using Gigabit Ethernet link to the aggregation Router, we can calculate the extreme
loaded case as follows:
For MxMFS
1560 GCHperGP * 16 Kbps = 24.96 Mbps
Assuming all this traffic coming from SGSN for one MxMFS with 21 GP boards we
get:
21 boards*24.96 Mbps = 524.16 Mbps -> Half of the GigaEthernet link capacity.
For Legacy MFS
480 GCHperGP * 16 Kbps = 7.68 Mbps
Assuming all this traffic coming from SGSN for one MFS DS10 with 30 GPU boards
we get:
30 boards*7.68 Mbps = 230.4 Mbps -> Quarter of the GigaEthernet link capacity.
Congestion is not expected at the level of the link to the aggregation router.
Any Congestion seen afterwards is dependent on bandwidth management of the core IP
network.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
154 / 162
4 Annex 1: BSS Architecture Impact from B9

Since 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 85: EGCH link in B8 vs. M-EGCH link in B9
As M-EGCH concept presented in Figure 85, 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 (MEGCH link), instead of using a single EGCH link per PDCH.
In following table, there is the summary showing the GCH usage gain in B9 - thanks to
M-EGCH compared to B8 for each coding scheme. For instance, to support MCS 9,
there are 40 GCHs per TRX needed in B8 but only 36 GCHs per TRX needed in B9.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
155 / 162
Coding
Schemes
CS1
CS2
CS3
CS4
MCS 1
MCS 2
MCS 3
MCS 4
MCS 5
MCS 6
MCS 7
MCS 8
MCS 9
B8 (w/o stat mux)

GCH per RTS
B9 (with M-EGCH stat Mux)
GCH per TRX
1
1
2
2
1
1
2
2
2
3
4
4
5
GCH per RTS
GCH per TRX
0.73
1.00
1.25
1.64
0.89
1.00
1.33
1.50
1.86
2.36
3.49
4.14
4.49
8
8
16
16
8
8
16
16
16
24
32
32
40
6
8
10
14
8
8
11
12
15
19
28
34
36
Table 41: GCH consumption B8 vs. B9
M-EGCH Statistical Multiplexing is mandatory feature (automatically enabled) in B10

(since B9 release).
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 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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
156 / 162
Figure 86: Wasted Abis nibbles case in B8
In Figure 82, there is a noticeable waste of Abis resources in B8 release linked to static
Abis allocation but it can be improved from 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 from B9.
Dynamic Abis allocation is mandatory feature (automatically enabled) in B10 (since B9
release).
Enhance Transmission Resource Management
The Enhanced transmission resource management feature can be seen on top of the MEGCH 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 87: Enhance transmission resource management
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
157 / 162
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 level and the Ater congestion situations
at GP(U) 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:
GP(U) 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 GP(U) to serve only new prioritary TBF establishment.
AterMUX PCM link
0
1
2
3
64kbps timeslot # 0
N_ATER_TS_MARGIN_GPU
Ater TS Reserved in GPU for priority request
64kbps timeslot # 1
.
...
64kbps timeslot # n
Figure 88: AterMUX TS reserved by GP(U) 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 GP(U)
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].
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
158 / 162
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 89: 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.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
159 / 162
5 Annex 2: Pre-requisites for MxBSC capacity improvements

Several improvements of the Mx BSC have been introduced with GboIP, HSL and Capacity
features.
With these several improvements, Mx BSC could not be no more considered as a standard
BSC. Indeed, the introduction of the new features may be problematic when non-compliant
Core Network have been planned to be interconnected to Mx BSC.
The Core Network (NSS & GSS) should allow an interconnection with the Mx BSC. This
feasibility (interoperability) is dependant on the CN capacity/capability to interconnect with
Mx BSC enhanced by the implementation of new B10 features.
5.1 CIC code limitation

With the capacity improvement, the Mx BSC can handle up to 4500Erl, which corresponds to
a number of 4630 CIC on A-interface (0.1% blocking rate).
However, each CIC is coded on 12-bits field that permits to address a maximum of 4096
circuits between MSC and BSC elements (defined in ITUT Q.763):
8
7
6
Circuit Identification Code
Spare
3
2
1
(least significant bits) lsb
msb CIC (most significant bits)
Thus, the total CS traffic really handled by Mx BSC could be limited by the restriction of CIC
number on A-interface (Ater-CS interface as well), rather than the hardware or software
capacity of the Mx BSC itself.
With this limitation, the total traffic that can be coded on CIC field is less than 3980Erlang.
This implies a reduction of about 600Erlang regarding the real capacity of the Mx BSC.
In order to overtake the 4096 CIC limitation, the Mx BSC will support the CIC coded on 16bits field from B10 release. The CIC code extension to 16-bits field is done with the use of the
4 spare bits in the header.
The CIC code limitation will be eliminated if the connected MSC also supports the 16-bits
CIC code, such as the A5060 Spatial Atrium Call Server (Alcatel-Lucent NGN solution).
5.2 HSL limitation

As mentioned in section 3.4.3.2, the SS7 signalling load is directly linked to the amount of
BHCA and traffic carried by the Mx BSC.
According tot ITU-T Recommendations, there is a limitation of a maximum of sixteen 64kbps
SS7 signalling links per BSC (e.g. LSL mode).
This limitation can be reached when the Mx BSC traffic growth occurs.
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
160 / 162
In order to overtake this limitation, the Alcatel-Lucent solution is to double the signalling
throughput by using HSL functionality (ITU-T Recommendation Q.703 Annex A).
The HSL feature is a mandatory feature in Mx BSC handling traffic higher than 2600Erl (in
fact 1900Erlang as described in section 3.4.3), and it may be used only if the option is also
supported by the MSC.
At MSC level, the HSL function could be based on two different options;
Two un-channelized 2Mbps PCM links (TS0 + data bulk of 1984kbps)
working in a redundant and load sharing purposes
Two structured 2Mbps PCM links (up to 16 TS per PCM)
The Alcatel-Lucent solution is based on two un-channelized HSL links structured with a
synchronisation TS0 as usual and a data channel of 1984kbps).
To conclude, the CS Core Network that will be interconnected to large Mx BSC (traffic load
higher than 2000Erlang) shall support the un-channelized HSL feature.
For interoperability purposes between Alcatel-Lucent Mx BSC and CS Core Network, the
CSCN elements supporting the HSL feature are:
Legacy MSC equipped with RCP A8362M + Umax EP6
NGN release W4.21
An additional requirement is to be checked; it concerns the signalling mode between BSS and
the MSC.
When MSC supports only the quasi-associated mode of signalling with the BSS, STP
functionality (Signalling Transfer Point) shall be provided outside the BSS (cf. TS 48.006).
5.3 GboIP limitation

The Gb interface type is defined at BSC level allowing the MFS to support mixed-mode (FR
and IP).
Several BSC could be connected to a single SGSN element; there is a strong need regarding
the support of mixed-Gb mode (FR and IP).
For interoperability purposes between Alcatel-Lucent MFS and SGSN, the SGSN will support
mixed Gb mode (FR and IP) and static IP address allocation (SGSN U3.2 & U3.3 roadmap).
As only IPv4 is supported at MFS side, the SGSN shall also support IPv4 protocol.
In the case of GboIP feature, the synchronization clock cannot be extracted from the SGSN.
The following configurations shall be considered:
-
In mixed Gb mode (FR and IP): clock synchronization can be extracted from the GboFR links
In GboIP with existing links between MFS & TC: clock synchronization for Ater TDM can be
extracted from the TC links
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
161 / 162
END OF DOCUMENT
Alcatel File
Reference
Date
Edition
Page
3DF 0190 329 8010 VAZZA 02
February 18, 2009
162 / 162

B10 BSS Arch Serv GuideLine Ed2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

B10 BSS Arch Serv GuideLine Ed2

Uploaded by

Copyright:

Available Formats

Site

Mobile Radio Division

B10: BSS Architecture Service Guideline

Distribution codes Internal:

Appraisal and approval authorities

3DF 0190 329 8010 VAZZA 02

February 18, 2009

OVERVIEW OF BSS ARCHITECTURE SERVICES ....................... 15

WHAT IS THE BSS ARCHITECTURE ? ........................................................................15

BSS Network Elements ..................................................................................15

BSS Interfaces ...............................................................................................16

2.1.2.1 Um (air or radio) interface .........................................................................16

BSS ARCHITECTURE SERVICES ................................................................................18

2.2.4.1 Process for Network Architecture SETUP and EVOLUTION....................19

BSS ARCHITECTURE IMPACT IN B10 .....................................................................25

Multiple CCCH .............................................................................................25

Capacity Improvements .................................................................................27

2.3.3.1 Optimized HR connectivity .......................................................................28

STM-1 transmission in 9125 Transcoder .......................................................29

DETAILED BSS ARCHITECTURE PROCESS ................................. 30

3.1.1.1 Cell Configuration .....................................................................................34

3DF 0190 329 8010 VAZZA 02

February 18, 2009

Determination of BTS configuration ..............................................................37

3.1.3.1 SDCCH Dimensioning ..............................................................................38

ABIS INTERFACE ......................................................................................................46

Abis Configuration ........................................................................................46

3.2.1.1 Abis Network Topology ............................................................................46

16K Static Multiplexing............................................................................................................. 51

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

64K Statistical Multiplexing ...................................................................................................... 53

3.2.1.5 Secondary Abis Link .................................................................................58

Abis Dimensioning ........................................................................................61

3.2.2.1 Case #1: B9 with No GPRS/EDGE B10 with EDGE ............................62

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

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

BSC Evolution Configuration ........................................................................72

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

BSC Dimensioning ........................................................................................80

3.3.3.1 Design BSC area .......................................................................................81

3DF 0190 329 8010 VAZZA 02

February 18, 2009

3.3.4.1 LA Definition and Capacity.......................................................................85

Summary of LA/RA dimensioning process......................................................91

ATERMUX AND A INTERFACES................................................................................94

3.4.1.1 AterMUX interface....................................................................................94

3.4.2.1 AterMUX CS and A interfaces ..................................................................96

SS7 Signalling mode....................................................................................101

3.4.3.1 LSL and HSL modes ...............................................................................101

AterMUX Dimensioning ..............................................................................108

3.4.4.1 AterMUX CS ..........................................................................................108

3.4.4.2 AterMUX PS...........................................................................................112

Process description .................................................................................................................. 112

GSL Dimensioning .................................................................................................................. 115

GCH/AterMUX-PS Dimensioning .......................................................................................... 120

3.4.4.3 AterMUX CS/PS .....................................................................................122

3.5.2.1 New MT120-xB boards available ............................................................125

3.5.4.1 Functional Requirements .........................................................................127

3DF 0190 329 8010 VAZZA 02

February 18, 2009

The 1st MFS generation (A9135 MFS) .........................................................129

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

MFS Evolution (A9130 MFS) ......................................................................131

3.6.2.1 Configurations and Capacity....................................................................132