This commit fixes as bug causing a crash of the eNB in case
of many pending RETX and the reception of a trimmed PDU.
The following sequence leads to a crash:
- RETX queue contains many PDUs for RETX
- Receive trimmed PDU containing a trimmed subset of NACKs
- RETX queue is cleared and re-populated with a trimmed subset
- After all RETX (/!\ trimmed subset) is done, continue TX new PDUs
- tx_window blows up
- tx_window overflows if another status PDU is not received in time
- Overflow overwrites oldest element in tx_window
- Handling of next status PDU fails due to missing elements in tx_window
Related PR #4029
This class is based on a template that receives as argument the
rlc_am_*_tx/rx entities, so that those are different for LTE and NR.
Moved code from rlc_am_lte/nr entities so that they use the new base class.
under some circumstances it could happen that the RLC is configured
when SDUs are already being written to the queue. The resize
operation of the underlying container would fail in this case.
Make sure to empty the queue before doing the resize.
this patch fixes a bug discovered in a real network where the DL CQI of a
user degraded repidly in very short time. A relativly big RLC PDU that
was still sent with the good CQI in a big grant now needs to be split
across many tiny segments because the CQI degraded so much.
The retx couting for each transmitted segment caused the retx counter to
reach maxRetx quickly.
With this patch we do not increment the retx counter for each transmitted
PDU or segment of a PDU but instead only increment the counter when
a given SN is added to the retx queue. This can happen either:
a) if the SN is negativly acknowledged and was not already on the retx queue,
b) no new data is available for tx and a SN is selected for retx.
This is in accordance with TS 36.322 which handles retx counting in section
5.2.1 according to the above description.
the do_status is queried from the Tx code frequently. To reduce
chances to delay the execution because the RLC Rx side is currently
holding the mutex we can use an atomic.
the patch uses try-lock whenever a status PDU is tried
to be built. This makes sure that when the lock is currently
hold (e.g. by a thread processing rx PDUs) the generation
of the status PDUs is not taking too long and blocking the calling
thread. Instead the status PDU generation is deferred to the next
Tx opportunity.
It's a probabilistic approach that assumes that at some stage the
lock can in fact be acquired.