Pages
More Information

Cell-site walk: who is affected, what we owe them

One degraded cell, walked from the first alarm to the credit on the bill, with a standard at every hop.

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. This page walks one degraded cell site from alarm to bill, with a TM Forum or 3GPP anchor at every hop. It is the target-state assurance loop Exos Systems delivers with each operator, on the same governed core every loop shares.

Updated

Answer the question the NOC and the bill both ask

Which customers are affected by this cell-site degradation, and what do we owe them?

The network knows what broke. BSS knows who pays and what was promised. The answer sits at the join between them: the customer-facing service. The telecom ontology for BSS and OSS makes that join a modelled path, not a report.

  • Proactive care. Affected customers hear from you before they call you.
  • Credits with evidence. Every credit carries the SLA clause, the evidence and the approver.
  • Repair on the right resource. Field work starts on the resource, while the service impact is tracked on its own record.

The ontology binding, the telemetry feed and the closed loop are built per engagement. The governance that wraps them, Exosphere, the judgment layer inside Exosphere Agentic, is the same for every loop.

The walk, hop by hop: from alarm to impact

sequenceDiagram
    autonumber
    participant CELL as Cell - TS 28.541
    participant PM as Thresholds - TMF649
    participant FM as Alarms - TMF642
    participant MESH as Event mesh - Exosphere
    participant AGT as Assurance agent
    participant ONT as Telecom ontology
    participant INV as Inventory - TMF639 638 637
    participant SLA as Terms - TMF651 657
    CELL->>PM: Counters reported
    PM->>FM: Threshold crossed, alarm raised
    FM->>MESH: Alarm on the cell
    MESH->>AGT: Normalised event with resource id
    AGT->>ONT: What depends on this cell
    ONT->>INV: Resource to RFS to CFS to product
    INV-->>ONT: Affected services and products
    ONT-->>AGT: Customers, agreements, CFS status
    AGT->>SLA: Objectives and consequences
    SLA-->>AGT: Targets, grace times, consequences
Hops 1 to 10 of the target-state assurance loop: from the alarm to the affected services, customers and terms, with a standards anchor at every hop.

The walk, hop by hop: decide, act and record

sequenceDiagram
    autonumber 11
    participant AGT as Assurance agent
    participant SPM as Service problem - TMF656
    participant TT as Field repair - TMF621
    participant HUM as Duty manager
    participant COM as Customer notice - TMF681
    participant BIL as Billing
    participant AUD as Audit record
    AGT->>SPM: Raise problem with affected services
    SPM-->>AGT: Problem id and impact factor
    AGT->>TT: Resource trouble for field repair
    AGT->>HUM: Proposed notices and credits with evidence
    Note over AGT,HUM: Human gate - scope, value, blast radius
    HUM-->>AGT: Approved within scope
    AGT->>COM: Proactive notice to affected customers
    AGT->>BIL: Raise credit per SLA consequence
    BIL-->>AGT: Credit line, visible via TMF678
    AGT->>AUD: Evidence, approver, actions, citations
Hops 11 to 19: a person signs before any notice or credit goes out, and the evidence, approver and actions land in one audit record.

A standard at every hop

StepWhat happensAnchor
DetectA threshold on the cell's counters is crossed. An alarm is raised, and cleared when the indicator recovers.3GPP TS 28.541 cell model, TMF649 Performance Thresholding, TMF642 Alarm Management
NormaliseThe alarm reaches the Exosphere event mesh with the alarmed object as a resource id, plus severity and probable cause.TMF642 alarm fields
UnderstandThe ontology walks resource to resource-facing service to customer-facing service to product to customer.GB922 SID, TMF639, TMF638, TMF637, TMF629
What we oweAgreement terms and service-level objectives for each affected customer, including the prescribed consequence.TMF651 Agreement, TMF657 Service Quality, SLA referenced from the TMF620 offering
Record impactA service problem names the affected services and carries an impact factor and a priority.TMF656 Service Problem Management
RepairA resource trouble goes to field operations.TMF621 Trouble Ticket
DecideNotices and credits are proposed with evidence. Policy routes them to the person with authority.Exosphere policy, TMF701 human task where used
ActProactive notice goes out. The credit is raised in billing, visible on the bill via TMF678.TMF681 Communication, GB929D SLA Violation Management, TMF678 Customer Bill
ConfirmOne incident view spans resource, service and product. The audit record closes the loop.TMF724 Incident Management, Exosphere audit lineage

Exos Systems is a TM Forum member and aligns to ODA. Standards bodies named here describe the context we work in; they are not an endorsement by those bodies.

Three records, each with one job

Assurance stays clean when every team works its own record and one lineage joins them. TM Forum's NaaS guidance (IG1224) sets the split.

  • TMF656 records the service impact. A service problem names at least one affected resource, service or location. It carries an impact factor and a priority, and in the NaaS suite it links SLA violations and trouble tickets.
  • TMF621 drives the resource repair. Resource troubles tell service problem management about likely service impact, and can be coordinated by it.
  • TMF724 is the ITIL incident view across both. Its affected entity can be a resource, a service or a customer's product.

Exosphere raises each record through its own API and ties them together in one audit lineage, so the NOC, care and billing all read the same story.

Where an OSS fault becomes a BSS obligation

flowchart TD
    EV["Alarm on a resource<br/>TMF642"]
    subgraph OSS["OSS DOMAIN"]
        RES["Resource<br/>TMF639"]
        RFS["Resource-facing service<br/>TMF638"]
    end
    subgraph XP["THE CROSSING POINT"]
        CFS["Customer-facing service<br/>TMF638"]
    end
    subgraph BSS["BSS DOMAIN"]
        PRD["Product<br/>TMF637"]
        CUS["Customer<br/>TMF629"]
    end
    SLO["Service level objective<br/>TMF657"]
    AGR["Agreement<br/>TMF651"]
    TT["Resource trouble<br/>TMF621"]
    SP["Service problem<br/>TMF656"]
    INC["Incident<br/>TMF724"]
    EV --> RES
    RES -->|"supports"| RFS
    RFS -->|"supports"| CFS
    CFS -->|"realizes"| PRD
    RES -.->|"realizes"| PRD
    PRD -->|"owned by"| CUS
    CFS -->|"measured by"| SLO
    SLO -->|"committed in"| AGR
    RES -.->|"raises"| TT
    TT -.->|"informs"| SP
    SP -->|"affects"| CFS
    INC -.->|"references"| PRD
    classDef exos stroke:#0077B6,stroke-width:2px
    classDef std stroke:#005F8A,stroke-width:1px
    class CFS,SP exos
    class RES,RFS,PRD,CUS,SLO,AGR,TT,INC std
The customer-facing service is the crossing point: the modelled path from a resource alarm to a customer and the terms they hold.

SID already knows degraded from owed

The agent does not guess whether a degradation costs money. The information model already draws the line.

  • CFS status. GB922 SID gives the customer-facing service a status that separates degraded but billable from in violation of its contract. A service-violation policy decides whether a violated service stays billable.
  • RFS status. The resource-facing service tracks whether it still supports its CFS.
  • Two vocabularies. CFS attributes are technology-neutral: throughput, latency, loss, availability. RFS attributes are technology-specific. A 3GPP slice maps to the RFS layer and its connectivity service to the CFS (GB999).
  • The consequence is written down. Each TMF657 objective carries targets, tolerance and grace times, and a consequence: the action the contract prescribes when the objective is missed.

So a degraded-but-billable service earns a proactive notice. A service in violation earns a credit proposal, routed to the person with authority. A loop that credits every dip costs money; restraint is part of governance.

From SLA consequence to credit note, under a human gate

The industry has already described this translation. Exosphere makes it run, with a person signing at the point of decision.

  1. Assess. eTOM Customer QoS/SLA Management (1.3.8, GB921) monitors delivered QoS against contracts: Assess Customer QoS/SLA Performance (1.3.8.1) tests whether contractual obligations are met, and Manage QoS/SLA Violation (1.3.8.2) acts on a violation and informs the customer of QoS impact.
  2. Quantify. TAM Customer SLA Violation Management (GB929D) turns a violation into an adjustment under the SLA contract and passes it to billing.
  3. Apply. Customer Account Adjustment applies the credit (GB929F). The credit is raised in the billing component and the customer sees it on the bill, via TMF678.
  4. Govern. Exosphere evaluates scope, value and blast radius against the operator's policy, routes the proposal to the duty manager, and records evidence, approver, actions and citations.

The agent assembles the evidence. A person signs. See the governance model for how routing is decided, and three planes for why the alarm path and the meaning path run on different clocks.

Take the next step

See the loop run on synthetic accounts, or walk through the ontology with Exos Systems.