🔄

Section 3.5

Orchestration Domains

How SOM integrates with technology domains — direct API to platforms (Mobile Core, RAN, Service Platforms) and ROM/NSO for device configuration (Transport, IP Core). Catalog-driven routing with per-domain engine mapping.

As you may have learned by now, SOM does not execute on the network directly — it delegates to execution engines or platforms, but not all domains are integrated the same way.

There are two distinct patterns:

Direct Platform API Integration

SOM calls platform APIs directly for centralised platforms with well-defined interfaces.

Mobile Core — UDM, PCF, SIM Platform
RAN — RAN OSS/EMS, NSMF
Service Platforms — IPTV, SIP/IMS, CDN
No device-level configuration — a network orchestrator like NSO adds no value here

ROM / Network Orchestrator

SOM delegates to ROM (and tools like Cisco NSO) for domains that push configuration to network devices.

Transport — MPLS, Segment Routing, DWDM
IP Core — routers, switches, BNG/BRAS
Multi-vendor abstraction via YANG models and NEDs
Transactional commits with automatic rollback on failure

The routing decision is catalog-driven — the RFS specification in the service catalog declares which execution engine handles it and whether it routes via ROM or direct API. SOM reads this metadata at orchestration time. There is no hardcoded if/else logic. Adding a new technology domain requires only new catalog entries — not new SOM code.

How SOM Decides Where to Route

Catalog-Driven Engine Routing

SOM reads the RFS specification's executionEngine characteristic to determine the target system for each resource order item. This metadata lives in the service/resource catalog (TMF633/634) and is resolved at orchestration time. The catalog — not SOM application logic — is the single source of truth for which engine provisions which RFS type.

Generic SOM Routing Sequence

SOM Receives CFS Order Item

SOM

SOM receives a service order (TMF641) containing one or more CFS items — e.g., CFS:Broadband-100M, CFS:5G-Data-Plan, CFS:SD-WAN-Service.

Decompose CFS → RFS Items

SOM

SOM reads the service catalog to decompose each CFS into its constituent RFS items. A single CFS may produce 3–8 RFS items depending on complexity.

Read Engine Assignment per RFS

SOM

For each RFS item, SOM reads the executionEngine characteristic from the resource catalog. This tells SOM which system handles this RFS type.

Route: Direct API or ROM

SOM

Platform domains (Mobile Core, RAN, Service Platforms): SOM calls the platform API directly or via a thin activation adapter. Device config domains (Transport, IP Core): SOM submits a NETCONF request to ROM/NSO for device-level configuration.

Dispatch to Engines

SOM → Engines

SOM dispatches RFS items to their respective engines. Independent items are dispatched in parallel; dependent items respect ordering. SOM tracks status and aggregates results.

SOM integration: direct API to platforms, NETCONF to ROM/Cisco NSO for device configuration

Figure 3.5 — SOM integration: direct API calls to platforms (left), ROM/NSO for device configuration (right)

Never Hardcode Routing Logic

If SOM contains if/else logic choosing engines based on RFS type (e.g., if rfsType == "VNF" then callMANO()), the catalog is incomplete. All engine assignments should be declared in the service/resource catalog as RFS specification metadata.

Technology Domain Activation

Each technology domain has its own execution engines, protocols, and activation patterns. Explore each domain below to understand how SOM integrates — direct API for platform domains, ROM/NSO for device configuration, and Itential for satellite SNO integration.

RAN / 5G

Radio & Network Slicing

Direct APICentralised Platform

RAN activation covers cell site configuration, carrier management, antenna parameters, and 5G network slicing. SOM delegates to a RAN OSS or vendor EMS — it does not configure individual radio parameters directly. Most retail subscriber activations do NOT require RAN changes.

Execution Engines

RAN OSS / EMS

Cell parameter config, carrier activation, neighbour relations

viaVendor API / NETCONF

NSMF

RAN slice subnet instance creation and association

via3GPP NRM

O-RAN SMO

Per-site radio unit config, power and tilt settings

viaO-RAN O1 (NETCONF/YANG)

Activation Example

5G Network Slice — Enterprise Private 5G

1SOM receives CFS:Enterprise-Private-5G with slice requirements (URLLC, 10ms latency)

2SOM calls NSMF API to create RAN slice subnet instance with dedicated PRBs

3NSMF configures gNodeBs at customer site with dedicated frequency/timeslot allocation

4SOM updates service inventory with slice ID and confirms activation to COM

Key Insight

SOM only touches the RAN for network slicing, enterprise private 5G, or new site rollouts. Standard consumer mobile activations route to Mobile Core only — the RAN serves any authenticated subscriber automatically.

1 / 6

RFS-to-Engine Routing Matrix

The following matrix consolidates RFS-to-engine assignments across all five technology domains. In a production system, this mapping lives in the service/resource catalog — the table represents the logical content of that catalog.

Comprehensive RFS-to-Engine Routing Matrix

RFS Type	Domain	Execution Engine	Interface
RFS:RAN-Cell-Config	RAN	RAN OSS / EMS	O-RAN O1 / proprietary
RFS:Network-Slice (RAN)	RAN	NSMF	3GPP NRM
RFS:UDM-Subscriber	Mobile Core	UDM / HSS	Diameter S6a / HTTP/2 Nudm
RFS:QoS-Policy	Mobile Core	PCF / PCRF	Diameter Gx / HTTP/2 Npcf
RFS:SIM-Activation	Mobile Core	SIM Platform	Proprietary (SM-DP+)
RFS:Transport-Path	Transport	SDN Controller	PCEP / NETCONF
RFS:PE-VRF-Config	Transport	NSO	NETCONF/CLI NEDs
RFS:Optical-Path	Transport	Optical Mgmt	T-API / NETCONF
RFS:OLT-Port-Config	IP Core	EMS	SNMP / TL1 / NETCONF
RFS:BNG-Session	IP Core	BNG / BRAS	RADIUS CoA / NETCONF
RFS:RADIUS-Profile	IP Core	AAA Server	RADIUS / REST
RFS:IPTV-Channel	Service Platform	IPTV Head-End	REST / SOAP
RFS:SIP-Subscriber	Service Platform	IMS Core	Diameter Cx / XCAP
RFS:CDN-Config	Service Platform	CDN Platform	REST API
RFS:VNF-Instance	Cloud / NFV	MANO (NFVO)	ETSI SOL005
RFS:CNF-Instance	Cloud / NFV	K8s / MANO	Helm / SOL005
RFS:Satellite-Link	Satellite / SNO	Itential → SNO API	REST API (SOM → Itential)

Multi-Engine Failure Handling

When SOM dispatches to multiple execution engines, partial failures are the norm, not the exception. One engine may succeed while another times out. SOM must handle these scenarios gracefully.

Failure Scenarios and SOM Responses

Scenario	SOM Response	Example
Engine timeout	Retry with backoff, then fail RFS item after max retries	UDM API timeout — SOM retries 3x with 30s/60s/120s delays
Partial multi-engine failure	Compensate completed engines if service cannot function partially	BNG succeeds but IPTV Head-End fails — SOM holds BNG session, retries IPTV
Dependency failure	Cascade: if prerequisite fails, block all dependent items	BNG session fails → SOM does not attempt IPTV multicast join
Engine unavailable	Queue for retry; do not block independent items on other engines	SIM Platform down — SOM queues SIM activation but proceeds with UDM + PCF

SOM Owns Cross-Engine Compensation

Individual engines handle their own internal rollback (e.g., NSO atomic transactions). But SOM owns the cross-engine saga: if the BNG session is active but the IPTV entitlement fails, SOM must decide whether to compensate (tear down BNG session) or hold (keep connectivity, retry IPTV). This cross-engine compensation logic is SOM's unique responsibility — no single engine has visibility across the full service.

Section 3.5 Key Takeaways

Two distinct integration patterns: SOM calls platform APIs directly (Mobile Core, RAN, Service Platforms) and delegates to ROM/NSO for device configuration (Transport, IP Core)
Mobile Core (UDM, PCF, SIM), RAN OSS, and Service Platforms are centralised platforms with well-defined APIs — NSO adds no value here
ROM and network orchestrators like NSO are for pushing configuration to network devices (routers, switches, optical) where multi-vendor abstraction and transactional rollback matter
Most retail mobile activations touch Mobile Core only — SOM touches the RAN for slicing, private 5G, or new site rollouts
Service Platforms (TV, SIP, CDN) must be treated as first-class execution engines, not manual handoffs
A converged service bundle can span all five domains in a single order — SOM orchestrates parallel and sequential dispatch across ~10 RFS items
SOM owns cross-engine saga compensation — no single engine sees the full service picture