B9 BSS Configuration Rules ed30.pdf

Alcatel BSS

B9 BSS Configuration Rules

BSS Document

Reference Guide

Release B9

3BK 17422 5000 PGZZA Ed.30P02

Status IN PREPARATION

Short title Configuration Rules

All rights reserved. Passing on and copying of this document, useand communication of its contents not permitted without writtenauthorization from Alcatel/Evolium.

BLANK PAGE BREAK

2 / 167 IN PREPARATION 3BK 17422 5000 PGZZA Ed.30P02

Contents

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.1 BSS Equipment Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2 Supported Hardware Platforms, Restrictions and Retrofits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.3 Platform Terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.4 Release Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.5 BSS Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.6 New B9 Features and Impacted Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 BSS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1 Transmission Architecture with CS Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2 Transmission Architecture with CS and PS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3 GPRS in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3.1 GPRS Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.2 GPRS General Dimensioning and Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.4 LCS in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.4.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.4.2 Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.4.3 Physical Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.4.4 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.4.5 GPS LCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.4.6 BSS and Cell Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.4.7 Traffic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.4.8 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.5 HSDS in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.5.1 Definitions and Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.5.2 Transmission Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.5.3 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.6 PLMN Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3 BTS Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.1 BTS Generation Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.2 Evolium BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.2.1 Evolium BTS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.2.2 Evolium BTS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.3 G2 BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.4 G1 BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.5 BTS Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.6 Physical Channel Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.6.1 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.6.2 GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.7 Frequency Band Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.7.2 Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.7.3 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.8 Speech Call Traffic Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.9 Adaptive Multi-rate Speech Codec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.9.2 Rules and Dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.10 Data Call Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.11 OML and RSL Submultiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.12 Cell Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.12.1 Cell Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.12.2 Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.12.3 Shared Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3BK 17422 5000 PGZZA Ed.30P02 IN PREPARATION 3 / 167

Contents

3.13 SDCCH Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.13.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.13.2 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4 BSC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.1 A9120 BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.1.1 A9120 BSC Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.1.2 ABIS TSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.1.3 ATER TSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.1.4 TSC Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.2 A9130 BSC Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.2.1 A9130 BSC Evolution Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.2.2 Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.2.3 A9130 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.3 Delta A9130 BSC Evolution versus A9120 BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5 TC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5.1 G2 TC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.1.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.1.2 Rules and Dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.2 A9125 Compact TC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.2.2 Rules and Dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6 MFS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.1 A9135 MFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.1.1 MFS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.1.2 MFS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.1.3 MFS Clock Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.2 A9130 MFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.2.1 MFS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.2.2 MFS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996.2.3 MFS Clock Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.3 Delta A9135MFS versus A9130MFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

7 ABIS Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037.1 Abis Network Topology and Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047.2 Impedance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057.3 Abis Channel Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

7.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057.3.2 TS0 Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

7.4 Signaling Link on Abis Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067.4.1 RSL and OML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067.4.2 Qmux Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067.4.3 OML Autodetection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

7.5 Signaling Link Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077.5.1 Signaling Link Multiplexing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077.5.2 Signaling Link Multiplexing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077.5.3 Multiplexed Channel Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

7.6 Mapping Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087.6.1 Free Mapping Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087.6.2 Abis-TS Defragmentation Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097.6.3 RSL Reshuffling Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097.6.4 Cross-Connect Use on Abis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107.6.5 SBL Numbering Scheme in A9120 BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117.6.6 SBLs Mapping on HW Modules in A9130 BSC Evolution versus A9120 BSC 1137.6.7 TCU Allocation Evolution in A9130 BSC Evolution . . . . . . . . . . . . . . . . . . . . . . . . 113

7.7 Abis Link Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147.8 Abis Satellite Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116


Contents

7.9 Two Abis Links per BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

8 Ater Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1218.1 Ater Network Topology and Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228.2 Impedance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228.3 Numbering Scheme on A9120 BSC-Ater/Atermux/TC Ater/A Interface . . . . . . . . . . . . . . . . . 122

8.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228.3.2 Numbering Scheme on the A9120 BSC Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1238.3.3 Numbering Scheme at G2 TC Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

8.4 Numbering Scheme on A9130 BSC Evolution-Ater/Atermux/TC Ater/A Interface . . . . . . . . 1248.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248.4.2 SBLs Mapping on HW Modules in A9130 BSC Evolution versus A9120 BSC 124

8.5 Signaling on Ater/Atermux Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258.5.2 Signaling Link Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1268.5.3 SS7 Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

8.6 GPRS and GSM Traffic on Atermux versus A9120 BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278.6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278.6.2 Hole Management in a G2 TC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288.6.3 Sharing Atermux PCM Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288.6.4 Ratio of Mixing CS and PS Traffic in Atermux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

8.7 Ater Satellite Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

9 GB Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1339.1 Gb Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1349.2 Gb Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

10 CBC Connection, SMSCB Phase 2+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13710.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13810.2 GSM Cell Broadcast Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13810.3 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

10.3.1 Solutions in A9120 BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13810.3.2 Solutions in A9130 BSC Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Appendix A : BSS Hardware Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Appendix B : Cell Radio Channel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143B.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

B.1.1 Cell Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143B.1.2 TRX Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143B.1.3 Hopping Types in a Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145B.1.4 Radio Carrier Hopping Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146B.1.5 Use of the Hopping Types per Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

B.2 Mapping Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148B.2.1 ARFN/CU Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148B.2.2 TCU/RSL & TRX/RSL Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

B.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150B.3.1 ARFCN requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150B.3.2 TRX Channel Configuration Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157


Figures

FiguresFigure 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 . . . . . . . . . . . . . . 27

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

Figure 9: Generic LCS Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Figure 10: SAGI Physical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Figure 11: Impact on Hub Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Figure 12: Choice of Modulation Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Figure 13: BTS in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Figure 14: BSC in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Figure 15: A9120 BSC Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Figure 16: Ater TSU Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Figure 17: A9130 BSC Evolution HW Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Figure 18: 600 TRX LIU Shelf connections assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Figure 19: TC in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Figure 20: MFS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Figure 21: BSC Connection for Multi-GPU per BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Figure 22: A9130 MFS Hardware Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Figure 23: Chain Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Figure 24: Ring or Loop Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Figure 25: Example of Cross-Connect Use on Abis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Figure 26: Gb Link Directly to SGSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Figure 27: Gb Link through the TC and MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Figure 28: Gb Link through the MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Figure 29: Gb Logical Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Figure 30: CBC-BSC Interconnection via PSDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Figure 31: CBC-BSCs Interconnection via the MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Figure 32: Maximum Number of Frequencies that can be Encoded in a CBCH Mobile Allocation and a CellAllocation (GPRS and of SoLSA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

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


Tables

TablesTable 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Table 9: Evolium BTS Minimum and Maximum Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

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

Table 11: Typical Multiband Configuration G3 BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Table 12: G2 BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Table 13: BTS Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Table 14: Frequency band configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Table 15: Hardware Transmission Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Table 16: Speech Call Traffic Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Table 17: AMR Codec List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Table 18: Data Call Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Table 19: OML and RSL Submultiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Table 20: Cell Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Table 21: Maximum Supported Capacities and Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Table 22: A9120 BSC Globally Applicable Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Table 23: BSS Evolution Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Table 24: B9 A9120 BSC Capacity per Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Table 25: TSL / TCU Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Table 26: Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Table 27: DTC Configuration and SBL Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Table 28: G2 TC/A9125 Compact TC capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Table 29: G2 TC configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Table 30: G2 TC Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Table 31: MFS Capacity for DS10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Table 32: Maximum MFS Configurations on MX Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Table 33: Multiplexed Channel Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Table 34: TS Mapping Table for Corresponding Abis Chain or Ring Configurations . . . . . . . . . . . . . . . . . . . . 111

Table 35: SBL Numbering at A9120 BSC Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Table 36: Abis Port - BIUA - TCU SBL Numbering in A9120 BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Table 37: Number of TS available in one Abis Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Table 38: Number of Required TS versus TRX Number and Sub-Multiplexing Type . . . . . . . . . . . . . . . . . . . 115

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


Tables

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

Table 41: Numbering Scheme on A9120 BSC Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Table 42: Numbering Scheme on G2 TC Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Table 43: SS7, Atermux, DTC and Ater Numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Table 44: GPU Atermux Connections Example Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

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


Preface

Preface

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

What’s New In Edition 30Increasing of A9130 MFS cells capacity in: GPRS General Dimensioningand Rules (Section 2.3.2) .

Introduction of GERAN TRA in:8-PSK Output Power (Section 2.5.2.2 ), BTSGeneration Summary (Section 3.1), Evolium BTS Configuration (Section 3.2.2),Evolium BTS Rules and Dimensioning (Section 3.2.2.2 ), Mixed configurationG3/G4/TWIN (Section 3.2.2.6 ), Two Abis Links per BTS (Section 7.9)

In Edition 05Creation from doc version to .xml.

Introduction of A9130 MFS in GPRS General Dimensioning and Rules (Section2.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 (Section7.6.4), Numbering Scheme on A9130 BSC Evolution-Ater/Atermux/TC Ater/AInterface (Section 8.4), SBLs Mapping on HW Modules in A9130 BSC Evolutionversus A9120 BSC (Section 7.6.6), TCU Allocation Evolution in A9130 BSCEvolution (Section 7.6.7), Rules (Section 3.13.2), Solutions (Section 10.3).

PS is supported in extended cell. Plus other additional rules regarding theextended cells in Cell Types (Section 3.12.1)

Editorial updates in chapters :New B9 Features and Impacted Sections (Section1.6), GPRS Configurations (Section 2.3.1), GPRS General Dimensioning andRules (Section 2.3.2), Rules (Section 2.5.3), A9130 BSC Evolution BoardConfigurations (Section 4.2.2.1 ), Centralized Mode (Section 6.1.3.2 ), MFSArchitecture (Section 6.2.1), MFS Clock Synchronization (Section 6.2.3)


Preface

In Edition 04A new feature allows the usage of TREs at their real power. More details inCell 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 03Editorial review

In Edition 02Creation from doc version to .xml

Audience This manual is for people requiring an in-depth understanding of theconfiguration rules of the Alcatel BSS:

Network decision makers who require an understanding of the underlyingfunctions and rules of the system

Iincluding:

Network planners

Technical design staff

Trainers.

Operations and support staff who need to know how the system operates innormal 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.


Preface

Assumed Knowledge The document assumes that the reader has an understanding of:

GSM

GPRS

Mobile telecommunications.


Preface


1 Introduction

1 Introduction

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


1 Introduction

1.1 BSS Equipment NamesThe following table lists the Alcatel commercial product names and thecorresponding 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 RetrofitsThe following table lists the Alcatel hardware platforms supported in by theBSS, 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


1 Introduction

Equipment B9 Support Retrofit Required

G4 (G3.8, G4.2) Yes

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 TerminalsThe Alcatel BSS supports the Windows XP and Windows 2000 OperatingSystems (OS).

1.4 Release MigrationMigration from release B8 to release B9 infers the succession of the OMC,MFS and BSC.

1.5 BSS UpdatesNo hardware upgrades are required.

1.6 New B9 Features and Impacted SectionsThe following table lists the new B9 features, and provides links to impactedsections of this document.

New B9 Features Impacted Sections

GCH Statistical Multiplexing Rules (Section 2.5.3)

Autonomous Packet ResourceAllocation

GPRS (Section 3.6.2)


1 Introduction

New B9 Features Impacted Sections

HCM Improvements (TRX/RSL andTRE/TCU)

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

Preparation for Complete CellIdentification

PLMN Interworking (Section 2.6)

Up to 64 cell reselection adjacenciesper cell

PLMN Interworking (Section 2.6)

Enhanced Transmission ResourceManagement

Definitions and Prerequisites (Section 2.5.1)

Enhanced support of EGPRS in uplink Definitions and Prerequisites (Section 2.5.1), Rules (Section2.5.3)

Enhanced E-GSM band handling GPRS General Dimensioning and Rules (Section 2.3.2), EvoliumBTS 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 perBTS sector

GMSK Output Power (Section 2.5.2.1 ), Cell Types (Section3.12.1), Rules (Section 2.5.3)

New platform introduction A9130 MFSEvolution

GPRS General Dimensioning and Rules (Section 2.3.2), MFSConfiguration (Section 6)

New platform introduction A9130 BSCEvolution and rack sharing

BSC Configuration (Section 4), Impedance (Section 7.2),Overview (Section 7.3.1), Qmux Bus (Section 7.4.2), RSLReshuffling Algorithm (Section 7.6.3), Cross-Connect Useon Abis (Section 7.6.4), Numbering Scheme on A9130 BSCEvolution-Ater/Atermux/TC Ater/A Interface (Section 8.4), SBLsMapping on HW Modules in A9130 BSC Evolution versus A9120BSC (Section 7.6.6), TCU Allocation Evolution in A9130 BSCEvolution (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


2 BSS Overview

2 BSS Overview

BSS Overview describes the Alcatel BSS, and corresponding features andfunctions.

The GSM Radio System (GRS) is a set of hardware and software equipmentprovided by Alcatel to support the radio part of the GSM network. The GRScomprises one OMC-R and one or more BSS. The OMC-R supervises oneor more BSS.

The BSS provides radio access for Mobile Stations (MS) to the PLMN. Thereare one or more GRS per PLMN.

The following figure shows a BSS with GPRS. All BSS operating over thefield are with/without data service.


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


2 BSS Overview

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

Note: The Gs interface, between the MSC and the SGSN, is not described in thisdocument, as it is not considered to be part of the BSS. For more informationabout this interface, refer to the BSS System Description.

For specific information about the LCS dedicated interfaces, refer to LCSin the BSS (Section 2.4).

Given that the transmission architecture depends on GPRS, there are twopossible transmission architectures:

Transmission architecture with Circuit Switched (CS) only

Transmission architecture with CS and Packet Switched (PS).


2 BSS Overview

2.1 Transmission Architecture with CS OnlyThis 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/sE1 digital hierarchy.


2 BSS Overview

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

Note: Microwave equipment is external to and independent of Alcatel transmissionequipment, however, in some cases, the microwave can be housed in thetransmission equipment rack and in the BTS.

2.2 Transmission Architecture with CS and PSPS is directly linked to GPRS and related MFS platforms.

The following figures represent the MFS with its physical interfaces, whenconnected 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 dedicatedto GPRS (only PS conveyed), or mixed CS/GPRS. In this case, the CS


2 BSS Overview

channels (called CICs) coexist with GPRS channels (called GICs) onthe same link.

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 andMFS. There are up to 4 tributaries multiplexed in one Atermux.

The MFS-SGSN interface, which carries the Gb interface when there is adedicated 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 MFSwhen 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 theTC) 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 BSSThe MFS enables GPRS in the network. The following figure shows the locationof 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 followingmodifications:

The introduction of the Packet Control Unit (PCU). The PCU controls the

GPRS activities for one Alcatel BSS.


2 BSS Overview

The introduction of the Gb interface termination function.

The Alcatel approach for the implementation of GPRS is to group the PCUand Gb termination functions of several BSS into one new NE called theMFS (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 planeThe 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 accessgrant 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 tothe 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. TheBSS connected to the same MFS can be linked to different MSC.


2 BSS Overview

2.3.2 GPRS General Dimensioning and Rules

O:OperatorChoice

S:SystemCheck

Maximum Quantity (No MultipleGPU)

Maximum Quantity (MultipleGPU*)

BSS per A9135MFS

O, S 22 22

BSS per A9130MFS

O, S 21 21

BSS per GPU S 1 1

GPU per BSS O, S (onmaximumvalue)

1 6 GPU per BSS (committed value)

GPU per A9135MFS

O, S 24=2(11+1) 32=2*(15+1) (DS10)

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

GPU perA9130MFS 1 shelf

O, S 9+1/8+1 9+1/8+1

GPU perA9130MFS 2shelfs

O, S 21+1 21+1

Number of GCHsimultaneouslyallocated per GPU

S 240 240

Number of GCHsimultaneouslyallocated per GP

S 1560 1560

Number of PDCHreached on GP

S 960 PDCH CS-2

912 PDCH MCS-1

784 PDCH CS-4/MCS-5

520 PDCH MCS-6

390 PDCH MCS-7

312 PDCH MCS-9

960 PDCH CS-2

912 PDCH MCS-1

784 PDCH CS-4/MCS-5

520 PDCH MCS-6

390 PDCH MCS-7

312 PDCH MCS-9

Atermux A9120BSS-A9135MFS

O 8 17 (minimum (ater Mux-1,nb.GPU*8))

Atermux A9120BSS-A9130MFS

O 6 17 (minimum (ater Mux-1,nb.GPU*6))

Cells / GPU S 264 264


2 BSS Overview

O:OperatorChoice

S:SystemCheck

Maximum Quantity (No MultipleGPU)

Maximum Quantity (MultipleGPU*)

Cells / A9135 MFS S 2000 2000

Cells / A9130 MFS S 3000 3000

Frame Relay BC /GPU

O, S 120 120

BVC per GPU S 264 264

TRX with PDCHper Cell

O,S 16 16

Allocated PDCHper TRX

S 8 8

NSE per A9135MFS

O, S 22=2*(11) 30=2*(15)(DS10)

22=2*(11)(AS800)

NSE perA9130MFS

O, S 21 21

GSL per BSC O 4GSL/GPU 4 GSL/GPU: up to 12 GSL/BSCminimum (12, 4*nb.GPU)

Allocated GICs perBSC

480=4*120 2000

BVC-PTP 240 240

NS-VC per NSE O, S 120 120

Bearer Channelper MFS

O, S 300 300

Bearer ChannelPer PCM

O, S 31 31

PVC per BC S 1 1

* : 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. Thecross-connection capacity in the MFS is at the 64k TS level.

Gb traffic going to the TC is routed transparently at the TC site


2 BSS Overview

There is no GPRS traffic directly on the BSC-TC Atermux, as there is noway 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 2ndtributary

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 thisPCM 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 atTC 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

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

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 MFSlinks (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/4GPRS Atermux 4:1 mapping).

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


2 BSS Overview

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


2 BSS Overview


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 thegeographical 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, butwith restrictions concerning the choice of positioning method when LCS orindividual positioning methods are not supported by the MS.

The LCS client resides in an entity (including the MS) within the PLMN, orin an entity external to the PLMN.

LCS provides the position of the target MS. Depending on the positioningtechniques, 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 networksynchronization.

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.


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 registrationauthorization, 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 andaccuracy, and controls a number of LMUs to obtain the radio interface

measurements required to locate the MS in the area it serves. The SMLCis 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. AnA-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 eachfunction), in that the LCS software is a module on top of the GPRS software.


2 BSS Overview

For a BSC connected to several GPUs, the SMLC function for the whole BSSis supported by the current pilot GPU and only by this GPU (the pilot GPUbeing the GPU handling procedures at the BSS level). When the pilot GPU isre-elected (e.g. following the loss of all GSLs on the current pilot GPU), theSMLC 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 deliveryof Cell Id and TA. The TA positioning method regroups several distinct

methods (Cell Id only (CI), Cell Id + TA (CI+TA)). The TA positioningmethod 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 MSAssisted 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-GPSThe MS receives GPS Assistance Data from the SMLC (which hasreceived the data previously from the external GPS server), performsGPS measurements, and returns the resulting GPS measurements tothe SMLC. The SMLC provides these GPS measurements to theexternal GPS server, which computes the MS location estimate.

MS Based A-GPSThe MS receives GPS Assistance Data from the SMLC (which hasreceived the data previously from the external GPS server), performsGPS measurements and location calculation, and returns its locationestimation 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.


2 BSS Overview

2.4.5 GPS LCS

If a high accuracy is required, GPS positioning method(s) are preferred, whenpossible.

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 agiven 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 anexternal 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 collocatedor not collocated.

The following figure shows the impact on hub connectivity.


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 22slots (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 + 1router) 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 bythe manufacturer. When provided to the customer, LCS can be enabled ordisabled 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-relatedattributes 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 onthis 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


2 BSS Overview

Enable the EN_SAGI flag, to indicate whether the SAGI interface isconfigured for the BSS (physical and transport level configuration) for

GPS LCS only.

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 bemet in release B8, and as a long-term objective that the initial B8 systemarchitecture support, as follows:

Long-term objective:38 location requests/s per 6 BSC configuration (the BSC can handle up to1900 Erlang) and 680 location requests/s per MFS. This traffic is basedon the assumption of one location request per call (mean call duration =80 s). This traffic requirement will remain unchanged when replacing CStraffic by PS traffic.

Note: With regard to the long-term objective:

The consensus is to accept one location request per CS call, whichleads 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 oflocation 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/sper 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 interfacehas 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 arouter 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_SAGIflag defined on a per BSS basis.


2 BSS Overview

2.5 HSDS in the BSS

2.5.1 Definitions and Prerequisites

The High Speed Data Service (HSDS) consists of:

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 frequencyband, 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 BTSis EDGE- ready simply by plugging in the EDGE-capable TRX where andwhen it is needed.

2.5.1.1 GPRS Coding SchemesTwo new coding schemes are proposed for GPRS in release B9:

CS-3

CS-4.

The following table lists the coding schemes and the corresponding modulationtypes and maximum transmission rates.

Scheme Modulation Maximum Rate [Kbps] perRadio TS

CS-4 GMSK 20

CS-3 GMSK 14.4


2 BSS Overview


CS-2 GMSK 12

CS-1 GMSK 8

Table 5: GPRS Coding Schemes

2.5.1.2 E-GPRS Modulation and Coding SchemesE-GPRS enables the support of data transmission at a bit rate which exceedsthe 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 propagationconditions (referred to as link adaptation).

The basic principle of link adaptation is to change the Modulation and CodingSchemes (MCS) according to the radio conditions. When the radio conditionsworsen, a more protected MCS (more redundancy) is chosen for a lowerthroughput. 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 datacommunications (E-GPRS), providing raw RLC data rates ranging from 8.8kbit/s (the minimum value under the worst radio propagation conditions perTS) up to 59.2 kbit/s (the maximum value achievable per TS under the bestradio propagation conditions). Data rates above 17.6 kbit/s require that 8-PSKmodulation is used on the air interface, instead of the regular GMSK.

The following table lists the coding schemes and the corresponding modulationtypes and maximum transmission rates.


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


2 BSS Overview


MCS-2 GMSK 11.2

MCS-1 GMSK 8.8

Table 6: EGPRS Modulation and Coding Schemes

2.5.1.3 HSDSHSDS provides support for GPRS with CS1 to CS4, and for E-GPRS withMCS1 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.

The different code rates within a family are achieved by transmitting a differentnumber of payload units within one radio block.

When 4 payload units are transmitted, these are split into 2 separate RLCblocks (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.


2 BSS Overview

Figure 12: Choice of Modulation Scheme

The choice of modulation schemes is based on the measurement of thebit error probability (BEP).

The coding scheme and the radio modulation rates are modified to increase thedata traffic throughput of a given radio TS. This implies that the increase ofthroughput is handled on the Abis and Ater interfaces (previously, for each radioTS in use, only a 16kb/s nibble was allocated on both interfaces).

2.5.1.4 Ater interfaceIn 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 InterfaceOn the Abis interface, to handle a throughput higher than 16Kb/s, severalAbis nibbles are also used. The configuration is dynamic for TRX insidethe same BTS.

A number of 64k EXTS (Extra TS) are defined for each BTS by O&M. Thisgroup of TS replaces the number of transmission pool types used previously.

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

2.5.1.6 M-EGCHThis term is used to refer to a link established between the MFS and the BTS.

One M-EGCH is defined per TRX.


2 BSS Overview

2.5.1.7 Enhanced Transmission Resource ManagementA dedicated manager sequences the GCH establishment, release, redistributionor pre-emption procedures.

The transmission resource manager is on the MFS/GPU level. It handles bothAbis 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 oftheir supported TBFs (UL and DL).

2.5.1.8 Abis Nibble Sharing RulesTo 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 RulesA 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 itsfour 16K Ater nibbles are free. This is the unique restriction concerning Aternibble sharing at GPU level.

2.5.2 Transmission Power

2.5.2.1 GMSK Output PowerGMSK is a constant amplitude modulation.

2.5.2.2 8-PSK Output PowerFor one given TRE, the maximum output power is lower in 8-PSK than in GMSKbecause of the 8-PSK modulation envelope which requires a quasi-linearamplification.

The TRE transmit power in 8-PSK does not exceed the GMSK transmit powerin 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.

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


2 BSS Overview

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

The output power values for GERAN TRA are available in the following table:

GERAN TRA / EDGE+ TRA

RIT name GMSK power 8-PSK power Ref Sensitivity

GSM900 GTT09 2*45 W / 46,5dBm

2*30 W / 44,8dBm

- 116 dBm Twin TRA

GTH09 90W / 49,5 dBm 40W / 46,0 dBm - 119 dBm HP / 4 RX TRA

GTS09 45 W / 46,5dBm

20 W / 43,0dBm

- 116 dBm SLIM / 2 RXTRA

DCS1800 GTT18 2*35 W / 45,4dBm

2*30 W / 44,8dBm

- 116 dBm Twin TRA

GTH18 70W / 48,5 dBm 30W / 44,8 dBm - 119 dBm HP / 4 RX TRA

GTM18 35 W / 45,4dBm

20 W / 43,0dBm

- 116 dBm SLIM / 2 RXTRA

GSM850 GTM08 45 W 30W

60W 40W

PCS1900 GTM19 35 W 30W

60W 30W

Note that the operator is allowed to allocate the E-GPRS TBF on the BCCHTRX, and the BCCH frequency must have a quite stable radio transmissionpower.

Due to this constraint, the 8-PSK output transmission power is not leveled persector, in order to effectively exploit the TRE capability, and the E-GPRS TRXsare preferably mapped to a TRE with the best 8-PSK capability.

The Modulation Delta Power is the difference between the GMSK output powerof 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 DeltaPower is less than 3 dB.


2 BSS Overview

2.5.3 Rules


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

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


2 BSS Overview

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

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

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


2 BSS Overview

TRX ranking:

PS capable TRXs are ranked according to the following criteria, forPS 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

BTSA mix of the G4 TRE medium power and G4 TRE high power (that offersa higher output power useful for 8-PSK modulation) in the same EvoliumBTS 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 inthe 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

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


2 BSS Overview

The support of 8PSK in UL is optional for the MS.

2.6 PLMN InterworkingA foreign PLMN is a PLMN other than the PLMN to which OMC-R internal cellsbelong. Only cells external to the OMC-R can belong to a foreign PLMN. Allinternal cells must belong to their own PLMN. Both OMC-R owned cells andcells 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 featureThe operator can define handover adjacency links towards external cellsbelonging to a foreign PLMN, (i.e. handovers from a serving cell belongingto the primary PLMN towards a target cell belonging to a foreign PLMN).

Inter-PLMN 2G to 2G cell reselectionsThe Alcatel BSS allows the operator to define cell reselection adjacencybetween two cells belonging to different primary PLMN (which musttherefore be owned by two different BSC).

Multi-PLMN, as an optional featureThe Multi-PLMN feature allows operators to define several primary PLMN,in order to support network sharing (Tool Chain, OMC-R, MFS, Abistransmissions, and also BTS, via rack sharing). Inter-PLMN handovers andcell reselections between two different primary PLMN are supported.The BSC itself cannot be shared and therefore remains mono-PLMN (i.e. allBSC 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 eightPLMN (four primary and four foreign). Both cell reselections and handoversare allowed between two cells which belong to different primary PLMN.The operator can define handover adjacency between two cells belonging todifferent primary PLMN (which must therefore be owned by two differentBSC).

The OMC-R (and the Tool Chain) is by definition of the feature itself alwaysshared 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-PLMNfeature.

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 theOMC-R side.

The primary PLMN cannot be added, removed or modified online.


2 BSS Overview

Customers no longer need to ensure CI (or LAC/CI) unicity over all PLMNinvolved in their network.

With regard to clock synchronization, the only constraint is that when theMFS is connected to different SGSN, these SGSN are not synchronizedtogether, therefore, central clocking and cascade clocking cannot be used onthe MFS side.


2 BSS Overview


3 BTS Configurations


BSS Overview describes the Alcatel BSS, and corresponding features andfunctions.

The following figure shows the location of the BTS inside the BSS.

Figure 13: BTS in the BSS



3.1 BTS Generation SummaryThe following table lists the successive BTS generations, along with thecorresponding 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

GERAN TRA

G3.8 G4.2 M5M MBS

GERAN TRA

* : Note that G3.8 and G4.2 are the TD used names for respectively Evolium Evolution Step 1 and Evolium EvolutionStep 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 tocover many cell configuration possibilities, including omni or sectored cellsconfigurations:

The antenna coupling level, which consists of ANX, ANY, ANC, AGX,AGY, AGC and ANB

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 isdescribed in Evolium BTS Architecture (Section 3.2.1).

Further evolutions were introduced, with the G3.5, G4 variants and GERANTRA:

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.5BTS 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 anda wide band combiner

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.

GERAN TRA

with following types:

GERAN High Power/4RX TRA, Geran Transceiver High Power GTH

GERAN SLIM TRA, Geran Transceiver Slim GTS

GERAN TWIN TRA, Geran Twin Transceiver GTT

3.2.2.1 Product PresentationThere 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 DimensioningThe following table lists the extension and reduction capacity rules for theEvolium BTS.



Extension / ReductionConfiguration

Physical Logical

BTS

Minimum Maximum Minimum

Evolium BTS 1 TRE Up to 24 TRE 1 to6 Sectors

1 TRE 1 TRE

M4M Micro-BTS 2 TRE Up to 6 TRE 1 to 6Sectors

2 TRE 1 TRE

M5M Micro-BTS 2 TRE Up to 12 TRE 1 to6 Sectors

2 TRE 1 TRE

Table 9: Evolium BTS Minimum and Maximum Capacity

The following table summarizes the typical GSM 900, GSM 1800 and GSM1900 configurations.

These configurations constitute only a subset of the possible configurations.

Network GSM 900 MHz GSM 1800 MHz, GSM 1900 MHz

Indoor /Outdoor

Indoor Outdoor Indoor Outdoor

Cabinetsize

Mini Medi Mini Medi Mini Medi Mini Medi

Numberof TRE 1sector

1x2 to1x4

1x2 to1x12

1x2 to1x4

1x2 to1x12

1x2 to1x4

1x2 to1x12

1x2 to1x4

1x2 to1x12

2 sectors 2x1 to2x2

2x2 to2x6

2x1 to2x2

2x2 to2x6

2x1 to2x2

2x2 to2x6

2x1 to2x2

2x2 to2x6

3 sectors 3x1 3x1 to3x4

3x1 to3x2

3x1 to3x4

3x1 3x1 to3x4

3x1 to3x2

3x1 to3x4

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

The table below shows BTS configurations based on G5 ANC (GERAN TRAbased):

BTS Configurations Single TRA Based Twin TRA Based

MBI3 3*2 TRA HP /4 RX low loss /2 G5ANC

3*4 TRA SLIM / 2 RX

3*2 TRA HP / 4 RX low loss

3*4 TRA TWIN / 2 RX



BTS Configurations Single TRA Based Twin TRA Based

MBI5 3*4 TRA HP / 4 RX low loss /2 G5ANC

3*6 TRA SLIM / 2 RX w. ANY3


3*8 TRA TWIN / 2 RX w. ANY2

MBO1 3*2 TRA HP / 4 RX low loss /2 G5ANC

3*4 TRA SLIM / 2 RX


3*4 TRA TWIN / 2 RX

MBO2 3*4 TRA HP / 4 RX low loss /2 G5ANC

3*6 TRA SLIM / 2 RX w. ANY3


3*8 TRA TWIN / 2 RX w. ANY2

CBO AC 2*1 TRA HP / 4 RX low loss /2 G5ANC

3*1 TRA SLIM / 2 RX

2*1 TRA HP / 4 RX low loss /2 G5ANC

2*2 TRA TWIN / 2 RX

CBO DC 3*1 TRA HP / 4 RX low loss /2 G5ANC

3*2 TRA SLIM / 2 RX

3*1 TRA HP / 4 RX low loss /2 G5ANC

3*2 TRA TWIN / 2 RX

TWIN operation modes supported by different BTS HW generation canbe found in the table below:

TWIN TRA 2TRX Modebothon same sector

2TRX Modebothon diff. sectors

1TRX ModewithTX Div.

1TRX Modew/o TXDiv.

BTS-A9100G3-Mini-IndoorYES YES NO1) NO1)

BTS-A9100G3&G3.5-Mini-Outdoor

YES YES NO1) NO1)

BTS-A9100G3&G3.5-Medi-Outdoor

YES YES NO1) NO1)

BTS-A9100G4-Mini-IndoorYES YES NO1) NO1)

BTS-A9100G4-Medi-IndoorYES YES NO1) NO1)

BTS-A9100G3.8-Mini-Outdoor

YES YES NO1) NO1)

BTS-A9100G3.8-CPT2-Outdoor

YES YES NO1) NO1)

BTS-A9100G3.8-Medi-Outdoor

YES YES NO1) NO1)

BTS-A9100G4-MBI-3YES YES YES2) YES

BTS-A9100G4-MBI-5YES YES YES2) YES



TWIN TRA 2TRX Modebothon same sector

2TRX Modebothon diff. sectors

1TRX ModewithTX Div.

1TRX Modew/o TXDiv.

BTS-A9100G4-MBO-1YES YES NO1) NO1)

BTS-A9100G4-MBO-2YES YES NO1) NO1)

BTS-A9100G4-CBO YES YES YES2) YES

BTS-A9100G5-MFO-1YES YES YES2) YES

BTS-A9100G5-MFO-2YES YES YES2) YES

1) : Due to the fact that for these Network elements the cell planning is done, the feature TX Div. will not be supportedon these net elements.

2) : Ordered configuration for TX Div. will be delivered from factory as default with 2TRX Mode cabled in differentsectors and has to be configured on site for TX Div.

All 4 types of TRA are supported in the same BTS on cell.

SUMP cannot support TWIN. SUMP must be upgraded. Second Abis isnecessary for EDGE and for more then 12 TRX.

The following table summarizes the typical Multiband 900/1800 BTSconfigurations.

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

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 ConfigurationUp to 12 TRX CS+PS capable, including the BCCH TRX can be offered in eachcell (inner + outer).

M4M and M5M do not support extended cell configurations.

Only one extended cell per BTS is possible.

3.2.2.4 Mixture of M5M and M4M BTSThe following 4 configurations rules are defined for pure M5M and M4M/M5Mmixed 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 theInter Entity Bus (IEB)

M4M is not allowed in the lower slave position

M5M must be set as master in M4M/M5M mixed configurations.

3.2.2.5 Mixed configuration G3 and G4In case of mixed hardware configuration in a cell with both G3 and G4 TREsin the same cell, it is recommended to map to E-GSM TRX on G4 TRE andP-GSM TRX on G3 TRX.

Under some conditions, the BSC does not guarantee that the PS TRXs havingthe highest priority for PS allocations are mapped on the G4 TREs.

3.2.2.6 Mixed configuration G3/G4/TWINThe following mixed configuration are possible:

BTSExtensions... in thefield

CabinetType

Features supported

2 TRXModeonsame sector

2 TRXModeon 2sectors

1 TRXModewithTX-DIV/4RX

1 TRXModew/oTX-DIV/4RX

> 12 TRX perBTS

G3 mix withTWIN

all YES YES NO NO NO

G3.8 mixwith TWIN


G4 mix withTWIN




3.3 G2 BTSThe 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..

Configuration Extension / Reduction

Physical Logical

BTS Minimum Maximum Minimum

G2 1 TRE 1 Sector:8 TRE 1 TRE 1 TRE

Table 12: G2 BTS

3.4 G1 BTSOnly MKII G1 BTS with DRFU and DRFE are supported in release B9, andrelease 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 SynchronizationIn terms of dimensioning, from a software point of view, there can but up to3 BTS slaves.

Depending on the hardware configuration, the number of BTS slaves canbe reduced to 2 or 1 BTS.

The following table lists the type of slave BTS which can be synchronized to themaster and the number of BTS slaves, for each BTS master.

Master Slaves Hardware Limitation Software Limitation

G2 standard G2 5 3

G2 standard Evolium 5 3

G2 mini G2 2 3

G2 mini Evolium 2 3



Master Slaves Hardware Limitation Software Limitation

Evolium medi/mini G2 1 3

Evolium medi/mini Evolium 3 BTS slaves maximumin a chain configuration

3

Table 13: BTS Synchronization

3.6 Physical Channel Types

3.6.1 GSM

In terms of TS content, there are several possible configurations, the mostrelevant 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 beoptionally configured. The extended CBCH channel is managed in the samemanner 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 numberof SDCCH due to the configuration of the CBCH can increase the SDCCHaverage 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. Ifit is set to 1 , GPRS is not supported in the cell.

GPRS radio time-slots (PDCH) are dynamically allocated according to thefollowing, 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.

Those parameters allow the operator to prioritize CS traffic versus GPRS trafficin 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-935MHz), this corresponds to 174 addressable carrier frequencies and leads to anincrease 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 GSM1800

GSM1900

850/1800 850/1900 900/1800 900/1900

G3/G4BTS

a

(*)

E-GSM a a a a a a

M5MBTS

a E-GSM a a a a a a

M4MBTS

N.A a a N.A N.A N.A a N.A

G2 BTS N.A E-GSM a a N.A N.A N.A N.A

G1 MKIIBTS

N.A a N.A N.A N.A N.A N.A N.A



* : 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) areused in different sectors of the BTS. There are 2 BCCH carriers, one in thesector 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 inband 2. Only one BCCH carrier is configured for the sector.

3.8 Speech Call Traffic RatesThere 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 a a

G2 + DRFU a a

G1 MKII + DRFU a a

Table 15: Hardware Transmission Compatibility

The following table shows the different rates available over different generationsof equipment.

BTS Traffic Rate

Evolium, M4M, M5M

G2 + DRFU

G1 MKII + DRFU

FR,DR,EFR,AMR

Table 16: Speech Call Traffic Rates

Dual Rate (DR) (HR+FR)

Full Rate (FR)

Enhanced Full Rate (EFR)

Adaptive Multi-Rate speech codec (AMR).



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 withthe best speech quality is used, regardless of radio conditions.

Under good radio conditions, a codec with a high bit-rate is used. Speech isencoded 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 isencoded with less information, but this information can be well protected due toredundancy 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 bythe MS (for downlink adaptation).

The codec used in the uplink and downlink directions can be different, as theadaptation 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 Half Rate

12.2 Kbit/s X

10.2 Kbit/s X

7.95 Kbit/s X X(*)

7.40 Kbit/s X X

6.70 Kbit/s X X

5.90 Kbit/s X X

5.15 Kbit/s X X

4.75 Kbit/s X X

* : 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 aper BSS basis.

A different number of codecs and different subsets can be defined for FR (1to 4 codecs out of the 8 codecs available), and for HR (1 to 4 codecs outof the 5 codecs available).

The codec subset is the same in uplink and downlink.



3.10 Data Call TrafficThe following table shows the data service rate available over differentgenerations of equipment.

Yes = a Up to 9.6 Kbit/s GPRSCS-1 andCS-2

GPRSCS-3 andCS-4

EGPRSMCS-1 toMCS-9

G4 TRE and M5M a a a a

G3 TRE and M4M a a a

G2 + DRFU a a

G1 MKII + DRFU a a

Table 18: Data Call Traffic

3.11 OML and RSL SubmultiplexingThe following table shows the submultiplexing OML with RSL over differentgenerations of equipment.

Yes = a RSL&OML StatisticalMultiplex

RSL &OMLTS64Kbit/s

RSL 16KbitsStaticMultiplex

64 Kbit/s 16 Kbit/s

Evolium,M4M, M5M

a a a a

G2 + DRFU a a

G1 MKII +DRFU

a

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 reuseof frequencies.

The following profile type parameters are used to define the cells:

Cell dimensionMacro up to 35 Km but up to 70Km with extended cells. Micro up to 300meters.



Cell CoverageThere are 4 types of coverage: single , lower (overlaid), upper (umbrella),and indoor.

Cell PartitionThere are 2 types of frequency partition: normal or concentric.

Cell RangeThe cell range can be either normal or extended.

Cell Band TypeA cell belongs to 850, 900, 1800 or 1900 bands, or to 2 frequency bands inthe 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 Micro Indoor Normal Normal

Table 20: Cell Types

Non extended, non concentric mono-band cells of any type can be converted tomultiband 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 aconcentric 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 cellof a specific type

The micro concentric, mini concentric, indoor concentric cells must bemultiband (the allowed FREQUENCY_RANGE is PGSM-DCS1800 orEGSM-DCS1800). This restriction does not apply to external cells.

The Unbalancing TRX Output Power per BTS sector allows unbalancedconfigurations on the same antenna network. This configuration behaves as a



concentric cell, where the output power balancing is performed on a zone basisinstead 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 isconnected in by-pass mode on the second antenna path. This leads to thesame sort of concentric cell configuration as in the case TREs with differentoutput power are used. When is activated, it is recommended to the operator toset 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

· 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 ratherthe structure of the hopping laws.

The following table shows the hopping types supported in release B9.

Hopping Type Supported in B9

Non Hopping (NH) X

Base Band Hopping (BBH) X

Radio Hopping (RH) * -

Non Hopping / Radio Hopping (NH/RH) X

NH/RH with Pseudo Non Hopping TRX X

BBH with Pseudo Non Hopping TRX X

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



BBH (baseband hopping): each transceiver (TRX) is transmitting on one fixedfrequency. Hopping is performed by switching the mobiles from burst to burst tothe 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 frequenciesN(hop) is determined by the number of TRXs N(TRX): N(hop) <= N(TRX). ABTS equipped with only one TRX cannot perform baseband hopping.

RH (radio hopping or synthesizer frequency hopping): The TRX do not getfixed frequency assignment, they can change their frequency from TS toTS according to a predefined hopping sequence. The number of applicablehopping 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 andthe G1 band; other mixings are not allowed.

3.12.3 Shared Cell

3.12.3.1 OverviewEach BTS can manage one (all BTS generations) or several cells (from G3BTS). In the case of a cell shared by several BTS, is possible to supportup to 16 TRX.

Only the A9100 Evolium BTS supports shared cells. In the case of a monobandshared sector, every type of cell is supported except for extended cells. In thecase of a bi-band shared sector, only concentric cells are supported.

In general, a BTS comprises several physical sectors. Until release B7, a cellwas mapped on a physical sector. The operator can associate 2 physicalsectors pertaining to different BTS with one shared sector. This shared sectorcan be mono or bi-band and it can support one cell as a normal sector. It takesthe identity of one of the physical sectors. Between the 2 sectors, one is themain sector, and the other is the secondary sector.

This allows:

Existing cells to be combined into one (for example, one 900 cell and one1800 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 adifferent Abis link, the same or different Abis TSU, or by same or differentmultiplexing schemes.

The shared cell requires a specific attribute that must be defined by theoperator (either primary or secondary) at the TRX level.

3.12.3.2 RulesThe following rules apply:

Clock synchronizationThe BTS in a shared cell must be synchronized.

Hardware coverageFor G3 BTS and beyond, generations can be mixed as long as master/slaveconfigurations are possible. Cell sharing is not supported on M5M andM4M, because they cannot be clock synchronized.



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

3.12.3.3 DimensioningThe 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 providesautomatic (the optimal number of) SDCCH in a cell, which translates as a set ofdynamic SDCCH/8 TS, used for TCH traffic or for SDCCH traffic, depending onthe requirements. SDCCH management is handled by the operator in RNUSM.It is also possible to customize the SDCCH templates by choosing from a listof 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 thepossible number of TRXs in a cell, because no algorithm can be defined toevaluate the number of SDCCH depending on the number of TRX in a cell.

3.13.1.1 General PrinciplesThe following general principles apply:

Dynamic SDCCH allocation only deals with SDCCH/8 TS. It is not necessaryto 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 staticSDCCH/8 TS (mapped on the TCU(s) whose load state is not Very HighOverload) 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/8TS

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



Cells with more than 2 TRX are configured with the non combined mode.

In the case of manual configuration (not assisted), the operator configures thestatic and dynamic SDCCH TS for the cell but cannot reuse the configurationfor other cell.

3.13.1.2 TerminologyA static SDCCH/x TS refers to one physical TS on the Air interface containing xSDCCH sub-channels (x = 3, or 4, or 7, or 8, depending whether the TS isSDCCH/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 configurationof 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 carryGPRS 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 outerzone, can support dynamic and static SDCCH

The total number of SDCCH sub-channels configured on static or dynamicSDCCH 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, cansupport 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 notexceed 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 featuredoes not require the use of more SDCCH in the BSS than without it, becausethe traffic model is the same as without this feature. The operator can configuremore SDCCH, without having to diminish the number of TCH.

An SDH TS must be (mandatory) ranked #1-#3 in the BCCH BBT.


4 BSC Configuration

4 BSC ConfigurationBSC Configuration describes the A9120 and A9130 BSC Evolution, andcorresponding features and configurations.

The following figure shows the location of the BSC inside the BSS.

Figure 14: BSC in the BSS


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 CapabilitiesThe following table lists the maximum theoretical capacities versusconfigurations that have been committed to by Mobile Networks Division.Capacities greater than this cannot be guaranteed and should not be offeredto customers.

Configuration Maximum TrafficMax

Release 1 2 3 4 5 6 FRTRX

DRTRX

Cells BTS Erlang

B5.1 X X X X X X 352 176 264 255 1700

B6.2 X X X X X X 352 224 264 255 1800

B7 X X X X X X 448 224 264 255 1900

B8 X X X X X X 448 224 264 255 1900


4 BSC Configuration

Configuration Maximum TrafficMax

B8 X X X X X X 448 224 264 255 1900

B8 X X X X X X 448 224 264 255 1900

B8 X X X X X X 448 224 264 255 1900

B8 X X X X X X 448 224 264 255 1900

B8 X X X X X X 448 224 264 255 1900

B9 X X X X X X 448 224 264 255 1900

Table 21: Maximum Supported Capacities and Configurations

The following table below lists the parameters that are applicable to allconfigurations across all releases.

B5.1 B6.2 B7 B8 B9

CPRC-SYS 2 2 2 2 2

CPRC-OSI 2 2 2 2 2

CPRC-BC 2 2 2 2 2

TRE (FR FU)/TCU or RSL /TCU

4 4 4 4 4

TRE (DR FU) /TCU

2 2 2 2 2

TRE / BTS(Evolium BTS)

12 12 12 12 12

LAPD / TCU 6 6 6 6 6

Cells or Sectors/BTS

6 6 6 6 6

TRX / Cell 12 12 16 16 16

TRX / Cell forGPRS support

1 16 16 16

Max Nb SCCPcnx / BSSAPproc.

128 128 128 128 128

FrequencyHoppingIdentifiers

1056 932 1056 1056 1056


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 ConfigurationsThe main rule is that the BSC configuration always has to handle the completeconfiguration for the G2 TC. It may be that some G2 TC racks can beunder-equipped compared with the BSC configuration.

4.1.1.3 Rack RulesThe following rules apply.

Extension / Reduction

Configuration Racks Physical Logical


A9120 BSC

Lower Half 1 3 Racks Half Rack Half Rack

The following data shows the different steps required to go from a minimumA9120 BSC configuration to the maximum configuration. The granularity ofextension/reduction is provided by a Terminal Unit (TU). A TU is a set of 4 TSUsharing 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 4 = 2 Abis TSU + 2 Ater TSU = Lower Rack 3.


The following table describes the BSS evolutions.

Step Abis TSU Ater TSU Stage 1 Stage 2 Racks FR TRX Abis/AterMux

1 1 2 1 4 1 32 6/4

2 4 3 2 4 1 128 24/6

3 6 5 3 8 2 192 36/10

4 9 6 4 8 2 288 54/12


4 BSC Configuration

Step Abis TSU Ater TSU Stage 1 Stage 2 Racks FR TRX Abis/AterMux

5 11 8 5 8 3 352 66/16

6 14 9 6 8 3 448 84/18

Table 23: BSS Evolution Description

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

Configuration 1 2 3 4 5 6

Racks Lower 1 Upper 1 Lower 2 Upper 2 Lower 3 Upper 3

Clock BoardsBCLA

4 4 6 6 8 8

TransmissionControllerTSCA

1 1 2 2 3 3

AccessSwitch

8 16 24 32 40 48

GroupSwitch Stage1

8 16 24 32 40 48

GroupSwitch Stage2

32 32 64 64 64 64

DC-DCConverters

13 17 30 34 42 47

Abis TSU 1 4 6 9 11 14

A bissub-multiplexersBIUA

1 4 6 9 11 14

TerminalControl UnitsTCUC

8 32 48 72 88 112

A bisinterfaces

6 24 36 54 66 84

LAPDchannels

48 192 288 432 528 672

ATER TSU 2 3 5 6 8 9


4 BSC Configuration


A tersub-multiplexersASMB

4 6 10 12 16 18

Digital TrunkControllersDTCC

16 24 40 48 64 72

A terinterfacesmaxicarryingtraffic

16 24 40 48 64 72

No.7 DTCC 4 6 10 12 16 16

TCHResourceManagementDTCC pairs

2 2 4 4 6 6

BSSAPDTCCs

8 14 22 28 36 44

Full/ DualRate TRXor 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 orsectors

32 120 192 240 264 264

BTSequipmentor OMLs (**)

23 95 142 214 255 255

A ter Qmuxcircuits

2 2 4 4 6 6

A ter X.25circuits

2 2 2 2 2 2

A ter AlarmOctets

4 6 10 12 16 18

A ter circuits(assumingX.25 on Ater)

454 686 1148 1380 1842 2074

A ter Erlangs(70%)

480 804 966 1289 1452


4 BSC Configuration


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

A ter Erlangscommitted

160 620 1050 1300 1700 1900

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

1 : + 4FR

2 : + 8FR

3 : + 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 thespeech/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 TCUCTSL is a LAPD link connecting the TCUC to the (Transcoder SubmultiplexerController (TSC). The TSC is in charge of the supervision of the transmissionpart of the BSS equipment and the transmission configuration. It polls the NEand collects the alarm indications. After the correlation process, it sends the listof 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 SBLNumber)

TCU Number TS Used on BS*Interface

TSL 1 (first rack) 1 1 28

TSL 2 (second rack) 6 41 28

TSL 3 (third rack) 11 81 28


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 TCUCRules 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 TSL

4 FR 2

4 FR 1 1

3 FR 3

2 FR 2 1

2 DR 2 1

Table 26: Configuration Example


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


4 BSC Configuration

All TRX of all BTSs of a same Abis multi-drop are controlled by the TCU ofa 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 tothe 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 .


4 BSC Configuration

4.1.2.3 G2 HR FlexibilityCurrently, GSM network operators see the HR as a way of extending thecapacity 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 individualTRE as full rate or dual rate. This allows control of the HR ratio on a per cellbasis. Due to the TRE/TCU mapping algorithm where TRE and TCU must be ofthe same type (full rate, dual rate), mapping is not possible when there is noTCU at all or when the TCU which could be available is already mapped toTRE whose type is different.

The TCUs of a TSU are allocated, by the A9120 BSC, to support FR or DRTREs 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 nomultiplexing mode.


4 BSC Configuration

The statistical multiplexing scheme (64/4, 64/2, 64/1) is not defined by theoperator, but the operator can select the expected level of signaling load (highor 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 withthe signaling load and the TRE type.

In the case of statistical 16Kbit/s multiplexing, only the FR TREs will bestatically 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 thetranscoder 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 forQmux, X25 or SS7)

2 access switches.

4.1.3.1 DTC RulesThe 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 theBSC 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 ofTRX per TCH-RM is limited to 90.



4 BSC Configuration

Figure 16: Ater TSU Configuration

4.1.3.2 DTC Architecture and FunctionsThe DTC processors are configured by default to perform one of 3 mainfunctions:

TCH-RM

BSSAP/GPRSAP

MTP-SS7.

The following table shows the default mapping on the DTC SBL number.

BSC Configuration

1 2 3 4 5 6

TCH-RM 3-4,11-12 27-28,35-36 51-52,59-60


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

65-72

SS7-MTP 1,5,9,13 17,21 25,29,33,37 41,45 49,53,57,61

Table 27: DTC Configuration and SBL Number

Rules and Dimensioning


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 ofsoftware 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 fordedicated management of the TSC software. The SBLs TSL must havea purely internal meaning.

The TSC data base update mechanisms must follow the principles of the BTSdata base updates (i.e. the TSC is configured by data coming from BSC atstart up, and whenever the BSS configuration has changed something whichis 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 ATCAplatform.


4 BSC Configuration

SSW

(duplicated)

Rad

io N

etw

ork

lin

ks

External Ethernet Links

LIU Shelf

(21 slots)

E1

CCP y

TP r TP

Mux

LIU1

LIU n

ATCA Shelf (14 slots)

CCP

OMCPw

OMCP r

graphics/20881001.cgm

r : Redundancy

W : Working

N and y : Network Element capacity

Figure 17: A9130 BSC Evolution HW Architecture

The following table describes the A9130 BSC Evolution functional blocksand boards.


4 BSC Configuration

Name Functional block mapped on board Existing function for BSC

SSW: Gigabit Ethernet switch (inATCA shelf)

Allows exchanges between all theelements of the platform and externalIP/Ethernet equipment:

Performs Gigabit Ethernetswitching at the shelf level

Performs powerful monitoring for

the user plane and control plane(Gigabit Ethernet on front panel)

Ensures daisy chain with othershelves via two 1 Gigabit Ethernet

ports (only one is used)

Ensures multicast function

Allows several external Ethernet10/100/1000 Base T connections:

OMC-R, CBC, LCS, Debug

Implements 12 non blocking1Gigabit Ethernet links via

backplane connections

...

The SSW board and all theconnections to the switch areduplicated to overcome board orconnection failures.

OMC-R physical interface

CBC physical interface

Monitoring

NEM terminal connection

OMCP: O&M Control Processingboard (in ATCA shelf)

Is based on ATCA technologyequipped with a permanent storagedevice. It manages the platform assystem manager, and manages O&Mapplications.

OMCP boards operate inactive-standby mode followingthe 1+1 redundancy model.

O&M logical interface to theOperation and MaintenanceCenter (OMC-R)

VCPR: S-CPR & O-CPRsoftware + TCH/RM

TSC software

CCP: Control Processing board (onATCA shelf)

Is based on ATCA technology usedfor call control functions. Identical tothe OMCP board but without a harddisk.

CCP boards operate in an N + 1redundancy model. N is the numberof active boards ready to handletraffic and one standby CCP boardis always available to take over thetraffic of failed board.

VTCU: TCU software

VDTC: DTC software


4 BSC Configuration


TP GSM: Transmission Processingboard (in ATCA shelf)

Provides telecom transmission /transport interfaces to the ATCAplatform.

Gigabit Ethernet switchOn-board local switch(separates/aggregates nE1oEtraffic and IP control traffic).

NE1oETransports n x E1 frames inEthernet payloads, and isassigned to a dedicated MACaddress.

Multiplexes/de-multiplexes up to252 E1Multiplexes/de-multiplexes upto 252 E1 from/to the GigabitEthernet Interface (NE1oE).

TDM switch8 kbit/s synchronous switchingwith a total bandwidth of 284 *2 Mbits (252 external links + 32internal links toward HDLC, SS7,Q1 and R/W bits controllers).

Handles low layers of GSMprotocolsLAP-D over HDLC, ML-PPP overHDLC, SS7, Q1 (= QMUX) andR/W bits.

Two TPGSM boards are available.They operate in active-standby modefollowing 1+1 redundancy model.

HDLC termination

SS7 termination

NE1oE

Q1

Ring control

LIU boards (in LIU shelf) Interface for Radio Network links These links correspond tothe user plane interfaces.

MUX board (in LIU shelf)

Ethernet links on IP ports of SSWswitch

These links connect theplatform to externalIP equipment (OMC-R,External Alarm Box, etc.).


4 BSC Configuration


LIU Shelf Multiplex/demultiplex which crossconnects all E1 external links to/froma NE multiplexed links (n E1 overEthernet) at TP and GP board.

It is equipped with 2 x Mux board andn LIU boards.

E1 physical termination

NE1oE

ATCA Shelf See above.

4.2.2 Configurations

For A9130 BSC Evolution, E1 termination ports are generic and are configuredto "Abis", "Ater" or "not used" without any constraints. Consequently Abis or Atertermination ports may be not contiguous. Abis-Hway-TP are numbered fromthe first E1 termination port to the last one. The numbering of Abis-Hway-TPremains without holes, even if they are mapped on discontinuous E1 terminationports. 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. Fora GPRS dedicated Atermux, the Ater-Hway-TP at TC side is not equipped, butthe 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 forfuture 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:


4 BSC Configuration

Figure 18: 600 TRX LIU Shelf connections assignment

where

4.2.2.1 A9130 BSC Evolution Board ConfigurationsThe following table lists the board configurations by shelf.

Equipment BSC Capacity 200 TRX BSC Capacity 400 TRX BSC Capacity 600 TRX

ATCA Shelf 1

CCP 1+1 2+1 3+1

SPARE CCP 1

TPGSM 2

OMCP 2

SSW 2

LIU Shelf 1


4 BSC Configuration

Equipment BSC Capacity 200 TRX BSC Capacity 400 TRX BSC Capacity 600 TRX

MUX 2

LIU 8 16

Note: Note that the quantity of TPGSM, OMCP, SSW and MUX boards must beconsidered 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 ConfigurationsRack shared configuration for A9130 MFS and A9130 BSC Evolution consistsof:

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 configurationfree 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 nearbyBSCs (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 MFS capacity

200TRX 400TRX 600TRX "9 GP" (*)

ATCA Shelf 1 1

CCP 1 2 3 NA

SPARE CCP 1 NA

TPGSM 2 NA

GP NA 1 to 9(*)

SPARE GP NA 1

OMCP 2 2

SSW 2 2

LIU Shelf 1 1

MUX 2 2

LIU 8 16 8


4 BSC Configuration

* : As no extension possible for MFS in rack shared, options 14E1 per GP or 16 E1 per GP are proposed then maximumnumber 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 1activ + 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:

Configuration Type 1 2 3

Nb TRX 200 400 600

Nb Cell 192 264 264

Nb BTS 150* 255 255

Nb SS7 links 8 16 16

Capacity

Nb CICs 1024 2068 3112

Abis 96 96 176

Ater CS 10 20 30

Nb of E1

Ater PS 6 12 18

Nb TCU 50 100 150

Nb DTC CS 40 80 120

Nb VCE CCP

Nb DTC PS 24 48 72

Nb TCH-RM pairs 8 8 8

Nb CPR pairs 2 2 2

Nb VCE OMCP

Nb TSC pairs 6 6 6

Nb VCE per CCP 114 114 114Nb VCE per board

Nb VCE/OMCP 15 15 15

Nb CCP 1 2 3

Nb OMCP 2 2 2

Nb spare CCP 1 1 1

Nb TP GSM 2 2 2

Nb boards ATCA

Nb SSW 2 2 2


4 BSC Configuration

Configuration Type 1 2 3

Nb boards SMM Nb SMM 2 2 2

Nb MUX 2 2 2Nb boards LIU

Nb LIU 8 8 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 BSCThe A9130 BSC Evolution differs in plus from standard BSC as follows:

Compared to previous generation BSC, the ATCA PF does not provide X.21interfaces. 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.


4 BSC Configuration


5 TC Configuration

5 TC Configuration

TC Configurations describes the transcoder, and corresponding featuresand 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 onesingle board, the MT120, which offers an Atermux connection to a BSC and upto 4 A-trunk connections to the MSC.

The MT120 can also be installed in the place of the ASMC in the G2 TC, andreplaces 1 ASMC, 4 ATBX and 8 DT16 boards.

The following table provides a summary of the technical data for the differentgenerations of TC.


5 TC Configuration

G2 TC(with/withoutMT120)

A9125 TC

Number Up to 3 One

Type S12 19"

Rack

Size mm 900*520*2200 600*600*2000

Atermux per rack 6 48

A interfaces 24 192

CIC 24*29 192*29

Table 28: G2 TC/A9125 Compact TC capabilities


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

The G2 TC architecture is linked to the A9120 BSC architecture (that is, theAter 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.



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), theextension 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 oneAter 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, theconfiguration rules described in the following table are applied for this rack.

Configuration Per Rack Extension / Reduction

Physical Logical


G2 TC 2 Atermux 6 Atermux One Atermux One Atermux

SU 2 6 1 1

ASMC 2 6 1 1


5 TC Configuration

Configuration Per Rack Extension / Reduction

TRCU SM 4:1 4 24 4 4

MT120 - 4 1 1

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 andA9125 Compact TC within a BSS), for G2 TC replacement and for new BSS.

For G2 TC replacement, one A9125 Compact TC can replace several G2TC racks.

The A9125 Compact TC can be equipped with up to 48 sub-units (referred toas MT120 boards). Each MT120 offers an Atermux connection to a BSC andup to 4 Atrunk connections to the MSC, so that the A9125 Compact TC offersup to 192 Atrunk connections to MSC.

The A9125 Compact TC can be shared between several A9120 BSC. OneMT120 board in any slot of any subrack can be allocated to any Atermux of aA9120 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 Logical


MT120 2 48 1 1

Table 30: G2 TC Configurations


For Qmux connectivity, all the TC boards connected to one BSC rack mustbelong to the same TC rack. This constraint is valid for both, G2 TC andA9125 Compact TC rack types.

For redundancy purpose, a A9120 BSC must be connected to a A9125Compact TC via 2 Atermux at minimum.

For exemple:


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 supervisionof the boards with the TSC of the related BSC. These MT120 boards cannotbe adjacent or in a different subrack, but must be always in the same A9125Compact TC rack.

The notion of Qmux clusters is important during extension of Atermux in a BSCrack, as it can induce modification of the initial configuration.

Different extensions are possible:

Extension of Atermux in a BSC rackIn this case, the Qmux cluster is increased. Recabling of all of the Atermuxof a cluster into a new A9125 Compact TC rack is necessary if there areno more free slots in the A9125 Compact TC.

G2 TC extensionOnce the G2 TC rack maximum capacity (6 Ater) has been reached, BSCextension will require TC capacity. In this case, the A9125 Compact TCrack is required as the G2 TC rack extension (G2 TC rack is kept). TheA9125 Compact TC rack can be shared afterwards between different BSCextensions. An A9125 Compact TC rack can also be added even if the G2TC rack is not completely filled (in the case of GPRS holes).

New rack of a BSC by extension of Atermux capacityDepending of free slot capacity in the A9125 Compact TC, a new A9125Compact TC may be required.

New BSCDepending of free slot capacity in the A9125 Compact TC, a new A9125Compact TC may be required.


5 TC Configuration


6 MFS Configuration

6 MFS Configuration

MFS Configuration describes the MFS, and corresponding features andfunctions.


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 networksfor interconnection.

The following figure shows the MFS architecture.

Figure 20: MFS Architecture

6.1.1.1 GPRS Processing UnitThe 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.


6 MFS Configuration

A GPU board is linked to one BSC.

The GPU supports the Packet Control Unit (PCU), as defined by GSM. ThePCU allows the BSS to access the GPRS service to SGSN.

The PCU is split into 2 parts:

The Packet Management Unit (PMU), which handles asynchronousfunctions

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 PCMlinks is not dedicated, and each interface can be connected to BSS or NSSentities. 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 BSSIn order to increase the GPRS capacity of the BSS in terms of the number ofPDCH, it is possible to connect several GPUs boards to the BSC to support thePCU function.

The maximum number of GPUs to be connected to a BSC depends on theconnection capacity of the BSC.

For example, assuming that a GPU can reach its traffic capacity with 2dedicated Atermux links, and that a GPU is connected to only one BSC with atleast 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 toanother GPU.

The mapping of cells onto GPU is performed by the MFS control station, whichdefines the mapping of cells onto LXPU (logical GPU, which represent eitherthe 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.


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 andignores the mapping of cells per GPU. The BSC is only impacted by a greaternumber of LAPD bearer channels. There GPU also redirect messages.

For inter-GPU links, there are two 100Mbs Ethernet links, which interconnectthe GPU and the Control Station. These links are used to exchange informationbetween GPU.

6.1.2 MFS Configuration

The MFS is offered in 2 configurations:

StandardThe MFS includes one telecom subrack with a minimum 2 GPU (1+1) andcan be extended up to 16 (15+1) GPU. The second Telecom subrack isonly wired and is not equipped.

Standard pre-equippedThe MFS includes 2 equipped and wired telecom subracks. The maximumcapacity is 32 GPU (2 * (15+1)).

The following table describes the MFS capacity for DS10.


6 MFS Configuration

MFS Configuration Standard Standard Pre-equipped

Number of equipped telecomsubrack

1 2

Minimum GPU + One GPU forredundancy

1+1 1+1

Maximum GPU + One GPU forredundancy

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 ifthis synchronization comes from the TC, 4 links will be needed (2 per MFSsubrack). If the synchronization comes from an SGSN (synchronized itself froman MSC), the synchronization must be ensured from this SGSN towards thetwo 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 aredefined via the IMT:

Autonomous

Centralized

Synchro. Fixed Configuration.

Note: The Synchro. Fixed Configuration mode, using GPU cascading, is only forMFS created in release B6.2.

The selected mode is valid for the complete MFS.

Clock synchronization can come from TC, SGSN , or from another entryprovided 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 thatthe GPU will still receive synchronization, either in autonomous mode (plus

one link towards the TC), or in centralized or cascading modes. Cascadingrefers to interconnections between GPU.

6.1.3.1 Autonomous ModeThere must be 2 secured link between each GPU and the TC.


6 MFS Configuration

If the synchronization comes from an SGSN (synchronized itself from anMSC), the synchronization must ensured from this SGSN towards the twoMFS subracks.

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

6.1.3.3 Synchro. Fixed Configuration or Cascading ModeThe ‘Synchro. Fixed Configuration’ mode requires the use of GPU cascading.

When the feature is activated from the IMT, the clock synchronization isperformed from ports 14 and 15 on each GPU.

On first GPU, the 2 primary synchronization interfaces (ports 14 and 15) can beany G.703/G.704 interfaces with no traffic, which have a frequency within 1in 109 of that of the BSS.

At the OMC-R, for each GPU:

The BSC (dedicated GPRS Atermux) and SGSN (Gb) ports (0 to 7) areconfigured 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 DDFto create the synchronization distribution scheme.

To prevent alarm reports towards the OMC-R, all unused ports (from 8 to 13) ofeach 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:


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 forO&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 onpSOS 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 usingnE1oE 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 (physicaltermination).

SSW boards, whereby SSW is the Ethernet switching module, whichconnects 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.


6 MFS Configuration

Board Mono Shelf CentralizedConfiguration

Two Shelf CentralizedConfiguration

OMCP 1+1 1+1

SSW 1+1 2+2

GP 9+1 21+1

E1 concentration boards or MUXboard

1+1 1+1

LIU boards 8 16

Table 32: Maximum MFS Configurations on MX Platform


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 RelativePosition to BSC

Maximum MFSSubrack Number

Configurations

12 TTP centralized

autonomous

remote /colocalized

2 subracks 21 GP

9 GP

14 TTP centralized remote G2 BSC 1 subrack 8 GP

16 TTP autonomous colocalized G2BSC

1 subrack 8 GP

6.2.3 MFS Clock Synchronization

There are two modes:

The autonomous mode, whereby each GPU receives the clock signal ondedicated 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 buson the back panel.


6 MFS Configuration

6.3 Delta A9135MFS versus A9130MFSThe 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 istransmitted 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 casein 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 sameparameters 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.


6 MFS Configuration


7 ABIS Interface

7 ABIS Interface

Abis Interface describes the Abis interface, and corresponding features andfunctions.

The Abis interface is standard ITU-T G.703 / G.704 interface. It is based on aframe structure. The frame length is 256 bits grouped in 32 TS, numbered from0 to 31. The rate of each TS is 64 Kbit/s.


7 ABIS Interface

7.1 Abis Network Topology and TransportFor a functional point of view, 2 topologies are specified to physically connectthe BTS to the BSC:

Open multi-drop topology "CHAIN"One PCM link connects up to 15 BTS in serial order and the PCM is notlooped back to BSC by the last BTS.In a chain topology, the BSC is connected by the Abis link to a BTS. TheBTS is connected to a second BTS with a second Abis link, and the secondBTS 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 loopedback to BSC by the last BTS.In a ring or loop topology, the last BTS of a chain is connected backto the BSC. This topology provides security as traffic between any BTSand BSC is broadcast on the two paths, and the selection is based ondedicated service bits and bytes.The following figure shows a ring or loop topology.


7 ABIS Interface

Figure 24: Ring or Loop Topology

There are several ways of transporting Abis over networks (the following listis 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 ImpedanceThere are 2 types of impedance which define the access to the transmissionnetwork:

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


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 UsageTS0 usage mean that the TS0 carries Qmux.

TS0 TransparencyThe Qmux is carried by any other TS from TS1 to TS31 (TS0 does notcarry 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 BTSand 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 networkmanagement 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 theBSS 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 Qmuxbus and are in slave mode. An O&M entity referred to as the TranscoderSub-multiplexer Controller (TSC) is the master for A9120 BSC and TP forA9130 BSC Evolution.

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


7 ABIS Interface

The Qmux bus is also used for configuring transmission / transcodingequipment.

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 OMLlocation. An on site visit is necessary to update the OML location. With thisconfiguration, the BTS cannot autonomously take into consideration anychange of OML address during a Move BTS, hence the development of OMLautodetection.

The BTS scans 31 TS on the Abis link to detect where its own OML linkis located. In the case of detection of an available OML, the BTS sends itsidentity (Qmux-id) to the BSC via this available OML. The BSC then reportswhether the BTS is listening to the right OML, or on which TS the BTS can findits dedicated OML.

After a reasonable delay, and without any onsite visit by a technician, the BTSautomatically 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 allowsthe 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 TREdeclared during BTS creation. This number must be taken as the DR TRE ineach 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 thesame radio TS0 bits1-2.

7.5.2 Signaling Link Multiplexing Rules


Static signaling submultiplexing is used only in a BSS with Evolium BTS andG2 BTS with DRFU, whereby each TRX carries a maximum of 8 SDCCH


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 staticsignaling 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 issupported.

7.5.3 Multiplexed Channel Block

In order to use statistical multiplexing, the Abis Channels are compounded by aset 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 8Traffic 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 free mapping algorithm begins allocating from the highest usable TS

number downwards, up to the lowest usable TS number, and so on. Itis 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 thecase of cross connects.


7 ABIS Interface

For a given BTS, only TS defined as "usable" for this BTS can be allocatedby the BSC

For any BTS except Evolium BTS, the 2 TS needed to carry the trafficchannels 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-TS0..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 (Section2.5).

7.6.2 Abis-TS Defragmentation Algorithm

Certain types of BTS require that the TCH of a TRE are mapped on 2consecutive 64Kbit/s PCM TS. There are no constraint for the signaling links.

Therefore, for BTS or TRE hardware extensions, two contiguous 64 Kbit/s PCMTS may be required, while only 2 (or more) isolated PCM TS are free. Analgorithm must be run that creates 2 consecutive free TS, with minimum trafficdisturbance. 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 ofG1/G2 BTS).

There is never any need to create in advance more couples of free PCM TSthan are required, as this would just lead to unnecessary traffic interruptions. Itis 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 caseof an Add BTS operation.

The RSLs inside one TCU must be moved to make room for new BTSextensions 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 thesame 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.


7 ABIS Interface

The sequence for remapping RSL/TRX and for programming the BIUA will bereversed 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) areprotected with a roll-back mechanism.

With HR flexibility, the reshuffling algorithm is kept but the reshuffling process isto 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 forthe Abis TS used by the BTS (Qmux bus, OML, RSL and TCHs) on the BTSconnector and on the BIUA/E1 connector. This flexibility is supported by theintroduction of a TS mapping table between the BTS connectors and theBIUA/E1 connectors.

The TS mapping table is introduced by the operator via the OMC-R andapplied by the BSC when a new BTS-BIE configuration is required, due to amodification of the Abis TSs allocation. In order to keep the release B6 principleof auto-allocation of TREs, this TS mapping table will be introduced duringthe "Create an Abis chain/ring" operation. Also, in order to maintain a relativeflexibility on the TS allocation within the TS reserved for each branch connectedto the cross-connect, the operator must also be able to select the TS which canbe used by each BTS during the "Create BTS" operation.

At the OMC-R, the operator can only change usable Abis TS, usable BTS TSand cross-connect tables.

The following figure provides an example of cross-connect use on Abis.

Figure 25: Example of Cross-Connect Use on Abis


7 ABIS Interface

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

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 theBIUA are 10-9-8, and according to the TS mapping table, the TS allocatedfor the BTS-BIE are 10-9-8.

When BTS 2 is created, according to the usable TS, the TS allocated for theBIUA are 15-14-13-12-1, and according to the TS mapping table, the TSallocated for the BTS-BIE are 6-5-4-3-2.

When BTS 1 is created, according to the usable TS, the TS allocated forthe BIUA are 24-23-22-21, and according to the TS mapping table, the TSallocated for the BTS-BIE are 5-4-3-2.

When a TRE is added to BTS 3, according to the usuable TS, the TS allocatedfor the BIUA are 27-26-25, and according to the TS mapping table, the TSallocated 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 otherbranch must use OML if possible (Evolium BTS).

Note: "AND" and "BROADCAST" functions on the Qmux TS are required in theintermediate cross-connect in order to respect the rules. If this function is notpossible, the Qmux bus is not implemented and downloading of the transmissionsettings 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.


7 ABIS Interface

SBL Abis-HW-TP BSC-Adapt TCU

Physical object Abis BUIA Q port BIUA P port TCU

Numbering 1..84 1..84 1..112 1..112

Table 35: SBL Numbering at A9120 BSC Side

The following table lists the Abis port - BIUA - TCU SBL numbering in A9120BSC.

BSC Configuration SBL Number

Abis-Port BIUA TCU

Conf 1 1-6 1 1-8

7-12 2 9-16

13-18 3 17-24

Conf 2

19-24 4 25-32

25-30 5 33-40Conf 3

31-36 6 41-48

37-42 7 49-56

43-48 8 57-64

Conf 4

49-54 9 65-72

55-60 10 73-80Conf 5

61-66 11 81-88

67-72 12 89-96

73-78 13 97-104

Conf 6

79-84 14 105-112

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.


7 ABIS Interface

7.6.6 SBLs Mapping on HW Modules in A9130 BSC Evolution versusA9120 BSC

The figure below gives with their HW modules mapping, the different kinds ofSBLs seen on one hand, at the interface between the A9120 BSC and the BTSsand, on the other hand, at the interface between the BTSs. The internal linksbetween 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 ofSBLs seen on one hand, at the interface between the A9130 BSC Evolutionand the BTSs and, on the other hand, at the interface between the BTSs. Forthe A9130 BSC Evolution, the SBL BSC-ADAPT is removed.

Note: BIUA connectors in A9120 BSC correspond to E1 termination ports in A9130BSC Evolution.

7.6.7 TCU Allocation Evolution in A9130 BSC Evolution

The "TCU allocation Evolution" feature enables the removal of differentconstraints in A9130 BSC Evolution due to flexible TCU allocation approach.The feature considers the removal of TSU concept where in A9120 BSC during


7 ABIS Interface

any extension/reduction of a TRE/BTS, the TCU allocation for RSL/OML wasdone within a TSU i.e. set of 8 TCUs. With this feature TCU resource candidateis extended to all the TCUs irrespective of the CCP baords i.e. not limited to 8TCUs per TSU/BIUA as in A9120 BSC. This also means that mapping betweenAbis & TCU will be replaced with free mapping of any TRE to any TCU as pernew TCU allocation algorithm. This feature aims at defining a new algorithm forTCU allocation. The proposal is to treat all the TCUs as a pool where any Abissignaling 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 ofsignaling channels i.e. RSL/OML on a TCU. Since traffic will be switched withinTPGSM 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 aswe can allocated any available TCU from the TCU pool from configuration pointview 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 (3RSLs) 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/OMLof a given BTS on the TCUs belonging to one and the same CP-LOG in orderto avoid inter-CP messages and Telecom performance degradation. Theseconstraints are preference rules (not mandatory). If they cannot be fulfilled, theRSLs 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 CapacityThe following table lists the number of TS available in one Abis link to use forTCHs 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 andsub-multiplexing type in one Abis Link before HR flexibility.


7 ABIS Interface

Signaling Multiplex

Nb of TRX No Multiplex Static Statistical 64 Statistical 16

1 4 4 3 2

2 7 6 5 4

3 10 8 8 6

4 13 10 9 8

5 16 13 12 10

6 19 15 14 12

7 22 17 17 14

8 25 19 18 16

9 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 inone open chain link.

In the case of statistical 16K multiplexing, it is possible to connect 15 M4M withone TRX or 7 M4M with 2 TRX in one open chain link.

The following table provides example FR/DR ratios according to cell size.


7 ABIS Interface

Number of TRX inCell

DR + FR TRX Max % HR Number of TCURequired (DR +FR)

Number of SIGTSs

(Statistical Mux)

(Low SIG Traffic)

1 1+0 100% + 0 1

2 1+1 66% + 2

3 1+2 50% + 2

4 1+3 40% + 3*

4 2+2 66% 1 + 2

6 2+4 50% 1 + 1 2

8 2+6 40% 1 + 1 3

10 4+6 40% 2 + 1 3

10 3+7 47% 1 + 1 5*

10 2+8 33% 1 + 2 3

12 4+8 50% 2 + 2 4

14 2+12 25% 1+3 4

16 0+16 0% 4 4

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

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

7.8 Abis Satellite LinksThe Abis interfaces were designed to use reasonably short terrestrialtransmission links. However, in developing countries, the terrestrialtransmission infrastructure does not exist and in many cases is difficult andcostly to provide. There is also a need in the developed world to providetemporary GSM coverage for transient mobile population density increases, forexample, at sporting events.

Geostationary earth orbiting satellites are a simple and relatively low costsolution. However, satellite links cannot be used at the same time on the Abisinterface 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


7 ABIS Interface

timers applied on the first BTS will be unnecessarily lengthened and thisdoes not support high traffic with poor quality links.

Usually, only a part of the TS is routed via the satellite. The customer musttake 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 arenot available:

Closed multidrop (Abis topology)

The BTS must be configured as a free run (no PCM synchronized) (OCXOsynchronization).

It is planned to support synchronous handovers.

Support of fax and data (in CS mode, transparent and not transparent) dependson 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 recommendationsdescribe the synchronization process based on a roundtrip delay BTS <->TC smaller than 120ms. This is not true in the case of satellite links. Inconsequence, when a TRAU frame is not synchronized with the BTS, thepermanent synchronization process provokes oscillations, leading in the worstcase (arrival time versus expected time too different) to a loss of 5% of thespeech frames.

For OML autodetection via satellite, a timer has been designed to be ableto manage the transmission delay. In that context, OML autodetection viasatellite is possible.

There are no restrictions for Abis satellites supporting LCS.

7.9 Two Abis Links per BTSIf HSDS is to be introduced in a BTS configuration, and if there are not enoughAbis TS on one Abis link, a second Abis can be attached to the BTS. In thatcase, OML, RSL and basic TS are always mapped to the first link and the extraTS for the TRX transmission pools are split over the 2 Abis links.



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 thesystem is allowed to allocate on the first Abis for this BTS.

To keep the maximum free TS on the secondary Abis, the allocation ofextra TS is done in priority on the first Abis until this Abis is full or untilMAX_EXTRA_TS_PRIMARY is reached.

In terms of the Abis topologies supported, the BTS can manage only 2termination points.

The second Abis is useful when there is not enough space on one completeAbis for all BTSTS. This means that the primary Abis must be fully assigned tothe BTS. Therefore, the secondary Abis cannot be attached to a BTS if theBTS is not alone on the primary Abis.

Consequently, only two added Abis topologies are supported in release B8.



7 ABIS Interface

The primary Abis and the secondary Abis of a BTS can be on different TSU ofdifferent 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 faultmanagement of the link must be based on the transmission alarm. The systemdoes not check for a cross-connect on the secondary Abis. Cross-connection isnot supported on the secondary Abis.

Rules


The second Abis per BTS can be used for CS traffic

The second Abis per BTS is used for more then 12 TRX feature in one BTS

OML, RSL and basic TS are always mapped to the first link and the extraTS for the TRX

Transmission pools are split over the 2 Abis links

Only an Evolium BTS with SUMA boards or M5M supports the secondAbis 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


7 ABIS Interface

Change the Abis from chain to ring if there is a BTS with 2 Abis

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, allEvolium 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 linkby terrestrial means.


8 Ater Interface

8 Ater Interface

Ater Interface describes the Ater interface, and corresponding features andfunctions.


8 Ater Interface

8.1 Ater Network Topology and TransportThere are several ways of transporting Atermux over networks (the following listis not exhaustive):

A terrestrial link referred to as the PCM 2Mbit/s link (64 Kbit/s * 32 TimeSlots = 2048 Kbit/s)

A microwave link (same capacity or higher)

Digital cross-connect network equipment, which concentrates 4, 16 or 64PCM 2Mbit/s link

A microwave hub equivalent to DCN

A satellite link.

8.2 ImpedanceThere are 2 types of impedance which define the access to the transmissionnetwork:

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/AInterface

8.3.1 Overview

The following table shows an overall view of the SBL numbering scheme ofthe path trunks from A9120 BSC DTC/ASMB through the PCM Atermux tothe transcoder.

The SBL numbering of the TRCU always follows the numbering of therespective 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 1 1 1-4

5-8 2 2 2 5-8

9-12 3 3 3 9-12

13-16 4 4 4 13-16

17-20 5 5 5 17-20

21-24 6 6 6 21-24

Rack 1


8 Ater Interface

BSC Side PCM G2 TC Side 4:1 TC Rack

25-28 7 7 7 25-28

29-32 8 8 8 29-32

33-36 9 9 9 33-36

37-40 10 10 10 37-40

41-44 11 11 11 41-44

45-48 12 12 12 45-48

Rack 2

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 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 numberingfollows 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 forthe A9120 BSC side.

This is described in the following table.


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 BSCEvolution-Ater/Atermux/TC Ater/A Interface

8.4.1 Overview

For detailed numbering scheme for A9130 BSC Evolution - Atermux see 600TRX LIU Shelf connections assignment (18).

To avoid the handling of big TC configuration, and because the A9130 BSCEvolution is anyway limited in Erlangs, there are two kinds of Atermux withA9130 BSC Evolution:

Atermux from 1 to 30 that could be connected to MFS or TC: E1 AterCS (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 atA9130 BSC Evolution side. Ater-Hway-TP from 31 to 48 could be used only forGPRS dedicated atermux.

8.4.2 SBLs Mapping on HW Modules in A9130 BSC Evolution versusA9120 BSC

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


8 Ater Interface

The figure below gives with their HW modules mapping, the different kinds ofSBLs seen at the interface between the MSC and the A9130 BSC Evolution (fora TC G2). For the A9130 BSC Evolution, the SBL SM-ADAPT (BSC side) isremoved 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 (« A trunk» refers to the A, Ater and Atermux links):

Signaling System N 7 (SS7)SS7 carries the signaling information relating to call control and mobilitymanagement between the BSS and MSC. The signaling is arrangedaccording to the CCITT Recomendations Q.700-714 for the network protocollayer and to GSM 08.08 for the GSM application layer.

X.25An X.25 link is set between the A9120 BSC and the OMC_R. Dependingon the BSC position related to the OMC_R, this link can be directlyestablished from the A9120 BSC to the OMC_R via an X.25 network, orcarried up to the TRCU site or the MSC site on the A trunk and then viaan X.25 Network (TS31).

IP


8 Ater Interface

The connection of A9130 BSC Evolution with the OMC-R is based on IPprotocol on both two routes, namely over direct IP network, or over Aterand IP network.

GSLThe GSL handles signaling for GPRS paging and for all synchronizationbetween the BSC and the MFS (TS28).

QmuxQmux 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 theheader (the label) of the Message Transfer Part (MTP) level 3 messages iscoded on 4 bits, with values ranging from 0 to 15.

There are no known constraints on SLC values. The value 0 has no particularrelevance when compared to the others. When less than 16 SS7 links are usedin 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 aprivate DTC attribute. In principle, the SLC values are determined by a bilateralagreement and assigned to the peer BSC and MSC management entities usingO&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 alreadyassociated 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 alreadyinstalled configuration. Furthermore, in the case of an MSC which does nothandle SLCs equal to "0", it guarantees that the SS7 which is associatedwith 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 neverhave the same SLC (requirement valid on a per BSS basis). The MSC must beconfigured accordingly when the corresponding SS7 is initialized.

Some MSCs are configured with SLCs starting from "1" (instead of "0"). TheOMC-R has no knowledge of such a restriction, therefore the OMC-R operatoris always allowed to choose "0" as an SLC, and no check is performedconcerning 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 amaximum of "15" SS7s (instead of "16" normally); however, in such a case, themaximum 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


8 Ater Interface

SBL numbering corresponds to DTC numbering which follows A trunknumbering.

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

A9120 BSCConfiguration

SBL SS7/DTC/AterNumber

NAD Atermux

1 020 1

5 024 2

9 030 3

Conf 1

13 034 4

17 120 5Conf 2

21 124 6

25 220 7

29 224 8

33 230 9

Conf 3

37 234 10

41 320 11Conf 4

45 324 12

49 420 13

53 424 14

57 430 15

Conf 5

61 434 16

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 Atermuxof the BSS (A9120 BSC, G2 TC).

CS refers to circuit switched GSM traffic, and PS refers to packet switchedGPRS traffic.


8 Ater Interface

For dedicated GPRS Atermux links, all traffic TS are used for GPRS. SM (TCsite) and associated TRCUs are not equipped. SS7 TS is not used, with orwithout GSL LAPD.

Note that iIn the MFS to BSC direction, on the Atermux supporting the "Alarmoctet" (or TS0 info), the MFS will force a fixed pattern that will be used bythe SM (at the BSC site).

For mixed GPRS/CS Atermux links, the traffic TS can be used 12.5% or25% or 50% or 75% or 100% for GPRS, with or without GSL LAPD. SS7 iscarried (without Atermux 17 and 18).

On the Atermux, channels located within the TS also containing the Qmuxcannot be used for GPRS.

Note: The Atermux channels located on the same Atermux TS as the Qmux cannotbe 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 ofPS 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 dedicatedto 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, theASMC in the TC rack and the TRCU which were not used, remain unused andthe added Atermux is connected to the following ASMC in the TC rack. Thiscan be considered as a hole in the TC rack configuration where an ASMCwill 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:


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 usedfor traffic.

When an MFS shelf is in autonomous synchronization mode, there must be2 "transcoder" links between each GPU and a good synchronization source(which can be a transcoder), or between each GPU and the SGSN if thisoption 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 GPUsassigned as master in 1+1 redundancy mode within a subrack.

MFS must be homogeneous (either all autonomous mode or all central clockmode).

The following tables shows GPU Atermux connection example scenarios.

Scenario X Y Z

1 8 8 0

2 6 6 4

3 8 4 4

With scenario 1, CS traffic goes to the MSC through the TC and PS trafficgoes to SGSN through the TC-MSC.

With scenario 2, CS traffic goes to the MSC through the TC and PS trafficgoes directly to SGSN.

With scenario 3, CS traffic goes to the MSC throughthe TC and PS trafficgoes directly to SGSN.

Atermux X=BSC-GPU Y=TC-GPU

Z=GPU-SGSN

Minimum 1 Y+Z=1

Redundant 2 Y+Z=2

Maximum 6(*) Y+Z=10


8 Ater Interface

* : The maximum (Y+Z=10) corresponds to scenario 2, in this scenario, CS, coming from the mix GSM & GPRS (X), goesto 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. Themaximum number of BSC-GPU links is 13, and the maximum number ofBSC-MFS links depends on the BSC conf (BSC conf 1-4 links, BSC conf 2-6links, BSC conf 3-10 links, BSC conf 4-12 links, BSC conf 5-16 links and BSCconf 6-18 links). It is also possible to have one complete PCM (X) with GPRSand 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 0

7/8 100 1/8 16

3/4 84 1/4 32

1/2 56 1/2 60

1/4 28 3/4 88

Null 0 Full 116

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

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


8 Ater Interface

The use of GSL on a given Ater Mux takes the place of 4GCH nibbles onthis link.

TS 15 is always occupied for N7, even if it is not used.

8.7 Ater Satellite LinksThe Ater interfaces were designed to use terrestrial transmission links.However, in developing countries the terrestrial transmission infrastructure doesnot exist and in many cases is difficult and costly to provide. There is also aneed in the developed world to provide temporary GSM coverage for transientmobile population density increases, for example, at sporting events.

Geostationary earth orbiting satellites are a simple and relatively low costsolution. However, satellite links cannot be used at the same time on both theAter 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), oron 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 supervisiontimer is not useful but is implemented.

In the case where only a part of the TS are routed via the satellite, at leastQmux, 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, orQmux. 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.


8 Ater Interface


9 GB Interface

9 GB Interface

GB Interface describes the GB interface, and corresponding features andfunctions.


9 GB Interface

9.1 Gb TopologyThe interface between the MFS and the SGSN is referred to as the Gbinterface. 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 CSTS 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 goesto 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.


9 GB Interface

Figure 28: Gb Link through the MSC

9.2 Gb ConfigurationBSSGP, Network Service (NS) and physical layer protocols define the Gbinterface. The BSSGP manages GB Interface manages Virtual Connections(BVC) identified by their BCVI.

There are three types of BVC:

BVC-PTPVirtual circuit Point to Point assigned for the GPRS traffic of one cell: BVCI>1

BVC-PTMVirtual circuit Point to Multi-point (not used in the BSS): BVCI=1

BVC-SIGSignaling 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 ITNused 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 isused for signaling on the Bearer Channel BC0.

Network Service Control (NSC) is independent from ITN. The NSC handlesNS-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 perBSS), so that adding a new GPU for a BSS implies the following on the SGSNside 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)


9 GB Interface

The definition and declaration on the SGSN side of the PVCs and NS-VCsof this NSE (NS-VCI are O&M static information).

The Bearer Channel can be minimum 64 Kbit/s TS or a bulk of adjacent 64Kbit/s TS or Maximum 31 of 64 Kbit/s TS of E1 Digital Hierarchy TransmissionNetwork.

The following figure shows the logical context for the Gb Interface.

The secured single Gb allows installing twice less GB links than with the oldrecommended configuration rules, having two PCM-TTP & 2 NS-VC perFR-BC for redundancy. In case of a GB failure on a given GPU board, are-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 ontheir related GPUs.

Figure 29: Gb Logical Context


10 CBC Connection, SMSCB Phase 2+


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



10.1 OverviewThe GSM Short Message Service Cell Broadcast (SMSCB) allows thedistribution of messages from a SMSCB centre (CBC) to MS listening in idlemode to a general broadcast channel called the CBCH.

10.2 GSM Cell Broadcast ApplicationsThere are 2 types of applications for the GSM Cell Broadcast feature:

Applications where the information broadcast relates more or less to MSoperation in the network. This type of application is driven directly by the

network/operator. Applications such as home zone indication, chargingrate indication or Network condition indication, are value added features for

the operator

Applications where the operator offers the Cell Broadcast facility for useby entities external to the GSM Network. Applications such as road traffic

information, public safety, advertisements, etc., can be a source of additionalrevenue 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 CBCmaximum.

10.3.1.1 CBC-BSC Interconnection via PSDNNormally, 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 ifthe communication with the CBC cannot be achieved using the primary link.

The following figure shows CBC-BSC interconnection via PSDN.



Figure 30: CBC-BSC Interconnection via PSDN

10.3.1.2 CBC-BSC Interconnection via MSCFor a private operator who pays a high price for connections, or for exportmarkets where there are no X.25 networks, the following solution may berequired.

It is preferred that the CBC and OMC-R are collocated (connected to the sameMSC). 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 proprietaryor SNMP stacks which prevent an integrated Network Management).

The following figure shows CBC-BSC interconnection via the MSC.



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 CBCfrom the BSC site is no more supported. The connection of CBC is donethrough the X25 over Ater at TC or MSC site. According to 3GPP’s definition,SMS-CB service keeps X.25 connection. So A9130 BSC Evolution keepstransferring X.25 packets to CBC over Ater on TC/MSC site or direct over IPnetwork on A9130 BSC Evolution site. (ML-) PPP or 802.3A/B is used onA9130 BSC Evolution site to carry X.25 packets. No LapB is supported again.


Appendix A : BSS Hardware Capability

Appendix A: BSS Hardware CapabilityThe following table describes BSS hardware compatibility.

B9 Release G1BTSMk IIDRFU

G2BTSDRFU

M4M M5M G3BTS

G4BTS

A9120BSC

G2TC -DT16

G2TC/A9125MT120

FRTCU

DRTCU

No Mux x x x x x x x x x

Static x x x x x x x x

64k Statistical 64/1-2-4 x x x x x x x

16k Statistical x x x x x x

FR x x x x x x x x x x

DR x x x x x x x x x x

Flexible DR x x x x x x x x x

EFR x x x x x x x x x

4:1 Ater Mapping x x x

Multiband BTS x x x x x

Multiband Cell x x x x x

GPRS (CS-1,CS-2) x x x x x x x x x

GPRS (CS-3,CS-4) x x x x x x x

EGPRS(MCS-MCS9) x x x x x

2nd Abis access x x x


Appendix A : BSS Hardware Capability


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 definedfrequencies will be a superset of those frequencies, which can be subsequentlyused.

Cell Allocation information is no longer used since release B6.2. The list ofused frequencies and the BCCH definition will be computed by the BSC frominformation contained in other parameter groups. It is not provided by theBSC during audit.

For a multiband cell, the zone supporting the BCCH and the second zone haveseparate Cell Allocations, each containing obviously either GSM or DCSfrequencies. The Cell Allocation for the second zone is not sent to the BSCand 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 conceptualentity controlled by the BSC, modeling 8 Abis channels mapped onto 8 AirInterface radio TS (TRX_TS). The 8 radio channels are therefore disjointed interms of time, but they can use common frequencies. The channels of a TRXare 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 itcannot 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 sharedcells. 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 meansof 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 TSThe following table provides an overview of the different channel types.



The TRX hopping mode defines whether a TRX uses one or more frequencies:

Non-hopping TRXA TRX that uses the same frequency on every burst on every TS

Hopping TRXA 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 allTRXs 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.



For instance, TS 1, 2, 4, 5, 6, 7 of TRX 1, 2, 3 use the same FHS with themapping 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 radiochannel configuration time. There is no relationship with the physical way inwhich the BTS hops. The operator provides the hopping type explicitly tothe OMC.

Note: Configuration of an extended FHS sequence with more than 16 and up to 64frequencies 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 hoppingtype "Non Hopping".



Base Band Hopping (BBH)If all TRXs of a cell are hopping TRXs and the number of used ARFCNsequals the number of TRXs then the cell has the hopping type "BaseBand Hopping".BBH offers the advantage of hopping on all TS. There are no collisions offrequencies 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 withone frequency.

Radio Hopping (RH)If the BCCH TRX is a hopping TRX and the number of ARFCNs definedfor this cell is higher than the number of equipped CUs/TREs then thecell has the hopping type "Radio hopping". The terminology Free RadioHopping is also used.In this case, hopping is performed over an almost arbitrary number offrequencies. Note that the RH type requires specific hardware on everyTRE. 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 nomore 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 anon-hopping TRX on the BCCH ARFCN, and the number of ARFCNsdefined 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 offrequencies. One disadvantage is that one TRX is NH. In the case ofthe NH/RH hopping mode, interferences can be avoided by a judiciousconfiguration 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 ofview reported during the hardware audit are as follows:

Mono frequencyThe Radio Carrier can generate only one frequency.

RH without on-board BCCH fillerThe Radio Carrier can generate one frequency per TS. The generatedfrequency can differ for every burst.

RH with on-board BCCH fillerThe Radio Carrier can generate one frequency every TS. The generatedfrequency can differ for every burst. If this frequency is not the BCCHfrequency then the Radio Carrier generates (at the same time) a dummyburst on the BCCH frequency. This mechanism ensures the presence of theBCCH 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-RThe accepted configurations are as follows:

BBH



The BCCH TRX TS is configured with either the BCCH ARFCN or theFHS 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 mustnot 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 = numberof TRX)

A mono-frequency FHS, which is a TRX referred to as a pseudonon 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 introduceother non hopping TRX, a mono frequency FHS must be introduced.

All the TS of this TRX are configured with the same mono-frequencyFHS. 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 checkof 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 theARFCN requirements and the TRX channel configuration requirements. Thehopping type defined by the operator. The hopping type is not (yet) transferredto the BSC or to the BTS. The OMC-R must check the consistency between thehopping 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 theBTS, to be checked by the OMC-R.



B.1.5.2 BSCThe BSC uses the hopping type.

The BSC uses the ARFCN/CU mapping in the recovery algorithms.

B.1.5.3 BTSThe BTS must check the consistency between the FU radio configuration(received in CDM) and the actual hopping capability deduced from thehardware 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-RThe OMC-R never produces and never sends an ARFCN/CU mapping,either at the moment of cell creation (very first definition of cell radiochannel configuration), or during any later modification of the radio channelconfiguration. 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 releaseB9 BSS, depending on BTS hopping capabilities and cell hopping types.

No ARFCN list means that no ARFCN list is created. An empty list is sentby OMC-R.

ARFCN list means that the OMC-R creates and sends an ARFCN list whereall ARFCNs are mapped on CU ‘Ffh’, and the boolean RACH_CATCHER foreach ARFCN.



Note: The previous table shows that, depending on the hardware TRE (i.e. monofrequency or no) , the OMC-R, in the case of the hopping type NH, does notapply the same rule.

In the case of a BTS equipped with TRE mono-frequency (BTS G2), the list ofARFCN used in the cell is sent to the BSC.

In the case of a BTS equipped with TRE multi-frequency capable, the list ofARFCN 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 BSCWhen the BSC receives a new cell radio channel configuration from theOMC-R, it "forgets" the previous one (if one existed), including the ARFCN/CUmapping; so at this moment the BSC stores either an ARFCN list (without CUmapping, 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 hoppingtype and the RACH CATCHER boolean to the BTS. The BSC can receive fromthe BTS (in State-Update-Report) an ARFCN/CU mapping and must store it. Itmust consider that all frequencies are in the ‘Available’ state.

B.2.1.6 BTSThe 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 andreturns 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 BTSmust map the remaining ARFCNs on ‘FFh’.

When remapping ARFCNs to CU, the BTS must take care to provoke aminimum of re-tuning; the BTS should compare previous and new mappingand deduce the necessary deltas.

For extended cells, the Evolium BTS is in charge of specific configurationactions related to the BCCH TREs.



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 RequirementsThe Cell Radio Channel Configuration must be in line with the GSM rules andthe capacity/functional constraints of the equipment on which the radio channelsare implemented (frequency range, hopping capability etc.). The requirementsto 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 theconfiguration is sent to the BSC; some of them are also verified by the BSC.

A split is made into "ARFCN requirements" and "TRX Channel Configurationrequirements".

B.3.1 ARFCN requirements

ARFCN requirements NH Type BBH Type RH Type NH/RHType

GSM rules

1. Frequency band definition

Checks related to the frequency range definitionGSM850 (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 tobe performed as described in the note below(Note 3).

x x x x

2. If a Radio configuration is defined for a cell,this defines a BCCH ARFCN and it must beunique in the cell.

Engineering rules

3. ARFCN spacing in a BTS equipment

For a BTS with cavities, the ARFCNs of thissector must be spaced out by three (i.e. 600kHz) to avoid damages through inter-modulation.

Otherwise (no cavities in the BTS), only awarning informs the operator when someARFCNs of this BTS are spaced out by less thanthree (inter-modulation problems can happen)

Note 1 Note 1 Note 1 Note 1

4. ARFCN/CU mapping

The BTS is in charge of the ARFN/CU mapping.

When the mapping is produced, any frequencyused by a TRX must be associated to one singleCU. The CUs associated to the frequencies ofthe cell must belong to the same sector.

x x x x




5. Concentric cells (also obviously fulfilled bymultiband cells)

For concentric cells, each TRX is associatedto one zone (inner or outer zone). A givenfrequency can be used by TRXs belonging all tothe same zone. A frequency cannot be used byTRXs belonging to different zones.

x x x x

Alcatel system restrictions

6. Number of frequencies in the Cell Allocation

At most 64 frequencies can be allocated to agiven Cell Allocation.

Frequency encoding specificity, however, limitthe number of frequencies in the cell to less than64 in certain cases.

in the case of multiband, it is the number offrequencies in the Cell BCCH range (frequencyrange in which the BCCH dwells), which islimited due to this encoding specificity. For theinner zone that is on the non-BCCH range the 64ARFNs limit is applicable.

x

Note 4

x

Note 4

x

Note 4

x

Note 4

7. Scope of FHSs

All frequencies of an FHS must be located in thesame frequency band.

For E-GSM cells, an FHS cannot mix PGSM andG1 frequencies.

For any TRX of an E-GSM cell, all frequencies(ARFN or FHS frequencies) is either PGSM orG1. This makes the TRX a PGSM or a G1 TRX.

x x x

8. Mandatory BCCH frequency in the MAFA list

A non empty list of ARFN values used forextended measurement reporting in RMSdefined for a cell must contain the BCCHfrequency of this cell.

x x x x




9. Number of frequencies in the MAFA list

At most 21 frequencies can be defined inthe list of ARFN values used for extendedmeasurement reporting in RMS (including theBCCH frequency).

Frequency encoding specificity, however, limitthe number of MAFA frequencies in the cell toless than 21 in certain cases.

x

Note 5

x

Note 5

x

Note 5

x

Note 5

10. Check MAFA list ARFCN.

MAFA list ARFCNs does not contain "illegalARFCN", i.e. an ARFCN that does not belong toP-GSM, G1, GSM850, DCS1800 or DCS1900frequency bands. This check is performed atPRC activation.

x x x x

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 thespacing 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 BTShardware families with cavities. For the other BTS hardware families, thespacing 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 BCCHARFCN must preferably be spaced out by at least three from the other ARFCNsused 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 higha limit since "consecutive" ARFCNs in the same FHS is conceivable withoutrisk of inter-modulation when the MAIOs are well chosen. Since the availablefrequencies are rare, it is important to not limit the choice of frequencies forthe 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), thefollowing choice of MAIOs avoids any risk of inter-modulation: MAIO=0 for allTSs 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:



BTS with cavitiesSpacing of three between the ARFCNs of the BTS is required. The OMC-Rdoes not accept "consecutive" ARFCNs in the same BTS (BTS with cavitieshave only one sector).

BTS without cavitiesThe OMC-R checks the ARFCN spacing of three for the ARFCNs of theBTS. However, in contrast to the previous case, this check does not forbid aconfiguration with "consecutive" ARFCNs. Only a warning for the operatorthat inter-modulation problems can appear. The radio configuration is theoperator’s 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 CellTypes (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 compatibilitytable). 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 ofthe global configuration scenario.

In the case of a monoband cell, the BTS (OMU) will check the compliance ofthe frequency range received in the Configuration Data Message (using thesame compatibility table, see below). In case of incompatibility, the BTS willrefuse to configure itself and answers with a Conf-Compl-Failure. The errorcode will be forwarded in an alarm issued by the BSC.

The following table describes compatibility.

Cell Frequency Range

Actual Frequency Range

HW capability of a Sector

P-GSM E-GSM

(A9100BTS)

GSM

850

DCS

1800

DCS

1900

PGSM

-DCS

EGSM-

DCS

(A9100BTS)

P-GSM OK ***) NOK NOK NOK OK/NOK

(*)

OK/NOK

(*)

E_GSM (A9100 BTS) OK OK NOK NOK NOK OK/NOK

(*)

OK/NOK

(*)

GSM850 NOK NOK OK NOK NOK NOK NOK

DCS1800 NOK NOK NOK OK NOK OK/NOK

(*)

OK/NOK

(*)

DCS1900 NOK NOK NOK NOK OK NOK NOK



Cell Frequency Range

Actual Frequency Range

HW capability of a Sector

P-GSM E-GSM

(A9100BTS)

GSM

850

DCS

1800

DCS

1900

PGSM

-DCS

EGSM-

DCS

(A9100BTS)

Multiband (PGSM-DCS) (**) (**)

(***)

NOK (**) NOK OK OK

(***)

Multiband (EGSM-DCS) (A9100BTS)

(**) (**) 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 ofTRE of other band on the BTS).

** : A BTS Evolium equipped for multiband can support a monoband cell with induced capacity loss. A BTS Evoliumequipped for monoband can also support a multiband cell, with obvious restrictions, even if the TREs of its innerzone are not equipped. For G2 BTS, these special cases are not allowed in the cell and the HW capacity ofthe 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 thefollowing system information messages:

System Information Type 1 message on BCCH

Packet System Information Type 2 message (if a PBCCH is present in theserving cell).

The Cell Allocation must not necessarily contain all the frequencies usedin the cell.

Therefore, the Cell Allocation must contain at least all the frequencies involvedin a frequency hopping law on the SDCCH (static and dynamic) and on thepotential hopping GPRS TS defined in the cell. Note that the CBCH is always asub-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 Allocationregroups all the frequencies (hopping or non-hopping frequencies) involved in anon-concentric cell or in a monoband concentric cell or in the outer zone of amultiband 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, theBCCH frequency is included in the Cell Allocation.

Indeed, as developed hereafter, only in the case of RH/NH, the BCCHfrequency is not included in a hopping sequence:

Case NH: As there is no frequency hopping, the BCCH frequency isincluded 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 fromthe calculation of the frequency span.



Case BBH: the BCCH frequency is always a hopping frequency, so theBCCH frequency is included in the Cell Allocation.

The number of frequencies usable in the Cell Allocation is limited by thefollowing factors:

CBCH hopping or non hopping. in the case CBCH Hopping, GPRS orSOLSA 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 frequenciesin 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 aCell Allocation (GPRS and of SoLSA)

If the CBCH is not configured or configured as non hopping, then the limitationon the maximum number of frequencies is defined by the rules concerningthe frequency span which follows:



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

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

For PGSM-DCS and EGSM-DCS multiband cells, the frequencies defined inthe inner zone are used for TCHs only. For the inner zone, the total number offrequencies is limited to 64.

Note 5: check related to the number of frequencies in the list of ARFN valuesused for extended measurement reporting in RMS.

The number of extended measurement frequencies is limited by the encoding ofthe Extended Measurement Order message and of the Extended MeasurementReport 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 maximumnumber depends on the frequency span, whether or not all the frequencies

belong to the P-GSM frequency band and whether or not the ARFCN 0is included in the list of extended measurement frequencies. As there is

no restriction on the frequency band in which the extended measurementfrequencies 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 orderedin the ascending order f0 to fn

Calculation ofd1=f1-f0-1...dn=fn-f(n-1)-1d0=f0-fn + 1023



S=1024-max(dk)

Limitations on the encoding of the Extended Measurement Report messageThe 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 extendedmeasurement 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 ExtendedMeasurement 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 acceptedby the system:

1-The hopping type is NH.

All defined TRXs are non-hopping and fulfil theGSM rules, the NH engineering rules, and theNH Alcatel restrictions.

x

2- The hopping type is BBH (Base BandHopping).

One mandatory group of TRXs ensuringthe BCCH carrier plus possibly a group ofoptional TRXs fulfilling the GSM rules, theBBH engineering rules and the BBH Alcatelrestrictions. Juxtaposition of NH TRX (i.e. NHTRX mixed with BBH TRX) is not permitted.Juxtaposition of pseudo non hopping TRX arepermitted.

x

3- The hopping type is RH.

One TRX fulfilling the GSM rules, the RHengineering rules, and the RH Alcatelrestrictions. No more supported.

x




4- The hopping type is NH/RH.

One NH TRX at the BCCH ARFCN, and a setof RH TRX fulfilling the GSM rules, the NH/RHengineering rules, and the NH/RH Alcatelrestrictions.

x

GSM rules

2. BCCH channel / BCCH carrier

BCCH channel carrying the BCCH informationis always on TS0 without hopping. The BCCHARFCN has to be continuously transmitted (onthe eight TSs) on the air.

x x x x

3. static SDCCH/CBCH localisation

If an static SDCCH/CBCH combination is usedon a given TS, that TS must be of rank 0 to 3.

x x x x

Engineering rules

4. Prevention against the use of the samefrequency

All TRX-TSs (belonging to TRXs of the samecell) of the same rank (0...7) must never usethe same frequency simultaneously.

When hopping, the TRX-TS must use for thatreason either the same FHS (with distinctMAIOs), or distinct FHSs that do not share anyfrequency

x x x x

5. Channel usage

The channel usage of any TRX-TS can beequal to :

- An ARFCN if the TRX-TS does not hop

- The couple (FHS identity, MAIO) otherwise(hopping)

x x x x

6. MAIO

TRX-TSs of the same rank and using the sameFHS must have each a different MAIO:

0 <= MAIO <= number of frequencies in theFHS minus 1 <= 63

in the case of pseudo non hopping TRX, MAIO= 0

x x x

7 NH type

All TRX-TSs of a non-hopping TRX must usethe same frequency

x x x




8. BBH type (Base Band hopping)

The number of frequencies of each FHS mustbe equal to the number of TRXs, which usethis FHS.

The channel usage of the TRX-TSs from themandatory group of TRX ensuring the BCCHcarrier must be equal to one of the followingvalues:

- BCCH FHS + MAIO

- Reduced FHS + MAIO

- BCCH ARFCN

The BCCH FHS owns the BCCH ARFCN, andremoving the BCCH ARFCN from the BCCHFHS produces the reduced FHS. They are bothmandatory.

The channel usage of the TRX-TSs of thegroup of optional TRXs must be equal to oneoptional FHS + MAIO. The optional FHSs mustnot contain the BCCH ARFCN.

One must notice that additional Alcatelrestrictions are associated to the BBH type.

x

9. RH type

Only one single TRX in RH: the channel usageof the TS0 is the BCCH ARFCN, whereas it isequal to one RH FHS + MAIO for the TS of rank1 to 7. There are up to seven RH FHSs (oneper TS of rank 1 to 7).

This configuration is not supported anymore.

The number of frequencies used in any RHFHS is arbitrary. The RH FHSs can use theBCCH ARFCN.

x

10. NH/RH type

One NH TRX, and a set of RH TRXs andpossibly pseudo NH TRX. The channel usageof each TRX-TS of the NH TRX is the BCCHARFCN, whereas it is equal to one RH FHS +MAIO for the RH TRXs.

The number of frequencies used in any RHFHS is arbitrary. The RH FHSs must notcontain the BCCH ARFCN.

x




11. Concentric cells and multiband cells

For concentric (monoband and multiband)cells, the inner zone can only be allocated TCHChannels.

As a consequence, these cell types are notcompatible with a sector of a BTS using 16kstatistical multiplexing: indeed, this multiplexingrule requires that the TS0 of all non BCCHTRXs be allocated SDCCH channels (static anddynamic) (refer to rule 18), which is impossiblefor the inner zone of concentric cells.

FHSs are not allowed to overlap between innerand outer zones of concentric cells.

Each TRX must be assigned to a zone: inneror outer.

In the case of a multiband cell, the TRXs withina zone must either all use GSM frequencies(P-GSM or E-GSM) or all use DCS 1800frequencies.

x x x x

12. Extended cells

For Evolium BTS, several TRXs are allowedon extended cellsOnly non hopping radioconfiguration is allowed for extended inner/outercells.

Due to uplink co-channel interference of outercell timeslot 7 and inner cell timeslot 0 (on outercell BCCH ARFCN), the OMC_R must forceIDLE the channel type of TRX-TS 7 of the outercell BCCH TRX and force its frequency usageto the BCCH of the outer cell. If the operatorchanges the channel type (or the Frequencyusage) of the TRX_TS 7 to another value, theOMC_R has to reject the configuration.

The CCCH/SDCCH (static) configuration(combined / non combined) must be identicalfor the inner and outer extended cell (EvoliumBTS only); in other words, the channelconfiguration must be the same for the TS 0 ofBCCH TRX for the inner and the outer cell.

On the other hand, the operator is stronglyrecommended to bar the Inner Cell; note thatthis is mandatory for BTS Evolium but cannotbe verified by the OMC.

x

Alcatel system restrictions




15. BBH type: localization of non-hoppingTRX-TS

Only the BCCH TRX can own non-hoppingTRX-TSs at the BCCH ARFCN.

As a consequence, if a TRX-TS of the BCCHTRX is non-hopping, then all TRX-TSs of thesame rank belonging to the group of TRXensuring the BCCH carrier (except the BCCHTRX) must use the reduced FHS.

x

16. BBH type: recovery algorithmssimplification

All TRX-TSs of a given TRX that use the sameFHS must have the same MAIO.

If the BCCH TRX hops, TRX-TSs of rank 1...7must have the lowest MAIO (=0)

x

17. Recovery: gathering of the vital resourceson one TRX

The BCCH TRX must carry a set of staticSDCCH sub-channels.

The CBCH, if it exists, must be configured onthe TRX which carries the BCCH.

The CBCH can be configured on the BCCH TSor on a static SDCCH TS (if any), but it mustbe unique for the cell.

x x x x

18. Dynamic and static SDCCH localization

The SDCCH, static or dynamic, can beconfigured on any time slot of the TRX butin the case of use of 16kbit/s statisticalmultiplexing, TS0 of each TRX must beconfigured with the BCCH or with staticSDCCH, but not with a TCH nor with adynamic SDCCH (the BSC will not accept thisconfiguration). Refer to rule 11.

x x x x




19 Checks related to GPRS

The mandatory rules to check are defined inthe "BSS Telecom Parameters" document for

EN-GPRS

TRX_Pref_Mark

MAX_PDCH

The check of limitation to 1 MA for PDCHgroups:

For the TRXs with TRX pref mark = 0, the TimeSlots selected (the BSC) to carry data musthave the same MA (1). The TSs must also beTCH TSs.

Pseudo MA (FHS mono frequency) are nottaken 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 BBHcell:

If Nb_TS_MPDCH<>0 and if the BCCH TRXdoes not support GPRS (TPM<>0)

ThenThe GPRS MA for the cell is the MA of theBCCH TRX PDCH group.

x x x x

20. TRE/TRX limitations x x x x

21. G1 frequencies limitations

Only TCH channels are acceptable on a G1TRX .

GPRS is not supported by TRX carrying atleast one frequency of the G1 band.

x x x x

22. Cell shared by 2 BTSs:

The BCCH TRX must be a main TRX

If the hopping type is ‘BBH, the FHS cannot beacross the two sectors.

x x x x

23. Check the maximum number of SDCCHper cell.

The number of configured static and dynamicSDCCH for a cell must not exceed themaximum of 88. If the limit is exceeded, anerror is sent to the operator who has to changethe static or dynamic SDCCH configuration forthe cell.

The OMC ensures the check at activation.

x x x x




24. Check the maximum number of SDCCHper TRX

The number of configured SDCCH (staticand dynamic) for a TRX must not exceed themaximum of 24 SDCCHs (static and dynamic).

If the limit is exceeded, an error is sent tothe operator who has to change the SDCCHconfiguration (static and dynamic) for the TRX.

The OMC ensures the check at PRC activation.

x x x x

25. Check BTS HW

Dynamic SDCCH TS is configured only on acell mapped on an Evolium BTS.

x x x x

26. Check HSDS activation

CS3/CS4 coding schemes must not beconfigured on a G2 BTS.

EN_Egprs must not be enabled on a G2 BTS.

x x x x

Customer Recommendations NH Type BBH Type RH Type NH/RHType

1. Recovery: preservation of SDCCH (static anddynamic) sub-channels

Hopping SDCCH (static or dynamic) is preferablyconfigured on the TRX with the lowest MAIO.

x

2. Check compatibility of signaling load and 16 k muxrule on A-bis

(The rules 2 to 5 are to be verified by activation ofthe ‘Check load impacts’)

A warning "Risk of RSL congestion with Abis16k statistical or static multiplexing" is sent to theoperator, on a per cell basis, if the Multiplexing rulefor the sector is 16k static or 16k statistical while anyof the following checks is true:

The number of SDCCH (static and dynamic) onat least one TRX (of a cell with more than one

TRX) is larger than 8.

For a 1 TRX cell, the number of SDCCHs (staticand dynamic) is larger than 12 .

The total number of SDCCHs (static and dynamic)

for the cell is larger than 24.

x x x x




3. Check the number of SDCCHs per cell

A warning "Too many SDCCHs, risk of RSLcongestion" is sent to the operator if the Multiplexingrule for the sector is 64k while the following checksis true:

the number of SDCCHs (static and dynamic) in thecell is larger than 8*Nb_TRX + 8*Nb_DR_TRE (*)

x x x x




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

A warning "Too many SDCCHs (static and dynamic),risk of CCCH congestion" is sent to the operator ifany 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 ofSDCCHs (static and dynamic) is larger than 64.

x x x x

5. Check to avoid configurations for which RSLreshuffling will fail

A warning "Risk of processor overload (MCBspossibly already overloaded)" is sent to the operatorif 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" whilethe BCCH TRX of the cell supports more than

12 SDCCH (static and dynamic) (resulting insaturated 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 ona TRX is never justified and is likely to create an

overloaded MCB).

It is always recommended to use a ‘High’ signalingload whenever there are enough TS on the Abisto support it; smaller MCBs will facilitate the RSLreshuffling at no extra cost.

x x x x

* : The OMC is not able to check the number of SDCCHs per Multiplexed Channel Block (MCB); this rule only verifies thatthe overall number of SDCCHs (static and dynamic) is limited to 8 per TRX (declared in the cell) plus 8 additional perDual Rate TRE (declared in the BTS). This restriction helps in preventing TCU overload situations even if the effectivenumber 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 morethan 4 TRXs, as this prevents the case of MCBs with more than one BCCH. Of course, this solution is acceptableonly if it is affordable in terms of Abis Time Slots. This rule could be by passed for small cells (in order to avoid



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

In case of violation of these rules, when the operator attempts to apply theconfiguration, 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 mustinform the operator. The configuration is sent to the BSC.

Otherwise, the OMC-R rejects the corresponding configuration, in allother 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 correspondingBTS-O&M.



BLANK PAGE BREAK


Documents

B9 BSS Configuration Rules ed30.pdf