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.
It also includes the queuing development. The idea
is that the 5G Userplane messages will be filled
and configured the same as previous commit, but
the uplink messages will be queued and then sent to
the gNB during the correct slot. Still WIP.
This commit properly is filing the dci_format but the
rx_ind and dl_ind has not been updated in the NR UE
prior to sending to gNB. The chnages in this commit
to properly fill the dci_format include:
- filling the dci canidates every slot indiction
- checking for a dl_tti/ul_tti containing a dci
- when dci payload is received we use the filled
dci canidates to update the dci_format
Also, a bug in LTE UE is found where we are indexing
passed the end of ue_sdu array. We added a check for this.
Furthermore, in the nr_ue_scheduler we were utilizing
tx_req but the memory wasnt properly initialized.
Also started handling ul_dci that is received in NR UE.
We now receive dci format 01, 10, and 11 at the NR UE.
The dl_info being filled in NRUE was not memset to 0, that
has been added. Additionally, we will need to get the dci_format
based on the length in the dl_config structs and map it.
For the moment the dci_format values are hard coded.
Also, there is not a field for dci_format in
nFAPI so there is a way it is detected by the NR UE.
For now, we have hardcoded the value in the stub when
we receive the DCI. Lastly, updated the nr_harq_handling
in the gNB.
This commit contains the changes to the OAI code in
the NR UE and in nFAPI.
- Filling crc_ind for msg3
- Updating pack/unpack of CRC_ind
- Creating phy abstraction CRC_ind handling in VNF
- Removal of old comments
- Only sending on RACH in phy_stub
- Calling nr_msg3_transmitted in scheduler for NSA mode
The send_standlone_msg will now be able to send
any type of uplink message and we fill the RX
indication in the stub_schedule_response and
are trying to send to gNB. Need to update the NR nfapi.
- Hardcoding the freq_index when filling RACH
- Not handling DCI unless dci_rel_15 global is allocated
- Verifies ra_rnti matches in prach pdu and RACH
- Updates handling of DCI and RX from dl and tx reqs
Melissa Elkadi