- 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.
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.
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.
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.
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.
Even though the jumbo frame has 9600 bytes by the spec, the max MTU is limited to the MTU of a switch, if any used.
However, the value can be < max MTU of a switch.
This is very important for fragmentation purposes. If not properly set, the PDSCH packets will be missing.
- Remove multiple single top-level (# H1) headings per file
- Use (# H2 and ###### H6) sub-headings for consistency
- Remove any trailing # in the headings
- This ensures proper table of contents rendering in MkDocs.
- Also removed RUN_NR_multiple_BWPs.md as it is moved to MAC usage
Performance Management support explanation.
Example run modified according to:
- modification of the frequency offset, frame structure, fft size, cyclic prefix, and Tx gain;
- addition of the managed delay node;
for Tx/Rx endpoints.
As per CUS spec, the MTU can be 1500 or 9000 B, where MTU = IQ data format.
Packet length = ethernet header + RTE_PKTMBUF_HEADROOM + MTU
However, xran assumes different definitions of the MTU:
(1) in xran_init_mbuf_pool(): MTU = ethernet header + IQ data format;
(2) in xran_get_num_prb_elm(), xran_init_PrbMap_from_cfg(), xran_init_PrbMap_from_cfg_for_rx(), xran_init_PrbMap_by_symbol_from_cfg(): MTU = complitely wrong (as the IQ data format is not well included).
Additionally, xran assumes that the max MTU 9600 B, instead of 9000 B as per spec.
Nevertheless, I left 9600 B in all config files and docs due to wrong calculation of (2) for the total number of PRBs per fragment.
1. Closes#884 - increase the XRAN_MAX_FRAGMENT from 4 to 6 (sufficient for MTU 1500 with compression 8b)
2. Add new firmware version that supports jumbo frames
3. Update the config file to align with the new Liteon unit in our lab - center frequency, jumbo frames, compression and RU MAC address,
as well as the max DL MIMO layers.
After capturing the FH packets, we observed that the RU supports the MTU value for jumbo frames.
Therefore, no fragmentation needed on DL.
Co-authored-by: Teodora Vladic <teodora.vladic@openairinterface.org>
FHI72: Management plane support
At the moment, tested with Benetel 550 and 650 RUs FW v1.2.2
- support for multiple RUs
- RPCs implemented: <connect>, <subscribe>, <get>, <supervision-watchdog-reset>,
<edit-config>, <validate>, <commit>, <disconnect>
- read PTP sync status from operational datastore xml
- get vendor name, and for xran store RU MAC, MTU and IQ bitwidth and PRACH
offset, and transfer this info
- store interface name, low-level-tx/rx-endpoint names, tx/rx-carrier names,...,
from operational datastore xml
- add reference gNB/DU config files with M-plane support
- update FHI readme
- This addition is based on past tests, iperf3 UDP throughput was 520Mbps DL and 40Mbps UL.
- Throughput degrades when using OAI L1 with tags beyond `2024.w30`.
- This RU is being CI tested only in the Aerial pipeline, not with OAI L1.
- The document will be updated once the issue is identified and fixed.
xran_fh_rx_read_slot() uses polling (a loop over cnt++) to wait for the
next frame/slot. The reasons I have been told is "it does not work
differently", or "there are real-time problems". None of those seem to
be true; by default disable polling, and use the queue instead.
It is possible to enable polling with the cmake option
OAI_FHI72_USE_POLLING=ON. Documentation has been updated to inform about
this change.
In DPDK, IO Virtual Addresses (IOVA) refers to the memory addressing
scheme used for IO operations. The two IOVA modes supported by DPDK are:
- IOVA as Physical Address (PA): IO memory addresses correspond directly
to physical addresses, no address translation required.
- IOVA as Virtual Address (VA): IO memory addresses align with user-space
virtual addresses, requiring IOMMU to remap physical memory.
Previously, this was hardcoded to 0, to use IOVA as PA mode, with xRAN's
DPDK EAL initialization using the "--iova-mode=pa" flag.
This commit introduces a gNB configuration option to allow users to select
the desired IOVA mode. The default remains PA mode to
ensure backward compatibility.
Using IOVA VA mode allows DPDK to run without requiring SYS_ADMIN
capability in the docker container.
xran has a mechanism to request DPDK to allocate a configurable amount
of bytes for huge pages. We set it to 0 until now; expose this variable
through configuration, and provide a meaningful default 8192 MiB.
Provide documentation.
The correct order for xran seems to be first Uplane, then C plane. In
the past, we used to switch (for reasons I don't know), but let's
reverse it to the proper order.
Jaroslava Fiedlerova