the EPS bearer manager was only informed when a single DRB
was removed but not when entering idle which requires to
remove all bearers.
This cause the service request to fail.
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.
when a lost PDU is detected a warning will be logged. In theory
this could be info as well but a warning may help to detect issues
in tests. The same event causes multiple other warnings to be logged,
which is very spammy. The patch reduces the log level for
those messages to info.
the patch is a re-implementation of the customer-specific optimization
we did in order to reduce the time the RLC holds the Tx mutex when
processing an incoming status PDU.
The patch makes sure to never operate on a raw mutex but instead
uses the deadlock-avoiding RAII lock.
before processing incoming status PDUs we should be checking
if the ACK_SN falls within our current Tx window. If not the PDU
will be dropped.
Without the check we were incorrectly processing the status PDU
and because the sequence number wrap around wasn't working
correctly if ACK_SN is smaller than vt_a we were corrupting
our Tx window.
the test verifies that the ACK_SN of a status PDU falls inside the
rx_window of the receiver. If not, than the RLC state has been
corrupted and the status PDU is likely invalid.
Andre Puschmann
faluco
Xavier Arteaga
David Rupprecht
Pedro Alvarez
Francisco
Ismael Gomez
Bedran Karakoc
Alejandro Leal Conejos