Activation & Provisioning

How services are activated on the network: provisioning patterns and integration.

What Activation Means in Telco

Activation is the process of making a service actually work on the network. It translates catalog definitions and inventory entries into real configurations on real devices. COM decomposes the commercial order, SOM orchestrates the service order, ROM manages the resource order, and the activation engine pushes configurations onto network elements. It is the last mile of order fulfilment.

Activation

The process of applying configurations to network elements and management systems to enable a service for a customer. Translates abstract service and resource definitions into concrete device commands, API calls, or policy configurations.

The catalog defines what could be. Inventory records what should be. Activation makes it so.
— Telco fulfilment principle

Provisioning vs Activation

Provisioning prepares and allocates resources (VLAN, IP, subscriber profile). Activation enables the service so the customer can use it (push QoS policy, enable port, update DHCP). Provisioning can happen in advance; activation happens at the moment the service should go live. In many implementations they are a single workflow, but the distinction matters in complex environments where resources are provisioned days before activation.

Activation Patterns

There are three architectural patterns for how the activation engine interacts with the network.

Three activation patterns — direct, mediated, and orchestrated — each suited to different network complexity levels

Figure 4.5 — Three activation patterns: direct, mediated, and orchestrated

Activation Pattern Comparison

Criteria	Direct	Mediated	Orchestrated
How it works	Activation engine talks directly to each device via native protocol (CLI, SNMP, NETCONF)	An EMS/NMS translates high-level intents into device-specific commands	A service orchestrator coordinates across multiple domains, controllers, and management systems
Multi-vendor	Hard — adapter per device type	Medium — EMS per vendor	Good — controller per domain
Rollback	Manual	Per-device via EMS	Cross-domain orchestrated rollback
Best for	Small or homogeneous networks	Mid-size, single-technology focus	Large operators, converged/NFV/SDN networks

Pre-Provisioning and Lazy Activation

Pre-provisioning: Configure network resources before a customer order exists. Common in FTTH rollouts — ONTs and OLT ports configured during construction so subsequent orders activate in minutes, not days. Risk: wasted investment if take-up is low.
Lazy activation: Delay final activation steps until the customer actually tries to use the service. Example: DHCP-triggered activation — the router sends a DHCP request, the network recognises the ONT serial, and triggers the remaining QoS configuration. Enables self-install with no truck roll.

End-to-End Activation Workflow

Activation Workflow: New Broadband Service

Request & Validation

ROM → Activation Engine

ROM sends an activation request with resource configurations. The activation engine validates: are parameters present? Is the device reachable? Is the port in the expected state?

Configuration Generation & Push

Activation Engine → NE / EMS / Controllers

Templates map abstract parameters ("VLAN=1042, QoS=200Mbps") to vendor-specific payloads. Commands are sent to network elements: configure VLAN, set QoS, update DHCP, create RADIUS profile.

Verification & Inventory Update

Activation Engine → Inventory

Configuration is read back from the device to confirm correct application. Resource Inventory updates to "In Use"; SLM updates to "Active". Events are published.

Confirmation Cascade

ROM → SOM → COM

Activation engine reports success to ROM → SOM → COM. Product Inventory updates to "Active." Customer is notified.

Error Handling and Rollback

Common Activation Failures

Device unreachable, configuration conflict with existing config, resource already consumed between reservation and activation, device timeout, or validation rejection. Partial failures (e.g., VLAN configured but QoS failed) leave the system in an inconsistent state.

Compensating actions: Apply specific "undo" commands for each successful step in reverse order
Checkpoint and retry: Save state before each step, retry failed step, roll back only if retry fails
Saga pattern (multi-domain): Each domain activation is a local transaction. If a downstream domain fails, compensating transactions execute in reverse on all successful domains
Manual intervention queue: If automated rollback fails, park the activation for operator resolution

Network Integration Points

The activation engine integrates with multiple network management and control systems:

EMS (Element Management System): Manages a specific vendor's devices — Huawei iManager, Nokia NetAct
SDN Controller: Programmable control of forwarding — ONOS, OpenDaylight
NFVO: VNF lifecycle management — ONAP, Open Source MANO
AAA / RADIUS: Subscriber authentication and profile management
DHCP / DNS: IP address assignment and name resolution

TMF640/641 Activation APIs

TMF640 & TMF641

TMF640 (Service Activation and Configuration) focuses on applying/modifying/removing configurations on the network. TMF641 (Service Order Management) orchestrates the service order lifecycle that triggers activation. Together they provide a standardized interface between SOM/ROM and the activation engine.

Model-Driven Activation

Advanced

From Script-Based to Model-Driven

Modern activation engines are moving from script-based (hardcoded command sequences) to model-driven (declarative intent, template rendering). This enables faster service introduction and reduced per-vendor customisation.

Activation templates are defined using YANG or TOSCA models. The engine receives a service intent, resolves the appropriate template for the target device vendor/model, renders it with instance-specific values, and pushes the result. New device support = new templates, not new code. Pre-validation against the model catches errors before they reach the device, and rollback can be auto-generated from the model.

Keeping Inventory and Network in Sync

Closed-loop activation: After every activation, read back configuration and compare with intended state. Flag discrepancies immediately.
Event-driven updates: Network elements publish configuration change events (NETCONF notifications, SNMP traps). Inventory listens and updates.
Periodic reconciliation: Scheduled scans compare device state against inventory. Discrepancies are queued for resolution.

Source of Record

Activation Domain SoR Mapping

Entity	System of Record	System of Engagement	System of Reference	Notes
Activation Task / Work Order	Activation Engine / ROM	SOM (triggers activation)	Assurance (activation history)	Tracks what was requested, attempted, and confirmed.
Device Configuration (intended)	Resource Inventory / Activation Engine	Activation Engine (pushes config)	Network Operations (verification)	What the configuration SHOULD be.
Device Configuration (actual)	Network Element / NMS	N/A (network element owns its running config)	Activation Engine (read-back), Reconciliation	What the configuration IS. May drift from intended.

Section 4.5 Key Takeaways

Activation configures network elements to make a service work — the last mile of fulfilment
Three patterns: direct (to device), mediated (via EMS), and orchestrated (multi-domain)
Pre-provisioning configures resources in advance; lazy activation defers until customer trigger (e.g., DHCP)
Error handling and rollback (including the Saga pattern) are essential for maintaining consistency
Modern activation is moving from script-based to model-driven approaches using YANG/TOSCA templates