Activation & Provisioning
Last updated 14 Oct 2026
At a glance
Activation applies configuration to network elements and network functions so that a service actually works. It turns assigned resources and service parameters into device commands, API calls or policies, verifies the result, and updates inventory. Provisioning prepares and allocates those resources, sometimes well before activation. Together they are the last step of fulfilment.
The picture
Three activation patterns — direct, mediated, and orchestrated — each suited to different network complexity levels
How it works
Provisioning and activation
Provisioning prepares and allocates: a VLAN, an IP address, a subscriber profile. Activation enables the service at the moment it should go live: push the QoS policy, enable the port, update DHCP. Many implementations run them as one workflow; the distinction matters where resources are provisioned days before the customer goes live.
Three patterns
| Direct | Mediated | Orchestrated | |
|---|---|---|---|
| How | Activation talks to each device in its own protocol | An EMS or NMS turns the request into vendor commands | An orchestrator coordinates several domains, controllers and EMSs |
| Multi-vendor | Hard: one adapter per device type | Moderate: one EMS per vendor | Easier: one controller per domain |
| Rollback | Largely manual | Per device, through the EMS | Coordinated across domains |
| Fits | Small or uniform networks | Mid-size, single-technology domains | Large, converged or virtualised networks |
The request may come from ROM, from a SOM workflow, or straight to a domain controller that assigns and configures for itself; there is no single mandatory chain. 10.3 covers the paths below ROM.
One activation, step by step
Request and validate
ROM or SOM → activationThe activation request arrives with resource and service parameters. Are they complete? Is the device reachable? Is the port in the expected state?
Generate and push
Activation → networkTemplates turn abstract values (VLAN 1042, 200 Mbps) into vendor-specific configuration and send it to devices, EMSs, controllers, AAA and DHCP.
Verify and record
TMF639Configuration is read back to confirm it applied. Resource inventory moves to In use and events are published.
Confirm upwards
TMF652 / TMF641 / TMF622Success is reported to the requesting layer and on up the order chain until the product is marked active.
Pre-provisioning and deferred activation
- Pre-provisioning: configure resources before any order exists, for example OLT ports during an FTTH build, so orders activate in minutes. The cost is configuration that may never be used.
- Deferred (lazy) activation: hold the final steps until the customer first connects. A DHCP request from a recognised ONT triggers the remaining configuration, which makes self-install possible.
Failure and rollback
Devices are unreachable, configuration conflicts with what is already there, a resource is taken between reservation and activation, or a step times out. A partial failure (VLAN applied, QoS not) is the hardest case, because the network is left half-changed.
- Compensating actions: undo each successful step in reverse order.
- Checkpoint and retry: retry the failed step, roll back only if the retry fails.
- Saga across domains: each domain is a local transaction; on downstream failure, compensations run in reverse in the domains that succeeded.
- Manual queue: when automated rollback fails, park the activation for an engineer.
Script-based to model-driven
Older activation engines run hard-coded command sequences per device. Model-driven activation defines templates against YANG or TOSCA models: the engine picks the template for the device type, fills in the instance values, validates against the model and pushes. Supporting a new device becomes a template change rather than new code, and rollback can be derived from the model.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Activation task | Activation engine (or ROM, where ROM performs activation itself) | SOM or ROM, which request it | Assurance (activation history) | What was requested, attempted and confirmed. |
| Intended device configuration | Activation engine or network automation platform | — | Resource inventory, network operations | What the configuration should be. Which system holds it depends on where templates and models live. |
| Actual device configuration | The network element | — | Activation (read-back), reconciliation | What the configuration is. It can drift from intent. |
| Resource state after activation | Resource inventory | Activation, ROM | — | TMF639. Moves to In use on confirmed activation. |
| Subscriber profile (AAA / policy) | The AAA or policy platform | Activation | Service inventory | Activation writes it; the network function holds it. |
In practice
Activation is where integration effort concentrates. An activation engine typically connects to several EMSs, SDN controllers, NFV orchestration, AAA/RADIUS and DHCP/DNS, each with its own interface, upgraded on its own schedule. Each new device type or vendor adds adapters or templates.
Rollback is the part most often designed late. Most network elements do not support transactions across devices, so rollback is a compensating sequence someone has to write and test. Where it is not designed, partial failures land in a manual queue and the inventory is left disagreeing with the network.
Keeping inventory and network in step after activation takes three mechanisms used together: read-back after each activation, change events from the network (NETCONF notifications, SNMP traps), and periodic reconciliation. Configuration changed by hand through an EMS bypasses the first and is caught only by the other two.
The trade-off
What it solves
Order-driven configuration of the network, repeatable and verified, with inventory updated as part of the same flow rather than afterwards.
What it does not solve
- Inventory accuracy. Activation trusts the resources it is given; wrong assignments become activation failures.
- Changes made outside the order flow. Engineers working directly through an EMS are invisible to activation.
- Device behaviour. Vendor quirks still have to be learned and encoded in adapters or templates.
What it adds
- One adapter or template set per device type and vendor, maintained across upgrades.
- Rollback and partial-failure handling that has to be designed and tested.
- Pre-provisioned configuration that must be tracked and cleaned up if never used.
Architecture decision
Script-based activation or model-driven activation?
Script-based
Choose when a small, stable set of device types, little change expected, and existing scripts that work
Model-driven (YANG or TOSCA templates)
Choose when several vendors, frequent new services or device types, and devices with usable model-driven interfaces
Breaks if Models are introduced but devices only accept CLI, so every template still wraps a script, or scripts multiply until nobody can say what configuration a service should have.
Takeaways
Key Takeaways
- Activation applies configuration to make a service work; provisioning prepares the resources, sometimes in advance.
- Direct, mediated and orchestrated patterns coexist, domain by domain; none is a mandatory chain.
- Every activation needs validation, verification by read-back and an inventory update.
- Partial failure is the hard case; rollback is a designed compensating sequence, not a single undo.
- Model-driven activation turns new device support into templates rather than code.
Check yourself
An activation applied the VLAN but the QoS step timed out. What should happen next?Show answerHide
Retry the QoS step; if it still fails, run the compensating action to remove the VLAN, release or hold the reserved resources according to policy, and if the rollback itself fails, park it for an engineer. Inventory must reflect whatever state the network is actually left in.
Why might an FTTH operator pre-provision OLT ports, and what is the cost?Show answerHide
So orders activate in minutes and customers can self-install. The cost is configuration and capacity committed to premises that may never order, which has to be tracked and eventually reclaimed.