How ONAP is blurring network boundaries
Telecom operators will soon be able to expand their networks by running virtualised network functions in the public cloud. This follows work by Amdocs to port the open-source Open Network Automation Platform (ONAP) onto Microsoft’s Azure cloud service.
Source: Amdocs, Linux Foundation
According to Craig Sinasac, network product business unit manager at Amdocs, several telecom operators are planning to run telecom applications on the Azure platform, and the software and services company is already working with one service provider to prepare the first trial of the technology.
Deploying ONAP in the public cloud blurs the normal understanding of what comprises an operator’s network. The development also offers the prospect of web-scale players delivering telecom services using ONAP.
ONAP
ONAP is an open-source network management and orchestration platform, overseen by the Linux Foundation. It was formed in 2017 with the merger of two open-source orchestration and management platforms: AT&T’s ECOMP platform, and Open-Orchestrator (Open-O), a network functions virtualisation platform initiative backed by companies such as China Mobile, China Telecom, Ericsson, Huawei and ZTE.
The ONAP framework’s aim is the become the telecom industry’s de-facto orchestration and management platform.
Craig SinasacAmdocs originally worked with AT&T to develop ECOMP as part of the operator’s Domain 2.0 initiative.
“Amdocs has hundreds of people working on ONAP and is the leading vendor in terms of added lines of code to the open-source project,” says Sinasac.
Amdocs has make several changes to the ONAP code to port it onto the Azure platform.
The company is using Kubernetes, the open-source orchestration system used to deploy, scale and manage container-based applications. Containers, used with micro-services, offer several advantages compared to running networks functions on virtual machines.
Amdocs is also changing ONAP components to make use of TOSCA cloud generic descriptor files that are employed with the virtual network functions. The descriptor files are an important element to enable virtual network functions from different vendors to work on ONAP, simplifying the operator effort needed for their integration.
“There are also changes to the multiVIM component of ONAP, to enable Azure cloud control,” says Sinasac. MultiVIM is designed to decouple ONAP from the underlying cloud infrastructure.
Further work is needed so that ONAP can manage a multi-cloud environment. One task is to enable closed-loop control by completing work already underway to the ONAP Data Collection, Analytics, and Events (DCAE) component to run in containers. The DCAE is a component of ONAP that is of interest to several operators that recently joined ONAP.
Amdocs is making its changes available as open-source code.
Business opportunities
For Microsoft, porting ONAP onto Azure promises new operator customers. Microsoft is also keen for vendors like Amdocs to use Azure for their own development work.
Telecom operators could use the Azure platform in several ways. An operator running ONAP on its own cloud-based network could use the platform to spin up additional network functions on the Azure platform. This could be to expand network capacity, restore the network in case of a fault, or to host location-sensitive network functions where the operator has no presence.
A telco could also use Azure’s data centres to expand into regions where it has no presence.
Amdocs says cloud players could offer telecom and over-the-top services using ONAP. “As long as they have connectivity to their customers,” says Sinasac.
Service providers' network planning in need of an overhaul
These are the findings of an operator study conducted by Analysys Mason on behalf of Amdocs, the business and operational support systems (BSS/ OSS) vendor.
Columns (left to right): 1) Stove-pipe solutions and legacy systems with no time-lined consolidated view 2) Too much time spent on manual processes 3) Too much time (or too little time) and investment on integration efforts with different OSS 4) Lack of consistent processes or tools to roll-out same resources/ technologies 5) Competition difficulties 6) Delays in launching new services. Source: Analysys MasonClick here to view full chart.
What is network planning?
Every service provider has a network planning organisation, connected to engineering but a separate unit. According to Mark Mortensen, senior analyst at Analysys Mason and co-author of the study, the unit typically numbers fewer than 100 staff although BT’s, for example, has 600.
"They are highly technical; you will have a ROADM specialist, radio frequency experts, someone knowledgeable on Juniper and Cisco routers," says Mortensen. "Their job is to figure out how to augment the network using the available budget."
In particular, the unit's tasks include strategic planning, doing ‘what-if’ analyses two years ahead to assess likely demand on the network. Technical planning, meanwhile, includes assessing what needs to be bought in the coming year assuming the budget comes in.
The network planners must also address immediate issues such as when an operator wins a contract and must connect an enterprise’s facilities in locations where the operator has no network presence.
“What operators did in two years of planning five years ago they are now doing in a quarter.”
Mark Mortensen, Analysys Mason.
Network planning issues
- Operators have less time to plan. “What operators did in two years of planning five years ago they are now doing in a quarter,” says Mortensen. “BT wants to be able to run a new plan overnight.”
- Automated and sophisticated planning tools do not exist. The small size of the network planning group has meant OSS vendors’ attention has been focused elsewhere.
- If operators could plan forward orders and traffic with greater confidence, they could reduce the amount of extra-capacity they currently have in place. This, according to Mortensen, could save operators 5% of their capital budget.
Key study findings
- Changes in budgets and networks are happening faster than ever before.
- Network planning is becoming more complex requiring the processing of many data inputs. These include how fast network resources are being consumed, by what services and how quickly the services are growing.
- As a result network planning takes longer than the very changes it needs to accommodate. “It [network planning] is a very manual process,” says Mortensen.
- Marketing people now control the budgets. This makes the network planners’ task more complex and requires interaction between the two groups. “This is not a known art and requires compromise,” he says. Mortensen admits that he was surprised by the degree to which the marketing people now control budgets.
In summary
Even if OSS vendors develop sophisticated network planning tools, it is unlikely that end users will notice a difference, says Mortensen. However, it will impact significantly operators’ efficiencies and competitiveness.
Users will also not be as frustrated when new service are launched, such as the poor network performance that resulted due to the huge increases in data generated by the introduction of the latest smartphones. This change may not be evident to users but will be welcome nonetheless.
Study details
Analysys Mason interviewed 24 operators including (40%) mobile, (50%) fixed and (10%) cable. A dozen were Tier One operators while two were Tier Three. The rest - Tier Two operators - are classed as having yearly revenues ranging from US$1bn and 10bn. Lastly, half the operators surveyed were European while the rest were split between Asia Pacific and North America. One Latin American operator was also included.