-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 1/19
Site
VELIZY
EVOLIUM SAS
Originators
F Binard
MFS / OMC-R
RADIO FILE INTERFACE SPECIFICATION
ALL RELEASES
System : ALCATEL 900/BSS Sub-system : SYS-OAM Document Category
: PRODUCT DEFINITION
ABSTRACT
This document describes the format of the files exchanged
between the MFS and the OMC-R for the radio configuration
purpose.
Approvals
Name App.
(DPM/ OSY)
G Dael (DPM/ CNS)
S Lablee
(DPM/ OMC-R) P Pelouas
REVIEW
Ed. 01 Proposal 03 99/01/19 MCD/TD/CNS/99-68/HL
Ed. 02 Proposal 01 99/10/27 /RCD/MR/TD/CNS/99-1002/BF
Ed. 03 Proposal 01 01/02/28 /RCD/MR/TD/CNS/99-2414/BF
Ed. 04 Proposal 01 02/02/19 /RCD/MR/TD/CNS/02-3141/BF
HISTORY Ed. 01 Proposal 01 98/09/08 Creation, Update after
synchronisation meeting with
OMC3 team on 98/09/08 (MCD/TD/OMC3/98.0775 File Format
Proposal), Distribution for reading.
Ed. 01 Proposal 02 98/12/14 Update according to reading
reports.
Removal of the file formats for the radio configuration change
per message and the initialisation since they are not supported by
the OMC.
Describe application to information model.
Distribution for approval.
-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 2/19
Ed. 01 Proposal 03 98/12/30 Update according to reading reports
(OMC3 & SYS).
Removal of two phases (apply action & accept action) for
massive radio configuration.
Ber encoding/decoding used on FileRecord and not on
FileStructure.
Distribution for approval.
Ed. 01 Released 99/01/28 Updates after review (see review
report).
Released version
Ed. 02 Proposal 01 99/08/18 Detailed file resynchronisation
principles
RFC: 3BKA13CBR047600
RFC: 3BKA13CBR061292
radio file format should compressed
RFC: 3BKA13CBR056061
apply of resynchro possible only on Cell or Bss basis.
Ed. 02 Released 99/11/05 Updates after review (see review
report).
Released version
Ed 03 Proposal 01 01/02/21 3BKA13CBR070006: new management of
resp file at MFS
3BKA13CBR069875: in resynchro, del ntf must be sent
3BKA13CBR067441:FTP interface instead of RCP for files
transfer
Ed 03 Released 01/03/02 Updates after review (see review
report)
Released version
Ed 04 Proposal 01 12/02/02 More details about the impact of
pdchGroup multi instances introduced in B7.2 (see
3BKA20FBR108363)
Ed 04 Released 01/03/02 Updates after review (see review
report).
Ed 05 Proposal 01 02/05/02 Alignement of the document on SW
behaviour (3BKA20FBR107799)
Ed 05 Released 02/09/09 Document is released by project
decision
Ed 06 Proposal 01 03/10/03 3BKA20CBR131120 : Radio Reinit no
more supported for whole MFS from release B8
Ed 06 Released 24/10/03 No remarks. Document is released by
project decision.
-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 3/19
TABLE OF CONTENTS
TABLE OF CONTENTS
.........................................................................................................................3
INTERNAL REFERENCED
DOCUMENTS............................................................................................4
REFERENCED
DOCUMENTS...............................................................................................................4
RELATED
DOCUMENTS.......................................................................................................................4
PREFACE
...............................................................................................................................................4
OPEN POINTS /
RESTRICTIONS..........................................................................................................4
1 SCOPE
..............................................................................................................................................5
2 GENERAL
PRINCIPLES...................................................................................................................5
2.1 File
transfer...................................................................................................................7
2.2 Processing of CMIS operations
..................................................................................8
2.3 File format
.....................................................................................................................8
2.3.1 Operation file format
........................................................................................................9
2.3.2 Result file format
..............................................................................................................9
2.4 Global status
response..............................................................................................10
2.5 aGprsConfigurationFile Status
.................................................................................11
3 RADIO CONFIGURATION UPDATE
..............................................................................................12
3.1 Principles
....................................................................................................................12
3.2 Operation file format : create, set, action and delete
.............................................12 3.3 Result file
format
........................................................................................................13
4 RADIO SYNCHRONISATION
.........................................................................................................13
4.1 Principles
....................................................................................................................13
4.2 Operation file format : create , set and
action.........................................................15
5 RADIO RE-INITIALISATION
...........................................................................................................16
5.1 Principles
....................................................................................................................16
5.2 Operation file format : create, set , action and delete
............................................16 5.3 Result file
format
........................................................................................................17
6 APPLICATION TO INFORMATION MODEL
..................................................................................18
6.1 CMIS attribute
.............................................................................................................18
6.2 CMIS
actions...............................................................................................................18
6.3 Model consistency
.....................................................................................................18
-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 4/19
INTERNAL REFERENCED DOCUMENTS
Not applicable
REFERENCED DOCUMENTS
[1] X.711
Common Management Information Protocol Specification for CCITT
Applications [2] 3BK 11203 0049 DSZZA
GPRS O&M Functional Architecture - Release B6.2 - [3] 3BK
10204 0458 DTZZA
GPRS BSS Technical Feature List - Release B6.2 - [4] 3BK 11204
0223 DSZZA
SBF OMC/MFS: Radio Domain - Release B6.2 - [5] 3BK 10204 0531
DTZZA
PACKET SERVICE BSS TECHNICAL FEATURE LIST - Release B7.2 [6] 3BK
11203 0074 DSZZA
GPRS/EDGE O&M Functional Architecture (B7&B8) [7] 3BK
11204 0255 DSZZA
OMC/MFS Radio Domain (B7&B8)
RELATED DOCUMENTS [8] 3BK 11204 0288 DSZZA
MFS / OMC interface: GDMO [Part 1]: Specific Object Identifiers
- Release B8 - [9] 3BK 11204 0256 PBZZA
MFS / OMC interface: GDMO [Part 1]: MIB- Release B7.2 -
PREFACE
The aim of this document is to describe the principles and the
formats of the file exchanges between the MFS and the OMC-R for the
radio configuration purpose. These files are used in the following
cases: the massive radio configuration, the radio synchronisation,
and the radio re-initialisation.
OPEN POINTS / RESTRICTIONS
None
-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 5/19
1 SCOPE
This document defines the principles and specifies the format of
the file exchanges between the MFS and the OMC. It only deals with
the configuration files used for the massive radio configuration
changes, the radio synchronisation, and the radio
re-initialisation.
For these operations, the files have a similar structure. There
is only one file format whichever functionality addressed.
The downloaded files (OMC-R MFS) contain strictly what is sent
by means of sockets. Results are reported through result files (MFS
OMC) which also contain the same as a communication by socket.
The way the files are downloaded or uploaded and the mechanisms
used to take them into account at the MFS level, follows those
presented in [2].
Two different actions are implemented: the activateConfiguration
file M_ACTION for radio re-initialisation and massive radio
configuration change and the synchroConfiguration M_ACTION because
radio synchronisation does not have the same behaviour as the two
others.
These two M_ACTION (aGprsSynchroConfigurationFile and
aGprsActivateConfigurationFile) trigger an operation supported at
MFS / OMC-R interface. Each functionality will be described in a
dedicated section in order to detail some specific behaviour.
2 GENERAL PRINCIPLES
This section presents the main principles of the radio file
interface.
The OMC-R downloads the configuration of the radio domain which
is defined in an operation file and write the result of this
operation in a result file (which contains error and confirmation
reports).
At the MFS, there is a protection against concurrent execution
of different operational files. Operational files are taken into
account, one after the other. It is not possible to execute
concurrently several operational files on the radio domain at the
MFS.
The OMC-R ensures the consistency of the data in the operation
file.
-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 6/19
It is possible to apply an operation file on different base
object(s):
- MFS basis. The scope of the action is the whole radio
configuration of the MFS (All BSC, all CELL)
managed Element (M3100)
aGprsBssFunction
aGprsBtsSiteManager
aGprsBts
aGprsPowerControl aGprsPdchGroupaGprsAdjacentCellReselection
aGprsMasterChannelData
Base ObjectInstance
- BSC basis, The scope of the action is the radio configuration
of one BSC with all related CELLs.
managed Element (M3100)
aGprsBssFunction
aGprsBtsSiteManager
aGprsBts
aGprsPowerControl aGprsPdchGroupaGprsAdjacentCellReselection
aGprsMasterChannelData
Base ObjectInstance
- CELL basis (aGprsBts). The scope of the action is the radio
configuration of one CELL.
managed Element (M3100)
aGprsBssFunction
aGprsBtsSiteManager
aGprsBts
aGprsPowerControl aGprsPdchGroupaGprsAdjacentCellReselection
aGprsMasterChannelData
Base ObjectInstance
-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 7/19
Important:
In case of radio resynchronisation operation, the list of base
object instances is given as argument of the ACTION. - If it is a
resynchronisation MFS basis, the list is composed of only one item:
the
managedElement object instance - If it is a resynchronisation
BSC basis, the list is composed of one or more
aGprsBssFunction object instance(s) - If it is a
resynchronisation CELL basis, the list is composed of one or
more
aGprsBts object instance(s) It is also possible to mix different
types of resynchronisation in a single action (CELL and BSC for
example).
The file formats described hereafter are used in all cases.
Nevertheless, some restrictions, which may apply in specific cases,
are presented in the corresponding section.
2.1 File transfer
Note: In order to speed up the file transfer (radio
configuration), the OMC-R will compress the radio configuration
file. The MFS is in charge to uncompress them. The results file
will follow the same way: they will be compressed by the MFS and
uncompress by the OMC. The compress tool will be the unix gzip
1.2.4 (18 Aug 93).
A Q3 action indicates to the MFS the way to take an operation
file into account. In all cases, a file containing CMIS operations
is downloaded. FTP interface is used for file transfer.
A partition is reserved in the MFS to store the operation1 and
result files2. It is taken into account at the MFS side on an OMC-R
CMIS action message with the operation file name as parameter
(except for the re-synchronization which need a base object
instance list and an operational filename).
Two directories are used:
/omcxchg contains all the operational and result files which are
valid (i.e. complete) for OMC
1 A file naming convention allows finding the result file name
from the operation file name. The result file name has the name of
the operation file prefixed by res_. 2 The pathname of the
radioFile files is stores in the attribute aGprsSpoolDirectory
(package aGprsManagedExtensionPackage (object
aGprsManagedExtension)). This path is locally defined in a MFS
configuration file. This attribute is not supported by the OMC.
-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 8/19
A working directory that contains the working result file that
is not visible by OMC. At the end of the operational file
processing, the working result file is compressed (see note) and
then, moved to /omcxchg directory. The working directory is
configured into param.cfg file (i.e.: /usr/mfs/tmp/q3_tmp). When
the processing of the operation file is finished: the results of
the operations are reported through a result file. A global status
is reported to the OMC-R in the response to the previous
action.
The OMC-R is in charge to remove the result files at the MFS
(the MFS does not remove these files). The operational file is
removed by the MFS when the M-ACTION response is sent to the OMC.
The advantage is that no specific CMIS command has to be
implemented neither by OMC-R nor by MFS to manage the deletion of
file.
2.2 Processing of CMIS operations
An operation file is processed according to the following
rules:
An operation file contains a set of CMIS operations, which
follows a consistent order according to naming and domains
relationships.
The operations are performed following a best effort policy.
Scoped/filtered operations are accepted because the exchanged
files contain the invoke identifier of the request.
2.3 File format
There is only one file format that contains strictly what is
sent by means of sockets. Thus, the COMET methods used in case of a
communication by socket will be reused as it is described below.
The file contains a sequence of CMIS message (CMISmsg), encoded in
BER. Each CMIS message contains a sequence of a CMIS header
(CMISheader) and a CMIS body message (AsnAny).
The CMISHeader contains the following parameters:
The operation involved (CMIS primitive) : request operation,
confirmed operation or errorStatus
The mode requested for the operation. The possible values are
confirmed or not confirmed.
The invoke identifier (this parameter specifies the identifier
assigned to the operation)
The length of the body message Note: refer to the COMET
CMISmsg.h for a detailed description of the CMISHeader.
-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 9/19
2.3.1 Operation file format
The file downloaded from the OMC-R to the MFS contains a
sequence of CMIS request primitive. The supported request
operations are:
M-CREATE-Req
M-DELETE-Req
M-SET-Req
M-ACTION-Req (alignDownAction)
For each operation, the following parameters must be present in
the operation file: MOC (Managed Object Class), MOI (Managed Object
Instance) and attributes values (for M-CREATE and M-SET). The
attribute value, which is used for naming, is always specified in
an M-CREATE request since the RDN of a created object is given by
the OMC.
The order of the operations in the operation file must follow
the dependence tree; i.e. an object creation necessarily appears
after the creation of its containing object. A delete operation on
an object deletes all its contained objects. Moreover, an
attribute, which contains a reference to an object instance, must
always be set after the object instance creation. A specific order
is required in some cases. It is exposed in the corresponding
chapter.
The CMIS body message is:
an AsnSetArgument OR
an AsnCreateArgument OR
an AsnDeleteArgument OR
an AsnActionArgument
Refer to [1], for the definitions of SetArgument,
CreateArgument, DeleteArgument, and ActionArgument.
2.3.2 Result file format
The result file format contains the results and/or the errors
for all the CMIS operations given in the operation file. The order
of the results is the same as the order of the operations in the
given sequence.
If the mode of an operation is equal to non-confirmed, no
results are written by the MFS in the result files.
-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 10/19
The file uploaded from the MFS to the OMC-R contains a sequence
of CMIS confirmation primitive and/or errorStatus. The possible
operations are:
M-CREATE-Conf
M-DELETE-Conf
M-SET-Conf
M-ACTION-Conf (alignDownAction)
COMPLETED (if multiple replies are sent for an operation, this
parameter indicates that it is the last reply)
errorStatus
The CMIS body message is:
an AsnSetResult OR
an AsnCreateResult OR
an AsnDeleteResult OR
an AsnActionResult OR
an AsnXXX ( XXX according to the errorStatus)
Refer to [1] for the definitions of SetResult, CreateResult,
DeleteResult, ActionResult and errorStatus.
2.4 Global status response
A global status of the operation is reported to the OMC-R in the
response of the action leading to the file processing.
If all the CMIS operations are correct, the response is an
ActionResult. Otherwise, an AlcatelErrorInfo is returned. The error
values are contained in a processingFailure structure with the
following error code:
File not found;
Decoding problem;
General failure;
Operation error.
The last one means that at least one CMIS operation found in the
file generates an error.
-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 11/19
This rule has two exceptions for radio synchronization
operations:
The error (duplicate managed object instance error), due to the
creation of an object instance that already exists, is not taken
into account.
The error (invalid operation error) in SET confirmation, due to
attributes which are mandatory at creation time and not replaceable
after (get only attributes), are not taken into account.
2.5 aGprsConfigurationFile Status
aGprsConfigurationFileStatus is an attribute of the package
aGprsManagedElementExtension.
Status:
ON when at least one operationFile is open (operate),
OFF when the last resultFile is closed (no more operation).
-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 12/19
3 RADIO CONFIGURATION UPDATE
3.1 Principles
The radio configuration update3 is used to download a set of
changes from the OMC-R to the MFS. It is performed as follows:
OMC MFS
Activate File Action (filename)aGprsConfigurationFileStatus
ON
Operation File download
Activate File Response (global
status)aGprsConfigurationFileStatus OFF
Processing may send- Attribute value change,- State Change,-
Object creation,- Object Deletion alarm ind.
Result File upload
Figure 1: Massive radio configuration change scenario
3.2 Operation file format : create, set, action and delete
The operation file is based on CMIS operations which express the
modifications performed at the OMC-R level on the radio MIB (object
creations, object deletions, attribute value changes).
The file is ordered per instance. The operation file contains
the following CMIS operations:
CMIS operation Presence into the file
M-CREATE-Req Optional M-DELETE-Req Optional M-SET-Req Optional)
M-ACTION-Req (alignDownAction)
Mandatory as soon as a cell or a cell sub-tree is modified via
M-SET-Req or
M- CREATE-Req or M-ACTION-Req). a cell sub-tree is modified via
a M_DELETE-Req on a
aGprsPdchGroup or a aGprsAdjacentCellReselection The
M_ACTION-Req, when inserted, is always put after the other
operations related to the cell and cell sub-tree.
3 Activate File action: The name of the operation file is given
as argument of a specific CMIS action.
-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 13/19
3.3 Result file format
This file is exactly the one described in section 2.3.2.
4 RADIO SYNCHRONISATION
4.1 Principles
For the radio domain, the OMC-R owns the reference MIB. The
OMC-R needs to synchronise4 the MFS, for instance in case of
network connection failure.
A file with a sub-tree of the radio MIB is downloaded to the
MFS. All the objects of the sub-tree with their attributes are
present in the file, including the base object(s). The radio
synchronisation is performed as follows:
OMC MFS
Synchro File Action (filename, baseObjet
list)aGprsConfigurationFileStatus ON
Operation File download
Synchro File Response (global
status)aGprsConfigurationFileStatus OFF
Processing may send- Attribute value change,- State Change,-
Object creation.
Result File upload
Figure 2: Radio synchronisation scenario
4 Synchronise action specific: A list of base object instances
is added to the parameters for the CMIS synchronise action. The
instance types must be a mfs (bsc(cell)), a bsc(bsc+cell), a cell
or a mix of those types. The base object instance must be present
in the operational file but may not exist in the current MIB (in
this case the base object is created during the operation).
-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 14/19
Example of resynchronisation:
MFS MIB BEFORE RESYNCHRONISATION
MFS MIB AFTER RESYNCHRONISATION
1.3.67
1.3.67.1
1.3.67.1.21.3.67.1.1
1.3.67.2
1.3.67
operation File
result file
RADIOFILESYNCHRONISATION
1.3.67
1.3.67.1
1.3.67.2.11.3.67.1.1
1.3.67.2
1.3.67
Figure 3 - resynchronisation example
1.3.67
1.3.67.1
1.3.67.1.21.3.67.1.1
1.3.67.2
1.3.67
The MFS MIB before resynchronisation is made of 5 objects. The
user wants to align the MFS MIB on the OMC-R MIB. It uses the
radio-synchronisation with an operation file that containshe OMC-R
MIB.
operation File
result file
RADIOFILESYNCHRONISATION
A M-ACTION on CmisFile is sent with the operation and result
file in parameter.
1.3.67
1.3.67.1
1.3.67.2.11.3.67.1.1
1.3.67.2
1.3.67
Objects that are not in the operation file are deleted, Object
that are in the OMC-R MIB but not in the MFS MIB yet are created,
Object that are present in both case are modified to fit the final
MIB by the set action (1.3.67.2.1 in the Figure 3 -
resynchronisation example).
Important: Re-synchronisation does not mean that an existing
object in the MFS MIB before resynchronisation have been deleted
then re-created with diferent set-by-create and get-only attributes
in the final state.
The delete operation is made autonomously by the MFS for all
objects not present in the subtree of the base object5, the base
object is never deleted. Base object that is not present in the
subtree but present in the operational file is also created.
5 MFS, BSC or CELL object.
-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 15/19
4.2 Operation file format : create , set and action
Contrary to the MLU file format, this is not a delta file but a
snapshot of the MIB. In order to perform the delta at the MFS
level, the file must contain the structure of the sub-tree to be
updated. The sub-tree permits to delete the managed objects that
are not present in the MIB any longer. For each object, a creation
order is composed of an M-CREATE operation followed by an M-SET
operation with all the object attributes. This combination of two
operations allows creating or updating the remaining objects.
The file is ordered per operation. The operation file contains
the following CMIS operations:
CMIS operation Presence into the file
1. M-CREATE-Req Mandatory 2. M-SET-Req Mandatory 3. M-ACTION-Req
(alignDownAction) Mandatory for every cells inserted into the
file.
All the M-CREATE-Req operations are at the beginning of the
file, then, the M-SET-Req operations. There is one M-CREATE-Req
operation and one M-SET-Req operation for each object present in
the sub-tree. The set operation must range all attributes.
The M-CREATE-Req operations are given in the sequence according
to the containment tree order, following an in-depth path. More
precisely, the order is the following: the root of the sub-tree,
one of its children (level 1), one of the children of the latter
(level 2), the second child (level 2), , the second child of the
root (level 1)...
This file is exactly the one described in section 2.3.2.
When an M-CREATE-Req is read for an object that already exists,
an error is written in the result file, but this error is not taken
into account for the global status of the synchronisation
operation.
When an M-SET-Req contains attributes which are mandatory at
creation time and not replaceable after (get only attributes), an
error is written in the result file, but this error is not taken
into account for the global status of the synchronization
operation. This error can occur because the attribute list of the
M-SET-Req and of the M-CREATE-Req is the same.
No information is written in the result file about object that
are deleted during the re-synchronization operation, but
objectDeletion Notification(s) is sent to the OMC-R.
Deletion of object can not fail. In fact, only a processing
failure can abort the object deletion. I.e. there is no restriction
known yet for object deletion after a resynchronization, if an
error occurs, a following trial will be successful.
-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 16/19
5 RADIO RE-INITIALISATION
MFS reinitialisation not supported from B8 (3BKA20CBR131120) for
the whole MFS .
NB : The MFS does not reject the action if received from the OMC
but there is a high risk of GOM crash during the processing.
5.1 Principles
The radio re-initialization is used to change a part of the
radio MIB. It is performed on an existing MIB and consists in
deleting all the objects of this part of the MIB before performing
the initialization.
The re-initialization is performed as follows:
OMC MFS
Activate File Action (filename)aGprsConfigurationFileStatus
ON
Result File download
Activate File Response (global
status)aGprsConfigurationFileStatus OFF
Processing may send- Attribute value change,- State Change,-
Object creation,- Object Deletion. alarm indication.
Result File upload
Figure 4: Radio re-initialization scenario
5.2 Operation file format : create, set , action and delete
The operation file is based on CMIS operations. The file begins
with an M-DELETE operation on the object instance of the sub-tree
root. It contains the following CMIS operations:
CMIS operation Presence into the file
M-DELETE-Req Mandatory M-CREATE-Req Mandatory M-SET-Req
Mandatory for relationship attributes M-ACTION-Req
(alignDownAction) Mandatory for every cells inserted into the
file
-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 17/19
Contrary to the synchronisation file, the M-SET-Req operation is
not mandatory for all object instances. The M-SET-Req operations
are present in the file for the attributes, which contain links to
other objects, and which can not be initialised prior to the
creation of these objects.
All the M_DELETE-Req operations not necessarily appear at the
beginning of the file. The order of the operations must only follow
the dependence tree, The M_DELETE-Req operation can be performed
via a scoped operation.
5.3 Result file format
This file is exactly the one described in section 2.3.2.
-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 18/19
6 APPLICATION TO INFORMATION MODEL
6.1 CMIS attribute
One attribute have been added to the object
aGprsManagedElementExtension, the aGprsConfigurationFileStatus
which can have two values: ON / OFF.
6.2 CMIS actions
Two CMIS actions must be defined in order to:
Activate File;
Synchronise the radio configuration;
These actions are defined on the aGprsManagedElementExtension
managed object and are aGprsSynchroConfigurationFile and
aGprsActivateConfigurationFile.
6.3 Model consistency
When an object is deleted, the MFS ensures that the objects,
which have a pointer on the deleted object, are updated in order to
avoid dangling pointers. A reference, which is implemented using a
simple identifier instead of a pointer, remains unchanged.
example: Deletion of object B.
- If the attribute "relationship" is a pointer to B, it is set
to NULL by the MFS.
- If the attribute "relationship" is an identifier (=B), it is
not (remains unchanged).
Object A
relationship
identif ier
o therparam e ters
identif ier
Object B
otherparam e ters
When a new object is created, the OMC-R (the operator or by
sofware) has to take care of the relationship attributes. And so,
it is responsible for checking and updating the relationship
attributes related to the new object to make the configuration
operational.
If the configuration is not consistent, the MFS will not reject
it (see below). In this case, the configuration will stay not
operational until the OMC-R makes the necessary corrections.
-
ED 06 RELEASED MFS/OMC-R Radio File Interface Specification
EVOLIUM 3bk09647fcadpbzza-ed6rl.doc 08/12/2004
3BK 09647 FCAD PBZZA 19/19
As the OMC-R is the master of radio data, the MFS can not reject
any radio files. So, to make it possible, all the relationship
attributes defined to objects related to radio domain are
identifiers (no pointer). This allows a complete flexibility in
term of creation/ destruction of objects related to radio
domain.
For instance, when a aGprsBssFunction is created, the OMC-R
takes care that the aGprs2MbTTP and the aGprsNse objects are
correctly linked to it. If there are not, the bssFunction will stay
disabled/ not installed.
managed Element
aGprs2MbTTP aGprsBssFunctionaGprsNse
The aGprsBts and aGprsBssFunction objects can be deleted by the
OMC-R even if their administrative state is unlocked. Note that, in
this case, the MFS will autonomaticaly lock them before to delete
them.
END OF DOCUMENT