B11 BSS Arch Serv GuideLine Ed1

Alcatel File Reference Date Edition Page
B11_BSS_arch_serv_GuideLine_Ed1.doc 3DF 01903 8110 VAZZA 01 January 29, 2010 1 1 / 180

Site
Vlizy
Mobile Radio Division
Originator(s)
E. Marza
B11: BSS Architecture Service Guideline

Domain : Network Architecture
Product : GSM B11
Division : Methods
Rubric : GSM/GPRS/EDGE
Type : Guidelines
Distribution codes Internal:

Pre-distribution:
NE Velizy NE Timisora NE Portugal NE Egypt
F. Colin Cristian I. Inta Pedro Henriques Maged Sayed
T. Plantier E. Marza Joo Frade
LM. Palumbo

Abstract: 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 & 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
NE Manager Florent Colin

GSM Romania Manager Oliviu Burlacu

All Alcatel system details given in this document are for your comfort only. The system
information may not reflect the latest status of the equipment used in your project.
Please consult in addition to this document the latest product descriptions!


Table of contents

1 INTRODUCTION.................................................................................. 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
3 DETAILED BSS ARCHITECTURE PROCESS................................. 29
3.1 BTS........................................................................................................................29
3.1.1 BTS Configuration.........................................................................................29
3.1.1.1 Cell Configuration.....................................................................................34
3.1.1.2 SDCCH Configuration ..............................................................................35
3.1.2 Determination of BTS configuration..............................................................36
3.1.3 Cell dimensioning..........................................................................................37
3.1.3.1 SDCCH Dimensioning ..............................................................................37


3.1.3.2 TCH/PDCH Dimensioning ........................................................................39
3.2 ABIS INTERFACE......................................................................................................46
3.2.1 Abis Configuration........................................................................................46
3.2.1.1 Abis Network Topology ............................................................................46
3.2.1.2 Abis Channels ...........................................................................................48
3.2.1.3 Abis Link Capacity....................................................................................50
3.2.1.4 Signalling Sub-Multiplexing Schemes .......................................................50
3.2.1.4.1 No Multiplexing......................................................................................................................... 51
3.2.1.4.2 16K Static Multiplexing............................................................................................................. 51
3.2.1.4.3 16K Statistical Multiplexing...................................................................................................... 52
3.2.1.4.4 64K Statistical Multiplexing...................................................................................................... 53
3.2.1.5 Secondary Abis Link .................................................................................58
3.2.2 Abis Dimensioning ........................................................................................61
3.2.2.1 Method 1...................................................................................................62
3.2.2.2 Method 2...................................................................................................64
3.3 BSC........................................................................................................................68
3.3.1 G2 BSC Configuration ..................................................................................68
3.3.1.1 BSC Capacity............................................................................................69
3.3.1.2 Abis TSU..................................................................................................70
3.3.1.3 Ater TSU...................................................................................................72
3.3.2 BSC Evolution Configuration ........................................................................72
3.3.2.1 BSC Capacity............................................................................................74
3.3.2.2 Delta BSC Evolution versus G2 BSC ........................................................75
3.3.2.3 TP GSM board ..........................................................................................76
3.3.2.4 CCP board.................................................................................................76
3.3.2.5 LIU shelf ...................................................................................................77
3.3.2.6 SS7 transport .............................................................................................77
3.3.2.7 HSL usage.................................................................................................78
3.3.2.8 The maximum ERLANG capacity, BHCA and Mean TCH duration..........80
3.3.3 New B11 features related to MxBSC..............................................................82
3.3.3.1 AsigOverIP ...............................................................................................82
3.3.3.2 A-Flex.......................................................................................................87
3.3.3.3 STM1 impact on BSC................................................................................91
3.3.4 BSC Dimensioning ........................................................................................95


3.3.4.1 Design BSC area .......................................................................................96
3.3.4.2 Parenting Abis ports of the BSC................................................................98
3.3.5 LA Dimensioning.........................................................................................100
3.3.5.1 LA Definition and Capacity.....................................................................100
3.3.6 RA Dimensioning ........................................................................................104
3.3.7 Summary of LA/RA dimensioning process....................................................106
3.3.8 CCCH dimensioning....................................................................................107
3.4 ATERMUX AND A INTERFACES..............................................................................109
3.4.1 General .......................................................................................................109
3.4.1.1 AterMUX interface..................................................................................109
3.4.1.2 A interface...............................................................................................109
3.4.1.3 AterMUX interface versus A interface.....................................................109
3.4.2 AterMUX configuration...............................................................................110
3.4.2.1 AterMUX CS and A interfaces ................................................................111
3.4.2.2 AterMUX PS...........................................................................................113
3.4.2.3 AterMUX CS/PS.....................................................................................114
3.4.3 SS7 Signalling mode....................................................................................116
3.4.3.1 LSL and HSL modes ...............................................................................116
3.4.3.2 SS7 Dimensioning for TDM Mode..........................................................116
3.4.3.3 SS7 Dimensioning for IP Mode (Asig over IP) ........................................123
3.4.4 AterMUX Dimensioning ..............................................................................126
3.4.4.1 AterMUX CS ..........................................................................................126
3.4.4.1.1 A Dimensioning....................................................................................................................... 129
3.4.4.2 AterMUX PS...........................................................................................130
3.4.4.2.1 Process description .................................................................................................................. 130
3.4.4.2.2 GSL Dimensioning .................................................................................................................. 133
3.4.4.2.3 GCH/AterMUX-PS Dimensioning .......................................................................................... 139
3.4.4.3 AterMUX CS/PS.....................................................................................141
3.5 TC........................................................................................................................143
3.5.1 G2 TC Configuration...................................................................................144
3.5.2 G2.5 TC Configuration................................................................................144
3.5.2.1 New MT120-xB boards available ............................................................145
3.5.3 TC Dimensioning ........................................................................................146
3.5.4 STM-1 in TC................................................................................................147


3.5.4.1 Functional Requirements .........................................................................147
3.5.4.2 Overall description ..................................................................................147
3.5.4.3 TC Configuration ....................................................................................148
3.6 MFS .....................................................................................................................149
3.6.1 The 1
st
MFS generation (A9135 MFS) .........................................................149
3.6.1.1 GPRS Processing Unit (GPU)..................................................................150
3.6.1.2 Multiple GPU per BSS ............................................................................150
3.6.1.3 Capacity ..................................................................................................151
3.6.2 MFS Evolution (A9130 MFS) ......................................................................151
3.6.2.1 Configurations and Capacity....................................................................152
3.6.2.2 Delta MFS Evolution versus the 1
st
MFS generation................................153
3.6.3 GP(U) Dimensioning and AterMux PS dimensioning (user traffic) ..............155
3.6.3.1 Required GCH traffic estimation .............................................................158
3.6.3.2 GP(U) GCH capacity estimation..............................................................160
3.6.3.3 GP(U) limitations ....................................................................................162
3.7 GB INTERFACE.......................................................................................................167
3.7.1 Gb configuration.........................................................................................169
3.7.2 Gb Dimensioning ........................................................................................171
3.7.2.1 Gb over Frame Relay...............................................................................172
3.7.2.2 Gb over IP...............................................................................................173
3.7.3 Gb-Flex.......................................................................................................176


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..............................................................29
Figure 12: Determination of BTS configuration....................................................................36
Figure 13: SDCCH dimensioning process.............................................................................38
Figure 14: TCH/PDCH dimensioning process.......................................................................41
Figure 15: TCH/PDCH dimensioning assessment .................................................................44
Figure 16: Abis Chain (Multi-drop) Topology ......................................................................46
Figure 17: Abis Star Topology..............................................................................................47
Figure 18: Abis Ring (Closed loop) Topology ......................................................................47
Figure 19: Secondary Abis Topology....................................................................................48
Figure 20: TRX - Abis mapping ...........................................................................................48
Figure 21: Example of Abis TS usage for 1 BTS/4 TRX No Multiplexing.........................51


Figure 22: Example of Abis TS usage for 1 BTS/4 TRX 16K Static Multiplexing .............52
Figure 23: 16K Statistical Multiplexing MCB 16/1 mapping .............................................52
Figure 24: Example of Abis TS usage for 1 BTS/4 TRX 16K Statistical Multiplexing.......53
Figure 28: Example of Abis TS usage for 1 BTS/4 TRX 64K Statistical Multiplexing.......54
Figure 29: Abis TS configuration on primary and secondary links ........................................58
Figure 30: BTS with 24 TRX mapped on both Abis links .....................................................58
Figure 31: Example of topology with two BTS chained........................................................59
Figure 32: Two Abis links filling examples. .........................................................................59
Figure 33: Abis dimensioning process Method 1................................................................63
Figure 34: Abis dimensioning process Method 2................................................................65
Figure 35: G2 BSC (A9120 BSC) Architecture.....................................................................68
Figure 36: G2 BSC Cabinet layout .......................................................................................69
Figure 37: Abis TSU G2 BSC............................................................................................70
Figure 38: Ater TSU G2 BSC............................................................................................72
Figure 39: BSC Evolution (A9130 BSC) HW Architecture...................................................73
Figure 40: Abis and Ater allocation on LIU boards / BSC capacity.......................................77
Figure 41: Asig Over IP Architecture ...................................................................................83
Figure 42: SS7 protocol stack (SIGTRAN)...........................................................................83
Figure 43: Connections between the BSC and MSC Servers.................................................84


Figure 44: Multi-homing on MSC side .................................................................................86
Figure 45: Multi-homing on BSC side ..................................................................................86
Figure 46: A-Flex Architecture ...........................................................................................87
Figure 47: Example of a TMSI structure with 7 bits NRI-length ...........................................90
Figure 48: TP-STM1 architecture .........................................................................................92
Figure 49: TPGSMv3 STM1 board.......................................................................................93
Figure 50: Network Architecture with STM1....................................................................94
Figure 51: BSC dimensioning process ..................................................................................95
Figure 52: BTS position & configuration design BSC area step 1 ......................................96
Figure 53: Transmission planning & BSC position design BSC area step 2........................97
Figure 54: BSC area definition design BSC area step 3......................................................97
Figure 55: Transmission load checking.................................................................................98
Figure 56: BTS / Abis parenting on BSC done by AMT.NET............................................99
Figure 57: LA dimensioning assessment.............................................................................103
Figure 58: Subdivision of a LA in GPRS routing areas (RA) ..............................................104
Figure 59: AterMUX and A relationship.............................................................................109
Figure 60: AterMUX interface structure .............................................................................110
Figure 61: AterMUX CS interface configuration G2 BSC................................................111
Figure 62: Channel mapping between AterMUX CS and A................................................112
Figure 63: AterMUX PS interface configuration - GPU......................................................113
Figure 64: Sharing AterMUX links.....................................................................................114
Figure 65: AterMUX CS/PS Timeslot configuration...........................................................115


Figure 66: SS7 message length (in bytes) according to GSM event .....................................117
Figure 67: Difference between Exact busy hour, NPO busy hour and Peak traffic...............119
Figure 68: IP packet structure for Asig over IP ...................................................................124
Figure 69: Method for Asig over IP dimensioning ..............................................................125
Figure 70: AterMUX-CS dimensioning process..................................................................127
Figure 71: AterMux-PS dimensioning process at BSC level ...............................................131
Figure 72: AterMux-PS dimensioning process at GP(U) level ............................................131
Figure 73: GSL dimensioning method ................................................................................133
Figure 74: GSL messages processing..................................................................................135
Figure 75: GSL dimensioning process ................................................................................136
Figure 76: GSL usage factor ...............................................................................................137
Figure 77: TC G2 architecture with mixed configuration ....................................................143
Figure 78: TC G2.5 architecture .........................................................................................144
Figure 79: TC dimensioning process...................................................................................146
Figure 80: The BSS Architecture with STM-1 on TC side ..................................................148
Figure 81: The 1
st
MFS generation (A9135 MFS) Architecture...........................................149
Figure 82: Multiple GPU per BSS ......................................................................................150
Figure 83: MFS Evolution (A9130 MFS) HW Architecture................................................152
Figure 84: MxMFS rack configurations ..............................................................................152
Figure 85: MFS capacity ....................................................................................................153
Figure 86: GP(U) dimensioning process .............................................................................156
Figure 87 AterMux PS dimensioning process based on user traffic.....................................157


Figure 88: Example of GCH/PDCH traffic relationship in case of AterMux PS
underdimensioning.......................................................................................................159
Figure 89: GCH vs. PDCH traffic relationship: example.....................................................160
Figure 90: Evolution of MS context number on GP(U) .......................................................163
Figure 91 GPU_for_MS_context_handling due to PMU memory limitation .......................163
Figure 92: GPU_for_Power_Limitation due to PMU CPU load..........................................164
Figure 93: GPU_for_Power_Limitation due to DSP CPU load ...........................................164
Figure 94: Gb interface configuration (from 3BK 09559 LAAA EBZZA) ..........................168
Figure 95: Gb interface connections ...................................................................................169
Figure 96: GboIP End-to-End architecture.......................................................................170
Figure 97: Gb dimensioning process...................................................................................171
Figure 98: Gb-Flex Architecture.........................................................................................176
Figure 99: LA, RA and SGSN pool ....................................................................................177
Figure 100: P-TMSI structure with NRI length set to 5. ......................................................179
Figure 101: P-TMSI and TLLI............................................................................................179


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


Table 22: Max BSC Paging rates ..........................................................................................75
Table 23: AsigOverIP limits .................................................................................................85
Table 24: A-Flex limits.........................................................................................................89
Table 25: Counter list LA dimensioning ..........................................................................100
Table 26: Counter list RA dimensioning..........................................................................104
Table 27: CCCH capacity...................................................................................................107
Table 28: Counter list LA dimensioning ..........................................................................107
Table 29: Max number of AterMUX CS interfaces G2 BSC............................................112
Table 30: Max number of A-interfaces G2 BSC...............................................................113
Table 31: Max number of AterMUX PS G2 BSC .............................................................114
Table 32: Ratio of Mixing CS and PS Traffic in AterMUX.................................................115
Table 33: Signaling link requirements for MxBSC .............................................................117
Table 34: Counter list AterMUX-CS dimensioning..........................................................118
Table 36: Counter list Asig over IP dimensioning............................................................123
Table 37: Overheads for Asig over IP.................................................................................124
Table 38: Counter list for Asig over IP traffic in UL and DL ..............................................125
Table 40: Counter list GSL dimensioning ........................................................................134
Table 43: G2 TC/ G2.5 TC capabilities...............................................................................143


Table 44: G2 TC configuration...........................................................................................144
Table 45: G2.5 TC configuration ........................................................................................145
Table 46: G2.5 TC capacity................................................................................................145
Table 47: The 1
st
MFS generation (A9135 MFS) Capacity .................................................151
Table 48: MFS Capacity evolutions....................................................................................153
Table 49: GP(U) Capacity limitations.................................................................................154
Table 50: Counter list - GP(U) dimensioning......................................................................156
Table 51: PDCH number per GP(U) in radio conditions .....................................................161
Table 52: GCH usage depending in coding schemes...........................................................161
Table 53: Counter list for TBF load assessment ..................................................................165
Table 54: Counter list for TBF assessment per cell .............................................................166
Table 55: Counter list - Gb dimensioning ...........................................................................171


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

References:

[1] 3BK 17438 5000 PGZZA BSS Configuration Rules release B11
[2] 3BK 10204 0608 DTZZA
Enhanced Transmission Resource Management
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
[8] 3DC 20003 0031 UZZZA
Dimensioning Rules for CS and PS traffic with BSS
Software Release B11 (TDM transport)
[9] 3DC 21150 0348 TQZZA
GSM/GPRS/EDGE Radio Network Design Process for
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.

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

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

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

).
MFS (Multi-BSS Fast packet Server): To be able to support PS traffic, a MFS is
introduced in the BSS in order to manage data packets.

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

BTS
BTS
BTS
BSC
MFS
TC
NSS
(CS traffic)
GSS
(PS traffic)
Um Abis
AterMUX CS
Gb
A
BSS (CS+PS traffic)
AterMUX PS
AterMUX CS/PS


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.

Abis
CH# 1 CH# 2 CH# 3 CH# 4
TS 0
TS 1
:
:
TS 26
TS 27
TS 28
TCH / GCH TCH / GCH TCH / GCH TCH / GCH
TS 29
TCH / GCH TCH / GCH TCH / GCH TCH / GCH
TS 30
TS 31
TS : 64 K bits/sec
Channel or N ibble : 16 K bits/sec
TS 0 Transparency
OML
RSL
Extra TS
Extra TS
:
:
Free
Mapping to 1 TRX
of Um Interface

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
TS 1 TCH TCH TCH TCH
:
:
TS 14 Qmux TCH TCH TCH
TS 15
TS 16
:
:
TS 31
TS : 64 Kbits/sec
Channel or Nibble : 16 Kbits/sec
Frame Synchronization
Alarm octet
SS7
X25
:
:
:
:

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
TS 1
TS 2
TS 3
:
:
:
:
TS 30
TS 31
TS : 64 Kbits/sec
CIC 1
CIC 2
CIC 3
:
:
:
:
CIC 30
CIC 31

Figure 5: A-interface configuration
2.1.2.5 Gb interface
The Gb interface connects the MFS with the SGSN
2
(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).

Network Architecture
Evolution
Assessment
Setup
Initial
Steady
Developing
BSS Architecture Services
Network State

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
(2) Design/Re-design
(2b) BSC/MFS (GPU/GP)/TC Configuration
(2d) Parenting Abis TSU/LIU ports of the BSC
(2a) BSC/LAC/RAC Areas
(2c) Number of interfaces: Abis, AterMUX, A and Gb
(3) Operational Implementation, according to (2)

FINISH
NW Configuration Rules

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
MFS
G2 TC, G2.5 TC
(A9125 Compact TC)
Configuration - Conf 1, 2, 3, 4, 5 or 6 for
A9120 BSC
- Stand Alone / Rack shared
configuration with 200, 400,
600, 800 or 1000 TRX for
A9130 BSC
Nb of GP(U) boards
dedicated to each
BSC
Nb of MFS racks
- Nb of TC boards
dedicated to each BSC
- Nb of TC racks
Table 1: BSC-MFS/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.
FINISH
START
(1) Gathering Data
NW Configuration Rules
Recommendation/Threshold
(2) Applying Dimensioning Methods
Counters/Indicators vs. Configuration analysis
for each Network Elements and Interfaces
(3) Assessment
- Identify bottle necks
- Identify need of new resources / new configuration

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.


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.

Figure 11: BTS generation/type supported in B11

Evolium BTS 3
rd
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

BTS
Generation
Evolium Evolution Evolium BTS
G3 BTS
M4M
G4 BTS
M5M
GPRS
CS-1 to CS-4
GPRS CS-1 to CS-4
EDGE MCS-1 to MCS-9


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
Physical Logical BTS
Min Max Min
Evolium BTS
(G3 / G3.5)
1 TRE Up to 18 TRE (1 to 6 sectors) 1 TRE TRE
M4M
(micro BTS)
2 TRE Up to 6 TRE (1 to 6 sectors) 2 TRE 1 TRE
Data in this table, based on [1]
Table 2: Configuration Evolium BTS

For more details, please refer to [1] and [5] .

Evolium Evolution 4
th
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

Their configurations are presented in Table 3.

Extension/Reduction
Configuration
Physical Logical BTS
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:

Evolium BTS Evolium Evolution BTS B11 Release
G3 BTS M4M G4 BTS M5M
No Multiplexing X X X X
16K Static Multiplexing X X X X
64K Statistical Multiplexing X X X X
16K Statistical Multiplexing X X X X
A
b
i
s

f
e
a
t
u
r
e

2nd Abis access X X X
FR X X X X
DR X X X X
AMR X X X X
V
o
i
c
e

T
r
a
f
f
i
c

EFR X X X X
GPRS (CS-1, CS-2) X X X X
GPRS (CS-3, CS-4) X X X X
D
a
t
a

T
r
a
f
f
i
c

EGPRS (MCS-1 to MCS-9) X X
GSM 850 X X
GSM 900 X X X X
GSM 1800 X X X X
M
o
n
o

b
a
n
d

GSM 1900 X X X
850/1800 X X X
850/1900 X X X
900/1800 X X X X
M
u
l
t
i

b
a
n
d

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.

Yes TGT18 A9100 TRX 1800 TWIN G5
Yes TADHE A9100 TRX 1800 HP EDGE PLUS G4
Yes TAGHE A9100 TRX 900 HP EDGE PLUS G4
Yes TRADE A9100 TRX 1800 EDGE PLUS G4
Yes TRAGE A9100 TRX 900 EDGE PLUS G4
Yes TADH A9100 TRX 1800 HP EDGE COMPATIBLE G4
Yes TAGH A9100 TRX 900 HP EDGE COMPATIBLE G4
Yes TRAP A9100 TRX 1900 EDGE COMPATIBLE G4
Yes TRAL A9100 TRX 850 EDGE COMPATIBLE G4
Yes TRAD A9100 TRX 1800 EDGE COMPATIBLE G4
Yes TRAG A9100 TRX 900 EDGE COMPATIBLE G4
No TRDH TRX 1800 60W DR-EFR 9100 G3
No TRDM TRX 1800 35W DR-EFR 9100 G3
No TRGM TRX 900 35W DR-EFR 9100 G3
EDGE MNEMO TRX Type Generation
Yes TADHE A9100 TRX 1800 HP EDGE PLUS G4
Yes TAGHE A9100 TRX 900 HP EDGE PLUS G4
Yes TRADE A9100 TRX 1800 EDGE PLUS G4
Yes TRAGE A9100 TRX 900 EDGE PLUS G4
Yes TADH A9100 TRX 1800 HP EDGE COMPATIBLE G4
Yes TAGH A9100 TRX 900 HP EDGE COMPATIBLE G4
Yes TRAP A9100 TRX 1900 EDGE COMPATIBLE G4
Yes TRAL A9100 TRX 850 EDGE COMPATIBLE G4
Yes TRAD A9100 TRX 1800 EDGE COMPATIBLE G4
Yes TRAG A9100 TRX 900 EDGE COMPATIBLE G4
No TRDH TRX 1800 60W DR-EFR 9100 G3
No TRDM TRX 1800 35W DR-EFR 9100 G3
No TRGM TRX 900 35W DR-EFR 9100 G3
EDGE MNEMO TRX Type Generation

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.


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

Dimension Coverage Partition Range
Micro Micro Overlaid Normal Normal
Single Macro Single Normal Normal
Mini Macro Overlaid Normal Normal
Extended Macro Single Normal Extended
Umbrella Macro Umbrella Normal Normal
Concentric Macro Single Concentric Normal
Umbrella-Concentric Macro Umbrella Concentric Normal
Indoor Micro Micro Indoor Normal Normal
Profile Type Parameters
Cell Type

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 B9
Non Hopping (NH) x
Base Band Hopping (BBH) x
Radio Hopping (RH) * -
Non Hopping / Radio Hopping (NH/RH) x
NH/RH with Pseudo Non Hopping TRX x
BBH with Pseudo Non Hopping TRX x

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

Table 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 12.
Nb of required TRXs
Nb of required cells
Max. Capacity of
the given BTS

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

Figure 12: 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 13.
Erlang B
Required
SDCCH Traffic
GoS:
% SDCCH blocking
Nb of required
SDCCH sub-
channels /
timeslots
INPUT OUTPUT METHOD

Figure 13: SDCCH dimensioning process

INPUT
The required SDCCH traffic is computed as below formula.
%) , cong _ SDCCH (% Min
traffic _ SDCCH _ Measured
traffic _ SDCCH _ quired Re
30 1
=

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

Where:
3600
400
_ _
MC
traffic SDCCH Measured =
% 100
148 04
04
_ %
+
=
MC MC
MC
cong SDCCH

The other input is Grade of Service (GoS), which is defined by the required SDCCH
congestion rate (p
SDCCH
).
Normally GoS should be given or agreed by the Mobile Operator.
The typical value for the required SDCCH congestion rate is 0.5%.

METHOD
Concerning only CS traffic, the statistical law Erlang B is used during the dimensioning
process to determine the necessary resources versus the traffic and the target GoS.


As SDCCH is associated to CS traffic only, Erlang B can be applied to calculate the
required number of SDCCH sub-channels according to required SDCCH traffic and the
target congestion rate.

OUTPUT
Number of required SDCCH sub-channels
= Erlang B (Required_SDCCH_traffic, p
SDCCH
)
Then,
Number of required SDCCH Timeslots
Nb of required SDCCH sub-channels / 8; for non- BCCH combined cell
(Nb of required SDCCH sub-channels 4) / 8; for BCCH combined cell

Assessment:
When % SDCCH congestion (of any cell) > p
SDCCH
, the SDCCH re-dimensioning is
needed.

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

Gathered Counters: TCH

MC380a 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+
P91d+P91e+P91f+
P505
GTRDTERQN Number of DL TBF establishment requests per cell.
P62a+P62b+P62c-
P438c + P507
GTRUTERQN Number of UL TBF establishment requests per cell.
P38e GARPDCUDBUT Cumulative time during which the slave PDCHs are
established and carry at least one DL TBF (established in
P38f GNPACUUBUT Cumulative time during which the slave PDCHs are
established and carry at least one UL TBF (established in
P20x
(x = ad)
GQRPDDRxN
(x = 1,.. ,4)
In acknowledged mode, number of DL RLC data blocks
(except RLC blocks containing LLC Dummy UI Commands
only) on PDTCH encoded in (M)CS-x (i.e. CS-1 (P20a)
CS-4 (P20d)) retransmitted due to unacknowledgement of the
MS.
P20f+P20g+P20h+
P20i+P20j+...+P20n
(x = fn)
GQRPDDRMN
(the indicator
gives the result
directly in bytes)
In acknowledged mode, number of DL RLC data blocks
encoded in all MCS-x and retransmitted due to
unacknowledgement of the MS. RLC blocks containing LLC
dummy UI commands are not counted.
P21x
(x = ad)
GQRPDURxN
(x = 1,.. ,4)
In acknowledged mode, number of UL RLC data blocks on
PDTCH encoded in (M)CS-x (i.e CS-1 (P21a) CS-4
(P21d)) retransmitted due to unacknowledgement of the MFS.
P21f+P21g+P21h+
P21i+P21j++P21n
(x = fn)
GQRPDURMN
(the indicator
gives the result
directly in bytes)
In acknowledged mode, number of UL RLC data blocks
encoded in all MCSx and retransmitted due to
unacknowledgement of the MFS.
P55x
(x = a,.. ,m)
GTRPDDCxN
(x = 1,.. ,4)
GTRPDDMyN
(y = 1,.. ,9)
Number of useful DL RLC blocks sent in RLC acknowledged
mode on PDTCH encoded in (M) CS-x i.e. CS-1 (P55a)
CS-4 (P55d) and MCS-1 (P55e) MCS-9 (P55m).
P57x
(x = a,.. ,m)
GTRPDUCxN
(x = 1,.. ,4)
GTRPDUMyN
(y = 1,.. ,9)
Number of useful UL RLC blocks received in RLC
acknowledged mode on PDTCH encoded in (M) CS-x i.e. CS-
1 (P57a) CS-4 (P57d) and MCS-1 (P57e) MCS-9
(P57m).
Table 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.
Kaufmann-
Robert
Algorithm
CS service
input data
PS service
input data
Total
required TS
for TCH and
PDCH
INPUT OUTPUT METHOD

Figure 14: TCH/PDCH dimensioning process

INPUT
(1) CS service input data:
CS Traffic Intensity in Erlang:
The CS traffic intensity is calculated separately between Full Rate (FR) and Half
Rate (HR) Traffic.
The calculation will take into account the real measured traffic and additional margin
from congestion rate.
The way to calculate the congestion rate for FR and HR is presented below:
Per) Real_Cong_ _ CS %, min( Per _ Cong _ CS 30 =

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

Request n RTCH_Assig
Cong n RTCH_Assig
ng_Per CS_Real_Co
_
_
=
703 812 MC MC
MC812
+
=

As there is no specific counter to identify the type of congestion (from FR calls or
HR calls), below is the calculation to divide the global congestion rate into FR
congestion rate and HR congestion rate.
Per _ Cong _ CS
b MC a MC
a MC
Per _ Cong _ FR
+
=
380 380
380

Per _ Cong _ CS
b MC a MC
b MC
Per _ Cong _ HR
+
=
380 380
380


Then,
Full Rate CS traffic Intensity is:
) Per _ Cong _ FR (
a MC
Per _ Cong _ FR
Traffic _ Successful _ FR
cell
FR

=
=
1 3600
380
1

Half Rate CS traffic Intensity is:
) Per _ Cong _ HR (
b MC
Per _ Cong _ HR
Traffic _ Successful _ HR
cell
HR

=
=
1 3600
380
1

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.

%) , cong _ radio _ TBF (% Min
traffic _ PS _ Measured
traffic _ PS _ quired Re
30 1
=


Where:
3600
451b P
traffic _ PS _ DL _ Measured =

3600
451a P
traffic _ PS _ UL _ Measured =

%
P f P e P d P c P b P a P
P
cong _ radio _ TBF _ DL % 100
505 91 91 91 91 91 91
14
+ + + + + +
=

%
P c P c P b P a P
P
cong _ radio _ TBF _ UL % 100
507 438 62 62 62
27
+ + +
=


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

Figure 15: 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:
DL PS
d
_

n_Time_DL Transmisio
Data_DL
=

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

= = =


For UL:
UL PS
d
_

UL _ Time _ n Transmisio
UL _ Data
=

f
x
n
f x
x
m
a x
x x
d
a x
x x
P
Size _ Block _ RLC P Size _ Block _ RLC P Size _ Block _ RLC P
38 1000
21 57 21 8
\
|
+ +
=

= = =

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
MCS-
8
(sent of
2
blocks)
2
*
68
MCS-
9
(sent of
2
blocks)
2
*
74

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.

BSC
BTS

Abis

Abis

Abis

BTS

BTS

Up to 15 BTSs
per
1 Abis Chain

Figure 16: 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
BTS

Abis

Abis
Abis

Abis

BSC

Only 1 BTS
per
1 Abis Star

Figure 17: 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.

BTS

BTS

BTS

BSC

Abis

Abis

Abis

Abis

Up to 7 BTSs
per
1 Abis Ring

Figure 18: 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

BTS

BTS

BSC

Sec Abis

Pri Abis

Configuration # 1
Pri Abis

BTS

BSC

Sec Abis

Configuration # 2

Figure 19: Secondary Abis Topology

3.2.1.2 Abis Channels
Three types of channels are mapped onto an Abis link:
Qmux Channel only necessary for G1 and G2 BTS
It is used by TSC O&M transmission supervision for non-Evolium BTS (G1 and G2 BTS).
In case of Evolium BTS, the functionality of Qmux can be managed through the OML, via
OML auto-detection.

Ring Control Channel used in Ring topology only
This channel is used by the transmission equipment (BIE), which depends on the TSC. There
are two kinds of bits (R Ring control bits and S Synchronization bits) containing in ring
control channel.

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

Abis
TS 0 TS 1 TS 2 TS 3
TS 4 TS 5 TS 6 TS 7
TRX
TS 0 TS 1 TS 2 TS 3 TS 4 TS 5 TS 6 TS 7

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

Nibble 1 Nibble 2 Nibble 3 Ni bble 4
TS 0
TS 1 TRX 1 - TS 0 TRX 1 - TS 1 TRX 1 - TS 2 TRX 1 - TS 3
TS 3
TS 6
TS 9
TS 12
TS 13
:
:
:
TS 31
:
:
Abis Configuration
OML
TRX 2 - RSL
TRX 3 - RSL
TRX 4 - RSL
TS 0 Usage / Transparency
TRX 1 - RSL
:
13 TS required
in case of
No Multiplexing

Figure 21: 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.


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

Figure 22: 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.

Nibble 1 Nibble 2 Nibble 3 Nibble 4
TS 0
TS 1 TRX1-RSL/OML TRX 1 - TS 1 TRX 1 - TS 2 TRX 1 - TS 3
Abis Configuration

Figure 23: 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.


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

Figure 24: 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
TS 0
TS 3
Abis Configuration
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

TS 0
TS 5
Abis Configuration
TRX 1 - RSL / TRX 2 - RSL / OML


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

TS 0
TS 9
Abis Configuration
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.

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

Figure 28: 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).

Table 15: Abis occupation according to the number of FR TRX
Number of FR
TRE per BTS
(per Abis link)
List of physical MCBs Max SDCCH weight
per MCB
Needed Abis TS
reserved for
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


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
S
C
B
T
S
ET ET ET ET OML RSL BT BT RSL BT BT
RSL BT BT RSL BT BT
ET ET ET ET ET ET ET ET
Primary Abis Link
Secondary Abis Link
BT: Basic Timeslot ET: Extra Timeslots
B
S
C
B
T
S
ET ET ET ET ET ET ET ET OML RSL BT BT OML RSL BT BT RSL BT BT RSL BT BT
RSL BT BT RSL BT BT RSL BT BT RSL BT BT
ET ET ET ET ET ET ET ET ET ET ET ET ET ET ET ET
Primary Abis Link
Secondary Abis Link
BT: Basic Timeslot ET: Extra Timeslots

Figure 29: 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.

Figure 30: BTS with 24 TRX mapped on both Abis links
BSC
BTS 24TRX
Primary link
TRX 1 to 12
+ extra PS TS
Secundary link
TRX 13 to 24
+ extra PS TS
BSC
BTS 24TRX
Primary link
TRX 1 to 12
+ extra PS TS
Secundary link
TRX 13 to 24
+ extra PS TS

A
l
c
a
t
e
l

F
i
l
e

R
e
f
e
r
e
n
c
e

D
a
t
e

E
d
i
t
i
o
n

P
a
g
e

B
1
1
_
B
S
S
_
a
r
c
h
_
s
e
r
v
_
G
u
i
d
e
L
i
n
e
_
E
d
1
.
d
o
c

3
D
F

0
1
9
0
3

8
1
1
0

V
A
Z
Z
A

0
1

J
a
n
u
a
r
y

2
9
,

2
0
1
0

1

5
9

/

1
8
0

T
h
e

p
r
i
m
a
r
y

a
n
d

s
e
c
o
n
d
a
r
y

A
b
i
s

l
i
n
k
s

o
f

a

B
T
S

c
a
n

b
e

o
n

d
i
f
f
e
r
e
n
t

A
b
i
s

T
S
U

o
f

d
i
f
f
e
r
e
n
t

B
S
C

r
a
c
k
s
.

F
i
g
u
r
e

3
1
:

E
x
a
m
p
l
e

o
f

t
o
p
o
l
o
g
y

w
i
t
h

t
w
o

B
T
S

c
h
a
i
n
e
d

T
h
e

o
p
e
r
a
t
o
r

h
a
s

t
o

d
e
f
i
n
e

t
h
e

p
a
r
a
m
e
t
e
r
s

M
A
X
_
D
R
_
T
R
E
_
P
R
I
M
A
R
Y

a
n
d

M
A
X
_
F
R
_
T
R
E
_
P
R
I
M
A
R
Y
,

w
h
i
c
h

g
i
v
e

t
h
e

m
a
x
i
m
u
m

n
u
m
b
e
r

o
f

D
R

(
r
e
s
p
.

F
R
)

T
R
E

t
o

b
e

m
a
p
p
e
d

o
n

f
i
r
s
t

A
b
i
s

w
h
e
n

a

s
e
c
o
n
d

A
b
i
s

i
s

a
t
t
a
c
h
e
d
.

F
i
g
u
r
e

3
2
:

T
w
o

A
b
i
s

l
i
n
k
s

f
i
l
l
i
n
g

e
x
a
m
p
l
e
s
.

B
S
C
B
T
S

2
6
T
R
X
B
T
S

1
1
6
T
R
X
B
T
S

1
1
2

T
R
X
B
T
S

2
6

T
R
X
B
T
S

1
4

T
R
X
B
S
C
B
T
S

2
6
T
R
X
B
T
S

1
1
6
T
R
X
B
T
S

1
1
2

T
R
X
B
T
S

2
6

T
R
X
B
T
S

1
4

T
R
X
M
A
X
_
F
R
_
T
R
E
_
P
R
I
M
A
R
Y

=

1
2
M
a
x
i
m
u
m

f
i
l
l
i
n
g

o
f

f
i
r
s
t
A
b
i
s

l
i
n
k
M
A
X
_
F
R
_
T
R
E
_
P
R
I
M
A
R
Y

=

8
o
r
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
F
i
r
s
t

A
-
b
i
s
S
e
c
o
n
d

A
-
b
i
s
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
F
i
r
s
t

A
-
b
i
s
S
e
c
o
n
d

A
-
b
i
s
F
i
r
s
t

A
-
b
i
s
S
e
c
o
n
d

A
-
b
i
s
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX12
-
E
q
u
a
l
f
i
l
l
i
n
g

o
f

t
h
e

t
w
o
A
b
i
s

l
i
n
k
s
M
A
X
_
F
R
_
T
R
E
_
P
R
I
M
A
R
Y

=

1
2
M
a
x
i
m
u
m

f
i
l
l
i
n
g

o
f

f
i
r
s
t
A
b
i
s

l
i
n
k
M
A
X
_
F
R
_
T
R
E
_
P
R
I
M
A
R
Y

=

8
o
r
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
F
i
r
s
t

A
-
b
i
s
S
e
c
o
n
d

A
-
b
i
s
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
F
i
r
s
t

A
-
b
i
s
S
e
c
o
n
d

A
-
b
i
s
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
F
i
r
s
t

A
-
b
i
s
S
e
c
o
n
d

A
-
b
i
s
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
F
i
r
s
t

A
-
b
i
s
S
e
c
o
n
d

A
-
b
i
s
F
i
r
s
t

A
-
b
i
s
S
e
c
o
n
d

A
-
b
i
s
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX12
-
F
i
r
s
t

A
-
b
i
s
S
e
c
o
n
d

A
-
b
i
s
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
OML+RSL1-4
TRX1
TRX1
TRX2
TRX2
TRX3
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
TRX3
TRX4
TRX4
RSL 5-8
TRX5
TRX5
TRX6
TRX6
TRX7
TRX7
TRX8
TRX8
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX12
-
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX11
TRX12
TRX12
RSL 13-16
TRX13
TRX13
TRX14
TRX14
TRX15
TRX15
TRX16
TRX16
RSL 9-12
TRX9
TRX9
TRX10
TRX10
TRX11
TRX12
-
E
q
u
a
l
f
i
l
l
i
n
g

o
f

t
h
e

t
w
o
A
b
i
s

l
i
n
k
s


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


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

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

Static
number of
needed
Abis TSs
Dynamic
number of
needed Abis
TSs


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 +
P91c + P91d +
P91e + P91f +
P505
P62a + P62b +
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 33.


Erlang C
Required extra
& bonus Abis
nibble Traffic
GoS:

% Quantile of x
delay sec
Nb of required
extra & bonus Abis
Nibbles
INPUT OUTPUT METHOD
Nb of required
extra Abis Nibbles

Figure 33: Abis dimensioning process Method 1

INPUT
The required extra & bonus Abis traffic is computed as below formula.
%) , cong _ Abis _ TBF (% Min
traffic _ Abis _ bonus & extra _ Measured
traffic _ Abis _ bonus & extra _ quired Re
30 1
=

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

Where:
3600
466 P
traffic _ Abis _ bonus & extra _ Measured =
) cong _ Abis _ TBF _ UL ,% cong _ Abis _ TBF _ DL (% Max cong _ Abis _ TBF % =

Where:
%
i P
cong _ Abis _ TBF _ DL % 100
505 91 91 91 91 91 91
105
+ + + + + +
=

%
P c P c P b P a P
j P
cong _ Abis _ TBF _ UL % 100
507 438 62 62 62
105
+ + +
=

The other input is Grade of Service (GoS), which is defined by % quantile of x delay
second (p
ABIS
).
Since the MFS always tries to assign TBFs as soon as the request is received, we
usually dimension for 0sec delay.
Normally GoS should be given or agreed by the 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, p
ABIS
)

However the number of bonus Abis nibbles is fixed according to the total number of
BCCH & SDCCH TS in the BTS; i.e. 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:
% 1 , 0 _ _ _ % > cong Abis TBF

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+
P91d+P91e+P91f+
+ P505
P62a+P62b+P62c-
-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:
Erlang C
Required Data
Traffic on Abis
GoS:
% Quantile of x
delay sec
Nb of required
Abis Nibbles
INPUT
OUTPUT
METHOD
Nb of required
extra Abis Nibbles
Nb of basic &
bonus Abis Nibbles
Erlang C
Required Data
Traffic on Abis
GoS:
% Quantile of x
delay sec
Nb of required
Abis Nibbles
INPUT
OUTPUT
METHOD
Nb of required
extra Abis Nibbles
Nb of basic &
bonus Abis Nibbles

Figure 34: Abis dimensioning process Method 2


INPUT
The required GCH Abis traffic is computed as below formula.
%) , cong _ Abis _ TBF (% Min
traffic _ GCH _ Measured
traffic _ GCH _ quired Re
30 1
=
Where:
3600
100c P
traffic _ GCH _ Measured =
) cong _ Abis _ TBF _ UL ,% cong _ Abis _ TBF _ DL (% Max cong _ Abis _ TBF % =

Where:
%
i P
cong _ Abis _ TBF _ DL % 100
505 91 91 91 91 91 91
105
+ + + + + +
=

%
P c P c P b P a P
j P
cong _ Abis _ TBF _ UL % 100
507 438 62 62 62
105
+ + +
=

The other input is Grade of Service (GoS), which is defined by % quantile of x delay
second (p
ABIS
).
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, p
ABIS
)

However the number of bonus Abis nibbles is fixed according to the total number of
BCCH & SDCCH TS in the BTS; i.e. 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
2 Stages
BIUA
TCUC
TCUC
TCUC
TCUC
TCUC
TCUC
TCUC
TCUC
AS
DTCC
DTCC
DTCC
DTCC
DTCC
DTCC
DTCC
AS
DTCC
CPRC CPRC CPRC CPRC CPRC CPRC CPRC CPRC
AS
6 x
G.703
Abis
I/F
2 x
G.703
Ater
muxed
I/F
Abis TSU Ater TSU
Common Functions TSU
TSCA
TSL
ASMB
ASMB
Q1 bus
Broadcast bus
self-routing, non-blocking
6 E1
2 E1
Group Switch
8 Planes
2 Stages
Group Switch
8 Planes
2 Stages
BIUA
TCUC
TCUC
TCUC
TCUC
TCUC
TCUC
TCUC
TCUC
AS
DTCC
DTCC
DTCC
DTCC
DTCC
DTCC
DTCC
AS
DTCC
CPRC CPRC CPRC CPRC CPRC CPRC CPRC CPRC
AS
6 x
G.703
Abis
I/F
6 x
G.703
Abis
I/F
2 x
G.703
Ater
muxed
I/F
2 x
G.703
Ater
muxed
I/F
Abis TSU Ater TSU
Common Functions TSU
TSCA
TSL
ASMB
ASMB
Q1 bus
Broadcast bus
self-routing, non-blocking
6 E1
2 E1

Figure 35: G2 BSC (A9120 BSC) Architecture

From Figure 35, 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 36: G2 BSC Cabinet layout

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

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:
2
2
allBTS
TS _ ABIS _ EXTRA _ N
TRX _ DR TRX _ FR TRXeq _ FR + + =


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

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

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


SSWW
R
a
d
i
o

N
e
t
w
o
r
k

l
i
n
k
s

External Ethernet Links
LIU Shelf
(21 slots)
E1
CCP
y

TP
r

TP
W

MUX
W

LIU
1

LIU
n

ATCA Shelf (14 slots)
CCP1
OMCPw
OMCP
r

SSW
r

MUX
r

r : Redundancy
W : Working
n and y : Network Element Capacity

Figure 39: 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:

Configuration
Mx BSC
200 TRX
Mx BSC
400 TRX
Mx BSC
600 TRX
Mx BSC
800 TRX
Mx BSC
1000 TRX
Nbr of CCP boards 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 DR TRX FR TRXeq FR TRX _ 2 _ _ + = =

When the Optimized HR connectivity feature is enabled, the TRX calculation become:
TRX DR TRX FR 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

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

Different Behaviors:
TSU is removed
Higher capacity: 1000 TRX / 500 cells
4500erl and SS7 High Speed Link
No need of TCU to support extra Abis TS
Removal of HR connectivity constraints
Abis/Ater fixed mapping to LIU boards
Ater optimization
Same Behaviors
No change in logical model of the BSC
No change in radio configuration
mechanisms
Same set of radio parameters
Same set of PM counters/indicators as
A9120 BSC


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

1000 TRX
200 TRX
LIU 1 LIU 2 LIU 3 LIU 4 LIU 5 LIU 6 LIU 7 LIU 8 LIU 9 LIU 10 LIU 11 LIU 12 LIU 13 LIU 14 LIU 15 LIU 16
1 1 17 33 49 65 81 97 113 129 145 161 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
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
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
16 16 32 48 64 80 96 112 128 144 160 176 55 49 43 32 31
Abis ports (max 176)
Ater CS (max 48): BSC Atermux numbers 1-30,59-76
Ater PS (max 28): BSC Atermux numbers 31-58
2
0
0
4
0
0
4
0
0
2
0
0
200 TRX
400 TRX 400 TRX
1000 TRX
600 TRX 600 TRX
800 TRX 800 TRX
Abi s ports
Ater Ports

Figure 40: 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 1
st
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.


BSC
TC
MSC
server
Ater
ASIGoIP
MSC
server
MSC
server
MSC
server
MGW
A

PSTN

IP

Figure 41: 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.

BSSAP
SCCP
M3UA
SCTP
IP
Ethernet
BSSAP
SCCP
M3UA
SCTP
IP
Ethernet
IP
IP
BSC MSC Server
IP Mode
BSSAP
SCCP
M3UA
SCTP
IP
Ethernet
BSSAP
SCCP
M3UA
SCTP
IP
Ethernet
BSSAP
SCCP
M3UA
SCTP
IP
Ethernet
BSSAP
SCCP
M3UA
SCTP
IP
Ethernet
IP
IP
BSC MSC Server
IP Mode

Figure 42: 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.
Figure 43: 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.
IPSP1
IPSP2
IPSP3
MSC 1
IPSPn
BSC Side
MSC Side
IPSP2
IPSP1
BSC
MSC 2
A single SCTP Association A Set of SCTP Associations
IPSP1
IPSP2
IPSP3
MSC 1
IPSPn
BSC Side
MSC Side
IPSP2
IPSP1
BSC
MSC 2
A single SCTP Association A Set of SCTP Associations


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


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.
Figure 44: 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).
BSC
Router 1
Router 2
SSW1
SSW2
VRRP
Gateway1
Gateway2
MSC
Server
IP Network 1
IP Network 1
IP Network 2
IP Network 2
Gateway1
Gateway2
BSC
Router 1
Router 2
SSW1
SSW2
VRRP
Gateway1
Gateway2
MSC
Server
IP Network 1
IP Network 1
IP Network 2
IP Network 2
Gateway1
Gateway2

Figure 45: Multi-homing on BSC side
IPSP in BSC
SCTP
M3UA
IPSP in MSC
SCTP
M3UA
IP Add1
IP Add2
Router1
Router2
VRRP
IP Network 1
IP Network 1
IP Network 2
IP Network 2
IPSP in BSC
SCTP
M3UA
IPSP in MSC
SCTP
M3UA
IP Add1
IP Add2
Router1
Router2
VRRP
IP Network 1
IP Network 1
IP Network 2
IP Network 2


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.

Figure 46: 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.
MSC 6 MSC 3
MSC 2
MSC 1
Area 1 Area 2 Area 3
MSC 7
Area 4
Area 8
BSC 3 BSC 4 BSC 2
BSC 7 BSC 8
BSC 1
BSC 5 BSC 6
CS pool-
area 2
CS pool-
area 1
MSC 5
MSC 4
MSC 6 MSC 3
MSC 2
MSC 1
MSC 7
Area 4
Area 8
BSC 3 BSC 4 BSC 2
BSC 7 BSC 8
BSC 1
BSC 5 BSC 6
CS pool-
area 2
CS pool-
area 1
MSC 5
MSC 4


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.

Figure 47: 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)

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


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.

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 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 STM-
1 (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.
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.

Figure 48: 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 49: 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 50: 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.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
Configurations
Location
BSC dimensioning process
BSC inputs
Software release
Available configurations
Architecture Constraints
Access transmissionNetwork topology
Core transmission network topology
Definition of sets of BTSs (BSC Area)
satisfying the archi tecture constraints
For each BSC area, choose a BSC
configuration
Check BSC border with RNP team
OK ?
No
Check Abis connectivity
Yes
OK ?
No
Choose an other BSC configuration,
if possibl e ?
No Yes
Check Ater connectivity
OK ?
No
Yes
Yes
Outputs
BSC configurations
BSC Areas
BTS inputs
Configurations
Location
BSC dimensioning process
BSC inputs
Software release
Available configurations
Architecture Constraints
Access transmissionNetwork topology
Core transmission network topology
Definition of sets of BTSs (BSC Area)
satisfying the archi tecture constraints
For each BSC area, choose a BSC
configuration
Check BSC border with RNP team
OK ?
No
Check Abis connectivity
Yes
OK ?
No
Choose an other BSC configuration,
if possibl e ?
No Yes
Check Ater connectivity
OK ?
No
Yes
Yes
Outputs
BSC configurations
BSC Areas

Figure 51: BSC dimensioning process

In Figure 51, 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 2
nd
Abis link) gives
the TRX & Abis load that this BTS will have at BSC level.

Figure 52: 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 53: 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 54: 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 55: 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.


Figure 56: 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 25: 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).

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

Figure 57: LA dimensioning assessment


In Figure 57, 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 58: 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 26: 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
at 60% load
Max assign/s
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 27: 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
* 3600 / 0.240)
GCCIARQO Load on AGCH logical channel(s) in case of fixed AGCH
configuration
(MC8A / N4) / ((N3
N2) * 3600 / 0.240)
GCCPGRQO Load on PCH logical channel(s) in case of fixed AGCH
configuration
Table 28: 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.
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.


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

TC BSC MSC
AterMUX A

Figure 59: 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
TS 1 TCH TCH TCH TCH TS 1 GCH GCH GCH GCH
TS 14 Qmux TCH TCH TCH TS 14 GCH GCH GCH GCH
TS 15 TS 15
TS 16 TS 16
TS 28 TCH TCH TCH TCH TS 28
TS 31 TS 31 GCH GCH GCH GCH
TS 0 Transparency
Alarm octet
SS7 (not used)
GSL
Alarm octet
SS7
X25
TS 0 Transparency

Figure 60: AterMUX interface structure

In Figure 60, 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 60), the following figure presents the
AterMUX CS configurations that depend on the G2 BSC configuration.

X 25 Q m u x Al a rm S S 7 T C H N um b e r
P C M 1 ( x ) x x x 1 1 1
P C M 2 ( x ) x x x 1 1 1
P C M 1 x x 1 1 6
P C M 2 x x 1 1 6
P C M 1 x x 1 1 6
P C M 2 x x 1 1 6
X 25 Q m u x Al a rm S S 7
P C M 1 x x x 1 1 5
P C M 2 x x x 1 1 5
P C M 1 x x 1 1 6
P C M 2 x x 1 1 6
P C M 1 x x 1 1 6
P C M 2 x x 1 1 6
X 25 Q m u x Al a rm S S 7
P C M 1 x x x 1 1 5
P C M 2 x x x 1 1 5
P C M 1 x x 1 1 6
P C M 2 x x 1 1 6
P C M 1 x 1 1 6
P C M 2 x 1 1 6
To t a l T C H 20 7 4
A t e r T S U 9
B S C R a c k 1
B S C R a c k 2
B S C R a c k 3
A t e r T S U 5
A t e r T S U 6
A t e r T S U 7
A t e r T S U 8
A t e r T S U 1
A t e r T S U 2
A t e r T S U 3
A t e r T S U 4

Figure 61: AterMUX CS interface configuration G2 BSC

In Figure 61, 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 29: 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
CH# 1 CH# 2 CH# 3 CH# 4
TS 0
TS 1
TCH TCH TCH TCH
:
:
TS 14 Qmux TCH TCH TCH
TS 15
TS 16
:
:
TS 30
TCH TCH TCH TCH
TS 31
TS : 64 Kbits/sec
Channel or Nibble : 16 Kbits/sec
Alarm octet
SS7
X25
:
:
:
:
A Interface
TS 0
TS 1
TS 2
TS 3
TS 4
TS 5
:
:
:
:
:
:
:
TS 30
TS 31
TS : 64 Kbits/sec
CIC 31
CIC 4
CIC 5
:
:
:
:
:
:
CIC 30
CIC 1
CIC 2
CIC 3
:

Figure 62: 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 30 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 30: Max number of A-interfaces G2 BSC

3.4.2.2 AterMUX PS
Referring to AterMUX PS structure (Figure 60), the following figure presents an example of
AterMUX PS configuration for a GPU.

One GPU
GSL Alarm SS7 GCH Number
PCM 1 x x x 112
PCM 2 (x) x x 112
PCM 3 x x 116
PCM 4 x x 116
PCM 5 x x 116
Total GCH 572

Figure 63: AterMUX PS interface configuration - GPU

Notes:
One GPU can support max. 480 GCH (a GPU has 4 DSPs one of which supports 120
GCH)
One GP can support max. 1560 GCH (a GP has 4 DSPs one of which supports 240 GCH)
5 AterMUX PS are needed to support 480 GCH (9 AterMUX PS are needed to support
1960 GCH)
Note: The max capacity of 5 AterMUX PS is 572 GCH, which is enough to support
480 GCH refer to Figure 60

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

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

Figure 64: Sharing AterMUX links

From Figure 64: - 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

BSC
GPU
(MFS)
TC
SGSN
X
Y
Z


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 32.
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 32: Ratio of Mixing CS and PS Traffic in AterMUX

The Figure 65 presents details of Timeslot sharing between CS (TCH) and PS (GCH):
PS Traffic Ratio / / / / Full
TS
TS TCH TCH TCH TCH GCH
TS TCH TCH TCH GCH GCH
TS
TS
TS TCH TCH GCH GCH GCH
TS TCH GCH GCH GCH GCH
TS GCH GCH GCH GCH GCH
AterMUX CS/PS
TS Transparency
Alarm octet
SS

Figure 65: 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 60.
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 66: 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).

(**) The BHCA corresponds to B10-MR2 capacity. For MR1, the BHCA is limited to 288 000.
Table 33: 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.

HSL HSL 324 000
HSL HSL 259 200 BSC - EV - 800
HSL 194 400
11 16 129 600 BSC - EV - 400
8
11 64 800
Nb of SS7 links
at 60% load
Nb of SS7 links
at 40% load
BHCA (**) BSC type (*)
HSL HSL 324 000
HSL HSL 259 200
HSL 194 400
15 HSL 129 600
64 800
Nb of SS7 links
at 60% load
Nb of SS7 links
at 40% load
BHCA (**) BSC type (*)
BSC_EV_200
BSC_EV_400
BSC_EV_600
BSC_EV_800
BSC_EV_1000
HSL


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 34: 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.
in arg m % traffic _ SCCP _ Measured traffic _ SCCP _ quired Re 15 + =
Where:
= traffic _ SCCP _ Measured

3600
380 380 10 02 01 390 400 ) b MC a MC ( ) MC MC MC ( * ) MC / MC (
TS TS TS

+ + + +
=

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


Time (H)
8H00 9H00 10H00 11H00 12H00 13H00 14H00
RNO traffic measurements
Exact Busy hour
Peak traffic

Figure 67: 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 (p
SS7
). Normally GoS should be given or agreed by the Mobile Operator.

GoS: Required blocking probability p
SS7

The typical maximum blocking rate at AterMUX interface is 0.1%.
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

N
u
m
b
e
r

o
f

o
c
c
u
p
i
e
d

C
h
a
n
n
e
l
s


For 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, p
SS7
)

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

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

For example:
If the total number of 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
Name
Long Name Definition
N3.1 NB_N7_SIF_SIO_SENT Number of octets of Signalling Information
(SIF) and Service Information Octets (SIO)
transmitted on the N7 SL.
N3.3 NB_N7_MSU_SENT Number of Message Signalling Units (MSU)
transmitted on the N7 SL.
N3.4 NB_N7_SIF_SIO_REC Number of octets of Signalling Information
Field (SIF) and Service Information Octets
(SIO) received on the N7 SL.
N3.5 NB_N7_MSU_REC Number of Message Signalling Units (MSU)
received on the N7 SL.
N3.10 NB_N7_MSU_DISC_DUE_CONG Number Message Signalling Units (MSU)
discarded due to a message buffer overflow
caused by an extended period of Signalling Link
congestion.

Traffic evaluation in UL
Counter values must be aggregated for the link set.

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.
112500
3 3 6 1 3
7
. N * . N
traffic _ SS _ Measured
+
=
%
. N . N
. N
cong _ SS % 100
10 3 3 3
10 3
7
+
=
%) ; cong _ SS (% Min
traffic _ SS _ quired Re
30 7 1
7
7
=
( ) ;0.1% S7_traffic Required_S angB InverseErl s connection SCCP quired Re of Nb =
103 / s connection SCCP quired Re of Nb TS SS7 quired Re of Nb =


Traffic evaluation in DL
Counter values must be aggregated for the link set.

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.

112500
5 3 6 4 3
7
. N * . N
+
=
in arg m % traffic _ SS _ Measured traffic _ SS _ quired Re 15 7 7 + =
( ) ;0.1% S7_traffic Required_S angB InverseErl s connection SCCP quired Re of Nb =
103 / s connection SCCP quired Re of Nb TS SS7 quired Re of Nb =


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
Name
Indicator Name Definition
MC1109 GIPABSMCSSBYN
Number of bytes of the SS7 flow sent by a BSC to the
MSC (MSC-CS) when A signaling over IP is used.
MC1110 GIPABSMCSSPKN
Number of SCTP packets sent by a BSC to a given
MSC for the SS7 flow when A signaling over IP is used. It
corresponds to is the number of SCTP segments sent,
counted by the SCTP stack.
MC1111 GIPABSMCSSPKRN
Number of SCTP packets resent by a BSC to a given
MSC for the SS7 flow, when A signaling over IP is used.
MC1112 GIPABSMCSSBYMN
Maximum number of bytes of the SS7 flow sent by a
BSC to a given MSC in one minute during the granularity
period of monitoring, when A signaling over IP is used.
Table 36: 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).


Figure 68: IP packet structure for Asig over IP

Headers
Ethernet 38 bytes
IP 20 bytes
SCTP 12 bytes
Chunk 16 bytes
M3UA 36 bytes
Table 37: 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).
IP header
SCTP
header
Chunk
header
Chunk payload
Chunk
header
Chunk payload Ethernet header
M3UA header SCCP msg
38 bytes
Average size: 604 bytes
20 bytes
12 bytes
36 bytes
16 bytes
IP header
SCTP
header
Chunk
header
Chunk payload
Chunk
header
Chunk payload Ethernet header
M3UA header SCCP msg
38 bytes
Average size: 604 bytes
20 bytes
12 bytes
36 bytes
16 bytes


Figure 69: 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
Name
Indicator Name Definition
MC1114 GIPABSSUDM0N
Number of connectionless Unit Data messages class 0
sent to the MSC, when A signaling over IP is used.
MC1115 GIPABSRUDM0N
Number of connectionless Unit Data messages class 0
received from the MSC, when A signaling over IP is used.
Table 38: Counter list for Asig over IP traffic in UL and DL

Nb of packets resent
Nb of packets sent
Total Nb of packets
sent and resent
(Sent+Resent)
/Sent packets
Resent
Ratio (RR)
Overhead bytes
per packet
Total Overhead Bytes (OB)
Max Nb of payload
bytes in one min
Nb of payload bytes in one hour (NB)
Engineering Margin (EM)
(Max bytesX60)
/(Nb bytes per hour)
EM*RR*(NB+OB)*8/1000/3600
Required
Bandwidth
(RBW)
Calculation
RBW
[kbps]
Nb of packets resent
Nb of packets sent
Total Nb of packets
sent and resent
(Sent+Resent)
/Sent packets
Resent
Ratio (RR)
Overhead bytes
per packet
Total Overhead Bytes (OB)
Max Nb of payload
bytes in one min
Nb of payload bytes in one hour (NB)
Engineering Margin (EM)
(Max bytesX60)
/(Nb bytes per hour)
EM*RR*(NB+OB)*8/1000/3600
Required
Bandwidth
(RBW)
Calculation
RBW
[kbps]


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.


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

Figure 70: AterMUX-CS dimensioning process

From Figure 70, 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.


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

Where:

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

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

Required blocking probability p
AterMuxCS

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

METHOD
Concerning only CS traffic, the statistical law Erlang B is used during the
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, p
AterMuxCS
)

Number of required AterMUX CS Links (2):
This can be derived from comparing the total number of AterMUX CS channels
(TCH) with AterMUX CS link capacity, which is shown in Figure 61.

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 61, 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 62, 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 71 the process for AterMux PS dimensioning that must be applied at BSC level, is
presented:


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

(user traffic)

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

(user traffic)

(user traffic)

(GSL traffic)

(GSL traffic)

Figure 71: 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 72:
GPU/GP dimensioning
Assessment
# Needed
GCH
max
# AterMux PS per GPU (esti mated at
BSC level)
# Needed
GSL links
# GSL links
Aterlink
GCH_Capacity
# AterMux PS

(user traffic)

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

(user traffic)

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

(user traffic)

(user traffic)

(GSL traffic)

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

(user traffic)

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

(user traffic)

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

Figure 72: 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)

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

Figure 73: 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 40: 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

28800
) 42 , 41 (
_ _
P P Max
traffic GSL Measured = Erlang

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
% 100
) 42 . 0 ( _
_ _
_
=
=
Erlangs Capacity GSL
traffic GSL Measured
load GSL

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.

BSC
GPU
K_GSL
GSL messages
buffer
GSL_round_trip_delay
A message is kept in the buffer
during GSL_round_trip_delay
BSC
GPU
K_GSL
GSL messages
buffer
BSC
GPU
K_GSL
GSL messages
buffer

Figure 74: GSL messages processing

The first method is based on the number of TBF establishment requests.
Gathered Counters:

P62a + P62b +
P62c - P438c +
P507
GTRUTERQN Number of UL TBF establishment -requests per cell.
P91a + P91b +
P91c + P91d +
P91e + P91f +
P505
GTRDTERQN Number of DL TBF establishment -requests
P30a + P30b +
P30c + P508
GTRUTESUN Number of UL TBF establishment -successes (seized by the
mobile).
P90a + P90b +
P90c + P90d +
P90e + P90f +
P506
GTRDTESUN Number of DL TBF establishment -successes (seized by the
mobile)
P62b GTRUTRV5N Number of UL TBF establishment requests per cell (seized by
the mobile) when MS is in packet transfer mode DL.
P160 GQRDTES1N Number of DL TBF establishment requests requesting 1 slot,
which are satisfied.
P383a GQAGALCTT Time during which AterMux interface (GICs) for this GPU is
congested (at least one PDCH group impacted).
P391a GTRPCHPAGPN Number of PS paging requests processed by the GPU.
P391b GTRPCHCIGPN Number of CS paging requests processed by the GPU.


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
Cells GPUs mapping
(if method applied to 1 GPU/GP)
GSL traffic condition
Calculation [2]
# GSL links
#GSL msg/sec due to
RAE4 traffic calculation [3]
#GSL msgs/sec due
to PS traffic calculation [3]
(*) QoS evaluation to be done
by QoS expert
75% x GSL_Link_Max_Capacity [4]
+
QoS acceptable ?* [1]
(i.e. UL TBF estab success rate >80%)
Yes
Retrieve data on a different
Period or on an updated
configuration with better QoS*
Select hours with acceptable QoS *
(i.e. for 90% of cells)
Compare PS traffic in the selected hours
with traffic observed on a similar BSC
(reference BSC)
Estimate PS traffic at busy hours on the basis
of the reference BSC (through a simple proportion
based on the respective number of cells)
No
OR
START
PS
Traffic data
CHECK
Calculation
If the method is applied at BSC level, the
total capacity (for all GPU/GP) must be kept
Retrieve indicators and
Cells GPUs mapping
(if method applied to 1 GPU/GP)
GSL traffic condition
Calculation [2]
# GSL links
#GSL msg/sec due to
RAE4 traffic calculation [3]
#GSL msgs/sec due
to PS traffic calculation [3]
(*) QoS evaluation to be done
by QoS expert
75% x GSL_Link_Max_Capacity [4]
+
QoS acceptable ?* [1]
(i.e. UL TBF estab success rate >80%)
Yes
Retrieve data on a different
Period or on an updated
configuration with better QoS*
Select hours with acceptable QoS *
(i.e. for 90% of cells)
Compare PS traffic in the selected hours
with traffic observed on a similar BSC
(reference BSC)
Estimate PS traffic at busy hours on the basis
of the reference BSC (through a simple proportion
based on the respective number of cells)
No
OR
START
PS
Traffic data
CHECK
Calculation
If the method is applied at BSC level, the
total capacity (for all GPU/GP) must be kept

Figure 75: 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.


3.5 2.5 Low
5 3.5 High Available
GCH
Low High
PS traffic
(TBF req)
Nb of Msg on GSL
3.5 2.5 Low
5 3.5 High Available
GCH
Low High
PS traffic
(TBF req)
Nb of Msg on GSL
Ater congestion observed
#TBF request/sec < 20

Figure 76: 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

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

++
Nb GSL messages/s


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.
% 100
_ _ _
sec _ _ _
_ =
Capacity Max Link GSL
per messages GSL Nb
load GSL
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)
% 100
_ _ _
sec _ _ _
_ =
Capacity Max Link GSL
per messages GSL Nb
load GSL

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 63 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 61, 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 32

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.

BSC
ASMC ASMC
ASMC
or
MT120
MT120
+FAN
ATBX
DT16 DT16
TSC
Ater-mux interfaces
MT120
+FAN
Ater interfaces
A interfaces
Local
Qmux
TC bus
MSC

Figure 77: 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
TRCU ATBX DT16
MT120

Data in this table, based on [1] and [9]
Table 43: 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
Physical Logical
Min Max
G2 TC 2 AterMux 6 AterMux 1 AterMux 1 AterMux
SU 2 6 1 1
ASMC 2 6 1 1
TRCU SM 4:1 4 24 4 4
MT120 - 4 1 1
TC
Configuration
Min

Table 44: 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).

MFS

TC G2.5

MSC

Ater mux interface

(4:1 Mapping scheme)

A interface

M T120

MT120

BSC

Figure 78: 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.

Extension / Reduction step
Physical Logical
Min Max
MT120 2 48 1 1
G2.5 TC
Configuration per Rack
(AterMux)
Min

Table 45: G2.5 TC configuration

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

Configuration 1 subrack 2 subracks 3 subracks 4 subracks
Max MT120 modules 12 24 36 48

Table 46: G2.5 TC capacity

Rules:
Each BSC must be connected to at least two MT120 boards for redundancy purposes,
refer to Table 45.
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
# AterMUX CS links from BSCn
Used TC type
(G2 TC or G2.5 TC)
Total
links
Needed TC
Configuration
(Nb of boards)
:
:
:
:
:
:
+

Figure 79: TC dimensioning process

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

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

As 36 MT120 boards are needed, this required one G2.5 TC with 3 subracks
refer to Table 46.
Total = 36 MT 120 boards


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:

MSC
TC
BSC
BTS
BTS
SGSN
MFS

BTS
Ater
A
STM-1
STM-1
n*E1
TDM
subrack
SDH

Figure 80: 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 1
st
MFS generation or A9135 MFS
MFS Evolution or A9130 MFS

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

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

The A9135 MFS comprises 3 sub-systems:
Control Sub-System (CSS): built from 2 DECAlpha AS800 or COMPAQ DS10 servers,
one of which is active and one of which is standby, referred to as the Control Station
Telecom Sub-System (TSS): a set of GPU and JBETI boards
Hub subsystem: 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 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.

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

Figure 82: 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

Table 47: The 1
st
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.


SSW
w

(duplicated)
R
a
d
i
o

N
e
t
w
o
r
k

l
i
n
k
s

LIU Shelf
(21 slots)
E1
Mux
1

LIU
1

LIU
n

OMCP
w

OMCP
r

SSW
r

Mux
r

GP1
GP
n

SSW
w

(duplicated)
R
a
d
i
o

N
e
t
w
o
r
k

l
i
n
k
s

LIU Shelf
(21 slots)
E1
Mux
1

LIU
1

LIU
n

OMCP
w

OMCP
r

SSW
r

Mux
r

GP1
GP
n
GP1
GP
n

Figure 83: 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 SA12 SA12 RS16 RS16

Figure 84: MxMFS rack configurations

Currently allowed configurations for MFS Evolution can be summarized as follow:


Stand-Alone Rack-shared
1 shelf:
up to 9 GP
2
nd
shelf extension possible:
up to 21 GP in total
Up to 12 E1per GP in B10MR2ed4*:
In centralized synchronization mode: up to 9GP
In autonomous synchronization mode: up to 21GP
MFS with 1 shelf,
up to 8 GP,
up to 16 E1per GP:
In centralized synchronization mode: up to 14 E1/GP
In autonomous synchronization mode: up to 16 E1/GP
Collocated BSC & MFS in one rack:
Either with O&M over IP
Or with O&M over Ater
(*) Before B10MR2ed4, there is a maximum allowed number of 10 E1 per GP board when MFS is in centralized mode.

Additional capacity rules:
One A9130 MFS is able to manage up to 4000 cells (up to 2000 cells for legacy MFS)
One A9130 MFS is able to control up to 21 BSCs
Per GPU Per GP Per MFS
(with DS10)
Per MFS
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
Points
16 16 480 336

Figure 85: 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 1
st
MFS generation
The main change/unchanged between those two MFS generation are below:
4000 cells 3000 cells MxMFS
2000 cells 2000 cells Legacy MFS
Max Nb of cells in B10 Max Nb of cells in B9 MFS
4000 cells 3000 cells MxMFS
2000 cells 2000 cells Legacy MFS
Max Nb of cells in B10 Max Nb of cells in B9 MFS

500 cells 264 cells GP
264 cells 264 cells GPU
Max Nb of cells in B10 Max Nb of cells in B9 GPU/GP
500 cells 264 cells GP
264 cells 264 cells GPU
Max Nb of cells in B10 Max Nb of cells in B9 GPU/GP

Table 48: 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)
448 (GPUAC)
960 DSP limitation
Max PDCH configured 480 1 920 DSP limitation
Max PDCH allocated
(0% EDGE penetration rate)
196 868 DSP limitation
Max PDCH allocated
(80% EDGE penetration rate)
124 348 (13 E1 links)
476 (16 E1 links)
DSP limitation
Max GCH 480 1 560 (GboFR)
1 920 (GboIP)
DSP limitation
Max MS contexts 1000 4 000 PPC limitation
Max UL + DL TBF
establishment requests and
reallocation requests in one hour
300 000 1 200 000 DSP limitation
Max nb of simultaneously
established UL TBF+DL TBF
(with max 10 TBF/PDCH in DL
and 6 TBF/PDCH in UL)
960 3 840 DSP limitation
Max Gb Throughput for GPRS
(UL+DL)
992 kbps (GboFR)
829 kbps (GboIP)
4527 kbps (GboFR)
4350 kbps (GboIP)
PPC limitation
Max Gb Throughput for EDGE
(UL+DL)
1161 kbps (GboFR)
971 kbps (GboIP)
5285 kbps (GboFR)
5037 kbps (GboIP)
PPC limitation
Table 49: 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-
P438c+P507] -
(P105d + P105f +
P27 + P105h + P105j
+ P105l + P204 +
P512 - P66 - P28 -
[P30a + P30b +
P30c+P508])
MC927e
GQRUTEBPN Number of UL TBF estab -failures due to BSS problem
per cell.
Reference: number of UL TBF estab -requests
P62a + P62b + P62c
- P438c + P507
GTRUTERQN Number of UL TBF establishment requests.
P105e GQRDTECCN Number of DL establishment failures due to CPU
processing power limitations of the GPU.


P105f GQRUTECCN Number of UL establishment failures due to CPU
processing power limitations of the GPU.
P203 GQRDTELDN Number of DL TBF establishment failures due to DSPs
that are in CPU load / overload state.
Note: This counter applies to GPRS and EGPRS MS.
P204 GQRUTELDN Number of UL TBF establishment failures due to DSPs
that are in CPU load / overload state.
Note: This counter applies to GPRS and EGPRS MS.
P91a + P91b + P91c
+ P91d + P91e +
P91f + P505
GTRDTERQN Number of DL TBF establishment requests.
P383b GTRGPUCOT_MA Time (cumulated over a granularity period) during which
the GPU remains in "high" Ater usage.
Table 50: 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.

Number
of GPU
GPU_GCH_Capacity
GPU_for_MS_context_handling (=0/1)
Needed
GCHs +
GPU_for_Power_Limitation (=0/1)
+
Number
of GPU
GPU_GCH_Capacity
GPU_for_MS_context_handling (=0/1)
Needed
GCHs +
GPU_for_Power_Limitation (=0/1)
+

Figure 86: GP(U) dimensioning process


ERLANG C
Counters
Required_GCH_Traffic
Needed
GCHs
With
quantile=99,9%
Feature
activation
Traffic
evolution
Stable
Network
estimation
ERLANG C
Counters
Needed
GCHs
With
quantile=99,9%
Feature
activation
Traffic
evolution
Stable
Network
estimation
Feature
activation
Traffic
evolution
Stable
Network
estimation

Figure 87 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 (p
GP(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, p
GP(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:
%) 30 , _ (% 1
_ _
_ _ Re
cong GCH Min
traffic GCH Measured
traffic GCH quired
=

Where:
3600
100
_ _
c P
traffic GCH Measured = , and
{ }
{ } overload CPU load DSP Cong DSP Cong Ater Max
Limitation GPU Congestion Ater Max cong GCH
_ ,% _ ,% _ ,% _ %
_ , _ _ % = =

Where:
% 100
3600
383
_ _ % =
a P
cong Ater GCH
% 100
3600
384
_ _ % =
P
cong DSP GCH
% 100
3600
) 202 , 201 (
_ % x
P P Max
load DSP =
% 100
3600
402
_ % x
P
overload CPU =

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.

y = 5,3905x + 21,057
0
112
224
336
448
0 10 20 30 40 50 60 70 80
Measured PDCH traffic
Measured
GCH traffic
Resources
saturation
y = 5,3905x + 21,057
0
112
224
336
448
0 10 20 30 40 50 60 70 80
Measured
GCH traffic
Resources
saturation

Figure 88: 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 89.


y = 5,3905x + 21,057
0
112
224
336
448
560
0 10 20 30 40 50 60 70 80
Measured
GCH traffic
Following the
4th link adding
ERLANG C
Needed_GCH
y = 5,3905x + 21,057
0
112
224
336
448
560
0 10 20 30 40 50 60 70 80
Measured
GCH traffic
Following the
4th link adding
ERLANG C
Needed_GCH

Figure 89: 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)
Case 16 E1
links per GP
GP (A9130)
Case 12 E1
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)
Case 16 E1
links per GP
GP (A9130)
Case 12 E1
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 51: 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.

1,60 1,64 CS-4
1,22 1,25 CS-3
1,00 1,00 CS-2
0,73 0,73 CS-1
DL UL CS
1,60 1,64 CS-4
1,22 1,25 CS-3
1,00 1,00 CS-2
0,73 0,73 CS-1
DL UL CS
4,39 4,49 MCS-9
4,00 4,14 MCS-8
3,39 3,49 MCS-7
2,31 2,36 MCS-6
1,81 1,86 MCS-5
1,47 1,50 MCS-4
1,28 1,33 MCS-3
1,00 1,00 MCS-2
0,86 0,89 MCS-1
DL UL MCS
Number of required GCHs
4,39 4,49 MCS-9
4,00 4,14 MCS-8
3,39 3,49 MCS-7
2,31 2,36 MCS-6
1,81 1,86 MCS-5
1,47 1,50 MCS-4
1,28 1,33 MCS-3
1,00 1,00 MCS-2
0,86 0,89 MCS-1
DL UL MCS
Number of required GCHs

Table 52: 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:
{ }

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

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:


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

:

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

:

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

:

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

:

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

:

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

:

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

:

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

:

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

:

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

:

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

Figure 90: Evolution of MS context number on GP(U)

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

Retrieve indicators
for 5 working days
P392b
BSC
=1000 and P392a
BSC
>900
during at least 12% of
the observed period
NO
YES
Observed QoS acceptable
for the customer?
YES
NO
GPU_for_MS_ context _ handling =0
Retrieve indicators
for 5 working days
_
_

Figure 91 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 92) or DSP CPU level (see
Figure 93).

Figure 92: GPU_for_Power_Limitation due to PMU CPU load

In Figure 92,

)
P438c - P62c P62b P62a
f P
;
P91f P91e P91d P91c P91b P91a
e P
( Max rate _ fail _ cong _ cpu
+ + + + + + +
=
105 105

Figure 93: GPU_for_Power_Limitation due to DSP CPU load
NO
YES
YES
NO
GPU_for_Power_Limitation=0
Retrieve indicators
for 5 working days
P402/3600>3% OR P76a>70%
the observed period
(P402/3600>3% OR P76a>70%) and cpu_cong_fail_rate>1% OR GPU reboots
observed the CPU loaded hours
NO
YES
YES
NO
Retrieve indicators
for 5 working days
Max(P201,P202)/3600>3%
the observed period
Max(P201,P202)/3600>3% and dsp_load_fail_rate>1% OR GPU reboots
observed during the CPU loaded hours


In Figure 93,
)
P438c - P62c P62b P62a
P
;
P91f P91e P91d P91c P91b P91a
P
( Max rate _ fail _ load _ dsp
+ + + + + + +
=
204 203

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 -
P438c + P507 + P91a
+ P91b + P91c +
P91d + P91e + P91f
+ P505
GTRATERQN GPRS_TBF_request Number of UL and DL TBF
establishment request per
cell.
P403a + P403b +
P403c + P403d +
P404a + P404b +
P404c + P404d
GTRRRRQN GPRS_TBF_realloc_request Total number of UL+DL
TBF reallocation requests.
Table 53: 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
P35 GTRDTBM_MA GPRS_DL_TBF_estab_max
Maximum number of DL TBF
simultaneously established over
the Granularity period.
P36 GTRDTBA_MA GPRS_DL_TBF_estab_avg_max
Average number of DL TBF
P39 GTRUTBM_MA GPRS_UL_TBF_estab_max
Maximum number of UL TBF
P40 GTRUTBA_MA GPRS_UL_TBF_estab_avg_max
Average number of UL TBF
Table 54: 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 49.


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.

N S l a y e r
B S S G P l a y e r
G P U m
B S S G P l a y e r
G P U n
L a y e r 1
B V C = o n e
p e r c e l l
B C V
B C V
B C V
N S E
L o a d s h a r i n g
B V C I
N S C s u b
l a y e r
S N S s u b
l a y e r
N S E = o n e p e r G P U

N S - V C I o r R e m o t e I P E n d p o i n t
I P n e t w o r k
N S - V L F R b e a r e r
I P E n d p o i n t
F R n e t w o r k
S G S N
B C V
B C V
B C V
P V C
N S - V C
N S - V L
R e m o t e I P e n d p o i n t
O R

Figure 94: 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:
System Name OMC-R modifiable Instance Unit Min Max
Default
Value
Definition
Gb_Transport_Mode Changeable BSS None 0 1 0
Mode of the transport for Gb
interface: FR or IP.
0: FR
1: IP
Gb_Transport_Mode_per
_NSE
Changeable NSE None 0 1 0
Mode of the transport for Gb
interface (per NSE).
0: FR
1: IP
Gb_Configuration_type Changeable NSE None 0 1 0
Configuration type used with
Gb over IP.
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

1) Through a FR Network MFS
2) Direct MFS - SGSN connections MFS
3) Through NSS transmission network MFS MSC/VLR MSC/VLR
SGSN
Frame Relay
Netwok
Gb
Gb
Gb
Gb Gb

Figure 95: 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.
Packet Packet Switched Switched Network Network
PDH/SDH network PDH/SDH network
BSC
MSC
SGSN
MFS
TC
E1
GE
GE
Ater(circuit)
Ater(packet)
A
Gb
Full Full redundant redundant architecture, architecture,
Seen Seen as single as single gateway gateway IP@ IP@

Figure 96: 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 55: Counter list - Gb dimensioning

Measured Object: Gb (PVC for GboFR, IP Endpoint for GboIP)

Methodology:
The process of Gb dimensioning is presented below.

Figure 97: Gb dimensioning process

Erlang C
Required Gb
Traffic
GoS:
% Quantile of x
delay sec
Nb of required TS per
GboFR link

Minimum Throughput
for GboIP link

INPUT OUTPUT METHOD


INPUT
The required Gb traffic is computed as below formula.

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

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 (p
Gb
).
Since the MFS always tries to assign TBFs as soon as the request is received, we
usually dimension for 0sec delay.
Normally GoS should be given or agreed by the Mobile Operator.
At high network element level Gb interface, the recommended value is 99.9% quantile
of 0 delay sec.

METHOD
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
3.7.2.1 Gb over Frame Relay
For GboFR interface, the measured traffic corresponds to P45 and P46 counters.

28800
46 45 ) P , P ( Max
traffic _ GboFR _ Measured =

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; p
Gb
)
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:
( ) ( ) 6 300 70 300 + + = / * traffic _ GboFR _ Measured traffic _ GboIP _ Measured
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.

Figure 98: 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.

BSS1
City center
BSS2
BSS5
BSS4
BSS3
BSS6
SGSN Pool
SGSN2 SGSN3 SGSN1


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.

Figure 99: LA, RA and SGSN pool

S
G
S
N

P
o
o
l
P
o
o
l

A
r
e
a
IP NETWORK IP NETWORK IP NETWORK IP NETWORK
SGSN
BSC1
MFS
BSC2
RA1
RA2
RA3
LAC1
LAC2
SGSN
S
G
S
N

P
o
o
l
S
G
S
N

P
o
o
l
P
o
o
l

A
r
e
a
P
o
o
l

A
r
e
a
IP NETWORK IP NETWORK IP NETWORK IP NETWORK IP NETWORK IP NETWORK IP NETWORK IP NETWORK
SGSN SGSN
BSC1 BSC1
MFS MFS
BSC2 BSC2
RA1 RA1
RA2 RA2
RA3 RA3
LAC1
LAC2
SGSN SGSN SGSN


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.

Figure 100: 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).

Figure 101: 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,

Valid P-TMSI 31 30 29 -24 NRI 18-0
29 -24 NRI 18-0 31

30 Local TLLI
2 bits set to 1
NRI
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
NRI
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31


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.

END OF DOCUMENT

B11 BSS Arch Serv GuideLine Ed1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

B11 BSS Arch Serv GuideLine Ed1

Uploaded by

Copyright:

Available Formats

Alcatel File Reference Date Edition Page

B11_BSS_arch_serv_GuideLine_Ed1.doc 3DF 01903 8110 VAZZA 01 January 29, 2010 1 1 / 180

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

# AterMux PS per GPU

You might also like