A9130 BSC Evolution Funtional Description

Alcatel BSS
A9130 BSC Evolution

Functional Description
BSC & TC Document

Sub-System Description
Release B9
3BK 20982 AAAA TQZZA Ed.03

BLANK PAGE BREAK
Status RELEASED
Short title A9130 BSC FD

All rights reserved. Passing on and copying of this document, use
and communication of its contents not permitted without written
authorization from Alcatel/Evolium.
2 / 68 3BK 20982 AAAA TQZZA Ed.03

Contents
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1 A9130 BSC Overall Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1 A9130 BSC Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2 A9130 BSC Hardware Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Rack Shared Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.1 Rack Shared by A9130 BSC Evolution - A9130 MFS Evolution . . . . . . . . . . . . . 14
1.3.2 Rack Shared by Two A9130 BSCs Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4 A9130 BSC Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4.1 BSC Software Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4.2 Process Mapping on OMCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4.3 Process Mapping on CCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4.4 Process Mapping on TPGSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4.5 A9130 BSC Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4.6 ATCA Platform Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4.7 A9130 BSC Application Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.4.8 A9130 BSC Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.5 A9130 IP Network Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.6 Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2 A9130 BSC Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1 A9130 BSC Application Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.1 A9130 BSC Application Process Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.2 VOS Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.3 FMM Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2 A9130 BSC External Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3 A9130 BSC CS Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4 A9130 BSC PS Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.5 A9130 BSC Performance Management Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.6 A9130 BSC SMS-CB Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.7 A9130 BSC SS7 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.8 A9130 BSC LAPD Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.9 A9130 BSC Qmux Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.10 A9130 BSC ML-PPP Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.11 A9130 BSC Transmission Function Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.11.1 NE1oE Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.11.2 Remote Tributary Alarm Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.11.3 Ring Control in A9130 BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.12 A9130 BSC Logical Configuration Management Functional Description . . . . . . . . . . . . . . . . . 50
2.13 A9130 BSC Hardware Configuration Management Functional Description . . . . . . . . . . . . . . . 51
2.14 A9130 BSC Software Management Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.14.1 BSS SW Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.14.2 SWMGT Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.15 A9130 BSC Fault Management Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3 Managed Objects and SBLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.1 Existing A9120 BSC SBL Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2 Replace TCU/DTC/CPR/TSC Processors by CCP Processors . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.2.1 Maintenance Management View and Impacts on SBL Definition . . . . . . . . . . . . 59
3.2.2 Network Defence (CCP Redundancy) View and Impacts on SBL Definition . . 61
3.2.3 New SBL Hierarchy for Controlling Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.3 Replace DSN Network by a Local Ethernet Gbit Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.4 Replace BIUA/ASMB by TPGSM Switching Processors and E1 Termination Shelf . . . . . . . 66
3.4.1 Maintenance Management View and Impacts on SBL Definition . . . . . . . . . . . . 66
3.4.2 Network Defence (TPGSM Redundancy) View and Impacts on SBL Definition 66
3.4.3 New SBL Hierarchy for Transmission Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3BK 20982 AAAA TQZZA Ed.03 3 / 68

Contents
3.5 Other Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.6 SBL Hierarchy Change Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4 / 68 3BK 20982 AAAA TQZZA Ed.03

Figures
Figures
Figure 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 Evolution IP Addresses with O&M link via Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 8: A9130 BSC Evolution IP Addresses with O&M link via Ater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 9: A9130 BSC Connection with OMC-R (Direct IP Connection) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figure 10: A9130 BSC Connection with OMC-R (IP over Ater) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figure 11: A9130 BSC Connection with CBC (Direct IP Connection) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 12: A9130 BSC Connection with CBC (IP over Ater) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 13: A9130 BSC External Communication Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 14: Telecom Modules and Corresponding Information Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figure 15: GPRS Telecom Modules and Corresponding Information Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figure 16: PM Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 17: SMS-CB Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figure 18: A9130 BSC SS7 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figure 19: LAPD Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figure 20: Qmux Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figure 21: ML-PPP Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 22: BSS Transmission Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 23: A9130 BSC Transmission Module with SBL Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 24: NE1oE Traffic Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 25: Alarm Handling on the A Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figure 26: Abis Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figure 27: Logical Parameter Configuration Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figure 28: HCM Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figure 29: BSS SW Package File Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 30: SWMGT Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 31: FM Functional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figure 32: SBL Hierarchy Change Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3BK 20982 AAAA TQZZA Ed.03 5 / 68

Figures
6 / 68 3BK 20982 AAAA TQZZA Ed.03

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 A9130
BSC Evolution also performs functions associated with the General Packet
Radio Service (GPRS).
The information provided is applicable in release B9 of the Alcatel BSS.
What’s New In Edition 03

Description improvement in A9130 BSC PS Functional Description (Section
2.4).
Figure 16 was updated.
In Edition 02
New section A9130 IP Network Overview (Section 1.5) was added.
In Edition 01
First 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.03 7 / 68

Preface
8 / 68 3BK 20982 AAAA TQZZA Ed.03

1 A9130 BSC Overall Description
This section provides an overview of the A9130 Base Station Controller.
3BK 20982 AAAA TQZZA Ed.03 9 / 68

1.1 A9130 BSC Overview

The 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 parameters

The BSC shares resources between circuit switched and packet switched
traffic, according to configuration parameters.
It shields the MSC and the MFS from the radio information, and performs
switching between the radio Traffic Channels (TCHs) and the terrestrial
channels, to the MSC and the MFS.
It manages transmission equipment by performing fault management

and correlation.
From a transmission point of view, the A9130 BSC also performs a
concentration function, therefore allowing more radio TCHs to be connected
to the A9130 BSC than terrestrial channels to the MSC.
The following figure provides an overview of the A9130 BSC in the BSS.
A−GPS server SGSN
SAGI Gb Interface Optional Link
BSS
BSC Site MSC Site

BTS BSC TM
MFS
Terminal Terminal
BTS BSC TC MSC

Abis Ater Mux A Interface
Interface Interface
BSS/CBC BSS/OMC−R Optional Link

Interface Interface
CBC OMC−R
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 / 68 3BK 20982 AAAA TQZZA Ed.03

The A9130 BSC performs the following telecommunication, transmission

and 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 Architecture

The following figure shows the BSC Hardware (HW) architecture on an ATCA
platform.
TP
TP r
SSW CCP
(duplicated)
Mux
CCP y
Radio Network links
LIU
E1 1
OMCPw
LIU n OMCP r
LIU Shelf
(21 slots) ATCA Shelf (14 slots)
External Ethernet Links

r : Redundancy
W : Working
N and y : Network Element capacity
Figure 2: A9130 BSC HW Architecture
3BK 20982 AAAA TQZZA Ed.03 11 / 68

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 (in Allows exchanges between all the OMC-R physical interface
ATCA shelf) elements of the platform and external
CBC physical interface
IP/Ethernet equipment:
Monitoring
Performs Gigabit Ethernet
NEM terminal connection
switching at the shelf level
Performs powerful monitoring for

the user plane and control plane
(Gigabit Ethernet on front panel)
Ensures daisy chain with other

shelves via two 1 Gigabit Ethernet
ports (only one is used)
Ensures multicast function
Allows several external Ethernet

10/100/1000 Base T connections:
OMC-R, CBC, LCS, Debug
Implements 12 non blocking
1Gigabit Ethernet links via
backplane connections
...
The SSW board and all the
connections to the switch are
duplicated to overcome board or
connection failures.
OMCP: O&M Control Processing Is based on ATCA technology O&M logical interface to the
board (in ATCA shelf) equipped with a permanent storage Operation and Maintenance
device. It manages the platform as Center (OMC-R)
system manager, and manages O&M
VCPR: S-CPR & O-CPR
applications.
software + TCH/RM
OMCP boards operate in
TSC software
active-standby mode following
the 1+1 redundancy model.
CCP: Control Processing board (on Is based on ATCA technology used VTCU: TCU software
ATCA shelf) for call control functions. Identical to
VDTC: DTC software
the OMCP board but without a hard
disk.
CCP boards operate in an N + 1
redundancy model. N is the number
of active boards ready to handle
traffic and one standby CCP board
is always available to take over the
traffic of failed board.
12 / 68 3BK 20982 AAAA TQZZA Ed.03

TP GSM: Transmission Processing Provides telecom transmission / HDLC termination

board (in ATCA shelf) transport interfaces to the ATCA
SS7 termination
platform.
NE1oE
Gigabit Ethernet switch
On-board local switch Q1
(separates/aggregates nE1oE Ring control
traffic and IP control traffic).
NE1oE
Transports n x E1 frames in
Ethernet payloads, and is
assigned to a dedicated MAC
address.
Multiplexes/de-multiplexes up to
252 E1
Multiplexes/de-multiplexes up
to 252 E1 from/to the Gigabit
Ethernet Interface (NE1oE).
TDM switch
8 kbit/s synchronous switching
with a total bandwidth of 284 *
2 Mbits (252 external links + 32
internal links toward HDLC, SS7,
Q1 and R/W bits controllers).
Handles low layers of GSM

protocols
LAP-D over HDLC, ML-PPP over
HDLC, SS7, Q1 (= QMUX) and
R/W bits.
Two TPGSM boards are available.
They operate in active-standby mode
following 1+1 redundancy model.
LIU boards (in LIU shelf) Interface for Radio Network links These links correspond to
the user plane interfaces.
MUX board (in LIU shelf)
Ethernet links on IP ports of SSW These links connect the

switch platform to external
IP equipment (OMC-R,
External Alarm Box, etc.).
3BK 20982 AAAA TQZZA Ed.03 13 / 68

LIU Shelf Multiplex/demultiplex which cross E1 physical termination

connects all E1 external links to/from
NE1oE
a NE multiplexed links (n E1 over
Ethernet) at TP and GP board.
It is equipped with 2 x Mux board and
n LIU boards.
ATCA Shelf See above.
Note: Compared to previous generation BSC, the ATCA PF does not provide X.21
interfaces. An X25 over IP link is used for CBC.
1.3 Rack Shared Configurations

Rack shared configuration for A9130 MFSEvolution and A9130 BSC Evolution
consists 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 only
dedicated 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
14 / 68 3BK 20982 AAAA TQZZA Ed.03

Equipment BSC capacity MFS capacity
OMCP 2 2
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 maximum
number of GP is limited to 8 GP instead of 9 GP.
Note: Quantity of TPGSM, OMCP, SSW and MUX boards have to be considered as 1
activ + 1 stand-by for redundancy function per shelf.
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 on
the Linux operating system, the A9130 BSC’s Evolution new software (SW)
architecture uses the best of existing A9120 BSC technology and specific new
features 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.03 15 / 68

The following figure shows the basic software architecture for an ATCA PF.
Equipt
Manager O&M +
Telecom applications
GPRS NE pSOSystem BSC
High Availibility MX
or
MFS Middleware Platform
MXPF Software
TOMAS ( include Endur X +
Middleware GoAhead Self reliant)
& drivers
Carrier Grade LINUX
AdvancedTCA (PICMG 3.x)
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 management

and services via APIs for telecom
application (OMCP, CCP and
TPGSM)
TOMAS System resources management

and services via APIs for telecom
application (OMCP)
GPRS Network Element Communication, telecom

equipment supervision, alarm
collection
Table 1: General Software Architecture of the ATCA PF
16 / 68 3BK 20982 AAAA TQZZA Ed.03

The following figure shows the A9130 BSC SW as seen by the processes.
VCE GSUP
? TP−Main
VCE
VCE
HM −mgt
VCE VCE SUP SUP
? VCE TDM
SUP SUP
VCE
SFT−mgt VCE TP− HDLC
VCE
VCE VCE SLH
CMW CPI SRL CMW CPI SRL CMW CPI SRL
Platform Internal Message TCP/IP ?

? CMW message
CMW
message
? TCP/IP
The process is the basic software element in the A9130 BSC. The process
can be an A9130 BSC application process or a general platform service
process, 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 new
function 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 the
TCP/IP service from Linux. For platform services, the process uses TCP
messages or communication mechanisms provided by SelfReliant. For the
A9130 BSC, the application process handles message routing.
The CPI process converts the application message format to a platform service
message format for communication between the A9130 BSC application
processes 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 by
CMW to be one application process
3BK 20982 AAAA TQZZA Ed.03 17 / 68

1.4.2 Process Mapping on OMCP

The following figure shows process mapping on the OMCP.
V−OCPR
V−SCPR
TSC
TSC
TSC
v−TSC
CMW
TCH −RM
TCH −RM
V−DTC(TCH −RM)
EIM −L
CMW
EIM −R
OMCP
Platform service
CPI
Interthreads Communication Bus
NE1oE SRR/P GSUP/ Init/SW FTP

Agent RMS/H SUP server
PI
HW
Figure 4: Process Mapping on the OMCP
The OMCP board manages O&M functions for both platform and application
processes. Depending on specific BSC application requirements, other
processes are also mapped on OMCP board.
The V-SCPR, the V-OCPR and the V-TSC are the major O&M processes
from A9130 BSC application. These three processes cover all A9130 BSC
application O&M.
The V-DTC (TCH-RM function) is the telecom function process which manages
the 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 processes
developed for the A9130:
The EIM-L/EIM-R are used by the A9130 BSC application to communicate

with 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/SW
and the FTP server are platform service processes. All of these services are
used for O&M management of the ATCA platform. The service covers A9130
HW management, ATCA platform process management, ATCA platform SW
management, ATCA platform installation and initialization, and NE1oE traffic
O&M management.
1.4.3 Process Mapping on CCP

The following figure shows process mapping on the CCP.
18 / 68 3BK 20982 AAAA TQZZA Ed.03

DTC
TCU DTC
TCU DTC
TCU CMW DTC
V−TCU DTC
TCU DTC
V−TCU DTC
V−TCU DTC
V−TCU V−DTC
CCP
Platform service
CPI
Interthreads Communication Bus
SUP Init/SW
Figure 5: Process Mapping on the CCP
The CCP board handles A9130 BSC telecom functions. Compared to the
A9120 BSC, which is a distributed system in that telecom functions are
distributed on the DTC/TCU board, the A9130 BSC centralizes telecom
functions by mixing more V-TCU/V-DTC processes in the CCP boards. In the
CCP 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 the
OMCP, so less platform services run on this board. Only the SUP for process
management and Init SW for software loading are mapped on this board.
The CMW/CPI are the common functions used for communication on every
board.
3BK 20982 AAAA TQZZA Ed.03 19 / 68

1.4.4 Process Mapping on TPGSM

The following figure shows process mapping on the TPGSM.
TP−SS7
CMW
Platform service
CPI TP−Main
Interthread comm. bus Interthread comm. bus
SUP Init/SW Configu Fault Perf. HDLC HDLC TDM QMUX R/W
ration Manag Param. LAPD MLPPP Handler Handler Bits
Handler er Handler Handler Handler Matrix Alarm
Handler Framer Octet
s Handler
Synchr
o
Figure 6: Process Mapping on TPGSM
The TPGSM is the centralized board which handles the lower layer of the
GSM signalling protocol and switching in the A9130 BSC. By definition, 4
main processes run on this board.
The TP-Main is a high level centralized process in the A9130 BSC. It covers
the HDLC, the Qmux, R/W bit handling, ML-PPP switching and the O&M
functions 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, this
process 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 / 68 3BK 20982 AAAA TQZZA Ed.03

1.4.5 A9130 BSC Operating System

MontaVista Linux is the A9130 BSC operating system. This product is the
Commercial-Off-The-Shelf (COTS) industry standard. The Carrier Grade Linux
platform provides specific telecom and datacom functions and provides high
availability, hardening and real-time performance.
The version used in the ATCA platform is MontaVista Linux Carrier Grade
Edition 3.1. This version supports the following Carrier Grade Class application
requirements:
The Carrier Grade Linux-based Operating System and complete

development environment enables faster time-to market and lower
development costs
It is designed for high availability, with support for persistent device naming
and 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 Grade

Linux 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 MontaVista

Runtime 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 Linux
Operating system. They control the common services required for the radio
controller system. The services covered by platform are platform software
installation and initialization, platform software migration, platform HW
management, platform process management and the platform internal network
communication service.
The platform communication service realizes the information exchange in an
A9130 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.03 21 / 68

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 services

and the A9130 BSC application.
1.4.7 A9130 BSC Application Overview

The A9130 BSC application communicates with the GSM radio controller, to
provide both O&M and telecom functions for the BSC.
The application software has been designed to take into account the platform
architecture and A9120 BSC software features.
In the A9130 BSC application, there are two types of process:
The Virtual Operating System (VOS) based application process

The VOS simulates the OSND function of the A9120 BSC. It is integrated
into a Linux process and simulates one A9120 BSC CE. This process is
called Virtual control Element (VCE). Compared to the A9120 BSC, most of
the 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 Init
Variant FMM functions include the different FMM modules, depending on
the application function performed by the VCE.
The Normal Linux process

This is the normal Linux process, without A9120 BSC functions. In the
A9130 BSC, this kind of process is used for the functions introduced by the
ATCA 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 / 68 3BK 20982 AAAA TQZZA Ed.03

1.4.8 A9130 BSC Process Overview

1.4.8.1 V-SCPR Process
The V-SCPR is the application process which simulates the A9120 BSC S-CPR
function. The V-SCPR process running on the OMCP is the hot backup in
both OMCPs.
The V-SCPR is the centralized O&M process in the A9130 BSC. As an external
process, it interfaces directly with the OMC-R and with the A9130 BSC Terminal
for O&M management. Internally, it manages the modification of the DLS,
basing changes on O&M issues, and triggers modules in other VCEs to verify
the 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 Process

The V-OCPR is the application process which simulates the A9120 BSC
O-CPR function. In the A9130 BSC, the V-OCPR is the termination of external
O&M traffic on BSC side. The V-OCPR runs in the OMCP, and is the hot
backup 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 Process

The V-TCU is the application process which simulates the A9120 BSC TCU
function. The V-TCU runs on the CCP board. In the A9130 BSC, the V-TCU is
the 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.03 23 / 68

1.4.8.4 V-DTC Process

The V-DTC is the application process which simulates the DTC function of the
A9120 BSC. It runs on the CCP board.
In the A9130 BSC, the V-DTC is the functional unit which handles the A
interface. Each V-DTC acts as one A-Trunk handler on the BSS side. In
addition, a particular V-DTC, the TCH-RM DTC, provides radio resource
management.
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, depending
on O&M requirements:
The BSSAP V-DTC, the BSSAP/SCCP performs the main functions of the
DTC 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 radio
resources. 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 it
only acts as an A-Trunk Handler.
1.4.8.5 V-TSC Process
The V-TSC is the application process which simulates the TSC function in
the A9120 BSC. Compared to other VCE in the A9130 BSC, the V-TSC is
composed of the VOS library, the V-BootTrap, the CMW API and upper layer
application 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 remote

sites, such as for the TC and the G2BTS
Configuration of remote Transmission NE.
24 / 68 3BK 20982 AAAA TQZZA Ed.03

1.4.8.6 EIM-R
The EIM-R is the application process which manages A9130 BSC external
communication with the CBC and the OMCR. This process runs on OMCP and
is secured by a 1+1 redundancy running on both OMCP.
1.4.8.7 EIM-L
The EIM-L is the application process which manages TCP connection with the
A9130 BSC local terminal. This process runs on OMCP and is secured by a
1+1 redundancy running on both OMCP.
1.4.8.8 TP-Main Process
TP-Main is a A9130 BSC application process which manages the low layer of
transmission 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 Process

The TP-SS7 is the A9130 BSC application process which manages the MTP3
function 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.03 25 / 68

1.5 A9130 IP Network Overview

In order to have an lP network overview of the IP addresses is necessary to
know the following:
BSC – OMCR link type:

Ethernet access see Figure 7
MLPPP over Ater see Figure 8.
IP Addresses for subnetworks A,B,C.
Note: The A,B,C are three defined external subnetworks used for A9130 BSC
Evolution and netmask 255.255.255.248.
Subnetwork A is the one seen from the external equipments.
External subnetworks B and C are visible only at the router’s entrance.
Example of subnetwork IP address: A3 = (last field of IP subnet A address) +
3.
B1 A6 Alarm
Box
OMCP1
A1
SSW1 B6
C1
Router External OMC−R
Network
e.f.g.h p.q.r.s
B2 C6
SSW2
OMCP2 to OMC−R
A2
C2 A3
Figure 7: A9130 BSC Evolution IP Addresses with O&M link via Ethernet
26 / 68 3BK 20982 AAAA TQZZA Ed.03

B1
OMCP1 A6
Alarm
A1 Box
C1
A−terMux A
SSW1
B6 BSS
LIU Transport MSC Router OMCR
Active Network
TPGSM
C6 SSW2
B2
OMCP2
A2
C2
Figure 8: A9130 BSC Evolution IP Addresses with O&M link via Ater
Equipments IP Address in IP Address in IP Address in

Subnet A Subnet B Subnet C
OMCP1 A1 B1 C1
OMCP2 A2 B2 C2
Active OMCP A3 - -
EAB A6 - -
Router / Active - B6 C6
TPGSM
Table 2: A9130 BSC Evolution IP Assignment
3BK 20982 AAAA TQZZA Ed.03 27 / 68

1.6 Configurations
The following table lists the board configurations by shelf.
Equipment BSC Capacity BSC Capacity BSC Capacity

200 TRX 400 TRX 600 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 be
considered to be 1 active + 1 standby to allow for redundancy in the shelf.
28 / 68 3BK 20982 AAAA TQZZA Ed.03

2 A9130 BSC Functional Description
This section describes A9130 BSC functions, according to the type of function
performed:
Telecommunication functions
Operations and Maintenance functions
Transmission functions.
3BK 20982 AAAA TQZZA Ed.03 29 / 68

2.1 A9130 BSC Application Initialization

A9130 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 platform
Power On, by rebooting the whole board.
A9130 BSC Restart ensures that all the A9130 BSC VCE are restarted
without 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 software
image is reloaded from the OMCP. Once this is done, the Linux kernel and
platform services are reinitialized. The A9130 BSC application process on
the board is then recreated.
Application process (VCE) initialization (VCE Reset and Restart).

VCE Reset kills the VCE and recreates it using the platform manager
VCE Restart starts the VCE process by putting the program back to the
beginning 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 the
A9130 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.
30 / 68 3BK 20982 AAAA TQZZA Ed.03

2.1.1 A9130 BSC Application Process Creation

The A9130 BSC application process creation is managed by the PMS platform
service.
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-MR

are 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 the
target board.
2.1.2 VOS Initialization

After the process is created, the VOS is the first element to be initialized. The
initialization 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_Init
sends an Init message to each FMM. This message is distributed by the VOS
to each FMM. On receiving the Init message, each FMM starts initialization at
the FMM level. If initialization is successful, each FMM sends a message back
to FMM_Init to confirm the initialization.
FMM_init consolidates the initialization, confirms reception of the messages
and sends a message to VSCPR to confirm the successful initialization of VCE.
3BK 20982 AAAA TQZZA Ed.03 31 / 68

2.2 A9130 BSC External Communication

A9130 BSC external communication comprises communication with the
OMCR, NEM, BSC terminal and the CBC server.
The following figures show how the external connections are managed in
different connection conditions.
MxBSC OMC−R
APPLICATION APPLICATION
CMISE/ROSE CMISE/ROSE
/ACSE /ACSE
ISO−L5,L6 ISO−L5,L6
ISO_TS ISO_TS
(ON TCP) (ON TCP)
TCP/UDP ROUTER TCP/UDP
IP IP IP IP
Link(802.3a/b) Link(802.3) Link(802.3) Link(802.3a/b)
802.3A/B 802.3A/B
Figure 9: A9130 BSC Connection with OMC-R (Direct IP Connection)
OMC −R
APPLICATION APPLICATION
CMISE/ROSE CMISE/ROSE
/ACSE /ACSE
MxBSC ROUTER
ISO−L5,L6 ISO−L5,L6
ISO_TS ISO_TS
(ON TCP) (ON TCP)
MFS
TCP/UDP TCP/UDP TCP/UDP TCP/UDP
IP IP IP TC/MSC IP IP IP
Link(802.3a/b) Link(802.3) (ML −)PPP (ML −)PPP Link(802.3) Link(802.3a/b)
Serial Link Serial Link Serial Link
Inner LAN
802.3A/B N*64K on Ater V.11/V.28 802.3A/B
Figure 10: A9130 BSC Connection with OMC-R (IP over Ater)
32 / 68 3BK 20982 AAAA TQZZA Ed.03

MxBSC
CBC
IP/X25 Router
SMS−CB SMS−CB
X.25 X.25 X.25 X.25
XOT XOT LAPB LAPB
TCP/UDP TCP/UDP Serial Link Serial Link
IP IP
Link(802.3) Link(802.3
802.3A/B V.11/V.28
Figure 11: A9130 BSC Connection with CBC (Direct IP Connection)
CBC
IP/X.25 ROUTER
SMS−CB SMS−CB
X.25 MxBSC X.25 X.25 X.25
XOT XOT LAPB LAPB
TCP/UDP TCP/UDP Serial Link Serial Link
IP IP IP IP
TC/MSC
Link(802.3) Link(802.3) (ML −)PPP (ML −)PPP
Serial Link Serial Link Serial Link

Inner VLAN
N*64K on Ater V.11/V.28 V.11/V.28
Figure 12: A9130 BSC Connection with CBC (IP over Ater)
Note that in the A9130 BSC application, EIM-R manages communication with
the OMCR/CBC and EIM-L manages communication with A9130 BSC local
terminal. This is shown in the following figure.
L5/L6/L7 L4_Conv
L4Transp X25_PLP
ort
RFC_1006VC XOT_VCE ME_MMC
E
VOS VOS
V−OCPR V−SCPR
CMW API
CMW API
EIM −R EIM −L
External Link
Figure 13: A9130 BSC External Communication Functional Architecture
EIM-R manages the TCP connection with the OMCR or the CBC.
3BK 20982 AAAA TQZZA Ed.03 33 / 68

In V-OCPR, A9120 BSC software is maintained to manage the upper layer of

the OSI stack. RFC_1006VCE manages ISO transport over TCP/IP. L5/L6/L7
and L4/Transp manage communication with the OMC-R. L4_CONV and
X25_PLP (A9120 BSC software), together with XOT_VCE and EIM-R, manage
the 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 the
external connection with the A9130 BSC local terminal.
Communication between the EIM-R/ V-OCPR and the EIM-L/ V-SCPR takes
place over the CMW API. As the messages used for external communication
are all intra-board messages, the CMW routing function between the different
boards is not used by EIM-L and EIM-R.
2.3 A9130 BSC CS Functional Description

The following figure identifies the principle functional blocks in the BSC telecom
part, and shows the main flow of information and control between the modules.
Telecom
OMCP Supervision
Module
SMS−CB
V−SCPR
Master V−OCPR TCH
Resource
Mgt
CCP
Radio Frequency BSSAP
Management SCCP
Device Device
SMS−CB handler Handler
Local
V−DTC
Lapd
V−TCU
TP−GSM Switch
HDLC Management MTP
BTS MSC
Figure 14: Telecom Modules and Corresponding Information Flow
Note: For reasons of clarity, the circuit switched and packet switched parts are
shown 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 terms
of FMM, they can also consist of one or more SSM, despite the code size
limitation (maximum 64kbytes) .
34 / 68 3BK 20982 AAAA TQZZA Ed.03

Distribution of the modules across the processes is determined by the proximity

to the Abis or Ater interfaces or to the SSD. In the A9130 BSC, these processes
are centralized in one processor to reduce unnecessary inter-board message
communication, 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 handle
A interface signalling messages
The V-DTC (TCH-RM) with no A-TRUNK mapped is located in the OMCP to

handle 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 management
Radio management includes SDCCH allocation, TCH allocation and other
Layer 3 message handling. The action can be triggered from an MS or from
the core network. The function is handled by RF-MGT and TCH-RM. When
the A9130 BSC selects one radio resource for an MS, the related Abis
terrestrial resource is also allocated. Radio resource and Abis terrestrial
resource mapping is performed statistically.
A-interface management
The BSSAP is responsible for handling the A-interface messages, which
inform 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 is
defined, switching between the Abis and Ater interfaces is defined by the
TCU-DH, DTC-DH and the switch management service in TPGSM.
DTC-DH handles the CIC information concerning the Ater interface. The
TCU-DH handles the information concerning the Abis transmission resource
for the MS. It sends this information to the DTC-DH. The DTC-DH then
sends the switch commands to the TPGSM switching handler to make the
connection for both the uplink and downlink.
3BK 20982 AAAA TQZZA Ed.03 35 / 68

2.4 A9130 BSC PS Functional Description

The following figure identifies the principle functional blocks in the BSC telecom
part, and shows the main flow of information and control between the modules.
GPRS
OMCP Telecom
Supervision
V−SCPR
TCH
Resource
Mgt
CCP V−TCU GPRS Radio V−DTC

Frequency GPRS APP
Management
Device Device
handler Handler
Lapd
Lapd
TP−GSM Switch
HDLC Management HDLC
BTS MFS
Figure 15: GPRS Telecom Modules and Corresponding Information Flow
Note: For reasons of clarity, the circuit switched and packet switched parts are
shown 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 in
TPGSM 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.
36 / 68 3BK 20982 AAAA TQZZA Ed.03

In general, packet switching in A9130 BSC can be divided into three parts:
GPRS radio resource management
GPRS radio resource is managed by the MFS, but A9130 BSC TCH-RM is
the radio resource master of the cell, responsible for balancing the radio
resource allocated for CS and for PS.
The Gaiter Transmission Resource is managed by the MFS.
Abis Transmission Resource management

The 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 by
TRE Abis allocation. The extra nibbles are also pre-configured but they
are allocated for one BTS and can be dynamically used by any TRX
inside of the BTS.
Compared to A9120 BSC, Abis Transmission Resources are not mapped
to any TCU, and only one TCU(DH) entity is responsible for basic and
extra nibble path setup and release.
Switch management.
When the A9130 BSC is asked by the MFS to set up a PS connection for an
MS, the GIC location is known by DTC-DH. The Abis terrestrial resource
is known by DH-TCU and it forwards this information to DTC-DH. Then it
is up to DH-DTC to command the switching handler in TPGSM to make
the connections for multiple GCHs.
2.5 A9130 BSC Performance Management Description

The following figure shows A9130 BSC performance management.
V−SCPR
X25−LME CPR−N7−LDCP
TCHRM−LDCP
OMCP
Central PM Central RMS

V−DTC(TCH−RM)
TCHRM−LDCP V−OCPR
TCU−TRF−
LDCP DTC−TRF−LDCP
RMS Local
DTC
V−TCU
CCP
HDLC MTP3 TP−GSM
Figure 16: PM Functional Blocks
The Local Data Collector (LDCP) module is a slave module of performance

management located in the same process as the telecom module, so that the
LDCP can retrieve the required counters.
3BK 20982 AAAA TQZZA Ed.03 37 / 68

The PM decomposition broadly follows the same decomposition schema as

that of the telecom module, but with the following additional features that allow
large 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 where

all the LDCP act as slaves to the Central-PM functional block that supervises
and coordinates all activities.
A 15 minute period principle is used in the BSC PM counter collection. Each
slave module saves the counter every 15 minutes. The master triggers the
slave audit every 15 minutes.
Central-PM is responsible for the OMC-R interface, persistency and formatting
of PM files and persistency and management of all PM jobs. These factors
determine its location on the OSI-CPR processors for proximity to the OMC-R
interface, disks for storage and the active-standby operation for fault tolerance.
Specifically for Radio Measurement Statistics (RMS) PM, some dedicated FMM
are created as these measurements originate from the TRE or the BTS.
These require much larger volumes of information to be collected and stored
separately. The TRE needs to have jobs activated and stopped. Measurements
are 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 repository
for forwarding to the OMC-R by Central-PM.
38 / 68 3BK 20982 AAAA TQZZA Ed.03

2.6 A9130 BSC SMS-CB Functional Description

The following figure shows the A9130 BSC SMS-CB functional blocks.
ASN1 SMAP
CONV FUN ME_Maint_CPR
VSCPR
VOCPR
ME_SMSCB_MASTER ME_Alarm−Corre
RMH
PM HSK TRX −Manager
CCP SMSCB−Local RF−MGT
VTCU
LAPD
TPGSM HDLC Handler
BTS1 BTSn
Figure 17: SMS-CB Functional Blocks
The SMS-CB function works in a master-slave relationship in the A9130

BSC. It is composed of two modules:
SMS-CB master
The SMS-CB master is located in the VOCPR in the OMCP, and acts as the
interface towards the convergence function and the SMAP and then to the
operator in the CBC or the OMC-R. It dispatches the commands to the local
SMS-CB for the cell to which the command is applicable.
SMS-CB Local
SMS-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.03 39 / 68

The following remaining modules perform the corresponding functions:

TRX-MGT
TRX-MGT informs the SMS-CB master of the availability of the CBCH
channel, whether it is blocked or unblocked. SMS-CB Master uses this
information to notify CBC whether the cell is operational or not.
HSK
HSK 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-CB
master via messages.
PM
PM interacts with the SMS-CB to periodically poll the master for
the write_load_counter and the kill_load_counter. It manages the
failure_load_counter and the Rejec_load_counter values.
RMH
RMH distributes the message to the other VCE when the message is
greater than 300 bytes.
LAPD
LAPD is the L2 layer for the SMS-CB function which sends the message to
BTS.
RF-MGT
RF-MGT is the SMS message from the BTS. It is received by RF-MGT, then
RF-MGT forwards the message to the local SMS-CB.
SMAP
The SMS-CB master sends and receives messages to/from the OMC-R
via SMAP.
CONV FUN
The SMS-CB master sends and receives messages to/from the CBC via
OCNV FUN.
40 / 68 3BK 20982 AAAA TQZZA Ed.03

2.7 A9130 BSC SS7 Functional Description

The following figure shows the A9130 BSC SS7 functional blocks.
OMCP CCP
VSCPR VDTC
BSSAP
Level 4 SCCP_SCMG SCCP
SLNM SM
CMW CMW
TPGSM SW
Level 3 CMW
TP_SS7 (process)
SLH API
PQ2
Level 2 MTP _2
Level 1 MTP _1
Figure 18: 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 of
modules.
Due to the distributed nature of the BSC concept, the software modules of
the 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 16
N7 links.
The CCITT SCCP can also be split into a centralized function and a distributed
function:
The SCCP management function (SCMG) is a centralized function. It is

handled 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 load
sharing purposes. They reside on VDTC processors.
3BK 20982 AAAA TQZZA Ed.03 41 / 68

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 Description

The following figure shows the A9130 BSC LAPD functional blocks.
CCP CCP
V−TCU V−DTC
L3 layer modules L3 layer
Lapd−L2 Lapd−l2
VOS VOS
CMW CMW
TPGSM SW
CMW
TP_MAIN (process)
HDLC Hanler
TPGSM HW
MTP _2
HDLC
MTP _1
Framer
HDLC
Figure 19: LAPD Functional Blocks
The BSC uses the LAPD protocol for signaling transmission. LAPD is managed
as 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.
42 / 68 3BK 20982 AAAA TQZZA Ed.03

2.9 A9130 BSC Qmux Functional Description

The following figure shows the A9130 BSC Qmux functional blocks.
Alarm Report Alarm Polling Messages Alarm Report

Functions Functions
NE Config NE Configuration Messages NE Config

Functions Functions
Application Data Application Data
Application Layer Application Layer
Qmux Payload Qmux Payload
LLC Layer LLC Layer
Qmux Address+ Qmux Address+

Qmux Payload+PCS Qmux Payload+PCS
Sub Layer 2 Sub Layer 2 Sub Layer 2
Sequence of UART Sequence of UART

Characters including Sequence of UART Characters Characters including
F/C bits including F/C bits F/C bits
CMW CMW Layer 1 Layer 1
Internal Communication Qmux packet

Message (Multiple (UART Characters with
UART Characters) Start/Parity and Stop bit)
TSC on OMCP TPGSM Network Element
Figure 20: Qmux Functional Blocks
In the A9130 BSC, Qmux is a lower layer transmission protocol used to

communicate with NEs in remote sites. This protocol is used by the A9130
BSC to supervise and configure the transmission node of the NE as G2BTS
BIE, ASMC, ATBX DT16 and MT120.
3BK 20982 AAAA TQZZA Ed.03 43 / 68

The Qmux protocol includes 3 layers:

Application layer:
This layer is used to handle VTSC application messages. Two types of
message 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 layer
The LLC sub-layer receives N octets from the Application layers. It
chops these N octets into blocks of 6 bits (eventually completing the
last block with "0"), adds the address (Q blocks of 6 bits) and calculates
the checksum over all the blocks.
Sub-layer 2
The sub-layer 2 takes each block of 6 bits, adds the bits F and C and
transfers this octet to the layer 1.
As in A9130 BSC, the layer function is implemented in TPGSM, so the
layer 1 frames are encapsulated in the TCP message (via CMW) sent to
TPGSM Qmux handler (UART). It is up to the TP Qmux handler to send
and receive the layer 1 frame.
Layer 1
This layer is a 1200 baud asynchronous link over 2 bits carried on a TS of
an E1/T1 link.
The physical level interface describes four main attributes:
Electrical
Functional
Mechanical
Procedural.
44 / 68 3BK 20982 AAAA TQZZA Ed.03

2.10 A9130 BSC ML-PPP Functional Description

The following figure shows the A9130 BSC ML-PPP functional blocks.
BSC
OMC
ATCA Shelf
Router
OM−CP
Appli
TPGSM
Appli IP routing TCP
IP
IP IP
TCP ML−PPP
IP IP IP LiU
ML−PPP MUX LiU PPP PPP PPP
LiU HDLC HDLC HDLC
PPP PPP PPP LiU E1 TDM TDM TDM
HDLC HDLC HDLC E1 E1 E1 MAC MAC
TDM TDM TDM E1
GbE NE1oE NE1oE NE1oE GbE NE1oE
MAC MAC MAC MAC MAC MAC
Figure 21: 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 on
the PPP link. These PPP links are set up over E1.
ML-PPP is implemented in TPGSM as one functional module of the TP-Main
process.
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 PPP
link with a HDLC channel to transfer message flow.
3BK 20982 AAAA TQZZA Ed.03 45 / 68

2.11 A9130 BSC Transmission Function Description

The following figure shows the A9130 BSC transmission functional blocks.
GB interface
SGSN
BTS
MFS/MxMFS
MS
BTS
MxBSC
TC/TC2.5 MSC
MS BTS
BTS
MS
Abis interface
Ater Mux Interffcae
A interface
Figure 22: BSS Transmission Functional Blocks
In the Alcatel BSS, the transmission NEs include the BTS, A9130 BSC, A9120
BSC, MFS, A9130 MFS, TC and TC2.5. Any of these NEs can be selected with
the others to compose the transmission architecture.
As a transmission NE, the A9130 BSC provides BTS to TC access for CS
services and MFS access for PS services.
The A9130 BSC uses the following hardware modules to support the
transmission function:
LIU
MUX
SSW
TPGSM.
The following figure provides an overview of the transmission model.
Other NE of
BSS
T C /TC ATER−HWAY−TP
2. 5 (Unit type=BSC)
TP
GSM
BTS LIU MUX SSW
Abis−HWAY−TP
(Unit type=BSC)
ETU ECU SSW−HW
(Unit type=BSC) (Unit type=BSC) (Unit type=BSC)
TP−HW
(Unit type=BSC)
Mx−BSC site
Figure 23: A9130 BSC Transmission Module with SBL Mapping
In the A9130 BSC, the transmission architecture can be viewed as four major
parts:
46 / 68 3BK 20982 AAAA TQZZA Ed.03

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.
16_E1 interface NE1oE interface NE1oE interface
E1 256
LIU 16
E1 16 MUX SSW TPGSM
LIU 1
MUX
SSW TPGSM
E1 1
E1 and supervision traffic
Supervision traffic
Figure 24: NE1oE Traffic Plane
NE1oE control provides TDM frame transferring inside the A9130 BSC
platform, and user plane supervision and redundancy management.
The NE1oE function uses an Ethernet packet to encapsulate a TDM frame to
transfer 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 is

multiplexed/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.03 47 / 68

2.11.2 Remote Tributary Alarm Management

The following figure shows alarm handling on the A interface.
R/W bit ATBX

Handler
R4 A4 1 0 R2 A2 R1 A1 ATBX
TDM ASMC
Switch RAI RAI
R4 A4 R3 1 R2 A2 R1 A1 ATBX
AIS LIS
ATBX
Figure 25: 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 carry
per Tributary A (AIS) or R(RAI) information in order to make multiplexed links
transparent 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 alarm
and 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 alarm
to 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.
BTS
Star BTS
BTS
MxBSC
BTS BTS Chain
BTS BTS
Ring
BTS BTS
Figure 26: Abis Topologies
48 / 68 3BK 20982 AAAA TQZZA Ed.03

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 a

BTS, 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 and
the 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 Abis
link 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 Qmux
are autonomously managed by TPGSM.
Two modules perform all the actions related to these activities
The ring control module

The ring control module reads the ring control bits from the Abis links in
the ring configuration and decides the transmit and receipt direction for
each BTS. This is materialized at TPGSM level by the orders transmitted
internally to the TPGSM-Switching Handler.
TDM switch control
The TDM switch control module is located in the TPGSM and performs the
actions resulting from the changes detected by the ring control module.
3BK 20982 AAAA TQZZA Ed.03 49 / 68

2.12 A9130 BSC Logical Configuration Management Functional

Description
This figure shows the logical parameter configuration management (CM)
functional blocks.
OMCP
HSK3,3Bis
Telecom Function module
HSK4,4Bi s
A2BS(ssm) FM function modules
HSK5,HSK5bi
s
VSCPR
HSK6.hsk7
VOCPR
VTCU
VDTC
HSK−loc−TCU
HSK−loc−DTC
Telecom function
Telecom function
FM fucntion
FM fucntion
CCP
Figure 27: Logical Parameter Configuration Functional Blocks
Logical Parameter CM manipulates the BSS parameter data in the BSC

database to interact with other BSC functional domains, in order to share the
BSS/Cell data to telecom and fault management functions.
The parameters are categorized into 4 classes:
Per BSS
The logical parameter item has a single value which applies to all BSS NEs
Per BSC
The logical parameter item has a single value which applies to the BSC only
Per BTS
An instance of the logical parameter item exists for each BTS
Per Cell
An 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 on
the VOCPR and the HSK local module on the VTCU and the VDTC. Telecom
functional modules and FM functional modules are the serving objects.
The logical parameter function provides the related configuration data to
telecom and FM modules via messages or via the data base synchronization
mechanism.
50 / 68 3BK 20982 AAAA TQZZA Ed.03

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 the
message 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 related
to 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 is
responsible for building and modifying the local parameters for concerned
TRX which are managed by the VTCU/VDTC.
2.13 A9130 BSC Hardware Configuration Management

Functional Description
This figure shows the Hardware Configuration Management (HCM) functional
blocks for the A9130 BSC.
OMCP
VSCPR ?
ME−TSCM−CPR VTSC
BSC EXT/RED ??
?
?? FM−TRANS TSC APP
BTS EXT/RED
?
L2 layer
? Conf−Trans−TP
BTS−MGT−CPR
?
?
?
VTCU TP−Main(conf)
BTS−MGT−TCU ?
Conf−Trans−loc TP−Main(HDLC) TP−Main(Qmux)
CM −Abis CM −Ater ?
?
TP−GSM
CCP
BTS TC
Figure 28: HCM Functional Blocks
3BK 20982 AAAA TQZZA Ed.03 51 / 68

A9130 BSC HCM comprises the following cases:

A9130 BSC/TC configuration type management
In 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 capacity
extended from 1 * 200 TRX to N * 200 TRX. Depending on the type of
configuration selected, the following components will be changed:
LIU boards
PCM link used for Abis and Ater
CCP boards
TC cluster
From a BSC application point of view, with increasing/decreasing TRX,
the number of VTCU/VDTC will also be increased or decreased. All the
above behavior will be handled by the A9130 BSC extension/reduction
module.
BTS sector configuration
BTS configuration
TRE configuration.
The last three functions listed above are handled by the A9130 BSC BTS-E
extension/reduction module. This module is responsible for the following
functions:
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 A9130
BSC to manage the configuration:
By Qmux to manage the configuration of G2BTS and Transcoder (TC2

or TC2.5)
Configuration of TPGSM
Configuration of BTS via OML.
2.14 A9130 BSC Software Management Functional Description

Software 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).
52 / 68 3BK 20982 AAAA TQZZA Ed.03

2.14.1 BSS SW Package

The following figure shows the file hierarchy for A9130 BSC files.
BSS
Master file
Refers to second level master files
More than
One One One One One One
Mx Platform BSC SW BSC DB BTS SW BTS DB BSS
Master file Master file Master file Master file Master file Map file
Figure 29: BSS SW Package File Hierarchy
BSS Software (SW) is organized by Master File (MF); consequently, the MFs
show the hierarchical structure of the BSC SW.
At the top level, the BSS master file is a sort of super directory that references
the following, second level master files:
BSC SW Master File
This file references all application files that correspond to the BSC software.
BSC DB Master File

This file references the DLS and configuration files of the BSC. It also
references all TC-CPFs and it may reference a steerfile or a command file.
BTS SW Master File

This file references all application files that correspond to the given BTS
software. The number of BTS SW Master Files depends on the different
BTS hardware types and the number of different ciphering algorithms
used by the PLMN network. All BTS SW Master files are referenced in
the BSS Master file.
BTS DB Master File

This file contains the references of all the OMU-CPF files.
BSS Map File

This file defines the reference of the OMU-CPF and the reference of the
BTS SW master file it uses for each BTS.
ATCA Platform Master File

This file has the same structure as the other master files for compatibility
reasons, but only the file name, separator, version and sub-version of the
A9130 OS A9130 PF MF header are taken into account. The A9130 OS
A9130 PF Master File does not contain a file descriptor.
3BK 20982 AAAA TQZZA Ed.03 53 / 68

2.14.2 SWMGT Architecture

The following figure shows the SWMGT functional blocks.
NEM OMC−R
MxBSC O−CPR OSI Stack
other
sub
BSC_SW_REPLACE
systems
S−CPR
Communication Midway
CPI
PMS
SelfReliant HW_MGT
MxPF SWMGT
FTP
CLIENT
Montavisa Linux
Figure 30: SWMGT Functional Blocks
The SWMGT comprises two parts:
BSC
A9130 PF.
The BSC acts as the master of whole scenario. It receives and analyses
the 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 BSC
to OMC-R
The download phase downloads the files required for SW Replacement

from 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.
54 / 68 3BK 20982 AAAA TQZZA Ed.03

2.15 A9130 BSC Fault Management Functional Description

The following figure shows the A9130 BSC Fault Management (FM) functional
blocks.
TRX_MANAGER ALARM
BSC MAINTANANCE TSC MAINTENANCE BTS MAINTENANCE
Figure 31: FM Functional Blocks
A9130 BS FM is divided into functional blocks broadly based on the SBL

or resources that each manages:
TRX Manager
TRX Manager coordinates availability and remapping of all TRX and cell
related resources. It has CM functions as well as FM functions since the
algorithms used often serve both purposes.
A9130 BSC Maintenance

A9130 BSC Maintenance is responsible for all BSC SBL maintenance and
dispatching all SBL related operator commands.
A9130 BSC TSC

A9130 TSC Maintenance is responsible for managing the complete interface
with the TSC.
A9130 BSC BTS Management

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

Alarm is a general service for all BSC functional areas and queues. It
formats and dispatches alarms towards the OMC-R and the LMT.
3BK 20982 AAAA TQZZA Ed.03 55 / 68

56 / 68 3BK 20982 AAAA TQZZA Ed.03

3 Managed Objects and SBLs
Managed Objects and SBLs describes the Managed Objects and the SBLs for
the A9130 BSC and the transmission equipment. It maps Managed Objects
and SBLs to the corresponding RIT.
3BK 20982 AAAA TQZZA Ed.03 57 / 68

3.1 Existing A9120 BSC SBL Status

In order to limit the impact on the SBL hierarchy and to reduce the impact
on the OMC subsystem, the SBL hierarchy remains relatively unchanged
when upgrading from A9120 BSC to A9130 BSC hardware. The following
sub-sections describe the new required BSC model where changes are
required. SBL Hierarchy Change Summary (Section 3.6) describes the final
SBL hierarchy.
In general, for logical SBLs and low level SBLs (SBLs managed by a processor
SBL), 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 IP
interfaces for test and debug and LMT connections, however the physical
interfaces 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 an
OMCP without the disk on the master OMCP. In the case of master OMCP disk
failure, the running application goes to standby and the other OMCP takes over
the master status. In the case of standby OMCP disk failure, it will continue
running in degraded mode (FIT state). If both OMCP have disk failure, the
BSC stops the operation.
The X25 SBL for BSC-CBC communication is maintained. This is because the
failure 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). This
SBL is not used for other purposes.
OMC-BSC communication is based over IP with two options (direct connection
to the switch board SSW of the A9130 BSC or transport of the IP over
ATERMUX, as is the case for the X25 links).
The OMC-BSC communication based on IP does not require a new SBL. It
is only required to supervise the SSW that carries the OMC connection and
report alarms (if any) directly on the SSW SBL. IP redundancy is offered only
at IP transmission level (spread of the ML-PPP link over several Ater links,
multiple access to the IP address). No applicative redundancy is applied.
58 / 68 3BK 20982 AAAA TQZZA Ed.03

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 hardware
no longer exists.
A Restart or Reset of the TCU/DTC/CPR/TSC has been kept to allow the
restart or the reset of a VCE, but the Unlock and Lock commands have no
meaning for these logical SBLs and have been removed.
The target for maintenance operations now includes the CCP and OMCP
processors in its scope. The SBL CP-HW has also been added. The same SBL
is used for the two types of boards.
3.2.1.1 Restart VCE

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

It is proposed that a Reset of TCU/DTC/CPR/TSC SBLs will result in the VCE
process being reloaded and reinitialized from disk (RAM or HARD disk in the
case of OMCP; RAM disk in the case of the other CCP boards). This means
that all context is lost (including the context of the stable calls if applicable). The
VCE application will be informed of the initialization reason (O&M intervention)
by the platform associated initialization service.
3.2.1.3 CP-LOG/VCE Mapping
In order to offer the required maintenance services, it is proposed to introduce
the CP-LOG new SBL type as the father SBL of the corresponding VCE type
SBLs (DTC, TCU, etc.). The mapping between CP-LOG and child VCE will be
autonomously determined by the BSC, depending on the CONFIGURATION
TYPE (typically based on the maximum number of TRX to be managed as
200, 400 or 600 TRX in other releases). It is also proposed to introduce
separate CP-HW SBLs to reflect the CCP HW status and provide a target for
CCP HW maintenance commands.
3BK 20982 AAAA TQZZA Ed.03 59 / 68

The reasons why two SBLs are required are explained as follows, and are
linked to the redundancy scheme of the CCP (N+1 schema):
CP-LOG/VCE Mapping is static

The mapping of VCE TCU/DTC (except TCH-RM) onto CP-LOG will be
pseudo-static (which means that BSC will not dynamically modify this
mapping).
No load balancing among the CCP boards

No performance criteria will be considered dynamically during operation of
the BSC. However the signalling load amongst the CCPs will be balanced
as much as possible during HW extensions.
No differentiation of the CCP boards based on their processing capability
The exact number of VCE mapped initially onto each CP-LOG can depends
on the actual maximum CPU processing capacity of the related CCP
board. This algorithm must take into account the split of the N7-DTC VCE
type between more than one CCP board, in order to ensure BSC-MSC
communication across BSC restarts (splitting these DTC between exactly
two CCP is considered to be reasonable).
OMCP Boards: same model but fixed SBL mapping

The 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 the
ATCA platform). From this point of view, the OMCP is considered as being
represented by the same CP-HW and CP-LOG SBL type as the other
telecom CCP boards. The two OMCP boards are just two instances of the
CP-HW SBL type and can be numbered 1 and 2 in a fixed way for the
A9130 BSC. OMCP will therefore carry (in 1+1 redundancy scheme) the
types S-CPR, O-CPR, TSC and DTC-TCHRM. There will be also two fixed
CP-LOG SBLs respectively mapped to the corresponding two CP-HW SBL
in a fixed way. Note that the OMCP hardware corresponding to the CP-HW
SBL will be reported with a RIT value necessarily different from the RIT
associated with the other CCP boards, due to the fact that the OMCP are
equipped 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 the
SBL numbers 1 and 2).
The new CP-LOG SBL will be dependent on the unique BSC SBL and will
have 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 the
hardware audit. The CP-HW has to be reported in the alarm-state audit
(general audit mechanism rules).
60 / 68 3BK 20982 AAAA TQZZA Ed.03

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

Definition
The following information applies in the case of a (N+1) CCP redundancy
scheme:
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 OS
supporting platform) of any other CP-HW SBL carrying the functions
mapped on a given CP-LOG SBL, the BSC application SW on OMCP
is autonomously notified by the OS platform (failure notification service
offered by the platform).
The application on OMCP will then trigger the platform to start the
application SW on the spare CP-HW SBL with the same list of logical VCEs
as mapped on the impacted CP-LOG SBL. This is how the application and
the platform cooperate to manage the full recovery of the CP-LOG SBL
and its associated functions. The created application processes will be
initialized by the platform service with an explicit indication of the reason for
initialization given by the BSC application on OMCP: switchover after
CCP fatal failure . This is useful in order to start the application on the
spare CP-HW SBL after recovery, to take the appropriate actions.
For example, for TCU and DTC, a force-release of all switched connections
on the active TPGSM board occurs for all involved calls (for more
information, refer to the description of the TPGSM transmission board).
After the new CP-HW SBL has been successfully initialized and has started
operation, the link of the CP-LOG toward the previous CP-HW SBL has to be
broken and changed into a link to the "previously" spare CP-HW SBL. The
previous CP-HW SBL supporting the recovered CP-LOG functions becomes
the new spare CCP hardware for the BSC (but is unavailable as long as
the operator does not repair the corresponding HW board; depending on
the failure, this CP-HW SBL might be in the FLT or FOS state). The whole
set of VCEs (and corresponding DTC and TCU SBLs) of the CP-LOG are
operational again, which means that the new carrying CP-HW SBL, the
CP-LOG SBL and all DTC/TCU SBLs are in IT.
3BK 20982 AAAA TQZZA Ed.03 61 / 68

After takeover, it is easy to inform the OMC about the new logical/physical
mapping via an event alarm and no HW audit is required. This is the main
reason 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-HW
SBL 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 be
calculated by the BSC and reported to the OMC during the BSS discover
operation. This mapping will therefore also be described in a dedicated
parameter group, in addition to the provision as an event alarm, in the case of
a CP-LOG SBL takeover.
The concept of "logical CCP" inherent to the CP-LOG SBL type does not need
to appear explicitly to the operator as it does not supply any additional VCE
function SBLs. In practice, the OMC will provide a functional view (different
groups of VCE running on CCP boards) and an equipment view (the CP-HW
SBL) 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 never
be 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 of
the master/standby status of each physical OMCP board and to notify the
application on the (standby) OMCP. The application on OMCP will switch to
master, inform the platform and the application will manage the rerouting of the
messages 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 also
valid for the O&M OMCPs, however, mapping of the functions is fixed.
As an improvement to the A9120 BSC, it is currently proposed to additionally
report the master/standby status of each OMCP board to the OMC. More
generally, the active/standby indication will be reported for all processing
boards SBLs in a unified manner, with a specific meanings, as described in the
table below. For explanations related to the TP-HW, TP-LOG and for SSW-HW
new SBLs, refer to the corresponding sections in the document.
62 / 68 3BK 20982 AAAA TQZZA Ed.03

After the failed CP-HW SBL has been repaired (and the failed hardware
replaced if necessary) the BSC application SW will report it again as IT in
an end-of-alarm notification to the OMC. This report indicates the same
or possibly a new RIT identity in case of replacement by a board with the
same variant or a different variant, respectively. This CP-HW SBL serves
as the new unique spare CP-HW for all other CP-HW (except the OMCP
type). The current assumption is that all CP-HW SBLs (including the spare
CP-HW) are displayed at the OMC, for maintenance efficacity.
Case of pre-equipped CCP boards

It is possible that the shelf (shelves) of the A9130 BSC have more CCP
boards plugged-in than the strictly required number of boards (for the
running standard configuration). Every extra CCP board is considered to
be a pre-equipped board, in order to later extend the BSC to a higher
configuration 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. the
first discovered running boards) strictly the exact number of CP-HW SBL
required for operation in a given configuration type. The pre-equipped CCP
boards will not be reported to the OMC (despite the fact that the remote
inventory information from the OS platform includes these boards).
In the case one where one or several CCP boards are missing (not
equipped), the A9130 BSC commissioning will fail. The operator must then
install the missing board(s) or start the BSC with a lower configuration
type (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 configuration
type requested and will select these extra boards in the new configuration
(e.g. the first discovered running CCP boards reported by the OS inventory
service).
Management (and reporting) of pre-equipped CCP boards should take into
consideration the necessity for improvement during a later release.
3BK 20982 AAAA TQZZA Ed.03 63 / 68

3.2.3 New SBL Hierarchy for Controlling Elements

The existing TCU, DTC, CPR, TSC SBLs are moved one level downwards in
the SBL hierarchy. All these SBLs are now under this SBL type. Any failure
of the CP-HW SBL will simply result in CP-LOG/CP-HW remapping and the
function SBLs will remain IT. Only double CCP board failures can lead to loss
of CP-LOG and propagation of the SOS state for all dependent VCEs. If
this occurs, the CP-LOG should go to the FLT state so that the BSC will
automatically remap the CP-LOG as soon as a CP-HW becomes available
for carrying the CP-LOG functions.
The new SBL types CP-LOG and CP-HW must be introduced and fully
described in the BSC-CPF. This will create new DLS relations/tuples
accordingly. The SBL has to be managed during extension reduction of the
ATCA 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 terms
of 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 at
the time of BSC migration/installation in a pseudo-static manner but does not
take into account the actual CP-HW processing capacity possibly retrieved
via the IPMI remote inventory service (refer to the OS related SFD for more
information about this service).
The BSC will report (via new event alarm and during audit via new logical
parameter group) the exact CP-LOG/VCE mapping to the OMC.
The proposal for a unique file (and a very different structure) aims at reducing
the impacts on the SDP SW packages (Software Downloadable Packages).
Extensions will be specifically targeted, for example, for going to 600, or later to
1000 TRX managed on the ATCA platform.
For SBL and RIT mapping for the existing A9120 BSC processor SBLs, the
existing definitions in the unique BSC-CPF will not be changed. The BSC
ALARM handling SW will be adapted in order that the RITs are not reported in
the corresponding alarms (test of BSC generation: no suspected RIT sent if
ATCA platform). Failure of a single process is unlikely to occur.
For SBL and RIT mapping for the new CP-HW SBL, the correct and relevant
RIT information will be reported on failures of the CCP boards. The RIT
information (and Rack-Shelf-Slot position) does not need to be described in
the BSC-CPF for the boards. This information will be retrieved via the IPMI
remote inventory service.
64 / 68 3BK 20982 AAAA TQZZA Ed.03

3.3 Replace DSN Network by a Local Ethernet Gbit Network

The corresponding A9120 BSC SBL SWITCH have all been removed
(however they are still in the unique BSC-CPF for the G2 platform). They are
not populated during A9130 BSC extension and reduction. They are also
removed from the skeleton DLS used as input for POLO (creation of a new
A9130 BSC build).
The LINKS SBLs (links between switches in the DSN) internal to the BSC
also no longer exist.
The switch boards’ SSW will obviously be a new SBL (type SSW-HW) to be
reported 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 and
two SBLs) and are possible candidates for managing the shelf in the context of
IPMI. Another possibility is that the shelf manager will consist of independent
separate boards, in which case separate SSM SBLs are needed (two such
SBLs per shelf). The SSW-HW SBLs (and possibly SSM SBLs) appear as
direct children of the BSC SBL (as is the case for the SWITCH SBL in the
A9120 BSC SBL hierarchy).
Each pair of SSW-HW SBL works in active /standby mode of operation or works
in active/active mode of operation. This depends on the manufacturer and the
A9130 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-HW
carries traffic. Lock and Unlock commands are allowed for the SSW-HW SBL
by the OMC or LMT operator (locking the active SSW-HW triggers the platform
to switchover the traffic to the standby board and exchange the master/standby
mode of the two SBLs). The commands are managed by the BSC application.
The ATCA platform offers a service for supporting these maintenance
commands and notifies the BSC application about the master/standby mode of
operation 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 OMC
or LMT operator (locking one of the SSW-HW results in disabling the alarm
reporting from this SSW-HW SBL). The commands are managed by the
BSC application.
For the failure of the Power/Fan, the application will be notified by platform and
an alarm should be reported to the operator.
For the maximum BSC HW configuration, 2*2 such SSW-HW SBL are
populated in the DLS from the BSC CPF file (two shelves maximum).
If failures occur on the several internal links managed by the different SSW-HW
SBL, in the current A9120 BSC, these failures are not reported as failures of
LINKS. Similarly failures of links will be reported on the SSW-HW SBL type for
the new A9130 BSC (including additional information for the precise localization
of the faulty link at the OMC).
As the SSW-HW SBL does not carry BSC application level functions, there is
no need to introduce a logical corresponding SSW-LOG SBL type, as done
for the CP-HW/CP-LOG SBL type.
3BK 20982 AAAA TQZZA Ed.03 65 / 68

3.4 Replace BIUA/ASMB by TPGSM Switching Processors and

E1 Termination Shelf
3.4.1 Maintenance Management View and Impacts on SBL Definition
As a result of software and hardware evolutions, the A9120 BSC multiplexing
boards on the Abis and Ater interfaces have been removed as the
corresponding hardware no longer exists. Therefore, the corresponding 2
BSC-ADAPT and SM-ADAPT [BSC side] SBL types are also removed from the
SBL hierarchy for the A9130 BSC.
The target for maintenance operations now includes the TPGSM and E1 shelf
boards in its scope. In order to offer the required maintenance services, it is
proposed to introduce TP-HW and ETU (E1 Termination Unit) new SBL types.
An ETU SBL represents a number of E1 terminations managed by one adaptor
and the adaptor is supposed to carry power supply (possibly redundant power
supply). The E1 shelf houses a number of fans. These SBL will be dependent
on the unique BSC SBL.
3.4.2 Network Defence (TPGSM Redundancy) View and Impacts on SBL

Definition
The TP runs in a (1+1) redundancy scheme for which the active TP manages
all the E1 links of the A9130 BSS. The other TP is hot standby and does
not manage the E1 links. This means that all highway SBLs (existing
ABIS-HWAY-TP and ATER-HWAY-TP SBLs) are mapped on the active
hardware board TP-HW during operation and are remapped on the other
board in case of takeover (autonomous or triggered by a Lock command from
the operator). As this rule is implicit there is no need to create links of the
highway SBLs to the TP-LOG SBL. The report of the active/standby state of
each 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 alarm
used for CCP takeover. The OMC-R is informed of the active/standby state of
each TP-HW SBL.
During operation the TP-LOG is mapped on the active TP-HW SBL and this
mapping is reported to the OMC. The other TP-HW SBL is standby and has
no TP-LOG mapped. A simple event alarm can be used to notify the OMC
of 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 notification
to the OMC. This report indicates the same or possibly a new RIT identity
in the case of replacement by a board with the same variant or a different
variant, respectively.
The mapping TP-LOG/TP-HW is initially calculated by the BSC and reported
to the OMC during the BSS discover. This mapping will therefore be also
described in a dedicated parameter group, in addition to the provision as an
event alarm in case of a CCP board takeover.
The concept of "logical TPGSM" does not need to appear explicitly to the
operator as it does not provide any additional Hway function SBLs functions. In
practice, the OMC will provide a functional view (*Hway SBLs running on
TPGSM boards ) and an equipment view (the TP-HW SBL), with navigation
links between the two views.
66 / 68 3BK 20982 AAAA TQZZA Ed.03

The OMC identifies the standby TP-HW SBL easily as there is simply no
associated mapped TP-LOG for this SBL. However it is proposed to additionally
report the master/and standby status of each TP-HW SBL to the OMC for
consistency 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 and
The BSC-ADAPT and SM-ADAPT [BSC side] are deleted from the SBL
hierarchy. The TPGSM hardware boards are mapped to the new TP-HW SBL
type (two such SBL exist). Any failure of the active TP-HW SBL will simply
result 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 described
in the BSC-CPF. This will create new DLS relations/tuples accordingly.
The BSC will report (via new event alarm and during audit via new logical
parameter group) the exact TP-LOG/ TP-HW mapping to the OMC, along with
the master/standby state of each TP-HW SBL.
All configurations are part of the unique BSC-CPF needed in the BSC package
of 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 relevant
RIT information will be reported on failures of the TP-HW SBL. The RIT
information (and Rack-Shelf-Slot position) does not need to be described in the
BSC-CPF for the TP-HW SBL. This information will be retrieved via the IPMI
remote 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 model
will be defied at a later date.
3.5 Other Equipment

The following remaining A9120 BSC HW specific SBLs must be completely
removed 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 (power
supplies, fans, converters, batteries, etc.) are monitored by the ATCA platform
and autonomous notifications are sent to the BSC application software. The
BSC will be responsible for forwarding these alarms in a proper format to
the OMC. All alarms are then mapped on the BSC SBL and the SBL state
is systematically set to FIT. The state is returned to IT when all concerned
alarms have been cleared (and correlated in the BSC central alarm manager
on the OMCP).
Note: The CLOCK alarms (the clock is used mainly by the TPGSM transmission NE
and by the MFS) are sent to the BSC application and reported by the BSC to
the OMC in the same way (BSC SBL alarm with explicit additional information).
3BK 20982 AAAA TQZZA Ed.03 67 / 68

3.6 SBL Hierarchy Change Summary

The following figure summarizes the changes in the hierarchy of the SBLs
controlled by the BSC and the TSC.
BSC
CP−HW* CP−LOG
* TP−HW
* ETU
* TP−LOG SSW−HW
*
* * * *
DTC * TCU CPR
* TSC ABIS−HWAY−TP ATER−HWAY−TP
(Unite Type−BSC) (Unite Type−BSC)
ATR
BSS−Tel BTS−OM*
ACH N7 GSL RSL* *

OML X25
BTS−Tel * TR−OM
Figure 32: SBL Hierarchy Change Summary
68 / 68 3BK 20982 AAAA TQZZA Ed.03

A9130 BSC Evolution Funtional Description

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A9130 BSC Evolution Funtional Description

Uploaded by

Copyright:

Available Formats

Alcatel BSS

A9130 BSC Evolution

BSC & TC Document

3BK 20982 AAAA TQZZA Ed.03

Short title A9130 BSC FD

2 / 68 3BK 20982 AAAA TQZZA Ed.03

3BK 20982 AAAA TQZZA Ed.03 3 / 68

3.5 Other Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4 / 68 3BK 20982 AAAA TQZZA Ed.03

3BK 20982 AAAA TQZZA Ed.03 5 / 68

6 / 68 3BK 20982 AAAA TQZZA Ed.03

What’s New In Edition 03

Audience This document is intended for:

System support engineers

3BK 20982 AAAA TQZZA Ed.03 7 / 68

8 / 68 3BK 20982 AAAA TQZZA Ed.03

1 A9130 BSC Overall Description

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

3BK 20982 AAAA TQZZA Ed.03 9 / 68

1.1 A9130 BSC Overview

It manages the radio resources and radio parameters

It manages transmission equipment by performing fault management

A−GPS server SGSN

SAGI Gb Interface Optional Link

BSC Site MSC Site

BTS BSC TC MSC

BSS/CBC BSS/OMC−R Optional Link

BTS : Base Transceiver Station

10 / 68 3BK 20982 AAAA TQZZA Ed.03

The A9130 BSC performs the following telecommunication, transmission

Provides signaling links to the MSC

Performs signaling control for the MFS links

Routes traffic between the MFS and the BTS

Provides O&M facilities.

1.2 A9130 BSC Hardware Architecture

External Ethernet Links

3BK 20982 AAAA TQZZA Ed.03 11 / 68

Name Functional block mapped on board Existing function for BSC

Performs powerful monitoring for

Ensures daisy chain with other

Ensures multicast function

Allows several external Ethernet

12 / 68 3BK 20982 AAAA TQZZA Ed.03

Name Functional block mapped on board Existing function for BSC

TP GSM: Transmission Processing Provides telecom transmission / HDLC termination

Handles low layers of GSM

MUX board (in LIU shelf)

Ethernet links on IP ports of SSW These links connect the

3BK 20982 AAAA TQZZA Ed.03 13 / 68

Name Functional block mapped on board Existing function for BSC

LIU Shelf Multiplex/demultiplex which cross E1 physical termination

ATCA Shelf See above.

1.3 Rack Shared Configurations

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

2 x independent BSC configurations in the same cabinet.

1.3.1 Rack Shared by A9130 BSC Evolution - A9130 MFS Evolution

Equipment BSC capacity MFS capacity

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

14 / 68 3BK 20982 AAAA TQZZA Ed.03

Equipment BSC capacity MFS capacity

1.3.2 Rack Shared by Two A9130 BSCs Evolution

1.4 A9130 BSC Software Architecture

The user plane and the control plane are redundant