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.
- replaced taus with a random seed + random number generation
- this fixes the bug with multiple UEs starting RA in the same time frame and slot
and selecting the same preamble index
In this commit we were trying to understand why
the memset of the def_dci_pdu_rel15 array in the NRUE
was casuing the NR UE to crash. This was happening
becuase some of the members of the def_dci_pdu_rel15
array canont be zero in NSA mode. This was happening
because sometimes, we would recevied two DCI indications
in a row, after the first one, we would be memesetting
the array to all 0s and then try to process the second
DCI. The fix we have implemnted is to call the configure_dci()
prior to processing ANY DCI, to ensure we have properly
configured the UE to handle these DCIs.
Also, in the gNB, it was not able to find the UL scheduled
slot for the feedback harq because it was not accounting for
the slot wrapping.
Removing the memset seemed to hide the problem
and now the problem is appearing in a differnt
manner... it is causing the NRUE to skip HARQ
PIDs as its filling the UCI indication and process
the DCI PDUs. So adding the memset causes the NR UE
to crash becasue the DL_BWP_ID is becoming 0
which leads us to index into an pointer that is not
allocated and then a crash happens in DCI handling.
This requires some updates to the nFAPI code as well.
We also have declared the def_dci_rel15 extern variable
consistently throughout the code.
In this commit, the gNB is still crashing. However, it seems
that the NSA UE is sending the proper responses back, but there
some sort of incorrect management of the def_dci_pdu_rel15
variable. If we memset this array to 0, we can see incorrect
0 assignments to elements of the UCI indications. Hopefully
fixing this issue will result in less gNB crashes.
Melissa Elkadi