How it really works: business, service and operational processes

Module 28 explained radio and core procedures. A telecom operator is also a business: it sells SIMs, counts usage, bills, settles with partners, builds sites and reacts to incidents. These processes decide whether the network makes money and stays alive. Same format: story → actors → steps → what goes wrong.

1. From order to working SIM (customer onboarding and provisioning)

The story

A customer walks into a shop (or orders online) and wants a number. Within minutes the SIM must exist in the network, the subscriber record must be in the databases, and billing must know whom to charge.

Steps

1. Identification (KYC). ID is checked (law requires registration of prepaid SIMs in many countries). Why: fraud prevention, lawful requests.
2. Product and number selection. A tariff is chosen; a number (MSISDN) is reserved from a free pool, or an existing number is ported in.
3. SIM allocation. A SIM (ICCID) from the factory batch is linked to the customer. The factory delivered a file of SIM data: IMSI, ICCID, the secret Ki/OPc, PIN/PUK. The keys are loaded by the SIM vendor into the operator's HSS/AuC/UDM securely — they are never typed by a person.
4. Provisioning. The BSS sends an order to the provisioning gateway, which creates records in: HLR/HSS/UDM (IMSI, MSISDN, services: voice, SMS, data, VoLTE, roaming), OCS (balance, rating plan), PCRF/PCF (speed policy), IMS/TAS (voice services), SMSC (SMS profile), billing/CRM (account, invoice address).
5. Activation. The SIM goes "active"; first time it attaches the network proves it matches the HSS.
6. First-use checks. Welcome SMS, settings push (APN/IMS), first-call test.

What goes wrong

eSIM — the same but over the air

 Operator orders profile → SM-DP+ prepares it (encrypted for that device's eUICC)
 Customer scans QR (activation code: SM-DP+ address + matching ID)
 Phone's LPA → contacts SM-DP+ (mutual authentication with certificates)
 Profile downloaded, installed in the eUICC, enabled → phone attaches with new IMSI

Why it's secure: the profile is encrypted for that one chip; stolen QR codes are a risk (hence one-time use and confirmation codes).

2. Number portability — keeping your number when you change operator

The story

The number prefix (e.g. 91, 98) used to identify the operator. After portability a number can belong to any operator, so every call and SMS must first check where the number lives now.

The porting process

1. Customer asks the new (recipient) operator to port the number, signs the request.
2. Recipient sends a porting request to the donor (old) operator or the central porting system. Donor validates (ID, contract, outstanding debts, timeframe).
3. Agreed porting date/time (regulated; often within a working day).
4. At the date: donor stops serving the number, recipient activates it, and the central database / routing tables are updated at the same moment.
5. Routing impact: other operators' networks now find the right target: - Calls: onward routing or all-call-query to the porting database, then route to the new operator. - SMS: MNP-SRF (relay at donor) or HLR lookup by the sender's SMSC.
6. Cleanup: SIM changes, old subscription ends, billing closed.

Where it breaks: database not updated everywhere → messages go to the old operator ("unknown subscriber"); porting windows missed; wrong routing in aggregators.

3. SIM swap — the legitimate process and how fraud abuses it

Legitimate steps (lost phone, new SIM)

1. Customer asks for a replacement in shop or online.
2. Verification (ID, security questions, PIN, previous number).
3. Operator assigns a new SIM (new ICCID/IMSI) to the same MSISDN.
4. In the HSS/UDM the old IMSI is deactivated and the new one linked to the number; old SIM stops working within minutes.

How attackers exploit it

They pass the verification (social engineering, forged ID, bribed employee) and the process moves the victim's number to their SIM → receives SMS codes and calls.

Defence in the process

• Stronger verification and cooling-off (high-risk actions delayed or double-checked).
• Alert to the old phone/email: "Your SIM was swapped".
• Port-out PIN.
• SIM-swap check APIs for banks (they ask the operator "was this number's SIM changed in the last X days?").
• Employee monitoring and limited rights.

4. Prepaid / online charging — how a call or session is paid in real time

The story

With prepaid, the network must know the balance before and during the service. The call can't be charged later: the customer might have no credit left.

Sequence (4G/IMS, Diameter Gy/Ro; 5G uses CHF; 2G/3G used CAMEL)

 Service start (call/data) ──▶ network node (MSC / PGW / UPF)
 Node ── Credit-Control-Request (INITIAL, who, what service) ──▶ OCS
 OCS: finds account, rates the service (tariff, time of day, destination), checks balance,
      RESERVES an amount (e.g. 5 minutes or 100 MB) and sends back a GRANT
 Node ◀── Credit-Control-Answer (granted units, validity time)
 ... customer uses service, node counts usage ...
 granted units nearly used ── CCR (UPDATE: used X, request more) ──▶ OCS ──▶ new grant
 balance exhausted ──▶ OCS sends "final unit" → node ends the call / throttles / redirects to top-up page
 service ends ── CCR (TERMINATION, total used) ──▶ OCS ── final deduction, releases unused reservation
 node writes CDR ── (for audit and reconciliation)

Why "reserve then confirm"? Several services can run in parallel (a call + data). Reservations stop the account from going negative.

In 2G/3G: the MSC triggers CAMEL → asks the SCP/gsmSCF which tells it how long the call may last, and can cut it off. In prepaid, roaming needs CAMEL support in the visited network.

5. Usage to invoice — the billing chain (postpaid)

 network nodes ── CDR/EDR/charging records ─▶ MEDIATION (collect, clean, deduplicate, convert formats)
 ─▶ RATING (apply tariff: free minutes, bundles, roaming zones, time bands)
 ─▶ BILLING (aggregate per customer, taxes, discounts, one-off charges)
 ─▶ INVOICE (PDF/e-bill) ─▶ COLLECTION (payment, dunning) ─▶ revenue recognised in finance

Wholesale settlement between operators

• Interconnect: operator A's customer calls operator B's customer. A pays B a termination rate (set by regulation for EU mobile/fixed). Both sides count minutes; mismatch → reconciliation.
• Roaming: visited operator sends TAP files to home operator; home pays via clearing house, bills the customer. RAP returns rejected records.
• SMS/A2P and transit: carriers settle per message/minute with price lists; fraud (IRSF, pumping) shows as unusual usage.

6. How a firewall decides — three walk-throughs

A) A legitimate SMS from abroad

1. Foreign SMSC sends SRI-SM for Ana's number. Firewall checks: source GT is a known SMS partner, rate is low → allowed but home routing answers with the home SMS router instead of the real MSC.
2. Foreign SMSC then sends MT-ForwardSM to the home router. Firewall sees a matching earlier request → passes message for spam/spoof checks → delivers internally.
3. Result: message arrives; Ana's IMSI and location were never revealed.

B) A spoofed location update

1. A message UpdateLocation for Ana arrives from a GT in another continent.
2. Firewall looks at Ana's state: her phone attached to a home cell 2 minutes ago; no roaming record. The claimed VLR is physically unreachable in 2 minutes.
3. Rule: Category 2/3 — impossible travel → block, raise alert, log GT and IMSI.
4. Result: the HLR never sees the message; OTP SMS keep going to the real phone.

C) A flood of "where is this number?" queries

1. One partner GT sends 5,000 SRI-SM per minute, almost no real messages after them.
2. Firewall counters: high request rate, low follow-up ratio.
3. Action: throttle or answer every request with the home-routing fake, alert SOC, contact the partner (via GSMA channels) if it keeps happening.
4. Result: the attacker's database fills with useless data; real customers unaffected.

7. Incident response — what happens when something goes wrong

The story

Alarms scream. Is it a hardware failure, a bug after an upgrade, or an attack? Teams must stabilise first, understand later.

The phases

1. Detect. NOC sees alarms/KPI drops, SOC sees anomalous traffic, customers report.
2. Triage and classify. Severity (how many customers? emergency calls affected? security?), assign an incident manager, open a bridge call.
3. Contain. Stop further damage: roll back the change, block malicious sources, isolate affected nodes, switch to backup paths.
4. Diagnose. Traces, logs, recent changes (what changed 1 hour before?), vendor support.
5. Recover. Restore service; verify with test calls/sessions and KPIs; communicate to customers.
6. Report. Regulatory notification — under NIS2: early warning within 24 h, notification within 72 h, final report within a month; emergency-call outages must be reported promptly to the regulator.
7. Learn. Root-Cause Analysis (RCA) and post-mortem (blameless): what failed, why detection was slow, what changes prevent repetition; update runbooks and tests.

Good incident habits

• Change freeze during incidents; one voice for communications.
• Rollback plan before every change.
• Out-of-band access (so you can fix the network when the network is down).
• Practice (tabletop exercises, failover tests).

8. Change management and maintenance windows

Why

Most big outages are caused by the operator's own changes (upgrades, configuration, routing changes). Hence strict process: 1. Request for change (RFC): what, why, risk, rollback. 2. Review and approval (CAB — Change Advisory Board). 3. Test in lab / staging with realistic traffic. 4. Schedule a maintenance window (usually at night; notify customers/partners). 5. Execute in small steps (canary: one node/site first), watching KPIs. 6. Validation (test calls, SMS, data, VoLTE, emergency). 7. Rollback if KPIs degrade; otherwise close the change. 8. Document (configuration database, runbooks).

9. From spectrum licence to a working 5G site (network build lifecycle)

1. Strategy and business case: demand, competition, regulation, budget.
2. Spectrum: apply for or win licences (auction), with coverage obligations.
3. Network design: coverage/capacity planning (Module 20), site list, transport and core dimensioning, vendor selection (RFP).
4. Site acquisition and permits: lease from landlord/TowerCo, construction permits, EMF compliance calculations.
5. Civil works and power: mast/rooftop, cabinets, power supply, batteries, grounding, fibre or microwave link.
6. Installation: antennas, radios (RU), baseband (DU/CU), cabling, GPS/PTP.
7. Integration: connect to the transport network and core; configure IPs, VLANs, certificates, IPsec to the SecGW; neighbour relations.
8. Commissioning and acceptance tests: alarms clear, drive/walk tests, throughput, handover tests, VoLTE/emergency tests.
9. Optimisation: tune tilt, power, handover parameters; SON features.
10. Operations: monitoring, maintenance, capacity upgrades when PRB utilisation passes thresholds.
11. Lifecycle: software upgrades, hardware refresh, decommissioning (2G/3G sunset).

10. A day in the life of a network operations centre (NOC)

11. Lawful interception — how an authorised request is fulfilled

1. A court or authorised authority issues a warrant for a target (number/IMSI).
2. The operator's LI department verifies authenticity and scope.
3. The target is provisioned in the LI system (X1 interface) — only authorised, logged staff can do this.
4. Network nodes (MSC, MME/AMF, SMSC, IMS, PGW/UPF) duplicate the target's signalling/metadata (X2) and, if allowed, content (X3) to the mediation device.
5. The mediation device formats the data and hands it to the agency over a secure handover interface (HI2/HI3).
6. All steps are audited; the operator doesn't see content; the target isn't informed. Security point: LI systems are valuable targets (see Module 27 incident list), so they are isolated and hardened.

Remember this: the network is the stage, but these processes are the plot: sell → provision → authenticate → charge → bill → settle, with change control, incident response and compliance keeping it safe. A fault in any process (e.g. one missing provisioning step) feels to the customer like a "network problem".