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 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.
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.
1. Prototype of nr indication functions were updated.
2. nr_rx_indication name changed to nr_rx_data_indication
3. Added other logs and assert conditions that were gone away from merge.
4. pnf files were not touched.
5. To be sync with original nfapi branch, the following file was checkout from eurocom-nfapi_nr_arch_mod
nfapi/open-nFAPI/vnf/public_inc/nfapi_vnf_interface.h
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.
This commit includes several changes.
First, it updates the way we fill the uplink
UCI indication. This still has some todo comments
since all the fields in this ind were hardcoded.
It also updates the pack and unpack functions for
the NR_UCI incations. Lastly, it includes updates
to the gNB UCI scheduler. The updates in the gNB
were cherry picked from develop. There are two updates
to the VNF which allow the VNF timing/slots to be
adjusted based on the received timing_info packets
from the VNF. This adjustment was disabled in IISc's
nFAPI code. For now, it is improving the timing
between the VNF and PNF.
Although the timing isnt perfect, if the VNF adjusts
in the middle of scheduling a DCI the gNB would try to
send two DCIs for a certain sfn/slot; this commit will
stop that from happening. The timing issue still persits.
Laurent THOMAS