Jaroslava Fiedlerova
6b06bda933
T-Tracer & Data Recording v1.1: UL PHY trace modularization and recording enhancements Based on the plan with @schmidtr and @roux-cedric, we agreed to enhance the data recording in two phases: - Phase 1: Update Data Recording framework to get All internal Massive Updates and enhancements through the whole framework public - Phase2: Restructure T-Tracer Apps and remove all Mems in gNB and UE Softmodems to Get data on T-tarcer Apps for all activated Messages symbol-by-symbol, and related Meta-data, then do the aggregation on the T-tracer App. So, there is No Memory Creation at all on the 5G NR Stack. This Merge Request is for Phase 1. We address the comments given in: !3632 Summary: Refactor T-Tracer instrumentation for UL PHY data capture and improve the data recording application (v1.0 → v1.1). This MR extracts inline T() macro calls into modular wrapper functions, adds Unix timestamp fields to trace messages, implements a 4-state shared memory protocol for gNB/UE tracers, and delivers an improved synchronized recording architecture in Python. Changes: - T-Tracer: Modular UL PHY trace wrappers - Add T_messages_creator.c/.h with 7 wrapper functions (log_ul_fd_dmrs, log_ul_fd_chan_est_dmrs_pos, log_ul_fd_pusch_iq, log_ul_fd_chan_est_dmrs_interpl, log_ul_payload_rx_bits, log_ul_payload_tx_bits, log_ul_scrambled_tx_bits) and a static log_ul_common() helper - Register T_messages_creator.c in the T library CMake build - Update T_messages.txt definitions: Remove string timestamps and get time stamp directly from sending_time of T-macro. - PHY: Replace inline T() calls with wrappers - gNB (nr_ulsch_demodulation.c, nr_ul_channel_estimation.c, phy_procedures_nr_gNB.c): replace inline T() calls with T_messages_creator wrappers - UE (nr_ulsch_coding.c, nr_ulsch_ue.c): replace inline T() calls with log_ul_payload_tx_bits and log_ul_scrambled_tx_bits wrappers - Remove deprecated log_tools.c/.h and its CMake reference - T-Tracer gNB & UE apps: Enhancements - Implement 4-state shared memory protocol (WAIT → CONFIG → RECORD → STOP) for coordination with the data recording app - Add event_trace_msg_ul_data struct with 27 UL metadata fields - Refactor event loop to poll()-based with proper signal handling - Separate project IDs (gNB=2335, UE=2336) and ftok paths for independent shared memory segments - Update shared memory sizing: Limit number of records to NUM_MESSAGES_PER_SLOT=5, 100 slots - Data Recording App v1.1 - Improved architecture with thread pool and barrier synchronization - Frame/slot-based message grouping with per-slot validation - atexit/signal-based cleanup for graceful shared memory detach - Delete legacy data_recording_app_v1.0.py - Library improvements - config_interface.py: remove legacy YAML config reader, streamline to JSON-only - shared_memory_interface.py: new module for shared memory attach/read/protocol - wireless_parameters_mapper.py: new module for NR parameter mapping - data_recording_messages_def.py: updated message definitions for 27-field struct - sigmf_interface.py, sync_service.py, common_utils.py: remove unused imports and dead code - Documentation - Update data_recording.md for v1.1 architecture and usage
OpenAirInterface License
The source code is distributed under CSSL v1.0. Some files, such as for orchestration, are distributed under MIT license(MIT.txt). Documentation is distributed under Creative Commons Attribution 4.0 International license.
All the files without an explicit copyright header have an implicit "Copyright of OpenAirInterface Authors".
Please see NOTICE for other licenses which are used in the software.
In the past OAI source code has been re-licensed sometimes, here is the history:
- CSSL v1.0 starting tag 2026.w14
- OAI Public License v1.1 starting tag v1.0 till
af4b0d53 - OAI Public License v1.0: starting tag v.04 till v1.0
- GPL 3: starting tag v.0 till v.04 (only initial implementation of 4G)
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.