Orchestration Domains
Last updated 14 Oct 2026
At a glance
SOM does not touch the network itself. It hands each RFS to an execution engine, and domains are reached in two ways: direct platform APIs for centralised platforms (mobile core, RAN, service platforms) and ROM or a network orchestrator for domains that need device configuration (transport, IP core). The catalog, not SOM code, says which engine handles which RFS.
The picture
SOM integration: direct API to platforms, NETCONF to ROM/Cisco NSO for device configuration
How it works
Two integration patterns
| Direct platform API | ROM / network orchestrator | |
|---|---|---|
| Domains | Mobile core (UDM/HSS, PCF/PCRF, SIM platform), RAN (RAN OSS/EMS, NSMF), service platforms (IPTV, SIP/IMS, CDN) | Transport (MPLS, Segment Routing, DWDM), IP core (routers, switches, BNG/BRAS) |
| What the engine is | A centralised platform with its own well-defined API | Many devices from many vendors that need configuration pushed |
| Why this pattern | No device-level configuration, so a network orchestrator adds nothing | Multi-vendor abstraction (YANG models, device drivers) and transactional commit with rollback |
How SOM decides where to route
Each RFS specification in the catalog (TMF633/634) carries metadata naming the engine that realises it, for example a characteristic such as executionEngine, and whether it goes direct or via ROM. SOM reads it at orchestration time. A new technology domain is new catalog entries and an adapter, not new SOM code.
Receive
TMF641A service order with CFS items arrives, e.g. CFS:Broadband-100M, CFS:5G-Data-Plan.
Decompose
SOMEach CFS becomes its RFS items from the service catalog; one CFS may produce several.
Look up the engine
CatalogFor each RFS, read the engine assignment from the catalog.
Route
SOMPlatform domains: call the platform API, directly or through a thin adapter. Device domains: send a resource order to ROM.
Dispatch and track
SOM → enginesIndependent items go in parallel; dependent items wait. SOM tracks each engine and aggregates the result.
If SOM code contains if rfsType == "VNF" then callMANO(), the catalog is incomplete. The engine assignment belongs in the RFS specification.
The domains
| Domain | Route | Typical engines and interfaces | When SOM touches it |
|---|---|---|---|
| Mobile core | Direct | UDM/HSS and PCF/PCRF through their provisioning APIs (S6a, Gx, Nudm and N7 are network-internal), SIM platform / SM-DP+ | Every mobile subscription, plan change or data feature; the highest-volume integration in a mobile operator |
| RAN / 5G | Direct | RAN OSS/EMS, NSMF (3GPP NRM), O-RAN SMO (O1, NETCONF/YANG) | Slicing, private 5G, new sites. Ordinary consumer activations do not change the RAN |
| Service platforms | Direct | IPTV head-end, SIP/IMS core (Diameter Cx/Sh, XCAP), CDN (REST) | TV, voice and content entitlements; often left as manual handoffs when SOM is designed |
| Satellite (SNO) | Via automation middleware | Middleware such as Itential mapping the RFS to each satellite operator’s REST workflow | Enterprise WAN resilience, maritime, rural. SNO APIs are proprietary and change often; the middleware absorbs that |
| Transport | ROM / orchestrator | SDN controller (PCEP, NETCONF), optical management (T-API), orchestrator such as Cisco NSO (NETCONF/CLI via device drivers) | Paths and VPNs; a prerequisite for many higher-layer services |
| IP core | ROM / orchestrator | BNG/BRAS (RADIUS CoA, NETCONF), AAA/RADIUS, orchestrator or EMS for router configuration | Every fixed broadband subscriber needs a BNG session profile |
| Cloud / NFV | Direct | MANO / NFVO (ETSI SOL005), Kubernetes | VNF and CNF instances |
Cross-domain dependencies
Within mobile core, UDM and PCF are independent and run in parallel; SIM activation waits for UDM. Across domains, an L3VPN cannot activate until the transport path exists, and an IPTV multicast join needs an active BNG session. SOM enforces these orderings because no single engine can see them.
When one engine fails
| Scenario | SOM response |
|---|---|
| Engine timeout | Retry with backoff, then fail the RFS item after the limit |
| Partial failure across engines | Hold or compensate the completed parts, e.g. keep the BNG session and retry the IPTV entitlement |
| Prerequisite fails | Block every item that depends on it |
| Engine unavailable | Queue its items; carry on with independent items on other engines |
Engines roll back their own work (an orchestrator’s atomic commit, for example). SOM owns the cross-engine saga: deciding whether to tear down what succeeded or hold it while the failed part is retried.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| RFS specification and its engine assignment | Service / Resource Catalog | — | SOM | TMF633/634. Routing metadata lives here, not in SOM code. |
| Cross-engine orchestration state | SOM | — | — | Which engines have succeeded, failed or are waiting, and the compensation decision. |
| Resource order (device domains) | ROM | — | SOM | TMF652. ROM and its orchestrator own device-level transactions. |
| Subscriber and policy data in platforms | The platform (UDM/HSS, PCF, IMS, head-end) | — | Service Inventory | The platform holds the live configuration; inventory records what SOM asked for. |
In practice
Most estates mix both patterns. Mobile operators often integrate SOM directly with the mobile core and never involve ROM for subscriber activation. Fixed and enterprise operators put a network orchestrator in front of transport and IP devices because multi-vendor configuration and rollback are the hard part.
Service platforms are often overlooked in SOM design. TV, voice and content entitlements are left as manual steps, which then show up as fallout and as customers with connectivity but no TV.
The trade-off
What it solves
It lets SOM orchestrate every technology domain through one model: catalog-declared routing, parallel and dependent dispatch, and one owner for compensation across engines.
What it does not solve
- Engine quality. A platform API that times out or an inventory that is wrong still fails the order.
- Missing RFS models for services already in the network.
- Vendor API churn, which still has to be absorbed by an adapter or middleware.
What it adds
- Routing metadata in the catalog that must be governed like code.
- A cross-engine saga that has to be designed per service, not per engine.
- More adapters and middleware layers to own and upgrade.
Architecture decision
For a new domain, does SOM call it directly or go through ROM?
Direct platform API
Choose when the domain is a centralised platform with a stable API that assigns and configures for itself.
ROM / network orchestrator
Choose when configuration is pushed to many devices, often multi-vendor, and needs transactional commit and rollback.
Automation middleware
Choose when the target is an external partner API that is proprietary, multi-step and changes often.
Breaks if The choice is coded into SOM instead of declared in the catalog. Each new domain then needs a SOM release, and routing rules drift between workflows.
Takeaways
Key Takeaways
- SOM reaches domains in two ways: direct platform APIs and ROM or a network orchestrator
- Platforms (mobile core, RAN, service platforms) go direct; device configuration (transport, IP core) goes via ROM
- The engine for each RFS is declared in the catalog, so a new domain is a catalog change, not SOM code
- Most consumer mobile activations touch the mobile core only, not the RAN
- SOM owns compensation across engines because no engine sees the whole service
Check yourself
Why would a network orchestrator such as NSO add little value for a 5G subscriber activation?Show answerHide
The work is in centralised platforms (UDM, PCF, SIM platform) with their own APIs. There is no multi-vendor device configuration to abstract or roll back, so SOM can call the platforms directly.
A BNG session is active but the IPTV entitlement failed. Who decides whether to tear down the BNG session?Show answerHide
SOM. Each engine only knows its own part; SOM sees the whole service and decides whether to compensate or hold connectivity and retry the entitlement.
An operator adds satellite backup to its enterprise WAN product. What changes in SOM?Show answerHide
Ideally nothing in code. A new RFS specification declares its engine (for example middleware fronting the satellite operator’s API), and SOM routes to it from the catalog.