Telecom software divides into OSS, which runs the network, and BSS, which runs the commercial relationship with the subscriber. Most engineering work is integrating and modernising that estate rather than building it new.
Steady demand20 min readOSS/BSS engineer, Billing systems engineer, Telecom solution architect, Integration engineer, Revenue assurance analyst, Network automation engineerUpdated 2026-07-27
Assumes you know: Relational data modelling and SQL, Messaging and integration basics (queues, APIs, batch file transfer), Comfort reading someone else's large codebase
Overview
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.
OSS
BSS
Faces
The network
The customer
Authoritative for
What exists and what is configured
What was sold and what is owed
Typical systems
Inventory, provisioning, activation, assurance, fault and performance management
Catalogue, CRM, order management, charging, billing, collections
Fails by
A service that does not work, or a record that disagrees with the field
A wrong bill, or revenue that was never invoiced
Measured on
Time to activate, mean time to repair
Bill accuracy, revenue leakage, days sales outstanding
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 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.
Subsection
What it is for
Subscriber & Provisioning
Turning an order into a working service on real equipment
Network Inventory
Knowing what exists, and reconciling that with reality
Mediation & Rating
Collecting usage records and turning them into charges
Billing & Revenue Assurance
Producing invoices and proving nothing was lost on the way
OSS/BSS Architecture
The domain split, catalogue-driven design, and decomposing a monolith
Network Services & 5G
Enough network to talk to the people who own it
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.
Loading diagram…
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
Term
What it means
CDR
A usage record emitted by a network element, whatever the usage was
Mediation
Collecting, normalising, deduplicating and correlating those records
Rating
Applying a tariff to a usage event to produce a charge
Charging
Authorising and decrementing in the moment, before or during use
Billing
Aggregating charges over a cycle into an invoice
Bill cycle
The recurring period an account is invoiced on
Proration
Splitting a recurring charge when something changes mid-cycle
Bundle
An allowance of included usage before per-unit rating applies
OCS
Online charging system, the authority over a prepaid balance
Provisioning
Writing configuration into network elements to make a service work
Inventory drift
The gap between what the records say exists and what does
Dunning
The escalating sequence of reminders for an unpaid bill
Leakage
Revenue that was earned but never invoiced or never collected
Interconnect
Settlement between operators for traffic crossing between them
Number portability
A subscriber keeping their number when changing operator
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.
Role
Employer
What their week is mostly
OSS/BSS engineer
Operator or integrator
Integration, adapters, defect triage across systems
Billing systems engineer
Operator or vendor
Tariff configuration, cycle runs, bill investigation
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.
Loading diagram…
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.
Loading diagram…
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.