Vodafone Germany successfully implemented the Fault Management Integration solution as the technical basis for several integration scenarios. This interface has been deployed at Vodafone D2 for approximately two years, and performance requirements (in terms of number of alarms processed and time to process alarms) has been satisfactory.
[Remark: the implementation is based on the Fault Management functionality of the OSS/J QoS API (JSR 90) V1.0, which contains more than just Fault Management. The implementation uses the FM – Part only.]
The solution is shown in the picture below. It has been used as the basis for the Fault Management Interface between the Network Management Fault Management System (TeMIP from HP) and the Service Monitoring System (SMoS, a local customization based on WSM from Agilent).
Other client system are already planned to be integrated in the future, like the IT Monitoring System, the SQM System, etc. It´s most likely, that there will be a large number of additional clients in the future.
<<illustration here>>
Background:
The NM-FM system is used on the resource level to monitor faults/ errors from the whole telco network (see TAM “Resource Status Monitor”). It consolidates and normalizes all underlying FM data-sources, like domain specific Element Management systems. The Service Monitoring system need the consolidated resource alarms / status information to analyze the impact of these faults on the services, as they are seen by the end – customer (see TAM “Impact Analysis”).
[Remark: the impact analysis capability of the Service Monitoring solution is based on a service-data-model, delivered by another system, which contains the service – catalogue and the relation between the services and their underlying resources. The Interface between Service Monitoring and the Service Catalogue is implemented by the OSS/J Service Inventory API. You will find a description of this implementation as a Service Provider testimonial in the “Prosspero Service Inventory Integration Solution Package”]
So, there was a need to forward the resource alarms from the NM-FM system to the Service Monitoring system, which has been realized with the Fault Management part of the OSS/J Quality of Service API (JSR 90). The approach taken to use a standardized type of interface shall help to integrate other potential FM data sources, e.g. the IT FM system or systems, which generate alarms based on threshold violations in performance data records (like SQM) with the Service Monitoring system. So the intention is to re-use already deployed parts of the interface without any further adoptions, e.g. the client interface at the Service Monitoring system.
It is essential for other OSS tools to be integrated with the Service Monitoring system, which enables the automation of several operational business processes via the OSS/J FM API.
The API itself uses a ITU.X.733 compliant information model to allow a standardized way of communication between all these vendor specific OSS components. All of them use (and can use) their own information model, which are (or will be) mapped onto the common OSS/J Alarm model.
The embedding and integration of OSS/J (operations support systems through Java™) capabilities in the NM-FM solution as a northbound interface and in the Service Monitoring solution as a southbound interface will lead to additional savings. OSS/J technologies enhance new generation operations support systems and software (NGOSS) by adding technology-specific components that are re-usable at the implementation, integration and deployment levels. It lets us correlate the alarms the system generates against our service topology management so we can see what is affected—what is the root cause of our problem and which services were impacted.
à So there is a need for integration with other OSS/BSS components
While protocols specifications and message formats such as XML are important to achieve this interoperability, as well as cost savings and reduced risk of integration, it’s even more important to make sure that the applications are prepared to exchange the same information, the same semantic, using the same interfaces. Using OSS/J makes sure that it happens.
<<illustration here>>
Business Scenario´s
The current implemented solution supports the following business scenario´s:
· Client starts Alarm Subscription
· Alarm and Event Reporting
· Generic Client Requests
· Automatic Alarm Resynchronisation
· Manual Alarm Resynchronisation
· System or Connection Breakdown Scenarios
· Connection Lost between QoS FM and FM Server
· Client(s) Not Available
· Specific Client Request
· Client Queries and Evaluation of Filter Patterns
· New Attribute Value Change Event
· State Management
· End to End Surveillance
Used versions of documents / specificiations
The following versions of documents / specifications have been used to develop this real life integration scenario actually (updated versions might used, if there is a need to upgrade parts of the solution)
- JSR 90: QoS API 1.0 (Only the FM – part of the QoS API has been used in this implementation !)
- OSS/J Design Guidelines 1.1
- QoS API RI 1.0
- QoS API TCK 1.0
Cost benefit / savings
Comparing our first steps with NGOSS & OSS/J to former integration projects shows clear benefits from a cost perspective. Here is cost comparison between a proprietary point-to-point integration versus the OSS/J approach:
Development of a proprietary interface between Fault Management servers and an OSS client like Service Monitoring
<<illustration here>>
Using the following assumptions:
* There are costs for the development of each p2p interface on the server side as well as on the client side.
* X=Y=Z (means: the costs might be the same for each part of the interfaces)
Result à Costs: 4*X
Below the implementation of the OSS/J QoS (FM-Part) API as a single client-interface to the Resource Fault Management systems, which allows the re-use of the interface connection and the de-coupling of the OSS components. Furthermore it allows re-use of that interface for other integration scenario´s, which leads to additional cost savings.
<<illustration here>>
Using the following assumptions:
* There are costs for the development of each interface on the server side and only one (standardized) Interface part on the client side to address the needs of both servers.
* X=Y=Z (means: the costs might be the same for each part of the interfaces)
Result à Costs: 3*X
That means a cost reduction of 25 % for this simple example.
These savings where possible by re-use of the FM Integration solution for different scenarios. Further savings are expected by re-use of this solution for further FM integrations with other OSS components and potentially for the exchange of FM information between different Vodafone subsidiaries.
An important driver for cost reduction over the whole solution lifecycle is the fact that all involved parties, i.e. customer's functional and technical department, OSS vendors as well as systems integrations companies use a standard interface (the QoS [FM-Part] API), standard data models (CBE, SID) and talk the standard “language”, using the TMF’s NGOSS defined terminology and syntax.
E.g. currently other Vodafone subsidiaries are in various stages of deploying OSS/J solutions. The same implementation approach has been used for the trouble ticket interface at the Trouble Ticketing systems and the Service Inventory systems. This is now going into production or in different project stages at other Vodafone subsidiaries. The QoS (FM-Part) API solution has the potential to be next for them. Vodafone D2 value the openness of OSS/J standards. OSS/J is a TeleManagement Forum initiative that offers a suite of functional OSS APIs, which use Java, XML (extensible markup language) and Web Services as underlying communication protocols. The APIs are aligned with the NGOSS architecture, quickly linking OSS applications together throughout their life cycle. While protocols specifications and message formats such as XML are important to achieve interoperability, as well as cost savings and reduced risk of integration, it’s even more important to make sure the applications are prepared to exchange the same information, the same semantic, using the same interfaces.
Contact details
Andreas Buschmann
Vodafone D2 GmbH
Network & Service Mngt. Engineering
Am Seestern 1
D-40547 Düsseldorf – Germany
eMail: Andreas.Buschmann@Vodafone.com
Phone: +49 (0) 211 533 6211