BSS/OSS Academy
🔧
Section 11.1

MANO vs Cisco NSO: What's the Difference?

Comparing ETSI MANO, Cisco NSO, and SOM — what each does, where they overlap, and when to use which.

In modern telco architectures, service orchestration does not stop at SOM. Below SOM, two major platforms frequently appear: ETSI MANO (Management and Orchestration) for virtualised and cloud-native network functions, and Cisco NSO (Network Services Orchestrator) for device-level network service automation. These three systems are complementary, not competing — each operates at a different abstraction layer.

BSS / COM

Commercial order capture and product lifecycle

SOM — Service Order Management

Service orchestration layer — decomposes CFS → RFS and delegates to the correct execution engine

VNF/CNF lifecycleDevice configuration
ETSI MANO

VNF/CNF lifecycle management

NFVOVNFMVIM
Cisco NSO

Network device configuration

YANGNETCONFCLI
NFVI / Physical Network / Cloud

Compute, storage, switches, routers, Kubernetes clusters, OpenStack

SOM

Service Order Management

The OSS orchestration engine that translates commercial intent into service-level fulfilment. SOM receives service orders from COM, decomposes CFS into RFS items, and delegates execution to the correct downstream system — MANO for VNF/CNF lifecycle, NSO for device configuration, workforce for physical installs. SOM is the system of record for service order state and manages cross-domain dependencies and rollback.

TMF641CFS/RFSOrchestrationCross-domain

ETSI MANO

NFV Management and Orchestration

The ETSI-standardised framework for managing the lifecycle of Virtual Network Functions (VNFs) and Cloud-Native Network Functions (CNFs). MANO consists of three functional blocks — NFVO (orchestrates network service composition), VNFM (manages individual NF instances: instantiate, scale, heal, update, terminate), and VIM (manages compute, storage, and networking on the NFVI). MANO operates at the infrastructure and VNF lifecycle layer.

ETSI NFVVNF/CNFNFVOVNFMVIM

Cisco NSO

Network Services Orchestrator

A model-driven network automation platform that uses YANG data models and a transactional configuration engine to manage device configurations across multi-vendor networks. NSO excels at Day-1 and Day-2 device configuration — routers, switches, firewalls — via NETCONF, CLI, SNMP, or REST southbound interfaces. NSO operates at the network device configuration layer, not the VNF lifecycle layer.

YANGNETCONFMulti-vendorDay-1/Day-2
The orchestration stack: SOM delegates to MANO and NSO based on the RFS type being fulfilled

Side-by-Side Comparison

SOM

E2E service fulfilment orchestration (TM Forum)

  • CFS → RFS decomposition and delegation
  • Day-0 through Day-2 at service level
  • SB: TMF652, MANO/NSO adapters
  • NB: TMF641 (COM), TMF638 (SLM)
  • State: order + CFS/RFS instance

ETSI MANO

VNF/CNF lifecycle on virtualised infra (ETSI NFV)

  • Instantiate, scale, heal, terminate NFs
  • Day-0/1 focus — limited Day-2
  • SB: OpenStack, Kubernetes, VMware
  • NB: SOL005 REST APIs
  • State: VNF/NS instance, NFVI allocation

Cisco NSO

Model-driven, multi-vendor device config (YANG)

  • Create, modify, rollback, audit configs
  • Day-1/2 focus — ongoing compliance
  • SB: NETCONF, CLI, SNMP, gNMI
  • NB: REST API, NETCONF, CLI
  • State: intended vs actual config

When to Use MANO, NSO, or Both

Rule of Thumb: Match the Object to the Engine
Use MANO when the task involves managing the lifecycle of a virtualised or cloud-native workload (VM, container, Helm chart). Use NSO when the task involves pushing configuration to network devices (routers, switches, firewalls). Use both when a service requires a new VNF/CNF to be deployed and device configurations to be updated to integrate it into the network. Use neither when the task is purely a physical installation (workforce management) or a SaaS integration (cloud API). SOM always sits above — it orchestrates which engine(s) to call based on the RFS decomposition.

Decision Guide: Which System Handles What?

ScenarioSystem(s) InvolvedWhy
Deploy a virtual firewallMANOVNF lifecycle: create VM, attach vNICs, verify health. No device config needed yet.
Configure an L3VPN across PE routersNSODevice configuration: push VRF, BGP, and interface configs to PE routers via NETCONF.
Deploy SD-WAN CPE with cloud gatewayMANO + NSOMANO deploys the vCPE/CNF. NSO configures the underlay routing and IPsec tunnels on PE routers.
Provision a new GPON broadband serviceNeither (EMS / SDN Controller)Access network provisioning is typically handled by Element Management Systems, not MANO or NSO.
Install physical CPE at customer siteNeither (Workforce Management)Physical installation requires a field technician, managed by WFM (TMF646).
Activate a cloud-based UCaaS serviceNeither (Cloud API)SaaS activation via the vendor's provisioning API — no network function or device config involved.

Section 11.1 Key Takeaways

  • MANO, NSO, and SOM are complementary systems operating at different abstraction layers — not competing alternatives
  • MANO manages VNF/CNF lifecycle (instantiate, scale, heal, terminate) on virtualised infrastructure per ETSI standards
  • NSO manages device configuration (create, modify, rollback, audit) across multi-vendor networks using YANG models
  • SOM orchestrates end-to-end service fulfilment and delegates infrastructure and device work to MANO and NSO
  • The RFS type in the service catalog determines which execution engine SOM delegates to
  • Complex services may require both MANO and NSO working in coordination, with SOM managing cross-domain dependencies
  • Neither MANO nor NSO replaces SOM — they lack commercial context, service-level state management, and cross-domain orchestration