OMC-R-MFS Radio File Interface Specification.pdf

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



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. 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


radio file format should compressed


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.




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




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




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.




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.


aGprsBssFunction

aGprsBtsSiteManager

aGprsBts


Base ObjectInstance

- CELL basis (aGprsBts). The scope of the action is the radio configuration of one CELL.


aGprsBssFunction

aGprsBtsSiteManager

aGprsBts


Base ObjectInstance




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.




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.




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.




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.




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).




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.




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).




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.




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:


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)...


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.




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:


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




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





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.




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

Date post:	14-Nov-2015
Category:	Documents
Upload:	vu-anh-tuan
View:	234 times
Download:	2 times

OMC-R-MFS Radio File Interface Specification.pdf

Documents