The PROTO_AGENT variable holding the channel for various was named as the same
one for FlexRAN. In C, global variables with the same name are merged into one,
which had the effect that the same queues where used for PROTO_AGENT and
FlexRAN, locking the FlexRAN RX thread. Renaming the PROTO_AGENT variable (it
was introduced second) resolves this issue.
This commit cleans up the link_manager interface:
* don't provide peer_addr/port in create_link_manager() (for TCP/SCTP it is not
needed, so in the UDP case in needs to be set explicitly)
* Make FlexRAN connect again (correct hardcoded address)
* Fix FlexRAN: retain the manager pointer
* Fix FlexRAN: store receive_queue pointer
* the link_manager's sender thread passes the correct peer_addr/port for the
UDP case
* 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
The functions of the RAN API should not return the types of OAI, but protobuf
types. Previously, they would return OAI types and the calling code "marshals"
this into Protobuf type. This commit changes the following functions and
modifies the calling code to directly store the protobuf type:
* flexran_get_hopping_mode()
* flexran_get_phich_resource()
* flexran_get_phich_duration()
* flexran_get_ul_cyclic_prefix_length()
* flexran_get_dl_cyclic_prefix_length()
* flexran_get_duplex_mode() usage
* flexran_get_enable64QAM()
* Hello msg agent->RTC carries ID and capabilities this agent supports
* RAN API provides ID and capabilities:
- flexran_get_bs_id()
- flexran_get_capabilities() // protobuf list of capabilities
- flexran_get_capabilities() // capabilities as bit mask
Add FlexRAN capabilities mask RAN API function
Robert Schmidt