Service Inventory
Service Inventory: The OSS Runtime View
Service Inventory is the OSS-side source of truth for all instantiated services. It tracks every Customer-Facing Service (CFS) and Resource-Facing Service (RFS) instance, recording what has been provisioned, its current state, and how it links to both the commercial product above and the network resources below.
If Product Inventory answers "what did the customer buy?", Service Inventory answers "what services are running to deliver what they bought?" This is a critical distinction — the commercial product and the technical service are different entities owned by different domains, and they can (and do) get out of sync.
Relationship Between Product and Service Inventory
Every CFS instance in Service Inventory is linked to a product instance in Product Inventory. This cross-domain reference is what connects the commercial world to the technical world. The product instance says "Customer X has Broadband 200Mbps." The CFS instance says "Internet Access service is active with 200Mbps bandwidth configured."
Product Inventory vs Service Inventory
| Aspect | Product Inventory | Service Inventory |
|---|---|---|
| Domain | BSS (Commercial) | OSS (Technical) |
| Audience | Customer, Sales, Billing | Network Operations, Service Assurance |
| Entity tracked | Product Instance (subscription) | Service Instance (CFS / RFS) |
| Characteristics | Commercial: price, contract, discounts | Technical: bandwidth, QoS, VLAN, IP config |
| Lifecycle driven by | Commercial order lifecycle | Service order lifecycle |
| Source of Record for | What the customer is paying for | What is technically deployed and running |
| TMF API | TMF637 | TMF638 |
CFS (Customer-Facing Service) Instance
A CFS instance represents a specific, instantiated customer-facing service. It is the runtime occurrence of a CFS specification from the Service Catalog. While the specification defines the template (e.g., "Internet Access service with configurable speed"), the instance holds the actual values for a specific customer deployment.
CFS Instance Data Elements
| Element | Description | Example |
|---|---|---|
| Instance ID | Unique identifier | SI-CFS-IA-88421 |
| Service Spec Reference | Link to CFS specification in Service Catalog | SS-CFS-INTERNET-ACCESS-v3 |
| Product Instance Reference | Link to product instance in Product Inventory | PI-88421 |
| State | Current lifecycle state | Active |
| Service Characteristics | Technical parameters | downloadSpeed=200Mbps, uploadSpeed=20Mbps |
| Service Date | When the service was activated | 2024-06-01T14:30:00Z |
| Place Reference | Location where service is delivered | ADDRESS-1234 (123 Main St, Apt 4B) |
| Related Services | Links to child RFS instances and sibling CFS instances | RFS:GPON-Bearer, RFS:VLAN-Service, RFS:IP-Profile |
| Supporting Resources | References to resource instances | OLT-EAST-07:Port3, VLAN-1042 |
RFS (Resource-Facing Service) Instance
An RFS instance represents a technology-specific service component that has been instantiated to deliver part of a CFS. While a CFS describes what service the customer gets, RFS instances describe how it is technically implemented. Each RFS instance maps to specific resource allocations and configurations.
RFS instances are particularly important for change management. When a customer upgrades their speed, the CFS instance speed characteristic changes, but only specific RFS instances need modification. The QoS-Profile RFS instance gets updated bandwidth values, while the GPON-Bearer and VLAN-Service RFS instances may remain unchanged.
Service Instance Lifecycle States
Service instances follow their own lifecycle that parallels — but is not identical to — the product instance lifecycle. The service lifecycle includes states specific to the technical domain.
Service Instance Lifecycle States
| State | Description | Typical Trigger |
|---|---|---|
| Feasibility Checked | Service has been validated as technically feasible at the given location | Service qualification check completed |
| Designed | Service has been designed with specific technical parameters but not yet reserved | Service order decomposition completed |
| Reserved | Required resources have been reserved but not yet configured | Resource allocation successful |
| Active | Service is fully provisioned, activated, and operational | Activation confirmation received from network |
| Inactive | Service exists but is not currently delivering (suspended) | Suspension order completed |
| Terminated | Service has been permanently deactivated and resources released | Disconnect order completed |
Service Qualification and Feasibility
Before a service can be ordered, the operator must determine whether it is technically feasible to deliver the service at the requested location. Service qualification checks Service and Resource Inventory to answer: "Can we provide this service here, and what options are available?"
Service Qualification Flow
Address Validation
Address ManagementValidate that the requested address exists in the address management system and is within the operator's service footprint.
Network Reachability Check
Resource Inventory / GISDetermine which network infrastructure (exchange, OLT, cabinet, node) serves the requested address.
Capacity Check
Resource InventoryCheck whether there is available capacity on the serving infrastructure (free ports, available bandwidth, IP addresses).
Existing Service Check
Service InventoryCheck Service Inventory for any existing services at the address that might conflict or could be reused.
Technology Determination
Service Qualification EngineBased on available infrastructure, determine which access technology (GPON, DOCSIS, FWA) and speed tiers are feasible.
Qualification Response
Service Qualification EngineReturn the list of feasible services, available speed tiers, estimated lead time, and any caveats (e.g., requires new cable pull).
Service Inventory and Service Assurance
Service Inventory is a critical input to service assurance processes. When a customer reports a problem, the assurance system needs to know: what services are active for this customer, what are the expected parameters (SLA), and what resources underpin those services?
When a network alarm fires (e.g., OLT port down), the fault management system queries Service Inventory to determine which services are affected. Service Inventory provides the mapping from resource to RFS to CFS, enabling automatic service impact analysis.
- Resource alarm triggers a lookup in Service Inventory
- All RFS instances using the affected resource are identified
- Parent CFS instances are identified through the RFS-CFS relationship
- Product Inventory is queried to identify affected customers
- Proactive customer notification can be triggered automatically
TMF638 Service Inventory Management API
TMF638 Key Operations
| Operation | Method | Purpose | Example |
|---|---|---|---|
| List Services | GET /service | Retrieve service instances with filtering | GET /service?relatedParty.id=CUST-42817&state=active |
| Get Service | GET /service/{id} | Retrieve a specific service instance with full details | GET /service/SI-CFS-IA-88421 |
| Create Service | POST /service | Create a new service instance (by SOM during fulfilment) | POST with service spec ref, characteristics, place |
| Update Service | PATCH /service/{id} | Modify characteristics or state | PATCH with updated bandwidth characteristics |
| Delete Service | DELETE /service/{id} | Remove a service instance | Typically state change to terminated preferred |
Service Inventory Data Model Considerations
Service Inventory is like a technician's work order record. It tracks every service that has been set up, what technology was used, and where it connects to. If the customer's Product Inventory is their "bill of purchased items," Service Inventory is the "installation record" showing exactly how each service was technically delivered.
The Service Inventory data model must capture several types of relationships:
- Service-to-Product: Each CFS instance links to its parent product instance (upward reference)
- CFS-to-RFS: A CFS instance contains or references its child RFS instances (decomposition)
- RFS-to-Resource: Each RFS instance references the specific resources it uses (downward reference)
- Service-to-Place: Services are delivered at a specific location (address, site, service point)
- Service-to-Service: Sibling relationships between CFS instances within a bundle
- Service-to-Party: Which customer or organization the service belongs to
In practice, Service Inventory often implements a graph-like data model because service instances have complex, multi-dimensional relationships. A single CFS instance might relate to multiple RFS instances, which share resources with other RFS instances belonging to different CFS instances. This creates a web of dependencies that simple hierarchical models cannot capture.
Advanced implementations support: (1) Topology views — showing how service instances map to network topology; (2) Impact graphs — pre-computed relationship graphs for fast fault correlation; (3) Temporal queries — "what was the service configuration at time T?"; (4) Multi-tenancy — separating service instances by customer while allowing shared infrastructure visibility for operations teams.
Service Inventory Architecture Patterns
Centralized vs Federated Service Inventory
Large operators often debate whether to centralize Service Inventory into one system or federate it across domain-specific inventories (fixed, mobile, transport). Each approach has trade-offs.
Centralized vs Federated Service Inventory
| Aspect | Centralized | Federated |
|---|---|---|
| Cross-domain visibility | Native — single system holds all services | Requires integration/aggregation layer |
| Scalability | Can become a bottleneck at scale | Each domain scales independently |
| Domain autonomy | Low — all domains share one model | High — each domain owns its model |
| Consistency | Strong — single source of truth | Eventual — requires synchronization |
| Fault correlation | Fast — direct queries across all services | Slower — must aggregate across inventories |
| Implementation cost | High upfront, lower ongoing | Lower upfront, higher integration cost |
Service Inventory Source of Record
Service Inventory SoR Mapping
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| CFS Instance | Service Inventory | SOM (creates/modifies via service orders) | Product Inventory, Assurance, CRM | Authoritative for what customer-facing services are running. |
| RFS Instance | Service Inventory | SOM / Activation engine | Resource Inventory, Network Operations | Authoritative for technology-specific service configuration. |
| Service State | Service Inventory | SOM (orchestrates state transitions) | Assurance (monitors), Product Inventory (reflects) | Activation confirmation sets Active. Suspension sets Inactive. |
| Service Characteristics | Service Inventory | SOM / Activation (configures values) | Assurance (SLA targets), CRM (customer view) | Technical parameters like bandwidth, QoS, VLAN assignments. |
Section 4.3 Key Takeaways
- Service Inventory tracks instantiated CFS and RFS instances — the technical runtime of deployed services
- CFS instances link upward to Product Inventory and downward (via RFS) to Resource Inventory, enabling full traceability
- Service qualification checks feasibility BEFORE ordering by querying Service and Resource Inventory
- Service Inventory is critical for service assurance: fault correlation, SLA monitoring, and root cause analysis
- TMF638 provides standardized CRUD and event notification for service instances
- CFS instances hold customer-visible service parameters; RFS instances hold technology-specific configurations
- Service Inventory can be centralized or federated — the choice impacts cross-domain correlation and scalability