Network Function Virtualization Impact on OSS
A spotlight on the benefits of Network Function Virtualization (NFV), and its impact on Operations Support System (OSS).
Virtualization is not new. It dates back to 1960 when virtual memory management was made possible on mainframes and today many communication functions such as policy control, real-time charging etc. are already running on virtualized environment. It makes sense to extend this functionality to other areas as the traditional network is over engineered to meet the worst-case scenarios of busy hours and 40-60% of the network is underutilized. In contrast to this approach, if we address ‘the need of hour’ by dynamic deployment of network resources, the anticipated amount of savings would be multifold.
NFV is an attempt to virtualize and automate network functions so that it can be managed on a general-purpose x86-based IT infrastructure instead of ASIC-based purpose built appliances. Any network function that is/or can be virtualized is termed as Virtual Network Function (VNF). NFV aims to bring in extensive orchestration capability to make dynamic deployment of VNF possible, there by addressing the issue of underutilized network. The figure below is a conceptual architecture of NFV platform.
Key Drivers
Following are obvious benefits realized from the NFV concept.
Low Capex and Opex: Capex savings will come by replacing the expensive bespoke appliances cheaper commodity hardware and optimized network utilization with ‘Just in Time’ introduction of VNFs. Opex cost will be reduced by automating traditional manual network configuration operations.
Elasticity: With the realization of NFV, scale up and scale down of network shall be possible which will enable communication service provider to manage an optimized network.
Service Agility: NFV will support new service rollouts faster. In the current scenario it takes weeks to months to roll out business services due to lengthy cycle of procurement, testing and deployment. With NFV this is expected to reduce drastically leveraging on faster software based integration, validation and deployment.
Operational Simplicity: NFV vouches for open standards-based implementation, which will bring an opportunity to simplify the elements and EMS, which in turn will simplify
provisioning embarrassing multi-vendor ecosystem.
Rapid Innovation: Innovation will be made easy since software is governing network. Gone will be the days where service provider will have to request for a hardware change and wait for the NEM to deliver. Service Provider will be able to innovate new Network Services in his lab without dependency on NEM vendor.
Challenges of NFV for OSS
Some of the key challenges that will be faced by OSS are:
Hybrid Environment: Virtual Network Functions (VNFs) and Physical Network Functions (PNFs) will have to co-exist and management of such a hybrid environment is inevitable. OSS modules will have to be enhanced to address a scenario where a network function will be partly in a physical device and the remaining part will be on a virtual server. In such an environment there will be need for a single Resource and Service Inventory which will hold references of both PNFs and VNFs to provide other OSS and BSS subsystems a global view of Network Resources.
Abstraction: As opposed to conventional way of management now it has to be done to an “abstraction”. This is a major change to the traditional OSS. There will be a need to design a relation between abstract virtual infrastructure and physical infrastructure. One or many of the OSS modules may be responsible to model this abstraction. The relation is important to be maintained to monitor network functions at both physical and logical levels.
Manage Dynamicity and Real Time: Deployment of a VNF will take few minutes as opposed to weeks / months. Due to the dynamic nature of resource deployment in the network, OSS components like Resource Inventory, Provisioning & Activation and Fault management will have to scale up with additional features to cope with this dynamic behavior. One can envisage the need for real time OSS components to manage VNFs. Current OSS systems especially Resource & Service Inventory is not equipped to manage this dynamicity and real time behavior.
Capacity Management
With the ability to spawn VNFs dynamically, there has to be a tight control and management on: —Thresholds, upon crossing which VNFs should be spawned. —The clash between multiple VNFs competing for underline physical resources. —Policy driven decision on when a new VNF is to be spawned and decommissioned.
Process Realignment
With the advent of NFV, there will be a need for OSS processes to be realigned so that both traditional and virtualized infrastructure can be managed simultaneously. Provisioning process will definitely witness an additional layer of management and orchestration. In current traditional way, expansion of network happens after a lot of testing and planning using Planning Tool.
Once approved network resources are instantiated in Resource Inventory to model the enhanced infrastructure with an “Available” status. While this process will continue to exist in the case of major network expansions, one can envisage quicker planning and deployment process for small scale up / scale down of network. It will be demand based and there will be use of more analytics and intelligent mechanism for scale up and scale down of network. In the fulfillment process, service feasibility process might change. If the related VNFs are running out of capacity, service feasibility check might not fail as there is a possibility of scaling up the corresponding VNF or spawning a new VNF. Feasibility check might actually fail only if the underline virtual infrastructure is also running out of capacity.
With the abstraction of software components from ASIC hardware to standard x86-based commodity servers, network engineers will have to learn IT and IT engineers will have to learn more Networks.
Performance
To make OSS real time, performance of the systems are expected to increase drastically. Accordingly, hardware and software changes should happen to OSS Systems. To cope with the dynamic changes like scale up and scale down of network, performance of these systems will be critical. Current OSS systems will not be able to scale up for this demand. Hence, it has to be revamped to meet this need.
Envisaged Changes and Impact on OSS
New generation OSS will have to manage an ‘abstraction’ and not just a physical appliance or PNF. OSS will have to be more service-centric. Network service(s) which encompasses multiple VNFs, and traditional PNFs, will have to be modeled in OSS. There should be a means to model all NFV entities in Resource & Service Inventory of OSS along with a reference mapping to its corresponding Virtual Machines. Once the concept is fully evolved, there is possibility of an overlap of functionality between OSS components and NFV components.
New generation OSS will for sure be more ‘Real Time’. It will also be governed by some business rules and policies to take intelligent decisions. Hence, OSS will have to cope with this dynamicity and become more real-time with the help of NFV Service Assurance and data analytics.
Some of the key areas under the OSS domain which will undergo change are discussed below.
Resource & Service Inventory
and Activation System: While modeling of physical devices will continue to happen for PNFs, resource inventory will have to be enhanced to model more logical objects and maps with all NFV entities in the form of network service objects that depict end-to-end network service. A mapping of VNF instances and its corresponding virtual machine details will have to be stored in Resource & Service Inventory. Resource inventory will be enhanced to manage hybrid global network which comprise PNFs and VNFs. The interfaces to Resource and Service Inventory will be enhanced to take feeds from NFV Orchestrator so that it can update the global resource inventory with the changes that are happening to VNFs.
Traditional resource inventory is more or less static. Resource Inventory systems will need to scale up for dynamic behavior. Current resource inventory can be extended to model NFV logical entities as explained above and make it co-exist with the existing physical network functions. It is also important to devise a smart mechanism in the resource and service inventory to have a global view of all network services which will span across the hybrid network (VNF and PNF).
Orchestration capabilities of activation system can be enhanced to manage the required VNF orchestration as prescribed by ETSI. Orchestration in entirety will not be done by Activation system. It will be managed along with the resource and service inventory system which will hold the specifications / catalogs for VNF configuration and management.
Activation System will in turn interact with respective VNF managers to get the required VNF activity completed. Thereby a combination of Resource & Service Inventory and Activation capabilities will supplement VNF Orchestrator. At the same time Resource Inventory and Activation system in its original capacity will continue to perform traditional functions and manage the PNFs. This architecture will enable to manage the required hybrid view which contains VNFs and PNFs.
One should not undermine the need for high performance integration between Resource Inventory, Activation System and VNF Manager in order to cope with swift changes that is bound to
happen in the network. Discovery and Reconciliation: While traditional discovery will continue to function the same way, there will also be a need to synchronize the changes in virtualization layer with the resource inventory. There will be a need to discover and synchronize the VNFs onto Resource Inventory, if not updated by the standard process for any reason. Synchronization in this case is expected to be largely automatic. Changes happening to VM should also be synchronized. Traditional discovery and reconciliation tool will have to change. In this case entity discovered and reconciled into resource in-
ventory will be VNFs and its associated attributes that is required for Global Hybrid Inventory.
Fault and Performance Manage
ment: Due to the abstraction brought in by virtualization, VNFs or essentially a VM has to be monitored in a different way. Dynamic nature of VNFs will make it more complicated. VNFs will have different monitoring needs. Though not exactly like monitory IT systems, it will have to bring in that flavor.
One VNF can be deployed over multiple Virtual Machines (VMs) or on a single VM. This will call for lot more correlation to be done to ensure service continuity. If a VM is impacted, the corresponding
VNFs and the respective network services should be identified to assess the impact. Global Resource Inventory will be of use in this scenario.
Service Assurance & Data Ana
lytics: As per ETSI design, VNF Manager is expected to monitor the VNFs under it and take necessary actions including spawning of a new VNF or scaling up an existing VNF based on demand. However, it is always debatable that a single VNF Manager will not have a complete view of all the VNFs in the domain and hence will not be capable of deciding on the demand. Hence probably there is a need for an external Service Assurance systems like fault and performance manage system to manage this activity. In conjunction with Data Analytics tool, should determine the exact need for spawning / scaling VNFs. Once determined, the VNFs should be instantiated via Orchestrator module mentioned in “Resource & Service Inventory and Activation System” section mentioned above. VIM is also mandated to provide inputs on capacity planning, monitoring and optimization. Hence a demand management is expected to happen in conjunction with inputs from data analytics, VIM and VNF Managers. However, the final decision to scale up / down, instantiate, terminate of a VNF shall be driven by policy / business rules defined in Policy Manager hosted by VNF Orchestrator.
Conceptual NFV Architecture
This section attempts to draw a conceptual architecture including NFV components working in tandem with OSS components. There is a possibility to enhance the Resource & Service Inventory to host NFV Catalogues – the specification required to instantiate a VNF. It can also host the Network Service instances along with the VNF instances. Policy Manager can be configured with rules as below:
-Elasticity required to scale up and scale down based on performance trends
-Capacity management rules based on business considerations,
-Compliance, SLA, thresholds based on cost of operation of implementation of Network Service
Upon getting a request for onboarding new Network Service, VNF-FG and/or VNF, Policy Manager will do the validation and authorization based on defined rules.
This architecture will enable the Resource & Service inventory to have a global view of all traditional network entities along with NFV components. It is important to hold a mapping of all VNF instances to its corresponding VMs. This will facilitate co-relating services that are impacted in the event of Virtual infrastructure failures reported by service assurance applications. Creation, Termination and Scale up/down of a VNF can be managed using the NFV Catalogue by interacting with the activation system, which is extended with orchestration capabilities.
Activation system will take the request from Resource & Service Inventory. Request manager will route the request to Orchestrator module to manage configuration request by interacting with VNF Manager with the help of NFV Cartridges and Policy Manager. Response is sent back by VNF Manger to Activation System and in turn to Resource & Service Inventory to maintain the state change. Thereby upstream O/BSS system is informed about the network resource changes.
Key features of this component:
NFV Orchestrator will be governed by a set of policies and business rules defined in ‘Policy Manager’.
Takes feed from ‘NFV Service Assurance and Data Analytics’ module and in conjunction with well-defined policies and NFV Catalogue -
o Creates, scale up / scale down, terminate logical instances of VNFs and Network Services in ‘Resource and Service Inventory’ .
o Stiches a logical view of network services offered.
Maintains a ‘VNF to VM Mapping’ to help correlate service impact in the event of a fault being discovered in the Virtual Infrastructure.
Having created logical instances, NFV Orchestrator shall orchestrate the creation of NFV instances by passing down the activation request to VNF Managers for actual creation on virtual infrastructure.
Maintains and manages state transition for logical VNF instances in ‘Resource & Service Inventory’
Architectural considerations are the following:
Real time OSS with hybrid view of traditional network objects and NFV objects
Traditional and new gen OSS can co-exist
Phase out and migration of traditional OSS will be easy
It is one of the approaches to enhance existing ‘Resource & Service Inventory’ and ‘Activation System’ to incorporate NFV Orchestrator features. With this, one can quickly build a single repository of hybrid view of traditional network objects and NFV objects. While there are definite benefits of enhancing current ‘Resource & Service Inventory’ and ‘Activation System’, there will be challenges to scale up this platform to meet the performance requirements demanded by NFV. Alternate option is to build a separate component for ‘NFV Orchestrator’ and integrate with traditional ‘Resource & Service Inventory’ and ‘Activation System’, keeping in mind the importance of hybrid view of PNFs and VNFs to be catered in either of the systems.