CPCM High Level User Guide

CPCM
CPCM High Level User Guide
Version: 3V1
Projekt/Titel: CPCM Filename: CPCM High Level User

Guide.docx
Bezeichnung: CPCM High Level User Guide Version: 3V1
© 2017 MicroNova AG (* siehe letzte Seite) 1

Erstellungs- / Änderungsvermerke
Name Datum Version Änderungsgrund Freigabe

Martin Kohls, 27.09.2016 1E0 Initial document
Dietmar Gauder,
Dominik Hindl,
Anton Kublan
Michael Mai 07.10.2016 1V0 Review and corrections
Martin Kohls 17.10.2016 1V1 Worked in some suggestions
after user review
Dietmar Gauder 2E0
Michael Mai 21.12.2016 2V0 Review and corrections
Michael Mai 21.06.2017 3E0 Annotations and new chapters
Martin Kohls 05.07.2017 3V0 Doc. of Integration Wizard
Martin Kohls 12.09.2017 3V1 Worked in customer/internal
suggestions/corrections after
review

Guide.docx

Content
1 From Plan to Wirk via CPM-CCM or IWZ .............................................................................. 4
1.1 Short Overview over the data workflow in CPM .................................................................... 4
1.2 Short overview over the data workflow in IWZ .................................................................... 6
2 Login ............................................................................................................................. 6
3 CPM ............................................................................................................................... 7
3.1 Planning ......................................................................................................................... 8
3.1.1 Import ....................................................................................................................... 8
3.1.1.1 Atoll import ............................................................................................................ 8
3.1.1.2 XAKTA Import ........................................................................................................ 9
3.1.1.3 Importing a Use Case List (Action List) .................................................................... 10
3.1.1.4 DataEngine-Import ............................................................................................... 12
3.1.2 The Data Engine and its working copy.......................................................................... 13
3.1.3 DataBrowser ............................................................................................................. 14
3.1.3.1 Basic editing and filtering ....................................................................................... 14
3.1.3.2 Sorting ................................................................................................................ 15
3.1.3.3 Searching for parameters ...................................................................................... 15
3.1.3.4 Hiding columns ..................................................................................................... 16
3.1.3.5 Hierachical Filter (NE-filter) .................................................................................... 16
3.1.3.6 Parameter Filter .................................................................................................... 17
3.1.4 CSV-/Excel Export ..................................................................................................... 17
3.1.5 Rule Editor ............................................................................................................... 18
3.1.6 DataEngine-Export into Workspace .............................................................................. 19
3.1.7 NWP-Editor............................................................................................................... 19
3.1.8 Export2CCM ............................................................................................................. 20
3.2 Optimizing .................................................................................................................... 22
3.2.1 Create SCRs ............................................................................................................. 22
3.2.1.1 Neighbour GUI / Excel-Import ................................................................................ 22
3.2.1.2 Parameter GUI / Excel-Import ................................................................................ 23
3.2.2 Apply WS/RDE .......................................................................................................... 25
3.2.3 SCR Overview ........................................................................................................... 25
3.2.4 Trace Back ............................................................................................................... 26
3.3 Data Verification ............................................................................................................ 26
3.3.1 NET-Import .............................................................................................................. 26
3.3.2 Delta ....................................................................................................................... 27
4 CCM ............................................................................................................................. 28
4.1 Import ......................................................................................................................... 28
4.1.1 Plan import............................................................................................................... 28
4.1.2 Live import ............................................................................................................... 29
4.2 Delta............................................................................................................................ 30
4.2.1 Deltabildung ............................................................................................................. 30
4.2.1.1 Delta Tree and Detail Table .................................................................................... 30
4.2.1.2 Object Delta Tree and Parameter Delta Tree............................................................. 31
4.2.1.3 Planexport and Selective Delta ............................................................................... 31
4.2.1.4 Statistic ............................................................................................................... 33
4.2.1.5 Searching ............................................................................................................ 33
4.2.1.6 Blacklist ............................................................................................................... 34
4.2.2 Export ..................................................................................................................... 35

Guide.docx

5 Integration Wizard ......................................................................................................... 36
5.1 Import ......................................................................................................................... 37
5.1.1 Atoll ........................................................................................................................ 37
5.1.2 X:Akta ..................................................................................................................... 38
5.1.3 Equipment ................................................................................................................ 39
5.2 Data Browser ................................................................................................................ 39
5.3 Rule Editor.................................................................................................................... 39
5.3.1 Raw Data Checks ...................................................................................................... 40
5.3.2 Global Checks ........................................................................................................... 40
5.4 Monitor ........................................................................................................................ 41
5.4.1 Recalculate Monitor Data ............................................................................................ 41
5.4.2 Generate Export File .................................................................................................. 43
5.4.3 Reset Monitor Status ................................................................................................. 44
5.4.4 Planexport ................................................................................................................ 44
5.4.5 About the ID Generation ............................................................................................ 44
5.4.6 History ..................................................................................................................... 45
6 Glossary ....................................................................................................................... 45
1 From Plan to Wirk via CPM-CCM or IWZ

There are two paths that lead from plan data to wirk data: Either the “classical” path using CPM-CCM, which
yields full support to integrate arbritrary plan data changes into the wirk network, or the new “fast-track”
IWZ (Integration Wizard), which allows to quickly integrate the plan changes coming from creating sites,
cells or trxs into the wirk network.
1.1 Short Overview over the data workflow in CPM

The following picture illustrates the data workflow of the planning component CPM (Common Planning
Managment) of CPCM.

Guide.docx

We briefly describe the different CPM-datasets:
1. Atoll Data: These data consist mainly of a copy (in CPM-format) of the data provided by the radio
planning tool ATOLL (see 3.1.1)
2. Data Engine Working Copy / Data Engine: These contain the vendor specific data set, obtained
by transformation of the ATOLL data. Only one data set (plus its working copy) per a given software
version can exist at a time. (see 3.1.1.4, 3.1.2). Note that a (CPM-relevant partial) copy of the
external data set of the fixed network planning tool is automatically imported in CPM XAKTA
data during the import into the Data Engine.
3. The Data Engine data can be exported into the workspace once they are in a consistent form. The
workspace can contain arbitrary many data sets, hence history can be preserved. In the workspace,
the data must be merged with NWP Templates. The workspace local consists of the subset of
activated workspace data sets, i.e. those which are meant to be exported further. Hence only one
workspace data set per region and technology can be in the workspace local at the same time. (see
3.1.6)
4. While data in Data Engine (Working copy) and Workspace (local) are in plan data format,
when the data set of workspace local is exported into Workspace global, it will be transformed in
wirk data format. For this transformation, also the fixed network data (imported during data
engine import) are used (see 3.1.8). At most two data sets per software version can be in
workspace global at the same time.
5. When a dataset in workspace global is consistent, it can be activated, and then imported into
CCM by plan-import. However, this step is already performed from the other component of CPCM,
the CCM (Common Configuration Managment), see 4.1.1.

Guide.docx

1.2 Short overview over the data workflow in IWZ
The following diagram gives an overview of the data flow in the Integration Wizard.
First, there are raw data sets for RADIO (RPT), TRANSPORT (FIT) and EQUIPMENT (EQP). These have to
be imported first from the corresponding tools, e.g. ATOLL and X:AKTA. These data sets have to pass
consistency checks and approval by a user before they can be used. From the other side, Wirk data have
to be imported in CCM. The Monitor shows for each site the Integration status, i.e. the delta between
plan data and Wirk data. If the current raw data set is approved, a frozen copy will be created for the
delta, otherwise, when the current raw data set is not approved, the last frozen copy will be used. NET
data are imported from CCM. When refreshing the monitor, global checks over (frozen) raw data sets and
net data are performed. For sites which pass all checks and a supported delta-usecase is detected, export
files can be created.
2 Login
After we start the CPCM client, the login screen appears, where you have to enter your user name and
password. These information should be given to you by your administrator. You can also choose to which
servers (CPM/CCM/IWZ) you want to connect, and enter their corresponding URLs. Note that you need
to connect to at least one server in order to start the client. If you log in the first time with the initial
password given to you, you will be prompted to change the password and choose your own one.
The following URLs are currently in use (July 2017):

Guide.docx

Operator O2(CPCM blue) EPLUS (CPCM green)
CPM-Server 10.127.4.97:8080 10.224.133.6: 8080
CCM-Server 1 10.127.4.90:8079 10.224.133.4: 8079
CCM-Server 2 10.127.4.91: 8079 -
IWZ-Server 10.127.4.97:8080 -
After login in, the main window of CPCM appears. What exactly you see, depends both on your rights, given
to you by your admistrator, and also which view you had opened last time.
CPCM Client main window, Data Maintenance View
3 CPM
The planning component of CPCM is called CPM (Common Planning Managment). It allows you to import
the data from radio and fixed network planning tools, and then transform them into the vendor specific
formats for e.g. NOKIA, HUAWEI or SIEMENS equipments, depending on nettypes 2G,3G,4G, the software
version of the equipment (e.g. RG20, RAN18, LTE16,...) and also different planning releases, which are of
the form (R/E)(YEAR)_(NUMBER), like R2016_7 and E2016_6 where R are the releases for O2 and E are
the releases for EPLUS. The data can then be manipulated and checked for consistency in many different
ways, before they are ready to be exported to the configuration component CCM (Common Configuaration
Management) of CPCM, and from there to the network.
The data sets in CPM are stored in CPM-Regions which are independent from each other, and correspond
to a database scheme. There is one CPM-Region per planning region and vendor.

Guide.docx

3.1 Planning
We now give a brief overview of how planning data can be imported, manipulated and checked in order to
be made ready for export to CCM. Note that for each planning region (for which you have the necessary
right to do the planning),
there is an extra tab in the
Navigation window of the
Data Maintenance View.
Before you go on, make
sure you select the tab
belonging to the region in
which you want to do the
planning.
Planning Regions TESTBED_NOKIA, TESTBED_HUAWEI, TB_EPL_NOKIA, TB_EPL_SIEMENS as tabs
3.1.1 Import
Basis for CPM are the radio planning data (RPT data) and the fixed network data (FPT data). The Use
Case List (Action List) defines which sites have to be imported into the DataEngine. So the first steps are
the imports of the RPT data (see 3.1.1.1), the import of the FPT data (see 3.1.1.2XAKTA Import), the
import of an Action List (see 3.1.1.3) and the DataEngien import (see 3.1.1.4). Before the first
DataEngine import, RPT data, FPT data and an Action List must exist.
3.1.1.1 Atoll import

The first step is to import the data from the radio planning tool (ATOLL) as a copy into
your planning region. This has to be done for each desired nettype 2G,3G,4G
separately, and in each planning region (which we also call CPM regions). To perform
the import, click on the corrpesponding blue arrow between the RPT-Computer icon
and the RPT Actual pots. Note that the arrows are
blue only for those nettypes for which ATOLL data are
available. A dialog window will open, where you could
change the choice of planning region and nettype,
before you start the import via the Start-button.
The blue arrow will start to blink, and the import is
started. Note that, if another user with another CPCM
client has started an ATOLL import, the blue arrow in
you client will blink too, and only one import per
region/nettype can be performed at the same time.
Also in the tab called RPT Data, which is usually in
the lower part of your client window (but can – like all tabs of CPCM – be dragged around freely, even
outside your CPCM-client window), you should latestly by now see in its sub-tab Data an entry belonging
to the imported Atoll data.
Instead of clicking on the blue arrow, the import can also be started
by right clicking in this Data tab and selecting “RPT Import Alles ...”.
In both cases, a complete Atoll import is started. The context menu
offers three more options for partial Atoll imports, namely only the
frequency plan, neighbour-relations or external neighbour-relations.

Guide.docx

During the import, the STATUS column will show “importing atoll data”, which after
the import will switch to “OK”, and the arrow stops blinking. Then the pot
corresponding to the nettype you imported is yellow, which indicates it has data,
but they are not yet checked for consistency. Now right click on the yellow pot,
and choose “Konsistenzcheck” from the context menu. Now if everything
is fine, the pot will turn green (or red otherwise), and the CONSISTENT
column of the table above will show the date when the last successful
consistency check was performed.
You can watch and edit the imported ATOLL Data by double clicking the desired entry of the “Data” sub-
tab of the “RPT Data” tab. Then the “Data browser” sub-tab will open, where on the left side you can see
the ATOLL-Tables (Objects), and by clicking on a table, you will see its contents on the right side of the
tab, i.e. the parameters (columns) and their values. This parameter values can be edited, and also filtered.
This right side of the tab is CPCM’s Data Viewer, which not only appears for the Atoll Data, but almost
everywhere in the Client where Tables are involved. Also a “Data Browser” tab with the same structure,
i.e. table names in the left part and contents of a selected table in the right part, appears multiple times in
CPCM. It is therefore explained in more detail later in section 3.1.3
3.1.1.2 XAKTA Import

Next step is to import the data from the fixed data planning tool (XAKTA) as a
copy into your planning region. The proceeding is analogous to the Atoll
import described in 3.1.1.1.
The XAKTA Import has to be performed for each CPM Region and nettype
separately. It is started by clicking one of the blue arrows between the FPT
computer icon and the FIT Actual pots. The blue
color of the arrow indicates that XAKTA data is
available. A grey arrow is inactive and is not
clickable. A dialog opens to choose planning region
and nettype. The Import Button starts the import.
Now the blue arrow is blinking until the import is
finished.

Guide.docx

In the tab called FIT Data, you should now see in its sub-tab Data an entry belonging to the imported
XAKTA data. During the import, the STATUS column will show “importing fit data”, which after the import
will switch to “OK”. The pot corresponding to the nettype you imported is yellow now, indicating that a
consistency check has not been performed for the imported data. Run a consistency check by right
clicking on the yellow pot and choosing “Konsistenzcheck” from the context menu. Now if everything is
fine, the pot will turn green (or red otherwise), and the CONSISTENT column of the table above will show
the date when the last successful consistency check was performed
Like the tab RPT Data the tab FIT Data has a Data Browser to inspect or edit the imported XAKTA data
given that you have the access rights to do so. The data browser is explained in 3.1.3.
3.1.1.3 Importing a Use Case List (Action List)

While the ATOLL data and XAKTA data can only be imported completely, there are several choices of use
cases which allow to control which sites are imported or modified from ATOLL data into data engine data.
Therefore before we can import any data into the data engine, we have to import a list of use cases, which
we also call an Action List. The Action List has to be in .xlsx format, and looks like this:
The first column is the name of the use case to be performed. These come from a fixed set of use cases,
that were defined in ZeroTOC Project. Then
“Controller Basekey” and “Site Basekey” define
which Sites/Contoller shall be affected by the use
case. Finally, the ActionGroupID is an arbitrary
name, which defines the list of actions to be
performed when this Action List is used. For
example, for one ActionGroupId, you could have
both the use cases 2G_Dismantling for one site,
and 2G_NewSite for another site. A very special
and important use case is the 2/3/4G_InitialPAC.
This use cases both sets up the necessary inital
database structure of the plan model, and also re-
sets the values of all parameters depending
directly from atoll – but only for sites that are
already imported in the data engine. Therefore,
this use case does not have a Controller/Site
Basekey. Also this use case cannot be combined
with any others within the same ActionGroupId.
Another special use case is the 2/3/4G_PrePAC. It is a combination of the InitialPAC and several other use
cases (including _NewSite), so it both sets up the database structure, and also imports data for the given
site list.
In order to import an Action List, select the sub tab “Action List” of the “Data Engine” Tab of your region,
right click in the table, and choose “Maßnahmen importieren” from the context menu.

Guide.docx

Then a dialog window will open, from which you can select
an .xlsx file to import. You can then see the results of the
import in the “Action List” tab. Right clicking on an entry
offers also options for deleting entries from the Action List.
As reference for the definition of use cases, see MN_Spezifikation_CPCM_ZeroTOC_1v19.docx.

The following use cases are defined there:
2G_Dismantling
3G_Dismantling
4G_Dismantling
2G_DeleteSite
3G_DeleteSite
4G_DeleteSite
2G_NewSite
3G_NewSite
4G_NewSite
2G_MorneRadioTx
3G_MorneRadioTx
4G_MorneRadioTx
2G_FreqChange
3G_PSCChange
4G_PCIChange
2G_Reparent
3G_Reparent
4G_Reparent
2G_ParamChange
3G_ParamChange
4G_ParamChange
2G_NeighbourChange
3G_NeighbourChange
4G_NeighbourChange
2G_ParamChangeTx
3G_ParamChangeTx
4G_ParamChangeTx
2G_BSCChangeTx
3G_RNCChangeTx
4G_SECGEChangeTx
4G_MMEChangeTx
4G_UGWChangeTx
2G_InitialPAC
3G_InitialPAC
4G_InitialPAC
2G_REPChange
2G_REPDelete
3G_REPChange
Guide.docx

3G_REPDelete
2G_MSSRehoming
3G_MSSRehoming
2G_PrePAC
3G_PrePAC
4G_PrePAC
3.1.1.4 DataEngine-Import
Now we import the Atoll Data into the Data Engine. A DataEngine import
has the prerequisite that a consistent data record in RPT Actual and FIT
Actual must exist for the desired nettype and planning region. To start the
import, click on the blue arrow between the RPT Actual and Data Engine pot
with the desired nettype. Then a dialog window will open, where you can
select the planning region, the equipment, software version, release and
one of the action lists you have imported before. As we haven’t imported any data before, the only action
list allowed is the one belonging to an InitialPac or to a PrePac, as these uses cases are the only ones
that set up the necessary database structure. Also note that the InitialPac use cases only updates
parameters of already existing sites, but does not import any new sites itself, so after this
import, all tables will still be empty. In order to really import data of sites, an Action List containing a
use case like NewSite must be used afterwards. Conversely, the PrePac use case both sets up the database
structure and imports data.
Note that in a region, for each equipment and software version, there are usually two instances of data
sets present: The “actual” Data-Engine data (which we will now call DTE-data), and a working copy
of it (which we will call DWC-data). For the further steps for exporting data through to CCM and into the
network, only the DTE-Data can be used. Therefore, the DTE-Data are considered to be more worthful and
need to be protected from failed imports. It is always possible to create a 1-1 copy of the DTE-data into
the DWC-data (even when DTE-data are inconsistent). Reversely, only a consistent set of DWC-data can
be copied into the DTE-data. So for saftey reasons, a DataEngine import is only possible into DWC-data,
so even after a failed import, the DTE-data will be unaffected. This explains the two buttons for importing
into the Data Engine:
 Neue Arbeitskopie für Import erstellen (recommended): This should be the button which is usually
used. It first copies the DTE-data to the DWC-data (old DWC-data will be deleted!), and then
imports into the DWC-data.
 Bereits existierende Arbeitskopie für import verwenden: If you press this button, the data will
directly be imported into the DWC-data. This makes sense if you haven’t changed your DTE-data
in between, but have already done several changes on your working copy.
In the case there are not any DTE-data yet (for example if a new software version is introduced), both
buttons will do the same and directly import into the DWC-data. Similarly as after an ATOLL import, the
“Data” sub tab of the “Data Engine” tab will show a new entry with tableprefix DWC which represents your
imported DWC-data.

Guide.docx

Also after any import (or any manual change of the data), the consistency is “UNCHECKED”,
which is also indicated by yellow color. Note that the color of the “Data Engine” pot never
shows the consistency state of the DWC-data, but always of the DTE-data, so its colour
might still be grey. Now once you have done all your use case based imports and manual
still grey changes on your working copy and think it is ready to become the actual DTE-data, you have to
get it through the consistency check, because only consistent
DWC-data can become new DTE-data. To start the
consistency check, right click on the DWC-data entry in the
“Data” sub tab of the “Data Engine” tab, and choose
“Konsistenzcheck”. If everything is fine, you should see the
date-time in the CONSISTENT-
column in green colour, indicating
the DWC-data are now consistent.
Note that whenever you make
any change to this DWC-data set (manually or by new
imports), the column gets “UNCHECKED” again, as of course any change could corrupt the consistency
of your DWC-data. Now if you want to make your DWC-data the
new DTE-Data, right click again on the DWC-data entry and choose
“Arbeitskopie in die Data-Engine mergen”. Note that after this
action is performed, the DTE-data are a 1-1 copy of the DWC-data (the word “mergen” only indicates that
the mechanism behind is able to just copy/delete/modify the data that really have changed, and leave the
rest untouched. But the result is really a copy, and not a mixture!). After the merge, you should see the
DTE-entry in the “Data”-sub tab of the “Data Engine” tab, (for saftey reasons with CONSISTENT-state
“UNCHECKED”, and the colour of the Data Engine pot (which, as mentioned before, always
shows the DTE-data consistency, and never the DWC-data consistency) has changed to yellow.
In order to export the DTE-data further into the workspace, they have to be consistency-
checked in the same way as the DWC-data, also see section 3.1.6. Note that in the situation
we just described, where there exist DWC-data but no DTE-data yet, you can always merge
your DWC-data into the DTE-data. However, there is a mechanism to prevent from doing so when the DTE-
data have newer modifications (that would be lost after the merge) – see the next section for the details.
Fixed Network Data

Note that whenever you import Data from Atoll
into DWC-data, merge from DWC-data into DTE-
data, or copy DTE-data to DWC-data,
simultaneously the corresponding action will
happen for the fixed network data. We call the
“actual” fixed network data FPT-data (corresponding
to DTE-data), and its working copy as FWC-data. DWC
and FWC Data (or DTE and FPT Data) are strongly tied together.
3.1.2 The Data Engine and its working copy

In the previous section, we have created the DTE-data
from the DWC-data by merging the working copy into the
data engine. Of course, there is also reverse way of
creating DWC-data as a 1-1 copy from DTE-data. To do so, right click on the DTE entry in the “Data
Browser” tab and choose “Arbeitskopie von diesem Data-Engine-Stand erzeugen”. This will create a 1-1
copy of the DTE-data as DWC-data,which are meant to be our working copy and keep our DTE-data safe.
Note that the old DWC-data will be deleted.
Creating a working copy is always possible (as long
as the DTE-data are in a “rest state”, i.e. the status
is “OK” or “ERROR”), even when the DTE data are of
consistency “INVALID” or “UNCHECKED”. When the
DTE-data are copied, the DTE entry gets a time-
Guide.docx

stamp at the colum “LAST_COPIED”. Note that if you do any changes to the DTE-data now, like
manually changing a parameter, the colum “LAST_MODIFIED” of the DTE-data gets a timestamp too.
The reverse process of merging DWC-data into DTE-data is only possible, when
 The DWC-data are consistent
 The timestamp “LAST_MODIFIED” of DTE-data is older than the timestamp “LAST_COPIED” of DTE-
data.
In other words, whenever you make any modification to the DTE-data AFTER you have created a
working copy, it is no longer possible to merge the DWC-data into the DTE-data, and you have to
create a new working copy. For that reason, the standard option for the DataEngine import (which goes
into DWC-data) is to create a new working copy first.
3.1.3 DataBrowser
The Data Browser is the component of CPCM to watch and manually edit data. It appears as a sub tab of
the Data tab for many types of Data, like ATOLL data, XAKTA data, Data Engine data, Workspace data and
so on. We explain the Data Browser for the example of the Data Enginge data. Note that though most of
the Data Browsers are very similiar, they might differ slightly in available features, e.g. depending if data
can be edited or not. Usually the Data Browser is opened by double clicking on an entry in the Data tab.
3.1.3.1 Basic editing and filtering

Basically, the Data Browser has two windows. The left window shows the objects (tables) belonging to the
selected entry from the Data tab. After selecting an object (by single click) from the left window, the right
window shows the columns and data of this object, i.e. the contents of the corresponding table. The relative
size of the two windows can be adjusted by moving the middle border with the mouse. From the header of
the left window, you can exactly determine which data set you are browsing through. The columns in the
right window have white
background if the values can
be edited, and a grey
background otherwise. In order to manually edit a value, just double click on it and enter
the new value.
You can edit several values before
finally submitting your changes by
clicking on the disk symbol. Values editing values
that you have changed get a yellow
background. If you want to undo your
changes, click on the reload button.
editable = white, non-editable=grey You will be asked if you want to save
before, in this case click “Nicht save/refresh
speichern” for getting the (refreshed) old data.

Guide.docx

The data can be filtered by entering the filter condition into the textfields above
the columns. Once you start typing, a list of possible completions appear, that you
can select by cursor keys. You can also use SQL-Wildcards such as “%” or “_”.
You can combine filters of several columns. To remove all filters click on
the swipe symbol.
Remove all filters
With the buttons you can build more complex filters using
own SQL statements. This so called ‘Parameter filter’ is explained in section
3.1.3.6.
filtering
Sometimes you want to change the value of a parameter for all rows
which are currently filtered out. To do so, click on . Then a dialog

will open where you can choose a parameter and a new value for this
parameter. Note that all visible rows will be affected immediately
after the commit.
3.1.3.2 Sorting
The data can be sorted by contents of a column by clicking on a

column name. Clicking on the column again, reverses the order.
You can also sort by several columns, in each column up or down
first, and nulls first or last. To do this, open the sort parameter
dialog by clicking on . From the dialog, which should be mainly

self explaining, you can then select a bunch of columns and a sort
order for each column.
Sorting by several columns at once
3.1.3.3 Searching for parameters

Sometimes you might know the name of a paramter, but not in
which object it appears. To find out, click on . Then the

“Parameter suchen” window opens, which is another data viewer.
Basically, it shows all tables (objects) and parameters (columns).
If you enter the name of a parameter in the text field above
COLUMN_NAME, it shows the list of all tables which have this
column. In the example left, we see that only the objects ADCE and
ADJW have the parameter TARGET_CELLNAME.

Guide.docx

3.1.3.4 Hiding columns
Sometimes you are only interested in a few parameters, and when
an object has a large bunch of parameters you might want to hide
the others. For this, you can click on , and choose the
parameters you want to see. Then in the Data View, all other
parameters will be hidden. Note that
for technical reasons, the number of
visible columns is restricted to 200,
so when an object has more
parameters, some of them will
only two parameters visible here
always be hidden.
3.1.3.5 Hierachical Filter (NE-filter)

With the hierarchical filter, you can use the
filters you have set up for one object to filter
another object. A classical example is that
for a cell object, you have filtered out a
bunch of cells, and you want to see all
neighbour objects for this cell. In the
example on the left, we have filtered out
exactly one cell for the BTS object. Now tick
the check box in the “NE” Column in the left
side of the data browser (which we marked
yellow here). Now CPCM will “remember” the currently filtered out lines. If we now select any other object,
CPCM will try to find a relation between the two objects (using common keys, sometimes over several
objects in between) and filter the lines with respect to the filter where “NE” is ticked.
Here we have selected ADJL, and it only shows
objects with the same CELLNAME as which are
filtered out in BTS, where “NE” is ticked on. Note
that in case CPCM finds no relation between
the two objects, no filter is applied, and just
the full content of the selected table is shown.

Guide.docx

3.1.3.6 Parameter Filter
If you know a bit of SQL, you can use the Parameter Filter to build more complex filter conditions. Basically
what you see in the Data Viewer is the result of a SELECT statement, and the
parameter filter allows you to write your own WHERE clause. Note that for each
object (table) the parameter filter will be stored separetely. To open its window,
either tick the “P”-column checkbox, or click the button in the toolbar of the
Data Viewer. Then the editor window of the parameter filter will open, where you can type in any valid
SQL-where-clause. Two combo-boxes, where you can create simple conditions for the parameters and
buttons for AND and OR support you.
3.1.4 CSV-/Excel Export

The current content of a data browser view can be exported to an Excel or CSV file. Note that “current
content” means that both filters and hidden columns are respected in this export, as well as the sort
order. So it is a “what you see is what you get” export. To open the export dialog, click on in the
current data broser view you want to export.
The main options of the

dialog are the type of the
export file (CSV or EXCEL)
and the path to an output
file. There are also type
dependent options:
- For CSV, you can
choose whether or not to
export the header, and
the delimiters for columns
(comma, semicolon,...)
and strings (apostroph,
quotation marks,...).
- For Excel, you can
choose whether a column
is used for partitioning into
several sheets or not. If
partitioning is used, for
each value occuring in this
column, an own sheet is
created, and the contents
of the data browser are
distributed to these sheets
with respect to the value of this column.

Guide.docx

3.1.5 Rule Editor
Most of the Data tabs have a Rule Editor sub tab (Screenshot below). The Rule Editor allows you to see
details of the checks that are performed during a consistency check, and add/edit own checks you want to
be executed. Note that for each kind of data sets (ATOLL data, data engine data, workspace data,...) own
lists of checks can be defined, and also for each software version, own lists apply. The user can only edit
those checks that start with “user_......”. However, note that the user defined
checks will then apply for every user of CPCM, not just you, so there is just one user_.... file for all
CPCM users per region! Therefore, if you want to create an own rule to be checked, for example for the
data engine and software release RG30, most likely you are not the first user, and an entry of the form
“RG30/user_consistency_(regionname)_dte” already exists. Then you can select it in order to add your rule
to it. Otherwise, you can create the user file by clicking on the first „+“ symbol. Now select this file, and
click on the second “+” symbol to create a new rule in it. In the right part of the window, you can enter
the name of the test case, the SQL to be executed, if the check shall be blocking or just warning, and if the
check is active or not. Note that the context menu appearing when clicking on the rules in the left window
offers options like copying or deleting rules.
We now describe the syntax for the SQL command in the right window. The idea is to write an SQL select
statemtent, that only will have an output if the check fails, and the output gives details for the reason of
the failure. Therefore, the select statement should produce three columns,
OBJECT, DISTNAME, DESCRIPTION.
For example, we choose
select 'This comes in object column' as object,

'This is a good description' as description,
'you should compute the distname here' as distname from dual
for our rule. IMPORTANT: The statement MUST NOT be ended with semicolon ‘;’!.
Also do not forget to click on the disk symbol for save. If we now right click on a Data Engine entry and
start the consistency check, this sql command will be performed, and always produce a line, hence the
check fails. In order to watch the results of all consistency checks, right click on your Data Engine entry
and choose “Log ansehen”. Then the error log will open,
and you can see the output of our sql statement.

Guide.docx

3.1.6 DataEngine-Export into Workspace
Once you have finalized your work on the Data Engine and it is in a consistent
state, it can be exported into the workspace. This can be done by clicking on
the blue arrow between the Data Engine and Workspace pot. In the dialog
window that opens, you can edit the “Datenrekord” to identify your export
easier. Initially, it is a timestamp and your username. After the export, the data
in the workspace will basically be a 1-1 copy of
those Data Engine data which do not carry the
deleted flag. The deleted flag is a parameter
that exists in each
object and can take
values 0 (not
deleted) or 1 A deleted cell
(deleted). A row
carrying the deleted flag 1 is as good as non-existent, with the advantage that it can be easily “revived”
by CPCM setting its deleted flag back to 0 (which is of course faster than inserting the full row again).
Another difference between Data Engine and Workspace is that while in a region, there is just one Data
Engine data set for a software version, you can have arbitrary many data sets in the workspace. Therefore,
to identify a workspace data set, you should either memorize the Datenrekord, or the tableprefix (which is
unique).
Right clicking on a workspace data set, the context menu offers options to delete or duplicate the selected
data set.
3.1.7 NWP-Editor
The “Network Wide Parameters” (NWPs) are parameters whose values are taken from a list called NWP
templates, and these NWP templates (usually) exist on the level of BSC/RNC, SITE and CELL. There is
always a ‘default’ template, but the user can create own templates.
To edit NWP-Templates, open the sub tab “NWP Template” of the workspace tab.
You will see a hierarchical view, with levels the CPM regions, equipments,
software versions, releases, layers, template set names, objects and instances.
By right clicking on a template set name, the context menu offers options to
delete or duplicate the contents of this template set. Similarly for NWP objects,
you can copy or delete instances from the context menu.

Guide.docx

If you select “Delta berechnen” from the context menu,
a dialog opens where you can select two template sets
of the same layer to compare their contents. The result
of the comparison is then shown in the “Nwp Delta” sub
tab.
The values of parameters in a template set can

directly be edited by clicking on the value. To
commit your changes, click the disk symbol.
Note that values from the default template set

can not be edited.
It is important to know that all changes made on

template sets in the “Nwp Template” Editor are
stored in the CPM region, and not directly linked to
a data set in a workspace. In fact, every data set
in the workspace has its own table “NWP_TEMPLATES”, where its current selection of NWPs is stored. This
table is not automatically updated when changes in the Nwp Template Editor are done!
In order to apply the changes made in the Nwp Template editor to a given set of workspace data, you have
to right click on the data set and select “Merge mit NWPs” – see also the next section.
3.1.8 Export2CCM
As there are many workspace data sets, before an export to

CCM can be performed, one of the data sets has to be marked
as the one to be exported. We call this “activation” of a plan,
and to do so right click on the data set you want to export and choose “Plan
aktivieren (local)”. Then this activated data set can also be selected by clicking
on the corresponding pot in “Workspace lokal”. Note that though in the GUI
there are own pots for “Workspace lokal”, there are no own data sets,
i.e. all the data sets that are in in the local
workspace are in the workspace, and can
also be selected from there. The only
Guide.docx

difference ist that the activated plans have value “YES” in the trunk column to distinguish them from the
non-activated plans. Note also that data in the SCR GUI are taken from the active plan, see section
3.2.1.
Before you export to CCM you must merge with NWPs. This also should always be done, when
you have made any changes with the NWP Editor in between.
To merge with NWPs, right click on the plan and choose “Merge
mit NWPs”. This will fill the table “NWP_TEMPLATES” of the
selected plan with the NWP data.
NWP_TEMPLATES after merge with NWPs
As only a consistent plan data set can be exported to CCM, right click on
it and choose Konsistenzcheck. Then the arrow between Workspace
Lokal/Global should be clickable. In the dialog window, you can then start
the export.
Export to CCM (Workspace Global)
Note that for the export, also the FPT data are used. The export to CCM will transfrom the data from
the plan format in the local workspace to the NBI (or wirk) format in the global workspace.
For further use of the data of workspace global in CCM (in particular for the Plan Import into CCM, see
4.1.1), the workspace global data set has to be activated. To do so, it has to be consistent, so first right
click on it and start the consistency check (“Konsistenzcheck”). After a successful check, activate the
workspace global data by right clicking on its entry in the Data-
subtab of the workspace-tab, and click on “Plan aktivieren
(global)”. Then the entry becomes green, and the ACTIVE
column of the entry has value “YES”.

Guide.docx

3.2 Optimizing
For optimizing individual parameters or adding and deleting neighbor relations you can use the SCR view.
It is divided into tabs for
ScrNeighbour,
ScrParameter, and
Show_SCR. In the tab
ScrNeighbour you can
add or delete neighbor
cells of specific cells. The
ScrParameter tab is used
to modify specific cell parameters. To display all planned and executed modifications you can use the
Show_SCR tab.
3.2.1 Create SCRs

All SCRs (Software Change Request) are realized in two steps. The first step is to define the changes which
should be performed on a data set. All changes are stored in a separate table which can be seen in the tab
Show_SCR. The second step is to apply all or parts of the requests to individual data sets.
In this chapter we only define and store the change requests.
3.2.1.1 Neighbour GUI / Excel-Import

The Neighbour GUI shows the existing and planned neighbours of specific cells.
In the tab ScrNeighbour you have to select at first a Region Source and a Source Tech for which you want
to add or delete a neighbour cell. In window (1) all cells are displayed which exists in the Local workspace
as active data set. Now you have to select a specific cell in window (1) and the Target Tech for the neighbor
relations you are interested. Now you can see in window (2) some informations of existing neighbor cells
of the selected cell in window (1). Additional you can see in window (3) all planned and executed operations
for the selected cell.
To add a new neighbor cell you can type its cellname in the Suche Target field. You can also type a blank
or the first few characters of the neighbor cell to get a list of possible cellnames. With the einfügen button

Guide.docx

you can save the planned neighbor relations. Automatisch beidseitig einfügen means that there are two
entries stored. One from source cell to target cell and one for target cell to source cell.
To delete a neighbor relation you have to select a cellname in window (2) and press the löschen button.
The checkbox automatisch löschen means that the neighbor relation is saved to be deleted in both
directions, if it is possible.
You can also import a Excel file where your planned neighbor relations are stored using the import button.
3.2.1.2 Parameter GUI / Excel-Import

In the Parameter GUI you can modify some parameters of specific cells. The parameters are divided into
four different types. The “Features and Flags” type contains special parameters like BCC, LNS, LAC, MHA,
SPEED_ENV, UMTS_LAYER and so on while “Cell Parameter” contains modifiable cell parameters of certains
objects. The type “NBR Parameter” contains modifiable parameters concerning neighbor relations based on
a cell to cell relation. The “TRX Parameter” type is only for 2G Equipment and is used to modify parameters
concerning to cells in combination with trx_number.
You first have to select the Region, the Equipment and one of the tabs Features and Flags, Cell Parameter,
NBR Parameter or TRX Parameter to see all cells or neighbor relations of the active data set in the local
workspace in the window verfügbare Zellen. You can use the combobox Prefix or the text field Filter to filter
the cells in the list of verfügbare Zellen. With the green arrow buttons you move selected cells from
verfügbare Zellen to Gewählte Zellen and vice versa to use the cells in Gewählte Zellen for modification.
Depending on the choosen type of parameter you have a slightly different appearance of the list of cells
and combo boxes.
 Features and Flags

Guide.docx

On the left side you can see the cellname.
On the right side you have a combo box for the Parameter. Here you can choose the special
parameter which should be modified.
Wert is an editable combo box where you can either enter the new value or choose one of the
predefined values.
The aktueller Wert displays the actual value before the modification is applied.
If available, the Range shows the specified range for the parameter.
 Cell Parameter
On the left side you can see the cellname.

On the right side you have a combo box Type for the Object you decide to modify.
In the combo box Parameter you can choose the parameter which should be modified.
Wert is a text field where you can enter the new value.
 NBR Parameter
On the left side you can see a cellname and the corresponding target cellname for a neighbor
relationship.
On the right side you have a combo box Type for the Object you decide to modify.
 TRX Parameter (only 2G)
On the left side you can see a cellname and the corresponding trx number.
Guide.docx

After you have inserted a new value in Wert you can press the Commit button to save the change request.
With the button Generiere XLS-Template you can generate an Excel-File as template for modifications using
Excel. The modified Excel-File can then be imported using the XLS-Import button.
3.2.2 Apply WS/RDE

In this chapter we apply all or parts of previously defined change requests to a specific data set.
To apply the change requests you have to
select either an active data set in the local
workspace or a DWC-data set. With a right
mouse click on the data set you get a
context menu where you can choose the
menu entry SCR anwenden. This will open
a dialog where you have to specify the time period which change requests should be applied. The time
period is related to the IMPORT_DATE in
the Show_SCR tab. All entries in the
specified time period are executed. With
the check box Zurücksetzen you can decide
whether already applied modifications are
applied again. By pressing the button SCRs
anwenden the change request is executed
while pressing the Abbrechen button cancel
the action. If the action is finished you will
be informed with a status window whether the action was successful or not.
If the action fails you have to open the Show_SCRs tab and press the refresh button. In the column
TOC_ARCHIV_STATUS or DATAENGINE_STATUS you can read the error message.
3.2.3 SCR Overview

In the tab Show_SCR you have an overview over the planned and already executed change requests.
The most relevant columns in the Show_SCR tab are:
 CELLNAME
Here is the cellname listed for which the modification is intended for.
 NEIGH_NAME (only for ADD or DELETE)
Here is the target cellname listed for which the modification is intended for.
 OPERATION
Possible operations are ADD, MODIFY or DELETE.
 PARAMETER (only for MODIFY)
The parameter for which the modification is intended for.
 BEFORE/AFTER (only for MODIFY)
The value before and after the modification.
 IMPORT_DATE
The timestamp where the SCR was created.
 OK_xxx
1 means the SCR was successful applied.
0 means the SCR was NOT successful applied.
 xxx_DATE
The timestamp where the SCR was applied.
 xxx_STATUS
OK, when the SCR was successful applied.
ERROR or Error message, when the SCR was NOT successful applied.
 EQUIPMENT
The equipment for which the SCR was applied.

Guide.docx

 REGION
The region for which the SCR was intended.
The first thing you have to do in this dialog is to press the reload button to ensure the table is up-to-date
because it has no automatic refresh.
If you want to verify your created SCRs you see in CELLNAME the cellname for which the SCR is intended.
When a neighbor relation was created the OPERATION column contains ADD. When a neighbor relation was
deleted the OPERATION column contains DELETE. In both cases you can see the target cellname in
NEIGH_NAME. The NEIGH_NAME is also filled with the target cellname when you created a parameter
modification of type NBR Parameter while all other parameter modification leaves the NEIGH_NAME empty.
The OPERATION column contains in case of parameter modifications MODIFY.
To check whether the SCR was successfully applied or not you have to look at the OK_xxx and xxx_STATUS
column. In the OK_xxx column and xxx_STATUS you can see whether the SCR of the corresponding data
set is successfully applied or not and in the xxx_DATE you can see when is was applied.
3.2.4 Trace Back

All changes you have made on a data set in the local workspace can be traced back to the DTE-data set.
Be aware that in this case not only
SCR modifications but also the
changes you made in the data set
itself are merged to the DTE-data set.
You can invoke the merge using the
context menu by a right mouse click
on the data set you want to trace
back. After pressing the anwenden button the merge is executed while pressing the nicht anwenden button
cancel the action.
3.3 Data Verification
3.3.1 NET-Import
To import NET data from CCM to CPM either click on the corresponding arrow between the CCM computer
icon and the NetData pot, or right click in the Data sub tab of the Net Data tab and choose “Import”. In
the dialog window, you can then select the appropriate data, and start the import. The Net Data are in
the same (NBI-) format as data in workspace global.
Note that before you can import from CCM to CPM, you must have startet a live import in CCM,
see the next chapter.

Guide.docx

3.3.2 Delta
It is possible to compare two data sets that are in the same format, i.e. one can compare two entries in
workspace (local), or two entries from workspace global/NET data. To start a delta computation, right click
on an entry in the Data sub tab of workspace or NET data. Then the delta check dialog
will open, where you can select two data sets you want to compare. Note that the dialog only allows to
select combinations that are comparable, so for example a change of the workspace from local
to global for the “Check data set” will automatically adapt the selection of the “Vergleich data
set”. After you have started the computation, you can watch the result of the comparison by double clicking
on the corresponding entry in the “Delta Table” sub tab of the “Delta Data” tab.
The results of the comparison are then displayed in the “Delta Browser” tab in a tree view.
Each object where a delta is found appears as a node. As possible sub nodes, it has MODIFY, CREATE and
DELETE, depending on if a parameter was modified or a whole row has been added or deleted respectively.

Guide.docx

4 CCM
The Common Configuration Manager (CCM) is used to configure the live system with changes made in the
planning data. To do so you first need to import your planning data (Plan import) and the current live data
(Live import). After the imports are finished you can calculate the so called Delta of the two data sets,
which is a record about the differences in the data. By exporting a Delta, the changes contained in it are
converted to an XML file which can then be imported into the live system.
All of these steps are performed per Network Management System

(NMS). By default all available NMS are used.
This can be changed by selecting CCM-NMS-Auswahl in
Einstellungen.
In the dialog window that opens an overview of all available NMS
is shown, as well as some additional information. By checking or
unchecking the combo box next to the NMS you can control which
ones are used. Unchecked NMS will be ignored in all upcoming
actions. If no valid NMS is selected when starting an import or
delta, an error message is displayed.
To open the CCM perspective you need to select one of the tools from the
CCM drop down list. These tools are organized according to their technology
2G, 3G or 4G. The different vendors can be identified by the prefix of the
tool name “HCM” for Huawei, “NCM” for Nokia and “SCM” for Siemens.
4.1 Import
4.1.1 Plan import

Having sufficient privileges for importing in CCM you can see an
active “Plan Import” button in the toolbar. Clicking the button starts
the import depending on the current state of the planning data on
CPM side. The import will be performed for the selected NMS
and the technology (2G/3G/4G) is determined by the
currently selected CCM tool. So the Planimport for a 2G tool
will only import 2G planning data. Precondition is a
consistent and activated set of planning data in the global workspace, which you can check in the section
“Stand Globaldaten”.

Guide.docx

If there are no data changes on CPM side compared to the
previous plan import the user will be asked via a dialog box
to start the plan import anyhow. You can see the log of this
operation in the "Import Log" view, at the bottom of the
window. After the operation ended successfully the data is
in the same format as the live data.
In the Statusinformation section you can see the status of the last successful plan import for each NMS
relevant for the selected tool. Additionally there is an overview of the number of network elements in the
data to check if new elements were introduced or deleted.
There are two sets of planning data on the

server, one active and one inactive. The latter
can not be seen from the GUI as it is
irrelevant to the user. During the import the
inactive data set is overwritten and if the
import succeeds it is set as the active one.
But if an error occurs the previously active data set will remain active to ensure consistent data is used in
all upcoming tasks.
After successfully finishing a Planimport the new set of data is available to all tools with the same technology
and all users.
4.1.2 Live import

The user interface of Wirkimport works similar to the one of Planimport. But the underlying mechanics are
quite different as the live data is fetched from an external system and read into the database. The
Wirkimport depends on the data active in the global workspace just
as the Planimport. The technology is determined by the currently
selected CCM tool.
When running a Wirkimport information about the ongoing process can be seen in the “Import Log” at the
bottom of the window. After it is finished the imported data is available for all tools and users.

Guide.docx

4.2 Delta
Using the delta tool the differences between live data and planning data can be calculated, inspected and
exported.
4.2.1 Deltabildung
With a CCM perspective open, the processing of a delta can be started by pressing the Delta button.
In the Statusinformation section you can see the status of the last successful delta for each NMS and
software version relevant for the selected tool.
After the Delta button has been pressed the delta is running. The progress of the delta processing is shown
in the view Delta Log.
The green line indicates that the delta processing has been successful.
4.2.1.1 Delta Tree and Detail Table

The delta is visualized in the delta tree view (Deltabaum) shown below on the left side. At the beginning
the delta tree shows a few nodes which can be expanded by clicking on the small triangles.
The bold words indicate that the corresponding objects have a delta. If you click on such an object the
details are shown in the detail table (Detailtabelle), the view shown on the right side. Here you can compare
old value and new Valus of the parameters which belong to the delta object.

Guide.docx

4.2.1.2 Object Delta Tree and Parameter Delta Tree
Some tools (e.g. all Param tools) have two diferent delta trees. One is called Object Delta Tree (Objekt
Deltabaum) which is the same as the delta tree mentioned above.
The parameter delta tree (Parameter Deltabaum) shows update delta only. The tree hierarchy is different
to the Object Delta Tree. The second level of the tree contain the parameter for which a delta exists. So
you easily can find all objects for which a certain parameter must be modified. Also note that parameters
which are displayed in orange color are service affecting.
4.2.1.3 Planexport and Selective Delta

Some tools are able to build a delta for a given quantity of controller or sites. These tools are identified by
the existence of the button Planexport .
After pressing this button a dialog opens in which you can define for which controller or sites the delta
should be performed.

Guide.docx

By pressing OK a new delta process is
triggered.
The result is shown in a special node

inside the delta tree view.

Guide.docx

4.2.1.4 Statistic
To see some statistical information about the delta data you can click the Statistic (Statistik) button.
4.2.1.5 Searching
To narrow the delta tree for entries which contain a given text, choose Search (Suche).

Guide.docx

The result is shown inside the delta tree view
in green letters. Objects which do not match
the search expression are not shown.
To cancel the search press the delta button.
4.2.1.6 Blacklist
To prevent some objects to be part of an export press the butto Blacklist. In the opening dialog you can
define controller and site the objects.
Note: Blacklist entries must be active (Aktiv) to be valid.

Guide.docx

The blacklisted elements are shown in a special node CCM
BLACKLIST in the delta tree. Blacklisted elements are not
shown in the other nodes of the delta tree.
4.2.2 Export
The export generates one or more files which can be used as input for the network management system.
To create an export first check the delta object

to be exportes in the delta tree.
Then press the export button.
The result is shown in a new window which has the name Dateiexport.

Guide.docx

If the export results consist of more than one file, each file is shown in separate tabs. You can save the
result file for further handling.
5 Integration Wizard
The Integration Wizard (IWZ) is the fast track to integrate new Sites, Cells and Trxs into the network. In
contrast to CPM, it only has one raw data pot for each type of Radio, Transport and Equipment data and
Technology, and one data pot for Net Data, but no other “intermediate”-data pots between raw data and
live data. The delta between raw data and net data is monitored in the IWZ-Monitor, which can also be
considered as the control room of the Integration Wizard. For each site it shows whether there is no
difference between raw data and network data, or in the other case which kind of operation (create
site/cell(s)/trx(s)) is needed to bring the live data in accordance with the planning data. When the
planning data has passed the consistency checks, the necessary export file to perform this operation can
be created from the IWZ-Monitor. When the IWZ-Monitor is refreshed, it checks if prepared operations
from the previous state have been successfully integrated into the network (i.e., there is no longer a
delta between planning data and net data). These sites and operations are then archived in a history
view, together with the relevant export files.

Guide.docx

The following screen shot shows the Integration Wizard-Perspective of CPCM.
First note thate there are tabs for each IWZ-Region (where there is one IWZ-Region per planning region
and vendor), where above we have the two regions TESTBED_HUAWEI and TESTBED_NOKIA. Make sure
you have the right region selected before you proceed. Then there are three main windows:
1. This window contains the icons for the pots of the three raw data pots RPT (radio data), FIT
(transport data), EQP (equipment data) and the pots for live data NET, for each technology
2G,3G,4G. The pots can have the colours grey (no data/operation active), yellow (unchecked
data), red (inconsistent/error data) or green (consistent data).
2. This window has tabs for each of the four pots from before, each coming with two tabs “Data”
(overview of the data sets in this pot) and “Data Browser” to view the objects of a data set.
Another tab is the Rule Editor, to manage existing consistency checks and create user-defined
consistency checks.
3. This window is the heart of the Integration Wizard, containing the four tabs related to the IWZ-
Monitor. These are the Monitor tab itself, containing information for each site, the monitor status
tab for an overview of the monitor data for each region and technology, the History tab which
contains the former monitor entries of successfully integrated operations, and a Konsistenz Log
tab, showing the results of consistency checks.
5.1 Import
The first step is to import the relevant planning raw data, i.e. RPT, FIT and EQP data.
5.1.1 Atoll
To import radio plan data, right click somwhere in the RPT tab, in its data sub
tab and select “RPT Import ...”. Then a new window will open, where you can
Guide.docx

select the region and technology for which to import
data. Also you can either import all sites, or just a subset
of sites defined by a comma separated list, by
deselecting “Importiere alle Sites” and filling out the text
field below (e.g. by copy and paste) with a CSV. After the
import, the corresponding RPT pot gets yellow colour
(indicating unchecked data) and a line for the imported

data set appears in the data tab. Double clicking on this
line switches to the Data Browser tab, where you can
view and edit the imported data.
When the imported data is considered to be

ready for further steps, the data set must be
approved, otherwise it will not be used in
the next monitor refresh (instead, the copy
of the last approved set at the last monitor
refresh is used. For more details, see the
section on the monitor refresh 5.4.1). Only a
consistent data set can be approved, so first
choose “Konsistenzcheck” from the
context menu. After a successfull check
(the pot gets green and the CONSISTENT
column of the entry gets the current
date-time as value, choose “Freigabe ...” from the context

menu. A window opens where a comment can be entered.
This comment,
together with the
name of the approver and the current date-time are stored in the
overview table.
5.1.2 X:Akta
To import fixed network data from X:Akta, select the FIT
tab, right click into its Data sub-tab and select “Festnetz
interims Daten import ...” from the context menu. Then
similar as for RPT data, a dialog opens where you can
select region and nettype, and either import all data or a
subset of sites determined by a CSV list. Also consistency
check and approval work in exactly the same way as for
RPT data.

Guide.docx

5.1.3 Equipment
To import Equipment Data, select the EQP Tab, right click somewhere in
the Data Tab and select “EQP Import ...”. Apart from this, Equipment
import works like RPT import. Currently, only an empty set is imported.
However, for the monitor refresh to work, this empty set has to be
approved also.
5.2 Data Browser

The Data Browser of the Integration Wizard works in the same way as for CPM. See Section 3.1.3 for the
Details.
5.3 Rule Editor

Basically the rule editor for the Integration Wizard works the same way as the one for CPM, see 3.1.5
For each technology, there are four types of consistency checks, where three come from one for each of
the raw data pots RPT,FIT,EQP (which can be started individually), and one is a global one performed
during monitor refresh, see 5.4.1. In the rule editor, you can both view the preinstalled consistency
checks for each type, and add user defined ones. Note that only one user defined check per type and
region can exist, which will always be performed after the preinstalled checks, independently which user
starts the check/monitor refresh. So here user defined means (various) users can edit these checks, but
then they will apply to any user of this region!
Each check (whether user defined or preinstalled) consists of a set of SQL statements, which are meant
to produce a row for each failure of a check, and produce no row when the check passes.
Also each check can have one of the severities “Warnung” or “Blockieren”, which affect how/if the data
set can be used for further actions (or has to be be fixed before), and it can be active (check will be
performed) or not active (check will not be performed). In the left window of the Rule Editor, these flags
are displayed through a orange/red flag for the severity and a checkmark/cross for the activity status.
To create a new user defined check, click on the first green plus in the top right of the
left window. In the following dialog window, you can choose region, technology and the type
(RPT,FIT,EQP,GLOBAL) of the user defined consistency checks. Now to define a SQL statement to perform
inside this test, select it and click on the second plus. In the right hand side of the window, you can
define a SQL statement, where the first column should yield the SITE_BASEKEY of the failing site, and
the second column a description. Now when executed during a consistency check, these columns will
appear in the consistency log, which can be opened by right clicking on the data set entry and selecting
“Log ansehen” for raw data checks, or in the Konsistenz Log tab of the Monitor.
Guide.docx

5.3.1 Raw Data Checks
Raw data checks are performed for the pots RPT, FIT, and EQP. The filenames are of the following form:
pre installed checks user defined checks
RPT consistency_intwiz_rpt_[TECHNOLOGY].xml user_consistency_intwiz_[REGION][TECHNOLOGY]_rpt.xml
FIT consistency_intwiz_[EQUIPMENT]_fit.xml user_consistency_intwiz_[REGION][TECHNOLOGY]_fit.xml

EQP consistency_intqiz_eqp_[TECHNOLOGY].xml user_consistency_intwiz_[REGION][TECHNOLOGY]_eqp.xml
Note that if a check with severity BLOCKING fails, it means that this raw data pot can not be approved
(and hence not used for a monitor refresh, see 5.4.1). If a check fails with WARNING, it does not block
the approval of the pot, but this check will then also appear in the “Konsistenz Log” tab of the Monitor,
and in particular, once a site has at least one entry here, it will have status INVALID in the monitor, so no
usecases can be performed on it (see 5.4.1)
Note that when writing own raw data checks, make sure the sql statements go to the T-DATA
sets (and NOT to the D-Data sets), as these are the sets relevant for the check! (I.e., for the
table prefix for radio use RPT and not RPD. And for transport, use FIT and not FPD. See 5.4.1)
5.3.2 Global Checks

Global checks are performed during the monitor refresh. The filenames are of the following form:
pre installed check user defined check
GLOBAL consistency_intwiz_[EQUIPMENT].xml user_consistency_intwiz_[REGION][TECHNOLOGY].xml
Note that when writing own GLOBAL checks, make sure the sql statements go to the D-DATA
sets (and NOT to the T-Data sets), as these are the sets relevant for the monitor refresh! (I.e.,
for the table prefix for radio use RPD and not RPT. And for transport, use FPD and not FIT. See 5.4.1)
Note that for GLOBAL checks, the severity should always be WARNING.

Guide.docx

5.4 Monitor
The monitor can be seen as the heart of the Integration Wizard. It gives (after a refresh) a quick
overview of the delta between plan and wirk, by showing for each site its consistency and integration
status, and allows to create export files for each site in order to update the network.
Note that the monitor data browser has a REGION column which by default is not filtered – so the
monitor will show data of all regions. So you might want to enter the region you are working in this
column in order to filter out the regions not relevant to you.
5.4.1 Recalculate Monitor Data

To refresh the monitor, right click somewhere in the “Monitor” or
“Monitor Status” tab and select “Monitordaten neu berechnen”. In
the following dialog window, you can change the region and
technology for which the refresh shall be performed. Note that in
order for a successful refresh, the following conditions must be satisfied:
a) A successful CCM-Wirk-Import has had to
performed before, as these CCM-Wirk data will
be used for the comparison between raw
planning data and live data. The currently
active (or if not existing, e.g. in case of an
ongoing wirk import, the last active) CCM Wirk
data set is used.
b) For each of the pots FIT, RPT, EQP an
approved data set for the selected region and
technology must exist. In case this condition is
not met, you will be informed by a popup
telling which pot(s) are missing approved data.
c) The monitor itself and involved pots must be in a rest state (no other action is running).
Note that in the pots FIT, RPT, EQP there are two kinds of data sets (per Region-Technology)
1) The raw data set coming from the last raw data import. We call these T-DATA.
2) The copy of an approved T-Data set created during the monitor refresh, which we will call D-
DATA.
Note that for the condition of b) above to be met it is enough for the pot that a (successfully copied) D-
DATA set exists. If there are currently no approved T-DATA, but a D-DATA set (from a previous refresh)
exists, this D-DATA set will be used for the monitor refresh. Therefore if you want to use newly
imported/edited T-data set for a refresh, you must make sure it is approved, otherwise a
maybe outdated D-DATA set will be used in the refresh!
Now during a monitor refresh, for each pot where there exists an approved T-Data set which has a newer
aprroval date than the D-Data set (or there is no D-Data set yet), the pot\type T-Data set D-Data set
old D-Data set will be replaced by the current T-Data set. When the prefix prefix
two approval dates are equal (or the T-Data set is not RPT-Data RPT RPD
approved), the existing D-Data set is preserved instead. FIT-Data FIT FPD
EQP-Data EQP EPD
In the Data-tabs, T-Data and D-Data sets can be distinguished by
their tableprefixes, see the following table. Note that the D-Data sets represent a “frozen state”, so they
cannot be edited by the user.
After the RPT/FIT/EQP D-data pots where (if necessary) actualized, NET Data will be imported from CCM.
Recall there are up to two CCM-Data sets per NMS, where at most one is active. For the import, either
the active CCM-Data set is used, or when there is no active set (e.g. because currently a CCM-Import is
running), the last active set is used. If there is neither an active nor a last active CCM-data set, the
monitor refresh will fail.
Once the monitor refresh is done, we see the following data:

Guide.docx

In the “Monitor Status”-tab, which represents the overview table for all monitor data, there is an entry
for the monitor data per region and technology.
It all also contains information of the involved RPT,FIT,EQP pots, e.g. their approval date and comment,
and the current status of the monitor for this region/technology overall.
In the “Konsistenz Log”-tab you get information on the results of the consistency checks.
Note that these consistency check results come from four sources, determined by the column
SOURCEPOT with values RADIO,TRANSMISSION,EQUIPMENT,GLOBAL.
- The entries for RADIO,TRANSMISSION,EQUIPMENT are the results of the consistency checks
on the corresponding pots. These consistency check are not performed during monitor
refresh, just its results are copied from the consistency logs of the pots into the monitor
consistency log.
- The entries for GLOBAL come from the global consistency checks, as defined in the xml files
“consistency_intwiz_[EQUIPMENT].xml” and
“user_consistency_intwiz_[REGION][TECHNOLOGY].xml” (for the user defined checks). These
are actually performed during the monitor refresh.
The most important tab is of course the “Monitor”-tab itself.
It contains for each site (per region/technology) the detected pre-delta between plan and wirk data. Of
relevancy here are the columns USECASE, USECASE_INFO, CONSISTENT and INTEGRATION_STATUS:
- The CONSISTENT column has values OK or INVALID. When any of the consistency checks
failed for the relevant site (i.e. there will be an entry in the “Konsistenz Log” tab with the
given SITE_BASEKEY), the site is INVALID and the INTEGRATION_STATUS will be
NO_OPERATION
- When the site passed all consistency checks, its CONSISTENT entry is OK, and the
INTEGRATION_STATUS is either NO_OPERATION (when there is no delta between plan and
wirk) or OPEN, when a delta between plan and wirk is detected.
- In this case, the USECASE and USECASE_INFO columns contain the information on the kind
of detected delta, where USECASE can take the values CREATE_SITE, CREATE_CELL,
CREATE_TRX. Then USECASE_INFO lists the affected elements, e.g. in case of CREATE_CELL
a list of the cellnames to be created.
Note that when creating an export-file for a site (see the next section), the INTEGRATION_STATUS
changes from OPEN to PREPARED. Now when the monitor is refreshed again, there will be a special
handling for sites which are prepared see 5.4.6
Also note that

- plan sites which are not invalid, but their controller is not in the wirk network, do not appear
in the monitor.
- a plan site appears as INVALID when any of the (plan-)consistency checks has failed (even
when the site exists in the wirk network and is ok there.)

Guide.docx

5.4.2 Generate Export File
When the
INTEGRATION_STATUS of a site
is OPEN, the export file to
integrate the necessary
operations in the network can
be generated by right clicking
on the relevant entries and
selecting “Export erstellen”. Note that multi select is possible,
even over different regions and technologies. In the following
window, the software version(s) and release(s) for which the
file(s) shall be generated can be chosen. Note that the
software version can only be chosen for 4G, while for 2G/3G
it is taken from the wirk controller.
Note that the export file will be stored in the database (not
directly on the filesystem). After the creation of the export
file, the INTEGRATION_STATUS changes from OPEN to
PREPARED, and the EXPORT_FILE_NAME column is filled,
showing the export file is ready. Also the
SW_VERSION/RELEASE column of the monitor will be
updated with the selected values.
See 5.4.5 for a remark on how ID’s are computed if necessary.
To download the file somewhere on the client

computer, right click on the corresponding
entry(ies) and select “Exportdateien
herunterladen”.
Then a dialog window will open, where you

can select a destination directory where the
export files shall be stored. Usually the
export files are zip files. There are three
options how to to handle the zip files after
download – they can be automatically
unpacked and deleted/not deleted, or just
downloaded without unpacking. (Non-zip files
will always just be downloaded).
The progress will be displayed in a separate window, and

the download can be cancelled. Note that cancelling will
only stop from downloading further, not yet downloaded
files, while it will still finish downloading the current file.
So some time can still pass after pressing the cancel
button, until download is stopped.
If a file to download already exists on your file system, you will be asked how to handle this file
(keep/overwrite), and possibly all
other files, so if you want to
download a larger bunch of files,
in order not to get stuck in the mid
with a dialog, it is best to make
sure the target directory is empty.
The downloaded file(s) remain also on the database, so it/they can be downloaded at any time again.

Guide.docx

5.4.3 Reset Monitor Status
There might be some reasons to undo setting a site to
INTEGRATION_STATUS prepared and deleting the
corresponding export file from the database. Also recall
that sites which are prepared will be treated
specially during monitor refresh, which might
not be wanted sometimes. To set the
INTEGRATION_STATUS from one or more
sites from PREPARED to OPEN and delete the
export files from the database, (multi-)select
the relevant sites and choose “Monitor
zurücksetzen” from the context menu.
Then a dialog opens which shows the selected
site_basekeys (sites which were selected, but
have another integration status then
prepared are filtered out) and ask to confirm
that you really want to reset the selected
monitor data (and delete the export files from
the database). Note that also the reserved
IDs for the selected sites will be deleted from
the ID-Pool.
5.4.4 Planexport
A plan export file can be created for any sites in the monitor which are consistent. It will generate export
files for the select sites as the export in 5.4.2 where for each selected site, the usecase CREATE_SITE is
assumed (even if no usecase or any other usecase is detected in fact). Contrary to the export in 5.4.2,
- the files will be directly stored on your filesystem in the selected path, not in the database
- the INTEGRATION_STATUS of the selected sites does not change
For the computation of ID’s when necessary, see 5.4.5.
To start a Planexport, right click on a site in the

monitor and select “Planexport erstellen”.
Similarly as in 5.4.2, you can select software
version/release for the selected sites, but
additionally you have to specify a directory
where the export files shall be stored.
5.4.5 About the ID Generation

Note that there are cases (currently: HUAWEI 2G/3G) where for the identification of objects, IDs are used
which must be unique inside the network, but apart from this they can be arbitrary (in the sense they do
not depend on “physical” properties of the object). So when an export file is generated, either by 5.4.2 or
5.4.4, for a new object, new ID’s have to be generated. In order to avoid that when executing this
process twice in a row after a short time, the same objects get different ID’s (recall they can be

Guide.docx

arbitrary), an ID Pool is used, where for each object, identified by its “physical keys”, an ID is stored,
with an expiration date of 24 hours. If now an export is started, the following happens:
- All objects/ID’s from the pool which are expired are deleted (in order to avoid that ID’s for no
longer relevant objects are stored forever).
- If an object that is relevant for the export is found in the pool, its expiration date is renewed
for another 24 hours, and the ID from the pool is reused.
- for relevant objects not in the pool, a new entry (with a new ID) is created, with an
expiration date of 24 hours, and this ID is used for the object.
5.4.6 History
Once a USE_CASE has been successfully implemented in the wirk network, the corresponding site will
have NO_OPERATION in the next monitor refresh. However, a history of formerly detected deltas can be
found in the “History”-tab.
More precisely, the History tab is filled from entries of the Monitor-Tab that before the refresh have
PREPARED as INTEGRATION_STATUS, and after the refresh either
-the detected USE_CASE differs (e.g. from CREATE_TRX to CREATE_CELL),
-the site becomes invalid,
-or there is no longer a delta detected (NO_OPERATION).
In each of these cases, the PREPARED entry in the monitor tab will be replaced by the new computed
entry, and will have OPEN (export file has to be computed again!)/NO_OPERATION as
INTEGRATION_STATUS, while the old entry with its export file can be found then in the History tab.
Also note in all other cases, a prepared entry together with its export file is kept in the monitor. So in
particular if the detected use case and consistency of a prepared site do not change during another
monitor refresh, the export file is preserved.
6 Glossary
ATOLL
Radio planning tool of O2/Epuls
ATOLL DATA
Often refers to the data set in CPCM, coming from Atoll
CCM
Common Configuration Management. Configuration part of CPCM.
CPCM
Common Plann & Configuration Management. The tool where this documentation is about.
CPM

Guide.docx

Common Planning Managment. Planning part of CPCM
D-DATA
Frozen states of raw data sets in the Integration Wizard. Relevant for the monitor refresh.
DATABROWSER
Component of CPCM to comfortably browse large tables, with powerful filter, sort and editing functions.
DELTA
There are two kinds of delta computation, one in CPM, one in CCM. The CPM-delta allows to compare two
CPM data sets which are in the same formar (both plan or both wirk format). The CCM-delta compares
the planning data coming from plan import, and the live net data coming from wirk import. This delta can
then be exported to the Network Managment System.
DTE
Data Engine. Pot in CPM, where data are in plan format. Data are separated from critical actions via its
working copy.
DWC
Data Engine Working Copy. Pot in CPM, where Data are in plan format. Can always be created from Data
Engine as 1-1 copy. Only when consistent, the working copy can become the new data engine.
EQUIPMENT DATA
Data pot in the Integration Wizard
FPT
Fixed Network Planning Tool (XAKTA)
FIT
Fixed Network Interims Tables
FWC
Fixed Network Interims Tables Working Copy
History
Place where formerly prepared monitor entries are stored that were either successfully integrated or are
no longer relevant.
IWZ
The Integration Wizard Component of CPCM.
Monitor
Central component of the Integration Wizard, which shows delta between plan and wirk and the
integration status of sites.
NET IMPORT
Imports the data from CCM’s wirk data tables (in wirk format) into CPM’s NET data tables (in wirk
format). These datasets then can be used to compute deltas between workspace global data (also in wirk
format).
NWP
Network Wide Parameters. For these parameters, sets of constant values (Templates) can be defined,
which can then be used in different situations.
PLAN
Plan always refers to data in the simplified model, i.e. a reduced set of objects and parameters.
Sometimes, a data set in plan format is also referred to as a plan. In CPCM, data in Data Engine (Working
Copy) and Workspace (Local) are in plan format.
PLAN IMPORT

Guide.docx

Imports the data from CPM’s workspace global (which are in wirk format, but represent the “plan” for the
network) into CCM’s plan-data tables (which are also in wirk format).
RDE
Radio Data Engine. See Data Engine.
REGION (or CPM-REGION / IWZ-REGION)

Planning in CPM is done in a regions, which are represented by tabs in the main window. The plannings in
regions are independent of each other. Only one vendor (NOKIA, HUAWEI, SIEMENS) is present in a
region.
RULEEDITOR
Sub-tab of the tabs of many data-sets. Allows to create user defined consistency checks via SQL.
SCR
Software Change Request. Also a module in CPM which allows to modify parameters and adjacencies
between cells.
T-DATA
Raw data sets in the Integration Wizard
USECASE
Usecases in CPM define how an import from ATOLL data into Data Engine Working Copy data is
performed in detail, and which information of ATOLL data is used for it.
WIRK
Refers to data which are in the actual NBI-Format of the vendor. The data of workspace global, and the
data in CCM are in wirk format.
WIRK IMPORT
Import the data from the live-network in CCM’s wirk data tables.
WORKSPACE
Pot in CPM for Workspace data, which are still in plan format
WORKSPACE GLOBAL
Pot in CPM for data in wirk format. An activated data set can be exportet through to CCM via Plan-Import.
WORKSPACE LOCAL
Pot in CPM which is the subset of activated data sets in workspace, in plan format.
XAKTA
Fixed network planning tool of O2/EPLUS.
XAKTA DATA
Often refers to the data set in CPCM coming from XAKTA.

Guide.docx

Unsere Adresse / Telefonnummer
MicroNova AG
Unterfeldring 17
85256 Vierkirchen
Telefon: 08139/9300-0
Telefax: 08139/9300-80
Ansprechpartner: (evtl.)
Vertrieb:
Technik etc.
Anlagen/Beiblätter etc.
© 2017 MicroNova AG
* Weitergabe sowie Vervielfältigung dieses Dokuments, Verwertung und Mitteilung seines Inhalts sind
verboten, soweit nicht ausdrücklich gestattet. Zuwiderhandlungen verpflichten zu Schadenersatz. Alle
Rechte für den Fall der Patent-, Gebrauchsmuster- oder Geschmacksmustereintragung vorbehalten.
Guide.docx

CPCM High Level User Guide - 3V1

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

CPCM High Level User Guide - 3V1

Enviado por

Direitos autorais:

Formatos disponíveis

CPCM

Projekt/Titel: CPCM Filename: CPCM High Level User

© 2017 MicroNova AG (* siehe letzte Seite) 1

Name Datum Version Änderungsgrund Freigabe

Projekt/Titel: CPCM Filename: CPCM High Level User

© 2017 MicroNova AG (* siehe letzte Seite) 2

Projekt/Titel: CPCM Filename: CPCM High Level User

© 2017 MicroNova AG (* siehe letzte Seite) 3

1 From Plan to Wirk via CPM-CCM or IWZ

1.1 Short Overview over the data workflow in CPM

Projekt/Titel: CPCM Filename: CPCM High Level User

© 2017 MicroNova AG (* siehe letzte Seite) 4

Projekt/Titel: CPCM Filename: CPCM High Level User

© 2017 MicroNova AG (* siehe letzte Seite) 5

The following URLs are currently in use (July 2017):

Projekt/Titel: CPCM Filename: CPCM High Level User

© 2017 MicroNova AG (* siehe letzte Seite) 6

CPCM Client main window, Data Maintenance View

Projekt/Titel: CPCM Filename: CPCM High Level User

© 2017 MicroNova AG (* siehe letzte Seite) 7

Planning Regions TESTBED_NOKIA, TESTBED_HUAWEI, TB_EPL_NOKIA, TB_EPL_SIEMENS as tabs

3.1.1.1 Atoll import

Projekt/Titel: CPCM Filename: CPCM High Level User

© 2017 MicroNova AG (* siehe letzte Seite) 8

3.1.1.2 XAKTA Import

Projekt/Titel: CPCM Filename: CPCM High Level User

© 2017 MicroNova AG (* siehe letzte Seite) 9

3.1.1.3 Importing a Use Case List (Action List)

Projekt/Titel: CPCM Filename: CPCM High Level User

© 2017 MicroNova AG (* siehe letzte Seite) 10

As reference for the definition of use cases, see MN_Spezifikation_CPCM_ZeroTOC_1v19.docx.

© 2017 MicroNova AG (* siehe letzte Seite) 11

Projekt/Titel: CPCM Filename: CPCM High Level User

© 2017 MicroNova AG (* siehe letzte Seite) 12

Fixed Network Data

3.1.2 The Data Engine and its working copy

© 2017 MicroNova AG (* siehe letzte Seite) 13

3.1.3.1 Basic editing and filtering

Projekt/Titel: CPCM Filename: CPCM High Level User

© 2017 MicroNova AG (* siehe letzte Seite) 14

which are currently filtered out. To do so, click on . Then a dialog

The data can be sorted by contents of a column by clicking on a

dialog by clicking on . From the dialog, which should be mainly

Sorting by several columns at once

3.1.3.3 Searching for parameters

which object it appears. To find out, click on . Then the

Projekt/Titel: CPCM Filename: CPCM High Level User

© 2017 MicroNova AG (* siehe letzte Seite) 15

3.1.3.5 Hierachical Filter (NE-filter)

Projekt/Titel: CPCM Filename: CPCM High Level User

© 2017 MicroNova AG (* siehe letzte Seite) 16

3.1.4 CSV-/Excel Export

The main options of the

Projekt/Titel: CPCM Filename: CPCM High Level User

© 2017 MicroNova AG (* siehe letzte Seite) 17

select 'This comes in object column' as object,

and you can see the output of our sql statement.

Projekt/Titel: CPCM Filename: CPCM High Level User

© 2017 MicroNova AG (* siehe letzte Seite) 18

Projekt/Titel: CPCM Filename: CPCM High Level User

© 2017 MicroNova AG (* siehe letzte Seite) 19

The values of parameters in a template set can