EMS & NMS – Element & Network Management Systems
🎯 Learning Objective: Understand the operational purpose of EMS (vendor-focused element management) and NMS (network-wide correlation, topology, service impact). Learn how they work together with mediation layers to provide unified network visibility.
EMS – Element Management System
EMS is a vendor-focused management platform for a network technology or equipment family. It handles device-level operations that NMS cannot (or should not) perform.
What EMS Does
- Element-level configuration – Pushing configs to routers, gNBs, switches
- Software upgrades – Managing firmware versions across device families
- Telemetry collection – Gathering performance metrics from devices
- Fault management – Collecting and forwarding alarms to NMS
- Device analytics – Vendor-specific diagnostics, logs, health checks
Example Vendor Management Platforms
- Nokia: NetAct – 4G/5G RAN and core management
- Ericsson: ENM – Multi-vendor RAN and core
- Huawei: U2020 / M2000 – Wireless network management
- Cisco: Cisco Prime / DNA Center – IP/MPLS management
NMS – Network Management System
NMS aggregates data from multiple EMS systems to provide a unified operational view across the entire network, regardless of vendor.
What NMS Does
- End-to-end topology – Visualizing how routers, switches, and base stations connect
- Service impact analysis – Determining which customers/SLAs are affected
- Root cause correlation (RCA) – Reducing thousands of alarms to a single cause
- Cross-domain coordination – RAN, transport, core, cloud domains
- Performance trending – Historical analysis and capacity planning
NMS Protocols
- SNMP – Traditional device polling and traps
- REST APIs – Modern EMS integration
- Kafka – Streaming telemetry events
- Netconf/gNMI – Modern configuration and telemetry
The Mediation Layer – Critical OSS Architecture
Many telecom operators use mediation layers between EMS and NMS to normalize, enrich, filter, and route data across domains before it reaches OSS applications.
Nokia EMS
Vendor-specific alarms and telemetry
Ericsson EMS
Proprietary event and KPI formats
Huawei EMS
Vendor-native device management
Normalize • Enrich • Deduplicate • Route
Correlation • Topology • Service Impact • RCA
Mediation Functions
- Normalization: Convert vendor-specific alarm formats to common model
- Enrichment: Add inventory, topology, service context
- Deduplication: Remove duplicate events
- Filtering: Suppress informational events
- Routing: Send to appropriate OSS applications
Why Mediation Matters
- Nokia alarms look different from Ericsson alarms
- Without mediation, NMS sees incompatible data
- Mediation creates a unified operational view
- Enables multi-vendor OSS without custom adapters
Real-World Example: EMS + NMS + Mediation in Action
Scenario: A fibre cut in Mumbai affects multiple gNBs from different vendors. EMS platforms generate vendor-specific alarms, mediation normalizes them, and NMS identifies the root cause and customer impact.
Nokia gNB
CPRI link down alarm
Ericsson gNB
eCPRI interface failure
Converts vendor-specific events into unified OSS format
Identifies single root cause → Fibre Cut
Maps impact to 128 affected enterprise customers
EMS vs NMS – Key Differences
| Aspect | EMS | NMS |
|---|---|---|
| Scope | Single device family / vendor-specific | Entire network, multi-vendor |
| Primary User | Vendor specialists, field engineers | NOC engineers, operations teams |
| Key Function | Element config, firmware, device logs | Topology, correlation, service impact |
| Protocols | SNMP, CLI, Netconf, gNMI (vendor-proprietary) | REST APIs, Kafka, SNMP traps (standardized) |
| Output Example | Device-specific alarm (e.g., Nokia alarmId 12345) | Correlated alarm → impacted service → customer ticket |
| Deployment | Per vendor (multiple EMS instances) | One or few NMS instances covering entire network |
NMS Architecture – FCAPS Layers
NMS Architecture based on TM Forum FCAPS model (Fault, Configuration, Accounting, Performance, Security)
Why This Matters in Real Operations
NOC Engineers Use NMS
NOC teams primarily use NMS for daily monitoring, not EMS. NMS provides the "single pane of glass" across all vendors.
EMS for Deep Dive
EMS is used for detailed troubleshooting, firmware upgrades, and vendor-specific diagnostics that NMS cannot perform.
Alarm Storms Are Real
Poor NMS correlation leads to alarm storms – thousands of alarms without root cause identification. Good NMS suppresses dependent alarms.
Mediation Is Critical
Without mediation, NMS sees incompatible vendor formats. Mediation layers are essential for multi-vendor integration success.
Key Terms You Must Know
TM Forum term for EMS functions
TM Forum term for NMS functions
Identifying the source of an alarm or problem
Grouping related alarms to identify root cause
Physical and logical connections between network elements
Mapping network faults to affected services/customers
Normalizes vendor-specific data for NMS
Hundreds/thousands of alarms from a single root cause
Fault, Configuration, Accounting, Performance, Security
gRPC Network Management Interface (modern telemetry)
Common Questions
Q1. What is the difference between EMS and NMS?
EMS manages individual device families (vendor-focused). NMS aggregates across multiple EMS to provide end-to-end network visibility, topology, root cause analysis, and service impact.
Q2. Why can't NMS bypass EMS and talk directly to devices?
Some NMS systems can talk directly using SNMP or gNMI. However, EMS provides vendor-specific value: bulk configuration, software upgrades, device analytics, and deep diagnostics that NMS lacks.
Q3. How does NMS reduce alarm noise?
Through root cause correlation. A single fibre cut generates hundreds of alarms from multiple devices. NMS identifies the fibre cut as the root cause and suppresses dependent alarms.
Q4. What role does mediation play between EMS and NMS?
Mediation normalizes vendor-specific alarm formats, enriches data with inventory/topology, deduplicates events, and routes processed data to NMS, assurance, or orchestration platforms.
Q5. What is an alarm storm and how does NMS prevent it?
Alarm storm = hundreds of alarms from a single root cause. NMS uses correlation to identify root cause and suppress child/dependent alarms, presenting only the actionable root cause to operators.
Q6. How does NMS determine service impact?
Using service models and inventory mappings. NMS knows which network resources serve which customers. When a device fails, NMS traverses the dependency tree to list affected services and customers.
Q7. What protocols are used for EMS-NMS integration?
Traditional: SNMP traps, Corba, XML over SOAP. Modern: REST APIs, Kafka event streams, gRPC. Many operators still maintain legacy interfaces for older equipment.
📌 Key Takeaways:
- EMS = vendor-focused, device-level management, configuration, firmware, telemetry
- NMS = multi-vendor, network-wide, service-aware management with topology and correlation
- Mediation layers normalize vendor data before it reaches NMS – critical for multi-vendor integration
- NOC engineers use NMS daily for monitoring; EMS for deep dive troubleshooting
- Root cause correlation transforms alarm storms into actionable insights
- FCAPS (Fault, Config, Accounting, Performance, Security) is a classic telecom/network management functional model
- Modern OSS uses cloud-native architectures but EMS/NMS functional split remains valid
- Multi-vendor environments are the norm – integration skills are critical