Did you know that one of the core technologies that drives 5G is ONAP? Learn more and be guided about ONAP. This guide has everything you need to know about ONAP.
The Open Network Automation Platform (ONAP) is an open-source platform for the orchestration and automation of network services such as telecommunications, cables, and cloud-services. ONAP works in real-time and is policy-driven, as is the business requirement of all modern service providers. It enables the rapid automation of the instantiation and configuration of physical and virtual network functions and supports lifecycle management tasks.
ONAP is an open-source project hosted by The Linux Foundation that started in 2017 and is now catering to cutting-edge network technologies such as 5G. The first release is named Amsterdam, whereas the latest release is called Guilin.
ONAP is an orchestration platform for network services. More importantly, it is open-source--that means that ONAP is a compilation of big and small global collaborators' best work. Its primary function is to automate and orchestrate network services, reducing time-to market, scaling difficulty, operation expenditure, capital expenditure, and infrastructure costs. It is also designed to work on top of existing investments.
A software-defined network is a network architecture approach that allows programmatic, dynamic, and efficient network configuration. This approach moves away from traditional hardware-bound networking and brings in cloud-computing style network management.
SDN is a direct product of the sudden shift to cloud computing, massive multimedia content, increasing mobile usage, and technological portability. Products and services that rely on any form of the network, such as cable, telecommunications, and the cloud cannot afford to press on with traditional business models. SDN offers a way to keep business costs flat while maintaining system scalability, availability, and robustness.
Many organizations have set standards for SDN. There is the Alliance for Telecommunications Industry Solutions (ATIS), the Broadband Forum Member (BBF), and the Institute of Electrical and Electronics Engineers(IEEE).
First, the separation of hardware and software enables network managers to be abstracted and API-driven. If companies would like to introduce new changes, it can be as simple as adding or refactoring the source code used to manage the network. Additionally, since software and hardware are decoupled, the physical layer is entirely independent of whatever changes are made to the software layer. If there are problems, operators are sure that the only domain they need to inspect it in the same layer where the problem occurred.
Second, it allows for the logical centralization of control. Logical centralization ensures the alignment of devices on a bandwidth, security, policy, and restoration level. In traditional network architectures, devices functioned autonomously with no regard for the states of the other instruments. Now, logical centralization allows for all these devices to work together optimally.
Third, open-source SDN enables vendor neutrality and allows for a wide range of applications such as cloud orchestration, OSS/BSS, SaaS, etc. Because it is open-source, vendor interoperability is also a key feature. An organization that uses SDN needs not be locked into using proprietary software. One example of an open-source tool for SDN is OpenFlow.
Network Function Virtualization (NFV) is an approach to virtualize proprietary network hardware appliances by packaging them as software and running them in virtual machines. It can be applied to routers, firewalls, and load balancers. The resulting software is called a Virtual Network Function or VNF.
NFV and SDN work together to implement an entirely virtual network. NFV is primarily concerned with converting network components into software, whereas SDN refers to the network architecture run by VNFs.
Like SDNs, NFVs are a direct product of service providers wanting to make the addition of network functions more streamlined and efficient than traditional methods. Several standards organizations, but ETSI (European Telecommunications Standards Institute) are the first organization to come up with NFV standards.
First and foremost, a virtual network is more cost-effective, faster to deploy, and more scalable than traditional networks. The time to market a virtual network is significantly lower than that of a conventional network because of the speed at which you can roll out applications. It is all because it is purely software-driven and decoupled from hardware.
Second, no, there is no vendor lock-in. The beauty of using open source software is that all the tools and resources that are out in the open are at your disposal. A common headache felt by companies is when they are locked into proprietary software, and in the case that it does not fulfill specific business requirements, they now have a problem.
Third, greater resource efficiency. A single server can host several VNFs. Thus, the network can take on a more significant operational load. Things such as power consumption and cooling requirements can be reduced while increasing workload capacity.
Fourth, scalability and flexibility. Scaling the number of VMs up and down, monitoring various metrics like workload and bandwidth, and deploying changes are done more efficiently because it is done through SDN software. There is less of a need for hardware to be purchased, shipped, and maintained in data-centers.
ONAP has two powerful frameworks: the design-time framework and the run-time framework. The design-time framework includes service design, whereas the run-time framework includes service deployment and service operations.
Service design falls under the design-time framework, whereas service deployment and service operations fall under the run-time framework. Service design allows operators to have complete control over network behaviour via defined policies. Applications, analytic, and closed control loop events guide service behavior in the design-time framework.
On the other hand, service deployment relies on policies to provide an automatic instantiation of services. Service operations are dedicated to monitoring during the service lifecycle based on the service design. These two ONAP activities fall under the run-time framework.
Amsterdam is the first major ONAP release. It was rolled out on November 20, 2017. It was the first project to unite the majority of operators with the majority of vendors in using and contributing to a network service automation and orchestration platform.
During this time, 55% of the world's mobile subscribers were supported by its members. The original vision for ONAP was to create a"globally shared architecture and implementation for network automation, based on open source and open standards," said Arpit Joshipura.
The Amsterdam release includes a unified architecture that provides for production-proven code from open source ECOMP and OPEN-O. ECOMP is a website used by federal agencies to record workplace health concerns such as injuries and illnesses. OPEN-O stands forOpen Orchestrator Project--an open-source project backed by the LinuxFoundation.
It enabled real-time inventory and analytics support monitoring, end-to-end troubleshooting, and closed-loop feedback to fulfill SLAs and optimize service design. Note that this also applies to physical networks.
During this time, Amsterdam was meant to be used primarily for VoLTE (Voice Over LTE) and residential vCPE (virtual Customer Premises Equipment). Amsterdam virtualized the core network to orchestrate the VoLTE service. With vCPE's, Amsterdam provided an avenue for CSPs to add services on-demand. It allowed companies that used these technologies to beat competitors in terms of time to market.
Beijing was released on June 12, 2018. During this period, there was a 65% global subscriber participation in ONAP. That is a 10%increase from the previous year's 55% global subscriber participation percentage.
More leading global service providers have opted to participate in ONAP--thus, Beijing focused on accelerating deployment ease. The Linux Foundation spawned an entity called LF Networking whose main goal was to ease the unification of the top 6 open source networking projects--of which ONAP was a part.
Beijing mostly focused on enhancing the stability and deployability of the platform. It is to make ONAP training more accessible to developers and the general tech community as a whole. Things such as documentation updates, training options, and new getting started guides were essential things that drove this initiative.
Beijing also featured container-based deployments that were made available to enhance scalability, security, stability, and performance. The documentation for VNFs has also been updated to aid developers, service designers, and operations managers.
In terms of architecture, the ONAP Operations Management has added support for the migration of microservices-based deployments on Kubernetes. Next, external APIs were made to have seamless communication. It was achieved by collaborating with MEF and TMForum.
In terms of deployability, the seven vital operational parameters were deployed for each platform module. Said parameters were usability, security, manageability, stability, scalability, performance, and resiliency. Next, the ONAP Operations Manager (OOM) and Multi-State Coordination Service (MUSIC) projects were rolled out to bring better platform stability.
CII (Core Infrastructure Initiative) is a project that focuses on improving the security and resilience of various open-source projects under the Linux Foundation--one of which is ONAP. Because of all these improvements, ONAP was able to gain over 70% improvement in the elapsed time of service resilience closed loop.
The vCPE blueprint's management and policy-driven systems were enriched using the HPA (hardware platform awareness). Network service scaling was also improved using the VNF Manual Scale-out. Finally, the R2 VNF data model has been aligned with VoLTE and CPE using the VF-C.
As mentioned above, Beijing was all about scalability and reliability enhancements and increasing the accessibility of the ONAP to the general community. Hence, the ONAP and OPNFV Verified Program (OVP) worked together to bring about rapid adoption. As mentioned, this includes new operation guides, API and SDK documentation, online training like Open Source Networking Technologies, and community-led best practices webinars.
As with the previous year, operators who are part of the ecosystem continued to use ONAP for network-reliant mobile technologies such as VoLTE. During this time, the code was being integrated into existing proofs of concept and production deployment plans for companies like AT&T, Bell Canada, China Mobile, China Telecom, Orange, and many others.
This release is dated October 24, 2019. This release saw the delivery of more than 2500 epics, user stories, tasks, and bug fixes. Three pillars govern El Alto: security by design, document as you code, and don't break the build.
Existing features were enhanced like the Controller Design Studio, UI Data Dictionary Screen Improvement, HEAT & TOSCA based VNF validation enabled for support of OVP & CVC, VNF Preload Generation, and more.
The recurring theme in the releases so far revolve around strengthening security. For El Alto, developers weeded out vulnerabilities in the components leading to even more reliable protection. For this release, it primarily built on existing features and enhanced them.
Similar to security, documentation improvement is also a recurring theme in releases. New user guides were also created for this purpose. Swagger also became a tool for API documentation. At this stage, more and more members were becoming involved with the ONAP community, which called for an even higher level of accessibility.
In keeping with the interest of maintaining code integrity among upgrades and changes, ONAP saw an increase in test coverage and E2E Test Automation. E2E (End-to-End) Automation is a method for testing software that covers the workflow from start to finish. With this method, real-life scenarios are simulated to get the most accurate production behaviour possible. It is very apt for the theme "don't break the build" because this method ensures that all components work together seamlessly.
The latest release is called Guilin. Presently, we are evolving towards 5G networks. During the Frankfurt release, end-to-end network slicing is further expanded. It enables the flexible slicing of network resources into virtual networks. It is similar to the SDN/NVF architecture discussed above, wherein resources spawned by a single unit are divided and allocated optimally.
At this time, the Linux Foundation has released an official Certified ONAP Professional (COP) exam. It is a three-hour, performance-based certification exam that developers can take to improve their marketability and potential for community contribution.
A significant feature includes support for the A1 interface (O-RAN, A1-AP v1. 1), leading to greater ONAP and O-RAN Software Community harmonization. It means that ONAP can now manage multiple A1 targets with different versions using an A1 Policy Management Service.
In terms of end-to-end network slicing that was first introduced in the Frankfurt release, Guilin now sees that there is an addition of RAN, core, and transportation through Network Slice Subnet Management Function (NSSMF). It then allows the Communication Service Management Function (CSMF) and Network Slice Management Function (NSSMF) components of the ONAP to work together. Additionally, there is now support for external RAN NSSMF and a simple closed control loop and ML for intelligent (automated) slicing.
Most features in this release fall under design time, run time, and ONAP Operations. These are meant to enhance the self-serve control loop and dashboard for better model reusability, xNF, pre-onboarding, on boarding, UI development, etc.
Other enhancements include:
· Standard Defined VNF Event Stream (VES) for Fault Management and Performance Management Data collection
· ML on Self Organizing Networks (SON)
· Service Modelling and Definition
· Intent-Based Network
· Multi-Domain Optical Network Services (MDONS)
ONAP started with a desire to decouple network hardware and software to increase efficiency and reduce costs. It is now the driving technology behind 5G, edge computing, IoT devices, and demanding real-life network applications like self-driving cars.
In 2017, it might have been hard for many people to seethe value in the shift from traditional network management to ONAP. Now, its importance is more palpable than ever. For example, self-driving cars rely on-network connections and thus demand ultra-low latency and ultra-high reliability. Self-driving cars' performance directly translates to the community's safety and needs to be backed by a reliable network.
The next release is called Honolulu, and it will be released in 2021. Its release requirements are available to authorized personnel only; however, at this point, we can speculate that on top of having existing features enhanced, we can hypothesize a more robust intelligent splicing mechanism for end-to-end splicing.
ONAP already has support for simple loop ML, but we can expect this to be further expanded by the Honolulu release because of concurrent improvements in AI. Next year, we might see ML models handling the automation of splicing--thereby eliminating the need for human intervention.
Another thing that we can expect from this is for orchestration to become increasingly "self-serve." It means that new features might allow operators to do more with an abstracted view of ONAP. Because ONAP will be more abstracted, we can also expect more enhancements and integrations in cloud nativity.
Here at codvo.ai, our subject matter experts have a deep understanding of networking technologies and ONAP. We always aim to increase efficiency and reduce business costs to provide better business value using modern open-source technologies. More than that, we are also interested in contributing to the open-source community. We believe that ONAP is the future of networking, telecommunications, cable, and cloud as it provides next level scalability, robustness, and reliability.
If you are interested, contact us today at marketing@codvo.ai !
.png)
