MFS 9130 Functional Description

Alcatel-Lucent GSM
A9130 MFS Evolution Functional

Description
MFS Document
Sub-System Description
Release B10
3BK 21272 AAAA TQZZA Ed.04
BLANK PAGE BREAK
Status
RELEASED
Short title
mxmfsfun
All rights reserved. Passing on and copying of this document, use
and communication of its contents not permitted without written
authorization from Alcatel.
2 / 62
Contents
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1
Introduction to MFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1
(E)GPRS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.2
MFS Position in Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.3
A9130 MFS Evolution Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1
External Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2
Basic Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.3
Detailed Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.4
Internal Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.5
Synchronization of A9130 MFS Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.6
Installation and Maintenance Terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.7
Connection with the OMC-R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3
Traffic and Signaling Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1
Physical Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2
Packet Data Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.3
Temporary Block Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.4
NC2 in Packet Transfer Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.5
Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4
GPRS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1
GP Telecommunications Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.2
MFS O&M Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5
SMLC Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managed Objects and SBLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1
MFS Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1
MFS Managed Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2
MFS Managed Object Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3
MFS Managed Object Supported States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.4
MFS Managed Object Supported Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.5
MFS FRUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
MFS Managed Object Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2
Global Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3
Communication Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4
Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1
GOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.2
GAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.3
GEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.4
GPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.5
GLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.6
GHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.7
Q3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.8
BAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.9
Telecom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.10
PM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.11
SCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.12
LRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
9
10
10
11
12
14
14
16
19
23
24
26
26
27
29
30
31
31
31
32
32
38
39
41
42
42
44
45
47
49
50
53
54
55
56
59
59
60
60
61
61
61
61
61
62
62
62
62
3 / 62
Figures
Figures
Figure 1: MFS Position in Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 2: External MFS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 3: A9130 MFS Evolution Basic Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 4: A9130 MFS Evolution One Shelf Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 5: A9130 MFS Evolution Two Shelves Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 6: Detailed A9130 MFS Evolution Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figure 7: Traffic and Signaling Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 8: PDCH Air Interface Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 9: Air Interface Block Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 10: Dynamic PDCH Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figure 11: Hierarchy of MFS Managed Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 12: Main Software Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 13: O&M Global Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figure 14: MFS Agents and Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4 / 62
Tables
Tables
Table 1: Standard (E)GPRS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Table 2: Traffic and Signaling Link Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Table 3: Packet Data Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Table 4: MFS Managed Object Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Table 5: Supported States of MFS Managed Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Table 6: Supported Operations of MFS Managed Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Table 7: MFS FRUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Table 8: MFS Managed Object Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5 / 62
Tables
6 / 62
Preface
Preface
Purpose
Whats New
This document describes the functions and software of the A9130 MFS
Evolution.
In Edition 04
Description improvement in A9130 MFS Evolution Configurations (Section
1.1.3).
In Edition 03
The following sections were updated due to new Gb routing configurations:
Synchronization of A9130 MFS Evolution (Section 1.2.5)
External Interfaces (Section 1.2.1)
MFS-SGSN Interface (Section 1.2.1.4)
MFS-OMC-R Interface (Section 1.2.1.5)
Detailed Architecture (Section 1.2.3)
Description improvement in Rack Shared by A9130 BSC Evolution- A9130
MFS Evolution (Section 1.1.3.1).
First release of the document.
In Edition 02
Description improvement in:
Rack Shared by A9130 BSC Evolution- A9130 MFS Evolution (Section
1.1.3.1)
Synchronization of A9130 MFS Evolution (Section 1.2.5).
In Edition 01
First release of the document.
7 / 62
Preface
Audience
This manual is intended for:

Commissioning personnel
Support and service engineers
OMC-R operators
Training department.
Assumed Knowledge
8 / 62
The reader must have a general knowledge of telecommunications systems,

terminology and Alcatel BSS functions.
1 Functional Description
This section describes the A9130 MFS Evolution architecture, functions and
features.
9 / 62
1.1 Introduction to MFS

General Packet Radio Service (GPRS) extends the circuit-switched voice and
data capabilities of a GSM network to include high speed packet-switched data.
An MS that is fitted with the (E)GPRS facility can transmit and receive data up
to an approximate theoretical maximum of 210 kbit/s.
The following sections describe:
(E)GPRS functions
MFS position in network
Configurations.
1.1.1 (E)GPRS Functions

Within the Alcatel (E)GPRS implementation, a new network element is added
to the BSS. This is the MFS which performs the GSM-defined GPRS Packet
Control Unit function. The table below lists the standard (E)GPRS functions
and shows where they are implemented. Implementation consists of software
only, or both software and hardware.
Function
BTS
MFS
SGSN
GGSN
CCU
software
PCU
software and
hardware
SGSN
software and
hardware
GGSN
software and
hardware
Gb Stack
software and
hardware
software and
hardware
Table 1: Standard (E)GPRS Functions
10 / 62
1.1.2 MFS Position in Network

The position of the MFS within the Alcatel BSS is shown in the figure below.
To Public Data
To Networks
Public Data
Networks
OMCR
Gb
Gb
MS
SGSN
PS Traffic
SAGI
BSS
MFS
AGPS
AGPS
Server
Server
GGSN
Gb
BSS
BTS
CS
Traffic
Ater Mux
Abis
BSC
BTS
TC
Ater Mux
BTS
: Base Station Subsystem
BSC
: Base Station Controller
MFS
: Multi Function Server
TC
: Transcoder
MSC
: Mobile Switching Center
OMC-R
: A1353-RA Operations and Maintenance Center-Radio
SGSN
: Serving GPRS Support Node
GGSN
: Gateway GPRS Support Node
A-GPS
: Assisted GPS
SAGI
: SMLC A-GPS Interface
Gb
: MFS/SGSN Interface
CS
: Circuit-Switched Traffic
PS
: Packet-Switched Traffic
PSTN
To PSTN
: Base Transceiver Station
BSS
MSC
: Public Switched Telephone Network
Figure 1: MFS Position in Network

The MFS supports multiple BSSs and MSCs. An MFS can be connected to
several SGSNs. Several MFSs can be connected to the same OMC-R.
Circuit-switched traffic is handled in the usual way by the MSC and the BSC.
The link between the BSC and TC can only carry circuit-switched traffic. A
link going through the MFS can contain circuit-switched, circuit-switched and
packet-switched, or packet-switched traffic.
In the uplink direction, packet-switched data from the MS are sent to the MFS
as blocks which are assembled into packets. Depending on the coding scheme
in use, a block can consist of 20 or 30 bytes. When all the bytes have been
received, they are placed into packets of up to 1500 bytes for transmission
to the SGSN via the Gb Interface. In the downlink direction, packets are
disassembled in the MFS and sent to the MS as blocks of 20 or 30 bytes.
11 / 62
Other GPRS network elements are:

The Serving GPRS Support Node (SGSN) - provides the BSS with mobile
packet switching functions, including security and an interface to the HLR.
The SMLC, a new functional NE in the BSS, is integrated into the MFS and
configured by the OMC-R. In the same way that the MFS provides the
GPRS services to several BSCs, the SMLC performs locations services
for the same set of BSCs.
The Gateway GPRS Support Node (GGSN) - provides interworking with
external packet-switched networks.
1.1.3 A9130 MFS Evolution Configurations

A9130 MFS Evolution configurations can by defined based on the number of
used shelves or based on the number of TTPs supported by one GP board.
Based on the number of used shelves the following configurations can be
defined:
Two shelves configuration
One shelf configuration not extensible, with one shelf supporting up to
8+1 GP boards. In this configuration each GP board can manage up to
16 E1/GP in autonomous clock synchronization mode or 14 E1/GP in
centralized clock synchronization mode. It is not possible to move to the two
shelves configuration without a complete restart of the MFS in configuration
mode. The main goal of this configuration is to allow a smooth migration to
rack shared configuration.
One shelf configuration, with one shelf supporting up to 9+1 GP boards.
In this configuration each GP board can manage up to 12 E1/GP
in autonomous clock synchronization mode or in centralized clock
synchronization mode. Such a configuration allows a smooth migration to
the two shelves configuration without outage.
Based on the number of the TTPs supported by each GP board the following
configurations can be defined:
12 TTPs per GP
This configuration allows supporting up to two subracks with smooth
extension when going from one to two subracks.
14 TTPs per GP
This configuration is used for MFS in centralized clock synchronization
mode. The centralized clock distribution can be needed in case the MFS is
connected to a A9120 BSC of another site. In this case, centralized clock
allows saving an E1 link.
16 TTPs per GP
This configuration is used for MFS in autonomous clock synchronization
mode. The autonomous clock is enough in case the MFS is not connected
to a A9120 BSC of another site. Contrary to clock centralized mode, the
autonomous mode allows 16 TTPs connectivity.
12 / 62
Rack shared configuration for A9130 MFS Evolution 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 MFS Evoltion or A9120 MFS Evolution). (MFS NE is not fully
or only dedicated to BSC traffic located in the same rack).
1.1.3.1 Rack Shared by A9130 BSC Evolution- A9130 MFS Evolution

You can follow the board configurations in shelves in next table.
Equipment BSC capacity
200TRX
MFS capacity
400TRX
600TRX
800TRX
1000TRX
"9 GP" (*)
ATCA
Shelf
CCP
NA
SPARE
CCP
NA
TPGSM
NA
GP
NA
1 to 9(*)
SPARE GP
NA
OMCP
SSW
LIU Shelf
MUX
LIU
*
16
16
16
: 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.1.3.2 Rack Shared by Two A9130 BSC Evolution

Board configurations in each ATCA and LIU shelf are identical to single BSC.
13 / 62
1.2 Functional Architecture

This section describes the MFS functional architecture in terms of:
External Interfaces
Basic architecture
Detailed architecture
1.2.1 External Interfaces

The external MFS interfaces are shown in the figure below.
AGPS
Server
Ethernet Link
PCM Links
Ater Mux Interface
PCM Links
BSC
Ater Mux
Interface
Ater Mux + Gb Interface

Gb Interface
TC
MSC
FR Network
MFS
BSC
Gb Interface
Gb Interface
Ater Mux
Interface
Gb Interface
IP Network
SGSN
(Ethernet Link)
IP Network
O&M
(Ethernet Link)
Ethernet Link
IMT
OMCR
IMT (Installation and Maintenance Terminal)
Figure 2: External MFS Interfaces
1.2.1.1 MFS-BSC Interface

The interface between the MFS and the BSC (Ater Mux interface) is a 2 Mbit/s
PCM link. The time slots within one link can carry both circuit-switched and
packet-switched traffic and SS7 signaling.
When the Ater Mux is mixed circuit-switched/packet-switched, the MFS
transparently connects the circuit-switched time slots to the TC and converts
the packet-switched time slots into the Gb interface protocol which is forwarded
to the SGSN through the TC and MSC or through the MSC.
When the Ater Mux is fully packet-switched, the Gb traffic is forwarded directly
to the SGSN when there is a dedicated MFS-SGSN link (over a FR network
or over an IP network) or through the MSC when there is no dedicated
MFS-SGSN link.
The BSCLP interface is an Lb based protocol that allows communication
between the BSC and SMLC in a circuit-switched domain.
14 / 62
1.2.1.2 MFS-TC Interface

The interface between the MFS and the TC (Ater Mux interface) is a 2 Mbit/s
PCM link.
This link can be:
Fully devoted to carry circuit-switched time slots
Fully devoted to carry the Gb interface and GSL on packet-switched time
slots
A mixed circuit-switched/packet-switched interface on the same Ater Mux.
1.2.1.3 MFS-MSC Interface

The interface between the MFS and the MSC is used to carry the Gb interface
when there is no dedicated MFS-SGSN link.
1.2.1.4 MFS-SGSN Interface

The interface between the MFS and the SGSN is used to carry the Gb interface.
The Gb interface can be forwarded to the SGSN on one of the following paths:
MFS -> TC -> SGSN
MFS -> TC -> MSC -> SGSN
MFS -> MSC -> SGSN
MFS -> SGSN direct connection over a Frame Relay network
MFS -> SGSN direct connection over an IP network
1.2.1.5 MFS-OMC-R Interface

The OMC-R is connected to the MFS via an Ethernet link. The OMC-R can be
collocated with the MFS or remote.
1.2.1.6 MFS-IMT Interface

An Ethernet link is used to connect the Installation and Maintenance Terminal
to the MFS. MFS commissioning and local management are performed using
the maintenance terminal.
1.2.1.7 MFS-A-GPS Server Interface (SAGI)

The SAGI interface is an Lb interface on TCP/IP that exchanges messages
between the SMLC and the external A-GPS server following an Assisted GPS
positioning request in the circuit-switched domain.
15 / 62
1.2.2 Basic Architecture

Functional blocks architecture of the A9130 MFS Evolution is shown in the
figure bellow:
MFS
E1 Boards
SSW
O&M
GP
GP
Figure 3: A9130 MFS Evolution Basic Architecture

A9130 MFS Evolution architecture is based on ATCA standards.
There are two possible configurations for A9130 MFS Evolution:
With 1 ATCA shelf
With 2 ATCA shelves.
The basic ATCA shelf contains:
4 FAN - Fan trays
4 PEM - Power Entry Modules
2 SHMC - Shelf Manager Boards
2 PC - Personnality Cards
Following ATCA modules are contained in the A9130 MFS Evolution shelves:
First ATCA shelf (shelf 3) contains always:
2 SSW - Gigabit Ethernet Switch Boards
2 OMCP - O&M Control Boards
Up to 10 GP - GP Radio Processing Boards
Second ATCA shelf (shelf 4) contains always:
2 SSW - Gigabit Ethernet Switch Boards
No OMCP - O&M Control Boards
Up to 12 GP - GP Radio Processing Boards
16 / 62
LIU shelf contains:

Up to 16 LIU boards - E1 Termination Boards
2 MUX - Multiplexing Boards
2 PEM - Power Entry Modules.
Note:
Quantity of OMCP, SSW, SHMC, PC and MUX boards have to be considered

as 1 activ + 1 stand-by for redundancy function per shelf.
PDU
Free space
(ATCA Shelf 4)
OPEN
OPEN
GP
GP
GP
H/S OOS
GP
H/S OOS
GP
SSW
OMCP
CLOSED
SSW
H/S OOS
GP
OPEN
OMCP
GP
CLOSED
GP
H/S OOS
GP
OPEN
CLOSED
ATCA
Shelf 3
GP
CLOSED
1234567890123456789
1234567890123456789
Air inlet
1234567890123456789
1234567890123456789
Free space
(LIU Shelf 2)
XPEM
LIU
Shelf 1
48 / 60
VDC
XLIU
XLIU
XLIU
XLIU
XLIU
XLIU
XLIU
XLIU
XMUX
XMUX
XDUM
XDUM
XDUM
XDUM
XDUM
XDUM
XDUM
XDUM
XPEM
48 / 60
VDC
4A
4A
Figure 4: A9130 MFS Evolution One Shelf Configuration
17 / 62
PDU
CLOSED
OPEN
H/S OOS
CLOSED
CLOSED
OPEN
H/S OOS
CLOSED
OPEN
H/S OOS
OPEN
H/S OOS
GP
GP
GP
GP
GP
GP
SSW
SSW
GP
GP
GP
GP
GP
GP
ATCA
Shelf 4
1234567890123456789
1234567890123456789
Air Inlet
1234567890123456789
1234567890123456789
CLOSED
OPEN
H/S OOS
CLOSED
OPEN
H/S OOS
OPEN
H/S OOS
GP
OMCP
SSW
OMCP
GP
GP
GP
GP
GP
ATCA
Shelf 3
GP
CLOSED
GP
H/S OOS
GP
OPEN
GP
SSW
CLOSED
1234567890123456789
1234567890123456789
Air Inlet
1234567890123456789
1234567890123456789
Free space
(LIU Shelf 2)
XPEM
XLIU
XLIU
XLIU
XLIU
XLIU
XLIU
XLIU
XLIU
XMUX
XMUX
XLIU
XLIU
XLIU
XLIU
XLIU
XLIU
XLIU
XLIU
XPEM
LIU
Shelf 1
48 / 60
VDC
48 / 60
VDC
4A
4A
Figure 5: A9130 MFS Evolution Two Shelves Configuration
18 / 62
1.2.3 Detailed Architecture

The A9130 MFS Evolution detailed architecture is shown in the figure below.
Most of the boards have a prefix in their names. Refer to section 2.1.5 for
naming information.
To PDU
DC Power
PEM01
PEM02
PC01
SHMC01
Console
link
PC02
SHMC02
Console
link
1n
GP
OMCP01
OMCR
AGPS
IMT PC
SGSN
OMCP02
RTM
Switch
Switch
Board
Switch
Board
RTM
Switch
RSSW01
SSW01
SSW02
RSSW02
OMCR
AGPS
IMT PC
SGSN
ATCA Shelf
LIU Shelf
MUX
18
Ater
Gb
MUX
9 16
LIU
LIU
PEM
Ater
Gb
PEM
To PDU
DC Power
Figure 6: Detailed A9130 MFS Evolution Architecture
19 / 62
1.2.3.1 OMCP
The O&M Control Processing board is based on ATCA technology. This board
is equipped with a permanent storage device and is in charge of managing the
O&M applications and whole platform as system manager.
There are two ATCA OMCP boards in the MFS, working in an active/standby
mode. They ensure the interface to the OMC-R.
The active OMCP board manages a set of GP boards, each of them responsible
at least for GPRS functions in one BSS (routing of LLC PDUs from SGSN
towards the BTS and MS through the BSC or vice-versa).
The active OMCP is responsible for the management of the E1 MUX boards
too. The E1 links are terminated in the E1 Termination boards and processed
by one or several GP boards.
In A9130 MFS Evolution, there are no shared disks. System data and Telecom
data are stored in the single local disk of the OMCP with TOMAS network
mirroring, in order to secure data on the peer OMCP board. This solution is
based on LVM (Logical Volume Management ) and ext3 Linux partitions.
1.2.3.2 GP
The GP board implements the telecommunication function, same as previous
GPU in A9135 MFS, and the NE1oE function. Also compared to the GPU in
A9135 MFS the processing capacity of the GP board has increased by four
times. It means, for example, that the GP can now handle 960 PDCHs instead
of 240 PDCHs.
GP Radio Processing boards manage the user plane packet data flow
processing. The GP boards send/receive their E1 links over Ethernet to/from
the LIU shelf.
The GP boards of the same BSS communicate each other using UDP protocol.
The E1 traffic is routed towards the GP board through the Ethernet switch
using the NE1oE protocol.
The GP board provides following functions:
Handling of GPRS packets
Management of the Frame Relay or UDP/IP for Gb interface
Management of the GSL interfaces
Management of Ater interface
Providing the physical termination of 12/14/16 E1 interfaces of the board
Ater&GB interfaces
Interface for hardware management services
Switches between data and control Ethernet frames
Emission/reception of the E1 link over Ethernet.
The protection offered by the equipment manager of the A9130 MFS Evolution
is a n+1 protection, that is n active GP boards and 1 standby (spare) GP
board. The spare GP is designated for both ATCA shelves. The spare GP is
considered as a floating spare during MFS operation.
When a hardware fault occurs on an active board, an automatic switch-over is
triggered. No outage of the speech traffic occurs. The former active board
will be automatically elected standby and can take over any GP of the MFS
20 / 62
rack in case of hardware failure. In this context the switch back administrative
request is no longer needed.
1.2.3.3 SSW
SSW is a Gigabit Ethernet switch which allows exchanges between all the
elements of the platform and external IP/Ethernet equipment.
Its functions are:
OMC-R physical interface
A-GPS server physical interface
LIU shelf connection
Monitoring local terminal connection.
The SSW boards are using a 1+1 securization scheme.The SSW boards
operate simultaneously (as the TOMAS secured LSN) , i.e. the paths to the
LIUs are available through both boards; so the switch can be solved internally
and very quickly (i.e. transparently, in term of service), by sending again a
not acknowledged message through the other path. This should not induce
any telecom outage.
1.2.3.4 SHMC
Two shelf management modules are implemented in the ATCA shelf: one
active, and one backup for redundancy reasons.
The SHMC functions are defined as following:
ATCA boards power-up and boot
Configuration of the various electronically keyed interfaces within the ATCA
shelf: Base interface, Fabric interface, Update interface, Synchronization
clock.
Monitors, controls, and ensures proper operation of ATCA boards and
other shelf components
Watches over the basic health of the system, reports anomalies, and
takes corrective action when needed
Retrieves inventory information and sensor readings as well as receive
event reports and failure notifications from boards and other intelligent FRUs
Performs basic recovery operations such as power cycle or reset of
managed entities
Provides low-level hardware management services to manage the power,
cooling, and interconnect resources of a shelf
Communicates with the System Manager implemented in the OMCP board.
1.2.3.5 PC
The Shelf Personnality Card (PC) is a general purpose device to provide all the
functions that may not be included by the other Field Replaceable Units (FRUs).
PC provides following functions:
Contains the Shelf FRU Information Store
21 / 62
Contains rotary switches for setting SGAs

Provides HA, SGA and configuration bit inputs
Provides interfaces for up to two filter switches and four temperature
sensors, for example, air inlet
Provides Telco alarming, that is, relay outputs for major, minor, and critical
errors and up to four opto-isolated inputs
Visualizes the states and alarms via LEDs on the front panel
Provides interface to IPMB0-A and IPMB0-B.
1.2.3.6 ATCA PEM

Two (and optionally four) field hot-swap intelligent PEMs with a 90 Amp
(50 Amp) breaker and line filter are installed beneath the rear slots of the
backplane. The current of the two PEM versions have a 90 Amp breaker. Two
PEMs are used to feed all redundant FRUs. Four PEMs are used to provide
split power distribution, each of which has a 50 Amp breaker.
The PEMs provide the following features and functions:
Redundancy so that a single PEM failure will still provide full power to
the system
Hot-swap
Providing monitoring information to the shelf manager
Power feed voltage and current measurement
Temperature sensing
Power filtering
IPMC for input power monitoring within the power distribution path.
1.2.3.7 FAN
The FAN unit provides ventilation for the subrack.
Each FAN tray monitors and reports air temperature and failure conditions to
the shelf manager. The shelf manager controls the FAN speed based on
sensor and failure information acquired from the FAN and board sensors. If a
FAN tray loses IPMI communication with the shelf manager, it will automatically
run the FANs at full speed.
1.2.3.8 LIU Boards - E1 Termination Boards

LIU boards are considered the boards in a specific shelf - the LIU shelf.
LIU shelf is equipped with two Mux boards and n (maximum 16) LIU boards, in
accordance with the capacity of the A9130 MFS Evolution.
LIU shelf manages the multiplexing/demultiplexing and cross-connecting of all
E1 external links toward or from a GP board (n E1 over Ethernet).
Incoming/outgoing PCMTTPs are connected to the boards located on the
LIU shelf, independently of GP boards. Therefore, there is no more a fixed
association between external (through LIUs) TPs (on the E1 termination
boards) and GP boards. These associations between GP TPs and LIU TPs (via
SSW boards switched connections), have to be defined through configuration
directives (BUL files).
22 / 62
1.2.3.9 LIU MUX

The LIU MUX board, part of the LIU shelf, ensures the concentration of 256 E1
PCM links onto a Gb Ethernet external interface.
This board realizes the following functions:
Multiplexing and de-multiplexing of up to 16 E1 trunks (1 per LIU board)
for a total capacity of 256 E1 lines
Overall BSC/ MFS timing synchronization generation through NE1oE
mechanism
NE1oE packing/unpacking
Control, supervision and data frames management through the GbE link
Control management and supervision of LIU boards in connection with
1 GbE physical interface
Active/standby communication link with the second MUX board for 1+1
protection purpose
Debug interface
Remote inventory data storage
Hot insertion.
1.2.3.10 LIU PEM

The LIU PEM board assumes the powering of the LIU shelf.
The PEM board functions are:
EMI filter
DC/DC converter with basic insulation (-40/72VDC into +12Vdc)
Alarm connection
Temperature detection
RI EEPROM
Current limitation device for hot insertion.
1.2.4 Internal Interfaces

Communication between boards is performed via the redundant Giga bit
Ethernet interface. It defines a private network including two independent
sub-nets.
A9130 MFS Evolution relies on the double Ethernet and supervision
management provided by TOMAS.
Following protocols are used on A9130 MFS Evolution:
CS layer (TOMAS) over TCP for OMCP/GP communication
RMCP/SNMP for hardware management through A9130 MFS Evolution
services
OMCP management of E1 boards using A9130 MFS Evolution services:
23 / 62
RI management
Basic supervision
Configuration of the mapping physical E1/virtual E1 of the GP boards
Clock synchronization configuration
NE1oE over Ethernet for GP/E1 boards communication (telecom
signaling and traffic).
The NE1 over Ethernet module in the GP board provides the transport of the
E1 links payload over a Giga Ethernet link between LIU shelf (256 E1) and GP
board (12/14/16 E1). This transport is made through a Giga Ethernet switch
(SSW board). The configuration and status retrieval of this module is under
the control of the OMCP.
There are defined three interfaces between the MFS components:
The interface between the NE1oE modules for Ethernet supervision and
traffic and between each NE1oE module
The interface in charge of the global supervision between each NE1oE
module and the OMCP
The interface between the NE1oE Agent on OMCP MFS and the MFS
Application (directly) or between the NE1oE Agent on OMCP BSC and
the CPI of MX Platform.
The interfaces are depicted in the figure bellow:
OMCP MFS
MFS Application
GPs
NE1oE
MUXs
NE1oE Agent
NE1oE
1.2.5 Synchronization of A9130 MFS Evolution

The clock synchronization service is provided by the hardware equipment
manager of the MFS. This service allows a GP to synchronize its clock with the
clock of an other Network Element (TC, A9130 BSC Evolution or SGSN).
In the case of GboIP feature, the synchronisation clock cant be extracted from
the SGSN. Depending on the Gb configuration, there can be three ways to
provide synchronization to the MFS:
Mixed Gb (FR and IP): clock synchronization can be extracted from
the FR links
24 / 62
Pure IP Gb, MFS with existing links to TC: clock synchronization for
Ater TDM can be extracted from the TC links
Pure IP Gb, MFS with no existing links to TC: in this specific
configuration, the MFS can get the synchronization from the A9130 BSC
Evolution or shall use the Centralized Timing Mode to synchronize Ater TDM.
Synchronization mode can be configured in the MFS bul profile. The chosen
mode is global to the MFS: either autonomous or centralized. This mode is
defined during the commissioning and can not be changed unless the MFS is
completely restarted in configuration mode.
The A9130 MFS Evolution provides following synchronization modes:
Autonomous timing mode - internal mode of each GP
Free run mode - local oscillator on the board
Centralized timing mode - external mode, where a GP is used to synchronize
the others.
Whatever the synchronization mode, the following priority order applies: TC,
A9130 BSC Evolution, SGSN ( A9130 BSC Evolution, TC, SGSN would also
work correctly).
1.2.5.1 Autonomous Timing Mode

This mode uses the frequency extracted from one of the 16 PCM to synchronise
the GP and only the GP. The selected clock is not transmitted to the other
GPs. The source of synchronization is the TC, A9130 BSC Evolution or the
SGSN which have high accuracy clock. In the case of GboIP feature, the
synchronisation clock cant be extracted from the SGSN.
During the GP initialisation, the hardware equipment manager on OMCP sends
data configuration to each GP. In this data, each GP finds a list of synchronizing
PCM-TTP. The PCM-TTP priority is computed by the board. All the PCM-TTP
coming from the same type of equipment have the same priority.
There is up to 4 synchronizing PCM-TTP per GP. It takes in the list the
PCM-TTP with the highest priority as reference PCM for the board. Then, the
software has to initialize the time base module.
In case of failure of the signal clock taken as reference clock, the GP software
switches to another source given in the list of synchronization source PCM-TTP
(it always takes the PCM-TTP with the highest priority). The switch back to the
highest PCM-TTP priority is performed automatically by the board.
1.2.5.2 Free Run Mode

This mode uses the local oscillator of the board. This free run mode is used
when the list of synchronization source PCM-TTP of internal PCM timing
mode becomes empty because no more PCM-TTP are operational. (This is
a defence mode for the MFS). An alarm is generated per GP board when
this mode is used.
25 / 62
1.2.5.3 Centralized Timing Mode

AT GPU level there is no difference with the autonomous mode except that only
two PCM-TTP per GP are synchronizing.
The equipment manager has to choose two E1s coming from the
synchronization source and configure nE1oE paths for all GPs in the rack (two
shelves). Two dedicated PCM_TTP equipped with same attributes as the
source will be updated in equipment manager MIB.
During the GP initialization, the hardware equipment manager on OMCP
sends data configuration to each GP. In this data, each GP finds a list of two
synchronizing PCM - TTPs. Note that at board insertion, the PCM-TTP on port
numbers 0 and 1 are chosen by default. The GP computes the synchronization
priority and takes the PCM-TTP with the highest priority as reference PCM
for the board.
1.2.6 Installation and Maintenance Terminal

The Installation and Maintenance Terminal (IMT) is the local or remote terminal
of the MFS.
The IMT is used to maintain the MFS by:
Displaying and managing MFS alarms, then identifying particular MFS
equipment related to the alarms
Maintaining MFS equipment (reset boards, etc.)
Viewing and reconfiguring hardware
Software management
Modifying telecom parameters.
The IMT is only running under Windows and Solaris (on OMC-R).
1.2.7 Connection with the OMC-R

The physical connection with the OMC-R is done via an Ethernet link connected
to one of the external link of the base interface switch. It means that two links
are available in the OMCP for the O&M flow, including :
OMC-R interface
OMCP/E1 boards interface
OMCP/GP interface.
26 / 62
1.3 Traffic and Signaling Links

The figure below shows the traffic and signaling links for both circuit-switched
and packet-switched connections.
MFS
BTS
TCH
BSC
RSL
EGCH
TCH
SS7
1222
111
GCH
122222
11111
121212
111111
1212
121212
111111
1212
TCH
SS7
TC
Gb + AterMux
GSL
Gb
MSC
PCU
Gb over FR
SGSN
Gb over IP
Figure 7: Traffic and Signaling Links

The table below briefly describes the circuit-switched and packet-switched
traffic and the signaling links.
Link
TCH
Carries circuit-switched voice or data. On the Abis Interface,

circuit-switched voice can be carried on an 8 kbit/s or 16 kbit/s
channel. On the Ater Mux Interface, it is carried on a 16 kbit/s
channel. Circuit-switched data is always carried on 16 kbit/s
channels.
RSL
Carries circuit-switched traffic management information for

MS-to-network communication. It is carried on a 16 kbit/s or 64
kbit/s channel. There is one RSL per TRE. The RSL also carries
signaling to control the BTS TRX.
SS7
Carries call control and mobility management information

between the MSC and BSC on a 64 kbit/s channel.
GCH
Carries blocks of packet-switched data on a nx16 kbit/s channel

between the BTS and MFS. The blocks are transparently
routed through the BSC to the BTS. There is one Ater resource
re-allocation per GCH for GPRS MS.
EGCH
Description
Carries packet-switched data traffic on nx16 kb/s channels (one

main GCH + a pool of auxiliary GCH) between the BTS and
MFS. There is one EGCH per PDCH.
27 / 62
Link
Description
GSL
Carries packet-switched traffic management information

between the MFS and BSC on a 64 kbit/s channel. If a second
GSL is connected to the BSC for redundancy purposes, it must
be on a different PCM link. GSL also carries location services
messages, when enabled.
Gb
Carries packets of data to and from the SGSN on transparent n x

64 kbit/s channels. This is a single link created by concatenating
a number of 64 kbit/s time slots. The HDLC or UDP/IP protocol
is used, allowing remote SGSN connections to be made over
a Frame Relay or IP network.
Table 2: Traffic and Signaling Link Descriptions
28 / 62
1.3.1 Physical Channel

The physical channel which supports the different packet data logical channels
is the Packet Data Channel (PDCH).
It consists of:
One TDMA time slot on the Air Interface, and
One EGCH (composed of 1 to 5 16 kb/s GCH) per PDCH
There are eight time slots in one TDMA frame which means that a maximum of
eight PDCHs are possible per TRX. The figure below shows the Air Interface
structure for one PDCH.
TDMA Frame (4.615 ms)
Time Slots
Frames
51
50
51
Multiframe = 52 TDMA Frames (240 ms)
Figure 8: PDCH Air Interface Structure

In the example in the figure above, TS2 of each TDMA frame forms part of the
same PDCH. The TDMA frames are organized as a 52-frame multiframe.
TS2 use of the frames in the multiframe is:
Frames 25 and 51 - unused
Frames 12 and 38 - Packet Timing Advance Control Channel (PTCCH) is
the packet data logical channel for MS timing advance control.
Remaining 46 frames - these frames are organized into blocks of four
consecutive frames and are shared by the other packet data logical
channels.
The figure below shows the air interface block structure.
Frame
Block
0
0
8
1
13
2
17
4
21
26
5
30
34
39
9
43
10
47
11
Multiframe = 52 TDMA Frames (240 ms)
Figure 9: Air Interface Block Structure

Each block consists of four consecutive TDMA frames. For example, Block 3
consists of TDMA frames 13-16. A block is the basic unit for transferring
information on the PDCH.
The blocks are shared by the packet data logical channels. In the case of the
Master Packet Data Channel (MPDCH) (see Section 1.3.2 ), Block 0 is reserved
for the Packet Broadcast Control Channel (PBCCH) in the downlink direction.
29 / 62
1.3.2 Packet Data Logical Channels

The table below provides a brief description of the packet data logical channels.
Channel
Description
PCCCH
The Packet Common Control Channel (PCCCH) provides common control information
to the MS. This includes paging, access grant and random access. When PCCCH is not
allocated, the circuit-switched CCCH is used to initiate the packet data transfer. When
PCCCH is allocated, PCCCH, PBCCH and Packet Data Traffic Channel (PDTCH) (see
below) share the same PDCH.
The PCCCH supports the sub-channels:
Packet Random Access Channel (PRACH) (uplink)
Packet Paging Channel (PPCH) (downlink)
Packet Access Grant Channel (PAGCH) (downlink).
PBCCH
The PBCCH broadcasts general information on the downlink which is used by the MS to
access the network for packet transmission. The existence of PCCCH (and consequently
the existence of the PBCCH) is indicated by the circuit-switched BCCH.
PTCH
The Packet Traffic Channel (PTCH) carries user data and associated signaling:
PDTCH. Mapped to one PDCH. Up to eight PDTCHs (using eight PDCHs with different
Air Interface time slots) can be allocated to one MS.
Packet Associated Control Channel (PACCH). If multiple PDTCHs are assigned to
one MS, the identity of the PDCH carrying the PACCH is provided in the resource
assignment message. PACCH is bi-directional.
PTCCH
Provides a bi-directional continuous timing advance mechanism. The MS is allocated a

sub-channel of the uplink PTCCH according to the timing advance index.
Table 3: Packet Data Logical Channels

The PDCH which carries the PCCCH and PBCCH logical channels is referred
to as the MPDCH. The location of the MPDCH is defined by the BCCH
system information.
When an MPDCH is not defined, both the circuit-switched and packet-switched
signaling use the BCCH and CCCH. The BSC forwards uplink CCCH flow
to the MSC or MFS, as required.
Declaring an MPDCH is an operator choice which is based on the overall traffic
density and relative loads of circuit-switched and packet-switched traffic. If
packet-switched traffic is low, an MPDCH is not declared.
30 / 62
1.3.3 Temporary Block Flow

A Temporary Block Flow (TBF) is the physical connection used by the MS
(uplink) or MFS (downlink) to support the unidirectional transfer of packet data
on packet-switched physical channels.
The TBF is allocated:
One or more PDCHs
One or more consecutive blocks to be used on the PDCHs for data transfer.
A TBF is temporary and is only maintained for the duration of the data transfer.
The blocks of a TBF contain a Temporary Flow Indicator (TFI) which identifies
the blocks belonging to one message. Each block in the downlink direction
also contains an Uplink Status Flag (USF). The USF tells the MS when it can
transmit data. For example, if the MS receives the required USF on Block n
(downlink), it transmits its data on the following Block n+1 (uplink).
1.3.4 NC2 in Packet Transfer Mode

During enhanced cell reselection, NC2 activates when the MS is in packet
transfer mode, reducing the number of cell reselections triggered during GPRS
sessions. When activated, the network controls the cell reselection of each MS
involved in the packet transfer. Each of these MS reports measurements on the
serving cell and the six strongest surrounding cells, enabling the network to
dynamically reselect a specific cell.
1.3.5 Signaling
A GSL consists of a 64 kbit/s LAPD link between the MFS and the BSC.
It is used to:
Request the BSC to allocate/de-allocate a PDCH
Notify the BSC whether there is a MPDCH
Carry paging, channel request, and access grant if there is no MPDCH
Receive cell state change information and BSC status
Load notification (BSC to MFS).
31 / 62
1.4 GPRS Functions

The functions performed by the MFS are described in:
GP telecommunications
MFS O&M.
1.4.1 GP Telecommunications Functions

A PCU controls the GPRS activity of one cell and is implemented in the GP
PBA.
The telecommunications functions performed by the GP are described in
detail below:
High Speed Data Services
Packet radio resource management
Packet radio resource allocation
T4 reallocation
Uplink power control
Uplink medium access mode
Timing advance
Paging management
Channel coding
Link Adaptation
Gb Stack.
32 / 62
1.4.1.1 High Speed Data Service (HSDS)

High Speed Data Service (HSDS) provides CS1 to CS4 for GPRS, and MCS1
to MCS9 for EGPRS. It also offers additional functions that adapt radio
resource allocation with EGPRS MSs to avoid Ater blocking by allocating
more transmission resources on Abis and Ater to a radio time slot managing
HSDS capability on TRE basis.
HSDS is supported in each BSS and provides:
A second Abis link: when there are insufficient Abis time slots on one Abis
link, a second Abis can be attached to the BTS. This second link supports
extra 16k nibbles for packet traffic but does not carry circuit-switched traffic.
MPDCH handling: allows the OMC-R to allocate a number of radio time
slots to the BSC that are reserved for packet-switched signaling. This avoids
inter-operablility issues with MSs and wasting Ater resources.
CS1/CS4 and EGPRS protocol modulation and coding schemes: Nine
different modulation and coding schemes, MCS1 to MCS9, are defined
for the EGPRS radio data blocks.
Enhanced radio resource allocation: EGPRS traffic has priority over GPRS
traffic. TRXs with a high throughput are preferred for EGPRS traffic but
GPRS throughput is optimized as long as it does not conflict with EGPRS
traffic.
T4 allocation: solves conflicts between uplink GPRS TBFs and downlink
EGPRS TBFs.
Dynamic transmission handling: PDCHs are established with the maximum
number of GCHs, whatever the supported traffic. Unused GCHs, depending
on traffic, are released in case of Ater congestion. For GPRS TBF allocation,
PDCHs are established with a reduced number of GCHs during the Ater
congestion state.
33 / 62
1.4.1.2 Packet Radio Resource Management

Packet radio resource management is concerned with the allocation and
de-allocation of PDCHs to a cell.
A cell which supports packet-switched data allocates resources on one or more
PDCHs to the MSs. The PDCHs are taken from a common pool of PDCHs
made available to the cell.
The allocation of physical channels for circuit-switched and packet-switched
services is done dynamically, according to traffic load. Common control
signaling in the initial phase of a packet-switched transfer is conveyed on the
PCCCH (when MPDCH is defined) or on the CCCH (when MPDCH is not
defined).
The principle of dynamic allocation is illustrated in the figure below.
PDCHs
Max Normal
Load = 7
(Max_PDCH)
Max High
Load = 4
(Max_PDCH
_High_Load)
2
Min = 1
(Min_PDCH)
Time
High Load
Notification
Normal Load
Notification
Figure 10: Dynamic PDCH Allocation

The number of PDCHs available to the cell is defined by O&M parameters
which specify the:
Minimum number
Maximum number under normal BSC loading
Maximum number under high BSC loading.
The minimum number of PDCHs for the cell is one. Additional PDCHs are
dynamically assigned, when required, until the maximum of seven is reached.
When the BSC notifies the MSC that there is a high traffic load, the MFS waits
for a PDCH to become free (no TBFs assigned) and then requests the BSC
to release it. This process continues until there are four PDCHs left. Later,
when the BSC notifies the MFS of normal loading, the MFS requests additional
PDCHs from the BSC when they are required.
34 / 62
1.4.1.3 Packet Radio Resource Allocation

Packet radio resource allocation is concerned with the number of PDCHs
that are assigned to the MS.
The number of PDCHs that can be assigned to the MS depends on the MS
multislot class capability:
Type 1 MSs operate in simplex mode (that is, transmission and reception
are not simultaneous). The maximum number of PDCHs allowed are two for
the uplink direction and four for the downlink direction.
Class 2 MSs operate in duplex mode (that is, transmission and reception
are simultaneous). The maximum number of PDCHs allowed are five for
the uplink and downlink directions.
An O&M parameter that can limit the number of PDCHs allocated to a TBF.
The MFS dynamically controls all radio time slots that can be used for
packet-switched traffic, simplifying time slot allocation and decreasing PMU
CPU loads.
1.4.1.4 T4 Reallocation
T4 reallocation resolves conflicts between uplink GPRS TBFs and downlink
EGPRS TBFs when they share the same PDCH. Uplink GPRS TBF is
reallocated on resources that dont support any downlink GPRS TBFs.
1.4.1.5 Uplink Power Control

When the MS first accesses the cell on the PRACH, it uses the output power
level specified on the PBCCH. After this, the MS output power level is based on
the received signal strength. It is assumed that the power loss is the same for
uplink and downlink.
35 / 62
1.4.1.6 Uplink Medium Access Mode

Contention control is not required in the downlink direction even if the PDCH
is shared by several MSs.
In the uplink direction, contention control is required when multiple MSs share
the same PDCH. The MFS avoids contention by authorizing particular MSs to
transmit at particular times.
Medium access mode is the method by which the logical channels are allocated
on the uplink PDCH.
The channels are:
PDTCH/PACCH. Each MS is allocated a particular USF value by the MFS.
When an MS receives the required USF value in a downlink block, it
transmits its data on the next uplink block.
PRACH. When the MS wants to initiate a packet access procedure, it has to
send a packet channel request on the PRACH.
The MS examines the downlink blocks and looks for a specific (free) USF
value which marks the position of the PRACH on the uplink. A free USF
value in downlink Block n means that the PRACH is on uplink Block n+1.
PACCH. When an MS is involved in a downlink packet transfer, it must
send an acknowledgment, when required, on the uplink PACCH. The
MS examines its downlink blocks and looks for a particular value (not
the USF) which authorizes the MS to transmit its acknowledgment. The
acknowledgment is required by the mechanism which schedules the
uplink block.
1.4.1.7 Timing Advance

The correct value for the timing advance used by the MS when transmitting
uplink blocks is derived in two parts:
Initial estimation. The BTS performs measurements on the single access
burst carrying the packet channel request and sends a value to the MS. This
value is used for uplink transmissions until the continuous timing advance
mechanism provides a new value.
Continuous advance. The BTS analyzes received access bursts over
successive 52-frame multiframes and determines values which it sends to
the MS.
For the downlink direction, the initial timing advance value is computed on
reception of the Packet Control Acknowledgment from the MS. The value is
then returned to the MS in a timing advance or power control message.
36 / 62
1.4.1.8 Paging Management

The network can co-ordinate circuit-switched and packet-switched paging. This
means that circuit-switched paging messages can be sent on the channels
used for packet-switched paging messages.
Three modes are defined:
Network Operation Mode 1 - circuit-switched paging messages are sent
via the SGSN and MFS.
The circuit-switched paging message for the GPRS-attached MS is sent on
the PPCH or CCCH paging channel, or on the PACCH. This means that the
MS only needs to monitor one paging channel. It receives circuit-switched
paging messages on the PACCH when the MS is in packet transfer mode.
Network Operation Mode 2 - circuit-switched paging messages are sent via
the MSC and BSC, but not the MFS.
the CCCH paging channel. The channel is also used for packet-switched
paging messages. This means that the MS only needs to monitor PCH.
Circuit-switched paging continues on the PCH even if the MS is assigned
a PDCH.
Network Operation Mode 3 - circuit-switched paging messages are sent via
the MSC and BSC, but not the MFS.
the CCCH paging channel. The packet-switched paging message is sent on
either the PPCH (if allocated) or on the CCCH paging channel.
1.4.1.9 Channel Coding

Different Coding Schemes (CSs) can be used for the data on the Air Interface:
CS1/CS4
MCS1 to MCS9.
1.4.1.10 Link Adaptation

Link adaptation changes Modulation and Coding Schemes (MCS) according
to radio conditions and CS1 to CS4. When radio conditions worsen, a
protected MCS with more redundancy is chosen, leading to a lower throughput.
Inversely, when radio conditions improve, a less protected MCS is chosen for
higher throughput. Nine modulation and coding schemes enhance packet
data communications (EGPRS), providing raw RLC data rates ranging from
8.8 kbit/s to 59.2 kbit/s. Data rates above 17.6 kbit/s require that 8-PSK
modulation are used on the air, instead of GMSK.
1.4.1.11 Gb Stack
Communication between the MFS and SGSN is via the Gb Interface.
The Gb Stack function provides the necessary supporting protocol layers:
Network service
BSS GPRS Protocol (BSSGP).
37 / 62
1.4.2 MFS O&M Functions

The O&M functions of the A9130 MFS Evolution manage the:
Equipment
GP telecommunications application
Alarms
Performance.
1.4.2.1 Equipment Management

This function manages the telecommunications equipment and, in particular,
the GP hardware and low level software.
It handles all requests in the first part of the initialization process.
This includes:
MUX/GP software booting protocol
GP software reset and rollback functions
Session layer configuration
Framer configuration for Gb Interface messages
GP switch configuration for circuit-switched connections
LIU ports to GP allocation.
The function also manages the switchover from the defective GP to the spare
GP, and outage time during major software changes.
1.4.2.2 GP Telecommunications Application Management

This function manages the telecommunications application of each logical GP. It
is responsible for telecommunications resource configuration and supervision.
This includes the:
Bearer channels
Gb Interface
Ater Mux Interface towards the BSC
Cell management domains.
1.4.2.3 Alarm Management

This function is responsible for the processing of hardware and
telecommunications alarms within the MFS.
The function:
Collects all fault information for telecommunications and external alarms, the
telecommunications hardware and the active OMCP.
Records the fault information in a secured table.
Allows the local maintenance terminal (IMT) and the OMC-R to access
the fault information.
38 / 62
Generates the end report for pending alarms.

Manages the communications with the IMT.
1.4.2.4 Performance Management

This function is responsible for:
Collecting the performance management counters associated with each
logical GP.
Creating a file to contain the counter values.
1.5 SMLC Functions

SMLC provides the following functions:
Handles LCS protocols towards the BSC, the MS, and the external A-GPS
server.
Manages call-related location context per MS and positioning methods.
Triggers the position calculation process for the TA positioning method, and
presents the MS location estimate in standard format.
Requests GPS Assistance Data from the external A-GPS server and
provides them to the MS.
Provides MS-performed GPS measurements to and from the A-GPS server
to provide MS-assisted or MS-based A-GPS positioning in a standard format.
Improves location accuracy by providing assistance data via a GPS link to
the GPS-MS (A-GPS): navigation data from satellites and Differential GPS
(DGPS), providing corrections to measurement errors.
Uses O&M information present in the MFS or SMLC, provided by the
OMC-R.
Error Handling.
39 / 62
40 / 62
2 Managed Objects and SBLs

This chapter describes the MFS Managed Objects and SBLs. It provides the
allowed states for both Managed Objects and SBLs. It maps Managed Objects
and SBLs to the corresponding RIT.
41 / 62
2.1 MFS Objects

This section describes the MFS Managed Objects and RITs.
2.1.1 MFS Managed Objects

The Managed Object classes for the MFS are listed in the following table. The
naming attribute is used to construct the RDN (Relative Distinguish Name)
of subordinate objects of this class. An RDN is constructed from the object
identifier assigned to that attribute type and the value of the instance of the
attribute.
The table bellow contains the ASN.1 (Abstract Syntax Notation) types for
each Managed Object class.
Managed Object Class
Naming Attribute
Type ASN.1
aGprs2MbTTP
tTPId
NameType
aGprsAdjacentCellReselection
adjacentCellID
GsmGeneralObjectID
aGprsBearerChannel
aGprsBearerChannelId
GsmGeneralObjectID
aGprsBssFunction
bssFunctionId
BssFunctionId
aGprsBts
btsID
GsmGeneralObjectID
aGprsFabric
fabricId
NameType
aGprsGicGroup
aGprsGicGroupId
GsmGeneralObjectID
aGprsLapdLink
lapdLinkId
GsmGeneralObjectID
aGprsManagedElementExtension
aGprsManagedElementExtensionId NameType
aGprsMasterChannelData
aGprsMasterChannelDataId
IntegerIdValue
aGprsNse
aGprsNseId
GsmGeneralObjectID
aGprsNsvc
aGprsNsvcId
GsmGeneralObjectID
aGprsSgsnIpEndPoint
aGprsSgsnIpEndPointId
IntegerValue
aGprsPdchGroup
aGprsPdchGroupId
GsmGeneralObjectID
aGprsPowerControl
powerControlID
GsmGeneralObjectID
aGprsPvc
aGprsDIcID
GsmGeneralObjectID
aGprsBtsSiteManager
btsSiteManagerID
GsmGeneralObjectID
circuitPack
equipmentId
NameType
crossConnection
crossConnectionId
NameType
equipmentHolder
equipmentId
NameType
eventForwardingDiscriminator
discriminatorId
SimpleNameType
extendedCurrentAlarmSummaryControl
currentAlarmSummaryControlId
NameType
managedElement
NameType
42 / 62
managedElementId
Naming Attribute
Type ASN.1
nectarCircuitPack
equipmentId
NameType
nectarFRU
equipmentId
NameType
Table 4: MFS Managed Object Classes
43 / 62
2.1.2 MFS Managed Object Hierarchy

The hierarchy of MFS Managed Objects is shown in the following figure.
This tree contains a graphical representation of the naming hierarchy of the
indicated Managed Objects.
managed Element
(M3100)
aGprsManagedElementExtension
event Forwarding Discriminator
equipmentHolder
(M3100)
aGprsFabric
extendedCurrentAlarmSummaryControl
aGprs2MbTTP
aGprsNse
aGprsBssFunction
crossConnection aGprsLapdLink aGprsBearerChannel aGprsNsvc aGprsSgsnIpEndPoint

aGprsBtsSiteManager
(M3100)
Circuit Pack
(M3100)
aGprsAdjacentCellReselection
aGprsGicGroup
aGprsPvc
aGprsPowerControl
aGprsBts
aGprsPdchGroup
Figure 11: Hierarchy of MFS Managed Objects
44 / 62
2.1.3 MFS Managed Object Supported States

The supported states of MFS Managed Objects are indicated in the following
table.
Following notations are used:
S
Supported/ Implemented
NS
Not Supported/ Not Implemented
Managed Object
Class
Administrative
State
Operational
State
Availability
Status
aGprs2MbTTP
aGprsAdjacentCellReselection aGprsBearerChannel
aGprsBssFunction
aGprsBts
aGprsFabric
NS
NS
NS
aGprsGicGroup
aGprsLapdLink
aGprsManagedElement
Extension
aGprsNse
aGprsNsvc
aGprsSgsnIpEndPoint
aGprsPdchGroup
aGprsPowerControl
aGprsPvc
aGprsbtsSiteManager
circuitPack
NS
crossConnection
NS
NS
equipmentHolder
NS
NS
eventForwardingDiscriminator
NS
NS
NS
extendedCurrentAlarm
SummaryControl
managedElement
NS
NS
45 / 62
Managed Object
Class
Administrative
State
Operational
State
Availability
Status
nectarCircuitPack
NS
NS
NS
nectarFRU
NS
Table 5: Supported States of MFS Managed Objects
46 / 62
2.1.4 MFS Managed Object Supported Operations

The supported operations of MFS Managed Objects are indicated by a
checkmark (X) in the following table.
Supported Operations
Set
Get
Create
Delete
Lock
Unlock
Connect Disconnect
aGprs2MbTTP
aGprsAdjacentCell
Reselection
aGprsBearerChannel
aGprsBssFunction
aGprsBts
aGprsFabric
aGprsGicGroup
aGprsLapdLink
aGprsManagedElement
Extension
X(*)
X(*)
aGprsMasterChannel
Data
aGprsNse
aGprsNsvc
aGprsSgsnIpEndPoint
aGprsPdchGroup
X(**)
aGprsPowerControl
X(**)
aGprsPvc
btsSiteManager
circuitPack
crossConnection
equipmentHolder
X(*)
X(*)
eventForwarding
Discriminator
SummaryControl
47 / 62
Supported Operations
Set
Get
Create
Delete
Lock
Unlock
Connect Disconnect
log
managedElement
X(*)
X(*)
nectarCircuitPack
X(*)
X(*)
nectarFRU
(*) Created at initialization time; after initialization, Create and Delete are not explicitly supported.
(**) Deleted only through cell deletion.
Table 6: Supported Operations of MFS Managed Objects
48 / 62
2.1.5 MFS FRUs

The field replaceable units in the MFS are listed in the following table:
FRU
Alcatel mnemonic
Designation
ATCA Shelf (*)
PVSER309
ATCA Shelf equipped
Fan tray
PVFAN003
Fan tray with handle
ATCA PEM
PVPEM
Power Entry Module
SHMC
JAXSMM
Shelf Manager
PC
JAXPC
Personnality card
Air Filter
PVFILT01
Air Filter
ATCA front filler (*)
JBXFILL
ATCA Front panel filler
ATCA rear filler (*)
JAXFILL
ATCA Rear panel filler
OMCP
JBXOMCP
O&M control board
SSW
JBXSSW
Gigabit Ethernet Switch board
RTM-SSW
JAXSSW
RTM copper Gb Ethernet Switch board
GP
JBXGPU
GP radio processing board: hot insertion/extraction, plug

and play (without declaration at the local terminal)
LIU shelf (*)
JSXLIU
LIU shelf equipped
LIU PEM
JBXPEM
LIU Power Entry Module
Front filler (*)
JBXDUM
LIU dummy board (Front panel filler)
MUX
JBXMUX
Multiplexing Board
LIU
JBXLIU
LIU board
Rack (*)
JRXCAB
Basic Rack for MX configurations
PDU
JSXPDU
PDU shelf for rack
Filler 1U
JMXF1U
Filler 1U for LIU shelf
SEISMIC KIT
(optionally) (*)
JDSISM
Earthquake kit
(*) These units are not replaceable; only events and alarms are reported.
Table 7: MFS FRUs
49 / 62
2.2 MFS Managed Object Description

The description of MFS Managed Objects is listed in the following table.
Description
aGprs2MbTTP
This Managed Object class is a 2 Mb port managing objects that terminates the
transport entities, such as trails and connections. All attributes are assigned
values at create time.
aGprsAdjacent
CellReselection
This Managed Object class focuses on the cell reselection adjacencies related
to GPRS functionality. This object is created for each adjacent cell to the
containing cell. It is used to broadcast on the Air interface (via master PDCH)
the adjacent cells that may support the GPRS functionality (if the adjacent cell
(i.e. target cell) does not support GPRS, the reselection procedure will fail).
aGprsBearerChannel
The Bearer Channel is the Frame Relay Bearer Channel (described in rec.
Q.922 annex A and Q.933 annex A). It represents a transport capacity on the
Gb interface. It can be a set of 64 kb time slots (case framed 2Mb-TTP). The
bearer channel supports the PVCs.
aGprsBssFunction
Represents a BSS network element. (Only the BSSs with GPRS capability
are seen at the OMC/MFS interface and can be configured by the operator.).
Object AGprsBssFunction is created when Non GPRS BSS becomes GPRS
BSS. Moreover, Gb_Transport_Mode is defining what type of Gb we are
dealing with: FR or IP.
aGprsBts
Represents the O&M functionality related to a specific cell within a BTS

equipment.
aGprsFabric
Represents the function of managing the establishment and the release of the
cross-connections of 2Mb-TTPs ports.
aGprsGicGroup
A Managed Object of this class represents the set of all GICs pertaining all to
the same Ater interface at the BSC side. The GICs have been grouped per Ater
because all GICs of the same Ater have the same operational state (depending
on the state of the DTC board at the BSC).
aGprsLapdLink
This Managed Object is the 64k channel on the MFS-BSC interface supporting
the GSL on a given BSC-MFS interface. The GSL uses the GPRS LapD links
in load sharing. The GSL is not managed as an object class.
aGprsManaged
ElementExtension
This Managed Object class is a class of Managed Objects that provide

additional services related to the managedElement object class for different
domains (Radio, Ater-Gb...). This is necessary because managedElement is a
standard Managed Object class and cannot be overloaded.
aGprsMasterChannelData This Managed Object class defines the characteristics (attributes) of the cell
that are not required when there is no master channel.
aGprsNse
50 / 62
The network service element (NSE) is an entity of the NSC telecom layer of
the Gb interface. The NSE ensures the load sharing of the outgoing BSSGP
messages over its set of NS-VCs or Remote IP Endpoints (to the SGSN),
and routes the incoming SNS messages to the required BVCs.A NSE is
associated to a set of NS-VCs / IP Endpoints and a set of BVCs . The NSE is
characterized by its NSEI, also known by the SGSN.
Description
aGprsNsvc
The network service virtual connection (NS-VC) is an entity of the network

service control (NSC telecom layer on the Gb interface). It is an end-to-end
virtual connection between MFS and SGSN. The NS-VC is identified by its
NS-VCI, also known by the SGSN.
aGprsSgsnIpEndPoint
An endpoint defined by its IP address and UDP port. An IP endpoint can be a

data endpoint and/or a signalling endpoint.
aGprsPdchGroup
This Managed Object class defines the configuration parameters of a group of

consecutive channels.
aGprsPowerControl
This Managed Object class focusses on the cell power control parameter
related to GPRS functionality (one object instance per cell).
aGprsPvc
This class represents the frame relay implementation of permanent virtual

connections.
btsSiteManager
This Managed Object class represents the O&M functionality related to a

specific BTS equipment. Its purpose is containment (BTS sector or cell
instances).
circuitPack
This Managed Object class is derived from M.3100 circuitPack class. It

represents boards that are present in Telecom subracks; these are GP boards.
This object is created when the GP board is first plugged in. An objectCreation
notification is the emitted. The board is deleted when it is unplugged. An
objectDeletion notification is the emitted.
crossConnection
Represents the cross-connection function between two 2Mb-TTPs (the from

termination and the to termination ) with a granularity of one time slot (64 kb).
equipmentHolder
It represents the physical resource of a network element that is capable of

holding other physical resources. It is created by NECTAR at initialization
using the NECTAR profile configuration file. In particular, this file is used
to configure the userLabel.
eventForwarding
Discriminator
Represents an Managed Object class that contains a discriminator construct

that specifies the characteristics a potential event report must satisfy in order
to be forwarded.
SummaryControl
Represents an Managed Object class of support objects that provide the

criteria for generation of current alarm summary reports.
log (not installed)
This Managed Object class represents a repository that may be used for alarm
logging.
managedElement
This Managed Object class represents the MFSnetwork element. Its purpose
is containment, allowing the associations of various functions that make up an
instance of this network element. It is created by NECTAR at initialization
using the NECTAR profile configuration file. In particular, this file is used
to configure the userLabel.
51 / 62
Description
nectarCircuitPack
This class is derived from M.3100 circuitPack class. It is created by NECTAR at

initialization using the NECTAR profile configuration file. In particular, this file
is used to configure the userLabel.
nectarFRU
This Managed Object class represents the FRUs of the platform such
as CPUBox, localDiskDrive, sharedDiskDrive, CDROMDrive, TapeDrive,
localPowerSupply, sharedPowerSupply, sharedFanTray, localDiscBox,
sharedDiskBox, LSNHub/Switch, LANIOHub/Switch, concentrator, X.25router.
Table 8: MFS Managed Object Description
52 / 62
3 Software
3 Software
This chapter describes the A9130 MFS Evolution software.
53 / 62
3 Software
3.1 Overview
The software manages the telecommunications and O&M aspects of the
MFS. It runs in the OMCP and XPU boards. The figure below shows the
main software components.
As a notation XPU represents the function of the GP board.
Active OMCP
XPU
MFS
Application
Telecom
Application
TOMAS
PSOS
General
Software
Hardware
LINUX OS
OS Operating System
PSOS Provable Secure Operating System
Hardware
Figure 12: Main Software Components

The active OMCP contains the following software components:
LINUX operating system.
General software. This includes tools, utilities and WAN support.
Telecom Middleware Application (TOMAS). This is a middleware platform
for IT hardware that enables the hardware to support telecommunications
applications.
MFS application. This supervises the MFS and downloads the
telecommunications application to the GP where the telecom functions
are performed.
Each XPU contains the following software components:
Provable Secure Operating System (PSOS)
Telecommunications application
SMLC software.
54 / 62
3 Software
3.2 Global Architecture

The O&M software architecture is shown in the figure below.
Active OMCP
Standby OMCP
O&M Application
Equipment
Manager
Mx Platform
Telecom
Manager
GPRS NE
Platform
TOMAS Platform
LINUX OS
TOMAS
Drivers
XPU Board
GPRS NE Platform
Telecom Application
TOMAS Platform
GPRS NE Platform
LINUX OS
TOMAS
Drivers
PSOS
XPU
Drivers
Figure 13: O&M Global Architecture

When an OMCP board operates in the standby mode, it does not run the
O&M application.
The components of the active OMCP board are:
LINUX operating system and TOMAS drivers that manage the Ethernet
double link.
TOMAS platform which provides secure communications services, data
management, OMCP boards supervision and disk mirroring, and TOMAS
process initialization within OMCP boards.
GPRS network element platform which:
Controls the communications with the XPUs. This function is active
on both OMCP boards.
Supervises the telecommunications equipment (XPU, E1 Mux boards,
PCM) and collects all alarms. These functions are not active on the
standby OMCP.
Mx platform provides services to manage the E1 mux boards:
Configuration and supervision of the two E1 mux boards
Remote inventory management.
O&M application which manages the telecom objects (AterMux interface,
Cell, Gb interface, LCS interface) and the Q3 interface. These functions are
not active on the standby OMCP board.
55 / 62
3 Software
3.3 Communication Channels

Communication between the XPUs and the OMCP boards takes place as
sessions over six types of channels:
Telecom channel - used for requests, replies and state change notifications
when configuring:
Network services (Gb Interface)
Bearer channels (GAter Mux Interface)
BSS and cells (cell management).
XPU network channel - used for network configuration requests and replies
and for network notifications.
XPU physical channel - used for XPU hardware component configuration
requests and replies and for hardware notifications.
Alarm channel - used for collecting all hardware, network and GPRS alarms.
Performance Manager channel - used for PM configuration requests and
reports from the XPU boards.
LCS channel - used for configuring the LCS BSS and the LCS cells
considering that one GPRS cell matches one LCS cell.
Each channel is a Communications Service session established between a
PSOS task (in the XPU) and a MFS Real-Time Agent (MRTA) as shown
in the figure below.
56 / 62
3 Software
OMC
CRAFT TERMINAL
OMCP
LAMFS
LAPF
COMET
Q3 Agent
Common Management Protocol Syntax (CMPS) Interface
DM
CFG
MIB
Admin
DM
RSC
MIB
Admin
Realtime
Realtime
GHM
GAM
GPM
BAM
PM
Realtime
Realtime
Realtime
GOM
Admin
Admin
GEM
GLM
SCA
Realtime
LRM
SMLC
XPU
TRM
RRM
NS
Bearer
PSOS Task
MFS SCIM
NECTAR SCIM
Communications
Service Session
CFG MIB: SEMIPERMANENT CONFIGURATION DATA

RSC MIB: DYNAMIC RESOURCE DATA (STATES)
Figure 14: MFS Agents and Processes
57 / 62
3 Software
Each real-time process has two main parts:

Administrative layer - manages configuration data received over the Q3
Interface or from the IMT.
Real-time layer - updates object states when a notification is received
from the XPU.
The real-time processes support data persistency. Configuration data is stored
in a table and a backup copy is retained on disk. Resource data is also stored
in a table but there is no backup.
58 / 62
3 Software
3.4 Agents
Agents provide support for the real-time MFS processes and the PSOS tasks.
The main agents are shown in Figure 14 .
These are:
Agents on OMCP board side
GPRS Operations and Maintenance (GOM)
Global Alarm Manager (GAM)
GPRS Equipment Manager (GEM)
GPRS Performance Manager (GPM)
LCS Global Manager (GLM)
TOMAS Hardware Management (GHM)
Q3 Agent
CNV (only for software replacement and migration).
Agents on XPU board side
Board and Alarm Manager (BAM)
Telecom Agent
Performance Management Agent (PM)
Session Configuration Agent (SCA)
LRM Agent
3.4.1 GOM
GOM manages the telecom resource configuration and supervision.
It works with the Telecom agent on each GP board and is responsible for:
BSS logical static and online configuration and activation. This includes
bearer channel, Gb Interface, GAter Mux Interface and cell management
domains. Validity checks are performed and persistent data is updated and
configured on the logical XPUs (LXPU).
Supervision of the domains for operational states and status. Changes are
notified to the administrative part of the process.
Processing of quality of service alarms.
Resynchronization of the LXPU resource states after a OMCP board
switchover.
Configuration of a LXPU when requested by the XPU (after a start, reset or
changeover).
CMPS requests processing.
59 / 62
3 Software
3.4.2 GAM
GAM manages and processes the hardware and telecom alarms of the MFS.
It processes all hardware and telecom alarms and is responsible for:
Collecting all the fault information which occurs in the MFS on the XPU,
OMCP, E1 Mux boards, ATCA shelves and the telecom alarms.
Recording alarms in a table.
Managing the relation between alarms reference and CMPS Distinguished
Name.
Allowing the IMT and the Q3 agent to access the alarms.
Generating ending alarms when a fault is cleared (for example, when a
XPU is replaced).
Managing a communication session with the IMT.
3.4.3 GEM
GEM manages the XPU hardware and low-layer software.
It handles all requests in the first steps of GP initialization and it is
responsible for:
XPU software booting.
Session layer configuration.
XPU framer hardware configuration (including data for clock
synchronization).
XPU switch configuration for circuit switched connections.
E1 Mux boards configuration and supervision.
NE1oE configuration on GP and E1 Mux board.
PCM-TTP supervision.
Hardware alarm reporting for XPU boards using the shelf manager and IPMI
interface and hardware control for XPU boards (reset, RI management).
XPU spare initialization and redundancy.
Version change management of GPs and E1 Mux boards.
Time management for XPU boards.
Manages the LXPU defence and XPU switchover
The administrative part of GEM also handles requests concerning:
XPU cross connections and PCM-TTP objects arriving via the Common
Management Protocol Syntax (CMPS) interface.
Static objects created during commissioning.
60 / 62
3 Software
3.4.4 GPM
GPM manages the PM domain and it is in charge of:
Configuring the scanner on the LXPU.
Collecting the PM counters from the LXPU.
Generating a file containing the counters and their values.
Process CPMS requests.
3.4.5 GLM
The LCS global manager is in charge of :
LCS configuration on BSS, cells and SAGI interface.
External router supervision for the two Ethernet networks.
Alarm reporting regarding the SAGI interface (the router connection).
3.4.6 GHM
GHM is in charge of hardware management of:
OMCP boards (active and stand-by).
Switch boards and Ethernet links.
ATCA rack and ATCA shelf (power modules, fan, shelf manager...).
3.4.7 Q3
Q3 agent manages the Q3 interface to the OMC-R.
It is responsible for processing OMC-R configuration or supervision requests
concerning the MFS. (detecting faults and supervising the O&M states and
status.)
It is responsible for processing OMC-R requests concerning:
Configuration of hardware, transport, GAterMux, FR, Gb and radio domains.
Supervision of the above mentioned domains.
The Q3 agent is split in:
LA-PF (Local agent platform) component for TOMAS hardware.
LA-MFS component for MFS telecom.
3.4.8 BAM
BAM agent (also called XPU agent) is responsible for:
GPRS physical configuration.
This includes:
XPU clock synchronisation.
Framer and TDM switch configuration.
61 / 62
3 Software
Ethernet switch configuration.

NE1oE traffic switch in case of XPU switchover.
DSP download.
Supervision of the physical resources (for example, PCM-TTP interfaces
and synchronization).
Starting telecom tasks.
Reporting hardware and telecom alarms to GAM.
Providing log, trace and software error services for the LXPUs.
3.4.9 Telecom
Telecom agent is in charge of following O&M aspects:
BSS logical configuration and activation and the supervision of bearer,
GAter Mux Interface and cell management domains.
Network service configuration and the supervision of the Gb interface
domain.
3.4.10 PM
PM agent manages the scanner configuration and the collection of PM
counter values.
3.4.11 SCA
SCA agent manages network configuration and supervision.
3.4.12 LRM
LRM agent is in charge of:
LCS configuration including SAGI interface.
Management of GLM connection upon pilot election/de-election , and
uninstallation of LCS configuration when the GP is no more pilot.
62 / 62

MFS 9130 Functional Description

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

MFS 9130 Functional Description

Caricato da

Copyright:

Formati disponibili

Alcatel-Lucent GSM

A9130 MFS Evolution Functional

3BK 21272 AAAA TQZZA Ed.04

BLANK PAGE BREAK

3BK 21272 AAAA TQZZA Ed.04

3BK 21272 AAAA TQZZA Ed.04

3BK 21272 AAAA TQZZA Ed.04

3BK 21272 AAAA TQZZA Ed.04

3BK 21272 AAAA TQZZA Ed.04

3BK 21272 AAAA TQZZA Ed.04

This manual is intended for:

The reader must have a general knowledge of telecommunications systems,

3BK 21272 AAAA TQZZA Ed.04

3BK 21272 AAAA TQZZA Ed.04

1.1 Introduction to MFS

1.1.1 (E)GPRS Functions

Table 1: Standard (E)GPRS Functions

3BK 21272 AAAA TQZZA Ed.04

1.1.2 MFS Position in Network

: Base Station Subsystem

: Base Station Controller

: Multi Function Server

: Mobile Switching Center

: A1353-RA Operations and Maintenance Center-Radio

: Serving GPRS Support Node

: Gateway GPRS Support Node

: SMLC A-GPS Interface

: Base Transceiver Station

: Public Switched Telephone Network

Figure 1: MFS Position in Network

3BK 21272 AAAA TQZZA Ed.04

Other GPRS network elements are:

1.1.3 A9130 MFS Evolution Configurations

3BK 21272 AAAA TQZZA Ed.04

1.1.3.1 Rack Shared by A9130 BSC Evolution- A9130 MFS Evolution

"9 GP" (*)

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

1.1.3.2 Rack Shared by Two A9130 BSC Evolution

3BK 21272 AAAA TQZZA Ed.04

1.2 Functional Architecture

1.2.1 External Interfaces

Ater Mux + Gb Interface

IMT (Installation and Maintenance Terminal)

Figure 2: External MFS Interfaces

1.2.1.1 MFS-BSC Interface

3BK 21272 AAAA TQZZA Ed.04

1.2.1.2 MFS-TC Interface

1.2.1.3 MFS-MSC Interface

1.2.1.4 MFS-SGSN Interface

1.2.1.5 MFS-OMC-R Interface

1.2.1.6 MFS-IMT Interface

1.2.1.7 MFS-A-GPS Server Interface (SAGI)

3BK 21272 AAAA TQZZA Ed.04

1.2.2 Basic Architecture

Figure 3: A9130 MFS Evolution Basic Architecture

3BK 21272 AAAA TQZZA Ed.04

LIU shelf contains:

Quantity of OMCP, SSW, SHMC, PC and MUX boards have to be considered

Figure 4: A9130 MFS Evolution One Shelf Configuration

3BK 21272 AAAA TQZZA Ed.04

Figure 5: A9130 MFS Evolution Two Shelves Configuration

3BK 21272 AAAA TQZZA Ed.04

1.2.3 Detailed Architecture

Figure 6: Detailed A9130 MFS Evolution Architecture