Glossary

A billing or service entity that groups one or more subscriptions under a single customer relationship. Accounts hold financial responsibility and are the anchor for invoicing, payments, and credit management.

The process of making a service or resource operationally live on the network. Activation translates logical service parameters into device-level configuration commands sent to network elements.

A design pattern that introduces a translation boundary between two systems or bounded contexts with different domain models. In telco, it prevents legacy system data models from leaking into modern catalog-driven services.

A single entry point that routes, authenticates, and rate-limits all inbound API traffic before it reaches backend microservices. In ODA deployments, the API gateway maps external consumers to internal TMF Open API endpoints.

The eTOM process area responsible for monitoring, diagnosing, and resolving issues with services and resources. Assurance encompasses fault management, performance management, and SLA compliance tracking.

Business-to-Business: the commercial model where a telecom operator sells services to enterprise customers rather than individual consumers. B2B ordering involves complex quoting, multi-site fulfilment, SLA-backed contracts, and partner/wholesale relationships.

Business-to-Consumer: the commercial model where a telecom operator sells services directly to individual end-users. B2C flows prioritise self-service, fast fulfilment, and simple product bundles.

An architectural pattern where a dedicated backend service is built for each frontend channel (web portal, mobile app, agent desktop). Each BFF aggregates and shapes data from multiple downstream APIs to match its channel's specific needs.

The BSS function that generates invoices based on rated usage events and recurring charges. Billing aggregates charges at the account level, applies discounts and taxes, and produces customer-facing bills.

The suite of systems managing the commercial side of a telecom operator: customer relationships, product catalogs, orders, billing, and revenue. BSS is the source of truth for what the customer bought and what they owe.

A design philosophy where product, service, and resource catalogs are the single source of truth for what can be sold, delivered, and managed. All downstream systems (ordering, fulfilment, billing) derive their behaviour from catalog definitions rather than hard-coded logic.

The real-time or near-real-time process of rating usage events (e.g. voice minutes, data consumption) against a pricing plan and applying charges to a customer's balance. Distinct from billing, which aggregates charges into invoices.

A network function implemented as containerised microservices running on Kubernetes or a similar container orchestration platform. CNFs are the cloud-native evolution of VNFs, designed for horizontal scaling and rolling upgrades.

The BSS capability that captures, validates, and manages customer-facing orders. COM decomposes a commercial order into the product actions required, then delegates technical fulfilment to SOM. It is the source of record for order intent.

An individual person associated with a customer or account. Contacts hold communication preferences, roles, and authorisation levels (e.g. billing contact, technical contact, authorised signatory).

Configure, Price, Quote: a BSS capability that allows sales teams or self-service channels to configure a product bundle, calculate pricing, and generate a formal quote. CPQ enforces catalog rules (compatibility, eligibility, pricing tiers) before an order is placed.

Command Query Responsibility Segregation: a pattern that separates read and write models into distinct paths. In telco, CQRS is often used in inventory systems where high-throughput order writes and complex search queries have very different performance profiles.

Customer Relationship Management: the BSS system that manages customer identities, interactions, and engagement history. CRM is typically the system of record for customer and account master data.

A party (individual or organisation) that has a commercial relationship with the operator. The customer entity is the root of the BSS data model and links to accounts, subscriptions, orders, and trouble tickets.

A service defined from the customer's perspective (e.g. "Broadband 100 Mbps", "Mobile Voice"). A CFS maps to one or more Resource-Facing Services and is the bridge between what the customer buys (product) and what the network delivers.

Day-0 covers initial planning and design of a network function. Day-1 covers deployment, instantiation, and initial configuration. Day-2 covers ongoing lifecycle management including scaling, healing, monitoring, and upgrades.

An order that expresses only the differences (additions, removals, changes) relative to the current state of a subscription, rather than restating the entire subscription. Delta ordering simplifies MACD flows but requires robust baseline tracking in product inventory.

A pricing adjustment that reduces the standard price of a product offering. Discounts can be percentage-based, fixed-amount, or volume-tiered, and are typically managed in the product catalog alongside price rules.

BSS capabilities specifically tailored for B2B and enterprise customers, including complex quoting (CPQ), hierarchical account structures, SLA-driven pricing, multi-site ordering, and partner/wholesale management.

The enhanced Telecom Operations Map, TM Forum's process framework that defines the full set of business processes a telecom operator needs. eTOM is organised in levels (L0-L4) across Strategy, Operations, and Enterprise Management domains.

An asynchronous message published when a state change occurs in a system (e.g. order status changed, inventory item created). TMF Open APIs define standard notification payloads using a publish/subscribe or webhook model.

An architectural style where systems communicate by producing and consuming asynchronous events rather than synchronous request/response calls. In telco, event-driven patterns decouple order management, inventory, and activation systems.

The OSS discipline responsible for detecting, isolating, and correcting faults in network resources and services. Fault management processes alarms, correlates events, and drives trouble ticket creation.

The end-to-end eTOM process area covering everything from order capture to service activation. Fulfilment spans COM, SOM, and ROM and ensures the customer receives what they ordered.

The eTOM end-to-end business flow from initial customer engagement through to revenue collection. It encompasses marketing, selling, ordering, fulfilment, billing, and payment across BSS and OSS systems.

Move, Add, Change, Disconnect: the four fundamental lifecycle operations on an existing subscription. MACD orders modify the product inventory baseline and trigger downstream service and resource changes.

Management and Orchestration: the ETSI NFV framework for lifecycle management of virtualised network functions. MANO comprises three functional blocks: NFVO (orchestrator), VNFM (VNF manager), and VIM (virtualised infrastructure manager).

An architectural style where an application is structured as a collection of small, independently deployable services, each owning its own data and communicating via APIs or events. Microservices are the target architecture for ODA components.

A software architecture where all functionality is deployed as a single, tightly coupled unit. Many legacy BSS/OSS platforms are monolithic, making them difficult to scale, extend, and integrate independently.

The ability to place a single B2B order that provisions services across multiple geographic locations for an enterprise customer. Multi-site orders require coordination of site surveys, access availability, and per-site fulfilment timelines.

Mobile Virtual Network Operator: a company that provides mobile services to end-users without owning radio network infrastructure, instead leasing capacity from a host MNO. MVNOs require BSS capabilities for retail operations and wholesale settlement with the host.

A physical or virtual device in the network (e.g. router, switch, OLT, base station) that is individually managed and appears in the resource inventory. Network elements are the lowest level of the resource domain hierarchy.

The totality of hardware and software components that form the environment in which VNFs are deployed. NFVI includes compute, storage, and networking resources managed by the VIM layer of MANO.

A service orchestration platform (notably Cisco NSO) that automates network service delivery by abstracting device-level configuration into service models. NSO sits between SOM and network elements, translating service intent into device commands via YANG/NETCONF.

The MANO component responsible for orchestrating the lifecycle of network services and coordinating VNF instantiation across the infrastructure. NFVO manages network service descriptors and delegates VNF-level operations to the VNFM.

The runtime execution environment defined by TM Forum's ODA that hosts ODA Components. The Canvas provides common infrastructure services such as identity management, API exposure, event handling, and observability so that components can focus on business logic.

A self-contained, independently deployable software unit that implements a specific business capability within TM Forum's ODA. Each component exposes and consumes TMF Open APIs and declares its functional scope via a Component Descriptor.

A standardised REST API specification published by TM Forum that enables interoperability between BSS/OSS components. Each Open API covers a specific domain (catalog, ordering, inventory, etc.) with well-defined resources, operations, and notification events.

TM Forum's reference architecture blueprint for modular, cloud-native telecom IT systems. ODA defines standardised components, APIs, and a runtime canvas that together replace monolithic BSS/OSS stacks with interoperable, vendor-neutral building blocks.

The suite of systems managing the technical and network side of a telecom operator: service design, fulfilment, inventory, activation, assurance, and network management. OSS is the source of truth for what is running on the network.

The sub-process within fulfilment that covers the journey from a validated order to a live, activated service. It spans commercial order decomposition (COM), service orchestration (SOM), and resource provisioning (ROM).

The BSS capability for managing commercial relationships with third-party partners, including MVNOs, resellers, content providers, and wholesale carriers. It covers partner onboarding, agreement management, settlement, and revenue sharing.

The OSS discipline focused on collecting, analysing, and reporting on network and service performance metrics (throughput, latency, error rates). Performance data feeds into assurance processes and SLA compliance monitoring.

A network function implemented on dedicated, purpose-built hardware (e.g. a physical router or firewall appliance). PNFs are managed alongside VNFs and CNFs in hybrid environments but are not orchestrated by MANO's VIM/VNFM.

A monetary value or pricing structure attached to a product offering. Prices can be one-time, recurring, or usage-based and are defined in the product catalog. Pricing rules determine how base prices are modified by discounts, promotions, and contract terms.

The BSS repository that defines all sellable products (product offerings) and their specifications, pricing, eligibility rules, and relationships. The product catalog is the commercial source of truth in a catalog-driven architecture.

The BSS repository that records what each customer has actually purchased and currently holds (active subscriptions, installed products). Product inventory is the runtime counterpart of the product catalog and the source of record for the customer's installed base.

A marketable, sellable entity in the product catalog that combines a product specification with commercial terms (pricing, eligibility, promotions, channels). A product offering is what a customer sees and buys.

A technical blueprint that defines the structure, characteristics, and valid values of a product, independent of commercial terms. Multiple product offerings can reference the same specification, enabling catalog reuse.

The process of allocating and configuring resources (ports, IP addresses, VLANs, network functions) to support a service. Provisioning is the resource-level counterpart of activation and is typically handled by ROM or a resource activation system.

A formal proposal presented to a customer that details the products, prices, terms, and conditions of a potential order. Quotes are generated by CPQ, may undergo approval workflows, and convert into orders upon customer acceptance.

The eTOM process flow that handles customer-initiated modifications to existing services or subscriptions. It covers change requests, impact assessment, approval, and fulfilment of modifications (adds, changes, moves).

The OSS repository that defines all available resource types (physical devices, virtual functions, logical resources) and their specifications. The resource catalog drives what can be provisioned on the network.

The OSS repository that records the current state of all network resources: physical devices, virtual functions, logical resources, ports, and links. It is the source of truth for what exists on the network.

The OSS capability that receives resource-level orders from SOM and orchestrates the allocation, configuration, and activation of physical and virtual resources. ROM is the lowest orchestration layer before direct device interaction.

A definition in the resource catalog that describes the type, characteristics, and capabilities of a resource (e.g. a specific router model, a virtual firewall template, a VLAN). Resource specifications are referenced by RFS definitions.

A service defined from the network/resource perspective that represents a technical capability delivered by one or more resources. An RFS bridges the gap between the customer-facing service (CFS) and the physical or virtual resources that provide it.

Representational State Transfer: the architectural style underpinning all TMF Open APIs. RESTful APIs use standard HTTP methods (GET, POST, PATCH, DELETE) on resource-oriented URLs, with JSON payloads and standardised error handling.

The end-to-end BSS domain covering charging, billing, collections, and revenue assurance. Revenue management ensures that all services consumed are accurately rated, billed, collected, and reconciled.

A commercial arrangement where revenue from jointly delivered services is split between partners according to agreed terms. Revenue sharing requires settlement engines that can calculate, reconcile, and report partner shares.

A distributed transaction pattern that manages data consistency across multiple microservices using a sequence of local transactions with compensating actions. In telco ordering, sagas coordinate COM, SOM, and ROM steps with rollback capabilities.

The OSS repository that defines all available service types (CFS and RFS specifications) and their decomposition rules. The service catalog bridges product catalog entries to resource-level implementations.

The OSS repository that records all active service instances and their current state. Service inventory tracks which CFS and RFS instances are running, their parameters, and their relationships to product and resource instances.

A contractual commitment specifying measurable service quality targets (uptime, latency, response time) and the remedies or penalties if those targets are not met. SLAs are central to B2B and enterprise service delivery.

The OSS capability that receives service-level orders from COM and orchestrates their decomposition into resource-level tasks. SOM translates product actions into CFS/RFS operations and coordinates with ROM for resource provisioning.

A transient BSS entity that holds a customer's selected product offerings before order submission. The shopping cart enforces catalog rules, calculates prices, and converts into a formal order upon checkout.

Shared Information/Data Model: TM Forum's canonical data model that defines the entities, attributes, and relationships used across BSS and OSS. SID provides a common vocabulary so that different systems can exchange data unambiguously.

The authoritative system that owns and masters a given piece of data. All other systems consuming that data must defer to the SoR. For example, CRM is typically the SoR for customer data, while product inventory is the SoR for installed products.

A migration pattern that gradually replaces a legacy system by incrementally routing traffic to a new implementation, one capability at a time, until the legacy system can be decommissioned. Named after the strangler fig tree that slowly envelops its host.

The BSS capability that manages the end-to-end lifecycle of a customer's subscriptions: from initial activation through modifications (MACD) to eventual termination. It maintains the product inventory baseline.

A system optimised for user interaction and experience rather than data mastery. SoE systems (e.g. self-service portals, agent desktops) consume data from the SoR and provide rich UX, but do not own the authoritative copy of the data.

A system that provides read-only, aggregated, or derived views of data sourced from one or more SoRs. Reporting platforms, data warehouses, and analytics tools are typical systems of reference.

A global industry association that produces standards, frameworks, and best practices for the telecommunications industry, including eTOM, SID, ODA, and the TMF Open API suite.

The standardised notification mechanism defined by TM Forum for asynchronous communication between components. It uses a hub/listener model where consumers register for specific event types and receive callbacks when state changes occur.

The TMF Open API for managing the product catalog, including product offerings, product specifications, categories, and their relationships. TMF620 is the foundation API for any catalog-driven BSS.

The TMF Open API for creating, updating, and tracking trouble tickets. It supports the full lifecycle of issue management, from initial report through diagnosis, resolution, and closure.

The TMF Open API for managing product orders throughout their lifecycle. TMF622 defines the structure for order items, order actions (add, modify, delete), and order state transitions from acknowledged to completed.

The TMF Open API for managing service level agreements, including SLA templates, SLA instances, and SLA violation tracking. It supports the contractual assurance process for enterprise services.

The TMF Open API for managing individuals and organisations (parties). TMF632 covers party creation, role assignment, and contact management, serving as the foundation for customer and partner data.

The TMF Open API for managing the service catalog, including service specifications (CFS and RFS), service categories, and candidate relationships. TMF633 defines the service design-time model.

The TMF Open API for managing the resource catalog, including resource specifications, categories, and candidate relationships. TMF634 defines the resource design-time model for physical, logical, and virtual resources.

The TMF Open API for managing the product inventory, which holds all active and historical product instances owned by customers. TMF637 tracks the customer's installed base and subscription state.

The TMF Open API for managing the service inventory, which records all active service instances (CFS and RFS) and their parameters, relationships, and state.

The TMF Open API for managing the resource inventory, which records all physical, logical, and virtual resource instances, their attributes, and interconnections.

The TMF Open API for activating, configuring, and deactivating services on the network. TMF640 provides a standardised interface between SOM/ROM and the activation layer.

The TMF Open API for managing service orders throughout their lifecycle. TMF641 defines the structure for service order items, actions, and state transitions, bridging commercial orders (TMF622) to resource-level fulfilment.

The TMF Open API for checking service availability and feasibility at a given location or for a given customer. TMF645 is used during the pre-order phase to confirm that requested services can actually be delivered.

The TMF Open API for managing the quotation lifecycle: creation, pricing calculation, negotiation, approval, and acceptance. TMF648 supports both simple consumer quotes and complex multi-site enterprise proposals.

The TMF Open API for managing resource orders that instruct the network to allocate, configure, or release resources. TMF652 is the interface between SOM/ROM and resource management systems.

The TMF Open API for managing service problems that are identified through alarm correlation, performance degradation, or customer-reported issues. TMF656 links faults to impacted services and drives resolution workflows.

The TMF Open API for defining and monitoring service quality objectives and thresholds. TMF657 supports SLA compliance tracking by comparing actual service performance against agreed targets.

The TMF Open API for managing customer accounts, including billing accounts, financial accounts, and settlement accounts. TMF666 covers account creation, hierarchies, and account-level contact and payment method management.

The TMF Open API for managing geographic sites and locations. TMF674 is used in address validation, site surveys, and multi-site ordering to ensure services are linked to verified physical locations.

The TMF Open API for managing customer bills and invoices. TMF678 supports bill retrieval, applied payments, bill dispute handling, and integration with downstream revenue management systems.

The TMF Open API for determining whether a specific product offering can be sold to a customer at a given location or context. TMF679 checks eligibility rules, availability constraints, and technical feasibility before quoting.

The eTOM end-to-end business flow from issue detection or customer complaint through to resolution and closure. It encompasses fault management, diagnostics, field dispatch, resolution, and root-cause analysis.

Virtualised Infrastructure Manager: the MANO component that manages compute, storage, and networking resources in the NFVI. VIM allocates virtual resources to VNFs and monitors infrastructure utilisation. OpenStack is a common VIM implementation.

A network function (e.g. firewall, router, load balancer) implemented as software running on virtualised infrastructure rather than on dedicated hardware. VNFs are deployed and managed through the MANO framework.

The MANO component responsible for the lifecycle management of individual VNF instances: instantiation, scaling, healing, and termination. VNFM operates under the coordination of the NFVO.

A commercial model where a telecom operator sells network capacity, connectivity, or service components to other operators or service providers rather than directly to end-users. Wholesale requires dedicated BSS capabilities for inter-carrier settlement and capacity management.