34 Tricky 4G/5G Protocol Interview Questions (Real Scenarios, Not Textbook Definitions)

Q. How does HARQ in 5G NR actually differ from LTE, beyond just "it's faster"?

A. The real structural difference is symmetry. NR HARQ is asynchronous and adaptive on both uplink and downlink — HARQ process ID and redundancy version are explicitly signalled in DCI every time, so a retransmission can land on any later slot with a fresh grant. LTE downlink HARQ already worked this way, but LTE uplink HARQ is synchronous — fixed 8ms RTT timing tied to the subframe number, process ID implied rather than signalled. So the architectural shift NR made wasn't inventing async HARQ — it was extending the flexibility LTE's downlink already had onto the uplink too, at the cost of extra signalling overhead in every single grant.

Q. Walk through how a UE reads SIB1 in 5G vs how it reads SIB1 in 4G — where does the process actually diverge?

A. In LTE: the UE syncs via PSS/SSS, decodes PBCH for MIB (a handful of critical parameters — DL bandwidth, PHICH config, SFN), then reads SIB1 on PDSCH via a fixed, well-known SI-RNTI and a fixed periodic pattern the UE can compute without any further dynamic scheduling info. In NR: the UE syncs via the SSB — PSS/SSS/PBCH bundled as one block, repeated in a burst set for beam-sweeping (a concept LTE never needed, since LTE predates beamformed coverage as a baseline design assumption). NR's PBCH/MIB now has to explicitly include a CORESET#0 configuration pointer — telling the UE exactly where to find the PDCCH search space for SIB1 — because NR's control channel is far more flexible/configurable than LTE's fixed layout, so the UE can no longer just assume a universal fixed location. The core comparison point: LTE's simplicity meant MIB didn't need to describe "where to look next"; NR's flexibility means it does.

Q. RACH in 5G supports 2-step in addition to 4-step — why doesn't LTE have this option, and what's actually being traded away?

A. LTE only ever standardised 4-step RACH: Msg1 (preamble) → Msg2 (Random Access Response) → Msg3 (connection request payload) → Msg4 (contention resolution). NR added 2-step RACH (msgA combining preamble+payload, msgB combining RAR+contention resolution) specifically to cut latency for URLLC and other low-latency use cases that weren't even part of LTE's original 2008 design brief. The trade-off: 2-step needs the UE to already have enough uplink timing/power confidence to send real payload data blind, alongside the preamble, without waiting for RAR-based timing advance first — viable only in good coverage with low mobility. 4-step remains the fallback for cell-edge or high-Doppler conditions, in both generations alike.

Q. How does Cell Reselection actually differ between LTE idle mode and NR idle/inactive mode?

A. The core ranking logic (R-criteria comparing neighbor cell quality against the serving cell, with hysteresis) is conceptually the same in both. What NR adds is an entire extra state to account for — RRC_INACTIVE, which LTE never had — meaning an NR UE can be reselecting cells while still holding suspended RRC context, which affects whether and how quickly it can Resume versus needing a fresh connection at the new cell. NR reselection also has to account for bandwidth part (BWP) and numerology considerations that don't exist in LTE's fixed-numerology design — a candidate cell might support the UE on one BWP but not another, a layer of complexity LTE's simpler two-state (IDLE/CONNECTED) model never had to handle.

Q. What actually IS a CORESET, and why did LTE never need this concept at all?

A. CORESET (Control Resource Set) is NR's way of defining a flexible, network-configurable time-frequency region where PDCCH candidates can be placed — a set of PRBs across 1-3 OFDM symbols, explicitly configured per use case. LTE never needed this because its control region was fixed and implicit: the first 1-3 OFDM symbols of every subframe (the exact count signalled per-subframe via PCFICH) were always the control region across the entire system bandwidth — no configurability, no multiple CORESETs, no per-UE customisation of where control could live. NR introduced CORESET because it needed several genuinely different use cases to coexist on one carrier — URLLC needing small, rapid control regions; eMBB needing traditional wider ones; multiple numerologies at once — none of which a single fixed "always the first few symbols, whole bandwidth" design could serve.

Q. How does a UE know where to decode its DCI?

A. It doesn't scan blindly across the whole PDCCH region. The UE is configured (via RRC) with one or more CORESETs and search spaces — Common Search Space (CSS) for broadcast/common signalling, UE-Specific Search Space (USS) for its own scheduling. Within a configured search space, the exact candidate CCE positions per aggregation level (1/2/4/8/16) are computed using a hashing function (TS 38.213 §10.1) seeded by the UE's RNTI, slot number, and CORESET ID. The UE then blind-decodes each candidate and checks the CRC after descrambling with the expected RNTI — a match confirms a genuine hit, everything else is discarded. So "knowing where" is really three things stacked: configured search space, a deterministic hash that narrows candidates, and CRC/RNTI match as the actual proof.

Q. Can multiple UEs share the same search space?

A. Yes, but only Common Search Space is genuinely shared — Type0 (SIB1), Type1 (RA response), and Type2 (paging) CSS carry broadcast DCI scrambled with common RNTIs (SI-RNTI, RA-RNTI, P-RNTI) that any UE monitoring that CORESET can legitimately decode. UE-Specific Search Space is dedicated per UE by virtue of C-RNTI scrambling — the CCE candidate positions can coincidentally overlap with another UE's USS (the hash doesn't guarantee zero collision), but a UE trying another UE's candidate will fail the CRC check since it's scrambled with the wrong RNTI. So overlap can happen structurally; successful shared decode cannot, outside CSS.

Q. Two UEs get assigned overlapping PDCCH candidates in the same CORESET occasion — how does the gNB avoid a real collision?

A. This isn't solved by the search space hash alone — the hash spreads candidates statistically, but with a finite CORESET, true CCE overlaps at the required aggregation level do happen. When they do, it's a scheduler problem, not a spec-mandated solution: the gNB's MAC scheduler must pick one UE to schedule in that PDCCH occasion and defer the other UE to a different slot or force a different aggregation level, since one set of CCEs can't carry two independent DCIs. This is exactly the kind of question that separates someone who's only read the spec from someone who's actually worked with a live scheduler.

Q. Why does NR use multiple aggregation levels (1, 2, 4, 8, 16) instead of one fixed size?

A. Aggregation level is the network's way of trading capacity for reliability. A UE deep in coverage with a clean channel can decode DCI reliably at AL1 (1 CCE, cheapest, most PDCCH capacity preserved). A UE at the cell edge with poor SINR needs more coded bits to survive — AL8 or AL16 — at the cost of consuming far more of the shared PDCCH resource. The network picks AL dynamically per UE per scheduling occasion based on radio conditions (effectively an outer-loop link adaptation problem for control channel, separate from PDSCH/PUSCH MCS selection).

Q. A UE reports good RSRP but PDSCH decode keeps failing — RSRP alone doesn't explain it. What do you check next?

A. RSRP measures reference signal power, not interference or actual demodulation quality — a UE can have excellent RSRP and still fail to decode if SINR is poor (high interference from neighboring cells reusing the same resources) or if DMRS-based channel estimation is degraded (fast fading, Doppler at high UE speed, or a genuine antenna/calibration fault). The real diagnostic order is: check SINR/CQI reports (not just RSRP) to confirm it's an interference story rather than a coverage story, then check whether the MCS the network selected actually matches the reported CQI — a scheduler using a stale or overly aggressive CQI would explain decode failures even with adequate SINR.

Q. Why can't the UE just always request the highest aggregation level to guarantee reliable DCI reception?

A. Because PDCCH capacity in a CORESET is finite and shared across every UE the gNB is scheduling that slot. If every UE defaulted to AL16, the CORESET would run out of room after only a handful of UEs, starving everyone else of control-channel capacity. Aggregation level has to match actual radio conditions per UE — using more than necessary is a direct, measurable cost to overall cell capacity, not a free reliability upgrade.

Q. HARQ retransmission and RLC retransmission both exist — when would you actually see both trigger for the same data?

A. HARQ (MAC, fast, soft-combining, per-TB) tries a configured maximum number of retransmissions for a transport block. If the channel is bad enough for long enough (sustained fade, blockage) that HARQ exhausts maxHARQ-Tx without success, it reports failure upward. RLC AM then detects the resulting gap via sequence numbers / status report and issues its own retransmission — a fresh transmission attempt that itself becomes subject to a brand-new HARQ process. Seeing both isn't a bug; it's the two-layer recovery design working as intended under a genuinely bad radio event.

Q. Is NR HARQ synchronous or asynchronous, and why does that answer differ from LTE?

A. NR HARQ is asynchronous and adaptive in both directions — the HARQ process ID is explicitly signalled in the DCI every time, so a retransmission can land in any later slot with fresh resource allocation and a different redundancy version. LTE uplink HARQ, by contrast, is synchronous (fixed 8ms RTT timing, implicit process ID from subframe number) — a design carried over from LTE's fixed TTI structure that NR deliberately dropped for scheduling flexibility across variable numerology.

Q. How does the UE know a UL transmission was ACKed when there's no explicit ACK channel for it?

A. Through the NDI (New Data Indicator) in the next grant for that HARQ process. If NDI toggles compared to last time, the network is signalling "previous transmission succeeded, here's new data." If NDI stays the same, it means "retransmit — I didn't get it." The UE never sees an explicit ACK/NACK for UL; NDI toggling is the ACK mechanism.

Q. A UE's DRX cycle is misconfigured too aggressively (very short On Duration) — what's the first KPI that degrades, and why?

A. Scheduling latency / user-plane latency degrades first, not throughput directly — the gNB can only schedule the UE within its On Duration window (plus any active inactivity-timer extension), so a too-short window means the UE simply isn't listening when the network has data for it, forcing delay until the next cycle. If it's severe enough, this cascades into RLC retransmission timers and even RLF if control-plane signalling (like measurement reports) gets delayed past its own timers — but the direct, first-order effect is latency, not raw throughput.

Q. UE has data to send but hasn't been granted UL resources yet — walk through exactly what happens.

A. If the UE already has a valid PUCCH-based Scheduling Request (SR) resource configured, it sends SR to request a grant. If it has NO valid SR resource (or SR is still pending/prohibited by sr-ProhibitTimer), it falls back to Random Access (RACH) purely to request UL resources — a contention-based RACH used as a fallback grant-request mechanism, not for the usual cell-access purpose. Once granted (either via SR response or RACH Msg3 grant), the UE reports a Buffer Status Report (BSR) so the scheduler knows how much data is actually queued, and only then gets an appropriately sized UL grant. Candidates often skip the "no SR resource → fallback to RACH" branch entirely, which is exactly the part interviewers probe for.

Q. Two UEs send a Scheduling Request in the exact same PUCCH resource — is that even possible, and what happens?

A. It shouldn't happen by design — SR PUCCH resources are dedicated per UE via RRC configuration specifically to avoid this collision, unlike RACH preambles which are intentionally contention-based. If it ever does happen (a genuine configuration error, not a designed contention scenario), the gNB would see an ambiguous or garbled PUCCH signal rather than two clean SRs, likely failing to properly detect either — which is why SR, unlike RACH, isn't built with a contention-resolution mechanism at all; it assumes dedicated resources are correctly provisioned.

Q. What's the actual trigger sequence for Radio Link Failure (RLF), and how does it relate to T310/T311?

A. RLF isn't one single event — it's the end of a sequence. The UE's lower layers detect sustained "out-of-sync" indications (N310 consecutive ones), which starts timer T310. If N311 consecutive "in-sync" indications arrive before T310 expires, the timer stops and nothing further happens — a genuine short degradation, not a failure. If T310 expires without recovery, RRC declares Radio Link Failure and starts T311, during which the UE searches for a suitable cell to attempt Reestablishment on. Only if T311 also expires without a successful reestablishment does the UE fall back to RRC_IDLE. The trap candidates fall into: treating "RLF declared" as "connection lost" — RLF declaration is actually the START of a recovery attempt, not the end state. The genuine drop only happens if reestablishment fails too.

Q. What happens if RRC Reestablishment fails?

A. If T311 expires without an RRCReestablishment message, or the network responds with RRCReestablishmentReject, or the target cell fails checks (PCI mismatch, no valid context), the UE falls back to RRC_IDLE and treats it as a full connection failure. The stored security/bearer context from the old connection is not reused — the UE has to run a complete Initial Access from scratch: cell selection, RACH, RRCSetupRequest, and full re-registration if NAS-level context is also lost. Any ongoing call or session experiences a visible interruption, and depending on IMS/VoNR handling, this is a common real-world cause of a dropped call rather than a seamless recovery.

Q. UE is in RRC_INACTIVE — what decides whether it gets a Resume or gets bounced back to a fresh RRCSetup?

A. Resume works when the UE's stored context (I-RNTI + security context) is still valid and the target cell either belongs to the same RNA or can fetch that context (Xn-based retrieval from the anchor gNB, if inter-gNB). If the context has expired, the target can't retrieve it, or something about the resume request fails validation, the network can respond to an RRCResumeRequest with RRCSetup instead of RRCResume — a silent fallback to treating the UE as brand new. From a trace, this looks exactly like: UE sent Resume, got Setup back — that mismatch is the tell.

Q. Why does RRC_INACTIVE exist at all, when the UE could just go straight to RRC_IDLE and reconnect?

A. Cost. Going fully IDLE means dropping all context and paying the full price of Initial Access (RACH, security setup, bearer re-establishment) every single time — expensive in both latency and core-network signalling load, especially for bursty smartphone traffic (short data bursts, long gaps). INACTIVE keeps the UE's context alive at the RAN and lets it resume in a couple of round trips instead, while still letting the UE sleep at IDLE-like power levels. It exists specifically to protect the core network from a signalling storm that constant IDLE↔CONNECTED cycling would cause at scale.

Q. RRCReconfiguration is sent for a handover, but the UE fails to apply it — what does the UE do, and what does the network see?

A. If the UE cannot successfully apply a reconfiguration (e.g., invalid target configuration, sync failure to target cell), it triggers reconfiguration failure handling, which — depending on what failed — typically results in the UE declaring radio link failure and attempting RRC Reestablishment, rather than silently staying on the source cell. The network, meanwhile, sees this as a Handover Failure: it stops receiving the expected RRCReconfigurationComplete on the target and, on the source side (if not yet released), may eventually notice the UE never appeared as expected — this is exactly the kind of event that surfaces in "too late handover" RLF reports.

Q. Security Mode Command is sent but the UE responds with SecurityModeFailure instead of SecurityModeComplete — what does that actually mean, and what happens next?

A. It means the UE couldn't successfully activate the ciphering/integrity algorithm the network selected — commonly because the UE doesn't actually support the selected algorithm (a capability mismatch the network shouldn't have chosen in the first place), or because integrity verification of the Security Mode Command itself failed, which is treated seriously since it could indicate tampering. Either way, the network can't simply retry the same command — the connection is generally torn down and the UE has to reattempt from RRC Setup, since you can't proceed with any protected signalling once security activation itself has failed to establish trust.

Q. Why does 3GPP require the Security Mode Command itself to arrive integrity-protected, given security isn't active yet?

A. Integrity protection on the Security Mode Command uses keys that were already derived earlier in the authentication procedure (from the NAS-level AKA run), even though RRC-level ciphering/integrity haven't been formally "activated" yet for subsequent messages. This closes an obvious attack window — without it, an attacker could inject a fake Security Mode Command proposing a weak or null algorithm before real protection kicks in. The command that turns security on has to itself be provably genuine, or the whole activation step is worthless.

Q. A UE attaches successfully on LTE but repeatedly fails to add a 5G NSA (EN-DC) secondary cell — where do you look first?

A. Since EN-DC addition depends on the LTE eNB (master node) successfully adding an NR SCG via the gNB, first check whether the UE ever sent a qualifying B1 measurement report for the NR neighbor at all — if not, it's a measurement configuration or RF issue on the LTE side, and the eNB never even attempts SCG addition. If the report was sent, check the X2 SgNB Addition Request/Response exchange for an explicit reject cause (commonly capacity/admission control at the gNB, or a UE-capability mismatch where the eNB misreads which NR bands the UE actually supports). If X2 signalling succeeds but the UE still fails, the last place to check is the UE's own RRCReconfigurationComplete (or failure) for the SCG addition — a config the UE itself couldn't apply.

Q. What's actually different between a PDU Session Establishment and an Initial Registration, and why do candidates often mix them up?

A. Initial Registration is UE↔AMF: it establishes the UE's presence and mobility context with the network (comparable to LTE Attach at the MME) — no user-plane data path exists yet. PDU Session Establishment is a separate, later NAS procedure (UE↔AMF↔SMF↔UPF) that actually sets up a user-plane data path with an IP address and QoS flows. Candidates mix them up because in LTE, Attach historically bundled default-bearer setup together with attach in one flow — 5G deliberately split "I exist on this network" from "give me a data path" into two distinct, separately-triggerable procedures, which is a real architectural difference worth being able to state precisely, not just wave at.

Q. A UE moves from 5G coverage back to LTE-only coverage mid-session, on a network with N26 interworking — what actually happens to its session?

A. With N26 present, the AMF and MME can directly exchange UE context, so the UE's 5GS registration and session context are mapped to an equivalent EPS context (5G QoS flows map to EPS bearers) rather than the UE having to fully re-attach from scratch. Without N26 (interworking without N26), the UE has no such direct context transfer and must perform a fresh Attach/TAU on the LTE side, effectively rebuilding its session — a noticeably slower, less seamless experience. Whether N26 is deployed is a real operator decision with real user-experience consequences, not just a spec footnote.

Q. UE's GUTI gets reallocated by the network — why does this happen, and what breaks if the UE misses the reallocation message?

A. GUTI reallocation is primarily a subscriber-privacy mechanism — reassigning a temporary identity periodically so the same UE can't be tracked over time by a fixed identifier over the air. If the UE misses or fails to acknowledge the reallocation (e.g., connection drops mid-procedure), the network and UE can end up out of sync on which GUTI is currently valid; the usual recovery is that the next registration attempt falls back to using the previous GUTI or, if that's rejected as stale, the UE re-identifies using its permanent identity (SUCI/IMSI) instead — a slower path than usual, but wired specifically as the fallback for this exact desync scenario.

Q. How would you actually debug an RRC success-rate drop, step by step?

A. First isolate WHICH RRC procedure is dropping — Setup, Reestablishment, Reconfiguration, or Resume each point in different directions. Then look for a pattern: specific cells/sectors (RF or hardware), specific hours (capacity/congestion), specific UE vendor/chipset (interop bug), or a specific step within the procedure (Msg2/Msg4 of RACH vs the RRC message exchange itself vs security mode command). Pull actual traces for failing attempts and check RACH success first — if RACH itself is failing, the problem is upstream of RRC entirely. If RACH succeeds, look at which specific timer expired (T300, T301, T311) or which explicit reject cause the network returned. Cross-check the timing against any recent parameter push, software upgrade, or new neighbor relation — config-induced regressions are one of the single most common real-world root causes, and far more common in practice than people expect walking into an interview.

Q. A UE won't camp on the network at all — what's your checklist?

A. In rough order: (1) SIM/USIM validity — correct PLMN/HPLMN provisioning, not barred; (2) actual RF presence — is there any signal at all at that location, and does the UE detect ANY cell (cell search issue) versus detecting a cell but failing later; (3) PLMN selection logic — stuck in manual mode, wrong PLMN selected, or roaming restrictions blocking this network; (4) cell/access barring — check SIB1 for cellBarred or access class barring parameters that might legitimately be blocking this UE's class; (5) RACH failure — is the UE attempting random access but exhausting power ramp-up without a response; (6) NAS-level reject — UE might camp fine but get an explicit Registration Reject (illegal UE, not found in HSS/UDM, roaming not allowed), which then drives it to search elsewhere; (7) device-level basics — airplane mode, SIM lock, IMEI blacklist, or a crashed modem, verified from device logs. Good candidates work this list roughly outside-in: physical layer first, then access-layer, then core-layer rejects.

Q. Call drops correlate specifically with handovers between two cells — what do you check first?

A. First check whether the failure is asymmetric — does it fail mostly A→B but not B→A? Asymmetry points at one specific cell/config, not a generic problem. Then trace the handover sequence itself: did the UE receive the RRCReconfiguration (HO command)? Did RACH succeed at the target (usually a dedicated preamble, so failure here often means a real RF or PCI-confusion problem at the target, not congestion)? Were there X2/Xn signalling failures during context transfer, or an admission-control reject at the target due to capacity? Finally, pull the UE's RLF report / Mobility History Information, which explicitly classifies the failure as too-early, too-late, or handover-to-wrong-cell — that classification tells you directly whether this is a timing/threshold-tuning problem (A3/A5 event parameters, time-to-trigger, hysteresis) versus a pure RF or capacity issue.

Q. Throughput is fine but latency-sensitive KPIs (like VoNR MOS score) are degrading — where do you look, given PHY throughput looks healthy?

A. Since raw throughput is healthy, the problem is very unlikely to be pure PHY/MCS — it's almost always scheduling or a real-time recovery mechanism interacting badly with voice's strict jitter tolerance. Check DRX configuration (a cycle tuned for data efficiency can add real latency voice can't absorb), HARQ retransmission frequency specifically on the voice bearer (occasional retransmission is fine for data, but directly audible as choppy audio for VoNR), and whether the voice QoS flow is actually getting the scheduling priority its 5QI implies — a misconfigured QoS mapping can let a "high priority" voice flow get scheduled like best-effort data under load. This is exactly the kind of question meant to test whether you separate "the radio is fine" from "the radio is fine for THIS traffic type," which are genuinely different claims.

Q. You see a UE repeatedly ping-ponging between two cells (A→B→A→B within seconds) — what's the root cause, and how would you fix it?

A. This is a classic handover-parameter tuning problem, not a hardware fault — usually the A3 offset/hysteresis and time-to-trigger between the two cells are set too tight relative to how the RF actually fluctuates at their boundary (a UE sitting near-exactly at the crossover point sees rapid RSRP rank-swapping and triggers a genuine measurement event each time). The fix isn't a code change — it's RF/parameter tuning: increasing hysteresis and/or time-to-trigger for that specific neighbor relation, or in more persistent cases, physically adjusting antenna tilt/azimuth so the true RF crossover point isn't sitting in a high-traffic area. This is a favorite interview question specifically because the "fix" is operational, not protocol-level — testing whether you understand that not every KPI problem is solved by a spec citation.

Q. Paging success rate for a specific UE type drops after a software upgrade on the core network side — what's your first move?

A. Before touching the RAN at all, check whether the paging occasion calculation itself changed — paging occasions are derived from parameters like the UE's ID, DRX cycle, and configured nB/N values, and a core-side software change can subtly shift how these are computed or which TAI list is used, causing the network to page in an occasion or area the UE isn't actually monitoring. Confirming a software-upgrade correlation first (timing lines up with the drop) means you check the AMF/MME's paging logic and configuration diff before assuming an RF problem — chasing radio conditions first, when the timing points straight at the software change, wastes real debugging time.