v18 omc-r engineering rules (2008).pdf

7/22/2019 V18 OMC-R Engineering Rules (2008).pdf

1/106

PE/DCL/DD/014282

GSM BSS 850/900/1800/1900 V18 OMC-REngineering Rules

Standard 04.02 October 2008

Whats inside...

Product Overview

OMC-R Server Engineering Consideration

Client, X-terminal and RACE Engineering Considerations

Preventive Backup and Disaster Recovery Plan

OMC-R Solution Architecture and Interfaces

Bandwidth Requirements

Hardware Specifications

DCN Hardware Specifications & RecommendationsAppendix A: Software Load line-up

Appendix B: OMC-R LAN Engineering


2/106

OMC-R Engineering Rules PE/DCL/DD/01428

Copyright 2008Nortel, All Rights Reserved

The information contained herein is the property of Nortel and is strictly confidential. Except as expressly

authorized in writing by Nortel, the holder shall keep all information contained herein confidential, shall

disclose the information only to its employees with a need to know, and shall protect the information, in whol

or in part, from disclosure and dissemination to third parties with the same degree of care it uses to protect it

own confidential information, but with no less than reasonable care. Except as expressly authorized in writinby Nortel, the holder is granted no rights to use the information contained herein.

Nortel, the Nortel logo, the Globemark are trademarks of Nortel.

SOLARIS, is a trademark of Sun Microsystems Inc. UNIX is a trademark licensed exclusively through X/Ope

Company Ltd. NIMS-PrOptima is a trademark of Mycom International.

Printed in Canada


3/106

Publication history i


Publication history

October 2008

Standard version 04.02

Version after internal IPOR 390810 review.September 2008

Preliminary version 04.01

Applicable to GSM BSS V18 release.

June 2008


Removed all references to the Ultra 5 workstation as it is not supported in v17 release.

March 2008

Standard version 03.03Updated to Standard Version. Added 1800Mhz cpu to SF V890 configuration.

September 2007


Removal of the WQA Server and Application Engineering guidelines section as WQA isoffered uniquely as part of a services offering

July 2007


Applicable to GSM BSS V17 release. BR+21 compliant.

October 2006


Addition of the WQA Server and Application Engineering guidelines section

May 2006


Applicable to GSM BSS V16 release

March 2006


Add engineering rules for concurrent activation of Call Path Trace, Call Drop Analysis anRadio Measurement Distribution

October 2005


Correct and update list of OEM software is installed on an OMC-R server in AppendiA: Software Load line-up document section


4/106

iv Publication history

OMC-R

Rewrite Q3 on Ethernet link via TCP/IP in OMC-R Solution Architecture and Interfacesdocument section

Add note about the need to provision 2 additional IP addresses for the BSCe3 CEMboards in OMC-R Solution Architecture and Interfaces document section

July 2005


Precise nominal hardware configuration with regards to OMC-R releases in HardwareSpecifications & Internal Redundancy Strategy document section

June 2005


Add SIE OMC-R OMC Administration, PE/OMC/DD/000182 in Reference documentsection

Clarify OMC-R Capacity Configuration naming and point to OMC-R Capacityparameters in OMC-R Server Engineering Considerations section

Clarify and update Dimensioning of Call Trace and Call Path Trace in OMC-R Server

Engineering Considerations section Change the number of SDOs supported back to 5 as it is the contractually agreed value

in NIMS-PrOptima for GSM BSS Server Engineering Considerations

Pull out the NTP time synchronization section and remove the info about the dataavailability KPI in NIMS-PrOptima for GSM BSS Server Engineering Considerationssection

Clarify maximum of simultaneous Graphic MMI in Client, X-terminal and RACEEngineering Considerations section

Clarify possibility to share a single switch for multiple PCUSN locally connected to theOMC-R server in OMC-R Solution Architecture and Interfaces section

March 2005



5/106

Table of Contents


Table of Contents

Table of Contents v

About this document vii

Audience for this document - vii

Scope - viiWhats new in this release - vii

Reference documents ix

References - ix

Product Overview 1 - 1

OMC-R interconnection with the GSM/GPRS network 1 - 1

OMC-R Architecture and Functions 1 - 2

Hardware Platform 1 - 4

New Items in the Release 1 - 4

OMC-R Server Engineering Considerations 2 - 1OMC-R architecture 2 - 1

OMC-R Capacity 2 - 2

Configuration Management 2 - 3

Fault Management 2 - 4

Performance Management 2 - 4

Security Management 2 - 7

Redundancy 2 - 8

Purge 2 - 8

Q3 (CMIP) interface 2 - 8

SDO server 2 - 9

PCUOAM server 2 - 9

Client, X-terminal and RACE Engineering Considerations 3 - 1

OMC-R Client 3 - 1

CIUS (centralized installation upgrade server) 3 - 2

X-terminal 3 - 3

RACE 3 - 6

Client workstations allowed configurations 3 - 8

Number and type of end-user connections to OMC-R 3 - 8

Preventive Backup and Disaster Recovery Plan 4 - 1

Preventive backup 4 - 1Backup media or server 4 - 1

Disaster Recovery Plan 4 - 2

OMC-R Solution Architecture and Interfaces 5 - 1

OMC-R Solution Architecture 5 - 1

OAM Interfaces 5 - 3


6/106

vi Table of Contents

OMC-R

OMC-R PCUSN Connection 5 - 5

OMC-R BSC 3000 Interface 5 - 8

OMC-R to NMS interface 5 - 12

Bandwidth Requirements 6 - 1

OMC-R LAN 6 - 1

OMC-R - Client bandwidth requirements 6 - 1

STATX Workstation - X-terminal bandwidth requirements 6 - 1

OMC to BSC bandwidth requirements 6 - 2

BSC to OMC bandwidth requirements 6 - 3

OMC-NMS bandwidth requirements 6 - 4

OMC - SDO bandwidth requirements 6 - 4

PCUOAM - OMC bandwidth requirements 6 - 5

Hardware Specifications 7 - 1

Supported configurations 7 - 1

Detailed hardware specifications 7 - 3

Sun Server Hardware 7 - 8

DCN Hardware Specifications & Recommendations 8 - 1

LAN switching device 8 - 1

WAN routing switch 8 - 2

Terminal Server 8 - 11

Console Server 8 - 14

Alarm Relay Box 8 - 16

RS-422/RS232 Interface Converter 8 - 20

Appendix A: Software Load line-up 9 - 1

Third Party software Load line-up 9 - 1

Appendix B: OMC-R LAN Engineering 10 - 1

IP Addresses planning 10 - 1

IPMP Implementation 10 - 3

10 - 5

T5140 IP Adrress Planning 10 - 5

List of Terms 11 - 1


7/106

About this document v


About this document

This document is intended for Network Designers and Application Engineers who performnetwork dimensioning tasks. The document provides all the required information forincluding OMC-R in GSM 850/900/1800/1900 networks.

Audience for this document

This OMC-R Engineering Information has been specifically prepared for the followingaudience:

Network Engineers

Installation Engineers

Network & System administrators

Network Architects

Scope

This document applies to the version 18 of OMC-R intended to manage the V18 BSSrelease and to manage temporarily the previous BSS releases to allow release upgradetransitions. This version of OMC-R supports the introduction of the new server T5140 witthe disk array device ST2510.

Whats new in this release

Introductions of V18 features with engineering impacts on the OMC-R solution

29389 Solaris 10 support

31737 New hardware introduction

32092 Removal of X25 and OSI software packages

34153-34157 Windows Vista compliancy for select client applications

34453 File System backup to tape

34497 BTS inventory

34535 Addition of TCU to multiple BSCs in parallel upgrade

34604 MDM 16.2 introduction and support

34617 End of support of synchronous PCUSN Data TRAU frame

34618 Support of NFS backups to non-local drives

34840 OMC-R upgrade enhancements


8/106

viii About this document

OMC-R


9/106

Reference documents i


Reference documents

The documents listed below contain all references used herein. Additional updates andcorrections can be found in the OMC-R Release Notes

References[R1] V18.0 Release Documentation List, PE/DCL/APP/019983

[R2] V18.0 Feature Planning Guide, PE/BSS/APP/019562

[R3] V18.0 Release Reference Book, PE/SYS/DPL/019036

[R4] V18.0 External Release Definition, PE/BSS/DJD/022189

[R5] OMC-R CUSTOMER PRODUCT OVERVIEW, PE/OMC/DD/000170

[R6] NIMS -PrOptima Customer Product Overview, PRO/MKT/SYD/NOR/008

[R7] SFS OMC-R DATA SERVER, PE/OMC/DD/000103[R8] OMC-R PRODUCT CATALOGUE, PE/OMC/INF/0066

[R9] OMC-R Modelled Offer Provisioning Guide, to be defined

[R10] W-NMS OAM Engineering guide, NTP 450-3101-638

[R11] Centralized Installation and upgrade service, PE/SYS/DD/006464

[R12] SIE OMC-R Web Access: RACE, PE/OMP/DD/0045

[R13] SIE OMC-R DATA SERVER, PE/OMC/DD/102

[R14] SIE OMC-R OMC Administration, PE/OMC/DD/000182

[R15] OMC-R CUSTOMIZATION PARAMETER NOTEBOOK,DS/OMC/APP/000019

[R16] GSM OAM SYSTEM SPECIFICATION, Firewall Support Information,PE/OMC/DD/004749

[R17] OMC-R OEM EQUIPMENT INSTALLATION PROCEDURE,DS/OMC/APP/000001

[R18] OMC-R VERSION UPGRADE PROCEDURE, DS/OMC/APP/000002

[R19] OMC-R SOFTWARE INSTALLATION PROCEDURE, DS/OMC/APP/00000

[R20] SDO INSTALLATION PROCEDURE, DS/OMC/APP/000008

[R21] OMC-R PREVENTIVE MAINTENANCE BACKUP, DS/OMC/APP/000016

[R22] OMC-R SYSTEM GLOBAL RESTORATION, DS/OMC/APP/000017

[R23] MULTIOMC WORKSTATION CONFIGURATION, DS/OMC/APP/000023


10/106

x Reference documents

OMC-R

[R24] OMC-R MAINTENANCE CHECKS, DS/OMC/APP/000024

[R25] OMC-R STATIONS MOVING, DS/OMC/APP/000032

[R26] OMC-R MULTI-MMI DISPLAY CONFIGURATION, DS/OMC/APP/000033

[R27] OMC-R CAPACITY INCREASE PROCEDURE, DS/OMC/APP/0000037

[R28] OMC-R MONOBOX PREVENTIVE MAINTENANCE BACKUP,DS/OMC/APP/000043

[R29] OMC-R MONOBOX SYSTEM GLOBAL RESTORATION,DS/OMC/APP/000044

[R30] COLD REDUNDANCY / DISASTER PLAN PROCEDURE,DS/OMC/APP/008020


11/106

Product Overview 1-


Product Overview 1

The OMC-R is the Operation and Maintenance Center of the NORTEL GSM Base Statiosub-system (BSS). It is at a remote location where operations and maintenance functionsfor the network radio sub-system equipment (BSC, TCU, BTSs) attached to the OMC-R

are centralized. The BTSs and TCU are managed from the OMC-R through the BSC towhich they are connected. In case of an additional GPRS service, the OMC-R provides alsa centralized management of the Nortel manufactured PCUs.

The OMC-S/CEM or W-NMS OAM solutions (not described in this documentation)manage the Nortel GSM Network Switching Subsystem (NSS).

The OMC-D or W-NMS OAM solutions (not described in this documentation) solutionsmanage the Nortel General Packet Radio Service core Subsystem (GPRS core).

The CT2000 (not described in this documentation) offers a centralized configuration ofentire Nortel Networks BSS including multiple OMC-Rs, as well as a centralized view o

all BSS networks parameters.OMC-R interconnection with the GSM/GPRS network

The different communication links between the OMC-R and the GSM network equipmenfollow:

The OMC-R/BSC interconnection.This links the OMC-R to the BSCs it controls. There armultiple ways to establish this link using a PSPDN network, the GSM A interface or privatinterconnection solutions.

The OMC-R/PCUSN interconnection.This links the OMC-R to the PCUSNs it controls.There are multiple ways to establish this link using a PSPDN network, the GSM A interfac

or private interconnection solutions.The OMC-R/NMS link. This links the OMC-R to one or more NMSs, which is a centralnetwork management system. There are two ways to establish this link: through the Q3interface if the NMS provides this interface or through an ASCII type interface (also knowas: non-Q3 interface)

The Remote Access links. These links are used to administrate the OMC-R from remotelocations. They can be linked to the OMC-R central site through a PSTN connection orthrough private interconnection solutions.

The following drawing shows the OMC-R within a GSM network.


12/106

1-2 Product Overview

OMC-R

Figure 1-1: OMC-R interconnection with a GSM/GPRS network

OMC-R Architecture and Functions

Network Operating Reliability

The OMC-R is the supervision system of the BSS. However, if the OMC-R fails this doesnot mean that the GSM network radio sub-system fails. If there is an OMC-R failure, theGSM network keeps working. The BSS stores supervision data, but it has a limited capacity(3 days). The only impact of an OMC-R failure is a temporary loss of supervision visibility

on the network (during the failure) and a possible loss of supervision data.

Architecture

The OMC-R is composed of two logical entities which are part of the same physicalequipment:

SIG

MSC

TCU

BSC PCUSN SGSN GGSNBTS

OMC-RServer

OMC-R clientworkstation

OMC-RDATAEXP

workstation

CT2000

Agprs

A

Ater

Gb Gn

Gs

Abis

WAN/LANWAN/LAN

Gr

BSS Subsystem

WPS

SIG

MSC

TCU

BSC PCUSN SGSN GGSNBTS

OMC-RServer

OMC-R clientworkstation

OMC-RDATAEXP

workstation

CT2000

Agprs

A

Ater

Gb Gn

Gs

Abis

WAN/LANWAN/LAN

Gr

BSS Subsystem

WPS


13/106

Product Overview 1-


One Mediation Device (MD) function to manage the BSC and PCUSN networkelements. The MD handles mediation between the standard Q3 interface and theOMC-R/BSC & OMC-R/PCUSN interfaces. It converts Q3 requests into OMC-R/BSCOMC-R/& PCUSN interfaces requests and BSS spontaneous event reports into Q3notifications.

One manager (MNGR) function to interface with the OMC workstations.

The Q3 interface is used as the inner OMN standard interface as specified in the TMNmodel. It enables communication between the MD-R and remote NMS (also known asExternal Manager). The MNGR and MD-R also communicate internally through the Q3interface.

Figure 1-2: OMC-R software architecture

OMC-R External Functions

OMC-R external functions correspond to the four functional areas defined in the TMNprinciples of the ITU-T M.3010 recommendation.

These are accessible to the operating staff through the local HMI or remote HMI.

Configuration management

This function handles control and synchronization of BSS equipment resources andconfigures BSS objects.


14/106


OMC-R

Fault management

This functions manages and stores the flow of BSS information concerning BSSoperational anomalies and breakdowns and the associated return to work procedure. TheOMC-R furnishes this information to the operating staff through the HMI.

Performance (and Observation) management

This function handles the Call monitoring feature and all the collecting and reportingfunctions of the performance counters.

Security management

For OMC-R external functions, security management refers to access security managementfor the OMC-R operating staff and not to management of the GSM network security fromthe OMC-R.

OMC-R Internal Functions

Administration and Communication management

This required system function is available to the end user. Administration management

handles OMC-R maintenance and operating functions through local HMI, backup storageof data files, power on and off, and command files management.

Communication management handles data file transfers, communication with thesupervised systems, and management of the Q3 interface.

Hardware Platform

The OMC-R system is composed of workstations and servers. It is made up of commercialthird party equipment (computers, communication equipment, etc.) that runs industrystandard and Nortel Networks developed proprietary software.

The Network Management functions are hosted by Sun servers; the OMC-R Server for the

Network Management platform, Fault Management, Configuration Management andPerformance Collection functions.

These servers are based on Sun servers with or without external storage arrays. The clientworkstations supported for management of the Wireless network are Sun workstations.

New Items in the Release

The OMC-R v18 release introduces and supports a new type of hardware, Suns T5140server and Sun StorageTek 2510 disk array. The following upgrade paths to the T5140server are supported:

SunFire V880/T3 v16 -> T5140/ST2510 v18

SunFire V880/T3 v17 -> T5140/ST2510 v18

Also, the v18 OMC-R will no longer support the BSC 2G, therefore the OMC-R will notrequire OSI and X25 software packages.


15/106

Product Overview 1-


A major feature in the v18 release is Abis over IP; this feature consists in enabling packebased backhaul transmission as an alternative to TDM-based E1/T1 links, on the BSC'BTAbis interface. All information on the Abis over IP feature and its impact to engineeringwill be covered in an ABIS over IP specific document; this document will not cover thisfeature.


16/106


OMC-R


17/106

OMC-R Server Engineering Considerations 2-


OMC-R Server Engineering Considerations 2

OMC-R architecture

The OMCR includes two entities, a local manager and an agent. The two entities

communicate across the Q3 interface.The agent, called the MD, supports the mediation function. It converts Q3 format messageinto requests in a standard format and forwards them to the OMCR/BSC &OMCR/PCUSN interface. Conversely, it converts messages coming from the BSS into Qformat messages.

Figure 2-1: OMC-R General Architecture

The OMCR provides the following functions:

Man Machine Interface (MMI)

Communication Management

Configuration Management

Fault Management

Performance Collection

Security Management

Common Functions

OMC-R General Architecture

Q3 InterfaceQ3 Interface

External Manager

(OSS)

BSS Vn-2BDA

MOD

Vn-2

BSS Vn-1BDA

MODVn-1

BSS VnBDA

MOD

Vn

OMC-R Manager aka local manager Part (Vn)

OMC-R Agent aka MD Part (Vn) BDE

BDA: Applicative Data Base, the Database of the BSC

BDE: Management Database, the DB of the OMC

MOD: Managed Object Dictionary it is the BSS-OMC interface definition; as such, it is versioned.


18/106

2-2 OMC-R Server Engineering Considerations

OMC-R

RACE management

OMCR databases

GPRS management

OMC-R Capacity

The OMC-R is able to handle:

up to 40 BSC / 4800 cells for the Enhanced Capacity configuration option with a SunFire V890 based OMC-R and the T5140 based server. This configuration is known asthe Ultra High Capacity (UHC) configuration.

up to 40 BSC / 3200 cells for the Enhanced Capacity configuration option with a SunFire V880. This configuration is also known as the Very High Capacity (VHC)configuration.

up to 30 BSC / 2400 cells for the Basic Capacity configuration. The Basic Capacityconfiguration corresponds to the High Capacity (HC) configuration.

The OMC-R is by default configured with the Basic Capacity configuration. To increasethe OMC-R capacity from Basic to Enhanced Capacity, one must first verify that the

OMC-R server is compliant with OMC-R very high capacity hardware requirements. Theenhanced configuration cannot be reached with all supported OMC-R server hardwareconfigurations. See "Hardware Specifications" section.

Refer to SIE OMC-R OMC Administration, PE/OMC/DD/000182 for the appropriatevalues of the OMC-R configuration files variables related to the OMC-R Capacity.

Number of managed objects

The capacity limits for OMC-R exploitation depend on the number of managed objects andnot the volume of supervised traffic. The following table shows the capacity limits for theOMC-R in V18 software release. The classes in bold are the most dimensioning factor for

the OMC-R. Possibility to override these limits can be envisioned through an engineeringservice.


19/106



Table 2-1: OMC-R object management capacities

Configuration ManagementBSS Software File Transfer

The OMC-R can simultaneously transfer a BSS software version (EFT) up to 10 differenBSCs.

Managed Objects Description Basic

Capacity

Enhanced

Capacity

for SF V880

based

OMC-R

Enhanced

Capacity for

SF V890/

T5140 based

OMC-R

Bts (cells) maximum number of cells per OMC-R 2400 3200 4800

Bsc maximum number of BSCs perOMC-R

30 40 40

BtsSiteManager maximum number of sites per OMC-R 2400 3200 4800

AdjacentCellHandover

defines a neighbor cell of a serving cellfor handover management purposes

76800 102400 153600

AdjacentCellReselection

defines reselection managementparameters for a serving cell

76800 102400 153600

Channel max number of channels (TCH, etc.) 76800 153600 230400

FrequencyHoppingSystem

max number offrequencyHoppingSystem objects(Hopping Seq Nb, Mob. All.)

9600 19200 28800

LapdLink max number of LAPD objects 22380 44960 62400

PcmCircuit(BSC2G/BSC3000)

max number of pcmCircuit objects 3120/9000(T1) or7740 (E1)

4160 /12000 (T1)or 10320(E1)

4160 / 12000(T1) or 10320(E1)

Pcu max number of PCUSN 30 40 40

Transceiver maximum number of TRX per OMC-R 9600 19200 28800

Transcoder_2G(BSC2G/BSC3000)

Max number of TCU2G 420/960 560/1280 560/1280

Transcoder_e3(BSC 3000)

Max number of TCUe3 60 80 80


20/106


OMC-R

The OMC-R can simultaneously build the BDA of up to 10 different BSCs, whatever thebuild type is (on-line, off-line). Also, it can simultaneously audit the BDA of up to 10different BSCs.

Scope and Filter Limits

The depth limit for a scope GET, SET or ACTION command is limited to 3.

There is no limit in depth for a scope DELETE command

Fault Management

Duration of Notification Data Storage

The Mediation Part stores the notification log of the current day and the last 3 days(D_MD_CONSULT_MAX).

The Manager part of the OMC-R stores the fault data of the current day and the last 7 days(D_MGR_CONSULT_MAX).

Number and Duration of Storage for Alarms

The maximum number of outstanding alarms (N_ALARM_MAX) managed at theManager part of the OMC-R is 10000.

The OMC-R stores the alarm history of the current day and the last 7 days(D_MGR_CONSULT_MAX).

The OMC-R can simultaneously manage 40 instances of alarm criteria

Performance Management

Observation Reporting Period

The BSC observation granularity periods (T2) are:

15, 30 or 60 minutes for Fast Statistic Observations

1 day for General Statistic Observations

1, 2, 3, 4 or 5 minutes for Real Time Observations

15 minutes for Diagnostic Observations 1

5, 10, 15, 30 or 60 minutes for temporary Observations

Note: PCUSN counters are NOT available at the OMC-R Performance Monitorwindow level and they are not available to External Managers via Q3 PM interface.However, PCUSN counters are available at the SDO level (observation files).

The value of T2 can be affected given the OMC-R server configuration, number of BSCmanaged, number of cells per BSC and number of neighbors (adjacentCellHandover) perBSC.

1Only available for BSC 3000: T2 ODIAG can be set to 5 mn only if one BTS is in mdOb-

jectList or if its set to 10 mn and there are less than 3 BTS


21/106



These limitations are linked to the number of cells handled per BSC and the number ofneighbors (adjacentCellHandover) per cell. According to these values the minimum T2value for Fast Statistic Observation cannot always be 15mn. These limitations can appeaeven with mixed BSC 2G/BSC 3000 in the OMC-R.

Nature and duration of Observation Data Storage

The Fast Statistic Observation, General Statistic Observation, Diagnostic Observation anTemporary Observation logs are stored in the OMC-R Mediation Part and Manager Part.

The Mediation Part stores the observation logs of the current day and the last 3 days(D_MD_CONSULT_MAX).

The Manager part of the OMC-R stores the observation files of the current day and the las7 days (D_MGR_CONSULT_MAX).

BSC Call Monitoring Observation

The OMC can simultaneously manage the following number of Call Trace (traceControland Call Path Trace (callPathTrace) objects classes:

Table 2-2: BSC Call monitoring capacity

Call Tracing

This function is the GSM 12.08 trace facility of the BSC. It is used to trace the activitiesassociated to specific communications (identified by IMSI or IMEI) in a BSC and totransfer this data to the associated OMC-R. This function is invoked by MSC. Thefollowing considerations apply:

No more than one call trace object can be created per BSC.

Only one Call Trace session per BSC can be activated.

The OMC-R can process at any given time the traces of 10 IMSIs, in radio or othersmodes, per day, in the whole BSS network it manages.

It is assumed that each IMSI performs 90 communications per day of 2 minutes duratio

with 1 handovers, on an average, when the traces are done in radio or others modes.Call Path Tracing

This function enables the BSC to trace the communication activities on specific devices othe BSC (CICs, TRX or cells). This function is initiated at the OMC-R level. The followinconsiderations apply:

No more than one call path trace object can be created per BSC.

ObjectsBasic

Capacity

Enhanced

Capacity

traceControl 30 40

callPathTrace 30 40


22/106


OMC-R

Only one Call Path Trace session per BSC can be activated, monitoring 36communications in parallel. It is assumed that communications are, on average, 2minutes long with 2 handovers.

The OMC-R can handle 6 or 8 active Call Path Trace sessions simultaneously(N_CPT_MAX) respectively for basic (HC) and enhanced (VHC/UHC) capacityconfigurations.

The total duration of the call path trace session (H_CPT_DURATION_MAX)determines the amount of CPT Data collected and therefore will be limited by the relatedOMC-R server & SDO server partitions size.

With allowing only one day of storage of CPT data in the SDO, the maximum active CPTduration (hours) for 8 BSCs monitoring 36 parallel communications with T2 at 30 minutesis limited to 10 hours.

For data transfer, FTAM is used for non-priority traces, and event reports are used forpriority traces.

Duration of Trace Data Storage

The H_CPT_DURATION_MAX is available for 4 days (current + 3). If theH_CPT_DURATION_MAX is used on one day, backup of the CPT data must be done tofree disk space for the next day.

The storage duration of the C[P]T data cannot therefore be guaranteed. However, and aslong as the H_CPT_DURATION_MAX is not reached, the storage duration is more thanone day and allows the user to retrieve these data.

Call Drop Analysis

This function enables the operator to analyze the call drops and thus optimize its RFnetwork based on the drop call causes.

This function is activated directly at the OMC-R level so as to retrieve the call drop datafrom the BSC. When activated, the feature allows the BSC to ask for BTS data when a dropis detected by the BSC, to store BTS and BSC data on BSC disk and, when deactivated, towarn the OMC-R that data are available. The CDA files are eventually stored on the SDOin XML format to be made available for an external post-processing tool.

Distributions on Radio measurements

This function helps the operator monitor his network by providing for the TRX of givencells and on a periodic time frame, the distribution at TDMA level of some measurementsdone on radio interface.

The activation of distribution retrieval is settable on a cell basis at the OMC-R level. Thedistributions are stored on the BSC on a cell basis and then automatically uploaded by theOMC-R via FTAM. The distributions files are eventually stored on the SDO in XMLformat to be made available for an external post-processing tool.


23/106



Concurrent activation of Call Path Trace, Call Drop Analysis and Radio

Measurement Distribution

The activation of the Call Drop Analysis feature and - in a much lesser extent - theactivation of the Radio Measurement Distribution feature both concur significantly toincrease the amount of data stored in the OMC and SDO disks. Therefore there are potentiarestriction in using those functions in parallel with the Call Path Tracing activity to avoidto reach the disk used space threshold monitored by the OMC-R purge defense mechanism

With the Call Drop Analysis activated, activating thereafter the Call Path Tracing willpotentially launch the OMC-R defense mechanism after a given period of time which widepend on the OMC-R hardware configuration. Otherwise, there is no restriction inactivating simultaneously Radio Measurement Distribution and Call Path Tracing.

With the following settings on those different functions that are activated simultaneously

Call Drop Analysis typically featuring 100 drop calls per cell for potentially 3200 celland assuming the data are kept on the SDO during 4 days,

Radio Measurement Distribution monitoring 3200 cells per day and assuming the dat

are kept on the SDO during 4 days,

Call Path Trace initiated for 8 BSCs monitoring 36 parallel communications with theBSC observation granularity period (T2) set at 30 minutes,

we can estimate that maximum active CPT duration (hours) for 8 BSCs monitoring 36parallel communications with T2 at 30 minutes is limited to 10 hours.

Within this duration, the SDO disk used is over 70% for a SFV880 with T3 IntegratedOMC-R.

If CPT exceeds maximum CPT duration, the OMC data will be either purged (if the CPTdatabase contains data older than the current day) and/or recording will be stopped (if th

CPT database contains only current day data). If CPT exceeds 10 hours, old SDO data wilbe purged on SDO based on U5 or SB150.

With an SDO device of 27 or 36GB, i.e. either dedicated SDO running on a U5 or SB150with Multipack or integrated in a SV880 with T3s, the SDO used disk space will suggest tonly activate those features in parallel with precaution and requires daily backup of CPTdata to prevent from having the oldest archive to be purged immediately at the next sessioof CDA or CPT.

With an SDO device of 90GB or more, i.e. either dedicated SDO running on a SB1500 ointegrated in a SFV890, the CDA, RMD and CPT can be activated in parallel. However wneed to remind you that the limitations described before on CPT when running alone stil

applies, but in that case it is not the SDO device which will be the limiting factor, butinstead the OMC Data partition size

Security Management

The number of user profiles that can be created in the OMC-R is up to 250.


24/106


OMC-R

Redundancy

The OMC R secures the storing of dynamic data in mirrored file systems that are identicalfiles (or identical Data Base tables) on two separate disk units.

Moreover, in SFV880 Integrated and SFV890 Integrated HDI, system disks and OMC-Rstatic data disks are also mirrored.

PurgeThree mechanisms are available at OMC-R level to purge the old data.

The first consists in automatic daily deleting the old data in order to avoid the saturation ofthe disks. The storage duration is defined in previous sections. This mechanism does notrequire any operator action.

The second is a defense mechanism used to delete automatically the oldest data when afilling threshold for any OMC-R partition is reached. This mechanism does not require anyoperator action.

The third mechanism is provided to avoid the saturation of the Call Trace and Call Path

Trace partitions (data base and ASN.1 files, but not the log files). The operator has thepossibility to purge the current day or any day available at OMC-R level according to thestorage duration of the Call Trace, Call Path Trace information.

Q3 (CMIP) interface

The Q3 interface is based on CMIP, FTAM, ACSE protocols. The OMC-R cansimultaneously manage on its Q3 interface:

transactional and an event reporting data flow based on CMIP with up to 8 CMISEcommand every second

file transfer data flow based on FTAM

The transport layer used for the OMC-R Q3 interface is either X.25 or TCP/IP.

Event report

Event reporting throughput is caused by Fault Management event reports, PerformanceManagement event reports, Call[[Path]Trace event reports and transactions entailing anotification (attribute value change, object creation, object deletion). We assume that thislast point corresponds to 25% of the transactional throughput

The mediation part of the OMC-R may support up to 3 managers, including the localmanager in the OMC-R, which supports the manager functions and the man-machineinterface. As a matter of fact, an OMC-R can be connected to a maximum of 2 NMS

simultaneously.The mediation part's managed objects and resources cannot be dedicated to a manager.Therefore a consistent management of the OMC-R (Mediation part) is supposed to beperformed by the manager(s).


25/106



To avoid the congestion of the OMC-R during a load of notifications, each externalmanager shall be able to acknowledge at least 16 notifications per second and per OMC-Rin average during a day on the Q3 interface. In the same way during scope/filteredoperations, the external manager shall be able to receive 4 up to 16 linked responses persecond and per OMC-R in average during a day

SDO server

The SDO allows to get the OMC-R data records and radio network configurationparameters in an ASCII readable format for peripheral OMC applications (which may gethem using 'rcp' or 'ftp' Unix commands).

Starting BSS v16.0, the observation reports available from the SDO (Nortel OMC-R DatServer) are compressed when older than one day. The directories which store observationreport files, and have a day tag different from current day are arranged into a singledestination file (using tar command), then the destination file is compressed (using gzipcommand, Standard RFC 1952). At the end, original data files are deleted. There arepotential impacts on the 3rd Party Post Processing tools as if the file retrieval is interruptefor some time (in case of OAM link failure, for instance), file compression will have been

applied by the SDO. In this case, compressed files will have to be retrieved (instead ofregular ones) and uncompressed before being processed.

Today, NMS for Performance Management (such as METRICA) use SDO data files asinputs (observation files).

With the Integrated OMC-R Server configuration, the SDO function is part of the OMC-Rserver with the same level of performance. For legacy mono or dual OMC-R serverconfiguration, the SDO function is hosted on a local (connected to the same LAN as theOMC-R server) or remote (connected to the OMC-R server via an XLAN) workstation.

PCUOAM server

The MDM software is responsible for managing the PCUSN hardware that is part of GPRSnetwork. Connected to MDM, then OMC-R processes will be providing PCUSN alarms tthe OMC-R MMI, and transferring PCUSN counters data from PCUSN to OMC-R SDOThe PCUSN counters are not displayed at the OMC-R MMI.

With the Integrated OMC-R Server configuration, the PCUOAM function is part of theOMC-R server. For legacy OMC-R server configuration, the PCUOAM function is hosteon a local (connected to the same LAN as the OMC-R server) or remote (connected to thOMC-R server via an XLAN) workstation.

The PCUSN per OMC-R limit is the maximum number of BSC an OMC-R can manage.


26/106


OMC-R


27/106

Client, X-terminal and RACE Engineering Considerations 3-


Client, X-terminal and RACE EngineeringConsiderations 3

The OMC-R Client software application can only be hosted on Unix workstation. But it i

also possible to emulate multiple client sessions using an X-Window terminal launchedfrom a Unix workstation local to the OMC-R server as well as launched from the IntegrateOMC-R server itself. Besides The Remote ACcess Equipment application allows end-userto interact with the OMC-R application from a PC running an Internet browser to performday-to-day operations, curative maintenance from a remote site.

OMC-R Client

The nominal OMC-R client is hosted on a Unix workstation which can be local (connecteto the same LAN as the active server) or on a remote (connected to the active server via anXLAN).

Table 3-1: OMC-R client capacity

Session windows

During a user session on a workstation, the number of windows of various types that canbe opened simultaneously is limited.

The performance of the OMC-R system is guaranteed under the following conditions: maximum of simultaneously opened or iconed windows = 10

maximum (Current alarm list + Notification windows + State Change window +OMC-R browsers + Topological view) opened or iconed = 5

The Client workstation allows since release V15.1R the use of a double screen display tooptimize Windows management, for example by having configuration management andperformance management windows opened on one screen, and Fault management windowopened on a second screen. To benefit from this feature also implies to have a secondgraphic card installed on the workstation.

Man Machine interface

The whole users activity can be:

on an average: 1 MMI unitary command each second for the whole set of users.

on a maximum: 8 MMI unitary commands each second for the whole set of users, durin3 hours maximum.

The average rate must not be exceeded on a 24 hours period.

Server configuration SFV880 SFV890/T5140

Number of cumulated OMC-R Client GraphicMMI (OMC-R workstations or X terminals)

16 40


28/106

3-2 Client, X-terminal and RACE Engineering Considerations

OMC-R

A MMI unitary command is not a "& filter" command, nor a "run command file" command.A "scope & filter" command is counted as N unitary commands, where N is the number ofobject instances in the scope. A command file is counted as N unitary commands where Nis the number of unitary commands in the command file

Multi OMC-R client workstation

A multi OMC-R client workstation is able to connect alternatively to several OMC-Rs, i.e.one after the other. When connected to a remote OMC-R, nothing distinguish thisworkstation running the MmiKernel and MmiGraphic binary from a local workstation ofthe remote OMC-R.

Other OMC-R workstation functional roles

The primary role of the client workstation is run the client of the OMC-R client application,but the client workstation hardware can also combine or be dedicated to more specificactivities

Centralized installation upgrade server (CIUS)

X terminal client

RACE application server

SDO workstation for legacy OMC-R configuration

PCUOAM server for legacy OMC-R configuration

CIUS (centralized installation upgrade server)

Centralized Installation & Upgrade Services is based on SUN Technologies (Jumpstart,Live Upgrade and Flash Archive) which facilitate installation and upgrade of Sun Solarismachine by automating (Jumpstart), by performing Operating System Upgrade On-Line(LiveUpgrade) and by speeding-up installation and upgrade phase (Flash Archive).Coupled with GUI sequencer this feature offers a full "hands free" efficient and automaticinstallation and upgrade package.

This service is made up of several components:

Centralized Graphical Sequencer which allows to play remotely on each machinebelonging to one OMC-R installation and upgrade steps. This Graphical Sequencerrealize on unitary functionalities (Capture of data mandatory for Installation/Upgrade,play scenarios of Install/Upgrade)

Jumpstart Service: this SUN technology allow to install Operating System from scratchremotely and automatically

LiveUpgrade Service: this technology available starting with Solaris 8 allows to Installa machine but without having to stop it at all. This technology is partially provided bySUN but equivalent functionality will also be implemented into OMC-R installation andconfiguration tools

Flash Archive: this SUN technology only available starting Solaris 8 allows to reducedramatically Jumpstart or LiveUpgrade Operating and 3rd parties software installationby using some Archive produced during previous installation.


29/106



The CIUS is installed on an OMC-R local workstation with a minimum of 20GB internahard disk. On the CIUS workstation, an internal DVD-ROM drive is required in order todownload tools and software. This hardware requirement matches with the followingconfigurations:

The SunBlade150 workstation with 512MB RAM and 80GB disk

The Sun Blade 1500 workstation

The Ultra 45 workstation with 1.6GHz, 2GB RAM, 250GB disk

After the install upgrade the workstation goes back to its OAM purpose.

As the SUN JumpStart needs to allow any machine to boot on the networks using the RARPservice, it is necessary to have JumpStart server residing on the CIUS server and the Sunmachines to upgrade on the same subnetwork. For the remote workstation which cannotboot using the Solaris image of the JumpStart server, a specific mechanism is set: a bootfrom a Solaris CDROM with an automatic JumpStart installation from the JumpStartserver. For the remote workstations with a low bandwidth, i.e. less than 1 Mbps, it is alsopossible to perform the installation from the CIUS CDROM and from the local tape driv

with the application software, while the configuration files will be fetched from the CIUSserver.

The workstations and the SFV8x0 servers can be installed from the CIUS even if theybelong to different subnets.

Figure 3-1: workstation as a centralized installation upgrade server

X-terminal

An X-terminal (X-Window terminal) can be connected either to the OMC-R server or to client workstation set up to support X-terminal session, also named STATX workstationswhich can be local or remote.

Servers

PCU OAM

WS 1

WS 2SDO

Install/Upgrade

serverBoot net - Install

Self Bootable

Self installable

CD ROM


30/106


OMC-R

According to the X-Window Client-Server relationship, in this type of configuration anX-terminal is an X11 server and the OMC-R server or the STATX workstation are an X11client. The benefit of X-terminal is to deploy low cost or poor computing power hardware(obsolete workstation). But actually the OMC-R server with a monitor and keyboard or anominal workstation running X11 server can also act as a X-terminal. Note that X-terminalbased on PC with X11 emulation software such as Exceed are not supported as they could

cause crash on the extended workstation.Figure 3-2: X-Window Client-Server relationship

X Terminal

(X11 server)

OMC-R B ws

with X11 server

running

OMC-R Server

A

Switch /

Router

OMC-R A ws

STATX

(X11 client,

Boot server)X11

X11, tftp

OMC-R Server

B

X Terminal

(X11 server)

OMC-R B ws

with X11 server

running

OMC-R Server

A

Switch /

Router

OMC-R A ws

STATX

(X11 client,

Boot server)X11

X11, tftp

OMC-R Server

B


31/106



Table 3-2: Number of X Terminal sessions allowed

Standard X-terminals could be diskless devices and therefore have the capability to boottheir X11 server software via the network using standard IP boot protocol (TFTP) from anX11 boot server. The boot server could be the extended workstation itself or a distinctmachine. X-terminals running on workstations will boot their X11 software using their ow

disk avoiding the need of a boot server.An X-Terminal cannot operate without its X11 client, that is to say, for OMC-R with nonintegrated OCM-R server for which X11 server can only run on the STATX workstation,this comforts the requirement to have a minimum of two local workstations per site if onworkstation is out of service.

Multi-MMI workstation

The Multi-MMI workstation is a Unix machine running an X server, or indeed more simplsaid an X terminal. By definition, an X-terminal can be simultaneously attached to severaX11 clients, i.e. STATX workstations or OMC-Rs and therefore perform multiplesimultaneous sessions for different OMC-Rs. With the Multi-MMI workstation, we can

connect to several remote OMC-R at once through their local workstations set up to act aan X client (STATX). The workstations STATX running the client software (MmiKerneland MmiGraphic binary) are sending back the display to this Multi-MMI machine or Xterminal. It implies having, in each remote OMC-Rs you want to reach, one localworkstation set up as STATX, or in case of the Integrated OMC-R based on SFV8x0, thione can also be playing the role of STATX.

X11 Client

configuration

SF V880

based

Integrated

OMC-R

server

SFV890/T5140 OMC-Rserver

STATX

based on

SB150

STATX

based on

SB1500 or

Ultra45

Maximalsimultaneouslynumber of XTerminal sessions

10 40 4 9


32/106


OMC-R

Figure 3-3: Multi-MMI workstation

RACE

RACE (Remote ACcess Equipment) provides assistance for end users to ensure day-to-dayoperations, curative maintenance, etc., from a remote site but also from OMC-R site.Despite its capabilities, RACE shall not be considered as a replacement of a workstation oran X-Terminal. Indeed, it is an Internet technology based server application that runs onOMC-R workstations. An Http server also runs on these workstations. A web browser isused on end user side to manage the information.

OMC-R ws

OMC-R site 1OMC-R Server

Switch /

Router

Multi OMC ws

OMC-R ws


Switch /

Router

OMC-R ws

STATX

Connexion to OMC-R 1

thru local OMC-R 1

STATX as X-Terminal


as client

OMC-R ws


Switch /

Router

Multi OMC ws

OMC-R ws


Switch /

Router

OMC-R ws

STATX


thru local OMC-R 1

STATX as X-Terminal


as client


33/106



Figure 3-4: Remote Access connection solutions

The RACE client sends requests to an HTTP server, which is on the LAN of the OMC-Rserver and which transmits these requests to a RACE server running on an OMC-Rworkstation.

Up to 3 RACE connections can be made on the same workstation that is recommended tbe a local MMI workstation. Special workstations such as PCU OAM, SDO and X-termina

server are not allowed to act as RACE server.

On client side, RACE requires a web browser and therefore the associated hardware ableto run this browser. The recommended hardware is a high end PC. Finally, on login the enuser is proposed two modes and has to choose one according to available communicationbandwidth.

The RACE can be in a remote site and access the OCM-R LAN with a WAN access. Afirewall canbe added to improve the security.

RACE & HTTP server

This application is the link between the RACE client and the applications that lies on the

OMC-R workstation. It transmits the commands to the MmiKernel, the subscriptions to thconcerning applications. On the other hand, it translates the internal messages of MMI fothe RACE client.

The HTTP server, which receives the requests coming from the RACE client and transmitthem to the RACE server, must be installed on the same OMC-R station as the RACEserver.

OMC-R Server

[SF V890]

Hub (optional)

OMC-R Clients

LX 8020S Console Server

Central OMC-R site

QGE

RS232

QGE

Switch /

Router

PrinterX Terminal NIMS PrOptimaClient [PC]

InternetInternet

VPN Router PC RACE

PC RACEOMC-R Client &

RACE HTTP Server

OMC-R Server

[SF V890]

Hub (optional)

OMC-R Clients

LX 8020S Console Server

Central OMC-R site

QGE

RS232

QGE

Switch /

Router

PrinterX Terminal NIMS PrOptimaClient [PC]

InternetInternet

VPN Router PC RACE

PC RACEOMC-R Client &

RACE HTTP ServerOMC-R Client &

RACE HTTP Server


34/106


OMC-R

In relation to the standard configuration for the RACE server, we must configure the slotsof the terminal server, and its modems, to support PPP through PSTN. The HTTP server isconfigured using the configuration shell of the OMC-R.

RACE Client

The RACE PC client is not productized by Nortel Networks and must be purchased locally

following the requirements given in "Hardware Specifications" section.One of the advantages of the RACE application is that all the software is on the server HTML pages and Java applets and download to the client if necessary. Hence, if acorrection has to be performed on the RACE application, the update is done on the serverside, but nothing is modified on the client PCs.

The PC client software requirements are:

Microsoft Internet Explorer 5.0 and higher

Operating system: Windows 2000, Windows XP, Windows Vista

Java 1.2.2 Plug-in (in case of Internet Explorer version used not supporting RACE

applets that are composed of swings or jdk1.2 components, the Java Plug-in 1.2.2 mustbe installed).

For a connection through a terminal server, a new connection has to be created on the PC,using the Dial-up networking option of Microsoft Windows. Besides, the TCP/IP layerof Microsoft Windows has to be configured, in order to well use the modem by determiningits maximum speed, data transferred in compressed form and checked for errors.

For more information refer to SIE OMC-R Web Access: RACE, PE/OMP/DD/0045

Client workstations allowed configurations

The table below gives the supported functional configurations of the OMC-R workstations.

Table 3-3: workstation allowed configurations

Number and type of end-user connections to OMC-R

The table below gives the different mode of end-user connections to interact with theOMC-R application and their engineering limitations.

Add functional roles to

following workstation

STATX RACE server STATX + RACE

server

Nominal client workstation Supported Supported Supported

PCUOAM workstation Not supported Not supported Not supported

SDO workstation Not supported Not supported Not supported


35/106



Table 3-4: number and mode of end-user connections to an OMC-R

Whenever those limits are overrun, this results in time response increase and degradedperformance from the OMC-R.

End-user connection mode Specified as Capacity

Local workstation Required Minimum of 2, maximum of 40

Remote workstation Optional No minimum, maximum of 38

X terminal Optional Refer to Table 3-2: Number of X Terminalsessions allowed

RACE application Optional Maximum of 3 RACE sessions per localworkstation


36/106


OMC-R


37/106

Preventive Backup and Disaster Recovery Plan 4-


Preventive Backup and Disaster RecoveryPlan 4

Preventive backup

The preventive backup can be performed on following data types. Each type of data can brestored separately when needed.

OMC-R file system backup

Starting OMC-R v18, the file system backup may be performed on-line to tape, this type obackup is needed for saving the file system of OMC-R machines. This backup doesntmanage the OMC-R environment data (saved on raw devices), and therefore is notsufficient for a complete OMC-R restoration (a database re-installation is needed).

This backup can be done from the OMC-R or from a local workstation equipped with aDAT drive.

The time required to perform a file system backup can vary significantly but may take abouthirty minutes to complete, and a file system restoration takes about thirty to ninetyminutes.

OMC-R environment data archiving

This on-line type backup deals with the OMC-R environment data: the network and theOMC-R configuration data.

The backup data include OMC-R configuration files and network description from thedatabase. This backup is usually called the BDE backup.

A backup operation takes about thirty (to sixty) minutes to complete (depending on the sizof the databases).

OMC-R daily data

This on-line backup deals with data collected the last four days on the OMC-R server.

The aim of this backup is to save daily data (i.e. all observations, notifications and alarms)before they are purged, so that they can be restored later for consultation.

An archive/restore operation takes about ten to thirty minutes to complete (depending onthe amount of data to save).

MDM configuration

This on-line type backup deals with MDM software configuration files and PCUSN viewfiles.

Backup media or server

The data can be backup either:

on a labeled DDS/DAT format tapes


38/106

4-2 Preventive Backup and Disaster Recovery Plan

OMC-R

on a mounted file system via NFS handled by a backup server

There is one SUN StorEdge DDS/DAT tape drive per OMC-R server and one externalDDS/DAT tape drive per site to be attached to a local workstation. Sun StorEdge DDS/DATtape media/drive in use versus supported hardware configurations are described in"Hardware Specifications" section.

Maximum data transfer rate of DDS/DAT tape drive before data compression are listed inFigure 4-1: DDS/DAT roadmap. Data compression ratio can vary depending of the type ofdata, but one can assume the maximum compression ratio is 2:1.

Figure 4-1: DDS/DAT roadmap

Disaster Recovery Plan

If a disaster occurs on an OMC-R site provoking the loss of all the site supervision, theDisaster Recovery Plan feature allows to reconfigure an OMC-R server located in anothersite to take over the supervision of the lost OMC-R site with the shortest downtime possible(less than 6H). It covers also the restoration procedure of the initial OMC-R site.

It also supposes that on each site, there is one or more spare OMC-R integrated server withcorrectly installed and ready to run OMC-R application which will be used as a recoveryOMC-R server to replace the destroyed OMC-R located on another site

Whereas PCUSN and spare OMC-R servers may be on different sub-networks, routingtables must be defined previously so that they are available to setup routes between PCUSNand the spare OMC-R servers when needed.

Daily operations

The daily backup is automated and the data are stored on a NFS server, the NFS server isnot a local partition as to limit the disk space on the OMC-R. A successful backupcompletion deletes the d-2 backup version avoiding disk saturation.

Data backed-up daily are:

NativeTransfer Rate

Native

Capacity

90mTape

Media Type

183KB/s

2 GB

3 MB/s

36 GB

1-3 MB/s

20 GB

1.5MB/s

12 GB

720KB/s

4 GB

90m

Tape

170m

Tape

150m

Tape125m

Tape

120m

Tape

DDS2

DDS1DDS2

DDS3

DDS4DAT 72

Read/Write

Compatibility

NativeTransfer Rate

Native

Capacity

90mTape

Media Type

183KB/s

2 GB

3 MB/s

36 GB

1-3 MB/s

20 GB

1.5MB/s

12 GB

720KB/s

4 GB

90m

Tape

170m

Tape

150m

Tape125m

Tape

120m

Tape

DDS2

DDS1DDS2

DDS3

DDS4DAT 72

Read/Write

Compatibility


39/106



Environment data (BDE)

PCUOAM configuration files

SDO configuration files (/SDO/base/config)

Disaster configuration files

EFT files

daily data (the last three days) - means the user has a possibility to configure automatic backup with or withouthe EFT and daily data.

Figure 4-2: Daily operations

Recovery phase

The spare OMC-R server that will be used as the recovery server must be operating withthe same OMC-R version as the destroyed machine.

The spare OMC-R server, now named as the recovery OMC-R server, being used withouworkstation, a local workstation currently used by another operational OMC-R will bereassigned to the recovery OMC-R server and be called as recovery workstation. It impliethat this workstation must be pre-defined in the spare OCM-R server configuration

Then, knowing the name parameter of the destroyed machine and the NFS label, the lastavailable backup is searched to be restored on this recovery server.

For the specified NFS label, the recovery tool finds the information about the NFS server

to verify that it is reachable and to search the last available backup for the destroyedOMC-R.

LANOMCA-1

OMC-R workstation OMC-R workstation

NETWORK

NFS server

DAILY

BACKUP

Site ASite B

SPARE integrated

OMC-Rs

SPARE integrated

OMC-Rs

OMCB-1

RECOVERY

SERVER

OMC-R workstation

LANOMCA-1


NETWORK

NFS server

DAILY

BACKUP

Site ASite B

SPARE integrated

OMC-Rs

LANOMCA-1


NETWORK

NFS server

DAILY

BACKUP

Site ASite B

SPARE integrated

OMC-Rs

SPARE integrated

OMC-Rs

OMCB-1

RECOVERY

SERVER

OMC-R workstation

LANOMCA-1


NETWORK

NFS server

DAILY

BACKUP

Site ASite B

SPARE integrated

OMC-Rs


40/106


OMC-R

Figure 4-3: Recovery phase initialization

The OMC-R application then is stopped on the recovery server to restore the environmentdata and started to restore the PCUOAM and the three days of daily data.

Some parameters that are hardware dependant must be updated, (T3 hostnames and IPaddresses, Sybase server names) and the OMC-R re-configuration performed.

Some post operations: PCUOAM configuration files update, PCUSNs synchronization,SDO data regeneration, daily backup configuration, are necessary.

After the recovery server is installed, the automatic task of centralized archiving is runningagain.

Thus, the recovery server performs its data backup on the NFS server just like the destroyed

OMC-R was supposed to do.

LANOMCA-1


NETWORK

NFS server

Site ASite B

SPARE integrated

OMC-Rs

SPARE integrated

OMC-Rs

OMCB-1

RECOVERY

SERVER

OMCA-1 DATA

RESTORE

OMC-R workstation

LANOMCA-1


NETWORK

NFS server

Site ASite B

SPARE integrated

OMC-Rs

SPARE integrated

OMC-Rs

OMCB-1

RECOVERY

SERVER

OMCA-1 DATA

RESTORE

OMC-R workstation


41/106



Figure 4-4: Recovery phase completion

Site restoration

The return to a normal state occurs after applying the reverse operation of the disaster plaassuming that the integrated OMC-R in failure is operational in its usual OMC-R version

So, the site restoration is performed by restoring the OMC-R data from the NFS server anapplying the post operations used during the recovery server configuration.

The workstation needs to be integrated again in its usual OMC-R configuration.

The recovery server needs to be installed from scratch with the same OMC-R version tobelong to the spare integrated OMC-R pool.

Figure 4-5: Site restoration

LAN

OMCA-1


NETWORK

NFS server

Site ASite B

SPARE integrated

OMC-Rs

SPARE integrated

OMC-Rs

OMCB-1

RECOVERY

SERVER

OMC-R workstation

DAILY BACKUP

LAN

OMCA-1


NETWORK

NFS server

Site ASite B

SPARE integrated

OMC-Rs

SPARE integrated

OMC-Rs

OMCB-1

RECOVERY

SERVER

OMC-R workstation

DAILY BACKUP

LAN

OMCA-1


NETWORK

NFS server

Site A Site B

SPARE integrated

OMC-Rs

SPARE integrated

OMC-Rs

OMCB-1

RECOVERY

SERVER

RECOVERY

SERVER DATA

RESTORE

OMC-R workstation

LAN

OMCA-1


NETWORK

NFS server

Site A Site B

SPARE integrated

OMC-Rs

SPARE integrated

OMC-Rs

OMCB-1

RECOVERY

SERVER

RECOVERY

SERVER DATA

RESTORE

OMC-R workstation


42/106


OMC-R

Engineering considerations

A maximum of approx 32GB per day of disk storage volume for daily data is required tobackup an OMC-R with 3200 cells, or 10 MB per day per cell. Thus the maximum storagevolume required on an NFS server will be the result of the following calculation:

Sum on total of OMC-R server to backup with for each OMC-R the volume given by the

number of cells in OMC-R[i] * 4 (number of days which is backuped)*10 MB.As a result, the nominal bandwidth requirement between the OMC-R servers and the NFSserver cannot be less than 100 Mb/s to accomplish the daily backup of each OMC-R withinless than 3 hours.

It is also recommended to have redundancy solution for the NFS server.


43/106

OMC-R Solution Architecture and Interfaces 5-


OMC-R Solution Architecture andInterfaces 5

OMC-R Solution Architecture

The OMC-R is a client-server system architecture as shown in the figure below with thenominal hardware configuration.

Figure 5-1: Nominal OMC-R system architecture

The system architecture implements the following equipment: a single server or dualserver, multiple clients, LAN equipment, optional servers (SDO, PCU OAM) whenapplicable, other optional devices as network printers, or an uninterrupted power supply(UPS).

Remote

site

Hub

(optional)

PC RACE

PSDN

or PCM

PSDN

or PCM

OMC-R Clients

Console

Server

Central OMC-R site

BSCe3 PCUSN

OMC-R

Server

QGE

TCP/IP

RS232

QGE

Switch /

Router

RS232

PrinterX Terminal

Internet

Internet

VPNRouter

Remote

site

Hub

(optional)

PC RACE

PSDN

or PCM

PSDN

or PCM

OMC-R Clients

Console

Server

Central OMC-R site

BSCe3 PCUSN

OMC-R

Server

QGE

TCP/IP

RS232

QGE

Switch /

Router

RS232

PrinterX Terminal

Internet

Internet

VPNRouter


44/106

5-2 OMC-R Solution Architecture and Interfaces

OMC-R

Clients

The connection of the local client workstations to the OMC-R server is made with anEthernet LAN.

An X-terminal is logically linked to a workstation or to an integrated OMC-R serverthrough an Ethernet LAN. It is not recommended to have the X-terminal access the

workstation or the Integrated OMC-R server through a WAN (via routers) because of thebandwidth requirements of the X11 protocol.

The RACE PC equipment is linked through a WAN to the OMC-R central site. The RACEPC equipment can be also directly connected to the OMC-R LAN.

Ethernet switch

The OMC-R LAN must be at minimum a 100 Mbps LAN built up around an 100 MbpsEthernet switch. 1000 Mbps Ethernet switches are supported.

Console Server

For Line-Mode feature a console server is used to connect Serial port A of the OMC-R

server to local LAN in order to assume its supervision through Telnet protocol.

Remote Access VPN

The Nortel VPN Router provides IP routing, Ipsec based VPN, stateful firewall, encryption(DES, 3DES, AES, RC4), authentication. It supports both site-to-site and remote accessVPNs. The VPN Router is connected to the Ethernet LAN of the OMC-R server site. Itgives access to the RACEs and support teams.

Ethernet routing switch

This routing device is connected to OMC-R Ethernet LAN to provide access to the remotesites, the remote BSC 3000 nodes and the remote PCUSN nodes.

Another type of remote site is the NMS which manages one or several OMC-R throughTMN Q3 interface.

OMC-R/BSC2G X.25 routing switch

This equipment is no longer required starting OMC-R v18.

Optional servers of the OMC-R system not based on the Integrated

OMC-R Server

The following optional servers are part of the OMC-R system which are not based on theIntegrated OMC-R server.

The PCU OAM server hosted by a dedicated local workstation with additional memory anddisks capacity will be connected to the Ethernet LAN. The PCU OAM can be installed onlylocal, i.e in the same LAN with the OMC-R.

The SDO (data server) is used to export OMC-R data in a pre-defined ASCII format. It caninstalled on a dedicated workstation with an external disk when necessary. An SDO can belocal or remote.


45/106



Other optional devices

All OMC-R equipment should be connected to an UPS or AC power backup. The ACpower must be protected. This requirement is of major importance for servers and workstations with software that runs on Solaris (Unix) systems.

A network printer can be connected to the OMC-R Ethernet LAN or be part of the remot

sites workstation.Security Feature - Solaris Secure Shell (SSH)

Solaris SSH provides a suite of tools that are secure alternative/replacement of traditionatelnet, ftp, rlogin, rsh commands. Operators and administrator should always use sshutilities such as ssh, sftp, scp for their administrative tasks.

Starting in the v17 release, the OMC-R servers and workstations support SSH v2 (SecureShell) allowing remote users or management systems to use secure shell and file transferThe objective is to ensure that passwords are not exchanged in readable text over thenetwork, as they are encrypted. With such security mechanism, a badly disposed personconnected to this network, can't retrieve passwords by 'packet sniffing'.

OAM Interfaces

OMC-R server X.25 interface

This equipment is no longer required in OMC-R v18. If the X.25 card is available on thehardware, it wont be utilized and the X25 software package is no longer installed.

Integrated OMC-R Server IP interface

The Integrated OMC-R server requires 2 Ethernet links because its implements SolarisInternet Protocol Multi Pathing (IPMP) to support redundancy at the network adapter and

connectivity level.

With the Integrated OMC-R Server based on the SF V8x0 platforms which have two QuaFast Ethernet cards (V880) or two Quad Gigabyte Ethernet (V890/T5140), to handle allserver traffic on a single subnet 3 IP addresses will be required. The active interfacerequires 2 IP addresses (one, public, for server data communications and the other, privatefor interface tests) and the standby requires 1 private test IP address (interface test only).Upon a failure of the active interface, the public data communication IP address transferover automatically to the standby interface.

The private test address is used only to detect failure and recovery of an interface. In solariterms, it is marked as depreciated so that applications do not actually use this address for

standard server communications.

The public data address (assigned to the Active Interface) is used for the standard servercommunication and migrates automatically between interfaces in the event of an interfacfailure. The Standby Interface does not have a public data address assigned. Should theActive Interface fail, the public data address will migrate to the Standby Interface. The


46/106


OMC-R

private test address must be a valid routable address and it must be in the same subnet as itsassociated data address. As soon as the interface originally set as active goes back infunction, the public data address is assigned back to this interface.

Refer to "Appendix B: OMC-R LAN Engineering" section.

Note 1: The Integrated OMC-R server based on SF V8x0 has one Gb Ethernet port

which is not used at the moment.Note 2: The Dual T3 External storage has two 100Mb Ethernet port which must beconnected to the OMC-R LAN.

BSC X.25 interface

This equipment is no longer required starting OMC-R v18.

BSC 3000 IP interface

The interface between BSC 3000 and OMC-R is Ethernet TCP/IP unlike X.25 or Ainterface with the BSC2G. The Ethernet LAN must be 100 Mbps full duplex.

At BSC 3000 Control Node, 2 OMU boards (1 Active + 1 Passive), provide connectivity

toward the OMC-R each of them using one 10/100 Base-T Ethernet port. Each OMUEthernet port has its own IP address, this will give us two Ethernet ports at the BSC level,each of these two ports being "called" by the OMC-R by different IP address. These twoports (we can say one active and one passive) are both accessible for local maintenancewith a local TML but only the one, corresponding to the OMU active, will "answer" to theOMC-R "call".

Note: For a BSC e3, 2 IP addresses should be reserved for the different OMU boards plus2 other for the CEM boards. These IP addresses need to be defined in the same IPsubnetwork. OMU boards are required to be connected to the IP network while CEM IPaddresses are not used externally of the BSC except if TML is used remotely. CEM boards

can be reached from the OMC-R through the OMUs. However it is recommended toconnect the CEM boards to the IP network to ease remote technical support interventionfrom a TML.

In order to facilitate the local maintenance, an optional integrated hub had been introducedas an option with the BSC 3000 order list (a Hub 8 ports dual speed 10.100 Base-T).Another option is to have the two OMU Ethernet links be connected to an Ethernet switchand allows equipment interconnection (TML, RACE).

Only the active OMU can be polled by the OMC-R. In case of OMU or Ethernet linkfailure, the BSC 3000 OMU are automatically switch (passive OMU becomes then active).The BSC informs then the OMC to use the second IP address.

PCUSN IP interface

The interface between PCUSN and OMC-R is Ethernet TCP/IP.


47/106



The PCUSN hosts 2 Control processor (CP), one active and one hot-standby in a singleshelf, but the two CPs have the same IP address. In case of switch over from the active tothe hot-standby CP, a hub or switch connected to both CP is required in order to keep theOAM connection alive. IP and MAC addresses are automatically propagated from thefailed CP to the standby CP.

Local connection performed between the OMC-R and the PCUSN requires the use of a

switch to isolate the PCUSN from the IP traffic messages not intended to PCUSN whichcould cause the PCUSN CP to crash in case of too heavy traffic. A single switch can beshared to connect locally multiple PCUSNs to the OMC-R.

OMC-R to GSM BSS Nodes end to end link solution

OMC-R has the following external interfaces:

The OMC-R to PCUSN interface using the TCP/IP communication protocol

The OMC-R to BSC 3000 interface using the TCP/IP communication protocol

The OMC-R to NMS interface using the TCP/IP communication protocol

OMC-R PCUSN Connection

OMC-R servers are connected to PCUSNs by TCP/IP connection established througheither LAN network for PCUSN local to the OMC-R site, or through a WAN network or onPCM time slots of the A interface for PCUSN remote to the OMC-R site.

There are four types of scenario, depending on the BSC location, design options, andcustomer requirements.

PCUSNs remote to the OMC-R site are connected via the Agprs interface using a rout PCUSNs remote to the OMC-R site are connected through a WAN

PCUSNs co-located to the OMC-R site are connected through the OMC-R LAN.

Agprs interface link solution

This configuration is an alternative that can be used when the PCUSN is remote to thePCUSN OAM traffic to the OMC-R LAN network. Using a router, we encapsulate IPtraffic over PCM time slots up to the SGSN via the Agprs interface, and de capsulate the IPtraffic to the OMC-R LAN.

The router used at both ends will require the following interface modules:

one ethernet interface (RJ 45 and 15-pin AUI connector) for connectivity to the OMC-RLAN or to the PCUSN Ethernet interface

one or more E1 or T1 interfaces

The figure below describes the OMC-R PCUSN Agprs interface link.


48/106


OMC-R

Figure 5-2: OMC-R PCUSN Agprs interface link

Ethernet routing switch solution

This solution will be used when the PCUSN is remote to the OMC-R LAN network.Interconnection is performed using a WAN (X.25, Frame relay, PCM). The VPN Router1750 or the Ethernet Routing Switch 8600 will be proposed for WAN access at both ends.

The VPN Router 1750 or ERS 8600 router used at both ends will require the followinginterface modules:

one ethernet interface (RJ 45 and 15-pin AUI connector) for connectivity to the OMC-RLAN or to the PCUSN Ethernet interface

one or more WAN access modules

This solution will also cover the interconnection of remote BSC 3000 and remoteworkstation to the OMC-R LAN.

The figure below describes the OMC-R PCUSN WAN solution.

MA E LAN

Hub or switch

Cross Connect

Gb I/f

MA E LAN

PCUSN (remote)

Cross Connect

PCUSN OAM packet

PCM : GPRS traffic only

Gb I/f

PCM links

Ethernet

PCM : GPRS + PCUSN OAM traffic

OMC-R

SGSNASN

GPRS packet

ASN

MA E LANMA E LAN

Hub or switch

Cross Connect

Gb I/f

MA E LANMA E LAN

PCUSN (remote)

Cross Connect

PCUSN OAM packet

PCM : GPRS traffic only

Gb I/f

PCM links

Ethernet

PCM : GPRS + PCUSN OAM traffic

OMC-R

SGSNASN

GPRS packet

ASN


49/106



Figure 5-3: OMC-R PCUSN WAN solution

LAN connection

When the PCUSN is local to the OMC-R site, the PCSUN Ethernet interface will bedirectly connected to the OMC-R LAN through a switch.

ROUTER 3

WAN

(LL,X.25, E1/T1)

OMC-RActive

server

BSC1

WAN

(LL,X.25, E1/T1)

WAN

(FR,X.25,E1/T1)

OMC-RActive

server

OMC-RActive

server

BSC1PCUSN

ROUTER 2

ROUTER 1

Ethernet :Cascade Link : 2.5Multi-Link Trunking

100 MbpsGbps

-

VRRP

IP 1

SWITCH 1

SWITCH 2

IP 2

Workstation

QFE 4

QFE 0

ROUTER 3

WAN

(LL,X.25, E1/T1)

WAN

(LL,X.25, E1/T1)

OMC-RActive

server

OMC-RActive

server

BSC1BSC1

WAN

(LL,X.25, E1/T1)

WAN

(FR,X.25,E1/T1)

OMC-RActive

server

OMC-RActive

server

BSC1PCUSN

ROUTER 2

ROUTER 1

Ethernet :Cascade Link : 2.5Multi-Link Trunking

100 MbpsGbps

-

VRRP

IP 1

SWITCH 1

SWITCH 2

IP 2

Workstation

QFE 4

QFE 0


50/106


OMC-R

OMC-R BSC 3000 Interface

BSC 3000 co-located with the OMC-R LAN

This configuration presents the advantage of using the existing OMC-R LAN equipmentbut it has to be mentioned that an Ethernet switch is mandatory between BSC 3000s andOMC-R. The OMC LAN traffic being quite high, the active and passive OMUs need to be

protected from this traffic load.In case of an OMC-R LAN made with hubs this one should be replaced with Ethernetswitch at least for BSC connections. No additional equipment is needed (not even the BSCinternal hub).

Simple connection using the existing LAN equipment (no redundancy)

The Ethernet Switches ranging from 24 ports to 48 ports can be used for this type ofconfiguration, and for each BSC 3000 2 Ethernet ports on the switch should be provisioned;In case of several co-located BSC 3000s, switches can be stacked to provide the requirednumber of ports. The Ethernet Switches BS470 and BS5510 can be used in thisconfiguration.

Figure 5-4: Simple connection using the existing LAN equipment (no redundancy)

Redundant Switch connection using Spanning Tree

This configuration uses a redundant Ethernet Switch configuration and is recommendedonly as an interface toward the BSS OAM network (it can connect the co-located BSCs andthe routers connecting the remote BSC)

This configuration can be made using the BS470 and BS5510 Ethernet Switches. Thosetype of switches have optional or built-in Cascade Modules allowing the interconnection ofseveral switches with a 2.5 Gbps link. Combining the cascade capability with the SpanningTree Protocol Support (detects and eliminates the logical loops in the network) thoseswitches are perfectly adapted for this kind of configuration.

OMC-R

Active

server

BSC 1

QFE 4

SWITCHIP 1

Passive link

IP 2

No redundancy

OMC-R

Active

server

OMC-R

Integrated

server

BSC 1BSC 1QFE 0

Workstation

Ethernet : 100 Mbps

OMC-R

Active

server

OMC-R

Active

server

BSC 1BSC 1

QFE 4

SWITCHIP 1

Passive link

IP 2

No redundancy

OMC-R

Active

server

OMC-R

Integrated

server

BSC 1BSC 1QFE 0

Workstation

Ethernet : 100 Mbps


51/106



Figure 5-5: Redundant Switch connection using spanning tree

Remote BSC 3000

When the BSC e3 is remote from the OMC-R, the BSC and OMC-R LANs must beinterconnected through a WANwith a throughput of 256 kbit/s:

For a throughput of 256 kbit/s, the use of the Frame Relay protocol is advised.A minimumof 128 kbps can be used for normal operation (OBS, NOTIF, TRACE) except for softwarupgrade

For several BSC 3000 collocated, the minimum recommended throughput is 128 kbit/s fothe site plus 128 kbit/s per BSC. Its to guaranteed the upload and download performancand redundancy purpose.

This supposes the introduction of IP routers at the OMC-R level and also at the BSC levelThe solution proposed here tries to ensure an increased redundancy at the transmission

network level and at the OMC-R level (the most critical parts of the OMN). The BSC sitwill contain only one router but equipped with two WAN interfaces.

We will consider here two cases of WAN, one based on Frame Relay network and secondone based on a PCM network.

Both types of WAN considered will use the same type of routers at the OMC and at the BSClevel but equipped with different types of WAN interfaces.

For the BSC 3000 site, one router should be considered with one Ethernet interface (anextra Ethernet switch will be required) and two WAN interfaces (V.11 or E1/T1) forredundancy purpose. The available routers are the VPN Router 1750. If the customers

request an increased redundancy level, then an additional router for the BSC should beconsidered.

For the OMC-R site a two router configuration is to be considered. The two routers at thOMC-R level should be equipped with one Ethernet interface and one WAN interface andwill be configured to work in tandem using VRRP (Virtual Router Redundancy Protocol

OMC-R

Active

server

BSC 1

IP 1IP 2

OMC-R

Active

server

OMC-R

Integrated

server

BSC 1BSC 1

SWITCH 1

SWITCH 2

QFE 4

QFE 0

Workstation

Ethernet :Cascade Link : 2.5

100 MbpsGbps

OMC-R

Active

server

OMC-R

Active

server

BSC 1BSC 1

IP 1IP 2

OMC-R

Active

server

OMC-R

Integrated

server

BSC 1BSC 1

SWITCH 1

SWITCH 2

QFE 4

QFE 0

Workstation

Ethernet :Cascade Link : 2.5

100 MbpsGbps


52/106


OMC-R

Figure 5-6: OMC-R / BSC 3000 remote connectivity using a WAN

The main idea is to keep alive the link between the OMC-R (QF0 IP address) and the activeOMU of the BSC (IP1 address) in case of one WAN interface or one router or one EthernetSwitch failure. There are still a single point of failure which but can be considered lesscritical: the router in the BSC site, but then only one BSC is affected in case of failure.

E1/T1 alternatives

If the chosen type of transmission network for WAN is E1/T1, than a PCM concentrationshould be made so that a minimum number of WAN interfaces to be used at the OMC-Rrouters level. This can be done at the WAN level (by using an SDH backbone):

Figure 5-7: E1/T1 links using WAN concentration

Or it can be done by concentrating the PCMs coming from several BSCs at the OMC-Rlevel by using a digital cross-connect (which can be even the MSC):

v18 omc-r engineering rules (2008).pdf

Documents