Secure operation in reparenting .1 Overview

This feature provides a new Graphical User Interface (GUI) for the Network Reconfiguration Procedure (NRP) tool. In the previous versions, each NRP procedure was described on paper. This tool eliminates the need for paper procedures.

This feature applies to version 15.0 of the BSS system. The NRP integrations in this tool are:

• BSC reparenting

• BTS reparenting

• PCU reparenting

These procedures help the user to operate and reconfigure a BSS without referring to paper procedures. This tool has the following enhancements:

• Reparenting procedures are performed using only mouse clicks, without a UNIX window. The tool executes all the steps in one procedure.

• Typing errors are minimized because the paper procedure is no longer required.

• The tool can handle error cases and fallback in real time. In previous versions, errors were displayed in the log file.

• The tool provides a simple way to configure the network with a window look and feel.

1.6.11.2 Architecture

The tool is based on the client/server architecture. A tool server is installed on each OMC-R server. The tool server uses a socket connection with a specific port number. The tool also uses Sybase client/server connections.

The tool client connects to each server to obtain information such as configuration files, etc. or to execute a script on the server. Using this architecture, the tool client can be installed on any UNIX station, even if it

is not an OMC-R station. The server/client tools enable communications between the local machine and available OMC-Rs. The tool can handle up to 4 active OMC-Rs, but it does not support a remote workstation.

1.6.11.3 Security

The server is in a listen mode at each OMC-R level via the default

communications port. This port is only authorized to handle communications between the client and server with encrypted keys. For that reason, a security tool is implemented on each machine hosting a client and/or server tools.

The security tool interacts with following tools:

• Reparenting tool: gives it encrypted keys for the administration users and remote server tools. This is done only for authorized administration users after their login using the security tool.

• Server tool: gives it its encrypted key and/or the result of the password contained in the encrypted key for validity. All communications with the server tools are dependent on the validity of the encrypted keys sent by the client tools.

All operations performed by the reparenting tool via client/server tools are indexed with encrypted keys. These keys are limited in time. Each command sent to server tool through client tool has a unique key and can not be reused.

The security tool has the following four main roles:

Administrator login security The operator must be logged-in with administrator user privileges to execute the reparenting tool procedures.

The reparenting tool connects to the security tool during the login process and the security tool displays a login window where the operator enters the administrator name and password. The security tool checks the validity of user and password and returns an administrator-encrypted key, if the check is ok. An error message is returned, if the security check fails.

Server key security To communicate with server tools, the reparenting tool must have a valid server-encrypted key per server tool. This

server-encrypted key is obtained via the security tool from the remote server.

Command send security To communicate with server tools, the commands sent by the client tools must be followed by a valid and unique server-encrypted key (one per command at a given time). The server tool executes this command, if the server-encrypted key is valid. If not, it returns an error code status to the client tool.

Managing security information The security tool is used to:

• Create users and their passwords on the local and remote machine

• Change user name or password on the local and remote machine

• Add users on the local and remote machine

• Delete users from the local and remote machine 1.6.12 Improved build online performance

The build on line improvements, introduced in V15.1, reduce the amount of time required for a BSC start-up. This start-up is required after the MIB is built.

Currently, the build on line is done in two phases:

• Phase 1: A MIB build that is done without interruption of services.

• Phase 2: A complete restart of the BSC that involves an interruption of services.

The improvements reduce the duration of the interruption of services due to the BSC restart. These improvements have no impact on the OMC-R.

The improvements include:

• restarting OMU applications (instead of resetting the OMU) to load new data from the new MIB

• restarting some components earlier in the BSC restart cycle

• reducing the number of messages exchanged during PCM configuration 1.6.13 PCUSN configuration

General Packet Radio Service (GPRS) on the BSS. The PCUSN is a separate node within the BSS which is based on a Nortel Networks Multiservice Switch,Figure 16 "PCUSN in the BSS subsystem" (page 74). It has a dedicated Operation, Administration and Maintenance (OAM) server running on a Sun Blade 150 or a Sun Blade 1500 workstation. The PCU-OAM server is connected to the OMC-R through the OMC-R LAN.

The dedicated PCU-OAM server will not be needed when the OMC-R server is upgraded to a Sun Fire^TMV880 because the PCU-OAM server functions will be transferred to it.

From V15.1, the Sun Fire^TMV890 server is used as the successor of the Sun Fire^TMV880, and the Sun Blade 1500 workstation is used as the successor of the Sun Blade 150 workstation.

The PCUSN is managed through specific software integrated in the server.

The following two software packages are utilized on the PCU-OAM server:

• MDM (Multiservice Data Management) for the configuration and the fault management functions

• MDP (Management Data Provider) for the performance management functions

The following day-to-day PCUSN operations are also integrated in the OMC-R for easy access:

• The GPRS access fault management is fully integrated within the GSM access faultmanagement. The fault and alarmmessages are forwarded in real time to the OMC-R database to be displayed on a Man--Machine Interface (MMI) workstation.

• Configuration management is accomplished with MDM hosted in the OMC-R server. It allows the operator to configure the PCUSN using an emulation window on each workstation.

• Other specific MDM applications are available on each MMI workstation to complete the integration of the functions for the GPRS PCUSN into the OMC-R server.

Figure 16

PCUSN in the BSS subsystem

The feature “WPS Introduction for PCUSN Configuration” (29818),

introduced in V16.0, replaces the configuration part of the PCU/CIQ and the PCUSN Provisioning plug-in chain.

The main features are:

• Off-line PCUSN provisioning

• On-line PCUSN creation by doing the provisioning preparation off-line

• HW configuration using a wizard and equipment model library For off-line configuration, the module runs on the CT2000 PC station. It allows the user to create and modify the PCUSN configuration. This module is called “WPS for PUCSN” and it replaces the “PCU_EngConf” tool and the “PCU/CIQ” tool.

For on-line configuration, the module runs on the OMC-R workstation connected to the PCU-OAM. This module is included on the current plug-in

“PCUSN provisioning”. It replaces the DRF to CAS converter.

The PCUSN Provisioning process contains 3 main steps:

1. Creation/Modification of the PCUSN configuration off-line

2. Generation of commands (CAS files) for PCUSN creation or modification 3. Applying modifications on the PCUSN

Step 1 is managed by WPS. Steps 2 and 3 are managed by the PCUSN provisioning plug-in

The reverse process contains 2 main steps:

1. Retrieve the current PCUSN configuration 2. Load the configuration on the off-line tool

Step 1 is managed by the PCUSN provisioning plug-in evolution. Step 2 is managed by WPS.

1.7 OMN access management

1.7.1 OMN access management for BSC 12000HC