TM Forum's MTOSI standard: Setting the Context

MTOSI stands for Multi-Technology Operations Systems Interface. It is a standard specified by TM Forum. It is now part of TM Forum's Interface Program (TIP).

Why is it called "multi-technology"? Why do you need to worry about it? What does it really do? How does it relate to other TM Forum standards and initiatives (often, quite confusing for starters!)? This article attempts to explain the answers for these questions.

This article is organized as follows: 

• Section "1 - Intent" provides a summary of what MTOSI aims to do.
• Section "2 - Related TM Forum Standards" provides a description of how MTOSI is related to some of the other TM Forum standards and initiatives.
• Section "3 - Motivation" provides scenarios that illustrates the problem(s) MTOSI addresses.
• Section "4 - MTOSI Description" provides more details on MTOSI.

1) Intent

The intent of TeleManagement Forum's (TMF) Multi-Technology Operations Systems (MTOSI) is to provide open and standards-based interfaces between OSSs (e.g., Service Activation systems, Inventory systems, Network Management Systems, Element Management Systems, etc.). For a detailed exploration of OSS/BSS systems, see my earlier post titled "Telecom OSS/BSS: An Overview".

2) Related TM Forum Standards

2.1 Relationship with MTNM

TeleManagement Forum's (TMF) Multi-Technology Operations Systems Interface (MTOSI) started as an MTNM (Multi-Tehchnology Network Management) substream sometime in 2003. Lets discuss MTNM first.

MTNM provides CORBA-based Element Management Layer (EML)-to-Network Management Layer (NML) interfaces for the management of "multi-technology" networks (SONET, SDH, PDH, ATM, Frame Relay, DSL, connectionless networks such as Ethernet, etc.). However, it can also be used to support a single technology such as ATM. Examples of management areas are: connection management, NE and EMS configuration, network inventory discovery, euqipment inventory management, performance monitoring, alarm surveillance and event reporting, etc. MTNM can also be used to manage a particular subset of a management area - say, alarm surveillance.

Around the time MTNM 3.5 commenced, it was realized that several vendors were using MTNM by converting the CORBA IDLs to XMLs, due to lack of XML based interfaces. Enter MTOSI.

MTOSI has gradually taken sets of MTNM interfaces, generalized the operations systems to operations systems interactions and created XML, SOAP Web services based interfaces - recasting and extending MTNM. Like MTNM, it provides a single interface for the management of many technologies. Moreover, MTOSI has had the goal to make XML interfaces independent of the underlying transport (HTTP, JMS, etc.)

2.2 Relationship with TIP and mTOP

MTOSI has been part of TM Forum Interface Program (TIP) since April 2008. Multi Technology OSS Program (mTOP) coordinates advances in the SOAP and XML based MTOSI interface standard, as well as the CORBA/IDL based MTNM standard. MTOSI service classifications are based on the eTOM model, while the information model is based on SID and MTNM data models.

2.3 Comparision with OSS/J

MTOSI APIs are focused towards providing interfaces at the service, network and element management layers. OSS/J on the other hand aims to provide open interfaces across the spectrum of both OSS and BSS. OSS/J APIs, unlike most MTOSI APIs are network technology independent [1]. OSS/J APIs are entity centric unlike MTOSI APIs that are task-centric. OSS/J provides a generic set of operations on "Managed Entities" [1]. There are efforts underway to draw the OSS/J and MTOSI communicaties together, and we may see a common goals and plans for migration for both OSS/J and MTOSI in the future.

3) Motivation

Element Management Systems (EMS) typically manage the functions of Network Elements (switches, CPU and remote hubs, gateways, routers, susbcriber line units, etc.) from a single vendor. Examples of such management functions include receiving and executing commands sent by upstream activation systems, feeding equipment status data back to upstream systems such as network and trouble management systems, etc. Moreover, the EMS may be able to manage functions related to a single technology (e.g., ATM, SONET, etc.) for a subset of management area (e.g., performance monitoring). Therefore a service provider environment typically has several types of EMS. Typically a Network Management System (NMS) manages functions of many EMSs. To be easily portable across different NMS systems, an EMS vendor can provide MTOSI based standards interface. This would enable easy integration of the EMS with various NMS that service providers could use.

Lets consider another example. A service activation system (an OS) may allow an order management system (also an OS), to request activation of a given service via a service request. The service activation system (an OS) may in turn need to send requests to multiple NMS and EMS OS's to complete the service activation request. A service provider environment in all likelihood contains multiple service activation systems as well as multiple EMS's. If each of those provided proprietary interfaces containing proprietary information models: a) the order management system must be integrated with each of the service activation interfaces, and b) the service activation systems must be integrated with the relevant EMS interfaces. With many services being added on frequent basis, this can easily turn into a nightmare. Utilizing standards-based interfaces provided by MTOSI the integration becomes lot more easier, reducing costs and increasing agility.

Lets consider yet another example. Say, an operator uses Telcordia TIRKS system to administer Layer 1 facilities and equipment while it uses a seperate OSS inventory system to administer Layer 2/3 (logical inventory) and higher services. TIRKS provides an open interface (data dictionaries and XML message definitions) using MTOSI which can be used by the OSS inventory systems to receive messages generated by TIRKS systems (such as inventory update notifications) and to send messages to the TIRKS system.

Similarly, a fault managent system may need to subscribe to alarm reports based on filtering conditions and may also handle subsequent reporting of alarms to subscribed OSs. Similarly, a manager fault management system may receive alarms from several technology-specific fault management system via active alarm sync.

4) MTOSI Description

MTOSI defines OS-to-OS (OS stands for operations systems) interfaces for service and resource management, where OS functionality can be at the levels of Element Management Layer, Network Management Layer or the Service Management layer, in the Telecommunications Management Network (TMN) Logical model.

Examples of such OS in this context include: Inventory Management, Performance Management Systems, Fault Management Systems, Service Activation, Service Assurance, CRM systems such as Order Entry system, Network Management systems, Element Management Systems (EMS). Refer to my earlier post titled "Telecom OSS/BSS: An Overview" for a description of some of these.

Note, that MTOSI is not concerned with EMS-to-NE API, which is typically based on protocols such as SNMP, TL or CMIP. Nor is it concerned with internal implementation details such as an internal inventory model - it only provides a data format and a number of operations around retrieving or modifying the data.

Management functions covered by MTOSI include (but not limited to): 

• Inventory Retrieval, Inventory Update Notifications, Enhanced Inventory Retrieval (attribute value matching based on XPath), Multi-Event Inventory Notifications (ability to send multiple inventory updates in a single notification)
• Alarm Reporting, Active Alarm Retrieval
• Service Activation
• Service Inventory Management
• Resource configuration and activation
• Performance management and maintenance commands
• Multi-Action and Request Transactions (MART) (i.e., ability to package multiple requests into a single message)

The output of the MTOSI effort can be downloaded from the TM Forum Web site. The output is partitioned into something called as Document Delivery Packages (DDPs) - often organized based on functional areas (such as resource inventory management). The framework DDPs contain the generic aspects applicable to all other DDPs while the Data Model DDPs contain aspects related to entities, data structures, attributes and states. Each DDP also contains the following set of documents:

• TMF 518, MTOSI Business Aggreement (BA): Identifies the requirements and use cases to be supported by the interface.
• TMF 612, MTOSI Information Aggreement (IA): UML description of the interface.
• TMF 864, MTOSI Interface Implementation Specifications (IIS): Maps the UML model to XML (WSDL, XSD, bindings, etc.)
• Supporting documentation

5) References

[1] "Bridging the Gap Between MTOSI and OSS/J" by Nigel Davis, John Reilly and Suresh Bhandarkar

[2] "Implementing NGOSS with MTOSI"
[3] "A very short history of mTOP" (Requires login to TM Forum site)
[4] Tim McElligott, "MTOSI brings OSS Integration a Step Closer", Nov 2005,
[5] "Designing a Standards-Based Application", March 2009,
[6] Stephen Fratini, Irene McGoey, Garry Grimes and Enrico Grosso, "Introduction to the TM Forum's Multi-Technology Network Model", National Fiber Optic Engineers Conference, 2001