Although not used in the UE, we currently need to link the F1 library into it.
This is because we do not define ASN_DISABLE_OER_SUPPORT (otherwise, F1 has
compilation problems). In this case, some functions are apparently not
correctly defined, giving linker errors in the UE. Linking F1 in solves the
problem.
This is a hack. It would be better to be able to define ASN_DISABLE_OER_SUPPORT
and have no compilation errors or compile everything with
ASN_DISABLE_OER_SUPPORT except F1. I did not do this because I did not find
another way than add target_compile_definitions() to every target except F1
which adds many lines just so that one target (F1 ASN.1) compiles correctly (in
other words, F1 needs to be fixed).
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).
Khalid Ahmed