Includes the following updates:
1. oaisim/lte-softmodem in noS1
2. UE fixes for oaisim
3. IF4p5 fixes (doesn't work on develop)
4. UE fixes for DCI handling (corrects problem introduced in develop)
Conflicts:
cmake_targets/CMakeLists.txt
targets/SIMU/USER/oaisim_functions.c
- print current working directory
- print git version (if available)
- print security keys
this last one is a security breach, but as of today
it's not a problem
- import RRC ASN.1 defintions from the specifications
(file openair2/RRC/LITE/MESSAGES/asn1c/ASN1_files/RRC-e10.asn)
contrary to rel8/10, all modules have been imported, maybe it's too much
to refine in case of problems
- deal with rel14 in fix_asn1
- all code that was for Rel10 is now for Rel10/Rel14
- some incompatible changes (mostly in naming) were resolved in favor
of rel14, see in openair2/RRC/LITE/defs.h
- unsure about the rlc layer, some arrays have changed (values appended),
I only changed the definition and in tests in the code, I changed
the index limit, maybe it's not enough
Rel14 is the default compilation mode.
see https://gitlab.eurecom.fr/oai/openairinterface5g/issues/227
When the UE connects to the eNodeB and receives its IP address from the
network, it calls system() to set it in the linux kernel world. This call
is not done in a realtime thread, but in the NAS, which uses its own thread,
independent of the realtime processing.
In some situations this totally disrupts realtime processing.
It is difficult to know precisely why that happens, but it seems that calling
fork(), as system() does, in a multi-threaded program is not a good idea. (So
say several people on the internet.) It is not clear why the softmodem is
impacted, but it seems that fork() is really what triggers the disruption.
Several tests lead to that conclusion.
To fix the problem, we create a child background process very early in main()
(before anything else basically). Then instead of calling system(), the main
process sends the string to the background process. The background process
gets the string, passes it to system() and reports the success/failure back
to the main process.
This solution involves a lot of system calls, but calling system() in the
first place is not cheap either. As long as no realtime thread uses this
mechanism, things should be fine. Time will tell.
- some cleanup
- thread names to include UE Mod_id
- arg of UE_thread_rxn_txnp4 to be struct rx_tx_thread_data again
- sync in UE_thread_rxn_txnp4 to use instance_cnt_rxtx again
- UE_thread to call itti_send_msg_to_task with UE->Mod_id + NB_eNB_INST
instead of INSTANCE_DEFAULT again
This may break the softmodem UE, to be tested.
The most problematic thing may be the synchronization.
I don't think it will impact the processing at all,
but I won't bet my shirt on it.
The idea is as follows.
oaisim waits for all tasks to be done for a TTI.
To do so it waits for last_rx_timestamp == current_rx_timestamp,
for all UEs and eNBs.
When it's done, it increases current_rx_timestamp by samples_per_tti,
to inform UEs and eNBs that a new TTI is ready.
In the functions [UE|eNB]_trx_read, we wait for a new TTI to be ready,
that is we wait for current_rx_timestamp != last_rx_timestamp.
The UE has also to wait for processing threads to be done.
In the eNB it's not necessary because the processing is all
done in one thread, that is: read subframe, process this subframe,
emit subframe+4, and then back to read subframe.
The code is not clean. We should not use usleep but semaphores.
Also, do_[DL|UL]_sig should not read from rxdata and write to txdata,
but use internal buffers.
The functions [UE|eNB]_trx_read should call do_[DL|UL]_sig and then
copy from the internal buffers of the channel simulator into rxdata.
The functions [UE|eNB]_trx_write should write data passed into the
internal buffers of the channel simulator.
Not sure if this is the right thing to do, but it seems to be.
"start_eNB = 1;" is also necessary when the l2l1 task gets INITIALIZE_MESSAGE
otherwise the eNB does not start.
As it is today, I don't think oaisim will work with more than one eNB.
It was probably the result of a bad merge.
At this point eNB_inst is not valid. Plus the T_ENB_MASTER_TICK
is now handled in lte-enb.c, even for oaisim.
Raymond Knopp