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).
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).
Update RHEL UBI image source to registry.redhat.io
This merge request updates the RHEL UBI base image source to registry.redhat.io,
aligning with Red Hat’s supported container registry and avoiding potential
access or availability issues with registry.access.redhat.com.
Add Ethernet PDU session support and make PDU session request configurable
This MR adds support for Ethernet PDU sessions, and makes PDU sessions
configurable: per-PDU session ID, type (IPv4/IPv4v6/IPv6/Ethernet [1]),
DNN, NSSAI.
Concretely, it adds a new configuration file section pdu_sessions below
uicc0 that looks like this if everything is specified (default values
are shown):
uicc0:
[...]
pdu_sessions:
- id: 1
type: "IPv4"
nssai_sst: 1
nssai_sd: 0xffffff
dnn: "oai"
It is possible to list multiple PDU sessions (add new line - id: 2 to
request a second PDU session). It is backwards-compatible to the current
PDU session configuration (uicc0.dnn/nssai_sst/etc), the idea being that
either legacy or new configuration could be used, but (1) if
pdu_sessions exist, it will overwrite the legacy configuration, and (2)
multiple PDU sessions, and type, can only be configured using the new
config. The old parameters --extra-pdu-id and --default-pdu-id are not
accepted anymore. Documentation has been added to the UE tutorial.
It is possible to test an Ethernet PDU session [1]. It is possible to
test the PDU session inside the UE by verifying it has an TAP interface
oaitap_ue1, and ARPing the data network (arping has been added to
oai-nr-ue container for that purpose):
ip addr add 192.168.72.140/26 dev oaitap_ue1 # same subnet as data network!
ip link set dev oaitap_ue1 up
arping -c 20 -I oaitap_ue1 192.168.72.135 # will send ARP request in Ethernet frame to get IP address of data network
[1] See description MR !3769 for more information. On the UE side, only
the type has to be changed to "Ethernet".
The CN team would like to test the ethernet PDU session capabilities of
the UPF. Install arping in the UE by default for ubuntu to help them
test the PDU session by pinging over ARP.
CI: Enable Physim threshold check for tests on Caracal and GH
This MR adds support for configurable timing threshold files in PhySim
tests.
- Introduces a new CMake cache variable PHYSIM_CHECK_FILES to specify
one or more timing threshold files (semicolon-separated).
- Enables optional enforcement of timing thresholds check in PhySim
tests without changing existing test definitions.
- Defines timing thresholds for LDPC encoding/decoding in nr_ulsim,
nr_dlsim and ldpctest on Caracal and GH machines.
Add missing timinig analysis scripts to RHEL9 physim docker image. These files
are now copied from the build stage to /oai-ran/openair1/SIMULATION/tests/,
where they are expected by ctest.
Resolves following issue when running ctest in docker container:
CMake Error: Error processing file: /oai-ran/openair1/SIMULATION/tests/RunTimedTest.cmake
Most (but not all) physical simulators are defined under
openair1/SIMULATION/. Defining physical simulators below there seems to
be the more "obvious" directory anyway, as the physical simulators are
openair1/SIMULATION/tests
Phy(L1) Sim tests => PhySim (tests)
Redirect to files and manual analysis as done in this Dockerfile is not
necessary since we just output all relevant build files to stdout.
Simplify to do the same here.
See: 35361db76b ("build_oai: don't redirect compilations to a file")
Improve MAC docs for MCS and docker for BuildKit usage
See commits for details. The first one is for fixing an omission in
!3281, the second to clarify docker build usage.
Closes: #973
The Dockerfiles are reused for building on different architectures
(amd64/arm64). They differ, though, on some steps for downloading or
installing platform-specific utilities.
This is handled automatically when using BuildKit, which is the default
in docker versions v23.0+. Older docker versions require some special
settings. Explain this in the README.
Closes: #973
As DEBIAN_FRONTEND has been set as environment variable, there is no need to use DEBIAN_FRONTEND=noninteractive inside RUN lines, it is redundant, hence it has been removed.
Libboost went from 1.74.0 to 1.83.0 alongside Ubuntu update.
GCC version is set as default to be more practical.
In Ubuntu22, apt sources were in .list files, in Ubuntu24 they are in .sources files.
Add --break-system-packages for pip installation to use same logic as before, see the pip update 23.0.1 (2023-02-17).
With Ubuntu24 liboai_device requires libpython3.12
Refactor F1 UE context messages, add unit tests
Add encoder+decoder+util functions for F1 UE context messages, and use
them in the stack. The overall goal is to unit test encoder+decoder (to
be sure that what we send is what we receive), and remove any memory
leaks related to F1 handling. Messages that have a unit test:
- F1 UE context setup request/response
- F1 UE context modification request/response
- F1 UE context release request/command/complete
This MR removes almost all remaining memory leaks that are observable in
a "standard" configuration, running SISO in RFsim. In RFsim (without
channel modelling), there are only two memory leaks shown in asan, one
in L1, and one in NGAP.
Speed up docker deployment in CI
- Using docker compose up --wait instead of a custom healthcheck script:
from: https://docs.docker.com/reference/cli/docker/compose/up/
--wait Wait for services to be running|healthy. Implies detached mode.
--wait-timeout Maximum duration in seconds to wait for the project to be running|healthy
- Speeding up the healthchecks by reducing the interval from 1-10s to
0.5s during start period
start_period creates a special period after the start of the container
where the healthcheck is executed every start_interval . During this
time the failures do not count towards the retries counter, but
successes change the status to healthy. This allows container to reach
healthy status much sooner.
- Using init: true to speed up docker compose down/stop
`init: true` initializes the docker container with tini or
alternative: tini is used to collect all the processes and correctly
pass the termination signal to them. This allows the docker container
to be stopped without waiting 10 seconds to kill the container
- Smallest example of this is:
services:
test-init:
image: ubuntu:jammy
command: sleep 10d
This modification aims to improve health status detection by using PRACH IO as
an indicator of the gNB's status (container is marked as "healthy" when the
PRACH IO value in gNB nrL1_stats.log exceeds 0.0 dB.). The new condition accounts
for scenarios where the container may not exit or produce error codes (e.g.,
“sleep” logs or "error code overflow" messages).
CI: Upgrade Aerial version to 25-1
- Update the Nvidia L1 (cuBB) from version 24-3 to 25-1
- Decrease the number of cores dedicated to the OAI gNB; testing showed
it does not need that many
- This is to avoid the Docker image builder from being confused in case we have multiple nvIPC files in `/opt/nvidia-ipc`
- This occurs when we have an MR to upgrade the cuBB image
Set the CMAKE_RUNTIME_OUTPUT_DIRECTORY CMake option during the OAI build
to control the location of runtime target files. This ensures that ctest
can locate necessary executables after they are copied to the target
Docker image.
Add --allowerasing, which will downgrades some packets in order to
satisfy LLVM dependencies.
When building the docker image for clang, CI fails with
Error:
Problem: llvm-18.1.8-3.el9.i686 from ubi-9-appstream-rpms does not belong to a distupgrade repository
- package llvm-toolset-18.1.8-3.el9.x86_64 from ubi-9-appstream-rpms requires llvm = 18.1.8, but none of the providers can be installed
- package llvm-18.1.8-3.el9.x86_64 from ubi-9-appstream-rpms requires llvm-libs(x86-64) = 18.1.8-3.el9, but none of the providers can be installed
- package llvm-18.1.8-3.el9.x86_64 from ubi-9-appstream-rpms requires libLLVM.so.18.1()(64bit), but none of the providers can be installed
- package llvm-18.1.8-3.el9.x86_64 from ubi-9-appstream-rpms requires libLLVM.so.18.1(LLVM_18.1)(64bit), but none of the providers can be installed
- cannot install both llvm-libs-18.1.8-3.el9.x86_64 from ubi-9-appstream-rpms and llvm-libs-19.1.7-2.el9.x86_64 from @System
- package mesa-dri-drivers-24.2.8-2.el9_6.x86_64 from @System requires libLLVM.so.19.1()(64bit), but none of the providers can be installed
- package mesa-dri-drivers-24.2.8-2.el9_6.x86_64 from @System requires libLLVM.so.19.1(LLVM_19.1)(64bit), but none of the providers can be installed
- package mesa-libGL-24.2.8-2.el9_6.x86_64 from @System requires libgallium-24.2.8.so()(64bit), but none of the providers can be installed
- package mesa-libGL-24.2.8-2.el9_6.x86_64 from @System requires libgallium-24.2.8.so(libgallium-24.2.8.so)(64bit), but none of the providers can be installed
- package mesa-libGL-devel-24.2.8-2.el9_6.x86_64 from @System requires mesa-libGL(x86-64) = 24.2.8-2.el9_6, but none of the providers can be installed
- conflicting requests
- problem with installed package mesa-libGL-devel-24.2.8-2.el9_6.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
So when trying to install llvm-toolset from docker/Dockerfile.clang.rhel9,
we have a conflict because this installs 18.1 from ubi-9-appstream-rpms,
but various mesa packets have llvm 19.1.
1. I don't understand why we have mesa installed (no graphics system?)
2. --allowerasing downgrades the relevent mesa package(s)
Alternatively, we would need to select 19.1 when installing
llvm-toolset, but I don't know how to do that.
Dockerfiles hardcoded one copy operation to x86; generalize to capture
ARM as well. Since the target directory cannot have any globs, we need
to manually check the right directory, then move the file.
Note that this is only necessary since we are forced to switch the
compiler, as Ubuntu's default gcc-11 does not work with FlexRIC. When
upgrading to Ubuntu 24, these lines should disappear and asan be
installed as normal. See commit 94497435e7 ("Upgrade CI images to
Ubuntu 22").
Fronthaul xran library update to F release (2. and final step towards M-plane integration)
- xran library support -> both E and F releases
- RU delay profile removed -> not used in neither of the releases
- DU delay profile updated
- one-way delay measurements support is improved/fixed in the F release.
However, not implemented here as it depends on the RU capabilities
