EMS/NMS Architecture
Last updated 14 Oct 2026
At a glance
Element and network management systems (EMS/NMS) are the vendor-specific platforms that configure, monitor and upgrade network equipment. They sit below ROM and network automation, and they are where vendor detail lives, so the architectural question is where ROM’s responsibility stops and theirs begins.
The picture
Intent flows down
State flows back up
↑ Discovery and reconciliation
What is actually on the network feeds resource inventory (TMF639), so inventory does not drift from reality.
↑ Alarms and performance
Faults and counters go to assurance (TMF642), usually from the EMS or NMS, not from ROM.
When this path fits: One vendor in the domain, and its EMS exposes a usable northbound API.
How it works
EMS and NMS
An EMS manages one vendor’s equipment in one domain: configuration, faults, performance counters, software upgrades. Examples are Ericsson ENM for RAN, Huawei iManager for transport and Ciena’s management platform for optical. An NMS spans more: several element types or vendors, topology and fault correlation. Some products do both, and some network automation platforms take on part of the EMS role.
The practical rule for the boundary
If a task needs to know the vendor, model, firmware or hardware variant of a device, it belongs in the EMS or NMS. If it needs to coordinate several vendors or domains to deliver a service, it belongs in ROM or network automation. ROM tells the network what is needed; the EMS knows how a particular box does it.
Three common paths
- ROM → EMS. Simplest, when a domain has one vendor and its EMS has a usable northbound API.
- ROM → network automation → devices. A platform such as Cisco NSO or Nokia NSP holds the service and device models and pushes configuration over NETCONF/YANG or gNMI. Fits multi-vendor paths with modern devices.
- ROM → network automation → EMS. Automation coordinates, but some equipment can only be configured through its own EMS, so automation calls it rather than the device.
Real estates mix all three, domain by domain. One vendor platform can also cover two layers at once, so the boxes in the picture are roles, not necessarily separate products.
What flows back up
Whatever the path for configuration, two flows run upwards. Discovery: the EMS knows what is actually installed, so resource inventory should be reconciled against it rather than maintained by hand. Alarms and performance: faults and counters usually reach assurance from the EMS or NMS, not through ROM.
Protocols
| Protocol | Typical use | Found in |
|---|---|---|
| NETCONF/YANG | Model-driven configuration with validation and rollback | Modern routers, optical, O-RAN |
| gNMI | Streaming telemetry and configuration | Newer IP and data-centre equipment |
| SNMP | Monitoring and simple configuration | Almost everything, especially older gear |
| CLI / SSH | Device commands, often scripted | Where nothing better exists |
| TL1, CORBA, vendor REST | Legacy and vendor-specific management | SDH, older transport, vendor EMS APIs |
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Device configuration (actual) | Network element, managed through the EMS | — | Network automation | The network is the final truth of what is configured |
| Intended service and device models | Network automation (where used) | — | ROM | Holds what should be configured, across vendors |
| Resource order | ROM | — | SOM | TMF652 |
| Discovered equipment and topology | EMS / NMS | — | Resource inventory | Feeds TMF639 reconciliation |
| Planned and assigned resources | Resource inventory | — | ROM, EMS | — |
| Alarms and performance counters | EMS / NMS | — | Assurance | TMF642 alarms to the fault platform |
In practice
A mid-size operator typically runs three to five EMS platforms, one per major vendor domain, each with its own data model, API style and alarm codes. That is why integration effort concentrates here, and why programmes that try to drive devices directly from ROM, bypassing the EMS, rediscover the vendor quirks the EMS already handles.
O-RAN shifts part of the RAN EMS role to the SMO (Service Management and Orchestration), which is managed over NETCONF/YANG. That makes RAN management more standard, but many networks will run traditional RAN EMS and O-RAN side by side for years.
Changes made directly through an EMS, bypassing ROM, are the main cause of inventory drift: the network changes and the inventory does not. Regular reconciliation against EMS discovery is the remedy.
The trade-off
What it solves
Keeping vendor-specific management in the EMS lets ROM and automation reason about services and resources rather than device quirks, and reuses tooling the vendor already maintains.
What it does not solve
- It does not give one consistent model: each EMS has its own data, APIs and alarm codes.
- It does not stop engineers changing the network through the EMS outside the order flow.
What it adds
- One integration per EMS, upgraded on each vendor’s schedule.
- Reconciliation between EMS discovery and resource inventory has to run continuously.
Architecture decision
Integrate ROM with each EMS directly, or put network automation in between?
Direct to each EMS
Choose when Each domain is single-vendor and its EMS has a reliable northbound API
Network automation in between
Choose when Activation paths cross vendors, and devices support NETCONF/YANG or gNMI
Breaks if Automation is added as a pass-through to a single-vendor EMS (extra layer, no gain), or ROM is wired to devices directly and has to absorb every vendor quirk itself.
Takeaways
Key Takeaways
- EMS and NMS hold vendor-specific management; ROM and automation hold cross-vendor intent.
- If a task needs to know the device model or firmware, it belongs below ROM.
- ROM → EMS, ROM → automation → devices and ROM → automation → EMS are all common; none is mandatory.
- Discovery from the EMS should keep resource inventory honest; alarms reach assurance from the EMS, not ROM.
Check yourself
A single-vendor fibre access domain has an EMS with a good API. Should ROM call it directly or go through network automation?Show answerHide
Directly is usually right: one vendor and a reliable API leave automation with nothing to coordinate. Add it when the path crosses vendors.
Activation keeps failing because ROM assigns ports the network says are in use. Where do you look first?Show answerHide
At reconciliation between EMS discovery and resource inventory: changes are being made through the EMS outside the order flow, and inventory has drifted.