[srsran-users] Issue with msg3 timing with commercial gNB

Magnus Kårdahl magnus.kardahl at ericsson.com
Tue Dec 6 15:14:46 UTC 2022


Hi,

I’m trying to get srsUE NR SA working with a commercial gNB.

K2 for MSG3 is four slots.
It could work as “Request grant to PHY state for this transmit TTI” seems to take 4 slots.
Problem (at least in my case) seems to be the order things are done.
The UL processing for a certain TTI is actually done before MSG2 is checked for any MSG3 (or how I should phrase it).


src/phy/nr/worker_pool.cc

  // initialize with Rx TTI of RAR
  srsran_slot_cfg_t msg3_slot_cfg = {};
  msg3_slot_cfg.idx               = rar_slot_idx;

2022-12-06T14:18:19.103075 [MAC-NR ] [I] [ 3258] DL RAPID: 15, Temp C-RNTI: 0x4958, TA: 10, UL Grant: [00 d2 00 c0 ]
2022-12-06T14:18:19.103080 [PHY-SA ] [I] [ 3262] Setting RAR Grant: ra-rnti=0x4958 dci=RAR ss=rar hop=0 f_alloc=0x69 t_alloc=0x0 mcs=0 tpc=3 csi=0


Then MSG3 grant is set here, with same slot as above(?):

        phy->set_rar_grant(tb.rx_slot_idx, subpdu.get_ul_grant(), subpdu.get_temp_crnti(), srsran_rnti_type_ra);


But problem is that this part in “src/phy/nr/sf_worker.cc” was actually checking the slot number for MSG3 RAR slot for any grant BEFORE the grant was set….

  // Perform UL processing
  for (auto& w : cc_workers) {
    w.get()->work_ul();
  }


This processing of UL slot seems to need four slots:

src/phy/nr/cc_worker.cc

  // Request grant to PHY state for this transmit TTI
  srsran_sch_cfg_nr_t pusch_cfg       = {};
  bool                has_pusch_grant = phy.get_ul_pending_grant(ul_slot_cfg.idx, pusch_cfg, pid);

2022-12-06T14:18:19.106999 [PHY1-NR] [D] [ 3262] EXTRA DEBUG UL processing ul slot=3266


Any ideas on how to proceed?
Has anyone tried NR SA with commercial gNB?





Another issue, not as stopping, is that MSG3 is discarded after first attempt.
So on any subsequent MSG1/MSG2 there is no MSG3 to send:

/srsue/src/phy/nr/cc_worker.cc:634: No MAC PDU provided by MAC

Thanks
Magnus K
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20221206/191892da/attachment.htm>


More information about the srsran-users mailing list