Files
openairinterface5g/openair2/RRC
Guido Casati 806a15da01 Implement TS 38.473 transparency for CellGroupConfig forwarding
This commit implements transparent forwarding of CellGroupConfig
as required by TS 38.473, eliminating CU-side decode/re-encode
cycles that violate transparency requirements.

Main Design Change:
- Before: CU decoded CellGroupConfig from DU, stored in the UE
  context then re-encoded when sending to UE. CU constructed
  new CellGroupConfig after RRCReestablishmentComplete.
- After: CU requests CellGroupConfig from DU via UE Context Modification
  Request with `gNB_DU_Configuration_Query=true`, DU sends CellGroupConfig
  which CU stores as encoded `byte_array_t` and forwards transparently
  via reconfiguration without decode/re-encode cycles

To this purpose, all decode operations of CellGroupConfig were removed
from DU and all encode operations were removed from the CU.

Key Changes:

CU:
- Replace NR_CellGroupConfig_t* masterCellGroup with byte_array_t mcg in
  gNB_RRC_UE_t for storing encoded CellGroupConfig
- Rename cell_group_config to cgc in nr_rrc_reconfig_param_t for brevity
- Implement transparent forwarding in build_RRCReconfiguration_IEs()
- Add helper functions:
  - `store_cgc()` to store encoded bytes
  - `get_meas_gap_config()`: Decode MeasGapConfig from DU to CU response
  - `rrc_detect_reestablishment()` to detect re-establishment by decoding
    temporarily (only for detection)
- Remove legacy decode/re-encode paths in RRC message generation
- Update all CellGroupConfig storage to use encoded bytes
- Update reconfiguration generation to accept is_reestablishment parameter

DU:
- Add `get_cellgroup_config()` to select source (CellGroup vs reconfigCellGroup)
  based on re-establishment state
- Add re-establishment detection logic in `ue_context_modification_request()`
- Add `update_cellgroup_for_reestablishment()` to set reestablishRLC flags and
  remove SRB1 from bearer list
- When `gNB_DU_Configuration_Query` is present and re-establishment detected:
  - Clones from reconfigCellGroup (which contains spCellConfig) instead of
    CellGroup (where spCellConfig was removed)
  - Sets `reestablishRLC` flags for all bearers except SRB1
  - Removes SRB1 from bearer list (already re-established)

Data Structure Changes:
- gNB_RRC_UE_t: Add byte_array_t mcg field
- nr_rrc_reconfig_param_t: Change cell_group_config to cgc (byte_array_t*)
- Remove masterCellGroup field usage in favor of encoded mcg

New re-establishment flow:
1. UE sends RRCReestablishmentRequest
2. CU processes -> sends RRCReestablishment
3. CU sends RRCReestablishmentComplete
4. CU sends UE Context Modification Request to DU with `gNB_DU_Configuration_Query=true`
5. DU detects re-establishment (`UE->reestablish_rlc && UE->reconfigCellGroup != NULL`):
   - Clones `UE->reconfigCellGroup` -> `new_CellGroup` (contains spCellConfig)
   - Sets `reestablishRLC` flags for all bearers except SRB1
   - Removes SRB1 from bearer list (already re-established)
   - Encodes `new_CellGroup` and sends to CU
6. CU receives encoded CellGroupConfig -> stores in `UE->mcg` via `store_cgc()`
7. CU detects re-establishment via `rrc_detect_reestablishment()`
8. CU calls `rrc_gNB_generate_dedicatedRRCReconfiguration()` with `is_reestablishment=true`:
   - Creates SRB/DRB lists with re-establishment flags
   - Generates RRC Reconfiguration with transparent CellGroupConfig
   - Sends to UE

Why spCellConfig must be added in the DU in case of re-establishment:

With transparent forwarding, CU requests CellGroupConfig from DU instead
of constructing it. During re-establishment, DU's runtime CellGroup has
spCellConfig = NULL (removed per TS 38.331 §5.3.7.2). However, for the
gNB_DU_Configuration_Query response, DU must provide a complete CellGroupConfig
including spCellConfig. Therefore, DU restores spCellConfig by encoding
reconfigCellGroup (with the original spCellConfig) in CellGroupConfig.
In the old design CU constructed CellGroupConfig itself in
`rrc_gNB_process_RRCReestablishmentComplete()` and used `spCellConfig`
from its stored `masterCellGroup`.

Closes #837
2026-01-29 10:17:42 +01:00
..
2025-10-08 18:21:10 +02:00
2023-01-19 14:52:39 +01:00