Paging in LTE 4G

Introduction

LTE paging is the downlink procedure the network runs whenever it needs to reach a UE that has no active radio connection. It spans two worlds: a core-network trigger (the MME deciding to page and fanning an S1AP Paging out over S1-MME) and an air-interface delivery (each eNB broadcasting an RRC Paging message on the PCCH at a precise, pre-computed instant). It is defined by TS 36.331 for the message contents and TS 36.304 for the idle-mode timing the UE uses to know when to listen.

Paging happens exactly when the UE is in RRC_IDLE — the state where it has released its radio connection to save battery but is still registered with the core (EMM-REGISTERED, ECM-IDLE). It is the entry point back into RRC_CONNECTED for anything mobile-terminated: an incoming voice call, downlink IP data, an SMS, or an SGs page for a circuit-switched fallback call. The same channel also carries cell-wide notices — system-information changes and ETWS/CMAS public warnings.

Because paging is a chain — core decision → S1 delivery → correct Paging Occasion → over-the-air decode → UE response — a failure almost always lives in one specific link. That is why a step-by-step debugging habit pays off: if you know whether the page was even sent, whether it landed at the right occasion, and whether the UE decoded it, you have already narrowed "the UE never rang" down to a small, testable set of causes.

Why paging is needed

Concretely, three facts force paging into existence. First, an idle UE holds no radio context — no C-RNTI, no bearer, no S1 signalling connection — so the eNB literally does not know it is there and cannot address it directly. Second, the core knows the UE only to Tracking-Area granularity, not cell granularity, so it cannot name a single cell to reach it. Third, the UE keeps its receiver off most of the time to save battery, so the network cannot call it at an arbitrary moment. Paging solves all three at once: it broadcasts a wake-up across a whole region, addresses the UE by a temporary identity it will recognise, and does so only at instants the UE has already agreed to monitor.

What LTE Paging Is

When a UE is in RRC_IDLE it has no dedicated radio connection to any cell. The eNB does not track it — it holds no context, no C-RNTI, no bearer. Only the core network knows the UE's rough whereabouts, and only to the granularity of a Tracking Area. So when something needs to reach that UE, the network cannot simply address one cell; it has to broadcast a "please wake up and connect" message across every cell where the UE might plausibly be. That broadcast is paging.

The state distinction matters. The core network sees the UE as EMM-REGISTERED and, for connection management, ECM-IDLE (equivalently CM-IDLE) — there is no S1 signalling connection and no active NAS link to a specific eNB. It is precisely this "known to the core, unknown to the RAN" condition that forces paging: the MME must reach the UE using the only handle it kept, the UE's temporary identity and its registered Tracking Area(s), and it must ask a whole region of eNBs to shout on its behalf.

The Network Side — MME, S1AP and the Tracking Area List

Paging starts in the core. When downlink data arrives at the Serving Gateway for an idle UE, or an incoming voice call needs setting up, the S-GW sends a Downlink Data Notification to the MME, which in turn initiates paging. The MME knows the UE only to the granularity of the Tracking Area(s) it registered the UE in during Attach or Tracking Area Update — the Tracking Area List (TA list). It therefore fans the page out to every eNB that owns a cell in any Tracking Area on that list.

The MME does this by sending an S1AP Paging message to each of those eNBs over the S1-MME interface. That message carries the UE's S-TMSI (the compact temporary identity the UE will recognise), a UE Identity Index Value (used by the eNB to place the page at the correct Paging Occasion — it is IMSI mod 1024), the list of Tracking Areas the eNB should page in, the paging DRX the core knows for this UE, and a CN Domain indicator (PS or CS). A Tracking Area can span many eNBs and many cells, so one paging request from the MME can turn into a broadcast across a wide geographic area — the price of not tracking idle UEs at cell granularity.

Each eNB receiving the S1AP Paging then builds the RRC Paging message and broadcasts it over the air in the cells belonging to the requested Tracking Areas. The eNB uses the UE Identity Index Value together with the cell's broadcast paging parameters to work out the exact frame and subframe at which to transmit, so that the page lands precisely where the target UE will be listening.

If the UE does not respond to the first paging attempt — it may have moved cell, or the radio conditions were poor — the MME can retransmit. A common implementation strategy is to page first only in the last cell/eNB the UE was seen in, then, on failure, escalate to the last Tracking Area, and finally to the whole TA list. This staged approach limits paging load on the radio while still eventually reaching a UE that has roamed within its registered area.

Over the Air — PCCH, PDSCH and the P-RNTI

On the radio side the RRC Paging message travels down the PCCH (Paging Control Channel) logical channel, which is mapped onto the PCH transport channel and ultimately carried on the PDSCH physical shared channel — paging reuses ordinary downlink data resources rather than a dedicated channel. What makes the UE look at that PDSCH allocation is the scheduling PDCCH: its CRC is scrambled with the P-RNTI, a fixed, well-known value of FFFE (hex). Because in idle mode the UE has no C-RNTI, this shared identity is the only address all idle UEs can agree to monitor.

A single RRC Paging message can carry a pagingRecordList of up to 16 PagingRecord entries, so one transmission can page several UEs at once and use the PDSCH resources efficiently. Each record names its target by ue-Identity — either an s-TMSI (for normal MME-initiated paging) or the full imsi (used only for a network-recovery / re-attach case). The UE compares each record against its own identity and reacts only on a match. Every record also carries a cn-Domain (ps or cs) telling the UE which core-network domain triggered the page, which the NAS layer uses when it responds.

Crucially, the same Paging message body also carries three broadcast fields that address no individual UE at all: systemInfoModification (system information is about to change), etws-Indication (an ETWS warning is available), and cmas-Indication (a CMAS commercial-mobile-alert notification is available, via the extension used by later releases). This is why a UE must inspect a decoded Paging message even when none of its PagingRecord entries match — the cell-wide flags may still concern it.

Idle-Mode DRX — When the UE Listens

If the UE decoded PDCCH on every subframe it would drain its battery in idle mode. Instead it uses Discontinuous Reception (DRX): it wakes only at its own Paging Occasion (PO), a specific subframe that falls inside a specific Paging Frame (PF). Between occasions the receiver is off.

The DRX cycle T is the shorter of a cell-wide defaultPagingCycle (broadcast in SystemInformationBlockType2, values rf32/rf64/rf128/rf256, i.e. 32 to 256 radio frames) and any UE-specific DRX value the UE has previously given the core network via NAS. Taking the minimum guarantees that whichever value the eNB uses, the UE is awake at least that often. The parameter nB is broadcast as a fraction of T — from 4T down to T/32 — and controls how many paging subframes exist per cycle: a larger nB creates more Paging Occasions (spreading many UEs across more subframes), a smaller nB concentrates them. From T and nB the UE derives two intermediate quantities, N (the number of paging frames within the cycle) and Ns (the number of Paging Occasions per paging frame). The exact algorithm from TS 36.304 is:

Read it in two steps. First the PF equation picks which radio frames in the cycle are paging frames: the SFN values whose remainder mod T equals (T div N) × (UE_ID mod N). Because N is capped at both T and nB, there are exactly N such frames spread evenly across every cycle of T frames. Second, within the chosen paging frame, i_s selects which Paging Occasion this UE uses: when Ns is 1 the PO is subframe 9 (FDD); when Ns is 2 or 4 the standard maps i_s to specific subframes (e.g. subframes 4 and 9, or 0/4/5/9) via a fixed table in TS 36.304. You need not memorise the algebra — the point is that UE_ID deterministically hashes each subscriber to one PF and one PO in every cycle, and the network runs the identical calculation, so both sides always agree.

Worked intuition: suppose T = 128 frames and nB = T. Then N = min(128, 128) = 128 and Ns = max(1, 128 div 128) = 1. There are 128 paging frames per cycle (one per frame) and one PO in each, so paging load is spread thinly across every frame and the UE's specific frame is SFN mod 128 = (128 div 128) × (UE_ID mod 128) = UE_ID mod 128. Halve nB to T/2 and now N = 64: only every other frame is a paging frame, concentrating the same UEs onto fewer frames.

Why the Network Pages

Not every page is about an incoming call. The RRC Paging message serves several distinct purposes, and the UE reacts differently to each. Only the first actually names an individual UE; the rest are cell-wide flags riding on the same channel.

Mobile-terminated call or data. The most common case: a voice call or incoming IP data has arrived for the idle UE. The PagingRecord carries the UE's s-TMSI and its cn-Domain, and the matched UE responds by requesting a connection so the bearer can be activated and the data delivered.

System information change. Instead of naming a UE, the message sets the systemInfoModification flag. This tells every UE in the cell that the broadcast System Information will change at the next modification period boundary, so UEs should re-acquire the affected SIBs. No specific UE is addressed.

ETWS and CMAS warnings. Public warning systems — the Earthquake and Tsunami Warning System (ETWS) and the Commercial Mobile Alert System (CMAS) — use the etws-Indication and cmas-Indication flags to tell UEs that a warning notification is available. The UE then reads the primary notification in SystemInformationBlockType10 and the secondary notification in SystemInformationBlockType11 for ETWS, or SystemInformationBlockType12 for CMAS. Because warnings are time-critical, a UE that supports ETWS may monitor paging more often than its normal DRX cycle so alerts arrive promptly.

Extended DRX (eDRX) — Sleeping for Minutes

Ordinary idle DRX caps the cycle at 256 radio frames — about 2.56 seconds. For a smartphone that is fine, but for a battery-powered IoT sensor that only needs to be reachable occasionally, waking every 2.56 s is wasteful. Release 13 introduced Extended DRX (eDRX), which lets the UE and the network agree on a much longer paging cycle — up to roughly 43.69 minutes in LTE (and far longer in NB-IoT) — at the cost of higher mobile-terminated latency.

The structure is two-tiered. The long eDRX cycle picks which hyperframe(s) the UE is reachable in, using a formula over the Hyper Frame Number (H-SFN) analogous to the PF equation over the SFN. Inside each reachable window the UE opens a Paging Time Window (PTW) — a short span of a few seconds during which it applies the ordinary idle-mode DRX rules (its normal PF and PO). Outside the PTW the receiver stays off for the whole remainder of the long cycle. So eDRX does not replace the PF/PO machinery; it wraps it in a much longer outer cycle and only lets it run during the PTW.

The trade-off is explicit and is chosen per device. A long eDRX cycle plus a short PTW gives maximum battery life but means the MME may have to hold buffered downlink data (or a paging attempt) until the next window opens, adding up to tens of minutes of latency. This is acceptable for a meter that reports once an hour but not for anything interactive — which is why eDRX is a negotiated, opt-in feature rather than a default.

How the UE Responds

When a UE finds a PagingRecord matching its s-TMSI, it must move from idle to connected to receive whatever triggered the page. It initiates the RRC connection establishment procedure: it performs random access (sends a preamble on PRACH, receives the Random Access Response), then sends an RRCConnectionRequest whose establishmentCause is set to mt-Access (mobile-terminated access). The eNB replies with RRCConnectionSetup, and the UE completes with RRCConnectionSetupComplete.

That completion message carries a NAS Service Request (or Extended Service Request) up to the MME. From the core's point of view the page it sent has now been answered — the UE is reachable, the S1 bearer and radio bearers can be established, and the buffered downlink data or the incoming call is delivered. For a system-information or warning page there is no such response: the UE simply re-acquires the affected SIBs (or reads the warning notification) and stays in RRC_IDLE.

Reading paging in the logs

Paging shows up in two places you can correlate: the eNB's transmission of the RRC Paging at a given SFN/subframe, and the UE's idle-mode decode of that message at its Paging Occasion. The whole "did the UE ring?" question comes down to whether the record's ue-Identity matches and whether the UE then launched an mt-Access connection.

Representative log — illustrative, values vary by vendor/build:

Summary

Paging is the network's only way to reach a UE it deliberately stopped tracking. Walk it as a chain and each link points at a distinct set of causes. The MME decides to page (on a Downlink Data Notification or an incoming call) and sends an S1AP Paging to every eNB in the UE's Tracking Area List — if the page never leaves the core, or the TA list is stale, nothing reaches the air. Each eNB builds the RRC Paging and broadcasts it on PCCH/PCH/PDSCH, scheduled by a PDCCH whose CRC is scrambled with the P-RNTI (FFFE) in the common search space — if the occasion is wrong, the UE is looking elsewhere.

The UE only listens at its own Paging Occasion, computed deterministically from UE_ID = IMSI mod 1024, the DRX cycle T = min(defaultPagingCycle, UE-specific DRX), and nB — both sides run the identical TS 36.304 arithmetic, so a de-sync there is almost always a DRX or index-value mismatch. When the UE matches its s-TMSI in a PagingRecord, it runs RRC connection establishment with establishmentCause = mt-Access and carries a NAS Service Request that lets the MME deliver the data. Isolate which link broke — core trigger, TA coverage, occasion timing, over-the-air decode, or the response — and "the phone never rang" becomes a specific, testable hypothesis.