Implement TS 38.473 transparency for CellGroupConfig forwarding and handle re-establishment on a different DU

This MR implements the following fixes that are relevant in RRC procedures (e.g. re-establishment, reconfiguration):

1. Transparent CellGroupConfig forwarding

This MR implements TS 38.473 transparency requirements by ensuring that the CellGroupConfig IE is transparently forwarded from the gNB-DU to the UE without any re-encoding at the gNB-CU. The CU stores and forwards the encoded bytes transparently, while the DU is responsible for all encoding and modifications (e.g., reestablishRLC flags).

Motivation

The 3GPP TS 38.473 specification mandates that the CellGroupConfig IE shall be transparently signaled to the UE. Previously, the CU was re-encoding CellGroupConfig depending on the scenario, instead of retrieving it from the DU, violating the transparency requirement. CU may decode for internal use but must not re-encode for forwarding.

Solution

Core Principle: The CU stores the encoded CellGroupConfig bytes received from the DU and forwards them directly to the UE without any re-encoding. The DU handles all encoding and modifications.

Key Changes:

1. Transparent Forwarding in RRC Reconfiguration
   • Modified build_RRCReconfiguration_IEs() to use pre-encoded bytes directly
   • Changed parameter from cell_group_config to cgc (encoded byte array with buffer and size)
2. Encoded Bytes Storage
   • Added byte_array_t mcg field to RRC UE structure to store encoded CellGroupConfig
   • Added store_cgc() helper function to save encoded cell group in the RRC UE Context at gNB (from F1AP messages)
3. DU Encoding Responsibilities
   • Add gNB-DU Configuration Query IE support to trigger cgc encoding to request CellGroupConfig from DU
   • DU encodes CellGroupConfig with proper reestablishRLC flags during re-establishment
   • DU removes SRB1 from rlc-BearerToAddModList during re-establishment (SRB1 re-establishment is done before RRCReconfiguration)
4. New functions
   • Add rrc_detect_reestablishment() function to detect re-establishment during UE Context Modification
   • Extracted rrc_gNB_first_reconfiguration_after_reestablishment() function to handle first reconfiguration after re-establishment
   • Added dump_cgc() and dump_mcg() utility functions for debugging purposes
5. Re-establishment Flow
   • rrc_gNB_process_RRCReestablishmentComplete() requests CellGroupConfig from DU via gNB_DU_Configuration_Query in UE Context Modification Request
   • DU detects re-establishment and add reestablishRLC IEs
   • CU stores encoded CGC from the UE Context Modification Response and forwards it transparently in subsequent RRC Reconfiguration

Testing

Manual Testing:

• RRC re-establishment procedure completes successfully
• RRC Reconfiguration after re-establishment includes all DU-provided information

Issues fixed

Closes issue #837

2. Trigger UE Context Setup fallback upon reestablishment on DU different from the original one

As per 38.401 §8.7: if the UE accesses a DU different from the original one during re-establishment, the CU must trigger UE Context Setup toward the new DU. This refers to steps 9-10 and steps 9’-10’. Either one or the other can be executed during re-establishment.

e.g. if this happens during handover, it shall trigger a UE Context Setup fallback on the CU.

This MR implements the required behavior by:

• Adding a new helper function rrc_handle_f1_ho_reestab_on_target() to handle F1 handover reestablishment on target DU. The function triggers UE Context Setup procedure when the UE reestablishes on the target DU during an ongoing F1 handover.
• Calling this function when detecting that the UE is reestablishing on the target DU during handover, i.e.: (1) from handle_rrcReestablishmentComplete(), as per 38.401 §8.7, NOTE on steps 9-10: CU gets UL RRC MESSAGE TRANSFER from a DU different than the original (2) from rrc_CU_process_ue_modification_required, as per 38.401 §8.7, NOTE on steps 9'-10': CU gets a UE CONTEXT MODIFICATION REQUIRED from a DU different from the original one.

Also:

• add helper rrc_fill_f1_ue_context_setup and adopt it in handover
• move DRB list filler fill_drb_to_be_setup into rrc_gNB.c and rename it rrc_fill_f1_drb_to_setup for consistency

3. DU: Handle missing old UE context in DL RRC Message Transfer

During F1 handover reestablishment, the CU may forward a DL RRC Message Transfer to the target DU with old_gNB_DU_ue_id included, even though the target DU does not have the old UE context yet.

The code previously used AssertFatal when the old UE context was not found, causing a crash: "CU claims we should know UE %04x, but we don't"

According to TS 38.473, the gNB-DU shall release the old gNB-DU UE F1AP ID only:

if the gNB-DU identifies the UE-associated logical F1-connection If there is no matching connection, there is nothing to release.

Fix:

• Check if old UE context exists before accessing it
• If old UE does not exist, log error, clean up any stale F1 UE data, and return early (do not deliver RRC message since reestablishment can't be completed)

The goal is to address a recurrent issue in the F1 pipeline, see jenkins-oai.eurecom.fr/job/RAN-SA-Handover-CN5G/514:

Assertion (oldUE) failed!
In dl_rrc_message_transfer() /oai-ran/openair2/LAYER2/NR_MAC_gNB/mac_rrc_dl_handler.c:956
CU claims we should know UE 35ce, but we don't

TODO :

• nr_rrc_reconfiguration_req: BWP reconfiguration transparency ? (currently setting BWP IEs at CU)
• Reproduce re-establishment on a different DU and validate fallback