To control along with pusch_maxNumRepetitionCEmodeA_r13 the actual number of repetitions for PUSCH according to 36.213 table 8.2b
Scope of commit: Parsing parameter's value. The value should be used in future commits.
Signed-off-by: Mohamed Gamal <mohammed.abdelkhalek.ext@orange.com>
The 5G phone OPPO has a very big UE capability (> 2KB).
We need bigger buffers to transfer this, especially in x2 handover.
Also the sctp messages need a bigger buffer.
Note: in sctp, we didn't check for partial messages, it's now
done. When detected, we exit. To be redone differently
if needed. (Look for "if (!(flags & MSG_EOR))".)
In the configuration file, to enable measurements, add:
enable_measurement_reports = "yes";
Note that if x2 is enabled then the option 'enable_measurement_reports'
is not taken into account and the measurements are enabled.
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.
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
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).
laurent