Merge remote-tracking branch 'origin/episys/mel/merge_develop_cfra_working' into episys/mel/merge_develop_cfra_working_for_multiUE

Resolved merge conflict.

Also, the error checking for writing to the TUN
interface was incorrect so that was fixed as well.

1. Changed hard coded preamble index(63) to soft coded.
2. Active UE will not be considered in gNB scheduging RA.
3. Added condition to process dci indication to handle multiple UEs.
4. Bug fix in mutex_lock (unlock to lock). It should be lock rather than unlock.
5. nr_ue_scheduler update not to entering into getting IP traffic to be transmitted in noS1 mode.
6. log update in checking the number of rx_ind or crc

Also, we only should be handling/generating AM
PDUs in the PDCP/RLC layer, not UM PDUs. Updated
the pre-configuration settings. This seemed to
make the uplink traffic work (meaning it gets
from NR UE to the gNB to the EPC). Woo! Still
working on the downlink.

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.

Update on scheduler to relax AssertFatal.

See merge request aburger/openairinterface5g!55

Merge branch 'episys/mel/merge_develop_cfra_working_bufsize' into 'episys/mel/merge_develop_cfra_working'

Be more careful about buffer sizes

See merge request aburger/openairinterface5g!54

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.

Had to add a check for our NSA mode. If we are in
NSA mode, the DCI format options should be populated
with formats 1 and 7 exclusively. This fixed the
DLBWP calculation for the PDCCH PDUs.

Merge branch 'episys/mel/merge_develop_cfra_working' of 10.1.1.59:aburger/openairinterface5g into episys/mel/merge_develop_cfra_working

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

However, when we free after we encode, fsanitize isnt happy.
Need to clean that up. Also, found an actual bug in LTE.
For the random value issue from fall 2020, we added a fix.
This fix uses ctxt and we were getting ctxt properly.
Lastly, we allocated some memory in processing of the
NR Meas report in the eNB.

Integration Branch : 2021 week 32

See merge request oai/openairinterface5g!1224

The following Merge Requests have been included:

* MR [1198] : 5G UE UCI procedurers at MAC
* MR [1207] : Code-cleanup-20210716
* MR [1215] : NR UL antenna ports cleanup
* MR [1220] : Temporary fix for CORESET configuration in SIB1
* MR [1221] : Container: adding conf template to gNB container image

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

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.

Merge branch 'episys/mel_and_david_ip' of 10.1.1.59:aburger/openairinterface5g into episys/mel_and_david_ip

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Added crnti checking in nrUE and update in gNB

See merge request aburger/openairinterface5g!53