that patch addreses issue #2199 by defering RA-related calls that
are executed from within PHY workers.
The time-critical bits of more complex functions such as tb_decoded()
are still executed in the PHY worker thread but the state machine
manipulation is defered.
* Refactor NR resource allocation classes. Use DCI instead of grant for dummy PDSCH UE/eNB test
* Minor refactors in NR workers and ue_dl
* Fix include issues
* fix compilation issues
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.
* 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
the current implementation was somehow broken after a
NAS refactor. It was undetected because we didn't really
use it.
this fixes the simulation by using a single timer to simulate
airplane mode transitions.
the timer is rearmed in the timer_expire() function
if the correspondig event is set.
Has been tested to work well with, e.g.:
--sim.airplane_t_on_ms 5000 --sim.airplane_t_off_ms 10000
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
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.
* 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>
* 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
the filter alpha was initialized to zero by default which causes an
issue because the first measurement for a cell can't be updated,
because the filtering function will always return the current value.
According to 36.331 Sec 5.5.3.2 Note 2, a k-value of 0 should turn
off filtering, which should be used as the default value until
an update is received from the network.
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
the PSS detection needs more temporary buffer than a full subframe.
we therefore need to allocate and initialize the sync object with
larger maximum size to support Scell search of large cells, e.g.
20 MHz
this fixes issue #1538
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
apply same change that we've done on the eNB also on the UE
to avoid the PHY processing TTIs faster than the stack.
Without that, we see lots of those in the logs:
...
08:39:17.580325 [STCK] [W] Detected slow task processing (sync_queue_len=7).
...
before entering RRC idle, after receiving a RRC connection release for example,
we need to wait until the RLC for SRB1 or SRB2 have been flushed, i.e.
the RLC has acknowledged the reception of the message.
Previously we have only waited for SRB1 but the message can also be received on SRB2
and in this case both bearers need to be checked.
The method is now streamlined to check both SRBs and is also used when
checking the msg transmission of an detach request.
David Rupprecht
Xavier Arteaga
Andre Puschmann
Ismael Gomez
Pedro Alvarez
Francisco Paisana
Sylvain Munaut
faluco
faluco
Daniel Willmann