ONAP Architecture Explained: Microservices-Based Platform for 5G Automation
Why ONAP Architecture is Key for 5G
Today’s telecom networks are all about cloud-native transformation. With 5G bringing in ultra-low latency, extensive IoT connectivity, and network slicing, service providers are in need of more than the usual management tools. They’re after orchestration, automation, and real-time intelligence—and they need it all to scale.
This is where ONAP (Open Network Automation Platform) comes into play. The architecture of ONAP, as depicted in the uploaded image, is microservices-based, modular, and cloud-ready, enabling operators to effectively design, deploy, and manage 5G services from start to finish.
In this piece, we’ll dive into the ONAP architecture, its design-time and run-time components, and how its shared services and utilities drive the automation needed for next-generation telecom.
Getting to Know ONAP Architecture
The backbone of ONAP's architecture is its microservices approach, where each functional block is containerized, loosely coupled, and can be scaled independently. Here’s what makes ONAP stand out:
Cloud-native – it’s designed to run on platforms like Kubernetes, OpenStack, or public clouds.
Scalable – resources can adjust to meet demand.
Modular – each function (design, orchestration, analytics) works separately but integrates smoothly.
Open-source – it allows for multi-vendor interoperability.
ONAP’s architecture is divided into three main areas:
Design-Time Environment – focuses on service and resource design.
Run-Time Environment – handles orchestration, control, and automation.
Shared Services and Utilities – includes security, logging, auditing, and integration.
- Design-Time Components: Crafting Services (SDC)
During the design-time phase, ONAP facilitates the creation of services, VNFs (Virtual Network Functions), and CNFs (Cloud-Native Functions) before they’re deployed. The standout module here is the Service Design & Creation (SDC).
Main Functions of SDC:
Service/xNF Design: Develop network services and functions.
xNF Onboarding: Import VNFs/CNFs from vendors.
Work Flow Designer: Outline service logic and workflows.
Controller Design Studio: Create control logic for automation.
DCAE Design Studio: Build models for data collection and analytics.
Catalog: Stores reusable service components.
👉 Why it matters:
Separating design-time from run-time allows operators to pre-set blueprints, cutting service rollout time from months to mere minutes.
- Run-Time Components: Orchestrating & Automating
Once services are designed, they transition into the run-time phase. This is where ONAP takes charge of orchestrating, monitoring, and automating the service lifecycle.
Key Run-Time Components:
Control Loop Automation (CLAMP): Enables closed-loop automation.
Policy Framework: Sets and enforces rules for automation.
Service Orchestration (SO): Manages the lifecycle of network services from end to end.
Active & Available Inventory (A&AI): Keeps a real-time inventory of resources.
External System Register (ESR): Integrates external systems and controllers.
Data Collection, Analytics & Events (DCAE): Gathers telemetry and drives AI insights.
SDN Controller (SDNC): Dynamically manages transport networks.
Application Controller (APP-C): Manages application-level services.
Virtual Function Controller (VNF-C): Oversees VNF operations (like scaling and healing).
👉 Why it matters:
With ONAP’s run-time capabilities, it supports dynamic scaling, fault recovery, and real-time optimization, which are essential for 5G features like network slicing and IoT.
- Shared Services in ONAP
Shared services offer cross-platform functions that are utilized by both design-time and run-time environments.
Core Shared Services:
AAF (Authentication & Authorization): Manages security and role-based access.
OOP (Optimization Framework): Focuses on resource and traffic optimization.
Logging Services: Tracks logs across different components.
Audit (POMBA): Ensures policy compliance.
Multi-Site State (MUSIC): Synchronizes across data centers.
👉 Why it matters:
These services ensure consistency, compliance, and security throughout the ONAP platform.
ONAP Shared Utilities
ONAP also comes packed with a range of utilities that assist with service design and orchestration:
CSSDK: Common Software Development Kit.
Model Utilities: For defining service and function models.
TOSCA Parser: Parses service templates in the TOSCA standard format.
These utilities keep ONAP vendor-agnostic and aligned with industry standards.
Managed Environment: The ONAP Deployment Landscape
ONAP operates within a managed environment that covers various cloud infrastructures:
Private Edge Cloud – ideal for latency-sensitive applications (like autonomous vehicles, AR/VR).
Private DC Cloud – dedicated to core VNFs and enterprise services.
Public Cloud – offers scalability and global reach.
MPLS/IP Transport – connects distributed locations.
ONAP integrates with:
VNFs and PNFs (Physical Network Functions).
sVNFM (specific VNF Managers) & EMS (Element Management Systems).
3rd-party controllers and external systems.
👉 Why it matters:
This hybrid approach provides flexible and distributed orchestration, which is essential for 5G and edge computing scenarios.
ONAP Microservices Bus and Data Routers
An essential component of ONAP’s architecture is the Microservice Bus (MSB) and Data Movement as a Platform (DMaaP):
MSB: Facilitates communication between ONAP microservices.
DMaaP: Oversees message routing and data exchange among ONAP components.
👉 Why it matters:
This design keeps ONAP highly modular and loosely coupled, simplifying upgrades, scaling, and troubleshooting.
Benefits of ONAP’s Microservices-Based Architecture
Telecom operators who adopt ONAP gain several key advantages:
Cloud-native and scalable: Microservices allow for flexible deployments.
End-to-end automation: Covers the whole service lifecycle from design to optimization.
Closed-loop control: Provides real-time monitoring with automated corrective measures.
Vendor neutrality: Supports a variety of vendors for VNFs, CNFs, and PNFs.
Standard compliance: Adheres to open standards like TOSCA and ETSI NFV.
Hybrid cloud support: Seamlessly functions across private, edge, and public clouds.
Example Use Case: Dynamic Network Slicing
Consider a 5G network slicing example:
Design-Time: Operators draft a slice blueprint in SDC.
Run-Time: SO provisions resources while SDNC sets up the transport paths.
Analytics: DCAE keeps an eye on slice performance.
Closed-Loop Automation: CLAMP and the Policy Framework adjust resources on the fly.
Shared Services: Logging and AAF ensure security and compliance.
Outcome: Operators can offer a tailored slice for uses like IoT, AR/VR, or self-driving cars, without any manual input.
Traditional OSS/BSS vs ONAP Architecture Comparison
Feature Traditional OSS/BSSONAP Microservices Architecture Service Deployment Time Weeks to Months Minutes to Hours Automation Partial End-to-End Closed Loop Architecture Monolithic Microservices & Cloud-Native Multi-Vendor Support Limited Full Inter operability Scalability Rigid Dynamic & Elastic
Wrapping Things Up
The ONAP architecture, with its microservices-based platform components, is foundational for today’s 5G networks. It effectively separates design-time from run-time, leverages shared services, and operates within cloud-native environments. This way, ONAP empowers telecom operators to orchestrate, automate, and optimize services effortlessly.
Be it for dynamic network slicing, supporting multi-vendor VNFs and CNFs, or enabling real-time analytics, ONAP delivers the flexibility, scalability, and intelligence that next-gen telecom services demand.
In this age of 5G, IoT, and edge computing, ONAP isn’t just another platform—it’s basically the operating system of the telecom cloud.