IManager U2000-CME Northbound Interface Scenario Description (UMTS)

iManager U2000-CME
Northbound Interface Scenario

Description (UMTS)
Issue
01
Date
2014-01-20
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2014. 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 01 (2014-01-20)
Huawei Proprietary and Confidential

Copyright Huawei Technologies Co.,
Ltd.
iManager U2000-CME Northbound Interface Scenario Description

(UMTS)
About This Document
About This Document

Keywords
CM, northbound, XML, import
Abstract
This document describes the technical specifications of the configuration scenarios that the
U2000 CM NBI supports on a UMTS network. CM is short for configuration management
and NBI is short for northbound interface. It provides information about interface control and
serves as a reference for users to integrate and interconnect umbrella operations support
system (OSS) tools and Huawei's U2000 system.
Issue 01 (2014-01-20)

Ltd.
ii

(UMTS)
Contents
Contents
About This Document.......................................................................ii
1 Introduction.................................................................................4
2 Features....................................................................................... 5
2.1 Network Resource Model..................................................................................................................................5
2.1.1 Managed Object Model............................................................................................................................5
2.1.2 Parameter List...........................................................................................................................................5
2.2 Radio Parameter Configuration Scenarios.........................................................................................................5
2.2.1 Cell Creation.............................................................................................................................................6
2.2.2 Cell Deletion.............................................................................................................................................9
2.2.3 Cell Data Modification...........................................................................................................................10
2.2.4 Neighbor Relationship Adjustment.........................................................................................................11
2.3 Transmission Parameter Configuration Scenarios...........................................................................................15
2.3.1 NodeB Creation......................................................................................................................................15
2.3.2 NodeB Deletion......................................................................................................................................16
2.3.3 Iub Interface Data Modification.............................................................................................................16
A Acronyms and Abbreviations.......................................................17
Issue 01 (2014-01-20)

Ltd.
iii

(UMTS)
1 Introduction
Introduction
The U2000 CM NBI provides configuration management based on configuration scenarios.

This document describes how to configure radio and transmission parameters for a UMTS
network through the NBI in common configuration scenarios.
These configuration scenarios are achieved based on a network resource model (NRM). For
details, users can see the reference document listed in this document.
Issue 01 (2014-01-20)

Ltd.
Northbound Interface Scenario Description (UMTS)
A Acronyms and Abbreviations
Features
2.1 Network Resource Model

2.1.1 Managed Object Model
For details about the network resource model, users can see Northbound Interface MOM
Reference (MOM for short). The MOM document provides information, such as managed
object classes (MOCs), relationships, parameters, parameter value ranges, and business rules,
about the network resource model.
2.1.2 Parameter List

Configuration management depends on parameters. Therefore, parameters are key
information about the NRM. In addition to the MOM document, Excel files are provided to
describe the parameters that the NBI supports. These parameter list files contain only
information about MOCs and parameters. They do not contain any information about business
rules and the relationships between MOCs. They serve as subsets for defining managed object
models (MOMs).
The U2000 CM NBI also provides list files that conform to XML schema constraints and
contain parameter definitions. This enables applications to execute basic data check on XML
instance files transferred over the NBI based on XML schema files.
2.2 Radio Parameter Configuration Scenarios

This section describes how the U2000 CM NBI supports radio parameter configuration
scenarios. Configuration management of UMTS radio data is achieved based on cells, and
therefore common scenarios for configuring radio parameters include creating a cell, deleting
a cell, modifying a cell parameter, and adjusting a neighbor relationship.
For details about the NRM, users can see the MOM document described in section
2.1"Network Resource Model."
2.2.1 Cell Creation

When users create a cell, they need to configure a logical cell (UCELL) on the RNC side and
a local cell (ULOCELL) on the physical NodeB side accordingly. Configuration data used on
Issue 01 (2014-01-20)

Ltd.
the RNC side and that used on the NodeB side are delivered separately as XML files through
the NBI.
A logical cell (UCELL) contains information about a cell that users want to create and is
served by the current RNC. CELLID uniquely identifies a cell within a radio network system.
During the creation of a logical cell, subobjects, such as channels and algorithm parameters,
of the cell must be provided to support certain services. For example, if users want to create a
cell that supports HSDPA services, they must configure a subobject, UCELLHSDPA, for the
cell.
Issue 01 (2014-01-20)
Users can import data to create a cell and then configure neighbor relationships repeatedly until they
have created all desired cells. Alternatively, they can import data to create all desired cells and then
configure neighbor relationships at a time. For example, if users want to create U2GNCELL,
UINTERFREQNCELL, UINTRAFREQNCELL, and ULTENCELL, they can centrally configure
neighbor relationships through the NBI after they have created all desired cells and external cells.
The cell subobject list varies with NE versions. Users can obtain the latest cell subobject list from
the MOM document.
When users create a cell, they do not need to include all subobjects of the cell in imported files. This
is because subobjects for features that users do not want to use are not required. However, the
following subobjects must be provided so that users can properly activate the cell:
UCELLCAC
UCELLLDB
UCELLPUC
UCELLRLPWR
UCELLALGOSWITCH
UCELLACCESSSTRICT
UCELLSELRESEL
UCELLMEAS
UCHPWROFFSET
UCELLSIBSWITCH
UCELLRLACTTIME
UCELLOLC
UCELLLDM
UCELLLDR
UCELLHCS
UPSCH
USSCH
UPCCPCH
UPCPICH
UBCH
USCCPCH
USCCPCHTFCS
UPCH
UPICH
UFACH
UFACHDYNTFS
UPRACHBASIC
UPRACHTFC
UPRACHSLOTFORMAT

Ltd.
UPRACHASC
UPRACHACTOASCMAP
UAICH
URACH
URACHDYNTFS
UCELLURA
UPCHDYNTFS
Cell Template
A large number of associated MOCs and parameters are used when users create a cell. This
brings challenges to the umbrella OSS.
Such MOCs and parameters are divided into the following categories based on the data
similarities between cells:
Planned parameters (such as sector- and base-station-related parameters): Such

parameters vary with cells as planned.
Reusable parameters (such as channel-related parameters): On an actual network, such

parameters are usually the same for cells of the same batch, which is consistent with the
results of cell configuration data analysis. Cell configuration data can be divided into a
limited number of categories based on data similarities. Cells of the same type are
featured with similar configuration data.
Based on the preceding information, the U2000 CM NBI provides a fast copy and
modification function for users to rapidly create a cell using a cell template. Each cell
template represents a type of typical cell configuration data. When users import files to create
a logical cell through the NBI, they only need to provide the planned parameters of the cell
and the used cell template. Then, users can copy cell configuration data from the cell template
and modify the planned parameters based on files imported over the U2000 CM NBI. This
simplifies user operations for creating a cell through the umbrella OSS.
A series of default cell templates are provided along with the release of a Configuration
Management Express (CME) version. Users are not allowed to delete these templates.
However, they can create and delete customized cell templates as required. For details about
the management of customized templates, users can see CME Online Help.
Creating Location Area Information

Before users create a cell, they need to configure location area (LA) information, such as
ULAC, USAC, URAC, and UURA, for the cell. Users can directly use the LAC, SAC,
RAC, and URA parameters of UCELL as the LA information. ULAC is optional based on
actual services.
Following is an example file for creating LA information:
01_Sample_Create_LAC_SAC_RAC_URA.xml
Creating a Cell
The CME allows users to create a cell using either of the following methods:
Creating a cell by using a cell template
Issue 01 (2014-01-20)
Creating a logical cell on the RNC side:

Ltd.
If users create a logical cell using a cell template through the NBI, they only need to
include basic parameters of the cell in imported files, and the NBI then automatically
inherits all parameters in the template. This simplifies user operations for collecting
files that they want to import and improves work efficiency. Information about the
cell template is provided for the NBI through the CELLTEMPLATE (include
parameters CELLID and NAME) object.
Following is an example file for creating a logical cell by using a cell template:
01_Sample_Create_LogicalCELL_With_Template.xml
The URA information (UCELLURA) of the cell is not included in the cell template. Users need to
configure UCELLURA when they create the cell. This ensures that the cell can be properly activated.
Creating a local cell on the physical NodeB side:

In versions later than SRAN8.0, users can also use a cell template to create a local
cell on the NodeB side, which is similar to the creation of a logical cell. Each cell
template represents a type of typical cell configuration data. Following is an example
file for creating a local cell by using a cell template:
01_Sample_Create_LocalCELL_With_Template.xml
As shown in the preceding example, when creating a cell based on a template, users have to set
Operation for the cell to CreateCellWithTemplate, but do not have to set modifier for all subobjects
of the cell. The CME takes this as a creation scenario by default.
Information about the used cell template is provided to the NBI through the TEMPLATENAME
parameter of the ULOCELL object.
Creating a cell without using a cell template
Creating a logical cell on the RNC side:

If users create a cell without using a cell template, they need to include complete
information, such as channels and algorithm parameters, about the cell and its
subobjects in imported files. However, they do not need to include data about the
CELLTEMPLATE object. Users can obtain information about cell subobjects from
the MOM document.
To properly activate a new cell, users must include the minimum object set for the cell in imported files.
Following is an example file for creating a logical cell without using a cell template:
02_Sample_Create_LogicalCELL_Without_Template.xml
Creating a local cell on the physical NodeB side:

If users create a cell without using a local cell template, they need to include
complete information about the cell and its subobjects in imported files. However,
they do not need to set the TEMPLATENAME parameter for the ULOCELL object.
Following is an example file for creating a local cell without using a cell template:
02_Sample_Create_LocalCELL_Without_Template.xml
Activating a Cell
Only active cells can provide network access services. After users create a logical cell and a
local cell, they need activate the cell by properly setting the ACTSTATUS parameter of its
logical cell.
Issue 01 (2014-01-20)

Ltd.
Following are example files for activating and deactivating a cell, respectively:
03_Sample_ACT_CELL.xml
03_Sample_DEA_CELL.xml
2.2.2 Cell Deletion

When users delete a cell, they need to delete the logical cell on the RNC side and the local
cell on the physical NodeB side accordingly. Deletion of the logical cell does not trigger
automatic deletion of the data about the local cell. Similarly, deletion of the local cell does not
trigger automatic deletion of the data about the logical cell.
Deleting the Logical Cell on the RNC Side

When users delete a cell, all neighbor relationships, including neighbor relationships between
the cell and its external cells, related to the cell as maintained on the current RNC are
automatically deleted. However, external cells, such as UEXT3GCELL, UEXT2GCELL, and
ULTECELL, are not automatically deleted because they might be involved in neighbor
relationships with other cells. If users check that certain external cells are no longer used, they
need to delete data about the external cells through the umbrella OSS.
A prerequisite for users to delete external cells is that all neighbor relationships involving the external
cells have been deleted.
Figure 1.1 and Figure 1.2 show the process for users to handle neighbor relationships and
perform operations over the NBI when they delete data about CELL1 as maintained on
RNC1.
Figure 1.1
Issue 01 (2014-01-20)

Ltd.
Figure 1.2
Following is an example file for deleting a logical cell on the RNC side:
03_Sample_Delete_LogicalCELL.xml
2.2.3 Cell Data Modification

Cell data is divided into the following categories based on whether they can be modified
through the NBI and whether other objects need to be modified synchronously after they are
modified:
Common parameters
Associated parameters
Primary key or key parameters
Common Parameter
Common parameters exist only on cells instead of their external cells, and therefore
modification of common parameters affects only cells instead of their external cells. Most cell
parameters are common parameters.
Following is an example file for modifying a common parameter:
Issue 01 (2014-01-20)

Ltd.
10
06_Sample_Update_CELLACINFO.xml
Associated Parameter
Associated parameters exist on cells and their external cells. After users modify an associated
parameter of a cell, they must also modify the related parameters of the cell's external cells to
ensure data consistency.
For example, if users modify the PSCRAMBCODEC parameter of a cell, they must also
modify the related parameters of its external cells (UEXT3GCELL) served by other RNCs; if
they modify the LAC, SAC, or RAC parameter of a cell, they must also modify the related
parameters of its external cells (UEXT3GCELL) served by other RNCs. If users do not
modify parameters of external cells served by other RNCs synchronously after they modify a
parameter of a cell, data of the cell and that of the external cells becomes inconsistent.
Primary Key or Key Parameter

Modification of the CELLID primary key parameter of a cell affects the cell and all other
objects whose neighbor relationships involves the cell. Therefore, users are not allowed to
directly modify the CELLID of a cell unless they delete the cell and then create another cell
with a new CELLID value.
Modification of the UARFCN of a cell affects the local cell on the NodeB side, as well as
neighbor relationships maintained on the current RNC and other involved RNCs. For
example, after users modify the UARFCN of a cell, a previous intra-frequency neighbor
relationship (UINTRAFREQNCELL) becomes an inter-frequency neighbor relationship
(UINTERFREQNCELL). Likewise, an inter-frequency neighbor relationship might become
an intra-frequency neighbor relationship. Therefore, if users want to modify the uplink or
downlink UARFCN of a cell, they must first delete all neighbor relationships involving the
cell through the umbrella OSS, and then re-plan the neighbor relationships after the UARFCN
is modified. The U2000 CM NBI does not allow users to modify the UARFCN of a cell.
2.2.4 Neighbor Relationship Adjustment

This section describes how to adjust a neighbor relationship through the U2000 CM NBI.
Neighbor relationship adjustment is critical to radio network optimization and involves two
types of objects: external cells and neighbor relationships. An external cell is the proxy of a
cell, which is served by an NE other than the current RNC, on the current RNC.
Neighbor relationships are divided into the following categories:
Neighbor relationship (including intra- and inter-frequency UMTS-UMTS neighbor

relationships) between two UMTS cells
Neighbor relationship between a UMTS cell and its external GSM cell
Neighbor relationship between a UMTS cell and its external LTE cell
Issue 01 (2014-01-20)

Ltd.
11
Figure 1.1
Following describes external cells involved in neighbor relationship adjustment and the
methods for configuring different types of neighbor relationships:
External Cells Involved in Neighbor Relationship Adjustment

External cells on RNCs include external UMTS cells, external GSM cells, and external LTE
cells. After an associated parameter of a cell is modified on the cell's serving RNC, users must
modify the data of all involved external cells synchronously through the umbrella OSS to
ensure data consistency. A cell can be set as an external cell on multiple RNCs, and therefore
users must check that all involved data is properly modified.
After a cell or an external cell is deleted on an RNC, the U2000 automatically deletes all
involved neighbor relationships.
Following describes the three types of external cells:
External GSM cells

An external GSM cell is a GSM cell neighboring on the coverage edge of the current
RNC. UEXT2GCELL is an MOC used for managing external GSM cells.
GSMCELLINDEX uniquely identifies an external GSM cell within an RNC. A
quaternary consisting of MCC, MNC, CID, and LAC uniquely identifies a GSM cell on
a radio network. Therefore, the GSMCELLINDEX value of a GSM cell might vary on
different RNCs; however, its quaternary consisting of MCC, MNC, CID, and LAC must
be the same on all RNCs.
Following is an example file for configuring an external GSM cell:
02_Sample_Create_EXT2GCELL_And_NCELL.xml
External UMTS cells

An external UMTS cell is a UMTS cell served by a neighboring RNC of the current
RNC. UEXT3GCELL is an MOC used for managing external UMTS cells. The MOC of
a neighboring RNC is NRNC. Neighboring RNCs might belong to one or more telecom
operators. NRNCID and CELLID together uniquely identify an external UMTS cell.
Issue 01 (2014-01-20)

Ltd.
12
Following is an example file for configuring an external UMTS cell:

External LTE cells

An external LTE cell is an LTE cell neighboring on the coverage edge of the current
RNC. ULTECELL is an MOC used for managing external LTE cells.
LTECELLINDEX uniquely identifies an external LTE cell within an RNC. A ternary
consisting of MCC, MNC, and EUTRANCELLID uniquely identifies an LTE cell on a
radio network. Therefore, the LTECELLINDEX value of an LTE cell might vary on
different RNCs; however, its ternary consisting of MCC, MNC, and EUTRANCELLID
must be the same on all RNCs.
Following is an example file for configuring an external LTE cell:
03_Sample_Create_LTECELL_And_NCELL.xml
UMTS-UMTS Neighbor Relationship Adjustment

A UMTS-UMTS neighbor relationship exists between two UMTS cells (including a local cell
and a peer cell). The local cell must be one served by the current RNC and the peer cell can be
one served by the current RNC or be an external UMTS cell. Users must check that the local
and peer cells have been configured before they create a UMTS-UMTS neighbor relationship.
UMTS-UMTS neighbor relationships are divided into the following categories based on
whether the UARFCNs of the local and peer cells are the same:
Intra-frequency UMTS-UMTS neighbor relationships

An intra-frequency UMTS-UMTS neighbor relationship exists between two UMTS cells
featured with the same UARFCN. UINTRAFREQNCELL is an MOC used for managing
intra-frequency UMTS-UMTS neighbor relationships. Two cells involved in an intrafrequency UMTS-UMTS neighbor relationship can be served by the current RNC, or by
the current RNC and a neighboring RNC, respectively.
RNCID and CELLID together uniquely identify a cell. NCELLRNCID and
NCELLID together uniquely identify a destination cell.
Inter-frequency UMTS-UMTS neighbor relationships

The UINTERFREQNCEL object indicates an inter-frequency neighbor relationship
between two UMTS cells. Rules for configuring this object are similar to those for
configuring the UINTRAFREQNCELL object. The only difference lies in that the
UARFCNs of the two involved cells are different.
UMTS-UMTS neighbor relationships can also be divided into the following categories
based on whether the peer cell is served by the current RNC:
Intra-RNC UMTS-UMTS neighbor relationships

An intra-RNC UMTS-UMTS neighbor relationship exists between two cells (including a
local cell and a peer cell) served by the current RNC. From the perspective of
configuration data, the RNCID values of the two cells are the same. Users must check
that the local and peer cells have been configured before they create a UMTS-UMTS
neighbor relationship.
Users can set an intra-RNC UMTS-UMTS neighbor relationship as bidirectional, where
CELL1 is a neighboring cell of CELL2 and CELL2 is a neighboring cell of CELL1.
Alternatively, they can set the neighbor relationship as unidirectional, where CELL1 is a
neighboring cell of CELL2 but CELL2 is not a neighboring cell of CELL1.
Issue 01 (2014-01-20)

Ltd.
13
Inter-RNC UMTS-UMTS neighbor relationships

An inter-RNC UMTS-UMTS neighbor relationship exists between two cells (including a
local cell and a peer cell) served by different RNCs. From the perspective of
configuration data, the peer cell is an external UMTS cell and its RNCID value is
different from the RNCID value of the local cell.
Inter-RNC UMTS-UMTS neighbor relationships can only be unidirectional. If users
want to configure a neighbor relationship between a local cell and its external UMTS
cell, they must perform operations on the RNC serving the external UMTS cell.
Following is an example file for creating a neighbor relationship between a local cell and
its external UMTS cell:
UMTS-GSM Neighbor Relationship Adjustment

A UMTS-GSM neighbor relationship exists between a UMTS cell and its external GSM cell.
U2GNCELL is an MOC used for managing UMTS-GSM neighbor relationships. Users must
check that an external GSM cell (UEXT2GCELL) has been configured before they create a
UMTS-GSM neighbor relationship.
UMTS-GSM neighbor relationships can only be unidirectional. If users want to configure a
neighbor relationship between a UMTS cell and its external GSM cell, they need to perform
operations on the BSC serving the external GSM cell.
RNCID and CELLID together uniquely identify a source UMTS cell. GSMCELLINDEX
uniquely identifies an external GSM cell.
Following is an example file for configuring a UMTS-GSM neighbor relationship:
UMTS-LTE Neighbor Relationship Adjustment

A UMTS-LTE neighbor relationship exists between a UMTS cell and its external LTE cell.
ULTENCELL is an MOC used for managing UMTS-LTE neighbor relationships. Users must
check that an external LTE cell (ULTECELL) has been configured before they create a
UMTS-LTE neighbor relationship.
UMTS-LTE neighbor relationships can only be unidirectional. If users want to create a
neighbor relationship between a UMTS cell and its external LTE cell, they need to perform
operations on the eNodeB serving the external LTE cell.
RNCID and CELLID together uniquely identify a source UMTS cell. LTECELLINDEX
uniquely identifies an external LTE cell.
Following is an example file for configuring a UMTS-LTE neighbor relationship:
03_Sample_Create_LTECELL_And_NCELL.xml
Issue 01 (2014-01-20)

Ltd.
14
2.3 Transmission Parameter Configuration

Scenarios
2.3.1 NodeB Creation
When users create a NodeB, they need to create a logical NodeB on the base station controller
side and a physical NodeB on the NodeB side. In addition, users need to properly configure
Iub interface data on the base station controller and physical NodeB sides so that the physical
NodeB can operate properly.
Creation of a physical NodeB involves a large number of MOCs and parameters. These
parameters can be divided into three categories: device parameters, transmission parameters,
and radio parameters. The device layer houses a large number of hardware objects, such as
subrack, radio frequency (RF) unit, baseband processing unit (BPU), and fan. Devices vary
with vendors. Therefore, objects at the device layer vary with vendors, their configurations
are complicated, and their models change frequently. In addition, these objects are rarely
changed after they are created on NodeBs. Therefore, the U2000 CM NBI does not allow
users to configure device parameters through the umbrella OSS.
Based on the data similarities between NodeBs, transmission and radio parameters are divided
into the following categories:
Planned parameters, such as the IP address of each interface
Reusable parameters, such as sector and baseband configuration data
On an actual network, NodeB configuration data can be divided into a limited number of
categories, and NodeBs of the same type are featured with similar configuration data.
Based on the preceding information, the U2000 CM NBI provides a fast copy and
modification function for users to rapidly create a NodeB using a template. Each template
represents a type of typical NodeB configuration data. When users import files to create a
NodeB through the NBI, they only need to provide the planned parameters of the NodeB and
the used template. Then, users can copy NodeB configuration data from the template and
modify the planned parameters based on files imported over the U2000 CM NBI. This
simplifies user operations for creating a NodeB through the umbrella OSS.
Configuration of device parameters and that of transmission parameters are closely related,
whereas configuration of radio parameters is decoupled from that of device and transmission
parameters. In addition, radio parameters and device and transmission parameters are usually
planned and configured by engineers from different departments through different umbrella
OSS tools. Therefore, the U2000 CM NBI divides the templates used for NodeB creation into
the following categories:
Site templatesTEMPLATENAME in the MOC NODE: contain reusable device and

transmission parameters.
Radio templatesTEMPLATENAME in the NODEBFUNCTION: contain reusable

radio parameters.
The U2000 CM NBI allows users to create a NodeB only by using a template. When users
attempt to create a NodeB, they must specify NodeB and radio templates in imported files
through the umbrella OSS.
Issue 01 (2014-01-20)

Ltd.
15
The CME provides a template management function for users to manage NodeB and radio
templates. For details, users can see the CME product documentation.
When users create a NodeB, they must include transmission parameters and related radio
parameters in one XML file. They can include neighbor relationship configuration data in the
same XML file or in a separate XML file.
Following are example files for creating various types of logic NodeBs:
01-Sample_Create_ATM_IMAGRP.xml
02-Sample_Create_ATM_OPT.xml
03-Sample_Create_ATM_ATMLOGICPORT.xml
04-Sample_Create_IP_ETH.xml
05-Sample_Create_IP_IPLOGICPORT.xml
06-Sample_Create_DUAL_OPT_ETH.xml
Following is an example file for creating one physical NodeB.
01-Sample_Create_NODEB.xml
Creation of a physical NodeB through the NBI is complicated because it involves file validity
check, NodeB business rules check, NodeB data integrity check, and the generation of NodeB
configuration data files. To avoid long waiting, users are advised to include data of less than
50 NodeBs in one XML file.
Two fields related to the NE name are involved in example files for creating a NodeB: neid in
the NE and NODEBFUNCTIONNAME in the NODEBFUNCTION. Users are advised to
keep values of these two fields consistent. If they are inconsistent, the NBI uses neid. After a
NodeB is created successfully, the name displayed in the general view is the value of neid.
As shown in the preceding example, when creating a NodeB based on a template, users have
to set Operation for the NodeB to CreateSite, but do not have to set modifier for all
subobjects of the NodeB. The CME takes this as a creation scenario by default.
productversion is the version of a base station, it should be set when creating a base
station. And the parameter NENAME in MOC NE, PRODUCTTYPE in MOC NODE should
be set when creating a base station.
2.3.2 NodeB Deletion

When users delete a NodeB, they only need to delete the logical NodeB on the RNC side.
Users can include only the correct name of a NodeB that they want to delete in an XML file,
and then the NBI automatically deletes the NodeB, the cells served by the NodeB, and the
neighbor relationships maintained on the NodeB synchronously after the XML file is
imported and takes effect.
Following is an example file for deleting a NodeB:
01_Sample_Delete_ATM_IMAGRP.xml
Issue 01 (2014-01-20)

Ltd.
16
2.3.3 Iub Interface Data Modification

OSS can directly modify the Iub interface data, so the MODIUB scenario in previous
version is not supported since RAN16.0 any more.
Acronyms and Abbreviations
B
BPU
baseband processing unit
C
CM
configuration management
CME
Configuration Management Express
L
LA
location area
M
MOC
managed object class
MOM
managed object model
N
NBI
northbound interface
NRM
network resource model
O
OSS
Issue 01 (2014-01-20)
operations support system

Ltd.
17
R
RF
radio frequency
X
XML
Issue 01 (2014-01-20)
Extensible Markup Language

Ltd.
18

IManager U2000-CME Northbound Interface Scenario Description (UMTS)

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

IManager U2000-CME Northbound Interface Scenario Description (UMTS)

Caricato da

Copyright:

Formati disponibili

iManager U2000-CME

Northbound Interface Scenario

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2014. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

Huawei Proprietary and Confidential