Network Orchestrator Variants & Specialised Domains
A taxonomy of the six system classes commonly called "orchestrators" β EMS, NMS, domain orchestrator, SDN controller, specialised provisioning engine, and manual / scripted β and the COTS products that fulfil them. Maps the specialised and legacy domains every Tier-1 estate also runs (microwave, satellite, SDH, ATM, GPON, SIP/voice, legacy optical, enterprise WiFi) to their typical orchestrator class and answers honestly whether each is reachable from a modern domain orchestrator. Closes with catalog and integration implications, and the anti-patterns that derail programmes which assume the modern domain-controller model applies everywhere.
Sections 11.3 to 11.5 walked through three modern orchestration domains β IP/MPLS, mobile core, fixed access β where domain controllers, model-driven APIs, and standard YANG service models exist and are reasonably mature. Section 11.6 composed across them. This section addresses everything else: the specialised, legacy, or technology-bound orchestrators that every Tier-1 estate also operates, and which rarely fit into a clean catalog-and-controller story.
The reason this matters is decision literacy. A transformation programme that assumes the modern domain-controller pattern applies everywhere will be ambushed the first time it touches microwave backhaul, satellite SD-WAN backup, an SDH leased-line tail, or a voice/SBC stack. Each of these domains has its own orchestrator class, its own COTS products, and its own integration shape β and most of them predate model-driven management entirely.
The Orchestrator Type Taxonomy
Before mapping products to domains, the categories themselves need to be made explicit. "Orchestrator" is used loosely in industry to describe at least six distinct classes of system, each sitting at a different layer above the network and offering a fundamentally different abstraction.
Six classes of system commonly called "orchestrators"
| Type | What it does | Where it sits |
|---|---|---|
| EMS β Element Management System | Manages one vendor's product family β config, fault, performance β typically with vendor-specific protocols and data models | Lowest layer above devices; one per vendor product line |
| NMS β Network Management System | Multi-element / multi-vendor network view, usually fault- and performance-centric; weak on service-level abstractions | Above EMS; aggregates fault/perf, sometimes config |
| Domain Orchestrator | Service-aware, single domain, exposes modern APIs (NETCONF/YANG, gNMI, TMF); carries service-level state and intra-domain rollback | Above NMS β Cisco NSO, Nokia NSP, Juniper Paragon, Blue Planet sit here |
| SDN Controller | Programmatic configuration of an SDN-managed domain (transport SDN, DC fabric, WAN) β usually one technology, one control plane | Domain-specific; often embedded within or below a domain orchestrator |
| Specialised Provisioning Engine | Niche technology (SatCom NMS, voice/SBC manager, microwave manager) β typically vendor-bound, often pre-NETCONF, with proprietary northbound APIs | Side-stack β integrates via custom adapter, rarely fits the standard pattern |
| Manual / scripted | Legacy gear with no modern API β provisioning happens via ticket, CLI, spreadsheet, or one-off scripts | Ticket-driven; runs alongside everything else and rarely goes away |
Specialised & Legacy Domains: Typical Orchestrator and Products
The IP/MPLS, mobile core, and fixed access sections covered the modern flagship domains. The table below covers the non-IP/MPLS, non-3GPP, non-PON technologies that real Tier-1 networks also run β and that transformation programmes routinely under-estimate. For each, the typical orchestrator class is named, the COTS products commonly seen are listed, and the question "can a modern orchestrator like Cisco NSO talk to it?" is answered honestly.
Likely orchestrator per specialised / legacy product class
| Product domain | Typical orchestrator class | Common COTS products | NSO-able (model-driven northbound)? |
|---|---|---|---|
| Microwave radio (cellular backhaul, enterprise links) | Vendor microwave EMS / NMS | Ericsson MINI-LINK Manager, Aviat ProVision, Ceragon NMS, Nokia Wavence (formerly 9500 MPR), SIAE-MICRO | Sometimes β newer kit ships NETCONF NEDs; older Cu/Eth-radio gear remains SNMP/CLI-only |
| Satellite (geostationary VSAT, LEO, mobility, backup) | SatCom NMS / Service Activation Platform | iDirect Pulse / Velocity, Comtech NMS, Hughes JUPITER, Gilat TotalNMS, Newtec Dialog, ST Engineering iDirect, Starlink Enterprise APIs | Rarely β proprietary northbound APIs; integrated via custom adapter or as an opaque service via partner API |
| SDH / SONET (legacy TDM transport) | Vendor EMS β pre-OpenROADM, pre-NETCONF | Ciena 6500 / OneControl, Nokia 1830 NMS, Huawei iManager U2000, ECI LightSoft | Mostly no β TL1 / CORBA / SOAP northbound; service-level abstractions weak or absent; usually wrapped via adapter or left manual |
| ATM / Frame Relay (residual legacy data) | Legacy EMS / scripted CLI | Cisco MGM, Lucent / Alcatel Navis, vendor CLI, in-house Perl/Python scripts | No β manual or scripted; typically read-only inventory at best |
| GPON / XGS-PON access (FTTH/FTTB OLT/ONT) | Access NMS / domain controller (newer) | Nokia Altiplano / AMS, Calix CMS / SMx, Huawei iManager NCE, Adtran Mosaic One, ZTE NetNumen | Possible β newer access controllers expose REST and TMF APIs; older OLT generations remain SNMP-driven |
| SIP / Voice / SBC (enterprise voice, SIP trunking) | SBC EMS / Voice OSS β separate stack | Oracle ACME (Session Element Manager), AudioCodes EMS / OVOC, Ribbon / Sonus EMS, Cisco CUCM, BroadSoft / BroadWorks | Specialised β separate orchestration domain; rarely integrated into a unified XDO; voice keeps its own provisioning chain |
| Submarine / DWDM long-haul (legacy generations) | Vendor EMS β pre-OpenConfig optical | Ciena OneControl, Infinera DNA / Transcend, Nokia 1830 NMS, Huawei iManager | Sometimes β newer ROADM platforms speak OpenROADM/NETCONF; older lines are EMS-only |
| WiFi enterprise / hotspot orchestration | Vendor controller / cloud-managed NMS | Cisco Meraki Dashboard, Aruba Central, Juniper Mist, Ruckus SmartZone | Cloud APIs available β typically integrated via REST adapter, not via NSO NEDs |
What This Means for the Catalog and Integration Layer
A multi-domain estate that includes any combination of these specialised domains forces specific design decisions on the catalog and the cross-domain orchestrator. Pretending otherwise produces catalogs that cannot represent real services, and orchestrators that cannot fulfil the orders the catalog accepts.
Anti-patterns Specific to Specialised Domains
Specialised-domain anti-patterns and their failure modes
| Anti-pattern | What it looks like | What breaks first |
|---|---|---|
| "NSO does everything" | Programme assumes the domain orchestrator will absorb microwave, satellite, voice, and legacy in a future phase | Phase 2 reveals SatCom and voice have no NETCONF/YANG path; adapter cost balloons; either schedule slips or those domains are quietly excluded from the orchestrator scope |
| Catalog enumerates the medium | Separate product offerings for "Internet over Fibre", "Internet over Microwave", "Internet over Satellite" | Customer chooses Fibre; site is unreachable by fibre; order fails commercially instead of being re-bound to a different bearer at the resource layer |
| Treating manual as "to be eliminated" | Roadmap shows manual domains being orchestrated by Q4; current architecture has no first-class ticket-and-wait state | Manual residue persists indefinitely; orchestrator marks orders complete that are still queued in someone's inbox; assurance has no way to detect |
| Voice swallowed by general orchestrator | Programme tries to orchestrate the voice/SBC stack from the same XDO that runs L3VPN β same models, same adapters | Voice service semantics (DID, dial plan, codec, regulatory routing) do not map to L3VPN-shaped models; voice team builds a parallel stack anyway |
| Treating an EMS as a domain controller | Northbound to Ciena CMS / Huawei iManager treated as if it were Cisco NSO | Service-level abstractions absent; orchestrator ends up sending CLI through the EMS; first feature change in the EMS breaks the integration; rollback impossible |
| Ignoring partner APIs | LEO satellite or third-party voice provider treated as a black box with no orchestration integration at all | Manual provisioning at scale; service activation lead times measured in days; assurance feedback non-existent; transformation has no way to demonstrate end-to-end automation |
Section 11.7 Key Takeaways
- "Orchestrator" is used loosely for at least six distinct system classes β EMS, NMS, domain orchestrator, SDN controller, specialised provisioning engine, and manual / scripted. Each has a different abstraction, a different API surface, and a different integration cost.
- The line between NMS and domain orchestrator is the architecturally important one: service-level state and service-level APIs, or device-centric underneath.
- Every Tier-1 estate runs specialised and legacy domains alongside the modern flagship domains. Microwave, satellite, SDH, ATM, voice/SBC, and older optical all live outside the clean NETCONF/YANG world.
- The "NSO-able" question has only three honest answers per domain: yes (modern domain controller), partial (custom adapter + accepted gaps), or no (manual or partner API). There is no fourth option.
- The catalog should declare orchestrator class as resource metadata, model manual fulfilment as a first-class lifecycle state, and abstract the transmission medium rather than enumerating it.
- Voice and satellite are usually not worth pulling into the unified XDO. Treat them as composable partner services consumed at the service-level API.
- The fastest way to derail a transformation is to assume the modern domain-controller pattern applies everywhere. The specialised-domain footprint is what determines whether a programme delivers automation or only looks like it does.