5G SA Authentication Failure with free5GC + OAI gNB (USRP B210): SQN Synchronization Issues

Q/A
1

I am working on a 5G SA setup using OpenAirInterface (OAI) gNB with a USRP B210 SDR connected to free5GC core. The NG setup between the gNB and AMF is successful, and the UE completes RRC connection and reaches the Authentication phase. However, during UE registration, authentication consistently fails with 5G AKA Synchronization Failure / MAC failure.

The UE uses a programmable SIM (pySIM), and the free5GC logs show errors such as Authentication Failure Cause: Synch Failure, Re-Sync MAC failed, and 403 Forbidden from UDM during authentication re-synchronization. This suggests a mismatch or desynchronization between the SIM credentials (IMSI/K/OPc/SQN) and the UDM database.

I am looking for guidance on the correct procedure to synchronize SIM SQN with free5GC UDM, best practices for programming SIM cards for free5GC, and any known issues when using commercial smartphones as UE with OAI gNB + USRP B210.

Best Regards,

Atash

here are the logs of the Free5gc Core

2026-01-24T15:37:11.383445470+01:00 [INFO][UDM][GIN] | 200 | 127.0.0.1 | POST | /nudm-ueau/v1/suci-0-001-01-0-0-0-0000016630/security-information/generate-auth-data | |
2026-01-24T15:37:11.383908560+01:00 [INFO][AUSF][UeAuth] Add SuciSupiPair (suci-0-001-01-0-0-0-0000016630, imsi-001010000016630) to map.
2026-01-24T15:37:11.383963600+01:00 [INFO][AUSF][UeAuth] Use 5G AKA auth method
2026-01-24T15:37:11.383985747+01:00 [INFO][AUSF][5gAka] XresStar = 3030663266303763656538353839383530303936303965376339623736336335
2026-01-24T15:37:11.384085976+01:00 [INFO][AUSF][GIN] | 201 | 127.0.0.1 | POST | /nausf-auth/v1/ue-authentications | |
2026-01-24T15:37:11.384511082+01:00 [INFO][AMF][Gmm][amf_ue_ngap_id:RU:1,AU:1(3GPP)][supi:SUPI:] Send Authentication Request
2026-01-24T15:37:11.384595326+01:00 [INFO][AMF][Ngap][amf_ue_ngap_id:RU:1,AU:1(3GPP)][ran_addr:10.3.1.20:36518] Send Downlink Nas Transport
2026-01-24T15:37:11.384694671+01:00 [INFO][AMF][Gmm][amf_ue_ngap_id:RU:1,AU:1(3GPP)][supi:SUPI:] Start T3560 timer
2026-01-24T15:37:11.430261940+01:00 [INFO][AMF][Ngap][ran_addr:10.3.1.20:36518] Handle UplinkNASTransport
2026-01-24T15:37:11.430442976+01:00 [INFO][AMF][Ngap][amf_ue_ngap_id:RU:1,AU:1(3GPP)][ran_addr:10.3.1.20:36518] Handle UplinkNASTransport (RAN UE NGAP ID: 1)
2026-01-24T15:37:11.430710117+01:00 [INFO][AMF][Gmm] Handle event[Gmm Message], transition from [Authentication] to [Authentication]
2026-01-24T15:37:11.430818906+01:00 [INFO][AMF][Gmm][amf_ue_ngap_id:RU:1,AU:1(3GPP)][supi:SUPI:] Handle Authentication Failure
2026-01-24T15:37:11.430958820+01:00 [INFO][AMF][Gmm][amf_ue_ngap_id:RU:1,AU:1(3GPP)][supi:SUPI:] Stop T3560 timer
2026-01-24T15:37:11.431077001+01:00 [WARN][AMF][Gmm][amf_ue_ngap_id:RU:1,AU:1(3GPP)][supi:SUPI:] Authentication Failure Cause: Mac Failure
2026-01-24T15:37:11.431226758+01:00 [INFO][AMF][Gmm][amf_ue_ngap_id:RU:1,AU:1(3GPP)][supi:SUPI:] Send Authentication Reject
2026-01-24T15:37:11.431330316+01:00 [INFO][AMF][Ngap][amf_ue_ngap_id:RU:1,AU:1(3GPP)][ran_addr:10.3.1.20:36518] Send Downlink Nas Transport
2026-01-24T15:37:11.431695575+01:00 [INFO][AMF][Gmm] Handle event[Authentication Fail], transition from [Authentication] to [Deregistered]
2026-01-24T15:37:11.431825121+01:00 [WARN][AMF][Gmm] Reject authentication
2026-01-24T15:37:11.431907062+01:00 [INFO][AMF][Ngap][amf_ue_ngap_id:RU:1,AU:1(3GPP)][ran_addr:10.3.1.20:36518] Send UE Context Release Command
2026-01-24T15:37:11.432237913+01:00 [INFO][AMF][CTX] AmfUe is removed
2026-01-24T15:37:11.636363387+01:00 [INFO][AMF][Ngap][ran_addr:10.3.1.20:36518] Handle UEContextReleaseComplete
2026-01-24T15:37:11.636569862+01:00 [ERRO][AMF][Ngap][ran_addr:10.3.1.20:36518] Handle UEContextReleaseComplete: no RanUe Context[AmfUeNgapID: 1, RanUeNgapID: 1]
2026-01-24T15:37:15.231382385+01:00 [INFO][UPF][PFCP][LAddr:127.0.0.8:8805] handleHeartbeatRequest

2

Hi Atash,

I’ve reviewed the logs you shared, and they indicate a credential mismatch rather than a sequence number (SQN) synchronization problem.

*MAC Failure
The logs clearly show “Authentication Failure Cause: MAC Failure.”
This means the UE received the Authentication Request but rejected it because the calculated Message Authentication Code (MAC) did not match what the core network expected.

This usually happens due to one of the following reasons:

  • K value mismatch: The secret key configured on the SIM card does not match the K stored in free5GC (WebConsole/MongoDB).

  • OP vs OPc mismatch:
    free5GC expects OPc, not the raw OP value. If your SIM was programmed using OP, you must derive OPc before entering it into free5GC. If the raw OP was entered directly into the OPc field, authentication will always fail with a MAC error.

*About SQN Synchronization
You mentioned a “Synch Failure.” Once the MAC issue (K/OPc) is fixed, a real SQN synchronization failure may appear if the SQN values are out of range.

Normally, free5GC handles this automatically using the AUTS mechanism sent by the UE. However, if manual intervention is needed:

  • In the free5GC WebConsole, ensure the subscriber SQN is slightly higher than the SQN stored on the SIM.

  • For programmable SIMs (e.g., using pySIM), you can read the current SQN from the card and update the SQN in MongoDB accordingly.

*Recommendation

  • Verify that the K value is identical on both the SIM and free5GC.

  • Confirm whether your SIM uses OP or OPc. If it uses OP, compute OPc and update the subscriber profile.

  • After resolving the MAC failure, SQN synchronization should recover automatically. If not, manually increase the SQN in the WebConsole.

Hope this helps clarify the issue.