Telecom OSS and BSS

What this area actually covers

Telecom domain knowledge is the software between a physical network and a paying customer. The organising idea, and the first thing to learn, is the split between OSS and BSS. OSS — operations support systems — faces the network: what equipment exists, what services are configured on it, whether they are healthy, and what to do when they are not. BSS — business support systems — faces the customer: what you can buy, what you ordered, what you used, what you owe, and what happens when you do not pay. A subscriber changing tariff is a BSS event that becomes an OSS action; a fibre cut is an OSS event that becomes a BSS credit note.

What this area is not is the network itself. Radio access, core packet routing, transmission planning and spectrum are network engineering, done by a different population with different qualifications. You must read their vocabulary; you are not designing a base station.

The six areas underneath

The subsections follow the two halves of the split and then the seam between them. The first two are OSS territory — who the subscriber is, what they were given, and what physically exists to give it on. The next two are BSS territory, turning usage into money. The fifth is the architecture that holds both together, which is where most modernisation work sits. The sixth is the minimum network literacy an IT engineer needs to be useful in the other five.

Subscriber & Provisioning

This is the order-to-activate path, and it is the most visible thing the systems do. It covers the subscriber lifecycle from prospect through activation, suspension, plan change, port-in and port-out, to termination; order decomposition, where one commercial product becomes several technical services; and the activation step that writes real configuration into real network elements. It exists as its own area because it is the domain's canonical distributed transaction — an order touches several systems, some of them slow, some of them occasionally down, none of them transactional with the others, and partial completion is the normal case rather than an edge case. Open it for orchestration patterns, for compensation when step four fails after step three succeeded, and for why a stalled order is the single most common thing you will be asked to debug.

Network Inventory

Provisioning can only assign what exists, and inventory is the record of what exists: sites, cabinets, cards, ports, circuits, IP address ranges, fibre strands, logical resources, and the cross-connections between all of them. This subsection covers physical and logical inventory as separate but linked models, resource assignment and reservation, capacity views, and discovery — reading the network's own state and reconciling it against the record. It exists separately because inventory drift, where the database and the field disagree, is one of the industry's permanent afflictions and has no purely technical cure: a technician in a cabinet at midnight will move a patch lead and not update anything. Open it for how inventory is modelled, for reconciliation strategy, and for the honest treatment of a data set that is never fully correct.

Mediation & Rating

Network elements emit usage events; this subsection is about turning them into money-shaped facts. Mediation collects records from many element types in many formats, normalises them, deduplicates, filters out what is not billable, and correlates fragments of one long session into one usable event. Rating then applies the tariff — the rate, the bundle allowance, the time-of-day rule, the roaming surcharge — to produce a charge. Real-time charging sits here too, because prepaid cannot wait for a batch. It exists as its own area because its correctness bar is unusual: mediation is judged almost entirely on never losing a record and never counting one twice, which makes idempotency and duplicate detection the whole job rather than a detail of it. Open it for record correlation, for how a tariff is modelled so it can change without a release, and for the reservation loop that online charging runs.

Billing & Revenue Assurance

Billing aggregates rated charges over a cycle, applies recurring charges, discounts, prorations and taxes, and produces an invoice; then collections, dunning and dispute handling follow. Revenue assurance is the discipline of proving the whole chain held: usage carried equals usage rated, rated equals billed, billed equals collected. This subsection covers the bill cycle and why subscribers are spread across several of them, proration when something changes mid-cycle, adjustments and credits, and the reconciliation controls that detect leakage. It exists separately from rating because the failure modes differ — a rating bug produces a wrong charge, a billing bug produces a wrong invoice, and only one of those generates a call to a contact centre and a regulatory complaint. Open it for how leakage is actually found, which is by counting the same thing in two places and caring about the difference.

OSS/BSS Architecture

This is the shape of the estate and how to change it. It covers the domain split itself, catalogue-driven design where a single product catalogue is the source of truth that order management, charging and self-service all read rather than each hard-coding the offers, the TM Forum information and API models that give the industry a common vocabulary, and the practical decomposition of a monolithic stack into services. It exists separately because the dominant engineering activity in telecom is not building a new system but splitting an old one while it continues to run and bill. Open it for strangler-fig patterns at this scale, for how to run old and new charging in parallel and compare them, and for migrating subscriber cohorts without double-billing anyone.

Network Services & 5G

The last subsection is the network literacy an IT engineer needs, pitched at what you must understand to design systems around it rather than at what a network engineer knows. It covers service models — what a connectivity product actually consists of — the move to a service-based, API-driven 5G core and what that enabled in automation, network slicing as a commercial construct as much as a technical one, and edge deployment. It exists because the OSS side is being reshaped by the network becoming programmable: provisioning that once meant a vendor-specific adapter increasingly means calling an API, and assurance that once meant reading alarms increasingly means closed-loop automation. Open it for the vocabulary and for a realistic read on how much of the automation promise has landed.

Where it sits in a real business

Follow one subscriber. Sales captures an order against a product catalogue — the commercial definition of what is sellable, with its eligibility rules, compatibility rules and prices. Order management decomposes that product into technical services and hands them to provisioning and activation, which configures real network elements: subscriber data in the home subscriber store or its 5G equivalent, policy rules deciding speed and priority, ports on access equipment. Provisioning must know what physically exists, which is the job of network inventory — the record of sites, cabinets, cards, ports, circuits, IP addresses and their cross-connections.

flowchart TD
  A[Order captured against the catalogue] --> B[Order decomposed into services]
  B --> C[Inventory assigns a port and resources]
  C --> D[Activation configures network elements]
  D --> E[Service live and usage flows]
  E --> F[Mediation collects and correlates records]
  F --> G[Rating applies the tariff]
  G --> H[Billing invoices over a cycle]
  H --> I[Collections, or dispute and credit]

The step that fails most often is C, and it fails silently. Inventory says a port is free, the field says it is patched to somebody else, activation succeeds against the wrong resource, and the fault surfaces days later as an unexplained outage on a different customer.

Now the subscriber uses the service. Network elements emit usage events, still universally called CDRs (call detail records) even when the usage is data rather than calls. Mediation collects those records from many element types, normalises formats, deduplicates, and correlates fragments of one session into one billable event. Rating applies the tariff to produce a charge. Billing aggregates rated charges over a cycle, applies bundle allowances, discounts and taxes, and produces an invoice, followed by collections if it is unpaid.

Around all of this sits revenue assurance: proving that usage carried equals usage rated, rated equals billed, and billed equals collected. Leakage is real money, so this function has budget and it has teeth. The method is unglamorous and effective — count the same population at two adjacent points in the chain and investigate the difference, every day, forever. A missing adapter for a newly deployed network element, a filter that drops records it should not, a tariff that fails to match and silently rates at zero: each of those is invisible in every system's own logs and obvious in a count.

Beside the retail flow, wholesale interconnect settles traffic between operators, because a call or message that starts on your network and ends on another creates an obligation between the two companies. Roaming works the same way for your subscribers on other networks, exchanging batched usage files — long standardised by the GSMA as TAP records — through clearing houses that sit between operators who do not want bilateral relationships with everybody. This side of the business is invisible to subscribers and is a material part of an operator's revenue and cost.

Money therefore changes hands at four distinct points, and it is worth being able to name them separately: the subscriber pays the operator on an invoice or from a prepaid balance; the operator settles with other operators for interconnect and roaming; the operator pays content and service partners for revenue-shared products; and regulators or governments take levies and taxes that the billing system has to compute correctly by jurisdiction.

The vocabulary of the first week

The distinction that separates people who have worked in the domain from people who have read about it is charging versus billing. Charging happens in the moment and controls whether service continues; billing happens after the fact and controls what is invoiced. A prepaid subscriber is charged and barely billed; a large enterprise account is billed heavily and charged hardly at all.

Who does this work

Vendor engineers build the products — Amdocs, Netcracker, Oracle, CSG, Ericsson and Huawei supply most of the world's billing and OSS stacks. Working for a vendor means deep product knowledge, a long release cycle and customers in many markets whose regulatory requirements differ.

Operator-side engineers integrate and extend: the adapter for a new network element, the transformation that makes a new tariff ratable, the API that lets the mobile app show a live balance. A day looks like tracing one order that stalled across four systems, reading logs in formats designed in the 2000s, and negotiating with the vendor about whose defect it is. That last activity is a genuine professional skill in this domain, because a large share of your production issues will be in software you cannot read and cannot patch, and the evidence you assemble determines how quickly it gets fixed.

Systems integrators run the multi-year migrations, which is where a lot of the domain's contract work sits. Alongside all of them, pricing managers specify tariffs, revenue assurance analysts hunt leakage, network operations centre staff operate what you build, and regulatory affairs teams translate obligations into requirements that land on your backlog with a statutory date attached.

Demand, adoption and how that is changing

Demand is steady rather than growing, and it is worth being clear why. Every operator already has this stack, it cannot be switched off, and the tariffs it encodes change constantly, so the maintenance floor is high. Regulation adds to it: number portability, lawful intercept and emergency call handling are statutory in most markets, and each of them is a system obligation with a compliance deadline rather than a product decision.

Meanwhile 5G core networks are service-based and API-driven, which pushed real automation into provisioning and assurance, and TM Forum's Open APIs gave the industry a common vocabulary that makes integration experience more portable between employers than it once was. That portability matters for a career here: a decade ago your value was largely knowledge of one vendor's product, and it is now somewhat more transferable.

Against that, this is a consolidating industry. Operators merge, revenue per subscriber is flat or falling in most markets, and cost pressure means outsourcing rather than hiring. The honest description of most telecom engineering jobs is modernisation: decomposing a monolithic BSS into catalogue, order and charging services, running old and new in parallel for years, and migrating subscriber cohorts without ever double-billing anyone. That work is real, well-paid and long-lived. It is not greenfield, and if you need greenfield to stay interested you will be unhappy.

Two adjacent areas are absorbing attention and worth knowing about. Operators have been trying for years to sell connectivity as an API to enterprises rather than only as a subscription to consumers, which if it lands makes the catalogue and charging systems into something a developer integrates with directly. And fixed-line and fibre rollouts in many markets have created a wave of inventory and order-management work that looks quite different from mobile, because a physical installation with an appointment and an engineer visit has constraints a SIM activation does not.

What makes it hard

The difficulty is not conceptual depth in any one place — it is that correctness is defined by a tariff document rather than by code, and the tariff has decades of accumulated exceptions. Every legacy product variant a marketing team ever launched still has customers on it, and your new charging engine must reproduce all of them to the penny, including the wrong-looking ones, because subscribers notice when their bill changes. Nobody can tell you the full list of variants either; you discover them by running the old and the new system side by side over real traffic and investigating every difference, which is why parallel-run is the default migration technique in this industry rather than a cautious option.

The subscriber lifecycle is a second source of accumulated complexity, because almost every state has a billing consequence and the transitions can be initiated by the customer, the operator or a regulator.

stateDiagram-v2
  [*] --> Ordered
  Ordered --> Active: activation succeeds
  Ordered --> Cancelled: activation fails or cools off
  Active --> Suspended: non payment or customer request
  Suspended --> Active: payment or reinstatement
  Suspended --> Terminated: dunning completes
  Active --> PortedOut: another operator wins the number
  Terminated --> [*]
  PortedOut --> [*]

Look at Suspended. Recurring charges may or may not continue during suspension depending on why it happened, incoming calls may still be permitted, and the rule differs by market and by regulator. That single state carries more disputed billing logic than the whole happy path.

The part that only bites in production is near-real-time charging for prepaid. A postpaid subscriber can be billed after the fact, because the operator carries that credit risk deliberately. A prepaid subscriber has no credit at all: if the balance empties mid-session and the network keeps carrying traffic, the operator has given away service it can never invoice. So prepaid cannot be rated in a nightly batch. The network element must ask an online charging system for authorisation before and during the session, which is why the industry standardised credit-control over Diameter (RFC 4006) and, in 5G, an equivalent HTTP-based charging interface defined by 3GPP. The mechanism is quota-based reservation:

start    element requests units      -> OCS reserves 5 MB, grants 5 MB
during   element reports 5 MB used   -> OCS commits, reserves and grants the next slice
low      balance nearly empty        -> OCS grants a final slice; element must then redirect
end      element reports 0.4 MB used -> OCS releases the unused reservation

Drawn as an exchange between the parties, the pressure points are easier to see.

sequenceDiagram
  participant N as Network element
  participant OCS as Online charging system
  participant Bal as Balance store
  N->>OCS: Initial request for units
  OCS->>Bal: Reserve a slice
  Bal-->>OCS: Reserved
  OCS-->>N: Grant
  N->>OCS: Used the slice, request more
  OCS->>Bal: Commit used, reserve next
  N--xOCS: Element crashes, no final report
  OCS->>Bal: Timeout releases the reservation

The crossed arrow is the whole problem. Between the crash and the timeout the subscriber's money is held against a session that no longer exists, so the timeout has to be short enough that customers do not complain about a missing balance and long enough that a slow network element is not cut off mid-call.

Everything painful follows from that loop. The reservation is a distributed lock on money, so a crashed element leaks balance until a timeout releases it. Grant size trades charging accuracy against signalling load: large grants mean fewer round trips and more over-grant risk at the end of a balance, small grants mean accuracy and a signalling storm at busy hour. One subscriber with several concurrent sessions means concurrent reservations against one balance, so the balance store needs strong consistency at high request rates and low latency in every region you operate — a genuinely hard distributed-systems problem hiding inside an unfashionable domain.

A third difficulty is that the product model is harder than it looks. A commercial offer is not a row with a price; it is a bundle of components with eligibility rules about who may buy it, compatibility rules about what it may be combined with, dependency rules about what must be bought alongside it, and validity dates that overlap with the offers it replaces. Getting that model right is what allows a marketing team to launch a tariff by configuration on a Tuesday instead of by a release in six weeks, and it is the single highest-leverage piece of design in a BSS. Getting it wrong is how an operator ends up with the same offer defined four times in four systems that then rate, display and bill it slightly differently.

Scale is the fourth difficulty and it is arithmetic rather than cleverness. A mid-sized operator produces usage records continuously from tens of millions of subscribers, and the bill cycle then has to process a month of them against tariffs that may themselves have changed mid-month, within a window measured in hours, without producing a single invoice that a regulator would call unfair. The uncomfortable property of a bill run is that it is both enormous and unforgiving: being 99.99% correct across tens of millions of invoices still means thousands of angry customers.

Why study it

Study it if you are joining a telco, an operator's integrator or a BSS vendor, where this vocabulary is the difference between six confused weeks and six productive ones. Study it also if you want to be paid to do strangler-fig decomposition of a system that cannot go down; few domains offer that at this scale with this much budget, and the experience of migrating live subscribers between charging systems is a genuinely hard thing to have done that transfers as a story even where the domain knowledge does not.

There is a narrower reason too. Online charging is one of the few widely deployed systems where strong consistency, low latency, geographic distribution and real money all apply at once, and if distributed systems is what interests you, this is a place where the constraints are not hypothetical. The literature is thinner than in web-scale engineering and the systems are less discussed, but the problems are real.

Do not study it as a route into distributed systems generally; you will learn the same lessons faster where the documentation is public and the implementations open source. And do not expect the skills to transfer — catalogue and rating knowledge is valuable within telecom and close to worthless outside it. That is the central career trade in this domain, and it is worth making deliberately rather than discovering after five years.

Your first hour

Take your own mobile bill and reverse-engineer it. Write one page naming, for a single month: the products on the account, which charges are recurring versus usage-based, which usage fell inside a bundle allowance and which was rated on top, any proration from a mid-cycle change, and the taxes. Then state which of those numbers an operator could compute overnight and which it would have to compute while the session was still running.

Line on the bill                        Recurring  Usage  Batch or real time
Monthly plan, 1-31 March                    yes      no    batch
Plan change on 12 March, prorated           yes      no    batch
Data: 42 GB, 40 GB included                  no     yes    batch if postpaid
Data: overage 2 GB at per-GB rate            no     yes    real time if prepaid
Roaming data in another country              no     yes    delayed, arrives by file
Calls to a premium number                    no     yes    real time, revenue shared
Tax on the total                             n/a    n/a    batch, by jurisdiction

Two rows repay thought. The roaming line cannot be rated in real time at all when the records arrive later as a file from another operator, which is why roaming fraud and bill shock have historically been such persistent problems. And the premium number line involves paying a third party out of what you collect, so getting it wrong costs the operator twice.

With the remaining time, read TM Forum's Open API descriptions for product catalogue and product ordering and note where your bill's structure and their model agree. The artefact is that page: a bill you can explain line by line, and a clear split between what is batch and what must be real time.

What this is not

It is not network engineering, and calling inventory "the network" in an interview will be noticed. The inventory database is a description of the network, maintained by people, and its relationship with reality is the whole subject of one of the subsections above.

It is not generic e-commerce billing: metered usage and prepaid balances make it a different problem, which telecom solved decades before SaaS met it. If you arrive from a subscription-billing background, the concepts that will not transfer are real-time authorisation and the bundle model, and those are the two that carry most of the complexity.

Mediation is not ETL renamed — its job is correlating and deduplicating events that arrive late, twice or in fragments, and it is judged on not losing or double-counting one. Charging is not billing: charging authorises and decrements in the moment, billing aggregates over a cycle, and confusing the two is the clearest signal that someone has read about the domain rather than worked in it. And a product catalogue is not a price list; it carries eligibility, compatibility and dependency rules, and treating it as a table of prices is how teams end up hard-coding offers into six systems that then disagree.

The whole architecture falls out of one asymmetry: postpaid lets you rate usage after it happened, prepaid does not.