Almost all of these systems focus only on one area of NMS functionality (such as fault, performance or configuration management). As a result, NOC engineers often have to use many different systems to procure basic information about their networks. With duplicated data in each system, it becomes very difficult for them to know the status of the real network. This makes troubleshooting and root-cause analysis virtually impossible, as NEs are tied up serving multifarious network management systems. Also, network configuration changes are difficult to manage for the same reasons.

In these scenarios, a modernized NMS translates into the ability to use a single software platform to discover networks at layer 2 and 3, providing traditional NMS functions such as inventory, fault, performance and configuration. In addition, other NMS functions required of modern network are provided, such as: packet data protocol (PDP) context management, corporate access point name (APN) management, location-based advertising management, tap aggregation management, configuration change detection, NetFlow management, IP SLA, and data forecasting.  

This is when it becomes evident that the modernized NMS has triggered a successful OSS modernization process.

Further OSS Modernization Points to Consider

In general, successful OSS modernization often depends on products with modern architecture and design. These products need to be designed with OSS transformation and modernization in mind, possessing symmetrically distributed architecture. These products should employ TM Forum’s well-defined Business Process Frameworx suites of principles and standards (i.e.,  eTOM, SID, and TAM).

And because OSS software systems are often very large in scale, the requirements from each operator will be very different in terms of the details, even within the same functional domain. The users of OSS systems from different operators can have very different perspectives, experiences and knowledge. A one-size-fit-all approach, such as those of packaged systems, will no longer be good practice when moving toward OSS modernization.

Component-oriented and product-line software engineering is a good way of meeting the challenges of software solutions development and deployment environments goals. OSS software vendors that own a rich set of modernized OSS software components will eventually win out in the OSS modernization process. These OSS vendors’ product components can be either directly assembled or extended easily to solutions so as to meet each customer’s needs and requirement. This component-oriented  and product-line software engineering approach will ensure each and every operator has its own look and feel in the delivered product and solution,  while software quality and agility can be maintained at a low cost.

Looking Ahead

As we head into the digitally enabled future, NFV and SDN are going to be major forces driving OSS transformation as the existing OSS will no longer work in tomorrow's environments. According to ETSI’s NFV framework, management functions of the NFV network will be carried out by virtual infrastructure manager (VIM), network function virtualization manager (NFVM) and MANO (management and organization) to manage infrastructure for virtual machines, NFV instances and the entire virtual network sector. The resource management layer will need to transform accordingly.

The separation of switching and control logic in SDN will also dramatically affect NE-level management. More importantly, with NFV and SDN, network functions will no longer depend on specific hardware or NEs, as any faulty element will be automatically corrected or replaced by another. For that reason, resource management in OSS and management components in NFV and SDN will require a unified data model such as TM Forum’s Information Framework (SID) and a standard process (such as TM Forum’s Business Process Framework) to facilitate each other. The distributed nature of MANO and SDN control modules will require distributed OSSs to match up. With management functions embedded inside NFV and SDN, component-oriented software can truly provide great benefit to both NFV and SDN.