3.412 min read

Resource Order Management (ROM)

What Is Resource Order Management?

Resource Order Management (ROM) is the lowest layer of the three-layer order management model. It is where abstract service-level requests meet the physical and logical reality of the network. ROM is responsible for allocating, configuring, and activating the actual network resources — ports, VLANs, IP addresses, bandwidth policies, devices — that make services work.

While COM deals with commercial products and SOM orchestrates customer-facing services, ROM operates at the Resource-Facing Service (RFS) and Resource layers. It is the bridge between the OSS fulfillment stack and the network infrastructure. In TM Forum's ODA, ROM maps to the Resource Order Management functional block within the Resource Management domain.

The OSS capability responsible for receiving resource orders from SOM, allocating physical and logical resources from inventory, driving configuration to network elements via activation interfaces, and confirming resource provisioning completion. ROM is the system of record for Resource Order entities and works closely with Resource Inventory (TMF639) and the network activation layer.

ROM in the Architecture

ROM resource activation flow: from resource order to network configuration

Figure 3.4 — ROM resource activation flow: from resource order reception through assignment, reservation, and network activation

The diagram above illustrates ROM's internal processing pipeline. Resource orders arrive from SOM via TMF652, resources are queried and assigned from Resource Inventory (TMF639), reserved to prevent concurrent allocation, then activated via technology-specific adapters (NETCONF, REST, TR-069, CLI) that push configuration to network elements. Completion events flow back to SOM via TMF652 events.

ROM Role and Responsibilities

ROM Core Responsibilities

Responsibility	Description	Why It Matters
Resource Order Reception	Receive resource orders from SOM via TMF652 and validate against resource catalog	Ensures well-formed resource requests enter the activation pipeline
Resource Assignment	Select and assign specific resources from Resource Inventory (e.g., pick a free OLT port)	Determines the actual physical/logical resources that will be used
Resource Reservation	Reserve assigned resources to prevent concurrent allocation to other orders	Prevents resource conflicts when multiple orders are in flight
Network Activation	Drive configuration commands to network elements (OLTs, routers, switches, management platforms)	The actual "make it work" step — where configuration reaches the network
Activation Verification	Confirm that network configuration was applied correctly (read-back, service test)	Ensures the intended configuration is actually active on the network
Resource Inventory Update	Update Resource Inventory (TMF639) with the allocated and activated resource state	Maintains the resource-level system of record
Rollback / De-allocation	Release resources and reverse configuration if activation fails or the order is cancelled	Prevents resource leaks and orphaned configurations

From Service Orders to Resource Orders

SOM generates resource order items by decomposing CFS-level items into RFS-level items using the service catalog. These RFS items are then bundled into a Resource Order and submitted to ROM via TMF652.

SOM → ROM Handoff Process

SOM Decomposes CFS → RFS

SOM

SOM reads the service catalog to determine which RFS specifications are required for each CFS. For example, CFS:Internet-Access with technology=GPON decomposes into RFS:GPON-Bearer, RFS:VLAN-Service, RFS:IP-Profile, and RFS:QoS-Profile.

SOM Builds Resource Order

SOM

SOM constructs a TMF652-compliant Resource Order containing one Resource Order Item per RFS. Each item includes the RFS specification reference, action (add/modify/delete), characteristic values, and the service location.

SOM Submits to ROM

SOM → ROM

SOM sends POST /resourceOrder to ROM via TMF652. ROM validates the request against the resource catalog, assigns an order ID, and acknowledges receipt.

ROM Processes Resource Items

ROM

ROM independently processes each resource order item: assigning resources, driving activation, and verifying completion. ROM reports status back to SOM via TMF652 events.

One Service Order, Multiple Resource Orders

SOM may submit multiple Resource Orders to ROM for a single Service Order — for example, one Resource Order for network configuration (handled by a network activation adapter) and a separate Resource Order for CPE configuration (handled by a device management system). The grouping of resource items into resource orders often depends on the target activation system.

RFS and Resource-Level Order Items

Resource order items operate at two sub-levels: Resource-Facing Service (RFS) items that describe technology-specific service components, and Resource Specification (RS) items that describe the actual physical or logical resources to be allocated.

RFS-level order items describe technology-specific service components that are invisible to the customer but essential for service delivery:

RFS Example	What It Does	Typical Characteristics
RFS:GPON-Bearer	Establishes the physical optical connection between OLT and ONT	oltSlot, oltPort, ontSerialNumber, bearerSpeed
RFS:VLAN-Service	Assigns and configures a customer VLAN on the access network	vlanId, vlanType (c-tag/s-tag), outerVlan, serviceType
RFS:IP-Profile	Configures IP addressing (DHCP, static, dual-stack)	ipv4Address, ipv6Prefix, dnsServers, dhcpPool
RFS:QoS-Profile	Applies bandwidth shaping and quality-of-service policies	downloadBandwidth, uploadBandwidth, policyName, trafficClass
RFS:TR069-Config	Configures auto-configuration server (ACS) profile for CPE management	acsUrl, deviceIdentifier, firmwareVersion, configTemplate

Resource Assignment and Reservation

Resource assignment is the process of selecting specific resources from inventory to fulfill an RFS. This is one of ROM's most critical and complex functions, because the right resource must be selected based on multiple criteria: availability, proximity, capacity, compatibility, and business rules.

Resource Assignment Steps

Identify Required Resource Type

ROM

ROM reads the RFS specification to determine what type of resource is needed (e.g., OLT port, VLAN ID).

Query Resource Inventory

ROM → Resource Inventory

ROM queries TMF639 for available resources matching the required type, location, and capacity constraints.

Select Best Candidate

ROM

ROM applies selection rules to pick the optimal resource (e.g., nearest OLT with available ports, VLAN from the correct range).

Reserve Resource

ROM → Resource Inventory

ROM marks the selected resource as "reserved" in inventory to prevent concurrent allocation by other orders.

Strategy	Description	Use Case
First Available	Select the first resource that meets the minimum criteria	Simple, fast allocation for abundant resources (e.g., IP addresses)
Best Fit	Select the resource that most closely matches the requirement without waste	Port capacity matching — avoid assigning a 10G port for a 100M service
Load Balanced	Distribute allocations evenly across available resources	Spreading customers across OLT cards to avoid hotspots
Proximity-Based	Select the nearest resource to the service location	Fibre path optimisation — minimise cable distance
Reserved Pool	Allocate from a pre-reserved pool for specific customer segments	Enterprise customers get resources from a dedicated pool with SLA guarantees

Resource reservation must handle concurrent access — multiple orders competing for the same resources simultaneously. Common patterns include:

Pessimistic locking: Reserve immediately and hold until activation completes or the order is cancelled. Simple but can tie up resources for extended periods.
Optimistic locking: Attempt allocation at activation time. Faster throughput but may fail if the resource was taken by another order.
Time-limited reservation: Reserve with a TTL (time-to-live). If the order does not complete within the TTL, the reservation is automatically released.
Two-phase commit: First reserve, then confirm. If confirmation does not arrive within a timeout, the reservation is released.

Resource Leaks

A "resource leak" occurs when a resource is reserved but the order that reserved it is cancelled or fails without properly releasing the reservation. Over time, this reduces the available resource pool and can cause false "resource exhaustion" alerts. Robust ROM implementations include periodic reconciliation jobs that detect and clean up orphaned reservations.

Network Activation Interface

Network activation is the step where ROM actually configures network equipment. This is the most technically diverse part of the fulfillment chain, because different network elements support different configuration protocols, data models, and operational procedures.

Common Network Activation Protocols

Protocol	Description	Typical Use
NETCONF/YANG	Model-driven configuration protocol using structured YANG data models over SSH	Modern routers, switches, and SDN controllers
CLI (SSH/Telnet)	Command-line interface scripting — send text commands to the device	Legacy network elements that do not support NETCONF
REST API	HTTP/JSON API exposed by the network element or controller	SDN controllers, cloud platforms, virtualized network functions (VNFs)
SNMP SET	Simple Network Management Protocol write operations	Legacy elements for simple configuration (increasingly rare for provisioning)
TR-069 (CWMP)	CPE WAN Management Protocol for managing customer premises equipment	Home routers, ONTs, set-top boxes
CORBA/MTOSI	Legacy TMN interfaces used by traditional OSS/NMS systems	Legacy transport network management (being replaced by NETCONF/REST)

The Activation Adapter Pattern

ROM typically does not interface with network elements directly. Instead, it uses an "activation adapter" (sometimes called a "mediation layer" or "activation driver") for each network element type. The adapter translates ROM's abstract resource order items into device-specific commands. This adapter pattern decouples ROM from network technology — when a new device type is introduced, only a new adapter needs to be built, not a change to ROM itself.

The activation process is typically:

Network Activation Sequence

ROM Prepares Activation Request

ROM

ROM builds an activation request containing the target device, configuration parameters, and the desired state. Parameters are derived from the resource order item characteristics and the allocated resource details.

Adapter Translates to Device Language

Activation Adapter

The activation adapter for the target device type translates the abstract request into device-specific commands (NETCONF edit-config, CLI commands, REST API calls).

Configuration Push

Adapter → Network Element

The adapter sends the configuration to the network element. For NETCONF, this is an edit-config operation. For CLI, this is a sequence of commands. For REST, this is an API call.

Verification

Adapter → Network Element

The adapter verifies the configuration was applied correctly — typically by reading back the configuration (NETCONF get-config) or running a service test (e.g., ping, layer 2 connectivity check).

Completion Reported

Adapter → ROM

The adapter reports success or failure back to ROM. If successful, ROM updates the resource order item state to "completed" and updates Resource Inventory.

Resource Order Lifecycle States

TMF652 Resource Order States

State	Description	Typical Trigger
acknowledged	Resource order received and validated	POST /resourceOrder from SOM
inProgress	Resource assignment and/or activation is underway	ROM begins processing first resource order item
held	Processing paused due to resource issue	No resources available, activation failure requiring manual intervention
completed	All resource order items allocated and activated successfully	All activation adapters report success
failed	Resource allocation or activation failed unrecoverably	Retry exhaustion, permanent resource unavailability
cancelled	Resource order cancelled; any allocated resources released	Cancellation request from SOM
partial	Some items completed, others failed	Mixed activation results

TMF652 Resource Ordering API

TMF652 — Resource Ordering Management

TMF652 provides a standardized REST API for creating, querying, and managing resource orders. It is the standard interface between SOM and ROM. Key operations: POST /resourceOrder (create), GET /resourceOrder/{id} (retrieve), GET /resourceOrder (list/search), PATCH /resourceOrder/{id} (update/cancel). Like TMF641, TMF652 supports event-based asynchronous notifications for state changes.

TMF652 is the API that SOM uses to submit resource orders to ROM. Its structure mirrors TMF622 and TMF641: a Resource Order containing Resource Order Items, each referencing a resource specification from the resource catalog.

POST /resourceOrder — Create a new resource order
GET /resourceOrder/{id} — Retrieve order status and details
GET /resourceOrder — List/search resource orders
PATCH /resourceOrder/{id} — Update (e.g., cancel)

TMF652 Resource Order Item Fields

Field	Type	Description
id	string	Unique item identifier
action	string	add \| modify \| delete \| noChange
state	string	Item-level lifecycle state
resource.resourceSpecification	ref	Reference to RFS or Resource spec in resource catalog
resource.resourceCharacteristic	array	Configuration values (VLAN ID, bandwidth, IP range)
resource.place	array	Location for physical resource allocation
resource.relatedParty	array	Owner/assignee of the resource
orderItemRelationship	array	Dependencies on other items in this order

ROM publishes events as resource order items progress through their lifecycle. SOM subscribes to these events to update its orchestration state:

ResourceOrderCreateEvent: ROM acknowledges receipt of a new resource order
ResourceOrderStateChangeEvent: Overall resource order state changes
ResourceOrderItemStateChangeEvent: Individual item state changes (most important for SOM)
ResourceOrderAttributeValueChangeEvent: Resource order attributes modified (e.g., assigned resource details populated)

SOM uses ResourceOrderItemStateChangeEvent to update its orchestration plan. When a resource order item completes, SOM evaluates whether dependent service order items can now proceed.

ROM and Resource Inventory

Resource Inventory (TMF639) is the system of record for all physical and logical resources in the network. ROM's relationship with Resource Inventory is bidirectional and critical:

Query available resources: ROM queries inventory to find resources that match the required specification, are available, and are located at or near the service address.
Reserve resources: ROM marks selected resources as "reserved" (allocated to a pending order) to prevent double-allocation.
Update resource state: Upon successful activation, ROM updates the resource state from "reserved" to "active" and associates it with the service instance.
Release on failure: If activation fails or the order is cancelled, ROM releases the reservation, returning the resource to "available" state.
Decommission on cease: For cease orders, ROM marks resources as "available" after deactivation, returning them to the pool.

TMF639 Resource Inventory Management

TMF639 provides the standard API for managing resource instances. Key resources include /resource (CRUD for resource instances), with support for complex queries by specification, status, location, and relationship. Resource instances carry characteristics, lifecycle state, location, and relationships to other resources and services.

ROM Integration Points

ROM Integration Map

System	Direction	API / Pattern	Purpose
SOM	Inbound	TMF652 POST /resourceOrder	Receive resource orders from service layer
SOM	Outbound events	TMF652 Events	Notify SOM of resource order state changes
Resource Catalog	Outbound query	TMF634 GET	Retrieve resource specifications
Resource Inventory	Bidirectional	TMF639	Query, reserve, update, release resources
Network Elements	Outbound	NETCONF, CLI, REST, TR-069	Push configuration to network devices
IPAM	Outbound	Custom / IPAM API	Allocate IP addresses and prefixes
VLAN Manager	Outbound	Custom API	Assign VLANs from managed pools
Workforce Management	Outbound	TMF646 / Custom	Schedule physical installation tasks (splicing, ONT install)

Common ROM Challenges

Resource exhaustion: All ports on the nearest OLT are in use. ROM must either find an alternative (different OLT, different technology) or flag the order for network planning intervention.
Stale inventory data: Resource Inventory says a port is available, but it is actually in use. This happens when manual network changes are not reflected in inventory (a major operational pain point).
Activation failures: Network element rejects the configuration due to incompatible firmware, configuration conflicts, or element being unreachable.
Multi-vendor complexity: Different network element vendors support different configuration models. The adapter layer must handle this heterogeneity.
Physical installation dependencies: Some resource orders require field work (fibre splicing, ONT installation) that introduces human scheduling dependencies.
Concurrent order contention: Two orders targeting the same network element may conflict. ROM must serialize or coordinate activation requests.

ROM vs Direct Network Activation

The Direct Activation Anti-Pattern

Some organisations bypass ROM entirely, having SOM (or even COM) directly call network activation adapters. While this reduces system count, it creates significant problems: loss of resource assignment separation, no resource reservation mechanism, tight coupling between service logic and network technology, and no resource-level order tracking. ROM exists specifically to encapsulate resource complexity behind a standard interface.

ROM-Based vs Direct Activation

Aspect	With ROM	Direct Activation
Resource assignment	Handled by ROM with inventory queries	Must be done by SOM (leaks responsibility)
Reservation	ROM manages resource locks	No standard reservation mechanism
Technology abstraction	ROM + adapters hide technology details	SOM must know about network technologies
Rollback	ROM handles resource de-allocation	SOM must implement resource cleanup
Order tracking	Resource orders are independently trackable	No resource-level order visibility
Scalability	ROM can scale independently	All concerns in SOM — harder to scale

Section 3.4 Key Takeaways

ROM is the lowest layer of order management, responsible for resource allocation and network activation
ROM operates at the RFS and Resource layers, bridging OSS fulfillment and network infrastructure
Resource assignment selects specific resources (ports, VLANs, IPs) from inventory using selection strategies
Resource reservation prevents concurrent allocation conflicts between orders
Network activation uses adapters to translate abstract orders into device-specific commands (NETCONF, CLI, REST, TR-069)
ROM maintains Resource Inventory (TMF639) as the system of record for all network resources
TMF652 Resource Ordering API standardises the SOM → ROM interface
Common challenges include resource exhaustion, stale inventory, and multi-vendor activation complexity
Bypassing ROM (direct activation from SOM) creates tight coupling and loses resource management capabilities