Anda di halaman 1dari 79

Nokia Siemens Networks

NetAct OSS5.2 CD Set 3 (PDF)

NetAct Configurator Principles


DN03317888
Issue 13-1

NetAct Configurator Principles

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 DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, 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

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 zwangslufig bestimmte Teile der Gerte unter Spannung. Einige Teile knnen auch eine hohe Betriebstemperatur aufweisen.
Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Krperverletzungen und Sachschden fhren.
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
Gerte mssen die zutreffenden Sicherheitsbestimmungen erfllen.

Id:0900d805807c3ab9

DN03317888
Issue 13-1

NetAct Configurator Principles

Table of Contents
This document has 79 pages.

DN03317888
Issue 13-1

1
1.1
1.2

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


NetAct compatibility and capacity information . . . . . . . . . . . . . . . . . . . . . 9
Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

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

3
3.1
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.3
3.4
3.5
3.5.1
3.5.2
3.5.3
3.6
3.6.1
3.6.2
3.6.3
3.6.4
3.6.5
3.6.6
3.7
3.8
3.8.1
3.8.2
3.8.3
3.9
3.10
3.10.1
3.10.2
3.10.3
3.10.4

Managed Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
States of managed objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Object states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Administrative states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operational states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Administrative / Operational states for core network objects . . . . . . . . .
Managed objects in R4 core network. . . . . . . . . . . . . . . . . . . . . . . . . . .
Managed objects in packet core network. . . . . . . . . . . . . . . . . . . . . . . .
Managed objects in GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managed objects in BTS RNW configuration. . . . . . . . . . . . . . . . . . . . .
Managed objects in BTS site configuration . . . . . . . . . . . . . . . . . . . . . .
Relationships between GSM and core network . . . . . . . . . . . . . . . . . . .
Managed objects in WCDMA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managed objects in RNC RNW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managed objects in AXC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managed objects in FTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managed objects in WBTS site configuration . . . . . . . . . . . . . . . . . . . .
Managed objects in RNC transport layer (ATM/IP) . . . . . . . . . . . . . . . .
Relationships between WCDMA and core network . . . . . . . . . . . . . . . .
Managed objects in I-HSPA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managed objects in LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managed objects in LTE RNW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managed objects in FTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managed objects in LTE BTS site configuration . . . . . . . . . . . . . . . . . .
Managed objects in FemtoBTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Non-network objects and parameters . . . . . . . . . . . . . . . . . . . . . . . . . .
External Cell Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Antenna objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Site object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Maintenance Region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12
13
14
14
14
15
16
16
23
23
23
25
26
27
27
28
29
30
31
32
33
36
37
37
38
38
39
39
40
40
40

4
4.1
4.2
4.2.1
4.3
4.4
4.4.1
4.4.2

Concepts for managing configuration data . . . . . . . . . . . . . . . . . . . . . .


Actual configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Constraints for naming plans, templates and site templates . . . . . . . . .
Reference configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41
41
41
42
42
42
43
43

Id:0900d805807c3ab9

NetAct Configurator Principles

4.4.3
4.4.4
4.5
4.6

Using templates . . . . . . . . . . .
Administering templates . . . . .
Site Templates . . . . . . . . . . . .
Rules. . . . . . . . . . . . . . . . . . . .

5
5.1
5.1.1
5.2
5.2.1
5.2.2
5.2.3
5.2.4
5.3
5.4
5.4.1
5.4.2
5.5
5.6
5.7
5.8
5.9

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


CM Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Table Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
CM Operations Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3G Rehosting Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Workflow engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Command Manager window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Operation statuses in CM Operations Manager . . . . . . . . . . . . . . . . . . . 52
CM Analyser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
CM Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Actual and reference configuration auditing . . . . . . . . . . . . . . . . . . . . . . 55
Initializing reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Command Line Interface (CLI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Site commissioning tools: Plan Editor and Site Configuration Tool . . . . 56
XML Interface for Configuration Management Data . . . . . . . . . . . . . . . . 56
CSV Interface for Configuration Management Data . . . . . . . . . . . . . . . . 57
3GPP CORBA Bulk CM Northbound Interface . . . . . . . . . . . . . . . . . . . . 57

6
6.1
6.1.1
6.1.2
6.1.3
6.1.4
6.1.5
6.1.6
6.2
6.3

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


Real-time updating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Real-time updating for GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Real-time updating for WCDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Real-time updating for core network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Real-time updating for I-HSPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Real-time updating for eNB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Real-time updating for LTE GOMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Uploading network data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Exporting network data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7
7.1
7.2
7.3
7.4
7.5
7.5.1
7.5.2
7.5.3
7.5.4
7.5.5
7.5.6
7.5.7
7.5.8
7.5.9

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


Importing plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Comparing plans to actual configuration. . . . . . . . . . . . . . . . . . . . . . . . . 61
Completing plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Preparing plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Provisioning plans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
RNC plan activation and pre-activation. . . . . . . . . . . . . . . . . . . . . . . . . . 64
BSC plan activation and pre-activation . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Flexi EDGE BTS site configuration plan activation and pre-activation . . 66
AXC and FTM plan activation and pre-activation . . . . . . . . . . . . . . . . . . 67
I-HSPA WBTS and IADA plan activation and pre-activation. . . . . . . . . . 67
eNB plan activation and pre-activation . . . . . . . . . . . . . . . . . . . . . . . . . . 67
GOMS activation and pre-activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
MSC and MGW plan activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
SGSN plan activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Id:0900d805807c3ab9

.......
.......
.......
.......

......
......
......
......

.......
.......
.......
.......

......
......
......
......

. . . . . . 43
. . . . . . 44
. . . . . . 44
. . . . . . 44

DN03317888
Issue 13-1

NetAct Configurator Principles

7.5.10
7.6
7.7
7.7.1
7.7.2
7.7.3
7.7.4

Non-network parameters and objects . . . . . . . . . . . . . . . . . . . . . . . . . .


Verifying plan provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Restoring the actual/reference configuration . . . . . . . . . . . . . . . . . . . . .
Using backup plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using AXC/FTM/BTS backup configuration. . . . . . . . . . . . . . . . . . . . . .
Using fallback operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using export and import. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68
68
68
68
69
69
69

8
8.1
8.1.1
8.1.2
8.2
8.3
8.4

Configuring the network using reference configuration . . . . . . . . . . . . .


Actual configuration auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Delta management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reference and network configuration alignment . . . . . . . . . . . . . . . . . .
Exporting reference configuration data . . . . . . . . . . . . . . . . . . . . . . . . .
Consistency checking for reference configuration . . . . . . . . . . . . . . . . .
Plan merge to reference configuration. . . . . . . . . . . . . . . . . . . . . . . . . .

70
70
71
71
72
72
72

9
9.1
9.2
9.3
9.3.1
9.3.2
9.3.3
9.4

Managing objects one by one . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Send to Network for GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Send to Network for WCDMA (Direct Activation for RNC). . . . . . . . . . .
Send to Network for core network objects . . . . . . . . . . . . . . . . . . . . . . .
Send to Network for MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Send to Network for MSS and MGW . . . . . . . . . . . . . . . . . . . . . . . . . . .
Send to Network for SGSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Send to Network for non-network objects . . . . . . . . . . . . . . . . . . . . . . .

73
73
74
75
75
75
75
75

10

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

11

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


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

DN03317888
Issue 13-1

Id:0900d805807c3ab9

NetAct Configurator Principles

List of Figures
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10
Figure 11
Figure 12
Figure 13
Figure 14
Figure 15
Figure 16
Figure 17
Figure 18
Figure 19
Figure 20
Figure 21
Figure 22
Figure 23
Figure 24
Figure 25
Figure 26
Figure 27
Figure 28
Figure 29
Figure 30
Figure 31
Figure 32
Figure 33
Figure 34
Figure 35
Figure 36
Figure 37
Figure 38
Figure 39
Figure 40
Figure 41
Figure 42

Configurator Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
MSC/MGW signalling object hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . 17
MSC/MGW routing object hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
MSC/MGW analysis object hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
MSC/MGW connection object hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . 20
MSC RNW object hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
MGW ATM object hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
MSC/MGW IP object hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
MSC/MGW general object hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Managed objects in packet core network hierarchy . . . . . . . . . . . . . . . . 23
Managed object hierarchy in GSM management, part 1 . . . . . . . . . . . . 24
Managed object hierarchy in GSM management, part 2 . . . . . . . . . . . . 25
Managed object hierarchy in BTS site configuration management. . . . . 26
Relationships between GSM and core network . . . . . . . . . . . . . . . . . . . 27
Managed object hierarchy in RNC RNW management . . . . . . . . . . . . . 28
Managed object hierarchy in AXC management . . . . . . . . . . . . . . . . . . 29
Managed object hierarchy in FTM management . . . . . . . . . . . . . . . . . . 30
Managed object hierarchy in WBTS site configuration management . . . 31
RNC transport layer managed object hierarchy in WCDMA management .
32
Relationships between WCDMA and core network . . . . . . . . . . . . . . . . 33
I-HSPA RNW managed object hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 33
I-HSPA Adapter IP managed object hierarchy . . . . . . . . . . . . . . . . . . . . 34
I-HSPA Adapter Signalling managed object hierarchy . . . . . . . . . . . . . . 34
I-HSPA FlexiTRS (FTM) managed object hierarchy . . . . . . . . . . . . . . . . 35
I-HSPA AXC managed object hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . 36
Managed object hierarchy in LTE RNW management . . . . . . . . . . . . . . 37
Managed object hierarchy in FTM management . . . . . . . . . . . . . . . . . . 38
Managed object hierarchy in LTE BTS site configuration management . 38
Managed object hierarchy in FemtoBTS configuration management . . . 38
Managed object hierarchy for external cells . . . . . . . . . . . . . . . . . . . . . . 39
Antenna objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
CM Editor user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Table Editor window in CM Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
CM Operations Manager user interface . . . . . . . . . . . . . . . . . . . . . . . . . 49
Workflow Engine window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Command Manager window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
CM Analyser user interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
CM Reference user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Actual configuration data handling, collection, storing, and tools . . . . . . 58
Plan-based configuration management, systems, interfaces, and flow of
configuration data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Interfaces and databases in the network elements used during plan provisioning process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Reference configuration based management, and flow of configuration
data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Id:0900d805807c3ab9

DN03317888
Issue 13-1

NetAct Configurator Principles

Figure 43
Figure 44

DN03317888
Issue 13-1

Actual and reference configuration auditing. . . . . . . . . . . . . . . . . . . . . . 71


Network Planning with Reference Configuration . . . . . . . . . . . . . . . . . . 72

Id:0900d805807c3ab9

NetAct Configurator Principles

List of Tables
Table 1
Table 2
Table 3
Table 4
Table 5
Table 6

Managed object related concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12


Managed object related concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Additional MO properties in Configurator . . . . . . . . . . . . . . . . . . . . . . . . 13
Object states and their meaning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Administrative states and their meaning . . . . . . . . . . . . . . . . . . . . . . . . 14
Characters not allowed in plan, template and site template names . . . . 42

Id:0900d805807c3ab9

DN03317888
Issue 13-1

NetAct Configurator Principles

About this document

1 About this document


NetAct Configurator Principles is a descriptive document which gives an overall picture
of the Nokia Siemens Networks NetAct Configurator. It describes the functionalities that
are available and the basic principles needed to utilise those functionalities.
This document is intended for NetAct operating personnel who manage the network
parameters and configuration in GSM, WCDMA, LTE, I-HSPA, and core networks.

1.1

NetAct compatibility and capacity information


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

1.2

Terms
If you are unfamiliar with any of the terms used in this document, see the Glossary.

DN03317888
Issue 13-1

Id:0900d805807cb38e

Introduction to NetAct Configurator

NetAct Configurator Principles

2 Introduction to NetAct Configurator


NetAct Configurator is a component in the scalable NetAct framework for operating
mobile networks. Configurator gives access to real-time network configuration data and
provides tools to manage network configuration.
The following figure illustrates Configurator role in network development and optimisation:

External Systems/Tools, Planning


Tools, Performance Reporting
Tools, Optimisation Tools
Actual/Reference
Configuration
Export

Plan
Import
NetAct
Configurator

Configurator Applications

NetAct
Common
Topology

Configurator
Database

Actual Configuration
Upload

Plan
Provisioning

Network
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.

10

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Introduction to NetAct Configurator

NetAct Configurator basic concepts


The basic concepts of Configurator are:
Network resources are represented as managed objects in NetAct. Configurator
supports managed object classes in GSM, WCDMA, LTE, I-HSPA, and core
network. For more information on managed object concept and supported managed
objects in Configurator, see Managed objects.
The actual configuration refers to the current configuration of the managed network.
There is only one actual configuration in the system. For more information, see
Actual configuration.
Changes to the actual configuration are implemented using plans. A plan contains
a configuration change that will be performed or has been performed to the network.
For more information, see Plans.
The reference configuration is a data set that describes the desired or the target configuration of the network for comparing it with the actual configuration due to consistency checks. For more information, see Reference configuration.
When the network is expanded and optimised, templates offer ready-made parameter 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.

DN03317888
Issue 13-1

Id:0900d805807cb38e

11

Managed Objects

NetAct Configurator Principles

3 Managed Objects
NetAct Configurator supports managed objects (MOs) related to radio network and core
network configuration management.
The NetAct-wide concept of MO represents network resources. In the managed
network, an MO represents a unique:
physical or logical network element (for example, BTS)
piece of equipment (for example, AXC)
logical resource (for example, Connection Configuration)
Each MO is connected to NetAct and managed via defined interfaces.
An MO without network interface is a non-network object defined inside Configurator.
Non-network objects are also used to manage the network. For more information, see
Non-network objects and parameters.
NetAct-wide concepts related to the MO identification are described in the following
table:
Managed Object Class
(MOC)

Defines the characteristics of the MO, such as its parameters,


operations, notifications, and behaviour. Class contains information 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 Distinguished Name.

Distinguished Name

Distinguished name uniquely identifies an MO in NetAct Topology. 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/BCF1/BTS-3).

(DN)

Table 1

Managed object related concepts

The following NetAct wide concepts are related to managed object hierarchy:
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

12

Managed object related concepts

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Managed Objects

In addition to NetAct managed object properties, an MO supported by Configurator has


the following additional properties:
Property

Explanation

Assigned template

A particular template that has been assigned to an MO.


For more information, see Templates.

Parameter values

Table 3

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 Configurator metadata.

Additional MO properties in Configurator

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 Reference and Database Description for NetAct Configurator.

3.1

Parameters
The basic functionality of NetAct Configurator is to define and manage parameter data
in the network.
Most of the parameters are network parameters, meaning that they can be managed via
network interfaces. There are some non-network parameters defined inside Configurator. 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 parameters, 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

DN03317888
Issue 13-1

Id:0900d805807cb38e

13

Managed Objects

NetAct Configurator Principles

Bitmask
Enumeration
Structure
List

3.2

States of managed objects


Managed objects have three separate states:
Object state, only valid for NetAct, for all managed objects
Administrative state, for selected objects
Operational state, for selected objects

3.2.1

Object states
The object state specifies whether the network element exists in the network or whether
it exists only in NetAct. The meaning of different object states, in relation to network
management, is described in the following table:
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

Table 4

The MO has the actual configuration in the NetAct database,


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

Object states and their meaning

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

3.2.2

Administrative states
The administrative state shows the functional state of the network objects from the operators 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:
Administrative state

Meaning

LOCKED

A LOCKED MO is not allowed to carry any traffic.

Table 5

14

Administrative states and their meaning

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Managed Objects

Administrative state

Meaning

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

Table 5

An UNLOCKED MO may carry traffic.

Administrative states and their meaning (Cont.)

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 locking/unlocking this WBTS only the WCELs that are related to that WBTS are
locked/unlocked and the state of the WBTS is not changed.

3.2.3

Operational states
The operational state shows the functional state of certain network objects from the
network point of view.
The operational state is defined only for selected managed objects:
GSM - BCF, BTS, TRX, timeslot

DN03317888
Issue 13-1

Id:0900d805807cb38e

15

Managed Objects

NetAct Configurator Principles

WCDMA - WCEL
I-HSPA - WCEL
LTE - LNCEL
The operational state is a non-modifiable parameter that can be viewed with the following tools:
MML, which can be launched also from CM Editor using ZEEI (GSM)
CM Editor (WCDMA, I-HSPA)
RNC RNW Object Browser (WCDMA)

3.2.4

Administrative / Operational states for core network objects


Core network objects do not have separate parameters for administrative and operational states. A state parameter can be modified both by the operator and the network
element. The state set by the network element overrides the user settings, for example,
if the network element is blocked because of some failure in the system.
For more detailed descriptions on the states for R4 core network, see MSC/HLR product
documentation set.

3.3

Managed objects in R4 core network


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

16

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Figure 2

DN03317888
Issue 13-1

Managed Objects

MSC/MGW signalling object hierarchy

Id:0900d805807cb38e

17

Managed Objects

NetAct Configurator Principles

PLMN

MSC/MGW
ROUTES
DEST
ROU
SDEST
GSMEND
IMHO
PAD
HLRENQ
MFWDP
NMOD
ANN
ANNP
FACC
SIPEND
MFWDP
CC
ANNF

SFILE

MFWDP
DTMF
MFWDP
DDTMF
MFWDP
NAT
MFWDP
DNAT
MSC/MGW
MSC
MGW
Figure 3

18

MSC/MGW routing object hierarchy

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Managed Objects

PLMN

MSC/MGW
ANALYS
TREE

DIGITA

PREA

CBAODC

AREASN

CBASSC

IMSIA
PLMNP
SMSADA
SMSROA
EC
AIR
ATTSA
DPCAA
DPREA
EAAR
EOSR
FR
GTAA
INR
SAEP
WEBSR
RR
RG

EOSAP

SRVRES
MSC/MGW
MSC

Figure 4

DN03317888
Issue 13-1

MSC/MGW analysis object hierarchy

Id:0900d805807cb38e

19

Managed Objects

NetAct Configurator Principles

PLMN

MSC/MGW
CONNR4
CGR
MGWC
MGWP
MGWIC
UPDAD
USUBAN
UFRES
H248LBS
H248UP

HPMU

LBSU
SIPLBS

SOCKET

MFWDP
VMGWCR

SPMU

MGWDP
SPTDM
RTDM
SCTTI
MSC/MGW
MSC
MGW
Figure 5

20

MSC/MGW connection object hierarchy

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Figure 6

PLMN

Managed Objects

MSC RNW object hierarchy

MGW
ATM
IMAG
TCTT

ACCP

RNNI

VPCT

UNI
VPTT

VCCT

TRDE
XCON
A2UT
SVTT
Figure 7

DN03317888
Issue 13-1

MGW ATM object hierarchy

Id:0900d805807cb38e

21

Managed Objects

NetAct Configurator Principles

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.

22

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

3.4

Managed Objects

Managed objects in packet core network


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

! ( # )
* % * )
+ , - "

) * ' "

&! ' "


! $ ! %
! $ ! .
! " #
' ( $
Figure 10

3.5
3.5.1

Managed objects in packet core network hierarchy

Managed objects in GSM


Managed objects in BTS RNW configuration
The following figure illustrates the managed object classes included in BTS RNW configuration management.

DN03317888
Issue 13-1

Id:0900d805807cb38e

23

Managed Objects

NetAct Configurator Principles

Figure 11

24

Managed object hierarchy in GSM management, part 1

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Figure 12

Managed Objects

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 configurations of up to 36 TRXs and 32 BTSs.
The segment object is not supported in NetAct Configurator. Configurator tools visualise
the segment's master BTS and the other BTSs. It is possible to manage multi-BCF
related parameters. For more information, see Configuring GSM/EDGE features.

3.5.2

Managed objects in BTS site configuration


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

DN03317888
Issue 13-1

Id:0900d805807cb38e

25

Managed Objects

NetAct Configurator Principles

Figure 13

3.5.3

Managed object hierarchy in BTS site configuration management

Relationships between GSM and core network


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

26

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Managed Objects

# * "
, ) 4
- * "
&/

- * "

* % * #

- * " #

* % * )
&/

) 4 ( $

' ( $

( $ "

( $

! $ ! .

" &01 2 3
( $ "

- 5 * #

- " +
- 5 *

! $ ! %
- * " 0&/

+ , - "
) * ' "

* % * )

* % * )
&/

&! ' "


- * " 0&/

&/

+ , - "
) * ' "

) * ' (
Figure 14

3.6

Relationships between GSM and core network

Managed objects in WCDMA


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

3.6.1

Managed objects in RNC RNW


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

DN03317888
Issue 13-1

Id:0900d805807cb38e

27

Managed Objects

NetAct Configurator Principles

Figure 15

3.6.2

Managed object hierarchy in RNC RNW management

Managed objects in AXC


The following figure illustrates the managed object classes included in AXC management:

28

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Managed Objects

AXC
ETHLK

PWMP

PWNE

PWTIP

UNIT

MODUL

PPTT
SPTT
SRTT
SMTT
SVTT
FRLI
IMAG
CIWT
IFPG
STPG

TOPIK

NNDT

BFD

TCTT

ACCP

QOS

TRDE

VPCT

TMPAR

VPTT

VCCT

IPRM
INTP

VCTT
A2NE

Figure 16

A2ST

A2UT

IAIF

CCFA

IVMP

IPNO

IEIF

FMAS

FMAF

IPRT

N3MD

N3CF

ISPF

ANBA

TPEL

IHCP

IVIF

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

DN03317888
Issue 13-1

Id:0900d805807cb38e

29

Managed Objects

NetAct Configurator Principles

Figure 17

3.6.4

Managed object hierarchy in FTM management

Managed objects in WBTS site configuration


The following figure illustrates the managed object classes included in WBTS site configuration management.

30

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Figure 18

3.6.5

Managed Objects

Managed object hierarchy in WBTS site configuration management

Managed objects in RNC transport layer (ATM/IP)


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

DN03317888
Issue 13-1

Id:0900d805807cb38e

31

Managed Objects

NetAct Configurator Principles

Figure 19

3.6.6

RNC transport layer managed object hierarchy in WCDMA management

Relationships between WCDMA and core network


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

32

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Managed Objects

MSC
RNC ID, MCC
and MNC added
to MGWM

MGW ID,
MGW name

RNW
MGWM

RNC

NWLA

WBTS

LA

LAC
WCEL

Figure 20

3.7

MGW

MSA

SAC (Service
Area Code)
and LAC
Relationships between WCDMA and core network

Managed objects in I-HSPA


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

! ( # )

&$ / $

" # 9 + # " &


+ # " *
+ # " %
8 9 ! &
8 9 ! %
8 9 ! *
&! 7 #
&. " *
&. ! *
$ / : &

&. ,
4 - 5 *

4 " 6 (

4 ( " * 6

$ / : *
$ / : %

4 * # ( "
&! ) Figure 21

DN03317888
Issue 13-1

I-HSPA RNW managed object hierarchy

Id:0900d805807cb38e

33

Managed Objects

NetAct Configurator Principles

IADA

PLMN

ISWTP
IPNO

IAIF
IDNS
IEIF
IPRT

Figure 22

I-HSPA Adapter IP managed object hierarchy

! ( # )
&$ / $
* .
&! * (
$ * * 6

$ * * 9

* ) 4

# * 6 , '
9 * !

* " " !

* " " ! *

* " " ! * -

/ * !

* " " !

* " " ! *

* " " ! ( -

* , *
* " " ! !

&! * ( *

$ * * !
Figure 23

34

I-HSPA Adapter Signalling managed object hierarchy

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Managed Objects

PLMN
IADA
WBTS
FTM
UNIT
PPTT
SDHIF
ETHLK
IMAG
SYNC

STPG

TRDE
TCTT

VPCT
ACCP

VPTT

VCCT

CESIF

CESPWT

CESPW

CCFA
VCTT
ANBA
A2NE
IPNO

INTP

CERTH

IAIF

FRLI

IEIF
IPRT
IHCP
IPRM
TOPIK
QOS
BFD
TMPAR

Figure 24

DN03317888
Issue 13-1

I-HSPA FlexiTRS (FTM) managed object hierarchy

Id:0900d805807cb38e

35

Managed Objects

NetAct Configurator Principles

! ( # )
&$ / $
4 - 5 *
$ ; "
6 5 8 ( >

! 4 # !

! 4 ) 6

! 4 5 &!

. ) &5

# 9 / . (

! ! 5 5
* ! 5 5
* , 5 5
* # 5 5
* ' 5 5
+ , ( &
&# $ %
" &4 5
&+ ! %
* 5 ! %
5 9 ! &>

) ) / 5
5 " 5 5

$ " " !

- + /

5 , / 6

' ! " 5

7 9 *

' ! 5 5

' " " 5

5 # ! $ ,
&! , #

' " 5 5
$ = ) 6

Figure 25

3.8

$ = * 5

$ = . 5

&) 5 !

" " + $

&$ &+

&! ) 9

&6 &+

+ # $ *

+ # $ +

&! , 5

) < # /

) < " +

&* ! +

$ ) - $

5 ! 6 (

&8 " !

I-HSPA AXC managed object hierarchy

Managed objects in LTE


The following figures illustrate the managed object classes that are included in LTE
management:

36

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

3.8.1

Managed Objects

Managed objects in LTE RNW


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

Figure 26

3.8.2

Managed object hierarchy in LTE RNW management

Managed objects in FTM


The following figure illustrates the managed object classes included in FTM management:

DN03317888
Issue 13-1

Id:0900d805807cb38e

37

Managed Objects

NetAct Configurator Principles

Figure 27

3.8.3

Managed object hierarchy in FTM management

Managed objects in LTE BTS site configuration


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

Figure 28

3.9

Managed object hierarchy in LTE BTS site configuration management

Managed objects in FemtoBTS


The following figure illustrates the managed object classes included in FemtoBTS configuration management.

Figure 29

38

Managed object hierarchy in FemtoBTS configuration management

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

3.10

Managed Objects

Non-network objects and parameters


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

g A plan must be provisioned even if it contains only non-network parameters.


The non-network objects and parameters are used to manage the following network
configuration data: external cell objects, antenna objects, site object, and managed
object specific non-network parameters. The managed object specific non-network
parameters contain, for example, various identification parameters. The non-network
parameters are listed in Adaptation Information Browser in NetAct category.
Templateid and siteID are common non-network parameters for all managed
objects and are not listed in Adaptation Information Browser.

3.10.1

External Cell Objects


Foreign BTSs and External WCDMA Cells (EWCE) are used for managing adjacencies
between regions.
The foreign BTS object represents a BTS managed by another network management
system. In the managed object hierarchy, a foreign BTS is not an object class of its own.
The foreign BTS DN is PLMN-PLMN/BSC-0/BCF-0/BTS <id> where id is LAC CI (the
first 5 digits are reserved for LAC).
The EWCE represents the WCEL managed by another network management system.
In the managed object hierarchy, the EWCE is an object class of its own. The EWCE
DN is EXCC-1/EWCE <id> where id is a string with a maximum length of 10 characters.
For more information on inter-regional adjacencies, see Managing Adjacencies.
The following figure illustrates the managed object hierarchy for external cells:
External GSM cell objects: BSC-0, BCF-0, BTS (foreign BTS), TRX-1.
External WCDMA cell objects: EWCE (External WCDMA Cell) and EXCC (External
WCDMA Cell Collection).

PLMN
EXCC

BSC-0

EWCE

BCF-0
BTS
TRX-1

Figure 30

DN03317888
Issue 13-1

Managed object hierarchy for external cells

Id:0900d805807cb38e

39

Managed Objects

3.10.2

NetAct Configurator Principles

Antenna objects
The antenna objects include ANTC (Antenna Collection), ANTE (Antenna), GCAL (GSM
Cell-Antenna Link), and WCAL (WCDMA Cell-Antenna Link).
ANTE represents the base station antenna. GCAL and WCAL represent the feeder
cables, and also the relationships to GSM and WCDMA cells.
The following figure illustrates the antenna objects:

PLMN
ANTC
ANTE
GCAL
WCAL
Figure 31

3.10.3

Antenna objects

Site object
The SITE object is a way of storing the geographical location of the managed objects in
GSM, WCDMA, I-HSPA, and core networks. Site objects are created, deleted, and
modified with CM Editor which also provides user interface for assigning and removing
managed objects in a site.
Coordinate information for GSM BTSs can also be stored in the parent BCF and, in the
case of the foreign BTS, for the object itself.

3.10.4

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

40

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Concepts for managing configuration data

4 Concepts for managing configuration data


This chapter describes the following basic concepts of NetAct Configurator:
Actual configuration
Plans
Reference configuration
Templates
Site Templates
Rules

4.1

Actual configuration
The actual configuration represents the current network configuration. There is only one
actual configuration stored in the database. The actual configuration is stored partly in
the NetAct Configurator database (parameter data) and in the NetAct common topology
database (object data).
The actual configuration comprises of the following:
Managed objects, location in topology, and object identification in topology database.
Parameter values in Configurator database:
Parameters with interface from Configurator to network element.
Non-network parameters and non-network objects without a management interface from Configurator.
Object administrative state (locked, unlocked) in topology database.
Object state (operational, non-operational) in topology database.
Non-operational objects are stored in the topology and they are not part of the active
network. The non-operational objects may have been planned for future use, or they
have been deleted from network.
For more information, see Maintaining up-to-date picture of the network.

4.2

Plans
A plan is a configuration containing a set of modifications for the actual configuration.
Plan contains only modifications and it can be viewed on top of the actual configuration.
Plan can include the following types of modifications:
Add new managed objects with mandatory parameters (create operation).
Remove an existing managed object (delete operation).
Modify parameters (including administrative state) of an existing managed object in
a certain configuration (update operation). The distinguished name or version
cannot be modified using a plan. Modifying parameters of some future version of
managed object in target configuration is not possible.
There can be four possible kind of plans differ from each other by the purpose for what
they were created.
General plans - these are the standard plans created by the user.
Backup plans - these plans are created by the system, for example, they are generated during the provisioning because of the safety reasons.

DN03317888
Issue 13-1

Id:0900d805807cb38e

41

Concepts for managing configuration data

NetAct Configurator Principles

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 corrective delta plans. Exception plans also defines objects with exceptions to template
parameters (differences that should be kept unchanged).
For more information, see Configuring the network using plans.

4.2.1

Constraints for naming plans, templates and site templates


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

Character

Exclamation mark

Quote

"

Apostrophe

Accent mark

Semicolon

Scandic

Scandic

Scandic

Space

Table 6

4.3

Characters not allowed in plan, template and site template names

Reference configuration
The reference configuration is stored in the system as a separate data set from actual
and planned configurations. Reference configuration can describe the desired configuration 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

Templates
Templates define a collection of parameter values for a particular managed object class.
Templates are used for two purposes:
They define managed object parameters for new planned (CREATE) managed
objects that define how the object should behave. Parameter values in plans
override the corresponding value provided by the assigned template.
They identify the objects type, for example, pico, micro, and macro for BTS. This
can be used as object classification or assigning templates for related managed

42

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Concepts for managing configuration data

objects. For this purpose, the template can be assigned both for new planned
(CREATE) and existing actual managed objects.
There are two types of templates: user and system templates.

4.4.1

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

4.4.2

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

4.4.3

Using templates
A template is primarily used to define an initial parameter set for a new managed object
by assigning a template to the object. The user can define assignments for each planned
object manually in CM Editor. Assignment information can also be imported as part of
the plan into NetAct Configurator using CM Operations Manager. The assignment is
shown as the name of the template in user interfaces. Values from the assigned
template for new managed objects are automatically utilised by CM Analyser, CM
Editor, and CM Operations Manager the same way as they would have been defined
directly in plan.
Template assignment is non-network data for the managed object. When the plan is provisioned, 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 automatically based on cell type definitions. Cell type based template assignments are configured 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 construct 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.

DN03317888
Issue 13-1

Id:0900d805807cb38e

43

Concepts for managing configuration data

NetAct Configurator Principles

It is possible to define several structures for a structure parameter in a user template. In


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

4.4.4

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

4.5

Site Templates
Site Template mechanism allows user to create and store models of different base
station configurations and to use these model configurations when generating the
needed full configuration data for a new base station.
The purpose of the feature is that the user needs to define only a few mandatory parameters for a new base station, and the rest of the configuration is automatically generated
by the Configurator System. Scope of managed objects and their parameters included
in the Site Templates can be defined by the user.
Site Templates can be generated from the Actual Configuration or from the Planned
Configuration. Site Templates are applicable only for Flexi Multiradio BTS in LTE mode.

4.6

Rules
During network configuration planning and plan data building, many types of constraints
and dependencies need to be noted and taken care of. The risk that new erroneous or
incomplete plan harms network functioning after activation to network elements needs
to be minimised. NetAct Configurator rules and check functionality by CM Analyser can
be used for that purpose.
Configurator contains predefined rule sets that can be used in different procedures with
network configuration. Also new rules can be added and tailored into the system by the
user. Rules can be collected into rule sets. The sets must contain an appropriate selection of rules that can be meaningfully executed at the same time. Rule or rule set execution 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 corrective 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.

44

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

NetAct Configurator functionality

5 NetAct Configurator functionality


NetAct Configurator supports network development and optimisation with the following
optional functionalities:
2G Configurator
3G Configurator
I-HSPA Configurator
R4 core network Configurator
2G Rehosting
3G Rehosting
Consistency checking
Plan Actual Compare
XML Interface for Configuration Management Data
CSV Interface for Configuration Management Data
3GPP CORBA Bulk CM (If-N) Northbound Interface
RNC ATM and IP Parameter Management
FTM Parameter Management.
AXC Parameter Management
Workflow engine
Actual and Reference Configuration auditing
Configurator must be installed to use the Optimizer, Open API, or Automated Optimization Solution modules. For more information, see Optimizer Principles.

5.1

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

DN03317888
Issue 13-1

Id:0900d805807cb38e

45

NetAct Configurator functionality

Figure 32

NetAct Configurator Principles

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

46

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

NetAct Configurator functionality

Managing maintenance regions


Visualisation for:
GSM Multi-BCF for Master BTS and BCCH TRX
Locked objects
Related objects
Supporting all objects and parameters in search and modify/search criteria. Note
that complex SQL search, or MO query, can load the data server, and this affects
NetAct. For more information on MO Query, see Appendix: Available search queries
in CM Editor in CM Editor Help.
Configurable editor views for parameter editing
Controller filtering based on the controller maintenance region information
For more information, see CM Editor Help.

5.1.1

Table Editor
Table Editor tool in CM Editor provides additional means which facilitate and speed up
the managing of planed and actual configuration. Unlike in classic plan and actual configuration 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 comparing and modifying managed object's parameters much faster.
Beside basic operations that can be performed on managed objects (creation/deletion/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.

DN03317888
Issue 13-1

Id:0900d805807cb38e

47

NetAct Configurator functionality

Figure 33

5.2

NetAct Configurator Principles

Table Editor window in CM Editor

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

48

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Figure 34

NetAct Configurator functionality

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

DN03317888
Issue 13-1

Id:0900d805807cb38e

49

NetAct Configurator functionality

NetAct Configurator Principles

Creating plans on top of reference configuration


Managing templates:
Deleting templates
Importing and exporting templates
Managing site templates:
Deleting site templates
Importing and exporting site templates
Rehosting GSM BTS Sites
Rehosting WCDMA BTS Sites (3G Rehosting Wizard)
TRX Loop test
Managing the operation execution with the workflow engine
Visualising MML commands for R4 core network
Executing MML commands and MML command files for R4 core network and SGSN
Managing networks elements as a user defined groups in Command Manager
For more information, see CM Operations Manager Help.

5.2.1

3G Rehosting Wizard
3G Rehosting Wizard is a functionality included in the Rehosting WCDMA BTS Sites
tool, which facilitates and speeds up the execution of the WCDMA BTS sites rehosting
operations. It enables faster rehosting preparation by minimising the number of parameters 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 Operations Manager.
For instructions on how to use the WCDMA BTS Sites tool and 3G Rehosting Wizard,
see CM Operations Manager Help.
For instructions on how to perform the WCDMA BTS sites rehosting, see Rehosting
WCDMA BTS Sites.

5.2.2

Workflow engine
Workflow is a configurable workspace, executed from CM Operations Manager, where
operator-specific tasks can be defined and executed in a user-friendly manner.
Workflow engine controls the operation execution and takes care of the operation feedback. The purpose of workflow engine is to simplify and speed up the execution of processes 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

50

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

NetAct Configurator functionality

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

5.2.3

Workflow Engine window

Command Manager window


Command Manager window in CM Operations Manager provides a convenient and fast
way to execute commands to MSC, MGW, SGSN, GGSN ang FING. It allows you to
perform the following operations:
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;

DN03317888
Issue 13-1

Id:0900d805807cb38e

51

NetAct Configurator functionality

NetAct Configurator Principles

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 possibility to execute command at once on more than one group at one time.
For more information, see CM Operations Manager Help.

Figure 36

5.2.4

Command Manager window

Operation statuses in CM Operations Manager


CM Operations Manager provides the information on the statuses of the operations and
operation groups that the user has executed using CM Operations Manager. The operation 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

52

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

NetAct Configurator functionality

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 operation feedback.
Interrupted - The user has interrupted the operation, which has been in Started or
Ongoing state.
Interrupting (only for operation group) - The user has interrupted the operation
group, but operations which cannot be interrupted will be executed normally and will
go to Finished or Failed state.
Queuing - The operation has been put to a queue.
The operation or operation group status is updated to the CM Operations Manager user
interface every time the operation status changes. The status information is also saved
to the NetAct Database.
For more information, see CM Operations Manager Help.

5.3

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

DN03317888
Issue 13-1

Id:0900d805807cb38e

53

NetAct Configurator functionality

Figure 37

NetAct Configurator Principles

CM Analyser user interface

CM Analyser functionality includes the following operations:


Checking radio network and core network parameters and managed objects, and
ensuring that the parameters are defined according to consistency rules
Checking for discrepancies in actual configuration, planned configurations and in
reference configuration
Autocorrection: defining a rule for automatic inconsistency correction
For more information, see CM Analyser Help.

5.4

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

54

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Figure 38

NetAct Configurator functionality

CM Reference user interface

CM Reference functionality includes the following operations:


Generating deltas
Selecting and visualising deltas
Analysing deltas
Initializing reference
Copying the Distinguished Names of managed object deltas
Committing changes to the network and to the reference configuration
For more information, see CM Reference Help.

5.4.1

Actual and reference configuration auditing


Actual and reference configuration auditing manages the possible deviation between
the current configuration and the planned reference configuration. It helps in finding
elements configured wrongly, and provides a delta-plan-based option for implementing
changes in the network or to the reference.
It is also possible to identify configuration or topology changes in the actual network,
when important definitions such as adjacent cells have been deleted. Adjacencies can
be re-created based on the approved reference configuration.
For more information, see CM Reference Help.

DN03317888
Issue 13-1

Id:0900d805807cb38e

55

NetAct Configurator functionality

5.4.2

NetAct Configurator Principles

Initializing reference
Actual and reference configuration is strictly connected, this functionality allows to add
new MO(s) from the actual configuration in CM Reference to the reference configuration
that is visible in CM Editor application. This allows to store MO(s) in reference configuration 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 Configurator.

5.6

Site commissioning tools: Plan Editor and Site Configuration Tool


Plan Editor is used for creating commissioning data files for different network elements.
For more information on Plan Editor, see Plan Editor Principles. The commissioning
data files, such as site configuration files for the WCDMA BTS and AXC, can be stored
in Site Configuration Tool. Using the Site Configuration Tool, you can:
store site configuration files during roll-out phase and other files, such as installation
instructions and commissioning reports, in the site data repository;
exchange site configuration information of WCDMA BTSs and AXCs (WCDMA);
commission I-HSPA BTS TRS and Adapter RNW parts by providing possibility to
create and edit commissioning data files;

5.7

XML Interface for Configuration Management Data


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

56

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

NetAct Configurator functionality

are used to export data from NetAct to XML files and import data from XML files to Configurator database.
For more information, see XML Interface for Configuration Management Data.

5.8

CSV Interface for Configuration Management Data


NetAct Configurator provides the CSV interface for planning data as an open application
interface with means for seamless exchange of network configuration data between
NetAct and external systems. Its functionality includes importing and exporting plans as
well as exporting the actual or reference configuration.
The network configuration data is transferred using CSV (Comma-Separated Values)
files. CM Operations Manager and Command Line Interface are used to export data
from NetAct to CSV files and import data from CSV files to Configurator database.
For more information, see CSV Interface for Configuration Management Data.
Plan Editor can be used to import files in CSV format. For more information, see Plan
Editor Help.

5.9

3GPP CORBA Bulk CM Northbound Interface


3GPP CORBA Bulk CM Northbound Interface provides a network management interface 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.

DN03317888
Issue 13-1

Id:0900d805807cb38e

57

Maintaining up-to-date picture of the network

NetAct Configurator Principles

6 Maintaining up-to-date picture of the network


NetAct maintains an accurate and up-to-date picture of the underlying network. The
managed network and NetAct system are synchronised by using two separate methods:
Real-time updating of the NetAct database by NetAct event management.
Uploading of the network configuration and parameters.
The following figure illustrates actual configuration data handling, collection, storing, and
tools in NetAct Configurator:
Optimising

External network
management

NetAct Optimizer

Management
System

3GPP Bulk CM Itf-N

Proprietary interface
Plan
databuilding

RAML/CM 2.0
RAML/CM 2.1

read

data available to
other systems

Plan Editor

GUI/CLI
file export
Radio planning

RAML/CM 2.0
RAML/CM 2.1

Planning tool

Other tool,
for example,
reporting

GUI
applications

read

GUI/CLI
upload

GUI/CLI
events, upload

RAML/CM 2.0
RAML/CM 2.1
CSV
NetAct
Configurator

NWI3
GOMS

Q3/XML

NWI3
GOMS

(configurable)

BSC***

NWI3

RNC**

MML
Q3
GSM
SGSN

MML
MSC/
MGW

NWI3
AXC*

NWI3
I-HSPA
AXC*

BTS O&M
eNB

Figure 39

I-HSPA
IADA**

I-HSPA
FTM*

BTS*

WBTS
FTM*

Actual configuration data handling, collection, storing, and tools

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

6.1

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

58

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Maintaining up-to-date picture of the network

Changing the administrative state of a managed object


Changing the parameters of a managed object

g When the adjacency creation event is received, an external cell is automatically


created to the NetAct database as a target cell. This also applies when the target
cell is not found during the upload.

6.1.1

Real-time updating for GSM


You can make local changes to the managed objects by using the local MML of the
network elements. The BSC S14 sends events via XML interface. The BSC S13 can be
configured to send events either via Q3 or XML embedded in Q3 interface, but XML
embedded in Q3 interface usage is preferred one due to better performance.
There are no events from BTS site configuration. The actuals need to be updated by
uploading.

6.1.2

Real-time updating for WCDMA


You can make local changes in the RNC with the RNC RNW Object Browser.
There are no events from AXC, FTM, and RNC ATM/IP. The actuals need to be updated
by uploading.

6.1.3

Real-time updating for core network


There are no events from core network elements.

6.1.4

Real-time updating for I-HSPA


When making local changes in the I-HSPA Adapter RNW, the NE sends events via
GOMS to NetAct.
There are no events from AXC, FTM, I-HSPA IP, and I-HSPA Signalling. The actuals
need to be updated by uploading.

6.1.5

Real-time updating for eNB


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

6.1.6

Real-time updating for LTE GOMS


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

6.2

Uploading network data


You can update the radio network and core network information with CM Operations
Manager and Command Line interface using the upload operation.
The accuracy of information in the NetAct database must be checked, for example,
when:

DN03317888
Issue 13-1

Id:0900d805807cb38e

59

Maintaining up-to-date picture of the network

NetAct Configurator Principles

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 IHSPA);
local changes have been made to the RNC ATM/IP configuration;
local changes have been made to the I-HSPA IP or I-HSPA Signalling configuration;
local changes have been made to the MSC/MGW configuration;
local changes have been made to the eNB configuration (LTE);
The status of upload operation executed by the user in CM Operations Manager can be
monitored in CM Operations Manager user interface. For more information, see section
Operation statuses in CM Operations Manager.
The tool automatically updates the parameter information of managed objects and
creates all the missing child objects in the NetAct database. It also deletes the actual set
of those objects that are defined in the NetAct database but do not exist in the network.
For detailed instructions, see CM Operations Manager Help.
For information on how the upload operation can be scheduled to happen automatically,
see Configuring the automatic upload operation in Administering NetAct Configurator.

6.3

Exporting network data


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

60

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Configuring the network using plans

7 Configuring the network using plans


The following figure illustrates plan based configuration management, systems, interfaces, and flow of configuration data in NetAct Configurator:
Optimising

External network
management

NetAct Optimizer

Management
System

Proprietary interface
Plan databuilding

3GPP Bulk CM Itf-N

RAML/CM 2.0
RAML/CM 2.1

write

data available from


other systems

Plan Editor

GUI/CLI
file import
Radio planning

RAML/CM 2.0
RAML/CM 2.1

GUI/CLI
create, edit,
read check, compare

Planning tool

Other tool,
for example,
reporting

GUI/CLI
provision

plan

RAML/CM 2.0
RAML/CM 2.1
CSV
NetAct
Configurator

NWI3

GOMS

NWI3

GOMS

XML/Q3

BSC

NWI3

RNC

MML
Q3
2G
SGSN

MML
MSC/
MGW

NWI3
AXC

NWI3
I-HSPA
AXC

BTS O&M
eNB

Figure 40

7.1

I-HSPA
IADA

I-HSPA
FTM

BTS

WBTS
FTM

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


configuration data

Importing plans
A plan that has been created with a planning tool can be imported to the NetAct Configurator with CM Operations Manager.
The status of import 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.

7.2

Comparing plans to actual configuration


The Plan Actual Compare function in CM Operations Manager can be used for the following purposes:
To review planned network modification plans against actual network configuration
before provisioning. If the actual configuration is changed before the plan is provisioned into network, the plan can become inconsistent.

DN03317888
Issue 13-1

Id:0900d805807cb38e

61

Configuring the network using plans

NetAct Configurator Principles

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
be monitored in CM Operations Manager user interface. For more information, see
section Operation statuses in CM Operations Manager.

7.3

Completing plans
You 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 plans
With 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 LNBTSs
ADIPNO is added to plan (if does not exist in the plan) and source LNBTSs
IPNO Control plane IP address is added to target ADIPNO Adjacent eNB IP
address parameter (if does not exist).

62

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Configuring the network using plans

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
section Operation statuses in CM Operations Manager.

7.5

Provisioning plans
CM 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 provisioning 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 configuration change.
A plan can contain changes on several network technologies and different element versions.
The status of provision 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 following figure illustrates the interfaces and databases in the network elements
used during plan provisioning process:

DN03317888
Issue 13-1

Id:0900d805807cb38e

63

Configuring the network using plans

NetAct Configurator Principles

File based
provisioning
Pre-activate
Q3

Save active config.


as fallback

Activate

Plan

Activate
Pre-activated Plan

Active

Fallback
Fall back
via MML

Activate

BSC

Activate
NWI3

Pre-activate

Activate
Pre-activated Plan

New

Active

Fallback
Fall Back

RNC

Activate
New
Plan

NWI3
Pre-activate

New Plan

Activate
Pre-activated
Plan

AXC
FTM

Active Plan

(WCDMA and I-HSPA)

Activate
NWI3
Pre-activate

New Plan

Activate
Pre-activated
Plan

Active Plan

WBTS
IADA
(I-HSPA)

Active Plan

eNB
(LTE)

Activate
NWI3
Pre-activate

MML
MML
Q3

New Plan

Activate
Pre-activated
Plan

Activate

New
Plan
New
Plan
Active

Activate

New
Plan
New
Plan
Active

MSC/MGW

2G SGSN

Activate
Q3

Activate
Pre-activated
Plan

Pre-activate
BTS specific
file

BSC

Figure 41

7.5.1

BTS specific
file

BTS

Interfaces and databases in the network elements used during plan provisioning process

RNC plan activation and pre-activation


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

64

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Configuring the network using plans

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 significantly.
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 Operations 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 activation

7.5.2

BSC plan activation and pre-activation


For BSC provisioning, there are two methods available:
File-based plan provisioning
Q3-based plan activation (only for BSC S13 release)
File-based plan provisioning
File-based plan provisioning offers better performance compared to the obsolete Q3based 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 information, 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.

DN03317888
Issue 13-1

Id:0900d805807cb38e

65

Configuring the network using plans

NetAct Configurator Principles

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 provisioning. Instead, the new mechanism of plan provisioning is used. At first all parameters supported by file-based plan provisioning are activated using file-based plan provisioning
method. Then the parameters not supported by file-based plan provisioning are automatically 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 provisioning are left untouched during the plan provisioning operation. They must be activated 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-activation


Flexi 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 transferred 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.

66

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Configuring the network using plans

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 Rehosting GSM BTS sites and <relevant document>

7.5.4

AXC and FTM plan activation and pre-activation


AXC 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-activation


I-HSPA 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.6

eNB plan activation and pre-activation


eNB 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 Provisioning 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 Activated automatically before "user plan" is pre-activated and activated. Unlocking is
appended to "user plan" and then eNB does the unlocking automatically after modification. 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-activation


PREBTS objects, that are used for auto connection, can be pre-activated and activated
to GOMS database.

DN03317888
Issue 13-1

Id:0900d805807cb38e

67

Configuring the network using plans

7.5.8

NetAct Configurator Principles

MSC and MGW plan activation


MSC and MGW does not support separate pre-activation operation but the changes are
always activated directly in the network.

7.5.9

SGSN plan activation


SGSN does not support separate pre-activation operation but the changes are always
activated directly in the network.

7.5.10

Non-network parameters and objects


Non-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 provisioning


You 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 configuration


If 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 plan


A backup plan is a reverse plan of the original plan. Creation operations are converted
to deletion operations and deletion operation to create operations. Parameter modifications 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.

68

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Configuring the network using plans

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 configuration


AXC, 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 generated 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 operation


A 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 unexpected 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 appropriate 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 import


You can export the actual or reference configuration of related controllers to a file with
CM Operations Manager. When necessary to restore the original parameter configuration for GSM, WCDMA, LTE, I-HSPA, and R4 core network import the file and provision
it to the network.

DN03317888
Issue 13-1

Id:0900d805807cb38e

69

Configuring the network using reference configuration

NetAct Configurator Principles

8 Configuring the network using reference


configuration
The following figure illustrates the reference based configuration management in NetAct
Configurator:

Plan
Import/Create
a plan

Check plan and update


planned changes
into Reference Configuration
Reference
Configuration

Generate delta and


save plan

Plan
Configuration

Build
Reference
Configuration
Provision plan
to network

Actual
Configuration
Actual
Configuration
Upload

Network
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 auditing


The following figure illustrates the delta report generation, in CM Reference application:

70

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Configuring the network using reference configuration

Generate Delta Report

Delta Analysis

Network Alignment

Reference Alignment

Ignore Delta

MO StandBy
Yes

More
Deltas?
No
Provision to Network/
Merge to Reference
Configuration

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 differences 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 procedure 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 management
Delta 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 visualised, 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 alignment


Reference configuration can be updated according to the delta report. This can exclude
potential mistake in the configuration. After that user can generate an actual configuration update plan which can be provisioned to the network. For more information, see CM
Reference Help and CM Operations Manager Help.

DN03317888
Issue 13-1

Id:0900d805807cb38e

71

Configuring the network using reference configuration

8.2

NetAct Configurator Principles

Exporting reference configuration data


You 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 configuration


The following figure illustrates the possible checks that can be started in NetAct Configurator to eliminate possible errors in plan management:
Get Plan
Get Plan

Consistency Check
(optional)

Ready
for Merge?

No

Archive Plan

Yes
Merge to
Reference Configuration

Figure 44

Provision to Network

Network Planning with Reference Configuration

Consistency checks are made to check if any errors and inconsistencies occurs in a reference configuration. As a result of a check a reference correction plan(s) is/are generated. 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 configuration


Reference configuration can be updated by merging a NetAct Configurator plan. This
allows to create, delete and modify MO(s) in reference configuration.

72

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Managing objects one by one

9 Managing objects one by one


This 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 information, see Administrative states and Locking and unlocking managed objects in the
network in CM Editor Help.

9.1

Send to Network for GSM


Send 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)

DN03317888
Issue 13-1

Id:0900d805807cb38e

73

Managing objects one by one

NetAct Configurator Principles

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 Activation for RNC' license has been purchased.

g If a parameter modification requires object locking and unlocking, it is done automatically 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 configurations 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.

74

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

9.3
9.3.1

Managing objects one by one

Send to Network for core network objects


Send to Network for MSC
Send 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 MGW


g Send to Network functionality for R4 core network objects (MSS and MGW) is available 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 supported (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 SGSN


Send 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 objects


Send to Network functionality in CM Editor can be used to manage the following nonnetwork objects:
Foreign BTS

DN03317888
Issue 13-1

Id:0900d805807cb38e

75

Where to find more information

NetAct Configurator Principles

10 Where to find more information


For more information related to NetAct Configurator and network configuration management, 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 Systemwide 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 Management Data.

76

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Where to find more information

Parameters
For more information on parameters used when configuring the network, see Adaptation 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 Description 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 documentation, see NetAct Electronic Documentation.
RNC documentation
For more detailed information on the RNC RNW Object Browser, see the RNC RNW
Object Browser online help.

DN03317888
Issue 13-1

Id:0900d805807cb38e

77

Appendix A: Objects not supported by file-based plan


provisioning

NetAct Configurator Principles

11 Appendix A: Objects not supported by filebased plan provisioning


The 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.

78

Id:0900d805807cb38e

DN03317888
Issue 13-1

NetAct Configurator Principles

Index
A

rule sets 44
rules 44

administrative states
basics 14
locked 14
shutting down 15
unlocked 15
applications
CM Operations Manager 59
Plan Editor 57

S
states
administrative 14
object 14
of managed objects 14

uploading 59

checks 44
CM Operations Manager 57, 59, 62

X
XML 56

D
database
updating 58

I
interfaces
3GPP CORBA Bulk CM Northbound 57
CSV 57
XML 56

M
managed object hierarchy
GSM 23
LTE RNW 37
MSC 26
RNC RNW 27
SGSN 26
managed objects
states 14

O
object states
created from network 14
non -operational 14
operational 14

P
Plan Editor 57

R
Radio Access Markup Language for Configuration
Management 56
RAML CM 2.0 57
real -time updating 58

DN03317888
Issue 13-1

Id:0900d805807c3ab9

79