Also, in the nr_rrc_mac_config_req_ue(), we should
only be configuring L1 if we are not in the L2 emul
mode. We are crashing due to the RRC state in the NRUE
not being set/checked properly.
In this commit, we changed the stub function of the NRUE
to handle the MIB and SIB1, which arrive in a single
DL_TTI_REQ. If we have not received the MIB, we first
call the scheduler, then we handle any received NFAPI
messages. The NFAPI message handler will then call
the nr_ue_dl_indication() again, which will process
first the MIB, then SIB1. It seems that we are not
properly sending the SIB1 response back to the gNB so
the NRUE eventually crashes. We are however, properly
decoding the MIB and SIB which is a step in the right
direction!
In the previous commit, the NRUE would record
the time it received a slot and compare this
rx time to the next slot. If the next slot
came in before it had been 500us, the NRUE
would sleep a delta amount to make the duration
between the two slot indications 500 us. This
change complicated the code and did not
improve the performance so it was removed.
Furthermore, this commit removes the old
queueing mechanism of the slot indications and
uses calloc rather than an array.
Also, reverted some init_pdcp logic to match
the develop branch and added NSA mode. Lastly,
added additional error checking for cellConfig
to avoid crash in MAC layer.
Also, this commit changes the len argument in the
pusharray32 to match the actual field type (uint16_t).
There is also simple name change from sf -> slot.
The new queueing system is not a permanent solution.
It was simply a way for us to try to handle late
dl_tti_requests. If we queue every single ul_tti_req
that we get, the queue gets full very quickly becasue
we only remove ul_ttis from the queue when a uci has
been populated with a matching sfn/sf. Because of this,
we only queue ul_ttis if we have a uci_indication
prepared already. Rarely, a dl_tti_req will arrive at
the NRUE too late, and the NRUE does not have time
to create the uci_ind so we dont process the corresponding
ul_tti. A seprate queue was made to hold all other ul_ttis
the arrive in the NRUE (this queue will continuously
get full and then emptied) but will occasionally hold
a ul_tti that corresponds to a uci that hasnt
been populated yet.
Melissa Elkadi