A smartphone may already show a 5G icon while web pages still refuse to load. When this happens, the first instinct is often to inspect the registration procedure: Did 5G-AKA complete? Was Registration Accept received? Did T3512 expire? After going through those checks, the Registration procedure may look completely normal while data service still does not work.
In many cases, the problem is not Registration but the PDU Session. Registration answers the question, "Can the UE register with the 5GS?" PDU Session Establishment answers the next one: "Can the UE actually reach a data network?" This article follows the PDU Session Establishment procedure from beginning to end—how the UE requests a session, how the AMF selects an SMF, how the SMF retrieves subscription and policy information, how the UPF is configured, and how the N3 tunnel is finally completed.
After the UE completes 5GS Registration, the AMF already has user identity, mobility, security and related subscription context. Registration success, however, does not mean that a user-plane path already exists. The UE may still have no active path to the Internet or an enterprise data network.
PDU Session Establishment is what moves the UE from "registered" to "able to carry application traffic." The UE requests a session, the network selects the SMF and UPF, retrieves subscription data associated with the DNN and S-NSSAI, obtains session policy, installs PFCP rules in the UPF, and coordinates with the gNB to establish the N3 tunnel. At the end of the procedure, the UE has an IP address, QoS rules and a user-plane path toward the Data Network.
The procedure is easier to understand when it is not treated as one isolated NAS message. Three things are happening together: session management, policy control and user-plane resource configuration. They eventually converge into a usable PDU Session.
Functional Boundary Between PDU Session and 5GS Registration
In 5GC, the division between Registration and PDU Session is straightforward: one establishes network registration, while the other establishes data connectivity.
Registration determines whether the UE can enter the 5GS. The AMF verifies UE identity, performs authentication, establishes NAS security, retrieves mobility-related subscription data and creates the context required for RM (Registration Management) and CM (Connection Management). Once these steps are complete, the management relationship between the UE and the core network is established.
A PDU Session is associated with actual data service. If the UE needs Internet access, IMS connectivity or an enterprise private network, Registration alone is not sufficient. The network still needs to determine which DNN is used, which S-NSSAI applies, which SMF controls the session, which UPF carries the user plane, and what QoS and bandwidth parameters are authorized.
Comparing this with EPC makes the distinction easier to remember. LTE uses the concepts of PDN Connection and EPS Bearer. In 5GC, this model is replaced by PDU Session + QoS Flow. After a PDU Session is established, the network creates QoS rules and QoS Flow resources rather than an LTE-style Default EPS Bearer.
Another important point is that a PDU Session does not have to be established at the same time as initial Registration. A UE can complete Registration and remain without a PDU Session until an application actually requires data service. For example, the device may register when it powers on, but the PDU Session may not be created until the user opens a video application half an hour later.
This distinction is useful during trace analysis. If Registration has completed successfully but PDU Session Establishment has not, repeatedly checking 5G-AKA, Registration Accept or T3512 will usually not solve the data-service problem because the investigation is focused on the wrong procedure.
DNN, S-NSSAI and Request Type in the PDU Session Request
PDU Session Establishment begins with a NAS message sent by the UE. A PDU Session Establishment Request does more than simply tell the core network, "I need data access." The information elements carried in the request influence later NF selection and session configuration.
A typical initial request may include PDU Session ID, Request Type, PDU Session Type, SSC Mode, DNN and S-NSSAI.
PDU Session ID distinguishes multiple sessions belonging to the same UE. One UE can maintain several PDU Sessions at the same time—for example, one for Internet access and another for an enterprise private network. SUPI identifies the subscriber, but it does not by itself identify which individual PDU Session is currently being processed.
DNN identifies the Data Network the UE wants to reach. Operator Internet access, IMS and enterprise networks may use different DNNs. The DNN also participates in SMF selection, UPF selection and policy decisions later in the procedure.
S-NSSAI associates the session with a particular Network Slice. The AMF and SMF need to determine whether the requested slice is consistent with the user's subscription, the requested DNN and the deployed network capabilities.
Request Type identifies the context of the request. Besides a new PDU Session, the procedure can also be associated with an existing session, access changes or emergency service scenarios. During trace analysis, the presence of a PDU Session Establishment Request should not automatically be interpreted as the same scenario every time.
The most common case is an Initial Request: the UE has already completed Registration and now creates a new PDU Session for a specific DNN. SMF selection, UDM subscription retrieval, PCF policy control and UPF resource establishment are all driven by this session context.
SMF Selection and SM Context Creation by the AMF
The UE's NAS session-management message first reaches the gNB and is then forwarded to the AMF through NGAP together with access-related information such as NR-CGI and TAI. The gNB does not make PDU Session control decisions; it transports the NAS information toward the core network.
After receiving the request, the AMF needs to identify an SMF capable of serving the requested S-NSSAI and DNN.
In a service-based 5GC architecture, the AMF can use the NRF for NF discovery. Discovery criteria may include the target NF type, the required Nsmf_PDUSession service, S-NSSAI, DNN and serving PLMN. The NRF returns candidate SMF instances, after which the AMF selects the actual serving SMF according to network policy.
The AMF then invokes the SMF's PDU Session service to create an SM Context. In addition to SUPI, PDU Session ID, DNN and S-NSSAI, the request carries the UE's original PDU Session Establishment Request as N1 SM information.
From this point onward, the center of session control shifts from the AMF to the SMF. The AMF continues to manage access and mobility and continues forwarding N1 SM signaling between the UE and SMF, but the SMF is responsible for deciding how the PDU Session is created, which UPF is selected, which policies apply and how the user-plane rules are configured.
One practical point is important during troubleshooting: the number of NRF transactions seen in a commercial network may not exactly match a reference signaling diagram. NF discovery results may be cached, static configuration may be used, or an SCP may provide service routing. The more important question is not whether a particular NRF query appears in the trace, but whether the selected SMF actually supports the required DNN, S-NSSAI and service capabilities.
UDM Subscription Data and PCF Session Policy Processing
Once the SMF understands what type of session the UE is requesting, it still cannot immediately create the user plane. It first needs to determine what kind of PDU Session the subscriber is actually authorized to establish.
In a typical procedure, the SMF locates the appropriate UDM, registers itself as the SMF serving the SUPI and PDU Session, and retrieves the Session Management Subscription Data associated with the requested S-NSSAI and DNN.
The subscription data may contain the permitted PDU Session Type, SSC Mode, Session-AMBR and default QoS-related settings. These values define the subscriber-level boundaries for the session. For example, if the UE requests an IPv4 PDU Session, the SMF still needs to verify that the DNN permits that PDU Session Type and that the requested SSC Mode is allowed.
The SMF may also subscribe to changes in SM subscription data. If the relevant session-management subscription is later modified in the UDM, the UDM can notify the serving SMF through the registered Callback URI.
If the deployment uses dynamic SM Policy Control, the SMF selects a PCF and establishes an SM Policy Association. The SMF provides context such as SUPI, PDU Session ID, DNN, S-NSSAI, UE location and subscribed QoS parameters. The PCF then returns authorized session policy, which may include Session-AMBR, default QoS and other applicable policy rules.
This stage can be viewed as a convergence of session parameters:
UE service request → UDM subscription limits → PCF policy authorization → SMF finalizes session control parameters
The QoS and forwarding rules installed in the UPF later in the procedure are based on these results.
N4 Session Establishment and UPF User-Plane Rule Installation
After the session parameters are determined, the SMF selects a UPF capable of serving the requested DNN, S-NSSAI and UE location, then establishes a PFCP Session over the N4 interface.
PFCP Session Establishment Request is one of the most important points in the PDU Session Establishment procedure. Up to this stage, the network has mostly been working with abstract service requirements. At N4, those requirements are converted into rules that the UPF can execute on actual user packets.
The SMF may install PDR, FAR, QER and URR rules in the UPF:
PDR: tells the UPF how to identify packets belonging to the PDU Session or a particular traffic flow;
FAR: defines what should happen to matching packets, such as forwarding, dropping, buffering or another applicable action;
QER: applies the required QoS enforcement in the UPF;
URR: defines user-plane usage measurement and reporting requirements.
These rules should not be treated as four unrelated functions. Together, they define how the UPF processes traffic. The PDR identifies the packet flow and references the applicable FAR, QER and URR so that the UPF knows where the packets should go, which QoS controls apply and whether usage needs to be measured.
When the UPF accepts the PFCP Session Establishment, it returns its F-SEID and the user-plane parameters it has created. One of the most important results is the UPF-side user-plane address and TEID used for N3.
At this point, however, the downlink path may still not be complete because the gNB has not yet finished allocating its N3 resources. PDU Session Establishment therefore does not end with a single PFCP request. The procedure still needs the RAN to complete its side of the user-plane setup.
N1/N2 Signaling Completes the N3 Tunnel and QoS Flow Setup
After the UPF-side resources are ready, the SMF needs to return two different sets of information through the AMF.
The first is N1 SM information, which is ultimately delivered to the UE. It contains the PDU Session Establishment Accept together with parameters the UE needs after the session has been established, such as PDU Session Type, SSC Mode, DNN, S-NSSAI, UE IP address, Session-AMBR and the default QoS Rule.
The second is N2 SM information, which is intended for the gNB. It tells the RAN which PDU Session is being created, which QoS Flows are involved, and which UPF IP address and TEID should be used on N3.
The AMF sends a PDU Session Resource Setup Request to the gNB over NGAP. The gNB allocates the required radio and N3 resources and forwards the PDU Session Establishment Accept to the UE.
After resource setup, the gNB returns a PDU Session Resource Setup Response containing its own N3 user-plane address and TEID, together with information about the QoS Flows that were successfully established.
There is an important timing detail here. When the SMF initially established the PFCP Session, it already knew the UPF-side N3 information, but it might not yet have known the final gNB-side tunnel information. Once the gNB returns its N3 address and TEID, the AMF forwards that information to the SMF. The SMF then uses PFCP Session Modification to update the relevant FAR in the UPF so that downlink packets can be encapsulated into the correct GTP-U tunnel toward the gNB.
At this point, the uplink and downlink user-plane paths become complete:
UE → gNB → N3 GTP-U → UPF → N6 → Data Network
Data Network → N6 → UPF → N3 GTP-U → gNB → UE
For this reason, receiving a PDU Session Establishment Accept does not by itself prove that every user-plane element is correct. N3 tunnel parameters, PFCP Session Modification and the final UPF rules still need to be verified against actual packet forwarding.
Signaling Troubleshooting for PDU Session Establishment
PDU Session Establishment involves many network functions. Troubleshooting the procedure by comparing every message from the first packet onward can quickly become confusing. A more efficient method is to divide the procedure into several checkpoints and narrow the fault domain step by step.
Verify That the Session Request Reaches the AMF Correctly
First confirm that the UE has completed the required 5GS Registration. Then inspect the PDU Session Establishment Request and verify that PDU Session ID, Request Type, DNN, S-NSSAI, PDU Session Type and SSC Mode are appropriate. If the request already contains an invalid parameter at the entry point, a healthy SMF and UPF cannot produce the intended session.
Verify That the SMF Creates a Valid SM Context
Next, verify that the AMF selects an appropriate SMF and that Create SM Context succeeds. The objective is not merely to find an NRF message in the trace, but to confirm that the selected SMF supports the required DNN, S-NSSAI and service capabilities.
Then verify that the SM subscription data returned by the UDM permits the requested PDU Session and that the PCF policy is consistent with the expected QoS configuration.
Verify That UPF and N3 Resources Are Complete
If the control plane has already returned PDU Session Establishment Accept but the UE still cannot pass data, the investigation should move down to N4 and N3.
Check the following in sequence:
Whether PFCP Session Establishment succeeds and the UPF creates the corresponding session;
Whether PDR, FAR, QER and other rules are consistent with the expected traffic direction;
Whether the gNB successfully returns its N3 user-plane IP address and TEID;
Whether the SMF updates the UPF with the gNB tunnel information through PFCP Session Modification;
Whether GTP-U packets using the expected TEID actually appear on N3;
Whether the UPF can successfully send and receive traffic toward the target Data Network over N6.
Following this sequence helps narrow the problem to NAS, SBI, N4, N3 or UPF packet forwarding instead of treating the entire 5GC as one undifferentiated fault domain.
FAQ
Why Can a UE Complete 5G Registration but Still Be Unable to Access the Internet?
Registration establishes access, identity, security and mobility context between the UE and the 5GC. It does not automatically create a user-data path. Before the UE can access the Internet or another Data Network, it still needs a PDU Session so that the SMF can configure the session parameters, UPF resources and N3 user plane.
Is a PDU Session Always Established When the UE Powers On?
No. A PDU Session can be established around the time of Registration, but it can also be initiated later when the UE actually requires a data service. The 5GS allows a UE to remain registered without an active PDU Session, so Registration completion and PDU Session Establishment should not be treated as the same event.
Does PDU Session Establishment Success Guarantee That the UE Can Access the Internet?
No. A NAS-layer PDU Session Establishment Accept alone is not sufficient proof of successful data connectivity. Actual user traffic also depends on the N3 tunnel between the gNB and UPF, the PDR/FAR/QER rules in the UPF, the N6 connection and the target Data Network. A UE can receive an IP address while user-plane forwarding is still incorrect.
Why Does PFCP Session Modification Occur After PFCP Session Establishment?
When the initial PFCP Session is created in the UPF, the gNB may not yet have completed its N3 resource allocation, so the SMF may not yet know the final gNB user-plane IP address and TEID. After the gNB returns these values in the PDU Session Resource Setup Response, the SMF updates the corresponding UPF rules through PFCP Session Modification so that downlink traffic can be sent through the correct N3 GTP-U tunnel.
Are QFI in a PDU Session and QER on the N4 Interface the Same Concept?
No. QFI identifies a QoS Flow in the 5GS, while QER is a QoS Enforcement Rule configured by the SMF in the UPF over N4. A QER participates in QoS enforcement and may be associated with a QFI where applicable, but QFI itself is not a QER and the two should not be treated as interchangeable concepts.
