Net act configurator principles copy

Nokia Siemens Networks NetAct OSS5.2 CD Set 3 (PDF)

NetAct Configurator Principles

DN03317888

Issue 13-1

2 DN03317888

Issue 13-1


Id:0900d805807c3ab9

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 2010/9/27. 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.

DN03317888

Issue 13-1

3


Id:0900d805807c3ab9

Table of ContentsThis document has 79 pages.

1 About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.1 NetAct compatibility and capacity information . . . . . . . . . . . . . . . . . . . . . 9

1.2 Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Introduction to NetAct Configurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Managed Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 States of managed objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.1 Object states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.2 Administrative states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.3 Operational states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.4 Administrative / Operational states for core network objects . . . . . . . . . 16

3.3 Managed objects in R4 core network. . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4 Managed objects in packet core network. . . . . . . . . . . . . . . . . . . . . . . . 23

3.5 Managed objects in GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.5.1 Managed objects in BTS RNW configuration. . . . . . . . . . . . . . . . . . . . . 23

3.5.2 Managed objects in BTS site configuration . . . . . . . . . . . . . . . . . . . . . . 25

3.5.3 Relationships between GSM and core network . . . . . . . . . . . . . . . . . . . 26

3.6 Managed objects in WCDMA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.6.1 Managed objects in RNC RNW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.6.2 Managed objects in AXC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.6.3 Managed objects in FTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.6.4 Managed objects in WBTS site configuration . . . . . . . . . . . . . . . . . . . . 30

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

3.6.6 Relationships between WCDMA and core network . . . . . . . . . . . . . . . . 32

3.7 Managed objects in I-HSPA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.8 Managed objects in LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.8.1 Managed objects in LTE RNW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.8.2 Managed objects in FTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.8.3 Managed objects in LTE BTS site configuration . . . . . . . . . . . . . . . . . . 38

3.9 Managed objects in FemtoBTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.10 Non-network objects and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.10.1 External Cell Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.10.2 Antenna objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.10.3 Site object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.10.4 Maintenance Region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Concepts for managing configuration data . . . . . . . . . . . . . . . . . . . . . . 41

4.1 Actual configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2 Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2.1 Constraints for naming plans, templates and site templates . . . . . . . . . 42

4.3 Reference configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.4 Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.4.1 System templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.4.2 User templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4 DN03317888

Issue 13-1


Id:0900d805807c3ab9

4.4.3 Using templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.4.4 Administering templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.5 Site Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.6 Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5 NetAct Configurator functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1 CM Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.1 Table Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2 CM Operations Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2.1 3G Rehosting Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2.2 Workflow engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2.3 Command Manager window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2.4 Operation statuses in CM Operations Manager . . . . . . . . . . . . . . . . . . . 52

5.3 CM Analyser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.4 CM Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.4.1 Actual and reference configuration auditing . . . . . . . . . . . . . . . . . . . . . . 55

5.4.2 Initializing reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.5 Command Line Interface (CLI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.6 Site commissioning tools: Plan Editor and Site Configuration Tool . . . . 56

5.7 XML Interface for Configuration Management Data . . . . . . . . . . . . . . . . 56

5.8 CSV Interface for Configuration Management Data . . . . . . . . . . . . . . . . 57

5.9 3GPP CORBA Bulk CM Northbound Interface . . . . . . . . . . . . . . . . . . . . 57

6 Maintaining up-to-date picture of the network. . . . . . . . . . . . . . . . . . . . . 58

6.1 Real-time updating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.1.1 Real-time updating for GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.1.2 Real-time updating for WCDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.1.3 Real-time updating for core network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.1.4 Real-time updating for I-HSPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.1.5 Real-time updating for eNB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.1.6 Real-time updating for LTE GOMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.2 Uploading network data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.3 Exporting network data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7 Configuring the network using plans. . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.1 Importing plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.2 Comparing plans to actual configuration. . . . . . . . . . . . . . . . . . . . . . . . . 61

7.3 Completing plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.4 Preparing plans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.5 Provisioning plans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.5.1 RNC plan activation and pre-activation. . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.5.2 BSC plan activation and pre-activation . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.5.3 Flexi EDGE BTS site configuration plan activation and pre-activation . . 66

7.5.4 AXC and FTM plan activation and pre-activation . . . . . . . . . . . . . . . . . . 67

7.5.5 I-HSPA WBTS and IADA plan activation and pre-activation. . . . . . . . . . 67

7.5.6 eNB plan activation and pre-activation . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.5.7 GOMS activation and pre-activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.5.8 MSC and MGW plan activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.5.9 SGSN plan activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

DN03317888

Issue 13-1

5


Id:0900d805807c3ab9

7.5.10 Non-network parameters and objects . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.6 Verifying plan provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.7 Restoring the actual/reference configuration . . . . . . . . . . . . . . . . . . . . . 68

7.7.1 Using backup plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.7.2 Using AXC/FTM/BTS backup configuration. . . . . . . . . . . . . . . . . . . . . . 69

7.7.3 Using fallback operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

7.7.4 Using export and import. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

8 Configuring the network using reference configuration . . . . . . . . . . . . . 70

8.1 Actual configuration auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

8.1.1 Delta management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

8.1.2 Reference and network configuration alignment . . . . . . . . . . . . . . . . . . 71

8.2 Exporting reference configuration data . . . . . . . . . . . . . . . . . . . . . . . . . 72

8.3 Consistency checking for reference configuration . . . . . . . . . . . . . . . . . 72

8.4 Plan merge to reference configuration. . . . . . . . . . . . . . . . . . . . . . . . . . 72

9 Managing objects one by one . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

9.1 Send to Network for GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

9.2 Send to Network for WCDMA (Direct Activation for RNC). . . . . . . . . . . 74

9.3 Send to Network for core network objects . . . . . . . . . . . . . . . . . . . . . . . 75

9.3.1 Send to Network for MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

9.3.2 Send to Network for MSS and MGW . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

9.3.3 Send to Network for SGSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

9.4 Send to Network for non-network objects . . . . . . . . . . . . . . . . . . . . . . . 75

10 Where to find more information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

11 Appendix A: Objects not supported by file-based plan provisioning . . . 78

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6 DN03317888

Issue 13-1


Id:0900d805807c3ab9

List of FiguresFigure 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

Figure 42 Reference configuration based management, and flow of configuration

data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

DN03317888

Issue 13-1

7


Id:0900d805807c3ab9

Figure 43 Actual and reference configuration auditing. . . . . . . . . . . . . . . . . . . . . . 71

Figure 44 Network Planning with Reference Configuration . . . . . . . . . . . . . . . . . . 72

8 DN03317888

Issue 13-1


Id:0900d805807c3ab9

List of TablesTable 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

Table 6 Characters not allowed in plan, template and site template names . . . . 42

DN03317888

Issue 13-1

9

NetAct Configurator Principles About this document

Id:0900d805807cb38e

1 About this documentNetAct 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 informationFor 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 TermsIf you are unfamiliar with any of the terms used in this document, see the Glossary.

10 DN03317888

Issue 13-1


Id:0900d805807cb38e

Introduction to NetAct Configurator

2 Introduction to NetAct ConfiguratorNetAct 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

NetActConfigurator

ActualConfiguration

Export

/Reference

PlanProvisioning

Actual ConfigurationUpload

ConfiguratorDatabase

Configurator Applications

External Systems/Tools, PlanningTools, Performance Reporting

Tools, Optimisation Tools

NetActCommonTopology

PlanImport

DN03317888

Issue 13-1

11

NetAct Configurator Principles Introduction to NetAct Configurator

Id:0900d805807cb38e

NetAct Configurator basic conceptsThe 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 configuration 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 DN03317888

Issue 13-1


Id:0900d805807cb38e

Managed Objects

3 Managed ObjectsNetAct 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.

Table 2 Managed object related concepts

DN03317888

Issue 13-1

13

NetAct Configurator Principles Managed Objects

Id:0900d805807cb38e

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 ParametersThe 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:

�ವ String

�ವ Boolean

�ವ Numeric

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.

Table 3 Additional MO properties in Configurator

14 DN03317888

Issue 13-1


Id:0900d805807cb38e

Managed Objects

�ವ Bitmask

�ವ Enumeration

�ವ Structure

�ವ List

3.2 States of managed objectsManaged 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 statesThe 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 statesThe 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.

Table 5 Administrative states and their meaning

DN03317888

Issue 13-1

15


Id:0900d805807cb38e

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 statesThe operational state shows the functional state of certain network objects from the

network point of view.

The operational state is defined only for selected managed objects:

�ವ GSM - BCF, BTS, TRX, timeslot

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

Table 5 Administrative states and their meaning (Cont.)

16 DN03317888

Issue 13-1


Id:0900d805807cb38e

Managed Objects

�ವ 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 objectsCore 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 networkThe following figures illustrate the managed object classes that are included in the MSC

and MGW management:

DN03317888

Issue 13-1

17


Id:0900d805807cb38e

Figure 2 MSC/MGW signalling object hierarchy

18 DN03317888

Issue 13-1


Id:0900d805807cb38e

Managed Objects

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

DN03317888

Issue 13-1

19


Id:0900d805807cb38e

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 DN03317888

Issue 13-1


Id:0900d805807cb38e

Managed Objects

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

MFWDPVMGWCR

SIPLBS SOCKET

SPMU

SPTDM

RTDM

SCTTI

DN03317888

Issue 13-1

21


Id:0900d805807cb38e

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 DN03317888

Issue 13-1


Id:0900d805807cb38e

Managed Objects

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.

DN03317888

Issue 13-1

23


Id:0900d805807cb38e

3.4 Managed objects in packet core networkThe 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 configurationThe following figure illustrates the managed object classes included in BTS RNW con-

figuration management.

! " #

! $ ! %

& ! ' "

! ( # )

* % * )

+ , - "

' ( $

! $ ! .

) * ' "

24 DN03317888

Issue 13-1


Id:0900d805807cb38e

Managed Objects

Figure 11 Managed object hierarchy in GSM management, part 1

DN03317888

Issue 13-1

25


Id:0900d805807cb38e

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 configurationThe following figure illustrates the managed object classes included in BTS site config-

uration management.

26 DN03317888

Issue 13-1


Id:0900d805807cb38e

Managed Objects

Figure 13 Managed object hierarchy in BTS site configuration management

3.5.3 Relationships between GSM and core networkThe following figure illustrates the relationships between GSM and core network

managed object classes:

DN03317888

Issue 13-1

27


Id:0900d805807cb38e

Figure 14 Relationships between GSM and core network

3.6 Managed objects in WCDMAThe 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 RNWThe following figure illustrates themanaged object classes that are included in RNC

RNW management:

* % * )

& /

( $ "

" & 0 1 2 3

( $ "

& /

) 4 ( $

- * "

- " +

) * ' "

* % * #

, ) 4

' ( $

! $ ! .

! $ ! %

* % * )

+ , - "

) * ' "

- * "

& /

- * " 0 & /

* % * )

& /

) * ' (

- * " #

+ , - " - * " 0 & /

- 5 *

( $

- 5 * #

& ! ' "

# * "

28 DN03317888

Issue 13-1


Id:0900d805807cb38e

Managed Objects

Figure 15 Managed object hierarchy in RNC RNW management

3.6.2 Managed objects in AXCThe following figure illustrates the managed object classes included in AXC manage-

ment:

DN03317888

Issue 13-1

29


Id:0900d805807cb38e

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-

ment:

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 DN03317888

Issue 13-1


Id:0900d805807cb38e

Managed Objects

Figure 17 Managed object hierarchy in FTM management

3.6.4 Managed objects in WBTS site configurationThe following figure illustrates the managed object classes included in WBTS site con-


DN03317888

Issue 13-1

31


Id:0900d805807cb38e

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 DN03317888

Issue 13-1


Id:0900d805807cb38e

Managed Objects

Figure 19 RNC transport layer managed object hierarchy in WCDMA management

3.6.6 Relationships between WCDMA and core networkThe 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:

DN03317888

Issue 13-1

33


Id:0900d805807cb38e

Figure 20 Relationships between WCDMA and core network

3.7 Managed objects in I-HSPAThe 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

RNWRNC ID, MCCand MNC addedto MGWM

SAC (ServiceArea 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 DN03317888

Issue 13-1


Id:0900d805807cb38e

Managed Objects

Figure 22 I-HSPA Adapter IP managed object hierarchy

Figure 23 I-HSPA Adapter Signalling managed object hierarchy

PLMN IADA

IPRT

IEIF

IDNS

IAIFIPNO

ISWTP

* ) 4

9 * ! * " " ! * " " ! * * " " ! * -

/ * ! * " " ! * " " ! * * " " ! ( -

* " " ! !

* .

& ! * (

$ * * 6 $ * * 9

# * 6 , '

* , *

& ! * ( *

$ * * !

& $ / $

! ( # )

DN03317888

Issue 13-1

35


Id:0900d805807cb38e

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

CESIF CESPWT CESPW

36 DN03317888

Issue 13-1


Id:0900d805807cb38e

Managed Objects

Figure 25 I-HSPA AXC managed object hierarchy

3.8 Managed objects in LTEThe following figures illustrate the managed object classes that are included in LTE

management:

* # 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 *

& $ / $

! ( # )

DN03317888

Issue 13-1

37


Id:0900d805807cb38e

3.8.1 Managed objects in LTE RNWThe 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 FTMThe following figure illustrates the managed object classes included in FTM manage-

ment:

38 DN03317888

Issue 13-1


Id:0900d805807cb38e

Managed Objects

Figure 27 Managed object hierarchy in FTM management

3.8.3 Managed objects in LTE BTS site configurationThe 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 FemtoBTSThe following figure illustrates the managed object classes included in FemtoBTS con-


Figure 29 Managed object hierarchy in FemtoBTS configuration management

DN03317888

Issue 13-1

39


Id:0900d805807cb38e

3.10 Non-network objects and parametersNon-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 ObjectsForeign 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).

Figure 30 Managed object hierarchy for external cells

EXCC

EWCE

PLMN

BTS

BSC-0

BCF-0

TRX-1

40 DN03317888

Issue 13-1


Id:0900d805807cb38e

Managed Objects

3.10.2 Antenna objectsThe 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 objectThe 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 RegionMaintenance 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

DN03317888

Issue 13-1

41

NetAct Configurator Principles Concepts for managing configuration data

Id:0900d805807cb38e

4 Concepts for managing configuration dataThis chapter describes the following basic concepts of NetAct Configurator:

�ವ Actual configuration

�ವ Plans

�ವ Reference configuration

�ವ Templates

�ವ Site Templates

�ವ Rules

4.1 Actual configurationThe 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 PlansA 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.

�ವ General plans - these are the standard plans created by the user.

�ವ Backup plans - these plans are created by the system, for example, they are gener-

ated during the provisioning because of the safety reasons.

42 DN03317888

Issue 13-1


Id:0900d805807cb38e

Concepts for managing configuration data

�ವ 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 templatesWhen naming plans, templatesand site templates, remember that some special charac-

ters are not allowed. The following table lists the illegal characters in plan, template

names and site templates:

4.3 Reference configurationThe 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 configuration

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 TemplatesTemplates 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

can be used as object classification or assigning templates for related managed

Description Character

Exclamation mark !

Quote "

Apostrophe ’

Accent mark ´

Semicolon ;

Scandic å

Scandic ä

Scandic ö

Space

Table 6 Characters not allowed in plan, template and site template names

DN03317888

Issue 13-1

43

NetAct Configurator Principles Concepts for managing configuration data

Id:0900d805807cb38e

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 templatesThere 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 templatesMultiple 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 templatesA 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.

With CM Editor it is also possible to use templates for forcing template values on existing

objects. Parameter values are overwritten with template values.

44 DN03317888

Issue 13-1


Id:0900d805807cb38e

Concepts for managing configuration data

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 templatesUser 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 TemplatesSite 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 RulesDuring 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.

For more information on rules, see Rules and Rule Syntax for NetAct Configurator.

DN03317888

Issue 13-1

45

NetAct Configurator Principles NetAct Configurator functionality

Id:0900d805807cb38e

5 NetAct Configurator functionalityNetAct 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 Solution modules. For more information, see Optimizer Principles.

5.1 CM EditorCM Editor provides intuitive parameter editing, both in minor parameter modifications

and mass modification purposes.

46 DN03317888

Issue 13-1


Id:0900d805807cb38e

NetAct Configurator functionality

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:

�ವ Creating and deleting site templates

�ವ Editing site templates

�ವ Managing site objects

DN03317888

Issue 13-1

47


Id:0900d805807cb38e

�ವ 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 EditorTable 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.

For instructions on how to use Table Editor, see CM Editor Help.

48 DN03317888

Issue 13-1


Id:0900d805807cb38e


Figure 33 Table Editor window in CM Editor

5.2 CM Operations ManagerThe 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.

DN03317888

Issue 13-1

49


Id:0900d805807cb38e

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

�ವ Comparing plans to actual configuration and reporting the differences

�ವ Validating plans against actual or reference configuration

�ವ Managing reference configuration:

�ವ Importing and exporting reference configuration

50 DN03317888

Issue 13-1


Id:0900d805807cb38e


�ವ 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 Wizard3G 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 engineWorkflow 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

�ವ Reconfiguring the ATM-based Iub

�ವ Reconfiguring Transport for Dual Iub

DN03317888

Issue 13-1

51


Id:0900d805807cb38e

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 windowCommand 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:

�ವ executing a single command to one MSC/MGW/SGSN/GGSN/FING;

�ವ executing a single command to multiple MSCs/MGWs/SGSNs/GGSNs/FINGs;

�ವ executing a command file to one MSC/MGW/SGSN/GGSN/FING;

�ವ executing a command file to multiple MSCs/MGWs/SGSNs/GGSNs/FINGs;

52 DN03317888

Issue 13-1


Id:0900d805807cb38e


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.


Figure 36 Command Manager window

5.2.4 Operation statuses in CM Operations ManagerCM 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 operation is a plan provision to

a specific network element (e.g. BSC). It means that operation group consist of number

of operations which are executed separately. Statuses of the performed operations and

DN03317888

Issue 13-1

53


Id:0900d805807cb38e

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.


5.3 CM AnalyserCM Analyser is the tool for checking the consistency rules in radio network and core

network parameters and managed objects.

54 DN03317888

Issue 13-1


Id:0900d805807cb38e


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 ReferenceCM Reference is the application for generating, visualising and solving differences

(deltas) that exist between the reference configuration and the actual configuration.

DN03317888

Issue 13-1

55


Id:0900d805807cb38e

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


5.4.1 Actual and reference configuration auditingActual 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

be re-created based on the approved reference configuration.


56 DN03317888

Issue 13-1


Id:0900d805807cb38e


5.4.2 Initializing referenceActual 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 configuration or for later use in planning the actual configuration.

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 ToolPlan 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 DataNetAct 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

language based on XML. The current supported versions of the markup language are

RAML/CM2.0 and RAML/CM2.1. CM Operations Manager and Command Line Interface

DN03317888

Issue 13-1

57


Id:0900d805807cb38e

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 DataNetAct 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 Interface3GPP 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 DN03317888

Issue 13-1


Id:0900d805807cb38e

Maintaining up-to-date picture of the network

6 Maintaining up-to-date picture of the networkNetAct 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 updatingThe 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:

�ವ Creating a managed object

�ವ Deleting a managed object

RAML/CM 2.0

data available to

other systems

Proprietary interface 3GPP Bulk CM Itf-N

GSM

SGSN

MMLNWI3

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-HSPA

FTM*

NWI3

MSC/

MGW

I-HSPA

AXC*AXC*

RAML/CM 2.1

RAML/CM 2.1

RAML/CM 2.1Other tool,

for example,

reporting

eNB

NWI3

GOMS

B *TS

DN03317888

Issue 13-1

59

NetAct Configurator Principles Maintaining up-to-date picture of the network

Id:0900d805807cb38e

�ವ 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 GSMYou 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 WCDMAYou 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 networkThere are no events from core network elements.

6.1.4 Real-time updating for I-HSPAWhen 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 eNBWhen 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 GOMSGOMS sends events for PREBTS objects that are used for auto connection.

6.2 Uploading network dataYou can update the radio network and core network information with CM Operations

Manager and Command Line interface using the upload operation.

The accuracy of information in the NetAct database must be checked, for example,

when:

60 DN03317888

Issue 13-1


Id:0900d805807cb38e

Maintaining up-to-date picture of the network

�ವ 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 dataThe 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.

DN03317888

Issue 13-1

61

NetAct Configurator Principles Configuring the network using plans

Id:0900d805807cb38e

7 Configuring the network using plansThe following figure illustrates plan based configuration management, systems, inter-

faces, and flow of configuration data in NetAct Configurator:

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

configuration data

7.1 Importing plansA plan that has been created with a planning tool can be imported to the NetAct Config-

urator with CM Operations Manager.

The status of import operation executed by the user from command line interface can



7.2 Comparing plans to actual configurationThe Plan Actual Compare function in CM Operations Manager can be used for the fol-

lowing purposes:

�ವ To review planned network modification plans against actual network configuration

before provisioning. If the actual configuration is changed before the plan is provi-

sioned into network, the plan can become inconsistent.

RAML/CM 2.0

data available from

other systems

Proprietary interface 3GPP Bulk CM Itf-N

2G

SGSN

MMLNWI3

MML

Q3XML/Q3

BSC

NetAct

Configurator

RAML/CM 2.0

RAML/CM 2.0

write

read

Plan databuilding

Plan Editor

Optimising

NetAct Optimizer

External network

management

Management

System

RNC

CSV

MSC/

MGWAXC

NWI3

BTS O&M

WBTS

FTM

GOMS

NWI3

GUI/CLI

create, edit,

check, compare

GUI/CLI

file import

GUI/CLI

provisionplan

I-HSPA

IADA

I-HSPA

FTM

I-HSPA

AXC

NWI3

Radio planning

Planning tool

RAML/CM 2.1

RAML/CM 2.1

RAML/CM 2.1

GOMS

eNB

NWI3

Other tool,

for example,

reporting

BTS

62 DN03317888

Issue 13-1


Id:0900d805807cb38e

Configuring the network using plans

�ವ To verify that all planned changes were implemented correctly to the network after

provisioning.

�ವ To review configuration data history, that is, to compare a plan that was exported on

day 1 against the actual network configuration.

The status of compare operation executed by the user in CM Operations Manager can



7.3 Completing plansYou can create plans with CM Editor and CM Operations Manager. Once the plan exists

in NetAct Configurator, you can:

�ವ modify the parameters in the plan with CM Editor;

�ವ add, modify, and remove objects in the plan with CM Editor;

�ವ add and remove adjacencies with CM Editor or Optimizer;

�ವ check the consistency of the plan content with CM Analyser;

�ವ approve a plan to indicate that it is ready for provisioning;

7.4 Preparing plansWith the plan prepare operation you do not need to maintain several and mandatory

dependencies manually in the GSM, WCDMA, LTE and I-HSPA configuration. This

helps you to decrease the amount of workload and faults. Plans can be prepared with

CM Operations Manager. Information on whether plan preparation has been performed

and when it took place is displayed in CM Operations Manager. If needed, the plan can

be edited again, checked, and prepared as many times as needed before provisioning

it in the network. The plan prepare operation can be performed separately or as part of

the activation process to ensure that the related parameters are synchronised.

Plan prepare is performed always on the entire plan. Plan preparation automatically

populates parameters of a given managed object in a plan based on a related object that

can exist in either the same plan or actual/reference configuration. As a result of the

preparation, new objects are added to the plan.

Plan prepare performs the following actions based on the plan content:

�ವ Adjacency creation: copies target cell parameters to the adjacency (ADCE, ADJI,

ADJS, ADJW, ADJG).

�ವ Cell modification: updates incoming adjacencies (ADCE, ADJI, ADJS, ADJG,

ADJW).

�ವ Cell deletion: deletes incoming adjacencies (ADCE, ADJI, ADJS, ADJG, ADJW).

�ವ WLCSE creation and modification: copies UTRAN cell id parameters from the

related WCEL object.

�ವ eNB adjacency creation: compares planned ADIPNO Adjacent eNB IP address to

actual value and check differences.

g For all new Adjacent eNB IP addresses, the corresponding target LNBTS’s

ADIPNO is added to plan (if does not exist in the plan) and source LNBTS’s

IPNO Control plane IP address is added to target ADIPNO Adjacent eNB IP

address parameter (if does not exist).

DN03317888

Issue 13-1

63


Id:0900d805807cb38e

The status of plan prepare operation executed by the user in CM Operations Manager

can be monitored in CM Operations Manager user interface. For more information, see


7.5 Provisioning plansCM Operations Manager is used to provision complete, prepared plans to the network.

The plan can be provisioned as a whole or partially. When provisioning partial plans,

note that plan preparation can add new objects that are outside the selected provision-

ing scope. These objects need to be provisioned in a separate operation.

There are two different ways to provision a plan to the network using CM Operations

Manager user interface:

�ವ Activate: direct activation where the plan is transferred to the network and the plan

values are taken into use immediately.

�ವ Pre-activate + Activate Pre-activated Plan: The plan is first transferred to the

network, but the plan values are taken into use in a separate operation.

Preactivating a plan does not affect the network traffic.

Activating a plan affects the network traffic, but it can be carried out in a controlled

manner. You can define the scale of impact on traffic that is allowed during the configu-

ration change.

A plan can contain changes on several network technologies and different element ver-

sions.

The status of provision operation executed by the user in CM Operations Manager can



The following figure illustrates the interfaces and databases in the network elements

used during plan provisioning process:

64 DN03317888

Issue 13-1


Id:0900d805807cb38e


Figure 41 Interfaces and databases in the network elements used during plan provi-

sioning process

7.5.1 RNC plan activation and pre-activationRNC has three databases. Activating a plan takes the plan values into use in the Active

database. The earlier content of the active database is transferred to the fallback data-

Pre-activate

Fall Back

Activate

Active FallbackNew

Active PlanPre-activate

Activate

New Plan

Activate

Pre-activate

Activate

Pre-activated Plan

Save active config.

as fallback

Fall back

via MML

Activate

Plan Active

New PlanNew PlanActivate

Active

New

Plan

Q3

File based

provisioning

NWI3

NWI3

MML

MML

Q3

BSC

RNC

AXC

FTM

2G SGSN

Fallback

Pre-activate

Activate

New Plan Active Plan

WBTS

IADA

(I-HSPA)

Activate

Pre-activated

Plan

New PlanNew PlanActivate

ActiveMSC/MGW

NWI3

Activate

Pre-activated Plan

Activate

Pre-activated

Plan

(WCDMA and I-HSPA)

Pre-activate

Activate

New Plan Active Plan

eNB

(LTE)

Activate

Pre-activated

Plan

NWI3

BSC

Pre-activate

BTS

Activate

Activate

Pre-activated

Plan

Q3

BTS specific

file

BTS specific

file

DN03317888

Issue 13-1

65


Id:0900d805807cb38e

base. When a plan is pre-activated, it is transferred to the New/Plan database to wait for

the activation.

There are three modes for RNC plan activation: Object by Object (Slow), Use Activation

Groups (Moderate), All Objects Parallel (Fast).

�ವ The Object by Object (Slow) mode is the slowest mode as it activates the objects

one by one. The next object is handled only after the previous object has been

updated to the NetAct Configurator database and the network. This mode has least

impact on the network traffic. COCO objects are always activated using Object by

Object mode.

�ವ The Use Activation Groups (Moderate) mode divides the planned WBTSs in sets

containing WBTSs that are not adjacent to each other. All WBTSs in the set are

updated parallel, first in the Configurator database and then the network. The same

procedure is repeated for all WBTS sets until all modification rounds are completed.

In this way, the dropped calls can be minimized and the activation time reduced sig-

nificantly.

�ವ The All Objects Parallel (Fast) mode updates all planned WBTSs in the Configurator

database and the network in one single round. This mode can have an effect on the

traffic in the network if the objects need to be locked for modification. If locking is not

required, this mode is the recommended and fastest solution.

Depending on the used tools, the defined default modes are different:

�ವ Use Activation Groups (Moderate) mode for generic plan activation from CM Oper-

ations user interface

�ವ All Objects Parallel (Fast) mode for rehosting plan activation from CM Operations

user interface

�ವ Object by Object (Slow) mode for Command Line Interface - originated plan activa-

tion

7.5.2 BSC plan activation and pre-activationFor BSC provisioning, there are two methods available:

�ವ File-based plan provisioning

�ವ Q3-based plan activation (only for BSC S13 release)

File-based plan provisioningFile-based plan provisioning offers better performance compared to the obsolete Q3-

based plan activation method.

Impact on the network traffic can be controlled to reduce the number of dropped calls.

You can also define the service impact level of the activation operation. For more infor-

mation, see CM Operations Manager Help.

If needed, the plan file can be first transferred to the Plan database in BSC (pre-activate

operation), and then activated separately (activate operation).

The plan is automatically validated before activation. Validating means cross-checking

in BSCs to ensure that the plan is correct for activation. The validation logs can be

reviewed in CM Operations Manager. If needed, a plan can be validated separately and

the activation started after that. It is possible to prevent local changes in the network

during validation.

66 DN03317888

Issue 13-1


Id:0900d805807cb38e


You can save the latest active configuration as a fallback and restore it using MML. You

can check if an active configuration is stored as fallback before you start the activation.

Since BSC S14 release, you do not longer need to select the method of plan provision-

ing. Instead, the new mechanism of plan provisioning is used. At first all parameters sup-

ported by file-based plan provisioning are activated using file-based plan provisioning

method. Then the parameters not supported by file-based plan provisioning are auto-

matically activated using new XML Send To Network functionality. All the operations are

performed and controlled by the system. You do not need to choose the activation

method.

For BSC S13 release, the objects and parameters not supported by file-based plan pro-

visioning are left untouched during the plan provisioning operation. They must be acti-

vated separately using Q3-based plan activation method. The following changes are not

possible via file-based plan provisioning for S13 release:

�ವ BSS and Site Synchronisation do not allow moving BCFs from one chain to another

in the plan.

�ವ You cannot modify the attached Dynamic Frequency and Channel Allocation

(DFCA) mobile allocation (MA) lists of the DFCA hopping BTS(s).

�ವ You can create, modify, and delete Link Access Procedure on the D-channel (LAPD)

and Transmission Network Element (TRE) objects locally after the RNW plan is

downloaded. However, when the RNW plan is downloaded, local changes to LAPD

and TRE RNW objects are not recommended as they may cause problems during

plan activation.

�ವ No support for segment reconfiguration.

For a list of objects not supported by file-based provisioning, see Appendix: Objects not

supported by file-based plan provisioning.

Q3-based plan activation (only for BSC S13 release)Q3-based plan activation is the obsolete method of plan provisioning, which can be used

only for BSC S13 release. The method supports all BSC objects and parameters. The

configuration change is directly taken into use in the Active database in the BSC, so the

Pre-activate operation is not possible with this method. When it is required, objects are

locked and unlocked automatically. The user can control the impact on the traffic by

defining handover time limits.

Q3-based plan activation method is not available for BSC S14 release. For BSC S14

release plan provisioning only the file-based method (assisted by Send To Network) can

be used.

7.5.3 Flexi EDGE BTS site configuration plan activation and pre-activa-tionFlexi EDGE BTS site configuration plan can be activated in the BTS directly, or the plan

file can be first transferred to BSC by a pre-activation operation and the plan can be

taken into use in a separate activation operation.

The File Based Provisioning feature is used for Flexi EDGE BTS site configuration plan

activation, and the file is transferred via Q3 to BSC. From BSC to BTS, the file is trans-

ferred via the OMUSIG link.

NetAct Configurator splits the original plan file into BSC specific files. The BSC further

splits the plan into BTS specific files.

DN03317888

Issue 13-1

67


Id:0900d805807cb38e

The BTS site configuration is validated as part of the activation operation. The validation

operation can also be run as a separate operation before activating the plan.

The following rules must be considered when activation BTS site configuration:

�ವ In site creation cases, the BCF in BSC RNW configuration must be created before

the BTS SC is activated. The same rule is applicable in site creation with and

without autoconnection. For more information on the procedure, see Creating BTS

sites.

�ವ In maintenance cases, the BTS site configuration is activated before the related

BSC RNW data is modified. This is the default order when the BSC RNW and BTS

SC data is activated in the same plan. Examples of this kind of modification are GSM

BTS site rehosting and Migration to Packet Abis. For more information, see Rehost-

ing GSM BTS sites and <relevant document>

7.5.4 AXC and FTM plan activation and pre-activationAXC and FTM plans can be activated in the network directly, or the plan file can be first

transferred to the network by a pre-activation operation and the planned values can be

taken into use in a separate activation operation.

7.5.5 I-HSPA WBTS and IADA plan activation and pre-activationI-HSPA plans can be activated in the network directly, or the plan file can be first trans-

ferred to the network by a pre-activation operation and the planned values can be taken

into use in a separate activation operation.

7.5.6 eNB plan activation and pre-activationeNB plans can be activated in the network directly, or the plan file can be first transferred

to the network by a pre-activation operation and the planned values can be taken into

use in a separate activation operation. The eNB configuration is validated as part of the

activation operation. The validation operation can also be run as a separate operation.

g "Locking" plan is generated automatically when activating "user plan" from Provi-

sioning dialog or command line. "User plan" is checked, and temporary "locking"

plan is generated for LNCELs when parameter modification requires object locking

or BTS restart. LNCEL is not added to "locking plan" when it is already locked or it

is not selected to the provisioning scope. "Locking plan" is Pre-activated and Acti-

vated automatically before "user plan" is pre-activated and activated. Unlocking is

appended to "user plan" and then eNB does the unlocking automatically after mod-

ification. Automatic locking is not done for FTM parameter modifications.

g Note that when plan contains changes to parameters that require cell locking or BTS

restart, then activate pre-activated plan is not possible, because required cells are

automatically locked by downloading and activating first temporary locking plan and

then downloading and activating the original plan.

7.5.7 GOMS activation and pre-activationPREBTS objects, that are used for auto connection, can be pre-activated and activated

to GOMS database.

68 DN03317888

Issue 13-1


Id:0900d805807cb38e


7.5.8 MSC and MGW plan activationMSC and MGW does not support separate pre-activation operation but the changes are

always activated directly in the network.

7.5.9 SGSN plan activationSGSN does not support separate pre-activation operation but the changes are always

activated directly in the network.

7.5.10 Non-network parameters and objectsNon-network parameters are saved into the actual configuration at the same time when

the plan is activated in the network. A plan with only non-network parameters must be

provisioned for updating the actual configuration.

7.6 Verifying plan provisioningYou can visualise the changes between the actual configuration and the plan with the

Plan Actual Compare function in CM Operations Manager, or manually in CM Editor.

After provisioning, there should be no differences between actual configuration and the

plan.

7.7 Restoring the actual/reference configurationIf activating a plan failed for some reason, or your plan was otherwise unsuccessful, you

can restore the latest active configuration by using a backup plan or a fallback operation.

The backup plan is a generic functionality of the supported network technologies. BSC

Q3-based plan activation method has its own backup plan functionality besides the

generic backup plan.

Fallback method is only available for BSC and RNC RNW, and the implementation is

different for these technologies.

7.7.1 Using backup planA backup plan is a reverse plan of the original plan. Creation operations are converted

to deletion operations and deletion operation to create operations. Parameter modifica-

tions are replaced with the values in the actual/reference configuration.

The backup plan can be automatically created before provisioning the original plan. The

system names the backup plan according to the original plan name by adding a backup

and a timestamp: <plan_name>_backup_<date>_<time>. The backup plan name

can be modified in the CM Operations Manager user interface. The backup plan is

added to plan list.

A backup plan is always created for the entire original plan even though the original plan

is provisioned partially.

The BSC traditional Q3-based plan activation backup plan is also created automatically

and added to the plan list. The format of the backup plan name is the following:

<original plan><timestamp><mtnman>. The name of the backup plan cannot be

modified.

DN03317888

Issue 13-1

69


Id:0900d805807cb38e

You can activate the backup plan whenever you need to restore the actual/reference

configuration. When using the generic backup plan for a partially provisioned plan, the

backup plan is activated also for objects that did not contain any modifications. It is

possible to modify the scope of the backup plan in CM Editor.

The BSC Q3-based plan activation specific backup plan is activated only for objects that

contained modifications.

In case BTS has been deleted from the network and you want to restore the object, use

the traditional Q3-based plan activation to provision your backup plan. Using file-based

provisioning for BTS recreation causes the operation to fail as the method does not

support filtering out optional parameters.

7.7.2 Using AXC/FTM/BTS backup configurationAXC, FTM and BTS backup configuration can also be created in connection with the

configuration upload. The backup is stored in files. By default, a backup plan is gener-

ated based on the handled plan. You can restore the configurations in the network to

match the situation before the provisioning by provisioning the backup plan. For more

information, see Provisioning plans in CM Operations Manager Help docment.

7.7.3 Using fallback operationA fallback configuration is stored in the network element.

In RNC, the actual/reference configuration is transferred to the fallback database when

a new plan is activated. The fallback configuration can be restored only for the latest

active configuration. You can check if the fallback for your plan is still in the fallback

database and activate the original plan to restore the configuration. To avoid unex-

pected situations, such as losing manual changes that have been done with RNC

element manager, it is recommanded that you execute the fallback immediately after the

need for the restoring the original configuration has been detected.

The fallback operation in the RNC is not possible for ATM/IP parameters.

The fallback for BSC can be created with file based provisioning by setting on the appro-

priate option in CM Operations Manager. You can start the fallback for BSC using MML.

In BSC, the fallback operation heavily affects the traffic in the network. Therefore, it is

recommended to use backup plans for restoring the actual/reference configuration.

For more information on using fallback operation, see Configuring WCDMA transport

network.

7.7.4 Using export and importYou can export the actual or reference configuration of related controllers to a file with

CM Operations Manager. When necessary to restore the original parameter configura-

tion for GSM, WCDMA, LTE, I-HSPA, and R4 core network import the file and provision

it to the network.

70 DN03317888

Issue 13-1


Id:0900d805807cb38e

Configuring the network using reference configuration

8 Configuring the network using reference configurationThe following figure illustrates the reference based configuration management in NetAct

Configurator:

Figure 42 Reference configuration based management, and flow of configuration

data

Reference configuration is stored in the network as a seprate data from actual and

planned configuration. As such reference configuration cannot be directly modified. This

can be made only through plans. Management of reference configuration consists of:

�ವ building reference configuration from actual configuration

�ವ generating, analysing and visualising deltas

�ವ checking plan(s), and building plans on top of reference configuration

�ವ comparing reference to actual and planned configuration

�ವ consistency checks

8.1 Actual configuration auditingThe following figure illustrates the delta report generation, in CM Reference application:

Import/Create

a plan

Actual

Configuration

Reference

Configuration

Plan

Plan

ConfigurationGenerate delta and

save plan

Check plan and update

planned changes

into Reference Configuration

Build

Reference

Configuration

Provision plan

to network

Network

Actual

Configuration

Upload

DN03317888

Issue 13-1

71

NetAct Configurator Principles Configuring the network using reference configuration

Id:0900d805807cb38e

Figure 43 Actual and reference configuration auditing

Actual configuration auditing is a set of functionalities that enables to see discrepancies

between actual and reference configuration.

The main feature of actual auditing is a delta generation which is a report about differ-

ences between actual network configuration and reference configuration which is the

configuration that should be kept in the network. The delta report can be analysed and

aligned to the reference configuration and/or to the network. The purpose of this proce-

dure is to keep reference and actual configuration synchronize.

Deltas can be also ignore (which is not recommended) or put in StandBy mode. StandBy

means that delta is distinguished from other deltas and they are, for example, shown as

differences when next delta is generated.

8.1.1 Delta managementDelta management is a set of functionalities that enables to compare the actual and the

reference configuration in order to find differences between them. Deltas can be visua-

lised, and analysed in a user-friendly manner. There is also a possibility to schedule

automatic delta analysis and parameters corrections. For more information, see CM

Reference Help.

8.1.2 Reference and network configuration alignmentReference configuration can be updated according to the delta report. This can exclude

potential mistake in the configuration. After that user can generate an actual configura-

tion update plan which can be provisioned to the network. For more information, see CM

Reference Help and CM Operations Manager Help.

Reference Alignment

MO StandBy Ignore Delta

More

Deltas?

No

Yes

Provision to Network/

Merge to Reference

Configuration

Network Alignment

Delta Analysis

Generate Delta Report

72 DN03317888

Issue 13-1


Id:0900d805807cb38e

Configuring the network using reference configuration

8.2 Exporting reference configuration dataYou can export the reference configuration to a file with CM Operations Manager (in

XML and CSV formats). For more information, see CM Operations Manager Help.

8.3 Consistency checking for reference configurationThe following figure illustrates the possible checks that can be started in NetAct Config-

urator to eliminate possible errors in plan management:

Figure 44 Network Planning with Reference Configuration

Consistency checks are made to check if any errors and inconsistencies occurs in a ref-

erence configuration. As a result of a check a reference correction plan(s) is/are gener-

ated. Correction plan can be then merge to reference configuration and provisioned to

the network. For more information, see CM Operations Manager Help.

8.4 Plan merge to reference configurationReference configuration can be updated by merging a NetAct Configurator plan. This

allows to create, delete and modify MO(s) in reference configuration.

Get Plan

Archive PlanReady

for Merge?No

Yes

Provision to Network

Consistency Check

(optional)

Get Plan

Merge to

Reference Configuration

DN03317888

Issue 13-1

73

NetAct Configurator Principles Managing objects one by one

Id:0900d805807cb38e

9 Managing objects one by oneThis chapter describes how to create, delete, and modify GSM, WCDMA, and core

network objects one by one, directly in the network.

Managing objects one by one enables ad hoc management of the most commonly

modified objects. In addition to the plan-based management that is the recommended

way to implement mass changes in the network, CM Editor can be used to make minor

modifications on the objects in the actual configuration.

For more information, see Creating new managed objects in the network, Deleting a

managed object from the network and Modifying managed object values in the network

in CM Editor Help.

Changing the administrative state of the managed objects is a similar functionality where

the object state can be modified one by one directly in the network. For more informa-

tion, see Administrative states and Locking and unlocking managed objects in the

network in CM Editor Help.

9.1 Send to Network for GSMSend to Network functionality in CM Editor can be used to manage the following GSM

objects:

�ವ ACP

�ವ ADCE

�ವ ADJW

�ವ ADJL

�ವ ANE

�ವ BAL

�ವ BCF

�ವ BSC (only modification)

�ವ BTS

�ವ CSDAP

�ವ DAP

�ವ ETP

�ವ FRBC (managed only via MML)

�ವ GPC (can be deleted only together with the parent BTS)

�ವ HDLC

�ವ HOC (can be deleted only together with the parent BTS)

�ವ LAPD

�ವ LCSE

�ವ LMUA

�ವ MAL

�ವ MALD

�ವ MBAL

�ವ NSE (creation/deletion automatically only together with the NSVL object)

�ವ NSVC

�ವ NSVL

�ವ PCU

�ವ POC (can be deleted only together with the parent BTS)

74 DN03317888

Issue 13-1


Id:0900d805807cb38e

Managing objects one by one

�ವ RA

�ವ SG

�ವ SMLC (creation/deletion automatically only together with parent BSC)

�ವ SPC

�ವ TID

�ವ TRKT

�ವ TRX

�ವ DN2 (only creation/deletion)

�ವ DMR (only creation/deletion)

�ವ TRE (only creation/deletion)

9.2 Send to Network for WCDMA (Direct Activation for RNC)g Send to Network functionality for WCDMA objects is available only if the 'Direct Acti-

vation for RNC' license has been purchased.

g If a parameter modification requires object locking and unlocking, it is done auto-

matically during Direct Activation. This is required only for dedicated parameters of

RNC, COCO, WBTS and WCEL objects.

Downloaded plan is updated based on Direct Activation request if it is allowed by the

user.

Send to Network for WCDMA (Direct Activation for RNC) enables ad hoc management

of all RNC RNW objects. Direct Activation can be done for one object each time and

there is up to 5 simultaneous Direct Activation operation, plan operation and local con-

figurations managements allowed for one RNC. The following objects and operations

are supported:

�ವ RNC:

�ವ Modification

�ವ COCO, CMOB, FMCG, FMCI, FMCS, HOPG, HOPI, HOPS, IUCS, IUPS, IUR,

IPNB, IPQM, TQM, WANE, WBTS, WCEL, WLCSE, WRAB, WSG, WSMLC, VBTS,

VCEL:

�ವ Creation

�ವ Deletion

�ವ Modification

�ವ ADJD, ADJS, ADJI, ADJG:

�ವ Creation

�ವ Deletion

�ವ Modification

�ವ Automatic update for incoming adjacencies

Direct Activation for RNC can be done in parallel with plan operation, but with certain

restrictions:

�ವ Delete operation is rejected if there is RNW plan activation ongoing.

�ವ Direct Activation request is rejected during roll-back plan.

�ವ If the same object is reserved during the RNW plan activation, the Direct Activation

fails.

�ವ Maximum of 5 simultaneous Direct Activation requests are allowed.

�ವ Direct Activation will fail if consistency check fails.

DN03317888

Issue 13-1

75

NetAct Configurator Principles Managing objects one by one

Id:0900d805807cb38e

9.3 Send to Network for core network objects

9.3.1 Send to Network for MSCSend to Network functionality in CM Editor can be used to manage the following pre-R4

MSC objects:

�ವ MSC

�ವ BSCM

�ವ BTSM

�ವ SGSM

�ವ LA

�ವ NWLA

�ವ MGWM

�ವ MSA

9.3.2 Send to Network for MSS and MGWg Send to Network functionality for R4 core network objects (MSS and MGW) is avail-

able only if the corresponding license has been purchased.

Send to Network functionality for R4 core network objects (MSS and MGW) supports the

following managed object operations:

�ವ MO creation

�ವ MO deletion

�ವ MO modification

Send to Network for object creation, deletion, and modification operations is available

for all MSS and MGW objects and child objects with the following exceptions:

�ವ MML object under MSC GEN fragment - Send to Network not supported;

�ವ MGW ATM fragment - Send to Network for object creation and deletion not sup-

ported (only modification available);

g When object creation requires several parent-child objects to be created, then only

the last child object creation is supported.

9.3.3 Send to Network for SGSNSend to Network functionality in CM Editor can be used to manage the following SGSN

packet core network objects:

�ವ SGSN

�ವ PAPU

�ವ FRBC

�ವ NSVC

9.4 Send to Network for non-network objectsSend to Network functionality in CM Editor can be used to manage the following non-

network objects:

�ವ Foreign BTS

76 DN03317888

Issue 13-1


Id:0900d805807cb38e

Where to find more information

10 Where to find more informationFor more information related to NetAct Configurator and network configuration manage-

ment, see the following documents:

Optimise and Expand Network

�ವ For information on creating a number of BTSs as a mass operation and extending

the BTS Sites, see Creating BTS Sites.

�ವ For information on how to activate the mobile location services in the network, see

Activating Location Services.

�ವ For information on how to take GPRS into use for the first time, see Configuring

GSM/EDGE features.

�ವ For information on creating an operational WCDMA network, see Rolling out the

WCDMA RAN.

�ವ For information on creating an operational LTE network, see Creating and Rolling

out LTE BTS sites.

�ವ For information on moving a GSM BTS site under the control of one BSC to another

BSC, see Rehosting GSM BTS Sites.

�ವ For information on moving one or more WCDMA BTS sites under the control of one

RNC to another RNC, see Rehosting WCDMA BTS Sites.

�ವ For information on moving a BSC under the control of one MSC to another MSC,

see Rehosting BSCs.

�ವ For information on creating and deleting BTSs and splitting segments in Multi-BCF

sites, see Configuring GSM/EDGE features.

�ವ For information on how to create, modify and delete adjacencies in the networks,

see Managing Adjacencies.

�ವ For more information on using Optimizer to optimise networks, see Optimising a

Network Using Optimizer.

Changes

�ವ For information on the functional changes in the product, see Changes in System-

wide functionalities in OSS5.2 CD Set 3 Regional Cluster System Impact document.

Introduction to NetAct

�ವ For information on the basic principles when using the NetAct Plan Editor tool, see

Plan Editor Principles.

�ವ For more information on Optimizer functionality, see Optimizer Principles.

Using NetAct applications

�ವ For information on the basic usage of the tools, see the online helps.

Interface Specifications

�ವ For more information on RAML/CM 2.0, and the radio configuration management

XML files used in planning, see XML Interface for Configuration Management Data.

�ವ For more information on the CSV format data files used as an interface between

Configurator and a planning system, see CSV Interface for Configuration Manage-

ment Data.

DN03317888

Issue 13-1

77

NetAct Configurator Principles Where to find more information

Id:0900d805807cb38e

Parameters

�ವ For more information on parameters used when configuring the network, see Adap-tation Information Browser.

Managed Objects

�ವ For more information on managed objects, see Managed Object Reference.

NetAct Database Descriptions

�ವ For information on the architecture of the network database, see Database Descrip-

tion for NetAct Configurator.

Technical Reference Guides

�ವ For information on various technical aspects of the product, for example, the file

system structure, processes, configuration files, see NetAct Configurator Technical

Reference Guide.

�ವ For more information on Optimizer, see Optimizer Technical Reference Guide.

Administer NetAct: System

�ವ For more information on how to manage the Configurator database, see Maintaining

the NetAct Configurator database using NetAct Configurator Database Doctor in

Managing NetAct Databases.

When you perform network management tasks, you possibly need to refer to other

NetAct documentation for further information. For a complete list of NetAct documenta-

tion, see NetAct Electronic Documentation.

RNC documentation

�ವ For more detailed information on the RNC RNW Object Browser, see the RNC RNW

Object Browser online help.

78 DN03317888

Issue 13-1


Id:0900d805807cb38e

Appendix A: Objects not supported by file-based plan

provisioning

11 Appendix A: Objects not supported by file-based plan provisioningThe following objects are not supported by file-based plan provisioning:

�ವ ACP

�ವ FRBC

�ವ NSE

�ವ NSVC

�ವ NSVL

�ವ PCM

�ವ PCU

�ವ TCSM

For information on which parameters are not supported by file-based plan provisioning,

see Adaptation Information Browser.

DN03317888

Issue 13-1

79


Id:0900d805807c3ab9

Index

Aadministrative states

basics 14

locked 14

shutting down 15

unlocked 15

applications

CM Operations Manager 59

Plan Editor 57

Cchecks 44

CM Operations Manager 57, 59, 62

Ddatabase

updating 58

Iinterfaces

3GPP CORBA Bulk CM Northbound 57

CSV 57

XML 56

Mmanaged object hierarchy

GSM 23

LTE RNW 37

MSC 26

RNC RNW 27

SGSN 26

managed objects

states 14

Oobject states

created from network 14

non -operational 14

operational 14

PPlan Editor 57

RRadio Access Markup Language for Configuration

Management 56

RAML CM 2.0 57

real -time updating 58

rule sets 44

rules 44

Sstates

administrative 14

object 14

of managed objects 14

Uuploading 59

XXML 56

Net act configurator principles copy

Technology

Transcript of Net act configurator principles copy