UE_list_t is now used as a separate list. It can be e.g. used in the
scheduler to mark groups of users. The original UE_list_t is renamed to
UE_info_t to reflect that it is a container for information about UEs.
The timer code used to trigger periodic statistics message sending used
ITTI. Together with a high frequency reporting (e.g. 1ms), this resulted
in high CPU usage. This commit reimplements this:
* using a thread that is synchronized to the RU (if there is no MAC, we
assume there is no RU generating a tick so we create the tick source
ourselves)
* no RB trees but plain arrays
* smaller interface for users
* slight user interface changes
* remove stopped timer state: such timer might be simply removed
* remove one-shot timers
* only set up timer for sending requests
* simplify interface for timer setup
* on timer expiry, do not pass through stats request function but
directly send the reply
* Remove whatever report structure and use stats request directly for
inferring the data to send
* the RAN API RRC part now takes rnti and does not look it up in the MAC every
time again
* the function flexran_get_aperiodic_cqi_rep_mode() has been changed to return
a proper protobuf variable, not OAI typedef
* give the correct UE_id instead an index of the protobuf message (they can
diverge from each other)
* in the PDCP part of the RAN API, the RAN API has to make the conversion UE_id
(MAC) to UID (PDCP)
* a follow up commit could clean up the interfaces:
- the MAC functions take the UE_id
- the RRC functions take the RNTI
- the PDCP functions take the UID
this would mean the caller has to find those ID but would decrease
computations since the RAN API functions do not have to do that themselves
* properly allocate memory for scheduler name/sorting
* free mem of sc_update, include todo for slice_config
* set has_x to one, add fct whether sorting update necessary
* set n_ul/n_dl to correct value after every loop iteration
* support for delete of multiple slices
* allocate memory for scheduler name in slice_config
* check that we really set the scheduler
Incoming slice configuration changes are buffered in an intermediate structure.
The MAC scheduler periodically polls the agent about changes. If there has been
a slice configuration change, apply it.
laurent