Releasing a PDU session leads to assert
Releasing the (default) PDU session without going into flight mode leads to an assert:
[NGAP] PDUSESSIONRelease initiating message
[NGAP] [SCTP 1480] Received pdu session release command for gNB_UE_NGAP_ID 1 amf_ue_ngap_id 553648141
[NR_RRC] [gNB 0] gNB_ue_ngap_id 1
[NR_RRC] PDU Session Release Command: AMF_UE_NGAP_ID 553648141 rrc_ue_id 1 release_pdusessions 1
[NR_RRC] RELEASE pdusession 1
[NR_RRC] Send RRCReconfiguration To UE
[NR_RRC] add NAS info with size 20
[NR_RRC] [gNB 0] Frame 0, Logical Channel DL-DCCH, Generate NR_RRCReconfiguration (bytes 25, UE RNTI 8703)
[NR_RRC] [FRAME 00000][gNB][MOD 00][RNTI 1] Logical Channel DL-DCCH, Generate RRCRelease (bytes 3)
[GTPU] [0] Deleted all tunnels for ue id 1 (1 tunnels deleted)
[NR_RRC] removed UE CU UE ID 1/RNTI 8703
[NR_RRC] Removed UE context
Assertion (ret == HASH_TABLE_OK && data != ((void *)0)) failed!
In du_get_f1_ue_data() /home/oaicicd/robert/openairinterface5g/openair2/F1AP/f1ap_ids.c:143
element for ue_id 34563 not found
Exiting execution
Possible reason: the PDU session release triggers the removal of the RRC UE context and related F1 UE data removal, but it still exists at the MAC (I am not exactly sure, to be investigated).
As a comparison: a "good" release is triggered through RRC release directly:
[NR_RRC] [FRAME 00000][gNB][MOD 00][RNTI 1] Logical Channel DL-DCCH, Generate RRCRelease (bytes 3)
[GTPU] [0] Deleted all tunnels for ue id 1 (1 tunnels deleted)
[NR_RRC] removed UE CU UE ID 1/RNTI 0765
[NR_RRC] Removed UE context
[RLC] remove UE 765
[NR_MAC] Remove NR rnti 0x0765
[NR_MAC] handle_nr_uci_pucch_0_1(): unknown RNTI 0765 in PUCCH UCI
[NR_MAC] handle_nr_uci_pucch_2_3_4(): unknown RNTI 0765 in PUCCH UCI
how to reproduce, using quectel-CM
on Linux:
- start gNB
- enable
quectel-CM
(sudo /home/oaicicd/quectel-CM/quectel-CM -4 -s oai.ipv4 &
) - send AT command to connect
- kill
quectel-CM
, triggering the PDU session release
note: the same happens sometimes in the OAI UE pipeline
Edited by Robert Schmidt