84a49e93adb00933835736c25741a2d3e1c5a31b
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
OpenAirInterface License
It is distributed under OAI Public License V1.1.
The license information is distributed under LICENSE file in the same directory.
Please see NOTICE file for third party software that is included in the sources.
Where to Start
- General overview of documentation
- The implemented features
- System Requirements for Using OAI Stack
- How to build
- How to run the modems
Not all information is available in a central place, and information for specific sub-systems might be available in the corresponding sub-directories. To find all READMEs, this command might be handy:
find . -iname "readme*"
RAN repository structure
The OpenAirInterface (OAI) software is composed of the following parts:
openairinterface5g
├── charts
├── ci-scripts : Meta-scripts used by the OSA CI process. Contains also configuration files used day-to-day by CI.
├── CMakeLists.txt : Top-level CMakeLists.txt for building
├── cmake_targets : Build utilities to compile (simulation, emulation and real-time platforms), and generated build files.
├── common : Some common OAI utilities, some other tools can be found at openair2/UTILS.
├── doc : Documentation
├── docker : Dockerfiles to build for Ubuntu and RHEL
├── executables : Top-level executable source files (gNB, eNB, ...)
├── maketags : Script to generate emacs tags.
├── nfapi : (n)FAPI code for MAC-PHY interface
├── openair1 : Layer 1 (3GPP LTE Rel-10/12 PHY, NR Rel-15 PHY)
├── openair2 : Layer 2 (3GPP LTE Rel-10 MAC/RLC/PDCP/RRC/X2AP, LTE Rel-14 M2AP, NR Rel-15+ MAC/RLC/PDCP/SDAP/RRC/X2AP/F1AP/E1AP), E2AP
├── openair3 : Layer 3 (3GPP LTE Rel-10 S1AP/GTP, NR Rel-15 NGAP/GTP)
├── openshift : OpenShift helm charts for some deployment options of OAI
├── radio : Drivers for various radios such as USRP, AW2S, RFsim, 7.2 FHI, ...
├── targets : Some configuration files; only historical relevance, and might be deleted in the future
└── tools : Tools for use by the developers/ci machines: code analysis and formatting
How to get support from the OAI Community
You can ask your question on the mailing lists.
Your email should contain below information:
- A clear subject in your email.
- For all the queries there should be [Query] in the subject of the email and for problems there should be [Problem].
- In case of a problem, add a small description.
- Do not share any photos unless you want to share a diagram.
- OAI gNB/DU/CU/CU-CP/CU-UP configuration file in
.confformat only. - Logs of OAI gNB/DU/CU/CU-CP/CU-UP in
.logor.txtformat only. - In case your question is related to performance, include a small description of the machine (Operating System, Kernel version, CPU, RAM and networking card) and diagram of your testing environment.
- Known/open issues are present on GitLab, so keep checking.
Always remember a structured email will help us understand your issues quickly.
Languages
C
91.8%
CMake
2.9%
C++
1.9%
TeX
1%
Python
1%
Other
1.1%
