- Add GOL-delay and AVG-soujour
- Correct the types of/measurement the tx/rxsdu_bytes and tx/rxsdu_occ_bytes
- Update txsdu_avg_time_to_tx value only when measurements activated
Co-authored-by: Teodora Vladic <teodora.vladic@openairinterface.org>
This time constant plays a major role in how long a UE has to wait
maximally before it might be scheduled. For instance, if a UE had a lot
of traffic, the average traffic will be high, pushing the PF coefficient
down. If another UE with no traffic in the past becomes active with
heavy traffic, the first UE might not be scheduled for an extended
period of time.
In the AW2S-Amarisoft UE CI test pipeline, we sometimes see that the
maximum number of RLC retransmissions was reached. While this might not
be the (only) cause, scheduling a UE more often might prevent such
situations, and we saw an improved stability.
When t_poll_retransmit expires we need to consider an SDU for
retransmission.
We used to take the first SDU (which could be a segment, not a full SDU)
of the wait list and put it in the retransmit list.
When testing with some UE (Amarisoft UE) a bad behavior was detected.
This is what happens for the SDU with SN 6 (for illustration purpose).
The gNB is sending an SDU in several pieces (it is segmented).
slot n: rlc sn 6 [1 .. 119[ p=0 RECEIVED
slot n+x: rlc sn 6 ]120 .. 180[ p=0 RECEIVED
slot n+x+y: rlc sn 6 ]181 .. 210] p=1 not RECEIVED
Then when t_poll_retransmit expires rlc retransmits only the PDU of
slot n (with p=1 this time) and the UE replies with ack 6. So nothing
happens on the gnb side.
(We would have expected ack 7 + nack 6 181..end.)
Then after t_poll_retransmit expires again rlc retransmits only PDU
of slot n and the UE still replies with ack 6.
This goes on forever (or some other timeout occurs.)
The logic is now changed.
When t_poll_retransmit expires we transfer all the SDUs in the wait list
having the same SN as the head of the wait list into the retransmit list.
Testing with Amarisoft UE, it seems to work properly.
This commit repairs the reestablishment after the introduction of the CU
UE ID in the CU, different from the DU UE ID. Now, the CU uses an
identifier different from the RNTI, used in the MAC, to refer to UEs.
To repair the reestablishment, a number of changes needed to be
introduced:
- Handle old_gNB_DU_UE_id in MAC
The MAC handles the old_gNB_DU_UE_id field in the DL RRC Message. The
commit adds encoding/decoding of the field. The MAC will drop the old
UE, but retain the CellGroup of the corresponding UE(!). Because a UE
releases the spCellGroup on reestablishment, the MAC does the same; it
needs to reapply the old configuration after a reconfiguration. For the
latter, introduce new variables to keep a "future" CellGroupConfig to be
applied (reconfigCellGroup) and a flag (expect_reconfiguration) that
applies the CellGroupConfig if a DL RRC Message transfer on DCCH, which
is assumed to be the reconfiguration.
- Add RNTI change in RLC
The RLC needs to reuse the old UE context. Hence, we simply change the
RNTI in the old context, and delete the new one.
- No PDCP UE ID change
The previous implementation of the PDCP used the RNTI; hence, the ID
needed to be switch (as above for the RLC). Since the PDCP now also uses
the CU UE ID, no identifier change is needed, and we remove all
corresponding code.
- No MAC modifications/update from CU
As foreseen by the spec, the CU does not modify or change the
cellGroupConfig in the RRC during reestablishment. This change will be
generalized in the future to all of the RRC. Also, the
nr_rrc_mac_remove_ue() function has been removed: the MAC handles any UE
changes autonomeously, without being triggered from the RRC explicitly.
- Remove reestablish_rnti_map
The RRC does not use RNTIs for UE identification. Hence, a
reestablish_rnti_map to link two UEs to each other is not necessary
anymore.
After a reestablishment, the PDCP sequence number counters have to be
reset. Implement an API to allow the RRC to reset the sequence numbers
for a particular UE in the case of reestablishment
- The CU/DU UE ID is used in DL RRC Message Transfer
- Note: The CU UE ID currently is still the RNTI
- on every DL RRC Message, the DU verifies that the UE exists
- Refactor RRC: common function to forward protected SRB PDUs
for reusing the old UE Context after reestablishment: we have to free a
UE context, but that also free's the RA process that we still need.
Remove here
Is this necessary?
In case of noS1-mode, we initialize the 'logicalChannelBearer_exist' array element for the pre-configured DRB0 in function 'nr_l2_init_ue()'.
That array is indexed with the LCID.
For DRB0, the LCID is 4.
Unfortunately, the code incorrectly used the array at index 0.
Therefore, the UE sent neither scheduling requests nor buffer status reports, what resulted in extremely poor UL throughput.
The RLC tests were not compiling because of the include of
openair2/RRC/NR/rrc_gNB_radio_bearers.h
by
openair2/LAYER2/nr_rlc/nr_rlc_entity.h
which does not seem correct/necessary to start with.
The only thing needed by nr_rlc_entity.h from rrc_gNB_radio_bearers.h
is MAX_DRBS_PER_UE which can be defined in common/platform_constants.h
like NGAP_MAX_PDU_SESSION.
