How it really works: network procedures step by step

Tables tell you what exists. This module tells you what happens, in order, and why. Each procedure has the same shape:

1. The story in plain words — what is the problem being solved?
2. Who takes part — the actors.
3. The sequence — a diagram and numbered steps, each with the reason for the step.
4. What can go wrong — where the failures happen and how they look.

Read each one slowly once. If you can retell the story without looking, you understand it.

1. Switching on a phone in 4G (LTE attach)

The story

You press the power button. The phone knows nothing: which network is nearby, whether it may use it, what IP address it should have. In about a second it must find a cell, introduce itself, prove who it is, be told the rules, and be given an IP address. Both sides must also prove themselves: the network checks the SIM, the SIM checks the network.

Who takes part

UE (phone + SIM) · eNodeB (radio) · MME (control) · HSS (subscriber database + keys) · SGW / PGW (data gateways) · PCRF/OCS (policy and charging)

Sequence

 UE            eNodeB          MME             HSS           SGW → PGW         PCRF
  │  1 find cell, read system info │              │               │              │
  │── 2 RRC connection ───────────▶│              │               │              │
  │── 3 ATTACH REQUEST (IMSI/GUTI, capabilities, PDN request) ───▶│              │
  │                                │── 4 S1AP Initial UE Message ▶│              │
  │                                │              │── 5 AIR (get auth vector) ──▶│
  │                                │              │◀─ AIA (RAND,AUTN,XRES,KASME)─│
  │◀──────── 6 AUTHENTICATION REQUEST (RAND, AUTN) ───────────────│              │
  │── 7 AUTHENTICATION RESPONSE (RES) ───────────▶│ compares RES with XRES       │
  │◀──────── 8 SECURITY MODE COMMAND ─────────────│  (ciphering + integrity on)   │
  │── 9 SECURITY MODE COMPLETE ──────────────────▶│              │               │
  │                                │              │── 10 ULR ───▶│               │
  │                                │              │◀─ ULA (profile: APNs, QoS) ──│
  │                                │              │── 11 Create Session Request ─▶ SGW ──▶ PGW
  │                                │              │                         │── 12 CCR ─▶ policy
  │                                │              │◀─ 13 Create Session Response (IP address, QoS) ─
  │◀─ 14 ATTACH ACCEPT (GUTI, IP, default bearer) + RRC Reconfiguration ─────│
  │── 15 ATTACH COMPLETE ─────────▶│──────────────▶│── 16 Modify Bearer ─▶ SGW│
  │═══════════ user data now flows: UE ⇄ eNodeB ⇄ SGW ⇄ PGW ⇄ Internet ═══════│

Step by step — and why

1. Cell search. The phone scans its allowed bands, finds synchronisation signals (PSS/SSS), reads the MIB/SIB broadcast. Why: it learns the network's identity (MCC/MNC), tracking area and access rules before saying anything.
2. PLMN selection. It prefers the home network; if none, it picks a roaming partner from the SIM's list. Why: the SIM tells the phone which networks are preferred and which are forbidden.
3. Random access and RRC connection. The phone sends a short burst (preamble), receives an allocation, then asks for an RRC connection. The first NAS message Attach Request rides inside it. Why: the radio link must exist before the core is contacted.
4. eNodeB chooses an MME and forwards the request (S1AP). Why: the eNodeB knows radio, not subscribers.
5. If the phone sent a GUTI (temporary ID) the MME may fetch the identity from the old MME; otherwise it asks for the IMSI. Why: the real identity is needed to find the subscriber, but sending IMSI over the air is avoided when possible (privacy).
6. Authentication vectors are requested from the HSS (AIR → AIA). The vector contains RAND (random), AUTN (network's proof), XRES (expected answer), KASME (master key). Why: only the HSS and the SIM share the secret key; the MME gets derived values, never the key.
7. Challenge. MME sends RAND + AUTN. The SIM computes using its secret key: it first verifies AUTN (the network is genuine) and then computes RES. The MME compares RES with XRES (the subscriber is genuine). Why: mutual authentication defeats fake base stations — a 4G improvement over 2G where only the phone was checked.
8. Security mode. Keys for integrity protection and ciphering are derived and switched on. Why: everything from here on (including the IP address) is protected.
9. Location update with the HSS (ULR/ULA). The MME tells the HSS "this IMSI is now served by me"; the HSS replies with the subscription: allowed APNs, default QoS (QCI, ARP), AMBR (speed cap). The HSS also cancels the subscriber at the previous MME (CLR). Why: the HSS is the single source of truth about who is where and what they are allowed to do.
10. Session creation. MME picks an SGW and PGW (using DNS with the APN name) and sends Create Session Request. The PGW allocates the IP address, asks the PCRF for policy rules (Gx) and, for prepaid, the OCS for credit. Why: the PGW is the doorway to the internet and must know the rules and the quota.
11. Accept. The MME answers with Attach Accept: new temporary identity (GUTI), tracking-area list, default bearer (QCI 9) and IP. The eNodeB reconfigures the radio bearers.
12. Completion. The phone confirms; the MME tells the SGW the eNodeB's tunnel address (Modify Bearer). Why: the SGW must know where to send downlink data.
13. If VoLTE is configured the phone opens a second PDN connection (APN ims) and registers in IMS (see procedure 5).

What can go wrong

2. Switching on a phone in 5G (registration and PDU session)

The story

5G splits what 4G did into two clear actions: Registration (the network knows you and tracks you) and PDU session establishment (you get a data connection). The core is a set of small services (AMF, AUSF, UDM, SMF, UPF…) that call each other like web services.

Sequence

 UE         gNB          AMF         AUSF     UDM      SMF       UPF       PCF
  │─RRC────▶│            │            │        │        │         │         │
  │── REGISTRATION REQUEST (SUCI = concealed identity, slice request) ──▶│    │
  │          │── NGAP Initial UE ──▶│                                         │
  │          │            │── Nausf: authenticate (SUCI, serving network) ─▶   │
  │          │            │            │── Nudm: generate auth data ─▶│        │
  │          │            │            │   (UDM de-conceals SUCI → SUPI)       │
  │◀─────────────────── AUTHENTICATION REQUEST (RAND, AUTN) ─────────│        │
  │──────────────────── AUTH RESPONSE (RES*) ─────────────────────▶│ verify   │
  │◀── SECURITY MODE COMMAND / COMPLETE ─────────────│                         │
  │          │            │── Nudm: register, get subscription data ─▶         │
  │          │            │── Npcf: get access policy ─────────────────────────▶
  │◀── REGISTRATION ACCEPT (5G-GUTI, allowed slices S-NSSAI, TA list) ──────────│
  │── REGISTRATION COMPLETE ─▶│
  │── PDU SESSION ESTABLISHMENT REQUEST (DNN, slice) ─▶│── Nsmf create ─▶│      │
  │          │            │            │        │        │── Npcf policy ─────▶ │
  │          │            │            │        │        │── N4 PFCP session ─▶│ (UPF)
  │◀─────── PDU SESSION ESTABLISHMENT ACCEPT (IP address, QoS rules) ───────│   │
  │═══════════════ user data: UE ⇄ gNB ⇄ UPF ⇄ Internet ═══════════════════════

Step by step — and why

1. SUCI instead of IMSI. The phone encrypts its permanent identity (SUPI) with the home network's public key and sends the result (SUCI). Why: a fake base station that asks "who are you?" gets unreadable data.
2. AMF picks an AUSF; AUSF asks UDM. Only UDM holds the private key to turn SUCI back into SUPI and to generate the authentication challenge. Why: secrets stay in the home network.
3. 5G-AKA. Same idea as 4G (challenge + response, mutual proof) but the home network confirms the result, which stops a visited network from lying about authentication.
4. Subscription and policy. AMF registers with UDM and receives which slices and which DNNs the user may use; it asks PCF for access and mobility policy.
5. Registration Accept. The user gets a temporary 5G-GUTI, a registration area, and the Allowed NSSAI (slices). Notice: no data connection exists yet.
6. PDU session request. The phone asks for a data connection naming the DNN (like APN) and slice. The AMF selects an SMF that serves that slice.
7. SMF gets session policy from PCF, selects a UPF, and installs the forwarding rules over N4 (PFCP). The UPF will anchor the IP address.
8. Accept. The phone receives its IP address and QoS rules; the gNB sets up radio bearers. Data flows through the UPF.

Why this design matters

• Control and user plane separation: the UPF can sit at the edge (near the user) while the AMF/SMF stay central → low latency (MEC).
• Slices are different SMF/UPF/policy combinations chosen at step 6.
• HTTP/2 APIs make functions scale like cloud services.

3. A phone call in 2G/3G (circuit-switched), including roaming

3a. The phone registers (location update)

Story: The network must always know roughly where you are so it can find you for incoming calls. Every phone is in a Location Area (LA). When the phone sees a new LA code, it reports it.

 Phone → BSS → MSC/VLR ───────────────────────────────────▶ HLR (in home network)
  1. Location Update Request (TMSI/IMSI, old LAI)
         VLR: "do I know this phone?"
  2. VLR asks HLR: MAP UpdateLocation (IMSI, my VLR/MSC GT)
         HLR stores "IMSI is at VLR X"; sends InsertSubscriberData (profile)
         HLR also tells the old VLR to forget the phone: CancelLocation
  3. Authentication (RAND/SRES in 2G; RAND/AUTN in 3G), ciphering on
  4. Location Update Accept + new TMSI

Why the HLR is told: the HLR is the only node that always knows which VLR serves the phone, even when it roams across the world.

3b. Phone A calls Phone B (both home, different MSCs)

 A → MSC-A: SETUP (called number)
 MSC-A: checks A in VLR (barring? prepaid? CAMEL?), analyses number
 MSC-A → GMSC-B: ISUP IAM (called, calling, circuit)      ← sets up the line
 GMSC-B → HLR-B: MAP SendRoutingInfo (SRI)               ← "where is B?"
 HLR-B → VLR-B: ProvideRoamingNumber (PRN)               ← "give me a temporary number"
 VLR-B → HLR-B → GMSC-B: MSRN (roaming number)
 GMSC-B → MSC-B: ISUP IAM to MSRN                          ← call now goes to the right MSC
 MSC-B → radio: PAGING for B ... B answers (Paging Response)
 B's phone rings → MSC-B → ISUP ACM (ringing) back to A
 B answers → ISUP ANM → charging starts → voice flows
 hang-up → ISUP REL / RLC → circuits released → CDR written

Why this roundabout path? B might be anywhere in the world. The dialled number is only an address of the home network. Only the home HLR knows the current MSC, so every incoming call must ask it. The temporary MSRN is a number valid for just this call, borrowed from the visited MSC's range.

What the subscriber and the network experience

4. A VoLTE call from end to end

The story

VoLTE is a normal phone call, but instead of a circuit, voice is sent as IP packets. Before you can call, the phone must (a) have a special data connection for IMS, (b) register with the IMS so the network knows where to find you, and (c) the network must reserve quality for the call.

Part 1 — IMS registration (done once after attach)

UE ── REGISTER ──▶ P-CSCF ──▶ I-CSCF ──▶ (asks HSS who serves this user) ──▶ S-CSCF
         ◀── 401 Unauthorized (challenge) ◀──────────────────────────────── (auth vector from HSS)
UE ── REGISTER (response computed with SIM) ──▶ ... ──▶ S-CSCF checks → 200 OK
S-CSCF downloads user profile from HSS and registers the phone with the Telephony Application Server (TAS)

Why twice REGISTER? The first is refused with a challenge; the phone answers with its SIM-based proof. Same pattern as authentication in the radio network.

Part 2 — The call

Caller UE                  IMS (caller side)                  IMS (callee side)               Callee UE
   │── INVITE (SDP: codecs AMR-WB/EVS, IP, ports, "I need QoS") ─▶ P-CSCF → S-CSCF → TAS ──▶ ... ──▶ P-CSCF ──▶ │
   │◀── 100 Trying ─────────────────────────────────────────                                    │
   │                        P-CSCF asks PCRF (Rx): "prepare QoS for audio"                        │
   │                        PCRF → PGW (Gx): create dedicated bearer (QCI 1, guaranteed bit rate) │
   │◀── 183 Session Progress (SDP answer: chosen codec)  ◀───────────────────────  callee side also prepares bearer
   │── PRACK / UPDATE ("my bearer is ready") ─────────────────────▶                              │
   │◀── 180 Ringing ◀─────────────────────────────────────────────  callee phone rings          │
   │◀── 200 OK (answered) ◀──────────────────────────────────────────────────────────────────── │
   │── ACK ─────────────────────────────────────────────────────▶                               │
   │◀════════════ RTP voice packets both ways on the QCI 1 bearer ═════════════════════════════▶│
   │── BYE ─────────▶ 200 OK                   bearer released, CDR written, charging closed

Step by step — and why

1. INVITE carries an SDP "offer": codecs the phone supports, the IP/port for audio, and a statement that quality must be guaranteed (preconditions).
2. P-CSCF → PCRF (Rx): the IMS tells the policy system "an audio call needs 24 kbit/s guaranteed". PCRF orders the PGW to create a dedicated bearer, QCI 1. Why: data traffic must not be able to starve the voice.
3. 183 Session Progress returns the callee's chosen codec; both sides reserve resources before ringing. Why: otherwise the call could ring and then fail because there was no capacity.
4. Ringing and answer; ACK completes the handshake. The audio now travels as RTP packets (each ≈20 ms of voice).
5. During the call: RTCP reports quality, a handover may occur on LTE; if LTE coverage ends, SRVCC hands the call to 2G/3G.
6. BYE ends the call; bearer removed; charging record closed.

If the callee is on a circuit network

The IMS sends the call through an MGCF + media gateway, which translates SIP ⇄ ISUP and RTP ⇄ TDM, so VoLTE users can call anyone.

5. Handover — moving a call without dropping it

The story

You drive while talking. The phone keeps measuring neighbouring cells. When another cell is clearly better, the network must move the connection before the old one gets too weak, without the user noticing.

LTE handover over X2 (the common, direct case)

 UE            Source eNB            Target eNB             MME / SGW
  │── Measurement Report (neighbour is better) ─▶│
  │            │── 1 decides handover                          │
  │            │── 2 X2 Handover Request ─────────▶│ target checks capacity, prepares
  │            │◀─ 3 Handover Request Ack (new radio config) ──│
  │◀── 4 RRC Reconfiguration (go to target, new C-RNTI) ───────│
  │            │── 5 forwards buffered data to target ────────▶│
  │── 6 random access to the target, RRC Reconfig Complete ───▶│
  │            │                       │── 7 Path Switch Request ─▶ MME
  │            │                       │            MME → SGW: Modify Bearer (new eNB address)
  │            │                       │◀─ 8 Path Switch Ack
  │            │◀── 9 UE Context Release ──────────────────────│

Key ideas - Make before break: target is prepared before the phone leaves (hard handover still has a tiny gap; soft handover in 3G uses two cells at once). - Data forwarding avoids losing packets in the gap. - Path switch tells the core where to send downlink data now. - If X2 doesn't exist, the same happens via the MME (S1 handover). - Inter-RAT (IRAT) handover (e.g. LTE → 3G) also moves the voice call (SRVCC).

Why handovers fail

6. Roaming — using your phone abroad

The story

You land in another country. Your phone attaches to a foreign (visited) network that has a roaming agreement with your home network. The visited network does the radio and local switching; the home network still holds your identity, keys, and the bill.

Sequence (4G, data and voice)

 Phone ──▶ Visited eNB ──▶ Visited MME ───(Diameter via IPX/DEA)──▶ Home HSS
                                  │  AIR/AIA: authentication vectors from home
                                  │  ULR/ULA: home gives profile + allowed roaming
                                  ▼
                           Visited SGW ═══ S8 (GTP over IPX) ═══▶ Home PGW  → Internet  (home routed)
                                                                    ↑
                                         home PCRF, home charging (Gy/Gz)

1. Steering. The SIM (and network) prefer certain partner networks (Steering of Roaming). Welcome SMS appears.
2. Authentication stays at home. The visited MME never sees your long-term key; it asks the home HSS for vectors across the IPX.
3. Profile with roaming rules. Home HSS may reject (roaming not allowed, cause 8/13/14) or accept.
4. Data path: Home-Routed (HR) — your traffic tunnels back home through the S8 interface to your home PGW. Why: you keep your home IP, home policy and home firewall. Local Breakout (LBO) exits locally: cheaper, but harder to control.
5. Voice: for VoLTE, S8 Home Routed (S8HR): the IMS stays in the home network; or circuit-switched fallback if the partner has no VoLTE agreement.
6. Billing: the visited network writes TAP records for your usage and sends them to your home operator; the home operator pays the partner at wholesale (IOT) rates and bills you at retail. Near-real-time fraud data (NRTRDE) is exchanged too.
7. EU rule: inside EU/EEA you pay home prices ("roam like at home"), but the operators still settle wholesale caps among themselves.

Typical roaming problems

7. SMS — three journeys in plain words

7a. Phone to phone (P2P) — "store and forward"

 Sender ──▶ MSC ──(MO-ForwardSM)──▶ SMSC (stores message)
 SMSC ──(SRI-SM)──▶ HLR : "where is the recipient?"          → IMSI + serving MSC
 SMSC ──(MT-ForwardSM)──▶ MSC ──▶ paging ──▶ recipient phone ──▶ delivery report ──▶ SMSC
 If phone is off: HLR says "absent subscriber"; SMSC keeps the message;
                  when the phone comes back, VLR/HLR tell the SMSC (Alert-SC) and it retries.

Why store-and-forward: the recipient may be off, out of coverage or roaming; the post office (SMSC) waits.

7b. Business to phone (A2P)

 Company app ──(SMPP bind + submit_sm)──▶ SMSC/aggregator ──▶ routing decision
     (cheapest legitimate route, number-portability lookup) ──▶ destination SMSC ──▶ phone
 Delivery receipt returns: DELIVRD / UNDELIV / EXPIRED / REJECTD

Why aggregators: a bank needs to reach every operator; aggregators connect to many. Cheap routes can be grey routes (SMS FW detects).

7c. SMS in 4G/5G

Without circuits, SMS travels either inside NAS signalling (via an SMSF/SGs link to the MSC) or over IMS as SIP MESSAGE (IP-SM-GW). The idea remains store-and-forward in an SMSC.

8. A data session through its whole life

 idle phone ── (data to send) ─▶ Service Request ─▶ radio connection re-established ─▶ bearers active
 browse: DNS query → (operator DNS) → IP of site → TCP/TLS → HTTP
 meanwhile: PGW/UPF counts bytes; PCRF enforces speed cap; OCS decrements credit (Gy/Chf)
 no activity for ~10 s → radio connection released (RRC IDLE), core keeps the session
 incoming packet for idle phone → SGW Downlink Data Notification → MME PAGES the phone → Service Request
 leave tracking area → Tracking Area Update (TAU)
 power off → Detach → sessions deleted, final charging record

Why idle state? It saves battery and radio capacity: the radio part is dropped while the core remembers you, and paging wakes you up.

9. An emergency call (112)

 Dial 112 → phone selects any available network (even a foreign one, even without SIM = "limited service")
          → special emergency attach (no authentication needed in limited service) with emergency bearer
          → INVITE/SETUP with emergency indicator → network routes to the PSAP of that location
          → phone sends AML location (GNSS/Wi-Fi) by SMS/data; network also supplies cell-based location
          → PSAP operator hears the caller; if the call drops the PSAP can call back

Priorities: emergency calls skip barring, prepaid checks, and can pre-empt other calls.

Remember this: every procedure is the same four-beat rhythm — find the subscriber (identity/location) → authenticate (prove it's real) → authorise (what's allowed, policy) → connect and charge (create the session, count usage). Once you see the rhythm, a new procedure is just new names for the same story.