Alcatel BSS

B9 BSS Configuration Rules

BSS Document
Reference Guide
Release B9

3BK 17422 5000 PGZZA Ed.06b

BLANK PAGE BREAK

Status

RELEASED

Short title

Configuration Rules
All rights reserved. Passing on and copying of this document, use
and communication of its contents not permitted without written
authorization from Alcatel/Evolium.

2 / 162

3BK 17422 5000 PGZZA Ed.06b

Contents

Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1
BSS Equipment Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Supported Hardware Platforms, Restrictions and Retrofits . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3
Platform Terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4
Release Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5
BSS Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6
New B9 Features and Impacted Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BSS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1
Transmission Architecture with CS Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Transmission Architecture with CS and PS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3
GPRS in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1
GPRS Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2
GPRS General Dimensioning and Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4
LCS in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2
Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.3
Physical Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.4
Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.5
GPS LCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.6
BSS and Cell Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.7
Traffic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.8
Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5
HSDS in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.1
Definitions and Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.2
Transmission Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.3
Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6
PLMN Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BTS Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
BTS Generation Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2
Evolium BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1
Evolium BTS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2
Evolium BTS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3
G2 BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4
G1 BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5
BTS Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6
Physical Channel Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1
GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.2
GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7
Frequency Band Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.2
Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.3
Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8
Speech Call Traffic Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9
Adaptive Multi-rate Speech Codec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.2
Rules and Dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10
Data Call Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.11
OML and RSL Submultiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.12
Cell Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.12.1
Cell Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.12.2
Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.12.3
Shared Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3BK 17422 5000 PGZZA Ed.06b

13
14
14
15
15
15
15
17
20
21
22
22
24
30
30
30
31
32
33
34
35
35
35
35
39
40
43
45
46
46
46
46
50
50
50
51
51
51
52
52
52
53
53
54
54
54
55
55
55
55
57
58

3 / 162

Contents

3.13

SDCCH Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.13.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.13.2
Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
BSC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.1
A9120 BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.1.1
A9120 BSC Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.1.2
ABIS TSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.1.3
ATER TSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.1.4
TSC Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.2
A9130 BSC Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.2.1
A9130 BSC Evolution Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.2.2
Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.2.3
A9130 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.3
Delta A9130 BSC Evolution versus A9120 BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
TC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.1
G2 TC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.1.1
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.1.2
Rules and Dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2
A9125 Compact TC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2.1
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2.2
Rules and Dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
MFS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.1
A9135 MFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.1.1
MFS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.1.2
MFS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.1.3
MFS Clock Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.2
A9130 MFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.2.1
MFS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.2.2
MFS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.2.3
MFS Clock Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.3
Delta A9135MFS versus A9130MFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
ABIS Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.1
Abis Network Topology and Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7.2
Impedance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.3
Abis Channel Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.3.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.3.2
TS0 Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.4
Signaling Link on Abis Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.4.1
RSL and OML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.4.2
Qmux Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.4.3
OML Autodetection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.5
Signaling Link Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.5.1
Signaling Link Multiplexing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.5.2
Signaling Link Multiplexing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.5.3
Multiplexed Channel Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.6
Mapping Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.6.1
Free Mapping Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.6.2
Abis-TS Defragmentation Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.6.3
RSL Reshuffling Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.6.4
Cross-Connect Use on Abis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.6.5
SBL Numbering Scheme in A9120 BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.6.6
SBLs Mapping on HW Modules in A9130 BSC Evolution versus A9120 BSC 109
7.6.7
TCU Allocation Evolution in A9130 BSC Evolution . . . . . . . . . . . . . . . . . . . . . . . . 109
7.7
Abis Link Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.8
Abis Satellite Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

4 / 162

3BK 17422 5000 PGZZA Ed.06b

Contents

7.9
Two Abis Links per BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ater Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1
Ater Network Topology and Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2
Impedance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3
Numbering Scheme on A9120 BSC-Ater/Atermux/TC Ater/A Interface . . . . . . . . . . . . . . . . .
8.3.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.2
Numbering Scheme on the A9120 BSC Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.3
Numbering Scheme at G2 TC Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4
Numbering Scheme on A9130 BSC Evolution-Ater/Atermux/TC Ater/A Interface . . . . . . . .
8.4.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.2
SBLs Mapping on HW Modules in A9130 BSC Evolution versus A9120 BSC
8.5
Signaling on Ater/Atermux Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.2
Signaling Link Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.3
SS7 Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.6
GPRS and GSM Traffic on Atermux versus A9120 BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.6.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.6.2
Hole Management in a G2 TC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.6.3
Sharing Atermux PCM Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.6.4
Ratio of Mixing CS and PS Traffic in Atermux . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.7
Ater Satellite Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
GB Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1
Gb Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2
Gb Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10 CBC Connection, SMSCB Phase 2+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2
GSM Cell Broadcast Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3
Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.1
Solutions in A9120 BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.2
Solutions in A9130 BSC Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appendix A : BSS Hardware Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

113
117
118
118
118
118
119
119
120
120
120
121
121
122
122
123
123
124
124
126
127
129
130
131
133
134
134
134
134
136
137

Appendix B : Cell Radio Channel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B.1
Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.1.1
Cell Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.1.2
TRX Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.1.3
Hopping Types in a Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.1.4
Radio Carrier Hopping Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.1.5
Use of the Hopping Types per Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2
Mapping Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2.1
ARFN/CU Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2.2
TCU/RSL & TRX/RSL Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.3
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.3.1
ARFCN Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.3.2
TRX Channel Configuration Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

139
139
139
139
141
142
142
144
144
146
146
146
153

3BK 17422 5000 PGZZA Ed.06b

5 / 162

Figures

Figures
Figure 1: BSS with GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 2: Transmission Architecture with CS Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figure 3: Transmission Architecture with CS and PS (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 4: Transmission Architecture with CS and PS (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 5: MFS in the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 6: GPRS NE, Interfaces and Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 7: Example 1 of a Link Configuration: 3/4 GSM& 1/4 GPRS Atermux 4:1 mapping . . . . . . . . . . . . . . 28
Figure 8: Example 2 of a Link Configuration: 3/4 GSM& 1/4 GPRS Atermux 4:1 mapping . . . . . . . . . . . . . . 30
Figure 9: Generic LCS Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 10: SAGI Physical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 11: Impact on Hub Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figure 12: Choice of Modulation Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figure 13: BTS in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 14: BSC in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figure 15: A9120 BSC Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figure 16: Ater TSU Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figure 17: A9130 BSC Evolution HW Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figure 18: 600 TRX LIU Shelf connections assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Figure 19: TC in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Figure 20: MFS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figure 21: BSC Connection for Multi-GPU per BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Figure 22: A9130 MFS Hardware Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Figure 23: Chain Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Figure 24: Ring or Loop Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Figure 25: Example of Cross-Connect Use on Abis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Figure 26: Gb Link Directly to SGSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Figure 27: Gb Link through the TC and MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Figure 28: Gb Link through the MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Figure 29: Gb Logical Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Figure 30: CBC-BSC Interconnection via PSDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Figure 31: CBC-BSCs Interconnection via the MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Figure 32: Maximum Number of Frequencies that can be Encoded in a CBCH Mobile Allocation and a Cell
Allocation (GPRS and of SoLSA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Figure 33: Maximum number of extended measurement frequencies that can be included in the Extended
Measurement Frequency List according to the frequency span. . . . . . . . . . . . . . . . . . . . . . . . . . . 153

6 / 162

3BK 17422 5000 PGZZA Ed.06b

Tables

Tables
Table 1: BSS Equipment Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Table 2: Supported Hardware Platforms, Restrictions and Retrofits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Table 3: New Features B9 and Impacted Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Table 4: GPRS General Dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Table 5: GPRS Coding Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Table 6: EGPRS Modulation and Coding Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Table 7: GMSK and 8-PSK Transmission Power Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Table 8: BTS Generation Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Table 9: Evolium BTS Minimum and Maximum Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Table 10: Typical GSM 900 and GSM 1800/1900 Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Table 11: Typical Multiband Configuration G3 BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Table 12: G2 BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Table 13: BTS Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Table 14: Frequency band configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Table 15: Hardware Transmission Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Table 16: Speech Call Traffic Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Table 17: AMR Codec List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Table 18: Data Call Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Table 19: OML and RSL Submultiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Table 20: Cell Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Table 21: Maximum Supported Capacities and Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Table 22: A9120 BSC Globally Applicable Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Table 23: BSS Evolution Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Table 24: B9 A9120 BSC Capacity per Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Table 25: TSL / TCU Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Table 26: Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Table 27: DTC Configuration and SBL Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Table 28: G2 TC/A9125 Compact TC capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Table 29: G2 TC configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Table 30: G2 TC Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Table 31: MFS Capacity for DS10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Table 32: Maximum MFS Configurations on MX Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Table 33: Multiplexed Channel Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Table 34: TS Mapping Table for Corresponding Abis Chain or Ring Configurations . . . . . . . . . . . . . . . . . . . . 107
Table 35: SBL Numbering at A9120 BSC Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Table 36: Abis Port - BIUA - TCU SBL Numbering in A9120 BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Table 37: Number of TS available in one Abis Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Table 38: Number of Required TS versus TRX Number and Sub-Multiplexing Type . . . . . . . . . . . . . . . . . . . 111
Table 39: Example of FR/DR Ratios According to Cell Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

3BK 17422 5000 PGZZA Ed.06b

7 / 162

Tables

Table 40: Numbering Scheme on BSC-Ater/Atermux/TC Ater/A Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Table 41: Numbering Scheme on A9120 BSC Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Table 42: Numbering Scheme on G2 TC Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Table 43: SS7, Atermux, DTC and Ater Numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Table 44: GPU Atermux Connections Example Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Table 45: Ratio of Mixing CS and PS Traffic in Atermux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

8 / 162

3BK 17422 5000 PGZZA Ed.06b

Preface

Preface
Purpose

Whats New

This document describes the configuration rules for release B8 of the Alcatel
BSS. It describes the possible BSS configurations supported in release B9, and
describes the new equipment in this release and the corresponding impact on
the various interfaces. Note that the OMC-R, RNO, NPA and LASER products
are beyond the scope of this document; refer to the appropriate documentation
for more information about these products.

In Edition 06b
Update made in Extended Cell Configuration (Section 3.2.2.3) due to system
evolution.

In Edition 06
Creation from doc version to.xml.
Introduction of A9130 MFS in GPRS General Dimensioning and Rules (Section
2.3.2), MFS Configuration (Section 6)
Introduction of A9130 BSC Evolution in BSC Configuration (Section 4),
Impedance (Section 7.2), Overview (Section 7.3.1), Qmux Bus (Section 7.4.2),
RSL Reshuffling Algorithm (Section 7.6.3), Cross-Connect Use on Abis (Section
7.6.4), Numbering Scheme on A9130 BSC Evolution-Ater/Atermux/TC Ater/A
Interface (Section 8.4), SBLs Mapping on HW Modules in A9130 BSC Evolution
versus A9120 BSC (Section 7.6.6), TCU Allocation Evolution in A9130 BSC
Evolution (Section 7.6.7), Rules (Section 3.13.2), Solutions (Section 10.3).
PS is supported in extended cell. Plus other additional rules regarding the
extended cells in Cell Types (Section 3.12.1), Extended Cell Configuration
(Section 3.2.2.3)
Editorial updates in chapters :New B9 Features and Impacted Sections (Section
1.6), GPRS Configurations (Section 2.3.1), GPRS General Dimensioning and
Rules (Section 2.3.2), Rules (Section 2.5.3), A9130 BSC Evolution Board
Configurations (Section 4.2.2.1), Centralized Mode (Section 6.1.3.2), MFS
Architecture (Section 6.2.1), MFS Clock Synchronization (Section 6.2.3)
Update chapter with BTS number on A9130 BSC type 1A9130 Capabilities
(Section 4.2.3)

In Edition 05

3BK 17422 5000 PGZZA Ed.06b

9 / 162

Preface

Overall document quality was improved following an editorial review.

In Edition 04
A new feature allows the usage of TREs at their real power. More details in
Cell Types (Section 3.12.1), GMSK Output Power (Section 2.5.2.1), Rules
(Section 2.5.3).
The secured single Gb details are included in chapters Gb Configuration
(Section 9.2) and MFS Clock Synchronization (Section 6.1.3).

In Edition 03
Editorial review

In Edition 02
Creation from doc version to.xml

Audience

This manual is for people requiring an in-depth understanding of the

configuration rules of the Alcatel BSS:
Network decision makers who require an understanding of the underlying
functions and rules of the system
Iincluding:
Network planners
Technical design staff
Trainers.
Operations and support staff who need to know how the system operates in
normal conditions
Including
Operators
Support engineers
Maintenance staff
Client Help Desk personnel.
This document can interest also
the following teams:
Quality Acceptance First-Off
Cellular Operations
Technical Project Managers
Validation
Methods.

10 / 162

3BK 17422 5000 PGZZA Ed.06b

Preface

Assumed Knowledge

The document assumes that the reader has an understanding of:

GSM
GPRS
Mobile telecommunications.

3BK 17422 5000 PGZZA Ed.06b

11 / 162

Preface

12 / 162

3BK 17422 5000 PGZZA Ed.06b

1 Introduction

1 Introduction
Introduction gives a brief mentioning of synonymus of terms and a first
approach of the Alcatel BSS, its equipments and features.

3BK 17422 5000 PGZZA Ed.06b

13 / 162

1 Introduction

1.1 BSS Equipment Names

The following table lists the Alcatel commercial product names and the
corresponding Alcatel internal names.

Note:

The names used in this document are those defined for internal use in Alcatel,
and not the commercial product names.

Alcatel Commercial Product Name

Alcatel Internal Name

Evolium A9100

G3, G3.5, G3.8, G4.2 BTS

Evolium A9110

M4M

Evolium A9110-E

M5M

A9135

MFS AS800, DS10 RC23, DS10 RC40

A1353-RA

OMC-3

A9125

A9125 Compact TC

A9120

G2 BSC

A9130 BSC Evolution

A9130 BSC Evolution

A9130 MFS Evolution

A9130 MFS Evolution

Table 1: BSS Equipment Names

1.2 Supported Hardware Platforms, Restrictions and Retrofits

The following table lists the Alcatel hardware platforms supported in by the
BSS, and corresponding restrictions and retrofits.
Equipment

B9 Support

Retrofit Required

BSC
A9120 BSC

Yes

A9130 BSC Evolution

Yes

TC
G2 TC

Yes

A9125 Compact TC

Yes

BTS Evolium
M4M, M5M

Yes

G3, G3.5

Yes

14 / 162

3BK 17422 5000 PGZZA Ed.06b

1 Introduction

Equipment

B9 Support

G4 (G3.8, G4.2)

Yes

Retrofit Required

G2 BTS
G2

Yes *

G1 BTS
G1 Mark II

Yes *

MFS
MFS / AS800

Yes

MFS / DS10 **

Yes

MFS / DS10 ***

Yes

MFS A9130

Yes

: For BTS G1 and G2 only DRFU configuration is supported. BTS G1 is not supported at all for A9130 BSC Evolution.

**

: DS10 with network mirroring disks RC23

***

: DS10 with local disks RC40

Table 2: Supported Hardware Platforms, Restrictions and Retrofits

1.3 Platform Terminals

The Alcatel BSS supports the Windows XP and Windows 2000 Operating
Systems (OS).

1.4 Release Migration

Migration from release B8 to release B9 infers the succession of the OMC,
MFS and BSC.

1.5 BSS Updates

No hardware upgrades are required.

1.6 New B9 Features and Impacted Sections

The following table lists the new B9 features, and provides links to impacted
sections of this document.
New B9 Features

Impacted Sections

GCH Statistical Multiplexing

Rules (Section 2.5.3)

Autonomous Packet Resource

Allocation

GPRS (Section 3.6.2)

3BK 17422 5000 PGZZA Ed.06b

15 / 162

1 Introduction

New B9 Features

Impacted Sections

HCM Improvements (TRX/RSL and

TRE/TCU)

TCU/RSL & TRX/RSL Mapping (Section B.2.2)

Preparation for Complete Cell

Identification

PLMN Interworking (Section 2.6)

Up to 64 cell reselection adjacencies

per cell

PLMN Interworking (Section 2.6)

Enhanced Transmission Resource

Management

Definitions and Prerequisites (Section 2.5.1)

Enhanced support of EGPRS in uplink

Definitions and Prerequisites (Section 2.5.1), Rules (Section

2.5.3)

Enhanced E-GSM band handling

GPRS General Dimensioning and Rules (Section 2.3.2), Evolium

BTS Configuration (Section 3.2.2), G1 BTS (Section 3.4),
Frequency Band Configuration (Section 3.7)

Secured single Gb

GPRS General Dimensioning and Rules (Section 2.3.2)

Unbalancing TRX Output Power per

BTS sector

GMSK Output Power (Section 2.5.2.1), Cell Types (Section

3.12.1), Rules (Section 2.5.3)

New platform introduction A9130 MFS

Evolution

GPRS General Dimensioning and Rules (Section 2.3.2), MFS

Configuration (Section 6)

New platform introduction A9130 BSC

Evolution and rack sharing

BSC Configuration (Section 4), Impedance (Section 7.2),

Overview (Section 7.3.1), Qmux Bus (Section 7.4.2), RSL
Reshuffling Algorithm (Section 7.6.3), Cross-Connect Use
on Abis (Section 7.6.4), Numbering Scheme on A9130 BSC
Evolution-Ater/Atermux/TC Ater/A Interface (Section 8.4), SBLs
Mapping on HW Modules in A9130 BSC Evolution versus A9120
BSC (Section 7.6.6), TCU Allocation Evolution in A9130 BSC
Evolution (Section 7.6.7), Rules (Section 3.13.2),Solutions
(Section 10.3)

PS in extended cell

Cell Types (Section 3.12.1)

Table 3: New Features B9 and Impacted Items

16 / 162

3BK 17422 5000 PGZZA Ed.06b

2 BSS Overview

2 BSS Overview
BSS Overview describes the Alcatel BSS, and corresponding features and
functions.
The GSM Radio System (GRS) is a set of hardware and software equipment
provided by Alcatel to support the radio part of the GSM network. The GRS
comprises one OMC-R and one or more BSS. The OMC-R supervises one
or more BSS.
The BSS provides radio access for Mobile Stations (MS) to the PLMN. There
are one or more GRS per PLMN.
The following figure shows a BSS with GPRS. All BSS operating over the
field are with/without data service.

3BK 17422 5000 PGZZA Ed.06b

17 / 162

2 BSS Overview

Figure 1: BSS with GPRS

The different Network Elements (NE) within the BSS are:
The Base Station Controller (BSC)
The Transcoder (TC)
The Base Transceiver Station (BTS)
The Multi BSS Fast packet Server (MFS).
The BSS interfaces are:
The Um interface (air or radio interface), between the MS and the BTS
The Abis interface, used to connect the BTS to the BSC
The Atermux interface
used to connect:
The BSC to the TC and/or the MFS
The MFS to the TC
The A interface, used to connect the TC to the MSC

18 / 162

3BK 17422 5000 PGZZA Ed.06b

2 BSS Overview

The Gb interface, used to connect the MFS to the SGSN (directly, or through
the TC and the MSC).

Note:

The Gs interface, between the MSC and the SGSN, is not described in this
document, as it is not considered to be part of the BSS. For more information
about this interface, refer to the BSS System Description.
For specific information about the LCS dedicated interfaces, refer to LCS
in the BSS (Section 2.4).
Given that the transmission architecture depends on GPRS, there are two
possible transmission architectures:
Transmission architecture with Circuit Switched (CS) only
Transmission architecture with CS and Packet Switched (PS).

3BK 17422 5000 PGZZA Ed.06b

19 / 162

2 BSS Overview

2.1 Transmission Architecture with CS Only

This section provides information about static Abis only.
The following figure shows the overall transmission architecture with CS only,
inside the BSS.

Figure 2: Transmission Architecture with CS Only

The transmission interfaces are:
The Abis interface, between the BIE BTS and the BIE BSC
The Ater interface, between the SM and the DTC inside the BSC, and
between the SM and the TRCU inside the TC
The Atermux interface, between the BSC-SM and the TC-SM
The A interface, between the TRCU and the MSC.
The Abis, Ater, Atermux and A interfaces are structured in 32 time slots (TS),
each of which is composed of 8 bits at 64Kbit/s, resulting in a 2048 Kbit/s
E1 digital hierarchy.

20 / 162

3BK 17422 5000 PGZZA Ed.06b

2 BSS Overview

The TS are numbered from TS0 to TS31. Each 64 Kbit/s TS takes place in one
byte, sized of 8 bits numbered from 1 to 8.

Note:

Microwave equipment is external to and independent of Alcatel transmission

equipment, however, in some cases, the microwave can be housed in the
transmission equipment rack and in the BTS.

2.2 Transmission Architecture with CS and PS

PS is directly linked to GPRS and related MFS platforms.
The following figures represent the MFS with its physical interfaces, when
connected to the network.

Figure 3: Transmission Architecture with CS and PS (1)

Figure 4: Transmission Architecture with CS and PS (2)

In addition to the interfaces defined in Transmission Architecture with CS Only
(Section 2.1), the following MFS physical interfaces are used:
The MFS-BSC interface, which is the Atermux interface (a 2Mbit/s PCM link
carrying 32 TS at 64Kbit/s). The Atermux interface can be fully dedicated
to GPRS (only PS conveyed), or mixed CS/GPRS. In this case, the CS
channels (called CICs) coexist with GPRS channels (called GICs) on
the same link.

3BK 17422 5000 PGZZA Ed.06b

21 / 162

2 BSS Overview

The MFS-TC interface, which is also a 2Mbit/s PCM link carrying CS only,
GPRS only, or mixed CS/GPRS channels. The Gb interface can be routed
through the TC for SGSN connection. While GSL is used between BSC and
MFS for signaling and not for traffic, the GCH is used between the BTS and
MFS. There are up to 4 tributaries multiplexed in one Atermux.
The MFS-SGSN interface, which carries the Gb interface when there is a
dedicated MFS-SGSN link. This interface can cross a Frame Relay network
or not (direct connection MFS-SGSN).
The MSC-SGSN interface, which carries the Gb interface to/from the MFS
when there is no dedicated MFS-SGSN link. This interface can cross a
Frame Relay network or not (direct connection MSC-SGSN).
The MFS-OMC-R interface, which is a Q3 and FTP interface.

Note:

The MFS can be directly connected to the MSC (that is, without crossing the
TC) for cabling facilities, however this still results in an MFS-SGSN interface,
because the MSC only cross-connects the GPRS traffic.

2.3 GPRS in the BSS

The MFS enables GPRS in the network. The following figure shows the location
of the MFS in the network.

Figure 5: MFS in the Network

2.3.1 GPRS Configurations

The introduction of GPRS into the BSS basically requires the following
modifications:
The introduction of the Packet Control Unit (PCU). The PCU controls the
GPRS activities for one Alcatel BSS.
The introduction of the Gb interface termination function.

22 / 162

3BK 17422 5000 PGZZA Ed.06b

2 BSS Overview

The Alcatel approach for the implementation of GPRS is to group the PCU
and Gb termination functions of several BSS into one new NE called the
MFS (MFS-A9135).
The following figure shows the GPRS NEs, interfaces and channels.

Figure 6: GPRS NE, Interfaces and Channels

Within the Alcatel BSS, two communication planes are used:
The transmission plane
The PCU at the MFS converses with the CCU on the BTS side, via GCH,
transparently through the BSC.
The control plane.
The following two signaling interfaces are used:
The GPRS Signaling Link (GSL) between the MFS and BSC. This link is
used for co-ordination between the BSC and the PCU, mainly for GPRS
capacity on demand, and for GPRS paging, access request and access
grant when the CCCH is used for GPRS.
The Radio Signaling Link (RSL) between the BTS and the BSC. The
RSL is mainly used for GPRS paging, access request and access grant,
when the CCCH is used for GPRS.
The following configurations are supported:
The Gb interface can be routed via the G2 TC and A9125 Compact TC to
the SGSN across the MSC
The MFS can be connected to one OMC-R only
The MFS and all connected BSS are managed by the same OMC-R. The
BSS connected to the same MFS can be linked to different MSC.

3BK 17422 5000 PGZZA Ed.06b

23 / 162

2 BSS Overview

2.3.2 GPRS General Dimensioning and Rules

O:
Operator
Choice

Maximum Quantity (No Multiple

GPU)

Maximum Quantity (Multiple

GPU*)

S:
System
Check
BSS per A9135
MFS

O, S

22

22

BSS per A9130

MFS

O, S

21

21

BSS per GPU

GPU per BSS

O, S (on
maximum
value)

6 GPU per BSS (committed value)

GPU per A9135

MFS

O, S

24=2(11+1)

32=2*(15+1) (DS10)

GPU per
A9130MFS 1 shelf

O, S

9+1/8+1

9+1/8+1

GPU per
A9130MFS 2
shelfs

O, S

21+1

21+1

Number of GCH
simultaneously
allocated per GPU

240

240

Number of GCH
simultaneously
allocated per GP

1560

1560

Number of PDCH
reached on GP

960 PDCH CS-2

960 PDCH CS-2

912 PDCH MCS-1

912 PDCH MCS-1

784 PDCH CS-4/MCS-5

784 PDCH CS-4/MCS-5

520 PDCH MCS-6

520 PDCH MCS-6

390 PDCH MCS-7

390 PDCH MCS-7

312 PDCH MCS-9

312 PDCH MCS-9

24=2*(11+1)(AS800)

Atermux A9120
BSS-A9135MFS

17 (minimum (ater Mux-1,

nb.GPU*8))

Atermux A9120
BSS-A9130MFS

17 (minimum (ater Mux-1,

nb.GPU*6))

Cells / GPU

264

264

24 / 162

3BK 17422 5000 PGZZA Ed.06b

2 BSS Overview

O:
Operator
Choice

Maximum Quantity (No Multiple

GPU)

Maximum Quantity (Multiple

GPU*)

S:
System
Check

Cells / MFS

2000

2000

Frame Relay BC /
GPU

O, S

120

120

BVC per GPU

264

264

TRX with PDCH

per Cell

O,S

16

16

Allocated PDCH
per TRX

NSE per A9135

MFS

O, S

22=2*(11)

30=2*(15)(DS10)

NSE per
A9130MFS

O, S

21

21

GSL per BSC

4GSL/GPU

4 GSL/GPU: up to 12 GSL/BSC
minimum (12, 4*nb.GPU)

Allocated GICs per

BSC

480=4*120

2000

BVC-PTP

240

240

22=2*(11)(AS800)

NS-VC per NSE

O, S

120

120

Bearer Channel
per MFS

O, S

300

300

Bearer Channel
Per PCM

O, S

31

31

PVC per BC

: GPU concerns the logical unit, and GP is expressed for A9130 MFS.

Table 4: GPRS General Dimensioning

The following rules and recommendations apply:
CS traffic going through the MFS is transparently connected. The
cross-connection capacity in the MFS is at the 64k TS level.
Gb traffic going to the TC is routed transparently at the TC site

3BK 17422 5000 PGZZA Ed.06b

25 / 162

2 BSS Overview

There is no GPRS traffic directly on the BSC-TC Atermux, as there is no

way to connect GPRS TS between the BSC and the MFS through the TC
Maximum 1 GSL per Atermux. The GSL is located on TS28 of the 2nd
tributary
To avoid complexity, the capacity to drop 64 Kbit/s TS in the TC (e.g. for the
X.25 OMC-R link) is not used to drop Gb traffic
When frame relay (Gb) is supported on a PCM, bearer channels on this
PCM are organized
as follows:
64 Kbit/s TS (up to 31 independent TS)
Nx64 Kbit/s or bundles of TS (a bundle of TS is a list of contiguous PCM
TS belonging to the same PCM). One exception that can break the TS
contiguity is the TS16 for SS7).
Whole 2Mbit/s PCM for the MFS/SGSN interface only.
To maximize the TS bundle for the Gb, Atermux TS routed transparently at
TC site are supported by a single tributary at A interface
CS traffic coming from different Atermux (of a same BSC) cannot be merged
at the MFS site to go to the TC
The GPRS Preference Mark (GPM) is removed after migration in release B8
(it no longer exists in release B8). The value "0" of TRX Preference Mark
(TPM) in release B8 means that the concerned TRX is PS capable.
GPRS is not supported by the G1 band TRXs, nor by the inner zone TRXs
of a concentric or a multiband cell
GPRS is not supported on extended cells
A dynamic SDCCH TS cannot be used to carry GPRS traffic
The setting of a new parameter (i.e. EN_FAST_INITIAL_GPRS_ACCESS
) must interact with the MIN_PDCH parameter and the number of the
master channels in the cell. It must fulfill the following rule: MIN_PDCH Nb_TS_MPDCH > 0 if EN_FAST_INITIAL_GPRS_ACCESS = enabled.
If there are several FHS, all PS TRX have the same FHS
In BBH, the FHS for PS TRX contains the BCCH TRX, if there is a master
channel.
The AS800/DS10 MFS supports only 8 BSC/MFS links (and 32 gicGroup
instances per GPU). The A9130 MFS supports up to 13 BSC/A9130 MFS
links (and up to 52 gicGroups instances per GP).
In case of A9130 BSC Evolution mono GPU do not configured more than
448 TRX on this GPU.
The following figures show an example link configuration (3/4 GSM& 1/4
GPRS Atermux 4:1 mapping).

26 / 162

3BK 17422 5000 PGZZA Ed.06b

2 BSS Overview

MFS-TC Atermux Interface 16 Kbit/s Ater Interface Trib. 1,2,3,4 A Interface

Trib. 1,2,3,4

3BK 17422 5000 PGZZA Ed.06b

27 / 162

2 BSS Overview

Figure 7: Example 1 of a Link Configuration: 3/4 GSM& 1/4 GPRS Atermux 4:1 mapping

28 / 162

3BK 17422 5000 PGZZA Ed.06b

2 BSS Overview

3BK 17422 5000 PGZZA Ed.06b

29 / 162

2 BSS Overview

Figure 8: Example 2 of a Link Configuration: 3/4 GSM& 1/4 GPRS Atermux 4:1 mapping

2.4 LCS in the BSS

2.4.1 Prerequisites
Location Services (LCS) are new end-user services which provide the
geographical location of an MS (i.e. longitude, latitude and optionally altitude).
LCS are applicable to any target MS, whether or not the MS supports LCS, but
with restrictions concerning the choice of positioning method when LCS or
individual positioning methods are not supported by the MS.
The LCS client resides in an entity (including the MS) within the PLMN, or
in an entity external to the PLMN.
LCS provides the position of the target MS. Depending on the positioning
techniques, some LCS functions reside in the MS.

2.4.2 Logical Architecture

LCS support requires new functions in the network sub-system, and optionally,
on the radio side, depending on the positioning technique and on the network
synchronization.
These new functions are respectively:
The Gateway Mobile Location Center (GMLC)
The Serving Mobile Location Center (SMLC).
The following figure shows the generic LCS logical architecture.

30 / 162

3BK 17422 5000 PGZZA Ed.06b

2 BSS Overview

Figure 9: Generic LCS Logical Architecture

As shown above:
The GMLC is the first NE serving external Location Application (LA) access
in a GSM PLMN. The GMLC requests routing information from the Home
Location Register (HLR) via the Lh interface. After performing registration
authorization, it sends positioning requests to the MSC and receives final
location estimates from the MSC or the SGSN via the Lg interface.
The SMLC is the NE which serves the client. The SMLC manages the
overall coordination and scheduling of the resources required to performing
MS positioning. The SMLC calculates the final location estimate and
accuracy, and controls a number of LMUs to obtain the radio interface
measurements required to locate the MS in the area it serves. The SMLC
is connected to the BSS (via the Lb interface).

2.4.3 Physical Implementation

The following physical implementation rules apply:
For hardware, the existing GPU boards support the SMLC function. An
A-GPS server is required for some LCS positioning method implementation.
For software, the GPU software supports both GPRS functions and SMLC
functions, and is handled as a whole (there is no dedicated software for each
function), in that the LCS software is a module on top of the GPRS software.

3BK 17422 5000 PGZZA Ed.06b

31 / 162

2 BSS Overview

For a BSC connected to several GPUs, the SMLC function for the whole BSS
is supported by the current pilot GPU and only by this GPU (the pilot GPU
being the GPU handling procedures at the BSS level). When the pilot GPU is
re-elected (e.g. following the loss of all GSLs on the current pilot GPU), the
SMLC function restarts on the new pilot GPU.

2.4.4 Functional Requirements

The Alcatel BSS supports the LCS feature, which implies:
The SMLC, a new functional NE in the BSS, is integrated into the MFS and
configured by the OMC-R. (MFS - GPRS services - several BSCs <->
SMLC - LCS services - same BSCs).
A new Alcatel proprietary interface (BSCLP, or Lb) for LCS signaling
protocols between the BSC and the SMLC (i.e. the MFS)
Support of the following
positioning methods:
The Timing Advance (TA) positioning method, which implies the delivery
of Cell Id and TA. The TA positioning method regroups several distinct
methods (Cell Id only (CI), Cell Id + TA (CI+TA)). The TA positioning
method is the only method applicable to all the MS (regardless of
whether they support LCS or not).
The conventional GPS positioning method, based on the GPS location
estimation performed in the MS itself and provided to the SMLC
The Assisted GPS (A-GPS) positioning method, which is split into MS
Assisted A-GPS and MS Based A-GPS positioning methods, depending
where the location calculation is processed (in the network or in the MS):
MS Assisted A-GPS
The MS receives GPS Assistance Data from the SMLC (which has
received the data previously from the external GPS server), performs
GPS measurements, and returns the resulting GPS measurements to
the SMLC. The SMLC provides these GPS measurements to the
external GPS server, which computes the MS location estimate.
MS Based A-GPS
The MS receives GPS Assistance Data from the SMLC (which has
received the data previously from the external GPS server), performs
GPS measurements and location calculation, and returns its location
estimation to the SMLC.
For the last two positioning methods, a GPS-capable MS is required.
New signaling messages on the A interface for LCS, as location requests
are received from the core network
New signaling messages on the radio interface, in the case of Conventional
GPS and A-GPS positioning methods
A new Alcatel proprietary interface (SAGI) between the SMLC (i.e. the MFS)
and an external GPS server in the case of A-GPS positioning methods.

32 / 162

3BK 17422 5000 PGZZA Ed.06b

2 BSS Overview

2.4.5 GPS LCS

If a high accuracy is required, GPS positioning method(s) are preferred, when
possible.
The following figure shows the interface towards the external A-GPS server.

Figure 10: SAGI Physical Architecture

The communication between a pilot GPU supporting the SMLC function of a
given BSS and the external GPS server is supported by:
An Ethernet LAN within the MFS (which already exists, except that 2
additional Ethernet cables must be added to connect the hubs to the
external router)
The customer network, the adaptation of the IP traffic (TCP/IP over Ethernet)
to the format of the customer network being under the responsibility of an
external router ( Alcatel OmniAccess 512 which is NOT capable of allowing
the MFS to present only one IP address to the A-GPS Server).
A router is used, regardless of whether the server and the MFS are collocated
or not collocated.
The following figure shows the impact on hub connectivity.

3BK 17422 5000 PGZZA Ed.06b

33 / 162

2 BSS Overview

Figure 11: Impact on Hub Connectivity

Each hub has 24 slots to plug in the Ethernet cables.
If the MFS is equipped with only one telecom subrack on a given hub, up to 22
slots (15 GPU + 1 spare GPU + 2 JBETI + 2 control stations + 1 PC + 1 router)
can be used, which means 2 free slots on this hub.
If the MFS is equipped with two telecom subracks on a given hub, up to 23 slots
(15 GPU + 1 spare GPU + 2 JBETI + 2 control stations + 1 PC + 1 HUB + 1
router) can be used, which means one free slot on this hub.

2.4.6 BSS and Cell Configuration

LCS is an optional feature in the Alcatel BSS. This feature can be blocked by
the manufacturer. When provided to the customer, LCS can be enabled or
disabled by the operator at cell level.
To have LCS support for a cell, the operator must:
Attach the BSC to an MFS in order to declare the BSC in the MFS. This
leads to the download of the BSS configuration (GPRS and LCS-related
attributes of the BSS, even if GPRS or LCS is not supported) in the MFS
Provide the geographical coordinates of the cell
Activate GPRS for the cell (i.e. set the MAX_PDCH to > 0, so that the cell is
locked for GPRS if the operator does not want to have GPRS running on
this cell)
Configure all the required transmission resources (Ater and Gb resources)
on the GPU(s) connected to the BSC
Activate LCS (by setting the EN_LCS flag, the common BSC/MFS
parameter, to true ) on the BSS handling the cell
Enable at least one of the following flags: EN_CONV_GPS,
EN_MS_ASSISTED_AGPS, EN_MS_BASED_AGPS
Enable the EN_SAGI flag, to indicate whether the SAGI interface is
configured for the BSS (physical and transport level configuration) for
GPS LCS only.

34 / 162

3BK 17422 5000 PGZZA Ed.06b

2 BSS Overview

Ater resources are required (GSL, Gb).

The OMC-R provides centralized management of the LCS.

2.4.7 Traffic Model

LCS traffic support is provided for as a short-term requirement that will be
met in release B8, and as a long-term objective that the initial B8 system
architecture support, as follows:
Long-term objective:
38 location requests/s per 6 BSC configuration (the BSC can handle up to
1900 Erlang) and 680 location requests/s per MFS. This traffic is based
on the assumption of one location request per call (mean call duration =
80 s). This traffic requirement will remain unchanged when replacing CS
traffic by PS traffic.

Note:

With regard to the long-term objective:

The consensus is to accept one location request per CS call, which
leads to 38 location requests/s for a 1900 Erlang (448 TRX) BSC and a
call duration of 50 s.
The capacity of an MFS being limited to 8000 TRX, the total number of
location requests/s to be processed is limited to 680.
Short term requirement:
3.8 location requests/s per configuration 6 BSC, i.e. 68 location requests/s
per MFS.

2.4.8 Rules
The following rules apply:
LCS is not supported in the PS domain
Network Measurement Results (NMR) are not supported with LCS
A-GPS positioning methods can be used only if the new SAGI interface
has been installed
LCS is supported on extended cells if it is in the GPRS locked administrative
state
An MFS with a router in front presents only one IP address to the GPS
server. Reciprocally, the GPS server presents only one IP address to a
router in front of the MFS
The router is external to the MFS, which implies that it is not supervised by
the MFS. The declaration of SAGI interface is supported by a EN_SAGI
flag defined on a per BSS basis.

2.5 HSDS in the BSS

2.5.1 Definitions and Prerequisites
The High Speed Data Service (HSDS) consists of:

3BK 17422 5000 PGZZA Ed.06b

35 / 162

2 BSS Overview

A basic service to offer CS3 and CS4 for GPRS and MCS1 to MCS9
for EGPRS (two optional features)
Additional functions
such as:
Adapting radio resource allocation in order to take into account E-GPRS
MS
The ability to avoid Ater blocking.
EDGE consists of two concepts defined by ETSI:
ECSD
E-GPRS.
EGPRS is 2.5 to 3 times more efficient than GPRS, regardless of the frequency
band, the environment and the mobile velocity.
EDGE is available in Evolium BSS with minimum impact on the network.
There is no hardware impact on the MFS and the BSC, and the Evolium BTS
is EDGE- ready simply by plugging in the EDGE-capable TRX where and
when it is needed.

2.5.1.1 GPRS Coding Schemes

Two new coding schemes are proposed for GPRS in release B9:
CS-3
CS-4.
The following table lists the coding schemes and the corresponding modulation
types and maximum transmission rates.
Scheme

Modulation

Maximum Rate [Kbps] per

Radio TS

CS-4

GMSK

20

CS-3

GMSK

14.4

CS-2

GMSK

12

CS-1

GMSK

Table 5: GPRS Coding Schemes

2.5.1.2 E-GPRS Modulation and Coding Schemes

E-GPRS enables the support of data transmission at a bit rate which exceeds
the capabilities of GPRS.
E-GPRS relies on new modulation and coding schemes on the air interface,
allowing a data throughput which is optimized with respect to radio propagation
conditions (referred to as link adaptation).
The basic principle of link adaptation is to change the Modulation and Coding
Schemes (MCS) according to the radio conditions. When the radio conditions

36 / 162

3BK 17422 5000 PGZZA Ed.06b

2 BSS Overview

worsen, a more protected MCS (more redundancy) is chosen for a lower

throughput. When the radio conditions become better, a less protected MCS
(less redundancy) is chosen for a higher throughput.
Nine modulation and coding schemes are proposed for enhanced packet data
communications (E-GPRS), providing raw RLC data rates ranging from 8.8
kbit/s (the minimum value under the worst radio propagation conditions per
TS) up to 59.2 kbit/s (the maximum value achievable per TS under the best
radio propagation conditions). Data rates above 17.6 kbit/s require that 8-PSK
modulation is used on the air interface, instead of the regular GMSK.
The following table lists the coding schemes and the corresponding modulation
types and maximum transmission rates.
Scheme

Modulation

Maximum Rate [Kbps] per

Radio TS

MCS-9

8-PSK

59.2

MCS-8

8-PSK

54.4

MCS-7

8-PSK

44.8

MCS-6

8-PSK

29.6 A/27.2 A padding

MCS-5

8-PSK

22.4

MCS-4

GMSK

17.6

MCS-3

GMSK

14.8 A/13.6 A padding

MCS-2

GMSK

11.2

MCS-1

GMSK

8.8

Table 6: EGPRS Modulation and Coding Schemes

2.5.1.3 HSDS
HSDS provides support for GPRS with CS1 to CS4, and for E-GPRS with
MCS1 to MCS9.
There are 3 families of modulation and coding schemes:
Family A: MCS3, MCS6, MCS8 and MCS9
Family B: MCS2, MCS5 and MCS7
Family C: MCS1 and MCS4.
Each family has a different unit of payload:
37 bytes: family A
34 bytes: family A padding (MCS3, MCS6 and MCS8)
28 bytes: family B
22 bytes: family C.

3BK 17422 5000 PGZZA Ed.06b

37 / 162

2 BSS Overview

The different code rates within a family are achieved by transmitting a different
number of payload units within one radio block.
When 4 payload units are transmitted, these are split into 2 separate RLC
blocks (i.e. with separate sequence numbers).
When a block has been retransmitted with a given MCS, it can be retransmitted
(if needed) via ARQ with a more robust MCS of the same family.
The following figure shows the choice of modulation schemes.

Figure 12: Choice of Modulation Scheme

The choice of modulation schemes is based on the measurement of the
bit error probability (BEP).
The coding scheme and the radio modulation rates are modified to increase the
data traffic throughput of a given radio TS. This implies that the increase of
throughput is handled on the Abis and Ater interfaces (previously, for each radio
TS in use, only a 16kb/s nibble was allocated on both interfaces).

2.5.1.4 Ater interface

In order to handle a throughput higher than 16Kb/s on the Ater interface,
several Ater nibbles are dynamically allocated by MFS Telecom.

2.5.1.5 Abis Interface

On the Abis interface, to handle a throughput higher than 16Kb/s, several
Abis nibbles are also used. The configuration is dynamic for TRX inside
the same BTS.
A number of 64k EXTS (Extra TS) are defined for each BTS by O&M. This
group of TS replaces the number of transmission pool types used previously.

38 / 162

3BK 17422 5000 PGZZA Ed.06b

2 BSS Overview

Due to the increase in Abis resource requirements, a single Abis link may not
be enough to introduce HSDS into a large BTS configuration. In this case, a
second Abis link is required (see Two Abis Links per BTS (Section 7.9) ).

2.5.1.6 M-EGCH
This term is used to refer to a link established between the MFS and the BTS.
One M-EGCH is defined per TRX.

2.5.1.7 Enhanced Transmission Resource Management

A dedicated manager sequences the GCH establishment, release, redistribution
or pre-emption procedures.
The transmission resource manager is on the MFS/GPU level. It handles both
Abis and Ater resources (GCH level).
It is in charge of:
Creating and removing the M-EGCH links
Selecting, adding, removing, and redistributing GCHs over the M-EGCH
links
Managing transmission resource preemptions
Managing Abis and/or Ater congestion states
Optionally, monitoring M-EGCH links usage, depending on the (M)CS of
their supported TBFs (UL and DL).

2.5.1.8 Abis Nibble Sharing Rules

To ensure that each cell of a given BTS is able to support PS traffic at all times,
there must be a minimal number of Abis nibbles for every cell in the BTS.

2.5.1.9 Ater Nibble Sharing Rules

A given amount of Ater transmission resource is allocated per GPU. Afterwards,
this Ater transmission resource is shared among the 4 DSPs of the GPU,
via the GPU on-board Ater switch.
Only 64K Ater TS are handled at GPU level between the DSPs. Therefore,
a 64K Ater TS is moved from one DSP to another if, and only if, all of its
four 16K Ater nibbles are free. This is the unique restriction concerning Ater
nibble sharing at GPU level.

2.5.2 Transmission Power

2.5.2.1 GMSK Output Power
GMSK is a constant amplitude modulation.

2.5.2.2 8-PSK Output Power

For one given TRE, the maximum output power is lower in 8-PSK than in GMSK
because of the 8-PSK modulation envelope which requires a quasi-linear
amplification.
The TRE transmit power in 8-PSK does not exceed the GMSK transmit power
in the sector and in the band.
8-PSK is a varied digital phase modulation.
Leveling of 8-PSK Output Transmission Power is new in release B8.

3BK 17422 5000 PGZZA Ed.06b

39 / 162

2 BSS Overview

For a TRE, there is a major difference in the output transmission power between
the GMSK and the 8-PSK modulation. This is shown in the following table.
G4 TRE Medium Power

G4 TRE High Power

GMSK (CS1-CS2/MCS1-MCS4)

46.5 dBm

47.8 dBm

8-PSK (MCS5-MC9)

41.8 dBm

44.0 dBm

Table 7: GMSK and 8-PSK Transmission Power Differences

Note that the operator is allowed to allocate the E-GPRS TBF on the BCCH
TRX, and the BCCH frequency must have a quite stable radio transmission
power.
Due to this constraint, the 8-PSK output transmission power is not leveled per
sector, in order to effectively exploit the TRE capability, and the E-GPRS TRXs
are preferably mapped to a TRE with the best 8-PSK capability.
The Modulation Delta Power is the difference between the GMSK output power
of the sector for the TRE band, and the 8-PSK output power of the TRE.
According to the 8-PSK delta power value, a TRE is called "High Power" or
"Medium Power". 8-PSK High Power Capability is true if Modulation Delta
Power is less than 3 dB.

2.5.3 Rules
The following rules apply:
TCU Allocation:
Extra Abis TS are allocated only on the FR TCU
RSL, OML and TCH are mapped on a TCU, regardless of extra Abis TS
Extra Abis TS are moved automatically from one TCU to another.
Allocation priorities (from highest to lowest)
PS TRX/TRE are ordered according to the following rules:
PS allocation is preferred on the BCCH TRX
The TRE hardware capability
The DR TRE configuration
The maximum PDCH group criterion
The TRX Identifier.
TRX TRE mapping:
G4 TRE or M5M is preferentially used for PS allocation
TRE with 8-PSK HP capability is preferentially used for PS allocation
PS traffic is allocated
in priority to:
G4 TRE with 8-PSK HP capability
G4 TRE without 8-PSK HP capability

40 / 162

3BK 17422 5000 PGZZA Ed.06b

2 BSS Overview

G3 TRE.
DR TRE is preferentially used for CS allocations. DR is reserved for
CS traffic
The DR must be assigned
in priority of:
G3 TRE
G4 TRE without 8-PSK HP capability
G4 TRE with 8-PSK HP capability.
TRE and TRX are classified
according their characteristics:
Full-rate, high power, E-GPRS capable TRE
Dual-rate, high power, E-GPRS capable TRE
Full-rate, medium power, E-GPRS capable TRE
Dual-rate, medium power, E-GPRS capable TRE
Full-rate, non-E-GPRS capable TRE
Dual-rate, non-E-GPRS capable TRE
When PS_Pref_BCCH_TRX = True, then the TRX supporting the
BCCH is mapped on the best TRE

3BK 17422 5000 PGZZA Ed.06b

41 / 162

2 BSS Overview

The TRE of the preferred class must be mapped to a TRX of the

preferred class
In the case where HSDS is not activated, only a reduced adjust is
performed, as shown below:

TRX ranking:
PS capable TRXs are ranked according to the following criteria, for
PS traffic
TRX supporting the BCCH, if PS_Pref_BCCH_TRX = True
TRX capability (E-GPRS capable, high power, then E-GPRS capable,
medium power and finally, non-E-GPRS capable)
Dual-rate capability (FR, then DR)
Size of the PDCH group.
This ranking will be used in the reverse order for CS traffic
BTS
A mix of the G4 TRE medium power and G4 TRE high power (that offers
a higher output power useful for 8-PSK modulation) in the same Evolium
BTS is allowed.
PS Capability of BTSs
Only Evolium BTS (including Evolium Micro-BTS) support the HSDS, but
the PS capability is function of the TRE generation. This is shown in
the following table.
TRE generation

PS Capability

G3 TRE and M4M

CS1 to CS4

G4 TRE and M5M

CS1 to CS4 and MCS1 to MCS9

To support MCS1 to MCS9, an Evolium BTS must be upgraded with

some G4 TRE

42 / 162

3BK 17422 5000 PGZZA Ed.06b

2 BSS Overview

A mix of G3 and G4 TRE in the same Evolium BTS is allowed. From a

software point of view, there are no specific rules that define the position
of G3 and G4 TRE: their position in the BTS rack is free
MFS capacity:
The MFS capacity is defined by the maximum throughput of the GPU
The maximum throughput of the GPU is
the minimum of:
PPC maximum throughput
4 x DSP maximum throughput.
For example, for A9135 MFS, the maximum throughput for a DSP, in one
direction, is about 800 kbit/s for pure GPRS and 1 Mbit/s with E-GPRS
(with some assumptions regarding MCS and CS distribution)
The support of 8PSK in UL is optional for the MS.

2.6 PLMN Interworking

A foreign PLMN is a PLMN other than the PLMN to which OMC-R internal cells
belong. Only cells external to the OMC-R can belong to a foreign PLMN. All
internal cells must belong to their own PLMN. Both OMC-R owned cells and
cells which are external to the OMC-R can belong to the primary PLMN.
The Alcatel BSS supports:
Incoming inter-PLMN 2G to 2G handovers
Outgoing inter-PLMN 2G to 2G handovers, as an optional feature
The operator can define handover adjacency links towards external cells
belonging to a foreign PLMN, (i.e. handovers from a serving cell belonging
to the primary PLMN towards a target cell belonging to a foreign PLMN).
Inter-PLMN 2G to 2G cell reselections
The Alcatel BSS allows the operator to define cell reselection adjacency
between two cells belonging to different primary PLMN (which must
therefore be owned by two different BSC).
Multi-PLMN, as an optional feature
The Multi-PLMN feature allows operators to define several primary PLMN,
in order to support network sharing (Tool Chain, OMC-R, MFS, Abis
transmissions, and also BTS, via rack sharing). Inter-PLMN handovers and
cell reselections between two different primary PLMN are supported.
The BSC itself cannot be shared and therefore remains mono-PLMN (i.e. all
BSC owned cells belong to the same primary PLMN).
The Alcatel BSS supports several primary PLMN (at least one, up to four).
An OMC-R therefore manages at least one (primary) PLMN and up to eight
PLMN (four primary and four foreign). Both cell reselections and handovers
are allowed between two cells which belong to different primary PLMN.
The operator can define handover adjacency between two cells belonging to
different primary PLMN (which must therefore be owned by two different
BSC).

3BK 17422 5000 PGZZA Ed.06b

43 / 162

2 BSS Overview

The OMC-R (and the Tool Chain) is by definition of the feature itself always
shared between the different primary PLMN. On the other hand:
The MFS can be shared
The BSC cannot be shared
The BTS can be shared up to the rack sharing level (no radio part sharing)
The Abis transmission part can be shared
The transcoder part can be shared.
The outgoing inter PLMN handovers feature is a prerequisite for the multi-PLMN
feature.
It is not allowed to modify the "PLMN friendly name" of a cell, even if the
"Multi-PLMN" feature is active and several PLMN have been defined on the
OMC-R side.
The primary PLMN cannot be added, removed or modified online.
Customers no longer need to ensure CI (or LAC/CI) unicity over all PLMN
involved in their network.
With regard to clock synchronization, the only constraint is that when the
MFS is connected to different SGSN, these SGSN are not synchronized
together, therefore, central clocking and cascade clocking cannot be used on
the MFS side.

44 / 162

3BK 17422 5000 PGZZA Ed.06b

3 BTS Configurations

3 BTS Configurations
BSS Overview describes the Alcatel BSS, and corresponding features and
functions.
The following figure shows the location of the BTS inside the BSS.

Figure 13: BTS in the BSS

3BK 17422 5000 PGZZA Ed.06b

45 / 162

3 BTS Configurations

3.1 BTS Generation Summary

The following table lists the successive BTS generations, along with the
corresponding commercial name.
G1 BTS

G2 BTS

Evolium BTS

Evolium Evolution

G1 BTS

G2 BTS

G3 BTS

G4 BTS (*)

MK2

Mini

Std

G3

M4M

G3.5

G3.8

G4.2

M5M

MBS

: Note that G3.8 and G4.2 are the TD used names for respectively Evolium Evolution Step 1 and Evolium Evolution
Step 2.

Table 8: BTS Generation Summary

The BTS are grouped into the following families:
A9110 BTS, which include the micro BTS M4M, and the A9110-E for
M5M micro BTS
A9100 BTS, which include all Evolium BTS, but not the micro BTS.

3.2 Evolium BTS

3.2.1 Evolium BTS Architecture
The Evolium BTS is designed with the following three levels of modules to
cover many cell configuration possibilities, including omni or sectored cells
configurations:
The antenna coupling level, which consists of ANX, ANY and ANC
The TRX, which is implemented as a TRE, and handles the GSM radio
access
The BCF level implemented in the SUM, which terminates the Abis interface.

Note:

The above-mentioned architecture does not include micro BTS.

3.2.2 Evolium BTS Configuration

The Evolium BTS family began with the G3 BTS, whose architecture is
described in Evolium BTS Architecture (Section 3.2.1).
Further evolutions were introduced, with the G3.5 and G4 variants:
G3.5 BTS, which is a G3 BTS with new power supply modules
G4 BTS Step 1 (also referred to within TD as the G3.8), which is a G3.5
BTS in which
the following modules have been redesigned:
SUMA, which is the new SUM board
ANC, which is a new antenna network combining a duplexer and
a wide band combiner

46 / 162

3BK 17422 5000 PGZZA Ed.06b

3 BTS Configurations

New power supply modules which are compatible with BTS subracks.
G4 BTS Step 2 (also referred to within TD as the G4.2) introduces a new
TRE with EDGE hardware capability,
including:
CBO, which is the compact outdoor BTS
MBS, which is provides multistandard cabinets with
the following G4.2 modules:
MBI3, MBI5 for Indoor
MBO1, MBO2 for Outdoor
The Evolium BTS family also includes
the two following micro BTS:
M4M
M5M.

3.2.2.1 Product Presentation

There are different types of Evolium cabinets:
The indoor cabinet, which exists in different sizes: Mini, Medi, MBI3 and
MBI5
The outdoor cabinet, which exists in different sizes and packaging: Mini,
Medi, CPT2, CBO, MBO1 and MBO2

3.2.2.2 Evolium BTS Rules and Dimensioning

The following table lists the extension and reduction capacity rules for the
Evolium BTS.
Extension / Reduction

Configuration

Physical

Evolium BTS

3BK 17422 5000 PGZZA Ed.06b

Minimum

Maximum

Minimum

1 TRE

Up to 12
TRE1 to 6
Sectors

1 TRE

Logical

1 TRE

47 / 162

3 BTS Configurations

Extension / Reduction

Configuration

Physical

Logical

Minimum

Maximum

Minimum

M4M
Micro-BTS

2 TRE

Up to 6 TRE1
to 6 Sectors

2 TRE

1 TRE

M5M
Micro-BTS

2 TRE

Up to 12
TRE1 to 6
Sectors

2 TRE

1 TRE

Table 9: Evolium BTS Minimum and Maximum Capacity

The following table summarizes the typical GSM 900, GSM 1800 and GSM
1900 configurations.
These configurations constitute only a subset of the possible configurations.
Network

GSM 900 MHz

Indoor /
Outdoor

Indoor

Cabinet
size

Mini

Medi

Mini

Medi

Mini

Medi

Mini

Medi

Number
of TRE1
sector

1x2 to
1x4

1x2 to
1x12

1x2 to
1x4

1x2 to
1x12

1x2 to
1x4

1x2 to
1x12

1x2 to
1x4

1x2 to
1x12

2 sectors

2x1 to
2x2

2x2 to
2x6

2x1 to
2x2

2x2 to
2x6

2x1 to
2x2

2x2 to
2x6

2x1 to
2x2

2x2 to
2x6

3 sectors

3x1

3x1 to
3x4

3x1 to
3x2

3x1 to
3x4

3x1

3x1 to
3x4

3x1 to
3x2

3x1 to
3x4

GSM 1800 MHz, GSM 1900 MHz

Outdoor

Indoor

Outdoor

Table 10: Typical GSM 900 and GSM 1800/1900 Configurations

The following table summarizes the typical Multiband 900/1800 BTS
configurations.
These configurations constitute only a subset of the possible configurations.
Network Multiband BTS or Multiband Cell
Cabinet size

Medi

Number of TRE4 sectors

2x2 GSM 900 & 2x4 GSM 1800

2x4 GSM 900 & 2x2 GSM 1800

48 / 162

3BK 17422 5000 PGZZA Ed.06b

3 BTS Configurations

Network Multiband BTS or Multiband Cell

6 sectors

3x2 GSM 900 & 3x2 GSM 1800 (outdoor only)

Diversity

4 sectors : Yes
6 sectors : Yes

Table 11: Typical Multiband Configuration G3 BTS

3.2.2.3 Extended Cell Configuration

Up to 12 TRX CS+PS capable, including the BCCH TRX can be offered in each
cell (inner + outer).
M4M and M5M do not support extended cell configurations.
Only one extended cell per BTS is possible.
Extended cell is not supported by SUMP.

3.2.2.4 Mixture of M5M and M4M BTS

The following 4 configurations rules are defined for pure M5M and M4M/M5M
mixed configurations:
A maximum of 3 hierarchic levels ( master, upper and lower slave ) are
allowed
Each M4M upper slave terminates the master-slave link, which is the
Inter Entity Bus (IEB)
M4M is not allowed in the lower slave position
M5M must be set as master in M4M/M5M mixed configurations.

3BK 17422 5000 PGZZA Ed.06b

49 / 162

3 BTS Configurations

3.2.2.5 Mixed configuration G3 and G4

In case of mixed hardware configuration in a cell with both G3 and G4 TREs
in the same cell, it is recommended to map to E-GSM TRX on G4 TRE and
P-GSM TRX on G3 TRX.
Under some conditions, the BSC does not guarantee that the PS TRXs having
the highest priority for PS allocations are mapped on the G4 TREs.

3.3 G2 BTS
The following rules apply:
Only G2 BTS with DRFU are supported in release B8
The FUMO in G2 BTS must be replaced by the DRFU, before migration to
release B7/B8 BSS
G2 BTS release B7.2 functions are unchanged.
The following table lists the maximum and minimum capacity for G2 BTS..
Extension / Reduction

Configuration

Physical
BTS

Minimum

Maximum

Minimum

G2

1 TRE

1 Sector:8 TRE

1 TRE

Logical

1 TRE

Table 12: G2 BTS

3.4 G1 BTS
Only MKII G1 BTS with DRFU and DRFE are supported in release B9, and
release B7.2 functions are unchanged.
G1 BTS are allowed to have channel combinations other than TCH.
G1 BTS can support GPRS, unless they belong to the inner zone.

3.5 BTS Synchronization

In terms of dimensioning, from a software point of view, there can but up to
3 BTS slaves.
Depending on the hardware configuration, the number of BTS slaves can
be reduced to 2 or 1 BTS.
The following table lists the type of slave BTS which can be synchronized to the
master and the number of BTS slaves, for each BTS master.
Master

Slaves

Hardware Limitation

Software Limitation

G2 standard

G2

G2 standard

Evolium

50 / 162

3BK 17422 5000 PGZZA Ed.06b

3 BTS Configurations

Master

Slaves

Hardware Limitation

Software Limitation

G2 mini

G2

G2 mini

Evolium

Evolium medi/mini

G2

Evolium medi/mini

Evolium

3 BTS slaves maximum

in a chain configuration

Table 13: BTS Synchronization

3.6 Physical Channel Types

3.6.1 GSM
In terms of TS content, there are several possible configurations, the most
relevant of which are:
Traffic channels (TCH)
Signaling channels:
BCC = FCCH + SCH + BCCH + CCCH
CBC = FCCH + SCH + BCCH + CCCH + SDCCH/4 + SACCH/4
SDC = SDCCH/8 + SACCH/8.

Note:

Two CBCH channels can be defined for cells used for SMS-CB:
The basic CBCH channel
The extended CBCH channel.
If the basic CBCH channel is configured, the extended CBCH channel can be
optionally configured. The extended CBCH channel is managed in the same
manner as the basic CBCH channel (2 instances of scheduling per cell).
When the initial SDCCH number in a cell is small, a reduction in the number
of SDCCH due to the configuration of the CBCH can increase the SDCCH
average load. In such a case, the operator may need to add one SDCCH TS.

3.6.2 GPRS
When the TRX_PREF_MARK parameter is set to 0, GPRS service is available.
If it is set to 1, GPRS is not supported in the cell.
GPRS radio time-slots (PDCH) are dynamically allocated according to the
following, customer-defined parameters:
MIN_PDCH defines the minimum number of PDCH TS per cell
MAX_PDCH defines the maximum number of PDCH TS per cell
MAX_PDCH_HIGH_LOAD defines the maximum number of PDCH TS per cell

in the case of CS traffic overload.

3BK 17422 5000 PGZZA Ed.06b

51 / 162

3 BTS Configurations

Those parameters allow the operator to prioritize CS traffic versus GPRS traffic
in order, for example, to avoid a QoS drop while introducing GPRS.
The following quality parameters can also be used:
N_TBF_PER_SPDCH defines the number of MS that can share the same PDCH

The number of Temporary Block Flow (TBF) allocated on one or more

PDCHs.

3.7 Frequency Band Configuration

3.7.1 Overview
E-GSM is used for the whole GSM-900 frequency band, i.e. the primary band
(890-915 MHz / 935-960MHz) plus the extension band (880-890 MHz/925-935
MHz), this corresponds to 174 addressable carrier frequencies and leads to an
increase of 40 % against the 124 frequencies in the primary band.
Frequency span

(U)ARFCNs

Uplink frequencies

Downlink frequencies

P-GSM band

1.. 124

890.2 to 915.0 MHz

935.2 to 960.0 MHz

G1 band

975.. 1023, 0

880.2 to 890.0 MHz

925.2 to 935.0 MHz

GSM850 band

128... 251

824.2 MHz to 848.8 MHz

869.2 MHz to 893.8 MHz

DCS1800 band

512.. 885

1710.2 to 1784.8 MHz

1805.2 to 1879.8 MHz

DCS1900 band

512.. 810

1850.2 to 1909.8 MHz

1930.2 to 1989.8 MHz

3.7.2 Compatibility
The following table shows BTS generation equipment versus radio band.
Multiband (BTS or Cell)
Yes = a

GSM 850

GSM 900

GSM
1800

GSM
1900

850/1800

850/1900

900/1800

900/1900

G3/G4
BTS

E-GSM

M5M
BTS

E-GSM

M4M
BTS

N.A

N.A

N.A

N.A

N.A

G2 BTS

N.A

E-GSM

N.A

N.A

N.A

N.A

G1 MKII
BTS

N.A

N.A

N.A

N.A

N.A

N.A

N.A

52 / 162

(*)

3BK 17422 5000 PGZZA Ed.06b

3 BTS Configurations

: The BTS can be a G3 BTS, but the TRE is a G4.2 TRE.

Table 14: Frequency band configuration

3.7.3 Rules
From functional point of view, two types for the multiband behavior:
Multiband BTS: The frequency bands (850/1800, or 850/1900, or 900/1800) are
used in different sectors of the BTS. There are 2 BCCH carriers, one in the
sector with frequency band 1, one in sector with frequency band 2.
Multiband cell: The sector (cell) is configured with TRX in band 1, and TRX in
band 2. Only one BCCH carrier is configured for the sector.

3.8 Speech Call Traffic Rates

There are no compatibility limitations between BTS and TC generations.
The following table shows the hardware transmission compatibility.
Yes =a

A9125 TC ( MT120)

G2 TC(DT16/MT120)

Evolium, M4M, M5M

G2 + DRFU

G1 MKII + DRFU

Table 15: Hardware Transmission Compatibility

The following table shows the different rates available over different generations
of equipment.
BTS

Traffic Rate

Evolium, M4M, M5M

FR,DR,EFR,AMR

G2 + DRFU
G1 MKII + DRFU
Table 16: Speech Call Traffic Rates
Dual Rate (DR) (HR+FR)
Full Rate (FR)
Enhanced Full Rate (EFR)
Adaptive Multi-Rate speech codec (AMR).

3BK 17422 5000 PGZZA Ed.06b

53 / 162

3 BTS Configurations

3.9 Adaptive Multi-rate Speech Codec

3.9.1 Overview
Adaptive Multi-Rate (AMR) is basically a set of codecs, of which the one with
the best speech quality is used, regardless of radio conditions.
Under good radio conditions, a codec with a high bit-rate is used. Speech is
encoded with more information so the quality is better. In the channel coding,
only a small space is left for redundancy.
Under poor radio conditions, a codec with a low bit-rate is chosen. Speech is
encoded with less information, but this information can be well protected due to
redundancy in the channel coding.
The BSS dynamically adapts the codec in the uplink and downlink directions,
taking into account the C/I measured by the BTS (for uplink adaptation) and by
the MS (for downlink adaptation).
The codec used in the uplink and downlink directions can be different, as the
adaptation is independent in each direction.

3.9.2 Rules and Dimensioning

The following table provides a list of AMR codecs.
Codec Bit Rate

Full Rate

12.2 Kbit/s

10.2 Kbit/s

7.95 Kbit/s

X(*)

7.40 Kbit/s

6.70 Kbit/s

5.90 Kbit/s

5.15 Kbit/s

4.75 Kbit/s

Half Rate

: Not supported by the Alcatel BSS.

Table 17: AMR Codec List

During a call, a subset of 1 to 4 codecs is used, configured by O&M on a
per BSS basis.
A different number of codecs and different subsets can be defined for FR (1
to 4 codecs out of the 8 codecs available), and for HR (1 to 4 codecs out
of the 5 codecs available).
The codec subset is the same in uplink and downlink.

54 / 162

3BK 17422 5000 PGZZA Ed.06b

3 BTS Configurations

3.10 Data Call Traffic

The following table shows the data service rate available over different
generations of equipment.
Yes = a

Up to 9.6 Kbit/s

GPRSCS-1 and
CS-2

GPRSCS-3 and
CS-4

EGPRSMCS-1 to
MCS-9

G4 TRE and M5M

G3 TRE and M4M

G2 + DRFU

G1 MKII + DRFU

Table 18: Data Call Traffic

3.11 OML and RSL Submultiplexing

The following table shows the submultiplexing OML with RSL over different
generations of equipment.
Yes = a

RSL&OML Statistical
Multiplex
RSL &
OMLTS
64Kbit/s

RSL 16Kbits 64 Kbit/s

StaticMultiplex

16 Kbit/s

Evolium,
M4M, M5M

G2 + DRFU

G1 MKII +
DRFU

Table 19: OML and RSL Submultiplexing

3.12 Cell Configurations

3.12.1 Cell Types
The BSS supports a set of cell configurations designed to optimize the reuse
of frequencies.
The following profile type parameters are used to define the cells:
Cell dimension
Macro up to 35 Km but up to 70Km with extended cells. Micro up to 300
meters.

3BK 17422 5000 PGZZA Ed.06b

55 / 162

3 BTS Configurations

Cell Coverage
There are 4 types of coverage: single, lower (overlaid), upper (umbrella),
and indoor.
Cell Partition
There are 2 types of frequency partition: normal or concentric.
Cell Range
The cell range can be either normal or extended.
Cell Band Type
A cell belongs to 850, 900, 1800 or 1900 bands, or to 2 frequency bands in
the case of a multiband cell.
The following table describes the cell types.
Cell Type

Dimension

Coverage

Partition

Range

Micro

Micro

Overlaid

Normal

Normal

Single

Macro

Single

Normal

Normal

Mini

Macro

Overlaid

Normal

Normal

Extended

Macro

Single

Normal

Extended

Umbrella

Macro

Umbrella

Normal

Normal

Concentric

Macro

Single

Concentric

Normal

Umbrella-Concentric Macro

Umbrella

Concentric

Normal

Indoor Micro

Indoor

Normal

Normal

Micro

Table 20: Cell Types

Non extended, non concentric mono-band cells of any type can be converted to
multiband cells by adding TRXs of a different band.
The Alcatel BSS cell types for multiband cells are:
Single/multiband which, in the internal model, is represented by a concentric
cell
Umbrella/multiband which, in the internal model, is represented by a
concentric umbrella cell
Mini/multiband which, in the internal model, is represented by a cell of a
specific type
Micro/multiband which, in the internal model, is represented by a cell
of a specific type
The micro concentric, mini concentric, indoor concentric cells must be
multiband (the allowed FREQUENCY_RANGE is PGSM-DCS1800 or
EGSM-DCS1800). This restriction does not apply to external cells.
The Unbalancing TRX Output Power per BTS sector allows unbalanced
configurations on the same antenna network. This configuration behaves as a

56 / 162

3BK 17422 5000 PGZZA Ed.06b

3 BTS Configurations

concentric cell, where the output power balancing is performed on a zone basis
instead of on the sector basis. Furthermore for 3 TRXs per ANc configuration,
2 TRXs are used in combining mode on the first antenna path and 1 TRX is
connected in by-pass mode on the second antenna path. This leads to the
same sort of concentric cell configuration as in the case TREs with different
output power are used. When is activated, it is recommended to the operator to
set the TPM parameter to 0 for all TRX of the outer zone.
For the extended cell the following applies:
(E)GPRS is supported
NC2 mode is not offered
The Network Assisted Cell Change is not allowed
The (Packet) PSI status procedure is not allowed
The extended inner cell because it is barred is not declared in the neighbor
cells reselection adjacencies
No MPDCH is configured in the extended cell
Up to 12 TRX CS+PS capable, including the BCCH TRX can be offered in
each cell (inner + outer)
The extended inner and outer cells are in the same Routing Area
No frequency hopping is allowed neither in the extended inner cell nor in the
extended outer cell for (E)GPRS TRX
In extended cell, the allowed coding schemes are:
CS1... CS4, MCS1...MCS9 in the inner cell for the both directions
[middot] CS1... CS4, MCS1...MCS4 in the outer cell for the both
directions.

3.12.2 Frequency Hopping

The frequency hopping types do not reflect the technology used, but rather
the structure of the hopping laws.
The following table shows the hopping types supported in release B9.

Hopping Type

Supported in B9

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

: This hopping mode works only with M1M, M2M that are obsolete.

3BK 17422 5000 PGZZA Ed.06b

57 / 162

3 BTS Configurations

BBH (baseband hopping): each transceiver (TRX) is transmitting on one fixed

frequency. Hopping is performed by switching the mobiles from burst to burst to
the different carrier units (CU) of the BTS. Within the BTS the baseband part
(FU) is separated from the RF-part (CU). The amount of hopping frequencies
N(hop) is determined by the number of TRXs N(TRX): N(hop) <= N(TRX). A
BTS equipped with only one TRX cannot perform baseband hopping.
RH (radio hopping or synthesizer frequency hopping): The TRX do not get
fixed frequency assignment, they can change their frequency from TS to
TS according to a predefined hopping sequence. The number of applicable
hopping frequencies can be larger then the number of equipped TRX: N(hop)
>= N(TRX).
Inside an FHS it is allowed to mix frequencies belong to the P-GSM band and
the G1 band; other mixings are not allowed.

3.12.3 Shared Cell

3.12.3.1 Overview
Each BTS can manage one (all BTS generations) or several cells (from G3
BTS). In the case of a cell shared by several BTS, is possible to support
up to 16 TRX.
Only the A9100 Evolium BTS supports shared cells. In the case of a monoband
shared sector, every type of cell is supported except for extended cells. In the
case of a bi-band shared sector, only concentric cells are supported.
In general, a BTS comprises several physical sectors. Until release B7, a cell
was mapped on a physical sector. The operator can associate 2 physical
sectors pertaining to different BTS with one shared sector. This shared sector
can be mono or bi-band and it can support one cell as a normal sector. It takes
the identity of one of the physical sectors. Between the 2 sectors, one is the
main sector, and the other is the secondary sector.
This allows:
Existing cells to be combined into one (for example, one 900 cell and one
1800 cell in order to get a multi band cell)
Existing cells can be extended only by adding new hardware in a new
cabinet, not touching the arrangement of the existing BTSs
Support for 3x8 in 2 racks.
The linked BTS can still be connected on the Abis side, by the same or a
different Abis link, the same or different Abis TSU, or by same or different
multiplexing schemes.
The shared cell requires a specific attribute that must be defined by the
operator (either primary or secondary) at the TRX level.

3.12.3.2 Rules
The following rules apply:
Clock synchronization
The BTS in a shared cell must be synchronized.
Hardware coverage
For G3 BTS and beyond, generations can be mixed as long as master/slave
configurations are possible. Cell sharing is not supported on M5M and
M4M, because they cannot be clock synchronized.

58 / 162

3BK 17422 5000 PGZZA Ed.06b

3 BTS Configurations

Output Power.
When a certain sector is extended with another sector, transmission output
powers can be different. In this case, a software adjustment of the output
power is performed. There is a separate power adjustment for 900MHz and
1800 MHz. In all cases, if there is a power discrepancy, only an alarm is
sent, without any further consequences, and sectors continue to transmit
traffic. In a cell shared over 2 BTSs, only one sector (main or secondary)
can support GPRS traffic (not both).

3.12.3.3 Dimensioning
The following dimensioning rules apply:
A BTS can manage up to 6 physical sectors (unchanged)
Each physical sector can have up to 12 TRX (unchanged)
The cell reselection capability per cell on both BSC and MFS OMC-R
interfaces and telecom SW is 64 adjacencies.

3.13 SDCCH Allocation

3.13.1 Overview
The dynamic SDCCH allocation feature is a new mechanism which provides
automatic (the optimal number of) SDCCH in a cell, which translates as a set of
dynamic SDCCH/8 TS, used for TCH traffic or for SDCCH traffic, depending on
the requirements. SDCCH management is handled by the operator in RNUSM.
It is also possible to customize the SDCCH templates by choosing from a list
of 10 patterns managed by the OMC-R to define SDCCH configurations.
The predefined template default configuration is the dynamic configuration.
16 sub-templates are associated with each template, corresponding to the
possible number of TRXs in a cell, because no algorithm can be defined to
evaluate the number of SDCCH depending on the number of TRX in a cell.

3.13.1.1 General Principles

The following general principles apply:
Dynamic SDCCH allocation only deals with SDCCH/8 TS. It is not necessary
to add or suppress a SDCCH/3, or a SDCCH/4, or a SDCCH/7 TS.
Static SDCCH/8 TS cannot be used as TCH
Dynamic SDCCH/8 TS are allocated for SDCCH only if all the static
SDCCH/8 TS (mapped on the TCU(s) whose load state is not Very High
Overload ) are busy (i.e. all its sub-channels are busy).
It is not possible to drop a TCH call to free a TS for SDCCH/8 allocation
A TCH call is preferably not allocated in the area of the dynamic SDCCH/8
TS
In the case of fault on a RSL, there is recovery of dynamic SDCCH.
The default dynamic configuration template considers that:
Cells with 1 or 2 TRX are configured with the combined mode

3BK 17422 5000 PGZZA Ed.06b

59 / 162

3 BTS Configurations

Cells with more than 2 TRX are configured with the non combined mode.
In the case of manual configuration (not assisted), the operator configures the
static and dynamic SDCCH TS for the cell but cannot reuse the configuration
for other cell.

3.13.1.2 Terminology
A static SDCCH/x TS refers to one physical TS on the Air interface containing x
SDCCH sub-channels (x = 3, or 4, or 7, or 8, depending whether the TS is
SDCCH/3, or SDCCH/4, or SDCCH/7, or SDCCH/8).

3.13.2 Rules
The following rules are applied for the default or non-default configuration
of dynamic and/or static SDCCH:
CBCH is configured on a static SDCCH/8 or SDCCH/4 TS
Combined SDCCHs (SDCCH/4 + BCCH) are always static
In order to avoid incoherent allocation strategies between SDCCH and
PDCH, a dynamic SDCCH/8 TS cannot be a PDCH (it can not carry
GPRS traffic)
The operator must configure at least one static SDCCH/8 or SDCCH/4
TS on BCCH TRX in a cell
In multiband and concentric cells, only the TRX, which belong to the outer
zone, can support dynamic and static SDCCH
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
In cells with E-GSM, only the TRX, which belong to the P-GSM band, can
support dynamic and static SDCCH
The maximum number of SDCCH per cell must be verified to ensure that
the number of configured SDCCH, dynamic and static, for a cell must not
exceed the defined maximum of 88
BTS with DRFU do not support SDCCH dynamic allocation
In A9130 BSC Evolution in not allowed more than one SDCCH TS per TRX.
Number of SDCCH +(BCCH_factor x number of BCCH) = 32 (system limitation)
at recovery time
With BCCH factor = 4 for a combined configuration
And BCCH factor = 8 for a non combined configuration. On average, the feature
does not require the use of more SDCCH in the BSS than without it, because
the traffic model is the same as without this feature. The operator can configure
more SDCCH, without having to diminish the number of TCH.
An SDH TS must be (mandatory) ranked #1-#3 in the BCCH BBT.

60 / 162

3BK 17422 5000 PGZZA Ed.06b

4 BSC Configuration

4 BSC Configuration
BSC Configuration describes the A9120 and A9130 BSC Evolution, and
corresponding features and configurations.
The following figure shows the location of the BSC inside the BSS.

Figure 14: BSC in the BSS

3BK 17422 5000 PGZZA Ed.06b

61 / 162

4 BSC Configuration

4.1 A9120 BSC

4.1.1 A9120 BSC Architecture
The A9120 BSC consists in one switch and 3 main sub-units (TSU):
The Abis TSU, which determines the connectivity with BTS
The Ater TSU, which sets the capacity the BSC can handle
The common TSU.
This is shown in the following figure.

Figure 15: A9120 BSC Architecture

4.1.1.1 Capabilities
The following table lists the maximum theoretical capacities versus
configurations that have been committed to by Mobile Networks Division.
Capacities greater than this cannot be guaranteed and should not be offered
to customers.
Maximum

Configuration

Traffic
Max

Release 1

FR
TRX

DR
TRX

Cells

BTS

Erlang

B5.1

352

176

264

255

1700

B6.2

352

224

264

255

1800

B7

448

224

264

255

1900

B8

448

224

264

255

1900

62 / 162

3BK 17422 5000 PGZZA Ed.06b

4 BSC Configuration

Maximum

Configuration

Traffic
Max

B8

448

224

264

255

1900

B8

448

224

264

255

1900

B8

448

224

264

255

1900

B8

448

224

264

255

1900

B8

448

224

264

255

1900

B9

448

224

264

255

1900

Table 21: Maximum Supported Capacities and Configurations

The following table below lists the parameters that are applicable to all
configurations across all releases.
B5.1

B6.2

B7

B8

B9

CPRC-SYS

CPRC-OSI

CPRC-BC

TRE (FR FU)/

TCU or RSL /
TCU

TRE (DR FU) /

TCU

TRE / BTS
(Evolium BTS)

12

12

12

12

12

LAPD / TCU

Cells or Sectors
/BTS

TRX / Cell

12

12

16

16

16

16

16

16

TRX / Cell for

GPRS support
Max Nb SCCP
cnx / BSSAP
proc.

128

128

128

128

128

Frequency
Hopping
Identifiers

1056

932

1056

1056

1056

3BK 17422 5000 PGZZA Ed.06b

63 / 162

4 BSC Configuration

B5.1

B6.2

B7

B8

B9

Neighbor Cells

3500

3500

3500

3500

3500

Adjacencies

5400

5400

5400

5400

5400

Table 22: A9120 BSC Globally Applicable Parameters

4.1.1.2 A9120 BSC versus G2 TC Configurations

The main rule is that the BSC configuration always has to handle the complete
configuration for the G2 TC. It may be that some G2 TC racks can be
under-equipped compared with the BSC configuration.

4.1.1.3 Rack Rules

The following rules apply.
Extension / Reduction
A9120 BSC

Configuration Racks

Physical

Minimum

Maximum

Minimum

Lower Half 1

3 Racks

Half Rack

Logical

Half Rack

The following data shows the different steps required to go from a minimum
A9120 BSC configuration to the maximum configuration. The granularity of
extension/reduction is provided by a Terminal Unit (TU). A TU is a set of 4 TSU
sharing an access switch through stage 1.
There are six TU: Maximum Configuration (6):
TU 0 = 1 COMMON TSU + 1 Abis TSU + 2 Ater TSU = Lower Rack 1.
TU 1 = 3 Abis TSU + 1 Ater TSU = Upper Rack 1.
TU 2 = 2 Abis TSU + 2 Ater TSU = Lower Rack 2.
TU 3 = 3 Abis TSU + 1 Ater TSU = Upper Rack 2.
TU 4 = 2 Abis TSU + 2 Ater TSU = Lower Rack 3.
TU 5 = 3 Abis TSU + 1 Ater TSU = Upper Rack 3.
The following table describes the BSS evolutions.
Step

Abis TSU

Ater TSU

Stage 1

Stage 2

Racks

FR TRX

Abis/Ater
Mux

32

6/4

128

24/6

192

36/10

288

54/12

64 / 162

3BK 17422 5000 PGZZA Ed.06b

4 BSC Configuration

Step

Abis TSU

Ater TSU

Stage 1

Stage 2

Racks

FR TRX

Abis/Ater
Mux

11

352

66/16

14

448

84/18

Table 23: BSS Evolution Description

The following table describes the A9120 BSC capacity for each configuration.
Configuration 1

Racks

Upper 1

Lower 2

Upper 2

Lower 3

Upper 3

Clock Boards 4
BCLA

Transmission
Controller
TSCA

Access
Switch

16

24

32

40

48

Group
Switch Stage
1

16

24

32

40

48

Group
Switch Stage
2

32

32

64

64

64

64

DC-DC
Converters

13

17

30

34

42

47

Abis TSU

11

14

1
A bis
sub-multiplexers
BIUA

11

14

Lower 1

Terminal
Control Units
TCUC

32

48

72

88

112

A bis
interfaces

24

36

54

66

84

LAPD
channels

48

192

288

432

528

672

ATER TSU

3BK 17422 5000 PGZZA Ed.06b

65 / 162

4 BSC Configuration

Configuration 1

4
A ter
sub-multiplexers
ASMB

10

12

16

18

Digital Trunk
Controllers
DTCC

16

24

40

48

64

72

A ter
interfaces
maxi
carrying
traffic

16

24

40

48

64

72

No.7 DTCC

10

12

16

16

TCH
Resource
Management
DTCC pairs

BSSAP
DTCCs

14

22

28

36

44

Full/ Dual
Rate TRX
or RSLs

32/14(1)

128/62(1)

192/92(2)

288/140(2)

352/170(3)

448/218(3)

Radio TCH

256(*)

1024(*)

1536(*)

2304(*)

2816(*)

3584(*)

Cells or
sectors

32

120

192

240

264

264

BTS
equipment
or OMLs (**)

23

95

142

214

255

255

A ter Qmux
circuits

A ter X.25
circuits

A ter Alarm
Octets

10

12

16

18

A ter circuits
(assuming
X.25 on A
ter)

454

686

1148

1380

1842

2074

480

804

966

1289

1452

A ter Erlangs
(70%)

66 / 162

3BK 17422 5000 PGZZA Ed.06b

4 BSC Configuration

Configuration 1

A ter Erlangs
(80%)

549

918

1104

1474

1659

A ter Erlangs
(85%)

583

976

1173

1566

1763

A ter Erlangs
(0.1%
blocking)

627

1074

1300

1753

1980

620

1050

1300

1700

1900

A ter Erlangs
committed

160

: The value does not take into account that this maximum cannot be reached due to SDCCH and BCCH configuration.

**

: Maximum number of BTS = (#TCU * #max_OML per TCU) - #TSL link

: + 4FR

: + 8FR

: + 12FR

Table 24: B9 A9120 BSC Capacity per Configuration

4.1.2 ABIS TSU

The Abis TSU is a functional entity terminating the interfaces carrying the
speech/data traffic and signaling to and from the BTS.
It includes the following boards:
1 BIUA cross-connected between 6 Abis Interfaces to 8 BS interfaces,
connected to 8 TCUC
8 TCUC (each TCUC can handle up to 32 TCH)
2 access switches.

4.1.2.1 Static Allocation of TSL Link to TCUC

TSL is a LAPD link connecting the TCUC to the (Transcoder Submultiplexer
Controller (TSC). The TSC is in charge of the supervision of the transmission
part of the BSS equipment and the transmission configuration. It polls the NE
and collects the alarm indications. After the correlation process, it sends the list
of the active alarms to OMC_R. The TSL/TCU mapping is fixed.
This is described in the following table.
TSL Links A9120 BSC

BIUA Number
(BSC-Adapt SBL
Number)

TCU Number

TS Used on BS*
Interface

TSL 1 (first rack)

28

TSL 2 (second rack)

41

28

TSL 3 (third rack)

11

81

28

3BK 17422 5000 PGZZA Ed.06b

67 / 162

4 BSC Configuration

: BS interface is the interface between the BIUA and the TCU.

Table 25: TSL / TCU Mapping

When present, the TSL uses one of the 6 LapD controllers of the G2 TCU.

4.1.2.2 Static Allocation of TRX and BTS to TCUC

Rules and Dimensioning
The following rules apply.
Each TCUC can handle:
A maximum of 6 LAPD links
A maximum of 4 RSL FR or 2 RSL DR
A maximum of 3 OML.
This is shown in the following table.
TRX

OML

4 FR

4 FR

3 FR

2 FR

2 DR

TSL

Table 26: Configuration Example

The following rules apply:
In the case of Signaling Multiplexing:
For 16K static multiplexing, all RSLs of a given 64 Kbit/s Abis time-slot
must be handled by the same TCUC
For statistical multiplexing, all multiplexed RSL and OML are processed
on the same TCU.
Mixing signaling multiplexing and non-multiplexed signaling on the same
TCU is allowed
Each TCUC can handle 32 Traffic channels,
which allows:
full rate TRXs
2 dual rate TRXs.
Each TCUC can handle either full rate or dual rate traffic
The operator can choose the multiplexing scheme and the rate type of
the TRX.

68 / 162

3BK 17422 5000 PGZZA Ed.06b

4 BSC Configuration

All TRX of all BTSs of a same Abis multi-drop are controlled by the TCU of
a single Abis TSU
Each Abis TSU (BIUA) can handle 6 Abis links,
which allows:
maximum 3 ring configuration (looped multi-drop)
maximum 6 chain configuration (open multi-drop or star configuration)
A maximum of 16 dual rate TRE assigned to a maximum of 16 BTS can be
connected to a single Abis TSU
Abis TSU can mix FR or DR cells
Each Abis TSU holds 8 TCUC
TRXs of one BTS cannot be split between two different Abis PCM, thus
in two different Abis TSU
First TSU of each rack can only support 14 DR TRE.
In the case of a closed multi-drop (Ring), both ends must be connected to
the same Abis TSU.
It is advisable to use Abis Ports 1, 3, 5 first for an open multi-drop, and, in
the case of a closed mMulti-drop,,use the Abis ports 1&2, 3&4, 5&6
The Abis TSU can handle up to 8 * 4 = 32 FR TRXs.

3BK 17422 5000 PGZZA Ed.06b

69 / 162

4 BSC Configuration

4.1.2.3 G2 HR Flexibility
Currently, GSM network operators see the HR as a way of extending the
capacity of the network without any additional hardware deployment (i.e.
without any extra significant cost).
The gradual introduction of HR allows the operator to define each individual
TRE as full rate or dual rate. This allows control of the HR ratio on a per cell
basis. Due to the TRE/TCU mapping algorithm where TRE and TCU must be of
the same type (full rate, dual rate), mapping is not possible when there is no
TCU at all or when the TCU which could be available is already mapped to
TRE whose type is different.
The TCUs of a TSU are allocated, by the A9120 BSC, to support FR or DR
TREs according to the mapping algorithm:
The 2 types of TRE are mapped on compatible TCUs with a maximum of 4
FR TREs per FR TCU and 2 DR TREs per DR TCU
The BSC allocates free TCUs as FR or DR TCU, according to requirements
The first TCUC of each BSC rack cannot be half rate, only full rate.
Abis Signaling TS Allocation
HR flexibility uses the 64 Kbit/s statistic OML/RSL multiplexing rule or no
multiplexing mode.

70 / 162

3BK 17422 5000 PGZZA Ed.06b

4 BSC Configuration

The statistical multiplexing scheme (64/4, 64/2, 64/1) is not defined by the
operator, but the operator can select the expected level of signaling load (high
or normal) per BTS or per sector according to:
Normal signaling load
4:1 is the maximum multiplexing scheme allowed for FR TRX
2:1 is the maximum multiplexing scheme allowed for DR TRX.
High signaling load
2:1 is the maximum multiplexing scheme allowed for FR TRX
1:1 is the maximum multiplexing scheme allowed for DR TRX.
The BSC is responsible for selecting the multiplexing scheme compatible with
the signaling load and the TRE type.
In the case of statistical 16Kbit/s multiplexing, only the FR TREs will be
statically multiplexed, and the DR are not multiplexed.

4.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 16 Kbit/s from 4 tributaries to 1 highway
8 DTCC (one DTCC can handle up to 30 circuits when no TS are used for
Qmux, X25 or SS7)
2 access switches.

4.1.3.1 DTC Rules

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

3BK 17422 5000 PGZZA Ed.06b

71 / 162

4 BSC Configuration

Figure 16: Ater TSU Configuration

4.1.3.2 DTC Architecture and Functions

The DTC processors are configured by default to perform one of 3 main
functions:
TCH-RM
BSSAP/GPRSAP
MTP-SS7.
The following table shows the default mapping on the DTC SBL number.
BSC Configuration
1
TCH-RM

72 / 162

3-4,11-12

3
27-28,35-36

51-52,59-60

3BK 17422 5000 PGZZA Ed.06b

4 BSC Configuration

BSC Configuration
BSSAP/
GPRSAP

2,6-8,10,14-16 18-20,22-24

26,30-32, 34,
38-40

42-44, 46-48

50,54-56, 58,
62-64

SS7-MTP

1,5,9,13

25,29,33,37

41,45

49,53,57,61

17,21

65-72

Table 27: DTC Configuration and SBL Number

Rules and Dimensioning
The following rules apply:
Up to 16 DTC are allowed with the SS7 link
For GPRS, the second DTC in each group of 4 (e.g. DTCs 2, 6 etc.) can be
configured to handle GSLs on TS28
The second DTC on the first 2 Atermux can support X.25 on TS31.

4.1.4 TSC Function

The A9120 BSC is directly in charge of the configuration of the TSC. In terms of
software management, the TSC is treated like any other BSC processor (e.g.
DTC). The TSC software is an integral part of the BSC software package.
The TSC is reset whenever the BSC is reset. There is no possibility for
dedicated management of the TSC software. The SBLs TSL must have
a purely internal meaning.
The TSC data base update mechanisms must follow the principles of the BTS
data base updates (i.e. the TSC is configured by data coming from BSC at
start up, and whenever the BSS configuration has changed something which
is of interest for the TSC).

4.2 A9130 BSC Evolution

4.2.1 A9130 BSC Evolution Architecture
The following figure shows the BSC Hardware (HW) architecture on an ATCA
platform.

3BK 17422 5000 PGZZA Ed.06b

73 / 162

4 BSC Configuration

TP

SSW

TP r

CCP

(duplicated)

Radio Network links

Mux

CCP y
E1

LIU

OMCPw

OMCP r

LIU n
LIU Shelf

ATCA Shelf (14 slots)

(21 slots)

External Ethernet Links

: Redundancy

: Working

N and y

: Network Element capacity

Figure 17: A9130 BSC Evolution HW Architecture

The following table describes the A9130 BSC Evolution functional blocks
and boards.

74 / 162

3BK 17422 5000 PGZZA Ed.06b

4 BSC Configuration

Name

Functional block mapped on board

SSW: Gigabit Ethernet switch (in

ATCA shelf)

OMC-R physical interface

Allows exchanges between all the
elements of the platform and external
CBC physical interface
IP/Ethernet equipment:
Monitoring
Performs Gigabit Ethernet
NEM terminal connection
switching at the shelf level

Existing function for BSC

Performs powerful monitoring for

the user plane and control plane
(Gigabit Ethernet on front panel)
Ensures daisy chain with other
shelves via two 1 Gigabit Ethernet
ports (only one is used)
Ensures multicast function
Allows several external Ethernet
10/100/1000 Base T connections:
OMC-R, CBC, LCS, Debug
Implements 12 non blocking
1Gigabit Ethernet links via
backplane connections
...
The SSW board and all the
connections to the switch are
duplicated to overcome board or
connection failures.
OMCP: O&M Control Processing
board (in ATCA shelf)

Is based on ATCA technology

equipped with a permanent storage
device. It manages the platform as
system manager, and manages O&M
applications.
OMCP boards operate in
active-standby mode following
the 1+1 redundancy model.

CCP: Control Processing board (on

ATCA shelf)

Is based on ATCA technology used

for call control functions. Identical to
the OMCP board but without a hard
disk.

O&M logical interface to the

Operation and Maintenance
Center (OMC-R)
VCPR: S-CPR & O-CPR
software + TCH/RM
TSC software

VTCU: TCU software

VDTC: DTC software

CCP boards operate in an N + 1

redundancy model. N is the number
of active boards ready to handle
traffic and one standby CCP board
is always available to take over the
traffic of failed board.

3BK 17422 5000 PGZZA Ed.06b

75 / 162

4 BSC Configuration

Name

Functional block mapped on board

Existing function for BSC

TP GSM: Transmission Processing

board (in ATCA shelf)

Provides telecom transmission /

transport interfaces to the ATCA
platform.

HDLC termination

Gigabit Ethernet switch

On-board local switch
(separates/aggregates nE1oE
traffic and IP control traffic).

SS7 termination
NE1oE
Q1
Ring control

NE1oE
Transports n x E1 frames in
Ethernet payloads, and is
assigned to a dedicated MAC
address.
Multiplexes/de-multiplexes up to
252 E1
Multiplexes/de-multiplexes up
to 252 E1 from/to the Gigabit
Ethernet Interface (NE1oE).
TDM switch
8 kbit/s synchronous switching
with a total bandwidth of 284 *
2 Mbits (252 external links + 32
internal links toward HDLC, SS7,
Q1 and R/W bits controllers).
Handles low layers of GSM
protocols
LAP-D over HDLC, ML-PPP over
HDLC, SS7, Q1 (= QMUX) and
R/W bits.
Two TPGSM boards are available.
They operate in active-standby mode
following 1+1 redundancy model.
LIU boards (in LIU shelf)

Interface for Radio Network links

These links correspond to

the user plane interfaces.

MUX board (in LIU shelf)

Ethernet links on IP ports of SSW
switch

76 / 162

These links connect the

platform to external
IP equipment (OMC-R,
External Alarm Box, etc.).

3BK 17422 5000 PGZZA Ed.06b

4 BSC Configuration

Name

Functional block mapped on board

Existing function for BSC

LIU Shelf

Multiplex/demultiplex which cross

connects all E1 external links to/from
a NE multiplexed links (n E1 over
Ethernet) at TP and GP board.

E1 physical termination
NE1oE

It is equipped with 2 x Mux board and

n LIU boards.
ATCA Shelf

See above.

4.2.2 Configurations
For A9130 BSC Evolution, E1 termination ports are generic and are configured
to "Abis", "Ater" or "not used" without any constraints. Consequently Abis or Ater
termination ports may be not contiguous. Abis-Hway-TP are numbered from
the first E1 termination port to the last one. The numbering of Abis-Hway-TP
remains without holes, even if they are mapped on discontinuous E1 termination
ports. It is the same for the Ater-Hway-TP. The order has no importance.
With A9120 BSC, any Atermux could be connected either to MFS or to TC. For
a GPRS dedicated Atermux, the Ater-Hway-TP at TC side is not equipped, but
the number of Ater-Hway-TP is the same at TC and A9120 BSC side.
In fact, the engineering rules lead to specialize the 16 LIU boards:
[1, 11] Abis
[12, 16] Ater
In B9, only 3 LIU boards (14, 15, 16) are used for Ater (12 & 13 are reserved for
future usage).
As there are 16 E1 per LIU board (i.e. 256 E1 in configuration type 3):
11x 16=176 E1 Abis HW-TP
3x16=48 E1 Ater HW-TP
Note that TP-GSM board can only manage 252 E1 so 4 E1 cannot be used.
The following figure shows the 600 TRX LIU Shelf connections assignment:

3BK 17422 5000 PGZZA Ed.06b

77 / 162

4 BSC Configuration

Figure 18: 600 TRX LIU Shelf connections assignment

where

4.2.2.1 A9130 BSC Evolution Board Configurations

The following table lists the board configurations by shelf.
Equipment

BSC Capacity 200 TRX

ATCA Shelf

CCP

1+1

SPARE CCP

TPGSM

OMCP

SSW

LIU Shelf

78 / 162

BSC Capacity 400 TRX

BSC Capacity 600 TRX

2+1

3+1

3BK 17422 5000 PGZZA Ed.06b

4 BSC Configuration

Equipment

BSC Capacity 200 TRX

MUX

LIU

Note:

BSC Capacity 400 TRX

BSC Capacity 600 TRX

16

Note that the quantity of TPGSM, OMCP, SSW and MUX boards must be
considered to be 1 active + 1 standby to allow for redundancy in the shelf.

4.2.2.2 A9130 MFS and A9130 BSC Evolution Rack Shared Configurations
Rack shared configuration for A9130 MFS and A9130 BSC Evolution consists
of:
1 x BSC configuration and a 1 x MFS configuration in the same cabinet
2 x BSC configurations in the same cabinet.
In both cases:
Each equipment is considered as independent (choice of each configuration
free in the limit of 1 x ATCA shelf per configuration)
In case of BSC and MFS, they are not considered as a stand alone node,
and MFS NEcan be used by the rack shared BSC, but also by other nearby
BSCs (MXPF based or G2). (MFS NE is not fully or only dedicated to BSC
traffic located in the same rack).
Rack shared by A9130 BSC Evolution - A9130 MFS
You can follow the board configurations in shelfs in next table:
Equipment

BSC capacity
200TRX

MFS capacity
400TRX

600TRX

"9 GP" (*)

ATCA Shelf

CCP

SPARE CCP

NA

TPGSM

NA

GP

NA

1 to 9(*)

SPARE GP

NA

OMCP

SSW

LIU Shelf

MUX

LIU

3BK 17422 5000 PGZZA Ed.06b

1
2

16

NA

79 / 162

4 BSC Configuration

: As no extension possible for MFS in rack shared, options 14E1 per GP or 16 E1 per GP are proposed then maximum
number of GP is limited to 8 GP instead of 9 GP.

Note:

Quantity of TPGSM, OMCP, SSW and MUX boards have to be considered as 1

activ + 1 stand-by for redundancy function per shelf.
Rack shared by two A9130 BSC Evolution
Board configurations in each ATCA and LIU shelf are identical to single BSC.

4.2.3 A9130 Capabilities

The following table shows the A9130 BSC Evolution capabilities:
1

Nb TRX

200

400

600

Nb Cell

192

264

264

Nb BTS

150*

255

255

Nb SS7 links

16

16

Nb CICs

1024

2068

3112

Abis

96

96

176

Ater CS

10

20

30

Ater PS

12

18

Nb TCU

50

100

150

Nb DTC CS

40

80

120

Nb DTC PS

24

48

72

Nb TCH-RM pairs

Nb CPR pairs

Nb TSC pairs

Nb VCE per CCP

114

114

114

Nb VCE/OMCP

15

15

15

Nb CCP

Nb OMCP

Nb spare CCP

Nb TP GSM

Nb SSW

Configuration Type
Capacity

Nb of E1

Nb VCE CCP

Nb VCE OMCP

Nb VCE per board

Nb boards ATCA

80 / 162

3BK 17422 5000 PGZZA Ed.06b

4 BSC Configuration

Configuration Type

Nb boards SMM

Nb SMM

Nb boards LIU

Nb MUX

Nb LIU

16

: 3 Nb OML per TCU * Nb TCU = 3 * 50=150

A9130 BSC Evolution can reach 2600 Erlangs.

4.3 Delta A9130 BSC Evolution versus A9120 BSC

The A9130 BSC Evolution differs in plus from standard BSC as follows:
Compared to previous generation BSC, the ATCA PF does not provide X.21
interfaces. An X25 over IP link is used for CBC.
TSU is removed
No more SDCCH limitation per TCU (32)
Remote inventory (like for other NEs)
Replace FTAM with FTP
Time/date management by ntp
Ater programming - new strategy
BSS files management - ftp browser
BSC fast restore
SNMP used for overload
A9130 BSC Evolution reduction in restriction
Abis/Ater fixed mapping to LIU boards.
The A9130 BSC Evolution can be used as clock synchronization source
for AS800, DS10 or A9130 MFS.
Behaviors that does not change:
DLS 1Mb limitation kept
No change in logical model of the BSC
No change in radio configuration mechanisms
Same set of radio parameters
No changes in PM mechanisms
Same set of PM counters/indicators as A9120 BSC.

3BK 17422 5000 PGZZA Ed.06b

81 / 162

4 BSC Configuration

82 / 162

3BK 17422 5000 PGZZA Ed.06b

5 TC Configuration

5 TC Configuration
TC Configurations describes the transcoder, and corresponding features
and functions.
The following figure shows the location of the transcoder (TC) inside the BSS.

Figure 19: TC in the BSS

The main architecture of TC is the Sub-Unit (TCSU), which is compounded by:
One Sub-Multiplexing Unit (SMU)
One or more Transcoding Units (TRCU).
In the case of A9125 Compact TC transcoder, these units are combined on one
single board, the MT120, which offers 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.
The following table provides a summary of the technical data for the different
generations of TC.

3BK 17422 5000 PGZZA Ed.06b

83 / 162

5 TC Configuration

G2 TC(with/without
MT120)

A9125 TC

Number

Up to 3

One

Type

S12

19"

Size mm

900*520*2200

600*600*2000

Atermux per rack

48

A interfaces

24

192

CIC

24*29

192*29

Rack

Table 28: G2 TC/A9125 Compact TC capabilities

84 / 162

3BK 17422 5000 PGZZA Ed.06b

5 TC Configuration

5.1 G2 TC
5.1.1 Architecture
There are 2 types of G2 TC:
G2 TC equipped with ASMC and TRCU
G2 TC equipped with ASMC/TRCU + MT120 boards (in the case of
an extension).
The G2 TC architecture is linked to the A9120 BSC architecture (that is, the
Ater TSU). A G2 TC rack is compounded by 6 Sub-multiplexing Units (SU)
with a granularity of 1 SU = 1 ASMC + 4 TRCU.
The ASMC terminates one Atermux on the t TC side
The TRCU is Transcoder Unit (TCU) compounded by 1 ATBX and 2 DT16.
One SU terminates one Atermux on the TC side in front of:
One ASMB board on the A9120 BSC side
4 A Interfaces on the MSC side.

5.1.2 Rules and Dimensioning

The following rules apply:
The G2 TC equipped with MT120 boards
adheres to the 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 A9125 Compact TC rack.
One G2-TC Full Rack can be installed in front of the A9120 BSC (one
full rack means Conf 2: 6 Atermux. as 2 SU are required in front of one
Ater TSU)
The maximum number of racks is 3 (i.e. 6*3=18 Atermux).
Taking into account the above rules for G2 TC equipped with MT120, the
configuration rules described in the following table are applied for this rack.
Configuration Per Rack

Extension / Reduction
Physical

Logical

Minimum

Maximum

Minimum

G2 TC

2 Atermux

6 Atermux

One Atermux

One Atermux

SU

ASMC

3BK 17422 5000 PGZZA Ed.06b

85 / 162

5 TC Configuration

Configuration Per Rack

Extension / Reduction

TRCU SM 4:1

24

MT120

Table 29: G2 TC configurations

When create one logic Atermux the new granularity of HW added is: (nx2)
DT16 or one ASMC + 4xATBX + (4x2 DT16)
Before introducing MT120 in a G2 TC, the ASMC must be completed with
all required DT16 (to remove holes in ASMC)

5.2 A9125 Compact TC

5.2.1 Architecture
The A9125 Compact TC can be used to extend the G2 TC (by mixing G2 TC and
A9125 Compact TC within a BSS), for G2 TC replacement and for new BSS.
For G2 TC replacement, one A9125 Compact TC can replace several G2
TC racks.
The A9125 Compact TC can be equipped with up to 48 sub-units (referred to
as MT120 boards). Each MT120 offers an Atermux connection to a BSC and
up to 4 Atrunk connections to the MSC, so that the A9125 Compact TC offers
up to 192 Atrunk connections to MSC.
The A9125 Compact TC can be shared between several A9120 BSC. One
MT120 board in any slot of any subrack can be allocated to any Atermux of a
A9120 BSC. These BSC can belong to several OMC-R.
The following table describes the G2 TC configurations.
Configuration Per Rack (Ater Mux)

Extension / Reduction step

Physical

MT120

Minimum

Maximum

Minimum

48

Logical

Table 30: G2 TC Configurations

5.2.2 Rules and Dimensioning

For Qmux connectivity, all the TC boards connected to one BSC rack must
belong to the same TC rack. This constraint is valid for both, G2 TC and
A9125 Compact TC rack types.
For redundancy purpose, a A9120 BSC must be connected to a A9125
Compact TC via 2 Atermux at minimum.
For exemple:

86 / 162

3BK 17422 5000 PGZZA Ed.06b

5 TC Configuration

24 BSCs with 2 Atermux can be connected to a A9125 Compact TC rack

6 BSCs with 8 Atermux can be connected to a A9125 Compact TC rack
Extension
A Qmux cluster is a group of up to 6 MT120 which ensure the Qmux supervision
of the boards with the TSC of the related BSC. These MT120 boards cannot
be adjacent or in a different subrack, but must be always in the same A9125
Compact TC rack.
The notion of Qmux clusters is important during extension of Atermux in a BSC
rack, as it can induce modification of the initial configuration.
Different extensions are possible:
Extension of Atermux in a BSC rack
In this case, the Qmux cluster is increased. Recabling of all of the Atermux
of a cluster into a new A9125 Compact TC rack is necessary if there are
no more free slots in the A9125 Compact TC.
G2 TC extension
Once the G2 TC rack maximum capacity (6 Ater) has been reached, BSC
extension will require TC capacity. In this case, the A9125 Compact TC
rack is required as the G2 TC rack extension (G2 TC rack is kept). The
A9125 Compact TC rack can be shared afterwards between different BSC
extensions. An A9125 Compact TC rack can also be added even if the G2
TC rack is not completely filled (in the case of GPRS holes).
New rack of a BSC by extension of Atermux capacity
Depending of free slot capacity in the A9125 Compact TC, a new A9125
Compact TC may be required.
New BSC
Depending of free slot capacity in the A9125 Compact TC, a new A9125
Compact TC may be required.

3BK 17422 5000 PGZZA Ed.06b

87 / 162

5 TC Configuration

88 / 162

3BK 17422 5000 PGZZA Ed.06b

6 MFS Configuration

6 MFS Configuration
MFS Configuration describes the MFS, and corresponding features and
functions.

3BK 17422 5000 PGZZA Ed.06b

89 / 162

6 MFS Configuration

6.1 A9135 MFS

6.1.1 MFS Architecture
The Multi-Function Server (MFS) comprises 3 sub-systems:
Control Sub-System (CSS), which is 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), which is a set of GPU and JBETI boards
Hub subsystem, which consists of duplicated 100 Mbit/s Ethernet networks
for interconnection.
The following figure shows the MFS architecture.

Figure 20: MFS Architecture

6.1.1.1 GPRS Processing Unit

The GPRS Processing Unit (GPU) board is part of the MFS.
A MFS includes at least one subrack equipped with:
16 (maximum) GPU boards (minimum is 2, including 1 spare)
2 redundant Ethernet Hubs
2 redundant Control Stations
1 IOLAN with 8 ports.

90 / 162

3BK 17422 5000 PGZZA Ed.06b

6 MFS Configuration

A GPU board is linked to one BSC.

The GPU supports the Packet Control Unit (PCU), as defined by GSM. The
PCU allows the BSS to access the GPRS service to SGSN.
The PCU is split into 2 parts:
The Packet Management Unit (PMU), which handles asynchronous
functions
The Packet Traffic Unit (PTU), which handles synchronous radio functions.
There are a maximum of 16 PCM links per GPU board. The use of these PCM
links is not dedicated, and each interface can be connected to BSS or NSS
entities. The supported interfaces are:
Ater transport TCH from the BTS to existing TC on the BSC side and TC side
Gb connects the MFS directly to SGSN, or through the Frame Relay
Network. The capacity required depends on GCH in Atermux.
LCS in the GPU also implements the SMLC function.

6.1.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 maximum number of GPUs to be connected to a BSC depends on the
connection capacity of the BSC.
For example, assuming that a GPU can reach its traffic capacity with 2
dedicated Atermux links, and that a GPU is connected to only one BSC with at
least two Atermux links to support GSL redundancy, a BSC Configuration 6
and a total of 18 Atermux links, up to 6 GPUs could be connected.
The GPU linked to same BSS do not need to be in same MFS subrack.
Cell Mapping
"Mapping a cell" means that a cell is associated with a GPU.
"Remapping a cell" means that a cell, already linked to a GPU, is moved to
another 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 on, GPU.
The following figure shows the BSC connection for mulit-GPU per BSS.

3BK 17422 5000 PGZZA Ed.06b

91 / 162

6 MFS Configuration

Figure 21: BSC Connection for Multi-GPU per BSS

In terms of the BSC connection, the BSC is transparent to this behavior and
ignores the mapping of cells per GPU. The BSC is only impacted by a greater
number of LAPD bearer channels. There GPU also redirect messages.
For inter-GPU links, there are two 100Mbs Ethernet links, which interconnect
the GPU and the Control Station. These links are used to exchange information
between GPU.

6.1.2 MFS Configuration

The MFS is offered in 2 configurations:
Standard
The MFS includes one telecom subrack with a minimum 2 GPU (1+1) and
can be extended up to 16 (15+1) GPU. The second Telecom subrack is
only wired and is not equipped.
Standard pre-equipped
The MFS includes 2 equipped and wired telecom subracks. The maximum
capacity is 32 GPU (2 * (15+1)).
The following table describes the MFS capacity for DS10.
MFS Configuration

Standard

Standard Pre-equipped

Number of equipped telecom

subrack

92 / 162

3BK 17422 5000 PGZZA Ed.06b

6 MFS Configuration

MFS Configuration

Standard

Standard Pre-equipped

Minimum GPU + One GPU for

redundancy

1+1

1+1

Maximum GPU + One GPU for

redundancy

15+1

2(15+1)

Maximum BSS

15

22

Maximum GPRS GCH

(240*15)3600

(240*30)7200

Table 31: MFS Capacity for DS10

An MFS with 2 subracks must be synchronized at the subrack level, so if
this synchronization comes from the TC, 4 links will be needed (2 per MFS
subrack). If the synchronization comes from an SGSN (synchronized itself from
an MSC), the synchronization must be ensured from this SGSN towards the
two MFS subracks.
There is also the possibility that one subrack can be synchronized to the other,
so that only two links are needed.

6.1.3 MFS Clock Synchronization

The MFS can operate in the following clock synchronization modes, which are
defined via the IMT:
Autonomous
Centralized
Synchro. Fixed Configuration.

Note:

The Synchro. Fixed Configuration mode, using GPU cascading, is only for
MFS created in release B6.2.
The selected mode is valid for the complete MFS.
Clock synchronization can come from TC, SGSN, or from another entry
provided by the customer.
The following constraints apply:
In the case of multi PLMN (see PLMN Interworking (Section 2.6) )
In the case where Secure Single Gb is used, it is necessary to check that
the GPU will still receive synchronization, either in autonomous mode (plus
one link towards the TC), or in centralized or cascading modes. Cascading
refers to interconnections between GPU.

6.1.3.1 Autonomous Mode

There must be 2 secured link between each GPU and the TC.
If the synchronization comes from an SGSN (synchronized itself from an
MSC), the synchronization must ensured from this SGSN towards the two
MFS subracks.

3BK 17422 5000 PGZZA Ed.06b

93 / 162

6 MFS Configuration

6.1.3.2 Centralized Mode

Synchronization is performed at subrack level, and so there are recommended:
two synchronizing PCM links connected to the corresponding synchronizing
PCM-TTPs for each master GPU => total four synchronizing PCM links.

6.1.3.3 Synchro. Fixed Configuration or Cascading Mode

The Synchro. Fixed Configuration mode requires the use of GPU cascading.
When the feature is activated from the IMT, the clock synchronization is
performed from ports 14 and 15 on each GPU.
On first GPU, the 2 primary synchronization interfaces (ports 14 and 15) can be
any G.703/G.704 interfaces with no traffic, which have a frequency within 1
9
in 10 of that of the BSS.
At the OMC-R, for each GPU:
The BSC (dedicated GPRS Atermux) and SGSN (Gb) ports (0 to 7) are
configured as usual for traffic
The last eight GPU ports (8 to 15) are configured as SGSN (Gb) ports
but with no data paths assigned.
From a hardware point of view, the GPU ports (8 to 15) are linked at the DDF
to create the synchronization distribution scheme.
To prevent alarm reports towards the OMC-R, all unused ports (from 8 to 13) of
each GPU will be looped at the DDF side (TX path looped on RX path).
In cascading mode, the whole MFS capacity (32 GPU) is not used.

6.2 A9130 MFS

6.2.1 MFS Architecture
The following figure shows the global A9130 MFS hardware architecture:

94 / 162

3BK 17422 5000 PGZZA Ed.06b

6 MFS Configuration

Figure 22: A9130 MFS Hardware Architecture

The MX-MFS is composed of the following types of boards:
OMCP boards, which are general processing boards that will be used for
O&M functions and O&M logical interface (in ATCA shelf).
They provide persistent storage on a 40 Gb IDE hard disk.
GP boards, composed of GPRS packet functions running on a PowerPC on
pSOS 2.5, DSP, and Ne1oE over Ethernet (same as GPU)(in ATCA).
E1 concentration boards (MUX), which are transmission boards that
terminates E1 links and connect to GP boards through Ethernet using
nE1oE protocol (n E1 over Ethernet). These boards are in the E1
termination shelf that is specific (LIU shelf not ATCA).
There are 2 E1 concentration boards in a termination shelf (physical
termination).
SSW boards, whereby SSW is the Ethernet switching module, which
connects all boards in a single subrack through 1 Giga bit/s star links
(OMC-R physical interface) in ATCA.
Tle local IMT is connected through these boards.
LIU boards which are used in the LIU shelf connect the E1 with GP boards.
1 LIU board supports 16 E1.
These boards are used in ATC and &LIU shelves.

6.2.2 MFS Configuration

The following table gives the number of boards for each configuration.

3BK 17422 5000 PGZZA Ed.06b

95 / 162

6 MFS Configuration

Board

Mono Shelf Centralized

Configuration

Two Shelf Centralized

Configuration

OMCP

1+1

1+1

SSW

1+1

2+2

GP

9+1

21+1

E1 concentration boards or MUX

board

1+1

1+1

LIU boards

16

Table 32: Maximum MFS Configurations on MX Platform

The following rules apply:
Maximum number of GP boards: 22 (21+ 1 standby GP)
The maximum number of E1 per GP managed by MFS software is 16
The maximum number of BSS is 21
For other objects (Cells, PDCH group, FrBR, PVC,etc.), the same values
are maintained.
The following LIU/GP configurations are supported:
TTP Number

Synchronization

Preferred Relative
Position to BSC

Maximum MFS
Subrack Number

Configurations

12 TTP

centralized

remote /
colocalized

2 subracks

21 GP

autonomous

9 GP

14 TTP

centralized

remote G2 BSC

1 subrack

8 GP

16 TTP

autonomous

colocalized G2
BSC

1 subrack

8 GP

6.2.3 MFS Clock Synchronization

There are two modes:
The autonomous mode, whereby each GPU receives the clock signal on
dedicated E1s (at least 2 links for redundancy reason)
The centralized mode, whereby two dedicated GP receive the clock
signal on dedicated E1s and transmit it to the other GPs using a RAB bus
on the back panel.

96 / 162

3BK 17422 5000 PGZZA Ed.06b

6 MFS Configuration

6.3 Delta A9135MFS versus A9130MFS

The A9130 MFS differs from the standard MFS as follows:
The GP replaces the current GPU
The E1 termination shelf replaces the E1 appliques, with the advantage of
separating processing from transmission
No spare physical GP (still N+1 protection scheme)
In the A9130 MFS, there are only 12 ports per GP
The JBETI is removed
The applique is removed
The fixed synchronization mode does not exist. The clock synchronization is
transmitted over Ethernet (nE1oE) from the E1 board. It is received on the
specific virtual E1 links of the GP and can be configured, as it is the case
in the autonomous mode or centralized mode.
Control stations are replaced by the OMCP board
There is a new operating system (OS), and a new Tomas
Installation is via.xml scripts, as for RC40.
The following elements do not change:
There is no change in the radio configuration mechanisms, and same
parameters are used
here is no change in the PM mechanisms, same counters/indicators
here is no change in the Ater/Gb transmission configuration and display
The hardware supervision is still handled through the IMT
There is no change in the OMC/MFS communication, which still uses the
Q3/CMISE stack in socket mode.

3BK 17422 5000 PGZZA Ed.06b

97 / 162

6 MFS Configuration

98 / 162

3BK 17422 5000 PGZZA Ed.06b

7 ABIS Interface

7 ABIS Interface
Abis Interface describes the Abis interface, and corresponding features and
functions.
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 TS, numbered from
0 to 31. The rate of each TS is 64 Kbit/s.

3BK 17422 5000 PGZZA Ed.06b

99 / 162

7 ABIS Interface

7.1 Abis Network Topology and Transport

For a functional point of view, 2 topologies are specified to physically connect
the BTS to the BSC:
Open multi-drop topology "CHAIN"
One PCM link connects up to 15 BTS in serial order and the PCM is not
looped back to BSC by the last BTS.
In a chain topology, the BSC is connected by the Abis link to a BTS. The
BTS is connected to a second BTS with a second Abis link, and the second
BTS is in turn connected to a third BTS, and so on.

Note:

A star topology is a particular case of a chain with one BTS.

The following figure shows a chain topology.

Figure 23: Chain Topology

Closed multi-drop topology "RING"
One PCM link connects up to 7 BTS in serial order and the PCM is looped
back to BSC by the last BTS.
In a ring or loop topology, the last BTS of a chain is connected back
to the BSC. This topology provides security as traffic between any BTS
and BSC is broadcast on the two paths, and the selection is based on
dedicated service bits and bytes.
The following figure shows a ring or loop topology.

100 / 162

3BK 17422 5000 PGZZA Ed.06b

7 ABIS Interface

Figure 24: Ring or Loop Topology

There are several ways of transporting Abis over networks (the following list
is not exhaustive):
A terrestrial link referred to as the PCM 2Mbit/s link (64 Kbit/s * 32 Time
Slots = 2048 Kbit/s)
A microwave link (same capacity or higher)
Digital cross-connect network equipment, which concentrates 4, 16 or 64
PCM 2Mbit/s link
A microwave hub equivalent to DCN
A satellite link.

7.2 Impedance
There are 2 types of impedance which define the access to the transmission
network:
120 Ohm balanced two twisted pairs
75 Ohm unbalanced two Coaxial cables (only for A9120BSC).

Note:

It is forbidden to mix impedance in the same BSS.

7.3 Abis Channel Types

7.3.1 Overview
Three types of channels are mapped in Abis trunks:
The Qmux channel is used by TSC O&M transmission supervision for non
Evolium BTS (G1 and G2 BTS)
The ring control channel R,S bits used by the transmission equipment (BIE)
which depends on the TSC (A9120 BSC)/TP(A9130BSC)
3 types

3BK 17422 5000 PGZZA Ed.06b

101 / 162

7 ABIS Interface

of BTS channels:
TCH channels: 8 per TRX
LAPD channels, which can carry one or more LAPs (RSL and/or OML),
and there is always only one RSL per TRX
Extra Abis TS.
Mapping is defined by:
The TS bearing the Qmux
The presence (or not) of the ring control channel
Allocation rules managing the PCM TS to the BTS via Multiplexed
Channel Blocks.

7.3.2 TS0 Use

There are TS0 modes:
TS0 Usage
TS0 usage mean that the TS0 carries Qmux.
TS0 Transparency
The Qmux is carried by any other TS from TS1 to TS31 (TS0 does not
carry Qmux).
TS0 transparency is strongly recommended.

7.4 Signaling Link on Abis Interface

7.4.1 RSL and OML
The GSM Recommendation 08.52 defines 2 logical links between the BTS
and the BSC :
The Radio Signaling Link (RSL), used for supporting traffic management
procedures (MS to network communication)
The Operation and Maintenance Link (OML) is used for supporting network
management procedures
Signaling for GPRS traffic is carried over RSL and/or GCH.

7.4.2 Qmux Bus

A link-denoted Qmux manages and supervises the transmission function of the
BSS equipment. This is based on a service Qmux master/slave bus principle.
The Qmux only is necessary for G1 and G2 BTS.
For transmission function management, the NEs are connected to this Qmux
bus and are in slave mode. An O&M entity referred to as the Transcoder
Sub-multiplexer Controller (TSC) is the master for A9120 BSC and TP for
A9130 BSC Evolution.

Note:

102 / 162

The Qmux bus can be replaced by Abis links for Evolium BTS, via the
"transmission management by the OMU" feature. Supervision is then managed
through the OML, via OML autodetection.

3BK 17422 5000 PGZZA Ed.06b

7 ABIS Interface

The Qmux bus is also used for configuring transmission / transcoding

equipment.
The Qmux link is carried on the PCM trunk TS for remote control.

7.4.3 OML Autodetection

When there is no Qmux, in release B6.2, the BTS cannot modify the OML
location. An on site visit is necessary to update the OML location. With this
configuration, the BTS cannot autonomously take into consideration any
change of OML address during a Move BTS, hence the development of OML
autodetection.
The BTS scans 31 TS on the Abis link to detect where its own OML link
is located. In the case of detection of an available OML, the BTS sends its
identity (Qmux-id) to the BSC via this available OML. The BSC then reports
whether the BTS is listening to the right OML, or on which TS the BTS can find
its dedicated OML.
After a reasonable delay, and without any onsite visit by a technician, the BTS
automatically reestablishes a link to the BSC.
This behavior is available only for Evolium BTS.

7.5 Signaling Link Multiplexing

7.5.1 Signaling Link Multiplexing Options
The following Signaling Link Multiplexing options apply:
No multiplexing
Static multiplexing of RSL 4*16Kbit/s in one TS. The OML is in another
TS. Static submultiplexing is not compatible with half rate configurations
(RSL capacity).
64K statistic multiplexing with HR flexibility
A new parameter signaling load (low/high) entered by the operator allows
the BSC to determine the multiplexing scheme according to:
Low: 4:1 (resp. 2:1) maximum multiplexing scheme for FR TRX
(responsible for DR TRX)
High 2:1 (responsible for 1:1) maximum multiplexing scheme for FR
TRX (resp. for DR TRX).
The operator gives the number of TRE per sector from the list of TRE
declared during BTS creation. This number must be taken as the DR TRE in
each sector and, in the case of a multiband sector, in each band.
Statistical submultiplexing 1 RSL and 1 OML, both at 16 Kbit/s in the
same radio TS0 bits1-2.

7.5.2 Signaling Link Multiplexing Rules

The following rules apply:
Static signaling submultiplexing is used only in a BSS with Evolium BTS and
G2 BTS with DRFU, whereby each TRX carries a maximum of 8 SDCCH

3BK 17422 5000 PGZZA Ed.06b

103 / 162

7 ABIS Interface

Statistical signaling submultiplexing 64k is used only with Evolium BTS

Statistical submultiplexing 16K is used only with Evolium BTS. Each TRX
carries a maximum 8 SDCCH, and radio TS0 cannot be used for TCH
For 16k statistical submultiplexing, the TS0 of each TRX must carry a static
signaling channel (BCCH, static SDCCH)
Dynamic SDCCH can exist on the BCCH TRX if the BCCH is combined
The combination of dual rate and 64Kbit/s statistical multiplexing is
supported.

7.5.3 Multiplexed Channel Block

In order to use statistical multiplexing, the Abis Channels are compounded by a
set of Multiplexed Channel Blocks (MCB).
One MCB connects 1 to 4 TRX of a single BTS to a single TCU.
One TCU can handle up to 4 MCB, according to the limit of 32 TCH per TCU.
Each MCB is composed of one multiplexed signaling channel and 2 to 8
Traffic Abis TS.
The following table describes 4 types of MCB configurations.
NAME

No. Of TS Used/
Number of FU

OML/RSL

Traffic Rate

SDCCH

MCB 64/4

9/4

1/4

FR only

32

MCB 64/2

5/2

1/2

FR or DR

32

MCB 64/1

3/1

1/1

FR or DR

32

MCB 16/1

2/1

1/1

FR only

32

Table 33: Multiplexed Channel Block

7.6 Mapping Techniques

7.6.1 Free Mapping Rules
The following rules apply:
The free mapping algorithm begins allocating from the highest usable TS
number downwards, up to the lowest usable TS number, and so on. It
is entirely controlled by the BSC.
The operator can reserve Abis TS per Abis (range of TS from Tsi to TSj)
(i and j from 0 to 31 and j>i). The operator can define (per BTS) the
usable TS inside the range defined on the Abis. The operator defines, TS
per TS, which one correspond to which BTS. This is necessary in the
case of cross connects.

104 / 162

3BK 17422 5000 PGZZA Ed.06b

7 ABIS Interface

For a given BTS, only TS defined as "usable" for this BTS can be allocated
by the BSC
For any BTS except Evolium BTS, the 2 TS needed to carry the traffic
channels over Abis must be contiguous
For Evolium BTS, the 2 TS required to carry the traffic channels over Abis
do not need to be contiguous, but the first set of 4 traffic channels (TRX-TS
0..3) must always be on a lower Abis-TS than the second set (TRX-TS 4..7)
Any TS of an Abis chain or ring is either free or occupied, and for certain
BTS, it is either usable or unusable
The Qmux, Rbits and Sbits can be mapped onto any usable TS from
TS0 to TS31
The OML and Qmux channels can be slotted anywhere by the operator
The RSL and TCH channels are slotted in any available TS by the BSC
RSL and traffic channels for one TRE must be on the same PCM link.

Note:

For an HSDS-configured BTS, refer to the mapping rules (extra Abis nibbles;
OML and RSL mandatory on first Abis) described in HSDS in the BSS (Section
2.5).

7.6.2 Abis-TS Defragmentation Algorithm

Certain types of BTS require that the TCH of a TRE are mapped on 2
consecutive 64Kbit/s PCM TS. There are no constraint for the signaling links.
Therefore, for BTS or TRE hardware extensions, two contiguous 64 Kbit/s PCM
TS may be required, while only 2 (or more) isolated PCM TS are free. An
algorithm must be run that creates 2 consecutive free TS, with minimum traffic
disturbance. This is referred to as defragmentation.
The operator can only add one TRE at a time. This operation is extremely rare
(there is no reason to have holes of 1 TS on Abis, and there is no extension of
G1/G2 BTS).
There is never any need to create in advance more couples of free PCM TS
than are required, as this would just lead to unnecessary traffic interruptions. It
is available only for G1 and G2 BTS.

7.6.3 RSL Reshuffling Algorithm

This chapter refers only to A9120 BSC.
The RSL_Reshuffle is triggered by explicit operator command (OMC) in case
of an Add BTS operation.
The RSLs inside one TCU must be moved to make room for new BTS
extensions within this TSU.
The following algorithms must ensure that FR and DR TCU are not mixed:
A MCB is either FR or DR and can only be mapped onto a TCU of the
same type
Extra Abis TS can only be mapped onto FR TCU
An empty TCU (without any MCB and extra Abis TS) can be set to FR or DR.

3BK 17422 5000 PGZZA Ed.06b

105 / 162

7 ABIS Interface

The sequence for remapping RSL/TRX and for programming the BIUA will be
reversed to reduce telecom outage. The scenario is as follows:
1. Construct a new RSL/TRX mapping and save this mapping in DLS.
2. Reprogram the BIUA based on this new mapping.
3. Activate the new RSL/TRX mapping in the BSC.
Each of these blocks are secured against take over, etc... Point (1) and (3) are
protected with a roll-back mechanism.
With HR flexibility, the reshuffling algorithm is kept but the reshuffling process is
to be conducted independently for each TCU type.

7.6.4 Cross-Connect Use on Abis

When cross-connects are used on Abis, different numbers are required for
the Abis TS used by the BTS (Qmux bus, OML, RSL and TCHs) on the BTS
connector and on the BIUA/E1 connector. This flexibility is supported by the
introduction of a TS mapping table between the BTS connectors and the
BIUA/E1 connectors.
The TS mapping table is introduced by the operator via the OMC-R and
applied by the BSC when a new BTS-BIE configuration is required, due to a
modification of the Abis TSs allocation. In order to keep the release B6 principle
of auto-allocation of TREs, this TS mapping table will be introduced during
the "Create an Abis chain/ring" operation. Also, in order to maintain a relative
flexibility on the TS allocation within the TS reserved for each branch connected
to the cross-connect, the operator must also be able to select the TS which can
be used by each BTS during the "Create BTS" operation.
At the OMC-R, the operator can only change usable Abis TS, usable BTS TS
and cross-connect tables.
The following figure provides an example of cross-connect use on Abis.

Figure 25: Example of Cross-Connect Use on Abis

The following table lists the possible TS mapping tables for the corresponding
Abis chain or ring in A9120 BSC.

106 / 162

3BK 17422 5000 PGZZA Ed.06b

7 ABIS Interface

TS Number for BIUA

TS Number for BTS-BIE

2 to 10

2 to 10

11 to 20

2 to 11

21 to 31

2 to 12

Table 34: TS Mapping Table for Corresponding Abis Chain or Ring Configurations
The following rules apply for TS use:
The TS which can be used for BTS 1 are 2 to 10
The TS which can be used for BTS 2 are 11 to 20
The TS which can be used for BTS 3 are 21 to 31.
When BTS 1 is created, according to the usable TS, the TS allocated for the
BIUA are 10-9-8, and according to the TS mapping table, the TS allocated
for the BTS-BIE are 10-9-8.
When BTS 2 is created, according to the usable TS, the TS allocated for the
BIUA are 15-14-13-12-1, and according to the TS mapping table, the TS
allocated for the BTS-BIE are 6-5-4-3-2.
When BTS 1 is created, according to the usable TS, the TS allocated for
the BIUA are 24-23-22-21, and according to the TS mapping table, the TS
allocated for the BTS-BIE are 5-4-3-2.
When a TRE is added to BTS 3, according to the usuable TS, the TS allocated
for the BIUA are 27-26-25, and according to the TS mapping table, the TS
allocated for the BTS-BIE are 8-7-6.
Cross-Connect Use on Abis Constraints
Cross-connect usage on Abis is supported only if the following rules are applied:
One BTS uses (for itself and for the forwarded Abis link) only PCM TS,
which come from a single BIUA/E1 connector
If Qmux is used, the BTS must be connected to the Qmux TS. The other
branch must use OML if possible (Evolium BTS).

Note:

"AND" and "BROADCAST" functions on the Qmux TS are required in the

intermediate cross-connect in order to respect the rules. If this function is not
possible, the Qmux bus is not implemented and downloading of the transmission
settings is performed via OML (if supported (Evolium BTS)) or locally.

7.6.5 SBL Numbering Scheme in A9120 BSC

The following table lists the SBL numbering on the A9120 BSC side.

3BK 17422 5000 PGZZA Ed.06b

107 / 162

7 ABIS Interface

SBL

Abis-HW-TP

BSC-Adapt

Physical object

Abis

BUIA Q port

BIUA P port

TCU

Numbering

1..84

1..84

1..112

1..112

TCU

Table 35: SBL Numbering at A9120 BSC Side

The following table lists the Abis port - BIUA - TCU SBL numbering in A9120
BSC.
BSC Configuration

SBL Number
Abis-Port

BIUA

TCU

Conf 1

1-6

1-8

Conf 2

7-12

9-16

13-18

17-24

19-24

25-32

25-30

33-40

31-36

41-48

37-42

49-56

43-48

57-64

49-54

65-72

55-60

10

73-80

61-66

11

81-88

67-72

12

89-96

73-78

13

97-104

79-84

14

105-112

Conf 3

Conf 4

Conf 5

Conf 6

Table 36: Abis Port - BIUA - TCU SBL Numbering in A9120 BSC
Where:
Rack 1: conf 1, conf 2
Rack 2: conf 3, conf 4
Rack 3: conf 5, conf 6.

108 / 162

3BK 17422 5000 PGZZA Ed.06b

7 ABIS Interface

7.6.6 SBLs Mapping on HW Modules in A9130 BSC Evolution versus

A9120 BSC
The figure below gives with their HW modules mapping, the different kinds of
SBLs seen on one hand, at the interface between the A9120 BSC and the BTSs
and, on the other hand, at the interface between the BTSs. The internal links
between TCU and BIU are mapped on SBLs having "BSC-ADAPT" as SBL type.

The figure below gives with their HW modules mapping, the different kinds of
SBLs seen on one hand, at the interface between the A9130 BSC Evolution
and the BTSs and, on the other hand, at the interface between the BTSs. For
the A9130 BSC Evolution, the SBL BSC-ADAPT is removed.

Note:

BIUA connectors in A9120 BSC correspond to E1 termination ports in A9130

BSC Evolution.

7.6.7 TCU Allocation Evolution in A9130 BSC Evolution

The "TCU allocation Evolution" feature enables the removal of different
constraints in A9130 BSC Evolution due to flexible TCU allocation approach.
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

3BK 17422 5000 PGZZA Ed.06b

109 / 162

7 ABIS Interface

done within a TSU i.e. set of 8 TCUs. With this feature TCU resource candidate
is extended to all the TCUs irrespective of the CCP baords i.e. not limited to 8
TCUs per TSU/BIUA as in A9120 BSC. This also means that mapping between
Abis & TCU will be replaced with free mapping of any TRE to any TCU as per
new TCU allocation algorithm. This feature aims at defining a new algorithm for
TCU allocation. The proposal is to treat all the TCUs as a pool where any Abis
signaling TS allocation can be routed to any TCU across CCPs boards.
We have the following benefits as far as removing this constraint is concerned:
TCU resource allocation will become more flexible
No need to perform reshuffling in any of the cases i.e. TCU compact &
SDCCH hot spot.
In A9130 BSC Evolution, TCU allocation will only involve the mapping of
signaling channels i.e. RSL/OML on a TCU. Since traffic will be switched within
TPGSM so it does not make sense to map TCHs & EXTS on to the TCU.
Moreover TCU allocation algorithm for signaling links will be highly flexible as
we can allocated any available TCU from the TCU pool from configuration point
view i.e. all TCUs across CCP boards will belong to one pool.
Note that we will still have the following constraint for TCU allocation:
TCU can handle maximum of 4 FR TREs (4 RSLs) or 2 FR + 1 DR TREs (3
RSLs) or 2 DR TREs (2 RSLs). In other words TCU can handle maximum
of 4 Eq. FR RSLs
TCU can handle maximum of 3 OMLs.
Note also that new constraints are added in order to map together all RSL/OML
of a given BTS on the TCUs belonging to one and the same CP-LOG in order
to avoid inter-CP messages and Telecom performance degradation. These
constraints are preference rules (not mandatory). If they cannot be fulfilled, the
RSLs of each given sector are kept together within one CP-LOG if possible.
Finally sectors are split if none of the preference rules can be fulfilled.

7.7 Abis Link Capacity

The following table lists the number of TS available in one Abis link to use for
TCHs and for the signaling channel.
Supervision

By Qmux

By OML

TS0

Transparency

Usage

Open Chain MD

30

31

31

Closed Loop MD

29

30

29

Table 37: Number of TS available in one Abis Link

The following table lists the number of required TS versus TRX number and
sub-multiplexing type in one Abis Link before HR flexibility.

110 / 162

3BK 17422 5000 PGZZA Ed.06b

7 ABIS Interface

Signaling Multiplex
Nb of TRX

No Multiplex

Static

Statistical 64

Statistical 16

10

13

10

16

13

12

10

19

15

14

12

22

17

17

14

25

19

18

16

28

22

20

18

10

31

24

22

20

11

Impossible

26

26

22

12

Impossible

28

27

24

13

Impossible

Impossible

30

26

14

Impossible

Impossible

Impossible

28

15

Impossible

Impossible

Impossible

30

Table 38: Number of Required TS versus TRX Number and Sub-Multiplexing Type
In the case of no multiplexing, there are maximum 10 TRX.
In the case of static multiplexing, it is possible to connect one G3 BTS 3*4 in
one open chain link.
In the case of statistical 16K multiplexing, it is possible to connect 15 M4M with
one TRX or 7 M4M with 2 TRX in one open chain link.
The following table provides example FR/DR ratios according to cell size.

3BK 17422 5000 PGZZA Ed.06b

111 / 162

7 ABIS Interface

Number of TRX in
Cell

DR + FR TRX

Max % HR

Number of TCU
Required (DR +
FR)

Number of SIG
TSs
(Statistical Mux)
(Low SIG Traffic)

1+0

100%

[frac12] + 0

1+1

66%

[frac12] + [frac14]

1+2

50%

[frac12] + [frac12]

1+3

40%

[frac12] + [frac34]

3*

2+2

66%

1 + [frac12]

2+4

50%

1+1

2+6

40%

1 + 1 [frac12]

10

4+6

40%

2 + 1 [frac12]

10

3+7

47%

1 [frac12] + 1
[frac34]

5*

10

2+8

33%

1+2

12

4+8

50%

2+2

14

2+12

25%

1+3

16

0+16

0%

: These unfortunate numbers come from the need to split any group of 3 TREs as 2+1 to facilitate the mapping. Some
other choices are however possible, as shown by the table.

Table 39: Example of FR/DR Ratios According to Cell Size

7.8 Abis Satellite Links

The Abis interfaces were designed to use reasonably short terrestrial
transmission links. However, in developing countries, the terrestrial
transmission infrastructure does not exist and in many cases is difficult and
costly to provide. There is also a need in the developed world to provide
temporary GSM coverage for transient mobile population density increases, for
example, at sporting events.
Geostationary earth orbiting satellites are a simple and relatively low cost
solution. However, satellite links cannot be used at the same time on the Abis
interface and on the Ater interface Ater Satellite Links (Section 8.7).
This feature is only available for Evolium BTSs and later versions.
The following configuration rules apply:
On Abis, the satellite link is considered to be installed between the BSC and
the first BTS of the multidrop. If this is not the case, the drawback is that

112 / 162

3BK 17422 5000 PGZZA Ed.06b

7 ABIS Interface

timers applied on the first BTS will be unnecessarily lengthened and this
does not support high traffic with poor quality links.
Usually, only a part of the TS is routed via the satellite. The customer must
take care to route the required TS.
The type of connection is defined per Abis link.
For those BTS where the satellite link is installed, the following features are
not available:
Closed multidrop (Abis topology)
The BTS must be configured as a free run (no PCM synchronized) (OCXO
synchronization).
It is planned to support synchronous handovers.
Support of fax and data (in CS mode, transparent and not transparent) depends
on timers managed by the NSS part.
GPRS connections are supported over satellite links (Abis or Ater).
In the case of incorrect synchronization of the BTS / TC, GSM recommendations
describe the synchronization process based on a roundtrip delay BTS <->
TC smaller than 120ms. This is not true in the case of satellite links. In
consequence, when a TRAU frame is not synchronized with the BTS, the
permanent synchronization process provokes oscillations, leading in the worst
case (arrival time versus expected time too different) to a loss of 5% of the
speech frames.
For OML autodetection via satellite, a timer has been designed to be able
to manage the transmission delay. In that context, OML autodetection via
satellite is possible.
There are no restrictions for Abis satellites supporting LCS.

7.9 Two Abis Links per BTS

If HSDS is to be introduced in a BTS configuration, and if there are not enough
Abis TS on one Abis link, a second Abis can be attached to the BTS. In that
case, OML, RSL and basic TS are always mapped to the first link and the extra
TS for the TRX transmission pools are split over the 2 Abis links.
This is shown in the following figure.

3BK 17422 5000 PGZZA Ed.06b

113 / 162

7 ABIS Interface

For a BTS with two Abis links, the operator defines a new parameter,
MAX_EXTRA_TS_PRIMARY, which defines the maximum number of extra TS the
system is allowed to allocate on the first Abis for this BTS.
To keep the maximum free TS on the secondary Abis, the allocation of
extra TS is done in priority on the first Abis until this Abis is full or until
MAX_EXTRA_TS_PRIMARY is reached.
In terms of the Abis topologies supported, the BTS can manage only 2
termination points.
The second Abis is useful when there is not enough space on one complete
Abis for all BTSTS. This means that the primary Abis must be fully assigned to
the BTS. Therefore, the secondary Abis cannot be attached to a BTS if the
BTS is not alone on the primary Abis.
Consequently, only two added Abis topologies are supported in release B8.
This is shown in the following figure.

114 / 162

3BK 17422 5000 PGZZA Ed.06b

7 ABIS Interface

The primary Abis and the secondary Abis of a BTS can be on different TSU of
different racks.
There are no restrictions concerning cross-connection on the primary Abis.
However, on the secondary Abis, because there is no RSL on this Abis, the fault
management of the link must be based on the transmission alarm. The system
does not check for a cross-connect on the secondary Abis. Cross-connection is
not supported on the secondary Abis.
Rules
The following rules apply:
The second Abis per BTS is only used for packet traffic (i.e. no LapD, no
CS, no basic Abis nibble)
OML, RSL and basic TS are always mapped to the first link and the extra
TS for the TRX
Transmission pools are split over the 2 Abis links
Only an Evolium BTS with SUMA boards or M5M supports the second
Abis link
An Evolium BTS with a SUMP board has to be upgraded. An Evolium BTS
can only manage 2 termination points.
This implies that it is not possible to:
Connect a BTS in chain after a BTS with two Abis
Change the Abis from chain to ring if there is a BTS with 2 Abis

3BK 17422 5000 PGZZA Ed.06b

115 / 162

7 ABIS Interface

Attach a second Abis to a BTS that is not at the end of an Abis chain
Attach a second Abis to a BTS that is in an Abis ring.
The second Abis link can be supported on G3 TREs.
In release B8, due to the fact that RSLs are only on the first Abis link, all
Evolium BTS with SUMA boards are able to manage 2 Abis links.
It is not possible to have the primary Abis via satellite and the secondary link
by terrestrial means.

116 / 162

3BK 17422 5000 PGZZA Ed.06b

8 Ater Interface

8 Ater Interface
Ater Interface describes the Ater interface, and corresponding features and
functions.

3BK 17422 5000 PGZZA Ed.06b

117 / 162

8 Ater Interface

8.1 Ater Network Topology and Transport

There are several ways of transporting Atermux over networks (the following list
is not exhaustive):
A terrestrial link referred to as the PCM 2Mbit/s link (64 Kbit/s * 32 Time
Slots = 2048 Kbit/s)
A microwave link (same capacity or higher)
Digital cross-connect network equipment, which concentrates 4, 16 or 64
PCM 2Mbit/s link
A microwave hub equivalent to DCN
A satellite link.

8.2 Impedance
There are 2 types of impedance which define the access to the transmission
network:
120 Ohm Balanced Two twisted pairs
75 Ohm Unbalanced two Coaxial cables (only for A9120BSC).

Note:

It is forbidden to mix impedance in the same BSS.

8.3 Numbering Scheme on A9120 BSC-Ater/Atermux/TC Ater/A

Interface
8.3.1 Overview
The following table shows an overall view of the SBL numbering scheme of
the path trunks from A9120 BSC DTC/ASMB through the PCM Atermux to
the transcoder.
The SBL numbering of the TRCU always follows the numbering of the
respective DTC/Ater (i.e. from 1...72).
BSC Side

PCM

G2 TC Side 4:1

TC Rack

DTC/Ater

ASMB

Atermux

ASMC

ATBXAter/A

1-4

1-4

5-8

5-8

9-12

9-12

13-16

13-16

17-20

17-20

21-24

21-24

118 / 162

Rack 1

3BK 17422 5000 PGZZA Ed.06b

8 Ater Interface

BSC Side

PCM

G2 TC Side 4:1

TC Rack

25-28

25-28

29-32

29-32

33-36

33-36

37-40

10

10

10

37-40

41-44

11

11

11

41-44

45-48

12

12

12

45-48

49-52

13

13

13

49-52

53-56

14

14

14

53-56

57-60

15

15

15

57-60

61-64

16

16

16

61-64

65-68

17

17

17

65-68

69-72

18

18

18

69-72

Rack 2

Rack 3

Table 40: Numbering Scheme on BSC-Ater/Atermux/TC Ater/A Interfaces

8.3.2 Numbering Scheme on the A9120 BSC Side

Atermux numbering follows the ASMB numbering, and A Trunk numbering
follows the DTC numbering.
The A9120 BSC has 18 * 4 = 72 A trunks.
The following table shows the numbering scheme as for the 19120 BSC side.
SBL

Ater-HW-TP

SM-Adapt

ATR

DTC

Physical object

Atermux

ASMB

Ater

DTC

Numbering

1...18

1...18

1...72

1...72

Table 41: Numbering Scheme on A9120 BSC Side

8.3.3 Numbering Scheme at G2 TC Side

On the G2 TC side, the scheme numbering follows the same scheme as for
the A9120 BSC side.
This is described in the following table.

3BK 17422 5000 PGZZA Ed.06b

119 / 162

8 Ater Interface

SBL

Ater-HW-TP

SM-Adapt

ATR

A-PCM-TP

Physical object

Atermux

ASMC

A Interface

ATBX / A Interface

Numbering

1...18

1...18

1...72

1...72

Table 42: Numbering Scheme on G2 TC Side

8.4 Numbering Scheme on A9130 BSC

Evolution-Ater/Atermux/TC Ater/A Interface
8.4.1 Overview
For detailed numbering scheme for A9130 BSC Evolution - Atermux see 600
TRX LIU Shelf connections assignment (18).
To avoid the handling of big TC configuration, and because the A9130 BSC
Evolution is anyway limited in Erlangs, there are two kinds of Atermux with
A9130 BSC Evolution:
Atermux from 1 to 30 that could be connected to MFS or TC: E1 Ater
CS (Circuit Switch)
Atermux from 31 to 48 that could be connected only to MFS: E1 Ater
PS (Packet Switch).
This is why the number of Ater-Hway-TP is not the same at TC side and at
A9130 BSC Evolution side. Ater-Hway-TP from 31 to 48 could be used only for
GPRS dedicated atermux.

8.4.2 SBLs Mapping on HW Modules in A9130 BSC Evolution versus

A9120 BSC
The figure below gives with their HW modules mapping, the different kinds
of SBLs seen at the interface between the MSC and the G2 BSC ( for a TC
G2). The internal links between TIU and SM (at TC side) and the internal links
between SM (at BSC side) and DTC are mapped on the SBL on which they
terminate (SBLs with "TC-ADAPT", "SM-ADAPT" or "A-tr" as SBL type).

120 / 162

3BK 17422 5000 PGZZA Ed.06b

8 Ater Interface

The figure below gives with their HW modules mapping, the different kinds of
SBLs seen at the interface between the MSC and the A9130 BSC Evolution (for
a TC G2). For the A9130 BSC Evolution, the SBL SM-ADAPT (BSC side) is
removed and the SBL ATR becomes logical.

8.5 Signaling on Ater/Atermux Side

8.5.1 Overview
Signaling links are conveyed on the A trunk between different entities ([laquo ]
A trunk [raquo ] refers to the A, Ater and Atermux links):
Signaling System N 7 (SS7)
SS7 carries the signaling information relating to call control and mobility
management between the BSS and MSC. The signaling is arranged
according to the CCITT Recomendations Q.700-714 for the network protocol
layer and to GSM 08.08 for the GSM application layer.
X.25
An X.25 link is set between the A9120 BSC and the OMC_R. Depending
on the BSC position related to the OMC_R, this link can be directly
established from the A9120 BSC to the OMC_R via an X.25 network, or
carried up to the TRCU site or the MSC site on the A trunk and then via
an X.25 Network (TS31).
IP

3BK 17422 5000 PGZZA Ed.06b

121 / 162

8 Ater Interface

The connection of A9130 BSC Evolution with the OMC-R is based on IP

protocol on both two routes, namely over direct IP network, or over Ater
and IP network.
GSL
The GSL handles signaling for GPRS paging and for all synchronization
between the BSC and the MFS (TS28).
Qmux
Qmux is always carried in the first nibble of TS 14.

8.5.2 Signaling Link Code

On the BSC/MSC interface, the Signaling Link Code (SLC) included in the
header (the label) of the Message Transfer Part (MTP) level 3 messages is
coded on 4 bits, with values ranging from 0 to 15.
There are no known constraints on SLC values. The value 0 has no particular
relevance when compared to the others. When less than 16 SS7 links are used
in a given signaling set, the SLC values in use can not be consecutive.
The SLC is an interface attribute concerning both the BSS and NSS. It is not a
private DTC attribute. In principle, the SLC values are determined by a bilateral
agreement and assigned to the peer BSC and MSC management entities using
O&M configuration procedures. A SLC value is unique within a BSS.
In terms of SLC value allocation:
The operator allocates the first free SLC to a SS7 link when it is created,
starting from 0 and going up to 15
The BSC ensures that all SS7 links use different SLC values
For each added SS7, its SLC equals the highest SLC which is not already
associated with an equipped SS7. This algorithm must be performed for
newly added SS7 in the increasing order of SS7 SBL numbering (i.e. the
new SS7 with the lowest SBL number must be processed first, and so on).
Such an algorithm is flexible enough to be compatible with any already
installed configuration. Furthermore, in the case of an MSC which does not
handle SLCs equal to "0", it guarantees that the SS7 which is associated
with the SLC "0" will be always the 16th (this SS7 must remain "OPR").
As for CIC modification, the OMC-R must guarantee that 2 different SS7 never
have the same SLC (requirement valid on a per BSS basis). The MSC must be
configured accordingly when the corresponding SS7 is initialized.
Some MSCs are configured with SLCs starting from "1" (instead of "0"). The
OMC-R has no knowledge of such a restriction, therefore the OMC-R operator
is always allowed to choose "0" as an SLC, and no check is performed
concerning the reduced SLC range (the SLC range is always "0-15").
A BSC linked to an MSC which does not handle SLCs equal to "0" can handle a
maximum of "15" SS7s (instead of "16" normally); however, in such a case, the
maximum BSC traffic capacity cannot be achieved.

8.5.3 SS7 Links

There are a maximum of 16 SS7 links, defined by:
The SLC is known by MSC and BSC within 4 bits

122 / 162

3BK 17422 5000 PGZZA Ed.06b

8 Ater Interface

SBL numbering corresponds to DTC numbering which follows A trunk

numbering.
The following table shows SS7, Atermux, DTC and Ater numbering. The
Network Location (NAD) is the DTC location in the BSS.
A9120 BSC
Configuration

SBL SS7/DTC/Ater
Number

NAD

Atermux

Conf 1

020

024

030

13

034

17

120

21

124

25

220

29

224

33

230

37

234

10

41

320

11

45

324

12

49

420

13

53

424

14

57

430

15

61

434

16

Conf 2

Conf 3

Conf 4

Conf 5

Conf 6

Table 43: SS7, Atermux, DTC and Ater Numbering

8.6 GPRS and GSM Traffic on Atermux versus A9120 BSC

8.6.1 Overview
The following information describes GPRS and GSM traffic on the Atermux
of the BSS (A9120 BSC, G2 TC).
CS refers to circuit switched GSM traffic, and PS refers to packet switched
GPRS traffic.

3BK 17422 5000 PGZZA Ed.06b

123 / 162

8 Ater Interface

For dedicated GPRS Atermux links, all traffic TS are used for GPRS. SM (TC
site) and associated TRCUs are not equipped. SS7 TS is not used, with or
without GSL LAPD.
Note that iIn the MFS to BSC direction, on the Atermux supporting the "Alarm
octet" (or TS0 info), the MFS will force a fixed pattern that will be used by
the SM (at the BSC site).
For mixed GPRS/CS Atermux links, the traffic TS can be used 12.5% or
25% or 50% or 75% or 100% for GPRS, with or without GSL LAPD. SS7 is
carried (without Atermux 17 and 18).
On the Atermux, channels located within the TS also containing the Qmux
cannot be used for GPRS.

Note:

The Atermux channels located on the same Atermux TS as the Qmux cannot
be used for GPRS (they are kept as CICs).
X.25 links can optionally be carried on the first 2 Atermux in the BSC.
Qmux links are always carried on the first 2 Atermux in each rack.
If there is an SS7, link then the Atermux can carry either CS or a mixture of
PS and CS traffic.

8.6.2 Hole Management in a G2 TC

When GPRS is introduced in a BSS and when an Atermux is fully dedicated
to the GPRS, the related ASMC in the TC rack and TRCU are not used,
because Gb does not go through TC.
When an Atermux dedicated to GSM traffic is added to the BSS later, the
ASMC in the TC rack and the TRCU which were not used, remain unused and
the added Atermux is connected to the following ASMC in the TC rack. This
can be considered as a hole in the TC rack configuration where an ASMC
will be never used.
This is shown in the following example:
First state:
Atermux is used for GSM traffic
G2 TC rack filled with 4 Atermux.
Second state:
GPRS Introduction
With dedicated Ater for Gb interface
Atermux 5 and 6 are put as NEQ for G2 TC equipment.
Third state:
GSM traffic increase
Need additional Atermux (TC boards)
A new rack is needed because Atermux 5 and 6 are NEQ.

8.6.3 Sharing Atermux PCM Links

The following PCM rules apply:

124 / 162

3BK 17422 5000 PGZZA Ed.06b

8 Ater Interface

X is the number of Atermux between the BSC and the GPU

Y is the number of Atermux between the GPU and the TC
Z is the number of Gb Interfaces between the GPU and SGSN.
X+Y+Z <= 16
When the Atermux transports mixed traffic: X=Y
There are a maximum 16 PCM links at the GPU for traffic, but in the case of
Fixed Synchronization Sources feature use, only 8 PCM links can be used
for traffic.
When an MFS shelf is in autonomous synchronization mode, there must be
2 "transcoder" links between each GPU and a good synchronization source
(which can be a transcoder), or between each GPU and the SGSN if this
option is used.
In the case of MFS shelf synchronization with central clocking within the MFS,
GPUs within a MFS are synchronized on a system clock generated by 2 GPUs
assigned as master in 1+1 redundancy mode within a subrack.
MFS must be homogeneous (either all autonomous mode or all central clock
mode).
The following tables shows GPU Atermux connection example scenarios.
Scenario

With scenario 1, CS traffic goes to the MSC through the TC and PS traffic
goes to SGSN through the TC-MSC.
With scenario 2, CS traffic goes to the MSC through the TC and PS traffic
goes directly to SGSN.
With scenario 3, CS traffic goes to the MSC throughthe TC and PS traffic
goes directly to SGSN.
Atermux

X=BSC-GPU

Y=TC-GPU
Z=GPU-SGSN

Minimum

Y+Z=1

Redundant

Y+Z=2

Maximum

6(*)

Y+Z=10

3BK 17422 5000 PGZZA Ed.06b

125 / 162

8 Ater Interface

: The maximum (Y+Z=10) corresponds to scenario 2, in this scenario, CS, coming from the mix GSM & GPRS (X), goes
to MSC through TC (Y = 6 links). The Gb is only supported by the direct connection to SGSN

Table 44: GPU Atermux Connections Example Scenarios

The minimum number of GPU-TC and GPU-SGSN links (Y+Z) is 1. The
maximum number of BSC-GPU links is 13, and the maximum number of
BSC-MFS links depends on the BSC conf (BSC conf 1-4 links, BSC conf 2-6
links, BSC conf 3-10 links, BSC conf 4-12 links, BSC conf 5-16 links and BSC
conf 6-18 links). It is also possible to have one complete PCM (X) with GPRS
and a direct connection to SGSN (then Y can be null). Z also can be null.
It is important to note that:
Each DSP supports 120 GCH
The GPU handles less than 480 GCH to avoid blocking the DSP
A full Ater Mux carries 112 GCH (32 TS - TS0, alarm octet, SS7, GSL)
5 Ater Mux are needed to support 480GCH
The increase of throughput is due to E-GPRS channels
The minimum usage of mixed Ater Mux (CS+PS).
The next configuration per GPU is as follows:
5 PCM towards BSC (one is mixed)
1 PCM towards TC or SGSN
2 PCM towards SGSN
5 bearer channels per PCM SGSN.

8.6.4 Ratio of Mixing CS and PS Traffic in Atermux

The following table lists the ratio available to mix CS and PS traffic.
CS

TS TCH

PS

TS GCH

Full

116

Null

7/8

100

1/8

16

3/4

84

1/4

32

1/2

56

1/2

60

1/4

28

3/4

88

Null

Full

116

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

The TS numbers are a maximum value, and depend on the presence (or
not) of signaling links.

126 / 162

3BK 17422 5000 PGZZA Ed.06b

8 Ater Interface

The use of GSL on a given Ater Mux takes the place of 4GCH nibbles on
this link.
TS 15 is always occupied for N7, even if it is not used.

8.7 Ater Satellite Links

The Ater interfaces were designed to use terrestrial transmission links.
However, in developing countries the terrestrial transmission infrastructure does
not exist and in many cases is difficult and costly to provide. There is also a
need in the developed world to provide temporary GSM coverage for transient
mobile population density increases, for example, at sporting events.
Geostationary earth orbiting satellites are a simple and relatively low cost
solution. However, satellite links cannot be used at the same time on both the
Ater interface and the Abis interface (see Abis Satellite Links (Section 7.8) ).
The following configuration rules apply:
On the Ater interface, all the links are handled in the same way. The satellite
link can be installed either on the Ater (between the BSC and the TC), or
on the A interface (between the TC and the MSC). As the latter case is
comparatively rare, the wording Ater is used. In the case where the satellite
link is on the A interface, the modification of the transmission supervision
timer is not useful but is implemented.
In the case where only a part of the TS are routed via the satellite, at least
Qmux, X25 (if via A interface) must be routed. Non-routed channels must be
blocked either from the MSC or from the OMC-R.
If only one link is forwarded, there will be no redundancy on SS7, X25, or
Qmux. This configuration is not recommended but it does work.
When A interfaces, or Ater interfaces, are routed via satellite, the SS7 are
configured to use Preventive Cyclic Retransmission (PCR).
There are no restrictions for Ater satellites supporting LCS.

3BK 17422 5000 PGZZA Ed.06b

127 / 162

8 Ater Interface

128 / 162

3BK 17422 5000 PGZZA Ed.06b

9 GB Interface

9 GB Interface
GB Interface describes the GB interface, and corresponding features and
functions.

3BK 17422 5000 PGZZA Ed.06b

129 / 162

9 GB Interface

9.1 Gb Topology
The interface between the MFS and the SGSN is referred to as the Gb
interface. It is supported by 2Mbit/s PCM links of 32 TS at 64Kbit/s.
There are three possible ways to connect the MFS to SGSN:
Via Gb links directly to SGSN

Figure 26: Gb Link Directly to SGSN

Via Atermux links and Gb links through the TC and the MSC, therefore CS
TS are routed transparently to the MSC across the MFS. GPRS TS are
transparent in the TC. GPRS TS are converted to Gb TS in the MFS. The
TC transmission is updated in this case, so that TC is ready when Gb goes
to SGSN through the TC (notion of "ready for Gb")

Figure 27: Gb Link through the TC and MSC

Via Gb links from the MFS to SGSN through the MSC, whereby a PCM is
dedicated to Gb interface and GPRS TS are converted to Gb TS in the MFS.

130 / 162

3BK 17422 5000 PGZZA Ed.06b

9 GB Interface

Figure 28: Gb Link through the MSC

9.2 Gb Configuration
BSSGP, Network Service (NS) and physical layer protocols define the Gb
interface. The BSSGP manages GB Interface manages Virtual Connections
(BVC) identified by their BCVI.
There are three types of BVC:
BVC-PTP
Virtual circuit Point to Point assigned for the GPRS traffic of one cell: BVCI>1
BVC-PTM
Virtual circuit Point to Multi-point (not used in the BSS): BVCI=1
BVC-SIG
Signaling of all BVC-TTP: BVCI=0.
The NS depends on the Intermediate Network Transmission (ITN), in two parts:
The Sub-Network Service (SNS) depends on ITN. At present, the ITN
used is Frame Relay. The SNS handles Permanent Virtual Connections
(PVC). Each PVC is associated with one NS-VC. The Data Link Connection
Identifier (DLCI) is used to number the PVC. The DLCI=0 is not PVC but is
used for signaling on the Bearer Channel BC0.
Network Service Control (NSC) is independent from ITN. The NSC handles
NS-VC virtual connections end to end MFS-SGSN. An Network Service
Element (NSE) is a group of NS-VC.
Only one NSE is declared per GPU board (in the case of multi-GPU per
BSS), so that adding a new GPU for a BSS implies the following on the SGSN
side for the Gb interface:
The definition of a new NSE (the NSE identifier is unique, is an O&M static
information and is given by SGSN)
The definition and declaration on the SGSN side of the PVCs and NS-VCs
of this NSE (NS-VCI are O&M static information).

3BK 17422 5000 PGZZA Ed.06b

131 / 162

9 GB Interface

The Bearer Channel can be minimum 64 Kbit/s TS or a bulk of adjacent 64

Kbit/s TS or Maximum 31 of 64 Kbit/s TS of E1 Digital Hierarchy Transmission
Network.
The following figure shows the logical context for the Gb Interface.
The secured single Gb allows installing twice less GB links than with the old
recommended configuration rules, having two PCM-TTP & 2 NS-VC per
FR-BC for redundancy. In case of a GB failure on a given GPU board, a
re-routing is done from Cell Traffic of the handicapped GPU to the all GB stack
(at BSSGP level) of other GPUs of the same BSS, which have Gb available.
There is no impact on the current cells mapping, i.e. cells remain mapped on
their related GPUs.

Figure 29: Gb Logical Context

132 / 162

3BK 17422 5000 PGZZA Ed.06b

10 CBC Connection, SMSCB Phase 2+

10 CBC Connection, SMSCB Phase 2+

CBC Connection, SMSCB Phase 2+ describes the GSM Short Message
Service Cell Broadcast features and functions.

3BK 17422 5000 PGZZA Ed.06b

133 / 162

10 CBC Connection, SMSCB Phase 2+

10.1 Overview
The GSM Short Message Service Cell Broadcast (SMSCB) allows the
distribution of messages from a SMSCB centre (CBC) to MS listening in idle
mode to a general broadcast channel called the CBCH.

10.2 GSM Cell Broadcast Applications

There are 2 types of applications for the GSM Cell Broadcast feature:
Applications where the information broadcast relates more or less to MS
operation in the network. This type of application is driven directly by the
network/operator. Applications such as home zone indication, charging
rate indication or Network condition indication, are value added features for
the operator
Applications where the operator offers the Cell Broadcast facility for use
by entities external to the GSM Network. Applications such as road traffic
information, public safety, advertisements, etc., can be a source of additional
revenue for the operator.
Note that the 2 types of applications described can coexist.

10.3 Solutions
10.3.1 Solutions in A9120 BSC
For the X25 CBC-BSC connection (which differs from the OMC connection),
several alternative solutions are proposed:
PSDN
Connection via Ater, extraction at TRCU
Connection via Ater, extraction at MSC.
The solution by default is PSDN. A BSC can be connected to one CBC
maximum.

10.3.1.1 CBC-BSC Interconnection via PSDN

Normally, an alternative solution will be used for CBC-BSC interconnection.
Two links can be provided towards the CBC:
Primary link
Secondary link (back-up link).
The secondary link is optional. This redundant link, if exists, will only be used if
the communication with the CBC cannot be achieved using the primary link.
The following figure shows CBC-BSC interconnection via PSDN.

134 / 162

3BK 17422 5000 PGZZA Ed.06b

10 CBC Connection, SMSCB Phase 2+

Figure 30: CBC-BSC Interconnection via PSDN

10.3.1.2 CBC-BSC Interconnection via MSC

For a private operator who pays a high price for connections, or for export
markets where there are no X.25 networks, the following solution may be
required.
It is preferred that the CBC and OMC-R are collocated (connected to the same
MSC). Otherwise this solution is technically too complicated, because of :
Redundancy of the external equipment (router) and transmission lines (LL)
Switchovers to handle
O&M to manage for external equipment (managed generally by proprietary
or SNMP stacks which prevent an integrated Network Management).
The following figure shows CBC-BSC interconnection via the MSC.

3BK 17422 5000 PGZZA Ed.06b

135 / 162

10 CBC Connection, SMSCB Phase 2+

Figure 31: CBC-BSCs Interconnection via the MSC

10.3.2 Solutions in A9130 BSC Evolution

X25 protocol is still supported for CBC interface. The direct connection of CBC
from the BSC site is no more supported. The connection of CBC is done
through the X25 over Ater at TC or MSC site. According to 3GPPs definition,
SMS-CB service keeps X.25 connection. So A9130 BSC Evolution keeps
transferring X.25 packets to CBC over Ater on TC/MSC site or direct over IP
network on A9130 BSC Evolution site. (ML-) PPP or 802.3A/B is used on
A9130 BSC Evolution site to carry X.25 packets. No LapB is supported again.

136 / 162

3BK 17422 5000 PGZZA Ed.06b

Appendix A : BSS Hardware Capability

Appendix A: BSS Hardware Capability

The following table describes BSS hardware compatibility.
B9 Release

M4M M5M G3
A9120 G2
FR DR
G1
G2
G4
G2
BTS BTS
BTS BTS BSC TC - TC/A9125 TCU TCU
Mk II DRFU
DT16 MT120
DRFU

No Mux

64k Statistical 64/1-2-4

16k Statistical

Static

FR

DR

Flexible DR

EFR

4:1 Ater Mapping

Multiband BTS

Multiband Cell

GPRS (CS-1,CS-2)
GPRS (CS-3,CS-4)

EGPRS(MCS-MCS9)

2nd Abis access

3BK 17422 5000 PGZZA Ed.06b

x
x

137 / 162

Appendix A : BSS Hardware Capability

138 / 162

3BK 17422 5000 PGZZA Ed.06b

Appendix B : Cell Radio Channel Configuration

Appendix B: Cell Radio Channel Configuration

B.1 Definitions
B.1.1 Cell Allocation
Cell Allocation is the list of frequencies assigned to a cell. The defined
frequencies will be a superset of those frequencies, which can be subsequently
used.
Cell Allocation information is no longer used since release B6.2. The list of
used frequencies and the BCCH definition will be computed by the BSC from
information contained in other parameter groups. It is not provided by the
BSC during audit.
For a multiband cell, the zone supporting the BCCH and the second zone have
separate Cell Allocations, each containing obviously either GSM or DCS
frequencies. The Cell Allocation for the second zone is not sent to the BSC
and is not available from BSC audits.

B.1.2 TRX Configuration

Within a cell, the radio channels are grouped into TRX. A TRX is a conceptual
entity controlled by the BSC, modeling 8 Abis channels mapped onto 8 Air
Interface radio TS (TRX_TS). The 8 radio channels are therefore disjointed in
terms of time, but they can use common frequencies. The channels of a TRX
are controlled over one common radio signaling link on the Abis Interface (RSL).
A TRX is a logical entity that exists independently of the hardware, however it
cannot perform any real function until supported by operational hardware parts.
The TRX configuration consists of:
An indication as to whether the TRX is supported by the main sector or the
secondary sector. This indication is only necessary in the case of shared
cells. For non-shared cells, all TRX are implicitly main but the indication is
not visible to the operator.
Radio definition
This defines the frequency usage of each radio channel:
For a non-hopping channel, a fixed frequency is used, defined by means
of an ARFCN
For a pseudo non-hopping channel, a set of frequencies is used but the
set contains only one element. (one ARFCN)
For the hopping channel, a set of frequencies (defined as ARFCNs), a
hopping sequence law and a MAIO are used.
Baseband definition, which defines the channel usage of each of its 8 TS
The following table provides an overview of the different channel types.

3BK 17422 5000 PGZZA Ed.06b

139 / 162

Appendix B : Cell Radio Channel Configuration

The TRX hopping mode defines whether a TRX uses one or more frequencies:
Non-hopping TRX
A TRX that uses the same frequency on every burst on every TS
Hopping TRX
A TRX that can change its frequency on every TS from burst to burst
To have a graphical view of the TRX configuration, it is convenient to present all
TRXs of the cell in parallel, and to group TRX_TSs, which use the same FHS
(same frequencies with the same HSN). This is shown in the following figure.

140 / 162

3BK 17422 5000 PGZZA Ed.06b

Appendix B : Cell Radio Channel Configuration

For instance, TS 1, 2, 4, 5, 6, 7 of TRX 1, 2, 3 use the same FHS with the

mapping TRX 1/MAIO 0, TRX 2/MAIO 1, TRX 3/MAIO 2.
It must be noted that to follow the rules, the relations between FHSs are:
fb belongs to FHS1 (BCCH FHS)
FHS2=FHS1 - fb (reduced FHS)
FHS3 contains different frequencies from FHS1.

B.1.3 Hopping Types in a Cell

The hopping type is the logical hopping configuration of a cell defined at radio
channel configuration time. There is no relationship with the physical way in
which the BTS hops. The operator provides the hopping type explicitly to
the OMC.

Note:

Configuration of an extended FHS sequence with more than 16 and up to 64

frequencies is allowed only if the feature Extended FHS sequence is licensed.
The possible hopping types from a configuration point of view are:
Non Hopping (NH)
If all TRXs of a cell are non-hopping TRXs then the cell has the hopping
type "Non Hopping".

3BK 17422 5000 PGZZA Ed.06b

141 / 162

Appendix B : Cell Radio Channel Configuration

Base Band Hopping (BBH)

If all TRXs of a cell are hopping TRXs and the number of used ARFCNs
equals the number of TRXs then the cell has the hopping type "Base
Band Hopping".
BBH offers the advantage of hopping on all TS. There are no collisions of
frequencies on the TRXs of a cell. If the operator wishes to have a mix of
"non hopping" TRXS and hopping TRXs, it is possible to define FHS with
one frequency.
Radio Hopping (RH)
If the BCCH TRX is a hopping TRX and the number of ARFCNs defined
for this cell is higher than the number of equipped CUs/TREs then the
cell has the hopping type "Radio hopping". The terminology Free Radio
Hopping is also used.
In this case, hopping is performed over an almost arbitrary number of
frequencies. Note that the RH type requires specific hardware on every
TRE. Currently, only cells with one TRX are supported in RH mode.
As G2 micro BTS are not more supported by a B9 BSS, the RH mode is no
more used in a B9 BSS.
Non Hopping Radio Hopping (NH/RH)
If at least one TRX of a cell is a hopping TRX, the BCCH TRX is a
non-hopping TRX on the BCCH ARFCN, and the number of ARFCNs
defined for this cell is higher or equal to the number of equipped CUs/TREs,
then the cell has the hopping type "Non hopping/Radio hopping".
The NH/RH offers the advantage of the use of a considerable number of
frequencies. One disadvantage is that one TRX is NH. In the case of
the NH/RH hopping mode, interferences can be avoided by a judicious
configuration of the MAIO, on a per BTS basis.

B.1.4 Radio Carrier Hopping Capability

The possible values for the hopping capability from a BTS Carrier Unit point of
view reported during the hardware audit are as follows:
Mono frequency
The Radio Carrier can generate only one frequency.
RH without on-board BCCH filler
The Radio Carrier can generate one frequency per TS. The generated
frequency can differ for every burst.
RH with on-board BCCH filler
The Radio Carrier can generate one frequency every TS. The generated
frequency can differ for every burst. If this frequency is not the BCCH
frequency then the Radio Carrier generates (at the same time) a dummy
burst on the BCCH frequency. This mechanism ensures the presence of the
BCCH frequency on every TS. This is not supported by a release B9 BSS.

B.1.5 Use of the Hopping Types per Subsystem

B.1.5.1 OMC-R
The accepted configurations are as follows:
BBH

142 / 162

3BK 17422 5000 PGZZA Ed.06b

Appendix B : Cell Radio Channel Configuration

The BCCH TRX TS is configured with either the BCCH ARFCN or the
FHS containing the BCCH frequency (complete FHS). The number of TS
configured with BCCH ARFCN must not exceed 7.
Other TRX:
If TS I of the BCCH TRX does not hop, the TS I of each TRX must
not hop on the BCCH ARFCN (reduced FHS)
All other TS hop on:
The complete FHS
An other FHS (if the rule number of used frequencies = number
of TRX)
A mono-frequency FHS, which is a TRX referred to as a pseudo
non hopping TRX. This is used in release B9 to manage GPRS
CS4. Such a TRX is considered by the MFS to be non hopping.

NH/RH
Only the BCCH TRX can be configured with an ARFCN. To introduce
other non hopping TRX, a mono frequency FHS must be introduced.
All the TS of this TRX are configured with the same mono-frequency
FHS. This TRX is referred to as a pseudo non hopping TRX. This is
used in release B9 to manage GPRS CS4. Such a TRX is considered
by the MFS to be non hopping.
The pseudo non hopping TRX are not taken into account in the check
of unique MA for GPRS.
On the OMC/BSC interface, mono frequency FHS are managed in
the same way as normal FHS.
The OMC-R must ensure that the entered radio configuration is in line with the
ARFCN requirements and the TRX channel configuration requirements. The
hopping type defined by the operator. The hopping type is not (yet) transferred
to the BSC or to the BTS. The OMC-R must check the consistency between the
hopping type and the hopping capability (as defined in the following table).
The following table summarizes the allowed hopping types per release B9 cell,
for each BTS hardware family, according to the hopping capability of the
BTS, to be checked by the OMC-R.

3BK 17422 5000 PGZZA Ed.06b

143 / 162

Appendix B : Cell Radio Channel Configuration

B.1.5.2 BSC
The BSC uses the hopping type.
The BSC uses the ARFCN/CU mapping in the recovery algorithms.

B.1.5.3 BTS
The BTS must check the consistency between the FU radio configuration
(received in CDM) and the actual hopping capability deduced from the
hardware during auto-identification (see the following table).
The ARFCN/CU mapping (conveyed within the CDM) is relevant for the BTS:
In the case of mono-frequency, to assign an ARFN to a CU, and
In the case of RH, to emulate the behavior of a G2 BTS towards the BSC.
RH with on-board BCCH filler (micro G2 BTS) is not more supported in
release B9 of the BSS.

B.2 Mapping Information

B.2.1 ARFN/CU Mapping
B.2.1.4 OMC-R
The OMC-R never produces and never sends an ARFCN/CU mapping,
either at the moment of cell creation (very first definition of cell radio
channel configuration), or during any later modification of the radio channel
configuration. The OMC-R sends either an ARFCN list (without CU mapping,
CU = FFh, but with RACH_CATCHER boolean), or an empty list.
The following table summarizes the information sent by the OMC-R for a release
B9 BSS, depending on BTS hopping capabilities and cell hopping types.
No ARFCN list means that no ARFCN list is created. An empty list is sent
by OMC-R.
ARFCN list means that the OMC-R creates and sends an ARFCN list where
all ARFCNs are mapped on CU Ffh, and the boolean RACH_CATCHER for
each ARFCN.

144 / 162

3BK 17422 5000 PGZZA Ed.06b

Appendix B : Cell Radio Channel Configuration

Note:

The previous table shows that, depending on the hardware TRE (i.e. mono
frequency or no), the OMC-R, in the case of the hopping type NH, does not
apply the same rule.
In the case of a BTS equipped with TRE mono-frequency (BTS G2), the list of
ARFCN used in the cell is sent to the BSC.
In the case of a BTS equipped with TRE multi-frequency capable, the list of
ARFCN used in the cell is not sent to the BSC.
In other cases, the OMC-R must send the ARFN list. The OMC-R must permit
#TRX > # TREs.

B.2.1.5 BSC
When the BSC receives a new cell radio channel configuration from the
OMC-R, it "forgets" the previous one (if one existed), including the ARFCN/CU
mapping; so at this moment the BSC stores either an ARFCN list (without CU
mapping, CU = FFh, but with RACH_CATCHER boolean), or an empty list.
Note that during the BSC-BTS audit, the BSC will send this list, the hopping
type and the RACH CATCHER boolean to the BTS. The BSC can receive from
the BTS (in State-Update-Report) an ARFCN/CU mapping and must store it. It
must consider that all frequencies are in the Available state.

B.2.1.6 BTS
The BTS is the entity in charge of the ARFN/CU mapping.
If the BTS has radio hopping capability (with or without on-board BCCH filler),
and if the hopping type is non hopping, the BTS performs no mapping and
returns no ARFCN-CU list, even if it has received one.
The BTS must map the BCCH frequency on a CU that is in IT state.
If there are more ARFCN in the list than CUs equipped in the sector, the BTS
must map the remaining ARFCNs on FFh.
When remapping ARFCNs to CU, the BTS must take care to provoke a
minimum of re-tuning; the BTS should compare previous and new mapping
and deduce the necessary deltas.
For extended cells, the Evolium BTS is in charge of specific configuration
actions related to the BCCH TREs.

3BK 17422 5000 PGZZA Ed.06b

145 / 162

Appendix B : Cell Radio Channel Configuration

B.2.2 TCU/RSL & TRX/RSL Mapping

For the new GSM850 frequency band, the RSL/TCU mapping (or remapping)
obeys the same rules as for PGSM/EGSM band.

B.3 Requirements
The Cell Radio Channel Configuration must be in line with the GSM rules and
the capacity/functional constraints of the equipment on which the radio channels
are implemented (frequency range, hopping capability etc.). The requirements
to take into account are listed here. They are valid on a per cell/sector basis
(except otherwise indicated). They are checked by the OMC before the
configuration is sent to the BSC; some of them are also verified by the BSC.
A split is made into "ARFCN requirements" and "TRX Channel Configuration
requirements".

B.3.1 ARFCN Requirements

ARFCN Requirements

NH Type

BBH Type

RH Type

NH/RH
Type

Note 1

Note 1

Note 1

Note 1

GSM rules
1. Frequency band definition
Checks related to the frequency range definition
GSM850 (128-251), P-GSM (1-124), E-GSM
(0,975-1023), DCS 1800 (512-885), DCS 1900
(512-810), PGSM-DCS (P-GSM+DCS 1800)
and EGSM-DCS (E-GSM+DCS 1800) have to
be performed as described in the note below
(Note 3).
2. If a Radio configuration is defined for a cell,
this defines a BCCH ARFCN and it must be
unique in the cell.
Engineering rules
3. ARFCN spacing in a BTS equipment
For a BTS with cavities, the ARFCNs of this
sector must be spaced out by three (i.e. 600
kHz) to avoid damages through inter-modulation.
Otherwise (no cavities in the BTS), only a
warning informs the operator when some
ARFCNs of this BTS are spaced out by less than
three (inter-modulation problems can happen)
4. ARFCN/CU mapping
The BTS is in charge of the ARFN/CU mapping.
When the mapping is produced, any frequency
used by a TRX must be associated to one single
CU. The CUs associated to the frequencies of
the cell must belong to the same sector.

146 / 162

3BK 17422 5000 PGZZA Ed.06b

Appendix B : Cell Radio Channel Configuration

ARFCN Requirements

NH Type

BBH Type

RH Type

NH/RH
Type

5. Concentric cells (also obviously fulfilled by

multiband cells)

6. Number of frequencies in the Cell Allocation

At most 64 frequencies can be allocated to a

given Cell Allocation.

Note 4

Note 4

Note 4

Note 4

For concentric cells, each TRX is associated

to one zone (inner or outer zone). A given
frequency can be used by TRXs belonging all to
the same zone. A frequency cannot be used by
TRXs belonging to different zones.
Alcatel system restrictions

Frequency encoding specificity, however, limit

the number of frequencies in the cell to less than
64 in certain cases.
in the case of multiband, it is the number of
frequencies in the Cell BCCH range (frequency
range in which the BCCH dwells), which is
limited due to this encoding specificity. For the
inner zone that is on the non-BCCH range the 64
ARFNs limit is applicable.
7. Scope of FHSs
All frequencies of an FHS must be located in the
same frequency band.
For E-GSM cells, an FHS cannot mix PGSM and
G1 frequencies.
For any TRX of an E-GSM cell, all frequencies
(ARFN or FHS frequencies) is either PGSM or
G1. This makes the TRX a PGSM or a G1 TRX.
8. Mandatory BCCH frequency in the MAFA list

A non empty list of ARFN values used for

extended measurement reporting in RMS
defined for a cell must contain the BCCH
frequency of this cell.

3BK 17422 5000 PGZZA Ed.06b

147 / 162

Appendix B : Cell Radio Channel Configuration

ARFCN Requirements

NH Type

BBH Type

RH Type

NH/RH
Type

9. Number of frequencies in the MAFA list

At most 21 frequencies can be defined in

the list of ARFN values used for extended
measurement reporting in RMS (including the
BCCH frequency).

Note 5

Note 5

Note 5

Note 5

Frequency encoding specificity, however, limit

the number of MAFA frequencies in the cell to
less than 21 in certain cases.
10. Check MAFA list ARFCN.
MAFA list ARFCNs does not contain "illegal
ARFCN", i.e. an ARFCN that does not belong to
P-GSM, G1, GSM850, DCS1800 or DCS1900
frequency bands. This check is performed at
PRC activation.

Note 1: Problem of ARFCN spacing of three

The rule of ARFCN spacing is applied for the following reasons:
A BTS with cavities (RTC) cannot transmit frequencies of which the
spacing is smaller than three (HW constraint). The cavities only exist for
G1/G2 BTSs.
Broadcasting of "consecutive" (this means with a spacing smaller than three)
frequencies in the Air can cause a bad quality of calls (inter-modulation).
In NH type or BBH type, the ARFCN spacing in a BTS is required for the BTS
hardware families with cavities. For the other BTS hardware families, the
spacing of three is recommended to avoid inter-modulation.
For B7 BSS, in RH type (no cavities), the ARFCNs of a given FHS can be
"consecutive" since there is only one TRX. On the other hand, the BCCH
ARFCN must preferably be spaced out by at least three from the other ARFCNs
used in the FHSs.
Example:
TRX1: RH with BCCH ARFCN = {2} and one FHS= {10,11,12,13}
In NH/RH type (no cavities), the rule of ARFCN spacing of three is too high
a limit since "consecutive" ARFCNs in the same FHS is conceivable without
risk of inter-modulation when the MAIOs are well chosen. Since the available
frequencies are rare, it is important to not limit the choice of frequencies for
the customer.
Example:
TRX1: NH at BCCH ARFCN = {2}; TRX2&TRX3 RH with one FHS= {10,
11, 20,21}.
Although consecutive ARFCNs are used in the FHS (10&11 and 20&21), the
following choice of MAIOs avoids any risk of inter-modulation: MAIO=0 for all
TSs of TRX2 and MAIO=2 for all TSs of TRX3.
The rule for ARFCN spacing to be checked by the OMC-R is as follows:

148 / 162

3BK 17422 5000 PGZZA Ed.06b

Appendix B : Cell Radio Channel Configuration

BTS with cavities

Spacing of three between the ARFCNs of the BTS is required. The OMC-R
does not accept "consecutive" ARFCNs in the same BTS (BTS with cavities
have only one sector).
BTS without cavities
The OMC-R checks the ARFCN spacing of three for the ARFCNs of the
BTS. However, in contrast to the previous case, this check does not forbid a
configuration with "consecutive" ARFCNs. Only a warning for the operator
that inter-modulation problems can appear. The radio configuration is the
operators responsibility.
Note 3 (checks related to the frequency range):
The OMC-R must ensure that:
The frequency range and the frequencies of the cell are compatible.
The frequency range and the cell type are compatible as defined in 2.2 Cell
Types (only 4 cell types are allowed for multiband cells). These compatibility
rules apply to OMC own cells and also to external cells.
If the frequency range HW capability is known by the OMC (BTS HW audit),
the OMC checks that the frequency range of the cell is compliant with the
frequency range HW capability of the respective sector (see compatibility
table). If the frequency range HW capability is unknown to the OMC-R
then no check is performed.
The OMC-R accepts the frequencies and forwards them to the BSC as a part of
the global configuration scenario.
In the case of a monoband cell, the BTS (OMU) will check the compliance of
the frequency range received in the Configuration Data Message (using the
same compatibility table, see below). In case of incompatibility, the BTS will
refuse to configure itself and answers with a Conf-Compl-Failure. The error
code will be forwarded in an alarm issued by the BSC.
The following table describes compatibility.
Cell Frequency Range

P-GSM

Actual Frequency Range

HW capability of a Sector

P-GSM

OK

E-GSM

GSM

DCS

DCS

PGSM

EGSM-

(A9100
BTS)

850

1800

1900

-DCS

DCS

***)

NOK

(A9100
BTS)
NOK

NOK

OK/NOK OK/NOK
(*)

E_GSM (A9100 BTS)

OK

OK

NOK

NOK

NOK

(*)

OK/NOK OK/NOK
(*)

(*)
NOK

GSM850

NOK

NOK

OK

NOK

NOK

NOK

DCS1800

NOK

NOK

NOK

OK

NOK

OK/NOK OK/NOK

DCS1900

3BK 17422 5000 PGZZA Ed.06b

NOK

NOK

NOK

NOK

OK

(*)

(*)

NOK

NOK

149 / 162

Appendix B : Cell Radio Channel Configuration

Cell Frequency Range

P-GSM

Actual Frequency Range

HW capability of a Sector

Multiband (PGSM-DCS)

(**)

E-GSM

GSM

DCS

DCS

PGSM

EGSM-

(A9100
BTS)

850

1800

1900

-DCS

DCS

(**)

NOK

(A9100
BTS)
(**)

NOK

OK

(***)
Multiband (EGSM-DCS) (A9100
BTS)

(**)

(**)

OK
(***)

NOK

(**)

NOK

OK

OK

oK

: Compatible

nok

: Not compatible; in particular a multiband cell can not use DCS 1900 band (cf rule 11)

: The check is OK if the BCCH frequency is in the band (PGSM or DCS 1800) of the sector (to support addition of
TRE of other band on the BTS).

**

: A BTS Evolium equipped for multiband can support a monoband cell with induced capacity loss. A BTS Evolium
equipped for monoband can also support a multiband cell, with obvious restrictions, even if the TREs of its inner
zone are not equipped. For G2 BTS, these special cases are not allowed in the cell and the HW capacity of
the sector must match.

***

: It is acceptable to define a cell as EGSM and map it on a PGSM sector provided no TRX is assigned a G1 frequency.

Note 4 (checks related to the number of frequencies in a range and per FHS):
Definition of the Cell Allocation:
The Cell Allocation defines a list of frequencies which is broadcast on the
following system information messages:
System Information Type 1 message on BCCH
Packet System Information Type 2 message (if a PBCCH is present in the
serving cell).
The Cell Allocation must not necessarily contain all the frequencies used
in the cell.
Therefore, the Cell Allocation must contain at least all the frequencies involved
in a frequency hopping law on the SDCCH (static and dynamic) and on the
potential hopping GPRS TS defined in the cell. Note that the CBCH is always a
sub-channel of SDCCH, so it always uses the same frequency of a SDCCH.
In order to simplify the implementation, in the Alcatel BSS, the Cell Allocation
regroups all the frequencies (hopping or non-hopping frequencies) involved in a
non-concentric cell or in a monoband concentric cell or in the outer zone of a
multiband concentric cell with the following exception on the BCCH frequency.
In cells defined at the OMC as "BCCH Non-Hopping / Radio Hopping (NH/RH)",
the BCCH frequency is never included in the Cell Allocation. In other cells, the
BCCH frequency is included in the Cell Allocation.
Indeed, as developed hereafter, only in the case of RH/NH, the BCCH
frequency is not included in a hopping sequence:
Case NH: As there is no frequency hopping, the BCCH frequency is
included in the Cell Allocation.
Case NH/RH: the BCCH frequency is never an hopping frequency, so the
BCCH frequency is excluded from the Cell Allocation and consequently from
the calculation of the frequency span.

150 / 162

3BK 17422 5000 PGZZA Ed.06b

Appendix B : Cell Radio Channel Configuration

Case BBH: the BCCH frequency is always a hopping frequency, so the

BCCH frequency is included in the Cell Allocation.
The number of frequencies usable in the Cell Allocation is limited by the
following factors:
CBCH hopping or non hopping. in the case CBCH Hopping, GPRS or
SOLSA configured or not in the cell.
The frequency band.
Maximum frequency span in the Cell Allocation.
If the CBCH is configured as hopping, then the maximum number of frequencies
in the Allocation and implicitly in any FHS in this frequency range is limited to:
16 frequencies if neither GPRS nor SOLSA is configured in the cell
8 frequencies if GPRS or SOLSA is configured (i.e. if maxPdch > 0 )

Figure 32: Maximum Number of Frequencies that can be Encoded in a CBCH Mobile Allocation and a
Cell Allocation (GPRS and of SoLSA)
If the CBCH is not configured or configured as non hopping, then the limitation
on the maximum number of frequencies is defined by the rules concerning
the frequency span which follows:

3BK 17422 5000 PGZZA Ed.06b

151 / 162

Appendix B : Cell Radio Channel Configuration

: Constraints are identical to P-GSM as BCCH must be in the P-GSM frequencies.

: This last line never happening: always less than 512 frequencies.

For PGSM-DCS and EGSM-DCS multiband cells, the frequencies defined in

the inner zone are used for TCHs only. For the inner zone, the total number of
frequencies is limited to 64.
Note 5: check related to the number of frequencies in the list of ARFN values
used for extended measurement reporting in RMS.
The number of extended measurement frequencies is limited by the encoding of
the Extended Measurement Order message and of the Extended Measurement
Report message.
Limitations on the encoding of the Extended Measurement Order message.
The number of extended measurement frequencies that can be encoded
in an Extended Measurement Order message is limited. This maximum
number depends on the frequency span, whether or not all the frequencies
belong to the P-GSM frequency band and whether or not the ARFCN 0
is included in the list of extended measurement frequencies. As there is
no restriction on the frequency band in which the extended measurement
frequencies must belong, the simplified method of calculating the frequency
span cannot be used here. Therefore, the OMC-R must use the complete
following method to determine the frequency span:
Calculation of the frequency span:
The frequencies in the list (including the BCCH frequency) is ordered
in the ascending order f0 to fn
Calculation of
d1=f1-f0-1
...
dn=fn-f(n-1)-1
d0=f0-fn + 1023

152 / 162

3BK 17422 5000 PGZZA Ed.06b

Appendix B : Cell Radio Channel Configuration

S=1024-max(dk)
Limitations on the encoding of the Extended Measurement Report message
The measurements on up to 21 frequencies can be encoded in an Extended
Measurement Report message.
Taking into account these two limitations, the maximum number of extended
measurement frequencies defined if the list is given in the following table:

Figure 33: Maximum number of extended measurement frequencies that can be included in the Extended
Measurement Frequency List according to the frequency span.

B.3.2 TRX Channel Configuration Requirements

TRX Channel Configuration Requirements

NH type

BBH type

RH type

NH/RH type

Allowed TRX configurations (entry point)

1. Only these TRX configurations are accepted
by the system:
1-The hopping type is NH.

All defined TRXs are non-hopping and fulfil the

GSM rules, the NH engineering rules, and the
NH Alcatel restrictions.
2- The hopping type is BBH (Base Band
Hopping).

One mandatory group of TRXs ensuring

the BCCH carrier plus possibly a group of
optional TRXs fulfilling the GSM rules, the
BBH engineering rules and the BBH Alcatel
restrictions. Juxtaposition of NH TRX (i.e. NH
TRX mixed with BBH TRX) is not permitted.
Juxtaposition of pseudo non hopping TRX are
permitted.
3- The hopping type is RH.

One TRX fulfilling the GSM rules, the RH

engineering rules, and the RH Alcatel
restrictions. No more supported.

3BK 17422 5000 PGZZA Ed.06b

153 / 162

Appendix B : Cell Radio Channel Configuration

TRX Channel Configuration Requirements

NH type

BBH type

RH type

NH/RH type
x

4- The hopping type is NH/RH.

One NH TRX at the BCCH ARFCN, and a set
of RH TRX fulfilling the GSM rules, the NH/RH
engineering rules, and the NH/RH Alcatel
restrictions.
GSM rules
2. BCCH channel / BCCH carrier

BCCH channel carrying the BCCH information

is always on TS0 without hopping. The BCCH
ARFCN has to be continuously transmitted (on
the eight TSs) on the air.
3. static SDCCH/CBCH localisation
If an static SDCCH/CBCH combination is used
on a given TS, that TS must be of rank 0 to 3.
Engineering rules
4. Prevention against the use of the same
frequency
All TRX-TSs (belonging to TRXs of the same
cell) of the same rank (0...7) must never use
the same frequency simultaneously.
When hopping, the TRX-TS must use for that
reason either the same FHS (with distinct
MAIOs), or distinct FHSs that do not share any
frequency
5. Channel usage
The channel usage of any TRX-TS can be
equal to :
- An ARFCN if the TRX-TS does not hop
- The couple (FHS identity, MAIO) otherwise
(hopping)
6. MAIO
TRX-TSs of the same rank and using the same
FHS must have each a different MAIO:
0 <= MAIO <= number of frequencies in the
FHS minus 1 <= 63
in the case of pseudo non hopping TRX, MAIO
=0
7 NH type

All TRX-TSs of a non-hopping TRX must use

the same frequency

154 / 162

3BK 17422 5000 PGZZA Ed.06b

Appendix B : Cell Radio Channel Configuration

TRX Channel Configuration Requirements

8. BBH type (Base Band hopping)

NH type

BBH type

RH type

NH/RH type

The number of frequencies of each FHS must

be equal to the number of TRXs, which use
this FHS.
The channel usage of the TRX-TSs from the
mandatory group of TRX ensuring the BCCH
carrier must be equal to one of the following
values:
- BCCH FHS + MAIO
- Reduced FHS + MAIO
- BCCH ARFCN
The BCCH FHS owns the BCCH ARFCN, and
removing the BCCH ARFCN from the BCCH
FHS produces the reduced FHS. They are both
mandatory.
The channel usage of the TRX-TSs of the
group of optional TRXs must be equal to one
optional FHS + MAIO. The optional FHSs must
not contain the BCCH ARFCN.
One must notice that additional Alcatel
restrictions are associated to the BBH type.
9. RH type

Only one single TRX in RH: the channel usage

of the TS0 is the BCCH ARFCN, whereas it is
equal to one RH FHS + MAIO for the TS of rank
1 to 7. There are up to seven RH FHSs (one
per TS of rank 1 to 7).
This configuration is not supported anymore.
The number of frequencies used in any RH
FHS is arbitrary. The RH FHSs can use the
BCCH ARFCN.
10. NH/RH type

One NH TRX, and a set of RH TRXs and

possibly pseudo NH TRX. The channel usage
of each TRX-TS of the NH TRX is the BCCH
ARFCN, whereas it is equal to one RH FHS +
MAIO for the RH TRXs.
The number of frequencies used in any RH
FHS is arbitrary. The RH FHSs must not
contain the BCCH ARFCN.

3BK 17422 5000 PGZZA Ed.06b

155 / 162

Appendix B : Cell Radio Channel Configuration

TRX Channel Configuration Requirements

NH type

BBH type

RH type

NH/RH type

11. Concentric cells and multiband cells

For concentric (monoband and multiband)

cells, the inner zone can only be allocated TCH
Channels.
As a consequence, these cell types are not
compatible with a sector of a BTS using 16k
statistical multiplexing: indeed, this multiplexing
rule requires that the TS0 of all non BCCH
TRXs be allocated SDCCH channels (static and
dynamic) (refer to rule 18), which is impossible
for the inner zone of concentric cells.
FHSs are not allowed to overlap between inner
and outer zones of concentric cells.
Each TRX must be assigned to a zone: inner
or outer.
In the case of a multiband cell, the TRXs within
a zone must either all use GSM frequencies
(P-GSM or E-GSM) or all use DCS 1800
frequencies.
12. Extended cells

For Evolium BTS, several TRXs are allowed

on extended cellsOnly non hopping radio
configuration is allowed for extended inner/outer
cells.
Due to uplink co-channel interference of outer
cell timeslot 7 and inner cell timeslot 0 (on outer
cell BCCH ARFCN), the OMC_R must force
IDLE the channel type of TRX-TS 7 of the outer
cell BCCH TRX and force its frequency usage
to the BCCH of the outer cell. If the operator
changes the channel type (or the Frequency
usage) of the TRX_TS 7 to another value, the
OMC_R has to reject the configuration.
The CCCH/SDCCH (static) configuration
(combined / non combined) must be identical
for the inner and outer extended cell (Evolium
BTS only); in other words, the channel
configuration must be the same for the TS 0 of
BCCH TRX for the inner and the outer cell.
On the other hand, the operator is strongly
recommended to bar the Inner Cell; note that
this is mandatory for BTS Evolium but cannot
be verified by the OMC.
Note: The extended cells (inner and outer)
do not support GPRS functionality (i.e.
maxPDCH=0
Alcatel system restrictions

156 / 162

3BK 17422 5000 PGZZA Ed.06b

Appendix B : Cell Radio Channel Configuration

TRX Channel Configuration Requirements

NH type

BBH type

RH type

NH/RH type

15. BBH type: localization of non-hopping

TRX-TS
Only the BCCH TRX can own non-hopping
TRX-TSs at the BCCH ARFCN.
As a consequence, if a TRX-TS of the BCCH
TRX is non-hopping, then all TRX-TSs of the
same rank belonging to the group of TRX
ensuring the BCCH carrier (except the BCCH
TRX) must use the reduced FHS.

16. BBH type: recovery algorithms

simplification
All TRX-TSs of a given TRX that use the same
FHS must have the same MAIO.
If the BCCH TRX hops, TRX-TSs of rank 1...7
must have the lowest MAIO (=0)
17. Recovery: gathering of the vital resources
on one TRX

The BCCH TRX must carry a set of static

SDCCH sub-channels.
The CBCH, if it exists, must be configured on
the TRX which carries the BCCH.
The CBCH can be configured on the BCCH TS
or on a static SDCCH TS (if any), but it must
be unique for the cell.
18. Dynamic and static SDCCH localization
The SDCCH, static or dynamic, can be
configured on any time slot of the TRX but
in the case of use of 16kbit/s statistical
multiplexing, TS0 of each TRX must be
configured with the BCCH or with static
SDCCH, but not with a TCH nor with a
dynamic SDCCH (the BSC will not accept this
configuration). Refer to rule 11.

3BK 17422 5000 PGZZA Ed.06b

157 / 162

Appendix B : Cell Radio Channel Configuration

TRX Channel Configuration Requirements

NH type

BBH type

RH type

NH/RH type

19 Checks related to GPRS

20. TRE/TRX limitations

21. G1 frequencies limitations

The mandatory rules to check are defined in

the "BSS Telecom Parameters" document for
EN-GPRS
TRX_Pref_Mark
MAX_PDCH
The check of limitation to 1 MA for PDCH
groups:
For the TRXs with TRX pref mark = 0, the Time
Slots selected (the BSC) to carry data must
have the same MA (1). The TSs must also be
TCH TSs.
Pseudo MA (FHS mono frequency) are not
taken into account in this check.
Check on inner zone:
GPRS is forbidden on the inner zone of a cell.
The check on GPRS MA in the case of BBH
cell:
If Nb_TS_MPDCH<>0 and if the BCCH TRX
does not support GPRS (TPM<>0)
ThenThe GPRS MA for the cell is the MA of the
BCCH TRX PDCH group.

Only TCH channels are acceptable on a G1

TRX.
GPRS is not supported by TRX carrying at
least one frequency of the G1 band.
22. Cell shared by 2 BTSs:
The BCCH TRX must be a main TRX
If the hopping type is BBH, the FHS cannot be
across the two sectors.
23. Check the maximum number of SDCCH
per cell.
The number of configured static and dynamic
SDCCH for a cell must not exceed the
maximum of 88. If the limit is exceeded, an
error is sent to the operator who has to change
the static or dynamic SDCCH configuration for
the cell.
The OMC ensures the check at activation.

158 / 162

3BK 17422 5000 PGZZA Ed.06b

Appendix B : Cell Radio Channel Configuration

TRX Channel Configuration Requirements

NH type

BBH type

RH type

NH/RH type

24. Check the maximum number of SDCCH

per TRX

The number of configured SDCCH (static

and dynamic) for a TRX must not exceed the
maximum of 24 SDCCHs (static and dynamic).
If the limit is exceeded, an error is sent to
the operator who has to change the SDCCH
configuration (static and dynamic) for the TRX.
The OMC ensures the check at PRC activation.
25. Check BTS HW
Dynamic SDCCH TS is configured only on a
cell mapped on an Evolium BTS.
26. Check HSDS activation
CS3/CS4 coding schemes must not be
configured on a G2 BTS.
EN_Egprs must not be enabled on a G2 BTS.

Customer Recommendations

NH Type

BBH Type

RH Type

NH/RH
Type

1. Recovery: preservation of SDCCH (static and

dynamic) sub-channels
Hopping SDCCH (static or dynamic) is preferably
configured on the TRX with the lowest MAIO.
2. Check compatibility of signaling load and 16 k mux
rule on A-bis

(The rules 2 to 5 are to be verified by activation of

the Check load impacts)
A warning "Risk of RSL congestion with Abis
16k statistical or static multiplexing" is sent to the
operator, on a per cell basis, if the Multiplexing rule
for the sector is 16k static or 16k statistical while any
of the following checks is true:
The number of SDCCH (static and dynamic) on
at least one TRX (of a cell with more than one
TRX) is larger than 8.
For a 1 TRX cell, the number of SDCCHs (static
and dynamic) is larger than 12.
The total number of SDCCHs (static and dynamic)
for the cell is larger than 24.

3BK 17422 5000 PGZZA Ed.06b

159 / 162

Appendix B : Cell Radio Channel Configuration

Customer Recommendations

NH Type

BBH Type

RH Type

NH/RH
Type

3. Check the number of SDCCHs per cell

A warning "Too many SDCCHs, risk of RSL

congestion" is sent to the operator if the Multiplexing
rule for the sector is 64k while the following checks
is true:
the number of SDCCHs (static and dynamic) in the
cell is larger than 8*Nb_TRX + 8*Nb_DR_TRE (*)

160 / 162

3BK 17422 5000 PGZZA Ed.06b

Appendix B : Cell Radio Channel Configuration

Customer Recommendations

NH Type

BBH Type

RH Type

NH/RH
Type

4. Check the number of SDCCH per cell for risk of

CCCH congestion

A warning "Too many SDCCHs (static and dynamic),

risk of CCCH congestion" is sent to the operator if
any of the following checks is true:
For a cell in Main combined the number of SDCCHs
(static and dynamic) is larger than 20.
For a cell not in Main combined the number of
SDCCHs (static and dynamic) is larger than 64.
5. Check to avoid configurations for which RSL
reshuffling will fail
A warning "Risk of processor overload (MCBs
possibly already overloaded)" is sent to the operator
if any of the following checks are true:
The multiplexing mode of a multisector BTS is
"per BTS" (can end up with a MCB with several
BCCH TRXs). (**)
The Signaling load of a sector is "Normal" while
the BCCH TRX of the cell supports more than
12 SDCCH (static and dynamic) (resulting in
saturated MCB if the BCCH TRX is combined
with TRXs also supporting SDCCH (static and
dynamic)).
The Signaling load of a sector is "Normal" while
the mean number of SDCCH (static and dynamic)
on the authorised TRXs is greater than 8 (can
end up with MCBs with more than 32 SDCCH
when authorised TRXs are grouped together).
At least one TRX supports more than 16 SDCCHs
(static and dynamic) (more than 16 SDCCHs on
a TRX is never justified and is likely to create an
overloaded MCB).
It is always recommended to use a High signaling
load whenever there are enough TS on the Abis
to support it; smaller MCBs will facilitate the RSL
reshuffling at no extra cost.
*

: The OMC is not able to check the number of SDCCHs per Multiplexed Channel Block (MCB); this rule only verifies that
the overall number of SDCCHs (static and dynamic) is limited to 8 per TRX (declared in the cell) plus 8 additional per
Dual Rate TRE (declared in the BTS). This restriction helps in preventing TCU overload situations even if the effective
number of SDCCHs (static and dynamic) on the TCUs depends on BSC mapping algorithms.

**

: It is preferable to avoid the grouping of TRXs from different sectors in the same MCB, in particular for cells with more
than 4 TRXs, as this prevents the case of MCBs with more than one BCCH. Of course, this solution is acceptable
only if it is affordable in terms of Abis Time Slots. This rule could be by passed for small cells (in order to avoid

3BK 17422 5000 PGZZA Ed.06b

161 / 162

Appendix B : Cell Radio Channel Configuration

incomplete MCBs) but, in this case, it is highly recommended to set the Signaling load (at BTS level) to High to avoid
MCBs with 3 or even 4 BCCHs.

In case of violation of these rules, when the operator attempts to apply the
configuration, there are three possible behaviors:
The violation is detected by the OMC-R
In this case, the OMC-R behaves as follows:
If the detected violation only gives rise to a warning, the OMC must
inform the operator. The configuration is sent to the BSC.
Otherwise, the OMC-R rejects the corresponding configuration, in all
other cases, when the OMC-R operator attempts to apply it. The rejected
configuration is NOT SENT to the BSS.
The violation is detected by the BSC (see rules 13 and 14)
The BSC rejects the configuration.
The violation is detected by the BTS (which will never normally occur)
The BTS rejects it. This causes an alarm to begin for the corresponding
BTS-O&M.

162 / 162

3BK 17422 5000 PGZZA Ed.06b