🔄

Section 8.6

Resource Order Management (ROM)

Last updated 14 Oct 2026

At a glance

Resource Order Management (ROM) takes a resource order from SOM, chooses and reserves the specific resources (ports, VLANs, IP addresses), configures the network through activation adapters, and records the result in resource inventory. It is where an abstract order becomes device configuration.

The picture

Service Order Management (SOM)Service Layer — TMF641

Service Order

TMF641

TMF652 POST

Resource Order Management (ROM)OSS — Resource Layer

Resource Order

TMF652 Reception

Resource Assignment

Query Available

TMF639 GET

Select Best Fit

Assignment rules

query

Resource Inventory

TMF639

Reserve Resource

Lock in inventory

reserve

Resource Catalog

TMF634

Activation via Adapters

NETCONF/YANG

Routers, switches

REST API

SDN, VNF, cloud

TR-069

CPE / ONT

CLI / SSH

Legacy elements

TMF652 events ↑ to SOMread-back & verification ↑ from network

config push

Network InfrastructurePhysical & Virtual Network Elements

OLT / Switch

BNG / Router

DHCP / IPAM

SDN Controller

CPE / ONT

ROM is typically provided by specialised network orchestration tools such as Itential or Cisco NSO — not by traditional O2A platforms like Hansen or Cerillion

ROM resource activation: from receiving the resource order through assignment, reservation and network activation

How it works

Where ROM sits

ROM is the lowest layer of the three-layer order model. It receives resource orders from SOM over TMF652, allocates physical and logical resources from Resource Inventory (TMF639), drives configuration to network elements through activation adapters, and confirms completion back to SOM. It works at the RFS and Resource layers, the bridge between the OSS fulfilment stack and the network.

What ROM does with one order

Receive

TMF652

Accept and validate the resource order from SOM.

Assign

TMF639

Select specific resources (ports, VLANs, IPs) from inventory by availability, proximity and capacity.

Reserve

Lock them so no other in-flight order can take the same resource.

Activate

Activation

Push configuration to network elements through adapters (NETCONF, CLI, REST, TR-069).

Verify

Confirm the change by read-back or a service test.

Update inventory

TMF639

Record the activated resource state in Resource Inventory.

Confirm

TMF652

Report completion to SOM, which closes the RFS order item.

Rollback

If activation fails or the order is cancelled, ROM releases the reserved resources and reverses any configuration already applied. Most network elements do not support transactions across devices, so rollback is a compensating sequence ROM has to design, not a single undo.

The activation adapter pattern

ROM does not talk to network elements directly. Activation adapters (southbound drivers) translate abstract resource order items into device-specific commands: NETCONF, RADIUS, Diameter, HTTP/2 SBI, TR-069, ETSI SOL005 and cloud REST SDKs. A new device type needs a new adapter, not a change to ROM.

Who owns what

Entity	System of Record	System of Engagement	System of Reference	Notes
Resource Order	ROM	—	SOM	TMF652. SOM tracks it against the RFS order item that created it.
Resource (port, VLAN, IP address)	Resource Inventory	—	—	TMF639. ROM assigns and reserves; inventory records.
Resource reservation	Resource Inventory	—	ROM	Held for the life of the order; released on cancel or rollback.
Device configuration	The network element	—	Resource Inventory / EMS	The network is the truth. Inventory is a model of it, and the two drift.
RFS	Service Inventory	—	ROM	ROM acts on the RFS that SOM sends; it does not own it.

In practice

ROM is specialised network orchestration

Most traditional O2A platforms (e.g. Hansen, Cerillion) do not provide ROM. Resource-level orchestration needs deep integration with element managers, device models (YANG, MIBs) and southbound protocols, which sit outside a typical BSS/OSS order stack. In practice ROM is delivered by specialised network orchestration tools such as Cisco NSO, Itential or Nokia NSP. When evaluating an O2A vendor, assume ROM is sourced separately and integrated over TMF652.

Many brownfield estates have no separate ROM at all. SOM workflows or scripts call element managers directly, and resource assignment is done by the workflow or by hand in inventory. It works for one domain and stops scaling at the second.

Where a domain has its own controller or platform API that assigns and configures for itself (the mobile core, many SD-WAN controllers), SOM often calls that controller directly and ROM is not involved for that domain. 8.7 covers that routing.

The trade-off

What it solves

It isolates the network. SOM and everything above it ask for resources in abstract terms; only ROM and its adapters know device models and protocols. A new device type means a new adapter, not a change to orders.

What it does not solve

Inventory accuracy. ROM trusts resource inventory and will assign resources the network is already using.
Service design. Which RFS a CFS needs is decided in SOM and the catalog, not in ROM.
Assurance once the resource is live.

What it adds

Another order layer with its own state machine, timeouts and fallout queue.
Rollback across devices that do not support transactions.
Usually a separate product to buy and integrate over TMF652.

Architecture decision

Does this estate need a separate ROM, or can SOM call the network directly?

Separate ROM / network orchestrator
Choose when several network domains or vendors, device-level configuration (transport, IP core), and resources that must be reserved and rolled back.
SOM calls domain controllers directly
Choose when each domain already has a controller or platform API that does its own assignment and configuration.

Breaks if SOM is allowed to hold device-level logic for one domain "just this once". The next domain copies the pattern, and SOM becomes a ROM nobody designed.

Takeaways

Key Takeaways

ROM is the lowest layer of order management: resource allocation and network activation
Assignment picks specific resources from inventory; reservation prevents conflicts between in-flight orders
Activation adapters translate abstract orders into device commands, so new devices do not change ROM
TMF652 is the SOM → ROM interface; TMF639 is the resource-level system of record

Check yourself

SOM sends ROM an order for an access RFS. What does ROM do before it confirms back?Show answerHide
Assigns specific resources from inventory, reserves them, configures the network through an adapter, verifies the change and updates resource inventory. Only then does it confirm to SOM over TMF652.
Inventory shows port 1/1/7 as free, but activation fails because the port is in use. Which system is wrong, and which is the truth?Show answerHide
Resource inventory is wrong; the network is the truth. ROM can only assign what inventory says is free, so inaccurate inventory shows up as activation fallout, not as a ROM defect.
A vendor’s O2A suite has COM and SOM but no ROM. What do you plan for?Show answerHide
Either source resource-level orchestration separately and integrate it with SOM over TMF652, or confirm that each domain’s controller can be called directly by SOM.