ONAP Architecture Explained: Design-Time, Run-Time, and Managed Environment
ONAP Architecture: A Complete Overview
The Open Network Automation Platform (ONAP) is a robust open-source framework designed for automating network functions, services, and operations in contemporary telecom networks. It seamlessly combines service design, orchestration, policy management, and real-time analytics into a single platform, helping operators manage both legacy (PNFs) and virtualized (VNFs) network functions effectively.
The diagram included shows the ONAP architecture, which is split into design-time, run-time, and managed environments, along with layers that support external systems and infrastructure integration. Let’s dive into the details step by step.
Key Components of ONAP Architecture
ONAP is structured into several functional domains:
- Design-Time (SDC – Service Design and Creation)
This phase is all about the creation and onboarding of resources and services before they go live.
Resources Onboarding: Network services, VNFs, and PNFs get uploaded into the system.
Service & Product Design: Operators can craft services, link VNFs/PNFs, and set up workflows.
Policy Creation & Validation: This step involves defining automation policies that steer ONAP's decisions during run-time.
Catalog: A repository for reusable assets like VNFs, service templates, and policies.
CLAMP (Closed Loop Automation Management Platform): It facilitates the design of automation loops and policy-driven operations.
VNF SDK: Ensures vendors can onboard VNFs in a standardized way.
Key role: Prepares network services for deployment by developing blueprints, recipes, and automation rules.
- Run-Time Environment
In this phase, ONAP carries out service orchestration, policy enforcement, and network automation.
Service Orchestration: Manages the deployment, modification, and termination of services in real-time.
DCAE (Data Collection, Analytics, and Events): Known as Holmes, this component collects telemetry data, analyzes events, and initiates corrective actions.
Policy Framework: Implements policies defined during design-time to enforce automation.
AAI/ESR (Active and Available Inventory / External System Repository): Offers a real-time inventory of resources and services.
External API Framework: Facilitates integration with third-party systems and northbound apps.
ONAP Common Services: This includes logging, authentication, and microservices frameworks.
Controllers:
- SDN-C (SDN Controller): Handles Layer 0–3 network functions.
- Application Controller: Manages applications and services at Layer 4–7.
- Virtual Function Controller: Aligns with ETSI for VNF lifecycle management.
- Multi-VIM/Cloud Infrastructure Adapter: Lets ONAP interact with various cloud environments (like OpenStack, Kubernetes, etc.).
Key role: Carries out automation, orchestration, and monitoring of services across multi-domain networks.
- External Systems and Controllers
ONAP connects with external elements to manage both legacy and modern network components.
3rd Party Controllers: Vendor-specific controllers for specialized hardware.
sVNFM (Standard VNF Manager): Oversees the VNF lifecycle.
EMS (Element Management Systems): Traditional management systems for PNFs.
Key role: Ensures smooth interoperability with external vendor systems and standards.
- Managed Environment (Infrastructure Layer)
This layer is all about the foundational infrastructure where services are deployed.
Network Function Layer: Includes VNFs (virtualized network functions) and PNFs (physical network functions).
Hypervisor/OS Layer: Supports virtualization platforms like OpenStack.
VIM (Virtualized Infrastructure Manager): Commercial VIMs or public cloud platforms that handle resources.
Clouds: Comprises private edge cloud, private DC cloud, and public cloud all linked via IP/MPLS.
Key role: Supplies the compute, storage, and networking infrastructure essential for ONAP-managed services.
ONAP Workflow: From Design to Execution
Design-Time Phase:
- Onboard VNFs/PNFs.
- Define service templates and policies.
- Store assets in the catalog.
Run-Time Phase:
- Service requests kick off orchestration.
- Policies are applied for closed-loop automation.
- DCAE keeps an eye on KPIs and sends alerts.
- Controllers (like SDN-C, Application Controller, etc.) set up the network.
Execution in Managed Environment:
- Services get deployed on VNFs, PNFs, or cloud-native functions.
- Infrastructure resources (compute, storage, connectivity) are allocated as needed.
- External controllers and EMS ensure smooth integration with vendor systems.
Benefits of ONAP Architecture
Unified Platform: Merges design, orchestration, policy, and analytics into one comprehensive framework.
Multi-Cloud Support: Operates across private, public, and edge cloud environments.
Vendor Interoperability: Accommodates both VNFs and PNFs through standard interfaces.
Closed-Loop Automation: Leverages analytics and policies for automatic correction of network issues.
Scalability: Supports extensive telecom deployments with a variety of services.
Open Source Ecosystem: Backed by the Linux Foundation and widely embraced by operators.
ONAP vs Traditional Network Management
Feature Traditional OSS/BSSONAP Service Design Manual, siloed Automated, catalog-driven Orchestration Limited End-to-end multi-domain Policy Control Static Dynamic, real-time Automation Reactive Closed-loop proactive Cloud Support Minimal Multi-cloud, edge, public
Use Cases of ONAP
5G Network Automation: Handles slice management and Vo NR service deployment.
Edge Computing: Manages services running in private edge clouds.
Hybrid Networks: Supports VNFs, PNFs, and cloud-native CNFs all in one environment.
Closed-Loop Assurance: Detects faults in real-time and implements corrective measures.
Multi-Domain Orchestration: Facilitates smooth coordination across transport, RAN, and core networks.
Keyword List for the ONAP Blog
ONAP Architecture
ONAP design-time and run-time
Open Network Automation Platform
ONAP orchestration and automation
ONAP telecom use cases
ONAP compared to traditional OSS/BSS
ONAP for 5G network automation
ONAP controllers (like SDN-C, VF-C, APP-C)
ONAP policy framework
ONAP closed-loop automation
ONAP DCAE analytics
ONAP cloud-native integration
Suggested WordPress Tags
ONAP Architecture
Telecom Automation
Network Orchestration
5G Network Automation
Open Network Automation Platform
Cloud-Native Networks
OSS/BSS Transformation
Telecom Network Management
Virtualized Network Functions (VNFs)
Physical Network Functions (PNFs)
Network Policy Automation
Telecom Cloud Integration
Conclusion
The ONAP architecture offers a comprehensive framework for telecom network automation, uniting design-time, run-time, and managed environments into a cohesive platform. With its integration of service orchestration, analytics, and closed-loop automation, ONAP empowers operators to handle next-generation networks efficiently.
As the landscape for 5G, edge computing, and cloud-native deployments evolves, ONAP will undoubtedly play a pivotal role in ensuring scalability, interoperability, and agility for telecom operators around the globe.