Skip to main content

UPF — User Plane Function

The UPF (User Plane Function) is the packet-forwarding node of the mobile core. It carries every subscriber's actual traffic: it receives GTP-U tunnels from the access network on N3 (S1-U in the EPC), forwards packets to and from the data network, applies per-flow QoS and volume accounting, and buffers downlink packets when a device is idle. It has no logic of its own — the control plane (an SGW-C in the EPC over Sxa, or an SMF in a 5G core over N4) programmes it entirely over PFCP, installing the packet-detection, forwarding, QoS and usage-reporting rules that describe how each session's traffic is handled. Omnitouch's OmniUPF implements the forwarding path as an eBPF/XDP dataplane in the kernel, so the rules the control plane installs become entries in eBPF maps that the XDP program consults for every packet. OmniWeb surfaces the UPF's PFCP associations and sessions, the live eBPF map contents, dataplane statistics, routing, downlink buffers, walled-garden state and configuration; throughput and trend charts are on the Grafana dashboards reached from the same page.

← Operations Guide

The UPF is a per-instance element page reached from the sidebar when one runs in the site's inventory, with an instance selector where several are deployed and a fleet view for aggregate status. All traffic goes through the OmniWeb backend proxy to the UPF's API, so it stays behind the single authenticated gateway. The documentation link in the page header (the in-context help button) opens this page. It is organised into tabs.

Fleet and instance selection​

The UPF fleet view listing every UPF instance in the site with its health status

Where a site runs more than one UPF, the fleet view lists every instance with its health at a glance — the fastest way to confirm the whole user plane is up before drilling into one node.

The UPF instance selector dropdown in the page header, switching the element page between deployed UPF instances

From any tab, the instance selector in the page header switches which UPF the page is reading. Everything below — sessions, associations, eBPF maps, statistics — is scoped to the selected instance, so you pick the node once and the whole page follows it.

Overview​

The UPF Overview showing health, PFCP association and active-session counts, XDP action counters and eBPF map sizes

A single-screen health read of the UPF: its health status, the number of PFCP associations it holds with control-plane peers, the total active sessions across those peers, and the XDP action counters — how many packets the dataplane has passed, dropped, redirected, transmitted or aborted, which is the quickest confirmation that traffic is actually flowing. Beneath it, each PFCP peer is listed with its association state, session count and any missed heartbeats, and the eBPF map sizes show the capacity of the PDR, FAR, QER and URR maps and the maximum session count. A search box jumps straight to a session by UE IP or TEID, and a Node Report action sends a PFCP Node Report Request to the first active control-plane peer.

Sessions​

The UPF Sessions tab listing PFCP sessions by SEID and IMSI with their APN/DNN, association and per-session rule counts

Every PFCP session — the per-bearer / per-PDU-session user-plane state the control plane has installed. Each row is keyed by its local and remote SEID and shows the session's IMSI, APN/DNN, the association (which control-plane peer owns it), and the count of packet-detection, forwarding-action, QoS-enforcement and usage-reporting rules it carries. Search by UE IP or TEID to find the session serving a specific device or tunnel.

Session detail​

The UPF session detail showing the rule map linking packet-detection rules to their forwarding, QoS and usage-reporting rules, with the per-rule tables beneath

Opening a session shows its full rule state. A session rule map draws how each Packet Detection Rule (PDR) references the Forwarding Action Rule (FAR), QoS Enforcement Rule (QER) and Usage Reporting Rules (URR) it applies — clicking any node highlights just the rules connected to it, so a single flow's path through the dataplane is easy to trace. Beneath the map, four tables give the detail:

  • Packet Detection Rules (PDR) — how incoming packets are classified: direction (uplink / downlink), the UE IP or inbound TEID they match, the SDF filters (protocol and port ranges), and which FAR, QER and URRs they resolve to.
  • Forwarding Action Rules (FAR) — what happens to matched packets: Forward, Drop, Buffer or Notify CP, the outbound GTP-U tunnel details (remote IP and TEID) and network instance. FARs can be edited in place.
  • QoS Enforcement Rules (QER) — the per-flow QoS: the QFI, the uplink and downlink gate status (open / closed) and the maximum and guaranteed bitrates. QERs can be edited in place.
  • Usage Reporting Rules (URR) — the volume counters: current and last-reported uplink and downlink bytes and the report sequence number, which is what the UPF feeds back to the control plane for charging and quota.

From the session header you can also activate or remove a walled-garden redirect for that specific session (see Walled Garden below).

Associations​

The UPF Associations tab listing each PFCP peer with its remote IP and port, session count, association state, missed heartbeats and connect/disconnect times

The PFCP associations — the Sxa/N4 relationships the UPF holds with its control-plane peers (the SGW-C or SMF). Each row shows the peer's remote IP and port, its session count, whether it is currently associated, the number of missed heartbeats, and when it last connected or disconnected. This is where you confirm the user plane and control plane are in step and spot a peer whose heartbeats are lapsing.

Statistics​

The UPF Statistics tab showing eBPF map usage bars, XDP action counters and the parsed dataplane metrics

The dataplane's real-time numbers. eBPF Map Usage shows how full each map is — sessions, PDR, FAR, QER and URR — as used-versus-capacity bars that turn amber and red as they approach their limit, so you can see a UPF nearing its dimensioned capacity before it starts rejecting sessions. XDP Statistics breaks out the pass / drop / redirect / TX / aborted packet counters, and the Metrics section surfaces the UPF's Prometheus counters as individual figures.

The UPF capacity view showing per-map used-versus-capacity utilisation

The same used-versus-capacity model is what a capacity check reads: at a glance you can tell whether the constraining resource is the session table or one of the rule maps.

Routing​

The UPF Routing tab with the active UE IP routes and the FRR routing console

The routes that steer subscriber traffic to and from the UPF. The Active UE IP Routes table lists the routes the UPF currently holds for allocated UE IP pools, and a Sync Routes action reconciles them with the dataplane. Below it, an FRR console gives an in-context vtysh terminal against the UPF's routing daemon — type a show command (for example show ip route or show ip ospf neighbor) to inspect routing state, with tab-completion and command history, or switch to configure mode to make a change. This is how the UPF advertises its UE pools into the surrounding network without leaving OmniWeb.

Buffers​

The UPF Buffers tab showing total buffered packets and FARs with per-FAR buffer limits and a lookup-by-FAR-ID tool

The downlink packet buffers. When downlink data arrives for a device that is idle (no active tunnel), the dataplane holds those packets against the relevant FAR and asks the control plane to page the device — the buffered packets are then flushed once the tunnel is re-established (this is the user-plane side of Downlink Data Notification). The tab shows the total buffered packets and total FARs holding packets, the per-FAR and total buffer limits, and a lookup by FAR ID to see how many packets a specific FAR is holding. Buffers can be flushed individually or cleared in bulk.

eBPF Maps​

The UPF eBPF Maps tab browsing the uplink and downlink PDR, FAR, QER and URR maps, with any row editable

A direct browser onto the eBPF maps that are the UPF's dataplane. These are the raw kernel-side entries the XDP program consults for every packet, split across tabs:

  • Uplink PDR — keyed by inbound TEID, mapping a tunnel to its PDR and FAR.
  • Downlink PDR — keyed by UE IP, mapping a subscriber's downlink to its PDR and FAR.
  • FAR — the forwarding actions, with decoded action, remote IP, outbound TEID and outer-header creation.
  • QER — the QoS entries, with QFI, gate status and bitrate limits.
  • URR — the usage counters, with current and last-reported uplink/downlink volumes.

Any row can be clicked to edit the raw map entry, which is a low-level troubleshooting and repair tool — the maps are normally driven entirely by PFCP, so hand-editing an entry is for diagnosis rather than routine operation.

Configuration​

The UPF Configuration tab showing the node's network, feature, heartbeat and dataplane settings, with a raw-JSON toggle

A read-only view of how the UPF is configured: its network identity (node ID, PFCP address and port, API port, N3 and N9 addresses), the features it has enabled (FTUP, UEIP, the route manager and its type, and the XDP attach mode — native, generic or offloaded), the PFCP heartbeat interval, timeout and retry settings, and the dataplane N3/N9 addresses. A Raw JSON toggle shows the full config document for support. This is where you confirm a UPF is dimensioned and addressed as expected.

Diagnostics​

The UPF Diagnostics tab running a ping from the UPF node to a target host

Runs a ping from the UPF node to a target host — enter a target and a packet count and the raw ping output comes back with a success/failure verdict. It is a quick way to confirm the UPF has data-network reachability (for example to a DNS server or upstream gateway) from where the packets actually leave, without shelling into the node.

Walled Garden​

The UPF Walled Garden tab showing active redirect sessions, the activate-redirect form and the whitelisted IP list

The walled garden — restricted forwarding for sessions that must reach only a captive portal before they are authenticated or entitled. Activating a redirect on a session's SEID rewrites its downlink so the device is steered to a redirect URL / portal IP instead of the open internet; the tab lists every active redirect with the UE IP, portal IP, redirect URL, gNB IP and the TEIDs involved, and a redirect can be removed to release the session to normal forwarding. A whitelist of IPs or CIDRs names the destinations a walled-garden session is still allowed to reach directly (for example the portal and its assets). Redirects can also be activated and removed per-session from the session detail page.

Logs​

The UPF Logs tab tailing the node's live log output

The Logs tab tails the UPF's live log output for troubleshooting a single instance without leaving OmniWeb.

Monitoring dashboards​

Throughput, per-interface packet rates, session-count trends and other time-series for the UPF are presented as Grafana dashboards, reached from the element page — OmniWeb does not duplicate those charts natively.

  • SGW-C — the EPC control peer that programmes this UPF (as the SGW-U) over Sxa/PFCP and forwards traffic on S1-U / N3.
  • PGW-C / SMF — anchors the PDN connection and, as the SMF, programmes the 5G user plane over N4/PFCP.
  • MME — drives bearer setup that ultimately installs the sessions seen here.
  • SCEF — carries small non-IP payloads over the control plane, deliberately bypassing this user plane.
  • Operations Guide — back to the element index.
Last updated on