gNB radio link failure handling bug

[Christoffer9712]

Hi everyone,
I found a possible issue with the code. I run the gNB UE on one VM and the gNB + Core (free5gc) on a second VM, and initially the setup works fine, which is illustrated by the log on the UE side:

Registration accept received
Initial Registration is successful
Sending PDU Session Establishment Request
PDU Session Establishment Accept received
TUN interface[uesimtun0, 10.60.0.1] is up

After around 5–10 minutes, a radio link failure occurred:

[2025-12-28 09:31:25.087] [rrc] [debug] Signal lost for cell[1], total [0] cells in coverage 
[2025-12-28 09:31:25.087] [nas] [error] Radio link failure detected 
[2025-12-28 09:31:25.087] [nas] [info] UE switches to state [CM-IDLE] 
[2025-12-28 09:31:25.088] [nas] [info] UE switches to state [MM-REGISTERED/PS] 
[2025-12-28 09:31:25.088] [nas] [info] UE switches to state [MM-REGISTERED/PLMN-SEARCH] 
[2025-12-28 09:31:25.088] [nas] [error] PLMN selection failure, no cells in coverage 

Afterwards, the UE tries to reconnect to the gNB:

[2025-12-28 09:31:25.100] [rrc] [debug] New signal detected for cell[2], total [1] cells in coverage 
[2025-12-28 09:31:27.667] [rrc] [warning] Acceptable cell selection failed in [1] cells. [1] no SI, [0] reserved, [0] barred, ftai [0] 
[2025-12-28 09:31:27.667] [rrc] [error] Cell selection failure, no suitable or acceptable cell found 
[2025-12-28 09:31:28.358] [nas] [error] PLMN selection failure, no cells in coverage 
[2025-12-28 09:31:30.817] [nas] [info] UE switches to state [MM-REGISTERED/NO-CELL-AVAILABLE] 
[2025-12-28 09:31:33.952] [nas] [info] Selected plmn[208/93] 
[2025-12-28 09:31:33.952] [rrc] [info] Selected cell plmn[208/93] tac[1] category[SUITABLE] 
[2025-12-28 09:31:33.953] [nas] [info] UE switches to state [MM-REGISTERED/PS] 
[2025-12-28 09:31:33.953] [nas] [info] UE switches to state [MM-REGISTERED/NORMAL-SERVICE] 
[2025-12-28 09:32:48.699] [nas] [debug] Uplink data status changed PSI[1] pending[true] 
[2025-12-28 09:32:48.700] [nas] [debug] Service request required due to [IDLE-UPLINK-DATA-PENDING] 
[2025-12-28 09:32:48.700] [nas] [debug] UAC access attempt is allowed for identity[0], category[MO_data] 
[2025-12-28 09:32:48.700] [nas] [debug] Sending Service Request due to [IDLE-UPLINK-DATA-PENDING] 
[2025-12-28 09:32:48.700] [nas] [info] UE switches to state [MM-SERVICE-REQUEST-INITIATED] 
[2025-12-28 09:32:48.700] [rrc] [debug] Sending RRC Setup Request 
[2025-12-28 09:33:03.763] [nas] [debug] NAS timer[3517] expired [1] 
[2025-12-28 09:33:03.763] [nas] [info] UE switches to state [MM-REGISTERED/PS] 
[2025-12-28 09:33:03.763] [nas] [info] UE switches to state [MM-REGISTERED/NORMAL-SERVICE]

The corresponding gNB log is:
setup:

09:28:34  SCTP up, NG Setup OK
09:28:47  RRC Setup for UE[1]
09:28:47  Initial NAS message received
09:28:48  Initial Context Setup Request
09:28:49  PDU session resource(s) setup

Radio link failure:
09:31:25.879 [rls] UE[1] signal lost

When the UE sends a new RRC setup request, the gNB replies with:
09:32:49.590 [rrc] [warning] Discarding RRC Setup Request, UE context already exists

It seems as if the gNB thinks:
“I already have UE[1], so I must not accept a new RRC Setup Request.”

But the UE thinks:
“I lost radio earlier, so I need to re-establish RRC.”

I believe the issue might come from faulty radio link failure handling in the gNB. This is quite annoying since I set up my configuration to do some experiments, but after around 5 minutes the link goes down, and I need to restart both the core, gNB, and UE to set it up again to use the same IP for the UE. Could the solution be to drop the UE context in the gNB when the radio link fails, as this would allow the UE to connect again?

I'm very thankful for any help regarding this. Also any confirmation if this is expected behaviour or a bug.

Kind regards
Chris