BSS Architecture Service Guideline B10

Originator(s) A. Rezzoug E.
Marza
Vlizy
Site
Mobile Radio Division
B10: BSS Architecture Service Guideline
Domain Product Division Rubric Type
: Network Architecture : GSM B10 : Methods : GSM/GPRS/EDGE : Guidelines
Distribution codes Internal: Pre-distribution: F. Colin NE Velizy
NE Timisora E. Marza
T. Plantier
Cristian I. Inta
NE Portugal Tiago Dias
Pedro Henriques
NE Egypt
Wessam Yanni
M. Talayssat
LM. Palumbo
Joo Frade
Abstract: The aim of this document is to describe BSS architecture configuration rules & dimensioning processes in Alcatel release B10. It is recommended to be the guideline for RNE & TPM people who are involve in BSS architecture aspect. Key words: BTS, BSC, TC, MFS/GP(U), Abis, AterMUX, A, and Gb; B10 release Appraisal and approval authorities GSM TIS
DD-MM-YY: Signature: DD-MM-YY: Signature:
Network Engineering
DD-MM-YY:
Florent Colin
Signature:
All Alcatel system details given in this document are for your comfort only. The system information may not reflect the latest status of the equipment used in your project. Please consult in addition to this document the latest product descriptions!
B10_BSS_arch_serv_GuideLine_Ed1.doc
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
1 / 154
Page
Table of contents
1 2 INTRODUCTION..................................................................................... 14 OVERVIEW OF BSS ARCHITECTURE SERVICES ........................ 15
2.1 2.1.1 2.1.2 WHAT IS THE BSS ARCHITECTURE ? .......................................................................... 15 BSS Network Elements ..................................................................................... 15 BSS Interfaces .................................................................................................. 16
2.1.2.1 Um (air or radio) interface ........................................................................... 16 2.1.2.2 Abis interface ............................................................................................... 16 2.1.2.3 AterMUX interface ...................................................................................... 16 2.1.2.4 A interface .................................................................................................... 17
2.2
2.1.2.5 Gb interface .................................................................................................. 17 BSS ARCHITECTURE SERVICES ................................................................................... 18 Scope ................................................................................................................ 18 Goal.................................................................................................................. 18 Category ........................................................................................................... 18 Process ............................................................................................................. 19
2.2.1 2.2.2 2.2.3 2.2.4
2.2.4.1 Process for Network Architecture SETUP and EVOLUTION.................... 19 2.2.4.2 Process for Network Architecture ASSESSMENT ..................................... 22 BSS ARCHITECTURE IMPACT IN B10 ....................................................................... 25
2.3
2.3.1 2.3.2 2.3.3
Multiple CCCH ................................................................................................ 25 Gb over IP ........................................................................................................ 26 Capacity Improvements.................................................................................... 27
2.3.3.1 Optimized HR connectivity.......................................................................... 28 2.3.3.2 HSL functionality......................................................................................... 28
DETAILED BSS ARCHITECTURE PROCESS .................................. 29

3.1 3.1.1 BTS ............................................................................................................................ 29 BTS Configuration............................................................................................ 29
3.1.1.1 Cell Configuration........................................................................................ 33 3.1.1.2 SDCCH Configuration ................................................................................. 34 Determination of BTS configuration ................................................................ 36 Cell dimensioning............................................................................................. 36
3.1.2 3.1.3
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
2 / 154
Page
3.1.3.1 SDCCH Dimensioning................................................................................. 37 3.2
3.1.3.2 TCH/PDCH Dimensioning .......................................................................... 39 ABIS INTERFACE ......................................................................................................... 45 Abis Configuration ........................................................................................... 45
3.2.1
3.2.1.1 Abis Network Topology............................................................................... 45
3.2.1.2 Abis Channels .............................................................................................. 47
3.2.1.3 Abis Link Capacity....................................................................................... 49

3.2.1.4.1 3.2.1.4.2 No Multiplexing......................................................................................................................... 50
3.2.1.4 Signalling Sub-Multiplexing Schemes......................................................... 49

16K Static Multiplexing............................................................................................................. 50
3.2.1.4.3
3.2.2
3.2.1.5 Secondary Abis Link.................................................................................... 55 3.2.2.1 Case #1: B9 with No GPRS/EDGE Abis Dimensioning ........................................................................................... 57 B10 with EDGE............................. 59
3.2.1.4.4
64K Statistical Multiplexing ...................................................................................................... 51 16K Statistical Multiplexing ...................................................................................................... 54
3.3
3.2.2.2 Case #2: B10 with EDGE............................................................................. 59 BSC ............................................................................................................................ 66 G2 BSC Configuration ..................................................................................... 66
3.3.1
3.3.1.1 BSC Capacity ............................................................................................... 67 3.3.1.2 Abis TSU...................................................................................................... 68 3.3.1.3 Ater TSU ...................................................................................................... 70
3.3.2
3.3.2.1 BSC Capacity ............................................................................................... 72 3.3.2.2 Delta BSC Evolution versus G2 BSC .......................................................... 73 3.3.2.3 CCP board .................................................................................................... 73 3.3.2.4 LIU shelf ...................................................................................................... 75
BSC Evolution Configuration........................................................................... 70
3.3.3
3.3.2.5 SS7 transport ................................................................................................ 75
3.3.3.1 Design BSC area .......................................................................................... 77 LA Dimensioning.............................................................................................. 81
BSC Dimensioning ........................................................................................... 76
3.3.5 3.3.6 3.3.7
3.3.4
3.3.3.2 Parenting Abis ports of the BSC .................................................................. 79 RA Dimensioning.............................................................................................. 85 CCCH dimensioning ........................................................................................ 88
Summary of LA/RA dimensioning process ....................................................... 87
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
3 / 154
Page
3.4
3.4.1
ATERMUX AND A INTERFACES .................................................................................. 89
3.4.1.1 AterMUX interface ...................................................................................... 89
General............................................................................................................. 89
3.4.1.2 A interface .................................................................................................... 89 3.4.2
3.4.1.3 AterMUX interface versus A interface ........................................................ 89 3.4.2.1 AterMUX CS and A interfaces .................................................................... 91 3.4.2.2 AterMUX PS ................................................................................................ 93 3.4.2.3 AterMUX CS/PS .......................................................................................... 94 AterMUX configuration.................................................................................... 90
3.4.3
3.4.3.1 LSL and HSL modes .................................................................................... 96
SS7 Signalling mode......................................................................................... 96
3.4.4
3.4.3.2 SS7 Dimensioning........................................................................................ 97 3.4.4.1 AterMUX CS.............................................................................................. 101 3.4.4.2 AterMUX PS .............................................................................................. 105
3.4.4.2.1 3.4.4.2.2 Process description .................................................................................................................. 105 GSL Dimensioning .................................................................................................................. 108 3.4.4.1.1 A Dimensioning....................................................................................................................... 104
AterMUX Dimensioning................................................................................. 101
3.5
3.5.2 3.6 3.5.3
3.5.1
TC............................................................................................................................. 116
3.4.4.3 AterMUX CS/PS ........................................................................................ 115
3.4.4.2.3
GCH/AterMUX-PS Dimensioning .......................................................................................... 113
G2.5 TC Configuration .................................................................................. 117 TC Dimensioning............................................................................................ 118
G2 TC Configuration ..................................................................................... 117
3.6.1
MFS.......................................................................................................................... 120 3.6.1.1 GPRS Processing Unit (GPU).................................................................... 121
The 1st MFS generation (A9135 MFS) ........................................................... 120
3.6.1.2 Multiple GPU per BSS............................................................................... 121 3.6.2
3.6.1.3 Capacity...................................................................................................... 122
3.6.2.1 Configurations and Capacity...................................................................... 123 3.6.2.2 Delta MFS Evolution versus the 1st MFS generation................................. 124 GP(U) Dimensioning and AterMux PS dimensioning (user traffic) .............. 125
MFS Evolution (A9130 MFS)......................................................................... 122
3.6.3
3.6.3.1 Required GCH traffic estimation in case of stable network....................... 128
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
4 / 154
Page
3.6.3.2 Required GCH estimation in anticipation of feature activation................. 130 3.6.3.3 GP(U) GCH capacity estimation................................................................ 132 3.7 3.6.3.4 GP(U) limitations ....................................................................................... 134 GB INTERFACE .......................................................................................................... 138 Gb configuration ............................................................................................ 140 Gb Dimensioning............................................................................................ 142
3.6.3.2.1 Increase_factor estimation ....................................................................................................... 131
3.7.2
3.7.1
ANNEX 1: BSS ARCHITECTURE IMPACT FROM B9 .................. 145
5 ANNEX 2: PRE-REQUISITES FOR MXBSC CAPACITY IMPROVEMENTS ......................................................................................... 150

5.2 5.3 5.1 CIC CODE LIMITATION .............................................................................................. 150 HSL LIMITATION ...................................................................................................... 150 GBOIP LIMITATION ................................................................................................... 151
6 7
ANNEX 3: ABIS, ATER & GB OVER SATELLITE ......................... 153 ANNEX 4: TRANSPORT MIGRATION ............................................. 154
7.1 7.2 OPTIMISATION OVER E1 ............................................................................................ 154 IP BACKHAULING ...................................................................................................... 154
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
5 / 154
Page
INDEX OF FIGURES Figure 1: BSS Architecture ...................................................................................................... 15 Figure 2: TRX configuration on Um interface......................................................................... 16 Figure 3: Abis configuration .................................................................................................... 16 Figure 4: AterMUX configuration Dedicated AterMUX for CS traffic ............................... 17 Figure 5: A-interface configuration.......................................................................................... 17 Figure 6: BSS Architecture Services........................................................................................ 18 Figure 7: Network Architecture Setup and Evolution process................................................. 19 Figure 8: BSC/LAC/RAC (re) design - example ..................................................................... 20 Figure 9: Abis TSU port (re) design......................................................................................... 22 Figure 10: Network architecture assessment process............................................................... 23 Figure 11: mCCCH mapping on Beacon TRX ........................................................................ 25 Figure 12: MFS capacity .......................................................................................................... 27 Figure 13: B10 BSC capacity improvements........................................................................... 27 Figure 14: BSC - MSC connectivity with HSL mode.............................................................. 28 Figure 15: BTS generation/type supported in B10................................................................ 29 Figure 16: Determination of BTS configuration ...................................................................... 36 Figure 17: SDCCH dimensioning process ............................................................................... 37 Figure 18: TCH/PDCH dimensioning process......................................................................... 40 Figure 19: TCH/PDCH dimensioning assessment ................................................................... 44 Figure 20: Abis Chain (Multi-drop) Topology ........................................................................ 45 Figure 21: Abis Star Topology................................................................................................. 46
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
6 / 154
Page
Figure 22: Abis Ring (Closed loop) Topology......................................................................... 46 Figure 23: Secondary Abis Topology ...................................................................................... 47 Figure 24: TRX - Abis mapping .............................................................................................. 47 Figure 25: Example of Abis TS usage for 1 BTS/4 TRX No Multiplexing.......................... 50 Figure 26: Example of Abis TS usage for 1 BTS/4 TRX 16K Static Multiplexing ............. 51 Figure 27: 64K Statistical Multiplexing MCB 64/1 mapping............................................... 51 Figure 28: 64K Statistical Multiplexing MCB 64/2 mapping............................................... 52 Figure 29: 64K Statistical Multiplexing MCB 64/4 mapping............................................... 52 Figure 30: Example of Abis TS usage for 1 BTS/4 TRX 64K Statistical Multiplexing....... 53 Figure 31: 16K Statistical Multiplexing MCB 16/1 mapping............................................... 54 Figure 32: Example of Abis TS usage for 1 BTS/4 TRX 16K Statistical Multiplexing....... 55 Figure 33: Abis TS configuration on primary and secondary links ......................................... 55 Figure 34: BTS with 24 TRX mapped on both Abis links....................................................... 56 Figure 35: Example of topology with two BTS chained.......................................................... 56 Figure 36: Two Abis links filling examples............................................................................. 57 Figure 37: Abis dimensioning process Method 1.................................................................. 60 Figure 38: Abis dimensioning process Method 2.................................................................. 63 Figure 39: Abis method algorithm ........................................................................................... 64 Figure 40: Abis dimensioning process ..................................................................................... 65 Figure 41: G2 BSC (A9120 BSC) Architecture....................................................................... 66 Figure 42: G2 BSC Cabinet layout .......................................................................................... 67 Figure 43: Abis TSU G2 BSC............................................................................................... 68
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
7 / 154
Page
Figure 44: Ater TSU G2 BSC ............................................................................................... 70 Figure 45: BSC Evolution (A9130 BSC) HW Architecture .................................................... 71 Figure 46: Abis and Ater allocation on LIU boards / BSC capacity........................................ 75 Figure 47: BSC dimensioning process ..................................................................................... 76 Figure 48: BTS position & configuration design BSC area step 1 ....................................... 77 Figure 49: Transmission planning & BSC position design BSC area step 2 ........................ 78 Figure 50: BSC area definition design BSC area step 3 ....................................................... 78 Figure 51: Transmission load checking ................................................................................... 79 Figure 52: BTS / Abis parenting on BSC done by AMT.NET ............................................. 80 Figure 53: LA dimensioning assessment ................................................................................. 84 Figure 54: Subdivision of a LA in GPRS routing areas (RA).................................................. 85 Figure 55: AterMUX and A relationship ................................................................................. 89 Figure 56: AterMUX interface structure.................................................................................. 90 Figure 57: AterMUX CS interface configuration G2 BSC ................................................... 91 Figure 58: Channel mapping between AterMUX CS and A.................................................... 92 Figure 59: AterMUX PS interface configuration - GPU.......................................................... 93 Figure 60: Sharing AterMUX links.......................................................................................... 94 Figure 61: AterMUX CS/PS Timeslot configuration............................................................... 95 Figure 62: SS7 message length (in bytes) according to GSM event........................................ 97 Figure 63: Difference between Exact busy hour, NPO busy hour and Peak traffic................. 99 Figure 64: AterMUX-CS dimensioning process.................................................................... 102 Figure 65 AterMux-PS dimensioning process at BSC level .................................................. 106
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
8 / 154
Page
Figure 66 AterMux-PS dimensioning process at GP(U) level............................................... 106 Figure 67 GSL usage factor ................................................................................................... 112 Figure 68: TC G2 architecture with mixed configuration...................................................... 116 Figure 69: TC dimensioning process ..................................................................................... 118 Figure 70: The 1st MFS generation (A9135 MFS) Architecture............................................ 120 Figure 71: Multiple GPU per BSS ......................................................................................... 121 Figure 72: MFS capacity ........................................................................................................ 124 Figure 73: GP(U) dimensioning process................................................................................ 126 Figure 74 AterMux PS dimensioning process based on user traffic ...................................... 127 Figure 75: Example of GCH/PDCH traffic relationship in case of AterMux PS underdimensioning .......................................................................................................... 129 Figure 76 GCH vs. PDCH traffic relationship: example ....................................................... 130 Figure 77 GCH vs. PDCH evolution in case of EDGE/CS3/CS4 activation......................... 131 Figure 78 GPU_for_Power_Limitation due to PMU CPU load ............................................ 136 Figure 79 GPU_for_Power_Limitation due to DSP CPU load.............................................. 137 Figure 80: Gb interface configuration (from 3BK 09559 LAAA EBZZA) ........................... 139 Figure 81: Gb interface connections ...................................................................................... 140 Figure 82: GboIP End-to-End architecture ......................................................................... 141 Figure 83: Gb dimensioning process...................................................................................... 142 Figure 84: EGCH link in B8 vs. M-EGCH link in B9 ........................................................... 145 Figure 85: Wasted Abis nibbles case in B8............................................................................ 147 Figure 86: Enhance transmission resource management ....................................................... 147 Figure 87: AterMUX TS reserved by GP(U) Ater TS margin............................................... 148
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
9 / 154
Page
Figure 88: Better transmission resource usage with DL retransmission in the BTS.............. 149
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
10 / 154
Page
INDEX OF TABLES Table 1: BSC-MFS/GP(U)-TC (re) design .............................................................................. 21 Table 2: Configuration G1 BTS MKII with DRFU .............................................................. 29 Table 3: Configuration G2 BTS ............................................................................................ 30 Table 4: Configuration Evolium BTS ................................................................................... 30 Table 5: Configuration Evolium Evolution........................................................................... 31 Table 6: BTS HW Capability in B10 ....................................................................................... 32 Table 7: TRX HW capability since G3 BTS generation.......................................................... 33 Table 8: Cell Types .................................................................................................................. 33 Table 9: Frequency Hopping supported in B10 ....................................................................... 34 Table 10: Recommended SDCCH configuration for a standard cell only FR TRXs........... 35 Table 11: Counter list - SDCCH dimensioning ....................................................................... 37 Table 12: Counter list - TCH dimensioning............................................................................. 39 Table 13: Counter list - PDCH dimensioning .......................................................................... 40 Table 14: RLC data block size for each (M) CS ...................................................................... 43 Table 15: Abis Channel Types ................................................................................................. 48 Table 16: Number of TS available in one Abis link ................................................................ 49 Table 17: Counter list - Abis dimensioning Method 1............................................................. 59 Table 18: Counter list - Abis dimensioning Method 2.1.......................................................... 63 Table 19: G2 BSC Capacity ..................................................................................................... 67 Table 20: TSL/TCU Mapping .................................................................................................. 69 Table 21: BSC Evolution Capacity .......................................................................................... 72
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
11 / 154
Page
Table 22: Counter list LA dimensioning............................................................................... 81 Table 23: Counter list RA dimensioning............................................................................... 85 Table 24: Max number of AterMUX CS interfaces G2 BSC ............................................... 92 Table 25: Max number of A-interfaces G2 BSC................................................................... 93 Table 26: Max number of AterMUX PS G2 BSC ................................................................. 94 Table 27: Ratio of Mixing CS and PS Traffic in AterMUX .................................................... 95 Table 28: Counter list AterMUX-CS dimensioning ............................................................. 98 Table 29: Counter list AterMUX-CS dimensioning ........................................................... 101 Table 30: Counter list GSL dimensioning........................................................................... 109 Table 31: Counter list GSL dimensioning........................................................................... 110 Table 32: G2 TC/ G2.5 TC capabilities ................................................................................. 116 Table 33: G2 TC configuration .............................................................................................. 117 Table 34: G2.5 TC configuration ........................................................................................... 117 Table 35: G2.5 TC capacity ................................................................................................... 118 Table 36: The 1st MFS generation (A9135 MFS) Capacity................................................... 122 Table 37: Counter list - GP(U) dimensioning ........................................................................ 126 Table 38: GCH resource increase factor ................................................................................ 132 Table 39: Counter list - Gb dimensioning.............................................................................. 142 Table 40: GCH consumption B8 vs. B9.............................................................................. 146
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
12 / 154
Page
History: Edition Draft Ed1P2 Ed1 Date 05/11/07 05/02/08 Originator Abdesselem Rezzoug Abdesselem Rezzoug Comments Creation from B9 version
10/01/08
Eugen Marza
Correction from NE comments
Additonnal corrections and updates
References:
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19]
3BK 17430 5000 PGZZA 3BK 10204 0608 DTZZA 3BK 17025 0062 DSZZA 3BK 17025 0061 DSZZA 3BK 11210 0157 DSZZA 3BK 11210 0328 DSZZA 3DC 21083 0001 TQZZA 3DF 01903 2810 PGZZA
BSS Configuration Rules release B10
Enhanced Transmission Resource Management Release B9
Introduction of DRFU on G2 BTS Principle of Method G3 BTS Architecture and Principles BTS G4 Architecture and Principles SFD: Dynamic SDCCH allocation
Introduction of DRFU on G1 MK II BTS Principle of Method
3BK 10204 0511 DTZZA 3DC 20003 0019 UZZZA 3DC 21150 0323 TQZZA 3DC 21016 0005 TQZZA 3DF 00995 0005 UAZZA 3BK 11203 0100 DSZZA 3BK 11206 0476 DSZZA 3DF 019032911 VAZZA
EVOLIUM A9100 Base Station Product description
BSS B8 Dimensioning Rules
Dimensioning Rules for CS and PS traffic with BSS Software Release B10
GPRS/E-GPRS Radio Network Planning Aspects GPRS management functional specification B9: BSS Architecture Service Guideline Gb over IP in Release B10 Multiple CCCH BSC abbreviations Release B9
A9135 MFS Product Description
GSM/GPRS/EDGE Radio Network Design Process for ALCATEL BSS Release B10
3BK 09722 JAAA DSZZA
GPRS resource usage and dimensioning B8 release
3DC 21144 0120 TQZZA
3BK 10204 0028 DTZZA Abbreviations: Refer to [16].
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
13 / 154
Page
1 INTRODUCTION
The aim of this document is to describe BSS architecture configuration rules & dimensioning processes in Alcatel release B10. It is recommended to be the guideline for RNE (Radio Network Engineer) & TPM (Technical Project Manager) people who are involve in BSS architecture aspect. This document is organised as below: Part I: Overview of BSS Architecture Service The purpose of this part is to give the reader the overview of the architecture service for the BSS network which consists of: -
The global picture of BSS network architecture together with the short definition for each network elements and interfaces Describing overall processes for each BSS architecture service The short presentation about B9/B10 impacts to BSS architecture. The main impacts are linked to the new features introduced in B10 release.
Part II: Detailed BSS Architecture Processes
This part describes in the details of the main network configuration rules in release B10 and the dimensioning processes, which are related to counter analysis. It covers the following BSS network elements and interfaces: BTS BSC MFS/GP(U) TC Abis interface AterMUX interface A interface Gb interface
The dimensioning method due to migration from B8 to B9 release is not detailed in this document (please refer to [17] document).
Nevertheless, a short presentation about BSS architecture impacts with the introduction of new B9 features is presented in Annex.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
14 / 154
Page
2 Overview of BSS Architecture Services

This section gives an overview of the BSS architecture. It describes briefly all the components in the BSS together with their key functions and the global BSS architecture processes.
2.1 What is the BSS Architecture ?

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

Figure 1: BSS Architecture
As presented in shown in Figure 1, the BSS consists of several network elements and interfaces.
2.1.1 BSS Network Elements

BTS (Base Transceiver Station): providing radio links between the Mobile Stations and the BSC. BSC (Base Station Controller): controlling several BTSs. TC (TransCoder): providing speech conversion between the 16kbps channel (from/to BSC side) and the 64kbps channel (from/to the MSC1 ). MFS (Multi-BSS Fast packet Server): To be able to support PS traffic, a MFS is introduced in the BSS in order to manage data packets.
MSC (Mobile Switching Center) is a main network element of the NSS having connection to the BSS.
Alcatel File Reference Date Edition
1
3DF 01903 8010 VAZZA 01
March 04, 2008
15 / 154
Page
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.
TS TS : : TS TS TS TS TS TS 0 1 A bis CH# 1 CH# 2 CH# 3 T S 0 T ra ns p a re n cy
F ree : : E xtra TS E xtra TS T C H / GC H T C H / GC H TCH / GCH TCH / GCH TCH / GCH TCH / GCH TCH / GCH TCH / GCH R SL O ML
CH# 4
26 27 28 29 30 31
Mapping to 1 TRX of Um Interface
T S : 6 4 K bits /s e c C h a nn e l o r N ibb le : 1 6 K bits /s e c
Figure 3: Abis configuration
2.1.2.3 AterMUX interface

The AterMUX interfaces provide connections between:
-
BSC and TC BSC and MFS MFS and TC (in case of AterMUX transporting mixed Traffic CS & PS)
Reference Date Edition
1
Alcatel File
3DF 01903 8010 VAZZA 01
March 04, 2008
16 / 154
Page
In general, the AterMUX is also a 2Mbps PCM link (64kbps * 32 TS). However, differently from Abis, every nibbles on AterMUX are already defined to be TCH or GCH or signalling channels.
TS TS TS : : TS TS TS TS TS : : TS TS 0 1 2 AterMUX CS CH# 1 CH# 2 CH# 3 CH# 4 Frame Synchronization
TCH TCH TCH TCH TCH TCH TCH TCH : : TCH
14 15 16 17 18
Qmux
TCH TCH
TCH TCH
Alarm octet SS7

: :
TCH
TCH
TCH TCH
TCH TCH
30 31
TCH
TCH
Figure 4: AterMUX configuration Dedicated AterMUX for CS traffic
TS : 64 Kbits/sec Channel or Nibble : 16 Kbits/sec
X25
TCH
TCH
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).
TS TS TS TS 0 1 2 3 : : : : A Interface Frame Synchronization
CIC 1 CIC 2 CIC 3 : : : : CIC 30 CIC 31
TS 30 TS 31
TS : 64 Kbits/sec
Figure 5: A-interface configuration
2.1.2.5 Gb interface
The Gb interface connects the MFS with the SGSN2 (Serving GPRS Support Node), which is a main network element of the GSS having connection to the BSS.
When using Frame Relay stack, the Gb interface (GboFR) is supported by 2Mbps PCM links (64kpbs * 32 TS). When using UDP/IP/Ethernet stack, the Gb interface (GboIP) is supported by a Gigabit Ethernet link (GE).
2
SGSN (Serving GPRS Support Node) is a main network element of the GSS having connection to the BSS.
1
3DF 01903 8010 VAZZA 01
March 04, 2008
17 / 154
Page
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.
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.2 Goal
2.2.3 Category
According to different network states, the BSS architecture services can be classified into: 1) Network Architecture SETUP This service is providing the BSS architecture design for a new network.
2) Network Architecture ASSESSMENT For an existing network, it is important to perform this service to check periodically the network performance from architecture point of view. 3) Network Architecture EVOLUTION The BSS architecture should be re-designed in case of some network evolutions e.g. network extension (to be adapted to a forecasted traffic scenario) and new network feature activation (GPRS CS 3-4 or EDGE, for instance).
BSS Architecture Services
Network Architecture Setup
Network State
Initial
Network Architecture Assessment
Steady
Network Architecture Evolution
Developing
Figure 6: BSS Architecture Services
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
18 / 154
Page
2.2.4 Process
Two different processes are defined, one supporting the services network architecture setup and evolution, and the other one supporting the service network architecture assessment.
2.2.4.1 Process for Network Architecture SETUP and EVOLUTION

It is considered the same process can be applied for these two BSS architecture services; see the process diagram below.
START
(1) Gathering Data
NW Configuration Rules
(2) Design/Re-design
(2a) BSC/LAC/RAC Areas (2b) BSC/MFS (GPU/GP)/TC Configuration (2c) Number of interfaces: Abis, AterMUX, A and Gb (2d) Parenting Abis TSU/LIU ports of the BSC
(3) Operational Implementation, according to (2) FINISH

Figure 7: Network Architecture Setup and Evolution process
Step (1) Gathering data
The first step is to gather the architecture data from the network:
NE specifications i.e. type of BTS, BSC, MFS, TC. NE locations.
Defined configuration e.g. TRX configuration (BCCH combined or non-combined and number of SDCCH).
1
Current BSS network topology (architecture) available in case of network evolution.
3DF 01903 8010 VAZZA 01
March 04, 2008
19 / 154
Page
Step (2) Design / Re-design
This step will be considered as design in case of network setup but re-design in case of network evolution of which current design already existed.
The architecture (re)-design should be performed for each BSS network elements and interfaces, based on the data from Step 1 and also strictly respected to Network configuration rules for more details, please refer to [1].
(2a) BSC/LAC/RAC Areas
Since the data about TRX configuration and BTS location are known (from step 1), the (re)-design will start with defining the BSC/LAC/RAC area based on geographical point of view. The following is the example of BSC/LAC/RAC (re) design.
Figure 8: BSC/LAC/RAC (re) design - example
Fore more details, please refer to section 3.3.3.1 for BSC area design, section 3.3.4 for LAC design and section 3.3.5 for RAC design.
(2b) BSC/MFS (GP(U))/TC Configuration 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.
1
BSC:
3DF 01903 8010 VAZZA 01
March 04, 2008
20 / 154
Page
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
MFS (GP(U)) and TC:
Type Configuration
A9120 BSC, A9130 BSC - Conf 1, 2, 3, 4, 5 or 6 for A9120 BSC
A9135 MFS, A9130 MFS
- Stand Alone / Rack shared configuration with 200, 400, 600, 800 or 1000 TRX for A9130 BSC
Nb of GP(U) boards - Nb of TC boards dedicated to each dedicated to each BSC BSC - Nb of TC racks Nb of MFS racks
G2 TC, G2.5 TC (A9125 Compact TC)
Table 1: BSC-MFS/GP(U)-TC (re) design
Fore more details, please refer to section 3.3 for BSC configuration, section 3.5 for TC configuration, and section 3.6 for MFS configuration.
(2c) Number of interfaces; Abis, AterMUX, A and Gb
In general, we have to design the number of needed interface links. However, additional characteristic has to be designed for some interfaces:
After the configuration of all BSS network elements is defined, it comes to the step to design interfaces connecting them.
Abis: Type of signalling sub-multiplexing schemes, BTS in multidrop and number of extra Abis TS (in case of supporting GPRS CS3-4 and EDGE). AterMUX: Type of Traffic i.e. CS, PS or Mixed CS/PS. Gb: Number of 64kbps TSs for GboFR Minimum throughput of IP network (QoS, Delay) for GboIP
Fore more details, please refer to section 3.2 for Abis, section 3.4 for AterMUX & Ainterface and section 3.7 for Gb.
(2d) Parenting Abis TSU ports of the BSC
The final (re)-design is to assign the dedicated Abis TSU (at BSC side) for each Abis link (from BTS side). To perform parenting Abis TSU, please refer to the Abis TSU configuration rules in section 3.3.1.2.
1
3DF 01903 8010 VAZZA 01
March 04, 2008
21 / 154
Page
However, Network Engineering service has developed the architecture management tool, so called AMT.NET, which assists the radio network engineer to design efficiently the parenting Abis TSU in the convenient way. For more details, please refer to website http://pcs.tm.alcatel.ro/Amt. Below is an example of parenting Abis TSU, which is done by AMT.NET tool.
Figure 9: Abis TSU port (re) design
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.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
22 / 154
Page
The process diagram for network assessment is presented below.

START
(1) Gathering Data
NW Configuration Rules
(2) Applying Dimensioning Methods
Counters/Indicators vs. Configuration analysis for each Network Elements and Interfaces Recommendation/Threshold
(3) Assessment
-
Identify bottle necks Identify need of new resources / new configuration
FINISH
Figure 10: Network architecture assessment process
Step (1) Gathering data
The first step is to gather 2 different kinds of data from the network:
Traffic data: relevant counters or indicators retrieved from OMC-R or NPO machines.
BSS network topology data: the existing number, location and configuration of each BSS network elements and interfaces.
It is the process to analyse the traffic counters (or indicators) by applying the defined dimensioning methods and the Network configuration rules.
Step (2) Applying dimensioning methods
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
23 / 154
Page
The traffic analysis should be done individually at different level of NE and interfaces. BSS network elements:
CELL dimensioning (for more details, please refer to section 3.1.3) BSC dimensioning (for more details, please refer to section 3.3.3) TC dimensioning (for more details, please refer to section 3.5.3)
GP(U) dimensioning (for more details, please refer to section 3.6.3)
BSS interfaces:
Abis dimensioning (for more details, please refer to section 3.2.2) A dimensioning (for more details, please refer to section 3.4.4.1) Gb dimensioning (for more details, please refer to section 3.7.2)
AterMUX dimensioning (for more details, please refer to section 3.4.4)
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.
Step (3) Assessment
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
24 / 154
Page
2.3 BSS Architecture Impact in B10

In B10 release, there are several improvements in term of architecture point of view. These improvements are related to the introduction of new features as follows:
Multiple CCCH (B10MR1) Gb over IP (B10MR2) Capacity Improvements (4000Erl in B10MR1, 4500Erl in B10MR2) Optimized HR connectivity (B10MR1) HSL functionality (B10MR1)
2.3.1 Multiple CCCH
The multiple CCCH (mCCCH) feature is required to support the increasing signalling load on the common channels, due to either big CS cells with high peak throughput or to PS traffic when no master PDCH is configured. The 3GPP defines up to 4 Time Slots (TS0, TS2, TS4 & TS6) to carry the CCCH information on the beacon TRX of one cell.
From B10 MR1, the optional mCCCH feature allows to define a second CCCH TS: only TS0 and TS2 on beacon TRX will be used, while TS0 is foreseen for single CCCH timeslot.
Beacon TRX 0 1 2 3 4 5 6 7
Figure 11: mCCCH mapping on Beacon TRX
The main benefits permit:

To handle high capacity cells To handle cells with heavy traffic models (high BHCA, high HR usage) To define larger Location Areas Avoid master Channel (PBCCH/PCCCH) deployment
Anyway, it is also possible to use mCCCH feature when master PDCH is implemented. The mCCCH feature that can be implemented in both G2 BSC and Mx BSC, and has impacts for:
Telecom: main impact on Paging and Access Control entity O&M: impacts include the introduction of a new channel type CCH (BCCH + CCCH) and change of the TRX mapping algorithm
In addition, TRE hardware limitation shall follow the below rules:

G3: maximum number of CCCH + SDCCH TS = 3 G4: maximum number of CCCH + SDCCH TS = 4 G5 (TWIN TRA): maximum number of CCCH + SDCCH TS = 4
1
Alcatel File
3DF 01903 8010 VAZZA 01
March 04, 2008
25 / 154
Page
The mCCCH feature has impacts in the Paging and Access Control entity.
On radio interface, the capacity of the PCH paging channel will allow about 63 paging/s. The following set of rules applying for the configuration of mCCCH:
1) 2) 3) 4) 5) 6) 7)
CCH should be configured on TS2 of BCCH TRX When BCCH is combined with SDCCH, CCH cannot be configured. In BCCH TRX, when CCH is configured, only one Static SDCCH is allowed In the cell with both BCC and CCH, the max number of SDCCH TS is extended to 22. CBC and CBH are forbidden Dynamic SDCCH is forbidden on BCCH TRX Limitation rule on G2 TCU shall respect CCCH (BCCH) TS +SDCCH TS <= 4 TS (one CCCH TS equal to one SDCCH TS in terms of signalling load) 8) The new channel type for CCCH is taken as bonus nibble in Abis interface.
Note: CCH is the new channel type for BCCH + CCCH; BCC is the channel type for FCCH + SCH + BCCH + CCCH.
2.3.2 Gb over IP
From B10 MR2 only, the Gb interface can be transported either on Frame Relay (GboFR) or IP (GboIP) protocol stacks.
The feature Gb interface over IP (GboIP) is transported over a standardized protocol stack according to 3GPP R6 (UDP/IP/Ethernet). This feature is optional and allows the backhauling of Gb traffic over IP networks (IPv4); the traffic flows from/to all GP(U) between MFS and SGSN can be aggregate in one single flow. So the dimensioning of the IP network i.e. handling GboIP traffic shall be done MFS per MFS instead of a per GP(U) dimensioning basis. Indeed the IP bandwidth is dynamically shared between all GP(U) within one MFS, and there is no service differentiation between handled traffic flows (signalling, streaming, best effort).
However, the IP network between SGSN and MFS shall provide enough bandwidth to pass all aggregated flows. The feature option, which has to be chosen per a BSC basis, is available and supported on:

A9130 MFS without any hardware impact (IP Ready) A9135 MFS equipped with DS10 systems and the replacement of the switch rack by 2 new GE switches (OS-LS-6224). There is no GboIP support for A9135 MFS with AS800 systems
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
26 / 154
Page
As shown in the following figure, the mix of GboIP and GboFR is allowed within one MFS.
M FS
BSS1 BSS2 BSS3 BSS4
BSSG P NS FR BSSG P NS FR BSSG P NS U D P/IP BSSG P NS U D P/IP
Frame Relay N etwork
SG SN
IP Network
Gb
Figure 12: MFS capacity
2.3.3 Capacity Improvements
With B10 release, the capacity of the Mx BSC has been improved in terms of TRX, cells and traffic mix load. The Mx BSC will support up to 1000TRX with 5 CPP boards in one ATCA shelf, the number of supported cells has been improved to reach the target of 500 cells.
Regardless these improvements, Mx BSC will allow a capacity of up to 324000 BHCA, about 575000 paging/hour and up to 4000Erl (B10 MR1). In B10 MR1, the committed capacity will allow up to 4000Erl with TPGSMv1 board, and up to 4500Erl in B10 MR2 with both the former TPGSMv1 and the new introduced TPGSMv3 board.
Five Mx BSC configuration types are defined based on the number of active CCP boards that support 200 TRX each. Without Optimized HR connectivity feature, the B9 rule is still applied. The following table gives the configuration data of each MX BSC configuration type.
BSC Evo Configuration 200 TRX 400 TRX 600 TRX 800 TRX 1000 TRX Max CS Load (Erlang) 900 1800 2600 (B9) 2700 (B10) 3600 (B10) 4000 (B10-MR1) 4500 (B10-MR2) BTSs 150 255 255 255 255 Cells 200 264 264 500 500 Abis E1 96 96 176 176 176 Ater-CS E1 10 20 30 40 48 Ater-PS E1 6 12 18 24 28
Figure 13: B10 BSC capacity improvements
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
27 / 154
Page
2.3.3.1 Optimized HR connectivity

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

The ITU-T Recommendations have limited the amount of Signalling Links (SL) between two adjacent Signalling Point (SP). For Alcatel BSCs, there is a maximum of 16 SS7 signalling channels per BSC. The signalling channel, called N7 channel, is carried over an individual 64kbps timeslot on the AterMUX CS link; it is traditionally dimensioned with a 40% load. In B9 release, Mx BSC was supporting up to 2600Erl that corresponds to a SS7 load of 60%. To overcome the ITU-T limitation, High Speed Link (HSL) functionality has been introduced. This HSL mode is only available with Mx BSC and it is used when Low Speed Link (LSL) mode i.e. 64kbps SS7 channels is not sufficient for Mx BSC requiring a high SS7 signalling load or a high traffic mix model (1900Erl up to 4500Erl). The HSL mode relies on the transport of SS7 signalling over a couple of 2Mbps PCM links:
Whatever the traffic load is For redundancy and load sharing purposes To double the BSC signalling throughput (for 4500Erl, the SS7 load is 33%) HSL links are directly connected to MSC, without passing through TC
BSC
ATERMUX
TC
Interface A
MSC
HSL 1 HSL 2
Figure 14: BSC - MSC connectivity with HSL mode
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
28 / 154
Page
3 Detailed BSS Architecture Process

This section describes in details of the BSS architecture process in release B10. Several sub-sections are created to focus on each network elements and interfaces.
3.1 BTS
The area covered by a BSS is divided into cells and each cell is managed by a BTS. Each BTS consists of radio transmission and reception devices including antennae and signal processing equipment for the Air Interface.
3.1.1 BTS Configuration
The following diagram presents the BTS generations, which are supported in release B10.
BTS Generation
G1 BTS G1 BTS MK II with DRFU
G2 BTS G2 BTS DRFU
Evolium BTS G3 BTS M4M
Evolium Evolution G4 BTS M5M G5 BTS
GPRS CS-1, CS-2
GPRS CS-1, CS-2
GPRS CS-1, CS-4
GPRS CS-1, CS-4 EDGE MCS-1, MCS-9
Twin
Figure 15: BTS generation/type supported in B10
Only MKII with DRFU is supported in B10. It stays at B7.2 functionality and its configuration is presented in Table 2.
Type MKII Characteristic Std + DRFU Nb of sectors 1 Nb of TRX 8 GSM 900 x
G1 BTS 1st BTS Generation
Table 2: Configuration G1 BTS MKII with DRFU
Data in this table, based on [9]
For more details, please refer to [1] and [3]
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
29 / 154
Page
Only G2 BTS with DRFU is supported in B10 with following the rule: the FUMO in G2 BTS must be replaced by DRFU before B7/B8 release migration. G2 BTS stays at B7.2 functionality and its configuration is presented in Table 3.
BTS G2 Configuration Min 1 TRE Max 1 Sector: 8 TRE Extension / Reduction Physical Logical Min 1 TRE 1 TRE
G2 BTS 2nd BTS Generation
Table 3: Configuration G2 BTS
The Evolium BTS is designed with some improvements as compared to the previous BTS generation (G2). The main changes (related to architecture design) are:
Support Abis Statistical Multiplexing (64kbps and 16kbps) Secondary Abis link (except micro BTS M4M) GPRS CS-3, CS-4 is available Support TWIN TRX modules (since B9 MR4)
Evolium BTS 3rd BTS Generation
From B9 support, Evolium BTSs include G3 BTS, G3.5 BTS (which is G3 BTS with new power supply modules) and micro BTS M4M. See their configurations in Table 4.
BTS
Evolium BTS (G3 / G3.5) M4M (micro BTS)
Configuration Min
1 TRE 2 TRE
Max
Up to 18 TRE (1 to 6 sectors) (since B9MR4) Up to 6 TRE (1 to 6 sectors) Table 4: Configuration Evolium BTS
Extension/Reduction Physical Logical Min

1 TRE 2 TRE TRE 1 TRE
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
30 / 154
Page
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.
Evolium Evolution 4th BTS Generation
The new architecture of the Transceiver module (digital & analogue parts on the same board) brings the possibility to develop a low power TRE that would allow achieving 18 TRX capacity in one rack.
Since B9 support, Evolium Evolution BTSs include:
G4.2 BTS, which introduces a new TRE with EDGE HW Capability Micro BTS M5M TWIN TRX modules (since B9MR4)
G3.8 BTS, which is G3.5 BTS with SUMA, ANC, new power supply modules
Their configurations are presented in Table 5.

BTS Evolium BTS (G3.8 / G4.2) Evolium BTS (G5) M5M (micro BTS) Configuration Min Max 1 TRE Up to 18 TRE (1 to 6 sectors) (since B9MR4) 1 TRE Up to 24 TRE (1 to 6 sectors) (since B9MR4) 2 TRE Up to 12 TRE (1 to 6 sectors)
Table 5: Configuration Evolium Evolution
Extension/Reduction Physical Logical Min 1 TRE 1 TRE 2 TRE 1 TRE 1 TRE 1 TRE
N.B. In case of BTS housing TWIN TRA modules and G3 TRX a maximum number of 12 TRX is allowed. For more details, please refer to [1], [6], [7]
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
31 / 154
Page
As shown in Table 6:
B9 release B10 release
Summary BTS Hardware Capability B10 release

G1 BTS G2 BTS
G2 BTS DRFU x x
No Multiplexing 16K Static Multiplexing 64K Statistical Multiplexing 16K Statistical Multiplexing 2nd Abis access FR DR AMR EFR GPRS (CS-1 , CS- 2) GPRS (CS-3 , CS- 4) EGPRS (MCS-1 to MCS-9) GSM 850 GSM 900 GSM 1800 GSM 1900 850/1800 850/1900 900/1800 900/1900
G1 BTS MKII DRFU x
Evolium BTS
G3 BTS x x x x x x x x x x x x x x x x x x M4M x x x x x x x x x x x x
Evolium Evolution
G4 BTS x x x x x x x x x x x x x x x x x x x x M5M x x x x x x x x x x x x x x x x x x x x
Abis feature
Data Traffic
x x x x x
x x x x x
Voice Traffic
Multi band
Mono band
x x x
Table 6: BTS HW Capability in B10
Three main types of Transceiver modules are implemented since G3 BTS generation; the Evolium TRE, the EDGE TRA and the Twin TRX. 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),
TRX hardware description
These Transceivers can cover either GSM band or DCS band.
Coverage mode (Tx Diversity mode) that generates a single functional TRX (8 RTS) allowing either:
Higher Output Power due to Tx diversity ("air coupling") usage (113W to 175W GMSK in 900MHz, and 88W to 136W GMSK in 1800MHz Higher Sensitivity (-117.4 to -121dBm) due to 4Rx Uplink Diversity usage (2Rx Diversity also possible)
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
32 / 154
Page
The following table describes the transceiver hardware since G3 BTS generation.
Generation G3 G3 G4 G4 G4 G4 G4 G4 G4 G4 G4 G4 G5 G5 G3 TRX 900 35W DR-EFR 9100 TRX 1800 35W DR-EFR 9100 TRX 1800 60W DR-EFR 9100 TRX Type MNEMO TRGM TRDM TRDH TRAD TRAP TRAL TRAG EDGE No No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No
A9100 TRX 900 EDGE COMPATIBLE A9100 TRX 850 EDGE COMPATIBLE
A9100 TRX 1800 EDGE COMPATIBLE A9100 TRX 1900 EDGE COMPATIBLE
A9100 TRX 900 HP EDGE COMPATIBLE A9100 TRX 900 EDGE PLUS
A9100 TRX 1800 HP EDGE COMPATIBLE A9100 TRX 1800 EDGE PLUS
TAGH TRAGE TAGHE TADHE TGT09 TGT18 TRADE TADH
A9100 TRX 900 HP EDGE PLUS A9100 TRX 900 TWIN
A9100 TRX 1800 HP EDGE PLUS A9100 TRX 1800 TWIN
Table 7: TRX HW capability since G3 BTS generation
3.1.1.1 Cell Configuration

Cell Types: the following table describes all the cell types (with profile type parameters) available in B10.
Cell Type Micro Single Mini Extended Umbrella Concentric Umbrella-Concentric Indoor Micro Dimension Micro Macro Macro Macro Macro Macro Macro Micro Profile Type Parameters Coverage Overlaid Single Overlaid Single Umbrella Single Umbrella Indoor Partition Normal Normal Normal Normal Normal Concentric Concentric Normal Range
Normal Normal Normal Extended Normal Normal Normal Normal
Table 8: Cell Types
Extended Cell:
Its configuration is a BTS with up to 4 TRX in the inner cell and up to 4 TRX in the outer cell. M4M and M5M do not support extended cell configurations. Only one extended cell per BTS is possible.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
33 / 154
Page
Shared Cell:
A cell shared by several BTSs is possible to support up to 16 TRX (software limitation). Only the A9100 Evolium BTS (G3 BTS & G4 BTS) support shared cell. The BTSs in a shared cell must be clock synchronized.
With Twin TRX, the 16 TRX limitation can be reached without using shared cell method.
M4M and M5M do not support a shared cell because they cannot be clock synchronized.
Frequency Hopping:
The Table 9 shows the hopping types supported in B10.

Hopping Type Non Hopping (NH) Base Band Hopping (BBH) Radio Hopping (RH) * Non Hopping / Radio Hopping (NH/RH) NH/RH with Pseudo Non Hopping TRX BBH with Pseudo Non Hopping TRX
Supported in B9 x x x x x
Data in this table, based on [1] * RH works only with M1M and M2M that are now obsolete.
Table 9: Frequency Hopping supported in B10
3.1.1.2 SDCCH Configuration

Since B8 release, the dynamic SDCCH allocation feature is a new mechanism that provides automatic (the optional number of) SDCCH in the cell, which translates as a set of dynamic SDCCH/8 TS, used for TCH traffic or for SDCCH traffic, depending on the requirement. Principle:
Static SDCCH sub-channels are defined to handle normal SDCCH traffic. Dynamic SDCCH sub-channels are defined to handle high SDCCH traffic.
Main Rules:
At least one static SDCCH/8 or SDCCH/4 timeslot on BCCH TRX must be configured in a cell. Combined SDCCHs (SDCCH/4 + BCCH) are always static. The total number of SDCCH sub-channels configured on static or dynamic SDCCH TS or on a BCCH/CCCH TS (CCCH combined case) must not exceed 24 sub-channels per TRX and 88 sub-channels per cell. In order to avoid incoherent allocation strategies between SDCCH and PDCH, a dynamic SDCCH/8 TS cannot be a PDCH. BTS with DRFU do not support dynamic SDCCH allocation. In A9130 BSC Evolution it is not allowed more than one SDCCH TS per TRX.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
34 / 154
Page
Recommended SDCCH configuration:

-
In a cell, the number of SDCCHs is defined variously, based on: Number of TRXs
Location Update (LU) signalling traffic: 1 LU/call for standard cell SMS signalling traffic: 0.5 SMS/call for standard cell
Recommended default number of SDCCH and configuration are presented in Table 10.
Number of TRXs 1 2 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 BCCH Combined Yes Yes No No No No No No No No No No No No No No No Number of SDCCH sub-channels Total 12 12 24 24 32 32 32 40 40 48 48 48 56 56 64 72 72
SDC 4 4 8 8 8 8 8 16 16 16 16 16 16 16 24 24 24
SDD 8 8 16 16 24 24 24 24 24 32 32 32 40 40 40 48 48
Table 10: Recommended SDCCH configuration for a standard cell only FR TRXs
Remarks:
1) 2) 3) 4) 5)
SDC means Static SDCCH, SDD means Dynamic SDCCH, and Max presents the maximum number of SDCCHs (SDC+SDD) that may be allocated in a cell. Up to 16 TRXs are possible to be configured for a cell thanks to shared cell feature. For one TRX, dynamic SDCCH are over-dimensioned because of the granularity of 8. According to Alcatel traffic model, all dynamic SDCCH will not be used. An additional dynamic SDCCH/8 must be provided for each DR TRX (these are expected mainly on small cells). For some particular cells with high (LU and/or SMS) signalling load, the operator will probably need to customize the number of SDCCHs (different from the recommendation) according to his requirements; otherwise the SDCCH dimensioning should be applied (please refer to section 3.1.3.1).
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
35 / 154
Page
3.1.2 Determination of BTS configuration
For each sites, it is necessary to define the number of required BTSs, which depends on the total number of required TRXs and cells and maximum capacity of the given BTS (refer to section 3.1.1).
To determine the number of required TRXs, the cell dimensioning (refer to section 3.1.3) is needed to start first, and then the following processes to determine BTS configuration will be performed afterwards as shown in Figure 16.
Nb of required TRXs Nb of required cells Max. Capacity of the given BTS
Nb of required BTSs
Nb of installed BTSs
Required >
Assessment (comparision)
Required =
Required <
Under-dimensioning Increase installed BTSs
OK
Over-dimensioning Decrease installed BTSs
Figure 16: Determination of BTS configuration
3.1.3 Cell dimensioning

BCCH TS: 1 TS
The number of required TRXs can be derived from the combination of several kinds of radio timeslots:
SDCCH TS: to be defined based on SDCCH traffic (cf. section 3.1.3.1)
TCH/PDCH TS: to be defined based on CS/PS traffic (cf. section 3.1.3.2)
And a TRX consists of 8 RTS (Radio TimeSlots). So, Number of TRXs = roundup [(BCCH TS + SDCCH TS + TCH/PDCH TS) / 8] When mCCCH feature is enabled, a second CCCH time slot shall be taken into consideration when computing the required number of BCCH, SDCCH and TCH/PDCH timeslots.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
36 / 154
Page
3.1.3.1 SDCCH Dimensioning

Target: To estimate the number of SDCCH resources needed at Cell level. Gathered Counters:
Counter Name MC400 MC04 MC148 Indicator Name GSDTRT GSDNACGN GSDNACAN Definition Cumulated time during which the SDCCH sub-channels belonging to the related static or dynamic SDCCH timeslots are busy.
Number of unsuccessful SDCCH sub-channel selection (all SDCCH sub-channels are busy or Out of Service).
Table 11: Counter list - SDCCH dimensioning
Number of SDCCH attempts for any other purpose than HO (Channel Activation).
Measured Object: Cell Gathering periods: 7-day Busy Hour data, recommended Otherwise, at least 2 working-day Busy Hour data
Note: Busy Hour means the hour gives the highest SDCCH traffic (i.e. MC400) of the day.
Methodology:
The process of SDCCH dimensioning is presented in Figure 17.

INPUT
Required SDCCH Traffic GoS: % SDCCH blocking
METHOD
OUTPUT Nb of required SDCCH subchannels / timeslots
Erlang B
Figure 17: SDCCH dimensioning process
The required SDCCH traffic is computed as below formula. Re quired _ SDCCH _ traffic =
INPUT
Measured _ SDCCH _ traffic 1 Min(%SDCCH _ cong , 30%)
Note: 30% is defined as the max congestion rate to be considered because several congestions can be re-produced from one given user trying to access the network several times.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
37 / 154
Page
Where:
Measured _ SDCCH _ traffic = % SDCCH _ cong =
MC 04 100% MC 04 + MC148
MC 400 3600
The other input is Grade of Service (GoS), which is defined by the required SDCCH congestion rate (pSDCCH). Normally GoS should be given or agreed by the Mobile Operator. The typical value for the required SDCCH congestion rate is 0.5%.
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.
METHOD
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 Then,
= Erlang B (Required_SDCCH_traffic, pSDCCH)
Number of required SDCCH Timeslots =
(Nb of required SDCCH sub-channels 4) / 8; for BCCH combined cell
Nb of required SDCCH sub-channels / 8; for non- BCCH combined cell
Assessment:
When % SDCCH congestion (of any cell) > pSDCCH, the SDCCH re-dimensioning is needed.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
38 / 154
Page
3.1.3.2 TCH/PDCH Dimensioning

Target: To estimate the number of TCH & PDCH resources needed at Cell level. Gathered Counters: TCH
Counter Name MC380a MC812 MC703 MC380b Indicator Name GTCTRFT GTCTRHT Definition Time during which the TCH FR are busy Time during which the TCH HR are busy
GTCNACGN GTCNACAN
Number of failures when switching from SDCCH to the TCH (call establishment only) due to congestion on Air Interface channels (RTCH). Number of TCH successfully selected for any purpose other than HO.
Table 12: Counter list - TCH dimensioning
Gathered Counters: PDCH

Counter Name P451b P451a P14 P27 P91a+P91b+P91c+ P91d+P91e+P91f+ P505 P62a+P62b+P62cP438c + P507 P38e P38f P20x (x = ad) Indicator Name GARPDCTDBUT GARPDCTUBUT GQRDTECGN GQRUTECGN GTRDTERQN GTRUTERQN GARPDCUDBUT GNPACUUBUT GQRPDDRxN (x = 1,.. ,4) Definition 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). Cumulative time during which a UL TBF uses on PDCH, for all PDCHs and for all the TBFs of the cell (established in GPRS mode or EGPRS mode).
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. Number of uplink TBF establishment failures due to congestion (no radio resource in the MFS). Number of DL TBF establishment requests per cell. Number of UL TBF establishment requests per cell.
Cumulative time during which the slave PDCHs are established and carry at least one DL TBF (established in GPRS mode or EGPRS mode). Cumulative time during which the slave PDCHs are established and carry at least one UL TBF (established in GPRS mode or EGPRS mode).
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.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
39 / 154
Page
P20f+P20g+P20h+ P20i+P20j+...+P20n (x = fn) P21x (x = ad) P21f+P21g+P21h+ P21i+P21j++P21n (x = fn) P55x (x = a,.. ,m) P57x (x = a,.. ,m)
GQRPDDRMN
GQRPDURxN (x = 1,.. ,4) GQRPDURMN GTRPDDCxN (x = 1,.. ,4) GTRPDDMyN (y = 1,.. ,9) GTRPDUCxN (x = 1,.. ,4) GTRPDUMyN (y = 1,.. ,9)
In acknowledged mode, number of DL RLC data bytes encoded in all MCS-x and retransmitted due to unacknowledgement of the MS. RLC blocks containing LLC dummy UI commands are not counted.
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. In acknowledged mode, number of UL RLC data bytes encoded in all MCSx and retransmitted due to unacknowledgement of the MFS.
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). Number of useful UL RLC blocks received in RLC acknowledged mode on PDTCH encoded in (M) CS-x i.e. CS1 (P57a) CS-4 (P57d) and MCS-1 (P57e) MCS-9 (P57m).
Table 13: Counter list - PDCH dimensioning
Note: Busy Hour means the hour gives the highest TCH & PDCH traffic of the day.
Methodology:
The process of TCH/PDCH dimensioning is presented below.

INPUT
CS service input data PS service input data
METHOD
OUTPUT Total required TS for TCH and PDCH
KaufmannRobert Algorithm
Figure 18: TCH/PDCH dimensioning process
INPUT
(1) CS service input data:
CS Traffic Intensity in Erlang: The CS traffic intensity is calculated separately between Full Rate (FR) and Half Rate (HR) Traffic. The calculation will take into account the real measured traffic and additional margin from congestion rate.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
40 / 154
Page
The way to calculate the congestion rate for FR and HR is presented below:
CS _ Cong _ Per = min( 30%,CS _ Real_Cong_ Per)
Note: 30% is defined as the max congestion rate to be considered because several congested calls can be re-produced from one given user trying to access the network several times.
CS_Real_Cong_Per =
RTCH_Assign _ Cong MC812 = RTCH_Assign _ Request MC 812 + MC 703
As there is no specific counter to identify the type of congestion (from FR calls or HR calls), below is the calculation to divide the global congestion rate into FR congestion rate and HR congestion rate.
FR _ Cong _ Per = HR _ Cong _ Per = MC 380a CS _ Cong _ Per MC 380a + MC 380 b
MC 380 b CS _ Cong _ Per MC 380a + MC 380 b
Then,
Full Rate CS traffic Intensity is:

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

HR =
MC380bcell HR _ Successful _ Traffic = 1 HR _ Cong _ Per 3600 ( 1 HR _ Cong _ Per )
CS Bandwidth:
1 TS; for FR
CS GoS (as requirement): Blocking Probability rate = 2 %, for instance
0.5 TS; for HR
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
41 / 154
Page
(2) PS service input data:
PS Traffic Intensity in Erlang:
The required PS traffic intensity is computed as below formula.

Re quired _ PS _ traffic = Measured _ PS _ traffic 1 Min(%TBF _ radio _ cong , 30%)
Where:
Measured _ DL _ PS _ traffic =
P 451b 3600
Measured _ UL _ PS _ traffic =
%DL _ TBF _ radio _ cong =
P 451a 3600
P14 100 % P 91a + P 91b + P 91c + P 91d + P 91e + P 91f + P 505
%UL _ TBF _ radio _ cong =
P 27 100 % P 62a + P 62b + P 62c P 438c + P 507
PS Bandwidth (minimum number of TS per a request on each direction): 1 / MAX_DL_TBF_SPDCH; for DL 1 / MAX_UL_TBF_SPDCH; for UL
Note: MAX_DL(UL)_TBF_SPDCH is the O&M parameter, which defines the maximum number of Down (Up) link (E)GPRS TBFs per Slave PDCH.
PS GoS (as requirement): Delay in seconds and Quantile in % PS throughput in kbps: For DL:
d PS _ DL =
m n d 8 P 20 x RLC _ Block _ Sizex + P 55 x RLC _ Block _ Sizex + P 20 x x =a x =a x =f = 1000 P 38e
Data_DL Transmision_Time_DL
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
42 / 154
Page
For UL:
d PS _ UL =
m d n 8 P 21x RLC _ Block _ Sizex + P 57 x RLC _ Block _ Sizex + P 21x x =a x =a x =f = 1000 P 38 f
Data _ UL Transmision _ Time _ UL
Where:
Channel Coding scheme CS-1 CS-2 CS-3 CS-4 MCS-1 MCS-2 MCS-3 MCS-4 MCS-5 MCS-6 MCS-7 (sent of 2 blocks) MCS-8 (sent of 2 blocks) MCS-9 (sent of 2 blocks)
RLC data block size in bytes 22 32 38 52 22 28 37 44 56 74 2*56 2*68 2*74
Table 14: RLC data block size for each (M) CS
Remark: PS throughput (in kbps) can also be defined by the target throughput per PDCH, which probably can be given by the operator e.g. 30kbps for DL & UL (this information should also be provided in R_AVERAGE_GPRS and R_AVERAGE_EGPRS parameters).
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.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
43 / 154
Page
Recommendation:
The method is complicated to apply manually, as it uses high level of mathematical formulas & statistical laws. Therefore, please contact Network Engineering service for related supports.
Assessment
The following diagram presents the TCH/PDCH assessment process.

Nb of required TCH/PDCH TSs Nb of installed TCH/PDCH TSs
Required > Installed
Assesment (comparision)
Required < Installed
Required = Installed
Under-dimensioning Increase installed TCH/PDCH
OK
Over-dimensioning Decrease installed TCH/PDCH
Figure 19: TCH/PDCH dimensioning assessment
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.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
44 / 154
Page
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 microwave link (same capacity or higher) A microwave hub equivalent to DCN A terrestrial link referred to as PCM 2Mbps link (64kbps * 32 TS = 2048kbps)
Digital Cross-connect Network equipment, which concentrates 4, 16 or 64 PCM links
A Satellite link (N.B. It is not possible to have Abis interface on satellite link if AterMux interface is also on Satellite link)
3.2.1 Abis Configuration

3.2.1.1 Abis Network Topology
The following network topologies are defined for BTS to BSC connection. Chain topology (or Multi-drop) Several BTSs are connected to the same Abis interface. It means the Abis link is statically shared. Chain topology brings the gain to save number of Abis links but it is possible only for the BTSs with small TRX configuration.
BTS Abis BTS Abis BTS Abis BSC
Up to 15 BTSs per 1 Abis Chain
Figure 20: Abis Chain (Multi-drop) Topology
Star topology
Each BTS is connected to the BSC directly; an Abis link is dedicated to a BTS. A star topology can be considered as a particular case of a chain topology with only one BTS.
This topology is well suited to support BTSs with large configuration and is also flexible for TRX expansion.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
45 / 154
Page
BTS
BTS Abis
BTS Abis BTS Abis
Abis
Only 1 BTS per 1 Abis Star
BSC
Figure 21: Abis Star Topology
Ring topology (or Closed loop)
Several BTSs are connected to the same Abis interface. It means the Abis link is statically shared. Moreover, the last BTS of the chain is connected to the BSC.
Compared to multi-drop, ring topology enhances security because the traffic between any BTS and BSC is broadcast on two paths and the selection is based on dedicated service bits and bytes. It is anyway more recommended to secure the transmission link rather than wasting BSC connectivity resources by using this kind of topology.
BSC
BTS Abis
BTS Abis
BTS Abis
Up to 7 BTSs per 1 Abis Ring
Abis
Figure 22: Abis Ring (Closed loop) Topology
Secondary Abis topology
Since B8 (EDGE introduction), secondary Abis topology may be needed to activate EDGE on some BTSs that have large TRX configuration.
There are two possible configurations for secondary Abis topology, supported in release B10:
Configuration # 1: Configuration # 2: Primary Abis connects only one BTS and Secondary Abis is looped back to BSC. Primary Abis connects only one BTS and for Secondary Abis there can be BTSs multi-dropped to each other.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
46 / 154
Page
BTS
Pri Abis
Sec Abis
BTS
BTS
Configuration # 1
BSC
BTS
Pri Abis Sec Abis BSC
Configuration # 2
Figure 23: Secondary Abis Topology
3.2.1.2 Abis Channels

Three types of channels are mapped onto an Abis link: Qmux Channel only necessary for G1 and G2 BTS
It is used by TSC O&M transmission supervision for non-Evolium BTS (G1 and G2 BTS). In case of Evolium BTS, the functionality of Qmux can be managed through the OML, via OML auto-detection.
Ring Control Channel used in Ring topology only
This channel is used by the transmission equipment (BIE), which depends on the TSC. There are two kinds of bits (R Ring control bits and S Synchronization bits) containing in ring control channel.
3 types of BTS Channels
1) TCH/GCH Channels: 8 Radio TS per TRX is mapping onto 2 Abis TS.

TRX TS 0 TS 1 TS 2 TS 3 TS 4 TS 5 TS 6 TS 7
Abis TS 0 TS 1 TS 2 TS 3 TS 4 TS 5 TS 6 TS 7
Figure 24: TRX - Abis mapping
For a given moment, a radio TS on a GPRS capable TRX can carry:
Either CS traffic, then it is called as TCH and the corresponding Abis channel is also called as TCH, Or PS traffic, then it is called as PDCH and the corresponding Abis channel(s) is/are called as GCH(s). Several GCHs per PDCH are used in case of EDGE.
1
Alcatel File
3DF 01903 8010 VAZZA 01
March 04, 2008
47 / 154
Page
2) LAPD Channels: carry one or more LAPs (RSL and/or OML).

Only 1 RSL per TRX Only 1 OML per BTS
The GSM Recommendation 08.52 defines 2 logical links between the BTS and the BSC:
Radio Signalling Link (RSL) is used for supporting traffic management procedures (MS to network communication). Operation & Maintenance Link (OML) is used for supporting network management procedures.
For details about Abis resource management for RSL/OML, please refer to section 0.
3) Extra Abis TS
On Abis interface, two types of 64kbps TS are considered:

Basic Abis TS: Extra Abis TS:
handle OML, RSL and traffic TS handle only supplementary GPRS (CS-3/CS-4) and EDGE (MCS-1 to MCS-9) nibbles when needed.
In B10 release, the maximum number of extra Abis TS can be configured through the new OMC parameter N_EXTRA_ABIS_TS. Summary Abis Channels:
Channel type Qmux Channel
Qmux TS0 Other TS except TS0
TS position
TS0 transparency
TS0 usage
Purpose
Used by the BSC to manage Remote Transmission Network Elements.
Ring control Channel used in Ring topology only

Ring control R bits Synchronisation controls S bits Other TS except TS0 TS0
Other TS except TS0 (Qmux)
Supervision of Ring continuity Direction of clock synchronisation GSM (GPRS CS-1/CS-2) traffic LAPD channel for BTS (1 OML per BTS) LAPD channel for TRX (1 RSL per TRX) To support GPRS CS-3/CS-4 and EDGE
Included with Qmux Other TS except TS0 Other TS except TS0 Other TS except TS0
BTS Channels
TCH/GCH LAPD Extra Abis TS
Table 15: Abis Channel Types
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
48 / 154
Page
TS 0 Usage: It means that TS 0 carries Qmux.
Remarks: There are two TS 0 modes:
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.
G1 or G2 BTS 31 30 Chain & Star Topology 31 EVOLIUM BTS (*) 31 G1 BTS (**) 30 28 Ring Topology G2 or EVOLIUM BTS 30 29
TS0 TRANSPARENCY TS0 USAGE
Table 16: Number of TS available in one Abis link

(*) Improvement with EVOLIUM BTS: In case all BTSs of a chain are EVOLIUM BTSs, and if TS0 transparency is used, then the time-slot used for transmission supervision (QMUX) can be saved (because the OML of EVOLIUM BTS supports also the transmission supervision information). (**) This column applies even if there is only one G1 BTS in a closed multidrop where other BTSs are not G1 BTSs.
From Table 16, one Abis link capacity depends on:

- Type of Abis network topology - BTS generations - TS 0 mode (TS 0 usage or TS 0 transparency)
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
64K Statistical Multiplexing 16K Statistical Multiplexing
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
49 / 154
Page
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.
TS TS TS TS TS TS 0 1 2 3 4 5 Nibble 1 TRX 1 - TS 0 TRX 1 - TS 4 TRX 2 - TS 0 TRX 2 - TS 4 TRX 3 - TS 0 TRX 3 - TS 4 TRX 4 - TS 0 TRX 4 - TS 4 Nibble 2 Nibble 3 TS 0 Usage / Transparency TRX 1 - TS 1 TRX 1 - TS 2 TRX 1 - TS 5 TRX 1 - TS 6 TRX 1 - RSL TRX 2 - TS 1 TRX 2 TRX 2 - TS 5 TRX 2 TRX 2 - RSL TRX 3 - TS 1 TRX 3 TRX 3 - TS 5 TRX 3 TRX 3 - RSL - TS 2 - TS 6 - TS 2 - TS 6
Abis Configuration
Nibble 4 TRX 1 - TS 3 TRX 1 - TS 7 TRX 2 - TS 3 TRX 2 - TS 7 TRX 3 - TS 3 TRX 3 - TS 7 TRX 4 - TS 3 TRX 4 - TS 7
TS 6 TS 7 TS 8 TS 9 TS 10 TS 11 TS 12 TS 13 : : : TS 31
13 TS required in case of No Multiplexing
TRX 4 - TS 1 TRX 4 - TS 2 TRX 4 - TS 5 TRX 4 - TS 6 TRX 4 - RSL OML : : :
Figure 25: Example of Abis TS usage for 1 BTS/4 TRX No Multiplexing
3.2.1.4.2 16K Static Multiplexing The RSL of a FR TRX requires only 16kbps. It is therefore possible to pack up to four RSL into one 64kbps Abis time slot. However, the OML is still carried on a full 64kbps Abis time slot. That means:
Up to 4 RSL: 1 Abis TS (64kbps) 1 OML: 1 Abis TS (64kbps)
The following figure shows the example of Abis timeslot consumption for 1 BTS with 4 TRX when 16K Static multiplexing is applied.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
50 / 154
Page
TS 0 TS 1
Nibble 1 TRX 1 - TS 0 TRX 1 - TS 4 TRX 2 - TS 0
TS 2 TS 3 TS 4 TS 5 TS 6
TS 10 : : TS 31 :
TS 7 TS 8 TS 9
TRX 2 - TS 4 TRX 3 - TS 0 TRX 3 - TS 4
TRX 3 - TS 1 TRX 3 - TS 5 TRX 4 - TS 0 TRX 4 - TS 1 TRX 4 - TS 4 TRX 4 - TS 5 TRX 1 - RSL / TRX 2 - RSL /
TRX 1 - TS 1 TRX 1 - TS 5 TRX 2 - TS 1 TRX 2 - TS 5
Nibble 2 Nibble 3 TS 0 Usage / Transparency
Abis Configuration
TRX 1 - TS 2
TRX 1 - TS 6 TRX 2 - TS 2
TRX 2 - TS 6
TRX 4 - TS 3 TRX 4 - TS 6 TRX 4 - TS 7 TRX 3 - RSL / TRX 4 - RSL OML : :
10 TS required in case of 16K Static Multiplexing
Figure 26: Example of Abis TS usage for 1 BTS/4 TRX 16K Static Multiplexing
Rules:
16K Static Multiplexing is used only in a BSS with Evolium BTS and G2 BTS with DRFU, whereby each TRX carries a maximum of 8 SDCCH. Not compatible with the Half-Rate mode. BTS should be connected to a G2 BSC.
3.2.1.4.3 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 3 Abis TS per TRX
Nibble 1 TRX 1 - TS 0 TRX 1 - TS 4
It is used for FR or DR TRX with high signalling load.

Abis Configuration
Figure 27: 64K Statistical Multiplexing MCB 64/1 mapping
TS 0 TS 1 TS 2 TS 3
TRX 1 - TS 1 TRX 1 - TS 2 TRX 1 - TS 5 TRX 1 - TS 6 TRX 1 - RSL / OML
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
51 / 154
Page
2) MCB 64/2 64K Statistical Multiplexing for 2 TRX
It is used for FR TRX with high signalling load or DR TRX with normal signalling load. 2.5 Abis TS per TRX
Nibble 1 TRX 1 - TS 0 TRX 1 - TS 4 TRX 2 - TS 0 TRX 2 - TS 4
TS 0 TS 1 TS 2 TS 3 TS 4 TS 5
TRX 1 - TS 1 TRX 1 - TS 2 TRX 1 - TS 5 TRX 1 - TS 6 TRX 2 - TS 1 TRX 2 - TS 2 TRX 2 - TS 5 TRX 2 - TS 6 TRX 1 - RSL / TRX 2 - RSL / OML
Abis Configuration
Nibble 4 TRX 1 - TS 3 TRX 1 - TS 7 TRX 2 - TS 3 TRX 2 - TS 7
3) MCB 64/4 64K Statistical Multiplexing for 4 TRX 2.25 Abis TS per TRX
Nibble 1
It is used for only FR TRX with normal signalling load.

Abis Configuration
TS 0 TS 1 TS 2 TS 3 TS 4 TS 5 TS 6 TS 7 TS 8 TS 9
TRX 1 - TS 0 TRX 1 - TS 1 TRX 1 - TS 2 TRX 1 - TS 3 TRX 1 - TS 4 TRX 1 - TS 5 TRX 1 - TS 6 TRX 1 - TS 7 TRX 2 - TS 0 TRX 2 - TS 1 TRX 2 - TS 2 TRX 2 - TS 3 TRX 2 - TS 4 TRX 2 - TS 5 TRX 2 - TS 6 TRX 2 - TS 7 TRX 3 - TS 0 TRX 3 - TS 1 TRX 3 - TS 2 TRX 3 - TS 3 TRX 3 - TS 4 TRX 3 - TS 5 TRX 3 - TS 6 TRX 3 - TS 7 TRX 4 - TS 0 TRX 4 - TS 1 TRX 4 - TS 2 TRX 4 - TS 3 TRX 4 - TS 4 TRX 4 - TS 5 TRX 4 - TS 6 TRX 4 - TS 7 TRX 1 - RSL / TRX 2 - RSL / TRX 3 - RSL / TRX 4 - RSL / OML
Nibble 4
The following figure shows the example of Abis timeslot consumption for 1 BTS with 4 TRX when 64K Statistical multiplexing is applied.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
52 / 154
Page
TS 0 TS 1 TS 2
TS 3 TS 4 TS 5 TS 6 TS 7 TS 8
TS 9 : : :
TRX 3 - TS 5 TRX 3 - TS 6 TRX 4 - TS 0 TRX 4 - TS 1 TRX 4 - TS 2 TRX 4 - TS 3 TRX 4 - TS 4 TRX 4 - TS 5 TRX 4 - TS 6 TRX 4 - TS 7 TRX 1 - RSL / TRX 2 - RSL / TRX 3 - RSL / TRX 4 - RSL / OML : : :
TRX 1 - TS 1 TRX 1 - TS 5 TRX 2 - TS 1 TRX 2 - TS 5 TRX 3 - TS 1
Abis Configuration
TRX 2 - TS 2
9 TS required in case of 64K Statistical Multiplexing
TS 31
Figure 30: Example of Abis TS usage for 1 BTS/4 TRX 64K Statistical Multiplexing
Rules:
64k Statistical Multiplexing is used only with Evolium BTS

I. (N/4) MCB 64/4
A BTS with N FR TRE configured with 64K statistical multiplexing requires:

II. One MCB 64/1 when N mod 4 = 1 (BTS with 1, 5, 9 or 13 TREs)
IV.
III.
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
One MCB 64/2 when N mod 4 = 2 (BTS with 2, 6, 10 or 14 TREs)
A BTS with N DR TRE configured with 64K statistical multiplexing includes ((N1)/2)+1 MCBs of which:
II. (N mod 2) MCB 64/1 I. (N/2) MCB 64/2
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).
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
53 / 154
Page
Number of FR TRE per BTS (per Abis link) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
List of physical MCBs 64/1 64/2 64/4 64/2; 64/1 64/4; 64/1 64/4; 64/2 64/4; 64/4 64/4; 64/2; 64/1 64/4; 64/4; 64/1
24 32 32
Max SDCCH weight per MCB
32; 24 32; 24 32; 32 32; 32 32; 32; 24
64/4; 64/4; 64/2 64/4; 64/4; 64/4
32; 32; 24
64/4; 64/4; 64/2; 64/1 64/4; 64/4; 64/4; 64/1 64/4; 64/4; 64/4; 64/2 64/4; 64/4; 64/4; 64/2, 64/1
32; 32; 32 32; 32; 32
32; 32; 32; 24 32; 32; 32; 24 32; 32; 32; 32
32; 32; 32; 32; 24
3.2.1.4.4 16K Statistical Multiplexing The basic Abis nibble corresponding to the radio timeslot 0 of each TRX encompasses the RSL of this TRX and eventually the OML of the BTS.
This multiplexing requires that no traffic, but only 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.
TS 0 TS 1 TS 2 Nibble 1 Nibble 2 Nibble 3 TS 0 Usage / Transparency
Abis Configuration
TRX1-RSL/OML TRX 1 - TS 1 TRX 1 - TS 4 TRX 1 - TS 5
The following figure shows the example of Abis timeslot consumption for 1 BTS with 4 TRX when 16K Statistical multiplexing is applied.
1
3DF 01903 8010 VAZZA 01
March 04, 2008
54 / 154
Page
TS 0 TS 1 TS 2
Nibble 1
TS 3 TS 4 TS 5
TS 6 TS 7 TS 8 : :
TRX 1-RSL/OML TRX 1 - TS 1 TRX 1 - TS 4 TRX 1 - TS 5 TRX 2 - RSL TRX 2 - TS 1 TRX 2 - TS 4 TRX 2 - TS 5 TRX 3 - TS 1 TRX 3 - RSL TRX 3 - TS 4 TRX 3 - TS 5 TRX 4 - TS 1 TRX 4 - RSL TRX 4 - TS 4 TRX 4 - TS 5
Abis Configuration
TRX 1 - TS 2 TRX 1 - TS 6 TRX 2 - TS 2 TRX 2 - TS 6 TRX 3 - TS 2 TRX 3 - TS 6 TRX 4 - TS 2
: : :
TRX 4 - TS 6
TRX 2 - TS 3 TRX 2 - TS 7 TRX 3 - TS 3 TRX 3 - TS 7 TRX 4 - TS 3 TRX 4 - TS 7
8 TS required in case of 16K Statistical Multiplexing
: TS 31
Figure 32: 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.5 Secondary Abis Link

If EDGE is to be introduced in a BTS configuration or if the BTS configuration in terms of number of supported TRX is increased (i.e. thanks to Twin TRX introduction), and if there are not enough Abis TS on one Abis link to carry all basic TS (TCH), signalling TS (RSL & OML) and extra TS, a second Abis link can be attached to the BTS.
B S C
Primary Abis Link

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

ET BT: Basic Timeslot ET ET ET ET ET ET ET
ET: Extra Timeslots
Figure 33: Abis TS configuration on primary and secondary links
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
55 / 154
Page
From B9 release:
The basic TS can be mapped to the primary or the secondary Abis link contrary to B8 where the basic TS can be only on the primary link. For more details, please refer to [2] The extra TS can be mapped to the primary or the secondary Abis link. For a BTS with two Abis links, the Operator defines the parameter: MAX_EXTRA_TS_PRIMARY that is the maximum number of extra timeslots the system is allowed to allocate on the first Abis for this BTS. To keep the maximum free timeslots on the secondary Abis, the allocation of extra timeslots is done in priority on the first Abis until this Abis is full or MAX_EXTRA_TS_PRIMARY is reached. For BTS with more than 12 TRX (up to 24), because of Twin TRX usage, it is possible to limit the number of TRX in the first Abis link.
Primary link TRX 1 to 12 + extra PS TS BSC Secundary link TRX 13 to 24 + extra PS TS
BTS 24TRX
Figure 34: BTS with 24 TRX mapped on both Abis links
The primary and secondary Abis links of a BTS can be on different Abis TSU of different BSC racks.
BTS 1 12 TRX BSC BTS 1 16TRX
BTS 2 6 TRX
BTS 2 6TRX
BTS 1 4 TRX
Figure 35: Example of topology with two BTS chained
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
56 / 154
Page
The operator has to define the parameters MAX_DR_TRE_PRIMARY and MAX_FR_TRE_PRIMARY, which give the maximum number of DR (resp. FR) TRE to be mapped on first Abis when a second Abis is attached.
First A-bis
OML+RSL1-4 OML+RSL1-4 TRX1 TRX1 TRX2 TRX2 TRX3 TRX3 TRX4 TRX4 RSL 5-8 TRX5 TRX5 TRX6 TRX6 TRX7 TRX7 TRX8 TRX8 RSL 9-12 TRX9 TRX9 TRX10 TRX10 TRX11 TRX11 TRX12 TRX12
MAX_FR_TRE_PRIMARY = 12
Maximum filling of first Abis link
Second A-bis
First A-bis
MAX_FR_TRE_PRIMARY = 8
Figure 36: Two Abis links filling examples.
Rules:
OML is always mapped on the first Abis link TCH and RSL of a TRX are always mapped on the same Abis link Only EVOLIUM BTS with SUMA board or M5M supports the 2nd Abis link. It is not possible to have the primary Abis link on terrestrial link and the secondary one on satellite link. An EVOLIUM BTS with SUMP board has to be upgraded. An EVOLIUM BTS can manage only 2 termination points - this implies that it is not possible to:
i) Connect a BTS in chain after a BTS with two Abis ii) Change the Abis from chain to ring if there is a BTS with two Abis iii) Attach a second Abis to a BTS that is not at the end of an Abis chain
3.2.2 Abis Dimensioning
The capacity of one Abis link is fixed at 32 TSs; however, only 31 TSs are actually available because 1 TS (TS#0) is always used for frame synchronization. If the number of needed TSs is greater than 31, the secondary Abis link is required. Thus, the aim of Abis dimensioning is to define how many Abis links (max. 2 links per BTS since B8) is sufficient to support the needed TSs.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
RSL 9-12 TRX9 TRX9 TRX10 TRX10 TRX11 TRX11 TRX12 TRX12 RSL 13-16 TRX13 TRX13 TRX14 TRX14 TRX15 TRX15 TRX16 TRX16
Equal filling of the two Abis links
Second A-bis
OML+RSL1-4 OML+RSL1-4 TRX1 TRX1 TRX2 TRX2 TRX3 TRX3 TRX4 TRX4 RSL 5-8 TRX5 TRX5 TRX6 TRX6 TRX7 TRX7 TRX8 TRX8
RSL 13-16 TRX13 TRX13 TRX14 TRX14 TRX15 TRX15 TRX16 TRX16
or
March 04, 2008
Date
Edition
1
57 / 154
Page
The number of needed Abis TS is based on: Type of Abis Topology TS0 mode Chain (Star) or Ring TS 0 usage or TS 0 transparency Used or Not used Static number of needed Abis TSs
Qmux usage
Type of signalling sub-multiplexing schemes Number of TRX
No mux, Static mux(16K), Statistical mux(16K or 64K) 2 Abis TSs are needed to support 1 TRX
Extra Abis TS
1 Extra Abis TS contains 4 GCHs (nibbles).
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. Various number of required GCH is based on modulation & coding scheme (MCS or CS), please refer to 3.4.4.2.3. Dynamic number of needed Abis TSs
Less GCH consumption in B9 thanks to M-EGCH and dynamic Abis allocation
Max number of extra Abis TS is limited by parameter N_EXTRA_ABIS_TS
It is simple to define the number of needed Abis TSs for conditions of topology, TS0 mode, Qmux usage, signalling sub-mux and number of TRX because each of them requires the certain number of TSs. The most complicated part of Abis dimensioning from B9 release is how to define the number of extra Abis TSs per BTS, as this kind of TS is allocated dynamically on Abis link when needed by traffic demand and it can be shared among the BTS sector.
The following presents the Abis dimensioning processes to define the needed extra Abis TSs based on the counter analysis.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
58 / 154
Page
3.2.2.1 Case #1: B9 with No GPRS/EDGE
B10 with EDGE
In case of a B9 network without GPRS/EDGE going to B10 network with EDGE, the Abis dimensioning should be performed only according to the operators assumption & requirement (e.g. target PS subscribers, PS traffic types, etc.) because there is no PS traffic counters available. Please contact Network Design division for Abis dimensioning case#1.
3.2.2.2 Case #2: B10 with EDGE

In case of B10 network with already EDGE, we can perform the Abis dimensioning based on the counter measurement. For this case, Abis dimensioning is not impacted by the migration from B9 to B10 release. There are 2 different methods approaching the Abis dimensioning:
Method 1: Abis dimensioning based on PS traffic only (bonus & extra Abis nibble traffic) Target: To estimate the number of Extra Abis Timeslots needed at BTS level. Gathered Counters:
Counter Name P466 P105i P105j P91a + P91b + P91c + P91d + P91e + P91f + P505 P62a + P62b + P62c - P438c + P507 Indicator Name GABGCHUSEBT GQRDTECBN GQRUTECBN GTRDTERQN Definition Cumulated time during which extra and bonus Abis nibbles are used in the cell, cumulated over all extra and bonus Abis nibbles. Number of DL establishment failures due to congestion of Abis. Number of UL establishment failures due to congestion of Abis. Number of DL TBF establishment requests per cell.
GTRUTERQN
Number of UL TBF establishment requests per cell.
Table 17: Counter list - Abis dimensioning Method 1
Measured Object: BTS Gathering periods: 7-day Busy Hour data, recommended Otherwise, at least 2 working-day Busy Hour data
Note: Busy Hour means the hour gives highest extra & bonus Abis nibble traffic (P466) of the day.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
59 / 154
Page
Methodology:
The process of Abis dimensioning is presented in Figure 37.

INPUT
Required extra & bonus Abis nibble Traffic GoS: % Quantile of x delay sec
METHOD
OUTPUT
Erlang C
Nb of required extra & bonus Abis Nibbles Nb of required extra Abis Nibbles
Figure 37: Abis dimensioning process Method 1
INPUT
The required extra & bonus Abis traffic is computed as below formula.
Re quired _ extra & bonus _ Abis _ traffic =
Measured _ extra & bonus _ Abis _ traffic 1 Min(%TBF _ Abis _ cong , 30%)
Where:
Measured _ extra & bonus _ Abis _ traffic =
P 466 3600
%TBF _ Abis _ cong = Max (%DL _ TBF _ Abis _ cong ,%UL _ TBF _ Abis _ cong )
Where:
%DL _ TBF _ Abis _ cong =
P105 i 100 % P 91a + P 91b + P 91c + P 91d + P 91e + P 91f + P 505
%UL _ TBF _ Abis _ cong =
P105 j 100% P 62a + P 62b + P 62c P 438c + P 507
The other input is Grade of Service (GoS), which is defined by % quantile of x delay second (pABIS).
Since the MFS always tries to assign TBFs as soon as the request is received, we usually dimension for 0sec delay.
1
3DF 01903 8010 VAZZA 01
March 04, 2008
60 / 154
Page
Normally GoS should be given or agreed by the Operator. On Abis interface, the recommended value is 95% quantile of 0 delay sec.
METHOD
Concerning only PS traffic, the statistical law Erlang C is used during the dimensioning process to determine the necessary resources versus the traffic and the target GoS.
As extra & bonus Abis nibbles are associated to PS traffic only, Erlang C can be applied to calculate the required number of extra & bonus Abis nibbles according to required PS traffic and % quantile of delay time.
OUTPUT
Number of required extra & bonus Abis nibbles
= Erlang C (Required_extra&bonus_Abis_traffic, pABIS)
However the number of bonus Abis nibbles is fixed according to the total number of BCCH & SDCCH TS in the BTS; i.e. one BCCH (SDCCH) TS gives one bonus Abis nibble. Then, Number of required extra Abis nibbles
= Number of required extra & bonus Abis nibbles Nbr of bonus Abis nibbles
And
Number of required extra Abis TS
= Number of required extra Abis nibbles / 4

Remark: 1 Abis TS contains 4 Abis nibble
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:
Assessment:
% _ TBF _ Abis _ cong > 0,1%
Radio throughput reduction: a method for throughput degradation is under study

1
3DF 01903 8010 VAZZA 01
March 04, 2008
61 / 154
Page
Method 2: Abis dimensioning based on CS & PS traffic
The main purpose of this method development is to provide Abis dimensioning based on both CS and PS traffic while method 1 is only taking into account PS traffic on bonus & extra nibbles. As in B9 with the new feature Autonomous Packet Resource Allocation, the number of basic nibbles mapped at one given moment to radio timeslot available for PS traffic is evaluated, according to the whole BSS load (CS and PS loads).
The amount of available basic nibbles for PS is related to the needed extra nibbles. The more basic nibbles for PS are available, the less extra nibbles are required. There are two different indicators, which are possible to represent PS traffic: MCS traffic GCH traffic Gathered Counters:
Counter Name MC380a P100c MC380b
Indicator Name GTCTRHT
Definition Time during which the TCH FR are busy Time during which the TCH HR are busy
GTCTRFT
GAAGCHUST GTRDTESUN GTRUTESUN GQRDTECBN GQRUTECBN GTRDTERQN GTRUTERQN GQRPDDRxN (x = 1,.. ,4)
P90a+P90b+P90c+ P90d+P90e+P90f+ P506
Cumulative time during which a GCH is busy in a cell. The counter is integrated over all the GCH available in the cell. Number of DL TBF establishment successes per cell Number of UL TBF establishment successes per cell Number of DL establishment failures due to congestion of Abis. Number of UL establishment failures due to congestion of Abis. Number of DL TBF establishment requests per cell. Number of UL TBF establishment requests per cell. In acknowledged mode, number of DL RLC data blocks (except RLC blocks containing LLC Dummy UI Commands only) on PDTCH encoded in CS-x (i.e CS-1 (P20a) CS-4 (P20d)) retransmitted due to unacknowledgement of the MS. In acknowledged mode, number of DL RLC data bytes encoded in all MCS-x (x = 1... 9) and retransmitted due to unacknowledgement of the MS.
P30a + P30b + P30c +P508 P105i
P105j P91a+P91b+P91c+ P91d+P91e+P91f+ + P505 P62a+P62b+P62c-P438c+P507 P20x (x = ad)
P20f+P20g+P20h+ P20i+P20j+...+P20n P21x (x = ad) P21f+P21g+P21h+ P21i+P21j++P21n
GQRPDDRMN GQRPDURxN (x = 1,.. ,4) GQRPDURMN
In acknowledged mode, number of UL RLC data blocks on PDTCH encoded in CS-x (i.e CS-1 (P21a) CS-4 (P21d)) retransmitted due to unacknowledgement of the MFS. In acknowledged mode, number of UL RLC data bytes encoded in all MCS-x (x = 1... 9) and retransmitted due to unacknowledgement of the MFS.
1
Alcatel File
3DF 01903 8010 VAZZA 01
March 04, 2008
62 / 154
Page
Counter Name P55x (x = a,.. ,m)
Indicator Name GTRPDDCxN (x = 1,.. ,4)
Definition 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). 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). Number of DL TBF establishment requests requesting 1 slot that are satisfied at once by the initial allocation.
P57x (x = a,.. ,m)
GTRPDDMyN (y = 1,.. ,9) GTRPDUCxN (x = 1,.. ,4)
P160 P162 P164 P161 P163 P165
GQRDTES1N GQRDTES3N GQRDTES5N GQRUTES1N GQRUTES3N GQRUTES5N
GTRPDUMyN (y = 1,.. ,9)
Number of DL TBF establishment requests requesting 2 or 3 slots which are satisfied at once by the initial allocation. Number of DL TBF establishment requests requesting 4 or 5 slots which are satisfied at once by the initial allocation. Number of UL TBF establishment requests requesting 1 slot which is satisfied at once by the initial allocation.
Number of UL TBF establishment requests requesting 2 or 3 slots which are satisfied at once by the initial allocation. Number of UL TBF establishment requests requesting 4 or 5 slots which are satisfied at once by the initial allocation.
Table 18: Counter list - Abis dimensioning Method 2.1
Measured Object: BTS 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 CS & PS traffic (i.e MC380a + MC380b + P100c) of the day.
Methodology:
INPUT
PS traffic (MCS or GCH) CS traffic Cell configuration: - Nb of Basic nibbles Parameters: - Min_PDCH - Max_PDCH_High_load - Max_PDCH
METHOD
OUTPUT
Abis Method
with Knapsack or with Knapsack + Erlang C
Nb of required extra Abis Nibbles
Figure 38: Abis dimensioning process Method 2

1
3DF 01903 8010 VAZZA 01
March 04, 2008
63 / 154
Page
The Abis method is specifically developed by using an iterative algorithm to calculate the needed number of extra nibbles.
With this algorithm, the number of extra and bonus nibbles is started at 0; for each value we calculate GoS of services in all cells and compare them to GoS requirement. Loops of the algorithm continue till GoS of all services are satisfied in all cells. The algorithm is shown in the following figure:
Nb extra and bonus = 0
Calculate GoS of all services in each cell
Compare calculated GoSs to required ones

False
Nb extra and bonus ++
GoS reached in all cell for all services?

True
Nb extra and bonus

Figure 39: Abis method algorithm
In addition, Abis method can be internally categorized into 2 different ways, depending on the representative indicators for PS traffic. PS traffic = MCS traffic Only Knapsack statistical law is applied in Abis method.
PS traffic = GCH traffic
Knapsack and Erlang C statistical laws are applied in Abis method.
Recommendation to apply this Abis method:
The method is complicated to apply manually, as it uses high level of mathematical formulas & statistical laws. Therefore, please contact Network Engineering service for related supports.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
64 / 154
Page
Comments on two methods for Abis dimensioning: Method 1: Simple application but limited accurate results
This method is simple by using only small number of counters and one statistical law required i.e. Erlang C, thus it is possible to apply the method manually without specific tool need.
However, the accuracy of this method should be limited as it considers on only extra & bonus nibble traffic not basic nibble.
Method 2: More accurate results but complicated application
This is advanced method to take into account CS & PS load by using several counters and statistical laws required i.e. Knapsack and Erlang C. So, this method should provide more accurate results for Abis dimensioning. However, a tool support is needed to apply the method due to its complexity (difficult to perform it manually).
These two methods should be used together in a complementary way in order to compute the optimized value for the N_EXTRA_ABIS_TS parameter. The recommended process is described hereafter:
For ALL BTS Extra & Bonus method yes MCS method
For each BTS Needing additional Resources according to Extra & Bonus method
Extra nibbles Needed ?
No
N_EXTRA_ABIS_TS=0 No
Extra nibbles Needed ? yes
Select minimumm between theoretically missing resources, according to the method described in 3.2.2.2, and the minimum between extra & bonus / MCS method results
Round up
/4
Figure 40: Abis dimensioning process
N_EXTRA_ABIS_TS
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
65 / 154
Page
3.3 BSC
Two generation of BSC are supported in B9: G2 BSC Mx BSC, also called A9130 BSC or BSC Evolution, relying on Advanced Telecom Computer Architecture (ATCA).
3.3.1 G2 BSC Configuration
The G2 BSC or A9120 BSC consists of 3 Terminal Sub-Units (TSU), responsible for specific functions, plus Group Switches realising the connections between TSUs connected to the BTSs and TSUs connected to the Transcoder or MFS.
Group Switch 8 Planes 2 Stages self-routing, non-blocking
6 E1
6x G.703 Abis I/F
Abis TSU
TCUC TCUC TCUC
Ater TSU
DTCC DTCC DTCC DTCC DTCC DTCC
2 E1
2x G.703 Ater muxed I/F
TCUC TCUC TCUC
ASMB
BIUA
TCUC TCUC
AS
AS
DTCC DTCC
ASMB
TSL
Q1 bus
AS
TSCA
CPRC CPRC CPRC CPRC CPRC CPRC CPRC CPRC
Broadcast bus
Common Functions TSU
Figure 41: G2 BSC (A9120 BSC) Architecture
From Figure 41, the BSC is basically divided in three building blocks:
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;
1) Abis TSU: For Abis interface management functions towards the Base Stations (BTS), see details in section 3.3.1.2
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
66 / 154
Page
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 42: G2 BSC Cabinet layout
In release B10, six types of G2 BSC configurations are offered:

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

Alcatel File Reference
N _ EXTRA _ ABIS _ TSallBTS 2

Date
3DF 01903 8010 VAZZA 01
March 04, 2008
Edition
1
67 / 154
Page
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 43: Abis TSU G2 BSC
1 BIUA: Base Station Interface Unit type A
BIUA is sub-multiplexing and cross-connect module, which provides six Abis PCM connections. Rules:
6 Abis connection of a BIUA can support the following Abis configuration: Maximum 3 Ring configurations Maximum 6 Chain/Star configurations
The primary and the secondary Abis links of a BTS can be on different TSUs (or BIUA) and also on different BSC racks.
All TRXs of all BTSs of a same Abis multidrop must be connected to a single Abis TSU.
8 TCUCs: Terminal Control Unit type C
The TCUC performs the telecommunication function and the O&M functions required to connect the BSC and the BTS. Rules:
Each TCUC can handle 6 LAPD signalling links LAPD (i.e. RSL, OML and TSL) that allows: 4 RSL+ 2 OML 3 RSL+ 3 OML
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
68 / 154
Page
For the TSL/TCU mapping is fixed as shown in next table:

TSL links G2 BSC TSL 1 (first rack) TSL 2 (second rack) TSL 3 (third rack) BIUA number (BSC-Adapt SBL nbr) 1 6 11 TCU number 1 41 81
Table 20: TSL/TCU Mapping
Each TCUC can handle 32 Traffic channels which allows: 4 Full Rate TRXs 2 Dual Rate TRXs 8 Extra Abis TSs (First Abis TSU of each rack can only support 14 DR TRXs) FR TCUC can handle a mix of FR & Extra Abis TS. DR TCUC does not support extra Abis. Each TCUC handle either Full Rate or Dual Rate traffic but not both.
Each TCUC can handle 32 SDCCH channels. However, in case of 16K Signalling Multiplexing (Static or Statistical 16kbps) each TRX can carry 8 SDCCH channels maximum.
Each TCUC will respect the rule CCCH (BCCH) TS +SDCCH TS <= 4 TS when mCCCH feature is enabled (one CCCH TS equal to one SDCCH TS in terms of signalling load). One TCUC shall not handle more than 2 BCCH in case of GPRS cell, this rule is a warning but the SW does not check it.
For 16K Static multiplexing, all RSLs of a given 64kbps Abis time-slot must be handled by the same TCUC. For Statistical Multiplexing, all multiplexed RSL and OML are processed on the same TCU.
Mix of the different signalling multiplexing and not multiplexed signalling on the same TCU is allowed for Full Rate.
2 AS: Access Switch
It allows TCUC to gain access to Group Switch. For more Abis TSU rules, please refer to [1]
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
69 / 154
Page
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 44: Ater TSU G2 BSC
DTC Rules:
Any of the first DTCs in each group of 4 supporting an AterMUX interface (among the 16 first Ater Mux) can terminate an SS7 signalling link if the Ater Mux is CS.
There are 6 potential BSC synchronization sources (one from each AterMUX in the first rack). If the AterMUX is used, then the first DTC attached to that ASMB recovers a synchronization reference signal and sends this to the BSC central clock. DTCC can be dedicated for SS7-MTP (supporting a physical SS7 link), GSL (supporting a physical GSL), BSSAP/GPRSAP (higher layers of SS7 and GSL) or TCHRM (TCH allocation) One DTCC TCH-RM pair can handle up to 60 cells and the number of TRX per TCH-RM is limited to 90.
For more Ater TSU rules, please refer to [1]
3.3.2 BSC Evolution Configuration
The architecture of Mx BSC (A9130) relies on the Advanced Telecom Computing Architecture (ATCA), re-using the same software as the G2 BSC. A virtual CPU approach has been developed: each control module (CCP or OMCP) supports several software processes corresponding to the TCUC, DTCC, TSCA or CPRC processor modules of the previous generation G2 BSC. The following figure shows the BSC Hardware (HW) architecture on an ATCA platform.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
70 / 154
Page
TPW
TPr
CCP1
MUXr MUXW
Radio Network links
SSWW SSW
E1
LIU1
CCPy
OMCPw
LIUn LIU Shelf
(21 slots)
OMCPr
ATCA Shelf (14 slots)
External Ethernet Links
r W n and y
: Redundancy : Working : Network Element Capacity
Figure 45: 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
Boards: four types of boards are defined:
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. CCP board: the Call Control Processing board, in charge of all the telecom functions of the BSC, except the TCH Resource Management. There are 1 to 5 active CCP board per BSC, i.e. per sub-rack, and 1 board for redundancy. Each CCP board can manage up to 200 TRX. OMCP board: the O&M Control Processing board, in charge of all the O&M functions of the BSC and TCH Resource Management. There are 2 OMCP boards per BSC, i.e. per subrack, including 1 for redundancy. SSW board: this board allows exchanges between all the elements of the platform and external IP/Ethernet equipment. It support IP Layer 3 functions and is based on Gigabit Ethernet. There are two SSW boards per shelf, 1 active and 1 for redundancy TP board: this board is in charge of the transmission processing functions of the BSC. It mainly processes the Abis timeslots and decides whether to send them back directly towards the LIU shelf (case of extra Abis timeslots, which explains why the extra Abis timeslots have no impact on the BSC Evolution) or towards one of the CCP boards.
LIU shelf: This module is in charge of the physical E1 connections, i.e. Abis, AterCS
and AterPS.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
71 / 154
Page
3.3.2.1 BSC Capacity

In release B10, five configurations of BSC Evolution are offered:
Configuration Nbr of CCP boards Nbr VTCU Nbr VDTC CS Nbr VDTC PS TRX Cells BTS Nbr of LIU boards Mx BSC 200 TRX 50 1 Mx BSC 400 TRX 100 48 8 80 2 Mx BSC 600 TRX 150 72 3 Mx BSC 800 TRX 200 96 4 Mx BSC 1000 TRX 250 5
24 8
40
120 14
160 15
192 112 16
200 200 150 96 10 900 6
400 400 255 96 20
600 500 176 18 30 255
800 500 176 24 255
1000 500 255
Abis links Ater CS Ater PS Erlang BHCA
Nbr Extra Abis TS SS7 (load @ 40%) SS7 (load @ 60%)
64 800 8 LSL 6 LSL 2000
129 600 16 LSL 11 LSL 2000
1800
12
40(*) 3600
48(*) 4500(**) 324 000 2000 HSL HSL 28
176
194 400 2000 HSL
2700
259 200 2000 HSL HSL
16 LSL
Table 21: BSC Evolution Capacity Note: (*) In B10 MR1, the number of Ater CS is limited to 36 interfaces. (**) In B10 MR1, a software limitation allows a capacity of 4000Erl and 288000 BHCA per BSC. It is recommended to limit the BSC load to 95% of its maximal capacity
Data in this table, based on [1] and [11]
The BSC capacity is defined with the FR TRXeq parameter that is defined by the formula:
TRX = FR _ TRXeq = FR _ TRX + 2 DR _ TRX
When the Optimized HR connectivity feature is enabled, the TRX calculation become:
TRX = FR _ TRX + DR _ TRX
Note: In Mx BSC, the HDLC channel (High Level Data Link) transports the signalling link (OML and/or RSL) of the BTS on a 64kbps Abis timeslot. One HDLC channel is used per LAPD link (if 16K Statistical Signaling Multiplexing or No Multiplexing mode is applied) or per group of multiplexed RSL and OML (i.e. when 16K Static or 64K Statistical Signaling Multiplexing mode is applied).
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
72 / 154
Page
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 2FR 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 allow a capacity of 1024 HDLC channels (984 channels are available for RSL and OML), but the same maximum of 481 HDLC is retained initially in order to guarantee transparent interoperability.
3.3.2.2 Delta BSC Evolution versus G2 BSC

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
Same Behaviors

No change in radio configuration mechanisms Same set of radio parameters
No change in logical model of the BSC
Same set of PM counters/indicators as A9120 BSC
For more details, please refer to [1]
3.3.2.3 CCP board

A CCP board contains several VTCUs and VDTC that corresponds respectively to TCU and DTC software.
Thanks to the TCU allocation Evolution feature, several constraints existing in G2 BSC are removed in A9130 BSC Evolution: all the VTCUs are managed as a pool where any Abis signalling TS allocation can be routed to any TCU across CCPs boards.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
73 / 154
Page
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 1100 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 remapbts-on-ccp command at the OMC-R to spread the load between the CCPs boards.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
74 / 154
Page
3.3.2.4 LIU shelf

The LIU shelf is in charge of the mapping of Abis towards Ater interface if the signal is not routed to a CCP board. The Abis/Ater allocation and mapping realized by LIU boards is fixed and it is shown in Figure 46.
1000 TRX 800 TRX 600 TRX 400 TRX 200 TRX LIU 1 LIU 2 LIU 3 LIU 4 LIU 5 LIU 6 LIU 7 1 17 33 49 65 81 97 2 18 34 50 66 82 98 3 19 35 51 67 83 99 4 20 36 52 68 84 100 5 21 37 53 69 85 101 6 22 38 54 70 86 102 7 23 39 55 71 87 103 8 24 40 56 72 88 104 9 25 41 57 73 89 105 10 26 42 58 74 90 106 11 27 43 59 75 91 107 12 28 44 60 76 92 108 13 29 45 61 77 93 109 14 30 46 62 78 94 110 15 31 47 63 79 95 111 16 32 48 64 80 96 112
Abis ports
Ater Ports
Abis ports (max 176) Ater CS (max 48): BSC Atermux numbers 1-30,59-76 Ater PS (max 28): BSC Atermux numbers 31-58
Figure 46: Abis and Ater allocation on LIU boards / BSC capacity
3.3.2.5 SS7 transport
For BSC Evolution there are two options for the SS7 transport in B10: LSL (Low Speed Links): SS7 channels on 16 * 64 kbps TS Available with BSC G2 and BSC Evolution
HSL (High Speed Links): SS7 channels on 2 * 2Mbps links (for redundancy purpose, the 2 links are required whatever the traffic is). If more than 16 SS7 channels are needed. Available only with BSC Evolution.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
75 / 154
Page
200
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
LIU 8 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128
LIU 9 LIU 10 129 145 130 145 131 147 132 148 133 149 134 150 135 151 136 152 137 153 138 154 139 155 140 156 141 157 142 158 143 159 144 160
LIU 11 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176
1000 TRX 800 TRX 600 TRX 400 TRX 200 TRX LIU 12 LIU 13 LIU 14 LIU 15 LIU 16 69 59 21 2 1 70 60 22 4 3 71 61 23 6 5 72 62 24 8 7 73 63 25 10 9 74 64 26 12 11 75 65 27 14 13 76 66 28 16 15 x 67 29 18 17 x 68 30 20 19 x 54 48 42 41 x 53 47 40 39 58 52 46 38 37 57 51 45 36 35 56 50 44 34 33 55 49 43 32 31
400
400
200
3.3.3 BSC Dimensioning
The BSC dimensioning is based on the configuration & connectivity aspect, not directly on the traffic counter analysis because the traffic analysis is already taken into account at the lower NE layer i.e BTS and Abis.
Thus, the main principle of BSC dimensioning is to define which BTSs together with their Abis are connected towards the BSC in accordance to the BSC configuration limitations and the BTS & transmission location constraints. The below diagram shows the BSC dimensioning process:
BTS inputs Location Configurations BSC inputs Software release Architecture Constraints Access transmissionNetwork topology
Available configurations BSC dimensioning process
Core transmission network topology
Definition Definition of of sets sets of of BTSs B TSs (BSC (BSC Ar Area ea) ) satisfying satisfying th the e archi architectur tecture e constraints constraints For SC For each each BSC BSC ar area, ea, choose choose a aB BSC configuration configuration Check SC border Check B BSC border with with RNP RNP team team OK OK ? ? No No
Check Check Abis Abis conn connectivity ectivity OK OK ? ? Yes Yes No No
Yes Yes
Yes Yes Choose Choose an an oth other er BSC BSC configura configuration, tion, if if possibl possible e? ?
No No
Check Check Ater Ater connectivity connectivity OK OK ? ? No No
Yes Yes
Outputs
BSC configurations BSC Areas
Figure 47: BSC dimensioning process
In Figure 47, basically the BSC dimensioning consists of two following parts: Parenting Abis TSU ports of the BSC
Design BSC area
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
76 / 154
Page
3.3.3.1 Design BSC area

As the design of BSC area is mainly based on the BTS and Transmission locations, it is recommended to perform this design by mean of a geographical program e.g. MapInfo or other equivalent programs. There are three steps to complete designing the BSC area: 1) Get BTS position & Configuration
The BTS positions are important to create a set of BTS as BSC area in the same geographical area. Moreover, the BTS configuration that includes:
Number of TRX per cell (Full rate and Dual Rate) Maximum number of extra TS defined by the O&M parameter N_EXTRA_ABIS_TS at BTS level Number of Abis links defined for this BTS (eventual use of 2nd Abis link) gives the TRX & Abis load that this BTS will have at BSC level.
Figure 48: BTS position & configuration design BSC area step 1
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
77 / 154
Page
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 49: 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 19).
It is recommended not to overcome 80% TRX load at G2 BSC level, to allow future network extensions.
Figure 50: BSC area definition design BSC area step 3
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
78 / 154
Page
3.3.3.2 Parenting Abis ports of the BSC

It consists of two following steps: 1) Transmission load checking

The number of Abis links used from one geographical location to another depends on:
Number of BTS in that location Number of Abis used per each BTS Eventual multidrops defined between several BTS (on the same location and/or on different ones) Number of E1
This number of Abis used between each geographical location has to be checked with the actual available number of E1 links, which will be implemented in the network. This task is usually performed by the Transmission team.
Figure 51: 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.4, 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.
1
3DF 01903 8010 VAZZA 01
March 04, 2008
79 / 154
Page
Figure 52: BTS / Abis parenting on BSC done by AMT.NET
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
80 / 154
Page
3.3.4 LA Dimensioning
Definition: A Location Area (LA) is the area in which a normal page for a particular mobile, registered in this LA, will be broadcasted. Too large LAs may lead to a too high paging load in the BTS resulting in congestion and lost pages. Smaller LAs reduce the paging load in the BTSs as well as in the BSCs. However, small LA also means a larger number of LA border cells. Each time a mobile crosses the boarder between two LAs, a location updating is performed. The LA update has an effect on the load on the signalling sub-channels, SDCCH, in the LA border cells.
Target: The aim of LA dimensioning is to define the appropriate size of a Location Area, which is mainly driven by the maximum number of paging the LA can handle, i.e. by the traffic seen on this Location Area.
Gathered Counters:
Counter Name MC8a Indicator Name GCCPGRQN Definition Number of Paging message seen on Abis interface (PCH usage).
Table 22: 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. There are 3 CCCH blocks per M51 frame for combined cells. Um interface Limitation 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.
1
3DF 01903 8010 VAZZA 01
March 04, 2008
81 / 154
Page
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 45,957 paging/hour
Recommended max paging per hour:
Recommended max paging per second: 12.76 paging/second
There are 9 CCCH blocks per 51 Multiframe for non-combined cells.
Um interface Limitation Non-combined cells
Among those 9 blocks, 9 minus BS_AG_BLK_RES are reserved for paging (BS_AG_BLK_RES = 4 as an usual default value for non-combined cells).
The calculation is similar to the one related to combined cell above. The only difference is a higher number of paging blocks per 51 Multiframe. Therefore; Available blocks for paging per hour: Maximum paging per hour:
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) Alcatel recommendation 114,893 paging/hour
When 60% engineering limit is applied
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
82 / 154
Page
There are 9 CCCH blocks per 51 Multiframe for each of the two timeslots for CCCH.
Um interface Limitation Cells with 2 CCCH (mCCCH feature activated)
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. Available blocks for paging per hour: Maximum paging per hour: 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) Alcatel recommendation 229,785 paging/hour
When 60% engineering limit is applied
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
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).
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 Maximum paging per hour: 237,600 paging/hour
G2 BSC Limitation
The BSC limit is 70 paging/sec on the A interface (Alcatel traffic model). Maximum paging per hour:
Alcatel File Reference
252,000 paging/hour
Date Edition
1
3DF 01903 8010 VAZZA 01
March 04, 2008
83 / 154
Page
Mx BSC Limitation
The BSC limit is 122 paging/sec on the A interface (Alcatel traffic model). Maximum paging per hour: 439,200 paging/hour
The paging on the A interface is the sum of the paging on all Location Area which are configured on a BSC. So it depends on the Paging rate on Location Area and on the number of Location Areas in a BSC.
Limitation Factor
The minimum value from those four limitations is therefore given by the Um interface, which is 45957 pagings/hour if aLA contains at least one combined cell, or is 114893 pagings/hour if the Location Area contains only non-combined cells (in case of G2 BSC). This conclusion holds true as long as there are max 5 LAs (resp. 9 LAs) covered by the G2 BSC (resp. Mx BSC), which should always be the case but it worst to mention it.
In case of non-combined cells, 2 LAs may be covered by one G2 BSC (252000/114893 = 2.19) and 4 LAs are required by one Mx BSC (439200/114893 = 3.9).
Assessment:
Below figure shows the LA dimensioning assessment (for G2 BSC).

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

1
3DF 01903 8010 VAZZA 01
March 04, 2008
84 / 154
Page
In Figure 53, the assessment is to perform checking measured paging traffic versus the paging limitation at the different levels:
BSC limitation Um limitation
It is not significant to check Abis limitation, because Um limitation is lower than the Abis one. Therefore, Um limitation is usually triggered first.
3.3.5 RA Dimensioning
A Routing Area (RA) is a sub-set of one LA and identifies one or several cells in a LA.
In case of a mobile terminating call in GSM, the MS in idle mode will be paged in all cells belonging to the LA, which the MS is present.
For PS services, the SGSN pages the MS in STANDBY state, in case of a downlink TBF. It means additional signalling effort (for GPRS/EDGE) will be produced in the network: at each DL TBF establishment the MS will be paged in the RA if the MS is in the GMM Standby state. Introducing RA, which should be smaller than LA, the signalling effort for paging is now more focused to a smaller area, the signalling load for the cells being reduced.
Figure 54: Subdivision of a LA in GPRS routing areas (RA)
Target: To estimate the number of RA per LA. Gathered Counters:
Counter Name P53a MC8a
Indicator Name GTRPCHPAN GCCPGRQN
Definition Number of (BSCGP) PAGING REQUEST for PS paging sent to the MS (through the BSC which manages the PCH resource). Number of Paging message seen on Abis interface (PCH usage).
Table 23: Counter list RA dimensioning
Note: the P53a (respectively MC8a) values for each cell in the same RA (respectively LA) should be identical. However sometimes it was observed (from the counter of live networks) that some cells in the same RA (respectively LA) have the different P53a (respectively MC8a) value for this case, the most frequency value will be chosen to be represented the paging traffic of the RA (respectively LA).
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
85 / 154
Page
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)
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.
Some general remarks apply:
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.

1
3DF 01903 8010 VAZZA 01
March 04, 2008
86 / 154
Page
If the measured GPRS paging load ratio is over the given limit, the re-design RA area (implying to have the smaller RA size) is triggered.
3.3.6 Summary of LA/RA dimensioning process
As master PDCH is not applicable, CS & PS pagings uses the same radio channel i.e. PCH, so LA and RA dimensioning should be performed together. Below is summary of LA/RA dimensioning process within G2 BSC:
2) Compute the paging load by MC8a / Max # pagings Whereas Max # pagings equals to: - 191,489 pagings/hour: for non-combined cells - 76,595 pagings/hour: for at least one combined cell in a LA 3) Assess whether any LA has the current paging load exceeding 60%. If not, it is OK => no LA/RA re-dimensioning required If yes, continue to 4) 4) Check GPRS paging load ratio = P53a / MC8a If this ratio is greater than 20%, the solution to reduce global paging load may be splitting RA into several RAs for a corresponding LA (one LA: several RA). If this ratio is low, the solution should be introducing a new LA/RA and/or LA/RA redimensioning. In addition, if there is any combined cell in a LA, it is recommended to change to non-combined cell in order to increase the Max # paging of the LA.
Note: P53a = PS paging while MC8a = total Paging (CS&PS).
1) Observe firstly only MC8a (CS + PS paging) @ Busy Hour for every LA.
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% Estimated Paging load of 1 LA with 3 RA = 43.8% + 18.8%/3 = 50.1% Estimated Paging load of 1 LA with 4 RA = 43.8% + 18.8%/4 = 48.5%
3DF 01903 8010 VAZZA 01
Alcatel File
Reference
March 04, 2008
Date
Edition
1
87 / 154
Page
3.3.7 CCCH dimensioning
With the introduction of mCCCH feature, the dimensioning of CCCH should be updated. In one hand, the number of messages (i.e. capacity) is deduced from the available AGCH and PCH blocks as detailed in LA dimensioning. In the other hand, the requested AGCH and PCH blocks are deduced from the number of messages per second.
The following table gives an indication about the offered capacity in terms of Paging and Immediate Assignment messages according to the number and configuration of CCCH TS.
Nb CCCH TS BS_AG_BLKS_RES PCH blocks 1 1 1 2 2 2 2 3 4 5 3 4 5 6 6 5 4 12 10 8 6 AGCH blocks Max paging/s Max assign/s at 60% load at 60% load 3 38 7 4 32 10 5 25 12 6 76 15 8 63 20 10 51 25 12 38 31
If not all cells in LAC are with mCCCH activated, the paging capacity is like in cells with single CCCH. However for AGCH, the capacity in cells with mCCCH should be greater. The needed number of PCH blocks is defined by Nb_Needed_PCH_Blocks, while the needed number of AGCH blocks is defined by BS_AG_BLKS_RES=N2. The need of a second CCCH is also related to the AGCH and PCH loads. When the nominal cell load is higher than 60%, a re-dimensioning of the CCCH channel is required or a second CCCH channel shall be allocated to that cell.
Counter Name (MC8B + MC8D) / (N2 * 3600 / 0.240) Indicator Name GCCIARQO GCCPGRQO Definition Load on AGCH logical channel(s) in case of fixed AGCH configuration
(MC8A / N4) / ((N3 N2) * 3600 / 0.240)
Load on PCH logical channel(s) in case of fixed AGCH configuration
N2 = 1 (combined mode) or 4 (non-combined mode) N3 = 3 (combined BCCH mode) or 9 (non-combined BCCH mode) N4 = average number of mobile identity sent within one PAGING REQUEST message: N4 = 3 if Paging is performed using TMSI N4 = 1.5 if Paging is performed using IMSI
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.
1
3DF 01903 8010 VAZZA 01
March 04, 2008
88 / 154
Page
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. then it is called AterMUX CS/PS.
It is possible to mix PS and CS traffic on one single AterMUX link, and
On the AterMUX CS interface, a 64kbps timeslot transmits information for 4 Circuit Switch calls (whatever they use FR or HR codec). On the AterMUX PS interface, a 64kbps timeslot supports 4 GCHs.
3.4.1.2 A interface
The A-interface is a set of 2Mbps PCM links carrying CS traffic between the TC and the MSC. One 64kbps channel on A interface is corresponding to one 16kbps channel on AterMUX.
3.4.1.3 AterMUX interface versus A interface
BSC
TC
MSC
AterMUX
Figure 55: AterMUX and A relationship
Since release B7.2, it is possible only 4:1 multiplexing at BSC side and 4:1 de-multiplexing at TC side. Therefore, the number of A-interface links is four times of the number of AterMUX CS interface links. That is: N AterMUX CS Links 4*N A Links
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
89 / 154
Page
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 CH# 1 CH# 2 CH# 3 CH# 4 TS 0 Transparency
TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH
TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Qmux
TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH
Alarm octet SS7
X25
Figure 56: AterMUX interface structure
TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
AterMUX PS CH# 1 CH# 2 CH# 3 CH# 4 TS 0 Transparency

GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH
GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH
Alarm octet SS7 (not used)

GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GSL GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH
In Figure 56, AterMUX consists of the following channels:
TS 0 transparency: used for frame synchronization Signalling Channels: 5 types of signalling
Traffic Channels: TCH in case of CS traffic but GCH for PS traffic

Qmux: In A9120 BSC, there is one sub-channel (on timeslot 14) on the first two Ater links (links N 1, 2, 7, 8, 13 & 14) that is dedicated to the Qmux protocol. Three other sub-channels are used for TCH. In A9130 BSC, there is one sub-channels (on timeslot 14) on the Ater links N1, 7, 13, 19, 25 and 2, 8, 14, 20, 26 that is dedicated to the Qmux protocol. The three other sub-channels are used for TCH. Alarm octet: reporting technical hitches on any DTC so it must be conveyed on each PCM of each Ater TSU. SS7:
carrying the signalling information about call control and mobility management between BSS and MSC. There are a maximum of 16 SS7 links. This TS is unused for AterMUX PS but cannot be used for GCH.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
90 / 154
Page
O&M: In A9120 BSC, two additional time slots (TS31 on Ater links n1 & 2) must be dedicated to O&M link from the BSC to the OMC-R if X.25 connection is used. In A9130 BSC, the O&M information is transported to the OMC, with IP over Ater, using the TS31 of the AterMUX 1 to N.
GSL: It handles signalling for GPRS paging and for all synchronization between the BSC and the MFS (TS 28). Each GP(U) requires at least one GSL channel (depending on the traffic), so there can be 0 or 1 GSL per AterMUX. For security reasons, it is recommended to have at least 2 GSL channels per GP(U).
3.4.2.1 AterMUX CS and A interfaces

AterMUX CS: Referring to AterMUX CS structure (in Figure 56), the following figure presents the AterMUX CS configurations that depend on the G2 BSC configuration.
A te r T S U 1 B SC R ack 1 A te r T S U 2 A te r T S U 3 P P P P P P P P P P P P P P P P P P CM CM CM CM CM CM CM CM CM CM CM CM CM CM CM CM CM CM 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 X 25 (x ) (x ) Qmux x x A la rm x x x x x x A la rm x x x x x x A la rm x x x x x x SS7 x x x x x x SS7 x x x x x x SS7 x x x x T o ta l T C H T C H N um b e r 111 111 116 116 116 116 115 115 116 116 116 116 115 115 116 116 116 116 20 7 4
X 25
A te r T S U 4 B SC R ack 2 A te r T S U 5 A te r T S U 6
Qmux x x
X 25
A te r T S U 7 B SC R ack 3 A te r T S U 8 A te r T S U 9
Qmux x x
Figure 57: AterMUX CS interface configuration G2 BSC
In Figure 57, the number of TCHs is different for each AterMUX link as it depends on the appearance of signalling channels.
Remark: with BSC configuration 6 Ater TSU 9 PCM 1 & 2 do not convey SS7 links; however, TS 16 is left unused and does not convey any traffic channels, so total TCH remains 116 not 120. For G2 BSC, the maximum number of AterMUX CS interfaces is summarized in below table.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
91 / 154
Page
G2 BSC Configuration 1 Configuration 2 Configuration 3 Configuration 4 Configuration 5 Configuration 6
Nb of Ater TSU 2 3 5 6 8 9
Max nb of AterMUX CS 4 6 10 12 16 18
Table 24: Max number of AterMUX CS interfaces G2 BSC
For BSC Evolution, the maximum number of AterMUX links for CS traffic (from BSC to TC) is 48 and are addressed by Ater-Hway-TP in the range [1-30] and [5976]. These links may be used for PS traffic also.
The channel mapping between AterMUX CS interface and A-interface is presented below:
A-interface:
TS 0 TS 1 TS 2 : : TS 14 TS 15 TS 16 TS 17 TS 18 : : TS 30 TS 31
AterMUX CS CH# 1 CH# 2 CH# 3 CH# 4 Frame Synchronization

TCH TCH TCH TCH TCH TCH TCH TCH : :
Qmux
TCH TCH
TCH
TCH TCH
Alarm octet SS7

: :
TCH
TCH
TCH TCH
TCH TCH
TCH
TCH
TS : 64 Kbits/sec Channel or Nibble : 16 Kbits/sec
X25
TCH
TCH
TS 0 TS 1 TS 2 TS 3 TS 4 TS 5 : : : : : : : TS 30 TS 31
A Interface
Frame Synchronization
CIC 1 CIC 2 CIC 3 CIC 4 CIC 5 : : : : : : : CIC 30 CIC 31
TS : 64 Kbits/sec
Figure 58: Channel mapping between AterMUX CS and A
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
92 / 154
Page
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 25 presents the maximum number of A-interfaces in case of G2 BSC.
Configuration 2 G2 BSC Configuration 1 Nb of Ater TSU 2 3 5 6 8 9
A 64kbps channel on A interface is known as CIC (Circuit Identification Code).
Max nb of AterMUX CS 4 6 10 12 16 18
Max nb of A 16 24 40 48 64 72
Configuration 6
Configuration 5
Configuration 3 Configuration 4
Table 25: Max number of A-interfaces G2 BSC
3.4.2.2 AterMUX PS
Referring to AterMUX PS structure (Figure 56), the following figure presents an example of AterMUX PS configuration for a GPU.
PCM 1 PCM 2 PCM 3 PCM 4 PCM 5 GSL x (x) Alarm x x x x x SS 7 x x x x x GCH Number 112 112 116 116 116 572
One GPU
Figure 59: AterMUX PS interface configuration - GPU
Total GCH
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 56
At least one GSL is required for a GP(U), but it is recommended to have 2 GSLs per GP(U) as the security reason is concerned Maximum 1 GSL is possible for an AterMUX PCM link (TS 28)
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
93 / 154
Page
For G2 BSC, the maximum number of AterMUX PS (BSC-MFS) is dependent on BSC configuration as shown in Table 26.
Configuration 1 Configuration 2 Configuration 3 Configuration 4 Configuration 5 Configuration 6 G2 BSC Max nb of AterMUX PS 4 6 10 12 16 18
Table 26: Max number of AterMUX PS G2 BSC
For BSC Evolution, the maximum number of AterMUX links dedicated for PS traffic (from BSC only to MFS) is 28 and they are addressed by Ater-Hway-TP from 31 to 58.
3.4.2.3 AterMUX CS/PS

The following information describes GPRS and GSM traffic on the AterMUX of the BSS . Sharing AterMUX PCM Links
TC Y BSC X GPU (MFS) SGSN
Figure 60: Sharing AterMUX links
From Figure 60:
- Y is the number of AterMUX between GP(U) and TC. - Z is the number of Gb between GP(U) and SGSN.
- X is the number of AterMUX between BSC and GP(U).
Rule of sharing AterMUX Link: 1) X+Y+Z <= Maximum nb of E1 links 2) When the AterMUX transports mixed traffic: X=Y
1
3DF 01903 8010 VAZZA 01
March 04, 2008
94 / 154
Page
The maximum number of E1 links depends on the BSC/MFS platform and can be summarised in the following way:
For Mx MFS: 10/12/14/16 E1 links depending on the configuration. For more details, please refer to section 3.6.2.1. For legacy MFS: 16 E1 links
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 27.
CS Full 7/8 3/4 1/2 1/4 Null Nb of TCH 116 100 84 56 28 0 PS Null 1/8 1/4 1/2 3/4 Full Nb of GCH 0 16 32 60 88 116
Table 27: Ratio of Mixing CS and PS Traffic in AterMUX
The Figure 61 presents details of Timeslot sharing between CS (TCH) and PS (GCH):
PS Traffic Ratio TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS TS AterMUX CS/PS / / / / TS Transparency
TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH
Full
TCH TCH TCH TCH TCH TCH TCH
GCH GCH GCH GCH GCH GCH GCH
TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH GCH GCH GCH GCH
TCH TCH TCH TCH TCH TCH TCH GCH GCH GCH GCH GCH GCH GCH GCH
Alarm octet SS
GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH GCH
Figure 61: AterMUX CS/PS Timeslot configuration
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
95 / 154
Page
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 56. 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. The BSC checks that these two AterMUX:
Do not carry Qmux (AterMUX 1 and 2, AterMUX 7 and 8) Do not carry IP over Ater 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
In this case, only 46 PCM will be allocated to AterMUX CS links.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
96 / 154
Page
In order to avoid excessive SS7 dimensioning, the number of BSS using HSL on a TC is limited to 4 Mx BSC. The choice of the signalling mode is based on the number of required SS7 64kbps channels. The dimensioning of the SS7 channels depends on the Operator traffic mix.
3.4.3.2 SS7 Dimensioning

The SS7 load depends on the BHCA and other call mix parameters. The SS7 links are traditionally dimensioned with 40% load (i.e. 0,4Erlang per signalling channel). The SS7 load estimation on A-interface is depending on capacity and call mix parameters. The following table indicates the required number of bytes per SS7 (event) messages.
S cenario MOC MT C IHO E HO LU S MS -MO S MS -MT P aging R etry T o MS C 352 341 38 183 203 0 254 0 F rom MS C 290 413 0 182 211 223 413 0
Figure 62: SS7 message length (in bytes) according to GSM event
With the total bytes for one call attempt from previous table and given BHCA, it is possible to estimate the SS7 required throughput and corresponding number of SS7 links needed. Required SS7 throughput (kbps) = BHCA /3600 x Total bytes for one call Attempt * 8/1000 The required SS7 throughput is estimated in the MSC to BSS direction (worst case, because of paging load).
BSC type (*) BSC-EV-200 BSC-EV-400 BSC-EV-600 BSC-EV-800 BSC-EV-1000 BHCA (**) 64 800 129 600 194 400 259 200 324 000 Nb of SS7 links at 40% load 8 16 HSL HSL HSL Nb of SS7 links at 60% load 6 11 16 HSL HSL
(**) The BHCA corresponds to B10-MR2 capacity. For MR1, the BHCA is limited to 288 000.
If the resulting number of links is above 16, then SS7 on 2Mbps link (HSL) is required.
So dimensioning SS7 links at 60% load is allowed with the Alcatel-Lucent BSS, if the MSC can also allow it. This SS7 signalling load is possible as soon as there is a minimum of four N7 links configured.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
97 / 154
Page
Target: To estimate the number of AterMUX-CS links per BSC based on signaling traffic. Gathered Counters:
Counter Name MC400 MC390 MC01+MC02 MC10 MC380a+MC380b Indicator Name GSDTRT GSDAHCAN GSDNASUN GSDHOSUN GTCTRT Definition Cumulated time during which the SDCCH sub-channels belonging to the related static or dynamic SDCCH timeslots are busy. Number of SDCCH seizures.
Total number of SDCCH successfully seized by mobile for any purpose (Originating or Terminating procedure): Establish Indication received.
Total number of SDCCH successfully seized by mobile for handover: Handover complete or Assignment complete received. Time during which the TCH are busy
Table 28: Counter list AterMUX-CS dimensioning
Methodology: INPUT
The SS7 traffic is related to the SCCP traffic generated by Call and Signalling treatments as detailed in the Method paragraph.
Re quired _ SCCP _ traffic = Measured _ SCCP _ traffic + 15%m arg in
Where:
Measured _ SCCP _ traffic =

=
TS
( MC 400 / MC 390 ) * ( MC 01 + MC 02 + MC10 ) + ( MC 380a + MC 380b )

TS
3600
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)
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
98 / 154
Page
RNO traffic measurements
Number of occupied Channels
Peak traffic Exact Busy hour
Time (H)
8H00 9H00 10H00 11H00 12H00 13H00 14H00
Figure 63: Difference between Exact busy hour, NPO busy hour and Peak traffic
The second input is the Grade of Service (GoS), which is defined by the required SS7 congestion rate (pSS7). Normally GoS should be given or agreed by the Mobile Operator. GoS: Required blocking probability pSS7 The typical maximum blocking rate at AterMUX interface is 0.1%. METHOD
The dimensioning of SS7 links in the Alcatel BSS is linked to three issues:
SCCP traffic Processor load
Physical link load
This section will explain here the SCCP traffic issue without going in the detailed of processor load and physical link load. For each scenario, a dedicated SCCP connection is open between the BSS and the MSC, for the duration of the scenario. It will carry all the signalling pertaining to that scenario. Therefore, there is one SCCP connection open for SDCCH and TCH request:
Speech calls, for a duration approximately equal to the SDCCH + TCH holding time
External handover, for a duration equal to the overlap time, during which the TCH resources in the old and the new BSC are simultaneously activated Location updates, for a duration approximately equal to the SDCCH holding time SMS and other services, for a duration approximately equal to SDCCH holding time
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
99 / 154
Page
For SDCCH duration, only real access onto SDCCH (C01, C02 and C10 counters) must be taken into account because the only ones leading to SCCP connection opening. The TCH traffic is the main traffic that generates SCCP connections on the SS7 links. The cause distribution of SCCP traffic is dependent on the Call mix of the monitored network.
So, the SS7 dimensioning will define the number of required SS7 links according to the measured SCCP traffic at BSC level. Below is the important configuration rule to be concerned for SS7 dimensioning. Since B7.2,
The Alcatel BSCs provide 256 SCCP connections per SS7 link.
According to ITU-T Recommendations a maximum load of 40% must be accepted on a SS7 link: 103 SCCP connections can be supported per SS7 link There is one SS7 link per AterMUX CS link.
As SS7 is associated to signalling CS traffic only, Erlang B can be applied to calculate the required number of SCCP connections according to the required SCCP traffic (SCCP_connection_erlang) and the target congestion rate. OUTPUT Number of required SCCP Channels/Connections: = Erlang B (Required_SCCP_traffic, pSS7)
Number of required SS7 Links:
This can be derived from the total number of required SCCP connections, as we know that 103 SCCP connections are available for one SS7 link. That is;
Nb _ required _ SCCP _ Connections Nb _ required _ SS 7 _ links = 103
Number of required AterMUX-CS Links (1) = Number of required SS7 Links
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).
For example:
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
100 / 154
Page
3.4.4 AterMUX Dimensioning
The purpose of the dimensioning is to define the number of required AterMUX links based on the measured traffic.
According to previous sections, there are 3 types of AterMUX interfaces i.e. one dedicated for CS traffic, one dedicated for PS traffic, and the last one with mixed (CS&PS) traffic. The different dimensioning methods for each AterMUX type are presented in the following sub-sections.
3.4.4.1 AterMUX CS
Target: To estimate the number of AterMUX-CS links per BSC. Gathered Counters:
Counter Name MC380a MC380b Indicator Name GTCTRHT Definition
GTCTRFT
Time during which the TCH FR are busy
Table 29: Counter list AterMUX-CS dimensioning
Time during which the TCH HR are busy
Measured Object: BSC Gathering periods: 7-day Busy Hour data, recommended Otherwise, at least 2 working-day Busy Hour data
Note: 2 Busy Hours will be defined: Busy Hour is the hour gives the highest TCH traffic (i.e. MC380a+MC380b) of the day. Busy Hour is the hour gives the highest SDCCH traffic (i.e. MC400) of the day.
Methodology:
The process of AterMUX-CS dimensioning is presented below.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
101 / 154
Page
INPUT
Signalling Traffic Required SDCCH Traffic GoS: % SS7 blocking User Traffic Required TCH Traffic GoS: % TCH blocking
METHOD
OUTPUT
Erlang B
Nb of required SS7 per BSC
Nb of required AterMUX-CS links per BSC Final nb of required AterMUX-CS links per BSC
Choose Max value
Erlang B
Nb of required TCH per BSC
Nb of required AterMUX-CS links per BSC
Figure 64: AterMUX-CS dimensioning process
From Figure 64, the AterMUX-CS dimensioning is based on 2 different kinds of traffic i.e. signalling & user traffic.
After applying the methods, each of traffic may need the different number of AterMUX-CS link, and then the final number of required AterMUX-CS link will be the maximum number. Signalling traffic
The SS7 traffic is partially related to traffic generated by CS Call as detailed in the previous paragraph. In LSL mode, each SS7 link is carried by an AterMUX-CS interface. In this case: Number of required AterMUX-CS Links (1) = Number of required SS7 Links
As an example, if the total number of required SS7 links of one BSC is 10 links, the number of needed AterMUX-CS will be equal to 10 links. For SS7 link definition, please refer to SS7 dimensioning and HSL mode User traffic INPUT The required TCH traffic is computed as below formula.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
102 / 154
Page
Re quired _ TCH _ traffic = Measured _ TCH _ traffic + 15%m arg in

Where:
Measured _ TCH _ traffic =
Note: a 15% margin is added to the required traffic - see more explanation in 3.4.3.2
MC 380a + MC 380b 3600
The other input is Grade of Service (GoS), which is defined by the required AterMUX-CS congestion rate (pAterMuxCS). Normally GoS should be given or agreed by the Mobile Operator. Required blocking probability pAterMuxCS The typical maximum blocking rate at AterMUX-CS interface is 0.1%.
METHOD
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
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.
Number of required TCH:
= Erlang B (Required_TCH_traffic, pAterMuxCS)
Number of required AterMUX CS Links (2):
This can be derived from comparing the total number of AterMUX CS channels (TCH) with AterMUX CS link capacity, which is shown in Figure 57. 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 57, 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)
1
Alcatel File
3DF 01903 8010 VAZZA 01
March 04, 2008
103 / 154
Page
= 1264 TCHs > 1200 TCHs Then, = Max (Required AterMUX CS Links (1), Required AterMUX CS Links (2)) Final number of required AterMUX CS Links:
3.4.4.1.1 A Dimensioning According to Figure 58, basically the number of required A-interfaces depends on the number of AterMUX-CS links connected to the Transcoder as following relation: Number of required A Links = Number of required AterMUX CS links * 4 In this case if there is 40 AterMUX CS links needed at TC level, then the number 160 Ainterface links (40*4) are required from TC to MSC.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
104 / 154
Page
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 User traffic are described in section 3.6.3
1. At which network element level it is applied
The dimensioning methods for Signalling traffic are described in section 3.4.4.2.2
Section 3.4.4.2.1 presents a global view on the AterMux-PS dimensioning process:

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) 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
AND
N.B. If, running the dimensioning assessment method, more than 1 GP(U) board are identified as underdimensioned (i.e. they are not able to handle the required traffic) the adding of GP(U) boards will be done in an iterative way (1 GP(U) at once) monitoring the consequent impact on the AterMux PS interface.
In Figure 65 the process for AterMux PS dimensioning that must be applied at BSC level, is presented:
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
105 / 154
Page
AterMux dimensioning Assessment for GSL traffic

# Needed GSL links
AterMux dimensioning Assessment for user traffic

# Needed GCH
GPU/GP dimensioning Assessment
# AterMux PS
Aterlink GCH_Capacity
# AterMux PS per GPU (GSL traffic)
max
# AterMux PS per GPU (user traffic)
2 (for security reason) # GPU/GP
(at least 2 per GPU/GP)
# GSL links
Figure 65 AterMux-PS dimensioning process at BSC level
# AterMux PS per GPU/GP
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 66:
# Needed GSL links
AterMux dimensioning Assessment for user traffic

# Needed GCH
GPU/GP dimensioning Assessment

If #GPU/GP=1
If #GPU/GP>1 then 1 GPU/GP must be added and the #AterMux PS per GPU/GP (for all Aterlink GPU/GPs) GCH_Capacity must be estimated as: New #GPU/GP at BSC level # Needed GSL links at BSC level # AterMux PS at BSC level
# AterMux PS
max
(at least 2 per GPU/GP)
# GSL links
# AterMux PS per GPU (estimated at BSC level)
max
Figure 66 AterMux-PS dimensioning process at GP(U) level
If, applying the dimensioning method at one GP(U), the result is that one (01) board is enough in order to support the required traffic; the number of needed AterMux PS links for this GP(U) will be assessed. Otherwise, if the board is overloaded, it is recommended to add one additional GP(U) board and the number of AterMux PS links per GP(U) will be re-assessed at BSC level.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
106 / 154
Page
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
GPU2
#Needed GCH GPU1 = 200 #Needed GP(U) = 1 #AterMux PS per GP(U) = Max (200 / 112, 3) = 3 #Needed GCH GPU2 = 300 #Needed GP(U) = 1 #AterMux PS per GP(U) = Max ( 300 / 112, 3) = 3
1. 2.
Reshuffle operation is done in order to try to balance traffic between the two GPUs Add 1 AterMux PS links on both GPUs
Example 2
BSC level (2 GP(U) with 2 AterMux links per GP(U)): #Needed GCH = 400 #Needed GP(U) = 2 #AterMux PS per BSC = 400/112 = 4 #AterMux PS per GP(U) = 4 / 2 = 2 GP(U) level GPU1
GPU2
#Needed GCH GPU1 = 160 #Needed GP(U) = 1 #AterMux PS per GP(U) = Max (160 / 112, 2) = 2 #Needed GCH GPU2 = 240 #Needed GP(U) = 1 #AterMux PS per GP(U) = Max (240 / 112, 2) = 3
1. Reshuffle operation is done in order to try to balance traffic between the two GPUs 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 #AterMux PS per GP(U) = 5 / 2 = 3
1
3DF 01903 8010 VAZZA 01
March 04, 2008
107 / 154
Page
GP(U) level GPU1
GPU2
#Needed GCH GPU1 = 200 #Needed GP(U) = 1 #AterMux PS per GP(U) = Max (200 / 112, 3) = 3 #Needed GCH GPU2 = 300 #Needed GP(U) = 2
1. 2.
Reshuffle operation is done in order to try to balance traffic between the two GPUs If Reshuffle has not the wanted effect: #Needed GCH at BSC = 500 #Needed GP(U) = 3 #AterMux PS per BSC = 500 / 112 = 5 #AterMux PS per GP(U) = 5 / 3 = 2
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
(for security reason)
max
# GSL links
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
108 / 154
Page
3.4.4.2.2.1 GSL dimensioning method based on bandwidth
Gathered Counters:
Counter Name P41 P42 GTALAPDLN GTALAPULN Indicator Name Definition Number of kilobytes sent to the BSC on the LapD link.
Table 30: Counter list GSL dimensioning
Number of kilobytes received from the BSC on the LapD link.
Measured Object: LAPD 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 signalling traffic i.e. max (P41, P42) of the day.
Methodology:
Calculate GSL (signalling) traffic for each AterMUX-PS link
Measured _ GSL _ traffic =
Max( P 41, P 42) Erlang 28800
Note: 1 Erlang = [Gb TS speed (64kbps) * 3600] / 8 =28800 Kbytes.
Estimate capacity of one GSL per AterMUX-PS link = 0.42 Erlang
Note: 0.42 Erlang is derived by applying reverse-Erlang C law of 4*16kbps channel (equivalent to 1 GSL 64kbps channel) with GoS 99.9% quantile 0 delay second.
Calculate GSL load GSL _ load =
Measured _ GSL _ traffic 100% GSL _ Capacity (= 0.42 Erlangs )
GSL load on a given GP(U) should not exceed 80%
It is recommended to increase the number of GSL per GP(U) if GSL load is greater than 80% (up to 4 GSLs can be defined per GP(U)) The number of GSL equals to the number of AterMUX-PS link, as only one GSL can be defined per AterMUX-PS link. At least two GSLs are recommended to be defined per GP(U) due to security reason. Up to 18 GSL (resp. 24 GSL) links can be defined on G2 BSC (resp. Mx BSC).
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
109 / 154
Page
3.4.4.2.2.2 GSL dimensioning method based on the number of treated messages
The goal of this dimensioning method is to compute the number of needed GSL links depending on the number of messages to be treated per second on GSL interface in the direction MFS to BSC (being the opposite direction less critical). The messages to be sent on GSL are queued in a buffer having a maximum dimension provided by the parameter K_GSL (MFS) and they are kept in the buffer during the time needed in order to receive the message acknowledgement reception by BSC. Therefore one message will be kept in the queue during the round trip delay of MFS-BSC interface.
The method can be run both at BSC and GP(U) level but, in case of specific assessment focus only on GSL interface, it is recommended to apply the method at GP(U) level.
GSL_round_trip_delay
GPU
K_GSL
GSL messages buffer A message is kept in the buffer during GSL_round_trip_delay
BSC
Gathered Counters:
Counter Name P62a + P62b + P62c - P438c + P507 GTRUTERQN GTRDTERQN Indicator Name Definition Number of UL TBF establishment -requests per cell. Number of DL TBF establishment -requests
P91a + P91b + P91c + P91d + P91e + P91f + P505 P30a + P30b + P30c + P508 P90a + P90b + P90c + P90d + P90e + P90f + P506 P62b P160 P383a P391a
GTRUTESUN GTRDTESUN
Number of UL TBF establishment -successes (seized by the mobile). Number of DL TBF establishment -successes (seized by the mobile)
GTRUTRV5N GQRDTES1N GQAGALCTT GTRPCHPAGPN GTRPCHCIGPN
Number of UL TBF establishment requests per cell (seized by the mobile) when MS is in packet transfer mode DL.
Number of DL TBF establishment requests requesting 1 slot, which are satisfied.
Time during which AterMux interface (GICs) for this GPU is congested (at least one PDCH group impacted). Number of PS paging requests processed by the GPU. Number of CS paging requests processed by the GPU.
P391b
Table 31: Counter list GSL dimensioning
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
110 / 154
Page
Measured Object: Cell (consolidated at BSC or GP(U) level) / GPU Gathering periods: 7-day hourly data, recommended Otherwise, at least 2 working-day hourly data
Note: Busy Hour is computed as the hour with the highest number of GSL messages of the day.
Methodology:
START Retrieve indicators and Cells GPUs mapping (if method applied to 1 GPU/GP) QoS acceptable ?* [1] Yes GSL traffic condition Calculation [2] #GSL msgs/sec due to PS traffic calculation [3] Calculation
Retrieve data on a different Period or on an updated (*) QoS evaluation to be done by QoS expert
configuration with better QoS*
PS Traffic data CHECK
(i.e. UL TBF estab success rate > 80%)
No
OR
Select hours with acceptable QoS * (i.e. for 90% of cells) Compare PS traffic in the selected hours with traffic observed on a similar BSC (reference BSC) Estimate PS traffic at busy hours on the basis of the reference BSC (through a simple proportion based on the respective number of cells)
# GSL links
#GSL msg/sec due to RAE4 traffic calculation [3] 75% x GSL_Link_Max_Capacity [4] If the method is applied at BSC level, the total capacity (for all GPU/GP) must be kept
[1] QoS Acceptable ? Since the method uses the number of TBF establishment requests, the
[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.
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.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
111 / 154
Page
Ater congestion observed
[3] #GSL messages/sec calculation

1) Msg on GSL due to RAE4 mechanism 2) Msg on GSL due to PS traffic:
(e.g. ACK of FTP DL transfer)
[4] GSL_Link_Max_Capacity. In order to compute the GSL interface capacity, the following formulas apply:
In case of AterMux on terrestrial links:
K_GSL * (1000ms/GSL_round_trip_delay) * number of configured GSL links per GP(U) if GSL_round_trip_delay < 500ms (default value for GSL_round_trip_delay is 60ms)

Nb of Msg on GSL High 3.5 2.5 Available GCH High Low
PS traffic (TBF req) Low 5 3.5
#TBF request/sec < 20
Figure 67 GSL usage factor
0.3 Msg/sec x Nb_cell
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 UL TBF without sig on GSL
1.7 x Nb_TBF_Sig_req/sec 0 x Nb_UL_TBF_req_noGSL/sec
TBF (UL & DL) corresponding to PS data (3 cases) Low GSL usage (eg. Ping 5 sec) Medium GSL usage High GSL usage (worst case)
2.5 3.5 5 x Nb_TBF_Data_req/sec
Nb GSL messages/s
In case of AterMux on satellite links:
K_GSL * (1000ms/GSL_round_trip_delay) * * number of configured GSL links per GP(U) if GSL_round_trip_delay >= 500ms (default value for GSL_round_trip_delay is 500ms)
N.B. The factor is due to FR 3BKA20FBR202481 that should be corrected in B10 release.
If the GSL link capacity is computed at BSC level the capacity of all GP(U) must be summed.
1
3DF 01903 8010 VAZZA 01
March 04, 2008
112 / 154
Page
Calculate GSL load (in terms of treated messages) The computation of Nb_GSL_messages_per_sec and GSL_Link_Max_Capacity is detailed in the previous Methodology description.
GSL _ load =
Nb _ GSL _ messages _ per sec 100% GSL _ Link _ Max _ Capacity
GSL load in terms of treated messages per second on a given GP(U) should not exceed 75% It is recommended to increase the number of GSL per GP(U) if GSL load is greater than 75%.
3.4.4.2.3 GCH/AterMUX-PS Dimensioning Target: To estimate the number of AterMUX-PS links needed per GP(U), according to user traffic.
The main principle is to have roughly same number of AterMUX-PS links per GP(U) (at least 2 links per GP(U)) for all the GP(U) connected to the same BSC.
N.B. This will not assure a balanced load distribution among the GP(U) boards connected to the BSC, because the AterMux interface capacity is not directly taken into account in the cell distribution criteria in MFS.
For more details on cell mapping on GP(U) boards, please refer to [15]. In order to estimate the number of AterMux-PS links per GP(U), analyzing the whole BSC, two main data must be estimated:
Number of required GCH per BSC Number of required GP(U) per BSC
Please find details on the method allowing to estimate the number of GCH (per BSC or per GPU) in the section 3.6.3.1 and 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 59 and also refer to section 3.4.4.2.2 GSL dimensioning.
Number of AterMUX-PS links per GP(U) (based on user traffic) =
Number of AterMUX-PS links per BSC / Number of required GP(U) per BSC
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
113 / 154
Page
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
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
Number of required GCH per BSC = 330 Number of required GP(U) per BSC = 2 Number of required GSL per GP(U) = 2
= Max (Number of required GSL per GP(U), Number of AterMUX-PS links per GP(U) based on user traffic, 2) = Max (2, 2, 2) = 2 links
Assessment:
AterMUX-PS re-dimensioning is required when:
GSL load in terms of bandwidth is exceeding 80%.
GSL load in terms of number of treated messages per second is exceeding 75%. GP(U) Ater time congestion rate exceeding 0.1 % can be observed regularly. GP(U) re-dimensioning is performed.
Warning:
It could happen that, because of unbalanced traffic distribution among the GP(U) boards connected to one BSC, one GP(U) board is more loaded than others.
This can be discovered applying the AterMux-PS dimensioning process at GP(U) level. Some examples are provided in 3.4.4.2.1.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
114 / 154
Page
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 GCH per BSC taken from GP(U) dimensioning Example of AterMUX-CS/PS dimensioning: If
Number of required TCH per BSC taken from AterMUX-CS dimensioning
Number of required TCH per BSC = 250 TCHs Number of required GCH per BSC = 50 GCHs
Then
Note: From Figure 57, the total capacity of AterMUX-CS links is: 111TCH(link#1) + 111TCH(link#2) = 222 TCHs So, 250 222 = 28 TCHs are remaining
From 250 TCH, 222 TCHs can be fit into 2 AterMUX-CS links
But 28 remaining TCHs and 50 GCHs can be fit into 1 AterMUX-CS/PS links with 50% sharing, see Table 27 Therefore, based on this example, we need 2 AterMUX-CS links and 1 AterMUXCS/PS links. Remark: the minimum usage of mixed AterMUX CS/PS is recommended.
Assessment:
AterMUX-CS/PS re-dimensioning is required when: The increase of TCH traffic GP(U) Ater time congestion rate exceeding 0.1 % can be observed regularly. GP(U) re-dimensioning is performed.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
115 / 154
Page
3.5 TC
There are two transcoder (TC) generations supported in B10, called G2 TC and G2.5 TC. The main architecture of transcoder is the Sub-Unit (TCSU), which is compounded by:
One Sub-Multiplexing Unit (SMU) One or more Transcoding Units (TRCU)
In the case of G2.5 TC, these units are combined on one single board, the MT120, offering an AterMUX connection to a BSC and up to 4 A-trunk connections to the MSC.
The MT120 can also be installed in the place of the ASMC in the G2 TC, and replaces 1 ASMC, 4 ATBX and 8 DT16 boards.
Local Qmux
ASMC
ATBX TSC
DT16 DT16 Ater interfaces
BSC
MT120 +FAN
TC bus
MSC
ASMC MT120 or +FAN MT120

Ater-mux interfaces
Figure 68: TC G2 architecture with mixed configuration
A interfaces
Here after summary of technical data overall generation transcoder.

Rack AterMux per rack A interfaces CIC SMU TRCU G2 TC Up to 3 6 24 24*29 ASMC ATBX DT16
G2.5 TC 1 48 192 192 *29 MT120
Table 32: G2 TC/ G2.5 TC capabilities
Data in this table, based on [1] and [9]
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
116 / 154
Page
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.
TC G2 TC SU ASMC TRCU SM 4:1 MT120 Configuration Min 2 AterMux 2 2 4 Max 6 AterMux 6 6 24 4 Extension / Reduction Min 1 AterMux 1 1 4 1 Physical Logical 1 AterMux 1 1 4 1
Table 33: G2 TC configuration
3.5.2 G2.5 TC Configuration
The G2.5 TC (or A9125 Compact TC) can be equipped with up to 48 sub-units (referred to as MT120 boards).
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.
G2.5 TC MT120 Configuration per Rack (AterMux) Min Max 2 48 Extension / Reduction step Physical Logical Min 1 1
Table 34: G2.5 TC configuration
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
117 / 154
Page
And, the capacity in terms of MT120 boards is summed up in Table 35.

Max MT120modules Configuration 1 subrack 12 2 subracks 24 3 subracks 36 4 subracks 48
Table 35: G2.5 TC capacity
Rules:
Each BSC must be connected to at least two MT120 boards for redundancy purposes, refer to Table 34. 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.3 TC Dimensioning
The TC dimensioning is based on the connectivity aspect rather than counter (or traffic) point of view. The concerned connectivity is the total number of required AterMUX CS links coming from all BSCs toward to the TC.
Also, the used TC type (either G2 TC or G2.5 TC) has to be taken into account because each type provides different configuration and capacity. The below figure presents the process of TC dimensioning.
# AterMUX CS links from BSC1 # AterMUX CS links from BSC2
: : : : : :
Total links
Used TC type (G2 TC or G2.5 TC)
Needed TC Configuration (Nb of boards)
# AterMUX CS links from BSCn Figure 69: TC dimensioning process
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
118 / 154
Page
For example;
If a small network consists of 4 BSCs with following required AterMUX CS links; BSCa: 10 AterMUX CS links BSCc: 6 AterMUX CS links BSCb: 12 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. BSCa needs 10 MT120 boards BSCc needs 6 MT120 boards Therefore,
BSCb needs 12 MT120 boards BSCd needs 8 MT120 boards
Total = 36 MT 120 boards
As 36 MT120 boards are needed, this required one G2.5 TC with 3 subracks refer to Table 35.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
119 / 154
Page
3.6 MFS
The MFS provides resource and equipment management facilities for the packet-switched system (GPRS) in the BSS. It has 2 main functions: the PCU function and Gb interface management. Each MFS can support multiple BSCs, and can be connected to several SGSNs. Several MFSs can be connected to the same OMC-R. Two generations of MFS are supported in B10:
The 1st MFS generation or A9135 MFS MFS Evolution or A9130 MFS
3.6.1 The 1st MFS generation (A9135 MFS)
It was introduced on the market in year 2000 together with the first GPRS release of Alcatel (release B6). The following figure presents A9135 MFS architecture.
Figure 70: The 1st MFS generation (A9135 MFS) Architecture
The A9135 MFS comprises 3 sub-systems:

Control Sub-System (CSS): built from 2 DECAlpha AS800 or COMPAQ DS10 servers, one of which is active and one of which is standby, referred to as the Control Station Telecom Sub-System (TSS): a set of GPU and JBETI boards Hub subsystem: consists of duplicated 100Mbps Ethernet networks for interconnection.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
120 / 154
Page
3.6.1.1 GPRS Processing Unit (GPU)

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

In order to increase the GPRS capacity of the BSS in terms of the number of PDCH, it is possible to connect several GPUs boards to the BSC to support the PCU function. The GPUs linked to same BSS do not need to be in same MFS subrack. Cell Mapping means that a cell is associated with a GPU. The mapping of cells onto GPU is performed by the MFS control station, which defines the mapping of cells onto LXPU (logical GPU, which represent either the primary GPU, or the spare GPU in the case of a switchover). All the GPRS traffic of one cell is handled by one, and only one GPU. The following figure shows the BSC connection for mulit-GPU per BSS.
Sub-BSS 1
cell1 cell4 cell3 cell2
Sub-BSS2 cell5 cell6 cell7
BSC GSL1
MFS GPU1
GSL2
GPU2
Sub-BSS3 cell8 cell9 cell11 cell13 cell12 cell10
GSL3
GPU3
GSL4
GPU4
cell14 cell15
Sub-BSS4
Figure 71: Multiple GPU per BSS
GPU1: cell1, cell2, cell3, cell4 GPU2: cell5, cell6, cell7 GPU3: cell8, cell9, cell10, cell11 cell12, cell13 GPU4: cell14, cell15
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
121 / 154
Page
3.6.1.3 Capacity
The following table describes the A9135 MFS capacity for DS10.
Nb of telecom subracks A9135MFS Configuration Standard 1 + 1 1 Standard Pre-equipped 2 + 1 1
Max GPU per MFS + One GPU for redundancy Max BSC per MFS Max GPRS GCH per MFS
Min GPU per MFS + One GPU for redundancy
15+1 or (240 *15) 3600 15 6 1
2 * (15+1) 7200 or (240 *30) 22 6 1
Max GPU per BSC Max BSC per GPU

st
Table 36: The 1 MFS generation (A9135 MFS) Capacity
3.6.2 MFS Evolution (A9130 MFS)
It is a brand new MFS introduced on the market in 2005, relying on the Advanced Telecom Computing Architecture (ATCA). The MFS Evolution is composed of the main following elements:

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

The following figure describes the A9130 MFS possible configurations:
SA12
SA12
RS16
RS16
Currently allowed configurations for MFS Evolution can be summarized as follow:

Stand-Alone 1 shelf: 2nd shelf extension possible:
up to 9 GP
Rack-shared MFS with 1 shelf,
up to 21 GP in total Up to 12 E1per GP in MR2ed4*:
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
In centralized synchronization mode: up to 9GP In autonomous synchronization mode: up to 21GP
Collocated BSC & MFS in one rack:

Either with O&M over IP Or with O&M over Ater
(*) Before MR2ed4, there is a maximum allowed number of 10 E1 per GP board when MFS is in centralized mode.
Additional capacity rules:
One A9130 MFS is able to manage up to 4000 cells (up to 2000 cells for legacy MFS) One A9130 MFS is able to control up to 21 BSCs
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
123 / 154
Page
Per GPU Fabric Extension Cnx PCM-TTP PCM-port TRX NS NSE NS-VC FR Bearer PVC Remote IP End Points 1 0 2 8 8 448 1 1 10 10 10 16
Per GP 1
Per MFS (with DS10) Equipment domain 30
Per MFS (with AS800) 20 1 40 160 160 9856 1 20 200 200 200 320
Per MFS Evolution 21 1 42 294 294 12600 1 21 210 210 210 336
0 1 2 60 14 240 14 240 600 9856 NS and Frame Relay domain 1 1 1 30 10 300 10 300 10 300 16 480
Figure 72: MFS capacity
Figures of above table is taken frome [3BK 10204 0034 DTZZA]. Note that Gb over IP is not supported on the AS800.
3.6.2.2 Delta MFS Evolution versus the 1st MFS generation

The main change/unchanged between those two MFS generation are below:
Different Behaviors: Same Behaviors
The GP replaces the current GPU No spare physical GP (still N+1 protection scheme)
No change in the radio configuration mechanisms, and same parameters are used
Control stations are replaced by the OMCP board
No change in the PM mechanisms, same counters/indicators No change in the Ater/Gb transmission configuration and display
In the A9130 MFS, there are only 12 ports per GP
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
124 / 154
Page
3.6.3 GP(U) Dimensioning and AterMux PS dimensioning (user traffic)

Target: To estimate the number of GP(U) needed per BSC. Gathered Counters:
Counter Name P100c P383a P384 P101 Indicator Name GAAGCHUST GQAGALCTT GQRGPUCDT Definition Cumulative time during which a GCH is busy in a cell. The counter is integrated over all the GCH available in the cell. Time during which AterMux interface (GICs) for this GPU is congested (at least one PDCH group impacted).
GAAGCHAVT
P474 P201 P202 P76a P77a P402 P106 P104 P107 P392b ([P62a+P62b+ P62cP438c+P507] (P105d + P105f + P27 + P105h + P105j + P105l + P204 + P512 - P66 - P28 [P30a + P30b + P30c+P508]) MC927e P62a + P62b + P62c - P438c + P507 P105e
GAAGCHAVANT GTRGPULDLT
GTRGPUPBA_MA GTRGPUPBM_MA GTRGPUOT GTRXTESUGPN GTRGPULPN
GTRGPULDOLT
Time during which a DSP enters the congestion state. Cumulative time during which a GCH resource (16k channel) is available in the GPU. Cumulative time over all the GCH resources configured in the GPU. Cumulated time per GPU during which Ater nibbles are free over the granularity period. They are nibbles not currently used in a GCH. Time during which at least a DSP is in CPU load state Average PMU CPU power budget observed. Consolidated in Day/Week/Month with the MAX value Maximum PMU CPU power budget observed. Consolidated in Day/Week/Month with the MAX value. Time during which at least a DSP is in CPU overload state
Time during which the GPU stays in the PMU CPU overload state due to PMU CPU power limitations. Number of UL and DL TBF establishment successes per GPU. Number of LLC PDU transferred (UL + DL)
GTRXTERQGPN GTRGPUM_MA GQRUTEBPN
Number of DL and UL TBF establishment requests per GPU
Maximum number of active contexts of MS (in RRM) observed. Consolidated in Day/Week/Month with the MAX value. Number of UL TBF estab -failures due to BSS problem per cell. Reference: number of UL TBF estab -requests
GTRUTERQN GQRDTECCN
Number of UL TBF establishment requests. Number of DL establishment failures due to CPU processing power limitations of the GPU.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
125 / 154
Page
P105f P203
GQRUTECCN GQRDTELDN
Number of UL establishment failures due to CPU processing power limitations of the GPU. 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. 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. Number of DL TBF establishment requests.
P204
GQRUTELDN
P91a + P91b + P91c + P91d + P91e + P91f + P505 P383b
GTRDTERQN GTRGPUCOT_MA
Table 37: Counter list - GP(U) dimensioning
Time (cumulated over a granularity period) during which the GPU remains in "high" Ater usage.
Measured Object: BSC/GPU 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 GCH traffic (i.e. P100c) of the day.
Methodology:
The process of GP(U) dimensioning is presented below.

GPU_for_MS_context_handling (=0/1) GPU_GCH_Capacity GPU_for_Power_Limitation (=0/1)
Needed GCHs
+
Figure 73: GP(U) dimensioning process
Number of GPU
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.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
126 / 154
Page
Counters
Required_GCH_Traffic estimation
Stable Network Feature activation
Required_GCH_Traffic ERLANG C With quantile=99,9%
Needed GCHs
Traffic evolution
Figure 74 AterMux PS dimensioning process based on user traffic
The required GCH traffic can be computed in different ways depending on the scenario: 1. Stable Network (see 3.6.3.1) 2. Feature Activation (see 3.6.3.2) Concerning only PS traffic, the statistical law Erlang C is used during the dimensioning process to determine the necessary resources versus the traffic and the target GoS.
As GCH resources are associated to PS traffic only, Erlang C can be applied to calculate the required number of GCH according to required PS traffic and the grade of service.
The Grade of Service (GoS) is defined by %Quantile of x delay second (pGP(U)). Since the MFS always tries to assign TBFs as soon as the request is received, we usually dimension for 0sec delay. Normally GoS should be given or agreed by the Operator. The recommended value is 99.9% quantile of 0 delay sec.
OUTPUT Number of required GCH = Erlang C (Required_GCH_traffic, pGP(U)) Number of required GP(U) = Number of required GCH / GPU_GCH_Capacity + GPU_for_MS_context_handling + GPU_for_Power_Limitation Being:
GPU_for_Ms_context_handling a quantity equal to 1 if a GPU memory limitation due to a too big number of MS contexts is observed (issue no more observed from B9MR1ed6QD2) and no additional GP(U) boards needed because of GPU GCH capacity limitation (see 3.6.3.4 for details on the estimation of this variable) GPU_For_Power_Limitation a quantity equal to 1 if a GPU power limitation is observed, no additional GP(U) boards needed because of GPU GCH capacity limitation and GPU_for_Ms_context_handling equal to 0 (see 3.6.3.4 for details on the estimation of this variable).
GPU_GCH_Capacity the maximum number of GCHs that the GPU can handle (see 3.6.3.3 for details on the estimation of this variable)
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
127 / 154
Page
3.6.3.1 Required GCH traffic estimation in case of stable network

Two methods have been elaborated in order to estimate the required GCH traffic in case of stable network:
Method 1: driven by GCH traffic and congestion observation Method 2: driven by GCH and PDCH traffic observation
Both methods should provide very close result in case of low high Ater usage time percentage and in case of limited (less than 30%) congestion. Method 1: Re quired _ GCH _ traffic =
Measured _ GCH _ traffic 1 Min(%GCH _ cong ,30%)
Where:
Measured _ GCH _ traffic =
%GCH _ cong = Max{Ater _ Congestion, GPU _ Limitation} = Max{% Ater _ Cong ,% DSP _ Cong ,% DSP _ load ,%CPU _ overload }
P100c , and 3600
Where:
%GCH _ Ater _ cong = %GCH _ DSP _ cong = % DSP _ load =
P383a 100% 3600 P384 100% 3600
Max( P 201, P 202) x100% 3600 P 402 x100% 3600
%CPU _ overload =
Remark: Before starting GP(U) dimensioning, it is recommended to check the reliability of P100c (cf. details in FR 3BKA20FBR181618) by comparing P100c value with P101 & P474 as: P100c P101 P474
If P100c value is far different than P101 P474, P100c is not reliable. The proposed workaround is GP(U) reset and after that check counter values again.
1
3DF 01903 8010 VAZZA 01
March 04, 2008
128 / 154
Page
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 relationship between these two quantities (that depends on the traffic profile, on parameter configuration, on the available resources) is quasi-linear.
448
Required_GCH_Traffic
y = 5,3905x + 21,057
336
Measured GCH traffic
224
Resources saturation
112
10
20
30
Measured PDCH traffic
40
50
60
70
80
Figure 75: Example of GCH/PDCH traffic relationship in case of AterMux PS underdimensioning
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 saturation around the available resource limit. 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.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
129 / 154
Page
An example of the evolution of GCH vs. PDCH traffic relationship following the adding of 1 AterMux Ps link is provided in Figure 76.
560
Following the 4th link adding
Needed_GCH
448
Measured GCH traffic
y = 5,3905x + 21,057
ERLANG C
336
224
112
10
20
Measured PDCH traffic
30
40
50
60
70
80
Figure 76 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 Required GCH estimation in anticipation of feature activation

Some optional feature activation can lead to an increase of the GCH usage (at Abis and Ater level). In order to be able to handle this traffic increase a method for the estimation of the final required_GCH_traffic has been defined. The following feature activation have been taken into account:
-
EDGE activation
CS3/CS4 activation
The goal of the method is to estimate the increase_factor to apply to the estimated required_GCH_traffic in stable conditions. Afterwards this increase_factor will be used in the following way:
Required_GCH_trafficafter_feature_activation = Required_GCH_trafficstable_network * increase_factor
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
130 / 154
Page
The target GCH traffic can also be estimated, estimating the target relationship between GCH and PDCH traffic. The proposed rule in order to obtain the target linear relationship is described below (see Figure 77).
After EDGE/CS3/CS4
GCH traffic
Y=a2x + b2 Y=a1x + b1
Before EDGE/CS3/CS4
a2= a1 * Increase_Factor and b2 = b1 (approximation !)
PDCH traffic
Figure 77 GCH vs. PDCH evolution in case of EDGE/CS3/CS4 activation
3.6.3.2.1 Increase_factor estimation If one or several reference BSC exist, the increase_factor can be simply equal to the increase_factor measured on these BSCs.
If no reference exists, the increase_factor can be estimated knowing which is the theoretical average target number of GCH per PDCH in the initial and final condition: Increase_factor = average_target_nb_GCH_per_PDCHfinal / average_target_nb_GCH_per_PDCHinitial
The increase_factor in case of EDGE/CS3/CS4 activation depends on the type of transition that must be supported and on the penetration of the activated service:
b CS1/CS2 c a CS3/CS4 d CS3/CS4 & EDGE
EDGE
Being:
%PDCH_EGPRS the % of Radio Resources (PDCH) supporting at least one TBF established in EGPRS mode on a cell with MAX_EGPRS = MCSx %PDCH_GPRS the % of Radio Resources (PDCH) supporting only TBF established in GPRS mode on a cell with MAX_GPRS = CSy
1
3DF 01903 8010 VAZZA 01
March 04, 2008
131 / 154
Page
Avg_target_nb_GCH_per_PDCH = (%_PDCH_EGPRS * nb_GCH_per_PDCH_MCSx) + (%_PDCH_GPRS*nb_GCH_per_PDCH_CSy) The increase_factor will have the following values, depending on the type of transition:
Transition type Increase_Factor
a c e
b d
[(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS*1,64)]/1 [1,64]/1 [(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS*1)]/1
[(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS*1,64)]/1,64 (%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS*1,64) / (%_PDCH_EGPRS*4,49) (%_PDCH_GPRS*1) Table 38: GCH resource increase factor
N.B. The recommended default value for %PDCH_EGPRS is 30%.
3.6.3.3 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_GP*4 (for Mx MFS with GboFR) 1920 N_ATER_TS_MARGIN_GP*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 CS1 CS2 CS3 CS4 GPU (A9135) 240 240 224 200 GP (A9130)
Case 16 E1 links per GP
GP (A9130)
960 960 892 804
960 960 864 660
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
132 / 154
Page
Max MCS MCS 1 MCS 2 MCS 3 MCS 4 MCS 5 MCS 6 MCS 7 MCS 8 MCS 9
GPU (A9135) 232 224 208 200 184 172 136 116 108
GP (A9130)
GP (A9130)
856 836 796 772 704 660 448 380 348
856 836 796 720 584 460 312 264 244
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.
CS CS-1 CS-2 CS-3 CS-4 UL 0,73 1,00 1,25 1,64 DL 0,73 1,00 1,22 1,60
MCS-1 MCS-2 MCS-3 MCS-4 MCS-5 MCS-6 MCS-7 MCS-8 MCS-9
MCS
Number of required GCHs 0,89 1,00 1,33 1,50 1,86 2,36 3,49 4,14 4,49 UL 0,86 1,00 1,28 1,47 1,81 2,31 3,39 4,00 4,39 DL
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)
1
3DF 01903 8010 VAZZA 01
March 04, 2008
133 / 154
Page
Min{ Max _ DL _ GCH _ GPU , Max _ UL _ GCH _ GPU , Max _ Capacity N _ ATER _ TS _ MARGIN _ GPU * 4}
GPU_GCH_Capacity will be defined in the following way:
Where,
Max_Capacity is equal to 480, 1560 or 1920 GCH depending on the limitation described above: % (M)CSx in DL direction = P55x/sum of P55y for all coding schemes % (M)CSx in UL direction = P57x/sum of P57y for all coding schemes
Assessment:
It is recommended to monitor the GPU GCH congestion through indicators, GP(U) Ater congestion (P383a/3600) and GP(U) DSP congestion (P384/3600). If we can see the GCH congestion occurring regularly e.g > 0.1% congestion, GP(U) redimensioning is required.
3.6.3.4 GP(U) limitations

Apart from GP(U) GCH capacity, some limitations due to GP(U) memory or processor capacity must also be taken into account; the consequence of these limitations can be the adding of 1 GP(U) resource in order to reduce the memory/processor load. Two types of limitations have been identified as critical in B9:
2. The capacity in terms of PMU or DSP CPU load 1. The capacity in terms of MS contexts (2000 for a GPU and 8000 for a GP board)
Capacity in terms of MS contexts (GPU_for_MS_context_handling variable estimation)
In B9MR1, before B9MR1Ed6, it was observed that when the maximum number of allowed MS contexts was reached an abnormal increase of UL TBF establishment failure due to BSS cause was observed:
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
134 / 154
Page
1200
Average number MS context (P392a)
Max number MS context (P392b)
60,0%
1000
50,0%
800
40,0%
600
30,0%
400
20,0%
200
10,0%
0 21/10/2006 : 00h 22/10/2006 : 00h 23/10/2006 : 00h 24/10/2006 : 00h 25/10/2006 : 00h 03h 06h 09h 12h 15h 18h 21h 03h 06h 09h 12h 15h 18h 21h 03h 06h 09h 12h 15h 18h 21h 03h 06h 09h 12h 15h 18h 21h 03h 06h 09h 12h 15h 18h
0,0%
UL TBF BSS Failure rate
In order to detect this problem the following methodology was defined:
Retrieve Retrieveindicators indicators for 5 working days P392bBSC = 2000 during at least 12% of the observed period
NO
GPU_for_MS_context_handling=0 _
YES
P392bBSC = 2000 when BSS_fail _rate max Observed for all days with at least two occurrences of P392b BSC = 2000
NO
GPU_for_MS_context_handling=0 GPU_for_MS_context_handling=1 _
YES
Observed QoS acceptable for the customer ?
NO
YES
GPU_for_MS_context_handling=0 _ =0
N.B. In B9 MR4 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.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
21h
Edition
1
135 / 154
Page
Capacity in terms of PMU/DSP CPU load (GPU_for_Power_Limitation variable estimation) In B9 release a big increase of CPU load has been observed (due to new B9 algorithms) leading, sometimes, to very critical situations (i.e. GPU reboots). Even if in most of the analysed cases the overload was due to an abnormal increase of events to be managed, the workaround for avoiding blocking conditions could be the adding of 1 additional GPU board. In order to determine GPU_for_Power_Limitation, two methodologies have been built (but not tested on field) in order to detect an overload at PMU CPU (see Figure 78) or DSP CPU (see Figure 79) level.
Retrieve indicators for 5 working days
P402/3600 >0,1% during at least 12% of The observed period
NO
GPU_for_Power_Limitation=0
YES
P402/3600 >0,1% and cpu_cong_fail_rate > 1% OR GPU reboots observed during the CPU loaded hours)
NO
YES
Figure 78 GPU_for_Power_Limitation due to PMU CPU load
In Figure 78,
cpu _ cong _ fail _ rate= Max( P105f P105e ; ) P91a + P91b + P91c + P91d + P91e + P91f P62a + P62b + P62c - P438c
N.B. In the specific case of B8 to B9 migration the check of the following additional condition was highly recommended for GPU_for_Power_Limitation variable estimation. Indeed GPU_for_Power_Limitation = 1 if the observed board is a GPU and if the B8 measured PMU CPU average load is greater than 40%. This recommendation is the result of ALU simulations about the CPU power budget increase from B8 to B9.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
136 / 154
Page
Retrieve indicators for 5 working days
Max(P201,P202)/3600 >0,1% during at least 12% of The observed period
NO
YES
Max(P201,P202)/3600 >0,1% and dsp_load_fail_rate > 1% OR GPU reboots Observed during the CPU loaded hours)
NO
YES
Figure 79 GPU_for_Power_Limitation due to DSP CPU load
In Figure 79,
dsp _ load _ fail _ rate = Max(
P 203 P 204 ; ) P91a + P91b + P91c + P91d + P91e + P91f P62a + P62b + P62c - P438c
WARNING: Since the methods described for GPU power limitation detection have not yet been validated on a real network, they could evolve following B9MR4 release generalization.
Assessment:
It is recommended to monitor the PMU and DSP load through the counters (P201, P202, P402, P76a, P77a).
If we can see that Max(201,202)/3600 or P402/3600 is regularly > 0.1%, GP(U) redimensioning is required.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
137 / 154
Page
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
-
Sub-Network Service (SNS) is dependent on the intermediate transmission network and provides access to the intermediate network
order is kept, except under exceptional circumstances Load-sharing (at the initiative of the sender) NS Virtual Connections (NS-VC) management
The BVC is identified by a BVC Identifier (BVCI) that is unique in one Network Service Entity (NSE). An NSE, which is identified by a NSE Identifier (NSEI), is a group of communication paths called NS-VC. The NSEI is an end-to-end identifier and shall be unique within a SGSN. The BVCI together with the NSEI uniquely identifies a BVC within a SGSN.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
138 / 154
Page
The next figure describes the Gb protocol stack implemented at both MFS and SGSN sides. It describes the logical context, i.e. protocol layers and entities, of the Gb interface.
In legacy GboFR architecture, NS-VC are built within FR Permanent Virtual Circuit
While in GboIP architecture, NS-VC are no more linked to a PVC and a BC but it is made of a couple of IP Endpoints (i.e. MFS and SGSN IP endpoint) The IP endpoint at GPU and SGSN level is identified by the UDP port and IP address.
B S S G P la y e r GPU m
B S S G P la y e r GPU n BCV BCV
BCV
BCV
BVC = one p e r c e ll
BCV
BCV
SGSN
BVCI
N S la y e r
L o a d s h a r in g
N SC sub la y e r
NSE
N SE = one per G PU N S -V C I o r R e m o te IP E n d p o in t R e m o te IP e n d p o in t
OR
N S -V C PVC
SN S sub la y e r Layer 1
N S -V L
IP E n d p o in t
IP n e t w o r k
N S -V L F R b e a re r
F R n e tw o rk
Figure 80: Gb interface configuration (from 3BK 09559 LAAA EBZZA)
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
139 / 154
Page
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 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:

GboFR
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
Gb
Frame Relay Netwok
Gb
SGSN
2) Direct MFS - SGSN connections
MFS
Gb Gb
MSC/VLR MSC/VLR
3) Through NSS transmission network
MFS
Gb
Figure 81: Gb interface connections
For more details, please refer to [1] and [10].
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
140 / 154
Page
The GboIP is transported over a Gigabit Ethernet (GE) link.

GboIP
Several configurations may be used to connect the MFS with the SGSN:
Direct point to point connection Over a public IP network (security, QoS and delay not guaranteed) Over a private IP network (security, QoS and delay guaranteed by the Operator) Over the SGSN IP backbone (similar to private IP network)
Example of connection: In the following figure, the MFS is connected to the SGSN through a private IP network. The MFS is connected to Edge Routers through a redundant GE link.
The Edge Routers are seen as a single gateway IP address, which is a MFS requirement. The Routers shall implement the VRRP protocol or an equivalent protocol like HSRP.
E1
Ater(packet)
PDH/SDH network
Ater(circuit)
TC
BSC
MSC GE Gb GE
MFS
Full redundant architecture,

Seen as single gateway IP@
Packet Switched Network
SGSN
Figure 82: GboIP End-to-End architecture
Only the O&M one LAN configuration allows GboIP feature in B10 release.
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
The support of GboIP is based on IPv4 protocol only, and is defined with following rules:

For more details, please refer to [1] and [10].
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
141 / 154
Page
3.7.2 Gb Dimensioning
The dimensioning of Gb interface is not impacted by any channel consideration or radio condition and it only depends on BH average throughput (from carried volume at Busy Hour). Target: To estimate the number Gb TS (GboFR) and average throughput (GboIP) Gathered Counters:
Counter Name P45 P46 P45a P46a Indicator Name GTGPVCDLN GTGGIPDLN GTGGIPULN GTGPVCULN Definition Nbr of kilobytes received from the SGSN at SNS sublayer Nbr of kilobytes received from the SGSN at SNS sublayer (GboIP) Nbr of kilobytes sent to the SGSN (GboIP) Nbr of kilobytes sent to the SGSN.
Table 39: Counter list - Gb dimensioning
Measured Object: Gb (PVC for GboFR, IP Endpoint for GboIP) Gathering periods: 7-day Busy Hour data, recommended Otherwise, at least 2 working-day Busy Hour data
Methodology:
The process of Gb dimensioning is presented below.

INPUT METHOD OUTPUT Nb of required TS per GboFR link Minimum Throughput for GboIP link
Required Gb Traffic GoS: % Quantile of x delay sec
Erlang C
Figure 83: Gb dimensioning process
INPUT
The required Gb traffic is computed as below formula.

Re quired _ Gb _ traffic = Measured _ Gb _ traffic + 15%m arg in
Note: a 15% margin is added to the required traffic.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
142 / 154
Page
Since the MFS always tries to assign TBFs as soon as the request is received, we usually dimension for 0sec delay.
The other input is Grade of Service (GoS), which is defined by %Quantile of x delay second (pGb).
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
Concerning only PS traffic, the statistical law Erlang C is used during the dimensioning process to determine the necessary resources versus the traffic and the target GoS.
As Gb resources are associated to PS traffic only, Erlang C can be applied to calculate the required number of GboFR TS and GboIP throughput according to required PS traffic and % quantile of delay time.
OUTPUT
Gb over Frame Relay
For GboFR interface, the measured traffic corresponds to P45 and P46 counters.
Measured _ Gb _ traffic = Max( P 45, P 46 ) 28800
Then the required number of bearer channels (i.e. 64kbps TS) is as follows: = Erlang C (Required_GboFR_traffic; pGb) Number of required Gb TS per link
Notes:
1 Erlang = [Gb TS speed (64kbps) * 3600] / 8 =28800 K bytes Minimum 2 Gb links are required for one GP(U) due to security reason Maximum 31 Gb TS (TS no. 1 to 31) can be configured per one GboFR link. TS0 cannot be used as it is reserved for specific usages e.g. frame synchronization. In general, around 4 to 8 TS are configured per one GboFR link.
For more detail, please see [19]
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
143 / 154
Page
Gb over IP
The dimensioning must be performed at MFS level with all BSC involved in the GboIP mode. 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
The overall overhead depends on the traffic flow characteristics (IP packets size). As an average value, the estimated overhead is about 35% for an IP PDU of 300 bytes. 1) When the GboIP interface is used, the measured traffic is given with P45a and P46a counters.
Measured _ GboIP _ traffic = Max ( P 45a, P 46a ) 3600 All _ MFS _ IP
Then the required GboIP throughput takes into account the header as follows: = Erlang C (Required_GboIP_traffic+35%; pGb) GboIP throughput required per MFS
2) 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. Measured _ Gb _ traffic = Max( P 45, P 46) 28800 AllPVC
The measured Gb shall take into account the removal BSSGP/NS/FR header and the addition of the BSSGP/NS/UDP/IP/Ethernet header:
Measured _ GboIP _ traffic = Measured _ Gb _ traffic * (300 + 118) /(300 + 54)

Then, = Erlang C (Required_GboIP_traffic; pGb)
Notes: Overhead from GboFR to GboIP = [300 + 118] / [300 + 54] = 18,1%.
GboIP throughput required per MFS
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
144 / 154
Page
4 Annex 1: BSS Architecture Impact from B9
Since B9 release, there is high improvement in term of architecture point of view, especially for the transmission resource (Abis & AterMUX) management, due to the benefits from the introduction of some new features. B9 features brought the architecture gains include: In order to carry PS-related data, a bi-directional link needs to be established between the MFS and the BTS (through the BSC). In B9 release, that link is called M-EGCH link (M standing for Multiplexed) for Evolium BTS. Contrary to B8 release where an EGCH link was defined per radio TS, an M-EGCH link is defined per TRX. M-EGCH Statistical Multiplexing
Figure 84: EGCH link in B8 vs. M-EGCH link in B9
As M-EGCH concept presented in Figure 84, the M-EGCH Statistical Multiplexing feature allows the reduction of the consumption of GCH resources (especially on Ater) by multiplexing the blocks of all the PDCHs of a TRX on a single transmission link (MEGCH link), instead of using a single EGCH link per PDCH. In following table, there is the summary showing the GCH usage gain in B9 - thanks to M-EGCH compared to B8 for each coding scheme. For instance, to support MCS 9, there are 40 GCHs per TRX needed in B8 but only 36 GCHs per TRX needed in B9.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
145 / 154
Page
Coding Schemes CS1 CS2 CS3 CS4 MCS 1 MCS 2 MCS 3 MCS 4 MCS 5 MCS 6 MCS 7 MCS 8 MCS 9
B8 (w/o stat mux)

GCH per RTS
B9 (with M-EGCH stat Mux) 8 8 16 16 8 8 16 16 16 24 32 32 40

GCH per RTS
Table 40: GCH consumption B8 vs. B9
1 1 2 2 1 1 2 2 2 3 4 4 5
GCH per TRX
0.73 1.00 1.25 1.64 0.89 1.00 1.33 1.50 1.86 2.36 3.49 4.14 4.49
GCH per TRX
6 8 10 14 8 8 11 12 15 19 28 34 36
M-EGCH Statistical Multiplexing is mandatory feature (automatically enabled) in B10 (since B9 release). For more details, please refer to [2].
This feature enables to dynamically allocate Abis nibbles among the different TREs used for PS traffic in a given BTS. Compared to B8, it allows a higher average Abis bandwidth per PDCH, the BSC capacity in terms of TREs is increased, and in some BTS configurations it may avoid to deploy a second Abis link. In B9 release, the concept of pool of Abis nibbles is introduced: A pool of Abis nibbles is a set of basic and extra Abis nibbles, which can be dynamically allocated among the M-EGCHs of some TREs.
Dynamic Abis Allocation
So, the pool of Abis nibbles is at a higher level of sharing than the M-EGCH (whose sharing is at TRX level), however, the level of sharing of the pool of Abis nibbles depends on the type of Abis resources:
The bonus basic Abis nibbles currently used for BCCH or static SDCCH channels can be shared at the BTS level. It means that they can be shared between the different sectors of the same BTS cabinet. The extra Abis nibbles can be shared at the BTS level. It means that they can be shared between the different sectors of the same BTS cabinet.
The basic Abis nibbles mapped to a PDCH currently available for PS traffic can be shared at the cell (BTS sector) level. In case of cell split over 2 BTSs, the share can be done only for one of the two BTS sectors of the cell. This means that only one of the BTS sectors of the cell will be PS capable (new O&M constraint in B9 release).
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
146 / 154
Page
Figure 85: Wasted Abis nibbles case in B8
In Figure 82, there is a noticeable waste of Abis resources in B8 release linked to static Abis allocation but it can be improved from B9 with dynamic Abis allocation feature which can manage to use basic Abis nibbles mapping to signalling channels i.e. BCCH and SDCCH (so called bonus basic nibbles) and all extra Abis nibbles for PS traffic so no more wasted Abis nibbles from B9. Dynamic Abis allocation is mandatory feature (automatically enabled) in B10 (since B9 release). For more details, please refer to [2].
The Enhanced transmission resource management feature can be seen on top of the MEGCH Statistical Multiplexing and Dynamic Abis allocation features.
Enhance Transmission Resource Management
Indeed, it assumes that the M-EGCH Statistical Multiplexing feature is implemented in RLC/MAC layers, and it relies on the Dynamic Abis allocation feature which offers a means to dynamically adjust (increase or decrease) the M-EGCH link size of the TRXs.
Figure 86: Enhance transmission resource management
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
147 / 154
Page
The main goals of the Enhanced transmission resource management feature are the following:
Determine the M-EGCH link size of all the TRXs and the nature of their GCHs Create/release the M-EGCH links of the TRXs, add/remove/preempt some GCHs over the M-EGCH links of the TRXs Manage the Abis congestion situations at BTS level and the Ater congestion situations at GP(U) level by applying some equity rules Ensure GPRS access in all the cells
Enhanced transmission resource management is mandatory feature (automatically enabled) in B9. For more details, please refer to [2].
The Ater Resource Management in a given GPU is based on two complementary mechanisms: GP(U) Ater TS margin Goal: Ensure that GPRS access never be blocked in a cell due to lack of Ater resources in the GPU. Mean: Reserve at least N_ATER_TS_MARGIN_GPU (O&M parameter) timeslots in GP(U) to serve only new prioritary TBF establishment.
AterMUX PCM link 0 1 2 3 N_ATER_TS_MARGIN_GPU Ater TS Reserved in GPU for priority request
...
Ater Resource Management
64kbps timeslot # 0 64kbps timeslot # 1 . 64kbps timeslot # n
Figure 87: AterMUX TS reserved by GP(U) Ater TS margin
High Ater usage handling
Ater Resource Management is mandatory feature (automatically enabled) in B9. For more details, please refer to [2]. DL retransmission in the BTS
1
It is the way to manage the Ater resource when Ater usage enters high state determined by the parameter Ater_Usage_Threshold. If Ater usage is high, the target number of GCH associated to TRXs of the GP(U) will be reduced according to GCH_RED_FACTOR_HIGH_ATER_USAGE (O&M parameter). However, this reduction factor is only applied on PDCHs newly open.
3DF 01903 8010 VAZZA 01
March 04, 2008
148 / 154
Page
The principle of this feature is to store, in the memory of the TREs of the BTSs, the DL RLC data blocks transmitted by the MFS to the MS. This avoids consuming transmission resources (Abis + Ater) in case of DL RLC data block retransmissions.
Figure 88: Better transmission resource usage with DL retransmission in the BTS
Without DL Retransmission in the BTS, the RLC/MAC layer shall retransmit the complete DL RLC data block to the TRE when retransmission needed so called complete retransmission B8 case. If DL Retransmission in the BTS is activated, the RLC/MAC layer may take the benefit to store RLC data block by TRE in the BTS. In this case, the RLC/MAC layer may retransmit to the TRE only RLC/MAC header and ask the TRE to add RLC data block before transmission to the MS so called reduced retransmission B9 case. DL Retransmission in the BTS is optional feature, which can be enabled/disabled at TRX/TRE level. In order to save transmission resource, it is recommended to activate this feature.
For more details, please refer to [2].
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
149 / 154
Page
5 Annex 2: Pre-requisites for MxBSC capacity improvements
Several improvements of the Mx BSC have been introduced with GboIP, HSL and Capacity features.
With these several improvements, Mx BSC could not be no more considered as a standard BSC. Indeed, the introduction of the new features may be problematic when non- compliant Core Network have been planned to be interconnected to Mx BSC.
The Core Network (NSS & GSS) should allow an interconnection with the Mx BSC. This feasibility (interoperability) is dependant on the CN capacity/capability to interconnect with Mx BSC enhanced by the implementation of new B10 features.
5.1 CIC code limitation
With the capacity improvement, the Mx BSC can handle up to 4500Erl, which corresponds to a number of 4630 CIC on A-interface (0.1% blocking rate). However, each CIC is coded on 12-bits field that permits to address a maximum of 4096 circuits between MSC and BSC elements (defined in ITUT Q.763):
8 7 6 5 4 3 2 1 Circuit Identification Code (least significant bits) Isb Spare msb CIC (most significant bits)
Thus, the total CS traffic really handled by Mx BSC could be limited by the restriction of CIC number on A-interface (Ater-CS interface as well), rather than the hardware or software capacity of the Mx BSC itself.
With this limitation, the total traffic that can be coded on CIC field is less than 3980Erlang. This implies a reduction of about 600Erlang regarding the real capacity of the Mx BSC. In order to overtake the 4096 CIC limitation, the Mx BSC will support the CIC coded on 16bits field from B10 release. The CIC code extension to 16-bits field is done with the use of the 4 spare bits in the header. The CIC code limitation will be eliminated if the connected MSC also supports the 16-bits CIC code, such as the A5060 Spatial Atrium Call Server (Alcatel-Lucent NGN solution).
5.2 HSL limitation
As mentioned in section 3.4.3.2, the SS7 signalling load is directly linked to the amount of BHCA and traffic carried by the Mx BSC. According tot ITU-T Recommendations, there is a limitation of a maximum of sixteen 64kbps SS7 signalling links per BSC (e.g. LSL mode).
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
150 / 154
Page
This limitation can be reached when the Mx BSC traffic growth occurs.
In order to overtake this limitation, the Alcatel-Lucent solution is to double the signalling throughput by using HSL functionality (ITU-T Recommendation Q.703 Annex A). The HSL feature is a mandatory feature in Mx BSC handling traffic higher than 2600Erl (in fact 1900Erlang as described in section 3.4.3), and it may be used only if the option is also supported by the MSC. At MSC level, the HSL function could be based on two different options;
Two un-channelized 2Mbps PCM links (TS0 + data bulk of 1984kbps) working in a redundant and load sharing purposes Two structured 2Mbps PCM links (up to 16 TS per PCM)
The Alcatel-Lucent solution is based on two un-channelized HSL links structured with a synchronisation TS0 as usual and a data channel of 1984kbps).
To conclude, the CS Core Network that will be interconnected to large Mx BSC (traffic load higher than 2000Erlang) shall support the un-channelized HSL feature. For interoperability purposes between Alcatel-Lucent Mx BSC and CS Core Network, the CSCN elements supporting the HSL feature are:
Legacy MSC equipped with RCP A8362M + Umax EP6 NGN release W4.21
An additional requirement is to be checked; it concerns the signalling mode between BSS and the MSC.
When MSC supports only the quasi-associated mode of signalling with the BSS, STP functionality (Signalling Transfer Point) shall be provided outside the BSS (cf. TS 48.006).
5.3 GboIP limitation
As described in sections 2.3.2 & 3.7, the NSE addresses (local IP endpoints) are preestablished by OMC-R commands (i.e. static) and there is no need for DHCP server to manage the addresses of IP endpoints. In that case, the PS Core Network (especially the SGSN element) shall support the static IP address allocation of the IP endpoints. While Alcatel-Lucent SGSN use a static IP address allocation (???), most of the third suppliers SGSN are using the automatic IP address management only. There may be a need for DHCP server in GboIP context (automatic IP addresses instead of O&M through the MFS).
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
151 / 154
Page
In addition, the Gb interface type is defined at BSC level allowing the MFS to support mixedmode (FR and IP). Several BSC could be connected to a single SGSN element; there is a strong need regarding the support of mixed-Gb mode (FR and IP).
For interoperability purposes between Alcatel-Lucent MFS and SGSN, the SGSN will support mixed Gb mode (FR and IP) and static IP address allocation (SGSN U3.2 & U3.3 roadmap). As only IPv4 is supported at MFS side, the SGSN shall also support IPv4 protocol. In the case of GboIP feature, the synchronization clock cannot be extracted from the SGSN. The following configurations shall be considered: In mixed Gb mode (FR and IP): clock synchronization can be extracted from the GboFR links In GboIP with existing links between MFS & TC: clock synchronization for Ater TDM can be extracted from the TC links
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
152 / 154
Page
6 Annex 3: Abis, Ater & Gb over Satellite

Under realization.
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
153 / 154
Page
7 Annex 4: Transport migration 7.1 Optimisation over E1 7.2 IP backhauling

Under realization.
END OF DOCUMENT
Alcatel File
3DF 01903 8010 VAZZA 01
Reference
March 04, 2008
Date
Edition
1
154 / 154
Page

BSS Architecture Service Guideline B10

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

BSS Architecture Service Guideline B10

Diunggah oleh

Hak Cipta:

Format Tersedia

Originator(s) A. Rezzoug E.

Mobile Radio Division

B10: BSS Architecture Service Guideline

Domain Product Division Rubric Type

: Network Architecture : GSM B10 : Methods : GSM/GPRS/EDGE : Guidelines

Distribution codes Internal: Pre-distribution: F. Colin NE Velizy

NE Portugal Tiago Dias

3DF 01903 8010 VAZZA 01

March 04, 2008

2.2.1 2.2.2 2.2.3 2.2.4

2.3.1 2.3.2 2.3.3

2.3.3.1 Optimized HR connectivity.......................................................................... 28 2.3.3.2 HSL functionality......................................................................................... 28

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

3DF 01903 8010 VAZZA 01

March 04, 2008

3.1.3.1 SDCCH Dimensioning................................................................................. 37 3.2

3.2.1.1 Abis Network Topology............................................................................... 45

3.2.1.2 Abis Channels .............................................................................................. 47

3.2.1.3 Abis Link Capacity....................................................................................... 49

3.2.1.4 Signalling Sub-Multiplexing Schemes......................................................... 49

64K Statistical Multiplexing ...................................................................................................... 51 16K Statistical Multiplexing ...................................................................................................... 54

BSC Evolution Configuration........................................................................... 70

3.3.2.5 SS7 transport ................................................................................................ 75

3.3.3.1 Design BSC area .......................................................................................... 77 LA Dimensioning.............................................................................................. 81

BSC Dimensioning ........................................................................................... 76

3.3.5 3.3.6 3.3.7

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

3DF 01903 8010 VAZZA 01

March 04, 2008

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

3.4.1.1 AterMUX interface ...................................................................................... 89

3.4.1.2 A interface .................................................................................................... 89 3.4.2

3.4.3.1 LSL and HSL modes .................................................................................... 96

SS7 Signalling mode......................................................................................... 96

AterMUX Dimensioning................................................................................. 101

3.5.2 3.6 3.5.3

3.4.4.3 AterMUX CS/PS ........................................................................................ 115

GCH/AterMUX-PS Dimensioning .......................................................................................... 113

G2.5 TC Configuration .................................................................................. 117 TC Dimensioning............................................................................................ 118

G2 TC Configuration ..................................................................................... 117

MFS.......................................................................................................................... 120 3.6.1.1 GPRS Processing Unit (GPU).................................................................... 121

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

3.6.1.2 Multiple GPU per BSS............................................................................... 121 3.6.2

3.6.1.3 Capacity...................................................................................................... 122

MFS Evolution (A9130 MFS)......................................................................... 122

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

3DF 01903 8010 VAZZA 01

March 04, 2008

ANNEX 1: BSS ARCHITECTURE IMPACT FROM B9 .................. 145

5 ANNEX 2: PRE-REQUISITES FOR MXBSC CAPACITY IMPROVEMENTS ......................................................................................... 150

3DF 01903 8010 VAZZA 01

March 04, 2008

3DF 01903 8010 VAZZA 01

March 04, 2008

3DF 01903 8010 VAZZA 01

March 04, 2008

3DF 01903 8010 VAZZA 01

March 04, 2008

3DF 01903 8010 VAZZA 01

March 04, 2008

3DF 01903 8010 VAZZA 01

March 04, 2008

3DF 01903 8010 VAZZA 01