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?
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.
nr_mac_prepare_ra_ue() is called with the scheduler being locked via
NR_SCHED_ENSURE_LOCKED(), but if there is no free RA process, it
unlocks the scheduler via NR_SCHED_UNLOCK(). This is commit fixes this.
In short, when calling nr_mac_prepare_ra_ue(), the scheduler is locked,
and should always return with the scheduler being locked.
francescomani