Open source is the future of telecoms, but telcos tend to be bamboozled by hype and a convoluted standards landscape. ONAP shows the way forward, but there’s still much to be done, writes IDC’s Hugh Ujhazy.
Telecoms companies have been virtualizing their networks for several years with a view to increase their ability to adapt to the changing competition in the telecoms environment and compete with OTT players. This transformation is driving toward agility, self-service provisioning, and rapid virtual network function (VNF) onboarding into the network combined with an emphasis on cloud-based solutions. To deliver nimble network solutions in a timely manner, carriers are faced with the challenge of striking the right balance between proprietary and open-source modules.
Open source can accelerate innovation, solution development and deployment while lowering costs and avoiding vendor lock-in. Open-source software is currently deployed at CSPs for network management, software monitoring tools, microservices and containers, and automation software. The CSP virtualization software stack can be decomposed into two major subsystems: (1) the NFV cloud (containing NFV infrastructure and VNs) and (2) the management and orchestration (MANO) software component, with both enabled by open source-based solutions.
Unfortunately, the hype around open source has created skewed expectations for what could have been an otherwise mutually beneficial concept. Determining the value of hundreds of different projects and standardization bodies (some of which are working on alternate solutions to the same issues) can be a major challenge for carriers, leading to confusion and reluctance to engage with open-source options.
However, open-source software is changing the CSP business model by moving from a supplier relationship to a partner relationship where vendors and CSPs share development resources for the same goal. It’s not about a simplistic answer – either proprietary OR open source solutions. Rather, as in life, it is about a combination of the two working together to realize business outcomes – proprietary code coming together with open-source initiatives, each bringing a different flavor.
One open-source solution, the open network automation platform (ONAP), has been positioned to become the de facto industry standard open-source platform for NFV/SDN automation. ONAP was created as a cloud-native superset of the MANO functionality in order to enable product-independent capabilities for design, creation and lifecycle management of network services.
ONAP provides a vendor-agnostic, policy-driven service design, analytics, and lifecycle management for large-scale workloads and services as required by CSPs. ONAP introduces the concept of blueprints for key uses cases such as VoLTE and residential vCPE. ONAP platform developers can test the blueprints against different open-source code and commercial products during the development process with real-time feedback. In this way ONAP and open source can support DevOps development.
Formed in March 2017, the ONAP project brings together over 50 of the largest network and cloud operators and technology providers from around the globe, representing more than 60% of the world’s mobile subscribers. As the community around ONAP expands, CSPs are deploying ONAP in the production environment. One of the first examples was Bell Canada which uses ONAP to automate its data center tenant network provisioning, support deployments and reduce its operational footprint, and enable continuous delivery. The Amsterdam release of ONAP earlier this year offers various scale, stability, security and performance improvements along with 5G features. SD-WAN features are also expected in the next release.
To reap the benefits (free or otherwise) and avoid cannibalizing itself, telecoms must reframe its expectations of open source and rethink open source as we know it in order to better align with the industry’s needs moving forward.
Standards are necessary if CSPs want to control the architecture and APIs of different projects. Applying a streamlined, managed community approach allows for a modern approach. This way, projects in progress can support fast iterations and can foster a climate of innovation from the same framework. Simply joining an open-source community does not equal contribution or active participation – to make a difference and drive standardization, active involvement in terms of code contribution and engagement in design/architecture is essential.
To derive value from open source, CSPs need to redirect efforts and develop new products with a service-oriented mindset that’s grounded in current market and customer demands. It’s paramount to the integrity of these projects that those involved have the resource capacity and capabilities to drive the specific business needs, all while adhering to openness and programmability goals. The products and business models they develop should leverage the power of open source, but also demonstrate the value-add that comes from either refining or strengthening certain solutions or building new solutions on top of them.
Written by Hugh Ujhazy, associate vice president of IOT & Telecoms at IDC | Originally published on LinkedIn
Be the first to comment