4.515 min read

Activation & Provisioning

What Activation Means in Telco

Activation is the process of making a service actually work on the network. It is the moment where catalog definitions and inventory entries translate into real configurations on real devices. Until activation happens, a customer's order is just data in systems. After activation, packets flow, calls connect, and TV channels stream.

Activation sits at the very bottom of the fulfilment chain: COM decomposes the commercial order, SOM orchestrates the service order, ROM manages the resource order, and finally 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. Activation translates the abstract service and resource definitions from inventory into concrete device commands, API calls, or policy configurations. It is the bridge between the OSS domain and the network domain.

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

Provisioning vs Activation: What Is the Difference?

The terms "provisioning" and "activation" are often used interchangeably, but they have distinct meanings in BSS/OSS architecture. Understanding the difference matters because different systems may be responsible for each.

Provisioning vs Activation

Aspect	Provisioning	Activation
Definition	Preparing and allocating resources for a service	Enabling the service so the customer can use it
Scope	Resource allocation, configuration preparation, account setup	Applying configuration to network, turning service on
Timing	Can happen in advance (pre-provisioning)	Happens at the moment service should go live
Reversibility	Provisioned resources can be released if order is cancelled	Activation is followed by the service being in use
Example	Allocate VLAN, reserve IP, create subscriber profile in RADIUS	Push QoS policy to OLT, enable ONT port, update DHCP server
System	Resource Order Management, IPAM, Subscriber Management	Activation engine, Network Element Managers, SDN controllers

The Practical Overlap

In many implementations, provisioning and activation are performed by the same system in a single workflow. The distinction becomes important in complex environments where resources are provisioned hours or days before the activation date (e.g., new build premises where equipment is installed during construction but service is activated when the customer moves in).

Activation Patterns

There are several architectural patterns for how the activation engine interacts with the network. The choice depends on the network technology, the number of network element types, and the operator's architecture maturity.

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

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

Pattern 1: Direct Activation

Beginner

Direct Activation

The activation engine communicates directly with each network element using the element's native protocol (CLI, SNMP, NETCONF, proprietary API). Simple but hard to scale.

In direct activation, the activation engine must understand the specific command syntax, protocol, and data model of every network element type. If you have 10 different OLT vendors, the activation engine needs 10 different adapters. This is the simplest pattern for small or homogeneous networks but becomes a maintenance burden as the network grows.

Pros: Simple, no middleware, fast for small networks
Cons: Vendor lock-in in the activation layer, hard to scale, adapter per device type
Best for: Small operators, homogeneous networks, legacy environments
Protocol examples: Telnet/SSH CLI, SNMP SET, TL1, proprietary APIs

Pattern 2: Mediated Activation

Intermediate

Mediated Activation

An Element Management System (EMS) or Network Management System (NMS) sits between the activation engine and the network elements. The activation engine speaks to the EMS via a northbound API, and the EMS translates to device-specific commands.

Mediated activation introduces a layer of abstraction. The activation engine sends a high-level intent ("create subscriber with 200Mbps downstream on OLT-EAST-07") and the EMS translates this into the vendor-specific CLI or NETCONF commands. This decouples the activation engine from device-specific details, making it easier to support multiple vendors and device types.

Pros: Vendor abstraction, EMS handles device specifics, easier multi-vendor support
Cons: EMS is often vendor-specific, adds latency, EMS availability becomes critical
Best for: Multi-vendor networks, operators with existing EMS/NMS infrastructure
Protocol examples: CORBA, MTOSI, REST APIs (EMS northbound), NETCONF/CLI (EMS southbound)

Pattern 3: Orchestrated Activation

Advanced

Orchestrated Activation

A service orchestrator coordinates activation across multiple network domains, controllers, and management systems. The orchestrator decomposes the service activation into technology-specific tasks and manages the end-to-end workflow.

Orchestrated activation is the modern pattern for complex, multi-domain services. The orchestrator (which may be the SOM itself, or a dedicated NFVO/service orchestrator) receives a service activation request and coordinates across SDN controllers, VNF managers, EMS systems, and direct device interfaces. This pattern supports complex workflows including rollback, compensation, and parallel activation across independent domains.

Pros: Multi-domain, technology-agnostic, supports complex workflows and rollback
Cons: Higher complexity, requires integration with multiple controllers, orchestrator is a critical system
Best for: Large operators, multi-technology networks, NFV/SDN environments, service chains
Technologies: TOSCA models, YANG-based intents, ETSI MANO (SOL005), TMF640/641

Activation Pattern Comparison

Criteria	Direct	Mediated	Orchestrated
Complexity	Low	Medium	High
Multi-vendor support	Hard (adapter per device)	Medium (EMS per vendor)	Good (controller per domain)
Scalability	Limited	Moderate	High
Rollback capability	Manual	Per-device via EMS	Cross-domain orchestrated rollback
Speed of change	Slow (new adapter per device type)	Moderate (EMS update per new device)	Fast (model-driven, template-based)
Typical deployment	Legacy, small operators	Mid-size, single-technology focus	Large operators, converged networks

Pre-Provisioning and Lazy Activation

Not all activation happens at the time of order fulfilment. Two important timing patterns are pre-provisioning (configure the network before the customer needs it) and lazy activation (delay activation until the customer actually tries to use the service).

Pre-provisioning means configuring network resources before a customer order exists. The most common example is provisioning ONTs and OLT ports during a fibre rollout, so that when a customer signs up, the service can be activated almost instantly because the heavy lifting is already done.

New build/MDU: ONTs installed, OLT ports configured during construction
Reduces activation time from days to minutes for subsequent orders
Resources are in "Installed/Available" state, waiting for customer allocation
Risk: wasted investment if customer take-up is lower than expected
Common in FTTH deployments and new housing developments

FTTH Pre-Provisioning Example

A fibre operator rolls out GPON to a new suburb. During construction, they install ONTs in every premise and connect each to an OLT port. Resource Inventory records each ONT and port as "Installed" with status "Available." When a customer signs up, the fulfilment process only needs to: allocate a VLAN, assign an IP address, configure the QoS profile, and enable the port. Activation time: 15 minutes instead of 5-7 days.

End-to-End Activation Workflow

A typical activation workflow involves multiple steps, from receiving the activation request through configuring network elements to confirming success. Each step must be tracked, and failure at any point must trigger appropriate error handling.

Activation Workflow: New Broadband Service

Activation Request Received

ROM → Activation Engine

ROM sends an activation request to the activation engine with the resource configurations to apply: OLT port, VLAN, IP address, QoS profile.

Pre-Activation Validation

Activation Engine

Activation engine validates the request: are all required parameters present? Is the target device reachable? Is the port in the expected state? Are there any conflicting configurations?

Configuration Generation

Activation Engine

Activation engine generates device-specific commands from the abstract resource model. Templates map "VLAN=1042, QoS=200Mbps" to vendor-specific CLI or NETCONF payloads.

Configuration Push

Activation Engine → NE / EMS / Controllers

Commands are sent to the network element(s): configure VLAN on OLT, set QoS profile, update DHCP server, create subscriber profile in RADIUS/AAA.

Post-Activation Verification

Activation Engine

Activation engine reads back the configuration from the device to confirm it was applied correctly. May also perform a connectivity test (ping, traffic check).

Inventory Update

Resource & Service Inventory

Resource Inventory is updated: resources move to "In Use" state. Service Inventory is updated: service instances move to "Active" state. Events are published.

Confirmation to SOM/ROM

Activation Engine → ROM → SOM → COM

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

Error Handling and Rollback

Activation failures are a reality of network operations. Devices may be unreachable, configurations may conflict, or resources may already be in use. Robust error handling and rollback capabilities are essential for maintaining system consistency.

Common Activation Failure Scenarios

Device unreachable: network element cannot be contacted due to network issues or device failure. Configuration conflict: the requested configuration conflicts with an existing configuration on the device. Resource already in use: the reserved resource was consumed by another process between reservation and activation. Timeout: the device did not respond within the expected time window. Validation failure: the device rejected the configuration due to syntax or constraint errors.

If activation fails halfway through (e.g., the VLAN was configured but the QoS profile failed), the system is in an inconsistent state. Rollback means undoing the partial changes to return to a clean state. Without rollback, partial configurations accumulate and cause operational problems.

Full rollback: Undo all changes made during this activation attempt, return all resources to previous state
Compensating actions: Apply specific "undo" commands for each successful step (reverse order)
Checkpoint and retry: Save state before each step, retry failed step, roll back only if retry fails
Idempotent activation: Design configurations so they can be safely re-applied (convergent approach)
Manual intervention queue: If automated rollback fails, park the activation for manual resolution

In orchestrated activation across multiple domains, the Saga pattern is commonly used. Each domain activation is a local transaction. If a downstream domain fails, compensating transactions are executed in reverse order on all previously successful domains. For example: if IP profile activation succeeds on the BNG but QoS profile activation fails on the OLT, the saga coordinator triggers an "undo IP profile" compensating action on the BNG.

The Saga pattern works well with the TMF640/641 service activation and configuration APIs, where each activation task has a corresponding deactivation/rollback task defined in the workflow model.

Integration with NMS, EMS, and SDN Controllers

The activation engine does not operate in isolation. It integrates with various network management and control systems. Understanding this integration landscape is crucial for anyone involved in BSS/OSS architecture.

Network Integration Points

System	Role	Protocol / Interface	Example
EMS (Element Management System)	Manages a specific vendor's devices	CORBA, REST API, MTOSI	Huawei iManager U2000 for OLT management
NMS (Network Management System)	Cross-vendor monitoring and management	SNMP, NETCONF, syslog	Multi-vendor network visibility and alerting
SDN Controller	Programmable control of network forwarding	OpenFlow, NETCONF, REST/gRPC	ONOS, OpenDaylight for transport SDN
NFVO (NFV Orchestrator)	Lifecycle management of virtual network functions	ETSI SOL005, REST API	ONAP, Open Source MANO for VNF deployment
AAA / RADIUS	Authentication and subscriber profile management	RADIUS CoA, Diameter	FreeRADIUS, Cisco ISE for subscriber auth
DHCP Server	IP address assignment to customer devices	DHCP relay, API	ISC Kea, Infoblox for dynamic IP allocation
DNS	Name resolution configuration	DNS API, zone file updates	Reverse DNS records for allocated IPs

TMF640/641 Service Activation and Configuration

TMF640 & TMF641 — Activation and Configuration

TMF640 (Service Activation and Configuration) and TMF641 (Service Order Management) define the APIs for activation workflows. TMF640 focuses on the activation/deactivation of service configurations on the network, while TMF641 orchestrates the service order lifecycle that triggers activation. Together they provide a standardized interface between SOM/ROM and the activation engine.

TMF640 vs TMF641

Aspect	TMF640	TMF641
Focus	Service activation/configuration execution	Service order lifecycle orchestration
Scope	Apply/modify/remove configurations on network	Manage the order that triggers activation
Consumer	SOM, ROM	COM, SOM
Provider	Activation engine, EMS, SDN controller	SOM (Service Order Management)
Key operations	Activate, modify, deactivate service config	Create, update, cancel service order

Activation Across Technology Domains

Activation looks very different depending on the technology domain. Each domain has its own devices, protocols, and activation patterns.

FTTH/GPON activation involves configuring the OLT (Optical Line Terminal) and ONT (Optical Network Terminal). Key activation steps include creating the subscriber profile on the OLT, configuring VLANs and GEM ports, setting QoS profiles, and registering the ONT serial number.

Register ONT serial number on OLT (whitelist)
Create service port with VLAN mapping (C-VLAN to S-VLAN)
Configure GEM port with traffic descriptors (bandwidth profiles)
Apply QoS profile (upstream/downstream rate limiting)
Configure multicast for IPTV (IGMP snooping)
Update RADIUS/AAA with subscriber profile

Model-Driven Activation

Advanced

From Script-Based to Model-Driven Activation

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

In a model-driven approach, activation templates are defined using YANG or TOSCA models. The activation engine receives a service intent (e.g., "create internet access with 200Mbps on GPON"), resolves the appropriate template for the target device vendor and model, renders the template with instance-specific values, and pushes the resulting configuration. New device support is added by creating new templates, not by writing new code. This aligns with the catalog-driven philosophy: the "catalog" of activation templates mirrors the service and resource catalogs.

Script-Based vs Model-Driven Activation

Aspect	Script-Based	Model-Driven
Configuration definition	Hardcoded in scripts/code	Declarative templates (YANG, TOSCA)
New service introduction	Write new scripts, test, deploy	Create new template, test, publish
New vendor support	Write vendor-specific adapter code	Create vendor-specific template set
Validation	Runtime errors (fail on device)	Pre-validation against model (fail before push)
Rollback	Custom rollback scripts per flow	Auto-generated from model (reverse of intent)
Auditability	Trace through code/logs	Clear mapping from intent to configuration

Keeping Inventory and Network in Sync

One of the hardest operational challenges is keeping inventory synchronized with the actual network state. Activation creates configurations, but over time, manual changes, device replacements, and software updates can cause drift between what inventory says and what the network has.

Closed-loop activation: After every activation, read back the configuration from the device and compare with the intended state. Flag discrepancies immediately.
Event-driven updates: Network elements publish configuration change events (NETCONF notifications, SNMP traps). Inventory listens and updates accordingly.
Periodic reconciliation: Scheduled jobs that scan devices and compare against inventory. Discrepancies are logged and queued for resolution.
Intent-based networking: The activation engine continuously monitors the network and corrects any drift from the intended state (convergent approach).

Design Intent vs Actual State

Mature operators maintain two views in inventory: the "design intent" (what the configuration should be) and the "actual state" (what the device reports). When these diverge, the operator can choose to either correct the network (enforce intent) or update the intent (accept the change). This dual-state model provides a clear foundation for reconciliation.

Activation 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.
Activation Templates	Activation Engine / Template Repository	Platform Engineering (template design)	SOM (determines which template to use)	Model-driven templates for each device type/vendor.

Section 4.5 Key Takeaways

Activation is the process of configuring network elements to make a service actually work — the last mile of fulfilment
Provisioning (prepare/allocate resources) and activation (enable the service) are related but distinct steps
Three activation patterns: direct (to device), mediated (via EMS/NMS), and orchestrated (multi-domain coordination)
Pre-provisioning configures resources in advance; lazy activation defers final steps until customer trigger (e.g., DHCP)
The activation workflow includes validation, configuration generation, push, verification, inventory update, and confirmation
Error handling and rollback (including the Saga pattern) are essential for maintaining consistency during failures
Modern activation is moving from script-based to model-driven approaches using YANG/TOSCA templates
Inventory-network synchronization requires closed-loop activation, event-driven updates, and periodic reconciliation