Unified data infrastructure
GitHub Let's talk

Telecom

Subscribers, network elements and events in one view.

A network operator holds the topology of a very large graph and the performance of every element in it, while subscribers expect both to be right immediately.

See Time-series Workloads All of Enterprise & Commerce

An alarm resolved to the elements and subscribers it touches, through real topology.

The story

An alarm resolved to the elements and subscribers it touches, through real topology.

Where it starts

Performance counters

Throughput, latency, error rates and utilisation per element. It is the first of 4 workloads running in Telecom.

The question it raises

Incident to topology

Alarms resolve to the elements, links and services they touch through relationships stored as data.

Why one question is hard

From Instrument to Resolve

Telecom data moves through 4 stages — Instrument → Model → Serve → Resolve. The shapes in play are Time series, Graph, SQL, Events, JSON / documents, and answering one question means reading across all of them.

What PLOMID contributes

Telecom is the largest graph most organisations own. These are the parts that keep it queryable.

The environment

Network topology, performance counters, subscriber records and incidents.

Network elements emit counters and alarms continuously, topology describes what connects to what, and subscriber and service records describe obligations. PLOMID holds the counters, the relationships and the records in one layer, so an incident resolves against the network rather than against a diagram.

The data journey

How telecom data reaches one layer.

Walk the path the data takes, from the environment that produces it to the questions it answers. Select a station, or a shape, to read each step.

An alarm resolved to the elements and subscribers it touches, through real topology.

Environment

The network

Elements, links, cells and sites — the largest graph most operators own.

Graph

One environment · many workloads

What runs against telecom data.

4 workload families over one set of shapes. Choose one to see what it moves and where it lands.

Throughput, latency, error rates and utilisation per element.

  • Planned once against the layer, not once per store
  • Read beside the records it shares a key with
  • Persisted under one storage contract
Where the data goes to work

Questions customers force you to answer.

Each one spans the event and the record around it, answered from the same layer rather than joined by hand.

Incident to topology

Alarms resolve to the elements, links and services they touch through relationships stored as data.

  • Time series
  • Events

Capacity honestly read

Counters and inventory sit together, so utilisation is computed against the real configuration.

  • Graph
  • SQL

Subscriber impact

A service question resolves through topology to the subscriber record in one request.

  • SQL
  • Time series

Documented resolution

Tickets and work orders stay queryable beside the alarms that produced them.

  • JSON / documents
  • SQL
Workload architecture

From event to record.

The work, the shapes it names and the path a request takes — from the storefront to the warehouse.

Telecom · workload architecture
Workloads

What runs against this data.

  • Performance counters
  • Topology and inventory
  • Subscriber and service records
  • Alarms and incidents
Data models

The shapes those workloads read and write.

  • Time series
  • Graph
  • SQL
  • Events
  • JSON / documents
The layer

One path from a request to the data it names.

  • Planning Predicates narrow the work before it runs
  • Execution Records, fields and windows answered together
  • Transactions Readers and writers do not block each other
Surfaces

How the work reaches the layer.

  • SQL surface The query language the layer is documented in
  • Applications Services and jobs writing and reading as they run
  • Analytics & AI clients The same layer, the same access path
Data models in play

The shapes, in one layer.

5 shapes carry this domain. Choose a stage to read the operation, or a shape to see every stage that handles it.

PLOMID · Telecom instrument · model · serve · resolve Select a stage
Stage

Instrument

Element counters, alarms and link state

Time series · Events

Workload map Telecom workload map. Every shape on it is a surface of the layer, and each stage names the part of the operation it carries.
  • Time series Measurements and events in time order
  • Graph Relationships and traversal
  • SQL Records, keys and joins
  • Events Operational events as they happen
  • JSON / documents Documents and nested objects
Deployment & residency

Where this data is allowed to run.

Elements are everywhere; aggregation points are few, so placement is part of the architecture.

Deployment, residency and control
What you build next

Time-series Workloads

Measurements and events stored beside the records they describe.

If Incident to topology is your question, start here.

See Time-series Workloads Every solution
Next

Where to go next

Solutions The workload answers this industry leans on, with their models and status. Platform The data models in the product today, and the ones extending the layer. Architecture How a request is planned, executed and persisted once it reaches the layer.