Commit Graph
4559 Commits
Author SHA1 Message Date
Guido Casati f247a6cc2e fix(RRC): add PCell to serving_cells in fallback path and refactor update logic
Fix assertion failure in rrc_gNB_send_NGAP_NAS_FIRST_REQ() when RRC
Reestablishment falls back to RRC Setup. The fallback path was not
adding the PCell to the UE's serving_cells array, causing
rrc_get_pcell_for_ue() to return NULL.

Major changes:
- Add rrc_update_ue_pcell() helper function that handles PCell updates
  for both new UEs (fallback) and existing UEs (normal reestablishment)
- Refactor normal reestablishment path to use rrc_update_ue_pcell()
  helper instead of manual cleanup + add sequence
- Add PCell update to fallback_rrc_setup path using the same helper
- Move C-RNTI validation after current_cell fetch to ensure current_cell
  is initialized before fallback_rrc_setup label
- Change error handling: return instead of fallback when PCell add fails
  in normal reestablishment path
2026-02-17 11:36:25 +01:00
Robert Schmidt 7bf290d674 Merge remote-tracking branch 'origin/cleanup-cmake' into integration_2026_w07 (!3915)
Cleanup Cmake: remove some double compilation

Harmonize some cmake code to avoid double compilation, notably around
polar and smallblock. In develop, we just add their sources to other
targets, whereas now we define STATIC libraries (further changed to
shared library in !3856) to avoid double compilation.

With this command line:

    cmake .. -GNinja -DENABLE_TESTS=ON && ninja

shows that before we compile 12631 files, where after it is 12583

there is additional supporting cleanup (move code, remove headers,
types, ...).

there is more harmonization to do, I limited myself to some easy wins.
For instance, we do the same with PDCP/SDAP, and this should be
refactored into STATIC libraries as well.
2026-02-12 12:00:24 +01:00
Robert Schmidt a0d2c172ad Merge remote-tracking branch 'origin/rrc-multi-cell' into integration_2026_w07 (!3783)
RRC: Multi-cell handling architecture

This MR implements a foundational multi-cell handling architecture for
RRC by separating DU management from cell management and establishing a
hierarchical cell organization within each DU container. The changes
enable proper multi-cell support where each DU can serve multiple cells,
addressing the previous limitation where DU and cell management were
tightly coupled with the assumption of one cell per DU.

Key Changes:

- Data Structure Separation: Separated for DU containers (DU-specific
  info) from cell containers (cell-specific data)
- Global DU and Cell Trees: Cells are now stored in global RB trees in
  RRC, similarly to DUs
- Du-specific cell seq_arr: within each DU container (du->cells) is
  stored a seq_arr of cells belonging to the DU
- UE Cell Association Framework: Introduced serving_cells array to track
  PCell and SCells for each UE with servCellIndex indexing
- Cell Management Library: Extracted cell management functions into
  rrc_cell_management.c/h for better testability and maintainability

Other relevant changes:

- F1AP Refactoring: cell list definitions, heap allocation to prevent
  stack overflow
- 5G-S-TMSI Helpers: Common helper functions for 3GPP TS 23.003
  compliant construction
- Integration Tests: Comprehensive test suite for DU lookup, cell
  lookup, and UE cell association
- Cell Duplication Checks: Validation in F1 DU configuration update to
  prevent duplicate cells
- Documentation: Updated RRC developer documentation with multi-cell
  architecture details

Validated with RFsim in re-establishment and handover scenarios.
2026-02-12 09:07:58 +01:00
Robert Schmidt 0464329eed Make 5G RRC not depend on LTE code 2026-02-12 08:47:08 +01:00
Robert Schmidt 4d4d0d4dd4 Move RRC config to RRC header, rename
openair2/COMMON/rrc_messages_types.h has mostly 4G types. The only 5G
(gNB) RRC type is gNB_RrcConfigurationReq, which we can move to a header
in the corresponding directory (where it is used).

This allows to separate 5G gNB RRC module from the 4G types in
rrc_messages_types.h in the next commit.
2026-02-12 08:47:08 +01:00
Robert Schmidt ee1f9dfede Move hashtable to ds/ folder
Notably, remove the include_directories(), which is not necessary, as
most files do not actually use this.
2026-02-12 08:47:07 +01:00
Robert Schmidt bfc0f9e2a3 Merge remote-tracking branch 'origin/remove_nr_vcd' into integration_2026_w07 (!3913)
Remove VCD signal dumper from NR code

We don't test VCD in 5G NR code (and haven't tested it in 4G for years).
Remove the VCD traces in 5G code to avoid any ambiguity. 4G code remains
in place, as well as the tools to analyze existing traces.
2026-02-12 08:43:27 +01:00
Robert Schmidt 2a4cbda212 Merge remote-tracking branch 'origin/rrc-qos-refactor' into integration_2026_w07 (!3907)
RRC QoS refactor: PDU Session Modify support, SDAP fixes, and code improvements

The goal of this MR is to prepare the RRC/NGAP layer for the multi-QoS
support. The MR:

- enables PDU Session Resource Modify support in RRC/NGAP/E1AP
- fixes SDAP header mapping
- enables SDAP by default
- refactors QoS flow handling in RRC/NGAP
- improves error handling, and code maintainability in RRC/NGAP

Changes:

- NGAP PDU Session Modify:
  * add NGAP PDU Session Resource Modify Request/Response handling with
    proper error reporting for unrecognized sessions and AMF UE NGAP ID
    validation
- E1AP Bearer Context Modification:
  * add DRB To Remove List IE to support DRB release during modify
  * rename numQosFlow2Setup to numQosFlowsMod in DRB To Modify List
- RRC QoS flow handling:
  * enable multi-QoS flow support per DRB
  * add utilities to map NGAP QoS parameters to E1AP
  * filter QoS flows by DRB ID
- SDAP configuration:
  * Fix SDAP header UL/DL mapping between internal representation and
    ASN.1 enum (invert mapping)
  * change SDAP header fields from long to bool for clarity
- F1 DRB setup refactoring:
  * Extract shared helpers for F1 DRB setup list filling
  * reduce duplication between E1 response and direct DRB setup paths
- AMBR management:
  * Store AMBR in UE context
  * validate AMBR is set before bearer setup
- Configuration:
  * remove unused drbs configuration parameter
  * enable SDAP by default (change default from false to true)
2026-02-11 15:02:01 +01:00
francescomani 0a447fd304 remove VCD_SIGNAL_DUMPER_DUMP_FUNCTION_BY_NAME from NR code and remaining unused header include 2026-02-11 10:30:07 +01:00
Guido Casati 3d41d28f1d RRC: enhance AMBR management in CU-CP
According to TS 38.413:

* AMBR is conditional to PDU Session Resource to setup in the Initial UE
  Context Setup procedure
* The UE Aggregate Maximum Bit Rate IE should be sent to the NG-RAN node
  if the AMF has not sent it previously. If it is included in the PDU
  SESSION RESOURCE SETUP REQUEST message, the NG-RAN node shall store
  it in the UE context
* Range is INTEGER [0..4,000,000,000,000]

To this purpose, changes in the commit:
* Init AMBR to out of range value when creating UE context
* Store AMBR in UE context whenever is received
* Assert if not set at the time of Bearer Setup (should be known at that stage)
2026-02-09 17:01:25 +01:00
Guido Casati 5ad1f14cb8 RRC: refactor F1 DRB setup list filling into shared helpers
Extract common code from `fill_drb_to_be_setup_from_e1_resp` and
`rrc_fill_f1_drb_to_setup` into reusable helper functions to reduce
duplication and improve maintainability. This refactoring enables
multi-QoS flow handling per DRB and prepares helpers for upcoming
PDU Session Modify changes.

Impact:
- Enables multi-QoS flow support: `rrc_fill_f1_drb_to_setup` now
  collects all QFIs mapped to a DRB instead of only the first one
- Reduces code duplication between E1 response and direct DRB setup
  code paths
- Improves maintainability by centralizing F1 DRB setup logic

Major changes:
- Add `fill_f1_drb_info_nr`: fills DRB information IE including QoS
  flows from QFI list
- Add `fill_f1_drb_to_be_setup`: creates F1 DRB to setup structure
  from RRC DRB, PDU session, and QFI list
- Add `fill_f1_drbs_from_e1`: processes DRBs from E1 response and
  extracts QFIs from drb_config->qosFlows
- Refactor `fill_drb_to_be_setup_from_e1_resp` to use
  `fill_f1_drbs_from_e1`
- Refactor `rrc_fill_f1_drb_to_setup` to collect all QFIs mapped to
  each DRB and use `fill_f1_drb_to_be_setup`
2026-02-09 14:02:12 +01:00
Guido Casati 2ed28c84b3 RRC/NGAP: refactor rrc_gNB_process_NGAP_PDUSESSION_MODIFY_REQ
TS 38.413 8.2.3 PDU Session Modify:

> For each PDU session which failed to be modified, the PDU Session Resource Modify
> Unsuccessful Transfer IE shall be included containing the failure cause

> If the NG-RAN node receives a PDU SESSION RESOURCE MODIFY REQUEST message containing
> some PDU Session ID IEs (in the PDU Session Resource Modify Request List IE) that the
> NG-RAN node does not recognize, the NG-RAN node shall report the corresponding invalid
> PDU sessions as failed in the PDU SESSION RESOURCE MODIFY RESPONSE message
> with an appropriate cause value

Changes in the commit:

* add rrc_gNB_ngap_pdusession_mod_failure helper function to handle
  abnormal conditions and send NGAP response with (all) failed PDU sessions
  * improve error handling: send NGAP response instead of silently returning -1
    when UE context lookup fails (unknown RAN UE NGAP ID)
  * add AMF UE NGAP ID validation: check stored AMF UE NGAP ID matches request
    and send failure response if mismatch (per 3GPP TS 38.413)
* handle unrecognized PDU Session IDs per 3GPP TS 38.413 8.2.3.4: add to
  failed list to be sent in the reponse message
* simplify failure path: reuse rrc_gNB_send_NGAP_PDUSESSION_MODIFY_RESP
  instead of manually constructing response message
* remove failed PDU sessions from RRC list in rrc_gNB_send_NGAP_PDUSESSION_MODIFY_RESP
* remove redundant code and improve code organization
* add bounds checking
* improve function signature
2026-02-09 14:01:50 +01:00
Guido Casati eaf27acb3b RRC/NGAP: refactor rrc_gNB_send_NGAP_PDUSESSION_MODIFY_RESP
This commit refactors the rrc_gNB_send_NGAP_PDUSESSION_MODIFY_RESP function
to improve code clarity, fix bugs, and ensure compliance with 3GPP TS 38.413
section 9.2.1.6.

The main improvement is ensuring the PDU Session Resource Modify Response message
is always sent with mandatory IEs, even when there are no PDU sessions to report
in the optional lists.

Key changes:
- Initialize message structure parameters to 0 by leveraging structure
  initialization, ensuring clean state
- Replace local counter variables (pdu_sessions_done, pdu_sessions_failed)
  with direct access to resp->nb_of_pdusessions and resp->nb_of_pdusessions_failed,
  eliminating redundant state tracking and improving code clarity
- Remove conditional message sending: always send the response message
  (per 3GPP TS 38.413 9.2.1.6, PDUSessionResourceModifyResponse must always
  be sent with mandatory IEs: AMF-UE-NGAP-ID and RAN-UE-NGAP-ID, even when
  optional lists are empty)
- Fix duplicate assignment: remove redundant p->pdusession_id assignment
  (was assigned twice in the PDU_SESSION_STATUS_DONE case)
- Improve failed PDU session handling: use direct structure assignment
  (failed->cause = session->cause) instead of field-by-field copying,
  making the code more maintainable
- Remove failed PDU session upon response
- Enhance logging: improve log messages for better debugging and clarity
- Add function documentation comment
2026-02-09 14:01:50 +01:00
Guido Casati 7982374f6a RRC/NGAP: add utility function to fill E1 QoS to setup list from NGAP
Introduce fill_e1_qos_flow_to_setup to translate pdusession_level_qos_parameter_t (NGAP)
into qos_flow_to_setup_t (E1), including ARP and QoS characteristics (dynamic/non-dynamic).

Refactor fill_e1_drb_to_setup to use the new helper for building QoS flows.
* Only include QoS flows whose drb_id matches the target DRB.
* Add DevAssert(drb_ngran.numQosFlow2Setup > 0) to ensure at least one QoS flow is added.

This change centralizes and simplifies QoS mapping logic between NGAP inputs
and E1 DRB configuration. It ensures correctness by associating QoS flows
to the appropriate DRB.

Major changes:
- Extract QoS flow mapping logic into fill_e1_qos_flow_to_setup helper function
- Filter QoS flows by matching drb_id before adding to DRB setup list
- Replace inline mapping code with helper function call
- Add assertion to verify at least one QoS flow is added per DRB
2026-02-09 14:01:08 +01:00
Guido Casati 2923e50ed0 RRC/E1AP: Fix SDAP header mapping in E1AP and test callback header handling
This commit fixes two related issues:

1. SDAP Header Mapping Bug (cucp_cuup_handler.c):
   The original code incorrectly mapped SDAP header configuration from
   internal E1AP representation to ASN.1 enum values. The internal
   representation (`bearer_context_sdap_config_t`) uses true=present/false=absent,
   while ASN.1 enum (`E1AP_SDAP_Configuration_t`) uses
   0=present/1=absent. The fix correctly inverts the mapping:
   - Internal true (1) → ASN.1 0 (present)
   - Internal false (0) → ASN.1 1 (absent)

The commit also clarifies internal representation in the stack.

2. Test Overhead Adjustment (nr-cuup-load-test.c):
   The change in (1) led to a failure in nr_cuup_functional_test
   with assertion: "size % 4 == 0" in recv_ng()

   - Changed UL packet overhead from 3 bytes to 2 bytes in sender_thread()
   - Before the SDAP fix, the test incorrectly accounted for 3 bytes:
     * 2 bytes PDCP header (correct)
     * 1 byte SDAP header (incorrectly included)
   - After the SDAP fix, SDAP headers are correctly set to absent, so
     only 2 bytes (PDCP header) are needed

   This ensures the test sends packets with the correct header size,
   matching what CU-UP expects after the SDAP configuration fix.

The load test does not enable SDAP headers, therefore the original 3-byte
overhead was possibly a workaround for the SDAP header bug.
With the bug fixed, the test correctly uses 2-byte overhead (PDCP header).
2026-02-09 13:19:02 +01:00
Guido Casati 53c0d2d306 NGAP: refactor PDU Session Resource Modify struct definition
This commit refactors the PDU Session Resource Modify Response message
structures to improve naming, documentation, and compliance with 3GPP TS 38.413 9.2.1.6.

Changes in NGAP:
- Rename qos_flow_tobe_modified_t to qos_flow_addmod_response_item_t to better
  reflect its purpose as a QoS Flow Add or Modify Response Item IE (as per specs)
- Add mandatory AMF UE NGAP ID field to ngap_pdusession_modify_resp_t structure
- Optimize field types: change nb_of_pdusessions and nb_of_pdusessions_failed
  from uint16_t to uint8_t (NGAP_MAX_PDU_SESSION limit) (ref 3GPP TS 38.413, 9.2.1.6)
- Update PDU Session Modify Response encoder to use amf_ue_ngap_id from the
  message structure (pdusession_modify_resp_p->amf_ue_ngap_id) instead of
  retrieving it from UE context (ue_context_p->amf_ue_ngap_id)
- Add comprehensive comments with 3GPP TS 38.413 section references throughout

Changes in RRC/NGAP:
- Populate amf_ue_ngap_id field in PDU Session Modify Response message from
  UE context
- Update type reference to qos_flow_addmod_response_item_t
2026-02-09 13:19:02 +01:00
Guido Casati e490faa60c E1AP: add DRB To Remove list to E1 Bearer Context Modification lib
Add DRB To Remove List IE to PDU Session To Modify list, which is sent
in the Bearer Context Modification request. This allows the CUCP to
inform the CUUP about DRBs to be released in a specific PDU session
during a MODIFY procedure.

Changes:

* Add struct definition
* Add enc/dec/eq/cp func
* Add test
2026-02-09 13:19:02 +01:00
francescomani 9b381f5d10 declare RLF to re-establish or restart the connection if the ASN1 decoding fails 2026-02-08 09:13:00 +01:00
francescomani 296fb2bd72 checking csi-rs resource mapping consistency to handle #1017 2026-02-08 09:12:58 +01:00
francescomani 562fcd322f checking SRS symbol mapping consistency to handle #1016 2026-02-08 09:09:44 +01:00
francescomani 833ff548c5 checking consistency in CSI-ResourceConfigId for channel and interference measurements in received RRC configuration
This handles issue #1018
2026-02-08 09:07:22 +01:00
francescomani 0b500d412a adding a function to check the received RRC configuration (function to be expanded in later commits)
also move functions to check RRC configuration to a new file not to overload the already big rrc_UE.c
2026-02-08 08:51:17 +01:00
Guido Casati e75399707c RRC multi-cell (finalise): add informative comments and logging
This commit adds documentation comments and logging to improve
code readability and debugging capabilities for the multi-cell
architecture.

Changes:
- gnb_config.c: Add logging when configuring DU with cell ID and PCI
- rrc_gNB_du.c: Add documentation comment for ssb_arfcn_mtc()
- rrc_gNB_du.c: Add documentation comment for dump_du_info()
2026-02-05 16:57:31 +01:00
Guido Casati 9bfe62b85b RRC multi-cell (finalise): make internal helper functions static
After introduction of new cell management design, these helper functions
are now only used internally within their respective modules and do not
need to be part of the public API. They are made static and their
declarations are removed from public headers.

Changes:
- f1ap_interface_management.c: Make free_f1ap_cell() and
  copy_f1ap_served_cell_info() static
- f1ap_interface_management.h: Remove declarations for the above functions
- rrc_gNB_du.c: Make get_dl_band() and get_ssb_scs() static
- rrc_gNB_du.h: Remove declarations for get_dl_band() and get_ssb_scs()
2026-02-05 16:57:31 +01:00
Guido Casati bd2fc0d237 RRC multi-cell: enable multiple cell in F1 Setup
Remove the single-cell limit in F1 Setup Request processing and
refactor to loop-based cell handling. Move cell validation (PLMN
check, neighbor configuration validation, system info extraction),
cell creation, SIB encoding, and neighbor labeling inside a loop
over all available cells.

Update F1 Setup Response to include all cells instead of hardcoding to 1.

Add warning log when more than one cell is received. Add proper
cleanup with free_f1ap_setup_response() on error paths.

Impact:
- F1 Setup now accepts and processes multiple cells from a single
  DU, enabling multi-cell deployments
- All cells are validated, created, and included in the setup
  response
2026-02-05 16:55:32 +01:00
Guido Casati d471046623 RRC multi-cell: complete migration to cell container architecture
Finalize the migration from single-cell-per-DU to the multi-cell
architecture: remove legacy DU/cell fields and refactor RRC procedures
to use cell containers and UE serving cells instead of DU-based lookups.

Data structure changes:
- Remove nr_cellid from gNB_RRC_UE_t; cell identity comes from the UE's
  serving_cells (PCell entry via ue_get_pcell_entry(ue)). UE_LOG_ARGS
  and LOG_UE_* macros take a PCell entry pointer for null-safe cell_id
  in logs; all call sites pass ue_get_pcell_entry(ue).
- Remove setup_req, mib, sib1, mtc from nr_rrc_du_container_t (held in
  cell containers); remove nr_cellid from gNB_RRC_INST and its
  assignment in gnb_config.c.

Function and signature updates:
- get_ssb_arfcn(): take cell container instead of DU.
- label_intra_frequency_neighbours(): drop du parameter, use cell only.
- Handover: Handover context (source and target) now stores cell
  pointers (source->cell, target->cell) instead of DU pointers. When
  the context is created (N2: on Handover Request; F1: in
  nr_rrc_trigger_f1_ho), the target cell is set in ho_context->target->cell
  and, for F1, the source cell in ho_context->source->cell.
  nr_initiate_handover() takes only source_cell and reads the target
  from ho_ctx->target->cell, so it no longer takes a target parameter.
  The target is known at handover creation time, while the UE’s
  serving_cells are only updated after F1 UE Context Setup Response.
- nr_rrc_trigger_f1_ho() and the N2 handover path pass cell pointers
  and set ho_context->target->cell (and for F1, source->cell) when
  the handover is triggered.

Procedure refactoring:
- Lookups: replace get_du_by_cell_id() with get_cell_by_cell_id()/
  get_cell_by_pci(); remove get_du_by_cell_id() and
  get_cell_information_by_phycellId().
  Rationale: cell-specific data (MIB, SIB1, mtc, info) now lives in
  cell containers, and a DU can host multiple cells. Callers need the
  cell (to use cell->info, cell->mtc, etc.), not the DU. Looking up
  by cell_id therefore returns the cell container
  (get_cell_by_cell_id()); when the DU is needed, use
  cell->assoc_id and get_du_by_assoc_id(). Looking up by PCI is
  scoped (e.g. get_cell_by_pci_for_du() for a given DU, or via the
  UE’s serving cells) because PCI is not globally unique.
- Setup/Reestablishment: resolve cell, register as PCell via
  rrc_add_ue_serving_cell(); reestablishment resolves cell by PCI
  (rrc_get_cell_by_pci_for_du), then rrc_remove_ue_scells_from_du +
  rrc_add_ue_serving_cell; validate_ue_cell_association() after update.
- Measurement config: use cell->info (SCS/band) and cell->mtc.
- Handover: use cell containers end-to-end; after UE context
  modification response call nr_rrc_update_cell_assoc_after_ho().
- NGAP: cell_id and TAC from UE PCell via rrc_get_pcell_for_ue();
  Handover Notify: get cell for message content, use get_du_for_ue() for
  DU existence check; paging resolves UE by 5G-S-TMSI-Part1 and uses that
  UE's PCell (rrc_get_pcell_for_ue) for F1AP_PAGING_IND nr_cellid.

Performance and robustness:
- Use rrc_get_pcell_for_ue() when cell data is needed; use
  get_du_for_ue() when only the DU is needed (F1/N2 HO trigger,
  Handover Notify DU check) for efficiency.
- Reestablishment: remove old PCell before adding new; error handling
  for PCell add and validation.

Code cleanup:
- F1 setup: stop copying/storing setup request in DU container; F1
  disconnect only frees cell containers via rrc_free_cell_container().
- dump_du_info(): iterate du->cells and show all cells per DU.
- telnetsrv_ci.c: use du->gNB_DU_id directly and fix format (%ld).
- UeContextSetupRequest servCellIndex set to RRC_PCELL_INDEX; remove
  servCellIndex from F1AP UE context modification request.
2026-02-05 11:44:10 +01:00
Guido Casati 5980dbcb40 RRC multi-cell: use cell lookups in NGAP Handover Request handling
In rrc_gNB_NGAP.c, rrc_gNB_process_Handover_Request() is updated to
resolve the target by cell instead of by DU, then resolve the DU from
the cell's assoc_id. This aligns Handover Request with the new
cell-centric model and cell management APIs.

- Resolve target with get_cell_by_cell_id(&rrc->cells, msg->nr_cell_id)
  instead of get_du_by_cell_id(); on failure, log "no cell found" and
  send NGAP handover failure.
- Resolve DU with get_du_by_assoc_id(rrc, cell->assoc_id); add a
  failure path (log, NGAP handover failure, return -1) when no DU
  exists for the cell's assoc_id.
- Use cell->info (nr_rrc_cell_info_t) for logging and for key
  derivation (nr_derive_key_ng_ran_star); use du->assoc_id
  for UE context creation instead of du->setup_req->cell[0].info.

get_ssb_arfcn(du) is unchanged and still takes the DU; other DU-based
lookups are kept where still required.
2026-02-05 11:44:10 +01:00
Guido Casati 15c79b0288 RRC multi-cell: adopt cell management in F1 DU configuration update procedures
Migrate F1 DU configuration update procedures in openair2/RRC/NR/rrc_gNB_du.c
to use the cell management API instead of accessing cell data through
setup_req, completing the transition to the new multi-cell architecture.

1. update_cell_info:
   - Refactored to use cell management API: takes RRC instance, old cell_id,
     and new cell info; finds cell via get_cell_by_cell_id() internally.
   - Returns cell container pointer (or NULL on failure) instead of void.
   - When cell_id changes: removes cell from RB tree (old key), updates via
     cp_f1_served_cell_info_to_cell(), re-inserts (new key); validates no
     duplicate cell_id/PCI before allowing change.
   - Frees old MTC when new measurement timing config is present.
   - Encapsulates cell lookup and update logic.

2. rrc_gNB_process_f1_du_configuration_update:
   - Uses update_cell_info() for cell modify; validates cell belongs to DU
     (assoc_id) after update.
   - Duplicate checking via get_cell_by_cell_id() and
     rrc_get_cell_by_pci_for_du()
   - For cells to add: validates duplicate cell_id globally and duplicate
     PCI within DU; rejects with logging.
   - MIB/SIB1 updated in cell container (cell->mib, cell->sib1); uses
     du->gNB_DU_id; passes cell to label_intra_frequency_neighbours();
     removes direct setup_req->cell[0] access.

Backward compatibility: setup_req remains until migration is completed;
cell-specific data is managed in the cell container and accessed via
the cell management API. Improves separation of concerns and enables
proper multi-cell support.
2026-02-05 11:44:09 +01:00
Guido Casati 95d35b9b7d RRC multi-cell: integrate cell containers into F1 setup flow
Refactor F1 setup processing to create and manage cell containers during DU
initialization, establishing the foundation for multi-cell architecture where
cells are managed independently from DUs.

Why: Cell information is currently tied to F1AP structures (f1ap_served_cell_info_t),
which complicates multi-cell support. Introducing cell containers at F1 setup
decouples RRC cell management from F1AP and allows cells to be managed
independently while keeping existing code paths working.

Key changes:

1. Cell container creation (cp_f1_served_cell_info_to_cell):
   New helper copying F1AP served cell info into nr_rrc_cell_container_t (cell_id,
   pci, plmn, tac, TDD/FDD frequency info). Extracts and stores MTC in the cell.

2. Function signature updates:
   get_cell_neighbour_list() and label_intra_frequency_neighbours() now take
   nr_rrc_cell_container_t* and use cell->info; improved logging (cell_id, PCI,
   SSB ARFCN).

3. valid_du_in_neighbour_configs:
   Removed ssb_arfcn parameter; MTC is extracted and freed inside the function.

4. F1 Setup (rrc_gNB_process_f1_setup_req):
   Initialize DU cell tree (RB_INIT(&du->cells)). Populate DU-only fields
   (gNB_DU_id, gNB_DU_name, rrc_ver).
   Flow:
   - create cell with cp_f1_served_cell_info_to_cell
   - add to global tree via rrc_add_cell()
   - add DU via rrc_add_du()
   - attach cell to DU with rrc_add_cell_to_du().
   Store MIB/SIB1/MTC in cell.
   Use cell container for neighbour labeling and SIB encoding.

5. Duplicate cell detection:
   Use rrc_add_cell() for global cell tree insert; collision return indicates
   duplicate cell_id. Clearer error messages for Cell ID vs PCI conflicts.
   Use F1AP_CauseRadioNetwork_cell_not_available for cell conflicts.

6. DU configuration update:
   Use get_cell_by_cell_id() to find cell, check assoc_id, pass cell container
   to label_intra_frequency_neighbours().

7. DU disconnection:
   Use rrc_cleanup_du() to remove cells from global tree and free resources;
   logging uses DU fields (gNB_DU_id, gNB_DU_name).

8. Global cell tree:
   Initialize rrc->cells in openair_rrc_gNB_configuration().

Backward compatibility: setup_req still built via cp_f1ap_setup_request();
du->mib, du->sib1, du->mtc remain set (shared with cell container).
2026-02-05 11:44:09 +01:00
Guido Casati c453c342ed RRC multi-cell: add integration tests
Add integration tests for RRC cell and DU management and UE serving-cell
logic so that multi-cell behaviour and regressions can be validated
without running the full stack.

* test_du_lookup() – DU container lookup by assoc_id:
  - Multiple DU creation and insertion into RRC DU tree
  - Lookup of existing DUs by assoc_id
  - Non-existing and invalid assoc_ids
  - Cleanup of DU containers and cells

* test_cell_lookup() – Cell management and UE association:
  - Cell lookup by cell_id and PCI (global and per-DU)
  - DU-specific lookup: rrc_get_cell_for_du(), rrc_get_cell_by_pci_for_du()
  - Duplicate cell and PCI collision handling (including PCI reuse across
    DUs and rejection of duplicate PCI within same DU)
  - Cell–DU association (add/remove cells from DU containers)
  - UE serving cell: add PCell/SCells, get by ID, get PCell, max serving
    cells limit, single PCell enforcement
  - validate_ue_cell_association(), rrc_remove_ue_scells_from_du()
  - Edge cases and error handling

Add openair2/RRC/NR/tests/rrc_cell_management_test.c and extend
openair2/RRC/NR/tests/CMakeLists.txt to build and register the test.
2026-02-05 11:44:09 +01:00
Guido Casati 2ff071a52e RRC multi-cell: add UE serving cell management functions
Add functions to manage UE serving cells so the RRC can track which cells
a UE is using (PCell and SCells) for multi-cell UE context and future
SCell management.

- rrc_cell_management.c / rrc_cell_management.h:
  * rrc_get_ue_serving_cell_by_id(): return serving cell by servCellIndex
    (O(k) linear search, k ≤ 32).
  * rrc_add_ue_serving_cell(ue, cell, serving_cell_id): add entry to UE
    serving_cells with validation: reject duplicate servCellIndex with
    different nci, enforce max 32 serving cells (TS 38.331), keep PCell
    at index 0 for O(1) access; return existing entry if same
    servCellIndex and nci.
  * rrc_remove_ue_scells_from_du(ue, assoc_id): remove all serving cells
    for the given DU (handover/DU disconnect); use stored assoc_id for
    O(k) comparison.
  * ue_get_pcell_entry(): return PCell entry (first element, O(1)).
  * rrc_get_pcell_for_ue(): return PCell container from cell tree using
    UE's PCell entry.
  * Header: RRC_PCELL_INDEX (0), RRC_MAX_NUM_SERVING_CELLS (32), and
    declarations for the above.

- UE context lifecycle:
  * rrc_gNB_create_ue_context(): seq_arr_init(serving_cells).
  * rrc_delete_ue_data(): seq_arr_free(serving_cells).
2026-02-05 11:44:09 +01:00
Guido Casati 6d0c7945c2 RRC multi-cell: extract DU management to cell management library
Move DU tree management from rrc_gNB_du.c into rrc_cell_management so that
DU and cell lookup logic live in one place, improving maintainability and
testability (there is no DU lib).

- rrc_cell_management: add du_compare(), RB_GENERATE(rrc_du_tree),
  get_du_by_assoc_id(), rrc_add_du(), rrc_rm_du(), rrc_cleanup_du(),
  rrc_free_du_container(); declare them in rrc_cell_management.h.
- rrc_gNB_du: move du_compare(), RB_GENERATE, get_du_by_assoc_id()
  to rrc_cell_management
2026-02-05 11:44:09 +01:00
Guido Casati 3dfdc66c41 RRC multi-cell: add cell management library with lookup and cleanup
This commit introduces a new library module (rrc_cell_management.c/h)
to centralise functions that provides cell lookup, DU-specific cell
management, and cell lifecycle managements.

The design uses a dual-tree architecture:
- Global cell tree: RB-tree at RRC level (rrc->cells) keyed by cell_id,
  used for O(log N_CELL) lookups and for maintaining num_cells.
- DU-specific storage: seq_arr_t per DU (du->cells) for iteration and
  management of cells belonging to each DU.

API added:
- Global tree: get_cell_by_cell_id()(finds cell using global RB-tree
  lookup (O(log N_CELL) complexity); rrc_add_cell(); rrc_rm_cell()
  (rrc_rm_cell removes from tree, decrements num_cells, and frees the
  cell via rrc_free_cell_container).
- DU-local seq_arr: rrc_get_cell_for_du(), rrc_get_cell_by_pci_for_du(),
  rrc_add_cell_to_du() (with duplicate cell_id/PCI checks).
- Cleanup: rrc_free_cell_container() (frees ASN.1 MIB/SIB1/MTC and
  container

Build: add rrc_cell_management static library in openair2/RRC/NR;
link it into nr_rrc from top-level CMakeLists.txt.
2026-02-05 11:44:09 +01:00
Guido Casati b699884ae4 RRC multi-cell: add data structure definitions for multi-cell architecture
Add foundational data structures in nr_rrc_defs.h for multi-cell handling
in RRC, separating DU management from cell management.
Design uses a global cell tree for O(log N) lookups while keeping cell
ownership in DUs for locality and maintenance.

The implementation maintains backward compatibility and follows the same
patterns as existing DU and CUUP management in the codebase, i.e. RB-trees
with logarithmic complexity for scalable multi-cell deployments.

- Cell container structures:
  * nr_rrc_cell_container_t: cell-specific data (cell_id, pci, plmn, tac,
    frequency info, mib, sib1, mtc)
  * nr_rrc_cell_info_t: TDD/FDD modes; frequency structs nr_rrc_freq_info_t,
    nr_rrc_tdd_info_t, nr_rrc_fdd_info_t

- UE serving cell tracking:
  * ue_serving_cell_t: nci, serving_cell_id (ServCellIndex TS 38.331,
    0=PCell, 1-31=SCell), assoc_id for fast DU lookup
  * gNB_RRC_UE_t: seq_arr_t serving_cells, with PCell always being the
    first in the sequence

- DU container refactoring:
  * nr_rrc_du_container_t: DU-only fields (gNB_DU_id, gNB_DU_name, rrc_ver);
    seq_arr_t cells for per-DU iteration; setup_req/mib/sib1/mtc kept for
    backward compatibility

- Global cell tree:
  * gNB_RRC_INST_s: RB_HEAD(rrc_cell_tree, nr_rrc_cell_container_t) cells,
    num_cells (data only; lookup helpers get_cell_by_cell_id/get_cell_by_pci
    to be added separately)
2026-02-05 11:44:09 +01:00
Guido Casati 4c56c6b2de Refactor (RRC): improve UE context removal logging
Replace generic UE event log with explicit INFO log including UE ID and RNTI
when removing a UE context and centralize access to UE fields via a local
pointer.

rrc_delete_ue_data removes the all the list in the UE context, including the
serving cells, and therefore the cell id should not be logged in the function
responsible for the removal of the UE context, which at this point is already
emptied and while the cells themselves are still there (in the DU/global cell
structures), the lists in the UE context are empty.
2026-02-05 11:43:59 +01:00
Guido Casati 5d657c801c Refactor (F1AP): align cell lists definitions with TS 38.473
* Commit applies to Setup Request, CU/DU Configuration Update
* Set standard compliant max number of cells per DU
* Allocate large lists on the heap to prevent stack overflow
  due to the large size
* Update relevant free functions
* Also, fix bug in eq_f1ap_cu_configuration_update

Also, improve comments in struct definition.
2026-02-02 16:26:10 +01:00
Robert Schmidt c8bcfedae0 Merge remote-tracking branch 'origin/issue-837' into integration_2026_w05 (!3732)
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

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

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

See also TS 38.401 Figure 8.7-1 "RRC connection reestablishment
procedure" for reference

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
2026-01-29 17:20:43 +01:00
luis_pereira87 d401cf0d31 Prevent CU to process UE context release requests from DUs for UEs with outdated or unexpected association ids 2026-01-29 10:17:42 +01:00
Guido Casati fc8e537f20 RRC: align SRB and PDCP re-establishment timing with TS 38.331 specifications
This commit fixes the timing of SRB and DRB PDCP re-establishment
during RRC connection re-establishment to align with 3GPP TS 38.331
specifications.

Key Changes:

1. SRB1 activation and re-establishment (TS 38.331 5.3.7.4):
   - Move SRB1 activation to rrc_gNB_generate_RRCReestablishment()
   - Use SRB1 constant instead of magic number 1 for clarity
   - Remove redundant security configuration loop (handled by
     nr_pdcp_reestablishment internally)

2. SRB2 re-establishment (TS 38.331 5.3.5.6.3 SRB addition/modification):
   - Move SRB2 PDCP re-establishment from rrc_gNB_process_RRCReestablishmentComplete()
   to rrc_gNB_generate_dedicatedRRCReconfiguration(): per spec: SRB2
   should be re-established in the first RRCReconfiguration after
   re-establishment (with reestablishPDCP=true flag)

3. DRB re-establishment (TS 38.331 5.3.5.6.5 DRB addition/modification):
   - Move cuup_notify_reestablishment() from rrc_gNB_process_RRCReestablishmentComplete()
   to rrc_gNB_generate_dedicatedRRCReconfiguration(). e.g at the first
   reconfiguration after reestablishment
   - Ensures CU-UP is notified at the correct time
2026-01-29 10:17:42 +01:00
Guido Casati c5787aa9a9 RRC: Trigger UE Context Setup upon re-establishment on different DU
As per TS 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 F1 handover, it shall trigger a
UE Context Setup fallback on the CU.

This commit implements the required behavior:

1. Detection mechanism:
   - Add `old_du_assoc_id` field to `f1_ue_data_t` to store the original
     DU association ID
   - At RRCReestablishmentRequest: Store original `du_assoc_id` in
     `old_du_assoc_id` and update `du_assoc_id` to the new DU
   - At RRCReestablishmentComplete: Compare `old_du_assoc_id` with the
     `assoc_id` from the Complete message to detect different DU

2. UE Context Setup trigger:
   - In `rrc_gNB_process_RRCReestablishmentComplete()`: When different DU
     is detected, call `rrc_f1_ue_context_setup_for_target_du()` to trigger
     UE Context Setup procedure (per TS 38.401 §8.7, NOTE on steps 9-10)
     upon reception of UL RRC MESSAGE TRANSFER
   - In `rrc_CU_process_ue_modification_required()`: Refuse UE Context
     Modification Required when `old_du_assoc_id != 0` to avoid conflicts
     with the ongoing UE Context Setup procedure (per TS 38.401 §8.7, NOTE
     on steps 9'-10')

3. UE Context Setup:
   - Replace `clone_CellGroupConfig()` with `get_cellgroup_config()` in
     UE Context Setup handler
   - Call `update_cellgroup_for_reestablishment()` during UE Context Setup
     when `reestablish_rlc` flag is set to prepare CellGroupConfig with
     reestablishRLC flags
   - Clean up `old_du_assoc_id` in `rrc_CU_process_ue_context_setup_response()`
   - Add `free_ue_context_mod_req()` call after UE Context Modification request

4. Function signature updates:
   - Update `handle_rrcReestablishmentComplete()` to accept `gNB_DU_ue_id`
     and `assoc_id` parameters, change return type from `int` to `void`
   - Update `rrc_gNB_process_RRCReestablishmentComplete()` to accept
     `assoc_id` parameter
   - Update `rrc_gNB_decode_dcch()` to accept and forward `assoc_id` parameter

Re-establishment on different DU flow (TS 38.401 §8.7, steps 9-10):
1. UE sends RRCReestablishmentRequest to new DU
2. DU forwards to CU via UL RRC MESSAGE TRANSFER
3. CU detects different DU (`assoc_id != ue_data.du_assoc_id`):
   - Stores `old_du_assoc_id = ue_data.du_assoc_id` (original DU)
   - Updates `ue_data.du_assoc_id = assoc_id` (new DU)
4. CU sends RRCReestablishment to UE
5. UE sends RRCReestablishmentComplete to new DU
6. DU forwards to CU via UL RRC MESSAGE TRANSFER
7. CU detects different DU scenario (with old_du_assoc_id):
   - Triggers UE Context Setup Request to new DU via `rrc_f1_ue_context_setup_for_target_du()`
8. DU receives UE Context Setup Request:
   - Detects re-establishment (`UE->reestablish_rlc` flag)
   - Calls `update_cellgroup_for_reestablishment()` to set reestablishRLC flags
   - Encodes CellGroupConfig with reestablishRLC flags and sends to CU
9. CU receives UE Context Setup Response:
   - Stores encoded CellGroupConfig
   - Clears `old_du_assoc_id = 0`
10. CU sends RRC Reconfiguration with transparent CellGroupConfig to UE
2026-01-29 10:17:42 +01:00
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
Guido Casati 50de6bd8fb F1: encode CGC in UE Context Modification Response upon GNB-DU Configuration Query
Apply CGC encoding through GNB-DU Configuration Query. This applies to the
pdu session release path (rrc_gNB_send_f1_drb_release_request) and E1 bearer
mod / DRB add+release path (rrc_gNB_generate_UeContextModificationRequest).

This is necessary to implement 3GPP TS 38.473 requirement for
gNB-DU Configuration Query IE in UE Context Modification Request:

"If the GNB-DU Configuration Query IE is contained in the UE CONTEXT
MODIFICATION REQUEST message, gNB-DU shall include the CellGroupConfig
IE in the DU To CU RRC Information IE in the UE CONTEXT MODIFICATION
RESPONSE message."

i.e.: The DU sends the CGC only when this IE is enabled in the REQ
message from the CU. The only other scenario according to the same
specs is when the Full Configuration IE is present. Outside of these
two cases, CGC shall not be sent.
2026-01-29 10:17:42 +01:00
Guido Casati aff0ea5760 RRC logging: add utility function to dump ASN1 MCG
Add debugging utilities dump_cgc() and dump_mcg() to decode and
print CellGroupConfig in XER format when DEBUG_ASN1 flag is enabled.
This helps debug RRC Reconfiguration messages containing masterCellGroup.
2026-01-29 10:17:42 +01:00
Guido Casati 9a11690f81 RRC: Improve UE context lookup for re-establishment on different DU
Add intermediate fallback to rrc_gNB_get_ue_context_by_rnti_any_du() in
re-establishment request handling to better handle cases where UE
re-establishes on a different DU.

RNTI is NOT globally unique - different DUs can assign the same RNTI to
different UEs. The assoc_id check in rrc_gNB_get_ue_context_by_rnti()
disambiguates RNTI across DUs and prevents returning the wrong UE.

However, during re-establishment on a different DU, du_assoc_id hasn't
been updated yet (message comes from new DU, but ue_data.du_assoc_id
still points to old DU), causing the primary lookup to fail even though
the UE exists.

The lookup now uses a three-tier fallback:
1. Primary: rrc_gNB_get_ue_context_by_rnti() with assoc_id check
   (normal case: same DU)
2. Fallback 1: rrc_gNB_get_ue_context_by_rnti_any_du() by RNTI only
   (re-establishment on different DU)
3. Fallback 2: rrc_gNB_get_ue_context_source_cell() using physCellId
   (handover scenarios)
2026-01-29 10:17:42 +01:00
Guido Casati d18c2d27f2 RRC: cleanup and improve safety of rrc_gNB_generate_RRCReestablishment()
- Remove unused masterCellGroup_from_DU parameter from rrc_gNB_generate_RRCReestablishment() as it is not used in the RRC
re-establishment generation, RRCReestablishment message does not contain CellGroupConfig which is obtained later via UE Context Modification Request/Response
- Update function documentation
- Initialize security_parameters struct to zero for safety
- Add check on ciphering and integrity algorithm ranges
2026-01-29 10:17:42 +01:00
Guido Casati 825cbcdb47 RRC: Allow re-establishment on different DU when physCellId differs
When a UE re-establishes on a different DU, the physCellId in the
re-establishment request (from the old cell) will differ from the
new DU's physCellId. The previous check incorrectly treated this as
a "too fast movement" scenario and triggered fallback to RRC setup.

This fix distinguishes between two scenarios:
1. Different DU scenario: physCellId differs because UE is on a
   different DU - this is legitimate and should be allowed. UE
   Context Setup will be triggered at RRCReestablishmentComplete.
2. Same DU but different physCellId: "too fast movement" scenario
   - fallback to RRC setup as before.

The fix checks if assoc_id != ue_data.du_assoc_id to detect a
different DU scenario and allows re-establishment in that case.

This addresses the issue where re-establishment on a different DU
was incorrectly rejected, preventing proper UE Context Setup per
TS 38.401 Section 8.7.
2026-01-29 10:17:42 +01:00
Guido Casati 290306d1f8 RRC: Refactor re-establishment request handling
- Extract old_rnti as const variable and reuse consistently
- Move as_security_active check earlier for fail-fast validation
- Move ue_data declaration earlier to avoid duplicates
- Improve code organization and readability

No functional changes.
2026-01-29 10:17:42 +01:00
Guido Casati ebc9158ca4 RRC/F1: provide DU UE ID for re-establishment scenario
Handle target DU UE context setup when handover preparation info
is unavailable (i.e. re-establishment scenario) by retrieving
secondary UE ID from F1 UE data.

rrc_f1_ue_context_setup_for_target_du is either applying to
handover or re-establishment. In the latter scenario, populate
DU UE ID, which should be known.
2026-01-29 10:17:42 +01:00
Robert Schmidt a0a68d56d5 Merge remote-tracking branch 'origin/remove-dead-code' into integration_2026_w05 (!3831)
semi-manual remove of not used #define commands

As i was upset to see all these #define with no code under, i made a
global pass to remove the obvious cases semi-manual remove of not used
bodies

manual script, then a lot of manual review

    grep -IRs "#define" ../openair* ../common/* ../executables/ ../nfapi/ ../radio/ | \
        fgrep -v '(' | fgrep -v '//' |awk '{print $2}' | egrep -v "#define *$n"| \
            while read n ; do
              grep -IRs $n ../openair* ../common/* ../executables/ ../nfapi/ ../radio/  | grep -v "#define *$n" | grep -q $n || echo $n;
            done

will give a decent list of #define never used.  Then, I think we should
keep lists of # define when it comes from standards, even if the code
doesn't use it right now
2026-01-29 08:23:41 +01:00
Robert Schmidt 0eb33e69c7 Merge remote-tracking branch 'origin/add-support-eth-pdu-sess' into integration_2026_w05 (!3769)
Add Ethernet PDU session support and make PDU session request configurable

This MR adds support for Ethernet PDU sessions, and makes PDU sessions
configurable: per-PDU session ID, type (IPv4/IPv4v6/IPv6/Ethernet [1]),
DNN, NSSAI.

Concretely, it adds a new configuration file section pdu_sessions below
uicc0 that looks like this if everything is specified (default values
are shown):

    uicc0:
      [...]
      pdu_sessions:
        - id: 1
          type: "IPv4"
          nssai_sst: 1
          nssai_sd: 0xffffff
          dnn: "oai"

It is possible to list multiple PDU sessions (add new line   - id: 2 to
request a second PDU session). It is backwards-compatible to the current
PDU session configuration (uicc0.dnn/nssai_sst/etc), the idea being that
either legacy or new configuration could be used, but (1) if
pdu_sessions exist, it will overwrite the legacy configuration, and (2)
multiple PDU sessions, and type, can only be configured using the new
config. The old parameters --extra-pdu-id and --default-pdu-id are not
accepted anymore. Documentation has been added to the UE tutorial.

It is possible to test an Ethernet PDU session [1]. It is possible to
test the PDU session inside the UE by verifying it has an TAP interface
oaitap_ue1, and ARPing the data network (arping has been added to
oai-nr-ue container for that purpose):

    ip addr add 192.168.72.140/26 dev oaitap_ue1  # same subnet as data network!
    ip link set dev oaitap_ue1 up
    arping -c 20 -I oaitap_ue1 192.168.72.135     # will send ARP request in Ethernet frame to get IP address of data network

[1] See description MR !3769 for more information. On the UE side, only
the type has to be changed to "Ethernet".
2026-01-29 07:52:48 +01:00