9130 fuctional

Alcatel-Lucent GSM

9130 MFS Evolution Functional

Description

MFS Document

Sub-System Description

Release B10

3BK 21272 AAAA TQZZA Ed.06

Status RELEASED

Short title mxmfsfun

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

BLANK PAGE BREAK

2 / 62 3BK 21272 AAAA TQZZA Ed.06

Contents

Contents

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

1 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1 Introduction to MFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.1.1 (E)GPRS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.1.2 MFS Position in Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.1.3 9130 MFS Evolution Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2 Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2.1 External Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2.2 Basic Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.2.3 Detailed Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.2.4 Internal Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.2.5 Synchronization of 9130 MFS Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.2.6 Installation and Maintenance Terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.2.7 Connection with the OMC-R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.3 Traffic and Signaling Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.3.1 Physical Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.3.2 Packet Data Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.3.3 Temporary Block Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311.3.4 NC2 in Packet Transfer Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311.3.5 Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

1.4 GPRS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321.4.1 GP Telecommunications Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321.4.2 MFS O&M Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

1.5 SMLC Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2 Managed Objects and SBLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.1 MFS Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.1.1 MFS Managed Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.1.2 MFS Managed Object Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.1.3 MFS Managed Object Supported States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.1.4 MFS Managed Object Supported Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.1.5 MFS FRUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

2.2 MFS Managed Object Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.2 Global Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.3 Communication Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.4 Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.4.1 GOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.4.2 GAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.4.3 GEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.4.4 GPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.4.5 GLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.4.6 GHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.4.7 Q3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.4.8 BAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.4.9 Telecom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.4.10 PM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.4.11 SCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.4.12 LRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3BK 21272 AAAA TQZZA Ed.06 3 / 62

Figures

FiguresFigure 1: MFS Position in Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 2: External MFS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Figure 3: 9130 MFS Evolution Basic Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Figure 4: 9130 MFS Evolution One Shelf Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figure 5: 9130 MFS Evolution Two Shelves Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Figure 6: Detailed 9130 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 3BK 21272 AAAA TQZZA Ed.06

Tables

TablesTable 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

3BK 21272 AAAA TQZZA Ed.06 5 / 62

Tables

6 / 62 3BK 21272 AAAA TQZZA Ed.06

Preface

Preface

Purpose This document describes the functions and software of the 9130 MFS Evolution.

What’s New In Edition 06Improve Synchronization of 9130 MFS Evolution (Section 1.2.5) with the newcondition for autonomous synchronization of the MFS.

Description improvement in 9130 MFS Evolution Configurations (Section 1.1.3).

In Edition 05Update for new equipment naming.

In Edition 04Description improvement in 9130 MFS Evolution Configurations (Section 1.1.3).

In Edition 03The following sections were updated due to new Gb routing configurations:

Synchronization of 9130 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 9130 BSC Evolution- 9130 MFSEvolution (Section 1.1.3.1).

First release of the document.

In Edition 02Description improvement in:

Rack Shared by 9130 BSC Evolution- 9130 MFS Evolution (Section 1.1.3.1)

Synchronization of 9130 MFS Evolution (Section 1.2.5).

3BK 21272 AAAA TQZZA Ed.06 7 / 62

Preface

In Edition 01First release of the document.

Audience This manual is intended for:

Commissioning personnel

Support and service engineers

OMC-R operators

Training department.

Assumed Knowledge The reader must have a general knowledge of telecommunications systems,terminology and Alcatel-Lucent BSS functions.

8 / 62 3BK 21272 AAAA TQZZA Ed.06

1 Functional Description


This section describes the 9130 MFS Evolution architecture, functions andfeatures.

3BK 21272 AAAA TQZZA Ed.06 9 / 62


1.1 Introduction to MFSGeneral Packet Radio Service (GPRS) extends the circuit-switched voice anddata 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 upto 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-Lucent (E)GPRS implementation, a new network element isadded to the BSS. This is the MFS which performs the GSM-defined GPRSPacket Control Unit function. The table below lists the standard (E)GPRSfunctions and shows where they are implemented. Implementation consistsof software only, or both software and hardware.

Function BTS MFS SGSN GGSN

CCU software - - -

PCU - software andhardware

- -

SGSN - - software andhardware

-

GGSN - - - software andhardware

Gb Stack - software andhardware

software andhardware

-

Table 1: Standard (E)GPRS Functions

10 / 62 3BK 21272 AAAA TQZZA Ed.06


1.1.2 MFS Position in Network

The position of the MFS within the Alcatel-Lucent BSS is shown in the figurebelow.

MS

MSC To PSTN

OMC−R

GGSN

TCBTS Ater Mux

Abis

SGSN

To Public DataNetworks

Ater Mux CS Traffic

Gb

Gb

BSC

MFSA−GPSServer

BTS

BSS

MS

MSC To PSTN

OMC−R

BSS

GGSN

TCBTS Ater Mux

Gb

PS Traffic

Abis

SGSN

To Public DataNetworks

Ater Mux CS Traffic

Gb

Gb

BSC

MFSA−GPSServer

SAGI

BTS

BTS : Base Transceiver Station

BSS : Base Station Subsystem

BSC : Base Station Controller

MFS : Multi Function Server

TC : Transcoder

MSC : Mobile Switching Center

OMC-R : 9153 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 : Public Switched Telephone Network

Figure 1: MFS Position in Network

The MFS supports multiple BSSs and MSCs. An MFS can be connected toseveral 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. Alink going through the MFS can contain circuit-switched, circuit-switched andpacket-switched, or packet-switched traffic.

In the uplink direction, packet-switched data from the MS are sent to the MFSas blocks which are assembled into packets. Depending on the coding schemein use, a block can consist of 20 or 30 bytes. When all the bytes have beenreceived, they are placed into packets of up to 1500 bytes for transmissionto the SGSN via the Gb Interface. In the downlink direction, packets aredisassembled in the MFS and sent to the MS as blocks of 20 or 30 bytes.

3BK 21272 AAAA TQZZA Ed.06 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 andconfigured by the OMC-R. In the same way that the MFS provides the

GPRS services to several BSCs, the SMLC performs locations servicesfor the same set of BSCs.

The Gateway GPRS Support Node (GGSN) - provides interworking with

external packet-switched networks.

1.1.3 9130 MFS Evolution Configurations

9130 MFS Evolution configurations can by defined based on the number ofused shelves or based on the number of TTPs supported by one GP board.

Based on the number of used shelves the following configurations can bedefined:

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 to16 E1/GP in autonomous clock synchronization mode or 14 E1/GP in

centralized clock synchronization mode. It is not possible to move to the twoshelves configuration without a complete restart of the MFS in configuration

mode. The main goal of this configuration is to allow a smooth migration torack 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/GPin autonomous clock synchronization mode or in centralized clock

synchronization mode. Such a configuration allows a smooth migration tothe two shelves configuration without outage.

Based on the number of the TTPs supported by each GP board the followingconfigurations can be defined:

12 TTPs per GPThis configuration allows supporting up to two subracks with smoothextension when going from one to two subracks.

14 TTPs per GPThis configuration is used for MFS in centralized clock synchronizationmode. The centralized clock distribution can be needed in case the MFS isconnected to a 9120 BSC of another site. In this case, centralized clockallows saving an E1 link.

16 TTPs per GPThis configuration is used for MFS in autonomous clock synchronizationmode. The autonomous clock is enough in case the MFS is not connectedto a 9120 BSC of another site. Contrary to clock centralized mode, theautonomous mode allows 16 TTPs connectivity.

12 / 62 3BK 21272 AAAA TQZZA Ed.06


Rack shared configuration for 9130 MFS Evolution and 9130 BSC Evolutionconsists of:

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

2 x independent BSC configurations in the same cabinet.

In both cases:

Each equipment is considered as independent (choice of each configurationfree in the limit of 1 x ATCA shelf per configuration)

In case of BSC and MFS, they are not considered as a stand alone node,

and MFS NE can be used by the rack shared BSC, but also by other nearbyBSCs (9130 BSC Evolution or 9120 BSC). MFS NE is not fully or only

dedicated to BSC traffic located in the same rack.

1.1.3.1 Rack Shared by 9130 BSC Evolution- 9130 MFS EvolutionYou can follow the board configurations in shelves in next table.

Equipment BSC capacity MFS capacity

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

ATCAShelf

1 1

CCP 1 2 3 4 5 NA

SPARECCP

1 1 1 1 1 NA

TPGSM 2 NA

GP NA 1 to 9(*)

SPARE GP NA 1

OMCP 2 2

SSW 2 2

LIU Shelf 1 1

MUX 2 2

LIU 8 8 16 16 16 8

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

Note: Quantity of TPGSM, OMCP, SSW and MUX boards have to be considered as 1activ + 1 stand-by for redundancy function per shelf.

1.1.3.2 Rack Shared by Two 9130 BSC EvolutionBoard configurations in each ATCA and LIU shelf are identical to single BSC.

3BK 21272 AAAA TQZZA Ed.06 13 / 62


1.2 Functional ArchitectureThis 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.

MFS

PCM Links

Ater MuxInterface

Gb Interface (Ethernet Link)

BSC

SGSN

FR Network

IMT (Installation and Maintenance Terminal)

TC

Ater Mux InterfacePCM Links

IMT

BSC

Ethernet Link

Ethernet Link

Gb Interface

Ater Mux + Gb Interface

A−GPS Server

Gb Interface

MSC

Ater MuxInterface

Gb Interface

IP Network

OMC−R O&M(Ethernet Link)

IP Network

Figure 2: External MFS Interfaces

1.2.1.1 MFS-BSC InterfaceThe interface between the MFS and the BSC (Ater Mux interface) is a 2 Mbit/sPCM link. The time slots within one link can carry both circuit-switched andpacket-switched traffic and SS7 signaling.

When the Ater Mux is mixed circuit-switched/packet-switched, the MFStransparently connects the circuit-switched time slots to the TC and convertsthe packet-switched time slots into the Gb interface protocol which is forwardedto the SGSN through the TC and MSC or through the MSC.

When the Ater Mux is fully packet-switched, the Gb traffic is forwarded directlyto the SGSN when there is a dedicated MFS-SGSN link (over a FR networkor over an IP network) or through the MSC when there is no dedicatedMFS-SGSN link.

The BSCLP interface is an Lb based protocol that allows communicationbetween the BSC and SMLC in a circuit-switched domain.

14 / 62 3BK 21272 AAAA TQZZA Ed.06


1.2.1.2 MFS-TC InterfaceThe interface between the MFS and the TC (Ater Mux interface) is a 2 Mbit/sPCM 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 InterfaceThe interface between the MFS and the MSC is used to carry the Gb interfacewhen there is no dedicated MFS-SGSN link.

1.2.1.4 MFS-SGSN InterfaceThe 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 InterfaceThe OMC-R is connected to the MFS via an Ethernet link. The OMC-R can becollocated with the MFS or remote.

1.2.1.6 MFS-IMT InterfaceAn Ethernet link is used to connect the Installation and Maintenance Terminalto the MFS. MFS commissioning and local management are performed usingthe maintenance terminal.

1.2.1.7 MFS-A-GPS Server Interface (SAGI)The SAGI interface is an Lb interface on TCP/IP that exchanges messagesbetween the SMLC and the external A-GPS server following an Assisted GPSpositioning request in the circuit-switched domain.

3BK 21272 AAAA TQZZA Ed.06 15 / 62


1.2.2 Basic Architecture

Functional blocks architecture of the 9130 MFS Evolution is shown in thefigure bellow:

E1 Boards

SSW

GPO&M GP

MFS

Figure 3: 9130 MFS Evolution Basic Architecture

9130 MFS Evolution architecture is based on ATCA standards.

There are two possible configurations for 9130 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 9130 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 3BK 21272 AAAA TQZZA Ed.06


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 consideredas 1 activ + 1 stand-by for redundancy function per shelf.

1234567890123456789123456789012345678912345678901234567891234567890123456789

CLOSED / OPEN H/S OOS




−48 / 60 VDC

4A

−48 / 60 VDC

4A

XPEM XLIU XMUXXLIU XLIU XLIU XLIU XLIU XLIU XLIU XDUM XPEMXMUX

LIUShelf 1

ATCAShelf 3

(ATCA Shelf 4)

PDU

SS

W

SS

W

GP

GP

GP

GP

GP

GP

GP

GP

GP

GP

Free space(LIU Shelf 2)

Air inlet

OM

CP

OM

CP

Free space

XDUM XDUM XDUMXDUMXDUMXDUM XDUM

Figure 4: 9130 MFS Evolution One Shelf Configuration

3BK 21272 AAAA TQZZA Ed.06 17 / 62


1234567890123456789123456789012345678912345678901234567891234567890123456789





1234567890123456789123456789012345678912345678901234567891234567890123456789





−48 / 60 VDC

4A

−48 / 60 VDC

4A

XPEM XLIU XMUXXLIU XLIU XLIU XLIU XLIU XLIU XLIU XLIU XLIU XLIU XLIU XLIU XLIU XLIU XLIU XPEMXMUX

LIUShelf 1

ATCAShelf 3

ATCAShelf 4

PDU

SS

W

SS

W

GP

GP

GP

GP

GP

GP

GP

GP

GP

GP

SS

W

SS

W

OM

CP

OM

CP

GP

GP

GP

GP

GP

GP

GP

GP

GP

GP

Free space

(LIU Shelf 2)

GP

GP

Air Inlet

Air Inlet

Figure 5: 9130 MFS Evolution Two Shelves Configuration

18 / 62 3BK 21272 AAAA TQZZA Ed.06


1.2.3 Detailed Architecture

The 9130 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 fornaming information.

LIU LIU

MUX MUX

PEM PEM

PEM02

1 − 8 9 − 16

GP

1 − n

SHMC01 SHMC02

PC01 PC02

OMCP01 OMCP02

ATCA Shelf

LIU Shelf

SwitchBoardSSW01

RTM Switch

RSSW01

SwitchBoardSSW02

RTMSwitch

RSSW02

PEM01

AterGbAter

Gb

OMC−R A−GPS

IMT PCSGSN

Consolelink

Consolelink

To PDUDC Power

To PDUDC Power

OMC−RA−GPSIMT PCSGSN

Figure 6: Detailed 9130 MFS Evolution Architecture

3BK 21272 AAAA TQZZA Ed.06 19 / 62


1.2.3.1 OMCPThe O&M Control Processing board is based on ATCA technology. This boardis equipped with a permanent storage device and is in charge of managing theO&M applications and whole platform as system manager.

There are two ATCA OMCP boards in the MFS, working in an active/standbymode. They ensure the interface to the OMC-R.

The active OMCP board manages a set of GP boards, each of them responsibleat least for GPRS functions in one BSS (routing of LLC PDUs from SGSNtowards the BTS and MS through the BSC or vice-versa).

The active OMCP is responsible for the management of the E1 MUX boardstoo. The E1 links are terminated in the E1 Termination boards and processedby one or several GP boards.

In 9130 MFS Evolution, there are no shared disks. System data and Telecomdata are stored in the single local disk of the OMCP with TOMAS networkmirroring, in order to secure data on the peer OMCP board. This solution isbased on LVM (Logical Volume Management ) and ext3 Linux partitions.

1.2.3.2 GPThe GP board implements the telecommunication function, same as previousGPU in 9135 MFS, and the NE1oE function. Also compared to the GPU in9135 MFS the processing capacity of the GP board has increased by fourtimes. It means, for example, that the GP can now handle 960 PDCHs insteadof 240 PDCHs.

GP Radio Processing boards manage the user plane packet data flowprocessing. The GP boards send/receive their E1 links over Ethernet to/fromthe 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 switchusing 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 9130 MFS Evolutionis a n+1 protection, that is n active GP boards and 1 standby (spare) GPboard. The spare GP is designated for both ATCA shelves. The spare GP isconsidered as a floating spare during MFS operation.

When a hardware fault occurs on an active board, an automatic switch-over istriggered. No outage of the speech traffic occurs. The former active boardwill be automatically elected standby and can take over any GP of the MFS

20 / 62 3BK 21272 AAAA TQZZA Ed.06


rack in case of hardware failure. In this context the switch back administrativerequest is no longer needed.

1.2.3.3 SSWSSW is a Gigabit Ethernet switch which allows exchanges between all theelements 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 boardsoperate simultaneously (as the TOMAS secured LSN) , i.e. the paths to theLIUs are available through both boards; so the switch can be solved internallyand very quickly (i.e. transparently, in term of service), by sending again anot acknowledged message through the other path. This should not induceany telecom outage.

1.2.3.4 SHMCTwo shelf management modules are implemented in the ATCA shelf: oneactive, 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, andtakes 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 PCThe Shelf Personnality Card (PC) is a general purpose device to provide all thefunctions that may not be included by the other Field Replaceable Units (FRUs).

PC provides following functions:

Contains the Shelf FRU Information Store

3BK 21272 AAAA TQZZA Ed.06 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 PEMTwo (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 thebackplane. The current of the two PEM versions have a 90 Amp breaker. TwoPEMs are used to feed all redundant FRUs. Four PEMs are used to providesplit 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 tothe 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 FANThe FAN unit provides ventilation for the subrack.

Each FAN tray monitors and reports air temperature and failure conditions tothe shelf manager. The shelf manager controls the FAN speed based onsensor and failure information acquired from the FAN and board sensors. If aFAN tray loses IPMI communication with the shelf manager, it will automaticallyrun the FANs at full speed.

1.2.3.8 LIU Boards - E1 Termination BoardsLIU 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, inaccordance with the capacity of the 9130 MFS Evolution.

LIU shelf manages the multiplexing/demultiplexing and cross-connecting of allE1 external links toward or from a GP board (n E1 over Ethernet).

Incoming/outgoing PCMTTPs are connected to the boards located on theLIU shelf, independently of GP boards. Therefore, there is no more a fixedassociation between external (through LIUs) TPs (on the E1 terminationboards) and GP boards. These associations between GP TPs and LIU TPs (viaSSW boards switched connections), have to be defined through configurationdirectives (BUL files).

22 / 62 3BK 21272 AAAA TQZZA Ed.06


1.2.3.9 LIU MUXThe LIU MUX board, part of the LIU shelf, ensures the concentration of 256 E1PCM 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 PEMThe 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 bitEthernet interface. It defines a private network including two independentsub-nets.

9130 MFS Evolution relies on the double Ethernet and supervisionmanagement provided by TOMAS.

Following protocols are used on 9130 MFS Evolution:

CS layer (TOMAS) over TCP for OMCP/GP communication

RMCP/SNMP for hardware management through 9130 MFS Evolutionservices

OMCP management of E1 boards using 9130 MFS Evolution services:

3BK 21272 AAAA TQZZA Ed.06 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 theE1 links payload over a Giga Ethernet link between LIU shelf (256 E1) and GPboard (12/14/16 E1). This transport is made through a Giga Ethernet switch(SSW board). The configuration and status retrieval of this module is underthe 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 NE1oEmodule 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 andthe CPI of MX Platform.

The interfaces are depicted in the figure bellow:

MFS Application

NE1oE Agent

OMCP MFS

NE1oE

NE1oE

GPs

MUXs

1.2.5 Synchronization of 9130 MFS Evolution

The clock synchronization service is provided by the hardware equipmentmanager of the MFS. This service allows a GP to synchronize its clock with theclock of an other Network Element (TC, 9130 BSC Evolution or SGSN).

In the case of GboIP feature, the synchronisation clock can’t be extracted fromthe SGSN. Depending on the Gb configuration, there can be three ways toprovide synchronization to the MFS:

“Mixed Gb” (FR and IP) : clock synchronization can be extracted from

the FR links

24 / 62 3BK 21272 AAAA TQZZA Ed.06


“Pure IP Gb”, MFS with existing links to TC : clock synchronization forAter TDM can be extracted from the TC links

“Pure IP Gb”, MFS with no existing links to TC : in this specificconfiguration, the MFS can get the synchronization from the 9130 BSC

Evolution or shall use the Centralized Timing Mode to synchronize Ater TDM.

Synchronization mode can be configured in the MFS bul profile. The chosenmode is global to the MFS: either autonomous or centralized. This mode isdefined during the commissioning and can not be changed unless the MFS iscompletely restarted in configuration mode.

The 9130 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,9130 BSC Evolution, SGSN ( 9130 BSC Evolution, TC, SGSN would alsowork correctly).

In case the MFS “single secured Gb” feature is used, the GPU synchronisationin autonomous mode can be used through the BSC links or through the TC linksif the Gb and the synchronisation from the TC do not share the same Atermux.

1.2.5.1 Autonomous Timing ModeThis mode uses the frequency extracted from one of the 16 PCM to synchronisethe GP and only the GP. The selected clock is not transmitted to the otherGPs. The source of synchronization is the TC, 9130 BSC Evolution or theSGSN which have high accuracy clock. In the case of GboIP feature, thesynchronisation clock can’t be extracted from the SGSN.

During the GP initialisation, the hardware equipment manager on OMCP sendsdata configuration to each GP. In this data, each GP finds a list of synchronizingPCM-TTP. The PCM-TTP priority is computed by the board. All the PCM-TTPcoming 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 thePCM-TTP with the highest priority as reference PCM for the board. Then, thesoftware has to initialize the time base module.

In case of failure of the signal clock taken as reference clock, the GP softwareswitches 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 thehighest PCM-TTP priority is performed automatically by the board.

1.2.5.2 Free Run ModeThis mode uses the local oscillator of the board. This free run mode is usedwhen the list of synchronization source PCM-TTP of internal PCM timingmode becomes empty because no more PCM-TTP are operational. (This isa defence mode for the MFS). An alarm is generated per GP board whenthis mode is used.

3BK 21272 AAAA TQZZA Ed.06 25 / 62


1.2.5.3 Centralized Timing ModeAT GPU level there is no difference with the autonomous mode except that onlytwo PCM-TTP per GP are synchronizing.

The equipment manager has to choose two E1s coming from thesynchronization source and configure nE1oE paths for all GPs in the rack (twoshelves). Two dedicated PCM_TTP equipped with same attributes as thesource will be updated in equipment manager MIB.

During the GP initialization, the hardware equipment manager on OMCPsends data configuration to each GP. In this data, each GP finds a list of twosynchronizing PCM - TTPs. Note that at board insertion, the PCM-TTP on portnumbers 0 and 1 are chosen by default. The GP computes the synchronizationpriority and takes the PCM-TTP with the highest priority as reference PCMfor the board.

1.2.6 Installation and Maintenance Terminal

The Installation and Maintenance Terminal (IMT) is the local or remote terminalof the MFS.

The IMT is used to maintain the MFS by:

Displaying and managing MFS alarms, then identifying particular MFSequipment 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 connectedto one of the external link of the base interface switch. It means that two linksare available in the OMCP for the O&M flow, including :

OMC-R interface

OMCP/E1 boards interface

OMCP/GP interface.

26 / 62 3BK 21272 AAAA TQZZA Ed.06


1.3 Traffic and Signaling LinksThe figure below shows the traffic and signaling links for both circuit-switchedand packet-switched connections.

1121121121121121

11121211121211121211121211121211

PCU

MFS

TC

BTS TCH

RSL

EGCH

BSCSS7

GCH

GSL

TCH

SS7

TCH

Gb + AterMux121121121

MSC

SGSN

Gb

Gb over FR

Gb over IP

Figure 7: Traffic and Signaling Links

The table below briefly describes the circuit-switched and packet-switchedtraffic and the signaling links.

Link Description

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/schannel. On the Ater Mux Interface, it is carried on a 16 kbit/schannel. Circuit-switched data is always carried on 16 kbit/schannels.

RSL Carries circuit-switched traffic management information forMS-to-network communication. It is carried on a 16 kbit/s or 64kbit/s channel. There is one RSL per TRE. The RSL also carriessignaling to control the BTS TRX.

SS7 Carries call control and mobility management informationbetween the MSC and BSC on a 64 kbit/s channel.

GCH Carries blocks of packet-switched data on a nx16 kbit/s channelbetween the BTS and MFS. The blocks are transparentlyrouted through the BSC to the BTS. There is one Ater resourcere-allocation per GCH for GPRS MS.

EGCH Carries packet-switched data traffic on nx16 kb/s channels (onemain GCH + a pool of auxiliary GCH) between the BTS andMFS. There is one EGCH per PDCH.

3BK 21272 AAAA TQZZA Ed.06 27 / 62


Link Description

GSL Carries packet-switched traffic management informationbetween the MFS and BSC on a 64 kbit/s channel. If a secondGSL is connected to the BSC for redundancy purposes, it mustbe on a different PCM link. GSL also carries location servicesmessages, when enabled.

Gb Carries packets of data to and from the SGSN on transparent n x64 kbit/s channels. This is a single link created by concatenatinga number of 64 kbit/s time slots. The HDLC or UDP/IP protocolis used, allowing remote SGSN connections to be made overa Frame Relay or IP network.

Table 2: Traffic and Signaling Link Descriptions

28 / 62 3BK 21272 AAAA TQZZA Ed.06


1.3.1 Physical Channel

The physical channel which supports the different packet data logical channelsis 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 ofeight PDCHs are possible per TRX. The figure below shows the Air Interfacestructure for one PDCH.

Time Slots 876543287 1 1 2 3 4 5 6 7 8 2 31

310 42 5150 051

TDMA Frame (4.615 ms)

Multiframe = 52 TDMA Frames (240 ms)

Frames

Figure 8: PDCH Air Interface Structure

In the example in the figure above, TS2 of each TDMA frame forms part of thesame 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) isthe 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 logicalchannels.

The figure below shows the air interface block structure.

3

Multiframe = 52 TDMA Frames (240 ms)

Frame

0 1 2 4 5 6 7 8 9 10 11

0 4 8 13 17 21 26 30 34 39 43 47

Block

0

Figure 9: Air Interface Block Structure

Each block consists of four consecutive TDMA frames. For example, Block 3consists of TDMA frames 13-16. A block is the basic unit for transferringinformation on the PDCH.

The blocks are shared by the packet data logical channels. In the case of theMaster Packet Data Channel (MPDCH) (see Section 1.3.2 ), Block 0 is reservedfor the Packet Broadcast Control Channel (PBCCH) in the downlink direction.

3BK 21272 AAAA TQZZA Ed.06 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 informationto the MS. This includes paging, access grant and random access. When PCCCH is notallocated, the circuit-switched CCCH is used to initiate the packet data transfer. WhenPCCCH is allocated, PCCCH, PBCCH and Packet Data Traffic Channel (PDTCH) (seebelow) 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 toaccess the network for packet transmission. The existence of PCCCH (and consequentlythe 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 differentAir 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 resourceassignment message. PACCH is bi-directional.

PTCCH Provides a bi-directional continuous timing advance mechanism. The MS is allocated asub-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 referredto as the MPDCH. The location of the MPDCH is defined by the BCCHsystem information.

When an MPDCH is not defined, both the circuit-switched and packet-switchedsignaling use the BCCH and CCCH. The BSC forwards uplink CCCH flowto the MSC or MFS, as required.

Declaring an MPDCH is an operator choice which is based on the overall trafficdensity and relative loads of circuit-switched and packet-switched traffic. Ifpacket-switched traffic is low, an MPDCH is not declared.

30 / 62 3BK 21272 AAAA TQZZA Ed.06


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 dataon 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 identifiesthe blocks belonging to one message. Each block in the downlink directionalso contains an Uplink Status Flag (USF). The USF tells the MS when it cantransmit 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 packettransfer mode, reducing the number of cell reselections triggered during GPRSsessions. When activated, the network controls the cell reselection of each MSinvolved in the packet transfer. Each of these MS reports measurements on theserving cell and the six strongest surrounding cells, enabling the network todynamically 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).

3BK 21272 AAAA TQZZA Ed.06 31 / 62


1.4 GPRS FunctionsThe 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 GPPBA.

The telecommunications functions performed by the GP are described indetail 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 3BK 21272 AAAA TQZZA Ed.06


1.4.1.1 High Speed Data Service (HSDS)High Speed Data Service (HSDS) provides CS1 to CS4 for GPRS, and MCS1to MCS9 for EGPRS. It also offers additional functions that adapt radioresource allocation with EGPRS MSs to avoid Ater blocking by allocatingmore transmission resources on Abis and Ater to a radio time slot managingHSDS 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 Abislink, 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 definedfor 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 butGPRS throughput is optimized as long as it does not conflict with EGPRS

traffic.

T4 allocation: solves conflicts between uplink GPRS TBFs and downlinkEGPRS TBFs.

Dynamic transmission handling: PDCHs are established with the maximum

number of GCHs, whatever the supported traffic. Unused GCHs, dependingon traffic, are released in case of Ater congestion. For GPRS TBF allocation,

PDCHs are established with a reduced number of GCHs during the Atercongestion state.

3BK 21272 AAAA TQZZA Ed.06 33 / 62


1.4.1.2 Packet Radio Resource ManagementPacket radio resource management is concerned with the allocation andde-allocation of PDCHs to a cell.

A cell which supports packet-switched data allocates resources on one or morePDCHs to the MSs. The PDCHs are taken from a common pool of PDCHsmade available to the cell.

The allocation of physical channels for circuit-switched and packet-switchedservices is done dynamically, according to traffic load. Common controlsignaling in the initial phase of a packet-switched transfer is conveyed on thePCCCH (when MPDCH is defined) or on the CCCH (when MPDCH is notdefined).

The principle of dynamic allocation is illustrated in the figure below.

PDCHs

Time

2

4

6

High Load Notification

Normal Load Notification

Max Normal Load = 7(Max_PDCH)

Max High Load = 4(Max_PDCH_High_Load)

Min = 1(Min_PDCH)

Figure 10: Dynamic PDCH Allocation

The number of PDCHs available to the cell is defined by O&M parameterswhich 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 aredynamically 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 waitsfor a PDCH to become free (no TBFs assigned) and then requests the BSCto release it. This process continues until there are four PDCHs left. Later,when the BSC notifies the MFS of normal loading, the MFS requests additionalPDCHs from the BSC when they are required.

34 / 62 3BK 21272 AAAA TQZZA Ed.06


1.4.1.3 Packet Radio Resource AllocationPacket radio resource allocation is concerned with the number of PDCHsthat are assigned to the MS.

The number of PDCHs that can be assigned to the MS depends on the MSmultislot 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 forthe 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 forthe 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 forpacket-switched traffic, simplifying time slot allocation and decreasing PMUCPU loads.

1.4.1.4 T4 ReallocationT4 reallocation resolves conflicts between uplink GPRS TBFs and downlinkEGPRS TBFs when they share the same PDCH. Uplink GPRS TBF isreallocated on resources that don’t support any downlink GPRS TBFs.

1.4.1.5 Uplink Power ControlWhen the MS first accesses the cell on the PRACH, it uses the output powerlevel specified on the PBCCH. After this, the MS output power level is based onthe received signal strength. It is assumed that the power loss is the same foruplink and downlink.

3BK 21272 AAAA TQZZA Ed.06 35 / 62


1.4.1.6 Uplink Medium Access ModeContention control is not required in the downlink direction even if the PDCHis shared by several MSs.

In the uplink direction, contention control is required when multiple MSs sharethe same PDCH. The MFS avoids contention by authorizing particular MSs totransmit at particular times.

Medium access mode is the method by which the logical channels are allocatedon 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, ittransmits 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) USFvalue which marks the position of the PRACH on the uplink. A free USFvalue 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 (notthe USF) which authorizes the MS to transmit its acknowledgment. The

acknowledgment is required by the mechanism which schedules theuplink block.

1.4.1.7 Timing AdvanceThe correct value for the timing advance used by the MS when transmittinguplink blocks is derived in two parts:

Initial estimation. The BTS performs measurements on the single accessburst carrying the packet channel request and sends a value to the MS. This

value is used for uplink transmissions until the continuous timing advancemechanism provides a new value.

Continuous advance. The BTS analyzes received access bursts over

successive 52-frame multiframes and determines values which it sends tothe MS.

For the downlink direction, the initial timing advance value is computed onreception of the Packet Control Acknowledgment from the MS. The value isthen returned to the MS in a timing advance or power control message.

36 / 62 3BK 21272 AAAA TQZZA Ed.06


1.4.1.8 Paging ManagementThe network can co-ordinate circuit-switched and packet-switched paging. Thismeans that circuit-switched paging messages can be sent on the channelsused 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 onthe PPCH or CCCH paging channel, or on the PACCH. This means that theMS only needs to monitor one paging channel. It receives circuit-switchedpaging 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 circuit-switched paging message for the GPRS-attached MS is sent onthe CCCH paging channel. The channel is also used for packet-switchedpaging messages. This means that the MS only needs to monitor PCH.Circuit-switched paging continues on the PCH even if the MS is assigneda PDCH.

Network Operation Mode 3 - circuit-switched paging messages are sent viathe MSC and BSC, but not the MFS.The circuit-switched paging message for the GPRS-attached MS is sent onthe CCCH paging channel. The packet-switched paging message is sent oneither the PPCH (if allocated) or on the CCCH paging channel.

1.4.1.9 Channel CodingDifferent Coding Schemes (CSs) can be used for the data on the Air Interface:

CS1/CS4

MCS1 to MCS9.

1.4.1.10 Link AdaptationLink adaptation changes Modulation and Coding Schemes (MCS) accordingto radio conditions and CS1 to CS4. When radio conditions worsen, aprotected MCS with more redundancy is chosen, leading to a lower throughput.Inversely, when radio conditions improve, a less protected MCS is chosen forhigher throughput. Nine modulation and coding schemes enhance packetdata communications (EGPRS), providing raw RLC data rates ranging from8.8 kbit/s to 59.2 kbit/s. Data rates above 17.6 kbit/s require that 8-PSKmodulation are used on the air, instead of GMSK.

1.4.1.11 Gb StackCommunication 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).

3BK 21272 AAAA TQZZA Ed.06 37 / 62


1.4.2 MFS O&M Functions

The O&M functions of the 9130 MFS Evolution manage the:

Equipment

GP telecommunications application

Alarms

Performance.

1.4.2.1 Equipment ManagementThis 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 spareGP, and outage time during major software changes.

1.4.2.2 GP Telecommunications Application ManagementThis function manages the telecommunications application of each logical GP. Itis 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 ManagementThis function is responsible for the processing of hardware andtelecommunications alarms within the MFS.

The function:

Collects all fault information for telecommunications and external alarms, thetelecommunications hardware and the active OMCP.

Records the fault information in a secured table.

Allows the local maintenance terminal (IMT) and the OMC-R to accessthe fault information.

38 / 62 3BK 21272 AAAA TQZZA Ed.06


Generates the end report for pending alarms.

Manages the communications with the IMT.

1.4.2.4 Performance ManagementThis 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 FunctionsSMLC 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, andpresents the MS location estimate in standard format.

Requests GPS Assistance Data from the external A-GPS server andprovides 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 tothe 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.

3BK 21272 AAAA TQZZA Ed.06 39 / 62


40 / 62 3BK 21272 AAAA TQZZA Ed.06

2 Managed Objects and SBLs


This chapter describes the MFS Managed Objects and SBLs. It provides theallowed states for both Managed Objects and SBLs. It maps Managed Objectsand SBLs to the corresponding RIT.

3BK 21272 AAAA TQZZA Ed.06 41 / 62


2.1 MFS ObjectsThis 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. Thenaming attribute is used to construct the RDN (Relative Distinguish Name)of subordinate objects of this class. An RDN is constructed from the objectidentifier assigned to that attribute type and the value of the instance of theattribute.

The table bellow contains the ASN.1 (Abstract Syntax Notation) types foreach 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

extendedCurrentAlarmSummaryControlcurrentAlarmSummaryControlId NameType

managedElement managedElementId NameType

42 / 62 3BK 21272 AAAA TQZZA Ed.06


Managed Object Class Naming Attribute Type ASN.1

nectarCircuitPack equipmentId NameType

nectarFRU equipmentId NameType

Table 4: MFS Managed Object Classes

3BK 21272 AAAA TQZZA Ed.06 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 theindicated Managed Objects.

managed Element(M3100)

event Forwarding Discriminator extendedCurrentAlarmSummaryControl

aGprsManagedElementExtension

aGprs2MbTTP aGprsNse aGprsBssFunctionequipmentHolder(M3100)

aGprsBearerChannel aGprsNsvc aGprsBtsSiteManagercrossConnection

(M3100) aGprsLapdLink

aGprsPvc aGprsBtsaGprsGicGroup

aGprsMasterChannelData aGprsPowerControl aGprsPdchGroup

Circuit Pack(M3100)

aGprsAdjacentCellReselection

aGprsFabric

aGprsSgsnIpEndPoint

Figure 11: Hierarchy of MFS Managed Objects

44 / 62 3BK 21272 AAAA TQZZA Ed.06


2.1.3 MFS Managed Object Supported States

The supported states of MFS Managed Objects are indicated in the followingtable.

Following notations are used:

S Supported/ Implemented

NS Not Supported/ Not Implemented

Managed ObjectClass

AdministrativeState

OperationalState

AvailabilityStatus

aGprs2MbTTP S S S

aGprsAdjacentCellReselection - - -

aGprsBearerChannel - S S

aGprsBssFunction S S S

aGprsBts S S S

aGprsFabric NS NS NS

aGprsGicGroup - - -

aGprsLapdLink S S S


- - -

aGprsMasterChannelData - - -

aGprsNse - - -

aGprsNsvc S S S

aGprsSgsnIpEndPoint S S S

aGprsPdchGroup - - -

aGprsPowerControl - - -

aGprsPvc - S S

aGprsbtsSiteManager - - -

circuitPack S S NS

crossConnection NS NS -

equipmentHolder NS NS -

eventForwardingDiscriminator NS NS NS

extendedCurrentAlarmSummaryControl

- - -

managedElement NS NS -

3BK 21272 AAAA TQZZA Ed.06 45 / 62


Managed ObjectClass

AdministrativeState

OperationalState

AvailabilityStatus

nectarCircuitPack NS NS NS

nectarFRU NS S -

Table 5: Supported States of MFS Managed Objects

46 / 62 3BK 21272 AAAA TQZZA Ed.06


2.1.4 MFS Managed Object Supported Operations

The supported operations of MFS Managed Objects are indicated by acheckmark (X) in the following table.

Managed Object Class Supported Operations

Set Get Create Delete Lock Unlock Connect Disconnect

aGprs2MbTTP X X X X X X - -


X X X X - - - -

aGprsBearerChannel X X X X - - - -

aGprsBssFunction X X X X - - - -

aGprsBts X X X X - - - -

aGprsFabric - X - - - - X X

aGprsGicGroup - X X X - - - -

aGprsLapdLink X X X X X X - -


- X X(*) X(*) - - - -

aGprsMasterChannelData

X X X X - - - -

aGprsNse X X X X - - - -

aGprsNsvc X X X X X X - -

aGprsSgsnIpEndPoint X X X X X X - -

aGprsPdchGroup X X X X(**) - - - -

aGprsPowerControl X X X X(**) - - - -

aGprsPvc X X X X - - - -

btsSiteManager X X X X - - - -

circuitPack X X - - - - - -

crossConnection - X - - - - - -

equipmentHolder - X X(*) X(*) - - - -

eventForwardingDiscriminator

X X X X - - - -


X X - - - - - -

3BK 21272 AAAA TQZZA Ed.06 47 / 62


Managed Object Class Supported Operations

Set Get Create Delete Lock Unlock Connect Disconnect

log X X X X - - - -

managedElement X X X(*) X(*) - - - -

nectarCircuitPack X X X(*) X(*) - - - -

nectarFRU - X X X - - - -

(*) 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 3BK 21272 AAAA TQZZA Ed.06


2.1.5 MFS FRUs

The field replaceable units in the MFS are listed in the following table:

FRUAlcatel-Lucentmnemonic 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, plugand 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

3BK 21272 AAAA TQZZA Ed.06 49 / 62


2.2 MFS Managed Object DescriptionThe description of MFS Managed Objects is listed in the following table.

Managed Object Class Description

aGprs2MbTTP This Managed Object class is a 2 Mb port managing objects that terminates thetransport entities, such as trails and connections. All attributes are assignedvalues at create time.


This Managed Object class focuses on the cell reselection adjacencies relatedto GPRS functionality. This object is created for each adjacent cell to thecontaining 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 theGb interface. It can be a set of 64 kb time slots (case framed 2Mb-TTP). Thebearer channel supports the PVCs.

aGprsBssFunction Represents a BSS network element. (Only the BSSs with GPRS capabilityare seen at the OMC/MFS interface and can be configured by the operator.).Object AGprsBssFunction is created when Non GPRS BSS becomes GPRSBSS. Moreover, Gb_Transport_Mode is defining what type of Gb we aredealing with: FR or IP.

aGprsBts Represents the O&M functionality related to a specific cell within a BTSequipment.

aGprsFabric Represents the function of managing the establishment and the release of thecross-connections of 2Mb-TTPs ports.

aGprsGicGroup A Managed Object of this class represents the set of all GICs pertaining all tothe same Ater interface at the BSC side. The GICs have been grouped per Aterbecause all GICs of the same Ater have the same operational state (dependingon the state of the DTC board at the BSC).

aGprsLapdLink This Managed Object is the 64k channel on the MFS-BSC interface supportingthe GSL on a given BSC-MFS interface. The GSL uses the GPRS LapD linksin load sharing. The GSL is not managed as an object class.


This Managed Object class is a class of Managed Objects that provideadditional services related to the managedElement object class for differentdomains (Radio, Ater-Gb...). This is necessary because managedElement is astandard Managed Object class and cannot be overloaded.

aGprsMasterChannelData This Managed Object class defines the characteristics (attributes) of the cellthat are not required when there is no master channel.

aGprsNse The network service element (NSE) is an entity of the NSC telecom layer ofthe Gb interface. The NSE ensures the load sharing of the outgoing BSSGPmessages 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 isassociated to a set of NS-VCs / IP Endpoints and a set of BVCs . The NSE ischaracterized by its NSEI, also known by the SGSN.

50 / 62 3BK 21272 AAAA TQZZA Ed.06



aGprsNsvc The network service virtual connection (NS-VC) is an entity of the networkservice control (NSC telecom layer on the Gb interface). It is an end-to-endvirtual connection between MFS and SGSN. The NS-VC is identified by itsNS-VCI, also known by the SGSN.

aGprsSgsnIpEndPoint An endpoint defined by its IP address and UDP port. An IP endpoint can be adata endpoint and/or a signalling endpoint.

aGprsPdchGroup This Managed Object class defines the configuration parameters of a group ofconsecutive channels.

aGprsPowerControl This Managed Object class focusses on the cell power control parameterrelated to GPRS functionality (one object instance per cell).

aGprsPvc This class represents the frame relay implementation of permanent virtualconnections.

btsSiteManager This Managed Object class represents the O&M functionality related to aspecific BTS equipment. Its purpose is containment (BTS sector or cellinstances).

circuitPack This Managed Object class is derived from M.3100 circuitPack class. Itrepresents boards that are present in Telecom subracks; these are GP boards.This object is created when the GP board is first plugged in. An objectCreationnotification is the emitted. The board is deleted when it is unplugged. AnobjectDeletion notification is the emitted.

crossConnection Represents the cross-connection function between two 2Mb-TTPs (the ’fromtermination’ 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 ofholding other physical resources. It is created by NECTAR at initializationusing the NECTAR ’profile’ configuration file. In particular, this file is usedto configure the userLabel.

eventForwardingDiscriminator

Represents an Managed Object class that contains a discriminator constructthat specifies the characteristics a potential event report must satisfy in orderto be forwarded.


Represents an Managed Object class of support objects that provide thecriteria for generation of current alarm summary reports.

log (not installed) This Managed Object class represents a repository that may be used for alarmlogging.

managedElement This Managed Object class represents the MFSnetwork element. Its purposeis containment, allowing the associations of various functions that make up aninstance of this network element. It is created by NECTAR at initializationusing the NECTAR ’profile’ configuration file. In particular, this file is usedto configure the userLabel.

3BK 21272 AAAA TQZZA Ed.06 51 / 62



nectarCircuitPack This class is derived from M.3100 circuitPack class. It is created by NECTAR atinitialization using the NECTAR ’profile’ configuration file. In particular, this fileis used to configure the userLabel.

nectarFRU This Managed Object class represents the FRUs of the platform suchas 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 3BK 21272 AAAA TQZZA Ed.06

3 Software

3 Software

This chapter describes the 9130 MFS Evolution software.

3BK 21272 AAAA TQZZA Ed.06 53 / 62

3 Software

3.1 OverviewThe software manages the telecommunications and O&M aspects of theMFS. It runs in the OMCP and XPU boards. The figure below shows themain software components.

As a notation XPU represents the function of the GP board.

Hardware

Hardware

LINUX OS

PSOS

General Software

TOMAS

MFS Application

Telecom Application

Active OMCP XPU

OS Operating SystemPSOS Provable Secure Operating System

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

MFS application. This supervises the MFS and downloads the

telecommunications application to the GP where the telecom functionsare performed.

Each XPU contains the following software components:

Provable Secure Operating System (PSOS)

Telecommunications application

SMLC software.

54 / 62 3BK 21272 AAAA TQZZA Ed.06

3 Software

3.2 Global ArchitectureThe O&M software architecture is shown in the figure below.

Active OMCP

LINUX OS

Standby OMCP

XPU Board

LINUX OS PSOS

TOMAS Platform

GPRS NE PlatformGPRS NE Platform

GPRS NE Platform

O&M Application

Telecom Application

TOMAS Drivers

TOMAS Drivers

XPU Drivers

Equipment Manager

Telecom Manager

TOMAS Platform

Mx Platform

Figure 13: O&M Global Architecture

When an OMCP board operates in the standby mode, it does not run theO&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 activeon both OMCP boards.

Supervises the telecommunications equipment (XPU, E1 Mux boards,

PCM) and collects all alarms. These functions are not active on thestandby 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.

3BK 21272 AAAA TQZZA Ed.06 55 / 62

3 Software

3.3 Communication ChannelsCommunication between the XPUs and the OMCP boards takes place assessions 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 configurationrequests 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 andreports 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 aPSOS task (in the XPU) and a MFS Real-Time Agent (MRTA) as shownin the figure below.

56 / 62 3BK 21272 AAAA TQZZA Ed.06

3 Software

Real−time

Admin

Real−time

Admin

Real−time

Real−time

Admin

Real−time

DMCFGMIB

DMRSCMIB

Common Management Protocol Syntax (CMPS) Interface

GOM GPM

TRM LRMSMLC PMSCA

OMCP

XPU

PSOS Task MFS SCIM NECTAR SCIM Communications Service Session

BAM

GAMGLMGEM

RRM NS Bearer

CFG MIB: SEMI−PERMANENT CONFIGURATION DATA

RSC MIB: DYNAMIC RESOURCE DATA (STATES)

Q3 Agent

COMET

LA−MFS

LA−PF

OMC CRAFT TERMINAL

Admin

Real−time

GHM

Figure 14: MFS Agents and Processes

3BK 21272 AAAA TQZZA Ed.06 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 receivedfrom the XPU.

The real-time processes support data persistency. Configuration data is storedin a table and a backup copy is retained on disk. Resource data is also storedin a table but there is no backup.

58 / 62 3BK 21272 AAAA TQZZA Ed.06

3 Software

3.4 AgentsAgents 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 managementdomains. 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 boardswitchover.

Configuration of a LXPU when requested by the XPU (after a start, reset orchangeover).

CMPS requests processing.

3BK 21272 AAAA TQZZA Ed.06 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 isresponsible 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 IPMIinterface 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 3BK 21272 AAAA TQZZA Ed.06

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 requestsconcerning the MFS. (detecting faults and supervising the O&M states andstatus.)

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.

3BK 21272 AAAA TQZZA Ed.06 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 interfacedomain.

3.4.10 PM

PM agent manages the scanner configuration and the collection of PMcounter 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 3BK 21272 AAAA TQZZA Ed.06

9130 fuctional

Documents