NETACT.pdf

(1)

NetAct OSS5.2 CD Set 3 (PDF)

NetAct Configurator Principles

DN03317888

(2)

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.

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.

(3)

List of Figures

Figure 1 Configurator Overview . . . 10

Figure 2 MSC/MGW signalling object hierarchy . . . 17

Figure 3 MSC/MGW routing object hierarchy . . . 18

Figure 4 MSC/MGW analysis object hierarchy . . . 19

Figure 5 MSC/MGW connection object hierarchy . . . 20

Figure 6 MSC RNW object hierarchy . . . 21

Figure 7 MGW ATM object hierarchy . . . 21

Figure 8 MSC/MGW IP object hierarchy . . . 22

Figure 9 MSC/MGW general object hierarchy . . . 22

Figure 10 Managed objects in packet core network hierarchy . . . 23

Figure 11 Managed object hierarchy in GSM management, part 1 . . . 24

Figure 12 Managed object hierarchy in GSM management, part 2 . . . 25

Figure 13 Managed object hierarchy in BTS site configuration management. . . 26

Figure 14 Relationships between GSM and core network . . . 27

Figure 15 Managed object hierarchy in RNC RNW management . . . 28

Figure 16 Managed object hierarchy in AXC management . . . 29

Figure 17 Managed object hierarchy in FTM management . . . 30

Figure 18 Managed object hierarchy in WBTS site configuration management . . . 31

Figure 19 RNC transport layer managed object hierarchy in WCDMA management . 32 Figure 20 Relationships between WCDMA and core network . . . 33

Figure 21 I-HSPA RNW managed object hierarchy . . . 33

Figure 22 I-HSPA Adapter IP managed object hierarchy . . . 34

Figure 23 I-HSPA Adapter Signalling managed object hierarchy . . . 34

Figure 24 I-HSPA FlexiTRS (FTM) managed object hierarchy . . . 35

Figure 25 I-HSPA AXC managed object hierarchy . . . 36

Figure 26 Managed object hierarchy in LTE RNW management . . . 37

Figure 27 Managed object hierarchy in FTM management . . . 38

Figure 28 Managed object hierarchy in LTE BTS site configuration management . 38 Figure 29 Managed object hierarchy in FemtoBTS configuration management . . . 38

Figure 30 Managed object hierarchy for external cells . . . 39

Figure 31 Antenna objects . . . 40

Figure 32 CM Editor user interface . . . 46

Figure 33 Table Editor window in CM Editor. . . 48

Figure 34 CM Operations Manager user interface . . . 49

Figure 35 Workflow Engine window . . . 51

Figure 36 Command Manager window . . . 52

Figure 37 CM Analyser user interface. . . 54

Figure 38 CM Reference user interface . . . 55

Figure 39 Actual configuration data handling, collection, storing, and tools . . . 58

Figure 40 Plan-based configuration management, systems, interfaces, and flow of configuration data . . . 61

Figure 41 Interfaces and databases in the network elements used during plan provi-sioning process . . . 64

(7)

Figure 43 Actual and reference configuration auditing. . . 71

(8)

List of Tables

Table 1 Managed object related concepts . . . 12

Table 2 Managed object related concepts . . . 12

Table 3 Additional MO properties in Configurator . . . 13

Table 4 Object states and their meaning . . . 14

Table 5 Administrative states and their meaning . . . 14

(9)

1 About this document

NetAct Configurator Principles is a descriptive document which gives an overall picture of the Nokia Siemens Networks NetAct Configurator. It describes the functionalities that are available and the basic principles needed to utilise those functionalities.

This document is intended for NetAct operating personnel who manage the network parameters and configuration in GSM, WCDMA, LTE, I-HSPA, and core networks.

1.1 NetAct compatibility and capacity information

For information on NetAct system and capacity, and the compatibility between NetAct and network element releases, see the NetAct Compatibility and Capacity Information document.

1.2 Terms

(10)

2 Introduction to NetAct Configurator

NetAct Configurator is a component in the scalable NetAct framework for operating mobile networks. Configurator gives access to real-time network configuration data and provides tools to manage network configuration.

The following figure illustrates Configurator role in network development and optimisa-tion:

Figure 1 Configurator Overview

Network architecture can be functionally grouped into the access network and the core network. The access network handles all radio-related functionality while the core network is responsible for routing calls and data connections to external networks. With Configurator, the access network and core network are managed in a centralised way. The main functionalities of Configurator are:

storing the network parameters in the database data exchange with external tools

setting, modifying, viewing, and comparing network configuration data

mass modifications on the network: integrating sites, extending and optimising the network

small scale tuning of the network configuration

For more information on the used tools, see NetAct Configurator functionality. Network NetAct Configurator Actual Configuration Export /Reference Plan Provisioning Actual Configuration Upload Configurator Database Configurator Applications External Systems/Tools, Planning

Tools, Performance Reporting Tools, Optimisation Tools

NetAct Common Topology

Plan Import

(11)

NetAct Configurator basic concepts

The basic concepts of Configurator are:

Network resources are represented as managed objects in NetAct. Configurator supports managed object classes in GSM, WCDMA, LTE, I-HSPA, and core network. For more information on managed object concept and supported managed objects in Configurator, see Managed objects.

The actual configuration refers to the current configuration of the managed network. There is only one actual configuration in the system. For more information, see

Actual configuration.

Changes to the actual configuration are implemented using plans. A plan contains a configuration change that will be performed or has been performed to the network. For more information, see Plans.

The reference configuration is a data set that describes the desired or the target con-figuration of the network for comparing it with the actual concon-figuration due to consis-tency checks. For more information, see Reference configuration.

When the network is expanded and optimised, templates offer ready-made param-eter sets for defining new managed objects in the network. Templates allow using patterns in object creation and decrease manual typing. For more information, see

Templates.

The consistency of the network parameters is vital for the optimum functioning of the network. Configurator provides rules and tools to check the consistency of the actual configuration or a single plan. For more information, see Rules.

(12)

3 Managed Objects

NetAct Configurator supports managed objects (MOs) related to radio network and core network configuration management.

The NetAct-wide concept of MO represents network resources. In the managed network, an MO represents a unique:

physical or logical network element (for example, BTS) piece of equipment (for example, AXC)

logical resource (for example, Connection Configuration)

Each MO is connected to NetAct and managed via defined interfaces.

An MO without network interface is a non-network object defined inside Configurator. Non-network objects are also used to manage the network. For more information, see

Non-network objects and parameters.

NetAct-wide concepts related to the MO identification are described in the following table:

The following NetAct wide concepts are related to managed object hierarchy: Managed Object Class

(MOC)

Defines the characteristics of the MO, such as its parameters, operations, notifications, and behaviour. Class contains infor-mation on:

the network resource type (for example, BTS) release (for example, S14)

parameter characteristics. For more information, see

Parameters.

Object instance Object instance is an identifier that, together with the MOC, uniquely identifies a child object within the scope of the parent object. The identification information is represented as Distin-guished Name.

Distinguished Name (DN)

Distinguished name uniquely identifies an MO in NetAct Topol-ogy. The DN consists of relative distinguished names of its superiors in the topology, separated by a slash (/), starting from the root object and advancing towards the managed object that is identified (for example, PLMN-PLMN/BSC-2318/BCF-1/BTS-3).

Table 1 Managed object related concepts

Concept Explanation

Topology The Managed Objects are arranged in a hierarchical structure according to the Object Model. For this reason the Topology is also referred to as the Managed Object Containment Tree. Parent Object The superior MO of a given MO within the Topology is called

the Parent Object of the given MO.

Child object Any subordinate MO of a given MO within the Topology is called a Child Object of the given MO.

(13)

In addition to NetAct managed object properties, an MO supported by Configurator has the following additional properties:

For more information on the managed object classes supported by Configurator, see: Managed objects in R4 core network

Managed objects in GSM Managed objects in WCDMA Managed objects in I-HSPA Managed objects in LTE Managed objects in FemtoBTS Non-network objects and parameters

For more detailed information on MOs and their object model, see Managed Object

Ref-erence and Database Description for NetAct Configurator.

3.1 Parameters

The basic functionality of NetAct Configurator is to define and manage parameter data in the network.

Most of the parameters are network parameters, meaning that they can be managed via network interfaces. There are some non-network parameters defined inside Configura-tor. The non-network parameters are used to facilitate network management. For example, an attached Template ID defines which pre-defined parameter set is used during object creation.

Parameter characteristics are defined in metadata for each managed object class and release. CM Editor provides tools for editing parameter data in plans or directly to the network.

Metadata defines parameter characteristics related to: Data type

Parameter names and descriptions

Context of use, for example, related network features, references to related param-eters, object creation related parameter, information on parameter modification, applicable interfaces

Parameter value, for example, range and step, default value, internal value The following common data types are used with parameters:

Property Explanation

Assigned template A particular template that has been assigned to an MO. For more information, see Templates.

Parameter values These are the managed object parameter values which should be managed by Configurator. The parameter characteristics (name, datatype, constraints and so on) are defined in Config-urator metadata.

(14)

Bitmask Enumeration Structure List

3.2 States of managed objects

Managed objects have three separate states:

Object state, only valid for NetAct, for all managed objects Administrative state, for selected objects

Operational state, for selected objects

3.2.1 Object states

The object state specifies whether the network element exists in the network or whether it exists only in NetAct. The meaning of different object states, in relation to network management, is described in the following table:

The state of a managed object is indicated by different colours in the Top-level User Interface. The state is also visible in CM Editor. For information on the colour codes, click Help Help on Colours... in the Top-level User Interface.

3.2.2 Administrative states

The administrative state shows the functional state of the network objects from the oper-ator’s point of view. The operator can by modifying the administrative state to define whether the MO can carry traffic or provide other services.

The meaning of different administrative states is described in the table below:

Object state Meaning

NON-OPERATIONAL The MO has no actual configuration in the NetAct database, indicating that the object exists in the NetAct database but not in the network.

CREATED FROM NETWORK The MO has not yet been managed with NetAct tools. The state is changed automatically into operational when it has been added to a view with Network Editor or it has been modified in the network with CM Editor or CM Operations Manager. OPERATIONAL The MO has the actual configuration in the NetAct database,

indicating that the object exists both in NetAct and in the network.

Table 4 Object states and their meaning

Administrative state Meaning

LOCKED A LOCKED MO is not allowed to carry any traffic.

(15)

The administrative state is defined only for selected managed objects: GSM - BCF, BTS, TRX, LAPD, NSVC MSC RNW - BTSM, BSCM, MGWM, MSA 2G SGSN - NSVC WCDMA - WCEL I-HSPA - WCEL LTE - LNCEL

The administrative state of the object is a modifiable parameter. The state for all managed objects can be changed by:

creating a plan for modifying the parameter and activating the plan in the network; activating a plan in network without modifications of the state parameter and letting the network element automatically take care of locking and unlocking of the required objects;

The following tools can also be used to manage the state of some managed objects: Object locking/unlocking functionality in CM Editor (GSM, WCDMA, LTE and core network)

BSC MMLs (GSM)

RNC RNW Object Browser (WCDMA) Top-level User Interface (WCDMA)

g

The administrative state of an MO has no effect on the administrative states of other MOs. For example, if the BCF is in locked status, the underlying BTSs and TRXs have the same statuses they had before the locking (locked or unlocked). However, if an MO is locked, its children do not carry any traffic either.

g

There is possibility to lock/unlock WBTS object in CM Editor application. When lock-ing/unlocking this WBTS only the WCELs that are related to that WBTS are locked/unlocked and the state of the WBTS is not changed.

3.2.3 Operational states

The operational state shows the functional state of certain network objects from the SHUTTING DOWN In GSM, a BTS with the status SHUTTING DOWN does not

accept any new calls. This means that, within a user-specified time limit, the BSC attempts to clear all the traffic in the BTS which is shut down by handing the calls over to other BTSs. Once the traffic is cleared, the BTS is put into the status LOCKED. The calls that cannot be handed over within the time limit are dropped.

In WCDMA and I-HSPA, the basic principle is the same, except that the WBTS takes care of clearing the traffic.

UNLOCKED An UNLOCKED MO may carry traffic.

Administrative state Meaning

(16)

WCDMA - WCEL I-HSPA - WCEL LTE - LNCEL

The operational state is a non-modifiable parameter that can be viewed with the follow-ing tools:

MML, which can be launched also from CM Editor using ZEEI (GSM) CM Editor (WCDMA, I-HSPA)

RNC RNW Object Browser (WCDMA)

3.2.4 Administrative / Operational states for core network objects

Core network objects do not have separate parameters for administrative and opera-tional states. A state parameter can be modified both by the operator and the network element. The state set by the network element overrides the user settings, for example, if the network element is blocked because of some failure in the system.

For more detailed descriptions on the states for R4 core network, see MSC/HLR product documentation set.

3.3 Managed objects in R4 core network

The following figures illustrate the managed object classes that are included in the MSC and MGW management:

(17)

(18)

Figure 3 MSC/MGW routing object hierarchy PLMN MSC/MGW MSC ROUTES MGW MSC/MGW GSMEND SDEST ROU IMHO MFWDP DEST MFWDP PAD HLRENQ NMOD ANN ANNP FACC SIPEND CC ANNF SFILE MFWDPDTMF MFWDPDDTMF MFWDPNAT MFWDPDNAT

(19)

Figure 4 MSC/MGW analysis object hierarchy PLMN MSC/MGW ANALYS AREASN PREA IMSIA PLMNP SMSADA SMSROA TREE MSC MSC/MGW EC DIGITA CBASSC CBAODC DPCAA ATTSA DPREA EAAR EOSR FR AIR GTAA INR SAEP RR RG EOSAP WEBSR SRVRES

(20)

Figure 5 MSC/MGW connection object hierarchy PLMN MSC/MGW MGWIC MGWP MGWC UPDAD USUBAN UFRES CGR MGWDP CONNR4 MSC MGW MSC/MGW H248LBS H248UP HPMU LBSU MFWDP VMGWCR SIPLBS SOCKET SPMU SPTDM RTDM SCTTI

(21)

Figure 6 MSC RNW object hierarchy

Figure 7 MGW ATM object hierarchy PLMN IMAG TCTT RNNI UNI VPTT TRDE XCON A2UT VCCT MGW ATM VPCT ACCP SVTT

(22)

Figure 8 MSC/MGW IP object hierarchy

Figure 9 MSC/MGW general object hierarchy

MML object provides MML support for parameters/objects not included in the

MSC/MGW object model. MML object is a planned object only. The parameters in the MML object can be planned and provisioned using normal plan management tools and processes.

(23)

3.4 Managed objects in packet core network

The following figure illustrates the managed object classes that are included in the 2G SGSN management:

Figure 10 Managed objects in packet core network hierarchy

3.5 Managed objects in GSM

3.5.1 Managed objects in BTS RNW configuration

The following figure illustrates the managed object classes included in BTS RNW con-figuration management. ! " # ! $ ! % & ! ' " ! ( # ) * % * ) + , - " ' ( $ ! $ ! . ) * ' "

(24)

(25)

Figure 12 Managed object hierarchy in GSM management, part 2

The following figure illustrates the managed object classes that are included in the GSM management:

In NetAct, the BCF represents physical base station equipment, which is made up of one or more BTSs, depending on BTS generation and configuration. The BTS represents a cell. Under each BTS, there is at least one TRX and two other units, HOC and POC. The HOC and POC represent the parameters the BTS uses when making handover and power control decisions.

Multi-BCF Control utilises an architecture and radio network object called a segment. The segment object is essentially the same as the telecom cell. A segment can consist of several BTS objects. A BTS in a segment is a group of similar TRXs. A segment can also consist of only one BTS in its simplest form. The BSC supports segment configu-rations of up to 36 TRXs and 32 BTSs.

The segment object is not supported in NetAct Configurator. Configurator tools visualise the segment's master BTS and the other BTSs. It is possible to manage multi-BCF related parameters. For more information, see Configuring GSM/EDGE features.

3.5.2 Managed objects in BTS site configuration

The following figure illustrates the managed object classes included in BTS site config-uration management.

(26)

Figure 13 Managed object hierarchy in BTS site configuration management

3.5.3 Relationships between GSM and core network

The following figure illustrates the relationships between GSM and core network managed object classes:

(27)

Figure 14 Relationships between GSM and core network

3.6 Managed objects in WCDMA

The managed objects in WCDMA are divided into the following management categories: RNC RNW, AXC, FTM, WBTS site configuration and RNC transport (ATM/IP).

3.6.1 Managed objects in RNC RNW

The following figure illustrates themanaged object classes that are included in RNC RNW management: * % * ) & / ( $ " " & 0 1 2 3 ( $ " & / ) 4 ( $ - * " - " + ) * ' " * % * # , ) 4 ' ( $ ! $ ! . ! $ ! % * % * ) + , - " ) * ' " - * " & / - * " 0 & / * % * ) & / ) * ' ( - * " # + , - " - * " 0 & / - 5 * ( $ - 5 * # & ! ' " # * "

(28)

Figure 15 Managed object hierarchy in RNC RNW management

3.6.2 Managed objects in AXC

The following figure illustrates the managed object classes included in AXC manage-ment:

(29)

Figure 16 Managed object hierarchy in AXC management

g

AXC can be either a standalone object under PLMN or embedded under a WBTS. Both have the same child objects. See figure Managed object hierarchy in RNC

RNW management.

3.6.3 Managed objects in FTM

The following figure illustrates the managed object classes included in FTM manage-SMTT SVTT FRLI SPTT TCTT TRDE VCTT AXC PPTT STPG NNDT CCFA IPNO N3MD UNIT SRTT FMAF IFPG CIWT A2NE ACCP VPCT FMAS VPTT VCCT IMAG N3CF TPEL A2ST A2UT ANBA INTP IAIF IEIF IPRT ISPF IHCP IPRM PWNE ETHLK PWMP PWTIP BFD QOS TMPAR TOPIK MODUL IVMP IVIF

(30)

Figure 17 Managed object hierarchy in FTM management

3.6.4 Managed objects in WBTS site configuration

(31)

con-Figure 18 Managed object hierarchy in WBTS site configuration management

3.6.5 Managed objects in RNC transport layer (ATM/IP)

The following figure illustrates the RNC transport layer managed object hierarchy in WCDMA management.

(32)

Figure 19 RNC transport layer managed object hierarchy in WCDMA management

3.6.6 Relationships between WCDMA and core network

The WCDMA objects must be acknowledged by the core network elements, for example, to locate users in the cells, perform hard handovers and paging. The following figure illustrates the managed object hierarchy in the 3GPP MSC:

(33)

Figure 20 Relationships between WCDMA and core network

3.7 Managed objects in I-HSPA

The following figures illustrate the managed object classes that are included in I-HSPA management:

Figure 21 I-HSPA RNW managed object hierarchy

MGW ID, MGW name LAC NWLA MSA MGW RNW RNC ID, MCC and MNC added to MGWM SAC (Service Area Code) and LAC WBTS RNC MGWM LA WCEL MSC 4 ( " * 6 4 - 5 * & . , & . ! * & . " * & ! 7 # 8 9 ! * 8 9 ! & + # " * + # " & ! ( # ) & $ / $ $ / : & $ / : * " # 9 -4 " 6 ( 4 * # ( " 8 9 ! % + # " % $ / : % & ! )

(34)

-Figure 22 I-HSPA Adapter IP managed object hierarchy

Figure 23 I-HSPA Adapter Signalling managed object hierarchy

PLMN IADA IPRT IEIF IDNS IAIF IPNO ISWTP * ) 4 9 * ! * " " ! * " " ! * * " " ! * -/ * ! * " " ! * " " ! * * " " ! ( -* " " ! ! * . & ! * ( $ * * 6 $ * * 9 # * 6 , ' * , * & ! * ( * $ * * ! & $ / $ ! ( # )

(35)

Figure 24 I-HSPA FlexiTRS (FTM) managed object hierarchy FTM WBTS PLMN UNIT PPTT SDHIF ETHLK IMAG SYNC STPG TRDE TCTT VPCT ACCP IADA VPTT CCFA VCTT ANBA A2NE IPNO VCCT CERTH FRLI INTP IEIF IPRT IHCP IPRM TOPIK QOS BFD TMPAR IAIF

(36)

Figure 25 I-HSPA AXC managed object hierarchy

3.8 Managed objects in LTE

The following figures illustrate the managed object classes that are included in LTE * # 5 5 * ' 5 5 + , ( & * ! 5 5 5 " 5 5 5 , / 6 ' " 5 5 $ ; " ! ! 5 5 * 5 ! % ) ) / 5 " " + $ & ! ) 9 ) < # / . ) & 5 * , 5 5 + # $ + & + ! % " & 4 5 $ = ) 6 $ " " ! ' ! " 5 + # $ * ' ! 5 5 ' " " 5 & # $ % ) < " + 5 ! 6 ( $ = * 5 $ = . 5 $ ) - $ & ) 5 ! & $ & + & 6 & + & ! , 5 & * ! + & 8 " ! & ! , # ! 4 ) 6 6 5 8 ( > ! 4 # ! ! 4 5 & ! - + / 7 9 * 5 # ! $ , 5 9 ! & > # 9 / . ( 4 - 5 * & $ / $ ! ( # )

(37)

3.8.1 Managed objects in LTE RNW

The following figure illustrates themanaged object classes that are included in LTE RNW management:

Figure 26 Managed object hierarchy in LTE RNW management

3.8.2 Managed objects in FTM

The following figure illustrates the managed object classes included in FTM manage-ment:

(38)

Figure 27 Managed object hierarchy in FTM management

3.8.3 Managed objects in LTE BTS site configuration

The following figure illustrates the managed object classes included in LTE BTS site configuration management

Figure 28 Managed object hierarchy in LTE BTS site configuration management

3.9 Managed objects in FemtoBTS

The following figure illustrates the managed object classes included in FemtoBTS con-figuration management.

(39)

3.10 Non-network objects and parameters

Non-network objects and parameters cover managed object classes and parameters that are not supported in the network interfaces (Q3, MML, NWI3). Non-network param-eters are stored in the NetAct Configurator database and can be viewed and managed using the Configurator tools. Non-network parameters can be planned, imported, and exported in the same way as other network configuration data. Non-network parameters are automatically saved into the actual configuration at the same time when the plan is provisioned. Non-network parameters can also be saved into the actual configuration, using Send to Network functionality in CM Editor.

g

A plan must be provisioned even if it contains only non-network parameters. The non-network objects and parameters are used to manage the following network configuration data: external cell objects, antenna objects, site object, and managed object specific non-network parameters. The managed object specific non-network parameters contain, for example, various identification parameters. The non-network parameters are listed in Adaptation Information Browser in NetAct category.

Templateid and siteID are common non-network parameters for all managed objects and are not listed in Adaptation Information Browser.

3.10.1 External Cell Objects

Foreign BTSs and External WCDMA Cells (EWCE) are used for managing adjacencies between regions.

The foreign BTS object represents a BTS managed by another network management system. In the managed object hierarchy, a foreign BTS is not an object class of its own. The foreign BTS DN is PLMN-PLMN/BSC-0/BCF-0/BTS <id> where id is LAC CI (the first 5 digits are reserved for LAC).

The EWCE represents the WCEL managed by another network management system. In the managed object hierarchy, the EWCE is an object class of its own. The EWCE DN is EXCC-1/EWCE <id> where id is a string with a maximum length of 10 characters. For more information on inter-regional adjacencies, see Managing Adjacencies. The following figure illustrates the managed object hierarchy for external cells:

External GSM cell objects: BSC-0, BCF-0, BTS (foreign BTS), TRX-1.

External WCDMA cell objects: EWCE (External WCDMA Cell) and EXCC (External WCDMA Cell Collection).

EXCC EWCE PLMN BTS BSC-0 BCF-0

(40)

3.10.2 Antenna objects

The antenna objects include ANTC (Antenna Collection), ANTE (Antenna), GCAL (GSM Cell-Antenna Link), and WCAL (WCDMA Cell-Antenna Link).

ANTE represents the base station antenna. GCAL and WCAL represent the feeder cables, and also the relationships to GSM and WCDMA cells.

The following figure illustrates the antenna objects:

Figure 31 Antenna objects

3.10.3 Site object

The SITE object is a way of storing the geographical location of the managed objects in GSM, WCDMA, I-HSPA, and core networks. Site objects are created, deleted, and modified with CM Editor which also provides user interface for assigning and removing managed objects in a site.

Coordinate information for GSM BTSs can also be stored in the parent BCF and, in the case of the foreign BTS, for the object itself.

3.10.4 Maintenance Region

Maintenance Region (MR) is a non-network object identified by maintenance region ID. Giving a maintenance region a name parameter is not obligatory. Maintenance regions are managed (created, modified, and deleted) with CM Editor. Maintenance regions are modified by assigning and removing managed objects. For more information, see

Managing maintenance regions in CM Editor Help. For more information on

mainte-nance region concept, see Maintenance Region in System Administration Principles.

ANTC ANTE

GCAL WCAL PLMN

(41)

4 Concepts for managing configuration data

This chapter describes the following basic concepts of NetAct Configurator:

Actual configuration Plans Reference configuration Templates Site Templates Rules

4.1 Actual configuration

The actual configuration represents the current network configuration. There is only one actual configuration stored in the database. The actual configuration is stored partly in the NetAct Configurator database (parameter data) and in the NetAct common topology database (object data).

The actual configuration comprises of the following:

Managed objects, location in topology, and object identification in topology data-base.

Parameter values in Configurator database:

Parameters with interface from Configurator to network element.

Non-network parameters and non-network objects without a management inter-face from Configurator.

Object administrative state (locked, unlocked) in topology database. Object state (operational, non-operational) in topology database.

Non-operational objects are stored in the topology and they are not part of the active network. The non-operational objects may have been planned for future use, or they have been deleted from network.

For more information, see Maintaining up-to-date picture of the network.

4.2 Plans

A plan is a configuration containing a set of modifications for the actual configuration. Plan contains only modifications and it can be viewed on top of the actual configuration. Plan can include the following types of modifications:

Add new managed objects with mandatory parameters (create operation). Remove an existing managed object (delete operation).

Modify parameters (including administrative state) of an existing managed object in a certain configuration (update operation). The distinguished name or version cannot be modified using a plan. Modifying parameters of some future version of managed object in target configuration is not possible.

There can be four possible kind of plans differ from each other by the purpose for what they were created.

(42)

Temporary plans - these plans are related to different kind of operations.

Exception plans - these plans are related to the Policy Based Compare feature, for example, checking the actual configuration against templates and creating correc-tive delta plans. Exception plans also defines objects with exceptions to template parameters (differences that should be kept unchanged).

For more information, see Configuring the network using plans.

4.2.1 Constraints for naming plans, templates and site templates

When naming plans, templatesand site templates, remember that some special charac-ters are not allowed. The following table lists the illegal characcharac-ters in plan, template names and site templates:

4.3 Reference configuration

The reference configuration is stored in the system as a separate data set from actual and planned configurations. Reference configuration can describe the desired configu-ration that should be kept in the network, but it can also describe the target configuconfigu-ration of the network. For both cases it is possible to find out if there have been changes in the actual configuration in the network, and if the changes are valid and expected.

For more information, see CM Reference Help.

4.4 Templates

Templates define a collection of parameter values for a particular managed object class. Templates are used for two purposes:

They define managed object parameters for new planned (CREATE) managed objects that define how the object should behave. Parameter values in plans override the corresponding value provided by the assigned template.

They identify the object’s type, for example, pico, micro, and macro for BTS. This

Description Character Exclamation mark ! Quote " Apostrophe ’ Accent mark ´ Semicolon ; Scandic å Scandic ä Scandic ö Space

(43)

objects. For this purpose, the template can be assigned both for new planned (CREATE) and existing actual managed objects.

There are two types of templates: user and system templates.

4.4.1 System templates

There is a single system template supporting the latest network element version for each managed object class. The system template values are defined according to the latest release of the network element. Versioning of templates is not supported in system tem-plates. These templates are provided as part of NetAct Configurator and they cannot be edited by users.

4.4.2 User templates

Multiple user templates can exist for a single managed object class or there can be none. A user template only contains values that differ from the system template as the system template is always automatically used under the user template to provide all missing values.

4.4.3 Using templates

A template is primarily used to define an initial parameter set for a new managed object by assigning a template to the object. The user can define assignments for each planned object manually in CM Editor. Assignment information can also be imported as part of the plan into NetAct Configurator using CM Operations Manager. The assignment is shown as the name of the template in user interfaces. Values from the assigned template for new managed objects are automatically utilised by CM Analyser, CM Editor, and CM Operations Manager the same way as they would have been defined directly in plan.

Template assignment is non-network data for the managed object. When the plan is pro-visioned, the defined template assignment is stored into the actual configuration. For working with non-network data, see Non-network objects and parameters.

If no template is assigned for the managed object with create operation, values for all mandatory parameters must be defined manually for that object in the plan.

In case of adjacencies, templates are assigned based on adjacency source and target cell template names. Therefore, the user must create adjacency templates according to this pattern.

In case the existing source and target cells do not have templates defined, the templates can be assigned for the existing cells. Parameters of the cells are not overwritten, only the object is associated with the template. The adjacencies created afterwards can then utilise the source and target cell based templates.

In case of GSM adjacencies, it is possible to let the system assign template automati-cally based on cell type definitions. Cell type based template assignments are config-ured in the Configurator configuration file $ETCROOT/rac/conf/rac_celltype.cf. If cell types are not used, the source and target cell template names are used to con-struct the name of the adjacency template.

(44)

It is possible to define several structures for a structure parameter in a user template. In one structure each attribute may or may not have a value in the user template. When working on the plan, it is possible to enter the planned value for some attributes in a structure and leave some attributes without a value. In this case, if a user template is assigned to the object, the missing values are picked up from the user template when provisioning the plan.

4.4.4 Administering templates

User templates are created and modified using CM Editor. New templates can also be defined in XML files and imported into NetAct Configurator using the CM Operations Manager tool. Only user templates can be modified and imported by the user. With CM Editor and CM Operations Manager the user can also delete templates that are not used. Deletion of a template is only possible if it is not assigned to any managed object in the plan or in the actual/reference configuration. Renaming existing templates is not currently possible. For list of naming rules for plans and templates, seeConstraints for

naming plans and templates.

4.5 Site Templates

Site Template mechanism allows user to create and store models of different base station configurations and to use these model configurations when generating the needed full configuration data for a new base station.

The purpose of the feature is that the user needs to define only a few mandatory param-eters for a new base station, and the rest of the configuration is automatically generated by the Configurator System. Scope of managed objects and their parameters included in the Site Templates can be defined by the user.

Site Templates can be generated from the Actual Configuration or from the Planned Configuration. Site Templates are applicable only for Flexi Multiradio BTS in LTE mode.

4.6 Rules

During network configuration planning and plan data building, many types of constraints and dependencies need to be noted and taken care of. The risk that new erroneous or incomplete plan harms network functioning after activation to network elements needs to be minimised. NetAct Configurator rules and check functionality by CM Analyser can be used for that purpose.

Configurator contains predefined rule sets that can be used in different procedures with network configuration. Also new rules can be added and tailored into the system by the user. Rules can be collected into rule sets. The sets must contain an appropriate selec-tion of rules that can be meaningfully executed at the same time. Rule or rule set exe-cution is called a check in CM Analyser.

The target of the check can be an actual network configuration, reference configuration or a plan that is edited or built using, for example, CM Editor.

Erroneous objects and violations are shown to the user in the user interface for correc-tive actions. In some cases, the correction or addition is straightforward, and CM Analyser is able to add automatic corrections to the plan.

(45)

5 NetAct Configurator functionality

NetAct Configurator supports network development and optimisation with the following optional functionalities:

2G Configurator 3G Configurator I-HSPA Configurator

R4 core network Configurator 2G Rehosting

3G Rehosting

Consistency checking Plan Actual Compare

XML Interface for Configuration Management Data CSV Interface for Configuration Management Data 3GPP CORBA Bulk CM (If-N) Northbound Interface RNC ATM and IP Parameter Management

FTM Parameter Management. AXC Parameter Management Workflow engine

Actual and Reference Configuration auditing

Configurator must be installed to use the Optimizer, Open API, or Automated Optimiza-tion SoluOptimiza-tion modules. For more informaOptimiza-tion, see Optimizer Principles.

5.1 CM Editor

CM Editor provides intuitive parameter editing, both in minor parameter modifications and mass modification purposes.

(46)

Figure 32 CM Editor user interface

CM Editor functionality includes the following operations: Managing plans:

Creating, modifying, and deleting plans

Creating, and mass creating of managed objects, editing, and mass editing parameter values of managed objects

Managing the actual configuration: Viewing actual network configuration

Send to Network for GSM and core network, and Direct Activation for RNC func-tionalities for modifying objects directly in the network. For more information, see Managing objects one by one

Managing administrative states of GSM, WCDMA, LTE and core network objects. For more information, see Administrative states

Uploading BCF objects and children

Managing GSM routing areas: uploading and downloading Routing Area IP Addresses from/to DNS

Managing the reference configuration

Managing planed and actual configuration with Table Editor Managing templates:

Creating and deleting templates Editing templates

Managing site templates:

(47)

Managing maintenance regions Visualisation for:

GSM Multi-BCF for Master BTS and BCCH TRX Locked objects

Related objects

Supporting all objects and parameters in search and modify/search criteria. Note that complex SQL search, or MO query, can load the data server, and this affects NetAct. For more information on MO Query, see Appendix: Available search queries

in CM Editor in CM Editor Help.

Configurable editor views for parameter editing

Controller filtering based on the controller maintenance region information For more information, see CM Editor Help.

5.1.1 Table Editor

Table Editor tool in CM Editor provides additional means which facilitate and speed up the managing of planed and actual configuration. Unlike in classic plan and actual con-figuration management, where only one object's parameters can be seen and managed at the same time, Table Editor allows you to view and manage number of managed objects (of the same class) and their parameters simultaneously, by presenting them as a table. Each row in the table represents one managed object and its parameters (one parameter per each column).

Presenting multiple objects and their parameters in the single table allows you to take an overall look at the parameters of bigger part of the managed network, as well as com-paring and modifying managed object's parameters much faster.

Beside basic operations that can be performed on managed objects (creation/dele-tion/modification), Table Editor provides additional functions, which facilitate objects and parameters management, for example, filtering. Filtering function allows you to specify filtering criteria against selected column, so only the managed objects fulfilling the criteria are displayed in the table.

Table Editor uses the editor views defined in CM Editor. Using the views significantly improves the readability of the view since you can divide and group the parameters into categories.

(48)

Figure 33 Table Editor window in CM Editor

5.2 CM Operations Manager

The overall function of the CM Operations Manager is to transfer configuration data between planning tools, NetAct Configurator, and the network. It provides both real-time feedback and history information on the operations.

(49)

Figure 34 CM Operations Manager user interface

CM Operations Manager functionality includes the following operations: Provisioning plans to the network:

Preparing, pre-activating, activating Validating BSC

Queuing for RNC provisioning and BSC file-based provisioning Scheduling provisioning operations

Generating and activating backup plans Falling back the RNC database

Managing actual configuration: Uploading actual configuration Queuing for BSC file-based upload Scheduling upload operations Exporting actual configurations Managing plans:

Creating and deleting plans

Importing and exporting network plans

(50)

Creating plans on top of reference configuration Managing templates:

Deleting templates

Importing and exporting templates Managing site templates:

Deleting site templates

Importing and exporting site templates Rehosting GSM BTS Sites

Rehosting WCDMA BTS Sites (3G Rehosting Wizard) TRX Loop test

Managing the operation execution with the workflow engine Visualising MML commands for R4 core network

Executing MML commands and MML command files for R4 core network and SGSN Managing networks elements as a user defined groups in Command Manager For more information, see CM Operations Manager Help.

5.2.1 3G Rehosting Wizard

3G Rehosting Wizard is a functionality included in the Rehosting WCDMA BTS Sites tool, which facilitates and speeds up the execution of the WCDMA BTS sites rehosting operations. It enables faster rehosting preparation by minimising the number of param-eters to be entered. The 3G Rehosting Wizard guides you step by step through the defining rehosting parameters process for each BTS site to be re-hosted. For each BTS site you need to specify only the parameters that are changing during the rehosting process. You can change the default set of the rehosting parameters to be specified and their names shown in the user interface by defining your own Rehosting Wizard XML file. 3G Rehosting Wizard starts automatically when you drag and drop or copy and paste the WBTS(s) to be re-hosted from the CM Editor to the Rehosting dialog in the CM Oper-ations Manager.

For instructions on how to use the WCDMA BTS Sites tool and 3G Rehosting Wizard,

see CM Operations Manager Help.

For instructions on how to perform the WCDMA BTS sites rehosting, see Rehosting

WCDMA BTS Sites.

5.2.2 Workflow engine

Workflow is a configurable workspace, executed from CM Operations Manager, where operator-specific tasks can be defined and executed in a user-friendly manner. Workflow engine controls the operation execution and takes care of the operation feed-back. The purpose of workflow engine is to simplify and speed up the execution of pro-cesses which consist of number of operations, for example, export, import, download, upload, provisioning, and automated plan generation.

Nokia Siemens Networks provides the following ready-made operation workflows: Reconfiguring Transport for IP-based Iub

(51)

Depending on the workflow execution, you can select the appropriate network elements to which you want to apply desired workflow.

The workflow definition contains a list of operations to be executed to complete a task. You can execute each operation defined in the selected workflow separately. After exe-cuting each operation, you can monitor its progress, and when it is completed, you can see the feedback of the operation.

Apart from the ready-made operation workflows provided by Nokia Siemens Networks, you can create/define new workflows tailored for your specific needs. The workflow is created as an XML-formatted operation definition list file.

For more information on workflow engine, see CM Operations Manager Help.

Figure 35 Workflow Engine window

5.2.3 Command Manager window

Command Manager window in CM Operations Manager provides a convenient and fast way to execute commands to MSC, MGW, SGSN, GGSN ang FING. It allows you to perform the following operations:

(52)

The output of the executed command or command file can be viewed in the Command Manager window and exported to a file.

The user can also schedule the command execution to be performed at a specified time. Command Manager allows to manage network elements as a user defined groups for faster command execution on several network elements at one time. There is also pos-sibility to execute command at once on more than one group at one time.

For more information, see CM Operations Manager Help.

Figure 36 Command Manager window

5.2.4 Operation statuses in CM Operations Manager

CM Operations Manager provides the information on the statuses of the operations and operation groups that the user has executed using CM Operations Manager. The oper-ation group is, for example, plan provisioning, while the operoper-ation is a plan provision to a specific network element (e.g. BSC). It means that operation group consist of number

(53)

operation groups are visible in the Operation History tab of the CM Operations Manager user interface.

The following operation (or operation group) statuses are possible:

Started - RAC Operation Service has created a new operation (and group) to the NetAct Database.

Ongoing - The operation execution has been started.

Finished - The operation has been completed without errors. The possible warnings can be checked from operation feedback.

Failed - The operation has failed. The reasons for the failure are described in oper-ation feedback.

Interrupted - The user has interrupted the operation, which has been in Started or Ongoing state.

Interrupting (only for operation group) - The user has interrupted the operation group, but operations which cannot be interrupted will be executed normally and will go to Finished or Failed state.

Queuing - The operation has been put to a queue.

The operation or operation group status is updated to the CM Operations Manager user interface every time the operation status changes. The status information is also saved to the NetAct Database.

For more information, see CM Operations Manager Help.

5.3 CM Analyser

CM Analyser is the tool for checking the consistency rules in radio network and core network parameters and managed objects.

(54)

Figure 37 CM Analyser user interface

CM Analyser functionality includes the following operations:

Checking radio network and core network parameters and managed objects, and ensuring that the parameters are defined according to consistency rules

Checking for discrepancies in actual configuration, planned configurations and in reference configuration

Autocorrection: defining a rule for automatic inconsistency correction For more information, see CM Analyser Help.

5.4 CM Reference

CM Reference is the application for generating, visualising and solving differences (deltas) that exist between the reference configuration and the actual configuration.

(55)

Figure 38 CM Reference user interface

CM Reference functionality includes the following operations: Generating deltas

Selecting and visualising deltas Analysing deltas

Initializing reference

Copying the Distinguished Names of managed object deltas

Committing changes to the network and to the reference configuration For more information, see CM Reference Help.

5.4.1 Actual and reference configuration auditing

Actual and reference configuration auditing manages the possible deviation between the current configuration and the planned reference configuration. It helps in finding elements configured wrongly, and provides a delta-plan-based option for implementing changes in the network or to the reference.

It is also possible to identify configuration or topology changes in the actual network, when important definitions such as adjacent cells have been deleted. Adjacencies can

(56)

5.4.2 Initializing reference

Actual and reference configuration is strictly connected, this functionality allows to add new MO(s) from the actual configuration in CM Reference to the reference configuration that is visible in CM Editor application. This allows to store MO(s) in reference configu-ration as a backup configuconfigu-ration or for later use in planning the actual configuconfigu-ration. For more information, see CM Reference Help and CM Editor Help.

5.5 Command Line Interface (CLI)

The following operations can be started from the command line interface: Uploading actual values

Exporting and importing plans, actuals, and templates Deleting plans

Comparing plans to actual configuration Provisioning plans

Validating plans

Reference configuration management Starting consistency checks

Worklfow related operations Restoring AXC, FTM configuration

Uploading actual values for GSM and downloading GSM parameters

For more information, see Command line operations in Administering NetAct Configu-rator.

5.6 Site commissioning tools: Plan Editor and Site

Configura-tion Tool

Plan Editor is used for creating commissioning data files for different network elements. For more information on Plan Editor, see Plan Editor Principles. The commissioning data files, such as site configuration files for the WCDMA BTS and AXC, can be stored in Site Configuration Tool. Using the Site Configuration Tool, you can:

store site configuration files during roll-out phase and other files, such as installation instructions and commissioning reports, in the site data repository;

exchange site configuration information of WCDMA BTSs and AXCs (WCDMA); commission I-HSPA BTS TRS and Adapter RNW parts by providing possibility to create and edit commissioning data files;

5.7 XML Interface for Configuration Management Data

NetAct Configurator provides the XML interface for planning data as an open application interface with means for seamless exchange of Radio Access Network configuration data between NetAct and external systems. Its functionality includes importing and exporting plans and templates as well as exporting the actual or reference configuration. The network configuration data is transferred using XML files. The format is RAML (Radio Access Markup Language) for Configuration Mananagement, which is a markup

(57)

are used to export data from NetAct to XML files and import data from XML files to Con-figurator database.

For more information, see XML Interface for Configuration Management Data.

5.8 CSV Interface for Configuration Management Data

NetAct Configurator provides the CSV interface for planning data as an open application interface with means for seamless exchange of network configuration data between NetAct and external systems. Its functionality includes importing and exporting plans as well as exporting the actual or reference configuration.

The network configuration data is transferred using CSV (Comma-Separated Values) files. CM Operations Manager and Command Line Interface are used to export data from NetAct to CSV files and import data from CSV files to Configurator database. For more information, see CSV Interface for Configuration Management Data. Plan Editor can be used to import files in CSV format. For more information, see Plan

Editor Help.

5.9 3GPP CORBA Bulk CM Northbound Interface

3GPP CORBA Bulk CM Northbound Interface provides a network management inter-face for integration of the NetAct Configurator regional cluster into a 3GPP-compliant network-wide configuration management system. The interface is provided for UMTS networks only and covers 3GPP common objects and parameters as well as Nokia Siemens Networks specific objects and parameters. For data exchange, standard 3GPP Bulk CM file format is used including vendor-specific data extensions to cover Nokia Siemens Networks specific objects and parameters.

(58)

6 Maintaining up-to-date picture of the network

NetAct maintains an accurate and up-to-date picture of the underlying network. The managed network and NetAct system are synchronised by using two separate methods:

Real-time updating of the NetAct database by NetAct event management. Uploading of the network configuration and parameters.

The following figure illustrates actual configuration data handling, collection, storing, and tools in NetAct Configurator:

Figure 39 Actual configuration data handling, collection, storing, and tools

* Note that there are no events from BTS, AXC and FTM (GSM, WCDMA and I-HSPA). ** Note that there are no events from RNC ATM/IP, I-HSPA IP, and I-HSPA Signalling. *** BSC S13 and S14 provide XML-based events.

6.1 Real-time updating

The network can be modified locally or using NetAct Configurator. In both cases, the changes are reported to Configurator by events. Events are generated by the network and the automatic updating is done by the event handling processes of Configurator. There are four kinds of local changes in the network elements that cause an event to be sent to Configurator:

RAML/CM 2.0

data available to other systems Proprietary interface 3GPP Bulk CM Itf-N

GSM SGSN MML NWI3 MML Q3 Q3/XML (configurable) GUI applications BSC*** NetAct Configurator RAML/CM 2.0 RAML/CM 2.0 read read Plan databuilding Plan Editor Radio planning Planning tool Optimising NetAct Optimizer External network management Management System RNC** CSV NWI3 BTS O&M WBTS FTM* GOMS NWI3 GUI/CLI file export GUI/CLI events, upload GUI/CLI upload I-HSPA IADA** I-HSPAFTM* NWI3 MSC/ MGW I-HSPA AXC* AXC* RAML/CM 2.1 RAML/CM 2.1 RAML/CM 2.1 Other tool, for example, reporting eNB NWI3 GOMS BTS*

(59)

Changing the administrative state of a managed object Changing the parameters of a managed object

g

When the adjacency creation event is received, an external cell is automatically created to the NetAct database as a target cell. This also applies when the target cell is not found during the upload.

6.1.1 Real-time updating for GSM

You can make local changes to the managed objects by using the local MML of the network elements. The BSC S14 sends events via XML interface. The BSC S13 can be configured to send events either via Q3 or XML embedded in Q3 interface, but XML embedded in Q3 interface usage is preferred one due to better performance.

There are no events from BTS site configuration. The actuals need to be updated by uploading.

6.1.2 Real-time updating for WCDMA

You can make local changes in the RNC with the RNC RNW Object Browser.

There are no events from AXC, FTM, and RNC ATM/IP. The actuals need to be updated by uploading.

6.1.3 Real-time updating for core network

There are no events from core network elements.

6.1.4 Real-time updating for I-HSPA

When making local changes in the I-HSPA Adapter RNW, the NE sends events via GOMS to NetAct.

There are no events from AXC, FTM, I-HSPA IP, and I-HSPA Signalling. The actuals need to be updated by uploading.

6.1.5 Real-time updating for eNB

When making local changes in the LTE RNW, the NE sends events via GOMS to NetAct. Events are received also after plan has been activated.

There are no events from eNB FTM objects.

6.1.6 Real-time updating for LTE GOMS

GOMS sends events for PREBTS objects that are used for auto connection.

6.2 Uploading network data

You can update the radio network and core network information with CM Operations Manager and Command Line interface using the upload operation.

(60)

you suspect for some reason that the databases in NetAct and network elements are not consistent;

local changes have been made to the GSM BTS site configuration; the BSC release is upgraded with new parameter values;

local changes have been made to the AXC/FTM configuration (WCDMA and I-HSPA);

local changes have been made to the RNC ATM/IP configuration;

local changes have been made to the I-HSPA IP or I-HSPA Signalling configuration; local changes have been made to the MSC/MGW configuration;

local changes have been made to the eNB configuration (LTE);

The status of upload operation executed by the user in CM Operations Manager can be monitored in CM Operations Manager user interface. For more information, see section

Operation statuses in CM Operations Manager.

The tool automatically updates the parameter information of managed objects and creates all the missing child objects in the NetAct database. It also deletes the actual set of those objects that are defined in the NetAct database but do not exist in the network. For detailed instructions, see CM Operations Manager Help.

For information on how the upload operation can be scheduled to happen automatically,

see Configuring the automatic upload operation in Administering NetAct Configurator.

6.3 Exporting network data

The actual or reference configuration data for radio network and core network is used as a basis for new plans in the planning tools. An actual or reference configuration can be exported from NetAct Configurator to files that are transferred into the planning tool using CM Operations Manager (in XML and CSV formats). Plans can also be exported by using CM Operations Manager (in XML and CSV formats). For more information on Interfaces, see section NetAct Configurator functionality.

The status of export operation executed by the user from command line interface can be monitored in CM Operations Manager user interface. For more information, see section Operation statuses in CM Operations Manager.

NETACT.pdf

NetAct OSS5.2 CD Set 3 (PDF)

NetAct Configurator Principles

DN03317888

f Important Notice on Product Safety

Table of Contents

List of Figures

List of Tables

1 About this document

1.1 NetAct compatibility and capacity information

1.2 Terms

2 Introduction to NetAct Configurator

3 Managed Objects

3.1 Parameters

3.2 States of managed objects

3.2.1

Object states

3.2.2

Administrative states

g

g

3.2.3

Operational states

3.2.4

Administrative / Operational states for core network objects

3.3 Managed objects in R4 core network

3.4 Managed objects in packet core network

3.5 Managed objects in GSM

3.5.1

Managed objects in BTS RNW configuration

3.5.2

Managed objects in BTS site configuration

3.5.3

Relationships between GSM and core network

3.6 Managed objects in WCDMA

3.6.1

Managed objects in RNC RNW

3.6.2

Managed objects in AXC

g

3.6.3

Managed objects in FTM

3.6.4

Managed objects in WBTS site configuration

3.6.5

Managed objects in RNC transport layer (ATM/IP)

3.6.6

Relationships between WCDMA and core network

3.7 Managed objects in I-HSPA

3.8 Managed objects in LTE

3.8.1

Managed objects in LTE RNW

3.8.2

Managed objects in FTM

3.8.3

Managed objects in LTE BTS site configuration

3.9 Managed objects in FemtoBTS

3.10 Non-network objects and parameters

g

3.10.1

External Cell Objects

3.10.2

Antenna objects

3.10.3

Site object

3.10.4

Maintenance Region

4 Concepts for managing configuration data

4.1 Actual configuration

4.2 Plans

4.2.1

Constraints for naming plans, templates and site templates

4.3 Reference configuration

4.4 Templates

4.4.1

System templates

4.4.2

User templates

4.4.3

Using templates