9.420 min read

SOM Execution Engine Routing

SOM Execution Engine Routing: Fixed, Mobile, SD-WAN & Cloud

SOM does not execute on the network directly — it delegates to execution engines. Section 9.3 introduced the concept of RFS-to-engine routing with a 10-row mapping table. This section expands that concept to cover every major technology domain: fixed access/broadband, mobile/RAN, SD-WAN, cloud/NFV, and enterprise network (L3VPN/MPLS). For each domain, we examine which engines SOM routes to, what protocols are used, and how a typical activation flow works end to end.

The routing decision is catalog-driven — the RFS specification in the service catalog declares which execution engine handles it. SOM reads this metadata at orchestration time. There is no hardcoded if/else logic in SOM that says "if the RFS is a VNF, call MANO". Instead, the catalog entry for RFS:VNF-Instance includes an executionEngine characteristic set to MANO/NFVO, and SOM resolves it dynamically. This approach means adding a new technology domain (e.g., satellite, private 5G) 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 resource/service 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. Each CFS references a product specification in the service catalog.

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. For example, CFS:SD-WAN-Service decomposes into RFS:Overlay-Config, RFS:uCPE-VNF-Deploy, RFS:Underlay-WAN, and RFS:CPE-Ship.

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 — e.g., "SD-WAN Controller" for RFS:Overlay-Config, "MANO" for RFS:uCPE-VNF-Deploy, "NSO" for RFS:Underlay-WAN.

Build Engine-Specific Payloads

SOM / ROM

SOM (or ROM) constructs the appropriate payload for each execution engine. This may involve mapping RFS characteristics to engine-specific data models — e.g., mapping RFS:PE-VRF-Config characteristics to NSO's L3VPN YANG service model, or mapping RFS:VNF-Instance to ETSI SOL005 VNF instantiation payload.

Dispatch to Engines (Parallel Where Possible)

SOM → Engines

SOM dispatches RFS items to their respective engines via ROM or direct API calls. Independent RFS items are dispatched in parallel; dependent items respect ordering (e.g., underlay must complete before overlay). SOM tracks the status of each dispatched item and aggregates results.

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. Hardcoded routing creates maintenance debt, prevents runtime reconfiguration, and breaks the catalog-driven architecture principle.

Technology Domains: Engines and Activation Patterns

Each technology domain has its own set of execution engines, protocols, and activation patterns. The following tabs cover the five major domains that SOM routes to in a modern telco.

Fixed access covers GPON/XGS-PON OLT provisioning, DSLAM port activation, and CPE configuration for FTTH, FTTC, and DSL services. These services typically involve a mix of automated network provisioning and physical field work (CPE installation, fibre splice).

EMS (per OLT vendor) — Nokia, Huawei, Calix, and ZTE each have vendor-specific Element Management Systems that handle OLT port configuration, ONT registration, VLAN assignment, and bandwidth profiles via SNMP, TL1, or NETCONF
SDN Controller — for disaggregated access networks (e.g., Open Networking), an SDN controller replaces vendor EMS and manages whitebox OLTs via OpenFlow or NETCONF
BNG/BRAS API — Broadband Network Gateway session profile configuration, including RADIUS-based subscriber policy, QoS profiles, and DHCP relay — accessed via NETCONF or RADIUS CoA
Workforce Management (TMF646) — physical CPE installation, fibre splicing, and ONT mounting require a field technician dispatched via a workforce management system

FTTH 100 Mbps Activation Flow

SOM decomposes CFS:Broadband-100M into four RFS items: RFS:OLT-Port-Config (→ EMS: configure PON port, assign bandwidth profile) | RFS:ONT-Provisioning (→ EMS: register ONT serial, assign VLAN, set service profile via OMCI) | RFS:CPE-Install (→ Workforce: dispatch field tech, mount ONT, test signal) | RFS:BNG-Session-Profile (→ SDN Controller/BNG API: create subscriber session, apply QoS policy, set DHCP relay). The CPE-Install is a prerequisite for ONT-Provisioning — SOM enforces this dependency.

RFS-to-Engine Routing Matrix

The following matrix consolidates RFS-to-engine assignments across all five technology domains. This is the comprehensive routing table that SOM (or ROM) uses to dispatch resource order items. In a production system, this mapping lives in the service/resource catalog — the table below represents the logical content of that catalog.

Comprehensive RFS-to-Engine Routing Matrix

RFS Type	Domain	Execution Engine	Interface / Protocol	Notes
RFS:OLT-Port-Config	Fixed	EMS (vendor-specific)	SNMP / TL1 / NETCONF	Per-OLT vendor (Nokia, Huawei, Calix) — configures PON port and bandwidth profile
RFS:ONT-Provisioning	Fixed	EMS	OMCI via OLT	Remote ONT registration, VLAN assignment, and service profile configuration
RFS:BNG-Session-Profile	Fixed	SDN Controller / BNG API	RADIUS / NETCONF	Subscriber session policy, QoS profile, and DHCP relay configuration
RFS:CPE-Install	Fixed	Workforce Mgmt	TMF646	Physical CPE/ONT installation requires field technician dispatch
RFS:UDM-Subscriber-Profile	Mobile	UDM / HSS	Diameter / HTTP2 (5GC)	Subscriber data: APN/DNN config, authentication vectors, subscription profile
RFS:QoS-Policy	Mobile	PCF / PCRF	Diameter Rx/Gx or HTTP2	Per-subscriber QoS rules, data rate limits, priority levels, charging keys
RFS:SIM-Activation	Mobile	SIM Platform	Proprietary API	eSIM profile download via SM-DP+ or physical SIM activation (ICCID/IMSI)
RFS:Network-Slice	Mobile	NSMF / MANO	3GPP APIs	Network slice subnet instance lifecycle — NF instantiation, resource allocation
RFS:RAN-Config	Mobile	RAN OSS / EMS	Vendor-specific	Cell parameter tuning, carrier addition — Ericsson ENM, Nokia NetAct, Huawei iManager
RFS:Overlay-Config	SD-WAN	SD-WAN Controller	REST API	Overlay tunnel creation, application-aware routing policy, traffic steering rules
RFS:uCPE-VNF-Deploy	SD-WAN	MANO	ETSI SOL005	VNF/CNF deployment on uCPE — vFirewall, vRouter, WAN-optimiser
RFS:Underlay-WAN	SD-WAN	NSO	NETCONF/CLI	PE router VRF, BGP peering, and interface config for MPLS underlay
RFS:VNF-Instance	Cloud	MANO (NFVO)	ETSI SOL005	Full VNF lifecycle: instantiate, configure, scale, heal, terminate
RFS:CNF-Instance	Cloud	MANO or K8s API	SOL005 / Helm	CNF on K8s — via MANO-managed Helm charts or direct Kubernetes API
RFS:Cloud-Infra	Cloud	Cloud API	AWS/Azure/GCP SDK	IaaS provisioning: VPC, subnet, security groups, load balancers
RFS:PE-VRF-Config	Enterprise	NSO	NETCONF/CLI via NEDs	Multi-vendor PE VRF creation, BGP VPNv4, route targets, sub-interfaces
RFS:CE-Interface-Config	Enterprise	NSO	NETCONF/CLI via NEDs	CE router interface, VLAN tagging, and routing configuration
RFS:Transport-Path	Enterprise	SDN Controller	PCEP / NETCONF	MPLS/SR-TE transport path computation and provisioning
RFS:Firewall-Policy	Enterprise / Cloud	NSO or Firewall Mgmt	NETCONF / API	Physical or virtual firewall rule configuration — ACLs, NAT, zones
RFS:DNS-Record	Cross-domain	Cloud / Infra API	REST API	DNS provisioning (A/AAAA/CNAME/SRV) for any service type

Worked Example: SD-WAN + Cloud Firewall (Multi-Domain)

A single commercial order can trigger multiple execution engines simultaneously. This worked example shows how an SD-WAN + Cloud Security bundle flows through SOM, dispatching to three engines in parallel where dependencies allow.

Multi-Domain: SD-WAN + Cloud Firewall Activation

COM Receives SD-WAN + Security Bundle Order

COM

A customer orders "Managed SD-WAN with Cloud Firewall" — a commercial bundle containing two product components: SD-WAN connectivity (3 sites) and cloud-based firewall protection. COM creates a Product Order with two product order items.

COM Decomposes to CFS and Submits to SOM

COM → SOM

COM maps the product bundle to two CFS items: CFS:SD-WAN-Service and CFS:Cloud-Firewall. A service order (TMF641) is submitted to SOM containing both CFS items.

SOM Decomposes CFS Items → RFS Items

SOM

SOM reads the service catalog and decomposes: CFS:SD-WAN-Service → RFS:Overlay-Config, RFS:uCPE-VNF-Deploy, RFS:Underlay-WAN. CFS:Cloud-Firewall → RFS:CNF-Instance, RFS:Firewall-Policy. Total: 5 RFS items across 3 execution engines.

SOM Reads Engine Assignments and Plans Dispatch

SOM

SOM reads the catalog: RFS:Overlay-Config → SD-WAN Controller, RFS:uCPE-VNF-Deploy → MANO, RFS:Underlay-WAN → NSO, RFS:CNF-Instance → MANO, RFS:Firewall-Policy → NSO. SOM identifies dependencies: Underlay-WAN must complete before Overlay-Config; CNF-Instance must complete before Firewall-Policy.

Parallel Dispatch: MANO + NSO (Phase 1)

SOM → NSO, MANO

SOM dispatches independent items in parallel: RFS:Underlay-WAN → NSO (configure PE routers for MPLS underlay), RFS:uCPE-VNF-Deploy → MANO (deploy vRouter + vFirewall VNFs on uCPEs), RFS:CNF-Instance → MANO (deploy cloud firewall CNF on K8s cluster). Three engine calls execute simultaneously.

Dependent Dispatch: SD-WAN Controller + NSO (Phase 2)

SOM → SD-WAN Controller, NSO

Once NSO confirms underlay is active: RFS:Overlay-Config → SD-WAN Controller (create overlay network, configure app-aware routing). Once MANO confirms CNF is running: RFS:Firewall-Policy → NSO (configure firewall rules, zones, NAT policies on the CNF).

SOM Aggregates Results

SOM

All 5 RFS items report completion. SOM marks the service order as completed, updates Service Inventory (TMF638) with both CFS instances: CFS:SD-WAN-Service (status: active, 3 sites) and CFS:Cloud-Firewall (status: active, linked to SD-WAN service).

SOM Notifies COM

SOM → COM

SOM publishes ServiceOrderStateChangeEvent (state: completed) to COM. COM marks the product order as fulfilled, triggers billing activation for both the SD-WAN and cloud firewall components, and sends a customer notification confirming the service is live.

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. One dependency may fail, blocking downstream items. SOM must handle these scenarios gracefully — retrying where appropriate, compensating where necessary, and always maintaining a consistent view of service state.

Multi-Engine Failure Scenarios and SOM Responses

Failure Scenario	SOM Response	Example
Engine timeout	Retry with exponential backoff, then mark RFS item as failed after max retries	NSO commit queue timeout — SOM retries 3 times with 30s/60s/120s delays before escalating
Partial multi-engine failure	Compensate completed engines if the service cannot function partially; report partial failure to COM	MANO succeeds (VNF running) but NSO fails (underlay not configured) — SOM decides: compensate (terminate VNF) or hold for NSO retry
Engine unavailable	Queue RFS item for retry; do not block independent RFS items dispatched to other engines	EMS offline during maintenance window — SOM queues OLT-Port-Config but proceeds with BNG-Session-Profile via SDN controller
Dependency failure	Cascade: if prerequisite RFS-A fails, do not attempt dependent RFS-B; mark RFS-B as blocked	SD-WAN underlay (NSO) fails → SOM does not attempt overlay (SD-WAN Controller) because overlay depends on active underlay
Idempotency violation	Detect duplicate resource (already exists), skip re-execution, reconcile state	Re-dispatched VNF create to MANO — MANO returns "already exists" — SOM treats as success and reconciles inventory
State inconsistency	Reconciliation job compares SOM service inventory state with engine state; flag discrepancies for manual or automated resolution	Service inventory says CFS:L3VPN is "active" but NSO config-audit shows VRF config missing on PE-03 — reconciliation job triggers re-provisioning

SOM Must Own Cross-Engine Compensation

Individual engines handle their own internal rollback: NSO provides atomic transactions (all-or-nothing across devices), MANO can terminate a failed VNF instance. But SOM owns the cross-engine saga: if MANO succeeds in deploying a VNF but NSO fails to configure the underlay, SOM must decide whether to compensate (ask MANO to terminate the VNF) or retry (re-attempt NSO). This cross-engine compensation logic is SOM's unique responsibility — no single engine has visibility across the full service.

Section 9.4 Key Takeaways

SOM routing is catalog-driven — the RFS specification declares the execution engine, and SOM reads it at runtime. No hardcoded if/else routing logic.
Five major technology domains each have distinct execution engines: Fixed (EMS/SDN), Mobile (UDM/PCF/NSMF), SD-WAN (Controller/MANO/NSO), Cloud (MANO/K8s), Enterprise (NSO/SDN)
A single commercial service can span multiple domains and execution engines simultaneously — SD-WAN + Cloud Firewall touches 3 engines in one order
SOM orchestrates across engines but never duplicates engine-specific logic — it delegates execution and aggregates results
Multi-engine orders require saga-based compensation — SOM owns the cross-engine transaction and decides retry vs compensate on partial failure
Failure handling distinguishes between engine timeout, partial failure, dependency failure, idempotency violations, and state inconsistency — each requires a different response
ROM can act as a mediation layer between SOM and heterogeneous engines, providing a uniform TMF652 interface and insulating SOM from engine-specific APIs
The routing matrix is a living artifact — new technology domains (e.g., satellite, private 5G, IoT) add rows to the catalog, not new routing logic in SOM