Guido Casati 425ea41ba5 fix (Config API): make config integer checks type-correct and add unsigned range validator
Change 1: config_check_intval() now uses the correct integer pointer for TYPE_INT

Problem: config_check_intval() previously dereferenced param->uptr regardless
of param->type. For parameters declared as signed (TYPE_INT / TYPE_INT32), the
active union member is param->iptr, and param->uptr may be NULL -> using uptr
makes validation unsafe and type-inconsistent.

What changed: Updated config_check_intval() behavior (signature unchanged).
Handle both param->type, param->iptr and param->uptr.

Change 1: new config_check_uintrange() for unsigned range constraints

Problem: there was a signed range checker (config_check_intrange()) that reads
param->iptr, but there was no dedicated unsigned range validator using param->uptr.

What changed: added config_check_uintrange() in config_userapi.h/.c
The new function reads param->uptr as uint32_t and validates against
param->chkPptr->s2.okintrange[] endpoints.

Change 3: constify input params for f2 function pointers

Problem: checkedparam_t.s2.f2 was typed with non-const input params, even though
range checks only read. A safer const-safe signature is required.

What changed: s2.f2 now takes const configmodule_interface_t *
and const paramdef_t *. config_check_intrange() and config_check_uintrange() use
the same const-qualified parameters.
2026-04-10 10:22:48 +02:00
2023-08-23 17:15:48 +02:00
2024-10-11 09:12:49 +02:00
2024-03-08 15:53:42 +01:00
2026-04-03 04:14:46 +02:00
2022-10-18 15:24:48 +02:00
2026-04-03 04:14:46 +02:00

OAI

License Supported OS Ubuntu 22 Supported OS Ubuntu 24 Supported OS RHEL9 Supported OS Fedora 43

GitLab Release (custom instance)

Docker Pulls Docker Pulls Docker Pulls Docker Pulls Docker Pulls

OpenAirInterface License

The source code is distributed under CSSL v1.0. Some files, such as for orchestration, are distributed under MIT license(MIT.txt). Documentation is distributed under Creative Commons Attribution 4.0 International license.

All the files without an explicit copyright header have an implicit "Copyright of OpenAirInterface Authors".

Please see NOTICE for other licenses which are used in the software.

In the past OAI source code has been re-licensed sometimes, here is the history:

  1. CSSL v1.0 starting tag 2026.w14
  2. OAI Public License v1.1 starting tag v1.0 till af4b0d53
  3. OAI Public License v1.0: starting tag v.04 till v1.0
  4. GPL 3: starting tag v.0 till v.04 (only initial implementation of 4G)

Where to Start

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 .conf format only.
  • Logs of OAI gNB/DU/CU/CU-CP/CU-UP in .log or .txt format 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.

S
Description
No description provided
Readme
379 MiB
Languages
C 91.8%
CMake 2.9%
C++ 1.9%
TeX 1%
Python 1%
Other 1.1%