Pages
More Information

One entity chain across BSS and OSS

From party to bill, with the service, the resource and the promise in between

Every loop that crosses from network to customer walks the same chain of entities, and in Exosphere Agentic that chain is modelled once. Exosphere Agentic runs on Azure and integrates with the Microsoft AI platform, deployed into the customer's own tenant — so context, data and governance stay where they belong.

Updated

One chain, from party to bill

The questions that matter most cross domains. Which customers ride on this resource? What did we promise them? What will appear on their next bill? Each answer is a walk along one chain of SID entities, and every hop already has a TM Forum Open API.

The telecom ontology for BSS and OSS makes that chain explicit: one identity per entity across every API, typed relationships between them, and the standards anchor for each hop. The customer-facing service is the join where BSS meets OSS. With the chain modelled, that join is a path, not a report.

Cross-domain entity chain with API and ODA anchors

erDiagram
    PARTY ||--o{ CUSTOMER : "plays role"
    PARTY }|--o{ AGREEMENT : "party to"
    CUSTOMER ||--o{ BILLING_ACCOUNT : "holds"
    CUSTOMER ||--o{ PRODUCT_ORDER : "places"
    PRODUCT_ORDER ||--|{ PRODUCT_ORDER_ITEM : "contains"
    PRODUCT_ORDER_ITEM }o--|| PRODUCT_OFFERING : "references"
    PRODUCT_OFFERING }o--|| PRODUCT_SPECIFICATION : "specified by"
    PRODUCT_SPECIFICATION }o--o{ SERVICE_SPECIFICATION : "requires"
    PRODUCT_SPECIFICATION }o--o{ RESOURCE_SPECIFICATION : "requires"
    PRODUCT_ORDER ||--o{ SERVICE_ORDER : "decomposed into"
    SERVICE_ORDER ||--o{ RESOURCE_ORDER : "triggers"
    CUSTOMER ||--o{ PRODUCT : "owns"
    PRODUCT }o--|| PRODUCT_OFFERING : "instance of"
    PRODUCT }o--o{ CFS : "realized by"
    PRODUCT }o--o{ RESOURCE : "realized by"
    CFS }o--o{ RFS : "supported by"
    RFS }o--o{ RESOURCE : "realized by"
    SERVICE_SPECIFICATION ||--o{ CFS : "specifies"
    RESOURCE_SPECIFICATION ||--o{ RESOURCE : "specifies"
    RESOURCE ||--o{ ALARM : "raises"
    ALARM }o--o{ SERVICE_PROBLEM : "underlies"
    SERVICE_PROBLEM }o--o{ CFS : "affects"
    SERVICE_PROBLEM }o--o{ RESOURCE : "affected resource"
    TROUBLE_TICKET }o--o{ SERVICE_PROBLEM : "informs"
    PRODUCT ||--o{ PRODUCT_USAGE : "generates"
    PRODUCT_USAGE }o--o| APPLIED_BILLING_RATE : "rated as"
    APPLIED_BILLING_RATE }o--|| CUSTOMER_BILL : "appears on"
    BILLING_ACCOUNT ||--o{ CUSTOMER_BILL : "receives"
    AGREEMENT ||--o{ SERVICE_LEVEL_SPEC : "commits via"
    SERVICE_LEVEL_SPEC ||--|{ SERVICE_LEVEL_OBJECTIVE : "groups"
    SERVICE_LEVEL_OBJECTIVE }o--o{ CFS : "measured on"
    PARTY {
        string api "TMF632"
        string oda "TMFC028"
    }
    CUSTOMER {
        string api "TMF629"
    }
    BILLING_ACCOUNT {
        string api "TMF666"
        string oda "TMFC024"
    }
    PRODUCT_OFFERING {
        string api "TMF620"
        string oda "TMFC001"
    }
    PRODUCT_SPECIFICATION {
        string api "TMF620"
        string oda "TMFC001"
    }
    PRODUCT_ORDER {
        string api "TMF622"
        string oda "TMFC002"
    }
    PRODUCT_ORDER_ITEM {
        string api "TMF622"
    }
    PRODUCT {
        string api "TMF637"
        string oda "TMFC005"
    }
    SERVICE_SPECIFICATION {
        string api "TMF633"
        string oda "TMFC006"
    }
    SERVICE_ORDER {
        string api "TMF641"
        string oda "TMFC007"
    }
    CFS {
        string api "TMF638"
        string oda "TMFC008"
    }
    RFS {
        string api "TMF638"
        string oda "TMFC008"
    }
    RESOURCE_SPECIFICATION {
        string api "TMF634"
        string oda "TMFC010"
    }
    RESOURCE_ORDER {
        string api "TMF652"
        string oda "TMFC011"
    }
    RESOURCE {
        string api "TMF639"
        string oda "TMFC012"
    }
    ALARM {
        string api "TMF642"
        string oda "TMFC043"
    }
    SERVICE_PROBLEM {
        string api "TMF656"
    }
    TROUBLE_TICKET {
        string api "TMF621"
    }
    PRODUCT_USAGE {
        string api "TMF635"
        string oda "TMFC040"
    }
    APPLIED_BILLING_RATE {
        string api "TMF678"
    }
    CUSTOMER_BILL {
        string api "TMF678"
        string oda "TMFC030"
    }
    AGREEMENT {
        string api "TMF651"
        string oda "TMFC039"
    }
    SERVICE_LEVEL_SPEC {
        string api "TMF657"
        string oda "TMFC006"
    }
    SERVICE_LEVEL_OBJECTIVE {
        string api "TMF657"
    }
One chain from party to bill. Order decomposition and triggering are ODA orchestration practice, not SID associations; an SLA is a kind of agreement.

Every hop has an Open API

Question the hop answersEntitiesTM Forum Open APIsODA components
Who is the customer?Party, PartyRole, Customer, BillingAccountTMF632 Party, TMF669 Party Role, TMF629 Customer, TMF666 AccountTMFC028, TMFC024
What did we sell?ProductOffering, ProductSpecification and the service and resource specifications it requiresTMF620 Product Catalog, TMF633 Service Catalog, TMF634 Resource CatalogTMFC001, TMFC006, TMFC010
What was ordered?ProductOrder, ServiceOrder, ResourceOrderTMF622 Product Ordering, TMF641 Service Ordering, TMF652 Resource OrderTMFC002, TMFC007, TMFC011
What is installed?Product, CFS, RFS, ResourceTMF637 Product Inventory, TMF638 Service Inventory, TMF639 Resource InventoryTMFC005, TMFC008, TMFC012
What went wrong?Alarm, ServiceProblem, TroubleTicket, IncidentTMF642 Alarm, TMF656 Service Problem, TMF621 Trouble Ticket, TMF724 IncidentTMFC043
What did we promise?Agreement, service level specification and objectivesTMF651 Agreement, TMF657 Service Quality, the SLA reference on TMF620TMFC039, TMFC006
What is billed?ProductUsage, applied billing rate, CustomerBillTMF635 Product Usage, TMF678 Customer BillTMFC040, TMFC030

API names follow the TM Forum Open API directory. Check the directory for current versions before building against a specific release.

Getting the service layer right

  • CFS and RFS are both service inventory. Customer-facing and resource-facing services live in TMF638 Service Inventory. TMF641 Service Ordering is how they change, and TMF652 Resource Order Management changes the resources beneath them.
  • CFS is technology-neutral; RFS is technology-specific. A VPN is the customer-facing service; the BGP routing behind it is resource-facing. Customers get the CFS through a product and never see the RFS.
  • A CFS is supported by zero or more RFS. In the ontology both are subtypes of Service rather than a category string, so rules can tell them apart.
  • Products reach resources directly too. A TMF637 product carries both realizing services and realizing resources, so a SIM or a device links to the product without a service in between.
  • Specifications link up front. A TMF620 product specification references the service and resource specifications needed to realise it.

Orders decompose by orchestration, and change runs as a saga

A product order becomes service orders, and service orders trigger resource orders. That decomposition is ODA orchestration practice. Product order capture and validation (TMFC002) takes the order; order orchestration (TMFC003) sequences the items, maps them to customer-facing service or resource specifications and sends service or resource orders to production. It is not a SID association, so the ontology records it as an orchestration link, together with the order state that governs it.

Exosphere, the judgment layer inside Exosphere Agentic, uses the same structure when it runs a multi-step change. Each step is an Open API operation on the owning component, coordinated as a saga with idempotency: a retried step never executes twice, and a failed step is compensated rather than left half-done.

Assurance and the promise on the same chain

  • TMF642 carries the alarm a resource raises.
  • TMF656 records the service impact: affected services, resources and locations.
  • TMF621 drives the resource repair, and TMF724 is the ITIL incident view across both (IG1224).
  • TMF651 and TMF657 carry the agreement and the service level objectives measured on the customer-facing service. An SLA is a kind of agreement, and TMF620 product offerings can reference it.
  • The credit is raised in billing and is visible via TMF678 on the customer bill.

Walk it end to end in Cell-site walk: who is affected, what we owe them.

Take the next step

Start with one loop. There are many more. Exos Systems will walk you through the mapping for the outcome you most need to improve.