Previously, we thought the memset in the nr_ue_dl_indication()
was causing issues / exposing a race. This is not the case. The
memset is not problematic, the issue is that in the emulate_l1
mode we were not always configuring the DCI nbits before handling
the DCI when we are pushing high (15 Mbps) throughput traffic.
Instead of conditionally calling the pucch_scheduler
we now only call the functions we need from the stub
function directly. This is better because we are not
modifying the OAI MAC layer code and ensuring that we
are not calling the pucch_scheduler twice for the same
sfn/slot
Adding error checking before indexing in mac layer harq array
Adding error checking before writing ul_harq_sfn_slot
Added comments
Made a "static" free_uci_inds() actually static
We have gotten rid of filling the ACK/NACK with
the DLSCH and now only fill with the PUCCH. This
assumes that the MAC layer is properly decoding the
dl_tti_req and tx_data_req and allows us to
simply use the MAC layers scheduled SNF/Slot
to return the ACK NACK. There are some hacks added
in this commit which ensure that the PDCP packet
has the correct header (1st byte = 80) and now with
15Mbps we are seeing about 20% packet loss and
a gNB bug on the edge case (current frame is 1023
and the gNB schduler wants an ACK in frame 0 but the
scheduled UL_TTI_REQ has a frame of 1023).
It seems that the RA procedure in the gNB was modified so
the RAR is sent in a single tx_data_req. The emualted mode
was not previously handling this. We now only process the
PDU in the rx_ind that has a matching preamble. If any
other PDUs exist, we ignore them and only build Msg3 based
on this single matching RAR PDU.
Also, two bug fixes applied here in the emulate-l1 mode.
When we check if the pointer is NULL before CALLOCing,
then the gNB will crash. It seems that we are mostlikely
leaking memeory since the gNB only crashes with the old
change. By reverting these changes, the gNB does not crash.
We are seeing UE-to-UE IP traffic on this commit when
the tunnel interfaces are established (~50% of the time).
In this commit, we changed the UCI handling.
When the UL_TTI_REQ arrives at the NRUE it
has info related to how many UCIs we should
pull from the queue and send to the gNB. If
we do not have that many UCIs available (likely
becasue a DL_TTI_REQ is late), then we will
requeue the UL_TTI_REQ and wait until we have
all the UCI indications before multiplexing.
This change makes it easier to handle multiple
UCIs becasue previously we would send what we
had and then try again later which made keeping
track of the UL_TTI_REQ and second UCI more
difficult.
Also, we had two heap-buffer-overflow crashes while
filling the CRC_IND and RX_IND. The corrected CALLOC
command is included in this commit as well.
Lastly, we included a better fix for handling late
DL_TTI_REQs. If the number of active harqs is larger
than the number of UCIs we have built, this is a good
indicator that the DL_TTI_REQ is late. To mitigate
problems, we will requeue the UL_TTI_REQ to when the
late DL_TTI_REQ comes in, we can handle the late
UCI that is built from it.
This commit includes a hack fix that has allowed
the Ip traffic to work in SA mode. Furthermore,
NSA mode (without the EPC) works in this commit
as well with up to 4 NSA UEs. We will need to
understand better the issue with the UL_DCI
handling in the NRUE that was causing the gNB
to crash.
The AssertFatal in the gNB when the gNB runs out
of downlink HARQ PIDs is caused by the NRUE
receiving a UL_DCI and then building BOTH a UCI
and a CRC/RX pair. So we are essentially sending
a UL and DL DCI to the gNB in this case which
results in an unexpected HARQ PID being received
in the gNB. The filtering in this commit stops
the UCI being built in the NRUE when a UL_DCI
is recevied.
The IP traffic of a single NRUE works most
of the time in this commit. There seems to
be a bug in the gNB and it will occassionally
crash with a heap-buffer-overflow. This will
be looked at in the next commit.
The changes in this commit include gathering
all of the UCI indications in the queue that
have the same scheduled sfn_slot and sending
them as one aggregated UCI when the scheduled
sfn_slot matches the received ul_tti_request.
The following was changed in this commit:
- A new struct in the mac instance was created
for all emulated L1 fields.
- NR UE RRC state bug was fixed
- Checking the RAR rnti based on the MAC instance
ra.ra_rnti and not hardcoding to 0x10b
- Modified the name of the new emulate_l2 flag
to make sense: emulate_l1
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.
Melissa Elkadi