inspired by accepted (but not yet merged) PR to include the
(unique_)byte_buffer_t for MAC/PHY interfacing, this patch adds
a few more useful bits to that. Buffer management for UL data is now
done in MAC and only a pointer to the data is passed in the UL action.
* Move Tx softbuffer to MAC (until UL HARQ class is ready)
* Remove temparal data member in cc_worker
* Remove memcpy after packing MAC PDU
this resolves issue #2277 in which a warning was logged when
the CC worker decoded a 2nd phantom PDDCH.
It's difficult to avoid this 2nd PDDCH without addional computation
that we don't want add at this stage.
Rather than filtering out the Warning in the log post-processing,
we reduce the log level to info.
after adding the thread-safe PCAP writer functionality to the EUTRA
MAC object it became clear that we don't wont to replicate the
same for the NR object.
This patch therefore refactors the class that now supports both EUTRA and
NR rats. The old mac_nr_pcap.[h/cc] has been deleted. All test-cases
and usages now use the new object that needs to pass the RAT type in
the ctor.
this patch addresses the last open point of #2160
this causes a debug log line as the first message in every ue.log because
the loggers/loglevels aren't configured yet.
22:10:02.463396 [MAC ] [D] [ 0] Msg3 buffer flushed
the msg3_flush isn't needed because all variables are initialized.
this patch fixes an issue with TC_9_3_1_17 after the "send attach in RRC connected" issue
has been fixed. The TC failed because the UE would always attempt to re-attach, even
after receiving an explicit detach request WITHOUT re-attach from the network.
According to TS 24.301 Sec. 5.5.2.3.2 the handling of that message largely depends
on the detach cause sent by network. Since we don't currently parse and handle
that the simplest solution here is to just enter deregistered:::null.
The patch is also part of the fix for issue #2237
this is an attempt to fix issue #2237 that cause the UE to fail to
attach because the attach request wasn't resent after T3410+T3411
expired.
this was only because RRC wasn't idle at that stage and the attach
request generation was aborted.
The patch fixes this by passing the NAS PDU directly to RRC in
connected state.
The patch also converts the blocking PDU alloc to a non-blocking one.
* Replaced UE logger in the ue class.
* Replaced loggers in the main phy class and prach.
* Replaced loggers in phy common and ta_control.
* Replace loggers in cc and sf workers.
* Replaced loggers in intra_measure, scell_recv, search, sfn_sync, sync.
* Remove last uses of the old loggers in the main phy class.
* Remove stray newline in logs.
* Replaced loggers in ue gw.
* - Started to replace loggers in the ue stack.
- Replaced loggers in usim and pcsc.
- Adapted nas and usim tests.
* Replace loggers in nas.
* Added missing log init calls in two previously modified tests.
* Replaced logger in nas idle procs.
* Replaced loggers in nas emm state.
* Replaced loggers in tft packet filter and adapted tft test.
* Replaced loggers in main RRC class.
* Replaced loggers in RRC cell.
* Replaced loggers in RRC meas.
* Replaced loggers in rrc procedures.
* Started logger replacement in MAC layer, more precisely in demux and dl_harq classes.
Been unable to inject loggers in construction for dl_tb_process due to very weird static assertions in the std::vector code being the type not constructible which is not true, so instead use the main MAC logger directly.
* Replaced loggers in mac mux class.
* Replaced loggers in mac pro_bsr.
* Replaced loggers in mac proc phr.
* Replaced loggers in mac proc SR and RA.
* Replace loggers in mac UL HARQ.
* Replaced loggers in main ue stack class.
* Fixed nas test crashing due to a null string.
* Ported mac_test to use the new loggers.
* Removed TTI reporting for the PHY log as the old logger did.
* Replaced loggers in UE phy tests.
* Configure loggers in nas_test.
* Replaced loggers in rrc_meas_test.
* Replaced loggers in rrc_reconfig_test.
* Added missing newline in tft_test.
* Fix compilation errors in TTCN3 tests.
* Fix linker error detected in CI and warning.
* Replaced loggers in TTCN3 tests.
* Fix a text replace error in some log messages.
* Remove trailing newlines from log entries.
* Remove old logger from rrc.
* Flush backend before printing the test status.
* - Fix compilation error from previous rebase.
- Remove trailing newlines from some missing log entries.
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
during MAC reset, scells are reset to and their PCI is set to UINT32_MAX
which results in malformatted stdout prints, see below:
Random Access Transmission: seq=16, ra-rnti=0x2
Random Access Transmission: seq=14, ra-rnti=0x2
0 4 -24 24 -1.1u 1.0 140 0.50 0.0 0% 0.0 0.0 0.0 0.0 67%
14294967295 0.0 0.0 -1.1u 0.0 0.0 0.0 0.0 0% 0.0 0.0 0.0 0.0 0%
24294967295 0.0 0.0 -1.1u 0.0 0.0 0.0 0.0 0% 0.0 0.0 0.0 0.0 0%
34294967295 0.0 0.0 -1.1u 0.0 0.0 0.0 0.0 0% 0.0 0.0 0.0 0.0 0%
this patch checks the configured PCI value against UINT32_MAX and
prints "n/a" in case the scells aren't set yet.
when retrieving the RLC metrics, the number of TTIs since the last
call are passed. This allows to calculate the actual rate
based on the LTE timing rather than only the system timing.
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.
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
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).
the BSR routine had a bug in which it would generate a BSR even
before the reTx timer expires if new data becomes availble
for a LCID that already had data and a BSR was already sent.
The RA test here relies on a BSR in the generated MAC PDU to pass.
However, since after fixing the BSR bug the PDU the MUX unit
no longer generates a BSR, we need generate data for a LCID
which has higher priority than the one for which a BSR has
already been sent.
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.
this test varifies the correct operation of the retxBSR timer.
the first PDU includes a long BSR to indicate more LCGs have
data to transmit. The retxBSR timer is started and subsequent
PDUs should not send a regular BSR.
After the retxBSR timer expires, a UL PDU should again include
a BSR.
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.
The “IPv4 local address type” filter should be 9 bytes since it includes
not only the ip address, but also its subnet mask.
Quoting from 3GPP TS 24.008 10.5.6.12:
"""
For "IPv4 remote address type", the packet filter component value field
shall be encoded as a sequence of a four octet IPv4 address field and a
four octet IPv4 address mask field. The IPv4 address field shall be
transmitted first. For "IPv4 local address type", the packet filter
component value field shall be encoded as defined for "IPv4 remote
address type".
"""
Same for the ToS which also includes a 1 byte mask value