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.
The ue_sched_mode is reset to 0 again when we
memset the ul_info and after the CFRA procedure
is complete, then uplink CRCs with the PUCCH
response (PUSCH) are not being sent because the
scheduler isnt being called. This makes the
gNB run out of uplink harq ids since its never
getting the proper responses. The change below
will ensure that we call the scheduler AFTER the
RACH is sent and all the time after that.
When running on some machines, the ue_sched_mode
will be initialized to zero. This will cause
the ul_info the go into the ONLY_PUSCH mode.
We do not want to ever call the scheduler and return.
Furthermore, we only want to call the scheduler after
the NRUE has sent the RACH_IND to the gNB.
Also, removed the check before calling the
nr_uescheduler that was associated with the
ra.state. Lastly, removed the DL_HARQ_PID
position change as that was incorrect.
How? Well, we had to properly allocate the
ul_config_req. We also had to update the
ue_get_rach function. There were several
places where the functionality would check
for a particular mode (ra, sa, phy_test, etc).
In some of these places we had to add NSA mode.
In the VNF, they start the scheduler after 3 sec,
this is sort of a hack, might want to revisit.
This commit also includes removal of printfs.
At this point we are successfully able to build.
Additionally, we can run the scenario,
however, it does not pass. It seems that the gNB
is not connecting to the proxy correctly. Just
wanted to push the progress so far. FYI, the items
that had to be changed to correct the linking issues
were the following:
- mac_rrc_data_ind_ue vs. nr_mac_rrc_data_ind_ue
- rrc_data_req vs. nr_rrc_data_req
- mac_rrc_data_req_ue vs. nr_mac_rrc_data_req_ue
- rrc_data_req_ue vs. rrc_data_req_nr_ue
- rrc_data_req vs. nr_rrc_data_req
The listed functions should be declard in the LTE/NR
UE directory depending on the functionality. Several
were mixed. i.e.: LTE functions being called in NR UE.
Also, removing siWindowLength, siWindowLength_int,
SIBType, SIBPeriod, and siPeriod_int from the NR UE RRC.
These variable were not used in the NR UE and are defined
for LTE only.
Lastly, in the NR_IF_Module.c of the NR UE, the global
variable def_dci_pdu_rel15 is not accessible. Need to
revisit this. For not it is commented out.
The IP traffic still does not work. But we are
updating the NR UE scheduler to ensure we are are
sending true IP traffic. Also, we were getting an
assert(); as well, and there was no logs, so we
fix that in this commit as well.
1. If VNF is slower than PNF, next scheduling will be done after resync.
2. If VNF is unstable in slot progress, next scheduling will be done in next stable status.
3. SFN/SLOT indications are queued in nrUE.
4. get_queue is used instead of unquque for FIFO operation.
Melissa Elkadi