Fundamentals of EMS, NMS and OSS/BSS
by Jithesh Sathyan
CRC Press. (c) 2010. Copying Prohibited.
Reprinted for Mahesh Sadashivappa Ghanti, Accenture
[Link]@[Link]
Reprinted with permission as a subscription benefit of Skillport,
[Link]
All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or
other forms without written permission is prohibited.
Fundamentals of EMS, NMS and OSS/BSS
Chapter 25: Standard Interfaces
Overview
This chapter is about OSS interfaces for interaction. Two of the most popular information models in telecom domain, Multi-Technology
Operations System Interface (MTOSI) and OSS through Java Initiative (OSS/J) are discussed in this chapter. How these two standards can
complement each other is also covered in this chapter.
25.1 Introduction
There are multiple operation support systems currently available in the telecom market. In a service provider space, multiple OSS solutions
need to interoperate seamlessly to reduce operational costs and improve operational efficiency. To make this possible the interfaces for
interaction need to be standardized. Most OSS solution developers are making their products compliant to MTOSI or OSS/J interface
standards.
In current industry, compliancy to standards is more a necessity. Let us take a simple example of a simple fault management module. Now the
network provisioning module might request active fault alarms using the interface call "getAlarm-List ()," the inventory management module
might request active fault alarms using the interface call "getActiveAlarms ()," and the event management module might request active fault
alarms using the interface call "getFaultLogs ()." On the other end, the fault management module might be exposing the interface
getActiveFault () for other modules to query and get the active alarm list as response.
One solution to fix this problem is to write an adapter that translates the call between modules, like getAlarmList () from network provisioning
module to getActiveFault () that the fault management module can understand. In the example we are discussing, the solution of developing
adapters will result in three adapters for the fault management module alone. So in a service provider space where there will be many OSS
solutions, the number of adapters required would make interoperability costs huge. Again when a new OSS solution is introduced, a set of
adapters needs to be developed for the modules it is expected to integrate with. So adapters are not a viable solution that would be cost
effective to the service provider.
Another option to fix the problem of interoperability is to have standard interfaces. Let us look into how this works for the example we are
discussing. If it is decided by the standardizing body that getActiveFault () is the standard interface for getting active alarms from the fault
management module, then the service provider can request compliancy to standard for modules that interact with the fault management
module. That is the fault management module that will respond only to getActiveFault () request and any module compliant to standard that
interacts with the fault management module is expected to use the standard interface. When a new module is introduced that is compliant to
standards interoperability with fault management module, this will not be an issue.
This chapter explains the fundamentals of MTOSI and OSS/J so that the reader can understand the significance of interface models and how
an interface model can be used in developing applications that are compliant to standards. The common terminologies used in the standard
documents on interface models are also discussed in this chapter.
25.2 MTOSI Overview
Before we discuss MTOSI, let us first give a brief overview on MTNM the predecessor of MTOSI. MTNM was formed by combining the ATM
information model (ATMIM) team that was formed to address ATM management and SONET/SDH information model (SSIM) team. MTNM
was one of the most deployed interface suites of TM Forum. It includes a business agreement document titled TMF513, an information
agreement titled TMF608, a CORBA solution set titled TMF814, and an implementation statement titled TMF814A. Popular NMS solutions
like AdventNet Web NMS provide support for TMNF MTNM interfaces. MTNM was mainly focusing on management of connectionless
networks with an emphasis on Ethernet and control plane-based networks.
When most OS suppliers started converting MTNM IDL to XML, TMF started the MTOSI group. This group took a subset of MTNM and
generalized the procedures for OS-OS interactions (see Figure 25.1) on an XML-based interface that was most required for the telecom
market. A major MTOSI goal is to make the XML interface independent of the transport and gradually supports more transports.
Use of MTOSI has many benefits to different players in the telecom value chain. To equipment vendors, MTOSI results in reduction of
development costs and provides a faster time to market. It also lowers deployment risks and enables differentiation. Service providers benefit
by a reduction of integration costs and faster time to market for new service rollout. Use of MTOSI helps in reducing development cost for
software vendors. It reduces relationship costs and provides easier maintenance and testing that enables product differentiation. For system
integrators, MTOSI simplifies interoperability testing and provides faster time to market for integrated solutions. The technical skills and
training requirements are also reduced with the use of MTOSI.
Page 2 / 7
Reprinted for OET7P/1248301, Accenture CRC Press, Taylor and Francis Group, LLC (c) 2010, Copying Prohibited
Fundamentals of EMS, NMS and OSS/BSS
Figure 25.1: MTNM (point to point) and MTOSI (bus) structure.
MTOSI leverages the knowledge gained from MTNM deployments and artifacts. It supports multiple synchronous and asynchronous
communication styles to satisfy the interaction needs. It supports bulk inventory and alarm operations, and replaces many fine grain operations
that were advocated in previous interface specifications. In XML, MTOSI supports most Web service standards including WDSL, SOAP, and
XSD. It can be seen that MTOSI offers support for service oriented architecture (SOA) and enterprise service bus (ESB).
In MTOSI, the requirements of network management or service resource management have been specified in terms of the entities visible
across the interface and the service requests that may be invoked across the interface. The interface agreement document contains the data
model describing the entities and associated service requests while the business agreement document contains requirements for the visible
data entities and the associated service requests.
The information exchange infrastructure through which OSS solutions interact is called a common communications vehicle or CCV. The CCV
is used to publish new entities. The OSS has direct access to the CCV. The existence of the entity instance on the CCV is announced by the
publishing. Storage and naming of the entity instance is done by naming OS. The entity name could be the name used to announce the entity.
The discovering OS and the naming OS need not be the same OS for any particular entity.
The following attributes of the entities are visible across the interface:
n Name: The entity instance on the CCV can be uniquely identified using the "name" attribute. Once the naming OS sets the attribute, its
value does not vary for the life of the entity.
n Discovered name: In the case where the OS that publishes the entity on the CCV is not the naming OS, the name of the entity is known as
the discovered name. This attribute may be left empty if the naming OS publishes the entity first on the CCV. The value of the name
attribute and the discovered name attribute of the entity can be set to the same value or different value.
n Naming OS: The OS that is responsible for setting the "name" of the entity also sets up the naming OS attribute and this attribute
represents an identifier for the steward of the entity. There is a unique naming OS for each entity published on CCV.
n Alias name list: The attribute is a list of name-value pairs for the entity. The name refers to the type of alias and the value component holds
the alias itself.
n User label: It is an optional attribute that represents the "user friendly" name for the entity.
n Owner: It is an optional attribute that is used to identify the owner of the entity.
n Vendor extensions: This attribute is used by vendors to further qualify and extend the entity characteristics.
MTOSI provides steps to discover new network entities such as managed elements and topological links in cases where two different
suppliers are providing the network inventory management OS and the network discovery/activation OS. Another interesting feature in MTOSI
is backward and forward compatibility.
n Backward compatibility: This feature allows a new version of a client OS to be rolled out in a way that does not break existing server OSs.
An older version of a message can be sent to a client OS (by server OS) that understands the new version and still have the message
successfully processed.
n Forward compatibility: This feature allows a new version of a server OS to be rolled out in a way that does not break existing client OSs.
Page 3 / 7
Reprinted for OET7P/1248301, Accenture CRC Press, Taylor and Francis Group, LLC (c) 2010, Copying Prohibited
Fundamentals of EMS, NMS and OSS/BSS
The server OS can send a newer version of an instance and still have the instance successfully processed.
MTOSI allows a client OS to perform multiple operations on multiple objects using a single request to a server OS. In this approach, the
transactional logic is delegated to the server OS facilitating in performance tasks like configuration of a managed element and all associated
equipment and ports. Also the same operation can be performed on a large number of objects of the same type in an efficient manner. These
requests may contain multiple actions and/or objects and the requests may be of long duration.
25.3 MTOSI Notifications
In this section, the notification feature is taken as a sample MTOSI feature for discussion. Some of the event notifications provided by MTOSI
include:
n Creation of a particular object
n Attribute value changes for attributes of an object
n Conveying all the change information in single notification
The interface offers capability for both single event inventory notifications like the creation of a particular entity or attribute value changes for
several attributes of a given entity, as well as multievent inventory notifications, which is a direct method for getting bulk inventory updates from
the source OS to other interested OSs.
To get a feel of notification generation like object creation notification (OCN) and attribute value change (AVC) notification, let us discuss two
methods by which a new network entity is announced on CCV. The first method requires the discovery OS to keep track of the planned
entities, and the network entities to be planned and named at the interface before they are discovered. The steps in the first method are:
1. A network entity is entered into the inventory OS.
2. The network entity is represented by the object created by inventory OS.
3. This object is transferred to the planning resource state. The network entity has not been installed now.
4. The "Object Creation Notification" is sent from the inventory OS to the discovery OS.
5. The network entity is actually installed later.
6. The discovery OS detects the installed entity and issues an "Attribute Value Change" notification on the resource state of the network
entity.
7. This results in change from planning to installing.
In the second method the new network entity is first announced on the CCV by the discovery OS before it is given a unique name. Here we will
deal with object discovery notification (ODscN) and object creation notification (OCN). The steps in the second method are:
1. A network entity that has not been announced by the inventory OS at the interface is directly detected by the discovery OS.
2. The discovery OS then sends an object discovery notification to the notification service.
3. The notification is received by the inventory OS.
4. The new object is given a name by the inventory OS.
5. Inventory OS issues an object creation notification.
6. Other modules like discovery and activation OSs receives and processes the OCN.
Service interfaces and data entities define interface implementation. The service interfaces consist of operations and notifications that have
parameters. Attributes make up data entities. Additional service interfaces like operations and notifications are needed as the interface is
extended. Interface elements like operations will not be deleted when passing from one version to the next unless an error with an existing
element is identified. Instead of "delete" term, "Deprecate" is used with respect to parameters for operations and notifications, since it may be
easier to leave the operation/notification signature alone and just deprecate usage of a particular parameter.
25.4 OSS/J Overview
While the NGOSS program of TMForum focuses on the business and systems aspects, essentially the problem and solution statement of
OSS-solution delivery, the OSS/J program focuses on the implementation, solution realization, and deployment aspects using Java
technology. The OSS through the Java (OSS/J) initiative defines a technology specific set of API specifications. In addition to API
specifications, OSS/J also includes reference implementations, technology compatibility kits, and multitechnology profiles for OSS integration
and deployment.
The core business entities (CBE) model of shared information/data (SID) model that helps to provide a technology neutral implementations
view of the NGOSS architecture is used by the OSS/J API specifications. The Java 2 Platform Enterprise Edition and EJB-based Application
Architecture are the enabling technologies in OSS/J, used as tools for developers to easily develop applications. The J2EE platform offers
faster solution delivery with a reduced cost of ownership. The Enterprise JavaBean (EJB) component architecture is designed to hide
complexity and enhance portability by separating complexities inherent in OSS applications.
Page 4 / 7
Reprinted for OET7P/1248301, Accenture CRC Press, Taylor and Francis Group, LLC (c) 2010, Copying Prohibited
Fundamentals of EMS, NMS and OSS/BSS
Rapid integration and deployment of a new OSS application can be done by OSS through Java initiative's framework due to standard EJB
components that are already equipped with connectors. Application integration capabilities are provided for server-side applications by APIs
that are defined within the initiative using J2EE platform and EJB architecture.
A standard set of APIs using Java technology for OSS and BSS can be defined and implemented by using OSS through Java initiative.
Members of OSS/J are leveraging standards from 3rd Generation Partnership Project (3GPP), Mobile Wireless Internet Forum (MWIF), and
the TeleManagement Forum (TMF) to implement common Java APIs and provide a source code that can be made freely available to the
industry. OSS/J implementation groups include telecom equipment manufacturers, software vendors, and systems vendors that are formed to
develop and implement interoperable and interchangeable components to build OSS applications.
Addressing the lack of interoperable and interchangeable OSS applications for the OSS industry is the goal of the initiative. Developing and
implementing common APIs based on an open component model with well-defined interoperable protocols and deployment models serve to
accomplish the goal.
OSS/J initiative is performed under the open Java community process (JCP). Using JCP the initiative will develop the following for each
application area:
n Specification documents: It details the interface APIs.
n Reference implementation (RI): This is a working version that facilitates use of the APIs.
n Technology compatibility kit (TCK): A suite of tests, tools, and documentation that will allow third parties to determine if their
implementation is compliant with the specification.
Production of demonstration systems to validate the OSS/J APIs against suitability for supporting actual field scenarios is a major goal of OSS
through the Java initiative. These systems should also meet performance and scalability for usage in actual field scenarios. Defining OSS
through Java APIs and maturing APIs from other sources results in the addition of more complete business scenarios to the demonstration
systems.
The OSS applications are divided into three fundamental parts by the J2EE application model. The three parts are:
n Components: The application developed is comprised of a set of components. This makes components the key focus area for application
developers.
n Containers: It provides service transparently to both transaction support and resource pooling. Using containers, component behaviors can
be specified at deployment time, rather than in the program code. Containers also provide security in addition to transaction support.
n Connectors: Connectors define a portable service API to plug into existing OSS vendor offerings. It is a layer beneath the J2EE platform
and promotes flexibility by enabling a variety of implementations of specific services. System vendors can conceal complexity and remote
portability by implementing containers and connectors.
Use of OSS/J has many benefits to different players in the telecom value chain. To equipment vendors, it facilitates integration of equipment
with more vendor products. Service providers are able to develop agile solution and improve interoperability using OSS/J component
architecture. To software vendors it provides a common API support for across-the-board integration. This accelerates the delivery of new
products, lowering integration and maintenance costs. The use of OSS/J will reduce integration costs for system integrators.
Various commercial off the shelf (COTS) and legacy applications, both network and customer facing, are integrated by the OSS systems.
OSS/J initiative works on specific application areas in OSS domain and uses J2EE, EJB, and XML technologies for its development. APIs
and message structures are defined for each application by the implantation group so that the OSS components can be developed and
assembled into complete solutions. APIs are specified and implemented as EJB components. OSS applications are developed using these
APIs.
OSS/J is emerging as a widely accepted OSS/BSS standard that helps Telco to realize standardization of interface, benefiting the service
providers with vendor independence. OSS systems developed the integration approach and construction approach using J2EE technology.
Integration approach is intended to integrate existing applications. Construction approach develops EJB-based applications, where both
application and its serving components are in the container.
Easier portability and rapid application development are possible through EJB. Based on the standardized APIs, it is possible to develop
vendor independent EJB connectors for various protocols like CMIP, SNMP, TL1, and the knowledge can be reused for multiple OSS/J
systems. Developing EJB connectors itself as COTs components offers many opportunities and the knowledge can be reused for developing
connectors for proprietary protocols also.
OSS/J model can address the impact of the emergence of rapid service creation environments like IP multimedia subsystems (IMS) and
service delivery platforms (SDP) on traditional OSS/BSS systems. OSS/J delivers standard functional OSS APIs, each including
specifications, reference implementations, conformance test suites, and certification process and source codes. Open IT standards form the
basis of OSS/J technology.
Use of OSS/J leads to a market of interoperable and interchangeable OSS components. OSS/J APIs include EJB and XML/JMS profiles, WS
profiles, and WSDL interfaces for the common API. Vendors can be compliant to OSS through Java API by supporting any one of these
profiles. Though OSS/J is generic it can be specialized to be model and technology specific. It provides coverage throughout the eTOM
processes. OSS/J can be extended to meet specific operational requirements by use of a disciplined extension mechanism. It also supports
metadata and queries.
Page 5 / 7
Reprinted for OET7P/1248301, Accenture CRC Press, Taylor and Francis Group, LLC (c) 2010, Copying Prohibited
Fundamentals of EMS, NMS and OSS/BSS
The best practices and design patterns implemented in each of the API back up OSS/J deliverables. eTOM can define a common map for
communications industry business processes and a reference point for internal process reengineering needs, partnerships, alliances, and
general working agreements with other providers as a result of endorsement by a large majority of the world's leading service providers. When
applied to the full range of Telco operations, maximum flexibility is provided by the technologies of OSS/J.
OSS/J has the following characteristics:
n OSS/J uses J2EE as middleware. This is an open standard middleware. J2EE can provide tightly coupled system implementation. It
comes with implementation conformance test tools and certification process.
n OSS/J uses XML over JMS that enables loose coupling among systems and interfaces.
n OSS/J components are Web services-enabled using WSDL specifications.
n OSS/J offers open standards for its APIs. The standards come with a source code. They are certifiable at implementation level and come
with conformance test tools.
Before we conclude the discussion let's look into OSS/J certification. The OSS/J API specification and reference implementation are
accessible for free download. OSS solution developers can use the API specification and reference implementation code to develop OSS/J
API in products that are planned to be certified. To certify the developed API, the solution developer has to download the technology
compatibility kit within the Java community process, which is a test suit that is available for free.
The test suite needs to be run against the API developed by the service provider. The test execution will generate a test report that will specify
if the test run was successful. On obtaining a successful test run in the report, the solution developer needs to send the test execution report to
the OSS/J certification committee. The certification committee will validate the report and the process used to create it. Once the certification
committee acknowledges the certification of the product, the certification can then be published. The published certificates will also have a
reference to the test execution report. The publication of the test report eases the procurement of certified products for faster integration.
25.5 MTOSI and OSS/J
MTOSI focuses on reducing the cost of integration in a commercial environment by providing a full XML interface specification detailing the
model, operations and communications enabling out of the box interoperability. The focus of OSS/J is also reduction of the integration cost in
a partner/open-source environment. OSS/J provides a Java interface specification that offers basic operations but does not contain the model
or interaction as specific as in MTOSI. Instead, OSS/J allows sharing of reference implementations to enable interoperability. Thus it becomes
evident that MTOSI and OSS/J are complementary technologies. Using a mapping/mediation approach MTOSI and OSS/J can interoperate.
For a closed partner engagement, OSS/J is best suited where as for an out-of-the-box commercial environment MTOSI is the best.
Figure 25.2: MTOSI and OSS/J can interoperate.
OSS/J offers technology independent APIs. There are separate APIs for various OSS functions. MTOSI gives OSS interfaces for a
multitechnology environment and is based on specific models. MTOSI models are defined in TMF 608. OSS/J, being associated to a generic
set of operations, can have an adapter written when a specialized set of operations needs to be executed with MTOSI. This is shown in Figure
Page 6 / 7
Reprinted for OET7P/1248301, Accenture CRC Press, Taylor and Francis Group, LLC (c) 2010, Copying Prohibited
Fundamentals of EMS, NMS and OSS/BSS
25.2 where the generic OSS/J framework has an MTOSI adapter for interaction wherever a defined set of operations are to be executed.
MTOSI and OSS/J has some marked differences. While OSS/J is Java based, MTOSI is XML based with emphasis on Web services. MTOSI
however has guidelines on using JMS, though its usage is not mandatory for implementing MTOSI compliant APIs. OSS/J also supports XML,
but the XML API is wrapped with Java API.
The MTOSI back end implementation is not based on a specific technology as compared to OSS/J where the back end implementation is in
Java. As MTOSI evolved from MTNM most of the issues in interface APIs were fixed and the definitions were to offer a service oriented
interface on a heterogeneous platform environment. So when multitechnology, multinetwork support is required MTOSI would be a good
choice, while in open source based environment OSS/J would be the popular choice. Support to both these interface standards can be
implemented in the same OSS solution.
25.6 Conclusion
An application programming interface (API) is an interface that defines the ways by which an application program may request services from
another application. APIs provide the format and calling conventions the application developer should use to work on the services. It may
include specifications for routines, data structures, object classes, and protocols used to communicate between the applications.
The APIs are mostly abstract interface specifications and controls the behavior of the objects specified in that interface. The application that
provides the functionality described by the interface specification is the implementation of the API. This chapter gives the reader an overview
of the management interface standards used in OSS/BSS development. It considers MTOSI and OSS/J for developing applications in the
customer, service, and network layers of OSS/BSS. The basic concepts of these two popular interface standards are discussed without diving
into the details of a specific topic.
Additional Reading
1. [Link] (Latest version of the documents can be downloaded from the Web site)
TMF608: MTOSI Information Agreement
TMF517: MTOSI Business Agreement
TMF854: MTOSI Systems Interface: XML Solution Set
TMF608: MTNM Information Agreement
TMF513: MTNM Business Agreement
TMF814: MTNM IDL Solution Set
TMF814A: MTNM Implementation Set and Guidelines
OSS APIs, Roadmap, Developer Guidelines, and Procurement Guidelines
2. Software Industry Report. Sun Leading Telecom Companies Announce Intention To Start Next Generation OSS Through Java‥
Washington, DC: Millin Publishing Inc., 2000.
3. Kornel Terplan. OSS Essentials: Support System Solutions for Service Providers. New York: John Wiley & Sons., 2001.
4. Dr. Christian Saxtoft. Convergence: User Expectations, Communications Enablers and Business Opportunities. New York: John
Wiley & Sons., 2008.
5. John Strassner. Policy-Based Network Management: Solutions for the Next Generation. San Francisco, CA: Morgan Kaufmann, 2003.
Page 7 / 7
Reprinted for OET7P/1248301, Accenture CRC Press, Taylor and Francis Group, LLC (c) 2010, Copying Prohibited
