AMF sees gNB over N2, but no UE-side signaling appears in amf.log in OAI NTN fixed-delay baseline

[kouamdo]

Summary

We are validating an OpenAirInterface + Open5GS 5G SA setup for NTN experiments.

Current status:

• the gNB successfully attaches to Open5GS AMF over N2
• the UE, on the OAI side, reaches PBCH decode, initial sync, and SIB1 decode
• however, no UE-side signaling appears in amf.log

So far, Open5GS only shows gNB-related events such as:

• gNB-N2 accepted
• [Added] Number of gNBs is now 1

But we do not see UE-related traces such as:

• InitialUEMessage
• Registration request
• Authentication
• Identity response
• Registration complete

Goal of this issue

We want to confirm whether Open5GS is correctly configured for the current validation target, which is simply:

"UE becomes visible to the 5GC at AMF level"

At this stage, we are not yet trying to validate Internet access or DN breakout.
So this is not primarily a UPF/NAT question.

Environment

• Open5GS version: 2.7.7
• OAI branch: develop
• 5G SA
• NTN validation baseline: fixed-delay RFsim scenario
• PLMN: 999/70
• UE subscriber inserted in MongoDB
• UE DNN: oai
• UE SST: 1

What works

• MongoDB is running
• subscriber is provisioned
• NRF / SCP / AMF / SMF / UPF start
• gNB reaches NGSetupResponse from AMF

What does not work

• no UE becomes visible in amf.log
• no AMF-side UE signaling appears

Current interpretation

From the radio side, this may still be a RAN-side issue between:

• SIB1 decoded
• and successful random access / RRC / NAS entry

However, before concluding that this is purely an OAI-side issue, we would like to confirm from the Open5GS side:

1. Is there any obvious Open5GS-side configuration mismatch that could prevent UE visibility at AMF level while still allowing gNB N2 attach?
2. Is the DNN=oai / session configuration something that must already be aligned before AMF UE traces appear, or does that only matter later for SMF/UPF/PDU session?
3. Are there any specific AMF logs or config sections we should inspect first to rule out a core-side issue?

Example AMF log behavior

Observed:

• gNB-N2 accepted[127.0.0.6]
• [Added] Number of gNBs is now 1

Not observed:

• InitialUEMessage
• Registration request
• Authentication

Note

At this stage we are only trying to validate that the UE becomes visible to the 5GC.
We are intentionally not treating UPF NAT / DN breakout as a prerequisite for success.

[ramrode]

try to :

1 - capture traces on UE side and validate if massages are triggered but not reaching the AMF (i.e tcpdump or wireshark )
2 - capture traces on AMF and validate if any errors .

[kouamdo]

Thanks for the suggestion.

We reproduced the issue again using the fixed-delay NTN baseline, so that the capture is not mixed with LEO Doppler effects.

We collected the following artifacts:

1. UE and gNB logs on the OAI side
2. AMF log on the Open5GS side
3. tcpdump capture of NGAP/SCTP traffic on loopback (sctp port 38412)

The goal is to verify whether UE-related signaling is actually triggered and sent by the gNB, and whether any InitialUEMessage or NAS-related signaling reaches the AMF.

Our current observation is:

• the gNB successfully attaches to the AMF
• the UE reaches PBCH / initial sync / SIB1
• but no UE-related trace appears in amf.log

We have uploaded the logs and the packet capture to our remote repository and are sharing the links here for analysis.