a2613d5604729957d9aee4eb8511f4348d065040
New LDPC coding library interface for decoding and encoding complete slots in one call to the library Previous attempts to integrate LDPC decoding relying on offloading show the limitation of the original code segment coding interface for the library implementing LDPC coding. In order to perform the offload and therefore the decoding in an optimal fashion, it is relevant to provide the implementation with the broader amount of data possible per call, which is a slot. A previous MR related to T2 offload managed to offer an interface for decoding transport blocks by modifying only nr_ulsch_decoding.c. But this may not be sufficient for performing an efficient decoding in any situation. Slots could be shared between multiple transport blocks in case multiple UEs are connected to the RAN, which makes the transport block size shrink and therefore degrades the efficiency of the offloading. This MR offers a broader interface with a gNB decoding entry point in phy_procedures_nr_gNB.c. The file nr_ulsch_decoding.c now lets the decoding library implement deinterleaving, rate-unmatching and decoding for the slot. In gNB encoding and UE decoding and encoding as well, tasks are partitioned in a similar fashion. As it allows to feed the implementation with the broadest amount of data possible, it allows to fit any coding solution in a library. This will avoid further modification to OAI source code and addition of options to select an implementation when integrating new decoding solutions. An implementation of this interface will therefore be offered for every existing decoding solution in OAI and solutions added in the future will be provided as independent module code without any modification to the core of OAI code. The way to choose the decoding solution and to configure it was also unified using configmodule. The library can be chosen through the option --loader.ldpc.shlibversion. The slot coding solutions shipped with this MR can be configured through configmodule (e.g., T2 address and isolated cores). This MR includes three coding implementations: - A wrapper around segment decoding libraries for test purpose: libldpc.so - A one shot slot coding and encoding with the T2 board: libldpc_t2.so - A decoder on FPGA using the XDMA driver: libldpc_xdma.so Improvements brought by this MR: - Easy integration of a wider variety of LDPC coding solution at gNB and UE - Easy selection of the LDPC coding solution (option --ldpc-offload-enable is kept for now but it can be ultimately removed) - T2: * More efficient when many UEs are connected * Decoding and encoding in nr-uesoftmodem
OpenAirInterface License
It is distributed under OAI Public License V1.1.
The license information is distributed under LICENSE file in the same directory.
Please see NOTICE file for third party software that is included in the sources.
Where to Start
- General overview of documentation
- The implemented features
- System Requirements for Using OAI Stack
- How to build
- How to run the modems
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
.confformat only. - Logs of OAI gNB/DU/CU/CU-CP/CU-UP in
.logor.txtformat 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.
Languages
C
91.8%
CMake
2.9%
C++
1.9%
TeX
1%
Python
1%
Other
1.1%
