Historical project notes: This article describes an earlier version of my telecom projects. Interface steps, coverage counts and sample outputs may differ from the current 3GPP Pilot. The examples are engineering illustrations, not evidence of client deployments.
3GPP specifications are essential but notoriously hard to navigate. A single procedure like 5G initial registration spans four separate specs across two series (24.501, 23.502, 38.413, 38.331) — and finding the right clause without knowing the structure takes hours with PDFs.
This article walks through five real questions a telecom engineer might ask, showing exactly what 3GPP Clause Search returns — the raw clause hits, the AI-synthesised explanation, and the generated procedure flow.
Scenario 1 — NR RRC Connection Establishment
Query
"How is RRC connection establishment triggered in NR 5G?"
What the search returns
Top results surface directly from TS 38.331 — the NR RRC spec — ranked by procedure relevance. The top match is §5.3.3 RRC connection establishment (procedure_step content type), followed by the initiation sub-clause §5.3.3.1, the RRCSetupRequest message definition at §6.2.2, and §5.3.3.4 covering the UE actions on receiving RRCSetup. The MAC-layer random access clause from 38.321 §9.1.1 also appears, since RACH is the transport trigger.
Notice that 38.300 (NR architecture overview) does not dominate even though it contains many mentions of "RRC connection" — the intent-aware ranking correctly promotes procedure-step clauses over architecture overviews for this type of query.
AI Explanation
The Explain with AI response synthesises the retrieved clauses into a structured answer covering: the trigger (UE in RRC_IDLE with upper-layer data or paging), the three-message exchange (RRCSetupRequest → RRCSetup → RRCSetupComplete), the key IEs (establishmentCause, SRB1 configuration, the NAS container in RRCSetupComplete), and the default configuration reference at §9.2.1. Every claim is inline-cited to the clause it came from.
Procedure Flow
The generated flow shows a 3-column message diagram (UE ↔ gNB ↔ AMF) with six annotated steps spanning three specs: the RACH exchange from 38.321 §5.1, the three RRC messages from 38.331 §5.3.3, and the Initial UE Message from 38.413 §8.6 that carries the NAS registration request to the AMF. This cross-spec span — from MAC layer through RRC to NGAP — in a single flow is what would take 30+ minutes to assemble manually from PDFs.
Specs covered: TS 38.331, TS 38.321, TS 38.413
Scenario 2 — NR Xn-Based Handover
Query
"What triggers an Xn-based handover in NR and what messages are exchanged?"
What the search returns
The search correctly routes to procedure specs, not the architecture overview. Top results are:
- TS 38.300 §10.3.2 — Handover preparation (architecture level, but specifically the handover procedure section)
- TS 38.331 §9.2.3 — Handover execution: the
MeasurementReporttrigger and the Event A3 condition - TS 38.423 §8.9.1 — XnAP Handover Resource Allocation: the
Handover Request/Handover Request Ackexchange between gNBs - TS 38.331 §5.4.2 — RRC Reconfiguration including
mobilityControlInfo
The key architectural insight here is that XnAP (38.423) and RRC (38.331) both appear, correctly showing the interface-level and UE-level parts of the same procedure. The S1AP/NGAP path-switch step from 38.413 also surfaces as a related result.
AI Explanation
The explanation covers: the Event A3 measurement trigger, the 6-step message sequence (Measurement Report → HO Request → HO Request Ack → RRCReconfiguration → RACH in target → Path Switch to AMF), the role of mobilityControlInfo in RRCReconfiguration, and why the UE doesn't know the target cell identity until it receives the reconfiguration message. Cross-spec reasoning across 38.331, 38.423 and 38.413 would take significant manual cross-referencing.
Specs covered: TS 38.331, TS 38.423, TS 38.413, TS 38.300
Scenario 3 — 5G NR Initial Registration (5GMM)
Query
"How does 5G NR initial registration work in 5GMM?"
What the search returns
This is a cross-series query — "registration" spans RAN, NAS, and Core specs. The results correctly span all three:
- TS 24.501 §5.5.1.2 — Initial Registration in 5GMM (NAS-level, what the UE sends)
- TS 23.502 §4.2.2.2 — Registration procedure (network-level: AMF flow, UDM invocation, PDU session setup)
- TS 38.413 §8.7.1 — Initial UE Message over N2/NGAP (how the gNB forwards NAS to AMF)
- TS 24.501 §6.1.3.1.1 — 5GMM-REGISTERED state definition
The fact that a single plain-English query surfaces procedure clauses from three different spec series (24-series NAS, 23-series architecture, 38-series RAN) in a single ranked list is the core value — the tool understands that "registration" in 5G is a multi-layer procedure, not a single-spec concept.
Why this matters
Engineers working on UE implementation need 24.501 (what the UE sends). Network-side engineers need 23.502 (what the AMF does). RAN engineers need 38.413 (how the gNB handles it). Previously, finding all three required knowing which spec to look in and manually cross-referencing. A single search now covers all three perspectives.
Specs covered: TS 24.501, TS 23.502, TS 38.413
Scenario 4 — LTE EPS Attach and TAU
Query
"What is the LTE EPS attach procedure and how does TAU work?"
What the search returns
The "LTE" keyword and the "attach" / "TAU" terms correctly route the search to the LTE Core (24/23-series) and LTE RAN interface (36-series) specs:
- TS 24.301 §5.3.2.1 — EPS attach procedure (NAS-level, EMM-DEREGISTERED state trigger, Attach Request IEs)
- TS 24.301 §5.3.3 — TAU procedure (TA-Change trigger, TAI list check, TAU Request IEs including EPS bearer status)
- TS 23.401 §5.10.1 — Attach procedure (MME-level: identity validation, authentication, default bearer activation, Attach Accept)
- TS 36.413 §8.6.1 — S1-MME Initial UE Message (eNB to MME forwarding of the initial NAS PDU)
This query demonstrates the LTE spec family routing: the same "initial registration" concept uses completely different specs in LTE (24.301 EMM, 23.401, 36.413 S1AP) vs 5G (24.501 5GMM, 23.502, 38.413 NGAP). The search correctly returns LTE-specific clauses rather than mixing in NR results.
Specs covered: TS 24.301, TS 23.401, TS 36.413
Scenario 5 — 5G PDU Session Establishment
Query
"How does 5G PDU session establishment work end-to-end?"
What the search returns
PDU session establishment is a 5G Core procedure that involves NAS, AMF, SMF, UPF, and the gNB. Results correctly span all relevant specs:
- TS 23.502 §4.3.2.2.1 — UE-requested PDU session establishment (system-level flow: UE → AMF → SMF → UPF)
- TS 24.501 §6.4.1 — PDU Session Establishment NAS procedure (what the UE sends: PDU session ID, type, S-NSSAI, DNN)
- TS 29.502 §5.2.1.2 — SMF-initiated PDU session modification (SMF ↔ AMF N1N2 interface)
- TS 38.413 §9.3.4 — PDU Session Resource Setup over N2/NGAP (how AMF instructs the gNB to allocate DRBs for QoS flows)
This scenario shows the full vertical stack — from what the UE sends (24.501) to how the core network orchestrates SMF/UPF selection (23.502) to the SMF-level API (29.502) to the RAN resource allocation (38.413). That is four specs from three different series in a single search. The generated procedure flow would show the complete UE ↔ gNB ↔ AMF ↔ SMF ↔ UPF message sequence with every step cited.
Specs covered: TS 23.502, TS 24.501, TS 29.502, TS 38.413
What these scenarios show
Across all five examples, the same pattern emerges: real telecom procedures don't live in a single spec. They span RRC ↔ MAC ↔ interface protocols ↔ NAS ↔ architecture specs in ways that make manual PDF navigation slow and error-prone. The key capabilities demonstrated are:
- Intent-aware ranking: procedure queries surface procedure-step clauses, not architecture boilerplate — even when overview specs like 38.300 contain many matching keywords.
- Cross-spec retrieval: a single query about "5G registration" spans 24.501, 23.502 and 38.413 in one ranked list — no need to know which spec to search first.
- Technology family routing: "LTE attach" and "5G registration" route to completely different spec sets automatically.
- AI grounding: explanations and procedure flows are built only from retrieved clauses, not from model training data — every claim is citable.
Try it yourself: 3GPP Clause Search is free for signed-in TejVox users.
Comments
Loading comments…