MT2
Extending OMCI support
The perfect tool to prepare for a smooth deployment
MT2
Rue Vincent d'Indy
F-07300 Tournon
Tel: +33 475 07 99 36
Fax: +33 475 07 99 31
www.mt2.fr
MT2 OMCI support is based on pseudo-XML descriptions of the OMCI managed
entities, and may be readily extended by simply adding new description files to the
relevant directories.
The figure below shows the populating of a ONU OMCI database for both analyzer (NIVA)
and emulator (eOLT) functions.
NIVA eOLT ONU
MT2Browser launch MT2Browser launch
Loading XML descriptions Loading XML descriptions
from OMCI/G988-1010 from OMCI/TR247
Creating Template database Creating Template database
Boot-up
PLOAM: Configure Port ID
Create shadow OMCI Create shadow OMCI
Database for ONU Database for ONU
OMCI: MIB_upload
...
OMCI: MIB_upload response
Entity X
is entity X is entity X
No in template No in template
database? database?
display error Ignore
message Yes Yes
instanciate entity X instanciate entity X
in ONU database in ONU database
OMCI: Create: Entity Y
OMCI: Create Response: Success
is entity Y is entity Y
No in template No in template
database? database?
display error Ignore
message Yes
Yes
instanciate entity Y instanciate entity Y
in ONU database in ONU database
OMCI: Set Entity X, Attribute A
OMCI: Set Response: Success
update entity X instance update entity X instance
in ONU database in ONU database
OMCI: MIB_reset
OMCI: MIB_response: Success
reset ONU Database reset ONU Database
OMCI Database Timeline
There are no limits to the number of ONUs & associated OMCC channels supported: for
each new ONU appearing on the PON, the browser will create shadow OMCI databases
for both the analyzer and the emulator functions.
At launch-time MT2Browser will load XML descriptions for both analyzer and emulator
functions and create a template library containing all the recognized OMCI entities.
The XML descriptions are by default located in:
OMCI/G988-1010/ for the NIVA analyzer function
OMCI/TR247 for the eOLT emulator function
The location of the directory may be changed in Preferences->OMCI:
NIVA OMCI directory
eOLT OMCI directory
OMCI directories configuration
Analyzer and emulator templates are mostly the same, but may differ: one may prefer a
more detailed and readable analysis (Message and OMCI Erd views), while conveniency
is paramount for the eOLT function (the object defined in the eOLT templates defines the
access through the javascript API).
Each entity XML description file must be present in both the NIVA and the eOLT OMCI
directories.
Understanding/Adding an XML description
We recommend to create one XML description file for each OMCI entity.
In the section below we analyze the XML description of the OMCI entity Physical path
termination point Ethernet UNI, from the file OMCI/TR247/PPTPEthernetUNI.xml, as
derived from G.988 section 9.5.1:
<omci:object name="PPTPEthernetUni" value="11" pointer="Circuit_Pack" docref="G.988:178">
omci:object indicates that this XML element defines an OMCI entity.
The XML name attribute defines the name of the entity which will be used to refer to it in the
javascript and in the message view. We recommend that it be the same as the description
file name, and we adopted the convention of removing spaces in the corresponding entity
name in G.988 (but is is not mandatory).
The XML value attribute provides the Managed Entity identifier as defined in G.988 Table
11.2.4-1 Managed entity identifiers.
The XML attribute pointer indicates that this entity is pointed to by an instance of the entity
Circuit_Pack (Circuit Pack), and that the Managed entity ID of the PPTPEthernetUNI instance
has the same value as that of the instance of Circuit_Pack. This attribute is only used in
analysis.
the XML docref attribute is optional and indicates the standard document and page from
where the description is derived.
For each of the OMCI attributes defined for the entity, an omci:attribute element MUST be
added to the omci:object section. The attributes MUST be ordered as they are in the OMCI
descriptions in G.988.
The first attribute is, thus, always the Managed entity ID:
<omci:attribute name="meid" type="Short" attribute="m" />
The XML attribute name defines the name of the attribute. For the Managed Entity ID
attribute it MUST be "meid". For other attributes names, we have followed the camel-back
convention (e.g.: Expected Type becomes ExpectedType).
The type XML attribute defines the format and size of the attribute.
Basic types are defined in base_types.xml.
One can create intermediate types for complex attributes, but all types must at the end
resolve into base types. Complex types only support 2 levels of indirection (the structure
can only have 2 levels).
The definition of intermediate types is described in more detail in the section Intermediate
Types below
The XML attribute attribute defines the 'mode' of the attribute, as indicated in G.988:
`m` is only used for the meid, and stands for mandatory: it MUST be present in all
messages applying to the entity. The meid is returned by the OMCI.Create
javascript command.
`r` means Readable
`w` means Writable
`o`means Optional. Attribute which support is mandatory is the default, and is not
indicated
`s` means Set-By-Create
The final mode is a concatenation: rws means Readable, Writable and Set-By-Create,
ro Readable, Optional, etc.
The second OMCI attribute for the Physical path termination point Ethernet UNI is the
Expected Type. It is defined as (in G.988):
This attribute supports pre-provisioning. It is coded as follows:
0 Autosense
1 to 254 One of the values from Table 9.1.5-1 that is compatible with an
Ethernet circuit pack
Upon ME instantiation, the ONU sets this attribute to 0. (R, W) (mandatory)
(1 byte)
It could therefore be defined in a first step as:
<omci:attribute name="ExpectedType" type="Byte" default="0" attribute="rw" />
The XML default attribute indicates the default value for this attribute. This may be the
default value as indicated in G.988 for entities instantiated by the ONU. It can also be the
default value which will be used by the eOLT for Set-By-Create attributes.
For the eOLT, this is enough.
For analysis, However it is possible to further describe the values in use, by defining an
enum intermediate type:
<omci:enumType name="Plugin_Unit_Type" base="Byte">
<omci:enum>
<omci:when value="0" string="No LIM" />
<omci:when value="1" string="Various ATM based UNIs" />
<omci:when value="2" string="Various ATM based UNIs" />
<omci:when value="255" string="Plug-and-play" />
</omci:enum>
</omci:enumType>
Note the XML attribute base in the enum declaration. This indicates the underlying type of
the enumeration.
Intermediate types may be defined in the same XML file as the entity they are used for, or
in separate files (which allows to re-use intermediate types across entities).
Following the example, the ExpectedType attribute can then be redefined as:
<omci:attribute name="ExpectedType" type="Plugin_Unit_Type" default="0" attribute="rw" />
Note that in for eOLT scripting, one has to use the final byte values, even when the enum
intermediate type is defined.
The remaining attributes for the PPTPEthernetUNI entities are enums of varying size.
At the end of the PPTPEthernetUNI declaration we have:
<omci:avc name="ARC" bit="12" />
<omci:alarm name="LAN-LOS" bit="0" />
</omci:object>
The omci:avc element defines the Attribute Value Change, as defined in the entity G.988
description. The XML attribute bit indicates the bit position in the attribute mask (which is
the same as the attribute ordinal number in the entity's attributes list).
The omci:alarm element defines an Alarm on this entity, as defined in the entity G.988
description. The XML attribute bit indicates the bit position in the attribute mask (which is
the same as the attribute ordinal number in the entity's attributes list)
Intermediate Types
Basic types are defined in base_types.xml, but it is possible to define intermediate types
for more complex structure:
Enumerations, as seen in the example
the syntax is:
<omci:enumType name=[Name of the type] base=[Type of the enumerated values]>
<omci:when value="[enumerated value]" string="[printable string]" />
<omci:default string="[Default value string]" />
</omci:enumType>
The default value declaration is optional.
javascript OMCI function accesses MUST use the actual value.
Arrays
An array is the finite repetition of element of the same type.
The syntax is:
<omci:arrayType name=[Name of the type] base=[Type of the enumerated values]>
<omci:occurence value="[Number of occurrence of the array elements]" />
<omci:format_separator value=[separator string] />
</omci:arrayType>
For the eOLT descriptions, the format_separator value MUST always be ;
(semicolon).
However, javascript access to the array MUST use brackets ([, ]) and ,. E.g. (for
the array typed VLANFilterList):
OMCI.Create(OMCC, "VLAN_Tagging_Filter_Data", {meid: BPCD1, VLANFilterList: [CVID1,
CVID2], ForwardOpr: 16, NumberOfEntries: 2});
For the NIVA descriptions, any separator may be used.
Structures
A structure is a type made of a finite number of elements (members) of different
types.
The syntax is:
<omci:structType name=[name of the type]>
<omci:element name=[name of element] type=[type of element] />
...
</omci:structType>
The syntax in eOLT javascript uses {, } and ,. E.g (for the structure type
DynamicACLTable):
OMCI.Set(OMCC, "Multicast_Opr_Profile", MOP1, {"DynamicACLTable": { "TableIndex":
0x4000, "GEMPortID": GEM2, "VlanID": CVID1, "SourceIPAddr": IP_S1, "DestIPAddrStart":
IP_G1, "DestIPAddrEnd": IP_G1, "ImputedGroupBandwidth": 0, "Reserved": 0}});
The depth of complex types (Arrays and Structures) is limited for eOLT descriptions:
there can be a structure containing arrays, or an array containing structures, but not
arrays containing arrays, or structure containing structures, and there can not be
more than one level of indirection.
Pointers
When an attribute is actually pointing to another entity (meid), it may be declared
as:
<omci:attribute name="[attribute name]" type="[attribute type]" default="[attribute default
value, if defined]" attribute="[mode]" pointer="object:[Name of the object pointed to]" />
The pointer XML attributes indicates the name of the entity it points to.
However, in many cases, the type of the pointed object depends on the value of
another attribute in the entity. In such cases, an intermediate pointer type may be
used:
<omci:pointerType name="[pointer type name]" base="Pointer">
<omci:switch field="[Name of the attribute which defines the pointed object type]" >
<omci:when value="[value 1]" object="[pointed object name]" />
<omci:when value="[value 2]" object="[pointed object name]" />
...
</omci:switch>
</omci:pointerType>
Note on OMCI tables: in many entities, attributes are defined as tables (for example: the
Received frame VLAN tagging operation table attribute in the Extended VLAN tagging
operation configuration data entity), but what is sent in OMCI messages at a time is
always 1 element of such tables. In such a case, the description of the attribute MUST
describe the element, not the table itself.
