What an OSS shouldn’t do

Being selective — doing less — is the path of the productive. Focus on the important few and ignore the rest.”
Tim Ferriss.

When speaking with a great friend of mine today, Eddie, I came to the startling realisation that in nearly 700 blog posts, I have forgotten to speak about a major misgiving that many people have when setting expectations for their OSS. Many of my past customers have held the belief that an OSS will replace all of the functionality of their various NMS and EMS. This simply isn’t true.

The diagram below will help to tell the story, which shows a four-layer stack with OSS on top, then NMS, EMS and network elements progressively southbound.

OSS abstract and connect

Starting at the most southerly layer, the network layer, are the network elements that carry real network traffic. These devices generally store their own local information and perhaps a little information about their neighbours (eg routing tables) but would generally not hold end-to-end knowledge of their interconnected network.

At the next layer up, the element management layer, the EMS is a system designed by a supplier / manufacturer to manage a set of devices that it also supplies (in most cases), as designated by the colour-coding.

The EMS doesn’t need to manage all the attributes that the NEs hold (eg signal power levels, signal processing, etc). The northbound interface (NBI) on the NE abstracts most of the information. It only passes information up to the EMS that is relevant to managing the device (eg alarms, performance, inventory, etc) whilst the EMS provides the glue that connects more devices together.

Each subsequent step northbound does the same thing:

  • It abstracts – it only performs a sub-set of the lower layer’s functionality
  • It connects – it performs the task of connecting and managing a larger number of network elements than the lower layer

So an OSS, will never (almost never?) replace the functionality of the NMS or EMS. But in return it should increase the cross-domain connectivity.

After all, from the diagram below NMS #1 from supplier X will hold highly proprietary information and complex algorithms relating to the SDH network that the OSS wouldn’t seek to replicate (and may find almost impossible to reverse engineer). Conversely, the OSS will hold information about connections from the SDH network to the IP network that  neither NMS#1 or EMS#1, 2 or 3 would store.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions


Most Recent Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.