Guido Casati
e1dd62df53
Problem: During N2 handover with integrity protection (NIA1/NIA2), the target gNB was disabling ciphering when configuring SRB1 security, while the UE continued using the old security context from the source gNB until it received and processed the RRC Reconfiguration with masterKeyUpdate. The first PDUs sent after CFRA were still ciphered with the old keys, but the target gNB had ciphering disabled, causing it to skip deciphering and attempt integrity verification on ciphered data, leading to MAC-I mismatches and integrity failures. Specification Reference: According to TS 33.501 section 6.11, "the UE shall keep the K gNB used in the source cell until the handover or a connection re-establishment has been completed successfully". This means the UE continues using the old security context (old KRRCint, KRRCenc) until it receives and processes the RRC Reconfiguration with masterKeyUpdate. The target gNB must therefore enable ciphering during handover setup to correctly decipher and verify integrity of PDUs sent with the old security context before the UE switches to the new keys. Root Cause: The code was calling nr_rrc_pdcp_config_security(UE, false) during handover setup, which disabled ciphering. This was incorrect because: 1. The UE already has security active from the source gNB 2. The UE continues using old ciphered keys until masterKeyUpdate 3. The UE sends ciphered PDUs immediately after CFRA succeeds 4. The target gNB must be able to decipher these PDUs to verify integrity Why it only manifested when drb_integrity = "yes": The bug was always present, but only caused visible failures when integrity verification was enabled. When drb_integrity = "no", the config typically also sets integrity_algorithms to only NIA0, resulting in UE->integrity_algorithm = 0, which causes has_integrity = 0 for SRB1, skipping integrity verification and hiding the underlying ciphering bug. When drb_integrity = "yes", integrity_algorithms typically includes NIA1/NIA2, resulting in has_integrity = 1 for SRB1, causing integrity checks to run on ciphered data and fail. Fix: Change nr_rrc_pdcp_config_security(UE, false) to nr_rrc_pdcp_config_security(UE, true) during handover setup to enable ciphering immediately, allowing the target gNB to correctly decipher and verify integrity of PDUs sent with the old security context. Note: This fix is specific to handover. During initial context setup, ciphering should remain disabled until SecurityModeComplete is received, as the UE hasn't activated ciphering yet at that point.
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.