stopping the UE in ZMQ mode caused a dead-lock because the Stack was
stopped before the PHY causing the sync queue to overflow. Since we
use a queue-length of 1 in ZMQ, mode, the PHY sync thread was blocking to
push a new sync event while the stack thread was already stopped.
this patch makes sure no new sync events are queued after the stack has
been terminated.
this patch fixes the UL BSR as per TS 36.321, it includes following
main changes:
* report UL buffer state to reflect the UEs transmit buffer after
the MAC UL PDU containing the BSR has been built.
In other words, if the UE, for example, can transmit all outstanding
data in an UL grant, it will not report any pending data to transmit.
* refactor MUX routines and subheader space calculation
* split existing BSR test into dedicated test for short, long, and trunc
BSR tests
* update MAC tests that include packing UL BSR.
(After checking TS 36.321 again it seems we have reported old UL buffer states)
simplify logic to check whether a BSR fits and, if so, which type.
before the check has been done in two places.
we now also accomodate for the CE subheader size.
we've not checked the return value when adding a new CE, like BSR or PHR,
for a UL MAC PDU. For very small UL grants, this could fail and
we need to remove the subheader again before packing the PDU.
This fixes issue #1649.
before the BSR was extracted but the actual index (between 0 and 63)
was not stored but directly converted into bytes.
for log parsing and debugging it is easier to follow the index
value. this patch therefore adds both values to the log message
and extends the API accordingly.
all calls that manipulate the RLC and/or PDCP arrays suffer
from a high deadlock risk if a PHY worker holds the RLC
AM Rx mutex at the same time when the stack wants to carry
out this reconfiguration.
this applies to RRC Reconfigs, but potentially also to RRC Connection
Reestablishment or even RRC Connection Setup, although this should
seldom be the case.
By breaking the call stack between RLC->PDCP->RRC->RCL and
carrying out the reconfig as a single task without holding the
RLC readlock the deadlock should not happen anymore.
This should fix issue #1593