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.
some RF boards might have issues with the sharp filters that are needed
for the reduced sample rate operation that we use by default.
This switch allows to use the default LTE sampling rates and
configure this at run-time, not compile time.
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.
when packing MAC PDUs, adding a new SDU might fail, for example
because RLC couldn't provide a new PDU. The muxer then needs
to delete the subheader from the PDU again.
When adding a padding BSR at the end, the same subheader is again
used to store the BSR, so any state in that subheader should be removed.
In the particular case, this was causing an issue when logging a LBSR
because the LCG buffer states are printed using the payload buffer,
which was still pointing to some memory that was used when trying
to add the new RLC PDU in the beginning.
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
this potentially fixes the issue we see during HO and RLF
under high DL load.
The issue happens because buffered DL PDUs are delivered to
RLC after reestablishing RLC that confuse the receiving
RLC entity bc the sequence numbers are very high, as opposed
to begin with zero again after reestablishment.
* 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