ser-Plane Connectivity Issue (Ping/Data Path Failure) in Distributed 3-Node 5G SA Setup

8 views
Skip to first unread message

Yasir Nawaz

unread,
May 14, 2026, 11:45:58 PM (7 days ago) May 14
to Powder Users

Hello Powder Community,

We are currently building a 3-node 5G testbed for research on NexRAN slicing and closed-loop PRB allocation, but we have hit a persistent blocker regarding user-plane connectivity (ping failure).

Our Setup
  • Profile: O-RAN (PowderProfiles/O-RAN)

  • Hardware: 3 nodes, d430, 10Gb/s LAN

  • Node-0 (10.10.1.1): Open5GS Core + Near-RT RIC (J-release) + NexRAN xApp

  • Node-1 (10.10.1.2): srsRAN_Project gNodeB (commit e5d5b44b92)

  • Node-2 (10.10.1.3): srsRAN_4G srsUE (ZeroMQ RF bridging)

Current Status

The Control Plane is working perfectly. The UE successfully attaches, and the AMF logs confirm full registration:

  • SUPI: imsi-999990123456789

  • DNN: internet | S-NSSAI: SST:1 SD:0x1

  • UE Interface: tun_srsue receives IP 10.45.0.3/24

The Problem

We cannot get any data through the user plane. A ping from the UE namespace to the core gateway fails with 100% packet loss: sudo ip netns exec ue1 ping -c 4 10.45.0.1

What We Have Tried
  1. UPF Config: Added 10.10.1.1 to the gtpu and pfcp server sections in upf.yaml. Confirmed UPF is listening on 10.10.1.1:2152.

  2. Routing: Verified the ogstun interface is UP on Node-0 (10.45.0.1/16) and an iptables MASQUERADE rule exists. Added a route for 10.45.0.0/16 via 10.10.1.1 on Node-1.

  3. SMF Attempt: We tried changing the SMF upf address to 10.10.1.1, but this resulted in a PDU Session Establishment Reject (HTTP 404). We reverted it to 127.0.0.7.

Our Hypothesis

We suspect the SMF is advertising the localhost address (127.0.0.7) to the gNodeB as the UPF's N3/GTP-U endpoint. Since the gNodeB is on a separate physical node (Node-1), it cannot route GTP-U traffic to a localhost address on Node-0.

Specific Questions
  1. How do we configure smf.yaml or upf.yaml to ensure the SMF advertises the LAN IP (10.10.1.1) to the gNodeB for the N3 interface while keeping internal PFCP communication on localhost?

  2. Is there a specific "advertise" parameter in Open5GS for distributed setups where the gNodeB and Core are on different physical nodes?

  3. Are there any POWDER-specific MTU or routing nuances we should be aware of when bridging ZMQ over the 10.10.x.x network?

Any insights or example configuration files for a distributed Open5GS + srsRAN setup would be greatly appreciated!

Best regards,

Yasir Nawaz

Dustin Maas

unread,
May 15, 2026, 12:57:12 AM (7 days ago) May 15
to Powder Users

Thank you for the detailed message in the other thread! (Just returned from a conference and had time to take a look.)

I have once again fixed the ue side zmq config. And I disabled the RIC connection to test because it doesn’t appear to currently be running (or that part of the current gnb config is incorrect).

I think the confusion here is partly around the use of a separate network namespace for the UE… you don’t need that when the UE, gNB, and core network are running on separate nodes, so I removed that bit from the ue config. The UE now attaches and pinging 10.45.0.1 from the gateway now works.

I’ve killed my test processes. So, back over to you guys.

-Dustin

--
You received this message because you are subscribed to the Google Groups "Powder Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to powder-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/powder-users/3ca18a04-84a0-428f-bc16-742dc7327ea7n%40googlegroups.com.
PastedImage.png
Reply all
Reply to author
Forward
0 new messages