A UE has registered and its PDU Session has been accepted. Why can it now reach an application server? The SMF has selected a User Plane Function (UPF) and told it exactly which packets belong to that session and where to send them. The UPF is the place where the user packets actually pass. It is not the network function that decides whether the subscriber is allowed to have the session.

The short version is SMF decides; UPF executes. That is useful, but it hides the interesting part: a UPF has to recognize packets on different interfaces, apply the right treatment, and preserve the session state while the radio path changes. This note follows one packet through that work and then looks at what an implementation must build.

This note covers the following.

• What does a UPF do, and what does it not do ?
• Where does the UPF sit ?
• How does the UPF decide what to do with a packet ?
  • PDR : which packet is this ?
  • FAR : where does it go ?
  • QER, URR and BAR : what else happens ?
• How does the SMF program the UPF over N4 ?
• What happens to an uplink and a downlink packet ?
• What changes when the UE moves or goes idle ?
• Can one PDU Session use more than one UPF ?
• What does a UPF implementation contain ?
• What are the levels of UPF implementation ?
  • Option 1 : a fixed packet pipe
  • Option 2 : a minimal N4-controlled UPF
  • Option 3 : a service-capable software UPF
  • Option 4 : a full-featured deployment
• How do I troubleshoot a UPF path ?
• Reference

What does a UPF do, and what does it not do ?

The UPF is the 5GC user-plane network function. It receives and sends PDU Session traffic, serves as the interconnect point to a Data Network (DN) when acting as a PDU Session Anchor (PSA), and applies packet handling rules supplied by the SMF. Depending on its role and supported features, it can classify traffic, enforce QoS, count usage, buffer downlink packets, and steer traffic toward another UPF or a local DN. 3GPP TS 23.501 lists these as UPF capabilities, not as a requirement that every UPF instance implement every possible feature.

The SMF owns PDU Session control. It selects the UPF, allocates or coordinates the UE address or prefix, obtains policy, and installs or changes N4 rules. The AMF handles access and mobility control, and the gNB supplies the radio-facing tunnel endpoint. The UPF does not run NAS registration, authenticate the subscriber, or choose the policy by itself. Unlike the SMF, the UPF is not an HTTP service producer on the ordinary 5GC service-based interfaces.

The closest 4G analogy is the user-plane part of an SGW or PGW after control/user-plane separation. It is not accurate to say every UPF is simply a PGW: an intermediate UPF may only relay traffic over N9, while a PSA UPF faces the DN over N6. The role depends on where the UPF sits in the PDU Session path.

Where does the UPF sit ?

Start with the simplest path. The gNB exchanges user packets with the UPF over N3. The SMF programs that UPF over N4. The PSA UPF exchanges the resulting packets with the DN over N6. Figure 1 also shows N9, because a session may put an intermediate UPF between the RAN and the PSA.

Figure 1. N4 controls the UPF; N3, N9 and N6 carry user traffic. N9 appears only when the path includes another UPF.

Do not read the diagram as a fixed deployment. A small network may have one UPF. A larger network may place an intermediate UPF near the access and a PSA elsewhere. N19 and other specialized reference points exist for particular features; the four above are the ones to understand first.

How does the UPF decide what to do with a packet ?

Imagine a packet arriving on N3. The outer IP address only gets it to the UPF. The UPF must still find the PFCP session and a matching Packet Detection Rule (PDR), then follow the rules linked to that PDR. Figure 2 is the useful mental model. It is not a claim that every implementation executes these blocks as separate software stages.

Figure 2. A PDR chooses the packet; its associated rules decide forwarding, QoS, accounting and optional buffering.

PDR : which packet is this ?

A PDR(Packet Detection Rule) contains a Packet Detection Information (PDI), precedence and references to the other rules. The PDI identifies the incoming side and the packet to match. For uplink GTP-U traffic, a local F-TEID is a common discriminator. For downlink IP traffic, a UE IP address and optionally an SDF filter identify the destination flow. A PDR may also match QFI or other filters when the feature uses them. If more than one PDR in a PFCP session matches, precedence determines which one wins; the lower numerical precedence value has higher priority in PFCP.

FAR : where does it go ?

The Forwarding Action Rule (FAR) says whether to forward, drop, buffer or notify, subject to the permitted Apply Action combinations. When it forwards, its Forwarding Parameters identify the destination interface. Sending downlink traffic to the gNB also needs Outer Header Creation with the gNB's GTP-U TEID and transport address. Uplink traffic going to a DN generally removes the received GTP-U outer header and heads to the Core-side destination interface. In PFCP, Core in Destination Interface is a logical direction, not a claim that N6 carries a standardized 5G protocol.

QER, URR and BAR : what else happens ?

Detection and forwarding alone do not tell the UPF how to shape a QoS flow, count its usage, or hold downlink packets temporarily. The SMF adds these rules when the session needs those functions. They remain linked to the matching PDR or its FAR, so their effect is still tied to the same packet classification.

A PDR, FAR, QER and URR are not four independent guesses made by the UPF. The SMF installs the relationships. A PDR ID or FAR ID identifies a rule within its PFCP session; the same number can appear in another session without referring to the same subscriber.

How does the SMF program the UPF over N4 ?

N4 is PFCP((Packet Forwarding Control Protocol), a binary control protocol, not ASN.1 and not a REST API. It has two levels of state. An association is between the SMF and UPF nodes; it exchanges identities and capabilities and is monitored independently of any UE. A PFCP session is the packet-handling context for a particular PDU Session at that UPF. A running association can carry many PFCP sessions.

Figure 3 follows a common successful case. The SMF starts association setup, establishes a PFCP session, and later modifies the downlink FAR after it knows the gNB endpoint. The association need not be set up anew for every UE. Association setup may also be initiated by the UPF if the corresponding option is supported; the CP-initiated form is the baseline in TS 29.244.

Figure 3. Association is node-level; session establishment and modification install and update one UPF packet path.

The selected information elements below use the IE names of TS 29.244. The addresses, SEIDs, TEIDs and IDs are illustrative, not a captured packet or a complete binary decode. The downlink gNB endpoint arrives later, so a second PFCP request updates the FAR instead of pretending that the SMF knew it at the start.

The example is deliberately small. Real sessions commonly include QERs, URRs, additional PDRs and feature-dependent IEs. On release, the SMF sends PFCP Session Deletion Request and the UPF answers with PFCP Session Deletion Response; the UPF then removes that session context and its dynamic rules. Heartbeat, association update and failure recovery are node-level concerns, not extra steps that every UE performs.

What happens to an uplink and a downlink packet ?

Use the values in Figure 3 as a concrete case. The UE has IPv4 address 10.45.0.10. The UPF's N3 address is 192.0.2.20, its local uplink TEID is 0x01020304, and the gNB's downlink tunnel is 198.51.100.20 / TEID 0x10203040. These addresses are documentation examples. In a real deployment they must be reachable on the correct transport networks.

Figure 4. N3 tunnel endpoints differ by direction. The UE PDU survives; the GTP-U envelope is removed or created at the UPF.

If you see the downlink packet on N6 but not on N3, first check that the packet reached the correct PSA and matched a downlink PDR. Then check the FAR's action, destination interface and Outer Header Creation. If N3 has GTP-U but the gNB cannot deliver it, check the gNB endpoint and TEID, not the UE's inner IP address first.

What changes when the UE moves or goes idle ?

A handover normally changes the RAN-facing endpoint, not the UE address at a retained PSA. The source and target gNBs handle the radio procedure; the SMF receives the new tunnel information through control-plane signalling and updates the UPF's downlink FAR over N4. The UPF does not decide the handover target. An N3 downlink tunnel pointing at the old gNB is a common reason that control-plane handover looks successful while packets disappear.

When a UE becomes unreachable for downlink delivery, a configured FAR can request buffering and/or notification. The UPF can report downlink data arrival to the SMF through PFCP Session Report Request. The SMF and AMF then coordinate the required network-triggered service procedure. After the access path is restored, the SMF supplies the new gNB endpoint and forwarding resumes. How much data is buffered and for how long depends on configuration and supported procedures; do not assume infinite buffering.

UPF relocation is a different event. If the selected UPF changes, the SMF establishes and updates contexts on the relevant UPFs and arranges path changes. Whether the UE IP address can stay the same depends on the session continuity mode and anchor arrangement. Merely moving between gNBs does not imply a new PSA.

Can one PDU Session use more than one UPF ?

Yes. An intermediate UPF (I-UPF) can sit on N3 and forward to a PSA over N9. The PSA remains the anchor to a DN over N6. This separates the access-facing location from the DN anchor. The SMF controls each selected UPF on its own N4 association and installs rules for each hop; N9 does not magically copy the rule context between them.

For local traffic breakout, a UPF may act as an uplink classifier (UL CL) or branching point when the corresponding architecture and session type call for it. The classification and branching are policy-driven, not a property of every UPF. A traffic flow might reach a local DN while another flow continues toward a central PSA. This is why one PDU Session cannot always be represented as exactly one UPF box and one N6 link.

Each hop needs its own tunnel state. A TEID valid on N3 does not become the N9 TEID merely because the packet is the same UE packet. The intermediate UPF matches the arriving N3 tunnel and creates the N9 outer header specified by its FAR. The PSA matches that N9 packet under its own PFCP session before sending the PDU toward its DN. This is also why a packet trace at just one UPF can show only half the path.

NOTE : N9 is UPF-to-UPF user plane. N6 is UPF-to-DN. Changing the number of UPFs in the path does not change those meanings. For more on the DN boundary, see N6 Network Architecture.

What does a UPF implementation contain ?

The specification defines behavior and interfaces, not one program layout. A useful implementation split has a PFCP(Packet Forwarding Control Protocol) control module, a session/rule store, a fast packet path, and an N6 integration point. The packet path can be ordinary kernel networking, userspace packet processing, specialized hardware, or a combination. The important test is whether the installed rules actually control the packet path.

Open5GS is a concrete software example, not a 3GPP prescription. Its published build guide configures an ogstun TUN interface and demonstrates routing/NAT for a UE address pool. In that layout the UPF terminates N3 GTP-U, and the host's network stack provides a route from the virtual N6 side toward the external network. A high-throughput deployment may instead terminate N6 on a physical port or VRF and use DPDK, VPP, XDP or hardware acceleration. Those are implementation choices; the N3/N4/N6 behavior is what peers observe.

Be careful with NAT. It can make an internet lab work, but the UPF standard does not require all N6 traffic to be NATed. An enterprise DN may have a route back to the UE prefix and need no NAT at all. If uplink packets leave the UPF and no downlink packets return, the missing DN route or NAT state is often a better suspect than PFCP.

What are the levels of UPF implementation ?

You can build something that passes a test packet with only a few lines of forwarding code. Does that make it a UPF? Not yet. A real 5GC UPF has to accept session-specific instructions from the SMF and apply them to the correct traffic. The four options here are a teaching ladder, not 3GPP-defined implementation levels or conformance classes. Each option adds an operational capability. Packet rate is a separate axis: a narrow feature set can run in hardware, and a broad feature set can run in software.

Option 1 : a fixed packet pipe

Start with a single UE address and two preconfigured tunnel endpoints. A small program can decapsulate incoming N3 GTP-U, route the inner IP packet to a DN, and put returning packets into a fixed GTP-U tunnel toward the gNB. Figure 5 shows why this is useful for a lab and why it is not yet a proper 5GC UPF.

Figure 5. The pipe demonstrates encapsulation and routing, but fixed tunnel state cannot serve dynamic 5GC sessions.

There is no PFCP association, PDR or FAR in this option. Nothing accepts a PDU Session Establishment Request from the SMF, allocates a TEID for a new UE, or updates the gNB endpoint after handover. A pure IP or GTP-U relay that never terminates and classifies the tunnel is even further from a UPF. Call this a traffic experiment, not a standards-interoperable UPF. It is still a useful first step because it exposes the N3 and N6 packet transformations without hiding them behind a larger core.

Option 2 : a minimal N4-controlled UPF

The next step is to remove the hard-coded UE and gNB state. The SMF forms a PFCP association, establishes a PFCP session, and installs uplink and downlink PDR/FAR pairs. The UPF allocates or accepts the tunnel information, and a later N4 modification changes the downlink destination when the gNB endpoint changes. Figure 6 separates that control path from the user packets.

Figure 6. N4 makes tunnel state session-specific: the SMF can add, change and remove packet paths without editing the UPF by hand.

This is the first option in the ladder that can meaningfully participate in a 5GC PDU Session. A tightly scoped implementation may handle only IP PDU Sessions, one DNN and basic forwarding. It still needs correct PFCP lifecycle and error behavior for what it advertises; receiving a Session Establishment Request is not enough. This option is suited to a controlled lab where advanced QoS, charging, buffering and topology changes are outside the test. If the SMF requires one of those features, the UPF must support it or the deployment must constrain the requested feature set.

Option 3 : a service-capable software UPF

A useful network needs more than forwarding. The SMF may install QERs to enforce or mark QoS flows, URRs to count and report usage, and BAR-controlled buffering where downlink delivery is temporarily unavailable. The same UPF may serve several DNNs whose N6 paths must stay separate. Figure 7 puts these rule functions inside one software instance without assuming that 3GPP mandates one process or one Linux interface per DNN.

Figure 7. The same packet path now applies service treatment and can keep different DN routing domains separate.

Open5GS with an ogstun TUN interface is one concrete software pattern for IP connectivity, but a TUN device is not a UPF feature level. A software UPF can instead use physical interfaces, VLANs or VRFs on N6. What distinguishes this option from Figure 6 is the session behavior: QoS enforcement, usage reporting, downlink handling and support for more than one service context. Performance depends on how those functions are implemented, not on the number of rule names in the diagram.

Option 4 : a full-featured deployment

At the broadest end, the operator may combine access-near and central UPFs, N9 transport, local breakout, multiple PSAs, detailed QoS and usage handling, failure recovery and operational monitoring. Figure 8 shows one possible topology, not a mandatory design for every PDU Session. A production packet engine may use userspace or hardware acceleration, but acceleration does not itself add a missing PFCP or mobility feature.

Figure 8. Multiple UPFs can split local and central traffic while the SMF programs each hop separately over N4.

This option needs coordinated rule installation on both sides of N9. A gNB-to-edge TEID is not reused automatically on the edge-to-PSA tunnel. The operator also has to decide which traffic is locally broken out, which traffic remains anchored centrally, how failures are detected, and how usage is reconciled. Ethernet PDU Sessions, ATSSS, application detection and other specialized capabilities may be added where the service requires them; none is an automatic consequence of using two UPFs. The full-fledged label therefore means a deployment built for a broad service and operations requirement, not a single 3GPP certification tier.

• Option 1 is a teaching pipe : it passes packets but cannot be driven by the SMF as a dynamic UPF.
• Option 2 is the control-plane turning point : PFCP sessions and PDR/FAR rules replace fixed tunnel state.
• Options 3 and 4 add service breadth and topology : QoS, reporting, buffering and multi-UPF routing are chosen according to the network's needs.
• Throughput is independent : TUN, kernel routing, DPDK and hardware offload are implementation choices, not 3GPP levels.

How do I troubleshoot a UPF path ?

Check from control to data, and check each direction separately. A successful PDU Session Establishment Accept proves less than an uplink-and-downlink packet test. The following order usually narrows the fault without guessing.

If the UPF increments an uplink PDR counter but the DN never sees the packet, the problem is past detection: inspect the FAR and N6. If the DN replies but the UPF's downlink PDR counter stays at zero, inspect UE-address routing and the PDI. Counters are implementation-specific, but the direction-by-direction reasoning follows the standardized rule model.

Reference

• 3GPP TS 23.501 - 5GS architecture, UPF functionality and user-plane arrangements.
• 3GPP TS 23.502 - N4 session procedures and PDU Session establishment.
• 3GPP TS 29.244 - PFCP association, session procedures and packet-processing rules.
• 3GPP TS 29.281 - GTP-U and extension headers on the user plane.
• 3GPP TS 29.561 - interworking between the 5G network and external Data Networks.
• Open5GS build guide - example of a software UPF's TUN interface and host routing.