iManager U2000-CME Northbound Interface Scenario Description
(UMTS)
Issue01
Date2014-07-30
DOCPROPERTY Confidential
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:[email protected]
About This Document
KeywordsCM, northbound, XML, importAbstractThis 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.
Contents
iiAbout This Document
41 Introduction
52 Features
52.1 Network Resource Model
52.1.1 Managed Object Model
52.1.2 Parameter List
52.2 Radio Parameter Configuration Scenarios
62.2.1 Cell Creation
92.2.2 Cell Deletion
102.2.3 Cell Data Modification
112.2.4 Neighbor Relationship Adjustment
152.3 Transmission Parameter Configuration Scenarios
152.3.1 NodeB Creation
162.3.2 NodeB Deletion
162.3.3 Iub Interface Data Modification
17A Acronyms and Abbreviations
1 IntroductionThe 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.2 Features2.1 Network Resource
Model2.1.1 Managed Object ModelFor 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 ListConfiguration 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 ScenariosThis 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
CreationWhen 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 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.
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
UPRACHASC
UPRACHACTOASCMAP
UAICH
URACH
URACHDYNTFS
UCELLURA
UPCHDYNTFS
Cell TemplateA 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 InformationBefore 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.xmlCreating a CellThe CME
allows users to create a cell using either of the following
methods:
Creating a cell by using a cell template
Creating a logical cell on the RNC side:
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.xmlActivating a
CellOnly 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.
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 DeletionWhen 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 SideWhen 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 2-1 and Figure 2-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.
Following is an example file for deleting a logical cell on the
RNC side:
03_Sample_Delete_LogicalCELL.xml
2.2.3 Cell Data ModificationCell 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 parametersCommon ParameterCommon 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:
06_Sample_Update_CELLACINFO.xmlAssociated ParameterAssociated
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 ParameterModification 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 AdjustmentThis 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
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
AdjustmentExternal 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 cellsAn 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.
Following is an example file for configuring an external UMTS
cell:
01_Sample_Create_EXT3GCELL_And_NCELL.xml
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 AdjustmentA 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
intra-frequency 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.
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:
01_Sample_Create_EXT3GCELL_And_NCELL.xml
UMTS-GSM Neighbor Relationship AdjustmentA 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:
02_Sample_Create_EXT2GCELL_And_NCELL.xml
UMTS-LTE Neighbor Relationship AdjustmentA 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
2.3 Transmission Parameter Configuration Scenarios2.3.1 NodeB
CreationWhen 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.
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 DeletionWhen 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
2.3.3 Iub Interface Data ModificationOSS can directly modify the
Iub interface data, so the MODIUB scenario in previous version is
not supported since RAN16.0 any more.A Acronyms and
Abbreviations
B
BPUbaseband processing unit
C
CMconfiguration management
CMEConfiguration Management Express
L
LAlocation area
M
MOCmanaged object class
MOMmanaged object model
N
NBInorthbound interface
NRMnetwork resource model
O
OSSoperations support system
R
RFradio frequency
X
XMLExtensible Markup Language
_1425732548.vsd1.1 Delete all the NR of cell1 in RNC 1, contains
both outgoing and incoming NR, ie 1+2+3+4
1.2 Delete cell 1 in RNC1
Umbrella OSS
CME
1. Request to delete cell 1 in RNC1
()
2 Delete all the NR of cell1 in involved RNC and involved BSC,ie
5, 6,7,8
3 Delete all the cell1 in involved RNC and involved BSC,ie
NRNCCELL1 in RNC2 ,NRNCCELL1 in BSC1
_1426149345.vsd
!
UNODEB
UCELL
1
*
UINTERFREQNCELL
1
*
UEXT3GCELL
XOR
1
1
1
1
Abbreviation list: ULTECELL: External LTE Cell UEXT2GCELL:
External GSM Cell UEXT3GCELL: External UMTS Cell ULTENCELL: LTE
Neighboring Cell U2GNCELL: GSM Neighboring Cell
UINTRAFREQNCELL:Intra-frequency Neighboring Cell
UINTERFREQNCELL:Inter-frequency Neighboring Cell
ULTENCELL
ULTECELL
1
*
1
1
U2GNCELL
UEXT2GCELL
1
1
1
*
UINTRAFREQNCELL
XOR
1
1
1
*
_1425732547.vsdCELL1
CELL2
NRNC 2
CELL10
GSMCELL1
NRNCCELL10
GSMCELL1
2
3
4
RNC1
RNC2
BSC1
1
NRNC 1
5
7
NRNCCELL1
NRNCCELL1
CELL20
6
GSMCELL2
8
