What is Mobile Billing System

In telecom platforms, large subscription businesses (like Rakuten), systems are usually split into:
1. OSS (Operational Support Systems) → network operations, provisioning, monitoring
2. Mobile Billing System/BSS (Business Support Systems) → customers, products, billing, payments, revenue.

Requirements

Functional

1. Monthly data pack subscriptions: Support states(Active, Expired, Suspended, Cancelled)
2. Pack Expiry Handling: When a pack reaches its expiry: Service usage must be blocked, Customer is notified (SMS / Email / App), Account state updated.
  Billing system does NOT directly stop network service → It notifies OSS / Network Control
3. Accept Payments & Renew: System shall accept customer payments & renew
4. Failed Payments: Do not renew pack, Retry payment based on policy, Notify customer
5. Refund & Adjustment: Full, Partial, Manual(policy based)
6. Overlimit Usage: Prevent usage beyond allowed quota. Soft limit (throttle), Hard limit (block)
7. Billing history: Store to show to customer

Non Functional Requirements

1. Scalable: if new customer come in, system should scale
2. High Availability: 99.9%+ availability. Multi AZ deployment
3. Consistency: No duplicate billing
4. Reliable: if billed once, it should not tell not billed recharge
5. Latency: Low, pack activation instant

BOE

OSS(See HLD Diagram) will send CDR(Call Detial Records) in Batch to BSS.
CDRs are send in BATCHES using Kafka from OSS to BSS

CDR ~= 300-500 bytes

| Field           | Reason              |
| --------------- | ------------------- |
| IMSI            | Subscriber identity |
| MSISDN          | Caller number       |
| Called number   | Receiver            |
| Call start time |                     |
| Call end time   |                     |
| Call duration   |                     |
| Cell ID         | Location            |
| MSC ID          | Network element     |
| Call type       | MO/MT               |
| Service type    | Voice/SMS/Data      |
| Cause code      | Call drop, reject   |
| Charging ID     | Correlation         |
| Roaming info    | Tariff impact       |
| Bearer type     | LTE/VoLTE           |
| Sequence number | Dedup               |
      

Storage estimates

Total users = 1M
Total calls/day/user = 30.
Outgoing calls = 15
1M users × 30 calls = 30M CDRs/day
30M x 300 = 9GB/day
9 GB × 365 ≈ 3.2 TB/year
3.2 x 5 ≈ 16 TB / 5 years

Traffic Estimates (Incoming bytes/sec)

5 calls/user/hour
1M × 5 / 3600 ≈ 1389 calls/sec
Incoming data = 1389 × 300 bytes ≈ 416,700 bytes/sec ≈ 407 KB/sec

Peak factor (3x or 5x)
- Telecom traffic is bursty
- Peak ≈ 407KB x 5 = 2 MB/sec
But we will design ingestion for ≥5 MB/sec to be safe.

HLD

Database Tables

Flows

New Subscriber / Subscriber Purchases a SIM card

Person goes to shop and purchases SIM card, makes 1st recharge. This message flows to BSS

OSS                                  BSS
  -- POST subscriber/register -->  REST_EndPoint
      json {                          --------INSERT INTO ------> Subscriber Table
        "imsi": "xxx",                     status=inactive     5 | ram | 25/2 | xxx | yy | inactive | 9jan | 
        "msisdn": "yyy",
        "name": "ram",
        "dob": "1995-11-23",
        "kyc_status": "VERIFIED"
      }
    <------- Registered ---------------
  Connect Plan
  ---- POST /subscription/activate -> BSS(REST_EndPoint)
      json {
        "imsi": "xxx",
        "plan_code": "279_PLAN",
        "payment_ref": "txn_123"
      }
                                      BSS(REST_EndPoint)
                                      // Verify req is not duplicate? (idempotency key)
                                      
                                        -----------payment_ref: "txn_123" ---------> Payment_GW
                                        <------------Pending------------------------
                                        retry for 5 times
                                        <------------ success ----------------------

                                        BSS
                                        -- INSERT INTO ------> Subscription table
      

Verify Payment Status

Why Payment status need to be verified?

User → Payment Gateway / Wallet
            ↓
        Payment System
            ↓
          BSS
        

User will send money to payment gateway and this information will not come to OSS. When recharge is successful Payment Gateway will send this information to OSS asynchronously.

Update Plan from 299_PLAN to 999_PLAN

Only subscription table need to be changed

OSS                      BSS
  -- update_plan -->  REST_EndPoint
                         ----- UPDATE ROW ------> Subscription table
      

Kafka Communication from OSS to BSS

Terms

IMSI(International Mobile Subscriber Identity)

An IMSI number is a unique, 15-digit code that identifies a specific mobile phone subscriber in a cellular network, stored on the SIM card and used for network authentication, distinct from your public phone number.
IMSI = {Mobile Country Code (MCC) + Mobile Network Code (MNC) + and Mobile Subscription Identification Number (MSIN)}

MSISDN