-- EPC lists are expended to 16 users
-- UE .u* files are regenerated on demand
-- ping still one UE from EPC
CI: pipeline improvement
-- L2-Sim is no more a build variant
One VM less to be created
Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>
-- Master has now a stage calling the Band 13 job
-- Pipeline executor is now a parameter
Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>
-- RRU max rx gain is given in command line
-- USRP reset is only done once in protocol split scenarios
Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>
This commit introduces X2AP timers (t_reloc_prep, tx2_reloc_overall).
You need to set the values in the configuration file.
X2AP can be enabled or disabled in the configuration file too (disabled
by default).
Some deadcode was removed.
-- Moved the Gitlab notification within the try:
As a result, when fails, the notification will be a fail
-- Changed all exit by return in the runTest script
Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>
Some deadcode was removed.
The implementation of the ID management is not finished.
It will only work if the handover is successful. No error
recovery has been done. For error recovery, we need to
implement the X2AP timers. As it is, in case of error, an ID
might very well never be released.
It has been tested with 1 and 2 UEs doing handover more or less
at the same time.
- manage target eNB based on target cell id received by measurement report
for Handover Request
- manage source eNB based on association id for Handover Request Ack
- use only x2ap instance and not x2ap data instance points to x2ap instance
- free correctly in rrc_eNB_free_mem_UE_context
- check for existence of ue_context.handover_info in rrc_enb_process_itti_msg
- check return value sctp_peeloff in sctp_handle_new_association_req_multi
and exit in case of failure
When testing x2 handover, we found a race issue between the
RRC thread and the phy/mac thread (which is calling rrc_rx_tx).
The UE context was updated by the RRC thread but in the middle of
the update (which consists of several function calls and variables'
updates) the context was accessed by rrc_rx_tx. At this point, the
context was in an inconsistent state.
The solution is to access RRC data in the RRC thread only.
The function rrc_rx_tx now just sends an ITTI message to the
RRC thread. When receiving this message, the RRC thread does
the processing that was done by the function rrc_rx_tx (in
the new function rrc_subframe_process).
This way, the race condition disappears.
However we now send an ITTI message from the phy/mac thread to
the RRC thread at each subframe. That might increase the processing
time of the eNB. So maybe it's not the best solution. It may also
improve the realtime performance because less work is done by the
phy/mac realtime thread. To be checked somehow.
Also, it may be possible that some other RRC functions are still
called by the phy/mac thread, which should also be checked and
replaced by ITTI messages (if this solution is considered to be
correct).
Raphael Defosseux