Sorry, you need to enable JavaScript to visit this website.


Your feedback is important to keep improving our website and offer you a more reliable experience.


BY Huang Haibin ON Aug 26, 2019

Due to the complexity and uncertainty of telecom services, a large number of manual operations and work order circulations have severely restricted the rapid development of the telecommunications industry. With the advent of 5G and IoT (Internet of Things), the network has become more complex and the traditional model cannot continue. It is very important to know how to deploy telecom services in real-time, on a large scale, and automatically. At present, the mainstream idea is to use cloud services and tools from other Internet companies to implement telecom network elements in software and to replace traditional physical network elements with hardware acceleration technology. In this wave of transformation, the open source community has provided unprecedented vitality to promote network automation.

In 2017, The Linux Foundation announced that two open source projects, Open-O (developed by China Mobile*) and ECOMP (developed by AT&T*) were merging into Open Network Automation Platform (ONAP*), beginning a new journey for network orchestration automation.

Image source

To automate orchestration networks, ONAP[1] divides this work into design time and run time. The design time effort is to develop a use case template that can be based on the TOSCA model, an OpenStack* Heat model, or another model. The run time instantiates the use case according to the template created in design time. The following sections introduce the working mechanism and process of ONAP design time and run time.


The use case template in this article conforms to the ETSI (European Telecommunications Standards Institute) SOL001 standard. The ETSI SOL001[2] describes Protocols and Data Models which is based on the Topology and Orchestration Specification for Cloud Applications (TOSCA) specification. However, templates for other models could be used, depending on the scenario.

The guidance in ETSI SOL001 was used to construct Virtual Network Functions (VNF). The VNF Descriptor (VNFD) structure in the diagram below, includes Virtual Deployment Unit (VDU), Internal Virtual Link, External Virtual Link, and Deployment Flavor. Next, the template file was packaged according to ETSI SOL004[3] which is the VNF package specification.

Below is an example template available on GitHub*[4], which includes one simple VNF including two VDUs linked by one Virtual Link.

After the design was completed in SDC, the CSAR package was verified and tested. After finishing these processes, the CSAR package was then distributed to VFC, Policy, and Others. The package can be used in run time. The SDC package distribution is based on subscriptions, so modules that do not subscribe are unable to receive the distributed package. For security, a username and password are needed to authenticate when subscribed.


Run time is the process of instantiating a template and finding the right placement based on the user requirements is the major task in the instantiation. Refer to the diagram and steps below for the detailed process.

  1. VFC (Virtual Function Controller)/SO (Service Orchestration) sends out a homing request to OOF (ONAP Optimization Framework) containing resource info.
  2. OOF gets cloud information from AAI (Active & Available Inventory).
  3. OOF gets all constraint information including HPA (Hardware Platform Awareness) from Policy.
  4. OOF compares AAI cloud information and Policy information to decide which cloud should be used and which flavor should be used.
  5. OOF returns a homing response that includes selected cloud information and flavor.
  6. VFC/SO calls multi-cloud to create VNF, which includes VDU, Virtual Link, and Connection Port.
  7. Multi-cloud calls the corresponding cloud to Create Virtual Machine, Network, Port in the cloud.


This section discusses the vCPE TOSCA with the HPA use case as an example of how to automate deployment using ONAP.

First, the physical network elements of CPE were divided into 5 VNFs (Virtual Network Functions) grouped by function. The infra VNF is for vCPE support. The other VNFs (vbrgemu, vbng, vgmux and vgw) provide vCPE functionality.

  • infra: vDHCP, vAAA, vDNS, vWEB
  • vbrgemu: BRG Emulator (Bridged Residential Gateway Emulator)
  • vbng:  VPP based Broadband Network Gateway
  • vgmux: VPP based Virtual Gateway Multiplexer
  • vgw: VPP based Virtual Gateway

Source: Reference [5]

Second, the VNF and NS (Network Service) were designed based on vCPE business logic in SDC. The completed design is shown in the following diagram.

Finally, the vCPE TOSCA template/CSAR package was distributed to VFC. VFC will create a network and VNF according to run time flow in the Wind River* environment through multi-cloud. The picture below shows the true physical test environment, which is located in the integration lab at Intel.

Source: Reference [6]


With the development of 5G computing, network deployment and management become very complex, and ONAP is urgently needed for automated management and deployment. At the same time, ONAP also needs to make many improvements to achieve intelligence, and analysis based on big data makes it more accurate for physical devices.

We encourage you to participate in the community by downloading the code, joining the mail list, and reading the ONAP documentation and the ONAP wiki. With your help, we can improve network automation!


[1] ONAP:

[2] ESTI SOL001:

[3] ETSI SOL004:

[4] Example template:

[5] ONAP Casablanca Use Case with HPA end to end:

[6] The Automatic Deployment of vCPE TOSCA with HPA:


Haibin Huang, Cloud Software Engineer at NST/DSS/SSP, Intel Corporation