B11 BSS Arch Serv GuideLine Ed2RL

Site
Mobile Radio Division

Vlizy
Originator(s)
B11: BSS Architecture Service Guideline
E. Marza
Domain : Network Architecture

Product : GSM B11
Division : Methods
Rubric : GSM/GPRS/EDGE
Type : Guidelines
Distribution codes Internal:
Pre-distribution:
TIS Velizy TIS Timisora TIS Portugal TIS Egypt
F. Berjon Cristian I. Inta Pedro Henriques Maged Sayed
T. Plantier E. Marza Joo Frade
L.M. Palumbo
Abstract: The aim of this document is to describe BSS architecture configuration rules &
dimensioning processes in Alcatel release B11 MR1 up to Ed.2. 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; B11 release
Appraisal and approval authorities

Department Name Date Signature
TIS Manager Franois Berjon
GSM Romania Manager Ioan Inta
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

B11_BSS_arch_serv_GuideLine_Ed2.doc 3DF 01903 8110 VAZZA 02 September 24, 2010 1 1 / 189
Table of contents
1 INTRODUCTION.................................................................................. 15
2 OVERVIEW OF BSS ARCHITECTURE SERVICES ....................... 17

2.1 WHAT IS THE BSS ARCHITECTURE ? ........................................................................17
2.1.1 BSS Network Elements ..................................................................................17
2.1.2 BSS Interfaces ...............................................................................................18
2.1.2.1 Um (air or radio) interface .........................................................................18
2.1.2.2 Abis interface ............................................................................................18
2.1.2.3 AterMUX interface....................................................................................18
2.1.2.4 A interface.................................................................................................19
2.1.2.5 Gb interface...............................................................................................19
2.2 BSS ARCHITECTURE SERVICES ................................................................................20
2.2.1 Scope.............................................................................................................20
2.2.2 Goal ..............................................................................................................20
2.2.3 Category .......................................................................................................20
2.2.4 Process..........................................................................................................21
2.2.4.1 Process for Network Architecture SETUP and EVOLUTION....................21
2.2.4.2 Process for Network Architecture ASSESSMENT.....................................24
2.3 BSS ARCHITECTURE IMPACT IN B11 .....................................................................27
2.3.1 A Signaling Over IP ......................................................................................27
2.3.2 A-Flex ...........................................................................................................27
2.3.3 STM1 impact for BSC Evolution....................................................................28
2.3.4 Gb-Flex.........................................................................................................28
2.3.5 IP Flow segregation ......................................................................................28
3 DETAILED BSS ARCHITECTURE PROCESS ................................. 30

3.1 BTS ........................................................................................................................30
3.1.1 BTS Configuration.........................................................................................30
3.1.1.1 Cell Configuration .....................................................................................36
3.1.1.2 SDCCH Configuration ..............................................................................36
3.1.2 Determination of BTS configuration ..............................................................38
3.1.3 Cell dimensioning..........................................................................................39

3.1.3.1 SDCCH Dimensioning ..............................................................................39
3.1.3.2 TCH/PDCH Dimensioning ........................................................................41
3.2 ABIS INTERFACE ......................................................................................................48
3.2.1 Abis Configuration ........................................................................................48
3.2.1.1 Abis Network Topology ............................................................................48
3.2.1.2 Abis Channels ...........................................................................................50
3.2.1.3 Abis Link Capacity....................................................................................52
3.2.1.4 Signalling Sub-Multiplexing Schemes .......................................................52
3.2.1.4.1 No Multiplexing......................................................................................................................... 53
3.2.1.4.2 16K Static Multiplexing............................................................................................................. 53
3.2.1.4.3 16K Statistical Multiplexing ...................................................................................................... 54
3.2.1.4.4 64K Statistical Multiplexing ...................................................................................................... 55
3.2.1.5 Secondary Abis Link .................................................................................60

3.2.2 Abis Dimensioning ........................................................................................63
3.2.2.1 Method 1 ...................................................................................................64
3.2.2.2 Method 2 ...................................................................................................66
3.3 BSC........................................................................................................................70
3.3.1 G2 BSC Configuration ..................................................................................70
3.3.1.1 BSC Capacity ............................................................................................71
3.3.1.2 Abis TSU ..................................................................................................72
3.3.1.3 Ater TSU...................................................................................................74
3.3.2 BSC Evolution Configuration ........................................................................74
3.3.2.1 BSC Capacity ............................................................................................76
3.3.2.2 Delta BSC Evolution versus G2 BSC ........................................................77
3.3.2.3 TP GSM board ..........................................................................................78
3.3.2.4 CCP board.................................................................................................78
3.3.2.5 LIU shelf ...................................................................................................79
3.3.2.6 SS7 transport .............................................................................................79
3.3.2.7 HSL usage.................................................................................................80
3.3.2.8 The maximum ERLANG capacity, BHCA and Mean TCH duration..........82
3.3.3 New B11 features related to MxBSC..............................................................84
3.3.3.1 AsigOverIP ...............................................................................................84
3.3.3.2 A-Flex .......................................................................................................89
3.3.3.3 STM1 impact on BSC................................................................................93

3.3.3.4 IP Flow segregation at BSC level ..............................................................97
3.3.4 BSC Dimensioning ......................................................................................100
3.3.4.1 Design BSC area .....................................................................................101
3.3.4.2 Parenting Abis ports of the BSC ..............................................................103
3.3.5 LA Dimensioning.........................................................................................105
3.3.5.1 LA Definition and Capacity.....................................................................105
3.3.6 RA Dimensioning ........................................................................................109
3.3.7 Summary of LA/RA dimensioning process....................................................111
3.3.8 CCCH dimensioning....................................................................................112
3.4 ATERMUX AND A INTERFACES..............................................................................116
3.4.1 General .......................................................................................................116
3.4.1.1 AterMUX interface..................................................................................116
3.4.1.2 A interface...............................................................................................116
3.4.1.3 AterMUX interface versus A interface.....................................................116
3.4.2 AterMUX configuration...............................................................................117
3.4.2.1 AterMUX CS and A interfaces ................................................................118
3.4.2.2 AterMUX PS...........................................................................................120
3.4.2.3 AterMUX CS/PS .....................................................................................121
3.4.3 SS7 Signalling mode....................................................................................123
3.4.3.1 LSL and HSL modes ...............................................................................123
3.4.3.2 SS7 Dimensioning for TDM Mode ..........................................................123
3.4.3.3 SS7 Dimensioning for IP Mode (Asig over IP) ........................................130
3.4.4 AterMUX Dimensioning ..............................................................................133
3.4.4.1 AterMUX CS ..........................................................................................133
3.4.4.1.1 A Dimensioning....................................................................................................................... 136
3.4.4.2 AterMUX PS...........................................................................................137

3.4.4.2.1 Process description .................................................................................................................. 137
3.4.4.2.2 GSL Dimensioning .................................................................................................................. 140
3.4.4.2.3 GCH/AterMUX-PS Dimensioning .......................................................................................... 146
3.4.4.3 AterMUX CS/PS .....................................................................................148

3.5 TC ........................................................................................................................150
3.5.1 G2 TC Configuration...................................................................................151
3.5.2 G2.5 TC Configuration................................................................................151
3.5.2.1 New MT120-xB boards available ............................................................152

3.5.3 TC Dimensioning ........................................................................................153
3.5.4 STM-1 in TC................................................................................................154
3.5.4.1 Functional Requirements .........................................................................154
3.5.4.2 Overall description ..................................................................................154
3.5.4.3 TC Configuration ....................................................................................155
3.6 MFS .....................................................................................................................156
3.6.1 The 1st MFS generation (A9135 MFS) .........................................................156
3.6.1.1 GPRS Processing Unit (GPU)..................................................................157
3.6.1.2 Multiple GPU per BSS ............................................................................157
3.6.1.3 Capacity ..................................................................................................158
3.6.2 MFS Evolution (A9130 MFS) ......................................................................158
3.6.2.1 Configurations and Capacity....................................................................159
3.6.2.2 Delta MFS Evolution versus the 1st MFS generation................................160
3.6.3 GP(U) Dimensioning and AterMux PS dimensioning (user traffic) ..............162
3.6.3.1 Required GCH traffic estimation .............................................................165
3.6.3.2 GP(U) GCH capacity estimation..............................................................167
3.6.3.3 GP(U) limitations ....................................................................................169
3.7 GB INTERFACE .......................................................................................................174
3.7.1 Gb configuration .........................................................................................176
3.7.2 Gb Dimensioning ........................................................................................178
3.7.2.1 Gb over Frame Relay...............................................................................179
3.7.2.2 Gb over IP ...............................................................................................180
3.7.3 Gb-Flex.......................................................................................................183
3.7.4 IP Flow segregation at MFS level ...............................................................187

INDEX OF FIGURES
Figure 1: BSS Architecture...................................................................................................17
Figure 2: TRX configuration on Um interface.......................................................................18
Figure 3: Abis configuration.................................................................................................18
Figure 4: AterMUX configuration Dedicated AterMUX for CS traffic...............................19
Figure 5: A-interface configuration.......................................................................................19
Figure 6: BSS Architecture Services.....................................................................................20
Figure 7: Network Architecture Setup and Evolution process ...............................................21
Figure 8: BSC/LAC/RAC (re) design - example ...................................................................22
Figure 9: Abis TSU port (re) design......................................................................................24
Figure 10: Network architecture assessment process.............................................................25
Figure 11: BTS generation/type supported in B11..............................................................30
Figure 12: BTS Architecture report from AMT.NET ............................................................35
Figure 13: Determination of BTS configuration....................................................................38
Figure 14: SDCCH dimensioning process.............................................................................40
Figure 15: TCH/PDCH dimensioning process.......................................................................43
Figure 16: TCH/PDCH dimensioning assessment .................................................................46
Figure 17: Abis Chain (Multi-drop) Topology ......................................................................48
Figure 18: Abis Star Topology..............................................................................................49
Figure 19: Abis Ring (Closed loop) Topology ......................................................................49
Figure 20: Secondary Abis Topology....................................................................................50
Figure 21: TRX - Abis mapping ...........................................................................................50

Figure 22: Example of Abis TS usage for 1 BTS/4 TRX No Multiplexing .........................53
Figure 23: Example of Abis TS usage for 1 BTS/4 TRX 16K Static Multiplexing .............54
Figure 24: 16K Statistical Multiplexing MCB 16/1 mapping .............................................54
Figure 25: Example of Abis TS usage for 1 BTS/4 TRX 16K Statistical Multiplexing .......55
Figure 29: Example of Abis TS usage for 1 BTS/4 TRX 64K Statistical Multiplexing .......56
Figure 30: Abis TS configuration on primary and secondary links ........................................60
Figure 31: BTS with 24 TRX mapped on both Abis links .....................................................60
Figure 32: Example of topology with two BTS chained ........................................................61
Figure 33: Two Abis links filling examples. .........................................................................61
Figure 34: Abis dimensioning process Method 1................................................................65
Figure 35: Abis dimensioning process Method 2................................................................67
Figure 36: G2 BSC (A9120 BSC) Architecture.....................................................................70
Figure 37: G2 BSC Cabinet layout .......................................................................................71
Figure 38: Abis TSU G2 BSC............................................................................................72
Figure 39: Ater TSU G2 BSC ............................................................................................74
Figure 40: BSC Evolution (A9130 BSC) HW Architecture...................................................75
Figure 41: Abis and Ater allocation on LIU boards / BSC capacity.......................................79
Figure 42: Asig Over IP Architecture ...................................................................................85
Figure 43: SS7 protocol stack (SIGTRAN)...........................................................................85

Figure 44: Connections between the BSC and MSC Servers .................................................86
Figure 45: Multi-homing on MSC side .................................................................................88
Figure 46: Multi-homing on BSC side ..................................................................................88
Figure 47: A-Flex Architecture.............................................................................................89
Figure 48: Example of a TMSI structure with 7 bits NRI-length ...........................................92
Figure 49: TP-STM1 architecture .........................................................................................94
Figure 50: TPGSMv3 STM1 board.......................................................................................95
Figure 51: Network Architecture with STM1........................................................................96
Figure 52: Mx-BSC in one LAN configuration with one external subnet ..............................98
Figure 53: Mx-BSC in one LAN configuration with two external subnets.............................99
Figure 54: BSC dimensioning process ................................................................................100
Figure 55: BTS position & configuration design BSC area step 1 ....................................101
Figure 56: Transmission planning & BSC position design BSC area step 2......................102
Figure 57: BSC area definition design BSC area step 3....................................................102
Figure 58: Transmission load checking...............................................................................103
Figure 59: BTS / Abis parenting on BSC done by AMT.NET ..........................................104
Figure 60: LA dimensioning assessment.............................................................................108
Figure 61: Subdivision of a LA in GPRS routing areas (RA) ..............................................109
Figure 62: AterMUX and A relationship.............................................................................116
Figure 63: AterMUX interface structure .............................................................................117
Figure 64: AterMUX CS interface configuration G2 BSC................................................118
Figure 65: Channel mapping between AterMUX CS and A ................................................119

Figure 66: AterMUX PS interface configuration - GPU ......................................................120
Figure 67: Sharing AterMUX links.....................................................................................121
Figure 68: AterMUX CS/PS Timeslot configuration...........................................................122
Figure 69: SS7 message length (in bytes) according to GSM event.....................................124
Figure 70: Difference between Exact busy hour, NPO busy hour and Peak traffic...............126
Figure 71: IP packet structure for Asig over IP ...................................................................131
Figure 72: Method for Asig over IP dimensioning ..............................................................132
Figure 73: AterMUX-CS dimensioning process..................................................................134
Figure 74: AterMux-PS dimensioning process at BSC level ...............................................138
Figure 75: AterMux-PS dimensioning process at GP(U) level ............................................138
Figure 76: GSL dimensioning method ................................................................................140
Figure 77: GSL messages processing..................................................................................142
Figure 78: GSL dimensioning process ................................................................................143
Figure 79: GSL usage factor ...............................................................................................144
Figure 80: TC G2 architecture with mixed configuration ....................................................150
Figure 81: TC G2.5 architecture .........................................................................................151
Figure 82: TC dimensioning process...................................................................................153
Figure 83: The BSS Architecture with STM-1 on TC side ..................................................155
Figure 84: The 1st MFS generation (A9135 MFS) Architecture...........................................156
Figure 85: Multiple GPU per BSS ......................................................................................157
Figure 86: MFS Evolution (A9130 MFS) HW Architecture................................................159
Figure 87: MxMFS rack configurations ..............................................................................159

Figure 88: MFS capacity ....................................................................................................160
Figure 89: GP(U) dimensioning process .............................................................................163
Figure 90: AterMux PS dimensioning process based on user traffic....................................164
Figure 91: Example of GCH/PDCH traffic relationship in case of AterMux PS

underdimensioning.......................................................................................................166
Figure 92: GCH vs. PDCH traffic relationship: example.....................................................167
Figure 93: Evolution of MS context number on GP(U) .......................................................170
Figure 94: GPU_for_MS_context_handling due to PMU memory limitation ......................170
Figure 95: GPU_for_Power_Limitation due to PMU CPU load ..........................................171
Figure 96: GPU_for_Power_Limitation due to DSP CPU load ...........................................171
Figure 97: Gb interface configuration (from 3BK 09559 LAAA EBZZA) ..........................175
Figure 98: Gb interface connections ...................................................................................176
Figure 99: GboIP End-to-End architecture .......................................................................177
Figure 100: Gb dimensioning process.................................................................................178
Figure 101: Gb-Flex Architecture .......................................................................................183
Figure 102: LA, RA and SGSN pool ..................................................................................184
Figure 103: P-TMSI structure with NRI length set to 5. ......................................................186
Figure 104: P-TMSI and TLLI............................................................................................186
Figure 105: Mx-MFS in one LAN configuration with one external subnet ..........................188
Figure 106: Mx-MFS in one LAN configuration with two external subnets ........................189

INDEX OF TABLES
Table 1: BSC-MFS/GP(U)-TC (re) design............................................................................23
Table 2: Configuration Evolium BTS ................................................................................31
Table 3: Configuration Evolium Evolution ........................................................................31
Table 4: BTS HW Capability in B11 ....................................................................................32
Table 5: TRX HW capability since G3 BTS generation ........................................................33
Table 6: Cell Types ..............................................................................................................36
Table 7: Frequency Hopping supported in B11 .....................................................................36
Table 8: Recommended SDCCH configuration for a standard cell only FR TRXs.............37
Table 9: Counter list - SDCCH dimensioning .......................................................................39
Table 10: Counter list - TCH dimensioning ..........................................................................41
Table 11: Counter list - PDCH dimensioning........................................................................42
Table 12: RLC data block size for each (M) CS....................................................................47
Table 13: Abis Channel Types..............................................................................................51
Table 14: Number of TS available in one Abis link ..............................................................52
Table 15: Abis occupation according to the number of FR TRX ...........................................57
Table 16: Counter list - Abis dimensioning Method 1...........................................................64
Table 17: Counter list - Abis dimensioning Method 2. ..........................................................67
Table 18: G2 BSC Capacity..................................................................................................71
Table 19: G2 BSC Capacity in TCU Number and ExtraAbisTSs ..........................................71
Table 20: TSL/TCU Mapping...............................................................................................73
Table 21: BSC Evolution Capacity .......................................................................................76

Table 22: Max BSC Paging rates ..........................................................................................77
Table 23: AsigOverIP limits .................................................................................................87
Table 24: A-Flex limits.........................................................................................................91
Table 25: Possible LAN configurations ................................................................................99
Table 26: Parameter values for IP flow segregation feature activation...................................99
Table 27: Counter list LA dimensioning ..........................................................................105
Table 28: Counter list RA dimensioning ..........................................................................109
Table 29: CCCH capacity ...................................................................................................112
Table 30: Counter list LA dimensioning ..........................................................................112
Table 31: Max number of AterMUX CS interfaces G2 BSC ............................................119
Table 32: Max number of A-interfaces G2 BSC...............................................................120
Table 33: Max number of AterMUX PS G2 BSC .............................................................121
Table 34: Ratio of Mixing CS and PS Traffic in AterMUX.................................................122
Table 35: Signaling link requirements for MxBSC .............................................................124
Table 36: Counter list AterMUX-CS dimensioning..........................................................125
Table 38: Counter list Asig over IP dimensioning ............................................................130
Table 39: Overheads for Asig over IP.................................................................................131
Table 40: Counter list for Asig over IP traffic in UL and DL ..............................................132
Table 42: Counter list GSL dimensioning ........................................................................141

Table 45: G2 TC/ G2.5 TC capabilities...............................................................................150
Table 46: G2 TC configuration...........................................................................................151
Table 47: G2.5 TC configuration ........................................................................................152
Table 48: G2.5 TC capacity ................................................................................................152
Table 49: The 1st MFS generation (A9135 MFS) Capacity .................................................158
Table 50: MxMFS configuration and connectivity ..............................................................160
Table 51: MFS Capacity evolutions....................................................................................161
Table 52: GP(U) Capacity limitations.................................................................................161
Table 53: Counter list - GP(U) dimensioning......................................................................163
Table 54: PDCH number per GP(U) in radio conditions .....................................................168
Table 55: GCH usage depending in coding schemes ...........................................................168
Table 56: Counter list for TBF load assessment ..................................................................172
Table 57: Counter list for TBF assessment per cell .............................................................173
Table 58: Counter list - Gb dimensioning ...........................................................................178
Table 59: Possible LAN configurations ..............................................................................189
Table 60: Parameter values for IP flow segregation feature activation.................................189

History:
Edition Date Originator Comments
Draft 05/10/09 Eugen Marza Creation from B10 version
Ed1 15/01/10 Eugen Marza Update of B11 draft
Ed2 30/08/10 Eugen Marza Update of Ed1
References:
[1] 3BK 17438 5000 PGZZA BSS Configuration Rules release B11
Enhanced Transmission Resource Management
[2] 3BK 10204 0608 DTZZA
Release B9
[3] 3BK 11210 0157 DSZZA G3 BTS Architecture and Principles
[4] 3BK 11210 0328 DSZZA BTS G4 Architecture and Principles
[5] 3DC 21083 0001 TQZZA EVOLIUM A9100 Base Station Product description
[6] 3BK 10204 0511 DTZZA SFD: Dynamic SDCCH allocation
[7] 3DF 01903 2810 PGZZA BSS B8 Dimensioning Rules
Dimensioning Rules for CS and PS traffic with BSS
[8] 3DC 20003 0031 UZZZA
Software Release B11 (TDM transport)
GSM/GPRS/EDGE Radio Network Design Process for
[9] 3DC 21150 0348 TQZZA
ALCATEL BSS Release B11
[10] 3DC 21016 0005 TQZZA A9135 MFS Product Description
[11] 3DF 00995 0005 UAZZA GPRS/E-GPRS Radio Network Planning Aspects
[12] 3BK 11203 0100 DSZZA GPRS resource usage and dimensioning B8 release
[13] 3BK 09722 JAAA DSZZA GPRS management functional specification
[14] 3BK 11206 0476 DSZZA BSC abbreviations Release B9
[15] 3DF 019038010 VAZZA B10: BSS Architecture Service Guideline
[16] 3DC 21144 0120 TQZZA Gb over IP in Release B10
[17] 3BK 10204 0028 DTZZA Multiple CCCH
[18] 3BK 10204 0101 DTZZA A Signaling over IP
[19] 3BK 10204 0099 DTZZA A-Flex
[20] 3BK 10204 0068 DTZZA STM-1 impact for BSC Evolution
[21] 3BK 10204 0115 DTZZA Gb Flex
Abbreviations:
Refer to [14].

1 INTRODUCTION
The aim of this document is to describe BSS architecture configuration rules &
dimensioning processes in Alcatel release B11 MR1.
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 B11MR1 impacts to BSS architecture.
Part II: Detailed BSS Architecture Processes

This part describes in the details of the main network configuration rules in release
B11 MR1 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 B9 to B10 release is not detailed in this
document (please refer to [15] document).
What is new in this document

HW changes:
- Starting with B11, there is no more support for G1 and G2 BTSs.
- From B11 a new class of TRE called Multi-Carrier-module (or MC-TRE) is
supported.
- The MFS AS800 is no more supported in B11.

New B11 features related to MxBSC:
- A Signalling over IP, for transporting SS7 signaling over the IP network between the
BSC and NGN core network.
- A-Flex network architecture, allowing a BSC to be connected to more than one MSC.
- STM1 connectivity.
- IP Flow segregation in MxBSC, using several routers to allow better flexibility
between the different IP flows (O&M and Asig over IP).
New B11 features related to MFS:

- Gb-Flex network architecture, allowing a BSS to be connected to more than one
SGSN (B11 MR1 ed.2).
- IP Flow segregation in MxMFS, using several routers to allow better flexibility
between the different IP flows (O&M and Gb over IP).
New dimensioning methods:

- The maximum ERLANG capacity, BHCA and Mean TCH duration,
- SS7 Dimensioning for IP Mode (Asig over IP).
- GSL Dimensioning based on new GSL counters (B11 optional feature).
- Gb over IP Dimensioning update.

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
BTS A NSS
AterMUX CS (CS traffic)
BTS BSC AterMUX CS/PS TC
MFS Gb
AterMUX PS
BTS
GSS
(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.
1 MSC (Mobile Switching Center) is a main network element of the NSS having connection to the BSS.

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 CH# 2 CH# 3 CH# 4
TS 0 T S 0 T ra ns p a re n cy
TS 1 F ree
: :
: :
TS 26 E xtra TS
TS 27 E xtra TS
TS 28 T C H / GC H TCH / G CH TCH / GCH TCH / GCH Mapping to 1 TRX
TS 29 T C H / GC H TCH / G CH TCH / GCH TCH / GCH of Um Interface
TS 30 R SL
TS 31 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)

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.
AterMUX CS
CH# 1 CH# 2 CH# 3 CH# 4
TS 0 Frame Synchronization
TS 1 TCH TCH TCH TCH
: :
: :
TS 14 Qmux TCH TCH TCH
TS 15 Alarm octet
TS 16 SS7
: :
: :
TS 31 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 0 Frame Synchronization
TS 1 CIC 1
TS 2 CIC 2
TS 3 CIC 3
: :
: :
: :
: :
TS 30 CIC 30
TS 31 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.

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

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

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.4.1 for BSC area design, section 3.3.5 for
LAC design and section 3.3.6 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.

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 G2 TC, G2.5 TC
MFS (A9125 Compact TC)
Configuration - Conf 1, 2, 3, 4, 5 or 6 for Nb of GP(U) boards - Nb of TC boards
A9120 BSC dedicated to each dedicated to each BSC
BSC
- Stand Alone / Rack shared - Nb of TC racks
configuration with 200, 400, Nb of MFS racks
600, 800 or 1000 TRX for
A9130 BSC
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 3.6 for MFS configuration.
(2c) Number of interfaces; Abis, AterMUX, A and Gb

After the configuration of all BSS network elements is defined, it comes to the step to
design interfaces connecting them.
In general, we have to design the number of needed interface links.
However, additional characteristic has to be designed for some interfaces:
Abis: Type of signalling sub-multiplexing schemes, BTS in multidrop and number
of extra Abis TS (in case of supporting GPRS CS3-4 and EDGE).
AterMUX: Type of Traffic i.e. CS, PS or Mixed CS/PS.
Gb: Number of 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 & A-
interface 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).
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://gtp.tm.alcatel.ro/index.php
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).
- 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

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.4)
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.1)
Gb dimensioning (for more details, please refer to section 3.7.2)
Step (3) Assessment

This is the last process to assess the installed capacity versus used capacity (refer to the
traffic analysis results from step 2), based on the recommendation and given threshold at
all levels of the BSS.
The assessment can identify the existing bottleneck that implies the lack of resources or
unbalanced resource usage.
Therefore, the proposed solutions should be implementing new resources and/or new
configuration and probably parameter modification.

2.3 BSS Architecture Impact in B11
In B11 release, there are several improvements in term of architecture point of view.
These improvements are related to the introduction of new features as follows:
A Signaling Over IP (B11 MR1)
A-Flex (B11 MR1)
STM1 impact for BSC Evolution (B11 MR1)
Gb-Flex (B11 MR1ed.2)
2.3.1 A Signaling Over IP

The purpose of this feature is to transfer the SS7 signaling over the IP network between the
BSC and NGN core network. This is a GSM BSS B11MR1 feature.
A Signalling Over IP supports BSC to be connected to multi MSCs.
The feature is an optional feature and the A-signalling over TDM is still supported. TDM
mode and IP mode are exclusive.
The basic idea is to separate the control plane and user plane in the core network. The legacy
MSC is replaced by MSC server (control plane) and MGW (user plane).
A signaling over IP is implemented for MSC server in the NGN network.

A signaling is not working on TDM and IP in the same time.
Benefits:
Extends the IP based transport on the control plane down to the BSC and supports the
general trend to IP based inter-connection layers;
Provides a high flexibility for BSS to connect to NGN;
Makes the introduction of the A-flex functionality much easier and future proof than the
combination of A-flex with TDM transport;
Limited interoperability issues are expected between BSC and MSC Server as SIGTRAN
is already used in NGN;
Feature complements also the Alcatel-Lucent native IP transport in the BSS
2.3.2 A-Flex
A-Flex network architecture is specified by 3GPP TS 23.236 and this feature allows a BSC
connecting to more than one MSC. This is a GSM BSS B11 MR1 feature.
Benefits:
Reduction of the signalling load in the core network: Signalling between the MSC/VLR
and HLR due to Location Update and inter-MSC handover procedure become necessary
only when MS leave the CS pool area;
Better MSC resilience: with A-Flex feature a BSC can be connected to several MSC
Servers for the handling of A-signalling. As a consequence if an MSC Server fails the

remaining MSC Servers can take over new service requests and maintain the service
availability;
Better signalling load balancing between MSC Servers;
Easier Core network expansion: if the core network capacity needs to be increased, there
is no need any more to reconfigure the radio network. The existing LA/RA configuration
can be kept. It is sufficient to add a new MSC to the CS pool area with the same radio
configuration as the other MSCs of this CS pool area.
2.3.3 STM1 impact for BSC Evolution

The STM-1 interface is an alternative to the TDM transport mode in order to decrease the cost
of the transport in BSS. This feature is offered only for A9130 BSC Evolution and four STM1
(155Mb/s) optical interfaces can be connected on the front plate of the new TPGSMv3 board.
Each STM-1 includes 63 channels (VC12) which can include an E1 of 2048 kbps, so one
STM-1 can carry 63 Abis and/or Ater, each E1 is transported separately on one VC12
container. This is a GSM BSS B11MR1 feature.
Benefits:
Reduce cost on interface equipment to SDH network: removal of E1 to STM-1 boards to
connect the TC and BSC to the SDH network and new NGN (CAPEX saving);
Reduce drastically time/error of installation/cabling (OPEX saving);
Reduce the space needed for cables and distribution frames (OPEX saving);
Simplify cabling & assignment changes: modification of routing of a VC12 can be done
remotely by computer command, as there is no cabling change (OPEX saving);
Increase the reliability and availability: STM-1 connectivity provides excellent
availability thanks to the combination of APS & EPS, as well as it benefits from the
reliability of SDH network architecture (OPEX saving)
2.3.4 Gb-Flex
Gb-Flex feature allows a BSS to be connected to more than one SGSN. This is a GSM BSS
B11 MR1ed.2 feature.
Benefits:
Load sharing can be done by the BSS for each SGSN where the BSS is connected.
Possibility of capacity upgrades by additional SGSN in the pool-area
Increase the reliability when an SGSN fails thanks to SGSN redundancy.
To have several SGSN allow to enlarge the served area and the reduction of signalling
within the core network (e.g. reduction of the HLR signalling traffic)
Possibility to off-load an SGSN to perform maintenance
CAPEX reduction thanks to load distribution on the SGSN of the pool.
2.3.5 IP Flow segregation

This feature provides the flow segregation at layer 1 (same or different physical ports for the
different flows). IP Flow segregation feature is available for MxBSC and MxMFS.
The feature is allowing several routers to be used for improved flexibility between the
different IP flows (O&M and A SigoIP at BSC level, or O&M and Gb over IP at MFS level).

The 9130 BSC Evolution has flexible mapping of O&M / A SigoIP flows onto GE ports
starting with B11 MR1.
The 9130 MFS Evolution has flexible mapping of O&M / GBoIP flows onto GE ports starting
with B11 MR1.
An external subnet is visible from the IP network.
This external subnet may be split into two external subnets: one for O&M and another for
Telecom.
Moreover the telecom traffic can be split itself in different subnets (only starting with
BSSoverIP introduction in B11 MR3).
The result is: Physical IP Flow Segregation
The flow segregation is physical, that is to say it is obtained by dedicating one MFS
switch Ethernet port per flow to segregate.
Its based on the operator request.
Separate routers may be used to allow better flexibility between the different IP flows
(O&M and Telecom).
The IP traffic without router (L2 networks) is also allowed, the flow segregation and
BSC/MFS internal VLAN tag configuration applying to both L2 and L3 cases.
Benefits:
To allow better flexibility and dimensioning from end to end per IP telecom flow with
excluding the impact of a flow on the other.
Having better organization in terms of separate teams working independently on each
telecom flow.
Allows for segregation at L1, which allows also for L2 segregation as a workaround due
to lack of VLAN tagging in BSC/MFS and the need for an external router.

3 Detailed BSS Architecture Process
This section describes in details of the BSS architecture process in release B11.
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 B11.
BTS
Generation
Evolium BTS Evolium Evolution
G3 BTS G4 BTS
M4M M5M
GPRS GPRS CS-1 to CS-4

CS-1 to CS-4 EDGE MCS-1 to MCS-9
Figure 11: BTS generation/type supported in B11
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

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 2.
Extension/Reduction
Configuration
BTS Physical Logical
Min Max Min
Evolium BTS
1 TRE Up to 18 TRE (1 to 6 sectors) 1 TRE TRE
(G3 / G3.5)
M4M
2 TRE Up to 6 TRE (1 to 6 sectors) 2 TRE 1 TRE
(micro BTS)
Data in this table, based on [1]
Table 2: Configuration Evolium BTS
For more details, please refer to [1] and [5] .
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.
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 and Multi-Carrier TRX modules
Their configurations are presented in Table 3.
Extension/Reduction
Configuration
BTS Physical Logical
Min Max Min
Evolium BTS
(G3.8 / G4.2)
Evolium BTS
(G5)
M5M
(micro BTS)
Table 3: 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], [4], [5].
Summary BTS Hardware Capability B11 release

As shown in Table 4:
B11 Release Evolium BTS Evolium Evolution BTS

G3 BTS M4M G4 BTS M5M
No Multiplexing X X X X
16K Static Multiplexing X X X X
Abis feature
64K Statistical Multiplexing X X X X

16K Statistical Multiplexing X X X X
2nd Abis access X X X
FR X X X X
DR X X X X
Traffic
Voice
AMR X X X X
EFR X X X X
GPRS (CS-1, CS-2) X X X X
Traffic
GPRS (CS-3, CS-4) X X X X

Data
EGPRS (MCS-1 to MCS-9) X X

GSM 850 X X
Mono band
GSM 900 X X X X
GSM 1800 X X X X
GSM 1900 X X X
850/1800 X X X
850/1900 X X X
band
Multi
900/1800 X X X X
900/1900 X X X

Table 4: BTS HW Capability in B11
Important Note:
In B10, G1 and G2 BTSs with DRFU were still supported.
Starting with B11, there is no more support for G1 and G2 BTSs.

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)
The following table describes the transceiver hardware since G3 BTS generation.
Generation TRE Type MNEMO EDGE
G3 TRX 900 35W DR-EFR 9100 TRGM No
G3 TRX 1800 35W DR-EFR 9100 TRDM No
G3 TRX 1800 60W DR-EFR 9100 TRDH No
G4 9100 TRX 900 EDGE COMPATIBLE TRAG Yes
G4 9100 TRX 1800 EDGE COMPATIBLE TRAD Yes
G4 9100 TRX 850 EDGE COMPATIBLE TRAL Yes
G4 9100 TRX 1900 EDGE COMPATIBLE TRAP Yes
G4 9100 TRX 900 HP EDGE COMPATIBLE TAGH Yes
G4 9100 TRX 1800 HP EDGE COMPATIBLE TADH Yes
G4 9100 TRX 900 EDGE PLUS TRAGE Yes
G4 9100 TRX 1800 EDGE PLUS TRADE Yes
G4 9100 TRX 900 HP EDGE PLUS TAGHE Yes
G4 9100 TRX 1800 HP EDGE PLUS TADHE Yes
G5 9100 TRX 900 TWIN TGT09 Yes
G5 9100 TRX 900 MULTICARRIER TMXA09 Yes
G5 9100 TRX 1800 MULTICARRIER TMXA18 Yes
Table 5: TRX HW capability since G3 BTS generation

MC-TRE
From B11 a new class of TRE called Multi-Carrier-module (or MC-TRE) is supported.
The Multi-Carrier-TRE can be hosted in a standard A9100 Evolium BTS with all BTS
modules (SUM, AN, Single Carrier TRE, TWIN) or is full part of a new outdoor box called
distributed BTS (with a central box containing the SUM and the connection to the outside
world).
A multi-carrier TRE is a module, which has one power amplifier, able to transmit
simultaneoulsy several carriers, and a dual receiver, able to receive simultaneoulsy several
carriers. A carrier is a GSM carrier (as defined in 3GPP 45.005) and or a W-CDMA, LTE (or
other system) carrier.
MC-TRE provides a new platform to offer all the GSM features of the current evolium
products with at least the same performance, at a lower shop cost (except small
configurations). The MC-TRE is intended as a replacement for the majority or all the current
products.
The MC-TRE is also intended as a solution for operators, which want to add LTE (or other
systems), sooner or later, in the existing GSM bands without the need to install additional
antennas and feeders.
The MC-TRE is further foreseen for LTE-only deployments, where an addition of GSM
later cannot be excluded or where the high power of the MC-TRE is demanded, or where the
low emissions outside the LTE band are advantageous.
The MC-TRE provides
Simultaneous transmission and diversity reception of up to 6 GSM carriers
FDD operation
additionally simultaneous transmission and diversity reception of 1 LTE (or other
systems) carrier
instantaneous bandwidth of 20 MHz (at least 15 MHz)
arbitrary allocation of the output power to the carriers
power pooling with per slot conflict resolution (e.g. priority based)
variable and selective clipping (i.e. clipping can be different for different carriers, and
the amount of clipping can change e.g. slot by slot)
good efficiency in fully, partially and low loaded conditions, with any number of
carriers
an output power which is in 2, 4 and 6 carrier configuration at least as high as an
equivalent configuration using single carrier TREs with 45W output power and two
transmit antennas
a sensitivity which is at least as good as a single carrier TRE provides
the baseband and control processing for 6 GSM carriers, with all radio features
required
all usual GSM features (channels, modulations, hopping up to edge evolution, incl.
Higher symbol rate and higher order modulation)
reasonable processing power and memory spare for future GSM evolutions
two modules provide up to 12 TRX in a cell. Configurations with more MC-TRE are
also possible.
Features requiring access to more than one MC-TRE per sector (such as antenna
hopping, Tx diversity, 4 Rx, wideband hopping).
Behaviour on interfaces towards the BSS must be as much as possible compatible with
existing Evolium BTS.

An example of BTS graphical report generated with AMT.NET (Architecture
Management and Traffic tool) is shown in picture below.
BTS Architecture REPORT

BTS_540018_1
BTS General Information

Label Identifier BTS Generation Related BSC
BTS_540018_1 { amecID 6, moiRdn 4} evolution BSC_570025_2
AlcatelCircuitPackInstanceIdentifier CircuitPackType RelatedTRXList RelatedFunctionList
Sector 6 4 1 TRX 3; 6 6 918015;

{ equipmentHolderID { ameID { amecID 6,
tmxa09 Sector 6 4 1 TRX 2; 6 6 918271;
moiRdn 6}, rackRdn 1,shelfRdn 1}, moiRdn 10}
Sector 6 4 1 TRX 1 6 6 919551
{ equipmentHolderID { ameID { amecID 6, Sector 6 4 2 TRX 1; 6 6 918527;

tmxa09
moiRdn 6}, rackRdn 1,shelfRdn 3}, moiRdn 10} Sector 6 4 2 TRX 2 6 6 918783
{ equipmentHolderID { ameID { amecID 6, Sector 6 4 3 TRX 2; 6 6 919039;

tmxa09
moiRdn 6}, rackRdn 1,shelfRdn 5}, moiRdn 1} Sector 6 4 3 TRX 1 6 6 919807
BTS_Sector ID LAC CI UserLabel

641 3800 5418 Melville_1
642 3800 15418 Melville_2
643 3800 761 Melville_3
Figure 12: BTS Architecture report from AMT.NET
This BTS is using only 3 MC-TRX to cover 3 cells in the configuration 3/2/2. In case of
traffic increase, it is easy to be extended up to 6/6/6 just using software configuration.

3.1.1.1 Cell Configuration
Cell Types: the following table describes all the cell types (with profile type
parameters) available in B11.
Profile Type Parameters

Cell Type
Dimension Coverage Partition Range
Micro Micro Overlaid Normal Normal
Single Macro Single Normal Normal
Mini Macro Overlaid Normal Normal
Extended Macro Single Normal Extended
Umbrella Macro Umbrella Normal Normal
Concentric Macro Single Concentric Normal
Umbrella-Concentric Macro Umbrella Concentric Normal
Indoor Micro Micro Indoor Normal Normal
Table 6: Cell Types
Extended Cell:
Its configuration is a BTS with up to 4 TRX in the inner cell and up to 4 TRX in the outer cell.
M4M and M5M do not support extended cell configurations.
Only one extended cell per BTS is possible.
Shared Cell:
A cell shared by several BTSs is possible to support up to 16 TRX (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 7 shows the hopping types supported in B11.
Hopping Type Supported in B11
Non Hopping (NH) X
Base Band Hopping (BBH) X
Radio Hopping (RH) * -
Non Hopping / Radio Hopping (NH/RH) X
NH/RH with Pseudo Non Hopping TRX X
BBH with Pseudo Non Hopping TRX X
* RH works only with M1M and M2M that are now obsolete.
Table 7: Frequency Hopping supported in B11
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.
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 8.

Number of SDCCH sub-channels
Number of TRXs BCCH Combined
Total SDC SDD
1 Yes 12 4 8
2 Yes 12 4 8
2 No 24 8 16
3 No 24 8 16
4 No 32 8 24
5 No 32 8 24
6 No 32 8 24
7 No 40 16 24
8 No 40 16 24
9 No 48 16 32
10 No 48 16 32
11 No 48 16 32
12 No 56 16 40
13 No 56 16 40
14 No 64 24 40
15 No 72 24 48
16 No 72 24 48
Table 8: Recommended SDCCH configuration for a standard cell only FR TRXs

Remarks:
1) SDC means Static SDCCH, SDD means Dynamic SDCCH, and Max presents the
maximum number of SDCCHs (SDC+SDD) that may be allocated in a cell.
2) Up to 16 TRXs are possible to be configured for a cell thanks to shared cell feature.
3) For one TRX, dynamic SDCCH are over-dimensioned because of the granularity of 8.
According to Alcatel traffic model, all dynamic SDCCH will not be used.
4) An additional dynamic SDCCH/8 must be provided for each DR TRX (these are
expected mainly on small cells).
5) For some particular cells with high (LU and/or SMS) 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).
For more details, please refer to [1] and [6].
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 13.
Nb of required TRXs Max. Capacity of

Nb of required cells the given BTS
Nb of required BTSs Nb of installed BTSs
Required > Assessment Required <

(comparision)
Required =
Under-dimensioning Over-dimensioning
Increase installed BTSs OK Decrease installed BTSs
Figure 13: 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.
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 9: 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 14.
INPUT METHOD OUTPUT
Required
SDCCH Traffic Nb of required
Erlang B SDCCH sub-
channels /
GoS: timeslots
% SDCCH blocking
Figure 14: SDCCH dimensioning process
INPUT
The required SDCCH traffic is computed as below formula.
Measured _ SDCCH _ traffic
Re quired _ 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.
Where:
MC 400
Measured _ SDCCH _ traffic =
3600
MC 04
% SDCCH _ cong = 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.
3.1.3.2 TCH/PDCH Dimensioning

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

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 10: Counter list - TCH dimensioning
Gathered Counters: PDCH

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+ GTRDTERQN Number of DL TBF establishment requests per cell.
P91d+P91e+P91f+
P505
P62a+P62b+P62c- GTRUTERQN Number of UL TBF establishment requests per cell.
P438c + P507
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 GQRPDDRxN In acknowledged mode, number of DL RLC data blocks
(x = ad) (except RLC blocks containing LLC Dummy UI Commands
(x = 1,.. ,4)
only) on PDTCH encoded in (M)CS-x (i.e. CS-1 (P20a)
CS-4 (P20d)) retransmitted due to unacknowledgement of the
MS.
P20f+P20g+P20h+ GQRPDDRMN In acknowledged mode, number of DL RLC data blocks
P20i+P20j+...+P20n (the indicator encoded in all MCS-x and retransmitted due to
(x = fn) gives the result unacknowledgement of the MS. RLC blocks containing LLC
directly in bytes) dummy UI commands are not counted.
P21x GQRPDURxN In acknowledged mode, number of UL RLC data blocks on
(x = ad) PDTCH encoded in (M)CS-x (i.e CS-1 (P21a) CS-4
(x = 1,.. ,4)
(P21d)) retransmitted due to unacknowledgement of the MFS.
P21f+P21g+P21h+ GQRPDURMN In acknowledged mode, number of UL RLC data blocks
P21i+P21j++P21n (the indicator encoded in all MCSx and retransmitted due to
(x = fn) gives the result unacknowledgement of the MFS.
directly in bytes)
P55x GTRPDDCxN Number of useful DL RLC blocks sent in RLC acknowledged
(x = a,.. ,m) (x = 1,.. ,4) mode on PDTCH encoded in (M) CS-x i.e. CS-1 (P55a)
GTRPDDMyN CS-4 (P55d) and MCS-1 (P55e) MCS-9 (P55m).
(y = 1,.. ,9)
P57x GTRPDUCxN Number of useful UL RLC blocks received in RLC
(x = a,.. ,m) (x = 1,.. ,4) acknowledged mode on PDTCH encoded in (M) CS-x i.e. CS-
GTRPDUMyN 1 (P57a) CS-4 (P57d) and MCS-1 (P57e) MCS-9
(y = 1,.. ,9) (P57m).
Table 11: 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 OUTPUT
CS service
input data Total
Kaufmann-
Robert required TS
Algorithm for TCH and
PS service PDCH
input data
Figure 15: TCH/PDCH dimensioning process
INPUT
(1) CS service input data:
CS Traffic Intensity in Erlang:
The CS traffic intensity is calculated separately between Full Rate (FR) and Half
Rate (HR) Traffic.
The calculation will take into account the real measured traffic and additional margin
from congestion rate.
The way to calculate the congestion rate for FR and HR is presented below:
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.
RTCH_Assign _ Cong MC812

CS_Real_Cong_Per = =
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.
MC 380a
FR _ Cong _ Per = CS _ Cong _ Per
MC 380a + MC 380 b
MC 380 b
HR _ Cong _ Per = CS _ Cong _ Per
MC 380a + MC 380 b

Then,
Full Rate CS traffic Intensity is:
FR _ Successful _ Traffic MC 380acell
FR = =
1 FR _ Cong _ Per 3600 ( 1 FR _ Cong _ Per )
Half Rate CS traffic Intensity is:

HR _ Successful _ Traffic MC 380bcell
HR = =
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
(2) PS service input data:

PS Traffic Intensity in Erlang:
The required PS traffic intensity is computed as below formula.
Measured _ PS _ traffic
Re quired _ PS _ traffic =
1 Min(%TBF _ radio _ cong , 30%)
Where:
P 451b
Measured _ DL _ PS _ traffic =
3600
P 451a
Measured _ UL _ PS _ traffic =
3600
P14
%DL _ TBF _ radio _ cong = 100 %
P 91a + P 91b + P 91c + P 91d + P 91e + P 91f + P 505
P 27
%UL _ TBF _ radio _ cong = 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.
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 Nb of installed
TCH/PDCH TSs TCH/PDCH TSs
Required > Installed Assesment Required < Installed

(comparision)
Required = Installed
Under-dimensioning Over-dimensioning
Increase installed TCH/PDCH OK Decrease installed TCH/PDCH
Figure 16: TCH/PDCH dimensioning assessment
To adjust the number of the installed radio TSs according to the required ones, it can
happen the case of the low efficiency resource utilization, for example, one or two
additional TSs require one new TRX!
Thus, the RNE has to define the optimized number of required radio TSs to trade-off
between the returned gain and the investment cost.
PS throughput in kbps is used as additional information:

PS throughput in kbps:
For DL:
d PS _ DL = Data_DL
Transmision_Time_DL
d m n

8 P 20 x RLC _ Block _ Sizex + P 55 x RLC _ Block _ Sizex + P 20 x RLC _ Block _ Sizex
= x =a x =a x =f
1000 P 38e

For UL:
d PS _ UL = Data _ UL
Transmision _ Time _ UL
d m n

8 P 21x RLC _ Block _ Sizex + P 57 x RLC _ Block _ Sizex + P 21x RLC _ Block _ Sizex
= x =a x =a x =f
1000 P 38f
Where:
Channel Coding scheme RLC data block size in bytes
CS-1 22
CS-2 32
CS-3 38
CS-4 52
MCS-1 22
MCS-2 28
MCS-3 37
MCS-4 44
MCS-5 56
MCS-6 74
MCS-7 (sent of 2 blocks) 2*56
Table 12: 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).

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.
Up to 15 BTSs
BTS BTS BTS per
1 Abis Chain
Abis Abis Abis
BSC
Figure 17: 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.

BTS
BTS
BTS Abis Only 1 BTS

Abis
Abis per
1 Abis Star
Abis
BTS
BSC
Figure 18: 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
Up to 7 BTSs
per
BTS BTS BTS
1 Abis Ring
Abis Abis Abis
Abis
Figure 19: 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 B11:
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.

BTS
Pri Abis
Sec Abis BTS BTS Configuration # 1
BSC
BTS Pri Abis Configuration # 2

Sec Abis
BSC
Figure 20: 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.
TRX Abis
TS 0 TS 1 TS 2 TS 3
TS 0 TS 1 TS 2 TS 3 TS 4 TS 5 TS 6 TS 7
TS 4 TS 5 TS 6 TS 7
Figure 21: TRX - Abis mapping
For a given moment, a radio TS on a GPRS capable TRX can carry:

Either CS traffic, then it is called as TCH and the corresponding Abis channel is also
called as TCH,
Or PS traffic, then it is called as PDCH and the corresponding Abis channel(s) is/are
called as GCH(s). Several GCHs per PDCH are used in case of EDGE.

2) LAPD Channels: carry one or more LAPs (RSL and/or OML).
Only 1 RSL per TRX
Only 1 OML per BTS
The GSM Recommendation 08.52 defines 2 logical links between the BTS and
the BSC:
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
3.2.1.4.
3) Extra Abis TS
On Abis interface, two types of 64kbps TS are considered:
Basic Abis TS: handle OML, RSL and traffic TS
Extra Abis TS: handle only supplementary GPRS (CS-3/CS-4) and EDGE
(MCS-1 to MCS-9) nibbles when needed.
In B11 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 Purpose
TS0 usage TS0 transparency
Qmux Channel
Used by the BSC to manage Remote
Qmux TS0 Other TS except TS0
Transmission Network Elements.
Ring control Channel used in Ring topology only

Other TS Other TS except TS0
Supervision of Ring continuity
Ring control R bits except TS0 (Qmux)
Synchronisation controls S bits TS0 Included with Qmux Direction of clock synchronisation
BTS Channels
TCH/GCH Other TS except TS0 GSM (GPRS CS-1/CS-2) traffic
LAPD channel for BTS (1 OML per BTS)
LAPD Other TS except TS0
LAPD channel for TRX (1 RSL per TRX)
Extra Abis TS Other TS except TS0 To support GPRS CS-3/CS-4 and EDGE
Table 13: Abis Channel Types

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

The following table lists the number of TS available in one Abis link to use for TCH (or
GCH), for signalling channels, and for extra Abis TS.
Chain & Star Topology Ring Topology

EVOLIUM BTS (*) EVOLIUM BTS
TS0 TRANSPARENCY 31 29
TS0 USAGE 31 30
Table 14: 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).
From Table 14, 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
16K Static Multiplexing
16K Statistical Multiplexing
64K Statistical Multiplexing

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 Nibble 2 Nibble 3 Nibble 4
TS 0 TS 0 Usage / Transparency
TS 1 TRX 1 - TS 0 TRX 1 - TS 1 TRX 1 - TS 2 TRX 1 - TS 3
TS 3 TRX 1 - RSL
TS 5 TRX 2 - TS 4 TRX 2 - TS 5 TRX 2 - TS 6 TRX 2 - TS 7 13 TS required
TS 6 TRX 2 - RSL in case of
No Multiplexing
TS 9 TRX 3 - RSL
TS 12 TRX 4 - RSL
TS 13 OML
: :
: :
: :
TS 31
Figure 22: 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.

Abis Configuration
10 TS required
in case of
TS 7 TRX 4 - TS 0 TRX 4 - TS 1 TRX 4 - TS 2 TRX 4 - TS 3 16K Static Multiplexing
TS 9 TRX 1 - RSL / TRX 2 - RSL / TRX 3 - RSL / TRX 4 - RSL
TS 10 OML
: :
: :
: :
TS 31
Figure 23: 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
TS 1 TRX1-RSL/OML TRX 1 - TS 1 TRX 1 - TS 2 TRX 1 - TS 3
Figure 24: 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.

Abis Configuration
TS 1 TRX 1-RSL/OML TRX 1 - TS 1 TRX 1 - TS 2 TRX 1 - TS 3
TS 3 TRX 2 - RSL TRX 2 - TS 1 TRX 2 - TS 2 TRX 2 - TS 3
8 TS required
TS 4 TRX 2 - TS 4 TRX 2 - TS 5 TRX 2 - TS 6 TRX 2 - TS 7 in case of
TS 5 TRX 3 - RSL TRX 3 - TS 1 TRX 3 - TS 2 TRX 3 - TS 3 16K Statistical
TS 6 TRX 3 - TS 4 TRX 3 - TS 5 TRX 3 - TS 6 TRX 3 - TS 7 Multiplexing
TS 7 TRX 4 - RSL TRX 4 - TS 1 TRX 4 - TS 2 TRX 4 - TS 3
: :
: :
: :
TS 31
Figure 25: 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 3 TRX 1 - RSL / OML

It is used for FR TRX with high signalling load or DR TRX with normal signalling
load.

2.5 Abis TS per TRX
Abis Configuration
TS 5 TRX 1 - RSL / TRX 2 - RSL / OML

It is used for only FR TRX with normal signalling load.
2.25 Abis TS per TRX
Abis Configuration
TS 9 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
TS 2 TRX 1 - TS 4 TRX 1 - TS 5 TRX 1 - TS 6 TRX 1 - TS 7 9 TS required
in case of
64K Statistical
TS 6 TRX 3 - TS 4 TRX 3 - TS 5 TRX 3 - TS 6 TRX 3 - TS 7 Multiplexing
TS 9 TRX 1 - RSL / TRX 2 - RSL / TRX 3 - RSL / TRX 4 - RSL / OML
: :
: :
: :
TS 31
Figure 29: Example of Abis TS usage for 1 BTS/4 TRX 64K Statistical Multiplexing

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

TRE per BTS per MCB reserved for
(per Abis link) LapD
1 64/1 24 1
2 64/2 32 1
3 64/2; 64/1 32; 24 2
4 64/4 32 1
5 64/4; 64/1 32; 24 2
6 64/4; 64/2 32; 32 2
7 64/4; 64/2; 64/1 32; 32; 24 3
8 64/4; 64/4 32; 32 2
9 64/4; 64/4; 64/1 32; 32; 24 3
10 64/4; 64/4; 64/2 32; 32; 32 3
11 64/4; 64/4; 64/2; 64/1 32; 32; 32; 24 4
12 64/4; 64/4; 64/4 32; 32; 32 3
13 64/4; 64/4; 64/4; 64/1 32; 32; 32; 24 4
14 64/4; 64/4; 64/4; 64/2 32; 32; 32; 32 4
15 64/4; 64/4; 64/4; 64/2, 64/1 32; 32; 32; 32; 24 5
Table 15: Abis occupation according to the number of FR TRX

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

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.

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 Primary Abis Link

B
S T
OML RSL BT BT RSL BT BT RSL BT BT RSL BT BT ET ET ET ET
C S
Secondary Abis Link
ET ET ET ET ET ET ET ET
BT : Basic Timeslot ET : Extra T imeslots
Figure 30: 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 BTS 24TRX
+ extra PS TS
BSC
Secundary link
TRX 13 to 24
+ extra PS TS
Figure 31: BTS with 24 TRX mapped on both Abis links

The primary and secondary Abis links of a BTS can be on different Abis TSU of different
BSC racks.
BTS 1
BTS 1
12 TRX
16TRX
BSC
BTS 2
BTS 2
6 TRX
6TRX
BTS 1
4 TRX
Figure 32: Example of topology with two BTS chained
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.
OML+RSL1-4
OML+RSL1-4
RSL 9-12
RSL 5-8
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
TRX9
TRX9
First A-bis
MAX_FR_TRE_PRIMARY = 12
RSL 13-16
Maximum filling of
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
Second A-bis
first Abis link
or
OML+RSL1-4
OML+RSL1-4
RSL 5-8
TRX1
TRX1
TRX2
TRX2
TRX3
TRX4
TRX5
TRX5
TRX6
TRX6
TRX7
TRX3
TRX4
TRX7
TRX8
TRX8
First A-bis
MAX_FR_TRE_PRIMARY = 8
Equal filling of the
RSL 13-16
RSL 9-12
Second A-bis
TRX13
TRX13
TRX14
TRX14
TRX15
TRX10
TRX10
TRX11
TRX12
TRX12
TRX15
TRX16
TRX16
TRX11
TRX9
TRX9
two Abis links
-
Figure 33: Two Abis links filling examples.
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

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
TS 0 usage or TS 0 transparency Static
number of
Qmux usage needed
Used or Not used Abis TSs
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
Various number of required GCH is based on number of
modulation & coding scheme (MCS or CS), please needed Abis
refer to 3.4.4.2.3. TSs
Less GCH consumption in B9 thanks to M-EGCH
and dynamic Abis allocation
Max number of extra Abis TS is limited by parameter
N_EXTRA_ABIS_TS

It is simple to define the number of needed Abis TSs for conditions of topology, TS0 mode,
Qmux usage, 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.
In case of B11 network we assume EDGE being activated, so we can perform the Abis
dimensioning based on the counter measurement.
There are 2 different methods approaching the Abis dimensioning:
3.2.2.1 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:
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 + GTRDTERQN Number of DL TBF establishment requests per cell.
P91c + P91d +
P91e + P91f +
P505
P62a + P62b + GTRUTERQN Number of UL TBF establishment requests per cell.
P62c - P438c +
P507
Table 16: Counter list - Abis dimensioning Method 1
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 34.

INPUT METHOD OUTPUT
Required extra
& bonus Abis Nb of required
nibble Traffic
Erlang C extra & bonus Abis
Nibbles
GoS:
% Quantile of x
delay sec Nb of required
extra Abis Nibbles
Figure 34: Abis dimensioning process Method 1
INPUT
The required extra & bonus Abis traffic is computed as below formula.
Measured _ extra & bonus _ Abis _ traffic
Re quired _ 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:
P 466
Measured _ extra & bonus _ Abis _ traffic =
3600
%TBF _ Abis _ cong = Max (%DL _ TBF _ Abis _ cong ,%UL _ TBF _ Abis _ cong )
Where:
P105i
%DL _ TBF _ Abis _ cong = 100%
P 91a + P 91b + P 91c + P 91d + P 91e + P 91f + P 505
P105 j
%UL _ TBF _ Abis _ cong = 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).
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: it may be the result of several factors, not only Abis
congestion (to be check).
3.2.2.2 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:
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+ GTRDTERQN Number of DL TBF establishment requests per cell.
P91d+P91e+P91f+
+ P505
P62a+P62b+P62c- GTRUTERQN Number of UL TBF establishment requests per cell.
-P438c+P507
Table 17: 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 METHOD OUTPUT
Required Data Nb of required

Traffic on Abis Abis Nibbles
Erlang C Nb of required
extra Abis Nibbles
GoS:
% Quantile of x
delay sec
Nb of basic &
bonus Abis Nibbles
Figure 35: Abis dimensioning process Method 2

INPUT
The required GCH Abis traffic is computed as below formula.
Measured _ GCH _ traffic
Re quired _ GCH _ traffic =
1 Min(%TBF _ Abis _ cong , 30%)
Where:
P100c
Measured _ GCH _ traffic =
3600
%TBF _ Abis _ cong = Max (%DL _ TBF _ Abis _ cong ,%UL _ TBF _ Abis _ cong )
Where:
P105i
%DL _ TBF _ Abis _ cong = 100%
P 91a + P 91b + P 91c + P 91d + P 91e + P 91f + P 505
P105 j
%UL _ TBF _ Abis _ cong = 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.

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

3.3 BSC
Two generation of BSC are supported in B11:
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
Abis TSU 2 Stages Ater TSU 2 E1
6 E1
TCUC self-routing, non-blocking DTCC
TCUC DTCC
2x
6x TCUC DTCC
ASMB
G.703
G.703 TCUC DTCC
Abis TCUC DTCC Ater

TCUC muxed
I/F DTCC
TCUC DTCC I/F

BIUA ASMB
AS AS
TCUC DTCC
TSL Q1 bus
AS
TSCA CPRC CPRC CPRC CPRC CPRC CPRC CPRC CPRC
Broadcast bus
Common Functions TSU
Figure 36: G2 BSC (A9120 BSC) Architecture
From Figure 36, 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;

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 37: G2 BSC Cabinet layout
In release B10, six types of G2 BSC configurations are offered:

Configuration
G2 BSC (A9120 BSC)
Config 1 Config 2 Config 3 Config 4 Config 5 Config 6
Capacity FR 32 128 192 288 352 448
Nb TRX
DR 14 62 92 140 170 218
Nb Cell 32 120 192 240 264 264
Nb BTS 23 95 142 214 255 255
Nb GPU 6 6 6 6 6 6
Nb SS7 links 4 6 10 12 16 16
Nb CICs 454 686 1148 1380 1842 2074
Nb of TSU Abis TSU 1 4 6 9 11 14
Ater TSU 2 3 5 6 8 9
Nb of E1 Abis 6 24 36 54 66 84
Ater (CS&PS) 4 6 10 12 16 18
Erlang Traffic on A interface (1:4 Mux) 160 627 1074 1300 1700 1900
Table 18: 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 8 32 48 72 88 112
Max EXTS 51 205 307 461 563 717
Table 19: G2 BSC Capacity in TCU Number and ExtraAbisTSs
N.B. It is recommended to limit the BSC load in terms of FR TRXeq to 80%, being FR TRXeq defined as:
N _ EXTRA _ ABIS _ TSallBTS
FR _ TRXeq = FR _ TRX + 2 DR _ TRX +
2

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 38: 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

For the TSL/TCU mapping is fixed as shown in next table:
TSL links G2 BSC BIUA number TCU number

(BSC-Adapt SBL nbr)
TSL 1 (first rack) 1 1
TSL 2 (second rack) 6 41
TSL 3 (third rack) 11 81
Table 20: 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]

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 39: 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]
Important Note: Almost all new features related to BSC in B10 and B11 are not
available for the G2 BSC.
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.

TPW
TPr
SSWW CCP1
MUXr
Radio Network links MUXW
SSW r
CCPy
LIU1
E1
OMCPw
LIUn OMCPr
LIU Shelf
(21 slots) ATCA Shelf (14 slots)
External Ethernet Links
r : Redundancy
W : Working
n and y : Network Element Capacity
Figure 40: 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 sub-
rack, including 1 for redundancy.
SSW board: this board allows exchanges between all the elements of the platform and
external IP/Ethernet equipment. It support IP Layer 3 functions and is based on Gigabit
Ethernet. There are two SSW boards per shelf, 1 active and 1 for redundancy
TP board: this board is in charge of the transmission processing functions of the BSC. It
mainly processes the Abis timeslots and decides whether to send them back directly towards
the LIU shelf (case of extra Abis timeslots, which explains why the extra Abis timeslots have
no impact on the BSC Evolution) or towards one of the CCP boards.
LIU shelf: This module is in charge of the physical E1 connections, i.e. Abis, AterCS
and AterPS.

3.3.2.1 BSC Capacity
In release B11, five configurations of BSC Evolution are offered:
Mx BSC Mx BSC Mx BSC Mx BSC Mx BSC

Configuration
200 TRX 400 TRX 600 TRX 800 TRX 1000 TRX
Nbr of CCP boards 1 2 3 4 5
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 8 8 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 6 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 [9]
Table 21: BSC Evolution Capacity
Note: 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 Control) 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).
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 No change in radio configuration
mechanisms
4500erl and SS7 High Speed Link
Same set of radio parameters
No need of TCU to support extra Abis TS
Same set of PM counters/indicators as
Removal of HR connectivity constraints
A9120 BSC
Abis/Ater fixed mapping to LIU boards
Ater optimization
For more details, please refer to [1].
The recommended Max Paging rate for different BSC configurations is shown in Table 22.
Max paging rate from MSC
BSC configuration
Pagings/second Pagings/hour
G2 BSC 1 12 43200
2 24 86400
3 36 129600
4 48 172800
5 60 216000
6 70 252000
MxBSC 11 24 86400
12 48 172800
13 72 259200
14 96 345600
15 120 432000
Table 22: Max BSC Paging rates

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

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

3.3.2.8 The maximum ERLANG capacity, BHCA and Mean TCH duration
BHCA
The Busy Hour Call Attempts (BHCA) is the average number of call attempts that the
system (BSC) can handle during the busy hour. BHCA defines the maximum signaling load
supported by BSC, and it is used for the signaling timeslot dimensioning.
The number of calls handled successfully is BHCA*(1-blocking probability).
The nominal value for BHCA depends on BSC configuration and traffic model.
The real BHCA, generated by subscribers, can be obtained as follows:
BHCA = RTCH_assign_request + HO_Inc_MSC_request
BHCA = GTCNARQN + GHOIMRQN = MC140a - (MC142e+MC142f) + MC820
It is not a perfect formula because MC820 counts RTCH and SDCCH external incoming
HOs, but there is not a specific counter only for RTCH external HOs or only for SDCCH
external HOs.
Anyway, the ratio of SDCCH HO cases inside MC820 should be very small.
The real BHCA must not exceed the nominal value for a given BSC configuration.
For example, in case of MxBSC in configuration with 800 TRX, with ALU traffic model,
the nominal BHCA is 259200 call attempts during busy hour.
The maximum ERLANG capacity

This is the number of ERLANGs supported by the system (MSC) in front of a nominal
traffic. The nominal value for Erlang capacity depends also on BSC configuration and traffic
model. It is used for the RTCH timeslot dimensioning.
Note that this CS traffic capacity is defined with a given blocking probability; hence it is
not equal to the processed ERLANGS which take into account only successful calls.
For example:
For an MxBSC with 4500 Erlang Capacity at 0.1% blocking, the Processed Erlang is:
4500*(1-0.001) = 4495.5 Erlang.
The offered traffic is the amount of traffic generated by the customers. Offered must be
understood as offered as input to the BSS.
The BSC traffic load can be measured as below:
RTCH_Erlang_total = GTCTRE =
= (RTCH_full_occy_total + RTCH_half_occy_total)/3600
= (GTCTRFT+ GTCTRHT)/3600 = (MC380a+MC380b)/3600
Important: The nominal values for maximum ERLANG capacity and BHCA must not be
exceeded whatever is the customer traffic model.
Mean TCH duration

The mean TCH duration is the average duration of a call inside the BSS, with possible
BSS-internal change of channel due to handover. It is also related to the traffic model.

For the ease of modeling, it is considered that each call is started and terminated in the BSS
and that each outgoing external handover is compensated by an incoming external handover.
So this is as if only intra-BSS handover are occurring during the call.
The mean TCH duration takes into account the successful and unsuccessful call attempt:
unsuccessful calls have a 0s TCH holding time, but generate signaling load.
It should be noted that this definition differs from the mean TCH holding time as
measured by OMC-NPA or RNO tool, which provides the time during which the MS remains
on the same channel (between Abis Channel Activation and Abis RF Channel Release
messages).
For one BSC, the value of Mean_TCH_duration can be calculated as below:
Mean_TCH_duration = RTCH_Erlang*3600/BHCA,
where RTCH_Erlang and BHCA are the nominal values for the coresponding BSC
configuration.
For an MxBSC, in configuration BSC-EV 1000, with nominal Capacity = 4500 Erlang and
nominal BHCA = 324000, the coresponding value for Mean_TCH_duration is 50 seconds
(ALU traffic model).
For MxBSC with a measured traffic RTCH_Erlang_total (GTCTRE) = 2088.3 Erlang and
measured BHCA = GTCNARQN + GHOIMRQN = 144837 call attempts we get real
Mean_TCH_duration = 51.9 seconds.
Related to holding time and call duration in the network with real traffic, the following
indicators are available from NPO:
Averaged RTCH seizure duration (holding time).
RTCH_duration_avg (GTCTRMHT) =
= RTCH_occy_total / RTCH_channel_allocated =
= (RTCH_half_occy_total + RTCH_full_occy_total) / (RTCH_half_allocated +
RTCH_full_allocated) =
= (MC380b + MC380a) / (MC370b + MC370a)
Averaged call duration (including the average number of handover per call).
Call_duration_avg (GTMMHT) =
= RTCH_duration_avg * (1 + RTCH_HO_per_Call) =
= (RTCH_half_occy_total + RTCH_full_occy_total) / ( RTCH_half_allocated +
RTCH_full_allocated) * (1 + (RTCH_HO_success / RTCH_assign_success)) =
= (MC380b + MC380a) / (MC370b + MC370a) * (1 + ((MC717a + MC717b) / MC718)
To be noted that RTCH_duration_avg is always less then Mean_TCH_duration because
HO are not considered.
In the same time, Call_duration_avg is always greater then Mean_TCH_duration because it
takes in account only successful call attempts.

3.3.3 New B11 features related to MxBSC
Rationale
On the core network side, Operators are transitioning to NGN architecture with separate
management of control plane (CP) and user plane (UP). The CP (i.e. signalling) is managed
by the MSC Server (MSC-S) while the UP (User traffic) is handled by the Media Gateway
(MGW).
MSC Server can reach much higher capacity than legacy MSC, so the failure of an MSC
Server can have very important impacts on the network availability for a very high number of
subscribers. Therefore, the A-Flex feature is interesting for Operators migrating to NGN, as
BSC can be connected to several MSC Servers, which allows limiting capacity losses in case
of MSC Server site disaster.
The backbone of the NGN is based on IP technology mostly. The A-signalling over IP feature
extends the IP based transport on the control plane down to the BSC and supports the general
trend to IP based inter-connection layers. The feature provides a high flexibility for BSS to
connect to NGN and makes the introduction of the A-flex functionality much easier and
future proof than the combination of A-flex with TDM transport. This strategy avoids the
introduction of several SS7-MSC instances (one MTP3 instance per MSC, one MTP2 link set
per MSC).
The A-signalling over IP feature is based on SIGTRAN protocol stacks already in use in the
NGN core. Therefore limited interoperability issues are expected between BSC and MSC
Server. The A-signalling over IP feature complements also the Alcatel-Lucent native IP
transport in the BSS. Both functionalities can be introduced independently.
3.3.3.1 AsigOverIP
Overview
The purpose of this feature is to transfer the SS7 signaling over the IP network between the
BSC and NGN core network.
A Signalling Over IP supports BSC to be connected to multi MSCs.
The benefits of this feature include:
Improvement of the signaling transfer reliability and lower transfer delay.
Higher signalling transfer bandwidth.
Simple network configuration and flexible network structure.
It supports multi remote SS7 end points to be connected to BSC.
The feature is an optional feature and the A-signalling over TDM is still supported.
TDM mode and IP mode are exclusive.
The basic idea is to separate the control plane and user plane in the core network. The legacy
MSC is replaced by MSC server (control plane) and MGW (user plane).
A signaling over IP is implemented for MSC server in the NGN network.
A signaling is not working on TDM and IP in the same time.

MSC
MSC
BSC MSC
server
MSC
ASIGoIP server
server
server
IP
Ater
A PSTN
TC MGW
Figure 42: Asig Over IP Architecture
SS7 Protocol Stack

SS7 protocol stack is different for TDM and IP mode.
In IP mode, as recommended by 3GPP TS 29.202, the M3UA protocol based on SCTP
protocol is used to transfer SCCP signalling instead of the MTP.
Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top
of a potentially unreliable connectionless packet service such as IP.
It offers acknowledged error-free non-duplicated transfer of datagrams (messages).
Detection of data corruption, loss of data and duplication of data is achieved by using
checksums and sequence numbers.
A selective retransmission mechanism is applied to correct loss or corruption of data.
BSC MSC Server
BSSAP BSSAP
SCCP SCCP
M3UA M3UA
SCTP SCTP
IP IP
Ethernet Ethernet
IPIP
IP Mode
Figure 43: SS7 protocol stack (SIGTRAN)
The Telecom function is essentially implemented in the BSC by M3UA/SCTP.

The M3UA in BSC and MSC works in the peer-to-peer mode, the mapping of BSC objects
and M3UA corresponding concepts is like below:
The AS (Application server) is a logical entity and one AS can have one or several
IPSPs. It is used to indicate one SS7 signaling point. One BSC is one AS. For the
BSC, each MSC is a separate remote AS.
The ASP (Application Server Process) is a process instance of an Application Server.
The IPSP (IP server process) is one process that handles the M3UA/SCTP. IPSP is the
physical entity managing the SCTP associations. An IPSP is essentially the same as an
ASP, except that it uses M3UA in a point-to-point fashion.
BSC Side MSC Side

MSC 1
BSC
IPSP1
IPSP1
IPSP2
IPSP2 IPSP3
MSC 2
IPSPn
A single SCTP Association A Set of SCTP Associations
Figure 44: Connections between the BSC and MSC Servers
Definitions
SCTP protocol is used for the M3UA message transfer. The features of the SCTP include:
Support multi-homing.
Support multi streams in one association. One SCTP association is established
between two SCTP endpoints (IPSPs), and in one association there can be more than
one stream. The stream is used to guarantee the sequencing message transfer.
SCTP Association: The association is established between two IPSPs belong to different AS.
For two ASs with n and k IPSPs respectively, there are at max n*k associations can be
established between them.
Stream: it is used in SCTP to refer to a sequence of user messages that are to be
delivered to the upper-layer protocol in order with respect to other messages within
the same stream.
SLS: Signalling Link Selector. The logical link used by SCCP, for one SLS the
message is transferred in sequence. The range of SLS is from 0 to 15.
Routing Key: A Routing Key describes a set of SS7 parameters and parameter values that
uniquely define the range of signaling traffic to be handled by a particular Application Server.
The Signalling Point Code (SPC) is used as the routing key.

The routing key is used to identify one IPS
One BSC has one routing key
From BSC view, one MSC has one routing key
On the current implementation, the routing key used by BSC is the SS7 point code of
the MSC server
The routing key of BSC and MSC server can be different
NA: Network Appearance, it is a M3UA local reference shared by SG and AS (typically an
integer) that, together with an Signaling Point Code, uniquely identifies an SS7 node by
indicating the specific SS7 network to which it belongs.
The NA is used together with the routing key by BSC to identify the unique MSC
server.
It is configured by the operator
The NA of the MSC server should be same in BSC side as it in the MSC server side
Alcatel-Lucent B11 Implementation
BSC can be connected to more than one MSC and each MSC can have more than one IPSPs.
In BSC, for each MSC there is one separate IPSP, and all the IPSPs in BSC have same IP
address and they are distinguished by different port number.
At the BSC, the following configuration should be provided for each MSC that will be
connected:
Network Appearance: it is configured for each MSC server by the operator.
Routing Key: The routing key of the MSC server, on current BSC implementation it is
the SS7 point code of the MSC server.
The number of the IPSP belongs to the MSC server.
The IP address and port number of each remote IPSP.
The redundancy mode of all the remote IPSPs.
As the BSC and MSC is a peer-to-peer mode, then the configuration for them is the same.
The following dimensioning limits should be verified:

Parameter Value
Max MSC servers per BSS 16
Max SPC per MSC server for one BSC 1
Max ASL per MSC server 4
Max ASL per BSC 64
Max IP addresses per SCTP endpoint 2
Max SCTP endpoints per MSC server 4
Table 23: AsigOverIP limits
Note: ASL means A Signaling Link.

Multi-Homing
The multi-homing is a way to increase the reliability of the Internet connection for an IP
network. Multi-homing is not mandatory for A Signalling Over IP, but when the MSC
endpoint has more than one IP addresses, it must be applied.
Support for Multi-Homing on MSC side:
The SCTP is designed to establish robust communication associations between two
endpoints, each of which may be reachable by more than one IP addresses.
Potentially different addresses may lead to different data paths between the two
endpoints. Then the BSS should be able to accept that the MSC SCTP endpoint has
more than one IP address.
For BSC side, it is accessible through different IP networks by one IP address, and
two IP addresses are meaningless.
One association may be established with two different paths, and only one path is used
to transfer the message in one time.
SCTP supervises both paths and it changes the path without association broken when
the active path has a failure.
IPSP in MSC
IPSP in BSC IP Add1
Router1 IP Network 1
IP Network 1
M3UA
M3UA
VRRP
IP Add2 SCTP
SCTP
IP Network 2
Router2 IP Network 2
Figure 45: Multi-homing on MSC side
Support for Multi-Homing from BSC

For BSC, to support the multi-homing, only one IP address is used in BSC.
BSC is connected to two routers with one IP address, and the two routers are working
with VRRP (Virtual Router Redundancy Protocol).
Gateway1
Router 1
IP Network 1
IP Network 1
BSC
Gateway2
SSW1
MSC
VRRP Server
SSW2
Router 2 Gateway1
IP Network 2
IP Network 2
Gateway2
Figure 46: Multi-homing on BSC side

Optionality
The feature A Signalling Over IP is a commercially optional feature, and the A-
signalling over TDM is still supported.
The optionality is controlled by counting all the TRX of all the cells of the BSSs
where the feature is activated.
TDM mode and IP mode are exclusive - A signaling will not working on TDM and IP
in the same time.
Activation of this feature
The feature is activated at BSC level (per BSC), by setting the parameter
EN_ASIG_OVER_IP equal to 1 (ENABLE).
Compatibility with previous HW generation
This feature is only supported on the BSC Evolution.
3.3.3.2 A-Flex
Overview
A-Flex network architecture is specified by 3GPP TS 23.236 and this feature allows a BSC
connecting to more than one MSC. This is a GSM BSS B11 feature.
MSC 3 MSC 6
MSC 2 MSC 5
MSC 1 MSC 4 MSC 7
CS pool- CS pool-
area 1 area 2
BSC 1 BSC 2 BSC 3 BSC 4
Area 1 Area 2 Area 3 Area 4
BSC 5 BSC 6 BSC 7 BSC 8
Area 5 Area 6 Area 7 Area 8
Figure 47: A-Flex Architecture
For an operator the benefits of this feature are:

Reducing the signalling traffic in the core network
An external location update to the HLR and an inter-MSC handover procedure become only
necessary if the UE leaves the CS pool area.
Increasing the service availability
Without this feature the unavailability of a MSC leads to the service outage of the complete
area controlled by the MSC. With this feature if a MSC fails the remaining MSC(s) in the CS
pool area can take over new service requests.

Achieving the load balancing among the MSCs
The introduction of CS pool area allows balancing the load in the MSCs of a CS pool area.
Thus situations where, within one CS pool area, certain MSCs are overloaded while others are
almost idle can be avoided. Indeed this means that in the CS pool area the available
processing capacity can be used in a better way. This leads to increasing the robustness and
better response times of the core network
Easier Core network expansion
If the core network capacity needs to be increased there is no need any more to reconfigure
the radio network. The existing LA/RA configuration can be kept. It is sufficient to add a new
MSC to the CS pool area with the same radio configuration data as the other MSCs of this CS
pool area.
Definitions
Media Gateway (MGW)
A MGW terminates bearer channels (e.g., A-trunk) from a switched circuit network.
Interacts with MSC server and GMSC server for resource control.
Owns and handles resources such as echo cancellers etc.
May need to have codecs.
Media Gateway Controller (MGC) = MSC Server
The MSC Server mainly comprises the call control (CC) and mobility control parts of
a MSC. The MSC Server is responsible for the control of mobile originated and
mobile terminated CC CS Domain calls. It terminates the user-network signalling and
translates it into the relevant network network signalling.
The MSC Server also contains a VLR to hold the mobile subscriber's service data and
CAMEL related data.
The MSC Server controls the parts of the call state that pertain to connection control
for media channels in a MGW.
Multiple virtual MGW
If a Media Gateway is connected to more than one MSC server, the Media Gateway
shall fulfil the requirements outlined in the sub clause "Multiple virtual MGW" in
ITU-T Recommendation H.248.1.
CS pool area
A CS pool area is an area within which a MS may roam without need to change the
serving MSC server.
A CS pool area is served by one or more MSC servers in parallel.
All the cells controlled by a BSC belong to the same one (or more) CS pool area(s).
MS has no idea about the CS pool area (A-Flex has no impact on MS).
BSS does not see the CS pool area: it sees only the NRI (Network Resource
Identifier) of MSC-s that the BSC connects to.
Available MSC server
A MSC Server is considered as available if it can be selected by the load balancing
algorithm.

Alcatel-Lucent B11 Implementation
A-Flex is only implemented in the Mx-BSC.
A-Flex does not work with legacy A-signalling in TDM mode. It works only with A-
Sig-Over-IP.
A-Flex feature cannot be used when the Alcatel-Lucent BSS is connected to a legacy
MSC.
A-Flex works only with NGN. NGN (Next Generation Network) architecture is
specified by 3GPP TS 23.205.
A-Flex feature works only with the Media Gateway supporting the virtual MGW
feature.
One BSC connects up to 16 MSC servers.
For MR1, only Mx BSC in TDM mode will be tested.
For MR3, Mx BSC in IP mode may be also tested (tbc).
The following dimensioning limits should be verified:

Parameter Value
Max MSC servers per BSS 16
Max ASL per MSC server 4
Max ASL per BSC 64
Max NRI per MSC server 8
Max SCTP endpoints per MSC server 4
Table 24: A-Flex limits
New Telecom Procedures due to A-Flex

Pool Area
A pool area is an area where A-flex is applied.
Within a pool-area an MS may roam without need to change the serving MSC.
A pool-area is served by one or more MSCs in parallel.
An MS is served by one dedicated MSC of a pool-area as long as it is in radio
coverage of the pool-area.
There is the possibility to configure overlapping pool-areas.
The number or capacity of MSCs is configured independently for each pool-area.
The usage of the A-flex may be configured in parts of the network only.
It co-exists with other areas not using this feature.
BSC does not need to know the pool area. Its a pure core network concept.
A BSC service area may belong to multiple pool-areas, which is the case when
multiple overlapping pool-areas include this BSC service area.
The configuration of overlapping pool-areas allows separating the overall traffic into
different MS moving pattern, e.g. pool-areas where each covers a separate residential
area and all the same city centre.
Network Resource Identification
The Network Resource Identifier (NRI) identifies uniquely an individual MSC out of
all MSCs in a pool-area.

The NRI is part of the temporary identity TMSI. It is coded in bits 23 to 14 of TMSI
with a flexible length between 10 and 0 bits (0 bits means the NRI is not used and the
feature is not applied). Regardless of the NRI length the most significant bit of the
NRI is always in bit 23 of TMSI. And the length of the NRI shall be the same in all
nodes in one pool-area.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CS/PS VLR-restart & TIME NRI
Figure 48: Example of a TMSI structure with 7 bits NRI-length
Each MSC supporting A-flex is configured with its specific one or more NRI(s). The
TMSI allocation mechanism in the MSC generates TMSI which contains a configured
NRI in the relevant bit positions.
The BSC is configured with a NRI_LENGTH parameter. This NRI_LENGTH
indicates the number of bits for NRI, which starts from the 23rd bit in TMSI. Then
BSC can derive the NRI from the TMSI contained in the initial layer 3 message from
the MS.
In areas where pool-areas overlap the NRI identifies uniquely a MSC out of all MSCs,
which serve all these overlapping pool-areas, i.e. an NRI identifies uniquely a MSC
within a BSC. In case of overlapping pool-areas the NRI length shall be configured to
be the same in all the nodes serving these pool-areas.
NAS Node Selection Function
This function is used in BSC to select the specific MSC to which the initial layer3
messages are routed. The BSC derives the NRI from the TMSI in the initial layer3
messages. If the BSC has a MSC configured for the NRI, then this message is routed
to this MSC.
Load Balancing
Preferably, the NAS Node Selection Function in the BSC balances the load between
the available MSCs. This is performed by an appropriate selection of the MSC for an
MS when there is no MSC configured for the NRI indicated by the MS, or when no
NRI can be derived or in abnormal cases, e.g. when the MSC corresponding to an NRI
cannot be reached.
Load Re-distribution
There are situations where a network operator will wish to remove load from one
MSC in an orderly manner (e.g. to perform scheduled maintenance, or, to perform
load re-distribution to avoid overload) with minimal impact to end users and/or
additional load on other MSCs.
Re-distribution of UEs is initiated via an O&M command in the MSC, which needs to
be off-loaded.
MSC traffic mode

override mode (i.e. only one of the IPSPs handle the traffic)
broadcast mode (i.e. all the active IPSPs receive the same messages)
load sharing mode (i.e. the traffic is distributed over all the active IPSPs)

Optionality
This feature is commercial optional.
It can be activated at BSC level by the parameter En_A_Flex.
Control of the activation at the OMC-R is done on a per TRX quantity base. As the price
of this feature depends on the number of TRX in the network, there must be a related
control in the BSS where the feature is activated (all the TRX-s of the BSC area shall be
counted).

This feature is only supported on the BSC Evolution.
It works only with A-Sig-Over-IP.
One unique Null_NRI shall be configured by for whole PLMN.
For a given BSC, a MSC server has only one SPC (Signalling Point Code).
Restrictions & Limitations

A-Flex does not work with legacy A-signalling in TDM mode.
A-Flex feature cannot be used when the Alcatel-Lucent BSS is connected to a legacy
MSC.
A-Flex works only with NGN.
Rules
When A-Flex is applied, one or more MSCs serve a CS pool-area, but only one of these
MSCs serves each individual MS.
One and only one MSC server always controls an A interface circuit.
The BSC load is shared by MSC servers of the CS pool-area, and the A-trunks of the BSC
must be split between different MSC servers in accordance with their weight.
If the MSC weight is increased, the number of A-trunks connected to that MSC may also
need to be increased.
3.3.3.3 STM1 impact on BSC

STM1 connectivity is introduced in B11 release for the 9130 BSC Evolution. It is available on
both A-bis and A-ter interfaces.
Overview
The STM-1 interface is an alternative to the TDM transport mode in order to decrease
the cost of the transport in BSS.
This feature is offered only for A9130 BSC Evolution, and 4 STM-1 can be connected
on the front plate of the new TPGSMv3 board.
Each STM-1 includes 63 channels (VC12) which can include an E1 of 2048 kbps, so
one STM-1 can carry 63 Abis and/or Ater, each E1 is transported separately on one
VC12 container.
The BTS and the MFS are still connected using E1 electrical interface; the connection
between MxBSC (STM-1) and BTS/MFS (E1) will be done through SDH network
containing equipments for optical-electrical conversion.
A BSC Evolium can be pure STM-1, pure E1 or mixed.
The transport of E1 over SDH vs. E1 over physical interface can be selected per E1
interface or per group of E1 interfaces, meaning that, in BSC, the choice is separate
for each E1 (used either for Abis, or for Atermux).

The new TPGSMV3-STM1 brings the following features to the BSC Evolution 9130:
It can be used at feature parity with TPGSM v2/v1 boards with E1 connectivity
from B10 MR2 ed04,
It offers up to 4 STM1-1 interfaces to transport up to 252 E1 from B11 MR1,
It support E1 over Ethernet (for up to 252 E1) from B11 MR1,
It can host a daughter board for the introduction of IP (for up to 252 E1) from B11
MR1.
Consequently, it will provide the following operational gains:

Smooth & quick replacement from G2 BSC to BSC Evolution,
Smooth IP introduction in BSS,
Centralized BSC/TC configurations,
Reduce CAPEX & OPEX:
- CAPEX - Simplified transmission equipments: removal of E1 boards in ADM,
- OPEX - Simplified cabling & reduced transmission costs + Integrated O&M (4
STM-1 to replace 252 E1 interfaces per BSC sub-rack 1000 TRX),
Reduce drastically time/error of installation/cabling ( hour vs. 2 days),
Simple network reconfiguration ("move BTS") when SDH lines.
TPGSMv3-STM1 architecture
The 9130 BSC are equipped with 2 STM-1 boards (for 1+1 redundancy, operating in a
master/standby mode), each of them providing 4 STM-1 interfaces in front access.
The new boards are compatible with all BSC Evolution installed base. Upgrade of the
existing BSC Evolution with STM-1 interfaces is performed without powering off the BSC
and without traffic impact. Any VC12 container of the BSC STM-1 link can be allocated
either to Abis or Ater interface.
When the connection of the BSC with other BSS entities is performed by mean of only
SDH links, the E1 physical interface boards and sub-rack can be removed from the BSC
configuration.
Figure 49: TP-STM1 architecture

TPGSMv3 STM1 Board
The optical fiber is connected directly to the TPGSMv3 board and settings/mapping are
done with the A9130 BSC Terminal.
With the STM-1 introduction, a BSC Evolium can be delivered without LIU shelf.
The TP-STM1 boards are always paired off to provide a 1+1 redundancy.
The board can be used in a mixed mode where a subset of its optical interfaces is used while
part of the E1 interfaces remain in service.
Figure 50: TPGSMv3 STM1 board
Equipment Protection Switching (EPS)

With EPS, the traffic on the Active STM-1 interface card is switched in case of board failure
to the spare standby card (Active/Hot standby mode). The two cards are coupled in ATCA
back panel to provide APS function. All established calls are preserved after the EPS switch.
Automatic Protection Switching (APS)

It is used in 1+1 mode with unidirectional non-revertive switching. Unidirectional switching
means that transmission is always performed on the two (working and redundant) links, while
reception is switched from working link to redundant link in case of failure. The two links are
hold by separate boards, thanks to EPS.
The following figure shows an example of network architecture where the traffic is partly
transported over STM-1 thanks to the TPGSM-STM1 board in the BSC and TC-STM1 board
in the TC A9125. To use STM1 over A and Abis, an Add Drop Multiplex (ADM) equipment
is required for the connection of the MFS and BTS.

Figure 51: Network Architecture with STM1
Optionality
The feature is optional from commercial point of view. Operators buy the feature
with a maximum number of STM1 Interface per OMC.
This maximum number concerns STM1 Interface generally speaking, that means
taking into account BSC STM1 interfaces but also TC ones.
An interface represents a pair of protected STM1 links.
An OMC has to check the total number of declared interfaces in all BSC and TC in
front of the upper limit licensed.

The feature is not supported for G2 BSC.

Replacement of TPGSMv1 with TPGSMv3 also called TPGSM STM-1 is
mandatory.

3.3.3.4 IP Flow segregation at BSC level
IP Flow segregation in MxBSC is a new feature allowing several routers to be used for improved
flexibility between the different IP flows (O&M and Asig over IP in case of MxBSC).
This feature provides the flow segregation at layer 1 (same or different physical ports for the
different flows). The feature is available for only 9130 BSC Evolution (it is not supported for
G2 BSC).
The 9130 BSC Evolution has flexible mapping of O&M / Asig over IP flows onto GE ports
starting with B11 MR1 Ed.2.
Definition:
The flow segregation is physical, that is to say it is obtained by dedicating one BSC switch
Ethernet port per flow to segregate. Its based on the operator request.
Several routers may be used to allow better flexibility between the different IP flows (O&M,
BSS over IP or Asig over IP).
The IP traffic without router (L2 networks) is also allowed, the flow segregation and BSC
internal VLAN tag configuration applying to both L2 and L3 cases.
Benefits:
Having better organization in terms of separate teams working independently on each telecom
flow.
Allows for segregation at L1, which allows also for L2 segregation as a workaround due to
lack of VLAN tagging in BSC and the need for an external router.
Features:
Layer 3:
o Supported on L3 router based Networks, Several routers to allow better
flexibility between the different IP flows (O&M and Asig over IP).
o Several routers allow a better performance in terms of less processing (Queing,
Priority handling, ) and delay savings compared without the feature.
Layer 2:
o Supported on L2 switch based Networks, The IP traffic without router is also
allowed thanks to the feature as a workaround which was not possible before
due to lack of VLAN tagging in BSC.
o Opex savings due to the ability to connect directly to switches without the need
of routers/ L3 Ethernet switches connected to L2.
o Better performance in terms of less processing/delay savings compared
without the feature due to elimination of routers.
o The flow segregation and BSC internal VLAN tag configuration applying both
to L2/L3 cases.
o It is not mandatory for the operator to segregate the flows; any combination is
possible, from no segregation at all to one port per identified flow.

Limitations:
L3 Network: The feature is only applied on L3 One LAN topology with static route
configuration which will need to be checked if compliant with the operators network.
L2 Network: This option can be used for complete physical flow segregation or in case of one
port per identified flow, once we have some aggregated/combined flows on the same subnet
this will require to have a Router/L3 Ethernet switch to handle the VLAN tagging.
In B11MR1ed2, Telecom IP flow means only Asig over IP.
After B11MR3 introduction, more Telecom IP flows will be available (AsigoIP, BSS over IP
or AupoIP) and more combinations for IP flow segregation will be possible.
ONE LAN Topology (without Asig over IP)

This solution without RIP V2 provides redundancy for the O&M link using the static route.
The subnet A is the external and visible subnet from the IP O&M network.
In one LAN configuration, both switch boards are connected to the same LAN.
It is mandatory to be already in one LAN configuration to operate Asig over IP feature.
Telecom flows over IP are supported in one LAN topology only.
IP Telecom subnet configurations are following:
o O&M and Telecom flows in same subnetworks (no segregation)
o O&M and Telecom flows in different subnetworks (flow segregation)
o The flow segregation is physical, dedicated BSC switch port per flow.
ONE LAN Topology (with Asig over IP)

The subnet A is the external and visible subnet from the IP O&M/Telecom network.
There are dedicated IP addresses for the O&M transport and dedicated IP addresses for the
Telecom transport.
Subnet A
Alarm Router 1
SSW 1 port 3
Box
IP O&M/Telecom
VRRP
OMCP 2
OMCP 1
NETWORK
TPGSM
CCPx
Router 2
SSW 2
port 3
MX-BSC
Figure 52: Mx-BSC in one LAN configuration with one external subnet
(O&M and Telecom are mixed no segregation)

Router O&M 1
Subnet A1 for O&M
VRRP IP O&M
Network
port 3 Router O&M 2
Alarm SSW 1
Box port 7
Router AsigoIP 1
OMCP 2
OMCP 1
TPGSM
CCPx
VRRP IP Telecom
port 3 Network
SSW 2 Router AsigoIP 2
port 7
MX-BSC Subnet A2 for AsigoIP
Figure 53: Mx-BSC in one LAN configuration with two external subnets
(O&M and Telecom are separated)
LAN IP Transport mode External

Comments
Topology possibility Subnet(s)
A is the only one external Subnet dedicated

O&M only A
to O&M
O&M and Telecom
A is the external Subnet shared by O&M and
with one shared A
One LAN Telecom
subnet
O&M and Telecom
A2 is the external subnet with Telecom when
with two separate A1, A2
A1 is dedicated to O&M
subnets
A is the external Subnet and there are 2 local
Two LAN* O&M only A
subnets named B and C.
*The Two LAN topology is not compatible with telecom over IP features, such as Asig over IP.
Table 25: Possible LAN configurations
The feature activation is obtained by changing the parameter VLAN_CONF_INDEX from

0 to 1.
VLAN_CONF_INDEX Definition
O&M and telecom (AsigoIP) use a common router.

0
1 Ethernet port is used per switch board.
O&M and telecom (AsigoIP) use two different routers.
1
2 Ethernet ports are used per switch board.
Table 26: Parameter values for IP flow segregation feature activation

3.3.4 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
No
No
OK
OK ??
Yes
Yes
Check
Check Abis conn
connectivity
ectivity
Yes
Yes No
No
No
No Choose
Choose an
an oth
otherer B SC configura
BSC configuration,
tion,
OK
OK ??
if
if possibl
possiblee ??
Yes
Yes
Check
Check At
Ater
er connectivity
connec tivity
No
No
OK
OK ??
Yes
Yes
Outputs
BSC configurations
BSC Areas
Figure 54: BSC dimensioning process
In Figure 54, basically the BSC dimensioning consists of two following parts:
Design BSC area
Parenting Abis TSU ports of the BSC

3.3.4.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 55: BTS position & configuration design BSC area step 1

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 56: 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 18).
It is recommended not to overcome 80% TRX load at G2 BSC level, to allow future
network extensions. For MxBSC the maximum load recommended is 95% TRX.
Figure 57: BSC area definition design BSC area step 3

3.3.4.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 58: 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.

BSC Architecture REPORT
MELVILLE : BSS4
BSC General Information

Configuration: 5 BSS Release: b11
MAX USED LOAD
Abis 66 32 48.48%
BTS 255 41 16.08%
BTS Sector 264 89 33.71%
TRX (FR eq) 352 340 96.59%
Number of TRX FR: 136 HR: 69 ExtraAbisTS: 132 TRE: 205 TRX Operational: 192
AterMux info Dedicated CS: 10 Dedicated GPRS: 4 Mixed CS_GPRS: 2
PS capabilities NbPScapableTRE: 122 NbEDGEcapableTRE: 176
Abis TSU Design: 11 TSU
TSU 1 TRX FR: 6 TCUC FR: 2 LAPD: 21
TRX HR: 12 TCUC DR: 6 Extra TS: 0
TRX FReq: 30
BTS_540023_8
PCM 1 4 FR; 4 DR; noMux; 5423
QAddr; 25 AbisTS; 0
26 TS ExtraAbisTS
BTS_540053_6
PCM 2 2 FR; 8 DR; statisticMux64;
5453 QAddr; 25 AbisTS; 0
26 TS ExtraAbisTS
PCM 3
0 TS
PCM 4
0 TS
Figure 59: 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.

3.3.5 LA Dimensioning
3.3.5.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:

MC8a GCCPGRQN Number of Paging message seen on Abis interface (PCH usage).
Table 27: 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.

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)


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)

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:
Maximum paging per hour: 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
G2 BSC Limitation
The BSC limit is 70 paging/sec on the A interface, for BSC in configuration 6 (Alcatel
traffic model).

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

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

Re-Design LA
Figure 60: LA dimensioning assessment

In Figure 60, 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.6 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 61: Subdivision of a LA in GPRS routing areas (RA)
Target: To estimate the number of RA per LA.

Gathered Counters:

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 28: Counter list RA dimensioning
Note: the P53a (respectively MC8a) values for each cell in the same RA (respectively LA) should be
identical. However sometimes it was observed (from the counter of live networks) that some cells in the
same RA (respectively LA) have the different P53a (respectively MC8a) value for this case, the most
frequency value will be chosen to be represented the paging traffic of the RA (respectively LA).

Note: Busy Hour means the hour gives the highest paging traffic (i.e. MC8a) of the day.
Methodology:
Main rule: RA size must be smaller than or equal to the LA size
It is not possible to define a RA across a LA border (e.g. one cell from LA1 and two
cells from LA2).
Other rules:
- One RA can contain one or several cells
- One cell cannot belong to two RA
- Cells from one BTS can be allocated to different RA
- The maximum number of RA in a LA is 256 (0, 1, 2... 255)
Some general remarks apply:

If the timer t_ready = high, MS doesnt need to be paged too often so RA size can be as big as
the LA size.
But if t_ready = low, 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.

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.7 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 re-
dimensioning. In addition, if there is any combined cell in a LA, it is recommended to
change to non-combined cell in order to increase the Max # paging of the LA.
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%

3.3.8 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 AGCH blocks Max paging/s Max assign/s
at 60% load at 60% load
1 3 6 3 38 7
1 4 5 4 32 10
1 5 4 5 25 12
2 3 12 6 76 15
2 4 10 8 63 20
2 5 8 10 51 25
2 6 6 12 38 31
Table 29: CCCH capacity

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.

(MC8B + MC8D) / (N2 GCCIARQO Load on AGCH logical channel(s) in case of fixed AGCH
* 3600 / 0.240) configuration
(MC8A / N4) / ((N3 GCCPGRQO Load on PCH logical channel(s) in case of fixed AGCH
N2) * 3600 / 0.240) configuration
Table 30: Counter list LA dimensioning
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
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.
The basic rules for LAC dimensioning are:

One LAC may have cells from one BSC (normal CCCH traffic load), or from several
BSCs (low CCCH traffic load).
Also, the cells of one BSC may be split in two or more LACs in case of high CCCH
traffic load.
The BS_AG_BLKS_RES parameter (min = 0; default =4; max = 7) should have the
same value for all cells belonging to the same location area, because the pagings sent
by the MSC are per location area and the resources allocated should be the same.
The BS_PA_MFRMS parameter should have also the same value for all cells within
one location area (min = 2; default = 5; max = 9).
If Multiple CCCH is used, it must be also activated for all cells of one LAC, to be
efficient in case of high CCCH traffic load.
New counters for CCCH assessment are available since 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.
Since B10, MxBSC is able to send multiple paging command messages.
It is important to notice the diference between the next two counters.
MC925g: Number of PAGING COMMAND received by the BTS on Abis and had to be
sent for CS and PS traffic to the MS.
a) This counter is increased by one each time a PAGING COMMAND message is
received on Abis interface.

b) This counter is increased by n each time a MULTIPLE PAGING COMMAND
message is received on Abis interface (n is the number of PAGING COMMAND
contained in the received MULTIPLE PAGING COMMAND message).
MC930: Number of PAGING COMMAND / MULTIPLE PAGING COMMAND
message received by the BTS on Abis.
Note: For legacy BSC, the value of this counter shall be set to 0.
For BSC EVOLUTION:
a) This counter is increased by one each time a PAGING COMMAND message is
received on Abis interface.
b) This counter is increased by one each time a MULTIPLE PAGING COMMAND
message is received on Abis interface.
Assuming NB_MAX_MSG_MULTIPLE_PAGING_CMD = 5 (default value), with Multiple
paging command feature, we have 5 times less Paging commands on Abis, but the size of one
Abis Paging command message becomes 5 times larger. So, the Abis load remains
unchanged, and the max number of Paging messages also. The feature gain is at BSC level
(lower CPU load and less discarded paging commands).
A new counter for BSC paging load is available in B11:

MC940 = NB_A_PAGING_MESSAGES
It gives the number of 48.008 PAGING messages received by the BSC on A Interface from
any MSC. The counter value for busy hour must be compared with BSC paging capacity.
If the number of paging messages received exceeds the BSC paging capacity, the number of
cells of this BSC must be reduced; else some paging messages will be descarded by BSC.
Also, since B11, a new feature called CS Paging Coordination in the BSS is available. It
is applied for NMO II (Gs interface is not used).
Alcatel-Lucent implementation of the Dual Transfer Mode (DTM) feature assumes the
support of CS paging coordination to be able to receive a DTM call during a PS transfer. If
DTM is not activated, or if MS has no DTM capabilities, the PS transfer is stopped during CS
call, and it is resumed after the CS call end.
The BSC sends the received CS paging messages (from the MSC) on the PCH and
forwards it to the MFS through CS paging Coordination Request message.
Afterwards the MFS sends it on PACCH whenever MS would be performing a packet
transfer (PTM) by searching the requested MS IMSI in the IMSI vs MS Context table created
internally in the MFS for all MSs in PTM only.
The following counters have been defined related to this feature:
P390a: CS_Paging_Request_received (by GPU from BSC);
P390b: CS_Paging_Sent_MS_PACCH_PTM (by GPU).
P390a must be equal with MC8a (NB_CELL_PAGING_CMD) or GCCPGRQN, and also
with MC940 (NB_A_PAGING_MESSAGES) or GTCNAAPRN (if only one LAC is
configured per BSC).

Important: The feature activation may have a significant impact on UL GSL load.
Because BSC sends all the received CS paging messages (coming from MSC) towards MFS,
we can estimate an increase of UL GSL load between 50% and 80% during BH, depending on
the Paging rate and number of GSL links.
It is also important to perform an estimation of the expected GSL load increase before
feature activation, in order to check it more GSL links are required or not.
The GSL load increase during BH due to feature activation can be estimated by computing
the UL volume transferred on GSL for paging messages:
NB_CELL_PAGING_CMD*NB_BITS_PER_PAGING_MESSAGE/8/1000 [Kbytes] =
= MC8a*168/8/1000 [Kbytes].
This value must be added to GSL load measured during BH, and the result may be used to
calculate the new number of GSL links.
Because this is only an approximation, the GSL dimensioning must be redone with
measured data after feature activation, to be sure that no congestion will occur.

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 MSC
AterMUX A
Figure 62: 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

3.4.2 AterMUX configuration
The AterMUX interface is supported by 2Mbps PCM links (64kpbs * 32 TS) with the
structure as shown below.
AterMUX CS AterMUX PS
CH# 1 CH# 2 CH# 3 CH# 4 CH# 1 CH# 2 CH# 3 CH# 4
TS 0 TS 0 Transparency TS 0 TS 0 Transparency
TS 1 TCH TCH TCH TCH TS 1 GCH GCH GCH GCH
TS 14 Qmux TCH TCH TCH TS 14 GCH GCH GCH GCH
TS 15 Alarm octet TS 15 Alarm octet
TS 16 SS7 TS 16 SS7 (not used)
TS 28 TCH TCH TCH TCH TS 28 GSL
TS 31 X25 TS 31 GCH GCH GCH GCH
Figure 63: AterMUX interface structure
In Figure 63, 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. It can be used for GCH.
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.

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). If TS 28
is not used for GSL on one AterMux PS link, it is used for GCH.
3.4.2.1 AterMUX CS and A interfaces
AterMUX CS:
Referring to AterMUX CS structure (in Figure 63), the following figure presents the
AterMUX CS configurations that depend on the G2 BSC configuration.
X 25 Qmux A l a rm SS7 T C H N um b e r
P CM 1 (x) x x x 111
A te r T S U 1
P CM 2 (x) x x x 111
P CM 1 x x 116
B SC R ack 1 A te r T S U 2
P CM 2 x x 116
P CM 1 x x 116
A te r T S U 3
P CM 2 x x 116
X 25 Qmux A l a rm SS7
P CM 1 x x x 115
A te r T S U 4
P CM 2 x x x 115
P CM 1 x x 116
P CM 2 x x 116
P CM 1 x x 116
A te r T S U 6
P CM 2 x x 116
X 25 Qmux A l a rm SS7
P CM 1 x x x 115
A te r T S U 7
P CM 2 x x x 115
P CM 1 x x 116
P CM 2 x x 116
P CM 1 x 116
A te r T S U 9
P CM 2 x 116
T o ta l T C H 20 7 4
Figure 64: AterMUX CS interface configuration G2 BSC
In Figure 64, 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.

G2 BSC Nb of Ater TSU Max nb of AterMUX CS
Configuration 1 2 4
Configuration 2 3 6
Configuration 3 5 10
Table 31: 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 [59-
76]. These links may be used for PS traffic also.
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, HSL position), the MxBSC
automatically opens TS15/TS16 for traffic. This principle is valid for any Ater CS.
A-interface:
The channel mapping between AterMUX CS interface and A-interface is presented
below:
AterMUX CS A Interface
CH# 1 CH# 2 CH# 3 CH# 4 TS 0 Frame Synchronization
TS 0 Frame Synchronization TS 1 CIC 1
TS 1 TCH TCH TCH TCH TS 2 CIC 2
: : TS 4 CIC 4
: : TS 5 CIC 5
TS 14 Qmux TCH TCH TCH : :
TS 15 Alarm octet : :
TS 16 SS7 : :
TS 17 TCH TCH TCH TCH : :
TS 18 TCH TCH TCH TCH : :
: : : :
: : : :
TS 31 X25 TS 31 CIC 31
TS : 64 Kbits/sec TS : 64 Kbits/sec
Channel or Nibble : 16 Kbits/sec
Figure 65: Channel mapping between AterMUX CS and A

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 32 presents the maximum number of A-interfaces in case of G2 BSC.
G2 BSC Nb of Ater TSU Max nb of AterMUX CS Max nb of A
Configuration 1 2 4 16
Table 32: Max number of A-interfaces G2 BSC
3.4.2.2 AterMUX PS
Referring to AterMUX PS structure (Figure 63), the following figure presents an example of
AterMUX PS configuration for a GPU.
GSL Alarm SS 7 GCH Number

PCM 1 x x x 112
PCM 2 (x) x x 112
One GPU PCM 3 x x 116
PCM 4 x x 116
PCM 5 x x 116
Total GCH 572
Figure 66: 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 480 GCH)
5 AterMUX PS are needed to support 480 GCH (14 AterMUX PS are needed to support
1560 GCH)
Note: The max capacity of 5 AterMUX PS is 572 GCH, which is enough to support
480 GCH refer to Figure 63
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)

For G2 BSC, the maximum number of AterMUX PS (BSC-MFS) is dependent on BSC
configuration as shown in Table 33.
G2 BSC Max nb of AterMUX PS

Configuration 1 4
Configuration 2 6
Configuration 3 10
Configuration 4 12
Configuration 5 16
Configuration 6 18
Table 33: 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
GPU
BSC SGSN
X (MFS) Z
Figure 67: Sharing AterMUX links
From Figure 67: - 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:
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 34.
CS Nb of TCH PS Nb of GCH
Full 116 Null 0
7/8 100 1/8 16
3/4 84 1/4 32
1/2 56 1/2 60
1/4 28 3/4 88
Null 0 Full 116
Table 34: Ratio of Mixing CS and PS Traffic in AterMUX
The Figure 65 presents details of Timeslot sharing between CS (TCH) and PS (GCH):
AterMUX CS/PS
PS Traffic Ratio / / / / Full
TS TS Transparency
TS TCH TCH TCH TCH GCH
TS TCH TCH TCH GCH GCH
TS Alarm octet
TS SS
TS TCH TCH GCH GCH GCH
TS TCH GCH GCH GCH GCH
TS GCH GCH GCH GCH GCH
Figure 68: AterMUX CS/PS Timeslot configuration

Notes:
The TS numbers are a maximum value, and depend on the presence (or not) of signalling
links.
The use of GSL on a given Ater Mux takes the place of 4 GCH nibbles on this link. See
Figure 63.
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 for TDM Mode

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.

Scenario To MSC From MSC
MOC 392 337
MTC 381 314
IHO 41 0
EHO 199 179
LU 228 225
SMS-MO 362 242
SMS-MT 283 286
Paging Retry 0 0
Figure 69: 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).
Nb of SS7 links Nb of SS7 links
BSC type (*) BHCA (**)
at 40% load at 60% load
BSC_EV_200 64 800 11 8
BSC-EV-400
BSC_EV_400 129 600 HSL
16 11
15
BSC_EV_600 194 400 HSL HSL
BSC-EV-800
(**) The BHCA corresponds to B10-MR2 capacity. For MR1, the BHCA is limited to 288 000.
Table 35: Signaling link requirements for MxBSC
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.

Gathered Counters:

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 36: 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).

RNO traffic measurements
Peak traffic
Number of occupied Channels

Exact Busy hour
Time (H)
8H00 9H00 10H00 11H00 12H00 13H00 14H00
Figure 70: 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

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.
Note 1: The required SS7 resources are based on a maximum 80% link load due to traffic diversion following
an SS7 link failure. MSC is moving all the traffic of SS7 failed link on a single valid link from the set.
Note 2: If MSC is able to redistribute the load on all remaining links, the dimensioning may be done at a
level of 60% load (154 SCCP connections per 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).

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 Long Name Definition

Name
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.
N 3.1 + 6 * N 3.3
Measured _ SS 7 _ traffic =
112500
N 3.10
%SS 7 _ cong = 100 %
N 3.3 + N 3.10
Measured _ SS 7 _ traffic
Re quired _ SS 7 _ traffic =
1 Min (%SS 7 _ cong ; 30%)
Nb of Re quired SCCP connection s = InverseErlangB (Required_S S7_traffic ;0.1% )
Nb of Re quired SS7 TS = Nb of Re quired SCCP connection s / 103
Note: 1 SS7 TS with 64Kbps (8000bytes/s) coresponds to 256 SCCP connections. For one
SCCP connection coresponds a byte rate of 31.25 bytes/second or 112500 bytes/hour.

Traffic evaluation in DL
Counter values must be aggregated for the link set.
N 3.4 + 6 * N 3.5
Measured _ SS 7 _ traffic =
112500
Re quired _ SS 7 _ traffic = Measured _ SS 7 _ traffic + 15%m arg in
Nb of Re quired SCCP connection s = InverseErlangB (Required_S S7_traffic ;0.1% )
Nb of Re quired SS7 TS = Nb of Re quired SCCP connection s / 103
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
N7 link utilization:
%N7 Utilization in UL = 100*(N3.1 + (6 * N3.3)) / (112500*256*NbTS)
%N7 Utilization in DL = 100*(N3.4 + (6 * N3.5)) / (112500*256*NbTS)
The load on one N7 link shall not exceed 40% (recommended).
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 = 100*(N3.1 + (6 * N3.3)) / (112500*256*31)
%N7 Utilization in DL = 100*(N3.4 + (6 * N3.5)) / (112500*256*31)
HSL case with Extended frame format
%N7 Utilization in UL = 100*(N3.1 + (9 * N3.3)) / (112500*256*31)
%N7 Utilization in DL = 100*(N3.4 + (9 * N3.5)) / (112500*256*31)
The load on one N7 link shall not exceed 40% (recommended).
Note:
The recommended SS7 dimensioning method is the one based on SCCP traffic assessment,
since it takes into account the overall usage time for SCCP connections.
However, the second method, based on SS7 volume of data transferred, is also useful since
it allows checking the load on each SS7 link.

3.4.3.3 SS7 Dimensioning for IP Mode (Asig over IP)
The purpose of dimensioning method is to use the available counters (indicators) to
compute the bandwidth ocupancy during busy hour in UL for Asig over IP traffic:
Check if Asig over IP congestion is negligible or not.
Compute the required bandwidth for aggregated traffic at BSC level in UL.
To assess the required bandwidths for the traffic flows between BSC and MSC, the
approach is to:
Aggregate the Asig over IP throughputs of MSCs connected to the selected BSC.
If throughput is obtained by adding all BSC_MSC objects throughput, a moderation
factor must be considered to take account of the fact that all the busy hours of those
objects may not occur at the same time.
Add overheads due to the fact that Asig over IP traffic is carried over Ethernet, to
compute the Asig over IP global throughput.
Apply a peak-to-average ratio (engineering margin). The peak-to-average ratio is
needed since almost all the counters have values counted during a granularity period
of one hour.
The counters available for this method are giving:

Payload bytes (without IP, SCTP and M3UA headers) sent during granularity period
for UL,
Max Number of bytes in one minute during the granularity period of monitoring,
Total Number of packets sent in UL.
Gathered Counters:
Counter Indicator Name Definition
Name
Number of bytes of the SS7 flow sent by a BSC to the
MC1109 GIPABSMCSSBYN
MSC (MSC-CS) when A signaling over IP is used.
Number of SCTP packets sent by a BSC to a given
MSC for the SS7 flow when A signaling over IP is used. It
MC1110 GIPABSMCSSPKN
corresponds to is the number of SCTP segments sent,
counted by the SCTP stack.
Number of SCTP packets resent by a BSC to a given
MC1111 GIPABSMCSSPKRN
MSC for the SS7 flow, when A signaling over IP is used.
Maximum number of bytes of the SS7 flow sent by a
MC1112 GIPABSMCSSBYMN BSC to a given MSC in one minute during the granularity
period of monitoring, when A signaling over IP is used.
Table 38: Counter list Asig over IP dimensioning
Headers added to payload:

One SCCP message (or SS7 message) is encapsulated into a chunk together with the
M3UA header.
Several chunks are multiplexed over an IP packet (see below picture).

38 bytes Average size: 604 bytes
SCTP Chunk Chunk

Ethernet header IP header header header
Chunk payload header
Chunk payload
20 bytes
12 bytes 16 bytes
M3UA header SCCP msg
36 bytes
Figure 71: IP packet structure for Asig over IP
Headers
Ethernet 38 bytes
IP 20 bytes
SCTP 12 bytes
Chunk 16 bytes
M3UA 36 bytes
Table 39: Overheads for Asig over IP
After observations:
Average size of an IP packet is 648 bytes.
Average size of an SCCP message is 20 bytes.
Average number of SCCP messages per IP packet is 8.
Total Nb of overhead bytes per IP packet is:
38 + 20 + 12 + (16 + 36)*8 = 486 bytes
Nb of overhead bytes per SS7 message (packet) is:
486/8 = 60.75 61 bytes
Method description:
Compute the Total Nb of (Eth+IP+UDP) Overhead Bytes (OB)
OB = (Eth+IP+UDP overhead bytes per packet)*(Total Nb of packets)
Compute the Resent Ratio (RR) if case (resent bytes not counted)
RR = (Nb of sent and resent packets)/(Nb of sent packets)
Compute the Engineering Margin (EM)
EM = (Max Nb of payload bytes in one minute*60)/(Total Nb of payload bytes in one hour)
Compute the Required Bandwidth (RBW)
RBW [kbps] = EM*(Nb of payload bytes in one hour + OB)*8/1000/3600
or if RR known
RBW [kbps] = EM*RR*(Nb of payload bytes in one hour + OB)*8/1000/3600
Note: For congestion cases, the denominator 3600 may be replaced by (3600 unavailability time).

Max Nb of payload
bytes in one min
Engineering Margin (EM)
(Max bytesX60)
/(Nb bytes per hour)
Required
Bandwidth
Nb of payload bytes in one hour (NB) (RBW)
Calculation
Nb of packets resent Resent

Ratio (RR) EM*RR*(NB+OB)*8/1000/3600
(Sent+Resent) RBW
Nb of packets sent /Sent packets [kbps]
Total Nb of packets
sent and resent
Overhead bytes
per packet Total Overhead Bytes (OB)
Figure 72: Method for Asig over IP dimensioning
In case of Asig over IP, with available counters, the method may be applied as follows:
OB = (Eth+IP+SCTP+M3UA overhead bytes per packet)*(Total Nb of packets) =
= 61*MC1110
RR (resent ratio) = (MC1111+MC1110)/MC1110
EM = (Max Nb of payload bytes in one minute*60)/(Nb of payload bytes in one hour)
= (MC1112*60)/MC1109
RBW [kbps] = EM*RR*(Nb of payload bytes in one hour + OB)*8/1000/3600 =
= EM*RR*(MC1109+OB)*8/1000/3600
Note: The counters are defined per MSC_BSC object and must be aggregated per BSC in case
Aflex feature is also activated (multiple MSC per BSC).
It is possible to compare the Asig over IP traffic in UL with the traffic in DL using the
following counters (just to check if the UL traffic is not less then DL traffic):
Counter Indicator Name Definition

Name
Number of connectionless Unit Data messages class 0
MC1114 GIPABSSUDM0N
sent to the MSC, when A signaling over IP is used.
Number of connectionless Unit Data messages class 0
MC1115 GIPABSRUDM0N
received from the MSC, when A signaling over IP is used.
Table 40: Counter list for Asig over IP traffic in UL and DL

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:

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.

INPUT METHOD OUTPUT
Signalling Traffic
Required
SDCCH Nb of Nb of
Traffic required SS7 required
Erlang B
per BSC AterMUX-CS
links per BSC
GoS:
% SS7
blocking Final nb of
Choose required
Max value AterMUX-CS
User Traffic links per BSC
Required
TCH Nb of Nb of
Traffic Erlang B required TCH required
per BSC AterMUX-CS
links per BSC
GoS:
% TCH
blocking
Figure 73: AterMUX-CS dimensioning process
From Figure 73, 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.

Re quired _ TCH _ traffic = Measured _ TCH _ traffic + 15% m arg in
Where:
MC 380a + MC 380b
Measured _ TCH _ traffic =
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 64.
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 64, the total capacity of 11 AterMUX CS links is:
111TCH(link#1) + 111TCH(link#2) + 116TCH(link#3) + 116TCH(link#4) +
116TCH(link#5) + 116TCH(link#6) + 115TCH(link#7) + 115TCH (link#8) +
116TCH(link #9) + 116TCH(link #10) + 116TCH(link #11)
= 1264 TCHs > 1200 TCHs

Then,
Final number of required AterMUX CS Links:

= Max (Required AterMUX CS Links (1), Required AterMUX CS Links (2))
3.4.4.1.1 A Dimensioning
According to Figure 65, 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 A-
interface links (40*4) are required from TC to MSC.

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 under-
dimensioned (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 74 the process for AterMux PS dimensioning that must be applied at BSC level, is
presented:

AterMux dimensioning AterMux dimensioning
Assessment for GSL traffic Assessment for user traffic
# Needed # Needed
GSL links GCH
Aterlink
GPU/GP dimensioning GCH_Capacity
Assessment # AterMux PS

# AterMux PS per GPU # AterMux PS per GPU
(GSL traffic) (user traffic)
max 2 (for security reason)
# GSL links
(at least 2 per GPU/GP) # GPU/GP
# AterMux PS per GPU/GP
Figure 74: 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 75:
AterMux dimensioning AterMux dimensioning

Assessment for GSL traffic Assessment for user traffic
If #GPU/GP>1 then 1 GPU/GP
# Needed # Needed must be added and the
GSL links GCH Aterlink #AterMux PS per GPU/GP (for all
GCH_Capacity GPU/GPs)

must be estimated as:
GPU/GP dimensioning New #GPU/GP at BSC level
Assessment # AterMux PS # Needed
GSL links # AterMux PS
If #GPU/GP=1 at BSC level
at BSC level

# AterMux PS per GPU
(GSL traffic)
# AterMux PS per GPU
(user traffic)
max # AterMux PS per GPU # AterMux PS per GPU
# AterMux PS per GPU (estimated at
(GSL traffic) (user traffic)
BSC level)
max
# GSL links 2
(at least 2 per GPU/GP) # AterMux PS per GPU/GP
# AterMux PS per GPU/GP
Figure 75: 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.

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. Reshuffle operation is done in order to try to balance traffic between the two GPUs
2. Add 1 AterMux PS links on both GPUs
Example 2
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
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

GP(U) level
GPU1
#Needed GP(U) = 1
GPU2
#Needed GP(U) = 2
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)
AterMux dimensioning
Assessment for GSL traffic
Assessment based
Assessment based
on the number of
on GSL bandwidth
GSL messages per second
2
(for security reason)
max
# GSL links
Figure 76: GSL dimensioning method

3.4.4.2.2.1 GSL dimensioning method based on bandwidth
Gathered Counters:

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 42: 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
Max( P 41, P 42)

Measured _ GSL _ traffic = 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

Measured _ GSL _ traffic
GSL _ load = 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 GPU, and up to 8 GSLs per
GP)
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).

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.
K_GSL is the maximum number of outstanding I frames on a GSL link (Min = 1, Max = 32,
Default = 7). 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.
GSL_round_trip_delay GPU
A message is kept in th e buffer
BSC K_GSL during GSL_round_trip_delay
GSL messages
buffer
Figure 77: GSL messages processing
The first method is based on the number of TBF establishment requests.

Gathered Counters:

P62a + P62b + GTRUTERQN Number of UL TBF establishment -requests per cell.
P62c - P438c +
P507
P91a + P91b + GTRDTERQN Number of DL TBF establishment -requests
P91c + P91d +
P91e + P91f +
P505
P30a + P30b + GTRUTESUN Number of UL TBF establishment -successes (seized by the
P30c + P508 mobile).
P90a + P90b + GTRDTESUN Number of DL TBF establishment -successes (seized by the
P90c + P90d + mobile)
P90e + P90f +
P506
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.

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:
Retrieve indicators and (*) QoS evaluation to be done
by QoS expert
Cells GPUs mapping
START (if method applied to 1 GPU/GP) Retrieve data on a different
Period or on an updated
configuration with better QoS*
PS QoS acceptable ?* [1] No

OR
Traffic data (i.e. UL TBF estab success rate > 80%)
CHECK Select hours with acceptable QoS *

Yes
(i.e. for 90% of cells)
Compare PS traffic in the selected hours
GSL traffic condition
with traffic observed on a similar BSC
Calculation [2] (reference BSC)
Estimate PS traffic at busy hours on the basis
of the reference BSC (through a simple proportion
#GSL msgs/sec due based on the respective number of cells)
to PS traffic calculation [3]
Calculation
+ #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

# GSL links total capacity (for all GPU/GP) must be kept
Figure 78: GSL dimensioning process
[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.

PS traffic
(TBF req)
#TBF request/sec < 20
Nb of Msg on GSL
High Low
Available High 3.5 5
GCH
Low 2.5 3.5
Ater congestion observed
Figure 79: GSL usage factor
[3] #GSL messages/sec calculation

1) Msg on GSL due to RAE4 mechanism 0.3 Msg/sec x Nb_cell
2) Msg on GSL due to PS traffic:
2.1) Msg on GSL due to PS/CS paging 1 x (Nb_PS_paging/sec+ Nb_CS_paging/sec)
2.2) Msg on GSL due to PS data traffic (TBF requests):
TBF (UL & DL) corresponding to RA update 1.7 x Nb_TBF_Sig_req/sec
UL TBF without sig on GSL 0 x Nb_UL_TBF_req_noGSL/sec

+
(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 x Nb_TBF_Data_req/sec
High GSL usage (worst case) 5
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
160ms)
Note: It is recommended to set K_GSL = 7 if GPRS traffic is carried through Ater terrestrial links in all
BSC of the MFS.
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
700ms)
Note: It is recommended to set K_GSL = 16 if GPRS traffic is carried through Ater satellite links in at
least one BSC of the MFS.

If the GSL link capacity is computed at BSC level the capacity of all GP(U)
must be summed.
Example 1 (terrestrial links case):

For 1 GP(U) board with 4 GSL links:
K_GSL = 7 and GSL_round_trip_delay = 160ms (default value for terrestrial)
GSL_link_Max_capacity per GPU is
K_GSL * (1000ms/GSL_round_trip_delay) * Nb of GSL links per GPU/GP =
= 7 * (1000/160) * 4 = 175 messages/s
Example 2 (satellite links) case:

For 1 GP(U) board with 4 GSL links:
K_GSL = 16 and GSL_round_trip_delay = 700ms (default value for satellite)
GSL_link_Max_capacity per GPU is
K_GSL * (1000ms/GSL_round_trip_delay) * Nb of GSL links per GPU/GP =
= 16 * (1000/700) * 4 = 91.42 messages/s
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.
Nb _ GSL _ messages _ per sec
GSL _ load = 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%.
The second method is based on new B11 GSL counters presented below (optional B11
feature).
Gathered GSL Counters:

MC1060 GGSLBSMFMSN Number of GSL messages sent by the BSC to the MFS on
one GSL link (this could be BSCGP or BSCLP messages).
MC1061 GGSLBSMFMDN Number of GSL messages discarded by the BSC (i.e not sent
to the MFS) on one GSL link (this could be BSCGP or
BSCLP messages).
MC1062 GGSLBSMFMRSN Number of GSL messages resent by the BSC to the MFS on
one GSL link (this could be BSCGP or BSCLP messages).
MC1066 GGSLBSMFMSMN Counts the maximum number of GSL messages (BSCGP or
BSCLP) sent by the BSC on a given GSL link to the MFS in
one minute during the granularity period of monitoring.
There is only 1 GSL link per GP in the MFS.
P7a GGSLMFBSMSN Number of BSCGP messages sent by the MFS to the BSC.
P7b GGSLMFBSMDN Number of BSCGP messages sent by MFS that are discarded.
P7d GGSLMFBSMRSN Number of BSCGP messages resent by the MFS to the BSC.
P7i GGSLMFBSMSMN Maximum number of BSCGP messages sent by the MFS to

the BSC in one minute.

Measured Object: Sub-BSS (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.
GSL load calculation
Compute the GSL_link_Max_capacity per GPU

Compute the Nb_GSL_messages_persec with:
o MC1066 (Max nb GSL msg sent in one minute) for UL (BSC to MFS)
o P7i (Max nb GSL msg sent in one minute) for DL (MFS to BSC)
o Check if MC1066/60 is less than GSL_link_Max_capacity [messages/s]
o Check if P7i/60 is less than GSL_link_Max_capacity [messages/s]
Check the rate of discarded messages:
o MC1061/(MC1060+MC1062) to be less than 1% in UL,
o P7b/(P7a+P7d) to be less than 1% in DL.
If the GSL link capacity is computed at BSC level the capacity of all GP(U)
must be summed.
Calculate GSL load in % (in terms of treated messages)
Nb _ GSL _ messages _ per sec
GSL _ load = 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 3.6.3.2.
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 66 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
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.
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:

If Number of required TCH per BSC = 250 TCHs
Number of required GCH per BSC = 50 GCHs
Then
From 250 TCH, 222 TCHs can be fit into 2 AterMUX-CS links
Note: From Figure 64, 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 34
Therefore, based on this example, we need 2 AterMUX-CS links and 1 AterMUX-

CS/PS links.
Remark: the minimum usage of mixed AterMUX CS/PS is recommended.
Assessment:
AterMUX-CS/PS re-dimensioning is required when:
The increase of TCH traffic
GP(U) Ater time congestion rate exceeding 0.1 % can be observed regularly.
GP(U) re-dimensioning is performed.

3.5 TC
There are two transcoder (TC) generations supported in B11, 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
TSC DT16 DT16
Ater interfaces
MT120
BSC +FAN MSC
TC bus
ASMC
MT120
or
+FAN
MT120
Ater-mux interfaces A interfaces

Figure 80: TC G2 architecture with mixed configuration
Here after summary of technical data overall generation transcoder.

G2 TC G2.5 TC
Rack Up to 3 1
AterMux per rack 6 48
A interfaces 24 192
CIC 24*29 192*29
SMU ASMC
MT120
TRCU ATBX DT16
Data in this table, based on [1] and [9]
Table 45: G2 TC/ G2.5 TC capabilities

3.5.1 G2 TC Configuration
There are 2 types of G2 TC:
G2 TC equipped with ASMC and TRCU
G2 TC equipped with ASMC/TRCU + MT120 boards (in 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.
Extension / Reduction
Configuration
TC Physical Logical
Min Max Min
G2 TC 2 AterMux 6 AterMux 1 AterMux 1 AterMux
SU 2 6 1 1
ASMC 2 6 1 1
TRCU SM 4:1 4 24 4 4
MT120 - 4 1 1
Table 46: G2 TC configuration
For more details, please refer to [1]
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).
Ater mux interface A interface

(4:1 Mapping scheme)
MT120
MT120
BSC MFS TC G2.5 MSC
Figure 81: 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.

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.
Configuration per Rack Extension / Reduction step

G2.5 TC (AterMux) Physical Logical
Min Max Min
MT120 2 48 1 1
Table 47: G2.5 TC configuration
And, the capacity in terms of MT120 boards is summed up in Table 48.
Configuration 1 subrack 2 subracks 3 subracks 4 subracks

Max MT120 modules 12 24 36 48
Table 48: G2.5 TC capacity
Rules:
Each BSC must be connected to at least two MT120 boards for redundancy purposes,
refer to Table 47.
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.

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 Used TC type Needed TC
: Configuration
: + links (G2 TC or G2.5 TC)
(Nb of boards)
:
:
# AterMUX CS links from BSCn
Figure 82: 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
Total = 36 MT 120 boards
BSCc needs 6 MT120 boards
BSCd needs 8 MT120 boards
As 36 MT120 boards are needed, this required one G2.5 TC with 3 subracks
refer to Table 48.

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.

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
A
SDH
BTS
subrack
Ater MSC
TDM TC
BSC
BTS
BTS
MFS
SGSN
Figure 83: The BSS Architecture with STM-1 on TC side

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 B11:
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 84: 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.

3.6.1.1 GPRS Processing Unit (GPU)
The GPU supports the Packet Control Unit (PCU), as defined by GSM. The PCU handles Gb-
related functions, Radio Resource Allocation functions and protocol exchanges with the
Mobile Stations.
Each GPU consists of 4 DSPs, which are in charge of the RLC/MAC functions as well as the
EGCH protocol exchanges with the BTSs.
Each DSP supports 120 GCH but the GPU should handle less than 480 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 (up to 6) 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 multi-GPU per BSS.
Sub-BSS 1
cell1
cell4 cell2
cell3
MFS
BSC
Sub-BSS2
GSL1
GPU1
cell5
cell6
cell7 GSL2
GPU2
Sub-BSS3 GSL3
GPU3
cell8
cell9 cell10
cell11 GSL4
GPU4
cell13 cell12
cell14
cell15
GPU1: cell1, cell2, cell3, cell4
GPU2: cell5, cell6, cell7
Sub-BSS4 GPU3: cell8, cell9, cell10, cell11 cell12, cell13
GPU4: cell14, cell15
Figure 85: Multiple GPU per BSS

3.6.1.3 Capacity
The following table describes the A9135 MFS capacity for DS10.
A9135 MFS Configuration Standard Standard Pre-equipped

Nb of telecom subracks 1 2
Min GPU per MFS + One GPU for redundancy 1+1 1+1
Max GPU per MFS + One GPU for redundancy 15+1 2 * (15+1)
Max GPRS GCH per MFS 3600 or (240*15) 7200 or (240*30)
Max BSC per MFS 15 22
Max GPU per BSC 6 6
Max BSC per GPU 1 1
st
Table 49: The 1 MFS generation (A9135 MFS) Capacity
Important: The MFS AS800 is no more supported in B11.
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.

SSWw GP1
Muxr
(duplicated)
Radio Network links Mux1
SSWr GPn
LIU1
E1
OMCPw
LIUn OMCPr
LIU Shelf
(21 slots) ATCA Shelf (14 slots)
External Ethernet Links
Figure 86: 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
Figure 87: MxMFS rack configurations

There are two modes of Clock Synchronization for MFS Evolution:
- The autonomous mode, whereby each GPU receives the clock signal on dedicated E1s
(at least two links for redundancy);
- The centralized mode, whereby two dedicated GP receive the clock signal on
dedicated E1s and transmit it to the other GPs. The 9130 MFS Evolution allows 12 E1
per GP with centralized clock.

Currently allowed configurations for MFS Evolution can be summarized as follows:
MxMFS size Synchronization type Nb of GP boards Nb E1 links per GP
1 shelf autonomous up to 8+1 16
1 shelf centralized up to 8+1 14
1 shelf autonomous or centralized up to 9+1 12
1 shelf centralized up to 9+1 10*
2 shelfs autonomous up to 16+1 16
2 shelfs centralized up to 16+1 14
2 shelfs autonomous or centralized up to 21+1 12
2 shelfs centralized up to 21+1 10*
*for backward compatibility only
Table 50: MxMFS configuration and connectivity
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 Per MFS
(with DS10) Evolution
Equipment domain
Fabric 1 1 30 21
Extension 0 0 1 1
Cnx 2 2 60 42
PCM-TTP 8 14 240 294
PCM-port 8 14 240 294
TRX 448 600 9856 12600
NS and Frame Relay domain
NS 1 1 1 1
NSE 1 1 30 21
NS-VC 10 10 300 210
FR Bearer 10 10 300 210
PVC 10 10 300 210
SGSN IP End 16 16 480 336
Points
Figure 88: MFS capacity

Figures of above table is taken frome [3BK 10204 0034 DTZZA]. Note that Gb over IP is not supported
on the AS800, and AS800 is not supported in B11.
3.6.2.2 Delta MFS Evolution versus the 1st MFS generation

The main change/unchanged between those two MFS generation are below:
MFS Max Nb of cells in B9 Max Nb of cells in B10

Legacy MFS 2000 cells 2000 cells
MxMFS 3000 cells 4000 cells

GPU/GP Max Nb of cells in B9 Max Nb of cells in B10
GPU 264 cells 264 cells
GP 264 cells 500 cells
Table 51: MFS Capacity evolutions
In B11 MR1 there are no changes in MFS capacity compared with B10.
The main capacity limits for GPU and GP boards are shown in table below.
GPU limit GP limit Comment

Max Nb of Cells 264 500 PPC limitation
Max Nb of TRX 240 (GPUAB) 960 DSP limitation

448 (GPUAC)
Max PDCH configured 480 1 920 DSP limitation
Max PDCH allocated 196 868 DSP limitation

(0% EDGE penetration rate)
Max PDCH allocated 124 348 (13 E1 links) DSP limitation
(80% EDGE penetration rate) 476 (16 E1 links)
Max GCH 480 1 560 (GboFR) DSP limitation
1 920 (GboIP)
Max MS contexts 1000 4 000 PPC limitation
Max UL + DL TBF 300 000 1 200 000 DSP limitation

establishment requests and
reallocation requests in one hour
Max nb of simultaneously 960 3 840 DSP limitation
established UL TBF+DL TBF
(with max 10 TBF/PDCH in DL
and 6 TBF/PDCH in UL)
Max Gb Throughput for GPRS 992 kbps (GboFR) 4527 kbps (GboFR) PPC limitation
(UL+DL) 829 kbps (GboIP) 4350 kbps (GboIP)
Max Gb Throughput for EDGE 1161 kbps (GboFR) 5285 kbps (GboFR) PPC limitation
(UL+DL) 971 kbps (GboIP) 5037 kbps (GboIP)
Table 52: GP(U) Capacity limitations

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:

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 Time during which a DSP enters the congestion state.
P101 GAAGCHAVT 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 Cumulated time per GPU during which Ater nibbles are
free over the granularity period.
They are nibbles not currently used in a GCH.
P201 GTRGPULDLT 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+ P62c- GQRUTEBPN Number of UL TBF estab -failures due to BSS problem
P438c+P507] - per cell.
(P105d + P105f +
Reference: number of UL TBF estab -requests
P27 + P105h + P105j
+ P105l + P204 +
P512 - P66 - P28 -
[P30a + P30b +
P30c+P508])
MC927e
P62a + P62b + P62c GTRUTERQN Number of UL TBF establishment requests.
- P438c + P507
P105e GQRDTECCN Number of DL establishment failures due to CPU
processing power limitations of the GPU.

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 GTRDTERQN Number of DL TBF establishment requests.
+ P91d + P91e +
P91f + P505
P383b GTRGPUCOT_MA Time (cumulated over a granularity period) during which
the GPU remains in "high" Ater usage.
Table 53: 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 89: GP(U) dimensioning process

Required_GCH_Traffic Needed
Counters Required_GCH_Traffic GCHs
estimation ERLANG C
Stable Feature Traffic
Network activation evolution
With
quantile=99,9%
Figure 90: 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 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).

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:
Measured _ GCH _ traffic
Re quired _ GCH _ traffic =
1 Min(%GCH _ cong ,30%)
Where:
P100c
Measured _ GCH _ traffic = , and
3600
%GCH _ cong = Max{Ater _ Congestion, GPU _ Limitation} =
Max{% Ater _ Cong ,% DSP _ Cong ,% DSP _ load ,%CPU _ overload }
Where:
P383a
%GCH _ Ater _ cong = 100%
3600
P384
%GCH _ DSP _ cong = 100%
3600
Max( P 201, P 202)
% DSP _ load = x100%
3600
P 402
%CPU _ overload = 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.

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.
Required_GCH_Traffic
448
y = 5,3905x + 21,057
336
Measured 224 Resources

GCH traffic
saturation
112
0
0 10 20 30 40 50 60 70 80
Measured PDCH traffic
Figure 91: 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 922.

Needed_GCH
Following the
560
4th link adding
448 ERLANG C
y = 5,3905x + 21,057
Measured
336
GCH traffic
224
112
0
0 10 20 30 40 50 60 70 80
Measured PDCH traffic
Figure 92: 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)

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) GP (A9130)

Case 16 E1 Case 12 E1
links per GP links per GP
CS1 240 960 960
CS2 240 960 960
CS3 216 924 924
CS4 192 860 816
Max MCS GPU (A9135) GP (A9130) GP (A9130)

Case 16 E1 Case 12 E1
links per GP links per GP
MCS 1 220 840 840
MCS 2 208 816 816
MCS 3 204 824 824
MCS 4 192 800 800
MCS 5 176 744 720
MCS 6 164 720 568
MCS 7 132 712 384
MCS 8 112 432 324
MCS 9 104 396 296
Table 54: PDCH number per GP(U) in radio conditions
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
MCS UL DL
CS 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
CS-3 1,25 1,22
MCS-5 1,86 1,81
CS-4 1,64 1,60
MCS-6 2,36 2,31
MCS-7 3,49 3,39
MCS-8 4,14 4,00
MCS-9 4,49 4,39
Table 55: GCH usage depending in coding schemes
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

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) re-
dimensioning 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:
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 previous releases, when the maximum number of allowed MS contexts was reached
an abnormal increase of UL TBF establishment failure due to BSS cause was observed:

Max number MS
1200 context (P392b) 60,0%
Average number
MS context (P392a)
1000 50,0%
800 40,0%
600 30,0%
400 20,0%
200 10,0%
0 0,0%
21/10/2006 : 00h
03h
06h
09h
12h
15h
18h
21h
22/10/2006 : 00h
03h
06h
09h
12h
15h
18h
21h
23/10/2006 : 00h
03h
06h
09h
12h
15h
18h
21h
24/10/2006 : 00h
03h
06h
09h
12h
15h
18h
21h
25/10/2006 : 00h
03h
06h
09h
12h
15h
18h
21h
UL TBF BSS
Failure rate
Figure 93: Evolution of MS context number on GP(U)
In order to detect this problem the following methodology was defined:
Retrieve
Retrieveindicators
indicators
for 5 working days
NO
P392bBSC=1000 and P392aBSC>900
during at least 12% of GPU_for_MS_context_handling =0
the observed period
YES
YES
Observed QoS acceptable GPU_for_MS_context_handling =0
for the customer?
NO
GPU_for_MS_context_handling =1
Figure 94: 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 B11 as 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)
The CPU load must be supervised and considered, because any overload is leading,
sometimes, to very critical situations (i.e. GPU reboots).

Even if in most of the analysed cases the overload was due to an abnormal increase of
events to be managed, the workaround for avoiding blocking conditions could be the
adding of 1 additional GPU board.
In order to determine GPU_for_Power_Limitation, two methodologies have been built
in order to detect an overload at PMU CPU (see Figure 95) or DSP CPU level (see
Figure 96).
Retrieve indicators
for 5 working days
P402/3600>3% OR P76a>70% NO
during at least 12% of GPU_for_Power_Limitation=0
the observed period
YES
NO
(P402/3600>3% OR P76a>70%) and cpu_cong_fail_rate>1% OR GPU reboots GPU_for_Power_Limitation=0
observed the CPU loaded hours
YES
GPU_for_Power_Limitation=1
Figure 95: GPU_for_Power_Limitation due to PMU CPU load
In Figure 95,
P105e P105f
cpu _ cong _ fail _ rate = Max( ; )
P91a + P91b + P91c + P91d + P91e + P91f P62a + P62b + P62c - P438c
Retrieve indicators
for 5 working days
Max(P201,P202)/3600>3% NO
during at least 12% of GPU_for_Power_Limitation=0
the observed period
YES
NO
Max(P201,P202)/3600>3% and dsp_load_fail_rate>1% OR GPU reboots GPU_for_Power_Limitation=0
observed during the CPU loaded hours
YES
GPU_for_Power_Limitation=1
Figure 96: GPU_for_Power_Limitation due to DSP CPU load

In Figure 96,
P 203 P 204
dsp _ load _ fail _ rate = Max( ; )
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 1 200 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 - GTRATERQN GPRS_TBF_request Number of UL and DL TBF
P438c + P507 + P91a establishment request per
+ P91b + P91c + cell.
P91d + P91e + P91f
+ P505
P403a + P403b + GTRRRRQN GPRS_TBF_realloc_request Total number of UL+DL
P403c + P403d + TBF reallocation requests.
P404a + P404b +
P404c + P404d
Table 56: Counter list for TBF load assessment
If the limit is exceeded, and PMU CPU overload is observed, 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

Maximum number of DL TBF
P35 GTRDTBM_MA GPRS_DL_TBF_estab_max simultaneously established over
the Granularity period.
Average number of DL TBF
P36 GTRDTBA_MA GPRS_DL_TBF_estab_avg_max simultaneously established over
Maximum number of UL TBF
P39 GTRUTBM_MA GPRS_UL_TBF_estab_max simultaneously established over
Average number of UL TBF
P40 GTRUTBA_MA GPRS_UL_TBF_estab_avg_max simultaneously established over
Table 57: Counter list for TBF assessment per cell
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.
The same counters or indicators can be used to check if the max number of DL + UL TBF
simultaneously established per GP(U) is below the limit from Table 52.

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.

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 OR N S -V C I o r R e m o te IP E n d p o in t
la y e r
N S -V C R e m o te IP e n d p o in t
PVC
SN S sub
la y e r N S -V L
IP E n d p o in t
Layer 1 IP n e t w o r k
N S -V L F R b e a re r
F R n e tw o rk
Figure 97: Gb interface configuration (from 3BK 09559 LAAA EBZZA)

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.
The main Telecom Parameters are:
Default
System Name OMC-R modifiable Instance Unit Min Max Definition
Value
Mode of the transport for Gb
interface: FR or IP.
Gb_Transport_Mode Changeable BSS None 0 1 0
0: FR
1: IP
Mode of the transport for Gb
Gb_Transport_Mode_per interface (per NSE).
Changeable NSE None 0 1 0
_NSE 0: FR
1: IP
Configuration type used with
Gb over IP.
Gb_Configuration_type Changeable NSE None 0 1 0
0: Static configuration
1: Dynamic Configuration
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 Frame Relay Gb
1) Through a FR Network MFS Netwok
SGSN
Gb
2) Direct MFS - SGSN connections MFS
Gb
Gb
3) Through NSS transmission network MFS MSC/VLR MSC/VLR
Figure 98: Gb interface connections


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.
E1 Ater(circuit)
PDH/SDH network A TC
Ater(packet)
BSC
MSC
GE
MFS
Gb GE
Full redundant architecture, Packet Switched Network SGSN

Seen as single gateway IP@
Figure 99: 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

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 required number Gb TS (GboFR) and average throughput

(GboFR and GboIP)
Gathered Counters:

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.
P43 GTGBVCDLN Number of DL LLC bytes received from the SGSN at BSSGP level
per cell.
P44 GTGBVCULN Number of UL LLC bytes sent to the SGSN at BSSGP level per cell.
P74 GTRDTDLPN Number of DL LLC PDUs transmitted to the RLC layer.
P75 GTRUTDLPN Number of LLC PDUs transmitted in UL during granularity period.
Table 58: 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
Required Gb Nb of required TS per

Traffic GboFR link
Erlang C
Minimum Throughput
GoS: for GboIP link
% Quantile of x
delay sec
Figure 100: 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.
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
The required number Gb TSs (GboFR) and the average throughput (GboFR and GboIP),
as shown below.
3.7.2.1 Gb over Frame Relay

For GboFR interface, the measured traffic corresponds to P45 and P46 counters.
Max ( P 45, P 46 )
Measured _ GboFR _ traffic =
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 [15] .

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:
Target: Find the DL and UL traffic during BH using counters at SNS 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 SNS and FR level (FR case overhead is of 6 bytes
per 300 bytes of payload).
More precise results may be obtained if the average LLC PDU size (payload) is computed
as shown below:
Average LLC PDU size in DL = a = P43/P74
Average LLC PDU size in UL = b = P44/P75
FR overhead for SNS level = 6 bytes (2 for FR and 4 for NS)
Header correction factor in DL = HCDL = (6 + a)/a
Header correction factor in UL = HCUL = (6 + b)/b
Data rate DL/UL, at GPU or BSC level:
DL Data rate [Kbps] = HCDL*(P45*8 )/(3600-P34)
UL Data rate [Kbps] = HCUL*(P46*8)/(3600-P34)
Data rate in DL (SGSN to MFS) and in UL (MFS to SGSN) may be calculated also at LLC
level, aggregated at GP or BSC level:
FR overhead for LLC level = 54 bytes (2 for FR, 4 for NS and 48 for BSSGP)
DL Data rate [Kbps] = HCDL*(P43*8 )/(1000*3600)
UL Data rate [Kbps] = HCUL*(P44*8)/(1000*3600)
Note: The counters P43, P44, P74 and P75 (and related indicators) are available only at
BSC level.
3.7.2.2 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, BSC or MFS level:
DL Data rate [Kbps] = 1.233*(P45a*8)/(3600-P34a)
UL Data rate [Kbps] = 1.233*(P46a*8)/(3600-P34a)
More precise results may be obtained if the average LLC PDU size (payload) is computed
as shown below:
IP overhead for SNS level = 70 bytes (38 for Ethernet, 28 for UDP and 4 for NS)
DL Data rate [Kbps] = HCDL*(P45a*8 )/(3600-P34a)
UL Data rate [Kbps] = HCUL*(P46a*8)/(3600-P34a)
Data rate in DL (SGSN to MFS) and in UL (MFS to SGSN) may be calculated also with
LLC counters, but only at BSC level:
IP overhead for LLC level = 118 bytes (38 for Ethernet, 28 for UDP, 4 for NS and 48
for BSSGP)
DL Data rate [Kbps] = HCDL*(P43*8 )/(1000*3600)
UL Data rate [Kbps] = HCUL*(P44*8)/(1000*3600)
BSC level.
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 it may be
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%.
More precise bandwidth estimation may be also obtained computing the average
LLC PDU size. For SNS counter case we get the following estimation:

Header correction factor in DL = HCDL = (70 + a)/(6 + a)
Header correction factor in UL = HCUL = (70 + b)/(6 + b)
Estimated DL IP Data rate [Kbps] = HCDL*(P45*8)/(3600-P34)
Estimated UL IP Data rate [Kbps] = HCUL*(P46*8)/(3600-P34)
For LLC counter case (only at BSC level) we get the following estimation:
Header correction factor in DL = HCDL = (118 + a)/(54 + a)
Header correction factor in UL = HCUL = (118 + b)/(54 + b)
Estimated DL IP Data rate [Kbps] = HCDL*(P43*8)/(1000*3600)
Estimated UL IP Data rate [Kbps] = HCUL*(P44*8)/(1000*3600)
BSC level.
Important: The max UL+DL Gb data rate must be below the GP(U) limit (Table 48).
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.

3.7.3 Gb-Flex
This feature is available starting with B11MR1ed2.
Gb-Flex feature allows a BSS to be connected to more than one SGSN.
Overview
The current Alcatel-Lucent BSS implementation is based on the legacy network
architecture: a BSS can only be connected to one SGSN. Gb Flex feature allows a BSS to be
connected to more than one SGSN. In Alcatel-Lucent solution, Gb-Flex works only with Gb
over IP. It simplifies the connection used for the transmission in Frame Relay. One NSE is
defined per GPU for each SGSN connected to the BSS. Up to 8 SGSN can be connected to a
GPU. Up to 8 NRI can be defined per SGSN.
SGSN Pool
SGSN1 SGSN2 SGSN3
BSS6
BSS3
BSS4 BSS5
BSS1 BSS2
City center
Figure 101: Gb-Flex Architecture
For a BSS, an SGSN is identified by its NRI we can extend the evolution by defining
several NSE for a BSS. NRI allow identifying an SGSN from a BSS point of view. The
operator creates the NSE to define the NSEI. The information related to the SGSN is set in the
NSE. En_Gb_Flex, NRI length and NULL NRI PS are new BSS attributes.
Several restrictions exist. All the NSEs belonging to the same SGSN and linked to one
BSS and having child IPendpoints must have the same config type when Gb_Transport_Mode
mode is IP.
The activation is at BSS level and managed as an RNL licensed feature. As the feature
depends on Gb over IP support, which is also an optional feature, activation of the Gb flex
feature can be refused either because the Gb over IP is not supported on the BSS or because
of Gb-flex license.
For an operator the benefit of this feature is the following:

Load sharing can be done by the BSS for each SGSN where the BSS is connected.
Possibility of capacity upgrades by additional SGSN in the pool-area.
Increase the reliability when an SGSN fails thanks to SGSN redundancy.

To have several SGSN allow to enlarge the served area and the reduction of signalling
within the core network (e.g. reduction of the HLR signalling traffic).
Possibility to off-load an SGSN to perform maintenance.
CAPEX reduction thanks to load distribution on the SGSN of the pool.
Step to the feature Multi-Operator Core Network (not in the scope of B11).
Definitions
IP Endpoint
An endpoint is defined by its IP address and UDP port. An IP endpoint can be a data
endpoint, a signalling endpoint or a pre-configured endpoint. An IP endpoint may be
concomitantly data and signaling endpoint.
NsVc
The NS-VC (Network Service Virtual Connection) is given by a pair of IP endpoints
at the MFS and SGSN.
For each NSE in the BSS one IP Endpoint per NSE, defining the IP address and UDP
port used by the SGSN, to reach the MFS, are defined.
Network Service Entity Identifier (NSEI)
NSEI is an identifier of an NS Entity having end-to-end significance across the Gb
interface, i.e. the peer NSEs on the BSS side and the SGSN side are identified by the
same NSEI value.
Pool area
To connect a BSS to several SGSN, the notion of pool area is introduced. A core
network (CN) node is either the MSC in CS domain or the SGSN in PS domain.
The following definition is an extract of the 3GPP 23.236: Pool-area: A pool area is
an area within which a MS may roam without need to change the serving CN node. A
pool area is served by one or more CN nodes in parallel. All the cells controlled by a
BSC belong to the same one (or more) pool area(s).
One pool area can be served by one or several SGSNs.
One BSS can belong to several pool areas.
RA1
SGSN Pool
LAC1 SGSN
Pool Area
BSC1
IP NETWORK
RA2
MFS
SGSN
RA3
BSC2
LAC2
Figure 102: LA, RA and SGSN pool

As specified by 3GPP 23.234 sub-clause 4.3 : If LAs or RAs span over multiple
RAN node service areas then all these RAN node service areas have to belong to the
same pool-area.
For the BSS it means that LAC and RA defined on several BSS must belong to the
same pool area. This is only a rule that can be given to the operator. No control to be
done at the OMC-R. The granularity in a pool area is the BSS.
Pool area and Network Resource Identification

An MS is served by one dedicated CN node of a pool-area as long as it is in radio
coverage of the pool-area. This is done thanks to the Network Resource Identifier
(NRI). The NRI is part of the temporary identity TMSI (CS domain) or P-TMSI (PS
domain), which is assigned by the serving CN node to the MS.
The NRI identifies uniquely an individual CN node out of all CN nodes, which serve
in parallel a pool-area. The length of the NRI shall be the same in all nodes of a
domain in one pool-area.
In areas where pool-areas overlap the NRI identifies uniquely a CN node out of all CN
nodes, which serve all these overlapping pool-areas, i.e. an NRI identifies uniquely a
CN node within a BSS.
The NRI has a flexible length between 1 and 10 bits. The NRI length is defined per
BSS. It is significant only when En_Gb_Flex is enabled in the BSS. The change of a
pool-area is not visible to the MS.
In general there is no need to detect a pool-area change. It may be advantageous for
load balancing purposes to detect pool-area changes in the network to distribute MSs
entering a pool-area to CN nodes with an appropriate load status. MSs changing a
pool-area may be detected by configuration of different NRI values for adjacent pool-
areas.
When a mobile changes of pool area, if the NRI defined in its P-TMSI, is also defined
in the new pool area, the NAS Node Selection Function will not be used. In this case,
there is no load balancing between the SGSNs of the new pool area.
Null-NRI
A 'null-NRI' indicates to the MFS that the NAS Node Selection Function shall be used
for selecting a SGSN to receive a message. There is one unique 'null-NRI' in PLMN
supporting pool functionality.
In B11 the Multi-Operator Core Network feature is not supported consequently, the
MFS supports only one unique 'null-NRI'.
NAS Node Selection Function
In the BSS, the function selects the specific CN node (i.e. SGSN) to which initial NAS
signalling messages or LLC frames are routed.
The pool-area has no influence on the decisions of the NAS Node Selection Function
as pool-areas may overlap. Once, an SGSN is selected for a mobile in a pool area, we
keep this association.
The SGSN is selected according to the NRI found in the TLLI (case of foreign or local
TLLI). Its the SGSN, which sets the NRI in the P-TMSI. The NRI is coded in bits 23

to 14 of P-TMSI. Regardless of the NRI length the most significant bit of the NRI is
always in bit 23 of P-TMSI.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
NRI
Figure 103: P-TMSI structure with NRI length set to 5.
The TLLI consists of 32 bits, numbered from 0 to 31 by order of significance, with bit
0 being the LSB. As the local or foreign TLLI is based on the P-TMSI, we will find
the NRI in the TLLI at the same position (from bit 23).
Valid P-TMSI 31 30 29 -24 NRI 18-0
Local TLLI 31 30 29 -24 NRI 18-0
2 bits set to 1
Figure 104: P-TMSI and TLLI
Off-loaded
There are situations where a network operator will wish to remove load from one CN
node in an orderly manner (e.g. to perform scheduled maintenance, or, to perform load
re-distribution to avoid overload) with minimal impact to end users and/or additional
load on other entities.
This is done in the BSS, by removing the CN node from the NAS Node Selection
Function. The SGSN is removed from the NAS Node Selection function by setting the
attribute SGSN_OFFLOAD_STATE SGSN Load Status to offloaded.
SGSN selection
The Node Selection Function (NSF) is used to select an SGSN when:
SGSN associated to the MS context is not known (NRI not significant in the MS
context).
SGSN associated to the MS context is out of service (bvc-sig of the NSEI related to
the NRI is no more operational).
SGSN associated to the cell where the MS is located is out of service (bvc-ptp of the
NSEI related to the NRI is not (operational, started)).
NRI retrieved in the TLLI is the Null-NRI.
NRI retrieved in the TLLI (foreign or local) is not known.
TLLI is random.
The NSEI used to select an SGSN, is updated in the MS context in the following cases:
NSEI selection by the NSF,
DL PDU reception with a local TLLI,
Start of Ul transfer with a local TLLI and no NSEI defined in the Ms context,

Start of Ul transfer with a foreign TLLI whose NSEI is known and no NRI defined in
the Ms context,
Reception of a Pfc create from the SGSN (Packet Flow Context feature used to
support the QoS).
Optionality
This feature is commercial optional.
It can be activated at BSC level by the parameter En_Gb_Flex.
The feature is licensed at OMC level and the activation is per BSS.
One new OMC-R limit named, NUMBER_OF_GbFlex_TRX is added for Gb flex
TREs, representing the maximum number of (PS) TRXs belonging to cells mapped on
BSCs having EN_GB_FLEX = Enabled.
As the feature depends on Gb over IP support, which is also an optional feature,
activation of the Gb flex feature can be refused either because the Gb over IP is not
supported on the BSS or because of Gb-flex licence.

Gb Flex is a 3GPP Release 5 feature.
This feature is only supported on the MFS DS10 and MFS Evolution.
It works only with Gb-Over-IP.
SGSNs must support the feature.
To support Gb-flex, the SGSN release should be Release 99 onwards.
Alcatel-Lucent SGSNs support this feature staring with U3.3 release.

It is not supported on MFS AS800.
It is not supported when FR is used between BSS and SGSN.
3.7.4 IP Flow segregation at MFS level

IP Flow segregation in MxMFS is a new feature allowing several routers to be used for improved
flexibility between the different IP flows (O&M and Gb over IP in case of MxMFS).
This feature is available starting with B11MR1ed2.
Definition:
The flow segregation is physical, that is to say it is obtained by dedicating one MFS switch
Ethernet port per flow to segregate. Its based on the operator request.
Several routers may be used to allow better flexibility between the different IP flows (O&M,
IPGSL, IPGCH, BSS over IP or Gb over IP).
The IP traffic without router (L2 networks) is also allowed, the flow segregation and MFS
internal VLAN tag configuration applying to both L2 and L3 cases.
Benefits:
Having better organization in terms of separate teams working independently on each telecom
flow.

Allows for segregation at L1, which allows also for L2 segregation as a workaround due to
lack of VLAN tagging in MFS and the need for an external router.
In B11MR1ed2, Telecom IP flow means only Gb over IP.
After B11MR3 introduction, more Telecom IP flows (IPGSL, IPGCH, BSS over IP or Gb
over IP) will be available, and more combinations for IP flow segregation will be possible.
ONE LAN Topology (without GboIP)

This solution without RIP V2 provides redundancy for the O&M link using the static route.
The subnet A is the external and visible subnet from the IP O&M network.
In one LAN configuration, both switch boards are connected to the same LAN.
It is mandatory to be already in one LAN configuration to operate GboIP feature.
Telecom flows over IP are supported in one LAN topology only.
IP Telecom subnet configurations are following:
o O&M and Telecom flows in same subnetworks (no segregation)
o O&M and Telecom flows in different subnetworks (flow segregation)
o The flow segregation is physical, dedicated MFS switch port per flow.
ONE LAN Topology (with GboIP)

The subnet A is the external and visible subnet from the IP O&M/Telecom network.
There are dedicated IP addresses for the O&M transport and dedicated IP addresses for the
Telecom transport.
Subnet A
SSW 1 Router 1
port 3
VRRP IP O&M/TELECOM
GPU x
CS A
CS B
NETWORK
Router 2
port 3
SSW 2
MX-MFS
CS A: Control Station A
CS B: Control Station B
Figure 105: Mx-MFS in one LAN configuration with one external subnet
(O&M and Telecom are mixed no segregation)

Router O&M 1
Subnet A1 for O&M
VRRP IP O&M
Network
port 3 Router O&M 2
SSW 1
port 7
Router GboIP 1
CS B
CS A
GPs VRRP IP Telecom
port 3 Network
SSW 2 Router GboIP 2
port 7
MX-MFS Subnet A2 for GboIP
Figure 106: Mx-MFS in one LAN configuration with two external subnets
(O&M and Telecom are separated)
LAN IP Transport mode External

Comments
Topology possibility Subnet(s)
A is the only one external Subnet dedicated to

O&M only A
O&M
O&M and Telecom
A is the external Subnet shared by O&M and
with one shared A
One LAN Telecom
subnet
O&M and Telecom
A2 is the external subnet with Telecom when
with two separate A1, A2
A1 is dedicated to O&M
subnets
A is the external Subnet and there are 2 local
Two LAN* O&M only A
subnets named B and C.
*The Two LAN topology is not compatible with telecom over IP features, such as Gb over IP.
Table 59: Possible LAN configurations
The feature activation is obtained by changing the parameter VLAN_CONF_INDEX from

0 to 1.
VLAN_CONF_INDEX Definition
O&M and telecom (GboIP) use a common router.

0
1 Ethernet port is used per switch board.
O&M and telecom (GboIP) use two different routers.
1
2 Ethernet ports are used per switch board.
Table 60: Parameter values for IP flow segregation feature activation
END OF DOCUMENT


B11 BSS Arch Serv GuideLine Ed2RL

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

B11 BSS Arch Serv GuideLine Ed2RL

Enviado por

Direitos autorais:

Formatos disponíveis

Site

Mobile Radio Division

Domain : Network Architecture

Appraisal and approval authorities

TIS Manager Franois Berjon

GSM Romania Manager Ioan Inta

Alcatel File Reference Date Edition Page

2 OVERVIEW OF BSS ARCHITECTURE SERVICES ....................... 17

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

Alcatel File Reference Date Edition Page

3.2.1.5 Secondary Abis Link .................................................................................60

Alcatel File Reference Date Edition Page

3.4.4.2 AterMUX PS...........................................................................................137

3.4.4.3 AterMUX CS/PS .....................................................................................148

Alcatel File Reference Date Edition Page

Alcatel File Reference Date Edition Page

Figure 1: BSS Architecture...................................................................................................17

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

Figure 3: Abis configuration.................................................................................................18

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

Figure 5: A-interface configuration.......................................................................................19

Figure 6: BSS Architecture Services.....................................................................................20

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

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

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

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

Figure 11: BTS generation/type supported in B11..............................................................30

Figure 12: BTS Architecture report from AMT.NET ............................................................35

Figure 13: Determination of BTS configuration....................................................................38

Figure 14: SDCCH dimensioning process.............................................................................40

Figure 15: TCH/PDCH dimensioning process.......................................................................43

Figure 16: TCH/PDCH dimensioning assessment .................................................................46

Figure 17: Abis Chain (Multi-drop) Topology ......................................................................48

Figure 18: Abis Star Topology..............................................................................................49

Figure 19: Abis Ring (Closed loop) Topology ......................................................................49

Figure 20: Secondary Abis Topology....................................................................................50

Figure 21: TRX - Abis mapping ...........................................................................................50

Alcatel File Reference Date Edition Page

Figure 24: 16K Statistical Multiplexing MCB 16/1 mapping .............................................54

Figure 26: 64K Statistical Multiplexing MCB 64/1 mapping .............................................55

Figure 27: 64K Statistical Multiplexing MCB 64/2 mapping .............................................56

Figure 28: 64K Statistical Multiplexing MCB 64/4 mapping .............................................56

Figure 30: Abis TS configuration on primary and secondary links ........................................60

Figure 32: Example of topology with two BTS chained ........................................................61

Figure 33: Two Abis links filling examples. .........................................................................61

Figure 34: Abis dimensioning process Method 1................................................................65

Figure 35: Abis dimensioning process Method 2................................................................67

Figure 36: G2 BSC (A9120 BSC) Architecture.....................................................................70

Figure 37: G2 BSC Cabinet layout .......................................................................................71

Figure 38: Abis TSU G2 BSC............................................................................................72

Figure 39: Ater TSU G2 BSC ............................................................................................74

Figure 40: BSC Evolution (A9130 BSC) HW Architecture...................................................75

Figure 42: Asig Over IP Architecture ...................................................................................85

Figure 43: SS7 protocol stack (SIGTRAN)...........................................................................85

Alcatel File Reference Date Edition Page

Figure 45: Multi-homing on MSC side .................................................................................88

Figure 46: Multi-homing on BSC side ..................................................................................88

Figure 47: A-Flex Architecture.............................................................................................89

Figure 48: Example of a TMSI structure with 7 bits NRI-length ...........................................92

Figure 49: TP-STM1 architecture .........................................................................................94

Figure 50: TPGSMv3 STM1 board.......................................................................................95

Figure 51: Network Architecture with STM1........................................................................96

Figure 54: BSC dimensioning process ................................................................................100

Figure 58: Transmission load checking...............................................................................103