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).
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.
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).
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
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.
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)
Neighbour lists are built per serving cell in fill_neighbour_cell_configuration.
Each neighbour in a list is identified by PCI; having two entries with the same
PCI in one cell's list would be ambiguous and indicate a configuration error.
This commit adds validation so that duplicate PCIs within a cell's neighbour
list are detected at configuration load time and cause a fatal assertion with
a clear error message.
Changes:
- Add eq_neighbour_pci() and get_neighbour_by_pci() using
common/utils/alg/find.h to look up a neighbour by PCI in a seq_arr.
- In fill_neighbour_cell_configuration(), before appending each
cell's neighbour list, iterate over neighbours and assert that no PCI
appears more than once
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.
Ensure noise power is non-zero
Prior to this commit, noise power estimation could be zero because of a
call to clearArray() in gNB_I0_measurements(). This is problematic, as
this can lead to a noise power of 0 if all symbols in a RB are used,
which in turn leads to a spike in SNR.
To avoid this, use an intermediate array to store noise power, and only
update n0_subband_power if not all RBs are used (i.e., we can detect
noise power). Further, use an exponential moving average to smoothen
noise estimation.
Fixes: fb4235fd ("changes in PUCCH0 SNR measurement, testing for
PUCCH power control")
Prior to this commit, noise power estimation could be zero because of a
call to clearArray() in gNB_I0_measurements(). This is problematic, as
this can lead to a noise power of 0 if all symbols in a RB are used,
which in turn leads to a spike in SNR.
To avoid this, use an intermediate array to store noise power, and only
update n0_subband_power if not all RBs are used (i.e., we can detect
noise power). Further, use an exponential moving average to smoothen
noise estimation.
Fixes: fb4235fd50 ("changes in PUCCH0 SNR measurement, testing for
PUCCH power control")
CI: Ensure OAI-FLEXRIC-RAN-Integration-Test pipeline always uses latest commit for non-MR builds
Related MR -> mosaic5g/flexric!77
For push events, we have:
sh "git fetch"
sh "git checkout -f ${commitID}"
We need to do a reset hard so that the run is executed on synchronized
develop branch.
In the pipeline, we see:
17:38:34 + git checkout -f develop
17:38:34 Previous HEAD position was 9cb79027e4 Merge branch 'integration_2026_w05' into 'develop'
17:38:34 Switched to branch 'develop'
17:38:34 Your branch is behind 'origin/develop' by 526 commits, and can be fast-forwarded.
17:38:34 (use "git pull" to update your local branch)
After implementing the fix:
Below are the runs for pipeline triggered by a merge request event:
https://jenkins-oai.eurecom.fr/job/OAI-FLEXRIC/229/https://jenkins-oai.eurecom.fr/job/OAI-FLEXRIC-RAN-Integration-Test/3788/
In the OAI-FLEXRIC-RAN-Integration-Test pipeline, which is executed by
Build with Parameters from OAI-FLEXRIC
We see the pipeline took the latest develop:
11:26:02 + git reset --hard origin/develop
11:26:02 HEAD is now at 9cb79027e4 Merge branch 'integration_2026_w05' into 'develop'
Change Aerial to pack directly in nvIPC message buffer
This MR changes the Aerial pack/send procedures to pack the messages
directly into the nvIPC message buffers.
This saves the use of some memcopy calls, as well as clean up the code.
The P7 message packing/send is now only handled in the file
`fapi_nv_p7.c`
Add 3 functions in fapi_nvIPC.c to allow message allocation, release and
send from fapi_vnf_p7.c
Add 2 functions to access the memory pool sizes allocated from nvIPC, as
we can't use sizeof to report the buffer size to the packing functions
Remove now unused aerial_send_P5_msg , aerial_send_P7_msg and
aerial_send_P7_msg_with_data functions
Now Aerial only has one function to handle sending P5 and another to
send P7 messages
Remove fapi_phy_api_msg from fapi_nvIPC.h as it is duplicated in
nr_fapi.h
Update RHEL UBI image source to registry.redhat.io
This merge request updates the RHEL UBI base image source to registry.redhat.io,
aligning with Red Hat’s supported container registry and avoiding potential
access or availability issues with registry.access.redhat.com.
[FHI72] Support large DU delay profiles in the xran F, and include ProtO-RU
emulator designed to run 7.2 with an USRP
This MR does the following:
- we patch xRAN to support large DU delay profiles (i.e., T1a/Ta4 values larger
than a TTI)
- we update the FHI72 docs to introduce ProtO-RU, a software implementation of a
Split-7.2 O-RU with large delay profile
- we provide an example configuration for ProtO-RU
Details on the xRAN patch:
In xRAN, it appears that T1a/Ta4 values are assumed to be within a TTI. When
T1a/Ta4 values larger than a TTI are used, this causes two issues:
(1) C-plane packets to be generated later than expected, and
(2) oai_xran_fh_rx_callback() receives the wrong timing information, resulting
in potentially empty/stale PUSCH/PRACH data to be read.
In the xRAN patch, we modify xRAN to make it handle large T1a/Ta4 values properly.
The changes include:
(1) three additional variables in offset_num_slots_* (xran_dev.h),
(2) modify "xran_timing_create_cbs" and "xran_timer_arm_for_deadline"
(xran_cb_proc.c), and
(3) revise "tx_cp_dl_cb" and "tx_cp_ul_cb" (xran_main.c).
Additionally, we add additional guard conditions to prevent xran_tx_proc.c from
sending U-plane packets when it is not a downlink slot.
* 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.
* 5G-S-TMSI construction is defined in 3GPP TS 23.003 and
relevant at both gNB and UE side
* Add helper functions to be later used in NG Paging
* Adopt in NAS UE
In xRAN, it appears that T1a/Ta4 values are assumed to be within a TTI.
When T1a/Ta4 values with larger than a TTI are used, this causes two issues: (1) C-plane packets to be generated later than expected and (2) oai_xran_fh_rx_callback() receives the wrong timing information resulting in potentially empty/stale PUSCH/PRACH data to be read.
In this patch, we modify xRAN to make it handle large T1a/Ta4 values properly.
The changes include: (1) three additional variables in offset_num_slots_* (xran_dev.h), (2) modify "xran_timing_create_cbs" and "xran_timer_arm_for_deadline" (xran_cb_proc.c), and (3) revise "tx_cp_dl_cb" and "tx_cp_ul_cb" (xran_main.c).
Additionally, we add additional guard conditions to prevent xran_tx_proc.c from sending U-plane packets when it is not a downlink slot.
Integration `2026.w05`
* !3850 Update vrtsim timing job thread
* !3853 Clear memory in shm_td_iq_channel after RX
* !3823 Fix RSRP overflow
* !3766 UE support to send CSI report on PUSCH
* !3848 Initial implementation of O-RU for 7.2 emulator
* !3860 NGAP: improve error handling in RRCReconfiguration from Handover Command decoding
* !3507 Create Debian and Redhat packages with CPack
* !3875 Fix FFT size for xran_fh_tx_send_slot_BySymbol() and xran_fh_rx_read_slot_BySymbol()
* !3593 NR UE: add support for multiple RF frontends
* !3769 Add Ethernet PDU session support and make PDU session request configurable
* !3831 semi-manual remove of not used #define commands
* Update RFsim4G UE configs for RFsim changes after !3593
* !3821 [FHI72] [xran F] Handle fragmented (un)compressed packets
* !3732 Implement TS 38.473 transparency for CellGroupConfig forwarding and handle re-establishment on a different DU
* !3880 Prevent the PNF from sending P7 messages after sending a STOP.indication
* !3868 CI: Upgrade Aerial pipeline to 25-3
* Revert one CI XML change after !3732Closes#1045, #837, and #1043
See merge request oai/openairinterface5g!3877
The CI test proved not as stable as expected (because the UE triggers A3
events which we don't want), so revert this functionality while we work
on a new pipeline.
This reverts commit bc62e8abca.
Prevent the PNF from sending P7 messages after sending a STOP.indication
Upon stopping the PNF, when sending the STOP.indication to the VNF, set
pnf_p7->terminate to 1.
Add a check on the PNF P7 send functions to not send a message after
pnf_p7->terminate is set.
This prevents the PNF from sending SLOT.indications after stopping,
which sometimes was causing the VNF to process a SLOT.indication after
it had received the indication to STOP.
Also, this MR adds a sanity check on the VNF P7 message handler to
ignore any P7 messages it receives after having it's own terminate flag
set to 1
This MR closes issue #1045
[FHI72] [xran F] Handle fragmented (un)compressed packets
In both E and F, the radio-transport fragmentation is not supported, and
all the "fragmented" (not seen as fragments in the xran, only as
sections) packets contain "E-bit" equal to 1. Per spec, the value 1 for
"E-bit" signifies the last fragment of one symbol. For more info, please
see "ecpriSeqid" section in the spec.
In E:
- nRBStart and nRBSize is updated according to the sent/received packet;
- max sections = 1;
- when a packet is fragmented, the xran uses memcpy(pos, iq_data_start,
size) function, and nothing is stored in start_prbu , num_prbu ,...
In F:
- nRBStart and nRBSize is only used for C-plane messages;
- nPrbElm represents the number of sections for DL only;
- based on the nPrbElm, each section contains UP_nRBStart and UP_nRBSize
parameters which represent the start and number of PRBs in one section
or one fragment;
- when a packet is fragmented, the xran uses nSecDesc and sec_desc to
extract the packet section content, and the data is stored in
start_prbu , num_prbu ,...
Previous work on the fragmentation in F:
- #884
- !3394 - only increases the XRAN_MAX_FRAGMENT from 4 to 6, since it was
only tested with BFP 8, but not end-to-end unfortunately. But this MR
fixes all the issues.
Tested with VVDN RU, 2x2, 16 bits, 100MHz, 30kHz, MTU <= 9216 B, and
Quectel UE RM520N-GL Revision: RM520NGLAAR03A03M4G.
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
The sufficient number of fragments needed for MTU 1500 and 8b compression is 6.
However, XRAN_MAX_FRAGMENT must be incremented by one (6+1 = 7).
In the MR https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/3394, XRAN_MAX_FRAGMENT was increased to 6,
but the Tx data was actually copied 5 times, and unfortunately I haven't tested end-to-end back then.
This commit was successfully tested with Liteon FR1.
Even though the jumbo frame has 9600 bytes by the spec, the max MTU is limited to the MTU of a switch, if any used.
However, the value can be < max MTU of a switch.
This is very important for fragmentation purposes. If not properly set, the PDSCH packets will be missing.
- increase requirements for Event A3 trigger to avoid unwanted handovers
and allow testing reestablishment on different DUs
- increase ping_packetloss_threshold from 5 to 30 because we are forcing
a reestablishment, thus, packet loss will inevitably happen
- further adjustments to avoid A3 Events
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.
However, the primary purpose of DL RRC MESSAGE TRANSFER is to deliver
the RRC message to the UE. The RRC message delivery is independent of
whether the old UE context can be retrieved. Per TS 38.473, the RRC
message must be delivered to the new UE regardless of old context
retrieval status.
Additionally, per TS 38.331 5.3.7.2 and 5.3.7.4, during reestablishment:
- The UE releases spCellConfig, which must be removed from CellGroupConfig
- SRB1 RLC must be reconfigured with specific parameters
These operations are required for the new UE during reestablishment and
are independent of whether the old UE context can be retrieved.
Fixes:
- Check if old UE context exists before accessing it
- If old UE does not exist, log error and clean up any stale F1 UE data,
but continue to deliver the RRC message
- Restructure code so context transfer only happens when oldUE exists
- Keep GTP-U update and RLC context transfer inside oldUE check (they
require old UE context to exist)
- Move spCellConfig handling and reestablish_rlc flag to execute
regardless during re-establishemnt (per TS 38.331 5.3.7.2)
- Move SRB1 RLC reconfiguration outside the oldUE check so it executes
regardless during re-establishment (per TS 38.331 5.3.7.4)
- Add function documentation and improve spec references in comments
Guido Casati