Standalone RNC OMS product description - RU20 P7.pdf

Standalone RNC OMS product description

DN70446142

Issue 01B

2 DN70446142Issue 01B


Id:0900d80580677eb7

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given "as is" and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2009. All rights reserved

f Important Notice on Product Safety Elevated voltages are inevitably present at specific points in this electrical equipment. Some of the parts may also have elevated operating temperatures.

Non-observance of these conditions and the safety instructions can result in personal injury or in property damage.

Therefore, only trained and qualified personnel may install and maintain the system.

The system complies with the standard EN 60950 / IEC 60950. All equipment connected has to comply with the applicable safety standards.

The same text in German:

Wichtiger Hinweis zur Produktsicherheit

In elektrischen Anlagen stehen zwangsläufig bestimmte Teile der Geräte unter Span-nung. Einige Teile können auch eine hohe Betriebstemperatur aufweisen.

Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Körperverlet-zungen und Sachschäden führen.

Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die Anlagen installiert und wartet.

Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene Geräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.

DN70446142Issue 01B

3


Id:0900d80580677eb7

Table of ContentsThis document has 44 pages.

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1 Introduction to RNC OMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 RNC OMS overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1 RNC OMS in RNC Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Scalability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Benefits of standalone RNC OMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 RNC OMS product structure, licensing and optional items . . . . . . . . . . 134.1 Basic product structure and licensing . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Optional product and service items . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2.1 Site solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 Management and software in RNC OMS. . . . . . . . . . . . . . . . . . . . . . . . 145.1 Command line interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.2 Centralised Element Manager with a graphical user interface. . . . . . . . 145.3 Software management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.4 Fault management of RNC OMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6 Software architecture in RNC OMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

7 Hardware in RNC OMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187.1 Hardware architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187.2 External interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207.3 Power supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207.4 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

8 RNC OMS site architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228.1 OMS at RNC site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

9 Technical specifications for RNC OMS . . . . . . . . . . . . . . . . . . . . . . . . . 259.1 Dimensions and weights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259.2 Power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259.3 Environmental information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259.3.1 Temperature and humidity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259.3.2 Altitude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269.3.3 Safety and Electromagnetic Conformance . . . . . . . . . . . . . . . . . . . . . . 269.4 RoHS Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

10 Linux operating system running in RNC OMS . . . . . . . . . . . . . . . . . . . . 2710.1 Operating system contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2810.2 Operating system security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

11 Runtime environment in RNC OMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3111.1 Runtime environment in RNC OMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3111.2 Disk access in RNC OMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3211.3 Disk partitions and images in RNC OMS. . . . . . . . . . . . . . . . . . . . . . . . 33

4 DN70446142Issue 01B


Id:0900d80580677eb7

11.4 File system in RNC OMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3711.5 File system contents in RNC OMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3811.5.1 The Linux Filesystem Hierarchy Standard . . . . . . . . . . . . . . . . . . . . . . . 3811.5.2 Access to the file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3811.5.3 File system layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

12 Operating system start-up and shutdown in OMS . . . . . . . . . . . . . . . . . 4312.1 High availability services architecture in OMS . . . . . . . . . . . . . . . . . . . . 4312.2 Operating system start-up. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4312.3 Operating system shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

DN70446142Issue 01B

5


Id:0900d80580677eb7

List of FiguresFigure 1 HP ProLiant DL360 G6 OMS server . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Figure 2 RNC OMS interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Figure 3 RNC OMS product structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Figure 4 RNC OMS software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Figure 5 Front panel view of the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Figure 6 Front panel indicator LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Figure 7 Rear panel of the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Figure 8 OMS located at RNC site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Figure 9 Rack installation space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Figure 10 Secure interfaces with standalone OMS . . . . . . . . . . . . . . . . . . . . . . . . 24Figure 11 FlexiPlatform architectural domains. . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Figure 12 FlexiPlatform operating system structure. . . . . . . . . . . . . . . . . . . . . . . . 29Figure 13 Physical volumes grouped into a volume group . . . . . . . . . . . . . . . . . . 34Figure 14 Base platform partitions on hard disk drives . . . . . . . . . . . . . . . . . . . . . 35Figure 15 An example of a dynamic directory hierarchy within the staging area . . 42Figure 16 Node start-up phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6 DN70446142Issue 01B


Id:0900d80580677eb7

List of TablesTable 1 Front panel indicator LEDs statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Table 2 Space requirements for RNC OMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Table 3 Physical partitions (CLA node) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Table 4 Logical volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Table 5 RAID metadevices and members (underlying resources) . . . . . . . . . . . 36Table 6 The staging area root directory structure . . . . . . . . . . . . . . . . . . . . . . . . 39Table 7 The /opt/Nokia directory contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Table 8 The /opt/Nokia_BP/ directory contents . . . . . . . . . . . . . . . . . . . . . . . . . 40Table 9 /opt/Nokia_BP/etc directory contents . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Table 10 /opt/Nokia_BP/etc/ldapfiles directory contents . . . . . . . . . . . . . . . . . . . . 41

DN70446142Issue 01B

7

Standalone RNC OMS product description Summary of changes

Id:0900d80580677fbf

Summary of changesChanges between issues are cumulative. Therefore, the latest issue contains all changes made to previous issues.

Changes between issues 01A and 01B

• Handling capacity has been changed from 1600 to 2800 WCDMA BTSs in RNC OMS overview.

• Microsoft Windows 2000 platform is no longer used in managing the OMS Element Manager applications. Microsoft Windows Vista is supported instead. Management and software in RNC OMS has been updated.

• Hardware architecture in Hardware in RNC OMS has been modified.

• Disk partitions and images in RNC OMS in Runtime environment in RNC OMS has been modified.

• Two fibre channel dual bus host bus adapters and SCSI card are not included in the server package. Therefore, two bullets have been removed from Hardware architec-ture in Hardware in RNC OMS.

Changes between issues 01 and 01A

• OMS and RNC have been shown in an one-to-one relation in OMS overview.

• ANS.1 connection has been changed to TCP/IP in EMT interface in OMS overview.

• Handling capacity has been changed from 2 800 to 1 600 WCDMA BTSs in OMS overview.

• High availability services (HAS) system has been described in Operating system start-up and shutdown on OMS.

• Information on installing the RNC OMS in the rack in the site has been added to Hardware in RNC OMS.

• Current OS delivery has been changed to Red Hat Enterprise Linux Release 4 Update 8 in Linux operating system running in RNC OMS.

8 DN70446142Issue 01B


Id:0900d80580677fbf

Summary of changes

DN70446142Issue 01B

9

Standalone RNC OMS product description Introduction to RNC OMS

Id:0900d805805ac029

1 Introduction to RNC OMSThis document provides a general overview of the RNC OMS product. It gives the infor-mation about RNC OMS under the following topics:

• overview • benefits • product structure • management • software architecture • hardware architecture • site architecture

10 DN70446142Issue 01B


Id:0900d80580670f9c

RNC OMS overview

2 RNC OMS overview

2.1 RNC OMS in RNC SolutionRNC OMS is a necessary network element in the operability architecture of Nokia Siemens Networks RNC Solution. It acts as a centraliser between WCDMA Access Network elements and NetAct. Thus, it contributes to overall operation and manage-ment solution efficiency and helps operators in achieving cost efficiency in network oper-ation and investments.

Previously it has been integrated part of RNC, but now it’s introduced as standalone network element. One RNC OMS is needed to support each RNC.

Figure HP ProLiant DL360 G6 OMS server introduces the RNC OMS server.

Figure 1 HP ProLiant DL360 G6 OMS server

Physically, it is composed of a compact, 1RU high server that is mountable to a standard 19 inch rack.

It concentrates operation and management traffic and performs operation and manage-ment activities towards the RNC and WCDMA Base Stations under control of NetAct. In addition RNC OMS offers a local management interface towards RNC network elements with basic centralised alarm and performance management capabilities. RNC OMS par-ticipates as a centralising node to all key management tasks, such as fault, perfor-mance, configuration, topology and software management.

Advanced tools for different management area tasks like full scale fault management, performance reporting, configuration and software management are provided by NetAct.

2.2 InterfacesRNC OMS connects to RNC through Nokia Siemens Networks’ management interface EMT. All fault management, performance management, configuration and software management transactions between RNC and OMS are transferred over the EMT inter-face.

The NWI3 and EMT management interfaces used in Nokia Siemens Networks WCDMA systems provide sophisticated functional capabilities, reliability and efficiency.

DN70446142Issue 01B

11

Standalone RNC OMS product description RNC OMS overview

Id:0900d80580670f9c

Figure 2 RNC OMS interfaces

2.3 ScalabilityRNC OMS is capable of handling capacity of RNC2600, 2 800 WCDMA BTSs and 4 800 cells.

RNC OMS is capable of handling different types of mass management operations under the control of NetAct, so that there are management operations going on in parallel towards several elements. Mass operations are used when certain management oper-ations need to be done to certain group of network elements. An example of this are con-figuration data and software downloads to new base stations.

12 DN70446142Issue 01B


Id:0900d8058068e2d5

Benefits of standalone RNC OMS

3 Benefits of standalone RNC OMSThe main benefits of Nokia Siemens Networks RNC OMS are outlined below.

State-of-the-art feature setNokia Siemens Networks’ long experience of radio access and mobile data networks management and input based on operator requirements ensure that RNC OMS func-tionality and feature set are well considered and provide maximum benefit to operators.

High quality, proven software platformRNC OMS software is running on top of a carrier grade FlexiPlatform (SW platform). The FlexiPlatform design ensures high availability, reliability, scalability and high perfor-mance incorporating innovations from open standards such as Linux and J2EE. RNC OMS is based on the field-proven NEMU unit used in Nokia Siemens Networks 3G net-works. Thus a high quality platform and increased benefits of economies of scale are ensured.

Scalable, efficient architectureRNC OMS provides scalability of operability architecture via aggregating, parsing and intermediating the operation and management traffic flow between NetAct and access network elements. RNC OMS performs individual management operations to network elements under control of NetAct. RNC OMS is able to perform efficient parallel mass operations towards several network elements and handle different operation and man-agement operations simultaneously to the same network element. These capabilities reduce both the processing and database access load in NetAct management system and overall management data transmission needs.

Accurate status of the networkRNC OMS provides synchronized measurement data from the WCDMA Access Network elements and real-time WCDMA BTS and RNC state supervision and manage-ment, giving thus an accurate picture of network status. Reliable, correct information helps operators to make right daily operation and management decisions. It also gives good input to longer-term network planning, enabling operators to plan network invest-ments in a cost efficient manner.

Local operation interface RNC OMS offers a local operation interface towards RNC. The interface makes it possible to monitor access networks locally via RNC OMS during network roll-out, upgrade and expansion phases and during regular daily operation, when reasonable.

Secure software platformRNC OMS runs on top of FlexiPlatform/Red Hat, gaining thus from the security benefits of Red Hat Linux Security Framework. Industry experts consider the security risk of Linux to be low, thus giving relief to platform software security concerns.

Easy to place and install RNC OMS has a compact size and it fits to a standard 19-inch rack.

DN70446142Issue 01B

13

Standalone RNC OMS product description RNC OMS product structure, licensing and optionalitems

Id:0900d8058068e2e9

4 RNC OMS product structure, licensing and optional items

4.1 Basic product structure and licensingThe RNC OMS product structure is simple. There are no optional configuration items. OMS consists of basic software and hardware items that belong to the following archi-tectural layers:

• WCDMA basic software • Platform hardware

Basic software contains commercial 3rd party software items, database and directory server and Nokia Siemens Networks specific platform software.

Figure 3 RNC OMS product structure

When ordering RNC OMS, the customer receives one basic licence that entitles you to run one instance of the product.

4.2 Optional product and service items

4.2.1 Site solutionSite solution items, for example a rack with a local management console, are offered as optional items. It is also possible to order rack installation service.

Field engineering workstation for commissioning RNC OMSCommissioning requires a Field Engineering WorkStation (FEWS). This must be Red Hat Enterprise Linux 4 (RHEL4) compatible PC HW, for example a laptop. One laptop can naturally serve commissioning needs of more than one RNC OMSs.

FEWS provides DHCP, TFTP and NFS services required for installation.

HW requirements for the computer are the following:

• RHEL4 compatible PC HW • 512 Mb memory • 60 GB HD • 2*100/1000 MB network interfaces • CD/DVD ROM • network cables

FEWS hardware is not included in the optional product offering, since it is a standard computer. FEWS is needed when using RNC OMS for the first time or updating the whole software image.

The needed FEWS software package including the required Red Hat licence is available as an optional product item.

14 DN70446142Issue 01B


Id:0900d8058068e318

Management and software in RNC OMS

5 Management and software in RNC OMS

5.1 Command line interfaceThe command line interface tool, a text-based management interface, can be used for configuring, commissioning and maintaining the RNC OMS software as well as managing user and user group data in RNC OMS internal LDAP.

CLI tools enable:

• configuring and controlling RNC OMS high availability services (HAS) • managing hardware data • configuring and managing IP services and IPSec • managing software deliveries and sets • managing data in Internal LDAP directory • controlling Common Object Request Broker Architecture (CORBA) • managing user accounts, user groups and permissions

RNC OMS CLI tools are meant for experienced users with knowledge of Linux operating system and FlexiPlatform system.

5.2 Centralised Element Manager with a graphical user inter-faceRNC OMS element manager applications have a graphical user interface. Java-based client applications run on Microsoft Windows XP/Vista and on Linux Red Hat platforms. These tools are accessible via Application Launcher that offers a single sign-on for all GUIs it launches.

RNC OMS Element Manager provides the following user interface applications:

• Fault Management • RNW Measurement Management • RNW Measurement Presentation • RNC RNW Object Browser • NE Threshold Management • NE Measurement Explorer • RNW online monitoring • Diagnostics • State Handling

NE Threshold Management is used for setting threshold values for performance indica-tors.

The RNC RNW Object Browser provides the user with a general view on the managed objects in the radio network. The RNW database contains the configuration data and the control parameters of the radio access network (RAN) controlled by the radio network controller (RNC).

With the RNW Measurement Management you can manage radio network measure-ments. RNW Measurement Management application is used to manage RNC radio network measurements, WBTS radio network measurement and Flexi BTS transmis-sion measurements.

DN70446142Issue 01B

15

Standalone RNC OMS product description Management and software in RNC OMS

Id:0900d8058068e318

With the RNW Measurement Presentation you can create presentations from radio network measurement data.

NE Measurement Explorer is used for viewing RNC Transport and Hardware (HW) mea-surement data stored to OMS database and managing RNC Transport and HW mea-surements.

The RNW online monitoring feature can be used to obtain real-time information from the predefined cells. Online monitoring provides valuable information for configuring and optimizing the network.

Fault management in RNC OMS consists of a set of functions to detect and correct fault situations in the system. The Fault Management GUI can be used for monitoring fault situations, alarm cancellation and alarm parameters change.

With the Diagnostics GUI you can run diagnostic test in RNC units and research the RNC diagnostics situation.

State Handling application is used for executing the state inquiries for units and I/O devices, changing unit and I/O device states, changing unit status info and restarting units and the system.

In addition, the graphical user interfaces offer:

• access to the master system log via a web GUI • a software version management GUI for checking software version data • Parameter Tool for handling RNC OMS runtime configuration data objects stored in

the Lightweight Directory Access Protocol (LDAP) directory. Parameter Tool allows the user to browse, search, add, delete, and modify RNC OMS configuration data objects and attributes stored in LDAP directory especially at the time of installation. Importing and editing LDAP data interchange format (LDIF) files is also possible. Restrictions to Parameter Tool user rights can be set.

• Active session GUI shows users currently using Element Manager.

5.3 Software managementRNC OMS has software management functionalities that support installation, online management and commissioning of RNC OMSs own software versions.

The operator may need to install new software versions or modify existing software due to enhancements, new features or security patches. The software upgrade is done in the background and then activated, which means that the operation is not disturbed.

The software version management utility used in RNC OMS to install software to the staging area (SA) is Red Hat Package Manager (RPM). Software management commands for software delivery management to staging area, software set manage-ment and LDAP upgrades are based on shell scripts.

There are two kinds of software deliveries: base delivery and incremental delivery.

The base delivery contains a full set of software subsystems forming an entire software release.

The incremental delivery is used for delivering corrections or enhancements to an existing system. It contains the RPM packages of one of more software subsets that are new or have changed compared to the base delivery or the previous delivery. A software subset is software unit that can be upgraded and installed separately. It implements a certain functionality of the system, for example, alarm management.

16 DN70446142Issue 01B


Id:0900d8058068e318

Management and software in RNC OMS

When RNC OMS is taken to use for the first time, commissioning process is needed. Commissioning is also always needed with base software deliveries that are typically software release upgrades.

Commissioning refers to installing software, inspections and internal configurations required after hardware installations before the server is connected to network.

Commissioning preparation consists of the following procedures:

• Setting up field engineering workstation. It is the Red Hat Enterprise Linux 4 computer that must meet the FEWS hardware configurations requirements.

• Configuring the hardware and the commissioning connection. • Preparing the software in FEWS for commissioning.

Incremental software deliveries can be taken into use without commissioning proce-dures. The first incremental delivery is built on top of the base delivery and the later ones will be based on the previous deliveries. RNC OMS offers flexible means for managing different software deliveries, like upgrading and downgrading software subsystems and incremental deliveries, deleting older versions to save disk space, checking software version and verifying software delivery.

The users of RNC OMS software management commands should have basic Linux skills and good understanding of RPM.

5.4 Fault management of RNC OMSRNC OMS high availability service (HAS) framework is involved in the fault management process from the moment the node is started. HAS supervises managed objects, health of node and software processes.

RNC OMS supports fault isolation, recovery and repairing mechanisms up to a graceful process or a node shutdown.

The RNC OMS alarm system that processes and stores access network element alarms, handles also the alarms raised by OMS itself. RNC OMS also makes internal alarms available to NetAct or the FM GUI applications.

The alarms definitions of OMS have evolved from telecommunications standards, namely 3GPP and ITU-T recommendations.

DN70446142Issue 01B

17

Standalone RNC OMS product description Software architecture in RNC OMS

Id:0900d80580625926

6 Software architecture in RNC OMSRNC OMS software is composed of WCDMA specific software and common access service network layer. WCDMA specific software contains the WCDMA specific imple-mentation of operation and management functionalities like fault, performance, software and configuration management and topology views. They are implemented using the underlying services of the common access service network application layer and oper-ation and management platform belonging to the underlying software (SW) platform.

RNC OMS software runs on top of a carrier grade Nokia Siemens Networks SW plat-form. RNC OMS SW platform is a high availability, high reliability platform that targets to provide high performance in a small footprint. SW platform leverages the newest industry wide innovations using Open Standards and Open Software such as CG Linux and J2EE. Modular architecture and open interface enables usage of best-of-breed commercial off-the-shelf hardware for WCDMA application.

RNC OMS SW platform has layered logical hierarchy that is composed of the following layers:

• Linux Red Hat Operating System • Base platform (BP) comprising LDAP directory services, basic software and back-

up management, IP, security and high availability services and hardware manage-ment for underlying hardware.

• Platform services (PS) comprising internal messaging, naming and MySQL database services.

• Application Framework (AF) comprising frameworks and libraries for application developers, J2EE platform for example.

• O&M platform comprising for example alarm and performance management services that interact with remote or local management system, for example with element manager.

• A selection of Network Protocols (NP)

Figure 4 RNC OMS software architecture

18 DN70446142Issue 01B


Id:0900d80580670be9

Hardware in RNC OMS

7 Hardware in RNC OMS

7.1 Hardware architectureRNC OMS hardware (HW) platform, HP ProLiant DL360 G6 1U rack-mount server is designed to offer concentrated computing power for installations, where space is limited. A dense, high performance computing system is combined to a compact size and fault tolerance. Latest Intel 5500 Series Xeon® Processors (Quad-Core and Dual-Core), with DDR3 Registered DIMMs, Serial Attached SCSI (SAS) and PCI Express Gen2 technol-ogy provide a high performance system, ideal for the full range of scale out applications. It has quad-core processor architecture with redundant hot-pluggable power supplies, redundant fans, 12 GB memory, redundant 146 GB Serial Attached SCSI (SAS) hard drives (total 4 discs) and embedded RAID capability.

The server includes the following main components:

• two Intel® Xeon® Quad-core processor E5540 (2.53 GHz, 8MB cache, 80W, 1066MHz)

• 12 GB memory • four 146 GB small form factor (SFF) SAS hard drives • HP Smart Array P410i embedded controller (RAID 0/1/1+0) • KVM extension • USB 2.0 ports (1 front, 2 rear)

The front view of the server is shown in the figure Front panel view of the server. The Systems Insight Display is accessed by pressing and releasing the display. Once extended, it can be rotated 90o.

Figure 5 Front panel view of the server

Figure Front panel indicator LEDs shows a close-up view of the front side LEDs:

DN70446142Issue 01B

19

Standalone RNC OMS product description Hardware in RNC OMS

Id:0900d80580670be9

Figure 6 Front panel indicator LEDs

Table Front panel indicator LEDs statuses explains the server status conditions accord-ing the frontside LEDs.

Table 1 Front panel indicator LEDs statuses

The rear view of the server is shown in the figure Rear panel of the server. It includes among others two RJ-45 NIC connectors, KVM connectors and power supply bays. The RJ-45 NIC connectors offer a 10/100/1000-T network interface for Ethernet connectivity.

Indicator LED Status

Power on/standby button with system power LED

Green = System is on.

Amber = System is shut off, but power is still connected.

Off = Power cord is disconnected, the power supply is not installed, the power supply has failed, facility power is not available, or power button cable is disconnected.

User indication (UID) and LED Blue = Identification is activated.

Flashing blue = System is being remotely managed.

Off = Identification is activated.

Health LED Green = System health is normal.

Amber = System health is degraded.

Red = System health is critical.

Off = System health is normal (when in standby mode).

Network Interface Card (NIC) 1 link/activity LED

Green = Network link exists.

Flashing green = Network link and activity exist.

Off = No link to network exists.

If power is off, the front panel LED is not active.

Network Interface Card (NIC) 2 link/activity LED

Green = Network link exists.

Flashing green = Network link and activity exist.

Off = No link to network exists.

If power is off, the front panel LED is not active.

20 DN70446142Issue 01B


Id:0900d80580670be9

Hardware in RNC OMS

Figure 7 Rear panel of the server

7.2 External interfacesRNC OMS interfaces:

• two 10/100/1000 Base-T Ethernet ports on an RJ-45 connector • USB 2.0 ports: 1 in front panel, 2 in back panel and 1 internal • I/O keyboard • P2/S Mouse • video • iLO 2-remote management port

7.3 Power supply RNC OMS supports AC input power with a power supply redundancy as follows:

• AC input power with auto-ranging, 100 VAC to 240 VAC, 50 Hz to 60 Hz • OMS is delivered with a redundant power supply.

Usage of UPS is highly recommended. OMS is delivered with IEC-IEC power cords. Nokia Siemens Networks services can help to arrange country-specific rack and power cable configurations.

7.4 Installation1RU high OMS can be placed to a standard 19 inch rack in well-ventilated, climate con-trolled indoor environment. The temperature of the room where the rack is located should not exceed 35oC (95oF) during operation of the server.

DN70446142Issue 01B

21

Standalone RNC OMS product description Hardware in RNC OMS

Id:0900d80580670be9

OMS can be installed in a separate rack or in an existing rack in the site provided there is enough space in it. For more information see Standalone RNC OMS hardware instal-lation quick guide and site instructions.

HP ProLiant DL360 G6 base configuration comes with three fan modules with three fan impellers on each module. They draw in cool air through the front door and reject heated air from the back door.

For proper serving and airflow conditions, the space requirements set for the equipment must be fulfilled.

Blanking panels must be used to fill empty spaces in the rack in order to assure adequate airflow and to prevent hardware damages. Also when using third party racks, you must ensure that airflow requirements set for the server are met.

Product installation documentation will provide more information of requirements, like safety, electrical grounding and electrostatic discharge arrangements.

22 DN70446142Issue 01B


Id:0900d80580670a2b

RNC OMS site architecture

8 RNC OMS site architecture

8.1 OMS at RNC siteIn RU20 release standalone OMS can be installed in the own separate rack or in the same site with RNC if there is a free space.

Figure 8 OMS located at RNC site

The RNC OMS provides two LAN-RJ45s with 10/100/1000 Base-T Ethernet network interfaces. OMS can be connected through an Ethernet switch or router to provide accessibility for RNC.

DN70446142Issue 01B

23

Standalone RNC OMS product description RNC OMS site architecture

Id:0900d80580670a2b

Figure 9 Rack installation space

Note also other environmental requirements for OMS from section Environmental infor-mation in Technical specifications for RNC OMS.

Clearance distance

63,5cm (25 inches) In front of rack

76,2cm (30 inches) Behind the rack

121,9cm (48 inches) From back of the rack to back of another rack or row of racks

Table 2 Space requirements for RNC OMS

24 DN70446142Issue 01B


Id:0900d80580670a2b

RNC OMS site architecture

Figure 10 Secure interfaces with standalone OMS

DN70446142Issue 01B

25

Standalone RNC OMS product description Technical specifications for RNC OMS

Id:0900d80580670f10

9 Technical specifications for RNC OMS

9.1 Dimensions and weights

9.2 Power

9.3 Environmental information

9.3.1 Temperature and humidity

Dimensions

Height 4.32 cm (1.7 in)

Depth 70.49 cm (27.75 in)

Width 42.62 cm (16.78 in)

Weight (empty/fully configured) 14.51 kg (32 lb) / 17.92 kg (39.5 lb)

Input requirements

Rated input voltage 100 VAC to 240 VAC

Rated input frequency 50 Hz to 60 Hz

Rated input current At 120 VAC: 4.5 A

At 240 VAC: 2.2 A

Rated input power max. 460 W

Rated steady-state power max. 460 W

Ambient Air Temperature

Operating 10°C (50°F) to 35°C (95°F) at sea level with an altitude derating of 1.0°C per every 305 m (1.8° F per every 1 000 ft) above sea level to a maximum of 3050 m (10 000 ft), no direct sustained sunlight. Maximum rate of change is 10° C/hr (18° F/hr). The upper limit may be limited by the type and number of options installed. System performance may be reduced if operating with a fan fault or above 30°C (86°F).

Non-operating -40oC (-40oF) to 70oC (158oF). Maximum rate of change is 20oC/hr (36oF/hr).

Humidity

Operating 10% to 90% relative humidity (Rh), 28oC (82.4oF) max wet bulb temperature, non-condensing.

Non-operating 5% to 95% relative humidity (Rh), 38.7oC (101.6oF) max wet bulb temperature, non-condensing.

26 DN70446142Issue 01B


Id:0900d80580670f10

Technical specifications for RNC OMS

9.3.2 Altitude

9.3.3 Safety and Electromagnetic Conformance

9.4 RoHS StatementOperation and Management Server complies with the European Union RoHS Directive 2002/95/ EC on the restriction of the use of certain hazardous substances in electrical and electronic equipment. The directive applies to the use of lead, mercury, cadmium, hexavalent chromium, polybrominated biphenyls (PBB), and polybrominated diphenyl ethers (PBDE) in electrical and electronic equipment put on the market after 1 July 2006.

Altitude

Operating 3 050 m (10 000 ft). This value may be limited by the type and number of options installed. Maximum allow-able altitude change rate is 457 m/min (1500 ft/min).

Non-operating 9 144 m (30 000 ft). Maximum allowable altitude change rate is 457 m/min (1500 ft/min).

Product Name HP Proliant DL360 G6 Server

FCC Rating Class A

Normative Standards CISPR 22; EN55022; EN55024; FCC CFR 47,Pt 15; ICES-003; CNS13438; GB9254; K22;K24; EN 61000-3-2; EN 61000-3-3; EN60950-1; IEC 60950-1

DN70446142Issue 01B

27

Standalone RNC OMS product description Linux operating system running in RNC OMS

Id:0900d8058068e393

10 Linux operating system running in RNC OMSGeneral operating system conceptsAn operating system (OS) is the software component within a working computer that manages the hardware and allocates hardware resources to applications for use. The resources include all hardware resources, such as processor time, memory, disk access, keyboard, display, and so on. The most important task of the operating system is to manage these hardware resources as efficiently as possible.

The hardware resource management functionality of an operating system is usually implemented in a core component called the kernel. In addition to the kernel, an operat-ing system delivery often contains additional programs and libraries packaged with the operating system that users and applications may use to perform various tasks. Examples of such programs include text editors, media players, and terminal applica-tions.

The operating system in the FlexiPlatform productsThe base platform consists of a collection of components that is needed by all platform-based products. The operating system (OS) delivery is one part of the base platform together with other important components such as backup, hardware and software man-agement and the high availability services middleware. These components of the base platform are then used by the other components to offer additional services to FlexiPlat-form-based products.

The current OS delivery is the Red Hat Enterprise Linux Release 4, Update 8.

The operating system together with the base platform forms the foundation on which the other services are built. In turn, the platform is used by specific network element appli-cations to create a final customer product that is used in production networks.

The high level architecture of the FlexiPlatform with a focus on the base platform struc-ture is shown in the following figure.

Figure 11 FlexiPlatform architectural domains

28 DN70446142Issue 01B


Id:0900d8058068e393

Linux operating system running in RNC OMS

• The network element (NE) applications use the application frameworks as an exe-cution environment and they also use the various platform services through the framework’s interfaces.

• The O&M (operation and maintenance) services include alarm, license and perfor-mance management.

• The platform services include databases, naming and messaging services, as well as command line interface and web user interface frameworks, and Java platforms and services.

• The networking services include all software components that handle external traffic with application-level protocols and load balancers.

• The base platform, of which the OS is a part, includes services such as software and backup management, high availability services (HAS) and hardware management. These provide the foundation for the platform.

10.1 Operating system contentsThe operating system (OS) product includes the base kernel, kernel modules (optional low level features and drivers to be loaded as needed), and various software compo-nents provided by Red Hat and Nokia Siemens Networks. These software components are also known as userland packages. These userland packages are often referred to as RPMs (Red Hat Package Management packages).

The kernel is the entity that performs the basic OS functions. Among other things, the kernel controls processor time sharing and memory access. The kernel also handles the communication between processes.

The userland is located outside the kernel and any application running outside the kernel is known as a userland application. The main difference between applications in the kernel and applications in userland is that the applications in the kernel run in privileged mode and applications in userland run in non-privileged mode.

In privileged mode, functions and applications have unrestricted access to memory and other resources in the system. In non-privileged mode, functions and applications have limited access to resources. In this mode, the kernel takes care of which resources are allocated to each application, as well as when they are allocated. Therefore, when an application experiences resource handling problems, it cannot starve the other applica-tions of resources, as long as it is running in non-privileged mode.

Most applications run in userland and it is not possible for regular users to instruct any applications to run within the kernel. This increases the stability of the environment because no application can prevent other applications from accessing critical system resources, such as memory or processor time.

The structure of the platform OS is described in the following figure.

DN70446142Issue 01B

29

Standalone RNC OMS product description Linux operating system running in RNC OMS

Id:0900d8058068e393

Figure 12 FlexiPlatform operating system structure

The FlexiPlatform Linux distribution is not completely identical to the Red Hat Linux dis-tribution. Many RPMs that are not needed by the FlexiPlatform and its applications, but are normally contained in standard Red Hat Enterprise Linux, have been removed. This reduces the size of operating system and removes potential vulnerabilities.

Currently, the number of different Linux OS SW packages included in the FlexiPlatform OS installation package has been reduced into roughly 1/7 from the original amount of SW packages included in Red Hat Enterprise Linux Release distribution.

In addition to selected RPMs from the Red Hat distribution, the system contains roughly 100 RPMs provided by Nokia Siemens Networks to add functionality to the system. Some examples of the enhancements provided by the Nokia RPMs are:

• The watchdog feeder subsystem WDMana • Network link monitor for automatic LAN failover support

The kernel used in the FlexiPlatform is the Linux kernel version 2.6.9 with symmetrical multiprocessing (SMP). For more information on the standard Linux 2.6.9 kernel fea-tures, see Linux kernel documentation on the Internet.

10.2 Operating system securityThe FlexiPlatform OS offers all the basic security features at the OS level that any modern Linux system does. This includes connection access control, file system access control, and audit logs.

The FlexiPlatform OS also uses the latest Linux security techniques as a secure base on which to build other system components. The following list describes the most notable additional security features that Red Hat provides in Red Hat Enterprise Linux Release 4:

• Security Enhanced Linux (SELinux) provides mandatory access control (MAC) for applications. In a MAC based environment, application capabilities and privileges are set by predefined policies and enforced by the kernel. This prevents faulty or possibly hijacked applications from compromising system security and performing tasks not specifically allowed for them.In the current FlexiPlatform, the SELinux is built into the kernel but is not configured (activated) for backward compatibility.

• Exec Shield provides protection against stack, buffer, or function pointer overflows and against other types of exploits that rely on overwriting data structures or putting code into those structures. It protects against common buffer overflow attacks,

30 DN70446142Issue 01B


Id:0900d8058068e393

Linux operating system running in RNC OMS

where the attacker overflows a buffer so that it eventually overwrites the return address of the program code.The protection is provided by randomising the location of certain crucial application components so that an attacker cannot know where they are located. Thus the attacker cannot craft appropriate data to be sent to a target that is vulnerable to buffer overflow attacks.

• The Position Independent Executables (PIE) feature allows the randomisation of the location of the application itself. This requires the recompiling of applications as Position Independent Code (PIC). PIE, together with Exec Shield, provides a high level of protection against the most common attack on vulnerable software – the buffer overflow attack.

• New buffer validation techniques have been added to GCC and the glibc library to check for possible buffer consistency problems. This makes it less likely that a faulty application can be hijacked.

DN70446142Issue 01B

31

Standalone RNC OMS product description Runtime environment in RNC OMS

Id:0900d80580677f8e

11 Runtime environment in RNC OMS

11.1 Runtime environment in RNC OMSThe runtime environment defines how the platform accesses and uses disk storage and disk partitions, as well as, how the file system is structured during normal operations. The runtime view differs from the physical directory assignments due to the unified view to the applications and their configuration files.

32 DN70446142Issue 01B


Id:0900d805805ac311

11.2 Disk access in RNC OMSThe OMS accesses the mirrored storage disks (hard disk drives 1 and 2) via SCSI pro-tocol.

DN70446142Issue 01B

33


Id:0900d8058069bc42

11.3 Disk partitions and images in RNC OMSPartitioningPartitioning is a method of dividing the storage space on a disk device into sections of varying sizes. The idea behind creating partitions is that each different type of data should be contained within its own space.

Usually Linux systems allocate one partition for the base operating system, one for user data, one for applications, some for databases, and one for temporary files. The idea behind this approach is that if a user, database or application uses up too much space, it can only fill its own partition and will have little impact on other applications using other partitions. This also applies to possible file system problems because the partitions are treated as independent devices. If a file system becomes corrupted on one partition, it does not affect the other partitions.

Traditionally the partitioning of a disk has been static after commissioning and almost impossible to reconfigure after the operating system is installed.

This approach is inefficient because partitions that do not use up all of their allocation waste disk space. Also, if an application runs out of space on its partition, it usually requires much work to add additional disk space to the system, to partition this space, and to move the data from the full partition to the new partition.

Software RAIDRedundant Array of Independent Disks (RAID) is a technology that allows multiple disks to behave as a single disk. Multiple disks are used to increase performance, data reli-ability, data availability, or a combination of these.

The different configuration possibilities are defined as RAID levels. Different levels define how multiple disks are to be used to create a single logical disk.

In the FlexiPlatform, the RAID level used is Level 0+1. As long as there are four disks in the OMS hardware configuration, SW controller mirrors the contents of the two disks striped using HW controller. In the striped configuration, data is distributed among the two disks.

This improves speed, but if one disk fails, all the data is lost. To prevent such a risk, mir-roring is used. If one of the disks in the striped pair fails, the data of this RAID 0 pair is lost. The broken disk must be then replaced with another one and the data can be restored using RAID 1 mirroring. This increases data availability, as all data has an auto-mated copy on the mirror disk.

Logical volumesFlexiPlatform uses logical volumes in addition to the more traditional direct disk partition-ing. Logical volumes add a layer of abstraction between the actual disk partitions and the mount points that the OS uses to write to the disk.

In logical volume management, a disk partition or partitions from one or multiple disks (known as physical volume) are added to a volume group. This volume group is equiv-alent to a single hard disk in the traditional partitioning scheme. This is illustrated in the figure Physical volumes grouped into a volume group.

34 DN70446142Issue 01B


Id:0900d8058069bc42

Figure 13 Physical volumes grouped into a volume group

Logical volumes (equivalent to partitions) are created within the volume group. The actual physical disk partitions are irrelevant in this case as the logical volumes are mapped into the volume group instead of physical disks or disk partitions.

When volume groups are used, instead of direct disk partitions, the system becomes more flexible and requires less downtime. For example, if one logical volume within a volume group becomes full, it is possible to dynamically reduce the size of another logical volume within the volume group and increase the size of the full logical volume without downtime.

It is also possible to add additional physical volumes into a volume group. After the expansion of the volume group, the full logical volume can be expanded to use the newly available space within the volume group. This reduces downtime and enables more flexible administration of storage resources. It is even possible to replace smaller hard disks with larger disks without losing data by dynamically shrinking and expanding logical volumes.

Base platform related partitionsThe FlexiPlatform includes some partitions that are common to all FlexiPlatform based products. These are known as base platform partitions.

The platform partitions can be divided into a boot partition, image partitions and applica-tion-specific partitions.

The boot partition is duplicated (but not mirrored) in the FlexiPlatform for boot time redundancy. This partition is marked as bootable and contains the kernel images and configuration data required for a system boot via hard disk.

The image partitions are special because they contain a complete working file system for the OMS node. There are two kinds of images: the system image and local image.

The local image contains the software that makes up the base platform and does not contain any application-specific directories or software. In contrast, the system image contains the base platform software, as well as all the application-specific software.

Volume group

Physical

volume

Physical

volume

uses

Logical

volume

Logical

volume

Logical

volume

usesuses uses

Logical

volume

uses

DN70446142Issue 01B

35


Id:0900d8058069bc42

The following figure illustrates the boot partition, the image partitions and the application specific partitions of the base platform. The boot partition is not implemented using a logical volume because the partition size is not expected to change during a product’s lifetime.

Other partitions than the boot partition are created using logical volumes because differ-ent products that use the FlexiPlatform base platform have different storage needs. The use of logical volumes makes it possible to change volume sizes during the lifetime of a product as the use of the system grows.

Figure 14 Base platform partitions on hard disk drives

The following tables list the default partitions available in the FlexiPlatform single-node reference configurations. Notice that the volume groups and some of the logical volumes are not assigned partition sizes in the following reference configuration tables. It is expected that these sizes may vary between different products.

Partition use Partition number Size File system RAID level

Boot partition 1 100 MB ext3 none

Compatibility partition (used in major software upgrade)

2 5000 MB ext2 none

Physical volume for volume group 62 or volume group 63

3 LVM RAID 1

Table 3 Physical partitions (CLA node)

Hard disk drive 2

Boot partition

Volume group 63

Hard disk drive 1

Boot partition

Volume group 62

Logical volume 1

Logical volume 2

Logical volume 3

Logical volume 4

Logical volume 5

Logical volume 1

Logical volume 2

Logical volume 3

Logical volume 4

Logical volume 5

CLA local image

System image

CMF persistent data

Logs and core dumps

System backups

36 DN70446142Issue 01B


Id:0900d8058069bc42

The local and system images can both contain multiple deliveries (versions) of the appli-cation software. These deliveries are separated into their own isolated directories, away from the root directory of the local images and system images. The directory that contains the currently active SW delivery is called a system directory.

Description Logical volume name Size (MB) RAID level

Local image localimg_CLA-0 5000 RAID 1

Area for system backups

backup RAID 1

System image sysimg 30000 RAID 1

CMF persistent data cmf RAID 1

Logs and core dumps log RAID 1

Tomcat servlet engine

Tomcatplat 500 RAID 1

Performance Man-agement server

PMNG RAID 1

Table 4 Logical volumes

Description RAID metade-vice

Underlying resources

Local image CLA-0:/dev/md0 /dev/VG_62/localimg_CLA-0

/dev/VG_63/localimg_CLA-0

System image /dev/md1 /dev/VG_62/sysimg

/dev/VG_63/sysimg

CMF persistent data /dev/md3 /dev/VG_62/cmf

/dev/VG_63/cmf

Logs and core dumps /dev/md4 /dev/VG_62/log

/dev/VG_63/log

Area for system backups

/dev/md5 /dev/VG_62/backup

/dev/VG_63/backup

Tomcat servlet engine

/dev/md10 /dev/VG_62/tomcatplat

/dev/VG_63/tomcatplat

Performance Man-agement server

/dev/md11 /dev/VG_62/PMNG

/dev/VG_63/PMNG

Table 5 RAID metadevices and members (underlying resources)

DN70446142Issue 01B

37


Id:0900d805805ac333

11.4 File system in RNC OMSAs in all Linux operating systems, the chosen file system dictates a large part of the operating system functionality. The operating system provides several file systems for the platform and for the applications to use. The file systems include memory-based file systems, disk file systems, and pseudo file systems that provide access to, for example, the processes of a node.

Ext3The main disk file system of the base platform is ext3. It is a journaling file system that provides high reliability and fast recovery in case of crashes. Ext3 is a direct descendant of the widely used Linux ext2 file system. Ext2 file systems can be converted into ext3 file systems and back without data loss.

Ext3 journals both data and metadata, but this behaviour can be changed if necessary. In the base platform, ext3 works in ordered mode, where only metadata is journaled. In ordered mode, data is linked to the metadata so that the data is written to the disk before the journaled metadata. This guarantees that the consistency of the actual file system is practically at the same level as in journal mode, where also data is journaled before it is written to the disk. In ordered mode, the data is written to the disk only once, rather than once for the journal and once for the actual write. This makes ordered mode faster than journal mode.

In the base platform, ext3 is used for storing the system image and all application data including databases.

38 DN70446142Issue 01B


Id:0900d805805ac361

11.5 File system contents in RNC OMS

11.5.1 The Linux Filesystem Hierarchy StandardThe file system content is either static or variable and it follows the Filesystem Hierarchy Standard (FHS). Static directories are accessed in read-only mode to guard against undesired changes. For variable directories, the access mode is read-write to enable modifications to various configuration files, logs, databases, and other modifiable files.

The current FlexiPlatform follows the Linux Filesystem Hierarchy Standard (FHS) version 2.3 with the following exceptions:

• network boot files reside in /boot • shared configuration files reside in /opt/Nokia*/etc • shared variable data resides in /opt/Nokia*/var • node local configuration files and variable data reside in /opt/Nokia_BP/nodes

11.5.2 Access to the file systemThe OMS always accesses a specific version of the file system directory structure. This version is known as a set and is created from a system master file system structure during SW updates. This master structure is known as the staging area (SA) and is located in the /flexiserver directory of the system image partition. All the directories and files under this directory are considered as the staging area with the exception of the setmap file and the sets directory. All SW upgrades are performed relative to the staging area.

The sets directory contains snapshots (or copies) of the staging area at previous points in time. Usually, each change delivery installation of the application SW creates a new directory under the sets directory. The new directory contains a copy of the directories in the staging area after the change delivery installation. This is known as a set.

The OMS accesses its file system structure via the corresponding set-specific directory in the /flexiserver/sets directory via direct disk access. The definition for the node’s currently active set is in the /flexiserver/setmap file.

11.5.3 File system layoutThe layout of the file system within the staging area can be divided into the following three parts:

• core part • static part • dynamic part

Core partThe core part contains both the static and dynamic parts of the file system. This core (or root) of the staging area is created during commissioning. The contents of the core part do not change during the lifetime of a node.

DN70446142Issue 01B

39


Id:0900d805805ac361

Within the core part, there are certain directories which warrant a closer look.

/bootThe /boot partition contains the directories for the node for booting up the operating system via GRUB boot as well as the actual kernel images and switch blade configura-tion files. This directory is accessed via direct disk access during node bootup.

GRUB is loaded from the boot sector and its configuration file is read from the/boot/grub directory. After GRUB has initialised, it loads the appropriate OS kernel and RAM disk images.

Static partThe static part contains software subsystems and their configuration files for platform SW subsystems, 3rd party subsystems and application subsystems.

Name Content

bin Essential command binaries

boot Boot loader files

dev Device file system mount point (commis-sioning)

etc Configuration files (commissioning)

home User home directories

lib Essential shared libraries and kernel modules

media Mount points for removable media (com-missioning)

mnt Temporary mount points (commissioning)

opt 3rd party and Nokia Siemens Networks made software components

proc Kernel and process information pseudo file system mount point (commissioning)

root Root user home directory

sbin Essential system binaries

selinux SELinux pseudo file system mount point (commissioning)

sets Software set directories (not part of the staging area)

srv Data for services

sys System and device information pseudo file system mount point (commissioning)

tftpboot Network boot related files (unused)

tmp Temporary files (commissioning)

usr Secondary hierarchy

var Variable data (mainly commissioning)

Table 6 The staging area root directory structure

40 DN70446142Issue 01B


Id:0900d805805ac361

Within the static part, the directories can be subdivided into three parts:

• /opt/Nokia • /opt/Nokia_BP

• /opt/<component_name>

/opt/NokiaThe /opt/Nokia directory contains files for all the subsystems that are not part of the FlexiPlatform base platform. The contents of the directory are shown below.

/opt/Nokia_BPThis directory contains the subsystems that are part of the FlexiPlatform base platform.

Two of the subdirectories within this directory warrant special attention and are described after the table.

/opt/Nokia_BP/etcThis directory contains the global configuration files for the base platform subsystems.

Name Content

J2EE J2EE application deployment packages and scripts

JavaHelp

bin Executables for human users

etc Configuration files

lib Shared libraries for FlexiPlatform and application use

share Manual pages

<SS_name> Other files for <SS_name>

Table 7 The /opt/Nokia directory contents

Name Content

bin BP executables for human users

etc BP configuration files and subsystem specific commissioning and deployment files

lib Shared libraries for FlexiPlatform BP use or provided by BP

nodes Node local configuration and variable data files

share BP manual pages

var BP variable data

<SS_name> Other files for BP subsystem <SS_name>

Table 8 The /opt/Nokia_BP/ directory contents

DN70446142Issue 01B

41


Id:0900d805805ac361

/opt/Nokia_BP/etc/ldapfilesThis directory contains the configuration files for the directory service as well as directo-ries for LDAP configuration during commissioning (ldif_in/) and the schema defini-tions (schema/).

opt/<component_name>3rd party applications are installed in the static part of the directory tree under the /opt/ directory. This practise follows the guidelines in the Linux file system hierarchy standard.

Dynamic partDynamic directories are created during commissioning based on the node information stored in LDAP. The directories are created under /opt/Nokia_BP/nodes.

During commissioning, the contents of /etc and /var of the staging area root are copied to the _master directory under /opt/Nokia_BP/nodes. After possible modi-fications of the _master directory using SW management utilities, the node directories are generated by duplicating the _master directory to the node-specific directories. The _master hierarchy is not used by the OMS directly.

For more detailed information, see the software management documentation.

See the following figure for an example of the content under /opt/Nokia_BP/nodes directory on the staging area.

Name Content

ldapfiles LDAP schemas, and SS configuration and deployment data

node.rc SS-specific commissioning scripts that are used during commissioning

Table 9 /opt/Nokia_BP/etc directory contents

Name Content

ldif_in Deployment scripts, utilities, and definition files, and SS-specific configuration and deployment data

schema LDAP schema definitions

Table 10 /opt/Nokia_BP/etc/ldapfiles directory contents

42 DN70446142Issue 01B


Id:0900d805805ac361

Figure 15 An example of a dynamic directory hierarchy within the staging area

opt

/

Nokia_BP

nodes

etc

etc

_master

CLA-0

DN70446142Issue 01B

43

Standalone RNC OMS product description Operating system start-up and shutdown in OMS

Id:0900d805806994ba

12 Operating system start-up and shutdown in OMS

12.1 High availability services architecture in OMSThe high availability services (HAS) system architecture consists of the HAS centralised part running on the server node and consisting of the cluster manager process (HASClusterManager). In a single node deployment, the cluster manager process is running on the CLA-0 and performs no redundancy.

In the network element, the HAS centralized part controls processes via the node agent process (HASNodeAgent) running on CLA-0.

The node agent process reacts to faults of resources within the network element. In other words, it can operate also without involvement of the cluster manager process. The cluster manager only deals with faults at the node level, not recovery unit or process level. In process level, the node agent autonomously performs resource isolation within the network element by running the recovery unit repair cycle, for instance by periodi-cally attempting to restart the failed recovery unit.

Starter processWhen the network element is powered on or restarted, the operating system automati-cally starts the HAS Starter process. The Starter communicates with other parts of the HAS system and starts, stops and restarts processes in a controlled fashion.

The Starter passively supervises all the processes it has started. It notifies the node agent of abnormal process terminations. The node agent can react to the failure and for example command the Starter to restart the process.

Application supervisionThe Application Supervisor process (ApplicationSupervisor) supervises the health of HA-aware processes by listening to the heartbeat of the processes.

Redundancy modelOMS is a single node system which implies the use of the no redundancy model, only.

No redundancyRecovery groups of the no redundancy type provide node-local services. In case of no redundancy, the HAS can attempt to restart individual processes or the whole recovery unit.

12.2 Operating system start-upThis start-up sequence of the operating system (OS) is performed every time the node is started up. The start-up sequence does not require any manual intervention by the operator.

Node start-upThe starting up of the node consists of three phases. The first two phases are also referred to as the boot sequence.

44 DN70446142Issue 01B


Id:0900d805806994ba

Operating system start-up and shutdown in OMS

1. The BIOS starts automatically after the node is powered up. The tasks of the BIOS are initialising the hardware (including power-on self test to detect hardware failures) and starting the boot loader.

2. The boot loader (GRUB) loads the OS image and starts it.3. The OS initialises the system so that the high availability services (HAS) can take

control of the node.

The start-up phases of a node are illustrated in the following figure:

Figure 16 Node start-up phases

12.3 Operating system shutdownWhen the high availability services restart the node, the operating system performs a graceful shutdown. This means the following:

• the services such as cron, secure shell server (sshd), syslog-ng, and starter (HAS subsystem) are stopped,

• TERM and KILL signals are sent to all the processes, • the system clock time is saved to the hardware clock, • the file system is unmounted (or remounted in read-only mode) to prevent data cor-

ruption, • the operating system is rebooted.

Standalone RNC OMS product description - RU20 P7.pdf

Documents

Transcript of Standalone RNC OMS product description - RU20 P7.pdf