Run multiple UPFs

Start several UPFs and register them all with the DMF using the repeatable -upf flag.

The DMF can associate with more than one UPF at once. You start each UPF as its own process (on its own N4/PFCP address) and tell the DMF about every one by repeating the -upf flag. The DMF opens a PFCP association to each on startup.

Start the UPFs

Run each UPF on a distinct PFCP address. Here, two userspace UPFs on different ports of the same host (in a real lab they would usually be separate hosts or containers):

Bash

Register them with the DMF

Pass each UPF's host:port with its own -upf flag. The flag is repeatable — list as many as you have:

Bash

On startup the DMF resolves each address and sends a PFCP Association Setup to it. A UPF becomes usable for PDU sessions once its association completes.

How the DMF picks a UPF today

No per-DNN or per-slice routing yet

For a new PDU session, the SMF inside the DMF selects the first associated UPF it finds. It does not yet route by DNN, S-NSSAI, or load. Registering multiple UPFs gives you redundancy of association and lets you stage future topologies, but every session today lands on whichever UPF associated first.

In practice this means running multiple UPFs is most useful for testing association, failover behaviour, and restart detection rather than for steering specific DNNs or slices to specific UPFs.

Looking ahead: per-DNN / per-slice UPFs

A common production pattern is a dedicated UPF per DNN or per network slice — for example a UPF for internet and another for voice. Each UPF already serves its own DNNs and UE-IP pools (see DNNs and IP pools), so you can pre-stage that layout now. Just be aware that the DMF's session-to-UPF selection is still first-associated, so verify which UPF a session actually landed on before relying on DNN-based steering.

Where to go next

Configure the DNNs and pools each UPF serves in DNNs and IP pools, or read how the user plane works for the bigger picture.