Robert Schmidt
35a450bd43
Refactor SDAP adaptation work for QoS This MR is an adaptation of the code introduced in !2703. The goal is a cleanup and functional refactor of the SDAP/PDCP integration, that is: - centralize SDAP configuration logic - simplify entity creation - improve robustness of role-based SDAP handling - prepare the codebase for clean support of DRB reconfiguration and teardown flows More concretely: 1. New sdap_config_t and get_sdap_Config() - Introduced an internal struct sdap_config_t to abstract SDAP config input - Centralized SDAP config parsing into new get_sdap_Config() function that translates ASN.1 NR_SDAP_Config into this internal representation. This is called during RRC triggered (re)configuration procedures. - Enable mapping of number of QoS flows > 1 2. Unified role handling with bitmasks - Added a bitmask-based entity_role field to track SDAP directions: SDAP_UL_RX, SDAP_UL_TX, SDAP_DL_RX, SDAP_DL_TX: header presence was determined by simple direction (UE vs gNB) and individual is_sdap_rx/tx() checks, however nr_sdap_rx_entity behaves differently depending on the direction of the RX entity (DL/UL), therefore this change can help enable a more accurate SDAP header handling across directions and node types. - Replaces old helpers is_sdap_rx() / is_sdap_tx() with internal checks against the role bitfield - QFI-to-DRB mapping is now annotated with direction for both data and control PDUs 3. Simplified DRB and SDAP setup - add_drb() in PDCP API now delegates SDAP config processing cleanly - new_nr_sdap_entity() is used consistently to register a fresh SDAP context for the UE and PDU session. - Also, re-use and reconfigure existing SDAP entity if already exists. - logging has been added to trace mapped QFIs from RRC and resulting table entries 4. Improved QFI-to-DRB management - Refactored nr_sdap_qfi2drb_map_update() to register QFIs based on parsed config - Ensures control PDUs are correctly routed even after reconfiguration - Extended nr_sdap_ue_qfi2drb_config: perform UL QoS flow to DRB mapping configuration for a SDAP entity has already been established according to TS 37.324, 5.3 QoS flow to DRB Mapping, 5.3.1 Configuration Procedures. Handle both UL QoS Flows mapping rules to add and to remove. QFIs will now be properly unmapped if specified via mappedQoS_FlowsToRelease, this might prevent stale QFI mappings from being used incorrectly. - nr_sdap_qfi2drb() and sdap_map_ctrl_pdu() now strictly fallback to default_drb only if a QFI mapping is missing. Missing default DRB now triggers LOG_E() (previously silent or misrouted to DRB 0). 5. Other cleanup - Remove dependencies from legacy rb_id_t
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.