a9130 bsc evolution functional description

Alcatel BSS

A9130 BSC Evolution

Functional Description

BSC & TC Document

Sub-System Description

Release B9

3BK 20982 AAAA TQZZA Ed.01

Status RELEASED

Short title A9130 BSC FD

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 / 66 3BK 20982 AAAA TQZZA Ed.01

Contents

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1 A9130 BSC Overall Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1 A9130 BSC Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2 A9130 BSC Hardware Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3 Rack Shared Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.3.1 Rack Shared by A9130 BSC Evolution - A9130 MFS Evolution . . . . . . . . . . . . . 141.3.2 Rack Shared by Two A9130 BSCs Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.4 A9130 BSC Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.4.1 BSC Software Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.4.2 Process Mapping on OMCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.4.3 Process Mapping on CCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.4.4 Process Mapping on TPGSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.4.5 A9130 BSC Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.4.6 ATCA Platform Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.4.7 A9130 BSC Application Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.4.8 A9130 BSC Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.5 Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2 A9130 BSC Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.1 A9130 BSC Application Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.1.1 A9130 BSC Application Process Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.1.2 VOS Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.1.3 FMM Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.2 A9130 BSC External Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3 A9130 BSC CS Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.4 A9130 BSC PS Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.5 A9130 BSC Performance Management Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.6 A9130 BSC SMS-CB Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.7 A9130 BSC SS7 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.8 A9130 BSC LAPD Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.9 A9130 BSC Qmux Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.10 A9130 BSC ML-PPP Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.11 A9130 BSC Transmission Function Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.11.1 NE1oE Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.11.2 Remote Tributary Alarm Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462.11.3 Ring Control in A9130 BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.12 A9130 BSC Logical Configuration Management Functional Description . . . . . . . . . . . . . . . . . 482.13 A9130 BSC Hardware Configuration Management Functional Description . . . . . . . . . . . . . . . 492.14 A9130 BSC Software Management Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.14.1 BSS SW Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512.14.2 SWMGT Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.15 A9130 BSC Fault Management Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3 Managed Objects and SBLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.1 Existing A9120 BSC SBL Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.2 Replace TCU/DTC/CPR/TSC Processors by CCP Processors . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.2.1 Maintenance Management View and Impacts on SBL Definition . . . . . . . . . . . . 573.2.2 Network Defence (CCP Redundancy) View and Impacts on SBL Definition . . 593.2.3 New SBL Hierarchy for Controlling Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.3 Replace DSN Network by a Local Ethernet Gbit Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.4 Replace BIUA/ASMB by TPGSM Switching Processors and E1 Termination Shelf . . . . . . . 64

3.4.1 Maintenance Management View and Impacts on SBL Definition . . . . . . . . . . . . 643.4.2 Network Defence (TPGSM Redundancy) View and Impacts on SBL Definition 643.4.3 New SBL Hierarchy for Transmission Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.5 Other Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3BK 20982 AAAA TQZZA Ed.01 3 / 66

Contents

3.6 SBL Hierarchy Change Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4 / 66 3BK 20982 AAAA TQZZA Ed.01

Figures

FiguresFigure 1: The A9130 BSC in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Figure 2: A9130 BSC HW Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 3: General Software Architecture of the ATCA PF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Figure 4: Process Mapping on the OMCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Figure 5: Process Mapping on the CCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Figure 6: Process Mapping on TPGSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Figure 7: A9130 BSC Connection with OMC-R (Direct IP Connection) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Figure 8: A9130 BSC Connection with OMC-R (IP over Ater) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Figure 9: A9130 BSC Connection with CBC (Direct IP Connection) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Figure 10: A9130 BSC Connection with CBC (IP over Ater) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Figure 11: A9130 BSC External Communication Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Figure 12: Telecom Modules and Corresponding Information Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Figure 13: GPRS Telecom Modules and Corresponding Information Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Figure 14: PM Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Figure 15: SMS-CB Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Figure 16: A9130 BSC SS7 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Figure 17: LAPD Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Figure 18: Qmux Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Figure 19: ML-PPP Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Figure 20: BSS Transmission Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Figure 21: A9130 BSC Transmission Module with SBL Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Figure 22: NE1oE Traffic Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Figure 23: Alarm Handling on the A Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Figure 24: Abis Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Figure 25: Logical Parameter Configuration Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Figure 26: HCM Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Figure 27: BSS SW Package File Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Figure 28: SWMGT Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Figure 29: FM Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Figure 30: SBL Hierarchy Change Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3BK 20982 AAAA TQZZA Ed.01 5 / 66

Figures

6 / 66 3BK 20982 AAAA TQZZA Ed.01

Preface

Preface

Purpose This document provides an overview of the A9130 Base Station Controller(BSC).

The A9130 BSC Evolution is the controlling part of the BSS. The A9130BSC Evolution also performs functions associated with the General PacketRadio Service (GPRS).

The information provided is applicable in release B9 of the Alcatel BSS.

What’s New In Edition 01First official release of the document.

Audience This document is intended for:

Commissioning personnel

System support engineers

Operating personnel

Training personnel.

Assumed Knowledge The reader must have a general knowledge of telecommunication systems,terminology and GSM functions.

3BK 20982 AAAA TQZZA Ed.01 7 / 66

Preface

8 / 66 3BK 20982 AAAA TQZZA Ed.01

1 A9130 BSC Overall Description


This section provides an overview of the A9130 Base Station Controller.

3BK 20982 AAAA TQZZA Ed.01 9 / 66


1.1 A9130 BSC OverviewThe A9130 BSC performs the following functions:

It provides GSM facilities for circuit switched mobile traffic and GPRS

facilities to allow the transfer of data in packets

It manages the radio resources and radio parametersThe BSC shares resources between circuit switched and packet switchedtraffic, according to configuration parameters.It shields the MSC and the MFS from the radio information, and performsswitching between the radio Traffic Channels (TCHs) and the terrestrialchannels, to the MSC and the MFS.

It manages transmission equipment by performing fault managementand correlation.From a transmission point of view, the A9130 BSC also performs aconcentration function, therefore allowing more radio TCHs to be connectedto the A9130 BSC than terrestrial channels to the MSC.

The following figure provides an overview of the A9130 BSC in the BSS.

Ater MuxInterface

BSC Site MSC Site

BSS

Abis Interface

A Interface

BSS/OMC−R Interface

BSS/CBC Interface

Gb Interface Optional Link

Optional Link

BTS

BSC

BSC Terminal

MFS

SGSN

OMC−R

TC MSC

CBC

BTS

TM Terminal

SAGI

A−GPS server

BTS : Base Transceiver Station

CBC : Cell Broadcast Center

OMC-R : Operations and Maintenance Center-Radio

SGSN : Serving General Packet Radio Service Support Node

TM : Transmission

A-GPS : Assisted GPS

SAGI : SMLC A-GPS Interface

BSS : Base Station Subsystem

MSC : Mobile Switching Center

MFS : Multi Function Server

TC : Transcoder

Figure 1: The A9130 BSC in the BSS

10 / 66 3BK 20982 AAAA TQZZA Ed.01


The A9130 BSC performs the following telecommunication, transmissionand O&M functions:

Provides signaling links to the MSC

Performs signaling control for the BTS and the Mobile Stations (MS)

Performs signaling control for the MFS links

Switches traffic between the MSC and the BTS

Routes traffic between the MFS and the BTS

Provides O&M facilities.

1.2 A9130 BSC Hardware ArchitectureThe following figure shows the BSC Hardware (HW) architecture on an ATCAplatform.

SSW

(duplicated)

Rad

io N

etw

ork

links

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

r : Redundancy

W : Working

N and y : Network Element capacity

Figure 2: A9130 BSC HW Architecture

3BK 20982 AAAA TQZZA Ed.01 11 / 66


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

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 blocking

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

12 / 66 3BK 20982 AAAA TQZZA Ed.01



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

3BK 20982 AAAA TQZZA Ed.01 13 / 66



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.

Note: Compared to previous generation BSC, the ATCA PF does not provide X.21interfaces. An X25 over IP link is used for CBC.

1.3 Rack Shared ConfigurationsRack shared configuration for A9130 MFSEvolution and A9130 BSC Evolutionconsists of:

1 x BSC configuration and 1 x MFS configuration in the same cabinet

2 x independent BSC configurations in the same cabinet.

In both cases:

Each equipment is considered as independent (choice of each configuration

free in the limit of 1 x ATCA shelf per configuration)

In case of BSC and MFS, they are not considered as a stand alone node,and MFS NE can be used by the rack shared BSC, but also by other nearby

BSCs (A9130 BSC Evolution or A9120 BSC). (MFS NE is not fully or onlydedicated to BSC traffic located in the same rack).

1.3.1 Rack Shared by A9130 BSC Evolution - A9130 MFS Evolution

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

14 / 66 3BK 20982 AAAA TQZZA Ed.01


Equipment BSC capacity MFS capacity

SSW 2 2

LIU Shelf 1 1

MUX 2 2

LIU 8 16 8

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

1.3.2 Rack Shared by Two A9130 BSCs Evolution

Board configurations in each ATCA and LIU shelf are identical to single BSC.

1.4 A9130 BSC Software Architecture

1.4.1 BSC Software Architecture Overview

Developed in accordance with the new hardware platform and based onthe Linux operating system, the A9130 BSC’s Evolution new software (SW)architecture uses the best of existing A9120 BSC technology and specific newfeatures to provide common platform services for all radio control platforms.

The main characteristics of A9130 BSC SW are the following:

The user plane and the control plane are redundant

Transmission and processing are split

The application process communication is based on redundant TCP/IP

Processing and transmission are centralized.

3BK 20982 AAAA TQZZA Ed.01 15 / 66


The following figure shows the basic software architecture for an ATCA PF.

MX

Platform

GPRS NE

O&M +

Telecom applications

BSC

High Availibility Middleware

MXPF Software

( include Endur X +

GoAhead Self reliant)

AdvancedTCA (PICMG 3.x)

MFS

TOMAS

Middleware

& drivers

or

pSOSystem

Carrier Grade LINUX

Equipt

Manager

Figure 3: General Software Architecture of the ATCA PF

The following table describes the general software architecture of the ATCA PF.

Functional block of SW Function for BSC Function for MFS

Carrier Grade Linux Operating system

pSOSystem Operating system

Endur X System resources managementand services via APIs for telecomapplication (OMCP, CCP andTPGSM)

TOMAS System resources managementand services via APIs for telecomapplication (OMCP)

GPRS Network Element Communication, telecomequipment supervision, alarmcollection

Table 1: General Software Architecture of the ATCA PF

16 / 66 3BK 20982 AAAA TQZZA Ed.01


The following figure shows the A9130 BSC SW as seen by the processes.

CMW

CPI

VCE

VCE

VCE

VCE

VCE

VCE

SFT−mgt

VCE

HM −mgt

GSUP

CMW

VCE

VCE

VCE

VCE

SRL CPI

SRL

SUP

SUP

CMW

SLH

−TP HDLC

TDM

TP−Main

CPI

SRL

SUP

SUP

Platform Internal Message

CMWmessage

CMW message

?

?

?

?

?

?

TCP/IP

TCP/IP

The process is the basic software element in the A9130 BSC. The processcan be an A9130 BSC application process or a general platform serviceprocess, as shown in the above figure.

The A9130 BSC application process focuses on GSM BSC functional

features. The process simulates a A9120 BSC CE function or a newfunction for BSC usage

The A9130 BSC platform service process is a general service for the

radio controller

Both kinds of process run on the Linux operating system.

In the A9130 BSC, internal communication among processes is based on theTCP/IP service from Linux. For platform services, the process uses TCPmessages or communication mechanisms provided by SelfReliant. For theA9130 BSC, the application process handles message routing.

The CPI process converts the application message format to a platform servicemessage format for communication between the A9130 BSC applicationprocesses and the ATCA platform services.

The different communication processes used in the A9130 BSC are as follows:

For application process to application process, CMW is used

For application process to platform service process, CPI is used by platform

services and CMW is used by application processes. CPI is considered byCMW to be one application process

3BK 20982 AAAA TQZZA Ed.01 17 / 66


1.4.2 Process Mapping on OMCP

The following figure shows process mapping on the OMCP.

Platform service

Interthreads Communication Bus

NE1oE

Agent SRR/PRMS/H

PI

HW

Init/SW GSUP/SUP

FTP server

CPI

CMW

V−SCPR

V−OCPR

CMW TCH −RM TCH −RM

V−DTC(TCH −RM)

TSC TSC TSC v−TSC

EIM −L

OMCP

EIM −R

Figure 4: Process Mapping on the OMCP

The OMCP board manages O&M functions for both platform and applicationprocesses. Depending on specific BSC application requirements, otherprocesses are also mapped on OMCP board.

The V-SCPR, the V-OCPR and the V-TSC are the major O&M processesfrom A9130 BSC application. These three processes cover all A9130 BSCapplication O&M.

The V-DTC (TCH-RM function) is the telecom function process which managesthe radio resources of BSS. The V-DTC (TCH-RM) on the OMCP uses the 1 +1 redundancy of the OMCP to provide the same function as in the A9120 BSC.

The CMW, the EIM-L and the EIM-R are specific application processesdeveloped for the A9130:

The EIM-L/EIM-R are used by the A9130 BSC application to communicatewith the A9130 BSC terminal and the OMC-R/CBC

The CMW is the common service for application process communication. It

is employed in every processing board.

The CPI, the NE1oE Agent, the HW management, the GSUP/SUP, the Init/SWand the FTP server are platform service processes. All of these services areused for O&M management of the ATCA platform. The service covers A9130HW management, ATCA platform process management, ATCA platform SWmanagement, ATCA platform installation and initialization, and NE1oE trafficO&M management.

1.4.3 Process Mapping on CCP

The following figure shows process mapping on the CCP.

18 / 66 3BK 20982 AAAA TQZZA Ed.01


Platform service

Interthreads Communication Bus

Init/SW SUP

CPI

TCU

TCU

TCU

V−TCU

TCU

V−TCU

V−TCU

V−TCU

DTC

DTC

DTC

DTC

DTC

DTC

DTC

DTC

V−DTC

CMW

CCP

Figure 5: Process Mapping on the CCP

The CCP board handles A9130 BSC telecom functions. Compared to theA9120 BSC, which is a distributed system in that telecom functions aredistributed on the DTC/TCU board, the A9130 BSC centralizes telecomfunctions by mixing more V-TCU/V-DTC processes in the CCP boards. In theCCP board, the V-TCU handles the signalling messages of the Abis interface.The V-DTC handles the A interface messages and A-Trunk management.

The CCP is an FRU, and is passively managed by platform services in theOMCP, so less platform services run on this board. Only the SUP for processmanagement and Init&SW for software loading are mapped on this board.

The CMW/CPI are the common functions used for communication on everyboard.

3BK 20982 AAAA TQZZA Ed.01 19 / 66


1.4.4 Process Mapping on TPGSM

The following figure shows process mapping on the TPGSM.

Platform service

Interthread comm. bus

Init/SW SUP

CPI

TP−SS7

CMW

TP−Main

Interthread comm. bus

Configuration Handler

Fault Manag

er Handler

HDLC LAPD Handler

Perf. Param. Handler

R/W Bits Alarm Octet

Handler

HDLC MLPPP

Handler

QMUX Handler

TDM Handler Matrix Framer

s Synchr

o

Figure 6: Process Mapping on TPGSM

The TPGSM is the centralized board which handles the lower layer of theGSM signalling protocol and switching in the A9130 BSC. By definition, 4main processes run on this board.

The TP-Main is a high level centralized process in the A9130 BSC. It coversthe HDLC, the Qmux, R/W bit handling, ML-PPP switching and the O&Mfunctions that support these services.

The TP-SS7 is a dedicated process in the TPGSM for the SS7 protocol.According to the definition of the SS7 architecture in the A9130 BSC, thisprocess is responsible for an MTP3 layer function, signalling link handling (SLH).

The CMW /CPI provides the common function as the other CCP/OMCP board.

20 / 66 3BK 20982 AAAA TQZZA Ed.01


1.4.5 A9130 BSC Operating System

MontaVista Linux is the A9130 BSC operating system. This product is theCommercial-Off-The-Shelf (COTS) industry standard. The Carrier Grade Linuxplatform provides specific telecom and datacom functions and provides highavailability, hardening and real-time performance.

The version used in the ATCA platform is MontaVista Linux Carrier GradeEdition 3.1. This version supports the following Carrier Grade Class applicationrequirements:

The Carrier Grade Linux-based Operating System and complete

development environment enables faster time-to market and lowerdevelopment costs

It is designed for high availability, with support for persistent device namingand hot swap insertion and removal capabilities

It is a preemptive kernel and O(1) real-time scheduler for low latency

real-time performance in native Linux

It is a comprehensive standards support, including the OSDL Carrier GradeLinux Specification 1.1, the IPv6, the POSIX, the PICMG 2.16 and the

AdvancedTCA (PICMG 3.0)

Its robust networking enhances high-performance telecommunications

applications

The MontaVista Field Safe Application Debugger and the MontaVistaRuntime Application Patcher provide improved maintainability

Offers an ecosystem of compatible COTS third-party middleware, hardware

and applications eases development of system solutions

Extensive development and carrier-class analysis tools reduce project risk.

1.4.6 ATCA Platform Services

Platform services are designed based on the ATCA platform and the LinuxOperating system. They control the common services required for the radiocontroller system. The services covered by platform are platform softwareinstallation and initialization, platform software migration, platform HWmanagement, platform process management and the platform internal networkcommunication service.

The platform communication service realizes the information exchange in anA9130 occupied network, by providing:

File transfers between the A9130 BSC and the OMC-R

File transfers between different boards inside the A9130 BSC

In the A9130 BSC, they configure an internal IP network for internal/external

uses, plane/control, and plane information exchange.

3BK 20982 AAAA TQZZA Ed.01 21 / 66


The communication services used to do so are:

FTP services

The IP assignment for the A9130 BSC

The VLAN configuration for the A9130 BSC

A communication interface between the A9130 BSC platform servicesand the A9130 BSC application.

1.4.7 A9130 BSC Application Overview

The A9130 BSC application communicates with the GSM radio controller, toprovide both O&M and telecom functions for the BSC.

The application software has been designed to take into account the platformarchitecture and A9120 BSC software features.

In the A9130 BSC application, there are two types of process:

The Virtual Operating System (VOS) based application processThe VOS simulates the OSND function of the A9120 BSC. It is integratedinto a Linux process and simulates one A9120 BSC CE. This process iscalled Virtual control Element (VCE). Compared to the A9120 BSC, most ofthe CE are simulated by the VCE.

As SCPR is simulated by a V-SCPR process:

OCPR is simulated by the V-OCPR

TSC is simulated by the V-TSC

TCU is simulated by the V-TCU

DTC is simulated by the V-DTC.

The VCE is composed of common VCE functions and variant FMM functions.

The common VCE functions include:

The VOS larboard

The VbootTrap

The DBCS (optional)

The TraceDebug (optional)

The FMM InitVariant FMM functions include the different FMM modules, depending onthe application function performed by the VCE.

The Normal Linux processThis is the normal Linux process, without A9120 BSC functions. In theA9130 BSC, this kind of process is used for the functions introduced by theATCA platform, including CMW, EIM-R, EIM-L, TP-Main, and TP-SS7.

Note: The OSND is the Real Operating System (ROS) used in A9120 BSC CEs.

22 / 66 3BK 20982 AAAA TQZZA Ed.01


1.4.8 A9130 BSC Process Overview

1.4.8.1 V-SCPR ProcessThe V-SCPR is the application process which simulates the A9120 BSC S-CPRfunction. The V-SCPR process running on the OMCP is the hot backup inboth OMCPs.

The V-SCPR is the centralized O&M process in the A9130 BSC. As an externalprocess, it interfaces directly with the OMC-R and with the A9130 BSC Terminalfor O&M management. Internally, it manages the modification of the DLS,basing changes on O&M issues, and triggers modules in other VCEs to verifythe changes to the BSC data base.

The V-SCPR provides the following functions:

Hardware Configuration and Massive Configuration Management (MCM) of

the BSC

Central TRX management

Central BTS management

A9130 BSC central maintenance

The A9130 BSC Central Alarm

TSC management

Central Performance Management (CPM)

The N7 MTP3 SLNM/SM and SCCP_SCMG

The A9130 BSC Application Software Replacement.

1.4.8.2 V-OCPR ProcessThe V-OCPR is the application process which simulates the A9120 BSCO-CPR function. In the A9130 BSC, the V-OCPR is the termination of externalO&M traffic on BSC side. The V-OCPR runs in the OMCP, and is the hotbackup on both OMCP.

The functions supported in V-OCPR are:

Logical Configuration Management (LCM)

SMS-CB management

External communication management.

1.4.8.3 V-TCU ProcessThe V-TCU is the application process which simulates the A9120 BSC TCUfunction. The V-TCU runs on the CCP board. In the A9130 BSC, the V-TCU isthe functional unit which handles the layer 3 functions on the Abis interface.

The functions supported in TCU are:

Telecom management on the Abis Interface l3

LAPD L2 Function

CS/PS switch management.

3BK 20982 AAAA TQZZA Ed.01 23 / 66


1.4.8.4 V-DTC ProcessThe V-DTC is the application process which simulates the DTC function of theA9120 BSC. It runs on the CCP board.

In the A9130 BSC, the V-DTC is the functional unit which handles the Ainterface. Each V-DTC acts as one A-Trunk handler on the BSS side. Inaddition, a particular V-DTC, the TCH-RM DTC, provides radio resourcemanagement.

The functions supported by DTC are:

Paging management

Radio Resource Management (RRM)

The BSSAP

The GPRS O&M functions

The BSCGP interface

A-Trunk management

The SCCP.

As opposed to the V-TCU, the V-DTC process plays different roles, dependingon O&M requirements:

The BSSAP V-DTC, the BSSAP/SCCP performs the main functions of theDTC process. It handles the AIF application layer messages

The TCH-RM V-DTC, the radio resource management carrier, is the

hot backup in OMCP. Each pair of DTC manages a group of TRX radioresources. The TCH-RM performs the main functions of this process

The SS7 V-DTC is the SS7 O&M handler, and is responsible for the alarm

management of each SS7 link

The GSL V-DTC process maps the GSL. It is used by the A9130 BSC to

handle BSCGP message distribution and perform GPRS O&M functions.

Note: There is a trunk-only DTC defined in the BSC software but it is never used, as itonly acts as an A-Trunk Handler.

1.4.8.5 V-TSC ProcessThe V-TSC is the application process which simulates the TSC function inthe A9120 BSC. Compared to other VCE in the A9130 BSC, the V-TSC iscomposed of the VOS library, the V-BootTrap, the CMW API and upper layerapplication modules. The DBCS is not included in the TSC.

The functions supported by the TSC are:

Fault supervision on the Transmission Network Element (NE) in remotesites, such as for the TC and the G2BTS

Configuration of remote Transmission NE.

24 / 66 3BK 20982 AAAA TQZZA Ed.01


1.4.8.6 EIM-RThe EIM-R is the application process which manages A9130 BSC externalcommunication with the CBC and the OMCR. This process runs on OMCP andis secured by a 1+1 redundancy running on both OMCP.

1.4.8.7 EIM-LThe EIM-L is the application process which manages TCP connection with theA9130 BSC local terminal. This process runs on OMCP and is secured by a1+1 redundancy running on both OMCP.

1.4.8.8 TP-Main ProcessTP-Main is a A9130 BSC application process which manages the low layer oftransmission protocols and the switch command of the user plane.

The functions supported by TP-Main are:

HDLC handler

Qmux Handler

Ring Control

Octet alarm handling

Bit switching management

TPGSM O&M

A9130 BSC clock synchronization.

1.4.8.9 TP-SS7 ProcessThe TP-SS7 is the A9130 BSC application process which manages the MTP3function part of SS7 protocol.

The functions supported in TP-SS7 are:

SLH function of each SS7 link

Performance Management of the SS7 link set

Fault management of the SS7 link

Configuration Management for SLH.

3BK 20982 AAAA TQZZA Ed.01 25 / 66


1.5 ConfigurationsThe following table lists the board configurations by shelf.

Equipment BSC Capacity200 TRX

BSC Capacity400 TRX

BSC Capacity600 TRX

ATCA Shelf 1

CCP 1 2 3

SPARE CCP 1

TPGSM 2

OMCP 2

SSW 2

LIU Shelf 1

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.

26 / 66 3BK 20982 AAAA TQZZA Ed.01

2 A9130 BSC Functional Description


This section describes A9130 BSC functions, according to the type of functionperformed:

Telecommunication functions

Operations and Maintenance functions

Transmission functions.

3BK 20982 AAAA TQZZA Ed.01 27 / 66


2.1 A9130 BSC Application InitializationA9130 BSC initialization comprises the following 3 levels:

System initialization (A9130 BSC Reset and Restart)A9130 BSC Reset performs the same function as the A9130 BSC platformPower On, by rebooting the whole board.A9130 BSC Restart ensures that all the A9130 BSC VCE are restartedwithout memory loss. There is no impact on ongoing traffic.

Processor initialization (OMCP/CCP/TPGSM Reset)Processor (OMCP/CCP/TPGSM) Reset reboots the board. For the OMCP,the software is loaded from the disk. For the CCP/TPGSM, the softwareimage is reloaded from the OMCP. Once this is done, the Linux kernel andplatform services are reinitialized. The A9130 BSC application process onthe board is then recreated.

Application process (VCE) initialization (VCE Reset and Restart).VCE Reset kills the VCE and recreates it using the platform managerVCE Restart starts the VCE process by putting the program back to thebeginning without memory loss.

The A9130 BSC initialization sequence is performed in 2 parts:

1. Platform initialization, including:

Software installation in both OMCP

Software download to non-disk processor (CCP/TPGSM/MUX)

Firmware initialization

Linux kernel initialization

Platform service initialization.

The board is now ready for platform service and is waiting to launch theA9130 BSC application process.

2. Application initialization, including:

A9130 BSC application process creation

VOS initialization

FMM initialization.

A9130 BSC application process is ready for any further processing.

28 / 66 3BK 20982 AAAA TQZZA Ed.01


2.1.1 A9130 BSC Application Process Creation

The A9130 BSC application process creation is managed by the PMS platformservice.

The process is further subdivided into 2 specific types of process:

V-SCPR, V-OCPR, V-TSC, V-DTC (TCHRM), EIM-R, EIM-L, CMW-MRare basic processes that are directly created by the PMS when the PMS

prepares the OMCP

For the V-TCU and other V-DTC processes, when the CCP is ready for

platform service, the V-SCPR is notified by the Board Ready message

from the platform. It then orders the PMS to create the process on thetarget board.

2.1.2 VOS Initialization

After the process is created, the VOS is the first element to be initialized. Theinitialization sequence is as follows:

1. Initialize memory

2. Initialize timer

3. Initialize VbootTrap

Vboottrap loads the DLS in the memory of the VCE and initializes the DBCS

4. Initialize Trace Debug module

5. Initialize the entries for each FMM

6. Give the initialization rights to FMM_Init for FMM initialization.

2.1.3 FMM Initialization

FMM initialization is managed by the FMM_Init module.

Once the VOS has finished initializing the entries for each FMM, FMM_Initsends an Init message to each FMM. This message is distributed by the VOSto each FMM. On receiving the Init message, each FMM starts initialization atthe FMM level. If initialization is successful, each FMM sends a message backto FMM_Init to confirm the initialization.

FMM_init consolidates the initialization, confirms reception of the messagesand sends a message to VSCPR to confirm the successful initialization of VCE.

3BK 20982 AAAA TQZZA Ed.01 29 / 66


2.2 A9130 BSC External CommunicationA9130 BSC external communication comprises communication with theOMCR, NEM, BSC terminal and the CBC server.

The following figures show how the external connections are managed indifferent connection conditions.

APPLICATION

CMISE/ROSE/ACSE

ISO−L5,L6

ISO_TS(ON TCP)

TCP/UDP

IP

Link(802.3a/b)

IP

Link(802.3)

IP

Link(802.3)

IP

Link(802.3a/b)

APPLICATION

CMISE/ROSE/ACSE

ISO−L5,L6

ISO_TS(ON TCP)

TCP/UDP

802.3A/B 802.3A/B

MxBSC OMC−R

ROUTER

Figure 7: A9130 BSC Connection with OMC-R (Direct IP Connection)

MxBSC

OMC −R

(ML −)PPP

IP

Serial Link Serial Link

N*64K on Ater

Inner LAN

IP

Link(802.3)

TC/MSC

V.11/V.28

ROUTER

802.3A/B

Link(802.3)

IP

TCP/UDP

(ML −)PPP

IP

Serial Link

TCP/UDP

ISO−L5,L6

ISO_TS

(ON TCP)

TCP/UDP

Link(802.3a/b)

IP

CMISE/ROSE

/ACSE

APPLICATION

ISO−L5,L6

ISO_TS

(ON TCP)

TCP/UDP

Link(802.3a/b)

IP

CMISE/ROSE

/ACSE

APPLICATION

MFS

802.3A/B

Figure 8: A9130 BSC Connection with OMC-R (IP over Ater)

30 / 66 3BK 20982 AAAA TQZZA Ed.01


MxBSC

CBC

X.25

TCP/UDP

Link(802.3)

IP

XOT

IP/X25 Router

TCP/UDP

XOT

X.25

SMS−CB

Link(802.3

LAPB

Serial Link

X.25

LAPB

Serial Link

X.25

SMS−CB

V.11/V.28

IP

802.3A/B

Figure 9: A9130 BSC Connection with CBC (Direct IP Connection)

MxBSC

CBC

X.25

TCP/UDP

Link(802.3)

IP

XOT

(ML −)PPP

Serial Link Serial Link

N*64K on Ater

Inner VLAN

TC/MSC

V.11/V.28

IP/X.25 ROUTER

IP

TCP/UDP

Link(802.3)

IP

XOT

X.25

SMS−CB

(ML −)PPP

Serial Link

LAPB

Serial Link

X.25

LAPB

Serial Link

X.25

SMS−CB

V.11/V.28

IP

Figure 10: A9130 BSC Connection with CBC (IP over Ater)

Note that in the A9130 BSC application, EIM-R manages communication withthe OMCR/CBC and EIM-L manages communication with A9130 BSC localterminal. This is shown in the following figure.

L5/L6/L7

L4Transport RFC_1006VC

E

L4_Conv

X25_PLP

XOT_VCE

VOS

ME_MMC

VOS

V−OCPR V−SCPR

CMW API

EIM −R EIM −L

External Link

CMW API

Figure 11: A9130 BSC External Communication Functional Architecture

EIM-R manages the TCP connection with the OMCR or the CBC.

3BK 20982 AAAA TQZZA Ed.01 31 / 66


In V-OCPR, A9120 BSC software is maintained to manage the upper layer ofthe OSI stack. RFC_1006VCE manages ISO transport over TCP/IP. L5/L6/L7and L4/Transp manage communication with the OMC-R. L4_CONV andX25_PLP (A9120 BSC software), together with XOT_VCE and EIM-R, managethe connection with the CBC via the X25 over IP solution.

EIM-L and V-SCPR are the processes used in the A9130 BSC to manage theexternal connection with the A9130 BSC local terminal.

Communication between the EIM-R/ V-OCPR and the EIM-L/ V-SCPR takesplace over the CMW API. As the messages used for external communicationare all intra-board messages, the CMW routing function between the differentboards is not used by EIM-L and EIM-R.

2.3 A9130 BSC CS Functional DescriptionThe following figure identifies the principle functional blocks in the BSC telecompart, and shows the main flow of information and control between the modules.

TelecomSupervision

Module

BSSAPSCCP

MTP

TCHResource

Mgt

Radio FrequencyManagement

Devicehandler

DeviceHandler

Lapd

HDLC SwitchManagement

SMS−CBLocal

SMS−CBMaster

OMCP

CCP

TP−GSM

V−DTC

V−TCU

V−SCPRV−OCPR

BTS MSC

Figure 12: Telecom Modules and Corresponding Information Flow

Note: For reasons of clarity, the circuit switched and packet switched parts areshown in two separate figures (see A9130 BSC PS Functional Description(Section 2.4)).

The telecom functional blocks shown have a one to one mapping. In termsof FMM, they can also consist of one or more SSM, despite the code sizelimitation (maximum 64kbytes) .

32 / 66 3BK 20982 AAAA TQZZA Ed.01


Distribution of the modules across the processes is determined by the proximityto the Abis or Ater interfaces or to the SSD. In the A9130 BSC, these processesare centralized in one processor to reduce unnecessary inter-board messagecommunication, and are described below:

The VTCU (RF-MGT, LAPD-L2-MGT) in CCP and the HDLC handler in

TPGSM handle Abis signalling messages

The VDTC (BSSAP, SCCP) in CCP and the SS7 (MTP) in TPGSM handleA interface signalling messages

The V-DTC (TCH-RM) with no A-TRUNK mapped is located in the OMCP tohandle radio resource management

The V-TCU (Device Handler), V-DTC (Device Handler) and switch handler

in TPGSM handle CS/PS path setup and release.

In general, circuit switching in A9130 BSC can be divided into three parts:

Radio managementRadio management includes SDCCH allocation, TCH allocation and otherLayer 3 message handling. The action can be triggered from an MS or fromthe core network. The function is handled by RF-MGT and TCH-RM. Whenthe A9130 BSC selects one radio resource for an MS, the related Abisterrestrial resource is also allocated. Radio resource and Abis terrestrialresource mapping is performed statistically.

A-interface managementThe BSSAP is responsible for handling the A-interface messages, whichinform the BSSAP about CIC allocation on A-Trunk.

Switch management.Switch management is the consequence of the previous two functions.Once the terrestrial transmission resource for the Abis and Ater interfaces isdefined, switching between the Abis and Ater interfaces is defined by theTCU-DH, DTC-DH and the switch management service in TPGSM.DTC-DH handles the CIC information concerning the Ater interface. TheTCU-DH handles the information concerning the Abis transmission resourcefor the MS. It sends this information to the DTC-DH. The DTC-DH thensends the switch commands to the TPGSM switching handler to make theconnection for both the uplink and downlink.

3BK 20982 AAAA TQZZA Ed.01 33 / 66


2.4 A9130 BSC PS Functional DescriptionThe following figure identifies the principle functional blocks in the BSC telecompart, and shows the main flow of information and control between the modules.

GPRSTelecom

Supervision

GPRS APP

HDLC

TCHResource

Mgt

GPRS RadioFrequencyManagement

Devicehandler

DeviceHandler

Lapd

HDLC SwitchManagement

OMCP

CCP

TP−GSM

V−DTCV−TCU

V−SCPR

BTS MFS

Lapd

Figure 13: GPRS Telecom Modules and Corresponding Information Flow

Note: For reasons of clarity, the circuit switched and packet switched parts areshown in two separate figures (see A9130 BSC CS Functional Description(Section 2.3)).

The modules are described below:

The V-DTC (GPRS AP), V-DTC (LAPD-L2-MGT) and the HDLC handler inTPGSM handle messages from the BSC GP interface (G-Ater)

The V-TCU (RF-GPRS), V-TCU (LAPD_L2-MGT) and the HDLC handler in

TPGSM handle Abis control messages

The V-TCU (DH), V-DTC(DH) and the switch handler in TPGSM handle PS

path setup and release.

34 / 66 3BK 20982 AAAA TQZZA Ed.01


In general, circuit switching in A9130 BSC can be divided into three parts:

GPRS radio resource managementGPRS radio resource is managed by the MFS, but A9130 BSC TCH-RM isthe radio resource master of the cell, responsible for balancing the radioresource allocated for CS and for PS.The Gaiter Transmission Resource is managed by the MFS.

Abis Transmission Resource managementThe Abis Transmission Resource is split into basic nibbles and extra nibbles.The Basic nibble is used both for CS and PS and is pre-configured byTRE Abis allocation. The extra nibbles are also pre-configured but theyare allocated for one BTS and can be dynamically used by any TRXinside of the BTS.Compared to A9120 BSC, Abis Transmission Resources are not mappedto any TCU, and only one TCU(DH) entity is responsible for basic andextra nibble path setup and release.

Switch management.When the A9130 BSC is asked by the MFS to set up a PS connection for anMS, the GIC location is known by DTC-DH. The Abis terrestrial resourceis known by DH-TCU and it forwards this information to DTC-DH. Then itis up to DH-DTC to command the switching handler in TPGSM to makethe connections for multiple GCHs.

2.5 A9130 BSC Performance Management DescriptionThe following figure shows A9130 BSC performance management.

Cnetral PM Cnetral RMS

TCHRM−LDCP

X25−LME

TCU−TRF−LDCP

CPR−N7−LDCP

RMS Local

DTC−TRF−LDCP

MTP3

DTC

V−TCU

HDLC TP−GSM

CCP

OMCP

V−DTC(TCH−RM)

TCHRM−LDCPV−SCPR

V−OCPR

Figure 14: PM Functional Blocks

The Local Data Collector (LDCP) module is a slave module of performancemanagement located in the same process as the telecom module, so that theLDCP can retrieve the required counters.

3BK 20982 AAAA TQZZA Ed.01 35 / 66


The PM decomposition broadly follows the same decomposition schema asthat of the telecom module, but with the following additional features that allowlarge volumes of data to be retrieved more efficiently:

TCU_TRF_LDCP in V-TCU monitors:

Radio Resource Management (RFMGT)

Radio Resource Control (RFMGT)

Broadcast services (on TCU) (SMS-CB_local)

Device Handlers (TCU_DH).

DTC_TRF_LDCP in V-DTC monitors:

BSSAP (BSSAP)

Device Handlers (DTC_DH).

TCHRM_LDCP in V-DTC(TCH-RM) monitors Traffic Resource management(TCH-RM)

CPR_N7_LDCP in V-SCPR monitors Centralized SCCP management

functions.

The principle of organization is that of the "master-slave" relationship whereall the LDCP act as slaves to the Central-PM functional block that supervisesand coordinates all activities.

A 15 minute period principle is used in the BSC PM counter collection. Eachslave module saves the counter every 15 minutes. The master triggers theslave audit every 15 minutes.

Central-PM is responsible for the OMC-R interface, persistency and formattingof PM files and persistency and management of all PM jobs. These factorsdetermine its location on the OSI-CPR processors for proximity to the OMC-Rinterface, disks for storage and the active-standby operation for fault tolerance.

Specifically for Radio Measurement Statistics (RMS) PM, some dedicated FMMare created as these measurements originate from the TRE or the BTS.These require much larger volumes of information to be collected and storedseparately. The TRE needs to have jobs activated and stopped. Measurementsare collected in shorter intervals.

The Local RMS entities receive and activate data at the TRE.

The Central RMS entries poll the local_RMS and construct the data repositoryfor forwarding to the OMC-R by Central-PM.

36 / 66 3BK 20982 AAAA TQZZA Ed.01


2.6 A9130 BSC SMS-CB Functional DescriptionThe following figure shows the A9130 BSC SMS-CB functional blocks.

ME_SMSCB_MASTER

ASN1 SMAP CONV FUN

RMH

PM HSK

ME_Maint_CPR

ME_Alarm−Corre

TRX −Manager

VOCPR

VSCPR

CCP SMSCB−Local RF−MGT

LAPD

HDLC Handler

VTCU

BTS1 BTSn

TPGSM

Figure 15: SMS-CB Functional Blocks

The SMS-CB function works in a master-slave relationship in the A9130BSC. It is composed of two modules:

SMS-CB masterThe SMS-CB master is located in the VOCPR in the OMCP, and acts as theinterface towards the convergence function and the SMAP and then to theoperator in the CBC or the OMC-R. It dispatches the commands to the localSMS-CB for the cell to which the command is applicable.

SMS-CB LocalSMS-CB Local is located in the VTCU and is responsible for constructing,segmenting and queuing the SMS-CB message towards the BTS.

3BK 20982 AAAA TQZZA Ed.01 37 / 66


The following remaining modules perform the corresponding functions:

TRX-MGTTRX-MGT informs the SMS-CB master of the availability of the CBCHchannel, whether it is blocked or unblocked. SMS-CB Master uses thisinformation to notify CBC whether the cell is operational or not.

HSKHSK interacts with the SMS-CB master for logical parameters configuration.When there is a change on the CBCH (for example, a remove operation)or there is modification on the CBCH DRX, the HSK informs the SMS-CBmaster via messages.

PMPM interacts with the SMS-CB to periodically poll the master forthe write_load_counter and the kill_load_counter. It manages thefailure_load_counter and the Rejec_load_counter values.

RMHRMH distributes the message to the other VCE when the message isgreater than 300 bytes.

LAPDLAPD is the L2 layer for the SMS-CB function which sends the message toBTS.

RF-MGTRF-MGT is the SMS message from the BTS. It is received by RF-MGT, thenRF-MGT forwards the message to the local SMS-CB.

SMAPThe SMS-CB master sends and receives messages to/from the OMC-Rvia SMAP.

CONV FUNThe SMS-CB master sends and receives messages to/from the CBC viaOCNV FUN.

38 / 66 3BK 20982 AAAA TQZZA Ed.01


2.7 A9130 BSC SS7 Functional DescriptionThe following figure shows the A9130 BSC SS7 functional blocks.

CCP

VDTC

OMCP VSCPR

TPGSM SW

CMW

CMW

BSSAP

TP_SS7 (process)

SLH

PQ2 MTP_2

MTP_1

API

CMW

SLNM SM

SCCP_SCMG SCCP Level 4

Level 3

Level 2

Level 1

Figure 16: A9130 BSC SS7 Architecture

The N7 signalling system is partitioned into an MTP part and an SCCP part.Both the implementations of CCITT MTP and SCCP consist of a number ofmodules.

Due to the distributed nature of the BSC concept, the software modules ofthe N7 MTP are partially distributed:

The (level 3) MTP network management functions require centralized

control. They are therefore located on a VSCPR

The (level 2 and level 3) MTP reside on TPGSM terminating all the 16N7 links.

The CCITT SCCP can also be split into a centralized function and a distributedfunction:

The SCCP management function (SCMG) is a centralized function. It ishandled by the SCCP_SCMG module, located on the VSCPR.

The SCCP addressing, routing and connection procedures are handled by

a number of SCCP software modules. They are fully distributed for loadsharing purposes. They reside on VDTC processors.

3BK 20982 AAAA TQZZA Ed.01 39 / 66


In the A9130 BSC:

BSSAP and SCCP in V-DTC manage the user application layer messages

and user connections

SLNM/SM and TP-SLH manage the MTP3 layer

The MTP2 and MTP1 layer are handled in the PowerQuicc process by

third party software.

2.8 A9130 BSC LAPD Functional DescriptionThe following figure shows the A9130 BSC LAPD functional blocks.

CCP

V−DTC

CCP V−TCU

TPGSM SW

CMW

CMW

Lapd −l2

TP_MAIN (process)

MTP_2

MTP_1

HDLC

CMW

Lapd −L2

L3 layer modules

TPGSM HW

VOS VOS

L3 layer

HDLC

Framer

HDLC Hanler

Figure 17: LAPD Functional Blocks

The BSC uses the LAPD protocol for signaling transmission. LAPD is managedas two entities:

LAPD L2 FMM in V-TCU/V-DTC, which handles Q921 LAPD protocol

Data link setup

Sequence control

Detection and recovery of errors

Data link monitoring

Flow control.

HDLC handler in TPGSM interfaces with LAPD FMM and sends the LAPD

frame onto HDLC channel.

40 / 66 3BK 20982 AAAA TQZZA Ed.01


2.9 A9130 BSC Qmux Functional DescriptionThe following figure shows the A9130 BSC Qmux functional blocks.

Layer 1

Alarm Report Functions

NE Config Functions

Application Layer

LLC Layer

Sub Layer 2

Layer 1CMW

Sub Layer 2

Application Data

Qmux Payload

Qmux Address+Qmux Payload+PCS

Internal Communication Message (Multiple UART Characters)

CMW

Sequence of UART Characters including

F/C bits

Alarm Report Functions

NE Config Functions

Application Layer

LLC Layer

Sub Layer 2

Application Data

Qmux Payload

Qmux Address+Qmux Payload+PCS

Sequence of UART Characters including

F/C bits

Sequence of UART Charactersincluding F/C bits

Alarm Polling Messages

NE Configuration Messages

Qmux packet(UART Characters with Start/Parity and Stop bit)

TSC on OMCP TPGSM Network Element

Figure 18: Qmux Functional Blocks

In the A9130 BSC, Qmux is a lower layer transmission protocol used tocommunicate with NEs in remote sites. This protocol is used by the A9130BSC to supervise and configure the transmission node of the NE as G2BTSBIE, ASMC, ATBX DT16 and MT120.

3BK 20982 AAAA TQZZA Ed.01 41 / 66


The Qmux protocol includes 3 layers:

Application layer:

This layer is used to handle VTSC application messages. Two types ofmessage are supported in this layer:

O&M application message, used to supervise the NE or get fault alarm

messages from the NE

The Transfer application message, used to configure the NE.

L2 layer

For the purposes of this document, the L2 layer is split into two sub-layers:

LLC layerThe LLC sub-layer receives N octets from the Application layers. Itchops these N octets into blocks of 6 bits (eventually completing thelast block with "0"), adds the address (Q blocks of 6 bits) and calculatesthe checksum over all the blocks.

Sub-layer 2The sub-layer 2 takes each block of 6 bits, adds the bits F and C andtransfers this octet to the layer 1.As in A9130 BSC, the layer function is implemented in TPGSM, so thelayer 1 frames are encapsulated in the TCP message (via CMW) sent toTPGSM Qmux handler (UART). It is up to the TP Qmux handler to sendand receive the layer 1 frame.

Layer 1This layer is a 1200 baud asynchronous link over 2 bits carried on a TS ofan E1/T1 link.

The physical level interface describes four main attributes:

Electrical

Functional

Mechanical

Procedural.

42 / 66 3BK 20982 AAAA TQZZA Ed.01


2.10 A9130 BSC ML-PPP Functional DescriptionThe following figure shows the A9130 BSC ML-PPP functional blocks.

OMC

TPGSM

BSC

ATCA Shelf

OM−CP

NE1oE

TDM

HDLC

MAC GbE

ML−PPP IP

PPP

NE1oE

TDM

HDLC

MAC

PPP

NE1oE

TDM

HDLC

MAC

PPP

IP

IP routing

MAC

IP

MAC

TCP

Appli

GbE

MUX

LiU

LiU

LiU

LiU

E1

MAC NE1oE

Router

E1

TDM

HDLC

PPP

ML−PPP IP IP

MAC E1

TDM

HDLC

PPP

E1

TDM

HDLC

PPP

IP

MAC

TCP

Appli

E1

Figure 19: ML-PPP Functional Blocks

In the A9130 BSC, ML-PPP carries the O&M traffic flow over the Ater interface.

ML-PPP is a L2 layer function which is used to carry IP traffic over a bundle onthe PPP link. These PPP links are set up over E1.

ML-PPP is implemented in TPGSM as one functional module of the TP-Mainprocess.

ML-PPP can be broken down into three functional parts:

The outline services which provide the O&M function to ML-PPP (for

example, ML-PPP configuration, ML-PPP alarm report and supervision,

ML-PPP performance management)

The ML-PPP handler which performs the main function of ML-PPP service

and is implemented in line with RFC 1717

The HDLC handler which is the lower layer function that provides the PPPlink with a HDLC channel to transfer message flow.

3BK 20982 AAAA TQZZA Ed.01 43 / 66


2.11 A9130 BSC Transmission Function DescriptionThe following figure shows the A9130 BSC transmission functional blocks.

MS

MS

MS

BTS

BTS

BTS

BTS

MxBSC

MFS/MxMFS

TC/TC2.5 MSC

SGSN

A interface

GB interface

Ater Mux Interffcae

Abis interface

Figure 20: BSS Transmission Functional Blocks

In the Alcatel BSS, the transmission NEs include the BTS, A9130 BSC, A9120BSC, MFS, A9130 MFS, TC and TC2.5. Any of these NEs can be selected withthe others to compose the transmission architecture.

As a transmission NE, the A9130 BSC provides BTS to TC access for CSservices and MFS access for PS services.

The A9130 BSC uses the following hardware modules to support thetransmission function:

LIU

MUX

SSW

TPGSM.

The following figure provides an overview of the transmission model.

Mx −BSC site

TTPP

GGSSMM

TP−HW

(Unit type=BSC)

ATER−HWAY−TP

(Unit type=BSC)

ECU

(Unit type=BSC)

ETU

(Unit type=BSC)

SSW−HW

(Uni t type=BSC)

LIU

MUX

SSW

Abis −HWAY−TP

(Unit type=BSC)

TTCC// TTCC22 .. 55

BBTTSS

Other NE of BSS

Figure 21: A9130 BSC Transmission Module with SBL Mapping

In the A9130 BSC, the transmission architecture can be viewed as four majorparts:

44 / 66 3BK 20982 AAAA TQZZA Ed.01


NE1oE control

Remote NE configuration and supervision via Q1, for more details see

A9130 BSC Qmux Functional Description (Section 2.9)

Ring Control for Abis

Remote tributary alarm management on A interface.

2.11.1 NE1oE Control

The following figure shows the NE1oE Traffic Plane in the A9130 BSC.

LIU 16

LIU 1MUX SSW TPGSM

MUXSSW TPGSM

E1 256

E1 16

E1 1

16_E1 interface NE1oE interface NE1oE interface

E1 and supervision traffic

Supervision traffic

Figure 22: NE1oE Traffic Plane

NE1oE control provides TDM frame transferring inside the A9130 BSCplatform, and user plane supervision and redundancy management.

The NE1oE function uses an Ethernet packet to encapsulate a TDM frame totransfer and recover the TDM frame on the access point of NE1oE.

For an incoming traffic flow (traffic flow from the LIU to TPGSM):

LIU is the E1 link access equipment. The E1 frame ismultiplexed/de-multiplexed by LIU and is sent to MUX over a 16 Serial link

MUX has an NE1oE component inside, and it encapsulates the E1 frame

into Ethernet frame

SSW routes the Ethernet frame to TPGSM

TPGSM has NE1oE inside, and it recovers the E1 frame from the Ethernet

frame it receives.

Outgoing traffic flows in the opposite direction.

3BK 20982 AAAA TQZZA Ed.01 45 / 66


2.11.2 Remote Tributary Alarm Management

The following figure shows alarm handling on the A interface.

R/W bitHandler

TDMSwitch ASMC

ATBX

ATBX

ATBX

ATBX

LIS

RAI

AIS

RAI

R4 A4 R3 1 R2 R1A2 A1

R4 A4 1 0 R2 R1A2 A1

Figure 23: Alarm Handling on the A Interface

The Remote Tributary Alarm is defined for alarms occurring on the A interface.

In Atermux, TS15 is typically defined for alarm octet usage, and is used to carryper Tributary A (AIS) or R(RAI) information in order to make multiplexed linkstransparent for alarm forwarding. The layout of the Alarm Octet is: 0 = No

Alarm; 1= Alarm Active.

The figure above shows the following information flow:

When an LIS alarm is detected on the A interface, the RAI is returned to

the MSC

The AIS is forwarded to the ASMC. The ASMC detects the AIS alarmand returns the RAI to the ATBX

The ASMC sets an Ai bit in the alarm octet for the tributary

The TPGSM R/W bit handler detects the Ai bit and generates an AIS alarmto the application and returns 10 on the corresponding CIC group (RAI

indication) of the impacted A-TRUNK.

2.11.3 Ring Control in A9130 BSC

The following figure shows the Abis topologies supported by the A9130 BSC.

MxBSC

BTS

BTS

BTS

BTS

BTS

BTS BTS

BTS

BTS

Star

Chain

Ring

Figure 24: Abis Topologies

46 / 66 3BK 20982 AAAA TQZZA Ed.01


In A9130 BSC, three topologies support BTS access:

Star

Chain

Ring.

The purpose of a ring configuration is to protect against any fault on a link or aBTS, which leads to the loss of BTS that are not faulty.

The protection is for:

The data traffic. This refers to all CS and PS information and data signaling

(all OML and RSL information) which is transmitted between the BSC andthe BTS using the traffic time slots (TS) of the Abis links. Transmission is

handled from both directions but reception is performed only from one or

both ends, depending of status of the ring

Clock transmission is made in both directions but the BSC does not read

this kind of information from the ring

Qmux refers to all the information transmitted in the Qmux TS of each Abislink between the BSC and the BTS. The transmission and the reception can

be handled from both directions or for only on one direction.

The selection and the switching of the paths of the signaling, traffic and Qmuxare autonomously managed by TPGSM.

Two modules perform all the actions related to these activities

The ring control moduleThe ring control module reads the ring control bits from the Abis links inthe ring configuration and decides the transmit and receipt direction foreach BTS. This is materialized at TPGSM level by the orders transmittedinternally to the TPGSM-Switching Handler.

TDM switch controlThe TDM switch control module is located in the TPGSM and performs theactions resulting from the changes detected by the ring control module.

3BK 20982 AAAA TQZZA Ed.01 47 / 66


2.12 A9130 BSC Logical Configuration Management FunctionalDescription

This figure shows the logical parameter configuration management (CM)functional blocks.

OMCP

HSK3,3Bis

HSK4,4Bis

HSK5,HSK5bi

s

HSK6.hsk7

A2BS(ssm)

VOCPR

Telecom Function module

FM function modules

VSCPR

HSK−loc−TCU

Telecom function

FM fucntion

HSK−loc−DTC

Telecom function

FM fucntion

VTCU

VDTC

CCP

Figure 25: Logical Parameter Configuration Functional Blocks

Logical Parameter CM manipulates the BSS parameter data in the BSCdatabase to interact with other BSC functional domains, in order to share theBSS/Cell data to telecom and fault management functions.

The parameters are categorized into 4 classes:

Per BSSThe logical parameter item has a single value which applies to all BSS NEs

Per BSCThe logical parameter item has a single value which applies to the BSC only

Per BTSAn instance of the logical parameter item exists for each BTS

Per CellAn instance of the logical parameter item exists for each CELL.

Each class is composed of multiple parameter groups.

The logical parameter configuration function is composed of HSK modules onthe VOCPR and the HSK local module on the VTCU and the VDTC. Telecomfunctional modules and FM functional modules are the serving objects.The logical parameter function provides the related configuration data totelecom and FM modules via messages or via the data base synchronizationmechanism.

48 / 66 3BK 20982 AAAA TQZZA Ed.01


The logical parameter function comprises centralized and local functions:

HSK3, HSK3Bis, HSK4, HSK4bis, HSK5, HSK6 and HSK7 are centralized

functions. HSK3 and HSK3Bis interface with the OMC-R, and forward themessage to the other HSKs if the parameter operation is not handled by

HSK3 and HSK3Bis. These modules are responsible for checking and

updating the parameters in the BSC data base. If the parameter is relatedto separated VTCU/VDTC, then a trigger will be sent to the local HSK to

rebuild the local data base or modify the local context.

HSK_local-TCU and HSK_Local_DTC are distributed modules responsible

for separated TCU and DTC. One HSK-Local-TCU is for one VTCU and

one HSK-Local_DTC is for one TCH-RM VDTC. The local HSK module isresponsible for building and modifying the local parameters for concerned

TRX which are managed by the VTCU/VDTC.

2.13 A9130 BSC Hardware Configuration ManagementFunctional Description

This figure shows the Hardware Configuration Management (HCM) functionalblocks for the A9130 BSC.

OMCP

BSC EXT/RED

BTS EXT/RED

VSCPR

BTS−MGT−TCU

Conf−Trans−loc

VTCU

CCP

FM −TRANS

Conf−Trans−TP

BTS−MGT−CPR

VTSC

ME−TSCM−CPR

CM −Abis CM −At er

TP−Main(conf)

TP−Main(Qmux) TP−Main(HDLC)

TC BTS

TP−GSM

TSC APP

L2 layer

?

?

?

?

?

?

?

?

?

?

?

?

? ?

Figure 26: HCM Functional Blocks

3BK 20982 AAAA TQZZA Ed.01 49 / 66


A9130 BSC HCM comprises the following cases:

A9130 BSC/TC configuration type managementIn the A9130 BSC, 200 TRX is defined for one BSC configuration type,A9130 BSC configuration type is from type 1 to type N with TRX capacityextended from 1 * 200 TRX to N * 200 TRX. Depending on the type ofconfiguration selected, the following components will be changed:

LIU boards

PCM link used for Abis and Ater

CCP boards

TC clusterFrom a BSC application point of view, with increasing/decreasing TRX,the number of VTCU/VDTC will also be increased or decreased. All theabove behavior will be handled by the A9130 BSC extension/reductionmodule.

BTS sector configuration

BTS configuration

TRE configuration.

The last three functions listed above are handled by the A9130 BSC BTS-Eextension/reduction module. This module is responsible for the followingfunctions:

Add/delete BTS

Add/delete BTS sector

Add/delete TRE

TRE auto-detection.

Depending on the configuration object, three flow charts are used by the A9130BSC to manage the configuration:

By Qmux to manage the configuration of G2BTS and Transcoder (TC2or TC2.5)

Configuration of TPGSM

Configuration of BTS via OML.

2.14 A9130 BSC Software Management Functional DescriptionSoftware Management (SM) allows the O&M operator to:

Introduce new BSS software (A9130 PF, A9130 BSC and BTS) in a BSS-NE

or to modify an existing one

Introduce a new version of the DLS (the BSC database)

Perform a Massive Logical Update (MLU).

50 / 66 3BK 20982 AAAA TQZZA Ed.01


2.14.1 BSS SW Package

The following figure shows the file hierarchy for A9130 BSC files.

BSS

Master file

Mx Platform

Master file

BSC SW

Master file

BSC DB

Master file

BTS SW

Master file

BTS DB

Master file

BSS

Map file

One One One One One

More than One

Refers to second level master files

Figure 27: BSS SW Package File Hierarchy

BSS Software (SW) is organized by Master File (MF); consequently, the MFsshow the hierarchical structure of the BSC SW.

At the top level, the BSS master file is a sort of super directory that referencesthe following, second level master files:

BSC SW Master FileThis file references all application files that correspond to the BSC software.

BSC DB Master FileThis file references the DLS and configuration files of the BSC. It alsoreferences all TC-CPFs and it may reference a steerfile or a command file.

BTS SW Master FileThis file references all application files that correspond to the given BTSsoftware. The number of BTS SW Master Files depends on the differentBTS hardware types and the number of different ciphering algorithmsused by the PLMN network. All BTS SW Master files are referenced inthe BSS Master file.

BTS DB Master FileThis file contains the references of all the OMU-CPF files.

BSS Map FileThis file defines the reference of the OMU-CPF and the reference of theBTS SW master file it uses for each BTS.

ATCA Platform Master FileThis file has the same structure as the other master files for compatibilityreasons, but only the file name, separator, version and sub-version of theA9130 OS A9130 PF MF header are taken into account. The A9130 OSA9130 PF Master File does not contain a file descriptor.

3BK 20982 AAAA TQZZA Ed.01 51 / 66


2.14.2 SWMGT Architecture

The following figure shows the SWMGT functional blocks.

Communication Midway

S−CPR

othersub

systems

BSC_SW_REPLACE

O−CPR OSI Stack

OMC−R

MxBSC

NEM

FTPCLIENT

HW_MGT

PMS

CPI

MxPF SWMGT

SelfR

eliant

Montavisa Linux

Figure 28: SWMGT Functional Blocks

The SWMGT comprises two parts:

BSC

A9130 PF.

The BSC acts as the master of whole scenario. It receives and analysesthe commands from the OMC-R/NEM. Then it triggers the required actions,as described below:

The upload phase is used to upload the present DLS and MF from BSCto OMC-R

The download phase downloads the files required for SW Replacementfrom OMC-R

The abort phase cancels the SW Replacement procedure

The preload scenario preloads the DLS (only in MLU) and every BTS

connected to the BSC

The active phase triggers BSS Switch into New SW once it has been

successfully downloaded or preloaded

The accept phase formally accepts the new version.

52 / 66 3BK 20982 AAAA TQZZA Ed.01


2.15 A9130 BSC Fault Management Functional DescriptionThe following figure shows the A9130 BSC Fault Management (FM) functionalblocks.

TRX_MANAGER ALARM

BSC MAINTANANCE TSC MAINTENANCE BTS MAINTENANCE

Figure 29: FM Functional Blocks

A9130 BS FM is divided into functional blocks broadly based on the SBLor resources that each manages:

TRX ManagerTRX Manager coordinates availability and remapping of all TRX and cellrelated resources. It has CM functions as well as FM functions since thealgorithms used often serve both purposes.

A9130 BSC MaintenanceA9130 BSC Maintenance is responsible for all BSC SBL maintenance anddispatching all SBL related operator commands.

A9130 BSC TSCA9130 TSC Maintenance is responsible for managing the complete interfacewith the TSC.

A9130 BSC BTS ManagementBTS Maintenance is responsible for all BTS related activities and hence hasa strong CM function as well as FM functions.

A9130 BSC AlarmAlarm is a general service for all BSC functional areas and queues. Itformats and dispatches alarms towards the OMC-R and the LMT.

3BK 20982 AAAA TQZZA Ed.01 53 / 66


54 / 66 3BK 20982 AAAA TQZZA Ed.01

3 Managed Objects and SBLs


Managed Objects and SBLs describes the Managed Objects and the SBLs forthe A9130 BSC and the transmission equipment. It maps Managed Objectsand SBLs to the corresponding RIT.

3BK 20982 AAAA TQZZA Ed.01 55 / 66


3.1 Existing A9120 BSC SBL StatusIn order to limit the impact on the SBL hierarchy and to reduce the impacton the OMC subsystem, the SBL hierarchy remains relatively unchangedwhen upgrading from A9120 BSC to A9130 BSC hardware. The followingsub-sections describe the new required BSC model where changes arerequired. SBL Hierarchy Change Summary (Section 3.6) describes the finalSBL hierarchy.

In general, for logical SBLs and low level SBLs (SBLs managed by a processorSBL), no change is required, with the following exceptions:

Logical SBLs:

BSS-TEL

BTS-TEL

BTS-O&M

TR_O&M.

Low level SBLs:

DTC dependent SBL: ATR, ACH, N7, GSL

TCU dependent SBL: RSL, OML

CPR dependent SBL: X25.

The RS232 SBL is removed from the ATCA platform as there are external IPinterfaces for test and debug and LMT connections, however the physicalinterfaces are kept for use by the OS (for example, after a BSC crash).

The DISC SBL is removed from the ATCA platform, in order to avoid running anOMCP without the disk on the master OMCP. In the case of master OMCP diskfailure, the running application goes to standby and the other OMCP takes overthe master status. In the case of standby OMCP disk failure, it will continuerunning in degraded mode (FIT state). If both OMCP have disk failure, theBSC stops the operation.

The X25 SBL for BSC-CBC communication is maintained. This is because thefailure of the physical link still needs to be reported to the OMC on the X25 SBL(CBC uses the same X25 link as the OMC with A9120 BSC architecture). ThisSBL is not used for other purposes.

OMC-BSC communication is based over IP with two options (direct connectionto the switch board SSW of the A9130 BSC or transport of the IP overATERMUX, as is the case for the X25 links).

The OMC-BSC communication based on IP does not require a new SBL. Itis only required to supervise the SSW that carries the OMC connection andreport alarms (if any) directly on the SSW SBL. IP redundancy is offered onlyat IP transmission level (spread of the ML-PPP link over several Ater links,multiple access to the IP address). No applicative redundancy is applied.

56 / 66 3BK 20982 AAAA TQZZA Ed.01


3.2 Replace TCU/DTC/CPR/TSC Processors by CCP Processors

3.2.1 Maintenance Management View and Impacts on SBL Definition

Due to software and hardware evolutions, the A9120 BSC processors TCU,DTC, CPR, TSC have become "logical SBLs", as the corresponding hardwareno longer exists.

A Restart or Resetof the TCU/DTC/CPR/TSC has been kept to allow therestart or the reset of a VCE, but the Unlock and Lock commands have nomeaning for these logical SBLs and have been removed.

The target for maintenance operations now includes the CCP and OMCPprocessors in its scope. The SBL CP-HW has also been added. The same SBLis used for the two types of boards.

3.2.1.1 Restart VCEIt is proposed that a Restart of TCU/DTC/CPR/TSC SBLs will result in theVCE process being reinitialized while keeping its context when applicable (e.g.stable call context). As for the A9120 BSC, this only holds for establishedCS calls (not for PS and not for short CS SDCCH transactions) The VCEapplication will be informed of the initialization reason (O&M intervention) bythe platform associated initialization service. With the current OS and possibleusage of shared memory, the VCE process keeps context data (including callcontext) and there will be no impact on traffic or other O&M behavior.

3.2.1.2 Reset VCEIt is proposed that a Reset of TCU/DTC/CPR/TSC SBLs will result in the VCEprocess being reloaded and reinitialized from disk (RAM or HARD disk in thecase of OMCP; RAM disk in the case of the other CCP boards). This meansthat all context is lost (including the context of the stable calls if applicable). TheVCE application will be informed of the initialization reason (O&M intervention)by the platform associated initialization service.

3.2.1.3 CP-LOG/VCE MappingIn order to offer the required maintenance services, it is proposed to introducethe CP-LOG new SBL type as the father SBL of the corresponding VCE typeSBLs (DTC, TCU, etc.). The mapping between CP-LOG and child VCE will beautonomously determined by the BSC, depending on the CONFIGURATIONTYPE (typically based on the maximum number of TRX to be managed as200, 400 or 600 TRX in other releases). It is also proposed to introduceseparate CP-HW SBLs to reflect the CCP HW status and provide a target forCCP HW maintenance commands.

3BK 20982 AAAA TQZZA Ed.01 57 / 66


The reasons why two SBLs are required are explained as follows, and arelinked to the redundancy scheme of the CCP (N+1 schema):

CP-LOG/VCE Mapping is staticThe mapping of VCE TCU/DTC (except TCH-RM) onto CP-LOG will bepseudo-static (which means that BSC will not dynamically modify thismapping).

No load balancing among the CCP boardsNo performance criteria will be considered dynamically during operation ofthe BSC. However the signalling load amongst the CCPs will be balancedas much as possible during HW extensions.

No differentiation of the CCP boards based on their processing capabilityThe exact number of VCE mapped initially onto each CP-LOG can dependson the actual maximum CPU processing capacity of the related CCPboard. This algorithm must take into account the split of the N7-DTC VCEtype between more than one CCP board, in order to ensure BSC-MSCcommunication across BSC restarts (splitting these DTC between exactlytwo CCP is considered to be reasonable).

OMCP Boards: same model but fixed SBL mappingThe mapping of the remaining VCE types S-CPR/O-CPR/TSC/DTC-TCH-RM is fixed on the OMCP board in a 1+1 configuration(note that the broadcast CPR VCE type B-CPR is not required on theATCA platform). From this point of view, the OMCP is considered as beingrepresented by the same CP-HW and CP-LOG SBL type as the othertelecom CCP boards. The two OMCP boards are just two instances of theCP-HW SBL type and can be numbered 1 and 2 in a fixed way for theA9130 BSC. OMCP will therefore carry (in 1+1 redundancy scheme) thetypes S-CPR, O-CPR, TSC and DTC-TCHRM. There will be also two fixedCP-LOG SBLs respectively mapped to the corresponding two CP-HW SBLin a fixed way. Note that the OMCP hardware corresponding to the CP-HWSBL will be reported with a RIT value necessarily different from the RITassociated with the other CCP boards, due to the fact that the OMCP areequipped with hard disks and the other CCP boards only have RAM disk.The RIT could be another way to discriminate the OMCP (in addition to theSBL numbers 1 and 2).The new CP-LOG SBL will be dependent on the unique BSC SBL and willhave as children the existing A9120 BSC SBLs CPR, DTC, TCU and TSC.The new SBL CP-HW and CP-LOG must be reported to the OMC during thehardware audit. The CP-HW has to be reported in the alarm-state audit(general audit mechanism rules).

58 / 66 3BK 20982 AAAA TQZZA Ed.01


3.2.2 Network Defence (CCP Redundancy) View and Impacts on SBLDefinition

The following information applies in the case of a (N+1) CCP redundancyscheme:

One spare CP-HW SBL is equipped in the A9130 BSC (one single SBL

common to all shelves)In the case of failure (after escalation procedures, as defined by the OSsupporting platform) of any other CP-HW SBL carrying the functionsmapped on a given CP-LOG SBL, the BSC application SW on OMCPis autonomously notified by the OS platform (failure notification serviceoffered by the platform).The application on OMCP will then trigger the platform to start theapplication SW on the spare CP-HW SBL with the same list of logical VCEsas mapped on the impacted CP-LOG SBL. This is how the application andthe platform cooperate to manage the full recovery of the CP-LOG SBLand its associated functions. The created application processes will beinitialized by the platform service with an explicit indication of the reason forinitialization given by the BSC application on OMCP: switchover after

CCP fatal failure. This is useful in order to start the application on thespare CP-HW SBL after recovery, to take the appropriate actions.For example, for TCU and DTC, a force-release of all switched connectionson the active TPGSM board occurs for all involved calls (for moreinformation, refer to the description of the TPGSM transmission board).After the new CP-HW SBL has been successfully initialized and has startedoperation, the link of the CP-LOG toward the previous CP-HW SBL has to bebroken and changed into a link to the "previously" spare CP-HW SBL. Theprevious CP-HW SBL supporting the recovered CP-LOG functions becomesthe new spare CCP hardware for the BSC (but is unavailable as long asthe operator does not repair the corresponding HW board; depending onthe failure, this CP-HW SBL might be in the FLT or FOS state). The wholeset of VCEs (and corresponding DTC and TCU SBLs) of the CP-LOG areoperational again, which means that the new carrying CP-HW SBL, theCP-LOG SBL and all DTC/TCU SBLs are in IT.

3BK 20982 AAAA TQZZA Ed.01 59 / 66


After takeover, it is easy to inform the OMC about the new logical/physicalmapping via an event alarm and no HW audit is required. This is the mainreason why the CP-LOG SBL has been introduced in the new SBL hierarchy,in addition to the CP-HW SBL type. The OMC identifies the spare CP-HWSBL easily, as there is simply no associated mapped CP-LOG for this board.

Note: The CP-LOG/VCE mapping and the CP-LOG/CP-HW mapping will initially becalculated by the BSC and reported to the OMC during the BSS discoveroperation. This mapping will therefore also be described in a dedicatedparameter group, in addition to the provision as an event alarm, in the case ofa CP-LOG SBL takeover.

The concept of "logical CCP" inherent to the CP-LOG SBL type does not needto appear explicitly to the operator as it does not supply any additional VCEfunction SBLs. In practice, the OMC will provide a functional view (differentgroups of VCE running on CCP boards) and an equipment view (the CP-HWSBL) with navigation links between the two views.

In the special case of the OMCP boards (which are also CP-HW SBL types),there will be a fixed dedicated logical CP-LOG for each OMCP. There will neverbe a remapping of CP-LOG for these SBLs, due to the 1+1 redundancy.Each OMCP carries a different set of VCEs that cannot be interchanged.In case of recovery, the requirement for the platform will be to be aware ofthe master/standby status of each physical OMCP board and to notify theapplication on the (standby) OMCP. The application on OMCP will switch tomaster, inform the platform and the application will manage the rerouting of themessages exchanged with the rest of the functional VCEs of the ATCA platform.In other words, the SBL hierarchy defined for CCP carrying DTC or TCU is alsovalid for the O&M OMCPs, however, mapping of the functions is fixed.

As an improvement to the A9120 BSC, it is currently proposed to additionallyreport the master/standby status of each OMCP board to the OMC. Moregenerally, the active/standby indication will be reported for all processingboards SBLs in a unified manner, with a specific meanings, as described in thetable below. For explanations related to the TP-HW, TP-LOG and for SSW-HWnew SBLs, refer to the corresponding sections in the document.

60 / 66 3BK 20982 AAAA TQZZA Ed.01


After the failed CP-HW SBL has been repaired (and the failed hardwarereplaced if necessary) the BSC application SW will report it again as IT inan end-of-alarm notification to the OMC. This report indicates the sameor possibly a new RIT identity in case of replacement by a board with thesame variant or a different variant, respectively. This CP-HW SBL servesas the new unique spare CP-HW for all other CP-HW (except the OMCPtype). The current assumption is that all CP-HW SBLs (including the spareCP-HW) are displayed at the OMC, for maintenance efficacity.

Case of pre-equipped CCP boardsIt is possible that the shelf (shelves) of the A9130 BSC have more CCPboards plugged-in than the strictly required number of boards (for therunning standard configuration). Every extra CCP board is considered tobe a pre-equipped board, in order to later extend the BSC to a higherconfiguration type. The BSC operational SW will ignore these extra boards(this means that no CP-HW SBL will exist for them) and select (e.g. thefirst discovered running boards) strictly the exact number of CP-HW SBLrequired for operation in a given configuration type. The pre-equipped CCPboards will not be reported to the OMC (despite the fact that the remoteinventory information from the OS platform includes these boards).In the case one where one or several CCP boards are missing (notequipped), the A9130 BSC commissioning will fail. The operator must theninstall the missing board(s) or start the BSC with a lower configurationtype (if possible).For an extension operation, the BSC SW will scan if extra (pre-equipped)CCP boards are available to cover the actual needs in the new configurationtype requested and will select these extra boards in the new configuration(e.g. the first discovered running CCP boards reported by the OS inventoryservice).Management (and reporting) of pre-equipped CCP boards should take intoconsideration the necessity for improvement during a later release.

3BK 20982 AAAA TQZZA Ed.01 61 / 66


3.2.3 New SBL Hierarchy for Controlling Elements

The existing TCU, DTC, CPR, TSC SBLs are moved one level downwards inthe SBL hierarchy. All these SBLs are now under this SBL type. Any failureof the CP-HW SBL will simply result in CP-LOG/CP-HW remapping and thefunction SBLs will remain IT. Only double CCP board failures can lead to lossof CP-LOG and propagation of the SOS state for all dependent VCEs. Ifthis occurs, the CP-LOG should go to the FLT state so that the BSC willautomatically remap the CP-LOG as soon as a CP-HW becomes availablefor carrying the CP-LOG functions.

The new SBL types CP-LOG and CP-HW must be introduced and fullydescribed in the BSC-CPF. This will create new DLS relations/tuplesaccordingly. The SBL has to be managed during extension reduction of theATCA platform in a similar way as for the TCU/DTC/TSC of the A9120 BSC(standard configuration types for the A9130).

For this purpose, standard A9130 BSC configurations will be designed in termsof CCP boards and corresponding virtual CE(s) mapped on these CCP boards.However the VCE/CP-LOG and CP-LOG/CP- HW mapping is performed atthe time of BSC migration/installation in a pseudo-static manner but does nottake into account the actual CP-HW processing capacity possibly retrievedvia the IPMI remote inventory service (refer to the OS related SFD for moreinformation about this service).

The BSC will report (via new event alarm and during audit via new logicalparameter group) the exact CP-LOG/VCE mapping to the OMC.

The proposal for a unique file (and a very different structure) aims at reducingthe impacts on the SDP SW packages (Software Downloadable Packages).

Extensions will be specifically targeted, for example, for going to 600, or later to1000 TRX managed on the ATCA platform.

For SBL and RIT mapping for the existing A9120 BSC processor SBLs, theexisting definitions in the unique BSC-CPF will not be changed. The BSCALARM handling SW will be adapted in order that the RITs are not reported inthe corresponding alarms (test of BSC generation: no suspected RIT sent ifATCA platform). Failure of a single process is unlikely to occur.

For SBL and RIT mapping for the new CP-HW SBL, the correct and relevantRIT information will be reported on failures of the CCP boards. The RITinformation (and Rack-Shelf-Slot position) does not need to be described inthe BSC-CPF for the boards. This information will be retrieved via the IPMIremote inventory service.

62 / 66 3BK 20982 AAAA TQZZA Ed.01


3.3 Replace DSN Network by a Local Ethernet Gbit NetworkThe corresponding A9120 BSC SBL SWITCH have all been removed(however they are still in the unique BSC-CPF for the G2 platform). They arenot populated during A9130 BSC extension and reduction. They are alsoremoved from the skeleton DLS used as input for POLO (creation of a newA9130 BSC build).

The LINKS SBLs (links between switches in the DSN) internal to the BSCalso no longer exist.

The switch boards’ SSW will obviously be a new SBL (type SSW-HW) to bereported to the OMC during the BSC HW audit (one SBL per equipped board).Two redundant SSW-HW SBL boards are equipped per shelf (two boards andtwo SBLs) and are possible candidates for managing the shelf in the context ofIPMI. Another possibility is that the shelf manager will consist of independentseparate boards, in which case separate SSM SBLs are needed (two suchSBLs per shelf). The SSW-HW SBLs (and possibly SSM SBLs) appear asdirect children of the BSC SBL (as is the case for the SWITCH SBL in theA9120 BSC SBL hierarchy).

Each pair of SSW-HW SBL works in active /standby mode of operation or worksin active/active mode of operation. This depends on the manufacturer and theA9130 behavior will be designed on the basis of the final HW capability.

In the case of the active/standby operation mode, only the active SSW-HWcarries traffic. Lock and Unlock commands are allowed for the SSW-HW SBLby the OMC or LMT operator (locking the active SSW-HW triggers the platformto switchover the traffic to the standby board and exchange the master/standbymode of the two SBLs). The commands are managed by the BSC application.The ATCA platform offers a service for supporting these maintenancecommands and notifies the BSC application about the master/standby mode ofoperation and about the detected failures on these SBLs.

In the case of the active/active operation mode, both SSW-HW carry traffic.Lock and Unlock commands are allowed for the SSW-HW SBL by the OMCor LMT operator (locking one of the SSW-HW results in disabling the alarmreporting from this SSW-HW SBL). The commands are managed by theBSC application.

For the failure of the Power/Fan, the application will be notified by platform andan alarm should be reported to the operator.

For the maximum BSC HW configuration, 2*2 such SSW-HW SBL arepopulated in the DLS from the BSC CPF file (two shelves maximum).

If failures occur on the several internal links managed by the different SSW-HWSBL, in the current A9120 BSC, these failures are not reported as failures ofLINKS. Similarly failures of links will be reported on the SSW-HW SBL type forthe new A9130 BSC (including additional information for the precise localizationof the faulty link at the OMC).

As the SSW-HW SBL does not carry BSC application level functions, there isno need to introduce a logical corresponding SSW-LOG SBL type, as donefor the CP-HW/CP-LOG SBL type.

3BK 20982 AAAA TQZZA Ed.01 63 / 66


3.4 Replace BIUA/ASMB by TPGSM Switching Processors andE1 Termination Shelf

3.4.1 Maintenance Management View and Impacts on SBL Definition

As a result of software and hardware evolutions, the A9120 BSC multiplexingboards on the Abis and Ater interfaces have been removed as thecorresponding hardware no longer exists. Therefore, the corresponding 2BSC-ADAPT and SM-ADAPT [BSC side] SBL types are also removed from theSBL hierarchy for the A9130 BSC.

The target for maintenance operations now includes the TPGSM and E1 shelfboards in its scope. In order to offer the required maintenance services, it isproposed to introduce TP-HW and ETU (E1 Termination Unit) new SBL types.An ETU SBL represents a number of E1 terminations managed by one adaptorand the adaptor is supposed to carry power supply (possibly redundant powersupply). The E1 shelf houses a number of fans. These SBL will be dependenton the unique BSC SBL.

3.4.2 Network Defence (TPGSM Redundancy) View and Impacts on SBLDefinition

The TP runs in a (1+1) redundancy scheme for which the active TP managesall the E1 links of the A9130 BSS. The other TP is hot standby and doesnot manage the E1 links. This means that all highway SBLs (existingABIS-HWAY-TP and ATER-HWAY-TP SBLs) are mapped on the activehardware board TP-HW during operation and are remapped on the otherboard in case of takeover (autonomous or triggered by a Lock command fromthe operator). As this rule is implicit there is no need to create links of thehighway SBLs to the TP-LOG SBL. The report of the active/standby state ofeach TP-HW SBL is enough.

Only one TP-LOG SBL is needed and represents the full set of E1 links.

After a TPGSM takeover the OMC is informed by using the same event alarmused for CCP takeover. The OMC-R is informed of the active/standby state ofeach TP-HW SBL.

During operation the TP-LOG is mapped on the active TP-HW SBL and thismapping is reported to the OMC. The other TP-HW SBL is standby and hasno TP-LOG mapped. A simple event alarm can be used to notify the OMCof the new mapping after takeover.

After the failed TPGSM board has been repaired (and replaced if necessary),the BSC application SW will report it again as IT in an end-of-alarm notificationto the OMC. This report indicates the same or possibly a new RIT identityin the case of replacement by a board with the same variant or a differentvariant, respectively.

The mapping TP-LOG/TP-HW is initially calculated by the BSC and reportedto the OMC during the BSS discover. This mapping will therefore be alsodescribed in a dedicated parameter group, in addition to the provision as anevent alarm in case of a CCP board takeover.

The concept of "logical TPGSM" does not need to appear explicitly to theoperator as it does not provide any additional Hway function SBLs functions. Inpractice, the OMC will provide a functional view (*Hway SBLs running on

TPGSM boards) and an equipment view (the TP-HW SBL), with navigationlinks between the two views.

64 / 66 3BK 20982 AAAA TQZZA Ed.01


The OMC identifies the standby TP-HW SBL easily as there is simply noassociated mapped TP-LOG for this SBL. However it is proposed to additionallyreport the master/and standby status of each TP-HW SBL to the OMC forconsistency with the CP-HW SBLs (as described above).

3.4.3 New SBL Hierarchy for Transmission Elements

The existing ABIS-HWAY-TP and ATER-HWAY-TP are kept unchanged andThe BSC-ADAPT and SM-ADAPT [BSC side] are deleted from the SBLhierarchy. The TPGSM hardware boards are mapped to the new TP-HW SBLtype (two such SBL exist). Any failure of the active TP-HW SBL will simplyresult in TP-LOG/ TP-HW remapping and the function SBLs will remain in IT.

The new SBL types TP-LOG and TP-HW must be introduced and fully describedin the BSC-CPF. This will create new DLS relations/tuples accordingly.

The BSC will report (via new event alarm and during audit via new logicalparameter group) the exact TP-LOG/ TP-HW mapping to the OMC, along withthe master/standby state of each TP-HW SBL.

All configurations are part of the unique BSC-CPF needed in the BSC packageof release B9 (this file describes both A9120 BSC and A9130 BSC)

For SBL and RIT mapping for the new TP-HW SBL, the correct and relevantRIT information will be reported on failures of the TP-HW SBL. The RITinformation (and Rack-Shelf-Slot position) does not need to be described in theBSC-CPF for the TP-HW SBL. This information will be retrieved via the IPMIremote inventory service (refer to the OS related SFD for more information).

The E1 termination shelf will be modelled as one new (or a set of several new)ETU SBL types and corresponding RIT type(s). However, the exact modelwill be defied at a later date.

3.5 Other EquipmentThe following remaining A9120 BSC HW specific SBLs must be completelyremoved from the A9130 BSC hardware audit:

CONV (DC/DC converters)

CLK-GEN and CLK-REP (clock generation and distribution)

BC-SYS-BUS and BC-RACK-BUS

BATTERY.

With the new A9130 BSC architecture, internal BSC equipment alarms (powersupplies, fans, converters, batteries, etc.) are monitored by the ATCA platformand autonomous notifications are sent to the BSC application software. TheBSC will be responsible for forwarding these alarms in a proper format tothe OMC. All alarms are then mapped on the BSC SBL and the SBL stateis systematically set to FIT. The state is returned to IT when all concernedalarms have been cleared (and correlated in the BSC central alarm manageron the OMCP).

Note: The CLOCK alarms (the clock is used mainly by the TPGSM transmission NEand by the MFS) are sent to the BSC application and reported by the BSC tothe OMC in the same way (BSC SBL alarm with explicit additional information).

3BK 20982 AAAA TQZZA Ed.01 65 / 66


3.6 SBL Hierarchy Change SummaryThe following figure summarizes the changes in the hierarchy of the SBLscontrolled by the BSC and the TSC.

BSC

CP−LOGCP−HW SSW−HWTP−LOGETUTP−HW

TCUDTC

ATR

CPR TSC ABIS−HWAY−TP ATER−HWAY−TP

ACH N7 GSL RSL OML X25

BSS−Tel

BTS−Tel

BTS−OM

TR−OM

* * * * *

* * * *

*

*

* *

*

(Unite Type−BSC)

*

(Unite Type−BSC)

Figure 30: SBL Hierarchy Change Summary

66 / 66 3BK 20982 AAAA TQZZA Ed.01

a9130 bsc evolution functional description

Documents