omc-r toolchain and ne ip ports usage b9 ed06.pdf

ED06Rel

OMC-R, ToolChain and N.E. IP Ports Usage Release B9

B9Ports_Usage_ed6Rel.doc 15/02/2007 3BK 29645 JAAA DSZZA 1/65

All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

OMC-R, ToolChain and N.E. IP Ports Usage Release B9 onwards

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

TABLE OF CONTENTS

REFERENCED DOCUMENTS...................................................................................4

1. PRINCIPLES.............................................................................................5 1.1 Principles about Ports ............................................................................5 1.2 Usage of FIREWALLS .............................................................................6 1.3 BSS O&M Network...................................................................................7 1.4 The OMC-R Network................................................................................8 1.5 ToolChain...............................................................................................11

1.5.1 RNO 12 1.5.2 LASER...................................................................................................13 1.5.3 NPA 15 1.5.4 RNP 17

1.6 Network Elements .................................................................................18 1.6.1 MFS 18 1.6.2 A9130 BSC Evolution............................................................................22

2. USAGE OF THE PORTS IN THE OMC-R ..............................................25 2.1 Services and applications not specific to the OMC-R........................25

2.1.1 Remote Procedure Call (RPC) ..............................................................25 2.1.1.1 RPC portmapper..............................................................................................25

2.1.2 File Transfer Protocol (FTP) ..................................................................27 2.1.3 Hypertext Transfer Protocol (HTTP)......................................................28 2.1.4 Network File System (NFS) ...................................................................29 2.1.5 Secure Shell (ssh) .................................................................................29

2.1.5.1 LDAP ..............................................................................................................29 2.1.6 SNMP....................................................................................................30 2.1.7 SMTP ....................................................................................................30

2.2 The OMC-R Application Services.........................................................31 2.2.1 DSM 31

2.2.1.1 Usage of Ports .................................................................................................31 2.2.1.2 Detailed Description of Service and Architecture...........................................32

2.2.2 SEC 33 2.2.2.1 Architecture.....................................................................................................33 2.2.2.2 Detailed Description of Service ......................................................................34

2.2.3 OSM 36 2.2.3.1 Architecture.....................................................................................................36 2.2.3.2 Detailed Description of Service ......................................................................36

2.2.4 AS 38 2.2.4.1 Architecture.....................................................................................................38 2.2.4.2 Detailed Description of Service ......................................................................39

2.2.5 RNIM 40 2.2.5.1 Architecture.....................................................................................................40 2.2.5.2 Detailed description of service........................................................................41

2.2.6 BSSIM ...................................................................................................42 2.2.6.1 Architecture.....................................................................................................42

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

2.2.6.2 Detailed Description of Service ......................................................................43 2.2.7 MFSIM...................................................................................................43

2.2.7.1 Detailed Description of Service ......................................................................44 2.2.8 OMC-R External Interfaces ...................................................................44

3. APPENDIX A (PORTS USAGE IN B9 RELEASE) .................................46 3.1 OMC........................................................................................................47

3.1.1 OMC-R System services: ......................................................................47 3.1.2 RPC Services ........................................................................................49 3.1.3 OMC-R Services ...................................................................................51

3.2 ToolChain...............................................................................................53 3.2.1 NPA (Network Performance Analyser)/MPM/NPAE (see 1.5.3) ............53 3.2.2 RNO (Radio Network Optimizer) ...........................................................54 3.2.3 LASER service ......................................................................................54 3.2.4 RNP 55

3.3 Network Element (N.E) ..........................................................................55 3.3.1 MFS 55

3.3.1.1 A9135 MFS legacy .........................................................................................55 3.3.1.2 A9130 MFS evolution.....................................................................................59

3.3.2 A9130 BSC Evolution............................................................................62 *Ephemeral ports range (39000-50000) on BSC side should always be opened to

communication outwards, .........................................................................62 3.3.3 External Alarm Box................................................................................63

4. TERMINOLOGY......................................................................................64

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

ED DATE CHANGE NOTE APPRAISAL AUTHORITY ORIGINATOR 01 051121 First issue O&M System TD/O&M/OMC3 Spec 02 060111 Second issue O&M System TD/O&M/OMC3 Spec 03 060130 Third issue O&M System TD/O&M/OMC3 Spec 04 060804 Forth issue O&M System TD/O&M/OMC3 Spec 05 061117 Fifth issue O&M System TD/O&M/OMC3 Spec 06 070208 Sixth issue O&M System TD/O&M/OMC3 Spec

Ed. 01 21/11/2005:

Creation

Ed. 02 11/01/2006:

Update of SNMP and CMIP related ports

Ed. 03 30/01/2006:

A9130 BSC Evolution and A9130 MFS Evolution added IMT documented

Ed. 04 04/08/2006:

New Ports added on the OMC side and also on MFS side

Ed. 05 17/11/2006: Editorial alignments

Ed. 06 08/02/2007: Updates made in the Port Usage tables

REFERENCED DOCUMENTS

Alcatel Documents

[1] OMC-R Architecture 3BK 09097 JAAA EBZZ

[2] OMC-R User and Administration Facilities 3BK 09635 JAAA DSZZA [3] IO 99 Usage of Ports between Master Host and HMI 3DF 0030 00099 UAZZA

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

1. PRINCIPLES

1.1 Principles about Ports

A TCP/IP (Transmission Control Protocol/Internet Protocol) or UDP/IP (User Datagram Protocol/Internet Protocol) port is the way a client program can reach a particular server program on a computer in a network.

Some applications have ports with pre assigned numbers. These are known as "well-known ports" and have been assigned port numbers by the Internet Assigned Numbers Authority (IANA). Other application processes are given port numbers dynamically for each connection. When a service (server program) is started, it listen to its designated port number. If any client program wants to use that server, it must use the designated port number.

Port numbers are from 0 to 65536. The port numbers are divided into three ranges (IANA conformity): The Well Known Ports, from 0 through 1023,

The Registered Ports, from 1024 through 49151,

The Dynamic and/or Private Ports, from 49152 through 65535.

But, on SOLARIS 10, the port numbers are divided as follows:

The Well Known Ports, from 0 through 1023,

The Registered Ports, from 1024 through 32768,

The Dynamic and/or Private Ports, from 32768 through 65535.

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

1.2 Usage of FIREWALLS

If it is known that a device will typically be deployed behind a firewall then it is possible to harden only those services that are visible through the firewall. A firewall is a set of related programs, located at a network gateway server, which protects the resources of a private network from users from other networks.

The present documentation tells the user how to configure the firewall for securing their equipments, which are present behind the them.

A stateless firewall inspects one packet at a time, and inspects it independently of every other packet.

A stateful firewall keeps track of information (state) about which packets are associated with which connections, and can use this information to make decisions about which packets and/or connections to drop.

The basic stateless firewalls will allow limited security since wide ranges of ports will have to be left open. Stateful firewalls will allow more controls.

It should be recalled here that another solution exists, which consists in using a Virtual Private Network (VPN). This solution is easy to implement and is fully compatible with the OMC-R architecture.

On Appendix A (Ports Usage in B9 Release) a list of ports used in BSS O&M network are provided.

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

1.3 BSS O&M Network

Figure 1 BSS O&M Network Architecture

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

1.4 The OMC-R Network

A1353-RA OMC-R architecture allows a flexible distribution of management components across the different nodes of the network according to specific needs related to for instance network dimensions and performance requirements. By means of this configuration flexibility, the management system can evolve and be adapted to new dimensioning requirements, adding new machines where necessary.

The main hardware configurations supported by A1353-RA are:

N M C

U s e r T e rm in a ls

P e ri D e v ic e s

P rin te rs

Q 3 M e d ia tio n

O M C -R M a s te r S e rve r

D a ta b a s e

L A N / W A N D C N

L A N / W A N D C N

H M I S e rve r(s )

lo c a l la n lo c a l o r rem o te la n

O M C -R

U s e r T e rm in a ls

P e ri D e v ic e s

P rin te rs

X 2 5 C o n n e c tio n IP C o n n ec tio n

B S S

IP N E

Figure 2 A1353-RA OMC-R Single Configuration Overview

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

NMC

User Terminals

Peri Devices

Printers

Q3 Mediation

OMC-R Master Server

Database

OMC-R Agent Server

Database

LAN / WAN DCN

LAN / WAN DCN

HMI Server(s)

local lan

local or remote lan

OMC-R Domain

User Terminals

Peri Devices

Printers

X25 Connection IP Connection

BSS

IP NE

X25 Connection IP Connection

BSS

IP NE

OMC-R Agent Server

Database

Figure 3 A1353-RA OMC-R Distributed Configuration Overview

For OMC-R configuration, the following assumptions are considered: - We may have Single-host or Multiple-host OMC-R. - N.E. (Network Elements) are connected to all OMC-Rs hosts through IP (A935MFS, A

9130 A9130 MFS Evolution, A9130 BSC Evolution) or X25 (BSC G2) The following OMC-R configurations are to be considered:

- Single-host OMC-R configurations. This family of configuration is composed of an unique host called master host, and of a variable number of HMI hosts. The offer of single host configurations is multiple (examples of such configurations are Small or Small with Embedded NPA configurations, Standard, Large 1, Large 2 Configurations),

- Multiple-hosts OMC-R configurations, called X-large configuration is considered. This configuration consists in 2 or 3 host machines one Master host and two Agent hosts - and of a variable number of HMI hosts.

NOTE: In present document, we will refer to AGENT as presented in the draw above (Multiple-hosts OMC-R configurations) On this purpose, for CLIENT SERVER architecture we will not use the equivalent name for avoiding confusion.

Master Server:

Unix Server, whose main purpose is to run the OMC-R management applications. In particular, this server hosts system administration functions, Alarm Database and Surveillance module, Q3 mediation and the Radio Network Configuration database.

In the Single server configuration only, this host server mediates also data from the Network Elements, and stores these data in the BSS database.

Agent Server:

Unix Server, present only in the distributed configuration, whose main purpose is to host the mediation of group of Network Elements in order to increase the capacity of the OMC-R.

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

User Terminal:

Graphical Workstations connected to the master Server or to the HMI Server

The master host and HMI do not totally follow a client/server model.

For almost all the applications, the server part is on the master host and the client part is on the HMI. The consequence in term of usage of ports is that the client applications of the HMI will contact the server application on the master host on an identified port (dynamically given by a port number server or static). But, for a few applications, identified in this document, the client part is on the master host and the server part is on the HMI. As a consequence, the client applications of the master host will contact the server applications on the HMI on an identified port (dynamically given by a port number server or static).

Figure 4 Flow of data between OMC-R and ToolChain

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

1.5 ToolChain

Alcatel 1353 RA

O MC R

Radio Config (FTP service

only)

PM Counters (FTP service

only)

Alarms (FTP service only)

Alcatel NPA

Alcatel 9157 LASER

Alcatel 9156 RNO Alcatel 9155 RNP

HMI

Network Management Center GSM

Q3 intf over IP (RFC 1006)

MFS A9135 A9130 MFS Evolution

BSC Evolution

X25 IP

BSC G2 BSC G2

Figure 5 Flow of Data between OMC-R and ToolChain

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

1.5.1 RNO

In GSM, RNO is part of the Toolchain. It manages radio configuration and offers QoS monitoring.

RNO is running on WINDOWS platform. This platform can run on a single site or on distributed area, by using remote clients.

1. RNP provides RNO with a cell design and related geographical information.

2. Periodic download of the network operational state is done

3. RNO needs PM data for QoS analysis. Those data are extracted from the NPA tool (based on a Metrica statistical database), which contains a multi-OMC-R database.

4. A new configuration for elements of a network can then be proposed. Conversion of tuning session files in LPM or PRC command files applicable to an OMC-R is done thanks to the Tuning Browser tool

Figure 6 RNO Place in O&M Network

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

There are 2 configurations possible for RNO:

1. SERVER CLIENT: 2. RNO SERVER STAND ALONE

RNO SERVER

RNO CLIENT

RNO CLIENT

RNO CLIENT

Option: CITRIX SRV

Figure 7 RNO SERVER CLIENT configuration

1.5.2 LASER

LASER is a post-processing application of OMC-R. From each OMC-R, BSS/MFS alarms,

OMC-R operator commands, resource state changes and BSS/MFS topology are retrieved daily.

LASER is not integrated in OMC-R. LASER is running on WINDOWS platform. This platform can run on a single site or on distributed area, by using remote clients.

Laser does not launch command on the OMC-R. Laser only uses ftp commands to get data. The data are located in directories located in the isolated exchange area.

Laser also put data on NPA. In case of NPA embedded OMC-R, it means these data are put within the OMC-R. These data shall be put in the Laser directory

There are also 2 configurations possible for LASER:

1. SERVER CLIENT:

2. LASER SERVER STAND ALONE

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

Event detection rules

Unavailability origin list

Busy/non busy hours

HMI

FTP

MFS

BTS

BSC

GetBSSConf.sh

BSS

topology

MFS

topology

BSS alarms

MFS alarms

Topol ogy

Alarms

FTP FTP

User HMI Events

Indicators Display/report

User

State changes

OMC operator commands

OMC - R

(1 ..n)

(1 ..n)

(1 ..n)

(1 ..n)

NPA

FTP

Unavailability Indicators

Current states

LASER

Figure 8 Laser Flow of Data

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

1.5.3 NPA

Definition: A software application developed by Alcatel used to collect Performance Measurements files of a telecommunication system. The information is stored in a database and can be queried.

This software is running either on OMC-R platform (MPM application or NPA embedded) either on a specific SOLARIS platform, generic called NPA.

Only put and get ftp actions are considered.

Figure 9 NPA Architecture

Every 5 minutes: - The transfer scripts transfer the new PM files. - The parser reads the data and transforms it into the standardised data load format:

the parser associates counters with the corresponding entity (TRX, cell, BSC, ) using the topology files.

Loader is a permanent process. The loaders have to: - Store counters in predetermined tables in database, using loadmaps - Compute raw indicators from counters table and store them in the database - Generate alarms if thresholds are crossed for alerters (for MPM only). NPA can handle B8 and B9 OMC.

NPA embedded, named as NPAE in this document, is a reunion between NPA and MPM specific features and can be found only on the OMC machine and can handle less than 250 cells.

NPA/MPM/NPAE can handle B8 and B9 BSSs and MFSs.

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

Figure 10 NPA Inter-release data flow

IMPORTANT NOTE: As seen above, NPA B9 will interface directly with MFS B8 if the last one is connected to OMC B8. This observation is particularly important during transition B8 -> B9, when this situation is inevitable (in a intermediate step).

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

1.5.4 RNP

For an integrated use of A9155 RNP in an overall radio network management environment, it can exchange data with Radio Network Optimization tools (e.g. A9156 RNO), OMC-Rs and field-measurement-tools like A954 RNM for example.

Field measurement (e.g. A9154)

A9155 RNP

Measurement Traces

RNO (e.g. A9156)

OMC-R

BSS

Planned radio resource design

Netw . Topology and

Frequency Plan

Figure 11 RNP Flow of data

The data is exchanged in form of files. The entire planning data is supplied in several files, depending on the destination (RNO or OMC-R). A9155 RNP supports data files that can be read by the Alcatel OMC-R and the Alcatel 9156 RNO.

RNP hosts an ftp client for transfer accesses with OMC-R.

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

1.6 Network Elements

On following chapter, the communication with IP based N.E. (Network Elements) is treated. Currently there are three types of IP based NE: A935 MFS A9130 MFS Evolution A9130 BSC Evolution In this document, unless explicitly mentioned, MFS includes both A935 MFS and A9130 MFS Evolution. Contrary, in case of BSC, we refer exclusively to A9130 BSC Evolution, as previous generation is not subjected by present document (not an IP NE)

1.6.1 MFS

B S C N o n IP N etw .

S G S N

IP T e le co m N etw .

IP O & M N etw o rk

O M C -R

IM T

N o t S u b jec ted b y p re sen t d o cu m en t

L E G E N D :

C o re N e tw o rk

B S S N etw o rk

IM T In s ta lla tio n an d M a in ten e n ce T e rm in a l

G G S N

E x tA lm B o x (fo r M F S E v o lu tio n

o n ly * )

* O n ly in c a se o f M F S E v o lu tio n

M F S

M F S s ite

Figure 12 MFS place and connections

As seen above, MFS communicates with 2 different correspondents: OMC-R and IMT. The IMT is the local terminal of the GPRS NE platform. It is the base of the Installation and Maintenance Terminal (IMT) of the MFS. The IMT can be used during development test phases and operational phases such as installation and maintenance. Can be used locally (co-site with MFS) or remotely.

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

The IMT GUI is a java application made by a Java compiler that produces bytecodes. We need to have a Java Virtual Machine (JVM) in order to execute the application onto a WEB browser. This JVM is installed on client platforms. Operating system: Microsoft windows 2000 , Microsoft windows XP, SUN Solaris version 2.10. WEB Browser accepting MIME type treatment for jnlp files. HTTP server on each MFS pilot station (Apache Server). Java Runtime Environement 1.4.2 including java webstart 1.2 from SUN microsystems. The architecture is based on JAVA webstart signed technology and HTML/cgi pages loaded in a web browser. Upon initial connection on WEB server, a package (JAR file) that contains IMT GUI application and BUI process is loaded and BUI is locally launched. As seen above, IMT can run either on PC, either on OMC-R platform. If running on OMC-R platform, can be hosted either by MASTER, either by HMI.

IMT Craft_Server On MFS control station

IP O&M Network

OMCR Local LAN

OMCR Remote LAN

IMT (LMT GUI) on HMI

IMT (LMT GUI)

on HMI

IMT (LMT GUI) on OMC Master

IMT (LMT GUI)

on PC

Figure 13 IMT Location

As seen in above figure, there is a direct communication IMT MFS. Also, it is mandatory that IMT may be open up from OMC-R.

The MFS is a network element, basically managed by an OMC-R and an Initialization and Maintenance Terminal (IMT) that can be started at OMC-R platform. MFS is managed from OMC-R via CMIP, FTP (bulk transfers), and NTP (time synchronisation). and SNMP (for MRTG application). Also, MFS is supervised from OMC-R by MRTG application (through SNMP stack).

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

MFS is managed from IMT, through several protocols/services (see below):

Windows NT or Solaris station

WEB Browser

LMT GUI BUI

Socket on TCP/IP

WebServer FTP daemon

Craft Server BackUp Restore/Patch

Server

GATEWAY

MFS Components

HTTP on TCP/IP

FTP on TCP/IP

Sockets on TCP/IP

Sockets on TCP/IP Incapsulates CMPS

MFS

Figure 14 IMT Lay-out

The protocols used between the IMT (views) and the MFS are: HTTP: for applet and web browser CMPS/BUI: for refreshing the IMT views with application objects... FTP: Radio configuration files, Counters files, new SW,... RSH: for DB restore activation,... TELNET: Remote Debug SNMP agent (server) for MFS supervision through MRTG (see 2.1.6) Other services like Craft server, backup restore server, patch server are also defined between the IMT and the MFS. The MFS is synchronized via NTP (RFC-1305, Network Time Protocol). As a basic rule at O&M system level, for MFS, communications are always initiated by a manager (OMC-R, remote IMT) and never by MFS. The only exception is for NTP (MFS is initiator). For ftp transfer, following rules applies: MFS Serves PM, rem. Inv. & MIB data save to the OMC MFS Accept massive config Q3 files pushed from the OMC Accept software data from the OMC (pushed by the IMT) Serves software change status info to the OMC

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

CMPS: Short for Common Management Protocol Syntax, an ALCATEL proprietary protocol used with a Common Management Information Services (CMIS) like. The IMT is composed of a graphical interface running on web browser and a process that is in charge of analysing BUL requests and translating into CMPS PDU. This process is called BUI.

BUL files represents the configuration files of MFS. These files can be downloaded/uploaded from IMT only.

NTP: The Network Time Protocol (NTP) is a program for synchronising the clocks of computer systems over packet-switched, variable-latency data networks. Although NTP is most commonly used in conjunction with UDP/IP protocol, it can also be transported over other network protocols such as TCP/IP. It is designed particularly to resist the effects of variable latency.

NTP server

NTP client MFS

NTP server

NTP client OMC

Customer defined NTP Server

Figure 15 NTP in BSS O&M

CRAFT TERMINAL: The CRAFT server (CRAFT_SRV) processes specific requests from the IMT (which are not CMPS requests) and is launched by the CRAFT supervisor. The Backup Restore Server: (BckpRstr) processes periodic MIB backup and on demand MIB backup or restore (control station tasks). Patch Server (for A935 MFS only): The Patch server (PatchSrv) which performs Tru64 UNIX patch installation (control station tasks).

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

1.6.2 A9130 BSC Evolution

NEM Network Element Manager. Situated always on the same LAN with BSC Evolution

BSCEvolution

BTS Non IP Netw.

MSC

Non IP Netw.

IP O&M Network

OMC-R (option MPM)

BSC Terminal (on Windows platform only)

Not Subjected by present document

LEGEND :

Core Network

BSS Network

BSC Terminal BSC Terminal can run on Windows platform only

Local or Remote LAN

Local or Remote LAN

NEM

Local LAN BSS

Network

External Alm Box

Figure 16 A9130 BSC Evolution. Place and Connections

A9130 BSC Evolution is a N.E. managed by OMC-R and BSC Terminal.

Collocated with A9130 BSC Evolution, there is another IP equipment called External Alarm Box. This equipment is also managed by OMC-R through SNMP protocol.

The role of this IP equipment is to send traps for describing alarms triggered by external events.

The only equipment External Alarm Box is communicating with is OMC-R, where the client is hosted.

External Services for A9130 BSC Evolution:

- FTP Services (External file transfer that allow file exchange between A9130 BSC Evolution and external world (currently identified as OMC-R and BSC Terminal).

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

On A9130 BSC Evolution, 2 ftp servers are chosen: proftpd & SFTP. SFTP comes with SSH and applies the SSH rules for security. Contrary to MFS case, where file transfer is initiated by OMC-R only, in case of BSC, GET only policy applies. Consequently, both OMC-R and BSC have initiative in requesting ftp transfer:

BSC pulls all software and configuration data from OMCR Serves OMC with all PM,traces & rem. Inv. Data Serves OMC for file management (remote operator)

- In A9130 BSC Evolution date/time synchronisation is managed via NTP protocol provided by LINUX. After system initialisation, OMC-R is configured as a default NTP server. But operator could also define another time reference for its network.

- SNMP based services (OMC-R - A9130 BSC Evolution - see 2.1.6) A9130 BSC Evolution communicates on external with: OMC-R, CBC (Cell Broadcast Centre), BSC Terminal.

BSC OMC-R

Link(802.3)

IP IP

Link(802.3)

ROUTER

802.3A/B

ISO-L5,L6

ISO_TS

(ON TCP)

TCP/UDP

Link(802.3a/b)

IP

CMISE/ROSE

/ACSE

APPLICATION

ISO-L5,L6

ISO_TS

(ON TCP)

TCP/UDP

Link(802.3a/b)

IP

CMISE/ROSE

/ACSE

APPLICATION

802.3A/B

Figure 17 A9130 BSC Evolution connection with OMC-R

A9130 BSC

IP Cloud IP

Router IP

IP Router

X25

CBC

Figure 18 Network Topology for A9130 BSC Evolution CBC connectivity

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

BSC CBC

X.25

TCP/UDP

Link(802.3)

IP

XOT

IP/X25 Router

TCP/UDP

XOT

X.25

SMS-CB

Link(802.3

LAPB

Serial Link

X.25

LAPB

Serial Link

X.25

SMS-CB

V.11/V.28

IP

802.3A/B

Figure 19 A9130 BSC Evolution connection with CBC

BSC Terminal will always initiate the connection request, and hence it has to run TCP/IP client application. A particular port in A9130 BSC Evolution is reserved for NEM connection requests (27767 see 3.3.2). Once the connection is established, TCP/IP client can send/receive data (command/report) to/from A9130 BSC Evolution.

MMC = Man Machine Communication

IM = Intermediate Module (basically a Linux process which will run in the OMCP board. This intermediate module will be responsible for routing the messages only from/to the BSC Terminal and Tradeb terminal to/from the MMC module.

Figure 20 Interaction A9130 BSC Evolution and BSC Terminal

IP

BSC Terminal

PC

TCP/ IP

Client IP

MMC

ME_MEASURE ME_ALRM

ME_HSK

OBCI_NH

ME_BTS

Tradeb Master

BSC

VOS (Virtual OS)

I M

ME_SWRep

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

2. USAGE OF THE PORTS IN THE OMC-R

This section is split in two parts:

The first part deals with the services and applications, which are not specific to the OMC-R, i.e. system services, Internet protocols, etc

The second part concerns the applications of the OMC-R. Services and applications not specific to the OMC-R.

2.1 Services and applications not specific to the OMC-R

The OMC-R is composed of Unix machines, which are using the usual Unix services, among which:

Services based on the Remote Procedure Call (RPC), The portmapper, The Network File System (NFS),

The ftp protocol The Hypertext Transfer Protocol (HTTP) The SSH Protocol LDAP

SNMP.

2.1.1 Remote Procedure Call (RPC)

Remote Procedure Call (RPC) is a protocol that a program can use to request a service from a program located in another computer in a network without having to understand network details. RPC uses the client/server model. The requesting program is a client and the service-providing program is the server.

2.1.1.1 RPC portmapper

Portmap is a server that converts RPC (Remote Procedure Call) program numbers into TCP/UDP port numbers. It must be running in order to make RPC calls. When an RPC server starts up, it registers with the portmap daemon. The server tells the daemon which port number it is listening to and which RPC program numbers it serves. Thus, the portmap daemon knows the location of every registered port on the host and which programs are available on each of these ports. A client consults the portmap daemon only once for each program the client tries to call. The portmap daemon tells the client which port to send the call to. The client stores this information for future reference.

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

SERVER

portmap

Server program

111

z

CLIENT

Client program z

Request a port number for a

service

Use the received port number

1

2

3

4

Figure 17 Portmap principles

In the OMC-R, portmap is used on both sides (master host and HMI) as described in the following figure.

HMI

portmap

Server program

111

zzzzz

MASTER

Client program zzzz

z

portmap

Server program

xxxxx

111

yyyyy

Client program yyyyy

Figure 18 Usage of portmpap in the OMC-R

Network File System (NFS) is a RPC application used in OMCR (see 2.1.4).

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

2.1.2 File Transfer Protocol (FTP)

File Transfer Protocol (FTP) is a standard Internet protocol used to exchange files between computers on the Internet. FTP is commonly used to upload and download data from a computer to a server.

Product used: Proftpd

The following security principle is followed. The exchange of information with external users/applications is based on the use of an ftp server and the isolation from the rest of the OMC-R of the exchange area. The Proftpd server is configured and used in such a way that the server itself is relatively protected from classical attacks, and if penetrated or used improperly, will create no significant problem for the rest of the OMC (isolated exchange area). The rights for using ftp services are defined in: /usr/local/etc/proftpd.conf In this file, the isolated exchange area is defined /var/tmp/proftp.passwd In this file, the users who may use ftp services are defined

The only operations authorized for external users/applications are put/get operations.

As FTP has its own specificity, not met in other applications we give a special attention to it. Below there are some explanations related to.

Two FTP modes are possible, active and passive. The main difference between the two FTP modes is in the initiation of the data connection. In the active mode, the server opens the data connection, whereas in the passive mode it is the client.

So, in passive mode only client have initiative for both connections (control and data) whereas in active mode both sides initiates one connection: client initiates control connexion and server initiates data connexion. It is illustrated in the following figure.

FTPserver

(Master)

FTPclient(HMI)

FTPserver

(Master)

FTPclient(HMI)

Port 21command

Port 20data

Port 21command

Port1882*

Port3235*

Port3236*

Port3235*

Port3236*

Active mode Passive mode

* : means random port number

1

23

4

1

23

4

Figure 19 The ftp protocol

NOTE: Modern FTP servers can restrict this dynamic allocation range

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

Inside the O&M network, both modes are used.

The following table describes the usage of ports for ftp protocol between master host and HMI - stateless firewall considered. Passive mode (passive mode is widely used to protect the FTP client network): a. client firewall

1. allow TCP from client to server dst port 21 setup (SYN,!ACK) 2. allow TCP from client to server dst port >1024 setup 3. deny TCP from any to client setup 4. allow TCP from any to any established (by rule 1) 5. deny all

b. server firewall 1. allow TCP from client to server dst port 21 setup 2. allow TCP from client to server dst port >1024 setup 3. deny TCP from any to server setup 4. allow TCP from any to any established (by rules 1,2) 5. deny all

Active mode a. client firewall

1. allow TCP from client to server dst port 21 setup 20 allow TCP from server to client src port 20 setup

2. deny TCP from any to client setup 3. allow TCP from any to any established (by rule 1,2) 4. deny all

b. server firewall 1. allow TCP from client to server dst port 21 setup 2. allow TCP from server to client src port 20 setup 3. deny TCP from any to server setup 4. allow TCP from any to any established (by rule 1,2) 5. deny all

2.1.3 Hypertext Transfer Protocol (HTTP)

The Hypertext Transfer Protocol (HTTP) HTTP is the Internet protocol for transferring files. It requires the host to use an HTTP server program, and the viewer to use an HTTP client program. The server used is Apache. Apache authentication is performed through mod_auth_LDAP. User authorization is performed through mod_auth_SEC7.

On the OMC-R, the http server is installed on the master host.

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

2.1.4 Network File System (NFS)

The Network File System (NFS) is a client/server application that lets a computer user view and optionally store and update file on a remote computer as though they were on the user's own computer. The user's system needs to have an NFS client and the other computer needs the NFS server. Both of them require also TCP/IP installed since the NFS server and client use TCP/IP as the program that sends the files and updates back and forth.

On the OMC-R NFS is used between the master hosts and the HMIs.

Master partitions are mounted on the HMI. The users logged on the HMI can view, store and update files, which are located on the master. For example, the home directories are mounted by NFS.

HMIMASTER

Partition

Partition

Partition

Partition

Partition

Partition

Mounted by NFS

Figure 20 Usage of NFS between Master and HMI

2.1.5 Secure Shell (ssh)

SSH is a program for logging into, and executing commands on, a remote computer. ssh is intended to replace rlogin, telnet, rcp and rsh, and provide secure encrypted communications between two hosts.

SSH protects the user from illicit network snooping (packet sniffing), whereby un-encrypted passwords and text can be read by unscrupulous persons.

As authentication method, ssh supports RSA based authentication

2.1.5.1 LDAP

LDAP, Lightweight Directory Access Protocol, is an Internet protocol that email and other programs use to look up information from a server. LDAP is used to look up encryption certificates, pointers to printers and other services on a network.

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

2.1.6 SNMP

Short for Simple Network Management Protocol, a set of protocols for managing complex networks.

Principle: one or more daemons (SNMP servers) are running on target machines (the MFS control stations for examples) to process the management requests sent by the Network Management Station. In current release is used for monitoring MFS resources (processor, disk, memory,)through MRTG tool - Service External Load Reporting. MRTG (application is selected in OMCR as SNMP manager.

O M C R ( S N M P C l i e n t )

A c t i v e O M C P - M F S ( S N M P S e r v e r )

Figure 21 SNMP Protocol

2.1.7 SMTP

Short for Simple Mail Transfer Protocol, a protocol for sending email messages between servers.

OMC Master configured as Mail server and Mail Host OMC Agents, HMIs configured as mail clients SMTP server is not configurated as Open Relay server. Also, no email forward to other servers apart from: Master, Agents and HMIs. Listening service (MTA), present on Master is protected with TCP wrapper.

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

2.2 The OMC-R Application Services

2.2.1 DSM

DSM is a software product in charge of monitoring the processes of the OMC-R.

2.2.1.1 Usage of Ports

The following figure presents the communications between the master host and the HMI for DSM.

MASTER

DSMIM

DSMLPCDSMCLI DSMUSM

HMIDSMLPC

DSMCLI

DSMUSM

LegendA establish a connection toward B: A B

Figure 22 DSM architecture

The ports used are dynamically selected.

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

2.2.1.2 Detailed Description of Service and Architecture

DSM is a software product dedicated to managing distributed applications along with the hosts running these applications. It offers the following features: Starts, stops and discovers distributed applications running on UNIX, Manages dependencies between applications, Handles HP OpenView processes, Monitors processes (existence, memory size), Monitors CPU load on remote hosts, Monitors disk space used on remote hosts.

DSM is based on a centralized architecture made up of the following building blocks:

DSM IM is the central part of DSM. It is responsible for the management of all hosts, subsystems, groups and processes defined in the offline configuration. It ensures the defense of permanent processes and groups.

DSM LPC performs, on each managed host, the monitoring of local host parameters and the management of local physical processes.

DSM USM is the graphical user interface. It offers to the administrator an access to all management functionalities and, to non-administrator, a view of the monitored configuration.

DSM CLI is a commandoriented interface providing a subset of management functionalities.

The communication between master host and HMI is achieved through different applications of DSM, which are DSMIM, DSMLPC, DSMUSM and DSMCLI.

The following resources, which are dynamically mapped to port number, are used:

For DSMIM, ImRpcProgramNumber (type: integer ranging from 536870912 to 1073741823 the default value is 553648128 no configured value). RPC program number of DSMIM. This resource is read by DSMIM, to register with the RPC portmapper, and by DSMCLI and DSMUSM, to connect to DSMIM.

For DSMLPC, LpcRpcProgramNumber (type: integer ranging from 536870912 to 1073741823 The default value is 553652224 - the configured value is 553648384). RPC program number of DSMLPC. This resource is read by DSMLPC, to register with the RPC port mapper, and by DSMIM, to connect to DSMLPC.

For DSMUSM, UsmRpcProgramNumber (type: integer ranging from 1073741824 to 1610612735 - The default value is 1073741824 - no configured value in B6. In B7 & B9: 1073741825). RPC program number used by DSMUSM. DSMUSM occupies the first free RPC program number in range from UsmRpcProgramNumber to 1610612735.

For DSMCLI, CliRpcProgramNumber (type: integer ranging from 1073741824 to 1610612735 The default value is 1073741824 - no configured value in B6. In B7 & B9 configured value is 1073741827). RPC program number of DSMCLI. DSMCLI occupies the first free RPC program number in the range from CliRpcProgramNumber to 610612735.

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

2.2.2 SEC

ACI: SEC 7.0 handles some access control related information, roughly defining who can access what at what time. This information is called Access Control Information (ACI), and is stored in a central repository called the ACI database.

SEC is split into the following components:

- The Security Information Manager (SEC IM) maintains the consistency of the Security Information stored in the LDAP

- The Security User Service Manager (SEC USM) provides all the services concerned with access control administration through an integrated graphical user interface.

- The Local Security Server (LSS), which is run on each machine where Access Control Information is needed. Its role is to provide each client with adapted Access Control Information (using LDAP).

The SEC application is in charge of the security of the OMC-R at application level.

2.2.2.1 Architecture

The following figure presents the communications between the master host and the HMI for SEC.

SE C IM L S S

M A ST E R H M I

L egend A estab lish a connection to w ard B : A B

L S S

S E C U S M

S E C U S M

Figure 23 SEC exchanges between master host and HMI

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

2.2.2.2 Detailed Description of Service

SEC is an application in charge of the security at application level. It is split into the following components:

The Security Information Manager (SEC IM) maintains the consistency of the Security Information stored in the ACI DB. During the start-up phase, it also uses external files to load the application functions and menu lists. This component is implemented as a dedicated process instantiated only once for a given ACI DB.

The Security User Service Manager (SEC USM) provides all the services concerned with access control administration through an integrated graphical user interface.

The Local Security Server (LSS), which is run on each machine where Access Control Information is needed. Its role is to provide each client with adapted Access Control Information. It is available for a client through one of the AC APIs described below. The C++ Access Control Library (C++ ACL) providing the C++ Access Control API. Any C++ application needing to control the access of an operator to objects and functions can use this library. BSSUSM, MFSUSM, DCNUSMUSM, and RNUSM use this library. The following figure presents the architecture of SEC.

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

LDAP server

SECIM

LSS

BSSUSM RNUSM

MFSUSM

SECUSM LSS

BSSUSM RNUSM

MFSUSM

LSS

BSSUSM RNUSM

MFSUSM

CORBA interface

Non CORBA interface

Legend:

Navigation

Read/write access

Read only access

Master host

HMI HMI

DSM DCN

BSSUSM ASCURUSM

ASHISTUSM MFSUSM

RNUSM

DSM DCN

BSSUSM ASCURUSM

ASHISTUSM MFSUSM

RNUSM

DSM DCN

BSSUSM ASCURUSM

ASHISTUSM MFSUSM

RNUSM

SECUSM SECUSM

Figure 24 SEC architecture

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

2.2.3 OSM

The OSM application is in charge of OMC-R platform management.


The following figure presents the communications between the master host and the HMI for OSM.

HMI

OSM CGI scripts

OSMD

MASTER

Legend A establish a connection toward B: A B

AGENT

OSMD

OSMD

Figure 25 OSM exchanges between master host and HMI


OSM is the platform management tool of the OMC-R. It offers the interface for the platform management functions. OSM provides: administration services including backup-restore, cleanup, scheduling management, failure management, set date and time, system monitoring, shutdown, user management. configuration services including configuration parameters, printer management, and workstation management. OSM relies upon distributed client-server architecture. The client is OSM, the servers are called osmd and are permanent processes. The basic interaction between the clients and the servers is the following: The client launches a connection request, The client specifies the requested service, The server executes the service and return the status, The client closes the connection. The communication between the clients and the osmd daemons is based upon a simple ASCII protocol, used by CGI-scripts. The following figure presents architecture of OSM.

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

OSMD

Unix command

OSM HTML interface

LDAP server

database

Unix database

CGI scripts

OSMD

Unix command

OSMD

Unix command

Remote host Remote host

Q3 interface Non Q3 interface

Legend:

Navigation

Read/write access

Read only access

Flat file

Master host

Figure 26 OSM architecture

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

2.2.4 AS

The Alarm Surveillance (AS) application is in charge of the handling of alarms.


The following figure presents the communications between the master host and the HMI for AS.

MASTER

AS current IM

AS hist IM

HMI

AS current USM

AS historic USM


AS current USM

AS historic USM

ExportCALTOASCII

acorequest

Figure 27 AS exchanges between master host and HMI

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.


The Alarm Surveillance (AS) application handles alarm information. The management of current and historical alarm information is separated in order to permit the use of one part without the other, and also to distribute the management of current and historical alarms.

AS can be decomposed into the following building blocks: AS Current IM (ASCURIM) managing the current alarm information, AS Current USM, in charge of presenting current alarm information to the operator, AS Historical IM (ASHISTIM), providing consultation services to AS Historical USMs

with respect to one Public Archive database. AS Historical USM, in charge of presenting historical alarm information to the

operator, The following figure presents the architecture of AS.

MASTER

AS currentUSM

AS historicUSM

AS currentIM

AS hist IM

CALPublic

Archive

MFSIMBSSIMBSSIMBSSIM MFSIMMFSIM

HMI

AS currentUSM

AS historicUSM

LegendA establish a connection toward B: A B

Figure 28 AS architecture

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

2.2.5 RNIM

The RNIM component is in charge of the radio network configuration.

2.2.5.1 Architecture The following figure presents the communications between the master host and the HMI for RNIM.

MASTER

RNIMSC

RNIMPRC

HMI

DCNUSM

RNUSM


RNUSM

DCNUSM

NAMESERVER

Figure 29 RNIM exchanges between master host and HMI

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

2.2.5.2 Detailed description of service

The RNIM component is in charge of: providing the services for radio network configuration in the SC (Supervised Configuration), and for PRC (Provisioning Radio Configurations). To achieve theses services, RNIM is split in: rnimsc, which manages the supervised configuration. It is a permanent process. It is launched at startup of the OMC-R, rnimprc, which manages the provisioning configurations. This process is launched by rnimsc, The following figure presents the architecture of RNIM.

MASTER

Q3IM DCNUSM

BSSIM

RNUSM

MFSIM

RNIMPRC

RNIM processes

HMI

DCNUSM

RNUSM

RNIMSC


NAMESERVER

Figure 30 RNIM architecture

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

2.2.6 BSSIM

BSSIM communicates with NEs through X25 (BSC G2) and TCP/IP (A9130 BSC Evolution) BSSIM is in charge of the supervision of the BSC equipment.

2.2.6.1 Architecture The following figure presents the communications between the master host and the HMI for BSSIM.

HMI MASTER/AGENTS

BSSIM

BSSUSM

DCNUSM

MFSUSM

BSSIM BSSIM


BSSUSM DCNUSM MFSUSM

Figure 31 BSSIM exchanges between master host and HMI

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

2.2.6.2 Detailed Description of Service BSSIM is in charge of the supervision of the BSC equipment. BSSIM is launched at BSC-NE declaration. The number of BSSIM instances is the number of BSC-NE declared (one BSC = 1 BSSIM instance). The following figure presents the architecture of BSSIM.

MASTER

BSSUSM

RNIM

DCNUSM

ASIM

MFSUSM

BSSIM

BSSUSM

DCNUSM

MFSUSM

BSSIM BSSIM

BSSCOMM BSSCOMM

BSC BSC BSC


AGENT

BSSCOMM BSSCOMM

BSSIM BSSIM BSSIM

BSC BSC BSC

HMI

Figure 32 BSSIM architecture

2.2.7 MFSIM

MFSIM is in charge of the supervision of the MFS equipment. Architecture: The following figure presents the communications between the master host and the HMI for MFSIM.

HMI MASTER/AGENTS

BSSIM

DCNUSM

MFSUSM BSSIM MFSIM


DCNUSM MFSUSM

Figure 33 MFSIM exchanges between master host and HMI

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.


MFSIM is in charge of the supervision of the MFS equipment. MFSIM is launched at MFS-NE declaration. The number of MFSIM instances is the number of MFS-NE declared (one MFS = 1 MFSIM instance). The following figure presents the architecture of MFSIM.

HMI MASTER

RNIM

DCNUSM

ASIM

MFSUSM

BSSIM

BSC

DCNUSM

MFSUSM BSSIM MFSIM

BSC MFS


AGENT

BSSIM

BSC

BSSIM MFSIM

BSC MFS

Figure 34 MFSIM architecture

2.2.8 OMC-R External Interfaces

OMC-R must provide in addition some external interfaces, in order to allow Post Processing machines to use specific OMC-R data, in required format for further usage. These machines are referred to as ToolChain. In the Appendix, the ToolChain is considered as well. But, 2 cases must be taken into account:

1. Usage of Alcatel delivered machines: NPA, LASER, RNO 2. Usage of other PostProcessing tools coming from other vendors.

In this case, a set of basic external interfaces are granted for customer in order to interface OMC-R with for Non Alcatel products. The following security principle is followed:

- The exchange of information with external users/applications is based on the use of an ftp server and the isolation from the rest of the OMC-R of the exchange area.

- The ftp server is configured and used in such a way that the server itself is relatively protected from classical attacks, and if penetrated or used improperly, will create no significant problem for the rest of the OMC (isolated exchange area).

- The only operations authorized for external users/applications are put/get operations. The following interfaces are provided: NMC / A1353-RA interface: it is a Q3-based external interface to NMCs for real-time network surveillance and discovery. The directory is: /Alcatel/var/share/q3im A1353-RA Configuration I/E (ACIE) interface: it is a ASCII file-based external interface for Configuration data Import/Export. The directory is: /Alcatel/var/share/AFTR/ACIE

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

A1353-RA Frequency Plan modifications I/E (FPIE) interface can be viewed as an add-in layer to the ACIE interface. The directory is: /alcatel/var/share/AFTR/ACIE/ACIE_NLexport_Dir1A1353-RA client nodeIdentifier values I/E (ANIE) ASCII interface: A client nodeIdentifier value is an operator-dependent INTEGER value that can be used by an operator to provide a unique identification of the corresponding resource (defined by a customer's network planning tool). The directory is: /Alcatel/var/share/AFTR/ANIE

A1353-RA Alarm and State Change Export (AASCE) interface: It is a file-based external interface for exporting current alarms (HALD directory) historical alarms (SOCAD directory) and state changes (SCD directory) to external applications. The directory is: /Alcatel/var/share/AFTR/AASCE

Figure 35 AASCE repository

A1353-RA Performance Management export (APME) interface: it is a file-based external interface for exporting data required by performance management post processing applications such as NPA or other Metrica-based tools to be able to retrieve and process the BSS PM result files. The directory is: /Alcatel/var/share/AFTR/APME Obsynt Interface. The OBSYNT-like tool works on a MPM or NPA machine. The output ASCII .csv files are stored in a specific directory and can be retrieved by an external component, for further analysis: /alcatel/var/share/AFTR/APME/OBSYNT.

The directory is: /alcatel/var/share/AFTR/APME/OBSYNT A1353-RA / LASER (ALSR) interface It is a file-based interface for exporting data required by A957-LASER to analyse the network stability and availability. The directory is: /alcatel/var/share/AFTR/LASERA1353-RA AGUE interface. This interface can be considered as an adaptation of the A1353-RA Configuration Import/Export interface (actually the Radio Network Level part of it) The directory is: /Alcatel/var/share/AFTR/AGUE

The A1353-RA ARIE interface The A1353-RA Remove Inventory Export (ARIE) interface is an interface that permits to access to ARIE files located in the A1353-RA File Transfer Repository. The directory is: /alcatel/var/share/AFTR/ARIE

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

3. APPENDIX A (PORTS USAGE IN B9 RELEASE) Assumptions: The informations are stored in following tables in respect of several rules: Informations are split in three domains: OMC, ToolChain and Network Elements (N.E.) By ToolChain are understood the post processing applications which, on their turn, will communicate with OMC-R, as well as each other. As an integrated solution, Alcatel propose several applications: LASER, RNO and NPA. LASER and RNO are hosted by specific machines, different from OMC-R: LASER (on separate WINDOWS OS), RNO (on WINDOWS OS), But, special attention must considered for NPA. There are 2 possible solution NPA (on SOLARIS OS) MPM applications running on OMC-R (Option) So, if MPM is not installed on OMC-R, the Firewall configured on OMC-R site must consider as input only the tables from 3.1. Opposite, if MPM does exists on OMC-R, the Firewall should include also NPA part from 3.2. - For OMC domain, following hosts are considered: Master, Agents, HMIs. In addition other

terminals may be taken into account as options. - In following tables, the notion of Agent is considered as part of OMC-R architecture (see

Figure 3) and explanations following the figure). - In OMC domain, servers may be hosted by: Master, Agents and HMIs. This is explicitely

stated on tables - The information is focused on services impacted by a Security Service. - In some cases services are enabled by default (Status = Enabled) but are not mandatory

(see next). - A service may or may not be mandatory for system functionality. This is specified in the

appropriate column. This means that operator may disable the Not mandatory services without any risks on OMCR functionality. The reason for acting like this may be taken for security purposes. In some cases the impact is obvious (ex: remote access through telnet or rlogin). In other situations, the impact is described on Short Description column.

Ex: If ctxfm is disabled, Citrix clients will not work. - RPC services are presented on separate table because its specificity. - The table does not give any details related with Legato based back-up services as a

documentation describing the configuration of a Firewall is available with Legato product.

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

3.1 OMC

3.1.1 OMC-R System services: Network Service

Short description, Server Location

Server Port / Protocol

Status: En/Dis

Mand Y/N

Client Port

Client Location (Local /Remote)

Httpd Apache web server MASTER (M)

80/tcp En Y Dyn Local and Remote (HMIs)

rpcbind or SUNRPC Server

universal addresses to RPC program number mapper (Port Mapper) MASTER, AGENTS, HMIs

111 /tcp

En (M , A , HMIs)

Y (M, A, HMIs)

Dyn

Remote (Master, Agents, HMI)

Proftpd (through inetd)

Professional configurable, secure file transfer protocol server MASTER, AGENTS,

21/tcp command mode, 20/tcp data transfer, for passive mode: 21/tcp, 39000-40000/tcp check 2.1.2 for further explanations

En (M, A)

Y (M, A)

Dyn Remote (A9130 BSC Evolution, RNO, NPA, LASER, RNP Passive Mode)

Xfs X Window System font server. Used if Xstation added MASTER, AGENTS, HMIs

7100/tcp Dis (M, A, HMI)

N

N

Dyn Remote only if Xstations installed

in.lpd network listening servicefor the BSD print protocol used by OMC when declaring a printer on remote machine via OSM MASTER, AGENTS, HMI

515/tcp En (M)

Dis (A,HMI)

Y (M, A)

N (HMIs)

Dyn Local and Remote (Master, Agents, HMIs)

Dtspcd CDE Subprocess Control Service Needed for CDE windowing environment MASTER, AGENTS, HMIs

6112/tcp En (M, A, HMIs)

YES

Dyn Local and Remote (HMIs)

Sendmail (MTA mode and MSP mode)

Send/receive emails. Running in Daemon mode (listening on 25 tcp port) MASTER, AGENTS, HMI

25,/tcp, alternate port: 587/tcp

En (M, A, HMI)

Y (M)

N (MTA mode on: A, HMIs)

Dyn Local andRemote (Agents, HMIs)

sshd OpenSSH SSH daemon. This daemon is listening for requests coming from ssh

22/tcp En (M, A, HMI)

Y (M, A, HMI)

Dyn Remote (Agents, HMI)

ED06Rel



All r

ights

re

serv

ed. Pa

ssin

g on

and

copy

ing

of th

is

docu

men

t, us

e an

d co

mm

unic

ation

of

its

co

nten

ts

not p

erm

itted

w

ithou

t writ

ten

auth

oriza

tion

from

Al

cate

l.

Network Service

Short description, Server Location

Server Port / Protocol

Status: En/Dis

Mand Y/N

Client Port

Client Location (Local /Remote)

clients MASTER, AGENTS, HMIs

slapd LDAP service MASTER only

389, tcp En Y Dyn Local and Remote (HMI, Agents)

ctxfm Citrix Metaframe Server (option) MASTER, HMI

1494/tcp (if lic. Serv. exists) else: Dyn

En (M, HMI)

N

ICA browser port: Dyn

Remote (Citrix client)

CtxXtw

Citrix sess manager (child process of ctxfm). If UNIX is specified, this means Listen on a UNIX socket (/tmp/.X11-unix/X). If UNIX is not specified, a slower TCP socket is used for communication (TCP port 6000+) - also using up additional resources. MASTER, HMI

6010-6030/tcp 1494/tcp

En (M, HMI) N Dyn Remote (Citrix client)

ctxmld The Citrix XML Service is included automatically and the XML process starts automatically. If you create a server farm, the XML Service runs on eac

omc-r toolchain and ne ip ports usage b9 ed06.pdf

Documents

usage of ports

omcr network

ed06rel omcr

ip ports usage release

omcr application services

usage of firewalls

network elements

jaaa dszza