srsue<->srsgnb via zmq: downlink packets stop flowing likely due to failed PDSCH allocation

[dziugas-wg2]

Issue Description

srsue can successfully talk to srsgnb via zeromq and attach to the core network. It can then ping remote hosts and receive replies. However, around 10-20 seconds after initial registration, downlink IP packets does not reach the UE anymore.

Inspecting ICMP packets at the core network and GTPU logs at the gnb suggests that uplink ICMP packets sent from the UE are seen both by the core network and the gnb. The same is also true for the downlink packets, that is, ICMP replies are being received by the gnb, but cannot be forwarded to UE via GTPU.

Once the downlink IP packets stop flowing, for each GTPU DL forwarding attempt there is a follow up PDSCH allocation skipped. Cause: No available HARQs message:

2023-08-17T06:30:44.211823 [GTPU    ] [D] Forwarding PDU. pdu_len=104 teid=0x000001
2023-08-17T06:30:44.211838 [GTPU    ] [I] ue=0 DL teid=0x000001: RX SDU. sdu_len=84 teid=0x000001 qos_flow=QFI=5
2023-08-17T06:30:44.211841 [SDAP    ] [D] ue=0 psi=1 QFI=5 DRB1 DL: TX PDU. QFI=5 pdu_len=84
2023-08-17T06:30:44.211849 [PDCP    ] [D] ue=0 DRB1 DL: TX SDU. sdu_len=84
2023-08-17T06:30:44.211854 [PDCP    ] [I] ue=0 DRB1 DL: TX PDU. type=data pdu_len=86 sn=17 count=17
2023-08-17T06:30:44.211857 [CU-F1-U ] [D] ue=0 DRB0: F1-U bearer received SDU with pdcp_sn=17, size=86
2023-08-17T06:30:44.211865 [DU-F1-U ] [D] ue=0 DRB1: F1-U bearer received PDU
2023-08-17T06:30:44.211866 [DU-F1-U ] [D] ue=0 DRB1: Delivering T-PDU of size=86, pdcp_sn=17
2023-08-17T06:30:44.211871 [RLC     ] [I] ue=0 DRB1 DL: TX SDU. sdu_len=86 pdcp_sn=17 queued_sdus=4 queued_bytes=344
2023-08-17T06:30:44.211878 [RLC     ] [D] ue=0 DRB1 DL: Triggering buffer state update to lower layer
2023-08-17T06:30:44.211893 [RLC     ] [D] ue=0 DRB1 DL: Sending buffer state update to lower layer. bs=355
2023-08-17T06:30:44.212039 [zmq:tx:0:0] [D] Socket received request.
2023-08-17T06:30:44.212060 [zmq:tx:0:0] [D] Socket sent 5760 samples.
2023-08-17T06:30:44.212109 [zmq:rx:0:0] [D] Socket received 11520 samples.
2023-08-17T06:30:44.212131 [zmq:rx:0:0] [D] Socket sent request.
2023-08-17T06:30:44.212237 [zmq:tx:0:0] [D] Socket received request.
2023-08-17T06:30:44.212813 [zmq:tx:0:0] [D] Requested to transmit 5760 samples.
2023-08-17T06:30:44.212829 [zmq:rx:0:0] [D] Requested to receive 5760 samples.
2023-08-17T06:30:44.212869 [FAPI    ] [D] [    57.4] Slot.indication
2023-08-17T06:30:44.212873 [zmq:tx:0:0] [D] Socket sent 5760 samples.
2023-08-17T06:30:44.212902 [SCHED   ] [D] [    57.4] ue=0 rnti=0x4601 PDSCH allocation skipped. Cause: No available HARQs
2023-08-17T06:30:44.212908 [SCHED   ] [D] [    57.4] Processed slot events:
- RLC Buffer State: ue=0 lcid=4 pending_bytes=355

Setup Details

• srsRAN_Project: e043e1e404de5e8a8e74bceaa37b31068b338948 (master)
• srsRAN_4G: fa56836 (master)
• ue.conf and gnb.conf from documentation ("The following config files were modified to use ZMQ-based RF driver") together with qos.yaml
• Tried on Ubuntu 22.04.2 on aarch64 and Ubuntu 22.04.1 on x86_64

Steps to reproduce the problem

1. Start gnb
2. Start srsue
3. Wait for PDU Session Establishment successful. and RRC NR reconfiguration successful. messages
4. Add a default route: ip netns exec ue1 ip route add default dev tun_srsue
5. Observe working connectivity with sudo ip netns exec ue1 ping remote-host for 10-20 seconds (this step can be omitted by simply waiting for around 20 seconds)
6. Observe ICMP replies not arriving to UE anymore (but visible on the remote host being pinged, UPF and gnb GTPU logs)

[s5uishida]

I had the same issue in my environment.

[andrepuschmann]

Hey @dziugas-wg2 - you don't share full logs but I guess your "waiting" results in a UE context release from the RAN/core due to user inactivity. The issue now is that this works well with full UEs, e.g. COTS phones, but not with srsUE because srsUE for 5G SA simply doesn't handle UE idle procedures. But you need to share full logs to confirm. Also try to increase the inactivity timer and see if that shifts the time before it "breaks".

[dziugas-wg2]

Apologies for not attaching the full logs previously @andrepuschmann , here are the full srsue and gnb logs gnb-ue-logs.zip.

Could you advice which inactivity timer I should be increasing? A 5G core we are using does not enforce an inactivity timer, suggesting that it should be gnb that does that even though a UE is actively sending traffic. I see that srsenb has rrc_inactivity_timer, but I cannot find the respective timer in srsRAN_Project / gnb. I found two related tickets #862 and #1066, but unfortunately none of them discuss how to increase the user inactivity timer in srsRAN_Project / gnb.

[dziugas-wg2]

I can confirm that at least the CU/CP inactivity timer (e.g., gnb cu_cp --inactivity_timer 7200 and seen in E1AP Bearer Context Setup Request as UE-Inactivity-Timer IE) does not seem to have any effect and the issue still persists. There are no F1AP messages after the initial RRC Reconfiguration Complete. There is also nothing "special" inside the MAC pcap except that ICMP replies on the DL-SCH channel are not seen after the "timeout" (in this example 9 ICMP replies went though) kicks in, but ICMP requests on UL-SCH keeps coming.

gnb-e1ap-f1ap-mac.pcap.zip

[frankist]

Hey, I am not seeing the scheduler doing any retransmissions. Eventually, all the HARQs are getting stalled. Can you share your full config?

[dziugas-wg2]

gnb:

• configuration: gnb.conf.zip
• command line: gnb -c gnb.yaml -c gnb-qos.yaml --gnb_id 1 amf --addr 172.42.42.20 --bind_addr 172.42.42.10 ru_sdr --device_args fail_on_disconnect=true,tx_port=tcp://*:1000,rx_port=tcp://127.0.0.1:1001,id=gnb,base_srate=11.52e6 cell_cfg --plmn 00101 --all_level debug cu_cp --inactivity_timer 7200

srsue:

• configuration: ue.conf.example
• command line: srsue --rf.device_name=zmq --rf.device_args=tx_port=tcp://*:1001,rx_port=tcp://127.0.0.1:1000,id=ue,base_srate=11.52e6 --rf.srate=11.52e6 --rf.tx_gain=50 --rf.rx_gain=40 --rat.eutra.dl_earfcn=2850 --rat.eutra.nof_carriers=0 --rat.nr.bands=3 --rat.nr.nof_carriers=1 --rrc.release=15 --rrc.ue_category=4 --gw.netns=ue1 --usim.imei=*** --usim.imsi=*** --usim.k=*** --usim.opc=*** --nas.apn=ims --log.all_level=debug

[s5uishida]

In my environment, there was a similar issue when using Open5GS and free5GC for CN and connecting gNodeB and NR-UE of srsRAN. (I have slicing enabled.)

The configuration details in this case are as follows.

• https://github.com/s5uishida/open5gs_5gc_srsran_sample_config
• https://github.com/s5uishida/free5gc_srsran_sample_config

FYI.

[frankist]

I noticed that you are not using the latest release. Can you see if you still see the same issue for the latest release?

If you still see the same issue, I will require your help to run this with the debugger, as I cannot reproduce the issue. I would request the following steps:

1. run the gnb in debug and wait for PDSCH allocation skipped. Cause: No available HARQs to appear. You can see this by running in the console tail -f /path/to/your/gnb.log | grep "PDSCH allocation skipped"
2. Once you start seeing "PDSCH allocation skipped" log lines, place a breakpoint in this line
3. Once the breakpoint in 2. is hit, keep stepping through the code and let me know what if condition is forbidding the function from reaching this line

Let me know if you need more help.

[dziugas-wg2]

Thanks @frankist for your reply. I did not pay attention to the fact that there has been a significant number of commits to the srsRAN_Project repo recently. I recompiled gnb using the head of the main branch (1afd7240f2b5e2061ab4158e8fcdacb15961813a) and I was initially able to see ICMP replies delivered to the UE in 10 minutes without any packet loss that never happened before. However, restarting srsue and gnb made the issue to reappear and downlink packets stopped flowing after around 14 seconds and error messages [W] [ 605.2] ue=0 rnti=0x4601 PDSCH allocation skipped. Cause: No available HARQs. Check if any HARQ-ACK went missing or is arriving to the scheduler too late.. appearing in the log (see full gnb.log.gz). Another restart – downlink packets keeps flowing, one more – downlink packets stop flowing after ~15 seconds.

I will try to run gnb with gdb as you suggested and come back to you as soon as I am able to hit the breakpoint.

[moycat]

I have exactly the same problem. When using ZeroMQ, the downlink stops working after between 10 seconds to 10 minutes, with PDSCH allocation skipped. Cause: No available HARQs. in logs. Sometimes it works fine for a long time (over 30 minutes), sometimes the downlink does not work since srsue starts.

• Ubuntu 22.04.3 + Linux 5.15.0-82-generic x86_64
• srsRAN_Project: latest (1afd724)
• srsRAN_4G: latest (fa56836)
• Core network: open5gs 2.6.4 (installed via apt)

I am using the configuration files from srsRAN gNB with srsUE.

[dziugas-wg2]

@frankist Stepping with gdb suggests that line 157 is reached, but pdsch_alloc.allocate_dl_grant() function is returning false:

(gdb) bt
#0  alloc_dl_ue (u=..., res_grid=..., pdsch_alloc=..., is_retx=true, logger=...) at /home/dziugas/git/srsRAN_Project/lib/scheduler/policy/scheduler_time_rr.cpp:156
#1  0x0000aaaaab7a81e8 in operator() (__closure=0xffffcefdd4d8, u=...) at /home/dziugas/git/srsRAN_Project/lib/scheduler/policy/scheduler_time_rr.cpp:296
#2  0x0000aaaaab7a8630 in round_robin_apply<srsran::scheduler_time_rr::dl_sched(srsran::ue_pdsch_allocator&, const srsran::ue_resource_grid_view&, const srsran::ue_repository&, bool)::<lambda(const srsran::ue&)>, srsran::scheduler_time_rr::dl_sched(srsran::ue_pdsch_allocator&, const srsran::ue_resource_grid_view&, const srsran::ue_repository&, bool)::<lambda()> >(const srsran::ue_repository &, srsran::du_ue_index_t, const struct {...} &, const struct {...} &) (ue_db=..., next_ue_index=1, alloc_ue=..., stop_cond=...)
    at /home/dziugas/git/srsRAN_Project/lib/scheduler/policy/scheduler_time_rr.cpp:53
#3  0x0000aaaaab7a8354 in srsran::scheduler_time_rr::dl_sched (this=0xffffc8002270, pdsch_alloc=..., res_grid=..., ues=..., is_retx=true) at /home/dziugas/git/srsRAN_Project/lib/scheduler/policy/scheduler_time_rr.cpp:307
[...]
(gdb) p are_crbs_valid
$1 = true
(gdb) p ue_grant_crbs.length()
$2 = 44
(gdb) p is_retx
$3 = true
(gdb) s
157	          const bool res_allocated = pdsch_alloc.allocate_dl_grant(ue_pdsch_grant{&u,
(gdb) n
157	          const bool res_allocated = pdsch_alloc.allocate_dl_grant(ue_pdsch_grant{&u,
(gdb) n
165	          if (res_allocated) {
(gdb) p res_allocated
$4 = false

[dziugas-wg2]

Here is why pdsch_alloc.allocate_dl_grant() returns false:

(gdb) s
alloc_dl_ue (u=..., res_grid=..., pdsch_alloc=..., is_retx=true, logger=...) at /home/dziugas/git/srsRAN_Project/lib/scheduler/policy/scheduler_time_rr.cpp:157
157	          const bool res_allocated = pdsch_alloc.allocate_dl_grant(ue_pdsch_grant{&u,
(gdb) s
srsran::ue_cell_grid_allocator::allocate_dl_grant (this=0xffffc8005748, grant=...) at /home/dziugas/git/srsRAN_Project/lib/scheduler/ue_scheduling/ue_cell_grid_allocator.cpp:51
51	{
(gdb) info args
this = 0xffffc8005748
grant = @0xffffcefdd340: {user = 0xffffc8415140, cell_index = srsran::MIN_DU_CELL_INDEX, h_id = 0, ss_id = 1, time_res_index = 0, crbs = {<srsran::interval<unsigned int, false>> = {start_ = 1, stop_ = 45}, <No data fields>}, aggr_lvl = srsran::aggregation_level::n4, 
  mcs = {<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> >> = {<srsran::strong_equality::strong_property<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> > >> = {<No data fields>}, <srsran::strong_equality_with<unsigned char>::strong_property<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> > >> = {<srsran::detail::strong_equality_with_type<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> >, unsigned char>> = {<No data fields>}, <No data fields>}, <srsran::strong_comparison::strong_property<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> > >> = {<No data fields>}, <srsran::strong_comparison_with<unsigned char>::strong_property<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> > >> = {<srsran::detail::strong_comparison_with_type<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> >, unsigned char>> = {<No data fields>}, <No data fields>}, val = 3 '\003'}, <No data fields>}}
(gdb) n
52	  srsran_assert(ues.contains(grant.user->ue_index), "Invalid UE candidate index={}", grant.user->ue_index);
(gdb) n
53	  srsran_assert(has_cell(grant.cell_index), "Invalid UE candidate cell_index={}", grant.cell_index);
(gdb) n
54	  ue& u = ues[grant.user->ue_index];
(gdb) n
57	  ue_cell* ue_cc = u.find_cell(grant.cell_index);
(gdb) n
58	  if (ue_cc == nullptr or not ue_cc->is_active()) {
(gdb) n
65	  const ue_cell_configuration& ue_cell_cfg = ue_cc->cfg();
(gdb) n
66	  const cell_configuration&    cell_cfg    = ue_cell_cfg.cell_cfg_common;
(gdb) n
67	  const bwp_downlink_common&   init_dl_bwp = *ue_cell_cfg.bwp(to_bwp_id(0)).dl_common;
(gdb) n
68	  const bwp_downlink_common&   bwp_dl_cmn  = *ue_cell_cfg.bwp(ue_cc->active_bwp_id()).dl_common;
(gdb) n
69	  dl_harq_process&             h_dl        = ue_cc->harqs.dl_harq(grant.h_id);
(gdb) n
72	  const search_space_info* ss_info = ue_cell_cfg.find_search_space(grant.ss_id);
(gdb) n
73	  if (ss_info == nullptr) {
(gdb) s
77	  if (ss_info->bwp->bwp_id != ue_cc->active_bwp_id()) {
(gdb) n
81	  const search_space_configuration& ss_cfg = *ss_info->cfg;
(gdb) n
82	  const coreset_configuration&      cs_cfg = *ss_info->coreset;
(gdb) n
86	  if (not h_dl.empty() and h_dl.last_alloc_params().dci_cfg_type != ss_info->get_crnti_dl_dci_format()) {
(gdb) n
87	    return false;
(gdb) p h_dl
$1 = (srsran::dl_harq_process &) @0xffffc84b9d10: {<srsran::detail::harq_process<true>> = {static DEFAULT_ACK_TIMEOUT_SLOTS = 256, static MAX_NOF_TBS = 2, id = 0, logger = @0xffffc85527f8, timeout_notifier = {handler = 0xffff5ae1b300, ue_index = srsran::MIN_DU_UE_INDEX}, 
    max_ack_wait_in_slots = 256, ack_wait_in_slots = 256, last_slot_tx = {static NOF_NUMEROLOGIES = 5, numerology_val = 0, count_val = 352}, last_slot_ack = {static NOF_NUMEROLOGIES = 5, numerology_val = 0, count_val = 356}, tb_array = {_M_elems = {{
          state = srsran::detail::harq_process<true>::transport_block::state_t::pending_retx, ndi = true, nof_retxs = 0, max_nof_harq_retxs = 4, dai = 0 '\000'}, {state = srsran::detail::harq_process<true>::transport_block::state_t::empty, ndi = false, nof_retxs = 0, 
          max_nof_harq_retxs = 0, dai = 0 '\000'}}}}, prev_tx_params = {dci_cfg_type = srsran::dci_dl_rnti_config_type::tc_rnti_f1_0, rbs = {alloc_type_0 = false, alloc = {rbgs = {static bits_per_word = 64, buffer = {_M_elems = {188978561024}}, cur_size = 0}, 
        interv = {<srsran::interval<unsigned int, false>> = {start_ = 0, stop_ = 44}, <No data fields>}}}, nof_symbols = 12, tb = {_M_elems = {{storage = {<srsran::detail::base_optional_storage<srsran::dl_harq_process::alloc_params::tb_params>> = {payload = {dummy = 0 '\000', 
                val = {mcs_table = srsran::pdsch_mcs_table::qam64, 
                  mcs = {<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> >> = {<srsran::strong_equality::strong_property<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> > >> = {<No data fields>}, <srsran::strong_equality_with<unsigned char>::strong_property<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> > >> = {<srsran::detail::strong_equality_with_type<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> >, unsigned char>> = {<No data fields>}, <No data fields>}, <srsran::strong_comparison::strong_property<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> > >> = {<No data fields>}, <srsran::strong_comparison_with<unsigned char>::strong_property<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> > >> = {<srsran::detail::strong_comparison_with_type<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> >, unsigned char>> = {<No data fields>}, <No data fields>}, val = 3 '\003'}, <No data fields>}, tbs_bytes = 301}}, has_val = true}, <No data fields>}}, {
          storage = {<srsran::detail::base_optional_storage<srsran::dl_harq_process::alloc_params::tb_params>> = {payload = {dummy = 0 '\000', val = {mcs_table = srsran::pdsch_mcs_table::qam64, 
                  mcs = {<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> >> = {<srsran::strong_equality::strong_property<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> > >> = {<No data fields>}, <srsran::strong_equality_with<unsigned char>::strong_property<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> > >> = {<srsran::detail::strong_equality_with_type<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> >, unsigned char>> = {<No data fields>}, <No data fields>}, <srsran::strong_comparison::strong_property<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> > >> = {<No data fields>}, <srsran::strong_comparison_with<unsigned char>::strong_property<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> > >> = {<srsran::detail::strong_comparison_with_type<srsran::strong_type<unsigned char, srsran::detail::bounded_integer_tag<unsigned char>, srsran::strong_equality, srsran::strong_equality_with<unsigned char>, srsran::strong_comparison, srsran::strong_comparison_with<unsigned char> >, unsigned char>> = {<No data fields>}, <No data fields>}, val = 0 '\000'}, <No data fields>}, tbs_bytes = 0}}, has_val = false}, <No data fields>}}}}}}
(gdb) p h_dl.empty()
$2 = false
(gdb) p h_dl.last_alloc_params().dci_cfg_type
$3 = srsran::dci_dl_rnti_config_type::tc_rnti_f1_0
(gdb) p ss_info->get_crnti_dl_dci_format()
$4 = srsran::dci_dl_rnti_config_type::c_rnti_f1_0
(gdb) p h_dl.last_alloc_params().dci_cfg_type != ss_info->get_crnti_dl_dci_format()
$5 = true
(gdb) n
337	}
(gdb) n
alloc_dl_ue (u=..., res_grid=..., pdsch_alloc=..., is_retx=true, logger=...) at /home/dziugas/git/srsRAN_Project/lib/scheduler/policy/scheduler_time_rr.cpp:165
165	          if (res_allocated) {
(gdb) p res_allocated
$6 = false

[frankist]

Ok, I see the issue. This will be solved in the next release. In the meantime, maybe this hotfix is sufficient to avoid this problem:

diff --git a/lib/scheduler/ue_scheduling/ue_srb0_scheduler.cpp b/lib/scheduler/ue_scheduling/ue_srb0_scheduler.cpp
index bac268873..8a5100ca3 100644
--- a/lib/scheduler/ue_scheduling/ue_srb0_scheduler.cpp
+++ b/lib/scheduler/ue_scheduling/ue_srb0_scheduler.cpp
@@ -258,7 +258,7 @@ void ue_srb0_scheduler::fill_srb0_grant(ue&                        u,
 {
   static constexpr uint8_t srb0_dai = 0;
   // Allocate DL HARQ.
-  h_dl.new_tx(pdsch_slot, k1, expert_cfg.max_nof_harq_retxs, srb0_dai);
+  h_dl.new_tx(pdsch_slot, k1, 0, srb0_dai);
 
   // Fill DL PDCCH DCI.
   static const uint8_t msg4_rv = 0;

Edit: i am basically setting 0 retransmissions for msg4, which seems to be the problematic harq

[s5uishida]

Hi @frankist

With that hotfix, ping errors no longer occurred in my environment.

Thank you very much!

[dziugas-wg2]

I can also confirm that having the diff applied No available HARQs errors is not seen anymore. Thanks for the fix.