Telecom domain fundamentals

A configured capability on shared infrastructure, metered or bundled, with devices and content wrapped around it. That distinction matters more than it sounds: because the product is not an object but a state of the network, every sale is an instruction to reconfigure something, and every cancellation is another. The margin comes from utilisation of an asset already paid for, so commercial agility — launching a new bundle, in a new market, this quarter — is worth more than almost any efficiency elsewhere. That is why an architect's attention belongs on the product catalogue and the order path rather than on the invoice renderer, which is the part outsiders assume is the system.

Because both ends of the business read from it. The commercial end needs it to define what can be sold, at what price, with what eligibility and what bundling rules. The technical end needs it to know what a sold product decomposes into on the network and how its usage should be rated. If those are two catalogues, they drift, and the drift is not cosmetic: marketing launches a plan, ordering knows the plan, and rating does not, so usage is either unrated or rated at a default tariff. A single catalogue driving ordering, provisioning and rating is what makes "launch a product without a release" possible, and its absence is the root cause behind most operator delivery complaints.

One product offering, with the two consumers of it annotated.

Product offering  PO-FIB-300-V   "Fibre 300 with Unlimited Voice"

  price
    recurring     INR  999   monthly, billed in advance
    one-off       INR 1500   installation, waived when term >= 12 months

  characteristics                     consumed by ORDERING
    bandwidth     300 Mbps            -> BNG rate-limit profile FIB300
    staticIp      false               -> skip the IPAM assignment step
    term          12 months           -> early-termination charge applies

  bundled service specs               consumed by PROVISIONING
    CFS-BB-ACCESS  -> RFS-GPON-PORT, RFS-BNG-SESSION
    CFS-VOICE-SIP  -> RFS-IMS-SUBSCRIBER

  usage rating rules                  consumed by RATING
    voice_domestic  included, fair use 3000 min, then INR 0.30/min
    voice_intl      INR 4.50/min, rated in 30-second increments
    data            unmetered, shaped to 2 Mbps beyond 3.3 TB

Read it as three views of one record. Ordering takes the characteristics and turns them into steps; provisioning takes the bundled specifications and turns them into network configuration; rating takes the usage rules and turns call records into charges. Nothing here is code, which is the point — a new offering is a catalogue change plus a price, not a release.

The failure this prevents is the most expensive routine failure in a BSS estate. When rating carries its own copy of the tariff, a plan launched on Monday is unrated until someone configures the rating engine, and unrated usage is revenue leakage that nobody notices because no error is raised. The mirror case is worse for the customer: rating falls back to a default tariff, invoices go out wrong, and the cost is a dispute queue plus a regulator interested in why.

Two details a candidate should offer unprompted. The catalogue is versioned and effective-dated, because customers stay on withdrawn offerings for years, so rating must resolve the tariff that applied on the date of the call rather than the current one. And the decomposition is a specification, not an instance: the catalogue says a fibre product needs a GPON port, while the inventory says which port this customer got.

Four entities that candidates collapse into one and interviewers separate deliberately. The customer is the legal party with the contract — a person or a company. The account is the billing arrangement, holding the currency, the billing cycle, the payment method and the balance, and one customer may have several. The subscriber is the user of a service, identified on the network rather than commercially, which is why a company can have a customer record, ten accounts and forty thousand subscribers. The service is the specific instance sold and provisioned — this line, this broadband circuit. Conflating them breaks immediately in the enterprise segment, where the payer, the user and the contracting entity are three different things.

Five identifiers, and the interview question is which travels with what.

subscriber "Priya Rao", one mobile line

  IMSI    404450123456789    identifies the SUBSCRIPTION on the network
                             MCC 404 | MNC 45 | MSIN 0123456789
                             lives on the SIM, used for authentication
                             and for HLR/UDM lookup. Rarely exposed.

  MSISDN  919845012345       identifies the DIALLABLE NUMBER
                             the commercial identity, printed on the bill,
                             portable between operators, mapped to an IMSI

  ICCID   8991450123456789012  identifies the SIM CARD itself
                             printed on the plastic, used in logistics
                             and stock management, not in call setup

  IMEI    35-209900-176148-1 identifies the HANDSET
                             burned into the device, travels with the
                             device across every SIM put into it

  IMPU/IMPI sip:+919845012345@ims.example  identifies the IMS identity
                             used for VoLTE registration and routing

The IMSI and the MSISDN are the pair that matters. The IMSI is the network's name for the subscription and effectively an internal key; the MSISDN is the customer's name for it and is portable, reassignable and recycled. Their mapping is many-to-one over time and is data, not identity — which is why using the MSISDN as a primary key fails, and why the IMSI is what a charging system keys on.

What travels with the handset is the IMEI, and only the IMEI. Move the SIM to a new phone and the IMSI, MSISDN and ICCID are unchanged while the IMEI changes; that asymmetry is what makes IMEI blocklists the mechanism for stolen devices, and what lets an operator report which handset models are on its network without asking anyone.

The ICCID is the one candidates omit and the one warehouse and eSIM flows depend on, because until the SIM is issued to somebody it is stock with a serial number and no subscriber at all. With eSIM the plastic disappears and the eUICC identifier plus a downloadable profile take its place, which turns SIM logistics into a provisioning problem — an improvement operationally and a new set of systems to build.

Because both are ratios the business optimises and both are computed from systems you build. ARPU — average revenue per user — falls whenever data becomes cheaper faster than volume grows, so operators chase revenue in bundles, content and enterprise services, each of which is a new product shape the catalogue must express without a release. Churn means a subscriber who leaves takes their acquisition cost with them, so retention offers must be applied mid-cycle, which is precisely the proration and mid-cycle-change machinery that is hardest to get right. When an interviewer asks what your system does for the business, these are the two numbers the answer connects to.

Business support systems are everything commercial: CRM and customer management, the product catalogue, order capture, charging, rating, billing, invoicing, collections, partner settlement and revenue management. Their subject matter is the customer and the money, and their units are offerings, accounts, orders and invoices. BSS stops where the question changes from "what did we promise and what do we charge" to "what must be configured, where, on which equipment". It does not stop at a nice clean line in most estates, which is itself worth saying: the reason the boundary is discussed so much is that vendors sell across it and the integration bill lands on whoever inherits the seam.

At the point where a commercial promise becomes a technical instruction — the service order. BSS decides what was sold, to whom, on what terms; OSS decides how to realise it on real resources and whether that is even possible. The practical marker is the vocabulary: BSS says "product offering", OSS says "resource-facing service and port 3/0/1". Two things cross the boundary in each direction, and naming them is a stronger answer than drawing the line. Outbound: the service order and the feasibility question. Inbound: activation completion, which starts billing, and assurance data — outages and degradations that a service-level agreement makes commercially significant.

eTOM, now the Business Process Framework, is TM Forum's hierarchical map of the processes an operator runs, decomposed to several levels. What an interviewer wants is not the level-three catalogue but the three horizontal process groupings and why they are useful as shorthand: fulfilment, assurance and billing — FAB — plus strategy and infrastructure lifecycle above them. Say that order-to-activate is fulfilment, trouble-to-resolve is assurance, and usage-to-cash is billing, and you have demonstrated the fluency being tested. Claiming to have implemented eTOM is a red flag, because it is a reference model used to structure and compare, not software.

The Information Framework, SID, is TM Forum's shared data model — the entity definitions behind the process map, so that two systems and two vendors mean the same thing by "product", "service" and "resource". The part worth knowing is its central distinction: a product is what a customer buys, a service is what is delivered, and a resource is what delivers it, with the product-service-resource chain running through the whole model. That layering is what allows a customer-facing service to be redesigned onto different equipment without the commercial catalogue changing, and it is the vocabulary Open APIs are built in.

A set of REST API specifications for the interfaces operators keep re-buying — product catalogue, product ordering, service ordering, resource inventory, party management, trouble ticketing, usage management. They matter because integration is the dominant cost in a BSS or OSS programme, and a standard interface turns vendor replacement from a rewrite into a swap. The pragmatic reality worth mentioning is partial conformance: most vendors implement a subset with extensions, so the standard reduces integration effort rather than removing it. Naming TMF620 for catalogue, TMF622 for product ordering and TMF641 for service ordering is the level of specificity that reads as experience.

The regulatory right to keep your number when you change operator. It breaks the oldest assumption in telecoms: that a number range identifies the operator that owns it. Once numbers move, routing a call requires a portability lookup against a central database rather than a prefix rule, and every operator must run or query one. Commercially it removes the strongest lock-in an operator had, so churn processes become time-bounded and regulated, with porting windows measured in hours. Internally it means a number is a lease rather than a property: it arrives with history elsewhere, it can leave, and it is recycled to somebody else after a quarantine period.

The model below is the one everyone writes first, and portability invalidates its primary key.

Naive
  subscriber
    msisdn      PRIMARY KEY    9845012345
    imsi                       404450123456789
    plan_id                    PO-MOB-499
    created_at                 2024-03-11

Three events it cannot survive

  PORT OUT   the MSISDN leaves for another operator, but the account, the
             unpaid final invoice, two years of CDRs and a dispute are ours.
             Deleting the row destroys history; keeping it blocks reuse.

  PORT IN    the MSISDN arrives with no IMSI of ours yet, and it belonged to
             a different operator last month. Rating a call made last month
             must resolve the operator that owned it then, not now.

  RECYCLE    ninety days after cancellation the number returns to the pool
             and is issued to a different person. Two unrelated humans now
             share the primary key.

The fix is to stop treating an identifier as an identity.

subscriber            id (surrogate)  customer_id  status
msisdn_assignment     msisdn, subscriber_id, valid_from, valid_to, source
imsi_assignment       imsi,   subscriber_id, valid_from, valid_to

Every lookup becomes temporal: which subscriber held this number at this instant. That single change is what makes the port-out, the port-in and the recycle all ordinary rather than exceptional, and it is why mature operator schemas are full of validity intervals.

Two consequences follow. Rating must be as-of-date on the identifier as well as on the tariff, because a CDR arriving four days late may refer to a number that has since moved. And any downstream system caching a number-to-subscriber map — fraud, analytics, the notification service — now has a cache that can be silently wrong about a real person, which is a privacy incident rather than a bug.

The network as a managed thing: inventory of what exists, activation of configuration onto it, discovery of what is really there, fault and performance data coming back, and the workforce and work orders that touch physical equipment. Its units are services and resources rather than products and accounts. The reason it is harder than it looks is that OSS is the only part of the estate whose model must match a physical world it does not control — a technician who patches a cable at two in the morning has changed the truth without telling any system, and every OSS design problem is downstream of that fact.

A customer-facing service is what the customer can perceive and be sold — broadband access at 300 Mbps, a voice line, a VPN site. A resource-facing service is what the network must do to deliver it — a GPON port, a VLAN, a subscriber session on a broadband gateway, an IMS subscriber record. The distinction earns its place because it is the seam that lets technology change without commercial change: migrate a customer from copper to fibre and the customer-facing service is identical while every resource-facing service beneath it is different. Without the layer, a network migration becomes a catalogue migration and a billing migration too.

One sold product, decomposed down to the resources an order will reserve.

flowchart TD
    P[Product offering<br/>Fibre 300 with static IP] --> C1[CFS Broadband access<br/>bandwidth and IP version]
    P --> C2[CFS Static IP address]
    C1 --> R1[RFS GPON port on OLT<br/>plus ONT at the premises]
    C1 --> R2[RFS VLAN on aggregation<br/>plus BNG subscriber session]
    C2 --> R3[RFS Address from the IPAM pool]
    R1 --> RES[Resources<br/>OLT slot, fibre path, ONT serial]
    R2 --> RES

Read the layers as three different lifetimes. The product changes when marketing changes; the customer-facing service changes when the offer's technical shape changes; the resource-facing services change whenever the network does, which is constantly. Collapsing them means the fastest-changing layer is coupled directly to the slowest.

The order path uses the graph downwards. Decomposition turns one product into several service orders, each of which reserves specific resources — this slot, this address — and the reservation matters because two orders in flight for the last port in a cabinet must not both succeed. The assurance path uses the same graph upwards: an alarm on the OLT card resolves through the resource-facing services to the customer-facing services above it, which is how an operator answers "who is affected" rather than "what is broken".

The detail candidates miss is that the graph is both a specification and an instance. The catalogue holds the shape — a fibre product needs a GPON port — while the inventory holds the fact that this customer has port 3/0/1 on OLT-BLR-14. Confusing the two produces an inventory that cannot answer capacity questions and a catalogue that must be edited for every installation.

The system of record for what the network contains and how it is connected — equipment, cards, ports, circuits, addresses, capacity and the assignments of all of them to services. It drifts because it is a model of a physical estate changed by humans and by automated systems that do not always report back: emergency repairs, temporary patches made permanent, a decommissioning that was performed but never recorded, a vendor tool configuring a device directly. Drift is not a tidiness problem. An inventory that overstates capacity causes orders to be accepted that cannot be delivered, and one that understates it means paying for equipment already owned.

Physical inventory is equipment and its containment — sites, racks, shelves, cards, ports, fibres and their serial numbers. Logical inventory is the configuration riding on it: circuits, VLANs, IP addresses and subnets, bearer paths. Service inventory records which customer-facing and resource-facing services exist and which logical and physical items each one consumes. The three answer different questions, which is why they are separated: physical answers "what would a technician find", logical answers "what is configured", and service answers "who breaks if this fails". Most operators have all three, often in different systems, and reconciling them is a permanent programme.

Discovery interrogates the network directly to learn what is actually deployed and configured. Reconciliation compares that against inventory and produces discrepancies: items present in the network and not in records, items recorded and absent, and attributes that disagree. It is never finished because the two sources are updated by different processes at different speeds, so a reconciliation run always finds something. The engineering judgement being tested is what you do with a discrepancy — automatically overwriting inventory from discovery destroys the assignment context that discovery cannot see, so mature designs auto-correct a whitelisted set of attributes and queue the rest for a human.

Three things. It is long-lived — a fibre installation may take three weeks and involve a site visit — so the order is a stateful process rather than a transaction, with milestones, jeopardy and customer-visible progress. It is conditional on feasibility: whether the product can be delivered to this address on this network is a question that must be asked before the order is accepted, and service qualification exists solely to answer it. And it is decomposed — one commercial order becomes several service orders with dependencies between them, so partial success is the normal case rather than an error, and the order must be able to describe itself as half done.

The happy path is short. Everything interesting is the branch at the bottom.

flowchart TD
    A[Order captured in CRM<br/>after service qualification] --> B[Validate and decompose<br/>against the catalogue]
    B --> C[Reserve resources<br/>in inventory]
    C --> D[Service orders to the<br/>provisioning orchestrator]
    D --> E[Activate on network<br/>elements]
    E --> F{Activation confirmed}
    F -->|yes| G[Inventory updated<br/>billing start date set]
    F -->|no| H[Fallout queue<br/>retry or manual repair]
    H --> D

The single most consequential arrow is the one from activation into billing. The billing start date is set by confirmed activation, not by order capture, because charging for a service that was never delivered is both a dispute and, in many jurisdictions, a regulatory matter. Operators that wire billing to the order rather than to the activation generate a permanent trickle of credits.

Reserving resources before activating is the second thing to notice. Without a reservation step, two orders in flight can both be told the last port in a cabinet is free, and the second discovers otherwise at the worst possible moment — after a technician has been dispatched.

The fallout loop is where the real system lives. Activation fails for reasons that have nothing to do with the order: an element unreachable, a timeout, a configuration rejected because a field the catalogue allows the element does not, an address in use. Each of those needs a different response, so fallout is classified rather than merely queued: transient faults retry with backoff, data faults route to a correction queue, and capacity faults go back to inventory for reassignment.

The detail that separates candidates is idempotency on the retry. Re-sending an activation that partially succeeded must not create a second subscriber record or a second reserved address, so every activation carries a correlation identifier and the orchestrator must be able to ask the element what state it is in rather than assuming.

Any order that leaves the automated path and needs intervention. It is hard because it is where every gap between the model and the world appears at once — stale inventory, an unreachable element, an address the customer typed imprecisely, a product combination nobody tested. It is also where cost concentrates: a fallout rate of five per cent on a million orders a month is fifty thousand manual touches, so fallout reduction is usually the highest-value work available in a fulfilment stack. The metric to know is flow-through or first-time-right rate, and the trap is that automating a failure into a silent retry loop improves the metric without improving the customer's experience.

Provisioning is the whole act of making a service ready — allocating resources, configuring elements, updating records, sometimes dispatching a technician. Activation is the narrower step that makes it live and usable, which is the moment the network will carry the customer's traffic and the moment billing should begin. The distinction matters operationally because the two can be separated in time deliberately: a line may be provisioned on Tuesday and activated when the customer confirms, or a SIM shipped pre-provisioned and activated on first use. Systems that treat them as one event cannot express either case.

Because a network element is a remote system with three outcomes rather than two, and the third — unknown — is common. A timeout tells you nothing about whether the configuration applied, so the only safe response is to retry, and a retry that duplicates a subscriber record or leaks an address is worse than the original failure. Compensation is the other half: when step four of six fails and cannot be retried, the first three must be undone, and there is no transaction spanning a broadband gateway, an IMS core and an inventory database. So each step needs an idempotent apply and an explicit reversal, which is a saga by another name.

The SIM is a tamper-resistant smart card holding the IMSI and a secret key, whose job is to prove the subscription's identity to the network without ever transmitting that key. Activation is therefore not something done to the card but to the network: the subscriber's profile is written into the home subscriber register — HLR, HSS or UDM depending on generation — associating the IMSI with an MSISDN, allowed services, roaming permissions and quality profiles. That is why a SIM in a drawer is inert stock and why activation is a database operation on the operator's side. With eSIM the profile itself is downloaded to an embedded chip, which replaces physical logistics with a provisioning service.

Completion is not the last step finishing; it is every decomposed service order reporting success and inventory reflecting the assignments, at which point the order transitions and billing begins. Jeopardy management is the watchdog: each milestone carries an expected duration, and an order that misses one raises a jeopardy event before the customer-promised date is missed rather than after. That distinction is the whole value — an order that will be late is actionable, an order that was late is an apology. It also means the orchestrator must persist expected timings alongside state, which is a design decision people discover they needed only after the first missed installation window.

The layer between the network and the commercial systems that turns raw usage records into something billable. It collects records from switches, gateways and probes in whatever proprietary or ASN.1 encoded format each emits, decodes them, validates them, discards what is not chargeable, deduplicates, correlates partial records belonging to one session, enriches them with commercial identifiers, and delivers them onward. It exists because the alternative is a rating engine that knows about every network element vendor, and because the volumes — billions of records a day for a large operator — need a stage designed for throughput rather than for business logic.

One voice call, as the switch writes it, then the six stages it passes through.

Voice CDR, mobile originated call, as emitted

  recordType           MOC
  servingElement       MSC-BLR-04
  callingNumber        919845012345          A party MSISDN
  calledNumber         912266778899          B party
  imsi                 404450123456789       identifies who is charged
  imei                 35-209900-176148-1    which handset
  startTime            2026-07-14T09:41:07+05:30
  duration             137                   seconds
  cellId               404-45-1201-8843      where the A party was
  bearer               voice
  causeForTermination  normal
  recordSequence       MSC-BLR-04:0000918273

Journey

  1 COLLECTION     files pulled from the element, or streamed; checked for
                   gaps in the sequence, because a missing file is missing
                   revenue and nothing else will report it
  2 DECODE         vendor format to a canonical record
  3 VALIDATE       drop zero-duration and malformed records, quarantine
                   rather than discard so they can be reprocessed
  4 DEDUPLICATE    on recordSequence, because re-sent files are routine
  5 CORRELATE      join partial records: a long call rolls over into
                   several records, a handover produces one per element
  6 ENRICH + RATE  IMSI to subscriber to account, then apply the tariff
                   effective on 14 July, producing a rated event
  7 BILL           accumulate rated events into the open bill period,
                   then invoice at cycle close

The two identifiers do different work. The IMSI decides who pays, because it is the subscription; the MSISDN is what appears on the itemised bill because it is what the customer recognises. Keying on the MSISDN instead breaks the moment a number is ported or recycled.

Stages three and four are where revenue assurance lives. A dropped file is silent — no error, no alarm, simply less revenue — so sequence-gap detection and a reconciliation count between what the element emitted and what rating received is not optional instrumentation, it is the control.

Correlation is the stage candidates omit and the one that produces wrong bills. A single ninety-minute call can generate several partial records, and a naive pipeline rates each as a separate call, applying a per-call connection charge several times. Session identifiers exist precisely to reassemble them, and any correlation window has to tolerate records arriving out of order and hours late.

It converts a usage event into a monetary amount by resolving which tariff applies and applying it. That resolution is the substance: the subscriber's offering, the applicable tariff version at the event time, the event's classification — destination, time of day, roaming status, bearer — any bundled allowance to be decremented before money is charged, then rounding and increments. Increments are where disputes come from: a 137-second call rated in 60-second increments costs three minutes, and whether that is legitimate depends on what the tariff published. The engine also has to be re-runnable, because correcting a mis-rated month means rerating millions of events.

Offline charging happens after the fact: usage is recorded, collected, rated and billed, and the network never waits for an answer. It suits postpaid, where the operator extends credit and reconciles monthly. Online charging happens during the session: the network asks whether to allow the usage and how much to grant before continuing, and enforces the answer. It is required whenever the balance must not be exceeded, which is prepaid, and increasingly for postpaid too — data caps, fair-use throttling and parental limits are all online decisions. The architectural difference is total: one is a batch pipeline, the other is a low-latency transactional service in the call path.

The exchange below is the shape of every credit-control conversation, and it is why prepaid is a real-time system.

sequenceDiagram
    participant N as Network node
    participant O as Charging function
    participant B as Balance store
    N->>O: Initial request, ask for quota
    O->>B: Reserve 60 seconds against the balance
    O-->>N: Granted 60 seconds
    N->>O: Update, used 60, ask for more
    O->>B: Commit 60, reserve the next 60
    O-->>N: Granted 60 seconds
    N->>O: Terminate, used 25 of 60
    O->>B: Commit 25, release the unused 35

Reservation is the entire idea. The network is never told the balance; it is granted a bounded amount of service it may deliver before asking again. That bound is what makes overspend structurally impossible rather than merely unlikely, because the sum of outstanding reservations plus committed spend can never exceed what the subscriber has.

The quota size is a genuine trade-off worth naming. Small grants mean tight control and more signalling — a busy node re-requesting every few seconds for millions of sessions. Large grants mean less signalling and more exposure, since a subscriber with three concurrent sessions each holding a generous reservation has most of their balance locked up and may be denied a call they could afford.

Two failure modes complete the answer. A reservation must expire, because a node can crash while holding one and the subscriber's money must not be stranded indefinitely. And the final message can be lost, so committing usage must be idempotent on a session identifier — otherwise a retried termination debits the same twenty-five seconds twice, which is the kind of error a regulator treats as overbilling rather than as a bug.

Because postpaid can be wrong for a month and corrected before the invoice, while prepaid must be right now, in the call path, at scale. A prepaid decision has a latency budget in the tens of milliseconds, because it sits inside session establishment and a slow answer is a failed call. It must be strictly ordered per subscriber even though the subscriber has concurrent voice, data and messaging sessions on different nodes in different sites. And it must never permit overspend, because there is no invoice to recover it on. Postpaid tolerates eventual consistency; prepaid needs a serialisation point per subscriber, which is why prepaid platforms partition by subscriber.

An authentication, authorisation and accounting protocol used between network elements and control functions — most relevantly the credit-control application that carries the quota conversation above, and the policy interface that decides what quality and what limits a session gets. Conceptually it is a request-response protocol with reliable transport, peer discovery, failover between redundant servers, and extensible attribute-value pairs, so a vendor can add fields without a new protocol. What matters for design is its expectations: sub-hundred-millisecond responses, very high transaction rates, and stateful sessions. In the 5G core the same functions are exposed as HTTP/2 service-based interfaces instead, but the semantics carry over.

A customer on a 30-day cycle upgrades on day twelve, and every line of the arithmetic is a policy decision.

Bill cycle        1 to 30 June, billed in advance on 1 June
Old offering      Plan A   INR 599 per month, already charged in full
New offering      Plan B   INR 999 per month, effective 12 June

Days on A         1 to 11                    = 11 days
Days on B         12 to 30                   = 19 days

Credit unused A   599 x 19 / 30              = 379.37   credit
Charge new B      999 x 19 / 30              = 632.70   charge
Already billed A  599                        = 599.00   charged on 1 June

July invoice
  Plan B in advance, full month              = 999.00
  Credit for unused Plan A                   = -379.37
  Prorated Plan B for 12 to 30 June          = +632.70
  Net                                        = 1252.33

The result is arithmetically simple and operationally contentious, because four conventions had to be chosen before the sum could be done. Whether a 30-day divisor or actual days in the month is used changes the answer in February. Whether day twelve belongs to the old plan or the new decides who pays for it. Whether the change is effective immediately or at next cycle is a product decision that removes the calculation entirely. And whether one-off charges, discounts and taxes prorate is usually decided separately for each.

The reason interviewers ask is that this is where billing systems leak and disputes originate. A credit computed on one convention and a charge on another produces a few rupees of unexplainable difference per changed subscriber, which at scale is both a revenue-assurance finding and a support cost, and neither side of the arithmetic is individually wrong.

Two design points follow. Proration must be derived from an effective-dated subscription history rather than from the current state, because retroactive changes and backdated cancellations are normal and a current-state model cannot recompute them. And the invoice must show the credit and the charge as separate lines: a netted single figure is correct and unexplainable, and an unexplainable invoice line becomes a call to the contact centre.

The staged process for pursuing an overdue balance: reminder, notice, service restriction, suspension, disconnection, then referral to collections and write-off. It is a state machine per account with timers, and it is worth knowing because each transition is both a customer-experience decision and a technical action reaching into the network — a restriction is a policy change, a suspension is a provisioning operation. Regulation constrains it, particularly around emergency calls remaining available and around notice periods. The failure mode is a dunning process that suspends a customer who has paid, because payment allocation and the dunning timer read different state.

Revenue assurance is the controls function that proves usage delivered equals usage billed, end to end, and quantifies the gap. Leakage is that gap, and it rarely comes from fraud. It comes from a mediation file that never arrived and raised no alarm, a product launched without a rating rule so its usage rated at zero, a service activated in the network but never marked billable, a discount applied without an end date, a partner charge inbound that was never passed on, and provisioning fallout that left a service working and unbilled. The characteristic all of these share is silence, which is why revenue assurance is built on reconciliation counts between stages rather than on error monitoring.

When a call crosses from one operator to another, the originating operator owes the terminating one for carrying it, at rates set by agreement or by the regulator. Interconnect settlement rates that traffic in both directions, produces the amounts payable and receivable, and reconciles them against the other operator's own count — which will differ, because two networks never record exactly the same events. It is its own system because the counterparty is an adversary in the arithmetic rather than a customer: disputes are routine, the volumes are large, and a systematic difference of a fraction of a per cent is material money. Wholesale margin lives here.

A subscriber makes a call while abroad, and the visited operator bills the home operator for it in a batch file.

TAP3 call event detail, from visited network MNO-DE, MCC 262 MNC 01

  imsi                  404450123456789
  callEventStartStamp   2026-07-14T20:14:03   utcTimeOffset +0200
  callEventDuration     204 seconds
  chargeableUnits       duration, 60-second increments
  chargeInformation     SDR 0.0180 per minute        inter-operator tariff
  taxInformation        19 per cent, applied by the visited operator
  exchangeRate          1 SDR = INR 112.40           as at the batch date

Wholesale cost to the home operator

  204 s rounded up to increments   = 4 minutes
  4 x SDR 0.0180                   = SDR 0.0720
  plus 19 per cent tax             = SDR 0.0857
  x 112.40                         = INR 9.63 payable to the visited operator

Retail charge to the subscriber

  home tariff, roaming zone 2, INR 65.00 per minute x 4 = INR 260.00
  gross margin on the event                             = INR 250.37

The two-sided nature is the point. Every roaming event is simultaneously a wholesale payable rated by somebody else's tariff and a retail receivable rated by yours, and the systems that compute them are different — settlement on one side, rating on the other. Reconciling the two is where roaming margin is either found or lost.

The currency chain is a real source of error. Inter-operator tariffs are denominated in special drawing rights or euros, converted at a rate fixed for the batch, so the same call costs a slightly different amount depending on when it was settled, and a rounding rule applied at the wrong step moves the total.

The timing is the harder problem. TAP batches arrive hours to days after the event, so a prepaid subscriber abroad could spend a balance they no longer have before the home operator ever hears about it. That gap is why near-real-time fraud reporting exists as a separate obligation, and why prepaid roaming is handled by keeping the charging decision at home — the visited network asks the home charging function in real time instead of reporting later.

The useful axis is not radio technology but what each generation forced on the systems around it.

gen     access and core            voice           architectural change                    demanded of BSS and OSS
------  -------------------------  --------------  --------------------------------------  ---------------------------------------
2G      TDM circuits, GSM          circuit         MSC and HLR, SS7 signalling             CDRs from switches, HLR provisioning
2.5G    GPRS packet overlay        circuit         SGSN and GGSN beside the circuit core   volume-rated data, APN provisioning
3G      UMTS, faster packet        circuit         richer bearers, session concept         session-based charging, QoS in catalogue
4G      LTE, all-IP                VoLTE on IMS    EPC, no circuit domain at all           real-time policy control, online
                                                                                           charging in the session path
5G NSA  new radio on the LTE core  VoLTE on IMS    radio change only                       almost no BSS change
5G SA   new radio, 5G core         VoNR on IMS     service-based architecture, HTTP/2      slice as a sellable product, slice
                                                   network functions, slicing, exposure    inventory, exposure APIs to partners

Two transitions did real work and the rest were increments. The first is the arrival of packet alongside circuit, which introduced usage that has volume as well as duration and a session that can be modified while it runs — a rating model that had never been needed before.

The second is the loss of the circuit domain in 4G. Voice stopped being a separate network and became an application over IP, so the reliability and regulatory obligations attached to voice moved onto a packet core, and charging moved into the session path in real time rather than after it.

5G standalone matters commercially rather than technically for most BSS work. Slicing makes a portion of network behaviour a sellable product, which means the catalogue must express it, inventory must track it, assurance must report on it per slice, and partners must be able to order it through an API. That is a larger change to the systems than the radio was.

A circuit reserves a fixed path and a fixed rate for the duration of a call, so usage is duration and quality is guaranteed by the reservation. A packet network shares capacity statistically, so usage has volume as well as duration, quality becomes a policy applied per flow rather than a property of the path, and a session can change shape while it runs. Every one of those reaches the commercial systems: rating gains a volume dimension and a policy dimension, charging gains mid-session updates, and the catalogue must express quality as a sold characteristic because it is no longer implicit.

The IP Multimedia Subsystem is the control layer that gives voice and messaging over a packet network the things a circuit network provided implicitly: registration, identity, routing between operators, supplementary services such as call forwarding, lawful interception, emergency call handling with location, and charging hooks. It is SIP-based, and its identities — the private and public user identities — are what a subscriber registers with rather than the IMSI directly. It matters in an interview because it explains why "voice is just an app over data" is wrong commercially: the regulatory and interconnect obligations attached to a phone number all live in that control layer.

The Evolved Packet Core is 4G's all-IP core, and four functions are worth naming. The mobility management entity handles authentication and mobility signalling but carries no user traffic. The serving gateway and the packet data network gateway carry it, the latter being the anchor that holds the subscriber's IP address and enforces policy. The policy and charging rules function decides what quality and what limits apply and instructs the gateway. The subscriber data sits in the home subscriber server. The control-plane and user-plane separation across those elements is the structural idea, and it is what 5G took further.

The 5G core replaces point-to-point protocol interfaces with network functions exposing HTTP/2 REST APIs to each other, discovered through a registry, with authorisation between them. Functionally it is the microservice pattern applied to a mobile core: access and mobility management, session management, the user plane, unified data management, policy control and the charging function are separate services rather than boxes with fixed links. What it buys is independent scaling and the ability to insert a function without a new interface specification. What it costs is a distributed system with the observability and version-compatibility problems that implies, in a domain where a failed registration is a customer with no service.

A slice is a logically separate end-to-end network — radio, transport and core — with its own performance and isolation characteristics, running on shared infrastructure. Its significance is commercial: it turns network behaviour into something sellable, so a factory can buy low latency and high reliability rather than bandwidth. That demand lands squarely on BSS and OSS. The catalogue must express a slice as a product with quality characteristics, ordering must be able to request one, inventory must track slice instances and their capacity, assurance must report per slice against a service-level agreement, and partners must be able to do all of that through an API rather than a salesperson.

The radio access network is the antennas, radio units and baseband processing that reach the handset; the core is everything behind it — mobility, authentication, session handling, policy and the path to the internet. The split matters because the two have completely different economics: the radio network is most of the capital cost and is physical and site-bound, while the core is increasingly software on general-purpose hardware. Open RAN is the attempt to define open interfaces inside the radio network so that radio units, distributed units and centralised units can come from different vendors, breaking a single-vendor dependency at the expense of taking on the integration risk yourself.

Network functions virtualisation moved network elements from purpose-built hardware onto virtual machines and then containers on standard servers, which changed operations more than architecture: capacity becomes a scaling decision rather than a procurement cycle, and lifecycle management, orchestration and software supply chain become the operator's problem. Multi-access edge computing pushes compute to the network edge, near the radio, so that latency-sensitive workloads avoid the round trip to a central data centre. Both matter to OSS because inventory must now track things created and destroyed by software, so discovery moves from months to minutes and a static inventory model stops working.

Fault management collects, deduplicates, correlates and presents faults from the network, and drives them to resolution. The distinction being tested is that an event is a notification that something happened at a point in time, while an alarm is stateful: it is raised, it persists while the condition exists, and it is cleared. Treating alarms as events produces two familiar bugs — a console full of conditions that were fixed hours ago because nobody processed the clear, and a flapping link generating thousands of rows instead of one alarm with a count. Statefulness is also what makes correlation and suppression possible at all.

One card fails, and the network reports it from every direction at once.

02:14:07  ROUTER-BLR-CORE-1   card 3 power supply failure
02:14:07  ROUTER-BLR-CORE-1   interface 3/0/1 down
02:14:08  ROUTER-BLR-CORE-1   interface 3/0/2 down
02:14:08  AGG-BLR-11          transport link failure to core
02:14:09  eNB-BLR-4412        backhaul link down
02:14:09  eNB-BLR-4417        backhaul link down
02:14:11  CHARGING-SITE-2     peer unreachable
...
        1,847 alarms in 90 seconds, 214 cell sites reporting

Correlation applied
  topology     every alarming element sits downstream of card 3 in inventory
  time window  all within 20 seconds of the first
  parent rule  interface down is a child of card failure
  result       1 root cause, 1,846 symptoms suppressed, 1 ticket raised
                affecting 214 sites and 41,000 subscribers

The number that changes the conversation is the last line. Correlation is not noise reduction for its own sake; it converts a wall of alarms into a statement of customer impact, which is what decides priority and what the service desk needs before the first call arrives.

Correlation depends entirely on the topology in inventory being correct, and that dependency runs the other way from how people expect. Stale inventory does not raise an error during a storm — it silently fails to correlate, so the operator sees 1,847 alarms on the worst night of the quarter and concludes the correlation engine is useless. Inventory quality is an assurance capability, not a records-management chore.

Two further mechanics complete the answer. Flap damping and deduplication stop a bouncing interface from producing thousands of rows, at the cost of delaying genuine detection by the damping window. And suppression must never hide an unrelated second fault occurring during the storm, which is why correlation is scoped by topology rather than by time alone — a purely time-based rule suppresses the independent outage that happened to start at 02:14 too.

Fault management answers whether something is broken; performance management answers how well it is working, by collecting counters from every element on a schedule — commonly every fifteen minutes — and aggregating them into indicators. The difference in shape matters: faults are sparse, urgent and stateful, while performance data is dense, continuous and analytical, so they need different storage and different tooling. Performance data is what detects degradation that never raises an alarm, which is the majority of what customers actually complain about: a cell that is congested at seven in the evening is not faulty, and a fault-only view will insist the network is healthy.

The indicators are standard. Knowing how each is manipulated is the part that demonstrates you have argued about one.

KPI                        measures                          gamed by
-------------------------  --------------------------------  ------------------------------------
Accessibility              share of service requests that    excluding attempts made in poor
                           establish successfully            radio conditions from the denominator
Retainability, drop rate   share of established sessions     reclassifying a drop as a normal
                           lost abnormally                   release in the counter definition
Handover success rate      mobility between cells            counting only intra-vendor handovers
Average user throughput    delivered rate per user           sampling only when the buffer is
                                                             full, so idle users vanish
Latency                    round trip on the bearer          measuring to the gateway rather
                                                             than to a real internet endpoint
Cell availability          time the cell carried service     excluding planned maintenance and
                                                             any period declared an incident
Busy-hour traffic          load at the peak hour             choosing the busy hour per week
                                                             rather than per day

Every entry gamed the same way: by changing the denominator, the sample or the window rather than the network. That is the general lesson worth stating — a KPI is a counter definition plus an aggregation rule, and both are editable, so a target attached to an indicator without a frozen definition is an invitation.

Aggregation hides the cases that matter. A network-wide accessibility figure of 99.4 per cent is compatible with forty cells at eighty per cent, and those forty cells are where every complaint originates. Worst-cell and percentile reporting exist because the average is structurally incapable of surfacing them, and an operator that reports only averages will be confident and wrong.

The consequence for design is that indicator definitions belong under change control with the counters they derive from, and that any trend comparison must state whether the definition changed inside the window. A step improvement in a KPI on the same date as a software upgrade is a definition change until proven otherwise.

A service-level agreement commits to measurable service quality — availability, latency, restoration time — with financial consequences for missing it, so SLA management means measuring the committed metric per customer, per service, comparing against the threshold, and computing credits. It is hard because the measurement must be defensible to a customer who disputes it, which requires agreeing exclusions in advance: planned maintenance, faults in the customer's own equipment, force majeure. It is also hard because the metric is per service while the network reports per resource, so it depends on the service-to-resource mapping being correct — the same inventory dependency that correlation has.

Trouble ticketing is the workflow that takes a problem from report to resolution, with ownership, priority, history and a resolution code. It joins to fault management from both directions and the join is the interesting part. Network-reported faults create tickets automatically after correlation, so one ticket represents one root cause rather than one alarm. Customer-reported troubles arrive separately and must be matched against known faults, which is what lets an agent say "this is a known outage affecting your area, restoration expected at four" instead of dispatching an engineer. Without that matching, a single outage generates thousands of independent tickets and as many truck rolls.

Automation of radio network configuration and optimisation, conventionally split three ways. Self-configuration brings a new base station into service with minimal manual parameter setting. Self-optimisation adjusts parameters continuously against observed performance — neighbour lists, handover thresholds, power and tilt. Self-healing reacts to a failure by compensating, typically by increasing coverage from surrounding cells. It matters because a network with hundreds of thousands of cells cannot be hand-tuned, and it matters in interviews because it is the clearest place where closed-loop automation meets operational risk: an optimiser acting on incorrect inventory or on a performance regression can degrade a region confidently.

By a couple of orders of magnitude, usually. A large operator generates billions of usage records a day across voice, messaging and data sessions, and each one must be collected, decoded, deduplicated, correlated, rated and retained for a regulated period that is often years. That makes mediation and rating a high-throughput data pipeline with hard correctness requirements, not a back-office job, and it explains design choices that look strange from outside: batch windows, file-level reconciliation, aggressive aggregation before storage, and a separate reprocessing path for the inevitable rerating. A candidate who sizes this aloud is immediately more credible than one who talks about invoices.

Because agreeing that the catalogue is the single source of truth is cheap and the discipline is not. A product manager needs a bundle the model cannot express, so a special case goes into code with a promise to model it properly later. A vendor's rating engine has its own tariff store, so the catalogue becomes an upstream copy rather than the source. An acquisition arrives with a second catalogue that cannot be merged this year. Each is locally reasonable and each reintroduces the drift the catalogue existed to prevent. The honest answer to "how do you do catalogue-driven design" includes how you police it, not only how you model it.

Fine in most of the estate: inventory reconciliation, analytics, notification, even the invoice, because a postpaid bill is assembled over a month and only has to be right at cycle close. Not fine in two places. Prepaid balance decisions cannot be eventually consistent, because there is no invoice on which to recover an overspend, so the charging function needs a serialisation point per subscriber. And resource assignment during ordering cannot be, because two orders eventually agreeing that they both got the last port is a dispatched technician and a missed installation. Naming the exceptions rather than the rule is what the question is for.

Because you cannot stop selling, activating or billing while you migrate, and the population being migrated has years of contractual state — effective-dated subscriptions, part-used allowances, open orders, unresolved disputes, tariffs long withdrawn but still live for someone. So the realistic pattern is running old and new stacks side by side, with new customers on the new stack and a migration programme moving cohorts, which means dual product catalogues, dual provisioning paths, a routing decision on every request, and reconciliation between the two. Anyone who describes a cutover weekend has not done one, and the interviewer asking has.

They are testing whether your architecture makes commercial change a configuration exercise. The strong answer traces the change through every system that must know about it — catalogue definition and pricing, eligibility and bundling rules, order decomposition, provisioning parameters, rating rules, invoice presentation, reporting — and says which of those are data and which would need code. The weak answer is a project plan. The follow-up is always the same and is the real question: which part of that list is code today, and what would it take to move it into the catalogue, because that is the actual state of most estates.

Whether you can see a real-time distributed problem inside an apparently trivial one.

The naive answer
  UPDATE balance SET amount = amount - :cost WHERE sub_id = :id

What is actually happening at the same instant, for one subscriber

  a voice call on MSC-2, rated after it ends
  a data session on UPF-7, consuming volume continuously
  an SMS through a third node
  all three in different sites, none aware of the others

  t0  balance 50.00
  t1  data session bursts, would cost 20.00 if allowed to run
  t2  voice call completes, rated at 42.00
  t3  SMS, 0.50

  Debiting after the fact permits total spend above the balance, and there
  is no invoice on which to recover it.

A strong answer names three things. Reservation, so each session holds a bounded grant and the sum of holds plus committed spend cannot exceed the balance, which makes overspend structurally impossible rather than unlikely. Idempotency on commit, because a lost final message must not debit the same usage twice. And partitioning by subscriber, because there is no distributed transaction across three network nodes, so the charging function has to be the single serialisation point for that subscriber's balance.

It then adds the non-functional envelope, which is the part that rules the naive answer out on its own. The decision sits inside session establishment, so it has a budget of tens of milliseconds; the aggregate rate is tens of thousands of transactions per second; and the store must survive a node dying mid-session without stranding a customer's money, which means reservations carry expiry and are recoverable.

A weak answer substitutes a mechanism for the problem — a row lock, a transaction, or a queue — without noticing that the three sessions are on different systems that will never share a transaction, and without the latency budget that makes a synchronous lock across sites impossible. The tell is whether the candidate reaches for reservation unprompted, because reservation is the idea, and everything else is implementation.