Before this PR, the eNB was not activating UL-64QAM if the UE release was below 12,
due to an erroneous convertion of the ASN1 EUTRA Capabilities struct into the flattened
srslte::ue_capabilities_t.
With this PR, the eNB activates UL-64QAM for the following cases:
- UE category 5
- UE category 8 and release >= 10
- UE category UL 8 and release >= 12
the RLC bearer name was empty after reestablishing a UM bearer.
we need to pass the RLF config and RB name to the internal configure()
call of the Rx entity, like we already do for the Tx side
when EVM measurements are enabled, instead of only logging them for
each decoded codeword, we also calculate the average.
this is useful for calibration.
hard killing of AGC thread causes issue on some RF devices,
such as the N310. The thread still seemed to access the device while
the radio was already killed (or the streamer object deleted).
It's unclear why this isn't causing similar issues on B210 or X310,
at least not visible, but it is obviously not the correct way to stop a thread.
The patch now correctly sets the stop flag for the AGC thread, wakes it
it up and waits until it has terminated.
the Lime has better performance when using the default LTE sample
rates due to filterering being done in the LMS RF chip.
Print a warning when using the Lime with the non-default LTE rates.
the bug causes the BSR to return a bsr_idx of 0, i.e. no data
pending, when the buff_size was reported to be 1 B only.
Instead, the UE should return BSR idx 1, i.e. between 0 < BSR <= 10.
LBSR packing is fine but this makes the eNB do wrong things
because it thinkgs LCG2 has no or too much data to send.
LCG2 is our default LCG for DRB1. One occasion we saw the issue
is doing full rate TCP DL which requires quite a bit of ACK traffic
back to the sender. With the BSR for LCG2 being wrong, providing
UL grants was delayed and so the TCP DL throuhgput was very low.
In the log below we see that the buff_size[2]=1 so there is data to send.
Interestingly, the packing was correct so Wireshark displays it correctly.
But the unpacking not, as can be seen in the MAC log below which reports
0 buffer state for all LCGs
22:08:54.804792 [MAC ] [I] [ 5084] pdu_get: sdu_len=1212, channel.sched_len=1213, bsr.buff_size[2]=1
22:08:54.804840 [MAC ] [I] [ 5084] UL LCID=3 len=1212 LBSR: b=0 0 0 0
* rlc_am: add TC for pollRetx timer handling
* rlc_am: fix stopping of pollRetx timer
stopping the pollRetx timer when receiving a status PDU
without checking the acknowledged PDUs is wrong.
if an ACK for another PDU, for which the polling bit has been set,
is still pending, it won't be rescheduled until another
PDU is transmitted that again starts the pollRetx timer.
this fixes the issue with missing RLC AM segment retx in #1992,
and #2003
* mac_test: add extended TBSR unit test
unit test to MAC UL packing after sending a TBSR
this fixes the MAC issues described in issue #2002
* mux: fix updating of LCG buffer state after packing PDU
we've previously lowered the buffer state of the LCG according
to the bytes that have been scheduled, but not according to
those that have been actually included in the PDU.
* proc_bsr: fix LCG buffer state updating for TBSR
when sending a TBSR do not update the internal buffer
state of the BSR proc.
This caused issues because the buffer state for all LCG that
are not included in the TBSR are set to zero, although at least
one LCG does have data to transmit.
* rlc_am: include LCID when logging retx of SN
I noticed that the app didn't configure the process with
RT thread prio. But it then turned out that in order to do
that we need to actually spawn a new thread. Also a few other things
didn't work out of the box.
In summary the changes are:
* fix duration to support more than 120s
* move main functionality in thread
* set high priority for radio thread
* only return success if no radio errors occured
this makes sure that the reconstructed RLC AM header
has the poll bit set when any of its segments had it set.
this triggered a bug in RLC AM because the Status PDU
isn't transmitted for a RLC PDU that was segmented and
only the first segment had the P flag set.
reported/provided by user softdev86 in https://github.com/srsLTE/srsLTE/issues/566
author tested with local 4 port cell. I am not able to verify locally but
it looks ok, we'll revise later if needed.
When using srsLTE with Lime devices, calibration was performed before any configuration steps have happened, thus making calibration values invalid. Removing Lime specific calibration step from rf_soapy_imp makes so that devices will be automatically calibrated by SoapyLMS on rf_soapy_start_stream call.
Tested and working with srsENB using LimeSDR-USB v1.4 and LimeSDR-Mini v1.2 boards.