- the band is coming from the SI, therefore a function to get the band is not
necessary
- this solves also the limitations of the get_band algorithm with the NR bands
overlapping in the NR operating bands table (e.g. band 78 and band 48)
- adapted the get_band function: the algorithm is now taking into account
also the UL frequency in order to fetch the proper band (this was failing
before as some NR bands have the same DL band, e.g. band 65 and 66)
- added new bands to the NR table as per TS 38.101 V16.4.0 (2020)
- made the from_nrarfcn function compatible with UL FDD (this function,
used for both DL and UL was previously working with TDD only as it
did not compute properly the frequency for the UL FDD, throwing asserts)
- introduced common functions to get the NR table idx and the duplex mode,
removing repeated code in the process
- removed the unused function to get the uldl offset
- improved some logging
- other minor fixes to the relevant code
- the RU now supports IF equipment with custom FR1 TX/RX frequencies
- this configuration parameter together with the if_freq parameter allows
to set a custom IF RX frequency for the gNB
- if the IF offset is not specified, legacy code applies
A test with band 79 was not working. It turns out that the computation
of the frequency from the NR-ARFCN was giving a wrong value.
After fixing band 79 as found in this commit, the frequency was correct.
The array nr_bandtable has then been reviewed fully and all the values
that were wrong have been changed. The check of correctness was done
using the website https://www.sqimway.com/nr_band.php
This completely removes the UESIM_EXPANSION define: it does not compile
at the moment. Its function was to multiplex multiple UEs on the same
TUN interface. However, this functionality is not needed since it is
possible to allocate many TUN devices (i.e., >= 32).
Various mutexes are present in the phy_stub_UE.c file. However, it will
only be run in a single thread; the multiple-thread implementation also
runs the higher layers concurrently, which leads to races and segfaults.
Therefore, remove these mutexes, as we don't need them.
-Since the aim of itti RRC_SUBFRAME_PROCESS message (MAC->RRC) is to trigger an itti X2AP_SUBFRAME_PROCESS message (RRC->X2AP), avoid creating
RRC_SUBFRAME_PROCESS message if x2ap task is not enabled. Not sure if this is the best solution. We could also avoid only sending the second itti X2AP_SUBFRAME_PROCESS message.
Thomas Schlichter