9135

Alcatel-Lucent GSM
9135 MFS Description
MFS Document Sub-System Description Release B10
3BK 21232 AAAA TQZZA Ed.05
BLANK PAGE BREAK
Status Short title
RELEASED 9135 MFS

All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
2 / 84
Contents
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 MFS Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Introduction to MFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 MFS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 (E)GPRS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 MFS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Telecommunications Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Server Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3 Hub/Switch Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.4 OMC-R Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 External Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Traffic and Signaling Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 Physical Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2 Packet Data Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.3 Temporary Block Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.4 NC2 in Packet Transfer Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.5 Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5 GPRS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 GPU Telecommunications Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2 Abis Resource Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.3 MFS O&M Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.4 SMLC Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Cabinet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Dimensions and Weight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.4 Cables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Power System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 MFS Rack Power Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 MFSDS10 Power Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Top Rack Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4 Bus Bars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.5 Telecommunications Subracks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.6 Server Subrack in MFSRACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.7 Server Subrack in MFSDS10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.8 Hub/Switch Subrack in MFSRACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.9 O&M System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Subracks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Telecommunications Subrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Server Subrack for MFSRACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Server Subrack for MFSDS10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.4 Hub/Switch Subrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Rack Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Rack Configurations with AS800 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Rack Configurations with DS10 Server (DS10/RC23 and DS10/RC40) . . . . . . Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 O&M Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Communication Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managed Objects and RITs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7 8 8 9 10 12 13 13 13 14 16 17 18 19 19 19 20 20 26 27 28 29 30 30 32 33 34 36 36 37 38 38 38 38 39 39 39 39 39 49 53 60 63 64 66 69 70 71 72 74 77
3 / 84
Contents
4.1
4.2
MFS Managed Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 MFS Managed Object Class, Naming Attribute and Description . . . . . . . . . . . . . 4.1.2 MFS Managed Object Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 MFS Managed Object Allowed States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.4 MFS Managed Object Supported Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MFS RITs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78 78 81 82 83 84
4 / 84
Preface
Preface
Purpose Whats New
The 9135 Multi-BSS Fast Packet Server Description describes the functions, hardware and software of the MFS.
In Edition 05
Improve Clock Synchronization (Section 2.3.1.4) with the new condition for autonomous synchronization of the MFS.
In Edition 04
Update with the new equipment naming.
In Edition 03
Improvements made in Hub/Switch Subsystem (Section 1.2.3), Cables (Section 2.1.4),Modules (Section 2.3.3.1), Hub/Switch Subrack (Section 2.3.4), Modules/PBAs (Section 2.3.4.1), MFS Managed Object Hierarchy (Section 4.1.2), MFS Managed Object Allowed States (Section 4.1.3), MFS Managed Object Supported Operations (Section 4.1.4) Improvements made in Clock Synchronization (Section 2.3.1.4). Add GB over IP, new transport mode for the GB interface
In Edition 02
Improvements made in Clock Synchronization (Section 2.3.1.4).
In Edition 01
First official delivery in B10.
Audience
This manual is intended for: Commissioning personnel Support and service engineers OMC-R operators.
5 / 84
Preface
Assumed Knowledge
The reader must have a general knowledge of telecommunications systems, terminology and Alcatel-Lucent BSS functions.
6 / 84
1 MFS Functional Description

This section provides an overview of the MFS. It describes the MFS architecture, including related external interfaces, presents the functions and features of the MFS, and introduces the traffic and signalling links used by the MFS.
7 / 84
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. A mobile station that is fitted with the (E)GPRS facility can transmit and receive data up to an approximate theoretical maximum of 150 kbit/s. The Alcatel-Lucent solution provides the Multi-BSS Fast Packet Server (MFS) to perform both circuit and high speed packet switching. The MFS is internal to the BSS and provides the following basic functions: PCU (Packet Control Unit) functions, including: PAD (Packet Assembly/Disassembly) function Scheduling of packet data channels Automatic Retransmission Request functions Channel access control functions Radio channel management functions. The Gb Interface protocol stack, with 2 transport mode: over Frame Relay over IP (not for AS800).
1.1.1 MFS Overview

The position of the MFS in the Alcatel-Lucent BSS is shown in the figure below.
To Public Data Networks OMCR Gb Gb MS SGSN PS Traffic GGSN Gb MFS
AGPS Server
BSS BSS
Gb
BTS Ater Mux Abis BTS BSC Ater Mux TC MSC
CS Traffic To PSTN
CS CircuitSwitched Traffic Gb MFS/SGSN Interface
GGSN Gateway GPRS Support Node PS PacketSwitched Traffic
PSTN Public Switched Telephone Network SGSN Serving GPRS Support Node
The MFS communicates primarily with the following GPRS network elements: The Serving GPRS Support Node (SGSN), which provides the BSS with mobile packet switching functions, including security and an interface to the Home Location Register (HLR). The Serving Mobile Location Center (SMLC), which is integrated into the MFS and is 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.
8 / 84
The Gateway GPRS Support Node (GGSN), which provides interworking with external packet-switched networks. For more information about these GPRS Elements , refer to the BSS System Description. 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 mobile station are sent to the MFS as blocks which are assembled into packets. Depending on the coding scheme in use (see GPU Telecommunications Functions (Section 1.5.1) ), 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 mobile station as blocks of 20 or 30 bytes. For more information about the Multi-BSS Fast Packet Server , refer to the BSS System Description.
1.1.2 (E)GPRS Functions

The table below lists the standard (E)GPRS functions and shows where they are implemented (software only, or both software and hardware). Function CCU PCU SGSN GGSN Gb Stack BTS software MFS software and hardware software and hardware SGSN software and hardware software and hardware GGSN software and hardware -
For more information about (E)GPRS-Specific Implementation , refer to the BSS System Introduction.
9 / 84
1.2 MFS Architecture

This section provides an overview of the MFS architecture and describes the three major subsystems of the MFS: Telecommunications Server Hub/Switch. The MFSs basic architecture is shown in the figure below.
Server Subsystem
Server A
PCM Links GPU
Duplicated Ethernet LANs
PCM Links GPU
Hub/Switch Subsystem
Telecommunications Subsystem
Spare GPU
Ethernet
IP Network
SGSN
GPU LAN
GPRS Processing Unit Local Area Network
10 / 84
The MFS architecture is shown in more detail in the figure below.

Redundant GPU BAREDC2 (for Redundant GPU) Telecommunications Subrack
GPU PCM Links JAE1/JAE1C Subrack Midplane
JBETI
ICL/ISL Busses JBETI
Power Alarms External Alarms External Settings
JAETI
BATTU
BATTU
JAETI
Power Alarms External Alarms External Settings
To IMT To SGSN
Ethernet
To SGSN Ethernet Hub/Switch A1 Ethernet Hub/Switch B1
Ethernet Hub/Switch A2
Ethernet Hub/Switch B2
Server Subrack
Server A
Server B
Terminal Server
To OMCR
Hub/Switch Subrack PCM Links Ethernet Links ICL/ISL Links RS232 Links
11 / 84
1.2.1 Telecommunications Subsystem

The telecommunications subsystem containes two subracks. Each subrack contains two power supply units. The subracks have a midplane with PBAs inserted from both the front and the rear. The subsystem uses the GPRS Processing Unit (GPU) PBA to implement the PCU function. These are inserted from the front. Up to 16 GPUs can be fitted in one subrack. Each GPU has an associated applique (JAE1 (120Ohm) or JAE1C (75Ohm)). These rear inserted appliques are used for physical line termination and as elements of an n+1 redundancy scheme. They are not protected by the redundancy mechanism. Communication between the servers and each GPU is via duplicated Ethernet connections which include the BATTUs and Ethernet hubs/switches. The RIT type of the GPU PBA is JBGPU2. The associated applique PBA for the redundant GPU is the BAREDC2. The associated applique PBAs for the duplicated JBETIs are the JAETIs. The JBETI provides alarm and status information for the servers. It detects the removal/insertion of its associated JAETI and, when required, resets or rolls back the GPU specified by the server with a minimum loss of time or GPRS telecom outage. The detection and reset functions are performed using the ICL/ISL buses. Each JAETI interconnects its associated JBETI with: The servers Three incoming cabinet power alarms Eight incoming alarms (external to the cabinet) Outgoing server-controlled settings for six external devices.
Note:
Most of the telecommunications PBAs have a JA (applique) or JB (board) prefix in their names. Refer to Telecommunications Subrack (Section 2.3.1) for specific layout information.
12 / 84
1.2.2 Server Subsystem

The server subsystem consists of two UNIX(TM) servers, one of which operates in redundant mode. In the event of the master server failing, the standby server becomes the master server. The servers have their own local disk storage and they also share at least two common disks. The server supervises the whole MFS cabinet and equipment and, in particular, the GPU PBAs. It gathers status and alarm information and communicates with the OMC-R to transfer O&M information. A IOLAN(TM) terminal server and an Installation and Maintenance Terminal (IMT) are used for the software installation, maintenance and hardware management of the servers. There are two types of servers: AS800 In this configuration, the servers and hubs are contained in separate subracks (refer to Subracks (Section 2.3) ) DS10 (RC23 or RC40) In these configurations, the servers and hubs/switches are contained in one subrack (refer to Subracks (Section 2.3) ). Both servers are interconnected via the Ethernet Hubs/Switches. The servers use RS-232 links via the terminal server and a Hub/Switch to connect to the IMT.
1.2.3 Hub/Switch Subsystem

The Hub/Switch subsystem consists of duplicated 100 Mbit/s Ethernet networks, one of which operates in redundant mode. The Ethernet networks interconnect the GPUs and servers and provide the connection points for the OMC-R and the IMT. Two Ethernet hubs/switches provide duplicated connections between the telecommunications subrack and the servers. If a second telecommunications subrack is fitted, two additional Ethernet hubs/switches are required.
Note:
There are the following limitations: The switch is not allowed for MFS with AS800 In order to support GB over IP, the old hubs/switches are replaced with Alcatel-Lucent OmniStack LS 6224 switches
1.2.4 OMC-R Connection

The interface with the OMC-R is IP over Ethernet. This can be extended using any available means.
13 / 84
1.3 External Interfaces

The external MFS interfaces are shown in the figure below.
OMCR Ethernet Link PCM Links Ater Mux Interface BSC PCM Links Ater Mux Interface Ater Mux + Gb Interface Gb Interface Gb Interface Ater Mux Interface BSC
IP Gb
IP Network
Gb Interface TC
MFS
FRDN
MSC
SGSN AGPS Server
Ethernet Link
Ethernet Link
IMT
IMT (Installation and Maintenance Terminal)
The external MFS interfaces are described in the following table. Interface MFS-BSC Interface Description 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, or through the MSC. The BSCLP interface is an Lb based protocol that allows communication between the BSC and SMLC in a circuit-switched domain. 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 SS7 on packet-switched time slots A mixed circuit-switched/packet-switched interface on the same Ater Mux. 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.
14 / 84
MFS-SGSN Interface
The interface between the MFS and the SGSN is used to carry the Gb interface. This interface can go through a: frame relay data network IP network.
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. An Ethernet link is used to connect the IMT to the MFS. MFS commissioning and local management are performed using the maintenance terminal. 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.
MFS-IMT Interface
MFS-A-GPS Server Interface (SAGI)
15 / 84
1.4 Traffic and Signaling Links

The figure below shows the traffic and signaling links for both circuit-switched and packet-switched connections.
MFS BTS TCH RSL MEGCH BSC TCH SS7
1122 211
GCH GSL
1221222 11211 1221222 11211

PCU
TCH SS7 Gb
TC
The table below briefly describes the circuit-switched and packet-switched traffic and the signaling links. Link TCH Description 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. Carries circuit-switched traffic management information for mobile station-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. Carries call control and mobility management information between the MSC and BSC on a 64 kbit/s channel. Carries blocks of packet-switched data on a 16 kbit/s channel between the BTS and MFS. The blocks are transparently routed through the BSC to the BTS. There is one Ater resource allocated per GCH for GPRS mobile stations. Carries packet-switched data traffic on 16 kb/s channels between the BTS and MFS. The blocks of all the PDCHs of a TRX are multiplexed on this link. 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. 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 protocol is used, allowing remote SGSN connections to be made over a Frame Relay network or through a IP network..
RSL
SS7 GCH
M-EGCH GSL
Gb
For more information about these traffic and signalling links, refer to the BSS System Description .
16 / 84
1.4.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 M-EGCH (composed of one to 36 16 kb/s GCH) per TRX. There are eight time slots in one TDMA frame, which means that each TRX can have up to eight PDCHs. The figure below shows the Air Interface structure for one PDCH.
TDMA Frame (4.615 ms) Time Slots 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3
Frames
51
50
51
Multiframe = 52 TDMA Frames (240 ms)
In the example shown 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 uses the frames in the multiframe as follows: Frames 25 and 51 are unused Frames 12 and 38 are used by the Packet Timing Advance Control Channel (PTCCH). The PTCCH is the packet data logical channel for mobile station timing advance control. The remaining 46 frames are organized into blocks of four consecutive frames (for example, Block 3 consists of TDMA frames 13-16) and are shared by the other packet data logical channels. The figure below shows the Air Interface block structure.
Frame Block 0 0 4 1 8 2 13 3 17 4 21 5 26 6 30 7 34 8 39 9 43 10 47 11 0
Multiframe = 52 TDMA Frames (240 ms)
Note:
In the case of the Master Packet Data Channel (MPDCH), Block 0 is reserved for the Packet Broadcast Control Channel (PBCCH) in the downlink direction. Refer to Packet Data Logical Channels (Section 1.4.2) for more information.
17 / 84
1.4.2 Packet Data Logical Channels

The table below provides a brief description of the packet data logical channels. Channel PCCCH Description The Packet Common Control Channel (PCCCH) provides common control information to the mobile station. This includes paging, access grant and random access. When the PCCCH is not allocated, the circuit-switched CCCH is used to initiate the packet data transfer. When the PCCCH is allocated, the PCCCH, Packet Broadcast Control Channel (PBCCH) and Packet Data Traffic Channel (PDTCH) share the same PDCH. The PCCCH supports the following 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 mobile station to access the network for packet transmission. The existence of PCCCH (and consequently the existence of the PBCCH) is indicated by the circuit-switched Broadcast Control Channel (BCCH). The Packet Traffic Channel (PTCH) carries user data and associated signaling: PDTCH. Mapped to one PDCH. Up to five PDTCHs can be allocated to one mobile station. Packet Associated Control Channel (PACCH). If multiple PDTCHs are assigned to one mobile station, 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 mobile station is allocated a sub-channel of the uplink PTCCH according to the timing advance index.
PTCH
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.
18 / 84
1.4.3 Temporary Block Flow

A Temporary Block Flow (TBF) is the physical connection used by the mobile station (uplink) or MFS (downlink) to support the unidirectional transfer of packet data on packet-switched physical channels. The TBF is allocated to: 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 mobile station when it can transmit data. For example, if the mobile station receives the required USF on Block n (downlink), it transmits its data on the following Block n+1 (uplink). For more information, refer to GPRS Network Functions in the BSS System Description.
1.4.4 NC2 in Packet Transfer Mode

During enhanced cell reselection, NC2 activates when the mobile station 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 mobile station involved in the packet transfer. Each of these mobile stations reports measurements on the serving cell and the six strongest surrounding cells, enabling the network to dynamically reselect a specific cell. For more information, refer to GPRS Network Functions in the BSS System Description.
1.4.5 Signaling
A GPRS Signalling Link (GSL) consists of a 64 kbit/s LAPD link between the MFS and the BSC. It is used to: Notify the BSC whether there is an MPDCH Carry paging, channel request and access grant messages if there is no MPDCH Receive cell state change information and BSC status Allocate SPDCHs to the MFS (BSC to MFS) Report SPDCH usage and radio usage to the BSC (MFS to BSC) Allocate Abis nibbles (MFS to BSC) Ask the BSC for cross-connection between Abis and Ater nibbles (MFS to BSC). For more information, refer to GPRS Network Functions in the BSS System Description.
19 / 84
1.5 GPRS Functions

The MFS performs two main types of functions: GPU telecommunications MFS O&M.
1.5.1 GPU Telecommunications Functions

A PCU controls the GPRS activity of one cell and is implemented in the GPU PBA. The GPU performs the following telecommunications functions: High Speed Data Services (HSDS) Packet radio resource allocation Autonomous Packet Resource Allocation T4 reallocation Uplink power control Uplink medium access mode Timing advance Paging management Channel coding Link adaptation Gb stack management Alignment of PMU capacity to PTU capacity. Refer to the following sections for more information about these functions.
20 / 84
1.5.1.1 High Speed Data Service

HSDS provides CS1 to CS4 for GPRS, and MCS1 to MCS9 for E-GPRS. It also provides functions to adapt radio resource allocation with E-GPRS mobile stations to avoid Ater blocking, by allocating more transmission resources on Abis and Ater to a radio time slot managing HSDS capability on a 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 an extra set of 16k nibbles for packet traffic but does not carry circuit-switched traffic. MPDCH handling MPDCH handling allows the MFS to manage the MPDCHs based on the positioning information received from the BSC. This avoids inter-operablility issues with mobile stations and wasting Ater resources. CS1/CS4 and E-GPRS protocol modulation and coding schemes Nine different modulation and coding schemes MCS1 to MCS9 are defined for the E-GPRS radio data blocks. Enhanced radio resource allocation E-GPRS traffic has priority over GPRS traffic. E-GPRS capable TRX are used for E-GPRS traffic and GPRS throughput is optimized as long as it does not conflict with E-GPRS traffic. T4 reallocation T4 reallocation solves conflicts between uplink GPRS TBFs and downlink E-GPRS TBFs. Dynamic transmission handling PDCHs are established with the maximum number of GCHs, whatever the supported traffic. GCHs are released if the number of established GCHs becomes greater than the target number of GCHs. For GPRS and E-GPRS TBF allocation, new PDCHs are established with a reduced number of GCHs during the Ater congestion state.
21 / 84
1.5.1.2 Packet Radio Resource Allocation

Packet radio resource allocation defines the number of PDCHs that are assigned to the mobile station. The number of PDCHs that can be assigned to the mobile station depends on the mobile station multislot class capability: Type 1 mobile stations 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. Class 2 mobile stations operate in duplex mode (that is, transmission and reception are simultaneous). The maximum number of PDCHs allowed are five for the uplink and downlink. 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, thereby simplifying time slot allocation and decreasing PMU CPU loads.
1.5.1.3 Autonomous Packet Resource Allocation

Autonomous Packet Resource Allocation introduces a new way of sharing radio resources between the MFS and the BSC. With this feature the MFS no longer needs to request radio time slots from the BSC. Instead, the MFS is always aware of all the available time slots. This speeds up PDCH establishment in the BSC and MFS and decreases CPU loads. The feature introduces a CS/PS resource-sharing concept using time slots defined as follows: Reserved for PS Priority for PS Priority for CS Reserved for CS Because the MFS is aware of all available time slots, the choice of the best allocation to serve the TBFs in the MFS is simplified. With this feature, the SPDCHs are ordered by the BSC to ensure consistent CS and PS allocation. The BSC ranks the PS TRXs and sends this ranking to the MFS on the BSCGP interface at cell creation and when the cell is modified during an O&M operation. The BSC defines the number of SPDCHs allocated to the MFS by computing the MAX_SPDCH_LIMIT parameter periodically. The resulting SPDCH allocation is based on the whole BSS load (CS + PS load), with the PS load being provided periodically by the MFS. The allocated SPDCHs are always those with the highest priority for PS allocations. Their positions are provided to the MFS in a new message, the Radio Resource (RR) Allocation Indication message. Consequently, the MFS no longer needs to request additional SPDCHs from the BSC.
1.5.1.4 T4 Re-allocation
T4 reallocation resolves conflicts between uplink GPRS TBFs and downlink E-GPRS TBFs when they share the same PDCH. An uplink GPRS TBF is reallocated on resources that do not support any downlink GPRS TBFs.
22 / 84
1.5.1.5 Uplink Power Control

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

Contention control is not required in the downlink direction even if the PDCH is shared by several mobile stations. In the uplink direction, contention control is required when multiple mobile stations share the same PDCH. The MFS avoids contention by authorizing particular mobile stations 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 mobile station is allocated a particular USF value by the MFS. When a mobile station receives the required USF value in a downlink block, it transmits its data on the next uplink block. PRACH When the mobile station wants to initiate a packet access procedure, it has to send a packet channel request on the PRACH. The mobile station 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 a mobile station is involved in a downlink packet transfer, it sends an acknowledgment, when required, on the uplink PACCH. The mobile station examines its downlink blocks and looks for a particular value (not the USF) which authorizes the mobile station to transmit its acknowledgment. The acknowledgment is required by the mechanism which schedules the uplink block.
1.5.1.7 Timing Advance

The correct value for the timing advance used by the mobile station when transmitting uplink blocks is derived by: Initial estimation The BTS performs measurements on the single access burst carrying the packet channel request and sends a value to the mobile station. 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 mobile station. For the downlink direction, the initial timing advance value is computed on reception of the Packet Control Acknowledgment from the mobile station. The value is then returned to the mobile station in a timing advance or power control message.
23 / 84
1.5.1.8 Paging Management

The network can coordinate 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. There are three modes: Network Operation Mode 1 Circuit-switched paging messages are sent via the SGSN and MFS. The circuit-switched paging message for the GPRS-attached mobile station is sent on the PPCH or CCCH paging channel, or on the PACCH. This means that the mobile station only needs to monitor one paging channel. It receives circuit-switched paging messages on the PACCH when the mobile station 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 mobile station is sent on the CCCH paging channel. The channel is also used for packet-switched paging messages. This means that the mobile station only needs to monitor PCH. Circuit-switched paging continues on the PCH even if the mobile station is assigned a PDCH. Network Operation Mode 3 Circuit-switched paging messages are sent via the MSC and BSC, but not the MFS. The circuit-switched paging message for the GPRS-attached mobile station is sent on the CCCH paging channel. The packet-switched paging message is sent on either the PPCH (if allocated) or on the CCCH paging channel.
1.5.1.9 Channel Coding

Different Coding Schemes (CS) can be used for the data on the Air Interface. For GPRS, the CS1 to CS4 coding schemes are used. For E-GPRS, the MSC1 to MSC9 schemes are used. For more information on coding schemes, refer to GPRS CS3/CS4 and E-GPRS Protocol in the BSS System Description.
1.5.1.10 Link Adaptation

For GPRS, link adaptation changes Coding Schemes (CS) according to radio conditions and CS1 to CS4 requirements. For E-GPRS, link adaptation changes Modulation and Coding Schemes (MCS) according to radio conditions and MCS requirements. 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 (E-GPRS), providing raw RLC data rates ranging from 8.8 kbit/s to 59.2 kbit/s. Data rates above 17.6 kbit/s require 8-PSK modulation on the Air Interface, instead of GMSK.
24 / 84
1.5.1.11 Gb Stack
Communication between the MFS and SGSN is via the Gb Interface. The Gb Stack function provides the following required supporting protocol layers: Depending on GB transport mode: Frame relay IP Network service BSS GPRS Protocol (BSSGP).
1.5.1.12 Alignment of PMU Capacity to PTU Capacity

For non-streaming PS traffic, the PPC in the GPU can become a bottleneck, reducing throughput. This bottleneck can be overcome by aligning the capacity of the PMU to that of the PTU. PMU throughput is increased by: Lowering the signaling overhead. This increases the amount of CPU available for PDU transfer Lowering the CPU cost of PDU transmission so that more PDUs are transmitted for a given signaling overhead. To lower both the signaling overhead and the CPU cost of PDU transmission, the following improvements are implemented in the GPU software: Extended UL allocation, whereby the radio resource allocation algorithm is no longer used for each UL TBE establishment Optimized Gb PDU handling Saved memory copies, which reduces the number of memory copies required per PDU.
25 / 84
1.5.2 Abis Resource Manager

The Abis Resource Manager was implemented in the MFS to manage the Abis nibbles (and their pools) required for Dynamic Abis Allocation and M-EGCH Statistical Multiplexing. For more information on these features, refer to Dynamic Abis Allocation and M-EGCH Statistical Multiplexing in the BSS System Description. There is one Abis resource manager per BTS. This resource manager is created in a GPU when the first cell (or the first BTS sector in cells shared over two BTS) of a given BTS is created. The cell-to-GPU mapping algorithm then ensures that all the other cells of the BTS are also mapped to the same GPU. As a result, cells created after the first cell are able to use the same Abis resource manager. When a cell shared over two BTS is created, two Abis resource managers are created (one for each BTS). In this case, one Abis resource manager is used to manage the Abis resources for the PS-capable TRXs of the cell. The other resource manager is used to: Establish an M-EGCH link for the MPDCHs of the cell (if MPDCHs are established by the BSC in the non-PS-capable sector of the cell) Make the bonus basic Abis nibbles available to the other cells (if any) of the BTS containing the non-PS-capable BTS sector. When the last cell of a BTS (or the last BTS sector of a shared cell) is deleted, the Abis resource manager of that BTS is also deleted. The Abis resource manager uses the following input messages to manage the Abis nibble pools:
Cell State Response or Cell State Change
The contents of the two messages are the same. These two messages contain information from the BSC indicating the position of the bonus Abis nibbles to the MFS.
Extra Abis Pool Configuration
This message indicates the extra Abis time slots available for PS traffic in a BTS.
RR Allocation Indication
This message indicates which radio time slots are available for PS traffic (i.e., which radio time slots have basic Abis nibbles which can or cannot be used for PS traffic).
Cell deletion message.
26 / 84
1.5.3 MFS O&M Functions

The O&M functions of the MFS manage the: Equipment GPU telecommunications application Alarms Performance.
1.5.3.1 Equipment Management

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

This function manages the telecommunications application of each logical GPU. 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.5.3.3 Alarm Management

Alarm Management is responsible for the processing of hardware and telecommunications alarms within the MFS. This function: Collects all fault information for telecommunications and external alarms, the telecommunications hardware and the active server Records the fault information in a table Allows the local IMT and the OMC-R to access the fault information Generates the end alarm for pending alarms Manages communication with the IMT.
27 / 84
1.5.3.4 Performance Management

Performance Management is responsible for: Collecting the performance management counters associated with each logical GPU Creating a file to contain the counter values. The MFS uses the following types of standard counters: Counters monitoring activity between the BSC and the MFS Counters monitoring activity between the MSC and the MFS.
1.5.4 SMLC Functions

The Serving Mobile Location Center (SMLC) provides the following functions: Handles LCS protocols towards the BSC, the mobile station, and the external A-GPS server Manages call-related location context per mobile station and positioning methods Triggers the position calculation process for the TA positioning method, and presents the mobile station location estimate in standard format Requests GPS Assistance Data from the external A-GPS server and provides it to the mobile station Provides mobile station-performed GPS measurements to and from the A-GPS server to provide mobile station-assisted or mobile station-based A-GPS positioning in a standard format Improves location accuracy by providing assistance data via a GPS link to the GPS-mobile station (A-GPS), navigation data from satellites and Differential GPS (DGPS), and provides corrections to measurement errors Uses O&M information present in the MFS or SMLC, provided by the OMC-R Performs error handling.
28 / 84
2 Hardware
2 Hardware
This section describes the MFS hardware.
29 / 84
2 Hardware
2.1 Cabinet
The 9135 MFS hardware consists of an indoor cabinet which is housed in a telecommunications building. The MFS cabinet exists in several versions: MFSRACK with an AS800 server MFSDS10 with: DS10/RC23 server, or. DS10/RC40 server. The following sections describe the cabinets in terms of: Layout (Section 2.1.1) Dimensions and Weight (Section 2.1.2) Environment (Section 2.1.3).
2.1.1 Layout
The cabinets (BRVPS2) contain the following components. MFSRACK: Top rack unit (BDTRU2) The top rack unit provides DC power. Refer to Power System (Section 2.2) Telecommunications Subrack (Section 2.3.1) (BSXTU) Server Subrack for MFSRACK (Section 2.3.2) (PVSERV44) Hub/Switch Subrack (Section 2.3.4) (JSHUB). MFSDS10: Top rack unit (BDTRU2) The top rack unit provides DC power. Refer to Power System (Section 2.2) Telecommunications Subrack (Section 2.3.1) (BSXTU) Server Subrack for MFSDS10 (Section 2.3.3) (JS19P)
30 / 84
2 Hardware
Both cabinets are shown in the figure below.

MFSRACK BDTRU2
Telecommunications Subrack Telecommunications Subrack
MFSDS10
BSXTU
Telecommunications Subrack
BSXTU
Telecommunications Subrack
BSXTU
BSXTU
Server Subrack
PVSERV44
Server Subrack
JS19P
Hub/ Switch Subrack
JSHUB
BRVPS2
BRVPS2
Cable entry to the cabinet can be from either the: Top If the cabinet is mounted on a solid floor, cable ducting in the ceiling carries the cables to the top of the cabinet. Bottom If the cabinet is mounted on a raised floor, cable ducting in the floor carries the cables to the bottom of the cabinet.
31 / 84
2 Hardware
2.1.2 Dimensions and Weight

The cabinet is designed for buildings with a minimum ceiling height of 2.7 meters. The table below shows the cabinets external physical dimensions. Dimension Height Width (including side panels) Depth Overall Size (mm) 2208 1000 600 (MFSRACK) 700 (MFSDS10)
The approximate weight of the fully equipped cabinet is 400 kg. The cabinet consists of a rack fitted with side panels and front and rear doors. When the doors are closed, the equipment is EMI protected. The doors and side panel are easily removed for maintenance purposes. The MFSRACK is a standard ETSI rack, 600 mm deep, that houses four subracks. The MFSDS10 rack is 700 mm deep and houses three subracks.
32 / 84
2 Hardware
2.1.3 Environment
Equipment must not be exposed to extremes of temperature or relative humidity. To meet the required environmental conditions, air conditioning equipment may be required. The following environmental conditions must be respected.
2.1.3.1 Temperature and Humidity

For altitudes between sea level and 500 meters, the temperature must be between + 5C and + 40C, within a relative humidity band of between 20 % and 80 %. The temperature gradient must be less than 0.5C per minute. Precautions must be taken to avoid electrostatics as this may result in minor shocks and/or damage to the equipment. The relative humidity must be at least 20 % at manned sites or during maintenance periods.
2.1.3.2 Atmospheric Pressure

For normal equipment operation, the atmospheric pressure must be between 65 kilopascals (kPa) and 120 kPa. Low pressure extremes must not be allowed to coincide with upper temperature limits.
Note: 2.1.3.3 Solar Radiation
An altitude of 3500 meters corresponds to a pressure of approximately 65.7 kPa.
Direct solar radiation must be avoided as this can result in damage to equipment due to overheating. Ensure that equipment is not subjected to direct sunlight.
2.1.3.4 Dust and Particles

The equipment operates normally in the presence of solid (non-conductive, non-ferromagnetic, non-corrosive) particles. The table below lists the maximum sizes and concentrations of particles. Size of Particles (micrometers) 0.5 1 3 5 Concentration (millions of particles per cubic meter) 14 0.7 0.24 0.13
2.1.3.5 Lighting
All optical signals, displays and labels are visible with an ambient light intensity of 800 lux.
33 / 84
2 Hardware
2.1.3.6 Cooling
The 9135 MFS equipment uses forced air cooling.
2.1.3.7 Safety Standards

The 9135 MFS conforms to the EN60950 (Europe) safety standards.
2.1.4 Cables
The external and inter-subrack cabling is shown in the figure below.
TRU
BLTLM To DDF
BLAAA 16 x JLHE1
BLTLM
External Alarms External Settings
BLAAA BLAAA BLAAA
J A E T I
B A T T U
16 x JAE1/JAE1C
B A T T U
J A E T I
JLHALA BLAAA
To DDF
16 x JLHE1
J A E T I JLERH 16 x JLERH
B A T T U
16 x JAE1/JAE1C
B A T T U
J A E T I
JLERH
16 x JLERH ALETHD
To IMT
ALETHD Hub
Terminal Server
Hub
Gb
ALETHD JLRJDB
J A H P S ALETHD
J A H P S
Gb
Server
Server
O&M
DDF : Digital Distribution Frame
34 / 84
2 Hardware
The table below lists the external cables. Identity ALETHD ALETHD BLAAA JLHE1 ALETHD From Hub/Switch Server JAETI JAE1 Switch To IMT OMC-R Devices DDF External Router External A-GPS Server External router Comment Ethernet Ethernet Alarms and settings 32 PCM cables per subrack Ethernet
ALETHD
Hub/Switch
Ethernet
To be updated
OS-LS-6224
1Gb Ethernet cable
The table below lists the inter-subrack cables. Identity ALETHD ALETHD BLAAA BLTLM From Hub/Switch Hub/Switch JAETI TRU To Server Terminal server JAETI JAETI Comment Ethernet Ethernet Different subracks TRU alarms and reference voltage RS-232 Ethernet Ethernet Power Alarms
JLRJDB JLERH JLERH JLHALA
AS800 JAET1 BATTU JAETI
Terminal server Hub/Switch Hub/Switch JAHPS
35 / 84
2 Hardware
2.2 Power System

The cabinet is powered by two independent -48V or -60V (nominal) DC external power sources. Each external power source must be capable of supplying the full power requirements of the cabinet in the event of the other external power source failing. The maximum power consumption for a fully equipped cabinet is 3325 W. The power distribution system is a duplicated system which minimizes system down time in the event of power faults. The figures below show the component parts of the MFSRACK and the MFSDS10.
2.2.1 MFS Rack Power Distribution

48V(A), 0V 48V(B), 0V
1 0
LOAD
ALM
A1
A2
A3
A4
LOAD
ALM
B1
B2
B3
B4
1 0
Bus Bar A
Bus Bar B
To Server Subrack 48V(A) 48V(B) 0V Power Unit
To Server Subrack 48V(A) 48V(B) 0V Power Unit
Telecommunications Subrack (Circuit Breakers A1,B1)
48V(A) 48V(B) 0V Power Unit
Telecommunications Subrack (Circuit Breakers A2,B2)
48V(A) 48V(B) 0V Power Unit
Server Subrack (Circuit Breakers A3,B3) 48V(A) 48V(B) 0V Power Unit
Hub Subrack (Circuit Breakers A4,B4)
Circuit Breaker Set Button Circuit Breaker Reset Button
LOAD Indicator LOAD Button
36 / 84
2 Hardware
2.2.2 MFSDS10 Power Distribution

48V(A), 0V 48V(B), 0V
1 LOAD 0
C ALM
A1
A2
A3
A4
LOAD
C ALM
B1
B2
B3
B4
1 0
Bus Bar A
Bus Bar B
48V(A) 48V(B) 0V
Power Unit
Telecomunications Subrack (Circuit Breakers A1,B1)
Power Unit
48V(A) 48V(B) 0V
48V(A) 48V(B) 0V
Power Unit
Telecomunications Subrack (Circuit Breakers A2,B2)
Power Unit
48V(A) 48V(B) 0V
Server Subrack
StorageWorks* A
StorageWorks* B Server A (DS10/RC23 or D10/RC40) Server B (DS10/RC23 or D10/RC40) Terminal Server
Sockets mains Filter A
Sockets mains Filter A
230 VAC
230 VAC
(*) StorageWorks are present only for MFS with DS10/RC23, not for MFS with DS10/RC40
Hub / Switch 4
Hub / Switch 2
Hub / Switch 3
Hub / Switch 1
37 / 84
2 Hardware
2.2.3 Top Rack Unit

The previous figures show the switches, reset buttons, and indicator lamps mounted on the front of the top rack unit. The top rack unit consists of two identical sections. Each section performs power isolation, distribution and protection for one of the input power supplies and external alarms: Input power isolation The input supply can be separately isolated by a manually-operated switch. Input power filtering Capacitors are used to filter the input supply. The capacitors must be charged up (loaded) while the protected output supply circuit breakers are switched off. A preload device monitors the charge level and illuminates the LOAD indicator when the charge voltage is sufficiently high. The charge-up process can be speeded up by pressing the LOAD button. Charge circuit protection The C circuit breaker opens if there is excessive current in the capacitor loading circuits. External alarm protection The ALM circuit breaker trips if there are excessive voltage or current levels in the external alarm links. Protected output supplies. Four circuit breakers (A1 to A4 or B1 to B4) protect the output supplies against excessive currents. Each circuit breaker has two outputs, one of which connects to Bus Bar A, while the other connects to Bus Bar B. In the MFSRACK, the A3/B3 outputs go directly to the server subrack. In the MFSDS10, the B4 output goes directly to the terminal server.
2.2.4 Bus Bars

A bus bar is fitted down each side of the rack. Each bus bar carries the protected output supplies from the A and B sections of the top rack unit. The Hub/Switch subrack in the MFSRACK receives protected output supplies only from Bus Bar B.
2.2.5 Telecommunications Subracks

The telecommunications subrack input supplies are protected by the A1/B1 and A2/B2 circuit breakers. The power units are located at each side of the subracks.
2.2.6 Server Subrack in MFSRACK

The AS800 server subrack input supplies are protected by the A3/B3 circuit breakers. The subrack contains its own power units.
38 / 84
2 Hardware
2.2.7 Server Subrack in MFSDS10

The DS10/RC23 servers and StorageWorks have a duplicated 230VAC power supply. The DS10/RC40 servers have a duplicated 230VAC power supply. The terminal server input supplies are protected by the B4 circuit breaker.
2.2.8 Hub/Switch Subrack in MFSRACK

The Hub/Switch subrack input supplies are protected by the A4/B4 circuit breakers. The subrack contains two power units fitted on the right-hand side of the subrack.
2.2.9 O&M System

A top rack unit alarm is generated if the C circuit breaker is open. The circuit breaker protects the capacitor charging circuits.
2.3 Subracks
This section describes the subracks for the MFSRACK and the MFSDS10 cabinets.
2.3.1 Telecommunications Subrack

This section describes the telecommunications subrack used in the MFSRACK and the MFSDS10. The figure below shows the subrack layout.
Fan Unit BDAFU3+BAFAN2
Power Unit PBAs
Telecommunications PBAs
Power Unit PBAs
The subrack contains the following components: Fan Unit Power Unit PBAs Telecommunications PBAs.
39 / 84
2 Hardware
2.3.1.1 Fan Unit

The fan unit consists of two modules: The main module (BDAFU3) The fan unit alarm board (BAFAN2), which is a sub-assembly of BDAFU3. The fan unit provides ventilation for the subrack. It draws air from below the subrack and expels it through the top. The front panel contains a maintenance switch and a fault indicator. The fan unit receives its 12V input supply from the subrack power units. It consists of a controller, a tray with 14 fans, and 10 temperature sensors. The controller: Controls the current supplied to each fan and monitors the fans speed A non-urgent fan alarm is generated if: The speed drops below the low speed threshold There is no fan current (fan missing). Monitors the temperature sensors. If a sensor detects an air temperature greater than 65C, an urgent alarm is generated. Switches off the subrack power units if the air temperature exceeds 70C.
40 / 84
2 Hardware
2.3.1.2 PBA Positions

The physical locations of the telecommunications and power unit PBAs are shown in the figure below.
SUBRACK TOP VIEW Rear
B A 3 5 B 2
B A 3 5 B 2
B A 3 5 B 2
J A E T I
B A T T U
J A E 1
J A E 1
J A E 1
J A E 1
J A E 1
J A E 1
J A E 1
B J A A R E E 1 D C 2
Midplane
J A E 1
J A E 1
J A E 1
B J A A T E T T U I
B A 3 5 B 2
B A 3 5 B 2
B A 3 5 B 2
B E 3 5 B 2
B E 3 5 B 2
B E 3 5 B 2
J B E T I
J B G P U 2
J B G P U 2
J B G P U 2
J B G P U 2
J B G P U 2
J B G P U 2
J B G P U 2
S p a r e J B G P U 2
J B G P U 2
J B G P U 2
J B G P U 2
J B G P U 2
J B E T I
B E 3 5 B 2
B E 3 5 B 2
B E 3 5 B 2
Front
Note:
The JAE1s are 120 Ohm PBAs. For 75 Ohm networks, JAE1Cs are used. The subrack contains a midplane, which means that PBAs are plugged into the front and rear of the subrack. PBAs that occupy the front and rear positions of one slot operate as a pair. For example, the GPU and JAE1/JAE1C work together. The rear PBAs provide the cabling interface. There are two types of PBAs: Telecommunications The figure above shows the positions of all the PBAs when the maximum number of JBGPU2s and their associated JAE1s are fitted. The redundant JBGPU2 and its associated BAREDC2 must occupy the positions shown. There are two firmware packages: JFGPU2 for the JBGPU2 board JFETI for the JBETI board. Power unit. There is a pool of six 200 W DC/DC converters. Each converter consists of one BE35B2 PBA and its associated BA35B2 PBA. Five converters provide the subracks internal power requirements and the sixth converter operates in redundant mode. Each converter receives both the -48V(A) and -48V(B) input supplies. In the event of one input supply failing, the other input supply is used. The internally produced voltages are 5V, 3.3V, and 12V.
41 / 84
2 Hardware
2.3.1.3 Telecommunications Subrack O&M

The telecommunications subrack equipment provides alarms, visual fault indicators and reset buttons. These are described below for the Fan Unit, JBETI, GPU, and BE35B2.
Fan Unit
1. Two alarm types are provided depending on the urgency: Non-urgent This alarm type is caused by: At least one fan not operating at sufficient speed The front panel maintenance key is set The fan unit is unplugged. Urgent. This alarm type is caused when a sensor detects a temperature greater than 65C. The front panel of the fan unit provides: A maintenance switch When the maintenance switch is in the on position, the fan unit can be disconnected and withdrawn without shutting down the subrack power units. LED. For a description of the LED states, refer to the following table. State Green Yellow Red Description Maintenance switch on or no fault Non-urgent alarm. Urgent alarm.
42 / 84
2 Hardware
JBETI
2. The JBETI PBA reports alarms to the server.It collects alarms from the: Top rack unit Telecommunications subrack power unit PBAs Fan unit. The front panel of the JBETI PBA provides: Two reset buttons with the following functions: S1 - hard reset All hardware is reset. S2 - soft reset Only the on-board PowerPC is reset. Two LEDs. The LEDs are controlled by the firmware during booting and by the software when the software is downloaded. For a description of the LED states during software booting, refer to the following table. Operation Reset Booting Initialization Self Test Self Test/Initialization Failed Ready to Download Downloading End of Download Initialization Complete L1 State Red Off Yellow Red Off Off Off Off Off L2 State Yellow Red Red Off Red (Blinking) Yellow (Blinking) Yellow Red Off Time 5s 10s 10s 5s -
43 / 84
2 Hardware
For a description of the LED states when the software is loaded, refer to the following table. JBETI Active Reserve L1 State Off Off L2 State Green Green (Blinking)
Note: GPU
Only one of the two JBETIs is active. If the active JBETI fails, the reserve JBETI becomes active. 3. The GPU PBA front panel provides: For a description of the LED states during software booting, refer to the following table. Operation Reset Booting Initialization Self Test Self Test/Initialization Failed Ready to Download Downloading End of Download Initialization Complete L1 State Red Off Yellow Red Off L2 State Yellow Red Red Off Red (Blinking) Time 5s 10s 10s 5s -
Off Off Off Off
Yellow (Blinking) Yellow Red Off
44 / 84
2 Hardware
For a description of the LED states after the software is downloaded, refer to the following table. GPU Active PCM Link State No PCM links installed At least one PCM link not installed L1 State Off Current color unchanged Green Red Off L2 State Green Green
All equipped PCM links available At least one equipped PCM link failed Spare No PCM links installed
Green Green Green (Blinking)
Note: BE35B2
Both GPU LEDs are off when in test mode. If the test fails or the GPU is locked, the LEDs are controlled by the firmware. 4. The BE35B2 DC/DC converters generate the following alarms: -48V Alarm. This alarm is triggered when the -48V(A) or -48V(B) input supply is in one of the following states: Missing Fuse needs replacing The fuse protects against overload of the -48V supply by internal short circuits. Two internally mounted fuses are provided, one for -48V (A) and one for -48V (B). Voltage too high (over-voltage). Converter Alarm. This is caused when any of the output voltages exceed the alarm threshold. If the voltage reaches the over-voltage threshold, the converter automatically shuts down. The table below shows the Converter Alarm thresholds. Output Voltage 3.3V 5V 12V Alarm Threshold 3.60V to 3.85V 5.25V to 5.50V 12.60V to 13.2V Shutdown Threshold 3.85V to 4.0V 5.5V to 6.0V 13.2V to 15.0V
45 / 84
2 Hardware
The front panel of the BE35B2 PBA provides: On/off switch LED. Refer to the table below for a description of the LED states. LED L1 State Green Off Description Normal operation Power off or fault
2.3.1.4 Clock Synchronization

The GPU architecture is based on synchronous interfaces, which means that all elements connected to a GPU need to operate synchronously. There are three modes of operation: Autonomous Mode This is the default mode. The GPU is synchronized on the source with: The links from the transcoder The Gb interfaces to the SGSN, directly or via a frame relay network If the GB is over IP, this Gb interface can not be used for synchronization. The AterMux links coming from 9130 BSC Evolution The recommended priority order for the synchronization source is TC with the highest priority, followed by SGSN and A1930 BSC Evolution with the lowest priority. The selection of the synchronization sources can be modified using the local maintenance terminal. Central Clock Mode Two GPUs per subrack are assigned as masters. These masters deliver a reference system clock signal on the back panels. All GPUs of the subrack are synchronized on this system clock signal. The master GPUs have one pool of synchronization sources. By default, this contains the transcoder inputs. This can be modified using the IMT. Fixed Synchronization Sources Mode When all GPRS links are dedicated, it is possible to synchronize one GPU to the output of another GPU. This GPU cascading reduces the synchronization sources required from two-per-GPU to two-per-MFS rack. In this mode, the synchronization source algorithm is disabled and each GPU synchronizes to port 14 or port 15 with equal priority.
Note:
This mode of operation is not used for new installations as it has been replaced by the central clock mode which is more secure.
46 / 84
2 Hardware
The connections are made at the DDF (i.e. port 8 of GPU 1 is connected to port 14 of GPU 3). GPU cascading for one telecom subrack is shown in the following figure.
From sync source
14 15 14 15
GPU 1
8 9 10 11 12 13
GPU 2
8 9 10 11 12 13
14
15
14
15
14
15
GPU 3
8 9 10 11 12 13
GPU 4
8 9 10 11 12 13
GPU 5
8 9 10 11 12 13
14
15
14
15
14
15
14
15
14
15
14
15
GPU 6
8 9 10 11 12 13
GPU 7
8 9 10 11 12 13
GPU 8
8 9 10 11 12 13
GPU 9
8 9 10 11 12 13
GPU 10
8 9 10 11 12 13
GPU 11
8 9 10 11 12 13
GPU cascading for two telecom subracks is shown in the following figure.
From sync source

14 15 14 15
GPU 1
8 9 10 11 12 13
GPU 12
8 9 10 11 12 13
14
15
14
15
GPU 2
8 9 10 11 12 13
GPU 13
8 9 10 11 12 13
14
15
14
15
14
15
14
15
14
15
14
15
GPU 3
8 9 10 11 12 13
GPU 4
8 9 10 11 12 13
GPU 5
8 9 10 11 12 13
GPU 14
8 9 10 11 12 13
GPU 15
8 9 10 11 12 13
GPU 16
8 9 10 11 12 13
14
15
14
15
14
15
14
15
14
15
14
15
14
15
14
15
14
15
14
15
14
15
14
15
GPU 6
8 9 10 11 12 13
GPU 7
8 9 10 11 12 13
GPU 8
8 9 10 11 12 13
GPU 9
8 9 10 11 12 13
GPU 10
8 9 10 11 12 13
GPU 11
8 9 10 11 12 13
GPU 17
8 9 10 11 12 13
GPU 18
8 9 10 11 12 13
GPU 19
8 9 10 11 12 13
GPU 20
8 9 10 11 12 13
GPU 21
8 9 10 11 12 13
GPU 22
8 9 10 11 12 13
Second Telecom subrack
In case of using GB over IP for one BSS, the GPUs attached to this BSS can not use the Gb link as synchronizing. There are the following alternatives for the MFS synchronization: autonomous mode, using: TC links if there are mixed AterMux 9130 BSC Evolution links
47 / 84
2 Hardware
centralized mode, when the BSS GPUs receive the synchronization from the GPU corresponding to other BSSs. In case the MFS single secured Gb feature is used, the GPU synchronisation in autonomous mode can be used through the BSC links or through the TC links if the Gb and the synchronisation from the TC do not share the same Atermux.
48 / 84
2 Hardware
2.3.2 Server Subrack for MFSRACK

The physical locations of the server modules are shown in the figure below.
300W Power Unit 90W Power Unit 90PS
LEDs SDBOX
300PS
Local CD Disks ROMs
Local Disks
300PS
Control Panel
Server B
Server A Shared Disks 9GBD FTRAY Shared Disks 9GBD FTRAY
CPUB + PCIBF
CPUB + PCIBF
The subrack contains two AS800 systems and two disk systems connected in a redundant configuration. Both servers are interconnected by the Ultra SCSI busses. The online server is responsible for the overall management of the 9135 MFS. The figure below shows the server device busses.
Ultra SCSI
Server A
Main Shared Disks
Server B
Mirrored Shared Disks OS Disk OS Disk
Optional Disk or Tape
Optional Disk or Tape
CD ROM
CD ROM
SE SCSI Local Bus
SE SCSI Local Bus
Each server has a local device bus for the OS disk, the CD-ROM and an optional disk or tape unit. Two busses are provided for the shared disks. The shared disk module located next to Server A contains the main shared disks. The mirrored disks are located in the shared disk module located next to Server B.
49 / 84
2 Hardware
2.3.2.1 Modules
The following modules are present: AS800 Server The AS800 server module consists of: CPUB (TM) (TM) (TM) This is a UNIX processor which runs the Digital UNIX OS and the telecommunications application software. For more information, refer to Software (Section 3) . 300PS This is an internal 300 W power unit which provides +3.3V, +5V, +12V, -5V and -12V. PCIBF. This is an internal fan unit. Local Disk Module The local disk module contains a LED panel and two slots for the OS disk and an optional disk or tape unit. The local disk module receives its DC supplies from the 300 W server module power unit. Shared Disk Module The shared disk module (SDBOX) contains a LED panel and three slots for the two shared disks (9GBD) and a 90 W power unit (90PS). The shared disk module, the fan unit below and the CD-ROM above, receive their DC supplies from the 90 W power unit. CD-ROM Module CD-ROM module. This is a two-slot module which contains two CD-ROM drives. Each CD-ROM drive is dedicated to one server. Main Fan Tray Each fan unit (FTRAY) contains two fans and provides ventilation for the modules above it. Air is drawn in from below the subrack and expelled from the top of the subrack.
50 / 84
2 Hardware
2.3.2.2 AS800 Server Subrack O&M

The server subrack equipment provides alarms, visual fault indicators and reset buttons.
Server
1. The server gathers and reports all 9135 MFS alarms to the OMC-R and the IMT.The alarms are the standard types: Quality of Service Communications Processing error Equipment Environment. The front control panel of the server module has three push-buttons: Right button Power on/off Middle button Enter console mode and stop server Left button. Reset server The server front panel has two LEDs which are mounted horizontally. These LEDs are described in the table below.
Left LED (Yellow) Off On
Right LED (Green) Off Off
Description Powered off at control panel or no DC input power. Powered on at control panel, but switched off by either: Console command Software Fan failure Over-temperature Power supply failure.
Off On
On On
Powered on at control panel and normal operation. Halt button pressed on front panel or halt command received from console.
51 / 84
2 Hardware
Local Disk LEDs
2. The local disk module has four green LEDs which are mounted vertically. The LEDs are described in the table below, where the upper LED is identified as 1 and the lower LED as 4 . LED 1 2 3 4 Description Disk 0 (left disk) active Disk 1 (right disk) active +5V present +12V present
Shared Disk LEDs
3. The shared disk has eight LEDs which are mounted vertically. The LEDs are described in the table below, where the upper LED is identified as 1 and the lower LED as 8 . LED 1 (Green) 2 (Green) 3 (Green) 4 (Green) 5 (Green) 6 (Yellow) 7 (Yellow) 8 (Yellow) Description Disk 0 (left disk) active. Disk 1 (right disk) active. User 0 - user-defined LED controlled by software. User 1 - user-defined LED controlled by software. +5V and +12V present. Fan Fail 0 - rear fan in fan tray failed. Fan Fail 1 - front fan in fan tray failed. Temperature above +50;C.
CD-ROM Drive 90 W Power Unit
4. The CD-ROM drive contains an ejector button and a green LED which illuminates when the unit is active. 5. The 90 W power unit contains a green LED which illuminates when there are no power faults.
52 / 84
2 Hardware
2.3.3 Server Subrack for MFSDS10

This section describes the DS10 server subrack. There are two types of MFS equipped with DS10: 9135 MFS with DS10/RC23 (one disk DS10 stations) 9135 MFS with DS10/RC40 (two disks DS10 stations) The subrack is composed of two 19" mechanics, one vertical and one horizontal, as shown in the figure below. For MFS with DS10/RC23, one frame contains two DS10 processor boxes, two StorageWorks boxes and a terminal server (IOLAN). The second one has up to four hubs/switches.
3.5U
StorageWorks A PVUSM088 StorageWorks B PVUSM088 DS10A PSERV59 DS10B PSERV59 Terminal Server TSERV
19"
3.5U
3U
3U
H U B / S W I T C H
1
H U B / S W I T C H
2
H U B / S W I T C H
3
H U B / S W I T C H
4
1U
19"
53 / 84
2 Hardware
For MFS with DS10/RC40, one frame contains two DS10 processor boxes and a terminal server (IOLAN). The second one has up to four switches.
3U
Server A (DS10/RC40) Server B (DS10/RC40)
3U
S W I T C H 1
S W I T C H
2
S W I T C H
3
S W I T C H
4
1U
Terminal Server TSERV

19" 19"
54 / 84
2 Hardware
2.3.3.1 Modules
The server subrack contains the following modules: DS10/RC23 Server Module (TM) (TM) The DS10/RC23 server module runs the Digital UNIX 4.0F OS and the telecommunications application software. For more information, refer to Software (Section 3) . DS10/RC40 Server Module (TM) (TM) The DS10/RC40 server module runs the Digital UNIX 5.1A OS and the telecommunications application software. For more information, refer to Software (Section 3) . StorageWorks Module
Note:
The StorageWorks module is present only in DS10/RC23, not in DS10/RC40. The StorageWorks module (PVUSM088) is shown in the figure below. It consists of: PVDD42, which is the shared disk PVDAT01, which is a DAT tape drive PSU, which provides an 180 W power supply.
Position of Shared Disk The shared disk must always be in the right slot of each of the StorageWorks modules.
Hub/Switch Module Depending on the configuration, two or four Ethernet hubs (HUB500) or switches (SuperStack(TM) 10/100, Alcatel-Lucent OmniStack LS 6224) are equipped. For more information, refer to Hub/Switch Subrack (Section 2.3.4) . Terminal Server Module The terminal server module (TSERV) is described in Hub/Switch Subrack (Section 2.3.4) .
55 / 84
2 Hardware
2.3.3.2 DS10 Server Subrack O&M

The server subrack equipment provides alarms, visual fault indicators and reset buttons. These are described for: DS10 server (both DS10/RC23 and DS10/RC40) front panel The front panel is located in the lower right corner of the server and contains from left to right: HALT button, to put the DS10 in halt mode Five LEDs, described in the table below. The left LED is identified as 1 , the right LED as 5 . LED 1 (Amber) Description Environment: On indicates temperature or fan LED is on. Flashes when operating system generates an alert. 2 (Amber) Temperature: On indicates that the internal temperature exceeds operating conditions. The system shuts down after 30 seconds. 3 (Amber) Fan: On indicates that at least one of the three fans in the system has failed. The system shuts down after 30 seconds. 4 (Green) Disk activity: Flashes when internal system disks are accessed. 5 (Green) Power On when power is present in the system.
Power button, to start/stop the system.
56 / 84
2 Hardware
DS10 server (both DS10/RC23 and DS10/RC40) LEDs Three Ethernet ports are required: Two for the connection to the Ethernet hubs/switches There are two sets of two Ethernet LEDs, located in the lower right corner on the back of the system. These LEDs are described in the table below. LED Upper LED (Green) Lower LED (Green or amber) Description Link: On indicates Ethernet connection. Speed: Green for Ethernet speed of 100 Mbit/s Amber for Ethernet speed of 10 Mbit/s. Activity: Flashes with Ethernet activity.
One for the OMC-R connection. There are two LEDs on the connector of the DE504 quad Ethernet board located at the back of the DS10. These LEDs are described in the table below. LED Left LED Description Speed: 100 Mbit/s Center LED Activity: Flashes with Ethernet activity. Right LED Link: On indicates Ethernet connection.
57 / 84
2 Hardware
StorageWorks Power Supply LEDs
Note:
StorageWorks is only present in DS10/RC23, not in DS10/RC40. Each power supply unit has two LEDs that display the status of the power supply and the blower. These LEDs are described in the table below. Upper LED (Green) On Off Lower LED (Green) On On
Description Normal operation Description: Power supply is OK One or more blowers failed.
Off
Off
One of the following conditions exists: There is no AC power Power supply failure.
58 / 84
2 Hardware
StorageWorks Shared Disk LEDs Each shared disk unit has two LEDs. The upper one is the device activity LED, and the lower one the fault indication LED. These LEDs are described in the table below. Upper LED (Green) On Off Flashing On Lower LED (Amber) Off Off Off On
Description Normal operation Normal operation Normal operation The shared disk is not responding to control signals. One of the following conditions exists: The disk is active and spinning down due to a fault The controller has issued the locate command. This is not a fault condition.
On
Flashing
Off
Flashing
One of the following conditions exists: Due to a fault condition, the controller is spinning down the disk The controller has issued the locate command. This is not a fault condition.
Off
On
The disk is inactive and spun down.
Data Corruption Do not remove the shared disk when the upper LED is on or flashing. This can cause corruption or loss of data.
59 / 84
2 Hardware
2.3.4 Hub/Switch Subrack

This section describes the hub/switch subrack used in the MFSRACK. The physical locations of the Ethernet modules and power unit PBAs (for AS800) are shown in the figure below.
Air Intake
Ethernet Hub B2 HUB500/Switch Ethernet Hub A2 HUB500/Switch Ethernet Hub B1 HUB500/Switch Ethernet Hub A1 HUB500/Switch Terminal Server TSERV
E m p t y
J A H P S + B E 3 5 B 2
J A H P S + B E 3 5 B 2
For AS800, the subrack contains power unit PBAs located on the right-hand side, and Ethernet modules on the left-hand side. Above the modules is an empty space which acts as the air intake for the server subrack. For AS800, the BE35B2 PBAs are at the front of the subrack and the JAHPS PBAs are at the rear.
2.3.4.1 Modules/PBAs
The hub subrack contains the: Ethernet Hubs (TM) (TM) Each Ethernet hub is a 3Com SuperStack II Dual Speed Hub 500 module. The modules have 24 ports which operate at 100 Mbit/s. If the 9135 MFS is a Standard configuration (up to 11 GPUs and a redundant GPU), only the A1 and B1 hub modules are fitted. When extending the Standard configuration, two additional hub modules must be fitted. Additional cabling is required to link Hub A1 to A2 and Hub B1 to B2. Ethernet Switches
Note:
Ethernet switches are not allowed for MFS with AS800 configurations. Each Ethernet switch is a 3Com(TM) SuperStack(TM) 3 Baseline 10/100 switch module or Alcatel-Lucent OmniStack LS 6224 switch. The modules have 24 ports which operate at 100 Mbit/s. If the 9135 MFS is a Standard configuration (up to 11 GPUs and a redundant GPU), only the A1 and B1 switch modules are fitted. When extending the Standard configuration, two additional switch modules must be fitted. Additional cabling is required to link Switch A1 to A2 and Switch B1 to B2. Terminal server The terminal server is a Chase(TM) IOLAN+(TM) module which has eight ports. Each port provides Ethernet to RS-232 conversion, and vice versa. The RS-232 connections operate at up to 115.2 Kbit/s. The terminal server uses -48V which is supplied by a cable connected to the JAHPS PBA front panel.
60 / 84
2 Hardware
Power Unit PBAs 9for AS800)
Note:
Power unit PBAs are not present for MFS with DS10 configurations. There are two 200 W DC/DC converters. Each converter consists of one BE35B2 PBA and its associated JAHPS PBA. Each converter receives both the -48V(A) and -48V(B) input supplies. In the event of one input supply failing, the other input supply is used. Both converter outputs are coupled together to supply the Ethernet hubs, via the JAHPS PBAs connectors. In the event of one converter failing, the other converter provides sufficient power for the hubs. The internally produced voltages (used by the Ethernet hubs) are: 5V 3.3V 12V. The -48V(A) and -48V(B) input supplies also provide power for the terminal server, via JAHPS PBAs connectors.
2.3.4.2 Hub/switch Subrack O&M

The hub/switch subrack equipment provides alarms and visual fault indicators for the following components: Ethernet hub/switch The Ethernet hub/switch front panel LEDs are described in the table below. LED Power/Self Test Description A two-color LED shows the power-on/self test states: Green - powered on and normal operation Green flashing - self test mode Yellow - self test failed Yellow flashing - fault on second (cascaded) hub/switch. Mgnt/Attn Not used.
61 / 84
2 Hardware
LED Status n
Description Two-color LEDs are provided for each of the 24 connections, where the connection speeds are represented by Green (100 Mbit/s) and Yellow (10 Mbit/s). The LED states are: On - link available Flashing - link disabled or partitioned Off - no link.
Segment
Two-color LEDs are provided for the 10 Mbit/s and 100 Mbit/s indicators. The LED states are: Green - traffic Yellow - collision Off - no traffic.
62 / 84
2 Hardware
Terminal server The terminal server front panel LEDs are described in the table below. LED POWER AUI 10BASE2 Description Module is switched on. Not used. Not used.
10BASE-T The LED states are: Green - no faults Yellow - fault. TXn RXn On or flashing when transmitting traffic on link n. On or flashing when receiving traffic on link n.
BE35B2. For the BE35B2 alarm, switches and indicator descriptions, refer to Telecommunications Subrack (Section 2.3.1) .
2.4 Rack Configurations

This section describes the MFS rack configurations. There are two possible rack configurations for each MFS version: Standard configuration depending on subrack number: One telecom subrack with a minimum of two GPU boards (1 active + 1 redundant) and a maximum of twelve GPU boards (11 active + 1 redundant) The second telecom subrack is internally pre-cabled but not equipped. This means that the cables are physically present but not plugged in when the board is not equipped. Standard pre-equipped configuration: Both telecom subracks are equipped and pre-cabled. The maximum capacity is 32 GPU boards (30 active + 2 redundant).
63 / 84
2 Hardware
2.4.1 Rack Configurations with AS800 Server

The figures below show the possible configurations for MFSs equipped with AS800 servers: Standard configuration Standard pre-equipped configuration.
2.4.1.1 Standard Configuration with AS800 Servers

TRU
Fan unit
GPU+baredc2 BE35B2+ba35b2 BE35B2+ba35b2 BE35B2+ba35b2 BE35B2+ba35b2 BE35B2+ba35b2
BE35B2+ba35b2
JBETI+jaeti
002 009 016
023
029
035 041 047 053 059 065 071 077 083 089 095 101 107 113 119 125
JBETI+jaeti
137
battu
GPU+jae1
battu
131
143 150 157
9 10 11 12 13 14 15 16 17 18 19 20 21
22
23
24 25 26
SBABPSPU
SBABPMVP
SBABPSPU
002 009 016
023
029
035 041 047 053 059 065 071 077 083 089 095 101 107 113 119 125
131
137
143 150 157
9 10 11 12 13 14 15 16 17 18 19 20 21
22
23
24 25 26
SBABPSPU
SBABPMVP
SBABPSPU
SERVERS
AS 800
empty space
BE35B2+jahps
SUPERSTACK II HUB 500 SUPERSTACK II HUB 500 IOLAN + 8 PORTS
SBABPSPU
64 / 84
BE35B2+jahps
2 Hardware
2.4.1.2 Standard Pre-equipped Configuration with AS800 Servers

TRU
Fan unit
GPU+baredc2 BE35B2+ba35b2 BE35B2+ba35b2 BE35B2+ba35b2 BE35B2+ba35b2 BE35B2+ba35b2 BE35B2+ba35b2 BE35B2+ba35b2 BE35B2+ba35b2
BE35B2+ba35b2
JBETI+jaeti
002 009 016
023
029
035 041 047 053 059 065 071 077 083 089 095 101 107 113 119 125
JBETI+jaeti
137
battu
GPU+jae1
GPU+jae1
GPU+jae1
GPU+jae1
GPU+jae1
GPU+jae1
GPU+jae1
GPU+jae1
GPU+jae1
GPU+jae1
GPU+jae1
battu
131
143 150 157
9 10 11 12 13 14 15 16 17 18 19 20 21
22
23
24 25 26
SBABPSPU
SBABPMVP Fan unit
SBABPSPU
BE35B2+ba35b2
BE35B2+ba35b2
BE35B2+ba35b2
GPU+baredc2
JBETI+jaeti
002 009 016
023
029
035 041 047 053 059 065 071 077 083 089 095 101 107 113 119 125
JBETI+jaeti
137
battu
battu
131
143 150 157
9 10 11 12 13 14 15 16 17 18 19 20 21
22
23
24 25 26
SBABPSPU
SBABPMVP
SBABPSPU
SERVERS
AS 800
empty space SUPERSTACK II HUB 500 SUPERSTACK II HUB 500 SUPERSTACK II HUB 500 SUPERSTACK II HUB 500 IOLAN + 8 PORTS
BE35B2+jahps
SBABPSPU
BE35B2+jahps
65 / 84
2 Hardware
2.4.2 Rack Configurations with DS10 Server (DS10/RC23 and DS10/RC40)

The figures below show the possible configurations for MFSs equipped with DS10 servers: Standard configuration Standard pre-equipped configuration.
2.4.2.1 Standard Configuration with DS10 Servers

TRU
Fan unit
GPU+baredc2 BE35B2+ba35b2 BE35B2+ba35b2 BE35B2+ba35b2 BE35B2+ba35b2 BE35B2+ba35b2 BE35B2+ba35b2 JBETI+jaeti JBETI+jaeti
137
battu
002 009 016
023
029
035 041 047 053 059 065 071 077 083 089 095 101 107 113 119 125
GPU+jae1
battu
131
143 150 157
9 10 11 12 13 14 15 16 17 18 19 20 21
22
23
24 25 26
SBABPSPU
SBABPMVP
SBABPSPU
002 009 016
023
029
035 041 047 053 059 065 071 077 083 089 095 101 107 113 119 125
131
137
143 150 157
9 10 11 12 13 14 15 16 17 18 19 20 21
22
23
24 25 26
SBABPSPU
SBABPMVP
SBABPSPU
StorageWorks*
HUB / SWITCH
StorageWorks* DS10 server DS10 server

IOLAN + 8 PORTS
(*) StorageWorks is present only for MFS with DS10/RC23, not for MFS with DS10/RC40
66 / 84
HUB / SWITCH
2 Hardware
2.4.2.2 Standard Pre-equipped Configuration with DS10 Servers

TRU
Fan unit
BE35B2+ba35b2 BE35B2+ba35b2 BE35B2+ba35b2 BE35B2+ba35b2 BE35B2+ba35b2 BE35B2+ba35b2
BE35B2+ba35b2
BE35B2+ba35b2
BE35B2+ba35b2
GPU+baredc2 GPU+jae1
JBETI+jaeti
002 009 016
023
029
035 041 047 053 059 065 071 077 083 089 095 101 107 113 119 125
JBETI+jaeti
137
battu
GPU+jae1
GPU+jae1
GPU+jae1
GPU+jae1
GPU+jae1
GPU+jae1
GPU+jae1
GPU+jae1
GPU+jae1
GPU+jae1
battu
131
143 150 157
9 10 11 12 13 14 15 16 17 18 19 20 21
22
23
24 25 26
SBABPSPU
SBABPMVP Fan unit
SBABPSPU
BE35B2+ba35b2
BE35B2+ba35b2
BE35B2+ba35b2
GPU+baredc2
JBETI+jaeti
002 009 016
023
029
035 041 047 053 059 065 071 077 083 089 095 101 107 113 119 125
JBETI+jaeti
137
battu
battu
131
143 150 157
9 10 11 12 13 14 15 16 17 18 19 20 21
22
23
24 25 26
SBABPSPU
SBABPMVP
SBABPSPU
StorageWorks*
HUB / SWITCH HUB / SWITCH HUB / SWITCH
StorageWorks* DS10 server DS10 server

IOLAN + 8 PORTS
(*) StorageWorks is present only for MFS with DS10/RC23, not for MFS with DS10/RC40
HUB / SWITCH
67 / 84
2 Hardware
68 / 84
3 Software
3 Software
This section describes the MFS software.
69 / 84
3 Software
3.1 Overview
The software manages MFS telecommunications and O&M. It runs in the servers and on the GPU boards. The figure below shows the main software components.
Active Server
MFS Application
GPU
Telecom Application
NECTAR General Software UNIX OS

OS Operating System
PSOS
Hardware
Hardware
PSOS Provable Secure Operating System
The active server contains the following software components: UNIX(TM) operating system General software This includes tools, utilities and WAN support. New Control Architecture (NECTAR) This is a middleware platform for IT hardware that enables the hardware to support telecommunications applications. MFS application. This application supervises the MFS and downloads the telecommunications application to the GPU where the telecom functions are performed. Each GPU contains the following software components: Provable Secure Operating System (PSOS) Telecommunications application SMLC software.
70 / 84
3 Software
3.2 O&M Software Architecture

The O&M software architecture is shown in the figure below.
Active Server
O&M Application
Standby Server
Equipment Manager
Telecom Manager
GPU
GPRS NE Platform Telecom Application
GPRS NE Platform
NECTAR Platform NECTAR Drivers
NECTAR Platform
GPRS NE Platform GPU Drivers
UNIX
UNIX
NECTAR Drivers
PSOS
When a server operates in the standby mode, it does not run the O&M application. The active server contains the following components: Digita UNIX the Ethernet links
(TM) (TM)
operating system and NECTAR drivers that manage
NECTAR platform which provides communications services, data management, server supervision and process initialization GPRS network element platform Functions: Controls the communications with the GPUs. This function is active on both servers Supervises the telecommunications equipment (GPUs, JBETI and PCM links) and collects all alarms. These functions are not active on the standby server. O&M application which manages the telecom objects (Ater Mux Interface, Cell, Gb Interface). These functions are not active on the standby server.
71 / 84
3 Software
3.3 Communication Channels

Communication between the GPUs and the server takes place as sessions over five types of channel: Telecom channels, used for requests, replies and state change notifications when configuring. There are the following channels: Network services (Gb Interface) Bearer channels (Ater Mux Interface) BSS and cells (cell management). GPU network channels, used for network configuration requests and replies and for network notifications GPU physical channels, used for GPU hardware component configuration requests and replies and for hardware notifications Alarm channels, used for collecting all hardware, network and GPRS alarms Performance manager channels, used for GPU PM configuration requests and reports from the GPUs. Each channel is a Communications Service session established between a PSOS task (in the GPU) and a real-time MFS process, as shown in the figure below.
Server
Q3
Common Management Protocol Syntax (CMPS) Interface
CFG MIB Admin Admin Admin Admin Admin
Realtime CFG MIB
Realtime
Realtime
Realtime
Realtime
GOM
GEM
GHW
GAM
GPM
GPU
Telecom SCA BAM PM
Agent
MFS Process
NECTAR Process
Communications Service Session
72 / 84
3 Software
Each real-time process has three main parts: The administrative layer manages configuration data received over the Q3 Interface or from the IMT The real-time layer updates object states when a notification is received from the GPU Agents to support the process (see Agents (Section 3.4) ). 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. The resource data table is shared by both servers.
73 / 84
3 Software
3.4 Agents
Agents provide support for the real-time MFS processes and the PSOS tasks. Refer to the following table for a description of each agent. Agent GPRS Operations and Maintenance (GOM) Description GOM manages telecom resource configuration and supervision. It works with the telecom agent on each GPU and is responsible for: BSS static and online configuration and activation. This includes bearer channel, Gb Interface, Ater Mux Interface and cell management domains. Validity checks are performed and persistent data is updated and configured on the logical GPUs. Supervision of the domains for operational states and status. Changes are notified to the administrative part of the process. Synchronization of the logical GPU resource states after a server changeover. Configuration of a logical GPU when requested by the GPU (after a start, reset or changeover). Notification to GEM of logical GPU creation and deletion and PCM port creation. Global Alarm Manager (GAM) GAM manages the MFS alarms. It processes all hardware and telecom alarms and is responsible for: Collecting all fault information relating to GPUs, the active server and telecom and external alarms. Recording alarms in a table. Allowing the IMT and the Q3 agent to access the alarms. Generating ending alarms when a fault is cleared (for example, when a GPU is replaced). Managing a communication session with the IMT.
74 / 84
3 Software
Agent GPRS Equipment Manager (GEM)
Description GEM manages the GPU hardware and low-level software. It handles all requests in the first steps of GPU initialization and is responsible for: GPU software booting. Session layer configuration. GPU framer hardware configuration (including data for clock synchronization) for Gb Interface messages. GPU switch configuration for Circuit Switched connections. Logical GPU switch over and recovery. The administrative part of GEM also handles requests concerning: GPU, JBETI, cross connection and PCM objects arriving via the Common Management Protocol Syntax (CMPS) interface. Static objects created during commissioning.
GPRS Performance Manager (GPM)
GPM manages the PM domain. It works with the PM agent and is responsible for: Configuring the scanners on the logical GPUs. Collecting the PM counter values. Generating a file to hold the values. Processing CPMS requests.
Q3
Q3 manages the Q3 interface to the OMC-R. It is responsible for processing OMC-R requests, detecting faults and supervising the O&M states and status. BAM manages the GPU hardware and is responsible for: Physical configuration. This includes framer and switch configuration and the change over to the spare GPU. Supervision of the physical resources (for example, PCM interfaces and synchronization). Starting telecom tasks. Reporting hardware and telecom alarms to GAM. Providing log, trace and software error services for the logical GPUs.
Board and Alarm Manager (BAM)
Telecom
Telecom manages telecom functions. It is also responsible for the following O&M functions: BSS logical configuration and activation and the supervision of bearer, Ater Mux Interface and cell management domains. Network service configuration and the supervision of the Gb Interface domain.
75 / 84
3 Software
Agent Performance Management (PM) Session Configuration Agent (SCA)
Description PM manages the scanner configuration and the collection of PM counter values. SCA manages network configuration and supervision.
76 / 84
4 Managed Objects and RITs

This section describes the MFS Managed Objects and Replaceable items (RITs).
77 / 84
4.1 MFS Managed Objects

This section provides the following information about MFS Managed Objects: Class, naming attribute and description Hierarchy Allowed States Supported Operations
4.1.1 MFS Managed Object Class, Naming Attribute and Description

The Managed Object classes for the MFS are listed in the following table, with their corresponding naming attributes. The naming attribute is used to construct the Relative Distinguished Name (RDN) 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 also provides a description of each Managed Object. Managed Object Class and Naming Attribute aGprs2MbTTP
tTPId
Description 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. 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). 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. Represents a BSS network element. Only the BSS with GPRS capability are seen at the OMC/MFS interface and can be configured by the operator. Represents the O&M functionality related to a specific cell within a BTS equipment. Represents the function of managing the establishment and the release of the cross-connections of 2Mb-TTPs ports.
aGprsAdjacent CellReselection
adjacentCellId
aGprsBearerChannel
aGprsBearerChannelId
aGprsBssFunction
bssFunctionId
aGprsBts
btsId
aGprsFabric
fabricId
78 / 84
Managed Object Class and Naming Attribute aGprsGicGroup

aGprsGicGroupId
Description A Managed Object from 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). 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. 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, etc.). This is necessary because managedElement is a standard Managed Object class and cannot be overloaded. This Managed Object class defines the characteristics (attributes) of the cell that are not required when there is no master channel. 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 (to the SGSN), and routes the incoming SNS messages to the required BVCs. The NSE contains a set of NS-VCs and a set of BVCs. The NSE is characterized by its NSEI, also known by the SGSN. 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. This Managed Object class defines the configuration parameters of a group of consecutive channels. This Managed Object class supports the cell power control parameter related to GPRS functionality (one object instance per cell). This class represents the frame relay implementation of permanent virtual connections. This Managed Object class represents the O&M functionality for a specific BTS equipment. Its purpose is containment (BTS sector or cell instances).
aGprsLapdLink
lapdLinkId
aGprsManaged ElementExtension
aGprsManagedElementExtensionId
aGprsMasterChannelData
aGprsMasterChannelDataId
aGprsNse
aGprsNseId
aGprsNsvc
aGprsNsvcId
aGprsPdchGroup
aGprsPdchGroupId
aGprsPowerControl
powerControlId
aGprsPvc
aGprsDIcId
btsSiteManager
btsSiteManagerId
79 / 84
Managed Object Class and Naming Attribute circuitPack

equipmentId
Description This Managed Object class is derived from M.3100 circuitPack class. It represents boards that are present in Telecom subracks; these are GPU boards. The JBETI boards are not instantiated. This object is created when the GPU board is first plugged in. An objectCreation notification is the emitted. The board is deleted when it is unplugged. An objectDeletion notification is then emitted. 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). 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. 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. Represents an Managed Object class of support objects that provide the criteria for generation of current alarm summary reports. This Managed Object class represents a repository that may be used for alarm logging. 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. 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. 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, etc. An endpoint defined by its IP address and UDP port. An IP endpoint can be a data endpoint and/or a signalling endpoint.
crossConnection
crossConnectionId
equipmentHolder
equipmentId
eventForwarding Discriminator
discriminatorId
extendedCurrentAlarm SummaryControl
currentAlarmSummaryControlId
log (not installed)

logId
managedElement
managedElementId
nectarCircuitPack
equipmentId
nectarFRU
equipmentId
aGprsSgsnIpEndPoint
80 / 84
4.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
extendedCurrentAlarmSummaryControl
equipmentHolder (rack)
aGprsFabric
aGprs2MbTTP
aGprsNse
aGprsBssFunction
equipmentHolder (shelf) Circuit Pack NectarCircuit Pack

equipmentHolder (ASPack)
crossConnection * (M3100)
aGprsLapdLink
aGprsBearerChannel
aGprsNsvc
btsSiteManager
aGprsGicGroup
aGprsPvc
aGprsSgsnIpEndPoint
aGprsBts
NectarCircuit Pack Nectar FRU

equipmentHolder (ITPack)
aGprsMasterChannelData
aGprsPowerControl
aGprsPdchGroup
aGprsAdjacentCellReselection NectarCircuit Pack Nectar FRU
81 / 84
4.1.3 MFS Managed Object Allowed States

The allowed states of MFS Managed Objects are indicated in the following table. Managed Object Class aGprs2MbTTP Administrative State Locked/unlocked Operational State Enabled/disabled Enabled/disabled Enabled/disabled Enabled/disabled Enabled/disabled Enabled/disabled Enabled/disabled Enabled/disabled Enabled/disabled Enabled Enabled/disabled Enabled/disabled Enabled Enabled/disabled Enabled/disabled Enabled/disabled Availability Status Not installed/failed/(empty) Not installed/failed/(empty) Not installed/failed/(empty) Not installed/failed/(empty) Not installed/failed/(empty) Not installed/failed/off duty/in test/ dependency/(empty) Not installed/failed/(empty) Failed/in test/(empty) Not installed/failed/(empty) Not installed/failed/(empty) Not installed/failed/off duty/in test/ dependency/(empty)
aGprsAdjacentCellReselection aGprsBearerChannel aGprsBssFunction aGprsBts aGprsFabric aGprsGicGroup aGprsLapdLink aGprsManagedElement Extension aGprsMasterChannelData aGprsNse aGprsNsvc aGprsPdchGroup aGprsPowerControl aGprsPvc btsSiteManager circuitPack crossConnection equipmentHolder eventForwardingDiscriminator extendedCurrentAlarm SummaryControl log managedElement nectarCircuitPack nectarFRU aGprsSgsnIpEndPoint Locked/unlocked Locked/unlocked Locked/unlocked Locked/unlocked Locked/unlocked Locked/unlocked Unlocked Locked/unlocked Locked/unlocked Unlocked Locked/unlocked Locked/unlocked Locked/unlocked
82 / 84
4.1.4 MFS Managed Object Supported Operations

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

The RITs in the MFS are listed in the following table. RIT GPU Remarks GPRS Processing Unit: hot insertion/extraction, plug and play (without declaration at the local terminal) Ethernet to ISL gateway board: hot insertion/extraction, plug and play (without declaration at the local terminal) Local Sub-network Ethernet Hub / Switch Redundancy applique Applique giving access to Ethernet ports of the JBGPU boards E1 access applique with redundancy facilities Access ports applique to the JBETI board Power supply applique
JBETI
Fan Unit Pilot Station LSN Ethernet Hub / Switch (*) Router (X.25) (*) Terminal concentrator (*) Shared disk Rack/Subrack including CONV boards and FAN (*) BAREDC BATTU
JAE1 JAETI BA35B2
(*) No action available for these units; only events and alarms are reported.
84 / 84

9135

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

9135

Uploaded by

Copyright:

Available Formats

Alcatel-Lucent GSM

9135 MFS Description

MFS Document Sub-System Description Release B10

3BK 21232 AAAA TQZZA Ed.05

BLANK PAGE BREAK

Status Short title

RELEASED 9135 MFS

3BK 21232 AAAA TQZZA Ed.05

3BK 21232 AAAA TQZZA Ed.05

3BK 21232 AAAA TQZZA Ed.05

3BK 21232 AAAA TQZZA Ed.05

3BK 21232 AAAA TQZZA Ed.05

1 MFS Functional Description

1 MFS Functional Description

3BK 21232 AAAA TQZZA Ed.05

1 MFS Functional Description

1.1 Introduction to MFS

1.1.1 MFS Overview

BTS Ater Mux Abis BTS BSC Ater Mux TC MSC

CS CircuitSwitched Traffic Gb MFS/SGSN Interface

GGSN Gateway GPRS Support Node PS PacketSwitched Traffic

3BK 21232 AAAA TQZZA Ed.05

1 MFS Functional Description

1.1.2 (E)GPRS Functions

3BK 21232 AAAA TQZZA Ed.05

1 MFS Functional Description

1.2 MFS Architecture

PCM Links GPU

Duplicated Ethernet LANs

PCM Links GPU

GPRS Processing Unit Local Area Network

3BK 21232 AAAA TQZZA Ed.05

1 MFS Functional Description

The MFS architecture is shown in more detail in the figure below.

GPU PCM Links JAE1/JAE1C Subrack Midplane

ICL/ISL Busses JBETI

Power Alarms External Alarms External Settings

Power Alarms External Alarms External Settings

To SGSN Ethernet Hub/Switch A1 Ethernet Hub/Switch B1

3BK 21232 AAAA TQZZA Ed.05

1 MFS Functional Description

1.2.1 Telecommunications Subsystem

3BK 21232 AAAA TQZZA Ed.05

1 MFS Functional Description

1.2.2 Server Subsystem

1.2.3 Hub/Switch Subsystem

1.2.4 OMC-R Connection

3BK 21232 AAAA TQZZA Ed.05

1 MFS Functional Description

1.3 External Interfaces

SGSN AGPS Server

IMT (Installation and Maintenance Terminal)

3BK 21232 AAAA TQZZA Ed.05

1 MFS Functional Description

MFS-A-GPS Server Interface (SAGI)

3BK 21232 AAAA TQZZA Ed.05

1 MFS Functional Description

1.4 Traffic and Signaling Links

1221222 11211 1221222 11211

3BK 21232 AAAA TQZZA Ed.05

1 MFS Functional Description

1.4.1 Physical Channel

Multiframe = 52 TDMA Frames (240 ms)