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
Not much has been changed in the driver (that used libbladerf 1.0).
Some bugs have been fixed. Documentation has been added. A configuration
file has been added too, put in the directory ./configuration/bladeRF.
To use a bladeRF device, see documentation in targets/ARCH/BLADERF/README.
Only the BladeRF x40 has been tested.
Performance is not too bad at 5MHz, a bit worse at 10MHz and on the test
machine I used I face realtime problems at 20MHz when I push downlink
throughput.
So, there is still some work to do to have a good support of bladeRF.
-- in slave job, the lock is now properly done for the whole job
-- in master job, all slave jobs are really sent in parallel
they should now now appear as failed (if fails)
Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>
Robert Schmidt