📦

Section 7.4

EMS/NMS Architecture

Where ROM stops and EMS/NMS begins — vendor-specific element management, integration patterns, protocol landscape, and the O-RAN boundary shift.

What Are EMS and NMS?

Element Management Systems (EMS) and Network Management Systems (NMS) are the vendor-specific platforms that manage physical and virtual network equipment. They sit between the higher-level orchestration stack (ROM, NSO) and the network elements themselves. Every router, switch, OLT, gNodeB, and core network function is managed by an EMS or NMS — either the vendor's own platform or a multi-vendor NMS.

EMS — Element Management System

A vendor-specific management platform for a single technology domain or product family. Manages device configuration, fault monitoring, performance data collection, and software upgrades for a specific set of network elements. Examples: Huawei iManager U2000, Nokia NetAct, Ericsson ENM.

NMS — Network Management System

A broader management platform that may span multiple vendors or technology domains. Provides cross-domain visibility, topology management, and fault correlation. Can be vendor-specific (Nokia NSP) or multi-vendor (IBM Netcool, BMC PATROL). Some NMS platforms also provide service-level views.

ROM tells the network what to do. EMS/NMS translates that intent into the vendor-specific language the equipment actually understands.
— OSS integration principle

Why EMS/NMS Still Matters

In a world of SDN controllers and cloud-native orchestration, EMS/NMS platforms can seem like legacy. They are not. Even modern networks require vendor-specific management for tasks that higher-level orchestrators cannot or should not handle.

Device lifecycle management — firmware upgrades, hardware inventory, port management, and alarm thresholds are vendor-specific and managed by EMS
Fault management — EMS collects traps, syslog, and SNMP alarms from elements and correlates them before forwarding to upstream assurance systems
Performance monitoring — granular per-port, per-interface, per-cell KPIs are collected by EMS and aggregated by NMS for capacity planning
Auto-discovery — EMS discovers new equipment and topology changes, feeding resource inventory with accurate network state
Vendor-specific configuration — even with NETCONF/YANG, vendors have proprietary extensions, custom MIBs, and model deviations that only the EMS handles correctly
Day-2 operations — ongoing config changes, policy updates, and maintenance windows are managed through EMS, not through the fulfilment stack

The Persistence of EMS/NMS

Operators who attempt to bypass EMS/NMS and drive network elements directly from ROM or NSO discover two things: (1) vendor-specific quirks are endless, and (2) the EMS already handles them. The pragmatic approach is to integrate with EMS/NMS rather than replace it — unless you are building a greenfield SDN-only network.

The Handoff Boundary

Understanding where ROM stops and EMS/NMS begins is one of the most important architectural decisions in any OSS transformation. Get it wrong and you end up with ROM trying to manage vendor-specific quirks, or EMS/NMS trying to orchestrate cross-domain services it was never designed for.

ROM vs EMS/NMS vs NSO — Responsibility Boundary

Responsibility	ROM	NSO	EMS/NMS
Service decomposition (CFS → RFS)	✓	—	—
Cross-domain orchestration	✓	✓	—
Vendor-specific device config	—	Partial	✓
Firmware / software upgrades	—	—	✓
Fault collection & correlation	—	—	✓
Performance monitoring (per-element)	—	—	✓
Auto-discovery & topology	—	—	✓
NETCONF/YANG model management	—	✓	✓
Multi-vendor abstraction	—	✓	—
Day-2 config changes (maintenance)	—	—	✓
Network-wide policy push	—	✓	—
Resource inventory sync	✓ (consumer)	—	✓ (source)

The Practical Rule

If the task requires knowing the vendor, model, firmware version, or hardware variant of a specific device — it belongs in EMS/NMS. If the task requires coordinating across multiple vendors or domains to deliver a service — it belongs in ROM or NSO.

Integration Patterns: ROM ↔ EMS/NMS

How ROM communicates with EMS/NMS depends on the network domain, vendor maturity, and whether an NSO layer sits between them.

Pattern 1: ROM → EMS (Direct)

ROM sends resource order

ROM

ROM dispatches a resource order item to the EMS adapter with the target configuration parameters.

EMS adapter translates

Adapter

The adapter converts the abstract resource order into the vendor-specific API call, CLI command, or NETCONF RPC the EMS expects.

EMS configures element

EMS

EMS pushes the configuration to the network element and returns success/failure status.

ROM updates inventory

ROM

On success, ROM updates the resource inventory with the provisioned state.

Pattern 2: ROM → NSO → EMS (Mediated)

ROM sends resource order

ROM

ROM dispatches the resource order to NSO (e.g. Cisco NSO, Nokia NSP) which provides a multi-vendor abstraction layer.

NSO decomposes to device config

NSO

NSO uses YANG models and NEDs (Network Element Drivers) to translate the intent into vendor-specific configurations.

NSO pushes via NETCONF or EMS

NSO / EMS

NSO either pushes directly to the device via NETCONF/YANG or delegates to the vendor EMS for complex operations.

Status propagates back

ROM

Completion status flows back through NSO to ROM, which updates resource inventory.

When to Use NSO vs Direct EMS

Use NSO when you have multiple vendors in the same activation path (e.g. Cisco routers + Juniper switches in an L3VPN). Use direct EMS integration when the domain is single-vendor and the EMS already provides reliable APIs. Adding NSO as a pass-through to a single EMS adds latency and complexity without value.

Protocol Landscape

EMS/NMS platforms communicate with network elements using a range of protocols, from legacy SNMP to modern NETCONF/YANG. The protocol mix depends on equipment age, vendor, and domain.

EMS/NMS Protocol Comparison

Protocol	Use Case	Direction	Maturity
SNMP v2c/v3	Fault monitoring, basic config, KPI polling	NMS → Element	Legacy but ubiquitous
NETCONF/YANG	Configuration management, state retrieval	NMS ↔ Element	Modern standard — preferred for new deployments
gNMI/gRPC	Streaming telemetry, real-time performance data	Element → NMS	Emerging — high-volume telemetry use cases
CLI/SSH	Legacy config push, vendor-specific commands	NMS → Element	Legacy — avoid for new integrations
CORBA/TL1	Legacy optical/transport management	NMS → Element	Legacy — found in older SONET/SDH and DWDM gear
REST API	Cloud-native NFs, SDN controllers, O-RAN	NMS ↔ Element	Modern — 5G Core NFs and SDN controllers
O-RAN O1 (NETCONF)	O-RAN managed elements (O-DU, O-CU, O-RU)	SMO → RAN	Emerging — O-RAN Alliance specified

EMS/NMS Vendor Landscape

Every major network equipment vendor ships an EMS for their own gear. Multi-vendor NMS platforms exist but are less common in practice because operators typically manage each vendor domain through its own EMS.

Common EMS/NMS Platforms by Domain

Vendor	Platform	Primary Domain	Key Capabilities
Huawei	iManager U2000 / NCE	RAN, Transport, Fixed Access	End-to-end management for Huawei gear — config, fault, PM, software management
Nokia	NetAct / NSP	RAN, Core, Transport	NetAct for RAN management, NSP (Network Services Platform) for transport and IP
Ericsson	ENM (Ericsson Network Manager)	RAN, Core, Transport	Unified management for Ericsson RAN (gNB) and core — auto-integration, bulk CM
Ciena	MCP (Manage, Control and Plan)	Optical, Packet	Multi-layer management for Ciena optical and packet platforms
Cisco	DNA Center / Crosswork	Enterprise, IP/MPLS	DNA Center for campus/enterprise, Crosswork for SP transport automation
Juniper	Paragon (Pathfinder/Planner)	IP/MPLS, Transport	Traffic engineering, path computation, and transport management
Samsung	Samsung NMS	RAN (5G)	Management for Samsung 5G RAN gear — increasingly common in O-RAN deployments
Multi-vendor	IBM Netcool / BMC Helix	Cross-domain	Fault management and event correlation across multiple vendor EMS platforms

The Multi-EMS Reality

A typical mid-size operator runs 3-5 different EMS platforms — one per major vendor domain (e.g. Ericsson ENM for RAN, Huawei iManager for transport, Ciena MCP for optical). Each EMS has its own data model, API style, and alarm taxonomy. This is why integration and normalisation layers (NSO, fault mediation) exist.

EMS/NMS and Resource Inventory

EMS/NMS is the primary source of truth for physical and logical network state. Resource inventory in the BSS/OSS stack should be fed by EMS/NMS discovery and reconciliation — not maintained independently. When these two diverge, activation fails because ROM provisions against inventory that does not match reality.

Auto-discovery — EMS discovers equipment, ports, links, and logical resources (VLANs, routes) and publishes them to resource inventory via synchronisation
Reconciliation — periodic comparison between what resource inventory believes exists and what EMS/NMS actually sees on the network. Discrepancies trigger investigation
State updates — when EMS detects a port failure, card removal, or config change, it pushes state updates to resource inventory to keep allocation data accurate
Capacity feeds — EMS provides real-time capacity data (port utilisation, bandwidth availability) that resource inventory exposes for pre-qualification and assignment

The Inventory Drift Problem

If resource inventory is not regularly reconciled with EMS/NMS, it drifts. Engineers make changes directly on the network via EMS (bypass ROM), manual interventions go unrecorded, and auto-discovery finds equipment that inventory does not know about. Drift is the number one cause of activation failures in brownfield environments.

O-RAN and the Changing EMS Boundary

O-RAN (Open RAN) introduces a new management architecture that shifts some traditional EMS responsibilities to the SMO (Service Management and Orchestration) platform. This changes the integration boundary for ROM.

Traditional RAN EMS vs O-RAN SMO

Capability	Traditional RAN EMS	O-RAN SMO
Config management	Vendor-proprietary	O1 interface (NETCONF/YANG)
Fault management	Vendor-specific alarms	Standardised O1 alarm model
Performance data	Vendor KPI format	Standardised PM counters
RAN intelligent control	Not supported	Near-RT RIC (xApps) + Non-RT RIC (rApps)
Multi-vendor RAN	Single vendor only	Designed for multi-vendor DU/CU/RU
ROM integration	Via vendor EMS adapter	Via O1 or NSMF standardised APIs

O-RAN Impact on BSS/OSS

For BSS/OSS architects, O-RAN means that RAN management becomes more standardised and API-driven — similar to how 5G Core NFs are managed via SBI. ROM can integrate with the O-RAN SMO using NETCONF/YANG rather than vendor-specific EMS adapters. However, O-RAN adoption is still early and most operators run traditional EMS alongside O-RAN SMO during transition.

Decision Framework: When to Retain EMS/NMS

In a BSS/OSS transformation, the question is not whether to keep EMS/NMS — you almost certainly will. The question is how to integrate the new O2A stack with existing EMS/NMS platforms.

Always retain EMS/NMS when the network equipment vendor requires it for warranty, support, and software upgrades — bypassing the EMS may void vendor support contracts
Integrate via NSO when you need multi-vendor orchestration in the same activation path (e.g. Cisco + Juniper in an enterprise VPN service)
Integrate ROM directly with EMS when the domain is single-vendor and the EMS provides a reliable northbound API (REST, NETCONF, or CORBA)
Replace EMS with NSO only for domains where the EMS adds no value beyond config push — rare in practice, and only viable for simple IP/Ethernet domains
Plan for O-RAN SMO alongside traditional RAN EMS if you are deploying O-RAN gear — both will coexist during the transition period

Section 7.4 Key Takeaways

EMS/NMS manages vendor-specific network elements — config, faults, performance, discovery, and firmware. It is not going away.
ROM orchestrates services across domains. EMS/NMS translates that intent into vendor-specific device commands. The boundary is clear: cross-domain = ROM/NSO, single-vendor device = EMS/NMS.
Resource inventory must be reconciled with EMS/NMS regularly — inventory drift is the top cause of activation failures in brownfield networks.
A typical operator runs 3-5 EMS platforms. Integration and normalisation layers (NSO, fault mediation) bridge the multi-vendor gap.
O-RAN shifts RAN management toward standardised APIs (O1 interface), but traditional RAN EMS will coexist for years during transition.
In a transformation, retain EMS/NMS and integrate — do not attempt to bypass it unless you are building a pure SDN greenfield.