For multiple UEs, we need to be able to filter the rx'd messages by
the RNTI. However, we do not have the RNTI value until the CFRA (NSA)
or CBRA (SA) procedure is complete. The check below will handle this.
Also, depending on the RNTI value, we can have a SIB (0xffff), RAR (0x10b),
Msg3 (TC_RNTI) or an actual DCI message (CRNTI). When we get Msg3, the
MAC instance of the UE still has a CRNTI = 0. Only once the RA procedure
succeeds is the CRNTI value updated to the TC_RNTI.
1. The preamble index in the NRUE is random for SA.
Using the preamble index from the mac->ra is
correct.
2. The dl_pathloss calculated is from L1. We should
shunt this feature out for our emulated mode. If
we add the abstraction later, we can model the
pathloss in the proxy and update it in the RA
procedure of the NRUE.
3. Checking that the crnti != t_crnti is not valid
for SA mode. And may only be needed for multi-UE
in NSA mode. We might be able to delete it all
together. For now, we only use for NSA mode.
4. Checking the RAR based on rnti = 10b and not the
RA_STATE is better.
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.
In SA mode, there were DCI_INDs and RX_INDS that
were allocated on the stack and were assigned to
pointers used in the MAC instance. In NSA mode we
allocated these members on the heap so we free'd
them once we were done. In SA mode, they were not
allocated on the heap so this free call caused an
a free() error. We have now allocated these pointers
on the heap to avoid this error and ensure the
pointers are correct.
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.
This commit is properly allocating the NR nFAPI
messages on the heap; however, when we do this,
it makes the NR UE behind the gNB even more and
casuses us to not finish the CFRA procedure. This
is because the RAR is recevied in the NR UE, but
the slot indications are too far in advance, so
the CRC/RX pair (msg3) is never sent because
the scheduled ul_slot and ul_frame already was
received prior to getting the RAR.
Need to fix this!!
This commit allows us to call the scheduler for
every slot indication we get to ensure we properly
configure the DCI. Also, we are sure to process the
DCI only when we have both the config (dl_tti) and
the payload (tx_req). Lastly, removed the hack
to the slot indication (we do not shift the slot
indication by -6 anymore). We are passing up to 4
NSA UEs, but sometimes one will not complete the CFRA
procedure.
This commit changes the stub functionality entirely.
We are now queueing any received NR nFAPI message
and handling it only after we recevie a slot ind
that corresponds with the nFAPI message's sfn/slot
value. When doing this, an existing issue has been
brought to light. The gNB and NR UE are not in sync
when it comes to their slot indications. Generally,
the NR UE seems to be ahead of the gNB by around 6-7
slots. This commit has a hack... when we receive a
slot indication at the moment, we decrament it by 6
to try to keep the NRUE from being ahead of the gNB.
This will be fixed shortly... This was a temporary
fix..
By reverting this change, we will see the NRUE2 crash
because the DCI wont be configured before handling.
This will get fixed in the next commit by adding
queues for the nFAPI messages, therefore forcing
us to handle the nfapi messages only after we have
processes the corresponding slot indication.
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.
In this commit, we create a new flag in the MAC
instance which is set to true if the recevied
DL DCI PDU's RNTI value matches the current UEs
RNTI value. If the RNTI value does not match,
then we should not process the recevied tx_request.
This check should only take place after the CFRA
procedure is complete.
Previously, we thought that filling the UCI ind
after we got the pdsch payload would stop the
harq_pid from going inactive, but this was not
the case. The harq_pid is getting set to inactive
too early because of the sf_slot ahead value. The
fix for this will come in the next commit.
The harq_pid is set to inactive during the scheduling
of ACK/NACK, but this is happening before tx_req (PDSCH)
is recevied. We update the global harq_pid then use it
once we get the PDSCH PDU, then we set it to inactive.
Also, the global previously wasnt being set properly because
a memset was changing the def_dci_re15 struct. We now
memset after we update the harq_pid global.
In this commit, we introduced a new global to save
the harq_pid from the PDCCH that comes down in the
DCI message so that we can use the harq_pid in the
PDSCH. Now, the UCI ind will be filled after we
have recevied the PDSCH in the tx_request.
Previously, we would assume every downlink in
slot 7 was an RAR; now we assume every slot 7
that occurs before the CFRA procedure is done
is an RAR. Also changed the logic in scheduler
to allow us to get nr_ue_sdus in the MAC layer.
Melissa Elkadi