fix for #1934
This fixes a race condition between Stack thread and DL
PDU processing that lead to updates of the RLC buffer that
are undetected by the BSR routine.
What happens is that in a UL SCH PDU all outstanding data is transmitted
and and a LBSR with all zero buffers is sent.
14:39:47.327301 [MAC ] [D] [ 3793] BSR: LCID=3 old_buffer=59
14:39:47.330600 [MAC ] [I] [ 3793] UL LCID=3 len=58 LBSR: b=0 0 0 0
Note that "old_buffer" isn't set to zero here.
At the same time (same TTI), the MAC PDU processing thread handles DL-SCH PDUs
that may generate new UL PDUs:
14:39:47.330749 [RLC ] [I] DRB1 Tx SDU (54 B, tx_sdu_queue_len=1)
14:39:47.330762 [RLC ] [I] DRB1 Tx SDU (54 B, tx_sdu_queue_len=2)
14:39:47.330775 [RLC ] [I] DRB1 Tx SDU (54 B, tx_sdu_queue_len=3)
..
Those PDUs are "new data" since the previous buffer state was zero.
Here is the race now between the threads, at the end of the bsr::step() function
old_buffer of each LCG is updated with the previous new_buffer, so
the buffer state of LCG=2 is now 59.
Now MAC starts the next TTI:
14:39:47.331910 [MAC ] [D] [ 3794] Running MAC tti=3794
14:39:47.331928 [MAC ] [D] [ 3794] Update Bj: lcid=0, Bj=0
14:39:47.331934 [MAC ] [D] [ 3794] Update Bj: lcid=1, Bj=0
14:39:47.331938 [MAC ] [D] [ 3794] Update Bj: lcid=2, Bj=0
14:39:47.331941 [MAC ] [D] [ 3794] Update Bj: lcid=3, Bj=-1752
14:39:47.331951 [MAC ] [D] [ 3794] BSR: LCID=0 update new buffer=0
14:39:47.331960 [MAC ] [D] [ 3794] BSR: LCID=1 update new buffer=0
14:39:47.331964 [MAC ] [D] [ 3794] BSR: LCID=2 update new buffer=0
14:39:47.331971 [MAC ] [D] [ 3794] BSR: LCID=3 update new buffer=335
14:39:47.331976 [MAC ] [D] [ 3794] BSR: check_new_data() -> get_buffer_state_lcg(0)=0
14:39:47.331980 [MAC ] [D] [ 3794] BSR: check_new_data() -> get_buffer_state_lcg(1)=0
14:39:47.331984 [MAC ] [D] [ 3794] BSR: check_new_data() -> get_buffer_state_lcg(2)=59
14:39:47.331988 [MAC ] [D] [ 3794] BSR: check_new_data() -> get_buffer_state_lcg(3)=0
14:39:47.331993 [MAC ] [D] [ 3794] BSR: LCID=0 old_buffer=0
14:39:47.332000 [MAC ] [D] [ 3794] BSR: LCID=1 old_buffer=0
14:39:47.332003 [MAC ] [D] [ 3794] BSR: LCID=2 old_buffer=0
14:39:47.332007 [MAC ] [D] [ 3794] BSR: LCID=3 old_buffer=335
And since the buffer state of LCG=2 isn't zero, the new data for LCID=3 of that LCG is considered.
So effectivly, the BSR missed the "empty" buffer state for a fraction of time and doesn't
consider the outgoing data generated in the same TTI as new. It therefore
doesn't transmit a BSR.
in which a BSR wasn't
this was a very noisy log that was printed in pretty much
every TTI because the BSR procedure starts a SR whenever
it needs to send a regular BSR. The SR is canceled when a UL
grant arrives but the log line stays there.
Since we are printing a log when we actually signal a SR
to the PHY, this line is not needed.
this fixes the trigger logic for periodic BSRs. Previously we
would always trigger the "new data for highest priority LCID"
whenever new data becomes available for a LCID for which
a BSR has already been sent.
However, a BSR should only be sent if the priority is in fact higher
(lower int number).
in ZMQ runs we've seen that entering idle could take quite
a bit of time depending how quickly workers get their samples
sent or reconfigurations done.
In one example up to ~160ms
this patch increases the maximum wait time to 2s.
the BSR trigger wasn't reset after includinga regular or periodic
BSR inside a PDU. This caused the muxing to include another BSR in the
next UL grant. For very small grants, for example with 6 PRBs, this
causes the UE to send way too many BSRs.
when releasing PUCCH/SRS (see 5.3.13 in 36.331) we need to reset the SR config as well.
In our case, SR is handled by MAC so we need to (re-)configure MAC, not all of
MAC though, just SR.
this avoid logging a warning on UE shutdown if the MAC is already reset
but one of the PHY workers still decodes an UL grant for the old RTNI
21:30:29.254844 [RRC ] [I] Going RRC_IDLE
21:30:29.254848 [RRC ] [I] Proc "Go Idle" - Left connected state
21:30:29.259499 [PHY0] [I] [ 3865] Finished setting new PHY configuration cc_idx=0
21:30:29.259512 [PHY0] [I] [ 3865] Setting new PHY configuration cc_idx=0...
21:30:29.264190 [PHY0] [I] [ 3867] Finished setting new PHY configuration cc_idx=0
21:30:29.275036 [PHY1] [I] [ 3872] PHICH: hi=1, corr=1.0, I_lowest=1, n_dmrs=0, I_phich=0
21:30:29.275050 [MAC ] [W] [ 3872] Received grant for unknown rnti=0x46
this fixes issue #1846 that appears to be related
to the enter/exit state for measurements that is kept
even after a cell disappears from the neighbor list
this fixes#1791 which was caused by a race between
the PHY workers preparing a new UL-SCH PDU and the Stack resetting
the MAC, which in turn resets the HARQ processeses, which cleared
the buffer and set the length to zero.
Not explicitly clearing the buffer on a HARQ reset seems to be
fine since the PHY worker clears the buffer before starting to
pack a new PDU anyway.
* Fix deadlock caused by update_measurements calling in_sync
* Fix overlapping SRS condition
* Do not use shortened PUSCH in transmissions and retx from RAR
* Revert "Fix deadlock caused by update_measurements calling in_sync"
This reverts commit f58c8c8c766f8f95baa3a3bf8287d8e25b2057ba.
* Take into account CRS from neigbhour cells when measuring interference
* fix std::isnormal compilation
* Fixed compilation of test
* Address comments
* Remove unused overrides
* Make PHY non-blocking and fefactor HO procedure
* makes entire PHY non-blocking through command interface
* adds dedicated queue for cell_search/cell_select commands
* refactor HO procedure to run faster, in one stack cycle. Looks closer to the specs
* force ue to always apply SIB2 configuration during reestablishment
* Run update_measurements in all workers
Co-authored-by: Ismael Gomez <ismagom@gmail.com>
this was preventing that the Temp-CRNTI used in the RAR to be identical
to the currently configured C-RNTI of the UE.
The issue simply was that the RACH procedure was declared successful too
early, even before the Msg3 UL grant was filled with the Msg3 content.
The patch moves the logic that detects the successful completion of
the RACH procedure below the Msg3 packing.
* Removed magic numbers.
* Reduced indentation of statements with early exists.
* Removed elses after a return statement.
* Trimmed unnecessary include files.
* Default initialized members in the class.
we fix a number of very related issues for HO/reestablishment
in the success/error case:
* this patch removes the hard-coded check that intra-cell HO aren't
allowed. There are cases where eNBs use this method to update
the security context.
* the patch also fixes an issue after failed HO where the security context
of the source eNB should be used for the reestablishment.
* update security keys according to specs when mobilitycontrol
indicated change of key
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
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.
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
- Import the srslog project into srslte.
- Ported srsue app to use the new logging framework.
- Implemented a wrapper that dispatches log entries to srslog.
- Renamed an existing log test to be more specific to avoid name clashes.
* add locked and unlocked version of has_data() since one is
called from stack and one from PHY threads
* add comments in each interface section as to why locking
is required or not
* remove RLC rwlock when not required
* move calls only used by RRC to RRC section
this patch refactors the SDU queuing and dropping policy of the RLC and PDCP layer.
the previous design had issues when packets have been generated at a higher
rate above the PDCP than they could be consumed below the RLC.
When the RLC SDU queues were full, we allowed two policies, one to block on the write
and the other to drop the SDU. Both options are not ideal because they either
lead to a blocking stack thread or to lost PDCP PDUs.
To avoid this, this patch makes the following changes:
* PDCP monitors RLC's SDU queue and drops packets on its north-bound SAP if queues are full
* a new method sdu_queue_is_full() has been added to the RLC interface for PDCP
* remove blocking write from pdcp and rlc write_sdu() interface
* all writes into queues need to be non-blocking
* if Tx queues are overflowing, SDUs are dropped above PDCP, not RLC
* log warning if RLC still needs to drop SDUs
* this case should be avoided with the monitoring mechanism
Xavier Arteaga
Andre Puschmann
Francisco Paisana
Pedro Alvarez
Ismael Gomez
faluco
Sylvain Munaut
faluco