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.
With soapy 0.8.0, GCC 11.1.0 warns of mismatched array bounds
in some functions.
This commit aligns the bound and adds proper wrappers to
fix subsequent warnings.
the code hasn't been maintained for a while an likely needs to be
adapted for a real-world scenarios.
in order to avoid having to maintain two MAC/PHY interfaces we
remove the code from now.
move implementation to cc file to avoid
[build] /bin/ld: CMakeFiles/rrc_nr_asn1_test.dir/rrc_nr_test.cc.o: in function `asn1::rrc_nr::setup_release_c<asn1::rrc_nr::pdcch_serving_cell_cfg_s>::set_setup()':
[build] /home/anpu/src/srsLTE/lib/include/srsran/asn1/rrc_nr.h:2276: undefined reference to `asn1::rrc_nr::setup_release_c<asn1::rrc_nr::pdcch_serving_cell_cfg_s>::set(asn1::rrc_nr::setup_release_c<asn1::rrc_nr::pdcch_serving_cell_cfg_s>::types_opts::options)'
[build] clang: error: linker command failed with exit code 1 (use -v to see invocation)
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.
on highly loaded systems it can happen that the get_metrics() is called
twice within a few houndred milliseconds. Logging a warning in this
case isn't needed, so reduce to info.
on the other hand, 100ms might be to convervative. Patch also
lowers the smallest interval to 10ms
* Protect PHY SR signal management in a class
* Protect intra_freq_meas vector
* Protect cell and srate shared variables in thread-safe classes
* srsue,srsenb: include TSAN options header
* Protect ue_rnti_t and rnti scheduling windows behind thread-safe classes
* Protect access to state variable in sync_state
* Protect access to metrics configuration
* Protect access to is_pending_sr
* Protect access to UE prach worker
* Protect UE mux
* Avoid unlocking mutex twice
* Fix data races in RF/ZMQ
* Fix data races in intra_measure and PHY
* Fix minor data races in MAC
* Make TSAN default behaviour to not halt on error
* Fix blocking in intra cell measurement
* Address comments
Co-authored-by: Andre Puschmann <andre@softwareradiosystems.com>
Introduce a new macro to catch UHD exceptions and log them directly instead of storing an error string, similar to what errno does.
Remove usrp logging helpers that depend on the now removed member since all calls potentially log the error directly.
RFCI has detected this assert failing in the log_backend_test. I have not been able to reproduce this locally but my theory is the following one:
one of the unit tests does the following:
backend.start();
backend.stop();
the internal running_flag member could be set to true and then to false by the main thread before the worker thread calls do_work(). If this happens
the assert will be triggered, which is wrong and too conservative, so remove the assert.
this is a rather large commit that is hard to split because
it touches quite a few components.
It's a preparation patch for adding NR split bearers in the next
step.
We realized that managing RLC and PDCP bearers for both NR and LTE
in the same entity doesn't work. This is because we use the LCID
as a key for all accesses. With NR dual connectivity however we
can have the same LCID active at the same time for both LTE and NR
carriers.
The patch solves that by creating a dedicated NR instance for RLC/PDCP
in the stack. But then the question arises for UL traffic on, e.g. LCID 4
what PDCP instance the GW should use for pushing SDUs. It doesnt' know
that. And in fact it doesn't need to. It just needs to know EPS
bearer IDs. So the next change was to remove the knowledge of what
LCIDs are from the GW. Make is agnostic and only work on EPS bearer IDs.
The handling and mapping between EPS bearer IDs and LCIDs for LTE
or NR (mainly PDCP for pushing data) is done in the Stack because
it has access to both.
The NAS also has a EPS bearer map but only knows about default and
dedicated bearers. It doesn't know on which logical channels they
are transmitted.
this patch mainly modernizes the bearer creation to use smart pointers.
that allows to simplify the error handling.
ue_stack is changed to match new interface. This commit compiles
but doesn't work.