OSS systems are expected to fulfil many business objectives of virtualised telecommunication networks. One of the most spoken benefits of OSS for NFV is driving operational efficiency by over 50% through continuous closed loop self-healing, scaling up and down of resources and allowing introduction of new services to the market much faster than ever before.
The expectation does not stop here.
OSS for NFV is also meant to improve customer experience and drive new revenue streams through automated analytics, exposure of APIs and service policy management.
This translates into OSS requiring a massive transformation before it can be ready for the virtualised networks.
One of the biggest problems that OSS has to deal with is the hybrid character (mostly virtualised, partly physical or on-premise) of the telecom networks for a long time (estimated 5-10 years). The other problem is the dynamism associated with NFV, which requires speedier processing of data and real-time ability. Finally, CSPs cannot ignore the fact that the virtualised networks will now have new network elements to manage. All of these challenges need to be addressed separately, says Sandeep Raina, Product Marketing director, MYCOM OSI.
Hybrid interim networks
Legacy networks will co-exist with virtualised networks for the next 5 to 10 years and OSS systems will need to support performance management of the hybrid networks in the interim. OSS will also have to facilitate service innovation across hybrid physical, logical and virtual environments using more agile service development methodologies (DevOps, for example).
Over this long transition period, the migration of virtual and physical networks will require resource scalability, elasticity, configuration and remediation across the-end to-end hybrid network. This can be imagined as squeezing one end of a balloon, which results in inflation of the other end; as resource/capacity of the physical part of the network shrinks, it will need to be steadily increased for the virtualised part of the network.
NFV-related extensions to each of the existing OSS layers, along with open RESTful APIs is a quick, practical way in managing the hybridity of NFV. Introducing mediation towards the virtualised network components, common inventory management, hybrid network dashboards for end-to-end viewing and correlating performance parameters across the physical and virtual parts of the network are the first few functionalities that must be introduced.
Dynamic character of NFV
NFV promises some key use cases for enterprise service management, which require dynamic RAN orchestration, dynamic traffic management and real-time management of QoS policies. To deliver the expected dynamism in service delivery, OSS will, first of all, need to move from a product-centric model to a metadata-driven service model.
At an application level, automation and service fulfilment need to become complementary to each other to achieve the expected dynamic orchestration. This will also require new emphasis on the integrity of inventory, i.e. mapping of physical and logical inventory, which can be achieved only through physical and virtual probing of data. Finally, a real-time configuration system will complete the picture.
Some other important features that need to be incorporated into OSS are:
- Service chaining, which enables creation of catalogues of network resources and related policies to which individual services can be assigned
- Reserving network resources through traffic/capacity management for specific services, e.g. video on NFV
- Integrating high-end analytics based on real-time traffic to predict customer behavior and network/service usage, thus delivering dynamically tuned services
- Creating a service partner ecosystem using open APIs to enable service exposure
New NFV network elements
New NFV elements are being introduced to the virtualised networks, which unfortunately do not yet have sufficient standardisation, thus posing a challenge in managing their uptime, health and performance. These elements include Hypervisors and VNFs (Virtual network functions).
The OSS system should be able to configure and adjust the virtual network element capacity on-demand, and carry out root cause analysis on the virtual network elements, synchronised in time with the physical network elements.
By establishing a common information model across the assurance functions, much of this challenge can be addressed. This includes covering devices, connectivity models, monitoring intervals, KPIs and the correlation with services and customers.
Data collection agents on the virtual elements can capture real-time performance intelligence at the packet, element, network and application levels in IP flows, thus providing the required consumption patterns, server usage, network nodes utilisation, errors and cause events.
Some other functionalities that need to be introduced are:
- Auto-discovery of:
- Physical infrastructure through Hypervisor
- VNFs through domain orchestrator
- Auto-discovery of service using an end-to-end Hybrid Service Orchestrator
- Identifying VNF-specific alarms in a multi-vendor environment
To summarise, the introduction of NFV in legacy telecom networks will bring about disruptive changes, which will have an immense impact on network, service and customer experience.
Although the current OSS framework with its layers of performance management, fault management, SQM and CEM is still valid, it needs to adapt to the hybridity invoked by NFV, the agility of NFV services and the new virtualised network elements. Incremental features and cross-functionality open APIs will resolve many of these challenges.
The author is Sandeep Raina, Product Marketing director, MYCOM OSI.
Comment on this article below or via Twitter: @ VanillaPlus OR @jcvplus
