- all RAN code, CI code, configuration files, dockerfiles, in CSSL v1.0
- all deployment code (openshift, charts, ancillary files like shell
scripts), in MIT
- documentation in CC-BY-4.0
- exceptions might apply and are listed in NOTICE
- there is a new LICENSES folder with all licenses
- CONTRIBUTIONS.md has been updated accordingly
For automated changes based on OAI PL v1.1:
perl -i~ -0pe 's/\/\*.*Licensed to the OpenAirInterface.*openairinterface.org\n#?/\/*\n * SPDX-License-Identifier: LicenseRef-CSSL-1.0\n/s' **/*.{c,h,cpp}
perl -i~ -0pe 's/\/\*.*Licensed to the OpenAirInterface.*openairinterface.org\n#?/\/*\n * SPDX-License-Identifier: LicenseRef-CSSL-1.0\n/s' **/*.ts
perl -i~ -0pe 's/<!--.*Licensed to the OpenAirInterface.*openairinterface.org\n.*-->/<!-- SPDX-License-Identifier: LicenseRef-CSSL-1.0 -->/s' **/*.xml
The rest (cmake, files with missing license, cmake) manually.
Fix Delta MCS mode, reimplement UL power control
This change set fixes the "delta-MCS" mode, and reimplements the UL power
control loops at gNB, i.e., for PUSCH and PUCCH. It further adds new T traces
to log PUSCH/PUCCH power infrmation, and cleans up code.
The "delta-MCS" mode in OAI refers to configuring a UE with deltaMCS in the
PUSCH-PowerControl IE (see TS 38.331). In this mode, the UE adjusts the PUSCH
power for transmissions to take into account for MCS (see TS 38.213 Sec. 7.1).
In other words, the target SNR can be set to a somewhat low value, and the UE
will still use the right power for UL transmissions. Note that the spec only
foresees this adjustment of UL power when using one layer. In contrast, in the
"normal" mode, the gNB sends TPC commands to keep a UE at a fixed target SNR
(default: 20dB), regardless of the MCS or number of layers. Future work is
planned to completely remove this fixed target SNR, which is not done in this
MR yet.
Further, there is a new power control loop implementation. Prior to this MR, on
each UL transmissions, the gNB uses the SNR to decide about TPC sent to a UE in
the next transmissions. The new implementation relies on averaging the SNR, and
a "TPC in flight" average to account for the slow reaction of the average SNR.
The sum of both quantities is the current SNR that is used by the UE. See the
commit messages or documentation for more information.
Further cleanup to group data (e.g., power control configuration, refactoring of
code to save space, ...) is done. Two new T traces GNB_MAC_PUSCH_POWER_CONTROL
and GNB_MAC_PUCCH_POWER_CONTROL are added; documentation exists to explain how
to graphically plot corresponding graphs.
Introduce UE NAS Simulator
This MR introduces a simple standalone tester for 5G UE NAS signaling and NGAP
messages. It connects to the AMF to perform NGAP and NAS encoding/decoding and
validates the UE Registration and PDU Session Establishment processes without
the overhead of a full Radio Access Network (PHY/MAC/RLC).
The motivation for this tester is as follows,
- This tester is a lightweight, deterministic tool to test the UE NAS layer
directly.
- Developers can easily inject specific NAS messages depending on the use-case.
- Developers can validate custom NAS/NGAP messages without the need to implement
complete RRC/MAC etc procedures.
Start the 5G Core network to test the UE NAS simulator. The compiling and
testing procedure is described below.
To compile:
mkdir build && cd build && cmake .. -GNinja && ninja nr-ue-nas-simulator-test
To run:
LD_LIBRARY_PATH=. ./tests/nr-ue-nas-simulator/nr-ue-nas-simulator-test -O ../tests/nr-ue-nas-simulator/test.conf
Remove old CUDA LDPC implementation
A new implementation is under way in !3955. To simplify the MR, remove the old
LDPC CUDA implementation in a first step.
Introduce new data structures to track the average SNR and RSSI, and
that allow to dynamically modify the target SNR (per UE) as well as
continuously get TPC updates based on the average SNR. The target SNR is
per power control loop (which a future commit will extend to use for
PUCCH).
Concretely, it maintains an average of measured SNR and RSSI. It also
updates "tpc_in_flight", which tracks TPC changes that don't show up in
the average yet. For instance, imagine that the target SNR of 15 changes
to 20. Three successive TPC commands need to be sent (+3, +1, +1), but
it will take time to show up in the average SNR. To account for this,
tpc_in_flight is updated by the TPCs sent, and an average will make it
go down back to zero at the same pace as the average SNR approaches the
target SNR. The sum of average SNR and tpc_in_flight sums up to the
actual, current SNR, which approximates the target SNR.
The SNR is kept within -1<=targetSNR<=+2dB to avoid too many TPC
changes.
The current average SNR (sum of average SNR and tpc_in_flight) is used
to continuously get TPC updates, taking into account recent TPCs sent,
the difference to target SNR, and RSSI.
If there is DTX, tpc_in_flight is modified to artificially introduce TPC
commands which increase the currently used SNR of the UE. This is
temporary, as tpc_in_flight eventually will go back to zero. If the DTX
was due to sudden SNR drop (e.g., higher path loss), this will allow to
quickly adapt the UE's SNR to new conditions.
The periodical logs are extended to not only show the current SNR, but
also the difference from the target for better analysis.
Co-authored-by: Maxime Elkael <m.elkael@northeastern.edu>
* Option to build ldpc_cuda was remaining in the build script
* Build script option to build ldpc_cuda was still used in CI
* Mentions of ldpc_cuda were remaining in the documentation
Note: In the documentation, the example of ldpctest usage that was
loading ldpc_cuda was replaced by an example in which it is loading
ldpc_orig even though this is pointless as it makes ldpctest compare
ldpc_orig with ldpc_orig. On the other hand, it is the only library
other than the default ldpc that uses the former interface.
Remove OSD, some scripts, oaisim references
The README says:
It is just generating the XML file and it is placing it in
$(OPENAIR_TARGETS)/SIMU/EXAMPLE/OSD/WEBXML/ or http://localhost/xmlfile/
so that the oaisim could pars and run the simulation/emulation
oaisim does not exist anymore, and corresponding simulation cannot be done.
Also, it requires XAMPP and similar technologies, that I think nobody uses
in the context of OAI.
Remove also most references to oaisim.
Remove some scripts that are likely not used by anybody, or straight useless.
Adjust ssPBCH_BlockPower in FHI7.2 configs
ssPBCH_BlockPower is the average EPRE of the resources elements that carry
secondary synchronization signals in dBm. In OAI, the SSB is the same level
as all the rest, so we can compute ssPBCH_BlockPower from RU TX power and
bandwidth using:
ssPBCH_BlockPower = P_TX(dBm) − 10 x log10(N_RB x 12)
where:
- P_TX is the RU transmit power
- 24 dBm for indoor RUs (configurable on the RU)
- 35 dBm for outdoor RUs (configurable on the RU)
- N_RB is the number of resource blocks for the configured bandwidth
- 12 corresponds to the number of subcarriers per RB
[FHI72] Fix long PRACH format
The problem was that xran_is_prach_slot() compared if the current slot is the
scheduled one. However, this becomes irrelevant if long PRACH format used.
Successfully tested end-to-end the PRACH index 7 with TDD DDDDDDDSUU and Benetel
v2.0.5.
Fix for NTN phy-test mode
- Corrected the initialisation of ntn params changed flag. Before this change on
UE, Phy-test was not running in NTN mode.
- Removed the assert wrt slot > 64 to run FR2-NTN in phy-test
- SIB2, 19 required only in SA mode like SIB1
- Introduced new method to schedule a slot in UL/DL in Phy-test mode. Dmod/ Umod
option in the command line with a value.
- This ensures that the slot n (in slots per frame) will be scheduled if
n % value == 0
- For ex: --Dmod 1 means every slot will be scheduled
- --Dmod 2 means every 2nd slot will be scheduled, like 0,2,4,6 until the
slots per frame 1.
- this can be used for testing FDD FR2 where slots go beyond 64 which is a
limitation of -D/-U option.
Only static long PRACH configuration verified, i.e. PRACH C-plane
is ignored by the RU.
Note: Introducing `N_ZC` and `num_prbu` parameters is needed for testing
with xran F release. However, in the K release, this information is
stored in xran_rx_packet_ctl struct.
Synchronize multiple gNBs by aligning the slot boundaries
Currently, we derive frame and slot number based on proc->timestamp_rx
using
proc->frame_rx = (proc->timestamp_rx / (fp->samples_per_subframe*10))&1023;
proc->tti_rx = get_slot_from_timestamp(proc->timestamp_rx, fp);
This ignores the samples
proc->timestamp_rx % fp->samples_per_frame
while computing the frame and slot number creating a mis-alignment with
the slot boundaries. A detailed description of the slot misalignment
in a pictorial representation can be seen in an attachment in the MR [1].
We fix this alignment issue by compensating these samples during the
first reception.
We can test the synchronization of the multiple gNBs from the estimated
ToAs from the PRS in the Downlink and the estimated ToAs from the SRS in
the Uplink using rfsim.
In order to test this, make sure you build gNB and nrUE along with the
telnetsrv flag using the option --build-lib telnetsrv.
Also, enable the following log in the function
nr_est_srs_timing_advance_offset() in
openair1/PHY/NR_ESTIMATION/nr_measurements_gNB.c to observe SRS ToAs
LOG_I(NR_PHY, "SRS estimatd ToA %d [RX ant %d]: TA offset %d, TA offset ns %d (max_val %ld, mean_val %ld, max_idx %d)\n", srs_toa, ant, *ta_offset, *ta_offset_nsec, max_val, mean_val, max_idx);
Furthermore, update the option Active_gNBs = 2; in
targets/PROJECTS/GENERIC-NR-5GC/CONF/ue.nr.prs.fr1.106prb.conf to enable
decoding PRS transmitted from two gNBs
To run:
nrUE:
sudo ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3619200000 --uicc0.imsi 001010000000001 --rfsim --phy-test -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/ue.nr.prs.fr1.106prb.conf --rfsimulator.serveraddr server
gNB 0:
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb0.prs.band78.fr1.106PRB.usrpx310.conf --gNBs.[0].min_rxtxtime 6 --rfsim --phy-test --rfsimulator.[0].serveraddr 127.0.0.1 --rfsimulator.[0].options chanmod --rfsimulator.[0].modelname AWGN --telnetsrv
gNB 1:
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb1.prs.band78.fr1.106PRB.usrpx310.conf --gNBs.[0].min_rxtxtime 6 --rfsim --phy-test --rfsimulator.[0].serveraddr 127.0.0.1 --rfsimulator.[0].options chanmod --rfsimulator.[0].modelname AWGN --telnetsrv
When we run the nrUE, gNB0 and gNB1, we can see the following logs
nrUE:
[PHY] [gNB 0][rsc 0][Rx 0][sfn 976][slot 2] DL PRS ToA ==> 0.0 / 2048 samples, peak channel power -16.4 dBm, SNR +4.0 dB, rsrp -42.2 dBm
[PHY] [gNB 1][rsc 0][Rx 0][sfn 976][slot 3] DL PRS ToA ==> 0.0 / 2048 samples, peak channel power -16.4 dBm, SNR +4.0 dB, rsrp -42.2 dBm
gNB 0:
[NR_PHY] SRS estimatd ToA 0 [RX ant 0]: TA offset 31, TA offset ns 0 (max_val 99820162, mean_val 80176, max_idx 0)
gNB 1:
[NR_PHY] SRS estimatd ToA 0 [RX ant 0]: TA offset 31, TA offset ns 0 (max_val 98784562, mean_val 79369, max_idx 0)
From the above logs, when we run the rfsim and when no delays introduced, we can observe the following results
In the Downlink at the UE, the estimated ToAs using PRS from both gNB0
and gNB1 are 0 and in the uplink, the ToA estimated from the SRS
transmitted by the UE at both the gNBs are also 0. This indicates that
both the gNBs are synchronized along with their slot boundaries. We also
highlight that this is not the case in the current develop branch since
the slot boundaries are not aligned.
We also can test the multi gNB synchronization by introducing delays
using telnet as follows,
Introduce new_offset (delay) of 4 samples to the gNB 0 from UE in the
uplink as follows,
openairinterface5g$ echo rfsimu setdistance rfsimu_channel_enB0 20 | ncat --idle 1 127.0.0.80 9080
softmodem_gnb> rfsimu_setdistance_cmd: new_offset 4, new (exact) distance 19.518 m, new delay 0.000065 ms
Ncat: Idle timeout expired (1000 ms).
We can oberve this delay of 4 samples being reflected in the estimated
SRS ToAs at gNB 0 while not changing the ToA in gNB 1
[NR_PHY] SRS estimatd ToA 4 [RX ant 0]: TA offset 31, TA offset ns 65 (max_val 98803636, mean_val 79430, max_idx 8)
similarly, Introduce new_offset (delay) of 2 samples to the gNB 1 from
UE in the uplink as follows,
openairinterface5g$ echo rfsimu setdistance rfsimu_channel_enB0 10 | ncat --idle 1 127.0.0.81 9081
softmodem_gnb> rfsimu_setdistance_cmd: new_offset 2, new (exact) distance 9.759 m, new delay 0.000033 ms
Ncat: Idle timeout expired (1000 ms).
We can oberve this delay of 2 samples being reflected in the estimated
SRS ToAs at gNB 1 while not changing the ToA in gNB 0
[NR_PHY] SRS estimatd ToA 2 [RX ant 0]: TA offset 31, TA offset ns 32 (max_val 98962768, mean_val 79552, max_idx 4)
Closes#897
[1] https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/3892
[FHI72] Remove support for xran E release
All the use cases we tested with E release are working end-to-end with F release.
The near future plan is to support K release which is ongoing in the MR !3444.
All the use cases we tested so far, are supported with xran F release.
Therefore, we can proceed with removing the support with E release.
In addition, our plan is to bring the support for K release which is ongoing activity in
the MR https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/3444.
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.
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.
- Change gNB RRC enable_sdap default to true
- Update RRC and RUNMODEM docs to reflect new default behavior
- Clean up CI gNB configs by removing redundant enable_sdap=1
- Keep explicit SDAP disable config for NFAPI gNB VNF
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.
- Delete drbs field from gNB_RrcConfigurationReq and its use in RCconfig_NRRRC()
- Remove GNB_CONFIG_STRING_DRBS, help text, index, and GNBPARAMS_CHECK entry from gnb_paramdef.h
- Drop DU-side verification and DRB count logging in gnb_config.c
Expand RRC developer and usage documentation to match the current
multi-cell design with separate DU and cell management.
- rrc-dev.md: Document DU and cell data structures and key functions
(get_du_by_assoc_id, get_cell_by_cell_id, rrc_add_cell_to_du, etc.);
add DU and cell lifecycle (F1 Setup, config update, disconnection)
and UE cell association (serving cells, PCell/SCells) with sequence
diagrams; add handover and cell association update flow; update UE
context description.
- rrc-usage.md: Update DU/cell list output format and description
(e.g. integrated DU-CU) and multi-cell per DU wording.
Robert Schmidt