Worked Example: Connectivity Service
Worked Example: Residential Broadband
This section walks through a complete, realistic example of how a residential broadband product decomposes through every catalog layer — from the Product Offering displayed in the online shop, all the way down to the physical resources on the network. This ties together every concept from Module 2.
Full decomposition of SuperFibre 200 Home -- from commercial offering down to network resources
Layer 1: Product Offering
Layer 2: Product Specification
Product Specification: Residential Broadband Access
| Component | Type | Cardinality | Linked CFS |
|---|---|---|---|
| Internet Access | Mandatory | 1:1 | CFS:Internet-Access |
| WiFi Management | Optional (included in this offering) | 0:1 | CFS:WiFi-Management |
| Router Equipment | Mandatory (choice of model) | 1:1 | CFS:CPE-Management |
| Static IP | Optional (not included) | 0:1 | CFS:Static-IP |
The Product Specification defines the structure: what components exist, which are mandatory, and which CFS each component links to. The Product Offering selects which optional components are included and sets characteristic values (speed = 200Mbps).
Layer 3: Customer-Facing Services
For the "SuperFibre 200 Home" offering, three CFS instances are created (Static IP was not selected):
| Attribute | Value |
|---|---|
| Service Type | Internet Access |
| Download Speed | 200 Mbps |
| Upload Speed | 50 Mbps |
| Data Quota | Unlimited |
| IP Version | Dual Stack (IPv4 + IPv6) |
| SLA | Standard residential (99.5% availability) |
Decomposes into RFS based on access technology at the customer's address. In this example: GPON technology.
Layer 4: Resource-Facing Services
The three CFS instances decompose into a set of RFS instances. This is where technology-specific detail appears:
RFS Decomposition
| Parent CFS | RFS | Purpose |
|---|---|---|
| Internet Access | RFS:GPON-Bearer | Configures the GPON connection (bearer channel, bandwidth profile) |
| Internet Access | RFS:VLAN-Service | Assigns and configures customer VLAN on the access network |
| Internet Access | RFS:IP-Profile | Configures DHCP, IPv4/IPv6 addressing, DNS delegation |
| Internet Access | RFS:QoS-Profile | Applies bandwidth policy (200/50 Mbps shaping) |
| WiFi Management | RFS:Cloud-Controller-Link | Registers CPE with cloud WiFi management platform |
| CPE Management | RFS:TR069-Config | Sets up TR-069 auto-configuration server (ACS) profile for the ONT |
| CPE Management | RFS:CPE-Provisioning | Pre-provisions ONT with customer config (SSID, password, LAN settings) |
Layer 5: Resources
Finally, each RFS requires specific physical or logical resources to be allocated from inventory:
Resource Allocation
| RFS | Resource | Type | Allocated Value |
|---|---|---|---|
| GPON-Bearer | OLT Port | Physical | OLT-EAST-07, Slot 3, Port 12 |
| GPON-Bearer | ONT Device | Physical | Huawei HG8245H, S/N: HWT2340098 |
| VLAN-Service | VLAN ID | Logical | VLAN 1042 (from range 1000-1999) |
| IP-Profile | IPv4 Address | Logical | 10.42.17.22 (from DHCP pool) |
| IP-Profile | IPv6 Prefix | Logical | 2001:db8:42:17::/64 |
| QoS-Profile | Bandwidth Policy | Logical | Policy ID: BW-200-50-RES |
| TR069-Config | ACS Endpoint | Logical | acs.example.com/device/HWT2340098 |
The Complete Picture
Stepping back, here is what happened when the customer clicked "Order Now" on "SuperFibre 200 Home":
End-to-End Fulfilment Flow
Commercial Order Captured
BSSCOM creates a Product Order for "SuperFibre 200 Home" with selected options (router model, no static IP). Product Inventory creates a pending Product Instance.
Product → CFS Decomposition
BSS → OSSThe catalog maps the Product Specification to 3 CFS types. SOM creates Service Orders for Internet Access, WiFi Management, and CPE Management.
CFS → RFS Decomposition
OSS — SOMThe service catalog decomposes each CFS into RFS. Access technology = GPON determines the specific RFS set. 7 RFS instances are created.
Resource Allocation
OSS — ROMROM allocates resources from inventory: OLT port, VLAN, IP addresses, bandwidth policy. Each resource is reserved for this service.
Network Activation
OSS — NetworkROM drives configuration to the network: OLT port configured, VLAN created, DHCP updated, QoS policy applied, ONT configured via TR-069.
Service Activation Complete
OSS → BSSService Inventory marks all CFS instances as Active. Product Inventory marks the Product Instance as Active. Customer receives confirmation.
When Things Go Wrong: Failure Scenarios
The happy path above shows how the chain works when everything succeeds. In production, failures occur at every layer. A catalog-driven architecture handles these failures systematically because the decomposition chain is modelled and traceable — the system knows exactly what was requested, what succeeded, and what needs to be compensated.
Failure Scenarios and Recovery
| Failure Point | What Happens | System Response | Recovery Action |
|---|---|---|---|
| OLT Port unavailable | ROM attempts to allocate a GPON port on OLT-EAST-07, but all ports on the nearest OLT are in use. | ROM returns a resource allocation failure to SOM. The RFS:GPON-Bearer order item fails. SOM marks the CFS:Internet-Access as blocked. | ROM queries Resource Inventory for alternative OLTs in the same serving area. If an alternative exists, ROM re-attempts allocation. If none available, SOM raises a capacity exception — the order is suspended pending network build. |
| VLAN pool exhausted | The VLAN range (1000-1999) for this access node is fully allocated. RFS:VLAN-Service cannot be provisioned. | ROM returns allocation failure. SOM holds dependent RFS items (IP-Profile, QoS-Profile depend on VLAN assignment). | Network planning is notified to extend the VLAN range or re-architect the access layer. The order remains in a "waiting for resource" state with full traceability to the blocking constraint. |
| Partial activation — Steps 1-4 succeed, Step 5 fails | OLT port configured, VLAN assigned, IP allocated, QoS applied — but TR-069 configuration of the ONT fails (device not reachable). | ROM reports partial success. SOM identifies which RFS succeeded and which failed. Service Inventory records partial activation state. | SOM triggers a compensating action: retry TR-069 configuration (the ONT may not be powered on yet). After N retries, SOM can hold the order for technician dispatch. Critically, the already-allocated resources (port, VLAN, IP) are reserved, not released — they belong to this service instance. |
| Commercial order cancelled after decomposition | Customer cancels the order after SOM has created service orders and ROM has allocated resources, but before network activation completes. | COM sends a cancellation to SOM. SOM triggers compensating service orders (cancel each CFS). ROM releases allocated resources back to their pools. | Each layer reverses its work in the correct dependency order: release resources → cancel RFS → cancel CFS → cancel Product Instance. The catalog-driven decomposition chain provides the exact reversal sequence. |
Modification Path: Speed Upgrade
What happens when this customer upgrades from SuperFibre 200 to SuperFibre 500? In a catalog-driven architecture, the system calculates the delta between the current state and the target state, and only modifies what needs to change.
Upgrade Impact Analysis: 200 Mbps → 500 Mbps
| Layer | Entity | Change Required? | Action |
|---|---|---|---|
| Product Offering | SuperFibre 200 Home → SuperFibre 500 Home | Yes | Product Inventory updates the product instance to reference the new offering. Pricing changes from $89 to $119/month. |
| Product Specification | Residential Broadband Access | No — same spec | The specification is unchanged. Only the downloadSpeed characteristic value changes from 200 to 500. |
| CFS: Internet Access | Speed characteristic | Yes — characteristic update | SOM issues a modify service order for the existing CFS instance. Download speed updated from 200 to 500 Mbps. |
| CFS: WiFi Management | No change | No | WiFi management is unaffected by a speed change. No service order generated. |
| CFS: CPE Management | No change | No | The same ONT supports 500 Mbps. No hardware swap needed. No service order generated. |
| RFS: QoS-Profile | Bandwidth policy | Yes — policy update | ROM issues a modify resource order. Bandwidth policy updated from BW-200-50-RES to BW-500-125-RES. |
| RFS: GPON-Bearer | Bearer configuration | Possibly | If the bearer profile needs adjustment for higher speeds, ROM modifies the bearer. If the existing bearer already supports 500 Mbps, no change needed. |
| RFS: VLAN, IP, TR069, Cloud-Controller | No change | No | These resources are unaffected by a speed upgrade. The customer keeps the same VLAN, IP address, and device management. |
The catalog-driven system identified that a speed upgrade only requires changes to 2 out of 7 RFS and 1 out of 3 CFS. The OLT port, VLAN, IP address, ONT device, and cloud controller link are all unchanged. This precision is impossible without a modelled decomposition chain — in a legacy system, a speed upgrade might trigger a full re-provision, disrupting the customer's service unnecessarily.
Key Takeaways
- A single product offering ("SuperFibre 200 Home") decomposes into 3 CFS, 7 RFS, and 7+ resources
- Each layer adds more technical specificity while the layer above stays technology-neutral
- The catalog defines all decomposition rules — fulfilment systems execute them at order time
- Resource allocation (finding free ports, VLANs, IPs) happens at the bottom of the chain
- The full chain is traceable: any resource can be traced back to the product that requires it
- Failure handling is systematic — the decomposition chain provides exact rollback sequencing and resource compensation
- Modifications use delta analysis: only entities that actually change are updated, minimising disruption and cost
- This traceability is essential for impact analysis, troubleshooting, and lifecycle management