PFCP Session Debugging: The PDU Session Is Up and Downlink Is Dead

The fault that every status light misses

A UE is registered. The SMF reports the PDU session established. The phone shows

full bars. Uplink works — DNS resolves, the request leaves the network. Nothing

comes back.

This is the most common N4 fault in a live core and the hardest to see from a

dashboard, because every control-plane indicator is green and correct. The

session really was established. The SMF really did get a success response. The

problem is downstream of everything the control plane knows about.

The UPF holds no intelligence

This is the idea that makes the rest of it obvious, and it is the one most

people have backwards.

The UPF makes no decisions. It is a rule matcher. Every forwarding decision for

a session was made by the SMF and pushed down over N4 as a set of rules at

session establishment. The UPF applies them and nothing else.

So "the session is up" means one thing only: the UPF accepted the rules. It

does not mean the rules are correct. A PFCP Session Establishment Response with

cause 1 — request accepted — says the syntax was valid and the resources were

allocated. Nothing in that exchange checks whether the rules describe a working

datapath, because nothing in PFCP could.

That gap between "accepted" and "correct" is where this class of fault lives.

The four rule types

A fifth, the BAR (Buffering Action Rule), governs how packets are held when a

FAR says buffer rather than forward.

Every PDR points at a FAR. That pair is the datapath. QERs and URRs hang off the

same PDR and matter for policing and charging, but they are not what stops a

packet arriving — if downlink is dead, the PDR/FAR pair is where to look.

Read the session by direction, not by rule number

A working session has at least two PDR/FAR pairs, and they are not symmetric.

Write them out like this before reading anything else:

The asymmetry is the whole point. Uplink arrives already inside a GTP-U tunnel

from the gNB and leaves as plain IP toward the data network. Downlink arrives as

plain IP from the data network and must be put into a tunnel to reach the gNB.

Once you have the table, three faults become findable.

Fault 1: the PDR is listening on the wrong side

A PDR matches on source interface. Set the downlink PDR's source interface to

Access and it is now waiting for packets from the gNB — which never arrive on

that path, because downlink comes from the Core side.

The rule never fires. Nothing is dropped, nothing errors, no counter moves in an

obvious way. The packet simply matches no rule.

Uplink is unaffected, which is exactly why this presents as "uplink works,

downlink doesn't" rather than as a dead session.

Fault 2: the FAR sends it the wrong way

The PDR matches correctly and the FAR points at the wrong destination interface

— downlink traffic forwarded back out to Core instead of to Access.

Here the packet is matched and acted on. The rule fires. The UPF does exactly

what it was told, which is the wrong thing, and the packet leaves toward the

data network it just came from.

Fault 3: forwarded correctly, and still never arrives

This is the one worth remembering, because everything above it looks right.

The downlink PDR matches. The FAR forwards to Access. And Outer Header Creation is missing, so the packet leaves the UPF as bare IP with no GTP-U

header, no TEID and no tunnel endpoint.

There is no gNB address on it. There is nothing to deliver it to. The rule table

reads as correct at a glance — right source, right destination — and the traffic

is still gone.

If you check one field on a downlink FAR, check this one.

What to look at on the wire

PFCP runs over UDP port 8805 between the SMF and the UPF. Filter N4 and you are

looking for three things, in this order:

1. Is the association up? PFCP Association Setup Request and Response, and

then Heartbeat Request/Response as the liveness check between the two nodes.

No association means no session could have been created at all — a different

and much more visible failure.

1. What did the SMF actually install? The Session Establishment Request

(message type 50) carries the PDRs and FARs. This is the authoritative copy

of the rule table. Read it directly rather than trusting a UPF GUI's summary

of it.

1. Did anything change after? A Session Modification Request updates rules

on a live session — most commonly repointing a downlink FAR to a new

F-TEID after a handover. A session that worked and then stopped is usually a

modification, not the original establishment.

The Session Establishment Response (type 51) returns the UPF's F-SEID and a

cause. Cause 1 is request accepted — which, again, means accepted, not correct.

When the UPF does reject it

Rejections are the easy case, because they are visible. PFCP cause #11, "Service

not supported" (TS 29.244 §8.2.1), means the UPF does not support something the

SMF asked for — commonly a QER feature the SMF assumed was available.

Watch the number. Cause #11 in PFCP is "Service not supported". Cause #11 in

5GMM (TS 24.501 §9.11.3.2) is "PLMN not allowed" — a subscription problem, on a

different interface, with nothing to do with the UPF. Same integer, two

protocols, two unrelated diagnoses. Always say which protocol's cause you are

quoting, because the person you are quoting it to will assume the other one.

Fix one yourself

Reading about a rule table is not the same as finding the wrong field in one.

Fix the Broken Session

gives you a session in exactly the state above — established, uplink fine,

downlink dead — with the PFCP rules the SMF installed. Three fields are wrong.

You repair them and run traffic; nothing is graded against a stored answer,

because a configuration is right when packets arrive, which is the same standard

the live network applies. It is free, and it is the first lab of the

5G Core & E2E Specialist course.

For the establishment side in a real capture,

PDU session failure is a session that

does not survive setup. N2, N3 and N4 covers the

interfaces underneath, PDU session establishment

covers the procedure that creates these rules, and

analysing 5G PCAPs covers the

Wireshark setup that makes any of it readable.

Takeaway: a PFCP session reporting success means the UPF accepted the rules,

not that they forward anything. When downlink dies and the control plane is

green, read the downlink PDR/FAR pair — source interface, destination, and the

outer header that turns a correctly forwarded packet into one that actually

arrives.