- RU IP address - to connect to RUs via netconf
- DU MAC address - for setting up the CU-planes on RU; not used in xran
- VLAN tag (*) - for setting up the CU-planes on RU; not used in xran
- DU keypair - for authentication when connecting to RU(s)
The parameters that RU-controller shall retreive from RU list of
capabilities:
- MTU
- compression
- RU MAC address
- PRACH offset (**)
(*) VLAN tag is not used in xran but an option is given in fh_config struct.
In my opinion, it is not a very suitable place, as it is needed for VFs.
Therefore, I moved it in the initialization part for M-plane purposes.
(**) PRACH offset shall be >= max(Ntx,Nrx), as per O-RAN CUS specification:
"The O-DU may decide to use same eAxC ID value to address endpoints on different O-RUs,
but eAxC ID values assigned to one O-RU must be unique within the O-RU’s endpoints of same direction."
=> however, LITEON supports flexible assignment of PRACH eAxC IDs, so
we made a workaround in the xran library to support PRACH eAxC IDs same
as PUSCH eAxC IDs.
Realtime and near-realtime RFSimulator alternative without channel modelling.
The purpose of this library is to allow realtime simulation of gNB and nrUE.
The library is loaded using --device.name shm_radio. The server side (gNB) should also
configure --shm_radio.role server and --shm_radio.timescale <timescale> according to requirements.
Limitations:
- Only 1UE-to-1gNB connection supported
Future work:
- Channel modelling
- Telnet API
- Histogram of the TX time budget
Change to bool for clarity. The log message would sometimes only show up
at the end, which is misleading; use the logging module, which
harmonizes log statements and should make this appear immediately.
We still do not handle RUs with MTUs of 1500 properly in F release;
therefore, for the close future, we cannot remove support for E release.
Also, it "promises" this for January, which is in the past already.
Update to keep the warning logical.
Use `rfsimu_channel_ue1`, `rfsimu_channel_ue2`, etc. if you want to
use different channel models for each client. The client connection
order determines its channel model name.
Enable/disable workaround based on a new option "hanging-workaround".
This addresses an issue where the workaround will trigger even if there
is no risk of a permanent lockup of the system.
Added new command line option to channelmod: noise_power_dBFS. This options
allows the user to configure noise power in dBFS added instead of the per-channel
value.
This makes it so noise is not accumulated per channel reaching higher than expected
values.
The dBFS unit allows easy configuration. The gNB by default uses -36 dBFS setting.
To reach 3dB SNR one should set the noise_power_dBFS value to -39.
To configure using command line use --channelmod.noise_power_dBFS -50. Using this
setting the gNB and nrUE connect without issue.
FHI72: remove polling, fix memory leak
- FHI72 used polling to track the next slot. This is not necessary, a
simple queue does the job and allows to save one core that was
previously at 100%
- Remove a workaround to avoid a memory leak (fixes#812); allows to
also run RFsim/USRP/otehr radios when compiling for FHI72
fix NTN LEO scenarios
- gNB: add support for NTN parameter ta-CommonDrift-r17
- NR UE: fix application of NTN TA information
- NR UE: add command line parameter ntn-initial-time-drift to compensate
time drift during initial sync
- NR UE: fix writeTimestamp inconsistencies
- NR UE: add MAC state UE_RECEIVING_SIB ensuring to start RA only after
successfully receiving SIBs
- rfsimulator: update earth radius for LEO simulation to match UE
position in ue.conf file
- update conf files for NTN LEO scenario
- update description how to run NTN scenarios in RUNMODEM.md
- fix: ta-Common is a round-trip-time, not a one-way delay
- NR UE: simplify calculation of next_tx_slot_and_frame by moving up
assignment of duration_rx_to_tx
- cellbarredNTN indicates notbarred in SIB1 if NTN access is available
- Removed b66 NTN and enabled B254 NTN conf file in CI
- NR UE: RRC layer now explicitly tells MAC layer when the RA procedure
can be started
- move NTN LEO config to band 254 and update doc/RUNMODEM.md
Closes#901
first_rx_set is polling-specific: it makes the polling loop wait to only
check the frame/slot counter once we set it for the first time. However,
that is equivalent to checking the frame/slot directly, which will also
be 0 in the beginning.
first_read_set seems to have the function of making frame/slot time
advance only if we started to read the samples in
xran_fh_rx_read_slot(). I interpret that as "only advance the time if
the gNB is reading from xran", which does not make sense to me, because
xran advances the time anyway. Also, polling would not notice, and
no-polling would simply warn about double messages. So the outcome is
likely the same, whether first_read_set is set or not.
I checked in multiple CI runs; it happens that first_read_set is always
set already when oai_xran_fh_rx_callback() is called anyway.
xran_fh_rx_read_slot() uses polling (a loop over cnt++) to wait for the
next frame/slot. The reasons I have been told is "it does not work
differently", or "there are real-time problems". None of those seem to
be true; by default disable polling, and use the queue instead.
It is possible to enable polling with the cmake option
OAI_FHI72_USE_POLLING=ON. Documentation has been updated to inform about
this change.
The queue L1_rx_out was in place to keep RX/TX processing relatively
"close" to each other (in terms of time, since in RFsim, they might
advance faster than realtime; see also parent commit). This lead to a
memory leak in radios that do not use ru->feprx (no front-end processing
for RX, e.g., PRACH), as the code to read the L1_rx_out messages was
inside a block of if (ru->feprx). Move it out so that the queue is
always read and messages are freed to eliminate the memory leak, and
remove the workaround for FHI72 to avoid this memory leak.
This also allows to run RFsim when compiling FHI72, which was not
possible before this commit.
Closes: #812
Deadlock avoidance in rfsimulator
This change introduces a countermeasure for deadlock in rfsimulator. The
deadlock happens when all entities are waiting for new data to come in,
and happens with 2+ clients, when a new client connects. I think this
issue is due to ordering of fullwrite calls, resulting in out-of-order
delivery of packets and eventually trashing the packets on the receiving
side. The out-of-order delivery warnings are printed just before the
system deadlocks but I have not found a better solution so far. The
workaround makes the server never lock up permanently by ignoring the
client failure to write on time after 10 tries.
This was tested locally for both UE as server and gNB as server and
works correctly, causing the deadlock to clear and the added log to be
printed several times when the deadlock is detected, after which the
system goes back to normal.
I have some gdb output of the executables during deadlock:
UE:
$7 = {conn_sock = 98, lastReceivedTS = 3226163740, headerMode = true, trashingPacket = false, th = {size = 13184, nbAnt = 1, timestamp = 3226150556, option_value = 0, option_flag = 0}, transferPtr = 0x7f6a500018a8 "\200\063", remainToTransfer = 24,
circularBufEnd = 0x7f6a503b3ac0 "", circularBuf = 0x7f6a501f1ac0, channel_model = 0x0}
(gdb) p t->buf[5]
$8 = {conn_sock = 97, lastReceivedTS = 0, headerMode = true, trashingPacket = false, th = {size = 0, nbAnt = 0, timestamp = 0, option_value = 0, option_flag = 0}, transferPtr = 0x7f6a50001900 "", remainToTransfer = 24, circularBufEnd = 0x7f6a50575ad0 "",
circularBuf = 0x7f6a503b3ad0, channel_model = 0x0}
nextRxTimestamp 3225937740
nsamps = 30720
gNB 1:
(gdb) p t->buf[0]
$4 = {conn_sock = 95, lastReceivedTS = 3226026876, headerMode = true, trashingPacket = false, th = {size = 1, nbAnt = 1, timestamp = 3226026875, option_value = 0, option_flag = 0},
transferPtr = 0x7f8dfc003ab8 "\001", remainToTransfer = 24, circularBufEnd = 0x7f8e1c3ff010 "", circularBuf = 0x7f8e1c23d010, channel_model = 0x0}
nextRxTimestamp 3225996956
gNB 2:
lastReceivedTS = 3226026875
$2 = {conn_sock = 95, lastReceivedTS = 3226026875, headerMode = true, trashingPacket = false, th = {size = 1, nbAnt = 1, timestamp = 3226026875, option_value = 0, option_flag = 0},
transferPtr = 0x744898003ab8 "\001", remainToTransfer = 24, circularBufEnd = 0x7448bc2e7010 "", circularBuf = 0x7448bc125010, channel_model = 0x0}
nextRxTimestamp 3226026875
As you can see all executables are in have_to_wait state.
FHI72: fix for a distributed antenna array for xran F release
in the Rx callback I reset the number of section descriptions/number of
fragments to 0, but for each antenna up to max number of antennas per
RU, instead of up to max number of distributed antenna array
- in the Rx callback I reset the number of section descriptions/number of fragments to 0,
but for each antenna up to max number of antennas per RU, instead of up to max number of a distributed antenna array
FHI72: FDD support
- harmonize DL/UL PRB mapping in one get_xran_prb_map() function with support
of mixed slot and duplex mode
- do not assume TDD by default
Remove most of m64 type usage
MMX instructions were first SIMD version, the registers management is complex
(_mm_empty()) so, it is better to remove it now and use more recent instructions
anyway, gcc/clang should replace it automatically as long as we enable sse2,
that should always be the case but for code understanding and for ARM porting
for example, it is better to explicitly remove it
Teodora