ULCL specificPath not applied in two-anchor topology, free5GC v4.2.2 Multus

Q/A
,
1

Hello everyone,

I am building a cloud-native 5G testbed on Kubernetes using free5GC v4.2.2 with
free5gc-helm and Multus CNI. I have a ULCL topology with one BranchingUPF and two
PSA-UPFs sharing the same DNN, and the specificPath toward AnchorUPF2 is never
installed. The SMF always logs DNN mismatch and skips it. The default path to
AnchorUPF1 works fine.

SMF binary is commit 2232d299, built 2026-04-21, which should include the fix from
PR #182. I tested three different smfcfg.yaml variants with and without dnaiList and
the result is always the same.

Below are all the relevant configs verified directly inside the running pod, plus the
MongoDB policy data. Any guidance on what I might be missing would be appreciated.

NETWORK INTERFACES

SMF: N4 10.100.50.244
BranchingUPF: N4 10.100.50.245 | N3 10.100.50.234 | N9 10.100.50.227
AnchorUPF1: N4 10.100.50.242 | N9 10.100.50.225 | pool 10.60.0.0/17
AnchorUPF2: N4 10.100.50.243 | N9 10.100.50.226 | pool 10.60.128.0/17

TOPOLOGY

gNB1
|
BranchingUPF (iUPF)
|-- AnchorUPF1 default path for all traffic [WORKING]
|-- AnchorUPF2 specificPath for dest 1.0.0.1/32 [NOT INSTALLED]

Both PSA-UPFs declare dnn: internet with different /17 pools.

SMF LOG
smfULCLPSA2DNNmissmatch_log.txt (28.8 KB)

[INFO][SMF][PFCP] Add PSAAndULCL
[INFO][SMF][PduSess] In AddPDUSessionAnchorAndULCL
[TRAC][SMF][PduSess] Skipping path via UPF [{0 10.100.50.243 }] (DNN mismatch)
[INFO][SMF][PduSess] No more valid PSA2 path found, finish selection.

SMFCFG.YAML (verified inside running pod, commit 2232d299)

ulcl: true
userplaneInformation:
upNodes:
BranchingUPF:
type: UPF
nodeID: 10.100.50.245
sNssaiUpfInfos:

  • sNssai: {sst: 1, sd: 010203}
    dnnUpfInfoList:
  • dnn: internet
    interfaces:
  • interfaceType: N3
    endpoints: [10.100.50.234]
    networkInstances: [internet]
  • interfaceType: N9
    endpoints: [10.100.50.227]
    networkInstances: [internet]
    AnchorUPF1:
    type: UPF
    nodeID: 10.100.50.242
    sNssaiUpfInfos:
  • sNssai: {sst: 1, sd: 010203}
    dnnUpfInfoList:
  • dnn: internet
    pools:
  • cidr: 10.60.0.0/17
    interfaces:
  • interfaceType: N9
    endpoints: [10.100.50.225]
    networkInstances: [internet]
    AnchorUPF2:
    type: UPF
    nodeID: 10.100.50.243
    sNssaiUpfInfos:
  • sNssai: {sst: 1, sd: 010203}
    dnnUpfInfoList:
  • dnn: internet
    pools:
  • cidr: 10.60.128.0/17
    interfaces:
  • interfaceType: N9
    endpoints: [10.100.50.226]
    networkInstances: [internet]
    links:
  • A: gNB1
    B: BranchingUPF
  • A: BranchingUPF
    B: AnchorUPF1
  • A: BranchingUPF
    B: AnchorUPF2

UEROUTING.YAML (verified inside running pod)

UE1:
members:

  • imsi-208930000000001
    topology:
  • A: gNB1
    B: BranchingUPF
  • A: BranchingUPF
    B: AnchorUPF1
    specificPath:
  • dest: 1.0.0.1/32
    path: [BranchingUPF, AnchorUPF2]

MONGODB policyData.ues.smData

{
“smPolicyDnnData”: {
“internet”: { “dnn”: “internet” }
}
}

No dnaiList field. The WebUI does not expose it.

MONGODB policyData.ues.flowRule

{
“filter”: “1.0.0.1/32”,
“precedence”: 128,
“dnn”: “internet”
}

WHAT WAS TRIED

We tested three smfcfg.yaml variants, all with the same DNN mismatch result:

  1. dnaiList: mec in dnnUpfInfoList of both BranchingUPF and AnchorUPF2
  2. dnaiList: mec only in AnchorUPF2
  3. No dnaiList anywhere (current state)

ADDITIONAL CONTEXT

We deploy via free5gc-helm v4.2.2 with multus.enabled=true. In this mode the SMF
configmap template hardcodes the entire userplaneInformation block and ignores
configuration.configuration from values.yaml completely. We found that ulcl: true
was missing from the generated configmap in Multus mode and had to patch the template
manually. We are not sure if there are other fields the template omits that may be
needed for SelectPSA2 to work correctly in a two-anchor topology.

QUESTIONS

  1. Is a topology with two PSA-UPFs sharing the same DNN but different pools supported
    in v4.2.2? Does PR #182 handle the DNN mismatch case in SelectPSA2, or only the panic?

  2. Is dnaiList required in MongoDB policyData.ues.smData for SelectPSA2 to identify
    AnchorUPF2? If so, what structure is expected and is there a supported way to set it?

  3. Could the Multus configmap template in free5gc-helm be missing fields that affect
    this behavior? If so, which fields are needed for a two-anchor ULCL topology?

  4. Where in the source code does the DNN mismatch check occur? We believe it is in
    internal/context/bp_manager.go or internal/context/userplane_information.go but
    could not confirm the exact function or condition.

Thanks for any guidance.

Luis Poclin-Romero
National University of San Marcos (UNMSM),
Lima, Peru