09661MAAAe11 PDF

All rights reserved.
Passing on and copying of this

document, use and communication of its contents
not permitted without written authorization from Alcatel.
9153 OMC-R Configuration Import/Export Interface

(Release B11 MR1ed2 onwards)
9153 OMC-R Configuration Import/Export interface

ED
11
RELEASED
9661m11re.doc
17/03/2010
3BK 09661 MAAA PBZZA
1/1
All rights reserved. Passing on and copying of this

SYSTEM FUNCTIONAL BLOCKS
TABLE OF CONTENTS
1.
INTRODUCTION...............................................................................................6
1.1
Scope of the document .........................................................................6
1.2
Overview of the ACIE interface.............................................................6
1.2.1
Presentation ..................................................................................6
1.2.2
The supported services .................................................................7
1.3
Conventions and notations.................................................................10
2.
THE FILES CONCERNED BY THE ACIE INTERFACE.................................12

2.1
The 9153 OMC-R Configuration File Repository (ACFR) ..................12
2.2
The 9153 OMC-R External Interfaces General repository (AEIGR)..14
2.3
The different types of ACIE files.........................................................15
2.4
Formats of the ACIE files ....................................................................15
2.5
Names of the ACIE files.......................................................................16
2.6
Structure of the ACIE files ..................................................................16
2.6.1
General description .....................................................................16
2.6.2
The header of an ACIE MOC file.................................................17
2.6.3
The sub-header of an ACIE MOC file..........................................18
2.6.4
The body of an ACIE MOC file ....................................................19
2.6.4.1
2.6.4.2
2.6.4.3
3.
3.1
CONCERNED 9153 OMC-R MOCS ...............................................................23

Concerned Network Level MOCs .......................................................23
3.1.1
Description...................................................................................23
3.1.2
Corresponding Naming Tree .......................................................24
3.1.3
Corresponding Network Level Id types ........................................25
3.1.3.1
3.1.3.2
3.2
3.2.1
3.2.2
3.2.3
Description......................................................................................................25
Corresponding ASN1 type definitions............................................................27
Concerned BSC-NE Level MOCs........................................................28

Description...................................................................................28
3.2.3.1
3.2.3.2
3.3
The different types of lines contained in the body .........................................19

Structure of MOI-related lines ........................................................................19
Representation of values in MOI-related lines ...............................................20
Description......................................................................................................32
Concerned MFS-NE Level MOCs........................................................32

3.3.1
Description...................................................................................32
3.3.2
3.3.3
3.3.3.1
3.3.3.2
Description......................................................................................................34

ED
11
RELEASED
9661m11re.doc
17/03/2010
1/66

4.
IMPORT/EXPORT MECHANISMS .................................................................36

4.1
Import mechanism...............................................................................36
4.2
Export mechanism...............................................................................48
4.2.1
General export mechanism .........................................................48
4.2.1.1
4.2.1.2
4.2.2
4.2.3
Peculiarities for an export triggered by an 9153 OMC-R operator52

Peculiarities for export sessions triggered by scripts ...................53
4.2.3.1
4.2.3.2
4.2.3.3
4.2.4
4.2.5
5.
Unitary export session ....................................................................................48

File Transfer Achieved function.....................................................................51
Introduction.....................................................................................................53
run_UnitaryExportSession.pl..........................................................................53
run_FileTransferAchieved.pl..........................................................................54
Peculiarities for exports that are automatically triggered .............55

Peculiarities for an export triggered by a NMC ............................55
THE ACIE FILTERING FACILITY...................................................................59

INTRODUCTION ...................................................................................59
The ACIE Filter files .............................................................................59
5.2.1
Names of the ACIE Filter files .....................................................59
5.2.2
Structure of the ACIE Filter files ..................................................59
5.3
The ACIE post-processing (APP) files ...............................................60
5.3.1
Names of the APP files................................................................60
5.1
5.2
5.3.1.1
5.3.1.2
5.3.2
Structure of the APP files ............................................................61

5.3.2.1
5.3.2.2
5.4
6.
11
04
03
02
01
ED
Names of the unitary APP files.......................................................................60

Names of the global APP files ........................................................................61
Structure of the unitary APP files ...................................................................61
Structure of the global APP files ....................................................................61
The ACIE filtering mechanism (apply_ACIEFilter.pl) ........................62

ACRONYMS ...................................................................................................66
100317
091023
090330
080229
080215
DATE
Update
Update
Update
Update
First issue
CHANGE NOTE
O&M System
O&M System
O&M System
O&M System
O&M System
APPRAISAL AUTHORITY
TD/MRC/OMD Spec
TD/MRC/OMD Spec
TD/MRC/OMD Spec
TD/MRC/OMD Spec
TD/MRC/OMD Spec
ORIGINATOR

ED
11
RELEASED
9661m11re.doc
17/03/2010
2/66

LIST OF FIGURES AND TABLES

Figure 1: The 9153 OMC-R Configuration Import/Export (ACIE) Interface ........................... 7
Figure 2: The different Levels for the 9153 OMC-R configuration data ................................. 8
Figure 3: Organisation of the ACFR for <ieCredit> equal to c............................................. 14
Figure 4: Naming Tree for the concerned Network Level MOCs......................................... 25
Figure 5: Naming Tree for the concerned BSC-NE Level MOCs ........................................ 31
Figure 6: Naming Tree for the concerned MFS-NE Level MOCs ........................................ 34
Table 1: Set of characters allowed in productions, names and labels ................................. 11
Table 2: Character translation rule...................................................................................... 11
Table 3: Representation of values in ACIE MOC files......................................................... 22
Table 4: Description of the concerned Network Level MOCs .............................................. 24
Table 5: Network Level Id types for the Network Level MOCs ............................................ 27
Table 6: Description of the concerned BSC-NE Level MOCs.............................................. 30
Table 7: Network Level Id types for the BSC-NE Level MOCs............................................ 32
Table 8: Description of the concerned MFS-NE Level MOCs ............................................. 34
Table 9: Network Level Id types for the MFS-NE Level MOCs............................................ 35
HISTORY
Ed. 01
21/10/2007: Creation from 3BK 09661 LAAA PBZZA Ed.01 Released
B10 is replaced by B11
The REFERENCED DOCUMENTS and RELATED DOCUMENT parts are updated

for B11 together with the corresponding references in the body of the document.
A1353 RA is replaced by 9153 OMC-R.
15/02/2008: No technical changes.

Ed. 02
18/02/2008:
The document is updated following the new capability to export alcatelIpPeer

MOIs. This implies to export also alcatelIPCoordinator MOIs (parent MOIs for
alcatelIpPeer MOIs).
The changes implied by the new capability to export alcatelTcRackManager MOIs

and rnlAlcatelTcRackManager MOIs.

Ed. 03
20/02/2009:
The changes implied by the new capability to export aGprsFabric MOIs.
The document is updated following the new capability to export circuitPack MOIs.
This implies to export also equipmentHolder MOIs (parent MOIs for circuitPack
MOIs).
The changes implied by the new capability to export crossConnection MOIs.
13/03/2009:
The changes implied by the new capability to export aGprsIpSigLink MOIs.

Ed. 04
08/10/2009:
ED
11
RELEASED
9661m11re.doc
17/03/2010
3/66

CBML:rat3g parameter is added to the list of the parameters to be checked at

creation of the "NML":externalOmc3gCell MOIs.
Ed. 11
21/12/2009:
The aGprsIpSigLink MOIs definition is updated.
The changes implied by the new capability to export adjacency2gToLte MOIs.
The changes implied by the new capability to export externalOmcLteCell MOIs.
REFERENCED DOCUMENTS
Standards
[ISO/IEC 8859-1]
Information technology - 8-bit single-byte coded graphic character sets

Part 1: Latin alphabet No.1
ISO/IEC 8859-1, April 1998
[ASN1]
Information Processing Systems - Open Systems Interconnection Specification of Abstract Syntax Notation One (ASN.1)
CCITT Rec. X.208 (1988) | ISO/IEC 8824 (1990)
[ISO/IEC 9899]
Programming languages - C
Recommendation ISO/IEC 9899, 1990
[GDMO]
Information Technology - Open Systems Interconnection- Structure of

Management Information:
Guidelines for the Definition of Management Information
CCITT Recommendation X.722 (ISO/IEC 10165-4), 1992
[X.721]
Information Technology - Open Systems Interconnection Structure of

Management Information - Part 2: Definition of Management
Information
CCITT Recommendation X.721 (ISO/IEC 10165-2); 1991
with the technical corrigendum 1, 1994
[M.3100]
Maintenance: Telecommunications Management Network - Generic

Network Information Model;
CCITT Recommendation M.3100, July 1995
[Q.751.1]
Specifications of signalling system No. 7 Network Element Management Information Model for the Message
Transfer Part (MTP)
ITU-T Recommendation Q.751.1, October 1995
[GSM 12.00]
Digital cellular telecommunications system (Phase 2);

Network Management (NM);
Part 1: Objectives and structure of Network Management
GSM 12.00 version 4.5.1, ETS 300 612-1, August 1996
[GSM 12.20]
Digital cellular telecommunications system (Phase 2);

ED
11
RELEASED
9661m11re.doc
17/03/2010
4/66

Base Station System (BSS) Management Information

GSM 12.20 version 4.2.1, ETS 300 622, June 1996
Alcatel documents
[ANOIprofile]
Profile for the NMC/A1353 RA Q3 Interface

3BK 09654 LAAA PBZZA
[ANOIgdmo]
NMC/A1353-RA Q3 Interface Information Model: GDMO Formal

Specification
[ANOIcs-gene]
NMC/A1353-RA Q3 Interface: Overview and Conformance Statements

[ACIE-si]
9153 OMC-R Configuration Import/Export Interface: Supplementary

Information
For Release B11
[ACIE-siex]
9153 OMC-R Configuration Import/Export Interface: Informal excerpts

of [ACIE-si]
For Release B11
9153 OMC-R Configuration Import/Export Interface: Informal
excerpts of 3BK 09773 MAAA PBZZA
[ACIE-map]
9153 OMC-R Configuration Import/Export Interface: Mapping to BSS

Telecom/O&M Parameters and to HMI names
For Release B11
RELATED DOCUMENTS
[ANOIappli]
NMC/A1353-RA Q3 Interface: Position with respect to standards of the

GDMO Formal Specification

ED
11
RELEASED
9661m11re.doc
17/03/2010
5/66

1. INTRODUCTION
1.1 Scope of the document
The 9153 OMC-R has several interfaces allowing external applications to access easily to
its internal data, among which:
A Q3 interface, namely the NMC/9153 OMC-R Q3 Interface

This Q3 interface is presented in [ANOIprofile] and is fully specified in [ANOIgdmo] and
[ANOIcs-gene].
Several interfaces based on ASCII files

These interfaces are distinguished according to the domain they are concerned with.
One of these interfaces concern the Configuration Management domain. This interface
is called the 9153 OMC-R Configuration Import/Export (ACIE) interface.
Typical applications that can be interested are:
Radio Network Level Configuration data:

Radio network planning, optimisation and tuning tools (e.g. A9159-NPO, A9155RNP)
BSS-NE Level Configuration data:

Tools for network inventory or equipment provisioning.
This document specifies the issues that are not release-dependent for the 9153 OMC-R
Configuration Import/Export (ACIE) interface with a special emphasis on the relationships
with the NMC/9153 OMC-R Q3 Interface.
The issues that are release-dependent are specified in the following documents associated
with a given 9153 OMC-R Release:
Reference
Contents
[ACIE-si]
Supplementary Information for a given 9153 OMC-R release
[ACIE-siex]
Informal excerpts of [ACIE-si]
[ACIE-map]
Mapping to BSS Telecom/O&M Parameters and to HMI

names
The way files are transferred is out of the scope of this document together with issues
pertaining to the 9153 OMC-R security or installation.
1.2 Overview of the ACIE interface

1.2.1 Presentation
The 9153 OMC-R Configuration Import/Export (ACIE) interface is an interface between:
the 9153 OMC-R Configuration databases (ACDB) which store the 9153 OMC-R
Configuration data
and the 9153 OMC-R Configuration File Repository (ACFR).

This interface enables to:
perform an import session, i.e. import a set of ASCII files from the ACFR to the ACDB;
ED
11
RELEASED
9661m11re.doc
17/03/2010
6/66

perform an export session, i.e. export a set of ASCII files from the ACDB to the ACFR.
These files are called ACIE files in what follows.
This can be sketched out as follows:
9153 OMC-R Configuration Databases
(ACDB)
9153 OMC-R Configuration File Repository

(ACFR)
Import
Export
9153 OMC-R configuration
ACIE files (ASCII)
data
Figure 1: The 9153 OMC-R Configuration Import/Export (ACIE) Interface
1.2.2 The supported services

The 9153 OMC-R configuration data that can be imported/exported are split up into the
following levels, in accordance with TMN principles:
Radio Network Level (associated acronym: RNL)

This corresponds to the Radio Configuration data at (sub-)network level
Core BSS-NE level (also called BSC-NE level, associated acronym: BL)
This corresponds to the Equipment, Transmission and Software configuration data for
a given core BSS-NE (also called BSC-NE).
GPRS BSS-NE level (also called MFS-NE level, associated acronym ML)
This corresponds to the Equipment and Transmission configuration data for a given
GPRS BSS-NE (also called MFS-NE). Actually, the data at this level are restricted to
the configuration data relating to the GB interface. GPRS Radio configuration data are
already addressed by the Radio Network level.
These levels can be sketched out as follows:

ED
11
RELEASED
9661m11re.doc
17/03/2010
7/66

Radio Network Level (RNL)
MFS-NE Level (ML)
BSC-NE Level (BL)
Figure 2: The different Levels for the 9153 OMC-R configuration data
These levels are handled separately.
More precisely:
The 9153 OMC-R (externally accessible) configuration data at Network Level can be
imported, partially or completely
exported for a whole domain.

For a 9153 OMC-R operator, this domain can be:
either the Supervised Configuration (SC)

N.B.:
The SC is the representation of the network in its present state (i.e. it
is the active domain). Modifications performed on the SC are
immediately applied on the fields.
or a Provisioning Radio Configuration (PRC).

N.B.:
A PRC is a workspace built by a 9153 OMC-R operator from a copy
of all or part of the SC. It allows to prepare changes on the radio
configuration in advance, check them and activate them as a whole.
The activation mechanism is either global (Massive Logical Update MLU- Mode) or atomic (Message Mode).
It is possible to create several PRCs concurrently.
For example, a 9153 OMC-R operator can perform a partial export by creating a
PRC with a part of the SC and export this PRC.
For a NMC, this domain can only be the SC.
The 9153 OMC-R (externally accessible) configuration data at BSC-NE Level can only
be exported for a whole BSC-NE.
The 9153 OMC-R (externally accessible) configuration data at MFS-NE Level can only
be exported for a whole MFS-NE.
In addition,
An import session can be requested only by a 9153 OMC-R operator.
An export session can be requested either by a 9153 OMC-R operator or by a NMC

(via the NMC/9153 OMC-R Q3 Interface) or via a dedicated script.
ED
11
RELEASED
9661m11re.doc
17/03/2010
8/66

A full export session (for the SC, for each of the existing BSC-NE and for each of the
existing MFS-NE) is also triggered automatically by the 9153 OMC-R every day at a
time that is defined at the installation of a 9153 OMC-R instance.
A Radio Network Level import/export session can be triggered using one of the following
modes for uniquely identifying own/external cells at network level (called ACIE Cell
Identification modes in what follows):
The Application-Relative Cell Identity mode (ARCI mode for short)

In this case, the cells are named by identifying the cell depending on the application
that has created it.
More precisely, this is performed using a NetworkCellID value. This value is built from:
An ApplicationID value which characterises uniquely the application (e.g. an 9153

OMC-R instance) that has created the corresponding cell;
A cell reference which identifies uniquely a cell within those that have been created
by the same application.
The CellGlobalIdentity mode (CGI mode for short)

In this case, the cells are named by identifying the cell depending on the location area
associated with it within a GSM PLMN.
More precisely, for a 2g cell this is performed using a CellGlobalIdentity value. This
value is built from:
A LocationAreaIdentity value which identifies uniquely a Location Area within a

GSM PLMN through its Mobile Country Code (MCC), Mobile Network Code (MNC)
and Location Area Code (LAC);
A Cell Identity (CI) which identifies uniquely a cell within a location area.
For a 3g cell this is performed using a Global3gCellIdentity value. This value is built
from:
Mobile Country Code (mcc3g);
Mobile Network Code (mnc3g);
Local3gCellIdentity which identifies uniquely a 3g cell in a PLMN.

For a Lte cell this is performed using a eGlobalLteCellIdentity value. This value is built
from:
Mobile Country Code (mccLte);
Mobile Network Code (mncLte);
LteCellIdentity which identifies uniquely a Lte cell.

This ACIE Cell Identification mode applies to any MOI representing a (own or external) cell
and whichever context of use, including as parent of another MOI or when referred to by or
within an attribute (see [ACIE-si] for more information on the concerned attributes).
The following restrictions apply:
The CGI mode is supported neither for a Radio Network Level export session
requested by a NMC, not for the automatic export session.
In CGI mode, it is not possible to modify the value of the "GSM

12.20":cellGlobalIdentity attribute both for "NML":cell MOIs and "NML":externalOmcCell
MOIs.
In CGI mode, it is not possible to modify the value of the "C9ML":global3gCellIdentity

attribute for "NML":externalOmc3gCell MOI.
In CGI mode, it is not possible to modify the value of the "CBML":eGlobalLteCellIdentity

attribute for "NML":externalOmcLteCell MOI.
Finally, the contents of a set of ASCII files produced as output of one ACIE export session
can be filtered according to a file supplied by a given external application according to the
ED
11
RELEASED
9661m11re.doc
17/03/2010
9/66

latter's actual needs. For the BSC-NE level, this facility is also supported for a set of ACIE
export sessions corresponding to all the existing BSC-NEs. For the MFS-NE level, this
facility is also supported for a set of ACIE export sessions corresponding to all the existing
MFS-NEs.
1.3 Conventions and notations

To specify the form taken by a number of items (names, parts of ACIE files, etc..), the
following conventions are used:
Item
Meaning
CR
carriage return
[09]
represents any digit from 0 to 9
[AZ]
represents any character value from A to Z
[09AF]
represents any character value from 0 to 9
or A to F
<productionName>
references a part (called a production)
whose semantics and syntax are described
separately
<n>
represents any integer value
<ieCredit>
is an integer value (possibly equal to 1)
defined at the installation of a 9153 OMC-R
instance which represents the maximum
number of sessions of the same kind that
are allowed.
<maxDisplayedErrors>
is an integer value defined at the installation
of a 9153 OMC-R instance which represents
the maximum number of errors that will be
displayed.
<form1> | <form2>
indicates that the form can be either the one
referenced by <form1> (exclusive) or the
one referenced by <form2> where <form1>
and <form2> denote either production
names or particular constant parts.
[...]
delimits a part that may either be absent or
present only once.
{...}*
delimits a part that may be present zero or
more times.
+
{...}
delimits a part that may be present once or
more times.
In addition,
For the names and character strings mentioned below (to value a so-called production)
The set of characters allowed are those whose [ISO/IEC 8859-1] code lies in the
following intervals:
Hexa Codes
Characters
20
(SPACE)
2D
30 to 39
[0-9]
ED
11
RELEASED
9661m11re.doc
17/03/2010
10/66

Hexa Codes
Characters
41 to 5A
[A-Z]
5F
61 to 7A
[a-z]
C0 to FC
Table 1: Set of characters allowed in productions, names and labels
They contain at most 255 characters

For the value of an attribute that contains a character string:
If this attribute represents a name or a label, the aforementioned limitation on the

set of characters allowed shall be met.
Otherwise, a character that is not in this set shall be represented according to the
following rule, referred to as the 'character translation rule' in what follows
Character
Represented as
Character in the aforementioned set
The same character
\\
Character not in the aforementioned \<asciiCode>

set and different from \
where <asciiCode> denotes
[ISO/IEC 8859-1] code of
character
the
the
Table 2: Character translation rule
The following notations are used:
The GDMO notation defined in [GDMO]

N.B.:
The labels used hereafter are not always the same as those used within
the 9153 OMC-R. The underlying intention is for this document to be
directly understandable, especially for readers familiar with the
NMC/9153 OMC-R Q3 interface.
The ASN1 notation defined in [ASN1].

In tables and figures:
Dark grey (patterned or not) is used to indicate that the corresponding feature is
not supported or not concerned.
indicates that the corresponding feature is supported.

ED
11
RELEASED
9661m11re.doc
17/03/2010
11/66

2. THE FILES CONCERNED BY THE ACIE INTERFACE

2.1 The 9153 OMC-R Configuration File Repository (ACFR)
The 9153 OMC-R has a File Repository dedicated to file transfers from/to external clients,
called the 9153 OMC-R File Transfer Repository (AFTR). The information required to
reach this general file repository is predefined at the installation of a 9153 OMC-R instance.
The 9153 OMC-R Configuration File Repository (ACFR) actually corresponds to a directory
of that repository. Its name is ACIE.
The access to ACFR is allowed for the 9153 OMC-R operators or external applications
having the configuration functional profile. In particular, it is always allowed for NMCs which
are assumed to have both the supervision and configuration functional profiles.
The authentification requirements are the same as for the 9153 OMC-R File Transfer
Repository; these requirements are predefined at the installation of a 9153 OMC-R
instance.
ACIE import directories:

The ACFR has <ieCredit> (sub-)directories dedicated to ACIE (Network Level) import
sessions, called the ACIE Network Level import directories.
These directories are named
ACIE_NLimport_Dir.
where is an integer whose value is between 1 to <ieCredit> included.
They are created at the installation of a 9153 OMC-R instance.
A peer entity (e.g. a NMC) is allowed to
list the contents of an import directory
transfer files to an import directory

When a file is transferred which has the same name as an existing file, the latter is
replaced.
On the other hand, a peer entity shall not directly delete or modify files in this directory.
ACIE export directories:
The ACFR has <ieCredit> (sub-)directories dedicated to ACIE Network Level

export sessions, called the ACIE Network Level export directories.
These directories are named
ACIE_NLexport_Dir.
where is an integer whose value is between 1 to <ieCredit> included.
They are created at the installation of a 9153 OMC-R instance.
There is one directory dedicated to ACIE BSC-NE Level export sessions, called
the ACIE BSC-NE Level export directory.
This directory is named ACIE_BLexport and is created at the installation of a
9153 OMC-R instance.
For each BSC-NE, this directory has <ieCredit> (sub-)directories called the ACIE
export directories for that BSC-NE. These directories have a name of the form
ACIE_BSS<MECId>export_Dir

ED
11
RELEASED
9661m11re.doc
17/03/2010
12/66

where
<MECId>
is
an
integer
equal
to
the
value
of
the
M.3100:managedElementComplexId
of
the
corresponding
EML:alcatelManagedElementComplex object instance.
All the ACIE export directories for a given BSC-NE are created when that BSC-NE
is created.
There is one directory dedicated to ACIE MFS-NE Level export sessions, called
the ACIE MFS-NE Level export directory.
This directory is named ACIE_MLexport and is created at the installation of a
For each MFS-NE, this directory has <ieCredit> (sub-)directories called the ACIE
export directories for that MFS-NE. These directories have a name of the form
ACIE_MFS<NEId>export_Dir
where <NEId> is an integer equal to the value of the NMD:networkElementId of
the corresponding NMD:networkEelement object instance.
All the ACIE export directories for a given MFS-NE are created when that MFS-NE
is created.
A peer entity (e.g. a NMC) is allowed to
list the contents of an export directory;
transfer files from an export directory

but not to add, delete or modify files in such a directory.
Only the 9153 OMC-R (i.e. not a peer entity) is allowed to create or delete a directory of the
ACFR.
This organisation can be pictured as follows for <ieCredit> equal to c:

ED
11
RELEASED
9661m11re.doc
17/03/2010
13/66
ACIE
ACIE_NLimport_Dir1

ACIE_NLimport_Diri
ACIE_NLimport_Dirc
ACIE_NLexport_Dir1
ACIE_NLexport_Diri
ACIE_NLexport_Dirc
ACIE_BLexport
ACIE_BSS1export_Dir1
ACIE_BSS1export_Diri
ACIE_BSS1export_Dirc
ACIE_BSSnexport_Dir1
ACIE_BSSnexport_Diri
ACIE_BSSnexport_Dirc
ACIE_MLexport
ACIE_MFS1export_Dir1
ACIE_MFS1export_Diri
ACIE_MFS1export_Dirc
ACIE_MFSnexport_Dir1
ACIE_MFSnexport_Diri
ACIE_MFSnexport_Dirc
Figure 3: Organisation of the ACFR for <ieCredit> equal to c

For a given 9153 OMC-R instance on which several clients or applications are likely to
trigger import and/or export sessions, it is recommended to have a clear policy with
respect to the allocation of sub-directory numbers that can be used by a given type of
client or application.
2.2 The 9153 OMC-R External Interfaces General repository

(AEIGR)
The 9153 OMC-R has a repository dedicated to files relating to the 9153 OMC-R external
interfaces and supplied by or for external applications. This repository is called the 9153
OMC-R External Interfaces general repository (AEIGR). The information required to
reach this general repository is predefined at the installation of a 9153 OMC-R instance.
This repository has at least one sub-directory dedicated to scripts associated with the 9153
OMC-R external interfaces that are made available by the 9153 OMC-R to external
applications.
ED
11
RELEASED
9661m11re.doc
17/03/2010
14/66

This (sub-)directory, called the 9153 OMC-R External Interfaces Script (AEIS) directory,
is named 'script'. The access rights of this directory and the script files it contains are such
that an external application can execute each of these scripts but not read nor modify them.
Depending on the 9153 OMC-R instance, there may or not be another sub-directory, called
the 9153 OMC-R External Interfaces Application (AEIA) public repository, named
'public' that can be used by any external application to store files used as input to the
aforementioned scripts or produced by the latter. The access rights of this repository are
such that any external application can freely use it.
2.3 The different types of ACIE files

The 9153 OMC-R Configuration File Repository contains so-called ACIE files.
An ACIE file can be associated:
either with a given Managed Object Class

These files are referred to as the ACIE MOC files.
These files have the same format, name and structure for import sessions and for
export sessions. This makes it possible to take advantage of an export file to produce a
corresponding import file.
or with (an) import or export session(s)

There are several such files:
Files intended to help a 9153 OMC-R operator to perform an import session.

These files are referred to as the ACIE help files. These files are not processed
by the 9153 OMC-R, they are only intended for human readers.
Files intended to prevent concurrent import/export sessions. These files are

referred to as the ACIE lock files.
Files intended to prevent an export session to be triggered on a directory in case a

previous export session has been triggered indicating this directory as input but
the corresponding produced ACIE MOC files have not yet been transferred. These
files are referred to as the ACIE done files.
2.4 Formats of the ACIE files

The format used for an ACIE MOC file is the (so-called) Comma Separated Value (CSV)
format that consists in several lines separated by CR, each line being of the form:
<linePart>[;<linePart>];
where <linePart> contains only characters different from ; and CR.
For example,
aaaaaaaaaa;bbbbbbbbbb;cccccccccc;dddddddddd;eeeeeeeee;
1111111;2222222222;333333333;444444444;555555555;
fffffff;gggggggg;hhhhhhhhh;iiiiiiiiiiiii;jjjjjjjjjjjjjjjjjjj;
The advantages of this format are as follows:
These files are readable without any specific tool.

ED
11
RELEASED
9661m11re.doc
17/03/2010
15/66

The contents of these files can easily be interpreted/converted as a table in which the
lines of the table correspond to the lines of the text and the columns of the tables are
splitted using the character ; in the text.
For example, the aforementioned text in CSV format can be interpreted as:
aaaaaaaaaa bbbbbbbbbb cccccccccc
dddddddddd eeeeeeeee
1111111
2222222222 333333333
444444444
555555555
fffffff
gggggggg
hhhhhhhhh
iiiiiiiiiiiii
jjjjjjjjjjjjjjjjjjj
N.B.:
This interpretation is assumed in what follows wherever it is more convenient.
The reverse conversion (from a table to a CSV format) can also easily be performed.
The files to be imported can be manually written or written using widely available tools.
For example, it is possible to write a Microsoft Excel worksheet then convert it to the
CSV format to produce a corresponding import file.
The expression Comma Separated Value comes from the US for which the
separator is the Comma (i.e. ,). In France, the Semi colon character is used
instead. This implies to configure the tools to interpret the corresponding CSV files
(e.g. Microsoft Excel) appropriately.
N.B.:
The format used for the ACIE help files is either plain ASCII or HTML.
The format used for the ACIE lock and done files is plain ASCII.
2.5 Names of the ACIE files

The name of an ACIE MOC file is of the form:
<MOC-related name>.csv
where <MOC-related name> is similar to the name of the MOC associated with the file,
except that
it begins with an upper case letter instead of a lower case one;
"-" are replaced with "_".

An example of such a name is Cell.csv.
The name of an ACIE help file is of the form:
Readme.<file extension>
where <file extension> is equal to:
txt if the format used is plain ASCII
html if the format used is HTML.

The name of an ACIE lock file is:
Lock
The name of an ACIE done file is:
Done
2.6 Structure of the ACIE files

2.6.1 General description
An ACIE MOC file is composed as follows:

ED
11
RELEASED
9661m11re.doc
17/03/2010
16/66

<header>
[<MOIs-related part>]
in which <MOIs-related part> is present only when there is at least one MOI of the
associated MOC and has the following form:
<sub-header>
<body>
<header>, <sub-header> and <body> are described in the following sections.
N.B.:
As regards <header> and <sub-header>, the strings mentioned in the
following sections are not enclosed between " characters, contrary to strings
in <body>.
An ACIE help file has no specific structure.
An ACIE lock file contains a lock body.

This lock body shall be placed on the first line of the file and shall be composed of only
one line.
The structure of the lock body is as follows:
[<hostName>;]<processId>
where:
<hostName> is a character string indicating the corresponding host name

It is never present for a session at Network level and is always present for a
session at BSS-NE level.
<processId> is an integer value corresponding to the process Id of the process

handling the import or export session.
An ACIE Done file contains a done body.

This done body shall be placed on the first line of the file and shall be composed of
only one line.
The structure of the done body is as follows:
<date>;<hour>;
where <date> (resp. <hour>) is identical to the <date> (resp. <hour>) of the <header>
part of the corresponding ACIE MOC files (see section 2.6.2).
2.6.2 The header of an ACIE MOC file

The header gives general information concerning the import or export session.
It notably supplies information enabling to distinguish ACIE MOC files belonging to different
import or export sessions.
This header shall be placed on the first line of the file and shall be composed of only one
line. This enables the header to be easily extracted from the file.
For example, under Unix, the header of a file named Cell.csv can be extracted taking
advantage of the following command:
head-1 Cell.csv
The structure of the header is as follows:
<InfoModelVersion>;<date>;<hour>;<9153OMCR Instance>;<from/to>;<sessionName>;[<cgiMode>;]
where:
<InfoModelVersion> is a character string that indicates the considered version of the

9153 OMC-R information model from an ACIE viewpoint. It serves to indicate, for a
given (set of) ACIE MOC files, which is the considered version of the associated
supplementary information document.
It has the form
ED
11
RELEASED
9661m11re.doc
17/03/2010
17/66

<InfoModelBase> ACIE <n>

where:
<InfoModelBase> indicates the Base used for the information model.
<n> is an integer
<date> indicates the (local) date at which the file was created.
It is of the form YYYY-MM-DD.
<hour> indicates the (local) time at which the file was created.
It is of the form hh:mm:ss.
<9153OMCRInstance> is a character string that indicates the concerned 9153 OMC-R
instance.
More precisely, it is a predefined value that uniquely identifies the 9153 OMC-R
instance throughout the world. It is assigned at the 9153 OMC-R instance installation
time. Its length is at most 32 characters. For more information, the reader is referred to
the document that specifies ACIE-related supplementary information for the concerned
release.
<from/to> is:
absent for an export file
a character string that indicates which entity has created the file for an import file.
<sessionName> is a character string that indicates:
For an export file:
At Network Level, the "M.3100":userLabel attribute value of the corresponding

"NML":subNetwork MOI, i.e. the name of the PRC or Supervised
Configuration.
At BSS-NE Level, the "M.3100":userLabel attribute value of the

"EML":alcatelManagedElement MOI representing the corresponding BSC
equipment.
For an import file, a session name.

A set of file to be imported should indicate the same value for <sessionName>.
<cgiMode> is a character string equal to CGIMode. The corresponding part (including
the ';' character) shall be present for a file produced for or by a Radio Network Level
import/export session triggered in CGI mode and absent otherwise.
2.6.3 The sub-header of an ACIE MOC file

The sub-header corresponds to the column titles of the table associated with the body part
of the ACIE MOC file; i.e. it describes the type of information contained in the columns.
This sub-header shall be placed on the second line of the file and shall be composed of only
one line. This enables the sub-header to be easily extracted from the file.
For example, under Unix, the sub-header of a file named Cell.csv can be extracted taking
advantage of the following command:
head 2 Cell.csv | tail 1
The structure of the sub-header is as follows:
<ieModeColumnTitle>;<MOINetworkLevelIdValueColumnTitle>;<attributeNameList>;
where:
<ieModeColumnTitle> is equal to the string Mode
<MOINetworkLevelIdValueColumnTitle> is equal to a string formed by concatenating

<MOC-related name> (see section 2.5) and the string InstanceIdentifier
<attributeNameList> has the form:

*
[;<attributeNameX>]
ED
11
RELEASED
9661m11re.doc
17/03/2010
18/66

in which <attributeNameX> corresponds to the name of an attribute of the

corresponding managed object instances. For an export file, these names are
translated as follows:
the first (lower case) letter is replaced by the corresponding upper case letter
"-" is replaced by "_"

The following should hold:
For an export file, the list of attributes indicated in the sub-header shall be
complete. It is specified in the supplementary information document associated
with the concerned 9153 OMC-R Release.
For an import file, this list of attributes can be limited to the attributes whose value
need to be specified in the body.
2.6.4 The body of an ACIE MOC file

2.6.4.1 The different types of lines contained in the body
The body can contain:
Lines that are not processed, namely:
either empty lines
or comment lines.
Comment lines begin with the character #. They can serve to make the body
more readable.
These lines and comment lines can appear freely in the body.
MOI-related lines
These lines correspond to a given object instance of the MOC associated with the file.
For an export file, there is exactly one such line per existing object instance of the
MOC.
For an import file, several lines may correspond to the same object instance.
This is intended to make it easier to write or modify import files manually and to
merge several import operations within one file.
2.6.4.2 Structure of MOI-related lines

MOI-related lines have the following form:
<ieMode>;<MOINetworkLevelIdValue>;<attributeValueList>;
where:
<ieMode> shall always be equal to E for an export file.

For an import file, it shall be equal to either C, M, D. It indicates which kind of
operation is requested on the object instance corresponding to the line, namely:
<ieMode>
Corresponding request
C
create a given object instance
M
change the value of a number of attributes of a given object
instance.
D
delete a given object instance
<MOINetworkLevelIdValue> identifies uniquely the object instance at network level1.

It is a value of the Network Level Id type for the MOC associated with the file.
It is the responsability of the entity that has created the import file to guarantee this unicity.
ED
11 RELEASED
9661m11re.doc
17/03/2010
19/66
These Network Level Id types are defined in section 3.1.3 for the concerned
Network Level MOCs and section 3.2.3 for the concerned BSS-NE Level
MOCs.
<attributeValueList> has the form:
*
[;[<attributeValueX>]]
in which <attributeValueX>
may be absent for a number of lines and/or a number of columns in an import file;
is present for all lines and for all columns in an export file whenever the attribute
value is applicable.
An attribute is said to have a value that is 'not applicable' for MOIs of a given MOC
when:
In an associated export file, the attribute is listed in the sub-header and no value is
indicated in the body.
In that respect, to specify an attribute value as 'not applicable' is stronger than
specifying that it is 'not significant' since, in that case, a value may be indicated
in the body but this value shall not be relied upon.
In an associated import file, if the attribute is listed in the sub-header and a value is
indicated in the body, this value is discarded.
These cases along with the possible attribute values are specified in the supplementary
information document associated with the concerned 9153 OMC-R Release.

N.B.:
2.6.4.3 Representation of values in MOI-related lines

Values in MOI-related lines (i.e. both <MOINetworkLevelIdValue> and <attributeValueX>
mentioned above) are represented using the ASN1 value notation as defined in [ASN1]. The
main peculiarities concern:
The ASN1 types for which there are several possible ways to express corresponding
values. In that case, only one way is chosen (the one stated as the preferred one by
[ASN1] if any).
The values of type OBJECT IDENTIFIER which are more specifically defined in the
framework of the ACIE interface.
The following table defines precisely how the values of the ASN1 types of interest are
represented:
ASN1 type
Represented as
Example
Description
Simple ASN1 types
BOOLEAN
TRUE | FALSE
TRUE
INTEGER
INTEGER {
int1 (0),
int2 (1),
.....
intn (<n>)
}
ENUMERATED {
enum1 (0),
enum2 (1),
.....
enumn (<n>)
}
REAL
<n>
int1 | int2 | ... | intn
123
degraded
N.B.: Integer values with

no
associated
symbolic
name
(legal in GDMO)
shall not be used.
The keyword TRUE

or FALSE.
Signed number
Symbolic name of
the integer value in
which
each
"-"
character, if any, is
replaced by "_"
enum1 | enum2 | ...

| enumn
locked
Symbolic name of
the
enumerated
value in which each
"-" character, if any,
is replaced by "_"
C
double
precision
floating point value as
3.4E3
C double precision
floating point

ED
11
RELEASED
9661m11re.doc
17/03/2010
20/66
defined
9899]
BIT STRING or
OCTET STRING or
BIT STRING {
bitstr1
(0),
bitstr2
(1),
.....
bitstrn
(<n>)
}
NULL
character string type
(e.g.
PrintableString,
GraphicString)
GeneralizedTime
OBJECT IDENTIFIER
in
[ISO/IEC
'[0-9A-F] 'H
'3FE2EBAD'H
BIT STRING or
OCTET
STRING
value
in
hexadecimal form
NULL
*
[<char>]
where <char> is any
character allowed for the
character string type
possibly
translated
according
to
the
character translation rule
mentioned in section 1.3.
First
form
of
a
GeneralizedTime value
defined in [ASN1]
<MOINetworkLevelIdValu
e>
NULL
BSS
keyword NULL
(possibly converted)
character
string
value
19951106210627.3
(6th
Nov
1995,
21:06:27.3 local time.)
{bsc{100}, btsRdn 1}
GeneralizedTime
value, local time
form.
See section 2.6.4.2.
Structured ASN1 types

In what follows:
<T> or <Tn> denotes an ASN1 type
<TValRep> (resp. <TnValRep>) denotes the representation of a value of type <T> (resp.
<Tn>).
N.B.:
Tags are not mentioned hereafter since they do not influence the representation of the
value.
SEQUENCE OF<T>
{[<TValRep>]
{12, 13, 14}
List of values of type
*
(value of type SET OF <T> separated with
or SET OF <T>
[,<TValRep>] ]}
INTEGER)
, and enclosed
between { and }.
SEQUENCE {
{ [f1 <T1ValRep>]
{hreqave
16} List of field names
f1 <T1>,
represents a value of and values of the
[, f2 <T2ValRep>]
f2 <T2> OPTIONAL, ...
type
associated
type
HoAveragingDistPara
separated with ,
...
[, fn <TnValRep>]
m (from [GSM 12.20]). and
enclosed
fn <Tn>
}
between { and }.
}
If
a
field
is
or SET {
OPTIONAL and is
f1 <T1>,
not present, it does
f2 <T2>,
not appear in the
...
list.
fn <Tn>
If a field is present
}
(in particular if it is
mandatory), it can
nevertheless
be
omitted in the list for
an import file. In that
case,
the
value
assumed for this
field is the current
one (if <ieMode> =
"M") or the default

ED
11
RELEASED
9661m11re.doc
17/03/2010
21/66

CHOICE {
alt1 [1] <T1>,
alt2 [2] <T2>,
...
altn [n] <Tn>
}
alt1:<T1ValRep>
alt2:<T2ValRep>
...
altn:<TnValRep>
noUse:NULL
represents a value of
type FrequencyUsage
(from [GSM 12.20]) for
which
the
noUse
alternative is relevant.
one (if <ieMode>

="C")
Name
of
the
alternative
and
value
of
the
associated
type
separated with :
Table 3: Representation of values in ACIE MOC files

ED
11
RELEASED
9661m11re.doc
17/03/2010
22/66

3. CONCERNED 9153 OMC-R MOCS

3.1 Concerned Network Level MOCs
3.1.1 Description
The Radio Network Level MOCs concerned by import sessions and export sessions are the
same. They are all defined in the Network Manager Level part of the 9153 OMC-R
Information Model (corresponding GDMO label: NML).
The following table lists these MOCs, indicating, for each MOC:
the closest standard MOC(s), if any
what the corresponding object instances represent
whether it is allowed to create (C), delete(D) or modify the attribute values of (M) these
object instances.
9153 OMC-R MOC
NML:adjacency
Closest standard MOC(s)

Merge of:
GSM 12.20:
adjacentCellHandOver
GSM 12.20:
adjacentCellReselection
NML:adjacency2gTo
3g
none
NML:adjacency2gTo
Lte
none
NML:cell
GSM 12.20:bts
NML:
externalOmc3gCell
none
NML:
externalOmcCell
GSM 12.20:bts
NML:
externalOmcLteCell
none
NML:hoControl
GSM 12.20:
handoverControlGSM0508
NML:rnlAlcatelMFS
None
Short description
C D M
Represents the logical view

of an adjacency (containing
cell, target cell) managed by
a 9153 OMC-R instance.
Represents the relationship

between a serving 2G cell
and a target (external) 3G
cell.
Represents the relationship
between a serving 2G cell
and a target (external) LTE
cell.
Represents the logical view
of a cell managed by the
9153 OMC-R.
Represents a 3G cell that is
not managed by the 9153
OMC-R but is used for the
handover and reselection
mechanisms.
Represents a cell that is not
managed by the 9153 OMCR but is used for the
handover and reselection
mechanisms.
Represents a LTE cell that is
not managed by the 9153
OMC-R but is used for the
reselection mechanisms.
Supports the management of
parameters for the handover
algorith used by Alcatel.
Represents
the
Radio
Network Level view of an
(1)

ED
11
RELEASED
9661m11re.doc
17/03/2010
23/66

9153 OMC-R MOC

NML:rnlAlcatelBSC
Closest standard MOC(s)

Merge of:
GSM 12.20:bssFunction
GSM 12.20:bsc
NML:rnlAlcatelSector
GSM 12.20:bts
NML:
rnlAlcatelSiteManager
GSM 12.20:btsSiteManager
NML:rnlAlcatelTcRac
kManager
"GSM 12.20":
gsmManagedFunction
NML:rnlBasebandTra
nsceiver
Merge of:
GSM
12.20:
basebandTransceiver
GSM 12.20: channel
NML:rnlFrequencyHo
ppingSystem
GSM 12.20:
frequencyHoppingSystem
NML:rnlPowerControl
GSM 12.20:
powerControlGSM0508
NML:subNetwork
GSM 12.00:plmnNetwork
C D M
Short description
Alcatel MFS (NE for GPRS
handling).
Represents
the
Radio
Alcatel BSC.
Represents
the
Radio
Alcatel BTS Sector.
An object of this MOC has a
relationship attribute (namely
NML:rnlRelatedCell) which
identifies the cell that is
mapped onto the represented
BTS sector, if any.
Represents
the
Radio
Alcatel BTS Site Manager.
Represents
the
Radio
Alcatel TC Rack Manager.
Represents
the
Radio
Alcatel
Baseband
Transceiver.
Represents a set of radio
frequency channels used in a
specific frequency hopping
sequence.
Supports the management of
parameters for the power
control algorithm used by
Alcatel.
Represents the radio network
managed by the 9153 OMCR.
(1)
Table 4: Description of the concerned Network Level MOCs

(1) The corresponding object instances are automatically created (resp. deleted) when the
containing cell is created (resp. deleted).
Implied sub-object instances: A NML:cell object instance has all the object instances
named under it as implied object instances.
3.1.2 Corresponding Naming Tree

The corresponding Naming tree is as follows:
NML:subNetwork
NML:
externalOmc3gCell
NML:
externalOmcLteCell
NML:
externalOmcCell
"NML":
rnlAlcatelMFS
NML:
rnlAlcatelBSC

ED
11
RELEASED
9661m11re.doc
17/03/2010
24/66

NML:
rnlAlcatelTcRackManager
NML:
rnlAlcatelSiteManager
NML:
rnlAlcatelSector
NML:cell
NML:
adjacency
NML:
hoControl
NML:
adjacency2gTo3g
NML:
rnlBasebandTransceiver
NML:
rnlFrequencyHoppingSystem
NML:
rnlPowerControl
NML:
adjacency2gToLte
Figure 4: Naming Tree for the concerned Network Level MOCs

From what precedes, it can be deduced that the MOIs that belong to one of the following
MOCs are identified differently depending on the chosen ACIE Cell Identification mode:
"NML":adjacency
"NML":adjacency2gTo3g
"NML":adjacency2gToLte
"NML":cell
"NML":externalOmcCell
"NML":externalOmc3gCell
"NML":externalOmcLteCell
"NML":hoControl
"NML":rnlBasebandTransceiver
"NML":rnlFrequencySystem
"NML":rnlPowerControl.
3.1.3 Corresponding Network Level Id types

3.1.3.1 Description
The notion of Network Level Id type has been presented in section 2.6.4.2.
N.B.:

ED
11
RELEASED
9661m11re.doc
17/03/2010
25/66

9153 OMC-R MOC

NML:adjacency
NML:adjacency2gTo3g
NML:adjacency2gToLte
NML:cell
NML:externalOmcCell
NML:externalOmc3gCell
NML:externalOmcLteCell
NML:hoControl
Network Level Id type

Comments
In CGI mode:
CGIBasedAdjacencyID
else:
NetworkAdjacencyID
In CGI mode:
CGIBasedAdjacency2g
To3gID
else:
NetworkAdjacency2gTo
3gID
In CGI mode:
ECGIBasedAdjacency2
gToLteID
else:
NetworkAdjacencyID
In CGI mode:
CellGlobalIdentity
else:
NetworkCellID
In CGI mode:
CellGlobalIdentity
else:
NetworkCellID
The corresponding value for
an externalOmcCell of one
9153 OMC-R instance may
differ from that of the
corresponding cell of another
In CGI mode:
Global3gCellIdentity
else:
Network3GCellID
an externalOmc3gCell of one
9153 OMC-R instance may
differ from that of the
In CGI mode:
EGlobalLteCellIdentity
else:
NetworkCellID
an externalOmcLteCell of
one 9153 OMC-R instance
may differ from that of the
In CGI mode:
CellGlobalIdentity
The value corresponds to the
CellGlobalIdentity value of
the containing cell
ED
11
RELEASED
9661m11re.doc
17/03/2010
26/66

9153 OMC-R MOC
Comments
else:
NetworkCellID value of the
containing cell
NetworkCellID
NML:rnlAlcatelBSC
NML:rnlAlcatelMFS
NML:rnlAlcatelSector
NML:rnlAlcatelSiteManager
NetworkBSCID
NetworkMFSID
NetworkSectorID
NetworkSiteManagerID
NML:rnlAlcatelTcRackManage
r
NML:rnlBasebandTransceiver
NetworkTcRackManag
erID
In CGI mode:
CGIBasedBbtID
else:
NetworkBbtID
In CGI mode:
NML:rnlFrequencyHoppingSys
tem
It is recommended to prevent
from
working
on
the
configuration of an object
instance of this MOC or
named under the latter
whereas a BTS is moved by
the 9153 OMC-R since this
changes the value of the
btsRdn
field
of
NetworkSiteManagerID.
CGIBasedFhsID
else:
NetworkFhsID
NML:rnlPowerControl
CellGlobalIdentity
NetworkCellID
NML:subNetwork
INTEGER
In CGI mode:
CellGlobalIdentity value of
the containing cell
else:
NetworkCellID value of the
containing cell
RDN of the corresponding
MOI
Table 5: Network Level Id types for the Network Level MOCs
3.1.3.2 Corresponding ASN1 type definitions

These types are defined in [ACIE-si] (ACIENetworkLevelASN1Module).

ED
11
RELEASED
9661m11re.doc
17/03/2010
27/66

3.2 Concerned BSC-NE Level MOCs

3.2.1 Description
There are no BSC-NE level MOC that is concerned by import sessions.
The BSC-NE level MOCs concerned by export sessions are defined in several parts of the
9153 OMC-R Information Model, namely:
The Element Manager Level part

(corresponding GDMO label: EML)
The Software part

(corresponding GDMO label: SW)
The M.3100 part

(corresponding GDMO label: M.3100)
The Q.751.1 part

(corresponding GDMO label: Q.751.1)
The GSM 12.20 customized part

(corresponding GDMO label: A12.20)

9153 OMC-R MOC
EML:alcatel2MbTTP
EML:alcatelAbisChainRingCoordin
ator
Closest standard
MOC(s)
Merge of:
M.3100:trailTerminatio
nPointBidirectional
M.3100:connectionTer
minationPointBidirection
al
none
EML:alcatelAbisChainRing
none
EML:alcatelBasebandTransceiver
EML:alcatelBssFunction
Merge of:
GSM
12.20:
basebandTransceiver
GSM 12.20: channel
Merge of:
GSM
12.20:bssFunction
GSM 12.20:bsc
GSM 12.00":bssFunction
EML:alcatelBts-Sector
GSM 12.20:bts
EML:alcatelBtsSiteManager
GSM 12.20:
btsSiteManager
EML:alcatelCircuitPack
M.3100:circuitPack
EML:alcatelConnectionR1
M.3100:connectionR1
EML:alcatelFunction
none
EML:alcatelBsc
Short description
Represents a 2Mb termination
point of a BSC, a BTS
equipment or a transcoder.
This MOC is introduced notably

to manage Abis Hardware
extension/reduction.
Represents a chain or a ring of
BTS at the Abis interface.
Represents the BSC-NE Level
view of an Alcatel Baseband
Transceiver.
view of an Alcatel BSC.
Models the functionality of a

corresponding Alcatel BSC-NE.
view of an Alcatel BTS Sector.
view of an Alcatel BTS Site
Manager.
Represents
a
plug-in
replaceable unit that can be
inserted or removed from a
corresponding equipment holder
in the Alcatel BSC-NE.
Represents a PCM Circuit at the
Abis or AterMux interface.
This MOC models a function
relevant for an equipment in a

ED
11
RELEASED
9661m11re.doc
17/03/2010
28/66

9153 OMC-R MOC
Closest standard
MOC(s)
Short description
EML:alcatelFunctionCoordinator
none
EML:alcatelIPCoordinator
none
EML:alcatelIPLink
none
EML:alcatelIpPeer
none
EML:alcatelLapdLink
GSM 12.20:lapdLink
EML:alcatelManagedElement
M.3100:
managedElement
EML:alcatelManagedElementCom
plex
EML:alcatelOperatingSoftwareUnit
M.3100:managedEleme
ntComplex
GSM 12.20:
operatingSoftwareUnit
EML:alcatelPeerCoordinator
none
EML:alcatelRadioCarrier
GSM 12.20:radioCarrier
EML:alcatelReplaceableSoftware
Unit
GSM 12.20:
replaceableSoftwareUnit
EML:alcatelSignLinkN7
Q.751.1:signLinkTp
EML:alcatelSignLinkSetTp
Q.751.1:signLinkSetTp
EML:alcatelTcRackManager
E6ML:alcatelX25Coordinator
"GSM 12.20":
gsmManagedFunction
none
E6ML:alcatelX25Link
none
M.3100:equipmentHolder
M.3100:
equipmentHolder
GSM 12.20:
executableSoftwareUnit
GSM 12.20:
executableSoftwareUnit
BSC-NE
This MOC models all the
functions related to the same
"EML":alcatelManagedElement
MOI
This MOC is introduced to
optimize requests concerning
EML:alcatelIPLink
object
instances.
Represents the IP link between
the 9153 OMC-R and the BSCNE
Represents the IP association
between the BSC-NE and
another NE.
Represents a logical LapD
connection on a signalling link
on the Abis interface.
Represents
an
equipment
composing a BSC-NE, i.e. either
a BSC, a BTS or a Transcoder
equipment.
Models all aspects (functionality,
equipment, ...) of a BSC-NE
Represents
an
operating
software resource in the Alcatel
BSC-NE.
EML:alcatelIpPeer
object
instances.
Contains manageable properties
of a radio carrier (notably
hardware ones)
Represents a unit of software
that needs to be separately
identifiable and/or replaceable in
the Alcatel BSC-NE.
Represents the termination of a
SS No.7 signalling link between
the BSC-NE and the MSC.
Represents a SS No.7 signalling
link set termination point.
Represents
the
supervising
BSSIM view of an TC Rack.
EML:alcatelX25Link
object
instances.
Represents
the
X25
link
between the 9153 OMC-R and
the BSC-NE
Represents either a shelf or a
rack in the BSC-NE.
Represents a unit of software
that is separately identifiable and

ED
11
RELEASED
9661m11re.doc
17/03/2010
29/66

9153 OMC-R MOC
Q.751.1:mtpSignPoint
Closest standard
MOC(s)
Short description
is ready to be used in the Alcatel

BSC-NE.
Represents
the
Message
Transfer Part (MTP) functionality
of the BSC.
Table 6: Description of the concerned BSC-NE Level MOCs

ED
11
RELEASED
9661m11re.doc
17/03/2010
30/66


EML:
alcatelManagedElementComplex
"EML":
alcatelManagedElement
"EML":
alcatelAbisChainRingCoordinator
E6ML:
alcatelX25Coordinator
"EML":
alcatelAbisChainRing
E6ML:
alcatelX25Link
"Q.751.1":
mtpSignPoint
"EML ":
alcatelSignLinkSetTp
"EML":alcatelFunctionCoordinator
"EML":
alcatelSignLinkN7
"EML":alcatelFunction
"M.3100":
equipmentHolder (Rack)
EML:
alcatelConnectionR1
"EML":alcatel2MbTTP
SW:
alcatelOperatingSoftwareUnit
"M.3100":
equipmentHolder (Shelf)
"EML":alcatelCircuitPack
"EML":
alcatelBssFunction
"EML":
alcatelBsc
"EML":
alcatelBtsSiteManager
"EML":
alcatelLapdLink
EML:
alcatelTcRackManager
"EML":alcatelBts-Sector
"EML":
alcatelIPCoordinator
"EML":
alcatelBasebandTransceiver
EML:
alcatelRadioCarrier
SW:alcatelReplaceableSoftwareUnit
"EML":
alcatelIPLink
"EML":
alcatelPeerCoordinator
"EML":
alcatelIpPeer
GSM 12.20:executableSoftwareUnit
Figure 5: Naming Tree for the concerned BSC-NE Level MOCs

ED
11
RELEASED
9661m11re.doc
17/03/2010
31/66


3.2.3.1 Description
9153 OMC-R MOC
N.B.:
EML:alcatel2MbTTP
EML:alcatelAbisChainRing
EML:alcatelAbisChainRingCoordinator
EML:alcatelBasebandTransceiver
EML:alcatelBsc
EML:alcatelBssFunction
EML:alcatelBts-Sector
EML:alcatelBtsSiteManager
EML:alcatelCircuitPack
EML:alcatelConnectionR1
EML:alcatelFunction
EML:alcatelFunctionCoordinator
EML:alcatelIPCoordinator
EML:alcatelIPLink
EML:alcatelIpPeer
EML:alcatelLapdLink
EML:alcatelManagedElement
EML:alcatelManagedElementComplex
EML:alcatelOperatingSoftwareUnit
EML:alcatelRadioCarrier
EML:alcatelPeerCoordinator
EML:alcatelReplaceableSoftwareUnit
EML:alcatelSignLinkN7
EML:alcatelSignLinkSetTp
EML:alcatelTcRackManager
E6ML:alcatelX25Coordinator
E6ML:alcatelX25Link
GSM 12.20:executableSoftwareUnit
NetworkAlcatel2MbTTPID
NetworkAlcatelAbisChainRingID
NetworkAlcatelAbisChainRingCoordinatorID
NetworkAlcatelBasebandTransceiverID
NetworkAlcatelBscID
NetworkAlcatelBssFunctionID
NetworkAlcatelBtsSectorID
NetworkAlcatelBtsSiteManagerID
NetworkAlcatelCircuitPackID
NetworkAlcatelConnectionR1ID
NetworkAlcatelFunction
NetworkAlcatelFunctionCoordinator
NetworkAlcatelIPCoordinatorID
NetworkAlcatelIPLinkID
NetworkAlcatelIpPeerID
NetworkAlcatelLapdLinkID
NetworkAlcatelManagedElementID
NetworkAlcatelMECID
NetworkAlcatelOSUID
NetworkAlcatelRadioCarrierID
NetworkAlcatelPeerCoordinatorID
NetworkAlcatelRSUID
NetworkAlcatelSignLinkN7ID
NetworkAlcatelSignLinkSetTpID
NetworkAlcatelTcRackManagerID
NetworkAlcatelX25CoordinatorID
NetworkAlcatelX25LinkID
NetworkEquipmentHolderID
NetworkESUID
NetworkMtpSignPointID
Table 7: Network Level Id types for the BSC-NE Level MOCs

These types are defined in [ACIE-si] (ACIEBSSLevelASN1Module).
3.3 Concerned MFS-NE Level MOCs

3.3.1 Description
There are no MFS-NE level MOC that is concerned by import sessions.
The MFS-NE level MOCs concerned by export sessions are defined in several parts of the
9153 OMC-R Information Model, namely:
The MFS-NE Manager Level part

(corresponding GDMO label: NMD)
ED
11
RELEASED
9661m11re.doc
17/03/2010
32/66

The MFS-NE transport part

The MFS-NE Frame Relay part
The GB interface part
(corresponding GDMO label: AMFSME)

(corresponding GDMO label: AGFR)
(corresponding GDMO label: AGVC)

9153 OMC-R MOC
"AMFSME":aGprs2MbTTP
Closest standard
MOC(s)
None
Short description
"AGFR":aGprsBearerChannel
None
"AMFSME":aGprsFabric
None
"AATER":aGprsIpSigLink
None
"AGVC":aGprsNse
None
"AGVC":aGprsNsvc
None
"AGFR":aGprsPvc
None
"AGVC":aGprsSgsnIpEndPoint
None
M.3100:circuitPack
M.3100:circuitPack
M.3100:crossConnection
M.3100:equipmentHolde
r
Represents a 2Mb termination

point of a MFS-NE
Represents a Bearer Channel at
the GB interface.
Represents the function of
managing the establishment and
the release of the crossconnections of 2Mb-TTPs ports.
Represents the GPRS signaling
link over IP. It Carries GPRS
signalisation between MFS and
BSC in IP mode.
Represents a Network Service
Element (NSE) which is a group
of Network Service Virtual
Connection (NS-VC).
Represents a Network Service
Virtual Connection (NS-VC)
which provides an end-to-end
communication between the
MFS and the SGSN.
Represents a Permanent Virtual
Connection (PVC) which allows
to support multiplexing on a
Bearer Channel.
Represents the Serving Gprs
Support Node (Sgsn) side of a
Gb IP link.
Represents
a
plug-in
replaceable unit that can be
inserted or removed from a
corresponding equipment holder
in the MFS-NE.
Represents
an
assignment
relationship
between
the
termination point or GTP object
listed in the From Termination
attribute and the termination
point or GTP objects listed in the
To Termination attribute of this
managed object.
Represents either a shelf or a
rack in the MFS-NE.

ED
11
RELEASED
9661m11re.doc
17/03/2010
33/66

9153 OMC-R MOC

NMD:networkElement
Closest standard
MOC(s)
None
Short description
Models the MFS-NE as viewed
by the 9153 OMC-R. It is
mapped onto a corresponding
"M.3100":managedElement MOI
in the NMF-NE information
Model.
Table 8: Description of the concerned MFS-NE Level MOCs

"NMD":networkElement
"AMFSME":
aGprs2MbTTP
"M.3100":
equipmentHolder (Rack)
"AGFR":
aGprsBearerChannel
"M.3100":
equipmentHolder (Shelf)
"AGFR":
aGprsPvc
"M.3100":
circuitPack
"AATER":
aGprsIpSigLink
"AGVC":
aGprsNse
"AGVC":
aGprsSgsnIpEndPoint
"AGVC":
aGprsNsvc
"AMFSME":
aGprsFabric
"M.3100":
crossConnection
Figure 6: Naming Tree for the concerned MFS-NE Level MOCs

3.3.3.1 Description
9153 OMC-R MOC
N.B.:
"AMFSME":aGprs2MbTTP
"AGFR":aGprsBearerChannel
"AMFSME":aGprsFabric
"AATER": aGprsIpSigLink
"AGVC":aGprsNse
"AGVC":aGprsNsvc
"AGFR":aGprsPvc
"AGVC":aGprsSgsnIpEndPoint
M.3100:circuitPack
NetworkAlcatelGprs2MbTTPID
NetworkAlcatelGprsBearerChannelID
NetworkAlcatelGprsFabricID
NetworkAlcatelGprsIpSigLinkID
NetworkAlcatelGprsNseID
NetworkAlcatelGprsNsvcID
NetworkAlcatelGprsPvcID
NetworkAlcatelGprsSgsnIpEndPointID
NetworkAlcatelGprsCircuitPackID
NetworkAlcatelCrossConnectionID
NetworkEquipmentHolderID

ED
11
RELEASED
9661m11re.doc
17/03/2010
34/66
9153 OMC-R MOC

NMD:networkElement

NetworkAlcatelGprsNetworkElementID
Table 9: Network Level Id types for the MFS-NE Level MOCs

These types are defined in [ACIE-si] (ACIEMFSLevelASN1Module).

ED
11
RELEASED
9661m11re.doc
17/03/2010
35/66

4. IMPORT/EXPORT MECHANISMS
4.1 Import mechanism
Triggers:
An import session can only be triggered by a 9153 OMC-R operator.
Pre-conditions:
A set of files is transferred to an ACIE import directory.

This transfer is of under the responsability of the entity which wants an import
session to be triggered. It should not be performed if an ACIE lock file is present in
that directory.
A (possibly empty) PRC is opened.

This PRC is called the target PRC.
Inputs:
N.B.:
There is no need to indicate the concerned level of the import session since
only the Network Level is supported.
A sub-directory number, say i.
The directory that contains the ACIE MOC files to be imported (called the
concerned directory in what follows) is ACIE_NLimport_Diri.
Possibly an ACIE help file
The ACIE Cell Identification mode
N.B.:
It is set:
to the mode preferred by the operator for import sessions (ARCI

mode by default)
unless changed by the operator for that import session.
Outputs:
None
Description:
The target PRC modified according to the import files (target configuration) is ready to
be applied/activated to a SC.
N.B.:
The reason why the changes described in the import files are not applied
directly to the operational configuration is to enable a check of the target
configuration before the latter is actually applied on the fields.
N.B.:
It is noteworthy that, for a PRC activated in MLU mode (see section 1.2.2), the
attributes representing BSS/BSC telecom parameters of NML:rnlAlcatelBSC
are not taken into account. In this case, before activation, it is necessary to
split the PRC in two PRCs, one with these parameters and one without.
Scenario:
The different steps of the import mechanism are as follows:
(I1) Check for a concurrent import session
If an ACIE lock file is present in the concerned directory,
The lock body is read.

ED
11
RELEASED
9661m11re.doc
17/03/2010
36/66

If the <processId> it contains does not correspond to a process that is still alive,
the ACIE lock file is deleted.
An ACIE lock file is created in the concerned directory and the lock body is stored in it.
(I2) Overall checks of the set of import files
The following checks are performed on the set of import files:
Existence in the concerned directory
Valid headers as regards the <InfoModelVersion>, <9153OMCRInstance>,

<sessionName> and <cgiMode> parts (see section 2.6.2)
Valid sub-headers: each attribute name listed should correspond to one of the
attributes present in the objects of the MOC for the considered version of the 9153
OMC-R.
If these checks fail, an error message is displayed to the 9153 OMC-R operator
indicating the encountered problem and the import session is terminated.
(I3) For each of the ACIE MOC files (processed in the aforementioned order):
N.B.:
Only the MOI-related lines are considered hereafter. The other lines are
simply skipped.
(I3a)
First pass (Load): Each line of the file is processed in turn as follows:
A syntactic check is performed on <ieMode>.
Sub-header/line consistency check: it is checked that the <attributeValueList>

part of the line has the same number of elements as <attributeNameList> in
the sub-header of the file.
It is checked that a value is supplied for <MOINetworkLevelIdValue> and that

this value is compliant/consistent with the associated ASN1 type, i.e.:
it is consistent with the ACIE Cell Identification mode and syntactically

compliant with the associated ASN1 type;
it is consistent with the associated Naming Tree.

In
particular,
the
cell
field
in
AdjacencyInstanceIdentifier,
Adjacency2gTo3gInstanceIdentifier,
Adjacency2gToLteInstanceIdentifier,
RnlBasebandTransceiverInstanceIdentifier,
RnlFrequencyHoppingSystemInstanceIdentifier
and
the
value
of
HoControlInstanceIdentifier and RnlPowerControlInstanceIdentifier shall
correspond to the NetworkCellID (CellGlobalIdentity in CGI mode) of the
parent cell MOI.
In CGI mode and for "NML":cell and "NML":externalOmcCell MOIs.
If <ieMode> is equal to C, it is checked that
The value in the column corresponding to the "GSM

12.20":cellGlobalIdentity attribute obeys the CGI-related functional
checks described below, i.e.
the CGI sub-fields values are all supplied
the (mcc,mnc) sub-field values are correct
the CGI value is unique.
The value provided in <MOINetworkLevelIdValue> is equal to that

value

ED
11
RELEASED
9661m11re.doc
17/03/2010
37/66

If <ieMode> is equal to M, it is checked that, if a value is supplied in the

column corresponding to the "GSM 12.20":cellGlobalIdentity attribute, it is
equal to that in <MOINetworkLevelIdValue>.
In CGI mode and for "NML":externalOmc3gCell MOI,
The
value
in
the
column
corresponding
to
the
"C9ML":global3gCellIdentity attribute obeys the CGI-related
functional checks described below, i.e.
the (mcc3g, mnc3g) sub-field values are correct.

value

column corresponding to the "C9ML":global3gCellIdentity attribute, it is
In CGI mode and for "NML":externalOmcLteCell MOI,
The
value
in
the
column
corresponding
to
the
"CBML":eGlobalLteCellIdentity attribute obeys the CGI-related
functional checks described below, i.e.
the (mccLte, mncLte) sub-field values are correct.

value

column corresponding to the "CBML":eGlobalLteCellIdentity attribute, it is
The object instance corresponding to <MOINetworkLevelIdValue> is loaded in

the target PRC.
More precisely:
If <ieMode> is equal to C and
if the corresponding managed object instance is present neither in a

PRC nor in the SC
if the associated functional checks described below succeed

N.B.:
In CGI mode, the CGI-related checks for "NML":cell,
"NML":externalOmcCell, "NML":externalOmc3gCell and
"NML":externalOmcLteCell MOIs have already been
performed at this stage and are, thus, useless.
the corresponding managed object instance is created with notably its
naming attribute value set according to <MOINetworkLevelIdValue> and
the attributes set to the supplied values if any (when valid).
N.B.:
In CGI mode,
For
"NML":cell,
and
"NML":externalOmcLteCell MOIs, this implies to assign a
NetworkCellID value that corresponds to the CGI value
supplied in <MOINetworkLevelIdValue>.
ED
11
RELEASED
9661m11re.doc
17/03/2010
38/66

For "NML":externalOmc3gCell MOIs, this implies to assign

a Network3GCellID value that corresponds to the CGI
value supplied in <MOINetworkLevelIdValue>.
For the MOIs named under a "NML":cell MOI, this implies
to convert the CGI value(s) in <MOINetworkLevelIdValue>
into corresponding NetworkCellID value(s).
If <ieMode> is equal to M:
If there are no implied object instances and the corresponding object

instance is present either in the target PRC or in the SC then:
if the corresponding object instance is not present in the target

PRC, then it is copied from the SC;
else nothing happens.
If there are implied sub-object instances:
If the corresponding object instance is not present in the target

PRC, then it is copied from the SC along with its implied object
instances
Else it is checked that all the implied object instances are

present in the target PRC.
N.B.:
The corresponding object instance denotes the MOI corresponding

to <MOINetworkLevelIdValue>, possibly after CellGlobalIdentity and
EGlobalLteCellIdentity
to
NetworkCellID
conversion
and
Global3gCellIdentity to Network3gCellID conversion in CGI mode.
If the value supplied for the CMB:rnlCellType attribute of a given

NML:cell MOI (<ieMode> = M) is extendedOuter or
extendedInner then:
the corresponding COML:mateCellID is also copied from the

SC
else if it is already in the target PRC, then nothing will happen
If <ieMode> is equal to D, the processing is identical to the one

described above (i.e. case <ieMode> is equal to M), provided the
associated functional checks described below succeed.
As a consequence, in a given import file and for a given object instance,
there can be at most one line with an <ieMode> equal to C;
there can be at most one one line with an <ieMode> equal to D;
there may be several lines with an <ieMode> equal to M but these lines
must either apply to an object instance that is present in the SC or the
target PRC (in case the latter is not empty when the import session is
triggered) or follow a line with an <ieMode> equal to C.
(I3b)
Second pass (Set): Each column corresponding to <attributeValueList> of

each line of the file with <ieMode> equal to M is processed in turn as follows
(excluding the column corresponding to the "GSM 12.20":cellGlobalIdentity,
C9ML:global3gCellIdentity and "CBML":eGlobalLteCellIdentity attributes in
CGI mode since already processed):
If a value is provided for the attribute associated with the column and:
this value is compliant/consistent with the ASN1 type of the attribute;
the corresponding attribute has the REPLACE property for the

concerned BSC release (specified in [ACIE-si]);
ED
11
RELEASED
9661m11re.doc
17/03/2010
39/66

the associated functional checks described below succeed

the attribute is set to the supplied value in the target PRC (or the
corresponding value after CellGlobalIdentity to NetworkCellID value
conversion, Global3gCellIdentity to Network3GCellID value conversion
and EglobalLteCellIdentity to NetworkCellID in CGI mode).
If no value is provided for the attribute associated with the column, the
column is skipped (i.e. the attribute contains the same value as the
corresponding loaded object instance).
N.B.:
This two-pass strategy makes it possible to value correctly the relationship

attributes.
If the value supplied for the "NML":rnlSupportingSector attribute of a given

"NML":cell MOI (<ieMode> = "C" or "M"), say cell2 corresponds to an already
mapped "NML":rnlAlcatelSector MOI, say sector1, this causes (when the
associated checks are successful):
the "NML":rnlRelatedCell attribute for sector1 to indicate cell2;
the "NML":cell MOI to which sector1 was mapped, say cell1, to become
unmapped, i.e. the "NML":rnlSupportingSector attribute for cell1 becomes
equal to NULL (notAvailable alternative).
Since this implicit unmapping is peculiar, a corresponding warning message
shall be issued.
Functional checks:
The overall strategy is to limit the number of functional checks as much as possible and
notably not to duplicate the checks that are performed at activation time. Broadly
speaking, the checks performed at the ACIE interface are mainly meant to avoid:
9153 OMC-R SW problems
Telecom outage problems that would not be detected at activation time.

which represents a subset of the checks that would be performed if the corresponding
operation had been requested by the 9153 OMC-R operator (i.e. via the 9153 OMC-R
HMI).
It is noteworthy that there are some exceptions to this strategy.
More precisely, the checks performed are the following:
Title:
Mandatory values check for creation
<ieMode>: "C"
MOIs:
See first column below
Description:
The table below indicates, for the MOIs in the first column, the associated
attributes for which a value shall be mandatorily supplied in a creation
request.
MOIs
Attributes
"NML":adjacency
"NML":rnlAdjacencyType
"NML":adjacency2gTo3g
"NML":adjacency2gToLte
"NML":cell
"GSM 12.20":cellGlobalIdentity.lai.mcc
"GSM 12.20":cellGlobalIdentity.lai.mnc
"GSM 12.20":cellGlobalIdentity.lai.lac
"GSM 12.20":cellGlobalIdentity.ci
"GSM 12.20":bCCHFrequency
"GSM 12.20":cellGlobalIdentity.lai.mcc
ED
11
RELEASED
9661m11re.doc
17/03/2010
40/66

"NML":externalOmcLteCell
ED
"GSM 12.20":cellGlobalIdentity.lai.mnc
"GSM 12.20":cellGlobalIdentity.lai.lac
"GSM 12.20":cellGlobalIdentity.ci
"COML":frequencyRange
"CMB":rnlCellType
C9ML:ci3g
C9ML:fDD_ARFCN
"C9ML":global3gCellIdentity.mcc3g
"C9ML":global3gCellIdentity.mnc3g
"C9ML":global3gCellIdentity.local3gCi
C9ML:lac3g
CBML:rat3g
C9ML:rncId
"CBML":eGlobalLteCellIdentity.ciLte
"CBML":eGlobalLteCellIdentity.mccLte
"CBML":eGlobalLteCellIdentity.mncLte
"CBML":eUARFCN
"CBML":ratLte
Title:
cellGlobalIdentity unicity check
<ieMode>: "C", "M"
MOIs:
"NML":cell and "NML":externalOmcCell MOIs
Description:
For "NML":cell MOIs, a creation or modification request is only allowed if the
value supplied for the "GSM 12.20":cellGlobalIdentity attribute is such that
there is no existing "NML":cell MOI with the same value for this attribute in the
PRC (when in the SC, the problem is only detected at activation time).
The same check applies to "NML":externalOmcCell MOIs.
Title:
global3gCellIdentity unicity check
<ieMode>: "C", "M"
MOIs:
"NML":externalOmc3gCell MOI
Description:
For "NML":externalOmc3gCell MOIs, a creation or modification request is only
allowed if the value supplied for the "C9ML":global3gCellIdentity attribute is
such that there is no existing "NML":externalOmc3gCell MOI with the same
value for this attribute in the PRC (when in the SC, the problem is only
detected at activation time).
Title:
eGlobalLteCellIdentity unicity check
<ieMode>: "C", "M"
MOIs:
"NML":externalOmcLteCell MOI
Description:
For "NML":externalOmcLteCell MOIs, a creation or modification request is
only allowed if the value supplied for the "CBML":eGlobalLteCellIdentity
attribute is such that there is no existing "NML":externalOmcLteCell MOI with
the same value for this attribute in the PRC (when in the SC, the problem is
only detected at activation time).
Title:
<ieMode>:
MOIs:
11
3g cells telecom identity unicity check

"C", "M"
"NML":externalOmc3gCell MOI
RELEASED
9661m11re.doc
17/03/2010
41/66

Description:
For "NML":externalOmc3gCell MOIs, a creation or modification request is only
allowed if the values supplied for the "C9ML":global3gCellIdentity.mcc3g,
"C9ML":global3gCellIdentity.mnc3g, "C9ML":rncId and "C9ML":ci3g attributes
are such that there is no existing "NML":externalOmc3gCell MOI with the
same values for these attributes in the PRC (when in the SC, the problem is
only detected at activation time).
Title:
MNC/MCC check for cell MOIs
<ieMode>: "C", "M"
MOIs:
"NML":cell
Description:
The following couple of sub-field values:
("GSM 12.20":cellGlobalIdentity.lai.mcc,"GSM 12.20":cellGlobalIdentity.lai
.mnc)
shall be equal to one of the couples of attribute values of the
"NML":subNetwork MOI (defined at the 9153 OMC-R installation time):
("N7ML":ownMCC-x, "N7ML":ownMNC-x) with x {1,2,3,4}
N.B.:
For x {2,3,4}, this check is performed only if the corresponding
couple is significant, i.e. when it is different from:
('FFFF'H, 'FFFF'H) for a network configured (at installation time)

to allow a MobileNetworkCode value on 3 BCD digits;
('FFFF'H, 'FF'H) otherwise.

In this case, ownPlmnName-x is not equal to the empty string.
Title:
MNC/MCC check for "NML":externalOmcCell MOIs
<ieMode>: "C", "M"
MOIs:
"NML":externalOmcCell MOIs
Description:
("GSM 12.20":cellGlobalIdentity.lai.mcc,"GSM 12.20":cellGlobalIdentity.lai
.mnc)
("N7ML":foreignMCC-x, "N7ML":foreignMNC-x) with x {1,2,3,4}

N.B.:


In this case,
ownPlmnName-x for the first set of couples
foreignPlmnName-x for the second set of couples

is not equal to the empty string.
Title:
MNC_3G/MCC_3G check for "NML":externalOmc3gCell MOIs
<ieMode>: "C", "M"
MOIs:
"NML":externalOmc3gCell MOIs
Description:
("C9ML":global3gCellIdentity.mcc3g,"C9ML":global3gCellIdentity.mnc3g)
ED
11
RELEASED
9661m11re.doc
17/03/2010
42/66



N.B.:


In this case,

Title:
MNC_LTE/MCC_LTE check for "NML":externalOmcLteCell MOIs
<ieMode>: "C", "M"
MOIs:
"NML":externalOmcLteCell MOIs
Description:
"CBML":eGlobalLteCellIdentity.mccLte,"CBML":eGlobalLteCellIdentity.mn
cLte)

N.B.:


In this case,

Title:
cellsToBeDeleted check
<ieMode>: "C", "D", "M"
MOIs:
"NML":cell MOIs
Description:
For "NML":cell MOIs, a creation/deletion/modification request shall not
concern a cell that is identified by the "NML":cellsToBeDeleted attribute of the
"NML":subNetwork MOI.
Title:
change cellType check
<ieMode>: "M"
MOIs:
"NML":cell and "NML":externalOmcCell MOIs
Description:
For a "NML":cell or "NML":externalOmcCell MOIs, a modification request
concerning the "CMB":rnlCellType attribute value is only allowed for the
transitions from a current value (line) to a requested value (column) marked
with "" in the table below:
requested
single
concentric
umbrella
micro
umbrella
mini
extended
extended
other

ED
11
RELEASED
9661m11re.doc
17/03/2010
43/66

\
currentl
single
concentric
umbrella
micro
umbrella
Concentric
mini
extended
Inner
extended
Outer
other
Concentric
Outer
Title:
<ieMode>:
MOIs:
N.B.:
Inner
frequencyRange versus cellType check

"C", "M"
"NML":cell MOIs
This check is not performed for "NML":externalOmcCell MOIs; in this
case, the problem will be detected at PRC activation time.
Description:
If the "COML":frequencyRange attribute value is equal to 'gsm-dcs' or

(from B7.1 onwards) 'e-gsm-dcs', the "CMB":rnlCellType attribute value
shall
be
equal
to
either
'concentric',
'umbrellaConcentric',
'miniConcentric',
'microConcentric'
or
(from
B7.1
onwards)
'indoorMultiband'.
If the "CMB":rnlCellType attribute value is equal to 'miniConcentric',

'microConcentric' or (from B7.1 onwards) 'indoorMultiband', the
"COML":frequencyRange attribute value shall be equal to either 'gsmdcs' or (from B7.1 onwards) 'e-gsm-dcs'.
This can be sketched ut as follows:
frequencyRange /
rnlCellType
concentric
umbrellaConcentric
miniConcentric
microConcentric
indoorMultiband
(from B7.1 onwards)
other values
gsm-dcs
e-gsm-dcs
(from B7.1 onwards)
other values
where '' means the values for the two attributes are compatible (and
therefore possible); otherwise the cell is filled in with dark grey.
Title:
max adjacency per cell check
<ieMode>: "C"
MOIs:
"NML":adjacency MOIs
Description:
A request to create a "NML":adjacency MOI is only allowed if it does not
cause the number of such MOIs for the parent "NML":cell MOI to exceed 64.
Title:
max 2g-3g adjacency per cell check
<ieMode>: "C"
MOIs:
"NML":adjacency2gTo3g MOIs
Description:
A request to create a "NML":adjacency2gTo3g MOI is only allowed if it does
not cause the number of such MOIs for the parent "NML":cell MOI to exceed
8.
ED
11
RELEASED
9661m11re.doc
17/03/2010
44/66

Title:
max 2g-Lte adjacency per cell check
<ieMode>: "C"
MOIs:
"NML":adjacency2gToLte MOIs
Description:
A request to create a "NML":adjacency2gToLte MOI is only allowed if it does
not cause the number of such MOIs for the parent "NML":cell MOI to exceed
20.
Title:
max rnlBBT check
<ieMode>: "C"
MOIs:
"NML":rnlBasebandTransceiver MOIs
Description:
A request to create a "NML":rnlBasebandTransceiver MOI is only allowed if it
does not cause the number of such MOIs to exceed 16.
Title:
NetworkFhsID.fhsRdn check
<ieMode>: "C"
MOIs:
"NML":rnlFrequencyHoppingSystem MOIs
Description:
A request to create a "NML":rnlFrequencyHoppingSystem MOI is only allowed
if the value supplied for <MOINetworkLevelIdValue> (second column), fhsRdn
field lies in the range [1..16].
Title:
mobileAllocation versus cellAllocation check
<ieMode>: "C", "M"
MOIs:
"NML":rnlFrequencyHoppingSystem MOIs
Description:
For "NML":rnlFrequencyHoppingSystem MOIs, all the radio frequencies
(ARFCNs) specified in the "A12.20":mobileAllocation attribute must belong to
the set of allowed radio frequency values specified by the
"GSM 12.20":cellAllocation attribute of the parent "NML":cell MOI.
(I4) The ACIE lock file is deleted.

Files cleanup:
The processed ACIE import files are not removed by the import mechanism. They shall
be deleted by the 9153 OMC-R operator prior to triggering an import session on an
ACIE import directory where there are old import files. It is recommended that this
deletion is not performed without noticing the 9153 OMC-R operator that has
triggered the old import session.
Error handling:
Type of problem
Problems
directory
with
the
ACIE
Concurrent import session
Step
Comments
Fatal errors
import
The
import
directory
I1
ACIE_NLimport_Diri has not been
created as specified in section 2.1.
The administrator of the 9153 OMCR instance shall be contacted.
In ACIE_NLimport_Diri, a lock file is
I1
present and <processId> in it
corresponds to a process that is still
ED
11
RELEASED
9661m11re.doc
17/03/2010
45/66
Type of problem
Step
Comments
alive.
No ACIE import files can be found in
the
import
directory
ACIE_NLimport_Diri.
Problems with an ACIE import file
An attempt to read an ACIE import
I2
file has failed
Headers not valid or not consistent
A header in one of the ACIE import
I2
disregarding <InfoModelVersion>
file does not comply with the rules
stated in section 2.6.2 (disregarding
<InfoModelVersion>) or the headers
are not consistent
Sub-header not valid
A sub-header in one of the ACIE
I2
import file does not comply with the
rules stated in section 1.3
Line-related errors
Inconsistent <InfoModelVersion>
<InfoModelVersion> mentioned in
I2
the header is not consistent with the
Information Model version of the
9153 OMC-R instance on which the
parsed file is imported.
Wrong <ieMode>
I3a <ieMode> is:
not equal to either C, M or D,
or not consistent with the set of
operations allowed for object
instances of the MOC associated
with the parsed file
Line inconsistent with sub-header
I3a The <attributeValueList> part of the
line has not the same number of
elements as <attributeNameList> in
the sub-header of the parsed file
Missing
or
invalid I3a <MOINetworkLevelIdValue> is not
<MOINetworkLevelIdValue>
supplied or not compliant/consistent
with the Network Level Id type
corresponding to the ACIE Cell
Identification mode for the MOC
associated with the parsed file
<MOINetworkLevelIdValue> and CGI I3a In CGI mode, for "NML":cell and
values not equal (in CGI Cell
"NML":externalOmcCell MOIs
Identification mode)
<ieMode> is equal to C and
<MOINetworkLevelIdValue> is not
equal to the value in the column
corresponding to the "GSM
12.20":cellGlobalIdentity attribute
<ieMode> is equal to D, a value
is supplied in the column
corresponding to the "GSM
which
is
not
equal
to
In
CGI
mode,
for
"NML":externalOmc3gCell MOIs

ACIE import files not found
I2

ED
11
RELEASED
9661m11re.doc
17/03/2010
46/66

Type of problem
Step
CGI value cannot be modified in CGI

mode
I3a
The Managed Object Instance to be

created already exists
I3a
The Managed Object Instance to be

deleted or modified does not exist
I3a
An implied sub-object instance of a

Managed Object Instance to be
deleted or modified does not exist
I3a
Missing or invalid attribute value(s) to

create a Managed Object Instance
I3a
Comments
<ieMode> is equal to C and
<MOINetworkLevelIdValue> is not
equal to the value in the column
corresponding
to
the
"C9ML":global3gCellIdentity
attribute
<ieMode> is equal to D, a value
is supplied in the column
corresponding
to
the
attribute which is not equal to
In CGI mode and for "NML":cell and
MOIs,
<ieMode> is equal to M and a valid
value is supplied in the column
corresponding
to
the
"GSM
In
CGI
mode
and
for
MOIs,
<ieMode> is equal to M and a valid
value is supplied in the column
corresponding
to
the
attribute
<ieMode> is equal to C and the
MOI
corresponding
to
<MOINetworkLevelIdValue> already
exists either in a PRC or in the SC.
N.B.: The SC and the set of existing
PRCs shall be consistent with
respect to the object instances
that are created in these
domains.
<ieMode> is equal to M or D and:
there are no implied object
instances
the corresponding object instance
is present neither in the target
PRC nor in the SC
<ieMode> is equal to M or D and:
there are implied sub-object
instances
at least one of these implied subobject instances is not present in
the target PRC
No value is indicated for at least one
of the attributes that are mandatory
for creating the corresponding
Managed Object Instance or the
value is invalid

ED
11
RELEASED
9661m11re.doc
17/03/2010
47/66
Comments
At least one of the functional checks
has
failed
for
deleting
the
corresponding Managed Object
Instance
ARCI
mode,
when
In ARCI mode and <ApplicationID> I3a In
equal to 9153 OMC-R the <ieMode>
<ApplicationID> is equal to 9153
can not be equal to C.
OMC-R, then any object instance
can not be created.
Column-related errors
An attribute value cannot be modified
I3b <ieMode> is equal to M, a value is
supplied for an attribute and:
this
value
is
not
compliant/consistent
with
the
ASN1 type of the attribute
or the corresponding attribute has
not the REPLACE property (i.e. it
is read-only) for the concerned
BSC release
a functional check concerning this
value has failed.

Type of problem
Invalid attribute value(s) to delete a
Managed Object Instance
Step
I3a
In case of a fatal error,
an appropriate error message is displayed
the import session is terminated.

In case of a line-related or column-related error:
If this error does not cause the total number of errors to exceed
<maxDisplayedErrors>, an appropriate error message is displayed indicating
notably the file, the line at which the problem has occurred and (in case of a
column-related error) the concerned attribute.
Otherwise, a last error message is displayed indicating that the max number of
displayed errors is exceeded.
For a line-related error, the line is skipped and, for a column-related error, the
column is skipped.
N.B.:
Whenever a problem is encountered but is automatically solved somehow
(e.g. by taking advantage of some default values), a warning message could
be issued provided the same operation performed by an 9153 OMC-R
operator (i.e. via the 9153 OMC-R HMI) also causes a warning to be issued.
4.2 Export mechanism

4.2.1 General export mechanism
4.2.1.1 Unitary export session
Triggers:
An export session can be triggered either by a 9153 OMC-R operator or by a NMC or
via a dedicated script (see section 4.2.3.2).
ED
11
RELEASED
9661m11re.doc
17/03/2010
48/66

It is also triggered automatically by the 9153 OMC-R every day at a time that is defined
at the installation of a 9153 OMC-R instance.
Pre-conditions:
None.
Inputs:
Export Scope: either at Network Level or for a given BSC-NE or for a given MFSNE
Export Domain (for the Network Level only):
either an opened PRC (known through its name)
or the SC.
By default, the export domain is the SC.

The directory in which the ACIE MOC files should be placed (called the concerned
directory in what follows) is:
ACIE_NLexport_Diri for a Network Level export session
ACIE_BSSxexport_Diri for an export session for BSS-NE x
The ACIE Cell Identification mode

Outputs:
In the concerned export directory, the following files are produced:
the corresponding ACIE MOC files;
a corresponding ACIE done file.

Description:
Provided the export session is successful, the 9153 OMC-R produces one ACIE done
file and:
for an export session at Network Level, one ACIE MOC file per Network Level
MOC defined in section 3.1.
for an export session at BSC-NE Level, one ACIE MOC file per BSC-NE Level
for an export session at MFS-NE Level, one ACIE MOC file per MFS-NE Level
If an error arises, either no ACIE MOC files or only a subset of these files are created.
Scenario:
General Mechanism
The different steps of the export general mechanism are as follows:
(E1) Check the concerned directory
It is checked that:
the supplied sub-directory number corresponds to an existing directory
no ACIE done file is present in the concerned directory.

(E2) Check for a concurrent export session
If an ACIE lock file is present in the concerned directory,
The lock body is read.
If the <processId> it contains does not correspond to a process that is still alive,
the ACIE lock file is deleted.
ED
11
RELEASED
9661m11re.doc
17/03/2010
49/66

An ACIE lock file is created in the concerned directory and the lock body is stored in it.
(E3) For an export session at Network Level or BSC-NE Level, a frozen snapshot of the part
of the 9153 OMC-R Configuration database containing the configuration data to be
exported is produced (so as to ensure that the exported data is consistent).
For an export session at MFS-NE level, the configuration data to be exported is
retrieved from the MFS-NE with a special care with respect to the consistency of the
retrieved data.
From an external viewpoint, this retrieval can be viewed as a M-GET request of the
following form:
BOC:
"M.3100":managedElement
BOI
"M.3100":managedElement MOI
corresponding to the MFS-NE supplied as input
scope:
baseToNthLevel = 3
filter:
equal(objectClass,<concernedMFSNEMoc_1>)
or equal(objectClass, <concernedMFSNEMoc_2>)
...
or equal(objectClass, <concernedMFSNEMoc_n>)
where <concernedMFSNEMoc_n> denotes in turn each of the concerned
MFS-NE Level MOCs (see section 3.3) except "NMD":networkElement
which
is
replaced
by
its
MFS-NE
counterpart,
namely
"M.3100":managedElement.
(E4) For each of the MOC concerned by the export session (i.e. the Network Level ones
defined in section 3.1, the BSC-NE Level ones defined in section 3.2 or the MFS-NE
Level ones defined in section 3.3), a corresponding ACIE MOC file is created and filled
up by translating the configuration data associated with all the existing object instances
of the MOC to the ACIE MOC file format and structure.
N.B.:
In CGI mode, this implies to convert all the NetworkCellID values to the
corresponding CGI values.
(E5) The ACIE lock file is deleted.
(E6) A corresponding ACIE done file is stored in the concerned directory.
Files cleanup:
The produced ACIE export files are kept until another similar export session (i.e. with
the same concerned export directory) is requested in which case the new produced
files automatically replace old ones, if any.
This strategy makes it possible for another entity (be it a 9153 OMC-R operator or
another NMC) to:
Check if there are ACIE MOC files in one of the directories corresponding the level
of the desired export session and that the number of files correspond to the
number of concerned MOCs at that level.
If yes, to transfer one of these files and extract the header and sub-headers to
decide whether the available ACIE MOC files are sufficient to meet the perceived
need of that entity.
If these files are sufficient, to transfer these files instead of requesting a new
export session.
In other words, this makes it possible to avoid triggering export sessions if the needed
information is already available, which is recommended (for performance reasons).
ED
11
RELEASED
9661m11re.doc
17/03/2010
50/66

The produced ACIE done file is deleted via the File Transfer Achieved function (see
section 4.2.1.2).
Error handling:
Type of problem
Step
Comments
Fatal errors
Problems with the ACIE export
The concerned export directory
E1
directory
does not exist, e.g. because the
E4
supplied sub-directory number is
erroneous or an attempt to place the
produced files in this directory has
failed.
ACIE done file present in the ACIE
In the concerned export directory,
E1
export directory
an ACIE done file is present,
indicating that there are ACIE MOC
files in this directory that have not
yet been transferred.
Concurrent export session
In the concerned export directory, a
E2
lock file is present and <processId>
in it corresponds to a process that is
still alive.
9153 OMC-R Configuration data
For an export session at Network
E3
Level or BSC-NE Level, an attempt
cannot be retrieved
to produce a frozen snapshot of the
part
of
the
9153
OMC-R
Configuration database containing
the configuration data to be
exported has failed
For an export session at MFS-NE
level, the attempt to retrieve the
corresponding configuration data
has failed.
In case of a fatal error,
the ACIE lock file, if already produced by the export session, is deleted
the export session is terminated.
4.2.1.2 File Transfer Achieved function

Triggers:
This function can be triggered either by a 9153 OMC-R operator or by a NMC or via a
dedicated script (see section 4.2.3.3).
It is also triggered automatically by the 9153 OMC-R prior to an automatic export
session.
Pre-conditions:
None.
Inputs:
Export Scope: either at Network Level or for a given BSC-NE or for a given MFSNE

ED
11
RELEASED
9661m11re.doc
17/03/2010
51/66

The directory in which the ACIE Done file shall be deleted (called the concerned
directory in what follows) is:
ACIE_NLexport_Diri for a Network Level export session
ACIE_BSSxexport_Diri for an export session for BSC-NE x
ACIE_MFSxexport_Diri for an export session for MFS-NE x

Outputs:
None
Description:
In the concerned export directory, the ACIE done file is deleted.
Scenario:
(F1) Check the concerned directory
It is checked that
the supplied sub-directory number corresponds to an existing directory
an ACIE done file is present in the concerned directory.

(F2) The corresponding ACIE done file is deleted.
Files cleanup:
Not relevant (since no files are produced)
Error handling:
Type of problem
Step
Comments
Fatal error
Problems with the ACIE export
The concerned export directory
F1
directory
does not exist, e.g. because the
supplied sub-directory number is
erroneous
Warning
ACIE done file not present in the
In the concerned export directory,
F1
ACIE export directory
no ACIE done file is present.
In case of a fatal error or warning, the function is terminated.
4.2.2 Peculiarities for an export triggered by an 9153 OMC-R

operator
Export session:
The ACIE Cell Identification mode is set
to the mode preferred by the operator for export sessions (ARCI mode by
default)
unless changed by the operator for that export session.
In case of a fatal error, a message is displayed to the operator indicating the

encountered problem.
If the export domain is a PRC, this PRC should be closed by the 9153 OMC-R
operator at the end of the export session.
File Transfer Achieved function:
ED
11
RELEASED
9661m11re.doc
17/03/2010
52/66

In case of a fatal error or warning, a message is displayed to the operator

indicating the encountered problem.
4.2.3 Peculiarities for export sessions triggered by scripts

4.2.3.1 Introduction
Two scripts are available under the 9153 OMC-R External Interfaces Script directory (see
section 2.2) to trigger:
ACIE unitary export sessions: run_UnitaryExportSession.pl
the File Transfer Achieved function: run_FileTransferAchieved.pl
4.2.3.2 run_UnitaryExportSession.pl
Trigger/Inputs:
To trigger ACIE export sessions, the run_UnitaryExportSession.pl script can be called
as follows:
run_UnitaryExportSession.pl -exportScope <export scope> -exportDirNumber [-cgiMode]
where:
<export scope> indicates the considered export scope.

It can be equal to:
rnl to request an ACIE unitary export session at Network Level

The Export Domain is the SC.
bss <x> where <x> is a number to request an ACIE unitary export session for
the BSC-NE identified by <x>2
bss ALL to request an ACIE unitary export session for all the existing BSCNEs at the time the script is launched.
mfs <x> where <x> is a number to request an ACIE unitary export session for
the MFS-NE identified by <x>3
mfs ALL to request an ACIE unitary export session for all the existing MFSNEs at the time the script is launched.
 indicates the considered sub-directory number.
-cgiMode shall only be present when <export scope> is equal to rnl and is
different from 1 and indicates that the export session is triggered in CGI mode.
Otherwise, the export session is triggered in ARCI mode.
Outputs:
Per triggered ACIE unitary export session,
the following files are produced:
the corresponding set of ACIE MOC files
a corresponding ACIE done file.
these files are placed in:
ACIE_NLexport_Dir if <export scope> is equal to 'rnl';
ACIE_BSS<x>export_Dir if <export scope> is equal to 'bss <x>' or 'bss

ALL';
ACIE_MFS<x>export_Dir if <export scope> is equal to 'mfs <x>' or 'mfs

ALL'.
<x> corresponds to <MECId> defined in section 2.1

<x> corresponds to <NEId> defined in section 2.1
ED
11 RELEASED
3
9661m11re.doc
17/03/2010
53/66

Description/ files cleanup:

The corresponding ACIE unitary export session(s) is(are) triggered. For each of them,
what is specified in the description and files cleanup parts of section 4.2.1.1 holds.
Scenario:
Same as in section 4.2.1.1 except that an initial step (E0) is added to check the syntax
used to call the script and the arguments passed to it.
Error handling:
Same as in section 4.2.1.1 with the following additional error:
Type of problem
Comments
Fatal error
Problems with the usage of the script
The syntax used to launch the script
E0
and/or the arguments passed to it
is/are not correct.
In that case, the script terminates with an indication that an error has occurred.
4.2.3.3 run_FileTransferAchieved.pl
Trigger/Inputs:
To trigger the File Transfer Achieved function, the run_FileTransferAchieved.pl script
can be called as follows:
run_FileTransferAchieved.pl -exportScope <export scope> -exportDirNumber 
where:
<export scope> indicates the considered export scope.

Its possible values are the same as for run_UnitaryExportSession.pl (see section
4.2.3.2), i.e. rnl, bss <x>, bss ALL, mfs <x> and mfs ALL.
 indicates the considered sub-directory number.

Outputs:
None
Description/Files cleanup:
The ACIE done file is deleted in
ACIE_BSS<x>export_Dir if <export scope> is equal to 'bss <x>';
ACIE_BSS<x>export_Dir for each of the existing BSC-NEs at the time the

script is launched if <export scope> is equal to 'bss ALL'.
ACIE_MFS<x>export_Dir if <export scope> is equal to 'mfs <x>';
ACIE_MFS<x>export_Dir for each of the existing MFS-NEs at the time the

script is launched if <export scope> is equal to 'mfs ALL'.
Scenario:
Same as in section 4.2.1.2 except that an initial step (F0) is added to check the syntax
used to call the script and the arguments passed to it.
Error handling:
Same as in section 4.2.1.2 with the following additional error:
Type of problem
Comments
Fatal error
F0
ED
11
RELEASED
9661m11re.doc
17/03/2010
54/66

Type of problem
Comments
is/are not correct.
In that case, the script terminates with an indication that an error has occurred.
4.2.4 Peculiarities for exports that are automatically triggered
First, the File Transfer Achieved function is triggered.

Then, several unitary export sessions are triggered:
one for the SC and
one for each of the existing BSC-NE
one for each of the existing MFS-NE

with the sub-directory number set to 1 and the ACIE Cell Identification mode set to the
ARCI mode.
4.2.5 Peculiarities for an export triggered by a NMC
NMC
9153
OMC-R
requestTransferUp action Req.
(simpleFileTransferControl)
(N1)
The 9153 OMC-R checks whether it can process the

corresponding export request.
(N2)
requestTransferUp action Resp.

The corresponding ACIE MOC files are produced by the
9153 OMC-R.
(N3)
(N5)
(N4)
transferUpReady notification Req.

( simpleFileTransferControl)
The NMC transfers these files
......
......
transferUpReceived action Req.
(N6)
transferUpReceived action Resp.

end of the scenario
(N1) A GSM 12.00:requestTransferUp action request is sent by a GSM

12.00:simpleFileTransferControl object instance to request an export session.
If the superior GSM 12.00:generalDataTransferControlFunction object instance is

named under ANOI:anoiPlmnNetwork, then the request corresponds to a
Network Level export session.
ED
11
RELEASED
9661m11re.doc
17/03/2010
55/66


named under ANOI:anoiCoreManagedElement, then the request corresponds to
a BSC-NE Level export session for the corresponding BSC-NE.

named under ANOI:anoiGPRSManagedElement, then the request corresponds
to a MFS-NE Level export session for the corresponding MFS-NE.
The export domain is the SC and the ACIE Cell Identification mode is set to the ARCI
mode.
The Action Info parameter of the corresponding M-ACTION indication primitive shall
be a list with only one element which can be described as follows:
FIELDS
M/C COMMENTS
typeOfFile
M
M
fileType
This
sub-field
should
contain
configurationFile
M
fileSubType
This sub-field should contain a valid subdirectory number (see section 4.2.1).
transferId
M
This field contains an integer value that
uniquely identifies the export session for the
requesting NMC. It is the responsability of the
requesting NMC to guarantee this unicity.
(N2) The 9153 OMC-R checks whether it can process the corresponding export request.
This step is similar to steps E1 and E2 of the general export scenario except that a
requestTransferUp
response
primitive
is
emitted
by
the
GSM
12.00:simpleFileTransferControl object instance. If:
the Action Info parameter of the request is valid from a GDMO viewpoint but
does not comply with its aforementioned description or
an ACIE done or lock file is present in the concerned directory

the requestTransferUp response primitive indicates that the request is denied with an
accessDenied error.
(N3) The corresponding ACIE MOC files are produced by the 9153 OMC-R.
This step is similar to steps E3 to E6 of the general export scenario.
If
an
error
occurs
when
producing
these
files,
the
GSM
12.00:simpleFileTransferControl
object
instance
emits
a
GSM
12.00:bulkTransferError notification.
The Event Information parameter of the corresponding M-EVENT-REPORT primitive
is a list with only one element which can be described as follows:
FIELDS
M/C COMMENTS
alarmInfo
M
M
probableCause
This sub-field contains the ProbableCause
value fileError (defined in AttributeASN1Module of [X.721]).
C
specificProblems
(absent)
M
perceivedSeverity
This sub-field contains major
C
other AlarmInfo fields

(absent)
transferId
M
This field contains the transferId value supplied
by the requesting NMC in the corresponding
requestTransferUp action request.
ED
11
RELEASED
9661m11re.doc
17/03/2010
56/66

(N4) The transferUpReady notification is sent by the GSM 12.00:simpleFileTransferControl

object instance to indicate that the requested ACIE MOC files are ready for transfer.
The Event Information parameter of the corresponding M-EVENT-REPORT primitive
is a list with only one element which can be described as follows:
FIELDS
M/C COMMENTS
fileList
M
List containing one element per produced
ACIE MOC file with the following sub-fields:
M
fileName
See section 2.5.

M
typeOfFile
M
fileType
contains configurationFile
M
fileSubType
This sub-field is used to indicate the
sub-directory number (see section
4.2.1).
C
fileSize
linkedTransferId
M
This field indicates whether or not the
notification is linked to a requestTransferUp
action identified by a transferId.
Its contains TRUE.
transferId
M
This field contains the transferId value
supplied by the requesting NMC in the
corresponding requestTransferUp action
request.
(N5) The corresponding ACIE MOC files are transferred by the requesting NMC.
This step is under the responsability of the requesting NMC. The protocol used is the
one
indicated
in
the
ANOI:typeOfFileTransfer
attribute
of
the
ANOI:anoiPlmnNetwork object (see [ANOIcs-gene]).
N.B.:
It is noteworthy that nothing prevents another NMC to transfer the same files.
(N6) When the requesting NMC has finished transferring these files, a GSM
12.00:transferUpReceived
action
request
is
sent
by
the
GSM
12.00:simpleFileTransferControl object instance.
This causes the File Transfer Achieved function to be triggered (i.e. steps F1 to F2
above).
The Action Info parameter of the corresponding M-ACTION Request primitive is a list
with only one element which can be described as follows:
FIELDS
M/C COMMENTS
fileList
M
List that shall contain only one element with
the following sub-fields:
M
fileName
ignored (could contain the empty

string)
M
typeOfFile
M
fileType
shall contain configurationFile
M
fileSubType
shall contain a valid sub-directory
number (see section 4.2.1).
C
fileSize
(shall be absent)
transferId
M
This field contains the transferId value supplied
by the requesting NMC in the corresponding
requestTransferUp action request.
ED
11
RELEASED
9661m11re.doc
17/03/2010
57/66

If the Action Info parameter of the request is valid from a GDMO viewpoint but does
not comply with its aforementioned description,
the request is denied with an 'accessDenied' error.

ED
11
RELEASED
9661m11re.doc
17/03/2010
58/66

5. THE ACIE FILTERING FACILITY

5.1 INTRODUCTION
Depending on the concerned MOC, the number of attributes whose value is exported in the
corresponding ACIE MOC file can be important whereas a given external application may
only need a small subset of these attribute values. In addition, only a subset of the ACIE
MOC files produced by an ACIE unitary export session may actually be needed by a given
external application.
To help in that respect, a filtering facility is supported via a dedicated script made available
in the 9153 OMC-R External Interfaces Script directory (see section 2.2). This facility
enables to filter the contents of set of ACIE MOC files produced by an ACIE unitary export
session according to:
an input file, called an ACIE Filter file in which the external application can express its
needs
some filtering options

and produces a set of corresponding unitary ACIE post-processing (APP) files. For the
BSC-NE level (resp. MFS-NE level), this facility is also supported for a set of ACIE export
sessions corresponding to all the existing BSC-NEs (resp. MFS-NEs). In that case
(depending on an option), it is possible either to produce the set of unitary ACIE postprocessing files for each of the existing BSC-NEs (resp. MFS-NEs) or only one file
collecting all the corresponding information, called a global ACIE post-processing file.
5.2 The ACIE Filter files

5.2.1 Names of the ACIE Filter files
The name of an ACIE Filter file can be any valid file name.
5.2.2 Structure of the ACIE Filter files

An ACIE Filter file is composed of:
Empty lines and comment lines which are not intended to be processed but to make
the body of the file more readable. Comment lines begin with either the character '#' or
two characters '-' (GDMO comment, see [GDMO]).
lines of the form:

<MOC indication> <separator(s)> <attribute indication>
where:
<MOC indication> has the following form:

["<ACIE subset identifier>":] <MOC name>
<separator(s)> contains either space or tab characters
<attribute indication> has the following form:

["<ACIE subset identifier>":] <attribute name>
in which:
"<ACIE subset identifier>" corresponds to one of the GDMO labels defined in

section 1.3 of the corresponding ACIE Interface Supplementary Information
document for the concerned release.
Any number of space characters (including zero) can be written before and after
the character ':' above
ED
11 RELEASED
9661m11re.doc
17/03/2010
59/66

<MOC name> is a string corresponding to the name of one of the concerned 9153
OMC-R Managed Object Class (see section 3).
<attribute name> is a string corresponding to the name of one attribute of the

MOIs belonging to the MOC denoted by <MOC indication>. The list of the possible
(MOC, attribute) couples is specified in the corresponding ACIE Interface
Supplementary Information document for the concerned release.
Such a line is considered to be equivalent to the following corresponding line:
<MOC name>
<attribute name>
i.e. with absent ["<ACIE subset identifier>"] parts and with <separator(s)> equal to a tab
character.
Examples of valid lines are:
"EML":alcatelBsc
"X.721":operationalState
alcatelBts-Sector
administrativeState
"EML" : alcatelBasebandTransceiver "X.721" : operationalState
which are equivalent, functionally speaking, to:
alcatelBsc
operationalState
alcatelBts-Sector administrativeState
alcatelBasebandTransceiver
operationalState
It is noteworthy that a same ACIE Filter file can be used by an external application to
express its needs for several levels: according to the export level implied by the <export
scope> argument passed to the script, only the lines for which <MOC name>
corresponds to one of the MOCs at the considered level are interpreted, the other ones
being discarded (see section 5.4).
5.3 The ACIE post-processing (APP) files

5.3.1 Names of the APP files
5.3.1.1 Names of the unitary APP files
A unitary ACIE post-processing file results in the processing of one corresponding ACIE
MOC file contained in one of the ACIE export directories. Its name has the following form:
<MOC-related name>_<ACIE export directory indication>.app
where:
<MOC-related name> corresponds to the name of the associated MOC, as defined in

section 2.5;
<ACIE export directory indication> is formed from the name of the associated ACIE
export directory by removing the 'ACIE_' prefix.
For example,
The name of the unitary APP file corresponding to the 'Cell.csv' ACIE MOC file in the
directory ACIE_NLexport_Dir2 is 'Cell_NLexport_Dir2.app'.
The name of the unitary APP file corresponding to the 'AlcatelBsc.csv' ACIE MOC file
in the directory ACIE_BSS5export_Dir3 is 'AlcatelBsc_BSS5export_Dir3.app'.
The name of the unitary APP file corresponding to the 'AGprsNsvc.csv' ACIE MOC file
in the directory ACIE_MFS6export_Dir4 is 'AGprsNsvc_MFS6export_Dir4.app'.

ED
11
RELEASED
9661m11re.doc
17/03/2010
60/66

5.3.1.2 Names of the global APP files

A global ACIE post-processing (APP) file results in the processing of one corresponding
ACIE MOC file contained in the ACIE export directories:
either for each of the existing BSC-NEs with a given ACIE sub-directory number.
In this case, its name has the following form:
<MOC-related name>_BSSALLexport_Dir.app
or for each of the existing MFS-NEs with a given ACIE sub-directory number.
In this case, its name has the following form:
<MOC-related name>_MFSALLexport_Dir.app
where:
<MOC-related name> corresponds to the name of the associated MOC, as defined in

section 2.5;
N.B.:
The associated MOC is one of the MOC for the BSS-NE level (see section
3.2).
 indicates the considered ACIE sub-directory number.

For example,
the name of the global APP file corresponding to the 'AlcatelBsc.csv' ACIE MOC file in
the directories ACIE_BSS<x>export_Dir3 (with <x> identifying any of the existing BSCNEs) is 'AlcatelBsc_BSSALLexport_Dir3.app'.
the name of the global APP file corresponding to the 'AGprsNsvc.csv' ACIE MOC file in
the directories ACIE_MFS<x>export_Dir4 (with <x> identifying any of the existing MFSNEs) is 'AGprsNsvc_MFSALLexport_Dir4.app'.
5.3.2 Structure of the APP files

5.3.2.1 Structure of the unitary APP files
A unitary ACIE post-processing (APP) file has exactly the same structure as its
corresponding ACIE MOC file - see section 2.6 - except in case options are used:
to remove the first column (relating to <ieMode>)

In that case, '<ieModeColumnTitle>;' is removed in the sub-header and 'E;' is removed
in each line of the body.
and/or the second column (relating to <MOINetworkLevelIdValue>).

In that case, '<MOINetworkLevelIdValueColumnTitle>;' is removed in the sub-header
and '<MOINetworkLevelIdValue>;' is removed in each line of the body.
Note that, in these cases, the APP file can no longer be used as a base for a subsequent
ACIE import session. It is of the responsability of the external application to take care
of this aspect.
In addition, compared with its corresponding ACIE MOC file, a number of attribute-related
columns can be absent depending on the supplied ACIE Filter file. For such a column, both
the part corresponding to the concerned attribute in the sub-header (including the ';'
character following the attribute name) and in each line of the body (including the ';'
character following the attribute value) are removed.
5.3.2.2 Structure of the global APP files

A global APP file for a given MOC and a given sub-directory number is built from the set of
corresponding unitary APP files for that MOC and that sub-directory number as follows:
ED
11
RELEASED
9661m11re.doc
17/03/2010
61/66

{<BSS-NE x indication>
<header of the unitary APP files for BSS-NE x>
<sub-header unitary APP files for BSS-NE x>
+
<body of the unitary APP file for BSS-NE x>}
where:
<BSS-NE x indication> is a comment line of the following form:
For a BSC-NE:
# Data for BSS <x>
For a MFS-NE:
# Data for MFS <x>
For example:
# Data for BSS 3
<header of the unitary APP files for BSS-NE x> corresponds to the header of the
unitary APP files for the corresponding BSC-NE or MFS-NE and for the concerned
MOC.
<sub-header of the unitary APP files for BSS-NE x> corresponds to the sub-header of
the unitary APP files for the corresponding BSC-NE or MFS-NE and for the concerned
MOC.
<body of the unitary APP file for BSS-NE x> correspond to the body of the unitary APP
file for the corresponding BSC-NE or MFS-NE and for the concerned MOC.
5.4 The ACIE filtering mechanism (apply_ACIEFilter.pl)

Trigger/Inputs:
To trigger the ACIE filtering mechanism, the apply_ACIEFilter.pl script can be called as
follows:
apply_ACIEFilter.pl <filtering options> <ACIE Filter file> <ACIE export
directory(ies)> [-global] <output directory>
where:
<ACIE Filter file> is the (absolute) name (i.e. possibly preceded by a path name) of
an ACIE Filter file
< filtering options> indicates the options chosen.

It has the following form:
[-v] [-mode] [-nid]
where:
-v (verbose) indicates that the supplied ACIE Filter file contains (MOC,
attribute) couples to keep.
If this option is not present, this indicates that the supplied ACIE Filter file
contains (MOC, attribute) couples to remove (in that case, the file is called
also an ACIE exception file).
-mode indicates that the first column (relating to <ieMode>) shall be removed.
If this option is not present, this indicates that the first column shall be kept.
-nid
indicates
that
the
second
column
(relating
to
<MOINetworkLevelIdValue>) shall be removed.
If this option is not present, this indicates that the second column shall be
kept.
<ACIE export directory(ies)> indicates the ACIE export directory(ies) in which the
ACIE MOC files to process can be found.
It has the following form:
-exportScope <export scope> -exportDirNumber 
where:
<export scope> indicates the considered ACIE export scope.

ED
11
RELEASED
9661m11re.doc
17/03/2010
62/66

Its possible values are the same as for run_UnitaryExportSession.pl (see

section 4.2.3.2), i.e. rnl, bss <x>, bss ALL, mfs <x> and mfs ALL.
 indicates the considered ACIE sub-directory number.

The considered ACIE export directory(ies) are thus:
ACIE_BSS<x>export_Dir if <export scope> is equal to 'bss <x>';
ACIE_BSS<x>export_Dir for each of the existing BSC-NEs at the time the

script is launched if <export scope> is equal to 'bss ALL'.
ACIE_MFS<x>export_Dir for each of the existing MFS-NEs at the time the

script is launched if <export scope> is equal to 'mfs ALL'.
-global is an option that can only be specified if <export scope> is equal to 'bss
ALL' or 'mfs ALL'.
If present, it indicates that global APP files shall be produced instead of the unitary
APP files for each BSC <x> or MFS <x>.
<output directory> indicates the (absolute) name of the directory in which the
produced files shall be placed (called the output directory in what follows).
It is recommended not to use one of the ACIE import directories as output
directory.
N.B.:
It cannot be one of the ACIE export directories since the access rights of
the latter are (luckily) not sufficient.
Pre-conditions:
The considered ACIE export directory(ies) contain(s) a set of ACIE MOC files produced
by the corresponding ACIE unitary export session(s).
Outputs:
In the directory <output directory>,
If the -global option is absent,
If the -v option is absent, one unitary APP file is produced per considered
ACIE export directory and per ACIE MOC file present in that directory.
Otherwise, one unitary APP file is produced per considered ACIE export
directory and per ACIE MOC file present in that directory that is also present
in the ACIE Filter file.
If the -global option is present,
If the -v option is absent, one global APP file is produced per ACIE MOC file
present in
one of the ACIE_BSS<x>export_Dir directories if <export scope> is

equal to 'bss ALL';
one of the ACIE_MFS<x>export_Dir directories if <export scope> is

equal to 'mfs ALL'.
Otherwise, one global APP file is produced per ACIE MOC file present in
one of the ACIE_BSS<x>export_Dir directories if <export scope> is

equal to 'bss ALL';
one of the ACIE_MFS<x>export_Dir directories if <export scope> is

equal to 'mfs ALL'.
that is also present in the ACIE Filter file.
Description:
The ACIE export files present in the ACIE export directory(ies) are processed in best
effort mode according to the supplied options and to the ACIE Filter file.
Scenario:
ED
11
RELEASED
9661m11re.doc
17/03/2010
63/66

(A0) Check the command

The syntax used to call the script and the arguments passed to it are checked.
then, for each of the considered ACIE export directories:
(A1) Produce the set of unitary APP files for the considered ACIE export directory
(A1.1) It is checked that the considered ACIE export directory exists, that the ACIE
Filter file can be found and that the output directory exists and has the
appropriate access rights.
In particular, the output directory shall not be an ACIE export directory.
(A1.2) Each of the ACIE MOC files in the considered ACIE export directory is
processed in turn.
The corresponding unitary APP file is produced by copying the header and
modifying the sub-header and body of the corresponding ACIE MOC file as
follows:
if -mode is present, the first column is removed
if -nid is present, the second column is removed
then
if -v is absent, for each of the attributes listed in the ACIE Filter file
for that MOC, the column corresponding to the attribute is removed;
if -v is present, only the columns corresponding to the attributes

listed in the ACIE Filter file for that MOC are kept.
(A1.3) if -v is present, the produced unitary APP files corresponding to the MOCs
that are not mentioned in the ACIE Filter file are deleted.
(A2) If the -global option is present, replace the produced unitary APP files by the
corresponding global APP files
For each of the MOC for which a set of corresponding unitary APP files has been
produced by step (A1):
(A2.1) Produce the corresponding global APP file (see section 5.3.2.2):
by copying the header and sub-header of one of these unitary APP files
by copying the body of each of the unitary APP files in turn preceded by
the appropriate <BSS-NE x indication> part.
(A2.2) Delete the set of corresponding unitary APP files for that MOC.
Files cleanup:
The deletion of the produced APP files is under the responsability of the external
application that has launched the script. It is recommended that this deletion is
performed as soon as these files are no longer of interest to this external
application and, to the least, prior to calling the script with the same ACIE export
directory(ies) and the same output directory as input: due to how APP files are
named (see section 5.3.1), this could lead e.g.
to have a set of unitary APP files for a given ACIE export directory that is not
consistent;
or to remove a set of APP files whereas they are still needed (e.g. in case the
script is called with the same ACIE export directory and the same output directory
but different options and/or different ACIE Filter files).
Error handling:
Type of problem
Comments
Fatal errors
A0
ED
11
RELEASED
9661m11re.doc
17/03/2010
64/66
Comments
is/are not correct.
Problems with an ACIE export A1.1 The
considered
ACIE
export
directory
directory does not exist, e.g.
because the supplied sub-directory
number is erroneous
Problems with the ACIE Filter file
A1.1 The ACIE Filter file cannot be found
Problems with the output directory
A1.1 The output directory does not exist
or it is not possible to place the APP
files to be produced in it.
Non-Fatal error
Problems with an ACIE export file
A1.1 An ACIE export file to process
cannot be found (e.g. because the
corresponding ACIE export session
has
not
been
terminated
successfully)
ACIE Filter file errors
Problems with the syntax of a line in A1.2 A line of the ACIE Filter file has not
the syntax described in section 5.2
the ACIE Filter file
Problems with a MOC indication in a A1.2 The MOC name specified in a line of
line of the ACIE Filter file
the ACIE Filter file does not
correspond to one of the MOC for
the concerned export level
Problems with an attribute indication A1.2 The attribute name specified for a
in a line of the ACIE Filter file
given MOC in a line of the ACIE
Filter file does not correspond to a
column of the corresponding ACIE
MOC file
In the fatal error cases, the script terminates with an indication that an error has
occurred.
In the non-fatal error case, the production of the APP file for the concerned MOC is
simply skipped.
In the ACIE Filter file error cases, each line in error is simply skipped.

Type of problem

ED
11
RELEASED
9661m11re.doc
17/03/2010
65/66

6. ACRONYMS
ACDB
ACFR
ACIE
AFTR
APP
ARCI
BSC
BSS
BSSIM
BTS
BBT
CGI
CI
DD
GDMO
GSM
hh
HMI
I/E
LAC
MCC
MFS
MLU
mm
MM
MNC
MOC
MOI
NE
NMC
NS-VC
NSE
OID
O&M
OMC
PLMN
PRC
PVC
SC
SGSN
ss
YYYY
ALU 9153 OMC-R Configuration Databases

ALU 9153 OMC-R Configuration File Repository
ALU 9153 OMC-R Configuration Import/Export Interface
ALU 9153 OMC-R File Transfer Repository
ACIE post-processing (file)
Application-Relative Cell Identity (mode)
Base Station Controller
Base Station Subsystem
Base Station Subsystem Information Manager
Base Transceiver Station
Baseband Transceiver
Cell Global Identity
Cell Identity
Two digit representation of a day
Guidelines for the Definition of Managed Objects
Global System for Mobile communications
Two digit representation of an hour
Human-Machine Interface
Import/Export
Location Area Code
Mobile Country Code
Multi-BSS Fast packet Server (A9135 equipment)
Massive Logical Update
Two digit representation of the minutes
Two digit representation of a month
Mobile Network Code
Managed Object Class
Managed Object Instance
Network Element
Network Management Centre
Network Service Virtual Connection
Network Service Element
Object Identifier
Operation and Maintenance
Operation and Maintenance Centre
Public Land Mobile Network
Provisioning Radio Configuration
Permanent Virtual Connection
Supervised Configuration
Serving Gprs Support Node
Two digit representation of the seconds
Four digit representation of a year
END OF DOCUMENT

ED
11
RELEASED
9661m11re.doc
17/03/2010
66/66

09661MAAAe11 PDF

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

09661MAAAe11 PDF

Hochgeladen von

Copyright:

Verfügbare Formate

All rights reserved.

Passing on and copying of this

9153 OMC-R Configuration Import/Export Interface

9153 OMC-R Configuration Import/Export interface

3BK 09661 MAAA PBZZA

All rights reserved. Passing on and copying of this

SYSTEM FUNCTIONAL BLOCKS

THE FILES CONCERNED BY THE ACIE INTERFACE.................................12

CONCERNED 9153 OMC-R MOCS ...............................................................23

Concerned BSC-NE Level MOCs........................................................28

The different types of lines contained in the body .........................................19

Concerned MFS-NE Level MOCs........................................................32

9153 OMC-R Configuration Import/Export interface

3BK 09661 MAAA PBZZA

All rights reserved. Passing on and copying of this

IMPORT/EXPORT MECHANISMS .................................................................36

Peculiarities for an export triggered by an 9153 OMC-R operator52

Unitary export session ....................................................................................48

Peculiarities for exports that are automatically triggered .............55

THE ACIE FILTERING FACILITY...................................................................59

Structure of the APP files ............................................................61

Names of the unitary APP files.......................................................................60

The ACIE filtering mechanism (apply_ACIEFilter.pl) ........................62

9153 OMC-R Configuration Import/Export interface

3BK 09661 MAAA PBZZA

All rights reserved. Passing on and copying of this

LIST OF FIGURES AND TABLES

21/10/2007: Creation from 3BK 09661 LAAA PBZZA Ed.01 Released

B10 is replaced by B11

The REFERENCED DOCUMENTS and RELATED DOCUMENT parts are updated

A1353 RA is replaced by 9153 OMC-R.

15/02/2008: No technical changes.

The document is updated following the new capability to export alcatelIpPeer

The changes implied by the new capability to export alcatelTcRackManager MOIs

29/02/2008: No technical changes.

The changes implied by the new capability to export aGprsFabric MOIs.

The changes implied by the new capability to export crossConnection MOIs.

The changes implied by the new capability to export aGprsIpSigLink MOIs.

30/03/2009: No technical changes.

3BK 09661 MAAA PBZZA

All rights reserved. Passing on and copying of this

CBML:rat3g parameter is added to the list of the parameters to be checked at

The aGprsIpSigLink MOIs definition is updated.

The changes implied by the new capability to export adjacency2gToLte MOIs.

The changes implied by the new capability to export externalOmcLteCell MOIs.

17/03/2010: No technical changes.

Information technology - 8-bit single-byte coded graphic character sets

Information Technology - Open Systems Interconnection- Structure of

Information Technology - Open Systems Interconnection Structure of

Maintenance: Telecommunications Management Network - Generic

Digital cellular telecommunications system (Phase 2);

Digital cellular telecommunications system (Phase 2);

3BK 09661 MAAA PBZZA

All rights reserved. Passing on and copying of this

Base Station System (BSS) Management Information

Profile for the NMC/A1353 RA Q3 Interface

NMC/A1353-RA Q3 Interface Information Model: GDMO Formal

NMC/A1353-RA Q3 Interface: Overview and Conformance Statements

9153 OMC-R Configuration Import/Export Interface: Supplementary

9153 OMC-R Configuration Import/Export Interface: Informal excerpts

9153 OMC-R Configuration Import/Export Interface: Mapping to BSS

NMC/A1353-RA Q3 Interface: Position with respect to standards of the