This reverts commit 16c333b1a3.
I tried to build everything in Ubuntu images, but
- this introduced a regression (ignores $BUILD_OPTION)
- made that we don't use -Werror (when we should)
I tried to fix the use of the first, but it would involve more changes
than I prefer. On the second, we cannot enable -Werror, as FlexRIC does
not build warning-free (in Release mode). We thus have to build only the
targets that we require, and therefore we can keep using build_oai,
which is the simplest option (cf. the first point).
Integration: `2026.w07`
* !3899 Solving issues caused by invalid RRC configuration
* !3905 Add undocumented Aerial ERROR.indication vendor specific error codes
* !3896 Add fallbacks for ARMv8a to make it compile
* !3734 vrtsim: add CIR DB playback with CLI flags
* !3886 Integrate GPU-Accelerated Channel Simulation + CI Test Pipeline
* !3907 RRC QoS refactor: PDU Session Modify support, SDAP fixes, and code improvements
* !3891 Fix for split 7.2 DU configurations including DU & RU ethernet addresses
* !3913 Remove VCD signal dumper from NR code
* !3783 RRC: Multi-cell handling architecture
* !3916 CI: Rename RAN-SA-2x2-Module-CN5G pipeline
* !3922 Fix and update tracy tag to v0.13.1
* !3917 Fix SRS power computation
* !3915 Cleanup Cmake: remove some double compilation
* !3883 Improvements in handling beamforming inputs
* !3906 fix(ci): remove git reset command from Jenkinsfile
* !3894 Reimplement BladeRF radio driver, make it work for 5G
Closes#845
See merge request oai/openairinterface5g!3908
fix(ci): remove git reset command from Jenkinsfile
- By default, the variable eNB_CommitID is set as 'develop' in the
config
- When OAI-FLEXRIC-RAN-Integration-Test is triggered by upstream FlexRIC
push events, it takes develop
- Triggered by RAN takes commit SHA where origin/SHA does not work
Below are issues seen after this week's merge to develop:
https://jenkins-oai.eurecom.fr/view/RAN/job/RAN-Ubuntu-ARM-Image-Builder/4103/pipeline-overview/?selected-node=44
08:43:07 + git reset --hard origin/9777d23173a740de7cf982659fae13ad6627d3aa
08:43:07 fatal: ambiguous argument 'origin/9777d23173a740de7cf982659fae13ad6627d3aa': unknown revision or path not in the working tree.
When triggered through upstream FlexRIC (as a PUSH Event), it is taking
the branch as shown in the logs:
https://jenkins-oai.eurecom.fr/job/OAI-FLEXRIC-RAN-Integration-Test/3832/pipeline-overview/?selected-node=47
13:45:27 + git reset --hard origin/develop
13:45:27 HEAD is now at 9777d23173 Merge branch 'integration_2026_w06' into 'develop'
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.
Fix SRS power computation
The SRS symbols have been remapped recently in
srs_estimated_channel_freq, and therefore the calculation of the SRS
power has to retrieve the symbols from different positions.
CI: Rename RAN-SA-2x2-Module-CN5G pipeline
RAN-SA-2x2-Module-CN5G performs tests not only with 2x2 but also with a
4x4 MIMO configuration. The pipeline name has been generalized to
RAN-SA-Multi-Antenna-CN5G to cover multiple antenna configurations.
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.
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.
reversing bits is not NR specific. Think of it like this: LTE code might
use reverse_bits*() as well, but in the old location, it would pull in a
bunch of NR dependencies that are superfluous.
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.
Compile all targets in Ubuntu build to avoid breakage of software.
Remove ldd in build dockerfile, as we don't need that (can also be
inspected manually).
- Add more sampling rates to support, e.g., 40MHz in 5G
- Allocate memory only at end to avoid memory leaks in case of failure
- Group recurring configuration functionality in configure_channel() to
reduced code duplication and uniform output
- Read maximum TX gain to set maximum automatically, and analogous to
USRP radio lib
- Check if BladeRF config (buffer size, num transfers, ...) fulfills
requirements as specified in documentation [1]
- Set BladeRF logging early to see BladeRF output
[1] https://www.nuand.com/bladeRF-doc/libbladeRF/v2.6.0/group___f_n___s_t_r_e_a_m_i_n_g___a_s_y_n_c.html#ga72752f2a047b95544e7686596a409abd
Co-authored-by: Brice Robert <robert@eurecom.fr>
Closes: #845
Don't enable radios twice, and only do it on device startup. Simplify
that function by using a new BLADERF_CHECK macro that checks return
codes and that will be reused in the following commits.
There is no reason to not allow
./build_oai -I -w USRP -w BLADERF
To install USRP and BladeRF together (which will be used in the CI in a
later commit). Fix this.
In this case, there are a number of linker errors:
/usr/bin/ld: libL2_NR.a(rrc_gNB.c.o): in function `nr_rrc_transfer_protected_rrc_message':
/home/richie/oai/openair2/RRC/NR/rrc_gNB.c:330:(.text+0x6f6): undefined reference to `signal_rrc_msg'
However, nr_srssim does not need RRC, while it is being linked in. Thus,
link without nr_rrc and L2. For the remaining two linker problems:
- provide a definition of NR_IF_Module_init() as in most other
simulators
- move rrc_get_max_nr_csrs() to nr_common.c. It is already declared in
the corresponding header, and itself does not have anything to do with
RRC radio configuration, therefore it does not belong to
nr_radio_config.c
Fix for split 7.2 DU configurations including DU & RU ethernet addresses
Fix parsing of DU configurations that include both RU and DU ethernet
addresses in the fhi_72 section. The extraneous DU addresses are used in
MPlane to configure the RU.
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)
RAN-SA-2x2-Module-CN5G performs tests not only with 2x2 but also with a 4x4 MIMO
configuration. The pipeline name has been generalized to RAN-SA-Multi-Antenna-CN5G
to cover multiple antenna configurations.
Integrate GPU-Accelerated Channel Simulation + CI Test Pipeline
This MR builds on top of MR !3588 (feat: GPU Accelerated Channel
Simulation Pipeline).
The main portion of the changes is directly taken from MR !3588, and
focuses on integrating the GPU-accelerated channel simulation. On top of
that, this MR adds CI-related configurations to introduce a new channel
simulation testing pipeline into the CI --> RAN-Channel-Simulation
This MR introduces a CUDA-based pipeline to offload the
multipath_channel and add_noise channel simulation functions to the GPU.
This enables large-scale, real-time physical layer simulations not
possible on the CPU.
For full documentation, please see the file at openair1/SIMULATION/TOOLS/DOC/gpu_acceleration.md.
System & Compiler Requirements: An NVIDIA GPU with a compatible driver
and the CUDA Toolkit installed.
This feature was developed and tested on the GH200 server using the GCC
12 toolchain. To ensure reproducibility, building with GCC 12 is highly
recommended. Build Instructions
The primary flag to enable this feature is -DCUDA_ENABLE=ON. The
following command shows a sample configuration used during development
on the GH200 server:
./build_oai --phy_simulators --cmake-opt "\
-DCUDA_ENABLE=ON \
-DUSE_UNIFIED_MEMORY=ON \
-DUSE_ATS_MEMORY=OFF \
-DCMAKE_C_COMPILER=/usr/bin/gcc-12 \
-DCMAKE_CXX_COMPILER=/usr/bin/g++-12 \
-DENABLE_TESTS=ON"
Memory Model Configuration
The pipeline supports multiple CUDA memory management modes, which can
be configured at compile time. ATS Memory (-DUSE_ATS_MEMORY=ON) is
enabled by default. To use another memory model, you must first disable
ATS.
For a detailed explanation of these models, please refer to Section 3 of
the gpu_acceleration.md report.
vrtsim: add CIR DB playback with CLI flags
VRTSIM: CIR DB playback via CLI
This change adds an optional in-process CIR DB path to VRTSIM. When
enabled with --vrtsim.cirdb and optional --vrtsim.cirdb-path, VRTSIM
reads precomputed taps from cir_db.bin. Default behavior is unchanged
when the flag is not set.
Build
cmake ../../ -GNinja -DOAI_VRTSIM_CIRDB=ON -DOAI_VRTSIM_TAPS_CLIENT=OFF
cmake --build . --target vrtsim
How to run
gNB
sudo ./nr-softmodem \
-O ./targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf \
--device.name vrtsim \
--vrtsim.role server \
--gNBs.[0].min_rxtxtime 3 \
--vrtsim.cirdb 1 \
--vrtsim.cirdb-path /home/merkeb/oai-cir-emitter/cir_db.bin
UE
sudo ./nr-uesoftmodem \
-C 3619200000 -r 106 --numerology 1 --ssb 516 --band 78 \
--device.name vrtsim
Expected logs
- VRTSIM prints that channel modelling is active and uses DB backed taps
- CIRDB ready: model=..., shape=Tx x Rx, L=..., S=..., fs=..., dt=...,
speed=...
CLI behavior and fallbacks
- TAPS client and chanmod paths are unchanged
- If --vrtsim.cirdb is not set or equals 0, VRTSIM uses the existing
channel model path
Jaroslava Fiedlerova