5G registered but no data? Match the PDU Session evidence first

KIHONG STORY LAB · PRACTICAL LEARNING

Registration, session establishment and a successful application response are three different outcomes. Here is how I keep them separate.

5G registered but no data? Match the PDU Session evidence first

A UE appears registered, but its application cannot exchange data. My first question is not “which side is broken?” It is “what does this trace actually establish?” Registration success does not, by itself, prove that a PDU Session or a working service path exists.

Video walkthrough
Watch the 5G troubleshooting walkthrough: registration, PDU Session and service evidence.

A small case with an important missing fact

This instructor-authored teaching example contains an established RRC connection, Registration Accept, Registration Complete in this particular case, and a PDU Session Establishment Request. Application data is unavailable. The supplied extract does not show a matching Accept or Reject, and its capture completeness is unknown.

Observed: a session request was recorded.
Not established: the matching response, a rejection cause, or end-to-end data success.
A response missing from an extract is not proof that the network rejected or never received the request.

This is a simplified teaching case, not a customer trace, an equipment lab result or a company interview question.

First, match the transaction

I correlate the request and response using the PDU Session ID and PTI, together with the relevant capture interval. I also compare the DNN, S-NSSAI and requested Session Type. The session identifier and the procedure transaction identifier have different jobs; proximity on a timeline is not sufficient to match messages.

If the matching Reject is available, I read its actual cause. If it is not, I leave the cause unknown and request the surrounding exchange or a more complete capture. A useful next step does not require an invented root cause.

Then, distinguish allocation from delivery

With an Accept, I inspect the selected Session Type, applicable address information and QoS, then the corresponding radio bearer configuration. For an IP-based service, the assigned address and supplied DNS information are useful starting points. I do not assume that every PDU Session uses an IP type.

An allocated IP address and a DNS server address still do not prove that a DNS query received a reply. When actual packets are available, I follow the requests, responses and service connection. With NAS messages alone, I cannot claim a successful response from the application server.

What I would write in the finding

“Registration is evidenced and a session request is recorded. No corresponding response is visible in the provided extract. Verify capture completeness and correlate the matching Accept or Reject before assigning a cause.” This separates the observation from the next verification.

I also avoid treating Registration Complete as an unconditional final line after every Registration Accept. Its conditions matter. It is included here because it is recorded in this specific example.

Learn the complete device-side flow

My 5G/LTE Call Process: Big Tech Technical Interview Prep course connects LTE, NSA and 5G SA procedures through UE RRC/NAS messages. I bring over 25 years of telecommunications and mobile-device practice to the starting state, key fields and expected response of each step.

The course is for device development and validation beginners, students and practitioners who want an organized call-flow model. It uses diagrams and message examples; it does not promise newly captured NSA/SA lab logs or equipment exercises. View the English curriculum and previews through the course link below.

5G/LTE Call Process: Big Tech Technical Interview Prep

View the curriculum and previews →

The companion video uses English narration. The article is self-contained.

3GPP TS 24.501 / ETSI

Comments

Post a Comment

Popular posts from this blog

Vibe Coding and AI Agents: A 30-Day Project Diary

Prologue: From a personal dashboard to content projects, starting with a $20/month AI subscription Building an AI one-person content studio with ChatGPT, Codex, and human judgment Turning one idea into a finished result requires more roles than it first appears. Someone has to define the problem, break the work into tasks, create the files, review the result, and decide what should happen next. This series documents how I ran that process as an AI-agent collaboration using ChatGPT and Codex. I set the direction and quality bar. ChatGPT structured the requirements and content. Codex handled execution at the level of code, files, documents, and production packages. The first proof case was a personal asset-management automation system. I then applied the same operating model to YouTube Shorts, webtoons, motion comics, blogs, and a future book. The result is becoming a multi-channel publishing system for an AI one-person content studio. Why I started The project did not begin with a grand...
Read more

From Webtoon to Novel: Adapting One Story Across Formats

Image
The creative background behind Learning to Take My Place, from visual storytelling to a published novel What a one-person AI studio taught me about expanding an IP instead of copying it I did not set out to make a film or write a novel. The original plan was much smaller: spend thirty days finding out what a non-developer could actually build with a $20 monthly AI subscription, then turn the experience into a book. The project refused to stay inside that book. One of its lessons became a webtoon. An incident in the webtoon became a motion comic, then a three-minute, fifty-three-second short film. The same characters eventually moved into an eighteen-chapter workplace thriller. From the outside, it may look as if I made one thing and reused it several times. The opposite was true. The moments that failed most often were the ones where I trusted an existing asset to work in a new medium without rebuilding it. Episode 6 opens with a question rather than an explanation: if the accident nev...
Read more

VoLTE Call Connected but No Audio? Check SIP, SDP, and RTP Separately

Image
  A connected-call indicator does not prove that usable audio is reaching the listener. I separate three questions: was the session established, what media conditions were negotiated, and what packets actually arrived? That separation helps narrow down a VoLTE no-audio problem without guessing the cause. 1. Which request received the 200 OK? SIP controls session establishment, modification, and termination. A 200 OK for REGISTER is different from a 200 OK for INVITE. Identify the call using its Call-ID and CSeq, then correlate the successful INVITE response with its ACK. This is evidence about call setup; it is not evidence that speech reached either listener. 2. Read SDP as receive destinations and media conditions Compare the offer and answer currently in effect: audio receive addresses, ports, codecs, and direction. If an UPDATE or re-INVITE changed the session, the initial SDP alone is insufficient. c= : connection address. A media-level c= overrides the session-level add...
Read more