IManager M2000 CME Northbound Interface

iManager M2000-CME
Northbound Interface
Specification
Issue 03
Date 2013-11-21
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2013. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 03 (2013-11-21) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
iManager M2000-CME
Northbound Interface Specification About This Document
About This Document
Keywords
M2000, CM, northbound, XML, import, export
Abstract
This document describes the design principles and technical specifications of the M2000 CM
NBI. CM is short for configuration management and NBI is short for northbound interface. It
serves as a reference for interface control and provides guidance for users to integrate and
interconnect umbrella operations support system (OSS) tools and Huawei M2000 system.
Issue 03 (2013-11-21) Huawei Proprietary and Confidential ii

iManager M2000-CME
Northbound Interface Specification Contents
Contents
About This Document .................................................................................................................... ii

1 Introduction to M2000 CM NBI.................................................................................................. 1
2 Northbound File Interface for Data Export .............................................................................. 3
2.1 Data Export Process ......................................................................................................................................... 3
2.1.1 Overview ................................................................................................................................................. 3
2.1.2 Exporting Data Through a Scheduled Task ............................................................................................. 4
2.1.3 Exporting Data Manually ........................................................................................................................ 4
2.2 Directories for Saving Exported Files .............................................................................................................. 5
2.2.1 Directory on the M2000 Server............................................................................................................... 5
2.2.2 Directory on the M2000 Client ............................................................................................................... 5
2.3 Rules for Compressing, Splitting, and Naming Exported Files ........................................................................ 5
2.3.1 Rules for Compressing Exported Files.................................................................................................... 5
2.3.2 Rules for Splitting Exported Files ........................................................................................................... 5
2.3.3 Rules for Naming Exported Files ............................................................................................................ 6
2.4 Deletion of Expired Exported Files .................................................................................................................. 8
2.5 FTP Information for File Transfer .................................................................................................................... 8
2.6 RAN Sharing Export ........................................................................................................................................ 8
3 Northbound File Interface for Data Import ........................................................................... 10

3.1 Data Import Process ....................................................................................................................................... 10
3.1.1 Overview ............................................................................................................................................... 10
3.1.2 Importing Data ...................................................................................................................................... 11
3.1.3 Principles for Designing the M2000 CM NBI ...................................................................................... 12
3.1.4 Software Architecture and Process of M2000 CM NBI Interconnection .............................................. 16
3.2 Technical Conventions for Data Import Over the NBI ................................................................................... 18
3.2.1 Import of Incremental Data Files .......................................................................................................... 18
3.2.2 Modification of Data ............................................................................................................................. 18
3.2.3 Management of Imported Files ............................................................................................................. 18
3.3 FTP Information for File Transfer .................................................................................................................. 19
3.3.1 FTP Server Information ........................................................................................................................ 19
3.3.2 Directory for Saving Imported Files ..................................................................................................... 19
3.3.3 Directory for Saving Report Files ......................................................................................................... 19
Issue 03 (2013-11-21) Huawei Proprietary and Confidential iii

iManager M2000-CME
Northbound Interface Specification Contents
4 Format of Northbound Data Files ............................................................................................ 20

4.1 File Header ..................................................................................................................................................... 20
4.2 Subsession ...................................................................................................................................................... 21
4.2.1 Attributes of Subsession ........................................................................................................................ 21
4.2.2 NE: Container of NE Data .................................................................................................................... 21
4.2.3 Module: Grouping of Configuration Data ............................................................................................. 22
4.2.4 Moi: Actual Configuration Data............................................................................................................ 22
4.2.5 Attributes: Detailed Parameter Information .......................................................................................... 24
4.3 File Footer ...................................................................................................................................................... 24
5 Format of Report Files ................................................................................................................ 25

5.1 Import Result Summary Files ........................................................................................................................ 25
5.2 Subsession Error Report Files ........................................................................................................................ 26
6 Other Technical Specifications ................................................................................................ 27

6.1 Introduction to Common Configuration Parameter Types ............................................................................. 27
6.2 Methods for Processing Parameters of the Bit Field Type ............................................................................. 28
6.3 Methods for Processing Parameters of the List Type ..................................................................................... 28
6.4 Recommended Specifications for NE Names ................................................................................................ 31
6.5 Methods for Exporting Template Data ........................................................................................................... 32
6.6 Uniqueness Restriction for MOIs in a Subsession ......................................................................................... 33
7 Customized Options for the NBI ............................................................................................. 34

7.1 Overview ........................................................................................................................................................ 34
7.2 Customized Data Export Options ................................................................................................................... 34
7.3 Policy for Inheriting Customized Options During Upgrade ........................................................................... 36
A Acronyms and Abbreviations .................................................................................................. 37
Issue 03 (2013-11-21) Huawei Proprietary and Confidential iv

iManager M2000-CME
Northbound Interface Specification 1 Introduction to M2000 CM NBI
1 Introduction to M2000 CM NBI
The M2000 CM NBI provides the following functions based on the direction of data flow:
 Northbound data export
This function allows umbrella OSS users to retrieve the configuration data of RAN (such
as GBSS, WRAN, and eRAN) NEs managed by the M2000. Data is exchanged between
the M2000 and the OSS as Extensible Markup Language (XML) files. The format of
XML files supported by the M2000 CM NBI will be described in the following sections.
 Northbound data import
This function allows umbrella OSS users to modify the configuration data of RAN (such
as GBSS, WRAN, and eRAN) NEs managed by the M2000. Data is exchanged between
the M2000 and the OSS as XML files. The format of XML files supported by the M2000
CM NBI will be described in the following sections.
Issue 03 (2013-11-21) Huawei Proprietary and Confidential 1

iManager M2000-CME
Northbound Interface Specification 1 Introduction to M2000 CM NBI
Figure 1-1 Schematic diagram of M2000 CM NBI
OSS Server
Northbound Interface
Export Import
O&M Operator
File Interface
M2000/CME Client
cmedb
M2000 Server
Southbound Interface
GBSS/WRAN/ERAN
The preceding M2000 CM NBI functions are achieved by using the Configuration
Management Express (CME). In this document, the CM Northbound Agent can be understood
as the CME.

iManager M2000-CME
Northbound Interface Specification 2 Northbound File Interface for Data Export
2 Northbound File Interface for Data Export
2.1 Data Export Process

2.1.1 Overview
Figure 2-1 shows the process of exporting data over the NBI.
Figure 2-1 Process of exporting data over the M2000 CM NBI
OSS
Umbrella OSS users obtain
files from the M2000 server.
CM Northbound Agent
M2000 GUI exports CM data as files to a
specified directory on the
M2000 server.
M2000
CM Northbound Agent
FM PM
Export Import
File FTP Job

Server Server Scheduling
CM DB
Public Utilities
RAN
RNC/BSC eNodeB
NodeB/BTS NodeB/BTS eNodeB eNodeB

iManager M2000-CME
The M2000 allows users to export data through a scheduled task or manually.
 Exporting data through a scheduled task
If users want to export data through a scheduled task, they need to create a scheduled
data export task by using the task management function provided by the M2000. Then,
the M2000 automatically executes the task at a specified time and saves generated data
configuration files to a specified directory on the file server. Umbrella OSS users can
obtain the files from the directory through FTP.
 Exporting data manually
Users can export data manually through the M2000 client. The M2000 exports
configuration data into files, and then saves the files to a specified directory on the file
server. Users can obtain the files from the directory through FTP by using the umbrella
OSS. At the same time, the files are automatically downloaded to a specified directory on
the M2000 client for users to view.
2.1.2 Exporting Data Through a Scheduled Task

Users can perform the following steps to export data through a scheduled task:
Step 1 Create a task.
Users need to do as follows to set information when they create a scheduled data export task
by using the task management function provided by the M2000:
 Specify whether the task is one-time or periodic: If users specify that the task is a
scheduled task, they can set the period (minimum unit: day) and times for executing the
task.
 Specify the time when the task will be executed. For the one-time task, it can be
specified as "execute immediately".
 Specify the range of exported data, such as radio parameters, transmission parameters,
and all.
 Select NEs whose data you want to export.
 Set telecom operator information: If multiple telecom operators share one network, users
can export only the configuration data of NEs owned by one telecom operator.
Step 2 Submit the task.
Users can submit the task after they set all required information. Then, the M2000
automatically executes the task at the specified time to export data.
 Users can create multiple tasks simultaneously as required.

 Users can view and modify settings of existing scheduled tasks.
 Users can delete tasks that are no longer used.
----End
2.1.3 Exporting Data Manually

Users need to do as follows to set information when they export data through the M2000
client:
 Specify the format of exported files. By default, only the XML format is supported.
 Specify the directory on the client for saving exported files.

iManager M2000-CME
 Specify the directory on the client for saving exported reports.

 Specify the range of exported data, such as radio parameters, transmission parameters,
and all.
 Select NEs whose data you want to export.
 Set telecom operator information: If multiple telecom operators share one network, users
can export only the configuration data of NEs owned by one telecom operator.
Exported files and reports are automatically downloaded to a specified directory on the
M2000 client for users to view.
2.2 Directories for Saving Exported Files

2.2.1 Directory on the M2000 Server
Exported northbound data files are saved in /export/home/omc/var/fileint/cm/Index. The
value of Index is 0 by default, and is the telecom operator index if multiple telecom operators
share one network.
2.2.2 Directory on the M2000 Client

If users export data manually, exported northbound data files are automatically downloaded to
a directory specified by users on the M2000 client. By default, the directory is the installation
path of the M2000 client.
2.3 Rules for Compressing, Splitting, and Naming

Exported Files
2.3.1 Rules for Compressing Exported Files
If users select a large number of NEs on a live network to export data simultaneously, the size
of exported data files might reach hundreds of MB or more. This wastes the disk space on the
server and requires longer time for file copy and transfer. To solve these problems, the M2000
compresses the files after the export.
Files to be transferred over the M2000 NBI are compressed in ZIP format.
One compressed package contains multiple files generated during one export task.
2.3.2 Rules for Splitting Exported Files

Isolation between NE Types and Versions
A live network always contains different types of NEs, such as base station and base station
controller. One type of NEs can map two versions during network upgrade. Different types of
NEs map different configuration models, and different versions of NEs of the same type also
map different configuration models.
Files exported over the NBI are carriers for data exchange between the M2000 and the
umbrella OSS. They are intended for umbrella OSS users. To prevent the coupling of the

iManager M2000-CME
configuration models for different types and versions of NEs from impeding the umbrella
OSS' file processing, the M2000 exports data from different types and versions of NEs into
different files.
Therefore, the umbrella OSS can use the same format to parse files and achieve better
software design in the following ways: Each data-parsing module processes only the
configuration data of one type of NEs. All data-parsing modules are centrally scheduled by a
management module. The management module assigns files to data-parsing modules based on
the characteristics of each file. This software architecture is closed to modification and open
to extension.
This software architecture also brings benefits in certain circumstances. For example, a
mature GSM data management tool is already available for managing BSC configuration data
on a network. However, with network development, spectrum refarming is implemented to
introduce LTE, and therefore users intend to develop a new tool for managing eNodeB
configuration data. In this case, the new tool manages only eNodeB configuration data
without affecting the existing GSM data management tool.
Export by NE Group
If configuration data of multiple NEs is exported into one file, the size of such a file might
also reach hundreds of MB or more. This requires that the umbrella OSS provide a high
data-processing performance in order to parse such files after it obtains the files.
To solve the problem, the M2000 groups NEs before it exports configuration data. Each group
contains a certain number of NEs and configuration data of NEs in the same group is exported
into one file. By doing this, the M2000 controls the size of each exported file. Users can set
the maximum number of NEs allowed in one group as required. By default, a maximum of
200 NEs are allowed.
Users are not allowed to specify the policy for the M2000 to group NEs. Therefore, the
grouping results might differ from users' expectation. For example, users hope to group NEs
by name, whereas the M2000 cannot meet the requirement. To group NEs as expected, users
are advised to create multiple scheduled data export tasks.
2.3.3 Rules for Naming Exported Files

Rules for Naming Compressed Packages
Users are allowed to set the name format of compressed packages exported over the M2000
CM NBI. This helps users obtain and parse data easily through the umbrella OSS. Names of
such compressed packages contain one constant character string and multiple variables. The
variables and their meanings are described as follows:
 $Scope$: range of exported parameters. Users specify the value of this variable when
they create an export task. If users export only radio parameters, the value of this
variable is Rf. If users export only transmission parameters, the value of this variable is
Tx. If users export radio and transmission parameters, the value of this variable is RT.
 $fileType$: format of exported files. The fixed value of this variable is XML.
 $TimeStamp$: time when a file is generated. The time is accurate to microsecond and is
in the following format: <MM>_<DD>_<YYYY>_<HH>_<MM>_<SS>_<MMM>.
 $OMCIP$: IP address of the M2000 server. The IP address is in the following format:
<XXX_XXX_XXX_XXX>. This information helps users identify the sources of data if
they obtain data of NEs managed by multiple M2000 servers simultaneously through the
umbrella OSS.

iManager M2000-CME
Users can define names of exported compressed packages using the constant character string
and variables. For detailed operations, users can see section 7.2 "Customized Data Export
Options."
By default, compressed packages exported over the M2000 CM NBI are named in the
following format: NBIExport_$fileType$_$Scope$_$TimeStamp$_$OMCIP$.zip.
For example, if the name of an exported compressed package is
NBIExport_XML_RT_10_20_2012_11_55_17_050_10_121_72_180.zip, the IP address of
the M2000 server is 10.121.72.180 and the XML compressed package that contains radio and
transmission parameters is generated at 11:55:17:050 on October 20, 2012.
Rules for Naming Exported Files

Users are allowed to set the name format of files exported over the M2000 CM NBI. This
helps users obtain and parse data easily through the umbrella OSS. Names of such files
contain one constant character string and multiple variables. The variables and their meanings
are described as follows:
 $MOCType$: range of exported parameters. Users specify the value of this variable
when they create an export task. If users export only radio parameters, the value of this
variable is Rf. If users export only transmission parameters, the value of this variable is
Tx. If users export radio and transmission parameters, the value of this variable is RT.
 $TimeStamp$: time when a file is generated. The time is accurate to microsecond and is
in the following format: <MM>_<DD>_<YYYY>_<HH>_<MM>_<SS>_<MMM>.
 $OMCIP$: IP address of the M2000 server. The IP address is in the following format:
<XXX_XXX_XXX_XXX>. This information helps users identify the sources of data if
they obtain data of NEs managed by multiple M2000 servers simultaneously through the
umbrella OSS.
Users can define names of exported files using the constant character string and variables. For
detailed operations, users can see section 7.2 "Customized Data Export Options."
Data of different network types might be managed by different umbrella OSS tools. To help
users identify data of different network types based on file names, the M2000 allows users to
set file formats based on network types including GSM, UMTS, and LTE.
By default, GSM data files exported over the M2000 CM NBI are named in the following
format: GNBIExport_XML_$MOCType$_$TimeStamp$_$OMCIP$.xml.
For example, if the name of an exported file is
GNBIExport_XML_RT_10_20_2012_11_55_17_050_10_121_72_180.xml, the IP address
of the M2000 server is 10.121.72.180 and the XML file that contains the radio and
transmission parameters of a GSM NE is generated at 11:55:17:050 on October 20, 2012.
Users can manage data more easily through the umbrella OSS if names of the files that
contain data of existing SingleRAN base stations on a live network provide network type
information. Therefore, a network type variable, $BizMode$, is included in each file name.
$BizMode$ indicates the network type of a SingleRAN base station. The values of this
variable are described as follows:
 LTE: indicates an eNodeB.
 NodeB: indicates a NodeB.
 Co-MPT BTS: indicates a BTS3900 co-MPT base station.
If users export files by NE group and set the maximum number of NEs allowed in one group
to 1, data of each NE is exported over the M2000 NBI into an independent file. If NE names

iManager M2000-CME
are included in names of such files, the OSS can manage the files more easily. Therefore, the
M2000 names such single-NE data files in a special format by including an NE name variable,
$NeName$, which indicates name of an NE.
By default, GSM single-NE data files exported over the M2000 CM NBI are named in the
following format:
GNBIExport_XML_$MOCType$_$NeName$_$TimeStamp$_$OMCIP$.xml.
For example, if the name of an exported file is
GNBIExport_XML_RT_BSC010_10_20_2012_11_55_17_050_10_121_72_180.xml, the
IP address of the M2000 server is 10.121.72.180 and the XML file that contains the radio and
transmission parameters of only a GSM NE named BSC010 is generated at 11:55:17:050 on
October 20, 2012.
2.4 Deletion of Expired Exported Files

As described in the preceding sections, NE configuration data is saved in a specified directory
on the server after it is exported into files. Consequently, excessive disk space is consumed if
more and more files continue to be saved in the directory. To solve this problem, users are
advised to delete expired files after they obtain new files through the umbrella OSS. In
addition, the M2000 attempts to automatically delete expired files through either of the
following mechanisms when it exports northbound data files:
 The M2000 deletes files generated before a predefined period (unit: day).
 The M2000 deletes files generated earlier based on a predefined maximum number of
files.
Users can select a mechanism as required.
2.5 FTP Information for File Transfer

Users obtain exported northbound data files saved in a specified directory on the M2000
server through FTP using the umbrella OSS. The M2000 serves as the FTP server. By default,
the FTP information is as follows:
 FTP user account: ftpuser
 FTP port: 21
 FTP password: set by the administrator. After the M2000 is deployed, the default
password is Changeme_123.
 FTP server directory: Users can see section 2.2 "Directories for Saving Exported Files."
2.6 RAN Sharing Export

If multiple telecom operators share one network, users can export only the configuration data
of NEs owned by one telecom operator. When setting telecom operator information,
Northbound Export could export XML files which just contain the CM data owned by
someone CnOperator.

iManager M2000-CME
Users can set telecom operator information in a scheduled task or manually, for example:
In the RAN Sharing export, all the transport MOCs and BSC algorithm parameter will not be
exported.
For RAN Sharing export files only provide to the corresponding CNOPERTOR, those files
should saved to different directory. The directory is
/export/home/omc/var/fileint/cm/CnOpIndex.
For example:
When one CnOperator has the information: MCC = 460, MNC = 07, CnOpIndex = 1.
Then the export directory is: /export/home/omc/var/fileint/cm/1.
Notes:
The directory /export/home/omc/var/fileint/cm/0 should be created after install M2000 system.
But other CnOperator’s directory should not be created at the beginning. If the directory not
be created, corresponding CnOperator should create a RAN Sharing user in the M2000 GUI,
the directory could be created automatically.
For export files will include all the BSC’s data, RAN Sharing export didn’t support one
CnOperator have two different CnOpIndex, or one CnOperator have two different
CnOperatorName.
For example the following settings are incorrect:
In RNC_001, MCC = 460, MNC = 07, CnOpIndex = 1.
In RNC_002, MCC = 460, MNC = 07, CnOpIndex = 2.

iManager M2000-CME
Northbound Interface Specification 3 Northbound File Interface for Data Import
3 Northbound File Interface for Data Import
3.1 Data Import Process

3.1.1 Overview
Figure 3-1 shows the process of importing data over the NBI.
Figure 3-1 Process of importing data over the M2000 CM NBI
The umbrella OSS

OSS generates an XML file and
saves the file to a specified
directory on the M2000
server.
The M2000-CME imports

M2000 GUI the XML file, and then
validates and activates the
file on the NE.
M2000
CM Northbound Agent
FM PM
Export Import
File FTP Job

Server Server Scheduling
CM DB
Public Utilities
RNC/BSC eNodeB
NodeB/BT
NodeB/BTS eNodeB eNodeB
S

iManager M2000-CME
Users can perform the following steps to import data.

Step 1 Generate files through the umbrella OSS and upload the files through FTP to a specified
directory on the M2000 server.
Step 2 Import the files through the M2000 client.
Step 3 Check the files and generate and deliver scripts using the M2000 after the files are imported.
----End
3.1.2 Importing Data

During actual O&M practice, one configuration data modification task might involve both the
data planning department, which is further divided into two departments for radio parameter
planning and transmission parameter planning, respectively, and the O&M department.
Therefore, engineers from these departments need to cooperate closely to modify
configuration data through the NBI.
Figure 3-2 shows the process of importing configuration data over the NBI.
Figure 3-2 Process of importing configuration data over the M2000 CM NBI
Import Workflow of Northbound interface

Data Planning Data Transfer Data Validation Data Activation
Phase Phase Phase Phase
Planning&design
OSS
Engineer
Generate XML
Radio Tool
files
Transmission Tool
Download file
via FTP
Engineer
M2000
XML Import Export Script

CME
files File
Activate
File Path
Result Report
RNC/BSC/eNodeB
NE
NodeB/BTS NodeB/BTS
The process includes the following phases.
Data Planning Phase

During this phase, data planning engineers plan how to modify NE configuration data based
on the configuration data on the live network and the expected adjustment target.
Data Transfer Phase

After NE configuration data is planned, the umbrella OSS generates XML files accordingly.
Users then upload the XML files to the /export/home/omc/var/fileint/cm/0/Data directory
on the M2000 server.

iManager M2000-CME
During this phase, two cooperation relationships are available based on users of the umbrella
OSS.
 O&M engineers use the umbrella OSS: Data planning engineers send planned data to
O&M engineers through an agreed method, and then the O&M engineers generate XML
files.
 Data planning engineers use the umbrella OSS: Data planning engineers directly send
XML files to O&M engineers.
Users can choose a cooperation relationship as required.
NOTE
The M2000 automatically creates the directory on the M2000 server for storing imported northbound
data files when the CME is installed, and assigns permission to access the files. Users can contact the
system administrator to reset permission if the permission does not meet their requirement for accessing
the files.
Data Validation Phase

During this phase, users import XML files through the M2000 client, and the CME checks
delivered configuration data.
If the delivered configuration data passes the check, the CME generates scripts that can be
delivered to NEs.
Data Activation Phase

After scripts are generated, users activate the scripts on NEs, and then evaluate network
performance through the M2000.
After the scripts are activated and take effect, the CME automatically synchronizes
configuration data from the live network. This ensures that the configuration data on the CME
is consistent with that on the live network.
3.1.3 Principles for Designing the M2000 CM NBI

Scenario-based Business Functionality
Based on its substantial global network O&M practice, Huawei learns that the adjustment of
configuration data depends on specific business targets and these business targets can be
divided into a limited number of categories. The data adjustment methods and involved data
for achieving business targets of the same type are similar. Such typical business targets and
adjustment methods are also referred to as configuration scenarios. Further analysis shows
that configuration scenarios are independent from one another and each configuration
scenario is featured with a unique requirement lifecycle. For example, the GSM frequency
refarming scenario is used across the whole network lifecycle, whereas the TDM-to-IP
transport network reconstruction scenario might be used only during the network
reconstruction phase.
The CM efficiency can be improved if CM is designed and implemented based on the
preceding typical configuration scenarios. In other words, the typical configuration scenarios
represent the requirements of actual network O&M on CM solutions, and are the value-added
points of the CM solutions. Based on this concept, R&D engineers should first analyze the
requirements on configuration data adjustment, identify typical configuration scenarios based
on the analysis results, and then formulate an efficient CM solution for each configuration
scenario. Driven by this concept, Huawei develops a scenario-based CM solution, CME,

iManager M2000-CME
which is used with the M2000. The M2000 CM NBI is also designed based on this concept in
order to provide an interface interconnection capability in all daily used configuration
scenarios.
Data-based Interface
Network resource model (NRM) information is critical during the design of a CM NBI
solution. The information provides guidance for users to construct business models through
the umbrella OSS. Users can efficiently manage configuration data through the umbrella OSS
only with the help of business models. Meta information about the NRM mainly includes the
relationships and business restrictions between objects.
The difference between configuration data and NRM meta information is as follows: NRM
meta information is static and does not change along with users' configuration operations,
whereas configuration data is changeable. From the perspective of the umbrella OSS, the
reason is as follows: NRM information is used only during the R&D phase and cannot be
updated after the interconnection, whereas configuration data is not used during the R&D
phase and needs to be periodically updated after the interconnection to ensure consistency
with data of the live network. In general, configuration data and NRM meta information
should be dealt with differently when the umbrella OSS and the M2000 are interconnected.
The NBI provided by the M2000 serves as a channel for configuration data exchange between
the umbrella OSS and the M2000. Files imported and exported over the NBI are used to carry
configuration data. However, they do not carry NRM meta information. This ensures a simple
structure of data configuration files transferred over the NBI and reduces the complexity for
the umbrella OSS and the M2000 to generate and parse files.
Huawei provides dedicated documentation to describe NRM meta information. The
documentation includes parameter lists and the descriptions, relationships, and business rules
of managed object classes (MOCs). By using the documentation, R&D engineers can obtain
NRM information and improve their work efficiency.
The M2000 CM NBI is designed as an incremental data interface to help users improve their
efficiency in adjusting configuration data.
Hierarchical Parameters and Customization

1. Principles and Policies for Hierarchical Parameters
Radio access networks (RANs) provide various services and the corresponding configuration
resource models contain a large number of parameters. If the upper-layer OSS manages all
parameters, development and maintenance costs will increase. In addition, Huawei finds that
the upper-layer OSS focuses on routine operation and maintenance and uses certain
configuration scenarios in most cases. Therefore, not all parameters are used in these
scenarios, and the upper-layer OSS has to manage required parameter subsets only. This
simplifies routine configuration operations and lowers northbound interconnection costs.
Huawei operates and maintains wireless networks all over the world and has rich experience
on northbound interworking. Based on the statistics about configuration parameter usage,
configuration parameters are classified into different types. The types and policies are as
follows:
Commonly used parameters: refer to parameters that are mandatory or frequently modified for
related features. The NBI parameter list covers all commonly used parameters, and the NBI
supports these parameters by default. In most cases, commonly used parameters are 30 to
40% of all parameters. Huawei provides the management object model document

iManager M2000-CME
(Northbound Interface MOM Reference) for commonly used parameters. This document
describes MOCs, relationships between MOCs, parameters, and service rules.
Uncommonly used parameters: refer to parameters that are seldom used. The NBI parameter
list covers uncommonly used parameters, but the NBI does not support these parameters by
default. Users can use a parameter selection tool to subscriber to these parameters over the
NBI if required. Huawei does not provide the management object model document for
uncommonly used parameters.
Northbound unexposed parameters: refer to parameters that are seldom used, parameters that
can be modified only by following Huawei engineers' guidance, or parameters for customized
features. The NBI parameter list does not cover these parameters.
2. Impact of Hierarchical Parameters
The impact of hierarchical parameters on the NBI is as follows:
 Parameter export over the NBI
By default, only commonly used parameters are exported over the NBI. If users concern on
some parameters that are excluded from commonly used parameters, they can use the
customization function provided by the CME to customize parameters. For details, see 3
"Customized Parameters."
 Parameter import over the NBI
By default, only commonly used parameters are imported over the NBI. If users concern on
some parameters that are excluded from commonly used parameters, the CME allows users to
customize parameters. For details, see 3 "Customized Parameters."
3. Customized Parameters
On the live network, different parameters are used during routine operation and maintenance.
Some uncommonly used parameters may be critical at certain sites, and some commonly used
parameters or mandatory parameters may be unnecessary at other sites.
To avoid the impact of customized parameters on northbound interworking, the CME
provides the function of customizing parameters.
 Customizing parameter ranges: Users can subscribe only to required parameters. After
users select parameters, the NBI allows users to import and export the parameters.
 Customizing default values for parameters: Users can use the customization tool to
customize default values for mandatory parameters that have only unique values on the
live network or for parameters whose default values provided by Huawei do not meet
user requirements. For example, in the GSM configuration resource model, users can set
latitude and longitude information for a cell in the MOC GCELLLCS and set the format
of latitude and longitude information in the INPUTMD parameter. The default value of
the INPUTMD parameter is Degree. However, on certain networks, the commonly used
format of latitude and longitude information may be the following: "Degree Minute
Second". In this case, users can customize default values to avoid that the upper-layer
OSS manages this parameter.
The CME provides a tool for users to customize parameters and default values. For details,
see iManager M2000-CME Northbound Interface Parameters Selection Tool User Guide.

iManager M2000-CME
Roles of the Umbrella OSS and the M2000

Based on the preceding sections, the M2000 CM NBI transfers simple data files based on
scenarios. Figure 3-3 shows the interconnection between the umbrella OSS and the M2000.
Figure 3-3 Interconnection between the umbrella OSS and the M2000 through the M2000 CM
NBI
Umbrella OSS CME
NBI Subsystem
Application Tools GUI Apps for User
Data Flow
Business Logic Engine NBI Logic Processor CM Logic Engine
Data Flow
Huawei EMS Adapter Data Interface for NMS Data Interface for NE
In the umbrella OSS, a Huawei element network system (EMS) mediation is deployed and
application tools are constructed based on the mediation. After data is submitted from an
application tool, the mediation reorganizes the data based on configuration scenarios, and then
generates incremental data files that meet the M2000 CME NBI's requirements.
The umbrella OSS can manage data of NEs from multiple vendors in terms of the entire
network. In certain configuration scenarios, for example, when neighbor relationships on the
entire network are adjusted, data of NEs from multiple vendors need to be adjusted together.
Therefore, the umbrella OSS instead of the M2000 is suitable to provide a capability for
adjusting configuration data of the entire network.
In certain configuration scenarios, required configuration data might be planned by using
multiple umbrella OSS tools, and such data needs to be merged when CM northbound data
files are generated.
The umbrella OSS executes the following checks when it generates northbound incremental
data files to ensure the validity of generated files:
 XML syntax check
Generated files must comply with the XML syntax.
 XML schema constraint check
The format of generated files is described in XML schemas. Therefore, the files must
follow XML schema constraints.
 General data check

iManager M2000-CME
The general data check includes a range check and a data type check.
The M2000 executes the following checks when it imports data over the NBI:
 Data file validity check: The M2000 checks whether data files are valid. For details,
users can see section 4 "Format of Northbound Data Files."
 Data validity check: The M2000 parses data and then checks whether the parsed data is
valid. The check includes a data consistency check and a data integrity check.
 Configuration scenario identification: The M2000 identifies the configuration scenario of
imported data.
 Business logic processing and rules check: The M2000 processes data based on the
identified configuration scenario and then checks the business rules of the data. Business
rules are restrictions on configuration data in terms of business and ensure that
configuration data can properly take effect.
Errors might occur during any of the preceding steps. If an error occurs, the CME stops to
export the error information into a file, and then saves the file to the
/export/home/omc/var/fileint/cm/0/report directory on the M2000 server. Users can obtain
such files through FTP by using the umbrella OSS. Such files are also automatically
downloaded to the M2000 client for users to view.
Errors might also occur when NE scripts are delivered and activated on NEs. Users must
handle such errors through the M2000.
3.1.4 Software Architecture and Process of M2000 CM NBI

Interconnection
This section describes the software architecture and process of the M2000 CM NBI
interconnection based on Huawei practice and serves as a reference only. Users can design
and deploy their own umbrella OSS as required.
Figure 3-4 shows the software architecture of the M2000 CM NBI interconnection.

iManager M2000-CME
Figure 3-4 Software architecture of the M2000 CM NBI interconnection
TPT RPT Planning

department
employee
Import planning data Import planning data
Umbrella OSS
O&M Operator
Import
Consistency Check
Delta
Log Delta
DB (XML file)
Network Data Importer Filter

(XML file)
Download
XML files to the
Fetch exported files from the M2000 M2000 through FTP
M2000
N-Itf App M2000
Client
Validate
O&M Operator
import data
Generate LMT
delta scripts Import
O&M Operator
Scripts
Activation Ctrl FTP Server
CME Current (Specified
DB Directory)
Activate scripts
Note:
Data Sync The line marked with blue
represents the downlink info
flow, and red for uplink info
NE flow.
In Figure 3-4, the transmission network planning tool (TPT) and radio access network
planning tool (RPT) are deployed at the OSS application layer based on specific configuration
scenarios. Users can purchase the TPT and RPT from third-party vendors or design such tools
by themselves. The umbrella OSS interconnects to the M2000 CM NBI and provides the
Huawei EMS mediation and business logic engine described in section 3.1.3 "Principles for
Designing the M2000 CM NBI." Scenario-based data generated by the TPT and RPT is
imported to the umbrella OSS. Then, the umbrella OSS compares the data with the live
network data saved in the database and generates incremental data files based on the M2000
CM NBI's format requirements.
After generated incremental data files are uploaded from the umbrella OSS to a specified
directory on the M2000 server, users can import the files on the M2000 client.
After the import, configuration data is delivered to NEs and takes effect. Then, the M2000
automatically synchronizes data from NEs to ensure that data on the M2000 is consistent with
that of the live network. Users can obtain updated configuration data through the umbrella
OSS after the M2000 completes data synchronization.

iManager M2000-CME
Figure 3-5 shows the process of importing data over the M2000 CM NBI.
Figure 3-5 Process of importing data over the M2000 CM NBI

Planning employee
RPT TPT
Do radio
planning job
Do transmission
planning job
Export planning data O&M

Operator
OSS M2000 Client M2000 Server NE
Notify O&M Operator

that the planning data is ready
Import planning
Data (csv) It’s HCM responsibility to
merge transmission data
and radio data together
Generate XML files
Download file
request
XML files are downloaded onto
M2000 Server via FTP
Import XML files

request
Validate the XML files
Report the import result
Generate the delta scripts
Activate scripts
request
Activate scripts in NE
Report the activation result
CME sync the live network data
Notify the completion of the synchronization
3.2 Technical Conventions for Data Import Over the NBI

3.2.1 Import of Incremental Data Files
Only incremental data files can be imported over the M2000 CM NBI. Therefore, the
umbrella OSS must be able to generate XML files that contain only incremental configuration
data. If other unmodified data is included in generated XML files, the performance of data
import might be affected.
3.2.2 Modification of Data

If users want to modify only one data record, only the parameters to be modified and the
primary key parameters need to be included in the configuration data. All other parameters
retain their existing values.
3.2.3 Management of Imported Files

As described in section 3.1.2 "Importing Data", users need to upload files to be imported over
the NBI to a specified directory on the M2000 server. If space in this directory is not cleaned,

iManager M2000-CME
more and more files will be saved in this directory. This consumes disk space and makes it
difficult for users to select desired files among a large number of files.
To solve this problem, the M2000 provides a function for users to delete files on the GUI for
selecting files to be imported. Alternatively, users can directly delete files in the directory
through FTP.
3.3 FTP Information for File Transfer

3.3.1 FTP Server Information
Users upload files to be imported over the NBI through FTP to a specified directory on the
M2000 server using the umbrella OSS, and then obtain report files after the files are imported.
The M2000 serves as the FTP server. By default, the FTP information is as follows:
 FTP user account: ftpuser
 FTP port: 21
 FTP password: set by the administrator. After the M2000 is deployed, the default
password is Changeme_123.
 FTP directory: Users can see sections 3.3.2 "Directory for Saving Imported Files" and
3.3.3 "Directory for Saving Report Files."
3.3.2 Directory for Saving Imported Files

Exported files are saved in /export/home/omc/var/fileint/cm/0/Data.
3.3.3 Directory for Saving Report Files

Report files are saved in /export/home/omc/var/fileint/cm/0/report.

iManager M2000-CME
Northbound Interface Specification 4 Format of Northbound Data Files
4 Format of Northbound Data Files
Files transferred over the M2000 CM NBI are in XML format and content of such files is
subject to XML schema constraints. XML schemas are used to define the objects, parameters,
and parameter ranges allowed in XML files. Such content is part of the NRM information and
varies with NE types and versions. Therefore, different XML schema files are used for
different types and versions of NEs and are released along with NE versions.
This chapter describes the general format of XML files transferred over the M2000 CM NBI
to help users understand the XML files. Information provided in this chapter is also included
in XML schema files, and therefore can serve as reference for users to analyze XML schema
files.
Each XML file transferred over the M2000 CM NBI includes the following parts:
 File header
 Subsession
 File footer
Following describes the formats of these parts:
4.1 File Header

File header, whose tag is fileheader, is the first element in an XML file. It contains only one
optional attribute, filetype, whose value is a character string. The M2000 CM NBI does not
process the value of this attribute when it processes a file. This attribute is designed to identify
certain reference information. For example, the value of this attribute is set to ImportFile
when files are imported and is set to ExportFile when files are exported.
One northbound XML file contains only one file header element.
For example:
<fileheader filetype="ExportFile"/>

iManager M2000-CME
4.2 Subsession
Subsession, whose tag is subsession, is the body of an imported northbound data file. Each
subsession contains the data of one NE. When users export data, data of one NE is exported as
one subsession.
As described in section 3.1.3 "Principles for Designing the M2000 CM NBI", the import of
data over the M2000 CM NBI is designed based on configuration scenarios. Therefore,
subsessions are introduced to isolate NE data for different configuration scenarios. For
example, even on the same base station controller, data for transmission expansion and data
for neighbor relationship adjustment are placed in different subsessions.
Subsession is also the unit for isolating transactions during data import. Subsessions are
processed in sequence. If one subsession fails, other subsessions are not affected.
One northbound XML file contains one or multiple subsessions.
4.2.1 Attributes of Subsession

Following describes the attributes of the subsession element:
subsessionid is an optional attribute whose value is a character string. It uniquely identifies a
subsession. During data import, one NE might map multiple subsessions and users cannot
identify the sources of imported data based only on NE information. To solve this problem,
subsessionid is designed to provide reference for users to fix bugs if there are any. If the
value of this attribute is empty, the M2000 automatically assigns a value to this attribute based
on the NE name and the sequence number of the subsession in the current file.
Opmode is a reserved attribute whose value is an enumerated value. Its valid values include
BestEffort and BreakonFailure. Opmode is designed to indicate the policy for processing a
subsession during data import. This attribute is unavailable for now, and therefore its value is
always set to BreakonFailure. This attribute does not apply to data export.
The child element of the subsession element is NE.
4.2.2 NE: Container of NE Data

The NE element carries NE data. It is featured with the following attributes:
 netype: type of an NE. This attribute is mandatory and its value is an enumerated value.
 neversion: version of an NE. This attribute is mandatory and its value is an enumerated
value.
 operation: configuration scenario. This attribute is optional and its value is an
enumerated value. It applies only to data import.
 neid: name of an NE. This attribute is mandatory and its value is a character string.
 productVersion: version of the base station. This attribute is optional. It is valid only
when you create a base station.
Currently, one subsession contains only one child element. In subsequent versions, this
structure might be used to enable closely related NE data to take effect as transactions.
For example:
<NE xsi:type="SRAN" netype="LTE" neversion="BTS3900 V100R008C00" neid="LTE_1"
productVersion="BTS3900 V100R008C00SPC020">
The child element of the NE element is module.

iManager M2000-CME
4.2.3 Module: Grouping of Configuration Data

As described in section 3.1.3 "Principles for Designing the M2000 CM NBI", users might
deploy multiple umbrella OSS tools based on actual service needs. These umbrella OSS tools
might manage different configuration data. In addition, a large number of MOCs and
parameters are available in the NRM. As a result, the data amount of XML files exported over
the NBI is large. Each umbrella OSS tool needs to filter out much unconcerned data when it
parses such a file. To solve this problem, the M2000 groups MOCs. The grouping is designed
based on Huawei experience in configuration management and might not be the same as what
users have expected.
The module element is also designed for logical NEs. With network development, multimode
NEs, each of which contains multiple logical NEs, are deployed. Each module maps one
logical NE.
Grouping of MOCs in XML files is represented by modules whose tag is module.
One NE element contains one or more module child elements.
Following describes the attributes of the module element:
 neName: name of a module. This attribute applies only to base stations and is mandatory.
Its value must be consistent with the neid attribute of the NE element.
 remark: applies only to base station controllers and is optional. This attribute serves
only as a reference and is not used during data import over the M2000 CM NBI.
In XML files, the xsi:type attribute is used to indicate the group type of each module.
xsi:type is a default attribute that is defined at http://www.w3.org/2001/XMLSchema-instance
to indicate the data type of an element, and its value varies with NE types.
For BSCs, configuration data includes transmission parameters and radio parameters, and
therefore the value of xsi:type is Transmission or Radio.
For NodeBs, the value of xsi:type is UMTSSiteModule. For eNodeBs, the value of xsi:type
is LTESiteModule.
For co-MPT base stations, configuration data is managed based on public network and
network type, and therefore the value of xsi:type is NodeModule, eNodeBFunctionModule,
NodeBFunctionModule, or GbtsFunctionModule. NodeModule indicates configuration
data collected from the device and transmission layers of a public network, whereas the other
values indicate configuration data collected from various types of network.
If multiple modules are available under one NE element, the sequence of these modules is
random.
For example:
<module xsi:type="LTESiteModule" neName="LTE_1">
The child element of the module element is moi.
4.2.4 Moi: Actual Configuration Data

One configuration data record is displayed as one moi element, whose tag is moi, in
northbound XML files. Following describes the attribute of the moi element:
 modifier: operation type of data. This optional attribute applies only to data import and
its valid values include create, update, or delete. In imported files, if the modifier
attribute of a moi element is empty, no operation is required. Different MOCs support

iManager M2000-CME
different types of operations. Some MOCs might support only data update. For details
about the types of operations that MOCs support, users can see the parameter description
document released with a desired NE version.
In XML files, the xsi:type attribute is used to indicate the MOC type of each moi element.
xsi:type is a default attribute that is defined at http://www.w3.org/2001/XMLSchema-instance
to indicate the data type of an element.
Following describes the operations related to the moi element:
Creating a Moi
When users create a moi element, they must set all mandatory parameters properly. If users do
not set optional parameters, the M2000 will use the default values of these optional
parameters. Users must check that the default values of parameters are the same as expected if
they choose to use the default values of these parameters.
If a moi element that users want to create already exists, the M2000 reports an error stating
that the object already exists and then terminates all other operations of the current
subsession.
Updating Some Parameters of an Existing Object

When users update an existing object, they must check that they have specified all primary
key parameters and the parameters that they want to update. They do not need to specify the
parameters that they do not want to update. If the object does not exist, the M2000 reports an
error stating that the object does not exist and then terminates all other operations of the
current subsession.
Deleting an Existing Object

When users delete an existing object, the M2000 automatically deletes only the subobjects,
instead of associated objects, of the object.
In addition, users must check that they have specified all primary key parameters of the
object.
Users must not create or modify any subobject of an object when they delete the object.
Otherwise, unexpected results might occur.
If an object that users attempt to delete does not exist, the M2000 ignores the object and
continues to subsequent operations. In addition, an alarm is generated in the related report file.
In exported files, the values of modifier for all moi elements are empty.
The sequence of all moi elements under a module is random. The umbrella OSS can sort moi
elements randomly in generated XML files.
Parameter information of each moi element is included in the attributes element.

iManager M2000-CME
4.2.5 Attributes: Detailed Parameter Information

The attributes element contains one or multiple child elements whose tags are parameter
names. Each child element indicates an actual parameter. Users specify the value range of
parameters through these child elements.
The sequence of child elements under the attributes element is random. However, each child
element appears only once.
Child elements available under the attributes element in a moi element depend on the MOC
indicated by the xsi:type value of the moi element. For details about the parameter
information included in MOCs, users can see the parameter description document released
with a desired NE version.
Each moi element contains only one attributes child element.
For example:
<moi xsi:type="CELLBF"
modifier=”update”><attributes><LOCALCELLID>0</LOCALCELLID><MAXBFRANKPARA>0</MAXBFR
ANKPARA></attributes></moi>
4.3 File Footer

The tag of file footer is filefooter. File footer has only one attribute, datetime, which
indicates the time when a file is generated in the following format: YYYY-MM-DD
HH:MM:SS. The value of this attribute is for reference only and has no substantial meaning
during data import and export.

iManager M2000-CME
Northbound Interface Specification 5 Format of Report Files
5 Format of Report Files
After data is imported, the M2000 generates resulting report files for users to view. This
chapter describes the format of such report files.
As described in section 3.1.2 "Importing Data", the subsession element is used in files
transferred over the M2000 CM NBI in order to isolate different configuration scenarios and
the configuration data of different NEs. Users can import data contained in multiple
subsessions during one import task. The M2000 generates an import result summary file for
each import task to help users understand the overall task result. The M2000 also generates an
error report for each subsession where errors occur in order to help users better locate
problems.
5.1 Import Result Summary Files

Import result summary files are named in the following format:
RPT_VDT_NBIImportSummary_MM_DD_YYYY_HH_mm_SS_<IP Address>.xml.
where
 MM_DD_YYYY_HH_mm_SS indicates the time when a report file is generated.
 <IP Address> indicates the IP address of the M2000 server. This information is critical
when the umbrella OSS is connected to multiple M2000 systems.
Each import result summary file starts with a result overview that is described by subsession
in the following format:
<spec:Total>1</spec:Total>
<spec:Successful>0</spec:Successful>
<spec:Failed>1</spec:Failed>
Details of each subsession are displayed as a child element whose tag is SubsessionResult.
Users can obtain the import result of each subsession based on the descriptions of the
following attributes of this child element:
 importresult: indicates whether data import succeeds or fails.
 dataimported: indicates whether data is saved in the CME database.
 filename: name of an imported file. This information is critical for users to locate errors
when multiple files are imported simultaneously.
 sequencenumber: sequence number of a subsession in a file.

iManager M2000-CME
Northbound Interface Specification 5 Format of Report Files
 subsessionid: identify of a subsession as described in section 4.2.1 "Attributes of

Subsession." If users do not set the value of this attribute, the values of neid and
sequencenumber, connected by using an underscore, is used.
 neid: the neid attribute described in section 4.2.1 "Attributes of Subsession."
5.2 Subsession Error Report Files

The M2000 generates an error report file for each subsession where errors occur. Such error
report files are named in the following format:
RPT_VDT_eNodeBNE_<SubsessionID>_<SequenceNumber>_MM_DD_YYYY_HH_MM_
SS_<IP Address>.xml.
where
 <SubsessionID> indicates the ID of a subsession, namely, the subsession attribute
described in section 4.2.1 "Attributes of Subsession." If users do not set the value of this
attribute, the values of neid and sequencenumber, connected by using an underscore, is
used.
 <SequenceNumber> indicates the sequence number of a subsession.
 MM_DD_YYYY_HH_mm_SS indicates the time when an error report file is generated.
 <IP Address> indicates the IP address of the M2000 server. This information is critical
when the umbrella OSS is connected to multiple M2000 systems.
In each error report file for rules check, business rules that configuration data violates are
listed one by one. Each error record is displayed as one child element whose tag is log. The
attributes of this child element are described as follows:
 filename: name of an imported file. This information is critical for users to locate errors
when multiple files are imported simultaneously.
 sequencenumber: sequence number of a subsession in a file.
 subsessionid: identify of a subsession as described in section 4.2.1 "Attributes of
Subsession." If users do not set the value of this attribute, the values of neid and
sequencenumber, connected by using an underscore, is used.
 neid: the neid attribute described in section 4.2.1 "Attributes of Subsession."
 description: severity of an error. The value of this attributes can be error or warning.
 class: name of the MOC to which an error belongs.
 time: time when an error occurs.
The log element of each error record includes the following child elements:
 data: values of the primary key parameters of a managed object instance (MOI) for
which an error occurs
 notes: information about an error

iManager M2000-CME
Northbound Interface Specification 6 Other Technical Specifications
6 Other Technical Specifications
6.1 Introduction to Common Configuration Parameter

Types
Following describes some types of configuration parameters for Huawei RAN NEs:
 Enumeration Type: parameter whose value consists of a specified number of discrete
valid integers, with each integer indicating a specific meaning. As described in section
3.1.3 "Principles for Designing the M2000 CM NBI", northbound XML files are used
only as carriers for exchanging data. Therefore, values of such parameters in northbound
XML files are integers instead of parameter meanings.
 Interval Type: parameter featured with one or multiple value ranges. The value of such
a parameter is an integer.
 IP Address Type: parameter whose value is an IP address.
 Character String Type: parameter whose value is a character string.
 Bit Field Type: parameter whose value is a bit field integer without symbol. Each bit
indicates a switch. As described in section 3.1.3 "Principles for Designing the M2000
CM NBI", values of such parameters in northbound XML files are integers instead of
switch information.
 Compound Type: parameter whose value is a character string that is connected by using
colons and indicates time.
Following explains how the value ranges of different types of parameters are described:
 Enumeration Type: All valid values and their meanings are provided.
 Interval Type: The value range of the parameter is delimited.
 IP Address Type: The value is described as a valid IP address character string. In XML
files, this parameter is subject to constraints specified in regular expressions.
 Character String Type: Invalid characters and the length range of the character string
are described.
 Compound Type: The fixed format of the value is described. In XML files, this
parameter is subject to constraints specified in regular expressions.

iManager M2000-CME
6.2 Methods for Processing Parameters of the Bit Field

Type
As described in the preceding section, each bit of a parameter of the bit field type indicates a
switch. This helps improve the memory use efficiency.
Table 6-1 describes a parameter of the bit field type.
Table 6-1 Example parameter of the bit field type
MOC Name Parameter Name Bit Position Value
BaseAttr EncryArithSetup 0 A5/0

In Table 6-1, the first bit of the parameter indicates switch A5/0 and the second bit indicates
switch A5/1.
If the value of this parameter is 161, its binary value is 10100001. Based on Table 6-1, it can
be inferred that the status of switches A5/7, A5/5, and A5/0 is ON and the status of all the
other switches is OFF, as shown in Table 6-2.
Table 6-2 Status of switches
A5/7 A5/6 A5/5 A5/4 A5/3 A5/2 A5/1 A5/0

7 6 5 4 3 2 1 0
1 0 1 0 0 0 0 1 = 161
6.3 Methods for Processing Parameters of the List Type

Parameters of the list type are introduced in Huawei SingleRAN8.0. Logically, such a
parameter is an MOC parameter whose value is a sequence of multiple elements, and is used
to represent a one-to-more binding relationship. For example, one sector includes a group of
functional antennas, where the sector and the antennas make a one-to-more binding
relationship. In the NRM, information about the sector is designed as an MOC named
SECTOR, and information about each antenna is designed as a parameter (of the list type)

iManager M2000-CME
named SECTORANTENNA under the SECTOR parameter. Each element of the

SECTORANTENNA parameter contains four attributes: CN, SRN, SN, and ANTN. The
four attributes comprise a quaternary that uniquely identifies an antenna. Following describes
an example in an XML file:
<moi xsi:type="SECTOR">
<attributes>
<SECTORID>0</SECTORID>
<SECTORANTENNA>
<element>
<ANTN>0</ANTN>
<CN>0</CN>
<SN>0</SN>
<SRN>69</SRN>
</element>
<element>
<ANTN>1</ANTN>
<CN>0</CN>
<SN>0</SN>
<SRN>69</SRN>
</element>
</SECTORANTENNA>
</attributes>
</moi>
From the perspective of NBI interconnection, this parameter design ensures clear logic
expression but brings challenges to data storage and update because:
 The M2000 stores data in a database where each MOC maps one table. However, a
parameter of the list type contains multiple attributes, and therefore cannot be defined as
one field in the table. Instead, users need to create an independent table for each
parameter of the list type in order to express a one-to-more binding relationship on GUIs.
 When users want to update such a parameter by adding or deleting an element, it is
difficult to express the intention in an XML file. Consequently, the umbrella OSS has to
include all elements of the parameter in the XML file, and the M2000 needs to compare
the sequence of all elements of the parameter, which consumes extra system resources.
 Extra codes need to be compiled for applications to parse the parameter.
To solve the preceding problem, each parameter of the list type in an XML file transferred
over the M2000 CM NBI is managed as an independent MOC. This parameter design brings
the following benefits:
 Parameters of the list type in each northbound XML file are expressed in compliance
with the database model. This simplifies the parsing, accessing, and storing of XML
files.
 The umbrella OSS can easily generate XML files in which the intention of modifying
parameters of the list type by adding or deleting certain elements is clearly expressed.
 Binding relationships expressed in parameters of the list type can be processed in batches.
This is because XML files generated by the umbrella OSS can contain only parameters
of the list type.
Following describes an example in an XML file.
<moi xsi:type="SECTOR">
<attributes>

iManager M2000-CME
</attributes>
</moi>
<moi xsi:type="SECTORANTENNAREF">
<attributes>
<ANTN>0</ANTN>
<CN>0</CN>
<SN>0</SN>
<SRN>69</SRN>
</attributes>
</moi>
<moi xsi:type="SECTORANTENNAREF">
<attributes>
<ANTN>1</ANTN>
<CN>0</CN>
<SN>0</SN>
<SRN>69</SRN>
</attributes>
</moi>
If users want to add an antenna for an existing sector, the XML file to be transferred over the
M2000 CM NBI can contain only the data about SECTORANTENNAREF to be added. In
the following example, antenna 2 installed in slot 0 of subrack 69, cabinet 0 is added to a
sector SECTOR 0.
<moi xsi:type="SECTORANTENNAREF" modifier = "create">
<attributes>
<ANTN>2</ANTN>
<CN>0</CN>
<SN>0</SN>
<SRN>69</SRN>
</attributes>
</moi>
Figure 6-1 shows the benefits of managing parameters of the list type as independent MOCs.

iManager M2000-CME
Figure 6-1 Policy for processing parameters of the list type
The only one to be NOT involved at all

added
Main MOI
Main MOC Table Main MOC Table

List Item 0
List Item 1
List Item 2 List MOI 0
List MOC Table List MOC Table
List Item 3
List Item 4
DB DB
XML XML
List as Parameter List as MOC
6.4 Recommended Specifications for NE Names

NE names on the M2000 must conform to the following rules:
 1 to 64 characters are allowed.
 Characters A through Z, a through z, and 0 through 9, and the following special
characters are recommended: _ - @ #
 The following characters are forbidden: ? : > < * / \ | "
 Space and the following characters are not recommended: = , ; '
If space or any of these characters is used, errors occur when users run MML commands
or MML scripts.
 The following characters are not recommended: { } ~ ` ! $ % ^ & ( ) + [ ] .
Otherwise, transferring files through FTP might fail.
The preceding rules apply to all NEs managed by the M2000.
If the NBI is enabled, the M2000 needs to communicate with NEs, operating systems, and
umbrella OSS tools in different formats. Each system might have its own reserved words,
such as the reserved words for operating systems and those for XML files. To maximize the
performance of the NBI, users are advised to name NEs using upper-case letters A through Z,
lower-case letters a through z, and the underscore (_) and ensure that NE names are not
started with digits 0 through 9.

iManager M2000-CME
6.5 Methods for Exporting Template Data

The M2000 CM NBI allows users to create base stations and cells by using a template. In
these scenarios, the template reduces the configuration complexity significantly. Users need to
specify the template information in imported northbound files.
When users export configuration data through the M2000 CM NBI, the template information
supported by the M2000 will be exported.
 Methods for exporting template information about 3900 series base stations
The templates of 3900 series base stations are classified into the base station template,
radio template, and cell template. The template information is exported in a separate file.
The format of the file name is as follows:
$BizMode$_templateInfo.xml
The rules for the value of $BizMode$ are consistent with those of data files, as described
in section 2.3.3 "Rules for Naming Exported Files."
The format of the template information file is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<TemplateInfo type="LTE">
<SiteTemplate>
<attributes>
<SERIES>BTS3900AL_LTE</SERIES>
<VERSION>BTS3900AL LTE V100R005C00SPC320</VERSION>
<TEMPLATENAME>BTS3900AL_BTS3900AL_FDD_S111_10M_2T2R</TEMPLATENAME>
</attributes>
</SiteTemplate>
<RadioTemplate>
<attributes>
<VERSION>DBS3900 LTE V100R005C00SPC320</VERSION>
<TEMPLATENAME>Radio_TDD_SA0</TEMPLATENAME>
</attributes>
</RadioTemplate>
<CellTemplate>
<attributes>
<VERSION>DBS3900 LTE V100R005C00SPC320</VERSION>
<TEMPLATENAME>Cell_TDD_10M_2T2R_SA0</TEMPLATENAME>
</attributes>
</CellTemplate>
</TemplateInfo>
 Template information exported along with base station controller data
The base station and cell data for base stations except the 3900 series base stations are
exported along with the base station controller data. One template information file is
exported for each base station controller.
The format of the template information file exported along with base station controller
data is as follows:
<module xsi:type="Transmission" remark="transmission mois">
<moi xsi:type="BTSTEMPLATERSC">
<attributes>
<TEMPLATENAME>defaultOfBTS3002E</TEMPLATENAME>
</attributes>

iManager M2000-CME
</moi>
<moi xsi:type="GCELLTEMPLATERSC">
<attributes>
<TEMPLATENAME>Default 2G Cell Template</TEMPLATENAME>
</attributes>
</moi>
</module>
6.6 Uniqueness Restriction for MOIs in a Subsession

As described in section 4.2.4 "Moi: Actual Configuration Data", MOIs are contained in
subsessions. Each MOI is identified by its MOC type and primary key parameter. The MOC
types and primary key parameters must be unique for all MOIs contained in a subsession.
During the import, this restriction indicates that a maximum of one MOI can be operated at a
time in a subsession.
For example, the primary key parameter for the MOC CELLBF is LOCALCELLID. MOIs
for which LOCALCELLID values are the same for CELLBF are not allowed in one session.
In an XML file, the following information in one subsession is valid:
modifier=”update”><attributes><LOCALCELLID>0</LOCALCELLID><MAXBFRANKPARA>0</MA
XBFRANKPARA></attributes></moi>
modifier=”update”><attributes><LOCALCELLID>1</LOCALCELLID><MAXBFRANKPARA>0</MA
In an XML file, the following information in one subsession is invalid, because the values of
LOCALCELLID for the two MOIs are the same:
modifier=”delete”><attributes><LOCALCELLID>0</LOCALCELLID><MAXBFRANKPARA>0</MA
modifier=”create”><attributes><LOCALCELLID>0</LOCALCELLID><MAXBFRANKPARA>1</MA

iManager M2000-CME
Northbound Interface Specification 7 Customized Options for the NBI
7 Customized Options for the NBI
7.1 Overview
This chapter describes common configurable customized options provided by the M2000 CM
NBI and the locations of these options. It provides guidance for users to control the NBI by
modifying the values of these options.
After a user changes the value of a customized option, all other users are affected. Therefore,
users must be cautious when they modify values of customized options.
The customized options provided by the M2000 CM NBI apply only to data import. This is
because the business logic for configuration data import is complicated and changes of the
customized options might cause unexpected results.
7.2 Customized Data Export Options

Configuration File Containing Customized Data Export Options
The configuration file containing customized data export options is
$InstallPath$/etc/CmeServer/NBIExportPara.xml. $InstallPath$, whose default value is
/opt/oss/server, indicates the installation path of the M2000.
Following describes an example customized option:
<param name="MaxFileNumber">100</param>
where
The name attribute of the param element indicates the name of the option. The content of the
element is the value of the option. In the preceding example, a maximum of 100 files are
allowed in the directory for storing files exported over the M2000 CM NBI, and expired files
are automatically deleted.
The value of a customized option takes effect immediately after it is modified and saved.
Common Customized Options

Following describes common customized options:

iManager M2000-CME
 NENumberInOneFile: specifies the number of NEs allowed in one file when base
station controller data is exported. The value of this option is an integer.
 NBIEXPFileNameFmt: specifies the name format of exported compressed packages.
The value of this option is a character string.
 CompressFile: specifies whether files to be exported need to be compressed. The value
of this option is 0 or 1. 0 indicates that files do not need to be compressed and 1 indicates
that files need to be compressed. If users set the value of this option to 0, the M2000
directly export files instead of compressed packages to a specified directory.
 ZipArchiveMode: specifies the compression mode of exported files. This option is valid
only when CompressFile is set to 1. Union indicates that all exported files are
compressed as a ZIP file, Separate indicates that each exported file is compressed as a
ZIP file, and ByTech indicates that exported files for each RAT are compressed as a ZIP
file.
 FileDelByNum: specifies whether expired files are automatically deleted. The value of
this option is 0 or 1. 0 indicates that files are deleted based on a specified date and 1
indicates that files are deleted based on a specified threshold for allowed number of files.
 FileLifecycle: specifies the maximum number of days for reserving files and functions
only if FileDelByNum is set to 0. The value of this option is an integer.
 MaxFileNumber: specifies the maximum number of reserved files and functions only if
FileDelByNum is set to 1. The value of this option is an integer.
 BaseStationNumberInOneFile: specifies the number of NEs allowed in one file when
SRAN8.0 base station data is exported. The value of this option must be an integer.
 MaxEnodebNum: specifies the number of NEs allowed in one file when LTE NE data
with the version of SRAN7.0 and before is exported. The value of this option must be an
integer.
 G_UnionFileNameFormat: specifies the name format of exported GSM NE data files.
The value of this option is a character string. If $Version$ is included in the
configuration item, it will be replaced by 'Legacy' in the name of the exported files for
the NE before SRAN8.0 and the Legacy model of SRAN8.0 NE; While for the
SingleOM model of SRAN8.0 NE, it will be replaced by the value of neversion attribute
in the exported files.
 U_UnionFileNameFormat: specifies the name format of exported UMTS NE data files.
The value of this option is a character string. If $Version$ is included in the
configuration item, it will be replaced by 'Legacy' in the name of the exported files for
the NE before SRAN8.0 and the Legacy model of SRAN8.0 NE; While for the
SingleOM model of SRAN8.0 NE, it will be replaced by the value of neversion attribute
in the exported files.
 L_UnionFileNameFormat: specifies the name format of exported file for the LTE NE
before SRAN8.0 and the Legacy model of SRAN8.0 LTE NE. The value of this option is
a character string. If $Version$ is included in the configuration item, it will be replaced
by 'Legacy' in the name of the exported files.
 SRAN_UnionFileNameFormat: specifies the name format of exported SRAN8.0 base
station data files. The value of this option is a character string. If $Version$ is included
in the configuration item, it will be replaced by the value of neversion attribute in the
exported files.
 G_SingleFileNameFormat: specifies the name format of exported GSM NE data files
and functions only if NENumberInOneFile is set to 1. The value of this option is a
character string. If $Version$ is included in the configuration item, it will be replaced by
'Legacy' in the name of the exported files for the NE before SRAN8.0 and the Legacy
model of SRAN8.0 NE; While for the SingleOM model of SRAN8.0 NE, it will be
replaced by the value of neversion attribute in the exported files.

iManager M2000-CME
 U_SingleFileNameFormat: specifies the name format of exported UMTS NE data files

and functions only if NENumberInOneFile is set to 1. The value of this option is a
character string. If $Version$ is included in the configuration item, it will be replaced by
'Legacy' in the name of the exported files for the NE before SRAN8.0 and the Legacy
model of SRAN8.0 NE; While for the SingleOM model of SRAN8.0 NE, it will be
replaced by the value of neversion attribute in the exported files.
 LTE_SingleFileNameFormat: specifies the name format of exported file for the LTE
NE before SRAN8.0 and the Legacy model of SRAN8.0 LTE NE. It functions only if
MaxEnodebNum is set to 1. The value of this option is a character string. If
$Version$ is included in the configuration item, it will be replaced by 'Legacy' in the
name of the exported files.
 SRAN_SingleFileNameFormat: specifies the name format of exported SRAN8.0 base
station data files and functions only if BaseStationNumberInOneFile is set to 1. The
value of this option is a character string. If $Version$ is included in the configuration
item, it will be replaced by the value of neversion attribute in the exported files.
 TemplateExpSwith: specifies whether base station template information needs to be
imported. 0 indicates False and 1 indicates True.
7.3 Policy for Inheriting Customized Options During

Upgrade
The customized options provided by the M2000 CM NBI are important for the umbrella OSS.
Therefore, these options are automatically inherited when the M2000 is upgraded, and users
do not need to reset these options after the upgrade.

iManager M2000-CME
Northbound Interface Specification A Acronyms and Abbreviations
A Acronyms and Abbreviations
C
CM configuration management
CME Configuration Management Express
M
MOC managed object class
MOI managed object instance
N
NBI northbound interface
NMS network management system
NRM network resource model
O
OSS operations support system
R
RPT radio access network planning tool
T
TPT transmission network planning tool
X
XML Extensible Markup Language


IManager M2000 CME Northbound Interface

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IManager M2000 CME Northbound Interface

Uploaded by

Copyright:

Available Formats

iManager M2000-CME

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 03 (2013-11-21) Huawei Proprietary and Confidential i

About This Document

Issue 03 (2013-11-21) Huawei Proprietary and Confidential ii

About This Document .................................................................................................................... ii

3 Northbound File Interface for Data Import ........................................................................... 10

Issue 03 (2013-11-21) Huawei Proprietary and Confidential iii

4 Format of Northbound Data Files ............................................................................................ 20

5 Format of Report Files ................................................................................................................ 25

6 Other Technical Specifications ................................................................................................ 27

7 Customized Options for the NBI ............................................................................................. 34

A Acronyms and Abbreviations .................................................................................................. 37

Issue 03 (2013-11-21) Huawei Proprietary and Confidential iv

1 Introduction to M2000 CM NBI

Issue 03 (2013-11-21) Huawei Proprietary and Confidential 1

Figure 1-1 Schematic diagram of M2000 CM NBI

Issue 03 (2013-11-21) Huawei Proprietary and Confidential 2

2 Northbound File Interface for Data Export

2.1 Data Export Process

Figure 2-1 Process of exporting data over the M2000 CM NBI

File FTP Job

NodeB/BTS NodeB/BTS eNodeB eNodeB

Issue 03 (2013-11-21) Huawei Proprietary and Confidential 3

2.1.2 Exporting Data Through a Scheduled Task

 Users can create multiple tasks simultaneously as required.

2.1.3 Exporting Data Manually

Issue 03 (2013-11-21) Huawei Proprietary and Confidential 4

 Specify the directory on the client for saving exported reports.

2.2 Directories for Saving Exported Files

2.2.2 Directory on the M2000 Client

2.3 Rules for Compressing, Splitting, and Naming

2.3.2 Rules for Splitting Exported Files

Issue 03 (2013-11-21) Huawei Proprietary and Confidential 5

2.3.3 Rules for Naming Exported Files

Issue 03 (2013-11-21) Huawei Proprietary and Confidential 6

Rules for Naming Exported Files

Issue 03 (2013-11-21) Huawei Proprietary and Confidential 7

2.4 Deletion of Expired Exported Files

2.5 FTP Information for File Transfer

2.6 RAN Sharing Export

Issue 03 (2013-11-21) Huawei Proprietary and Confidential 8

Issue 03 (2013-11-21) Huawei Proprietary and Confidential 9

3 Northbound File Interface for Data Import

3.1 Data Import Process

Figure 3-1 Process of importing data over the M2000 CM NBI

The umbrella OSS

The M2000-CME imports

File FTP Job

Issue 03 (2013-11-21) Huawei Proprietary and Confidential 10

Users can perform the following steps to import data.

3.1.2 Importing Data

Import Workflow of Northbound interface

XML Import Export Script

The process includes the following phases.

Data Planning Phase

Data Transfer Phase

Issue 03 (2013-11-21) Huawei Proprietary and Confidential 11

Data Validation Phase

Data Activation Phase

3.1.3 Principles for Designing the M2000 CM NBI

Issue 03 (2013-11-21) Huawei Proprietary and Confidential 12