Add SRS flag in the aerial gNB Docker image build

doc/5Gnas.md

@@ -1,10 +1,10 @@
-# 5GS NAS Overview and OAI Implementation status
+**5GS NAS Overview and OAI Implementation status**
 
 This document provides an overview of the 5G System Non-Access Stratum (5GS NAS) protocol as specified in 3GPP TS 24.501. It highlights key message types involved in Mobility and Session Management and explains how these are implemented within the OAI software stack. The document outlines the structure of the OAI codebase by detailing current support for encoding, decoding, and unit testing of specific NAS messages, and explains how the UE handles USIM simulation and message generation.
 
 [TOC]
 
-## About 5GS NAS
+# About 5GS NAS
 
 The 5G System Non-Access Stratum (5GS NAS) is defined in 3GPP TS 24.501. It operates within the control plane, facilitating communication between the User Equipment (UE) and the Access and Mobility Management Function (AMF) over the N1 interface.
 
@@ -13,7 +13,7 @@ Key 5GS NAS messages:
 * Mobility Management (5GMM): Handles UE registration, deregistration, authentication and tracking area updates. 5GMM also manages transitions between idle and connected states.
 * Session Management (5GSM): Establishes, modifies, and releases PDU sessions. Coordinates with the Session Management Function (SMF) to manage user-plane resources.
 
-## OAI Implementation Status
+# OAI Implementation Status
 
 The following tables lists implemented NAS messages and whether there is an encoder or decoder function, and if a corresponding unit test exists.
 
@@ -33,37 +33,37 @@ The following tables lists implemented NAS messages and whether there is an enco
 | 5GSM  | PDU Session Establishment Request         | yes      | no       | no         |
 | 5GSM  | PDU Session Establishment Accept          | no       | yes      | no         |
 
-### Code Structure
+## Code Structure
 
-[openair3/NAS/NR_UE/nr_nas_msg.c](../../openair3/NAS/NR_UE/nr_nas_msg.c):
+[openair3/NAS/NR_UE/nr_nas_msg.c](../openair3/NAS/NR_UE/nr_nas_msg.c):
 * NAS procedures and message handlers/callbacks
 * Integration with RRC (ITTI) and SDAP
 * Invokes enc/dec libraries
 * Handles 5GMM state and mode
 
-[openair3/NAS/NR_UE/5GS/fgs_nas_lib.c](../../openair3/NAS/NR_UE/5GS/fgs_nas_lib.c):
-[openair3/NAS/NR_UE/5GS/NR_NAS_defs.h](../../openair3/NAS/NR_UE/5GS/NR_NAS_defs.h):
+[openair3/NAS/NR_UE/5GS/fgs_nas_lib.c](../openair3/NAS/NR_UE/5GS/fgs_nas_lib.c):
+[openair3/NAS/NR_UE/5GS/NR_NAS_defs.h](../openair3/NAS/NR_UE/5GS/NR_NAS_defs.h):
 * encoding and decoding functions for 5G NAS message headers and payloads
 * relies on 5GMM/5GSM messages libs for payload encoding
 
-[openair3/NAS/NR_UE/5GS/fgs_nas_utils.h](../../openair3/NAS/NR_UE/5GS/fgs_nas_utils.h):
+[openair3/NAS/NR_UE/5GS/fgs_nas_utils.h](../openair3/NAS/NR_UE/5GS/fgs_nas_utils.h):
 * NAS helpers, macros
 
-[openair3/NAS/NR_UE/5GS/5GMM](../../openair3/NAS/NR_UE/5GS/5GMM):
+[openair3/NAS/NR_UE/5GS/5GMM](../openair3/NAS/NR_UE/5GS/5GMM):
 * encoding/decoding functions and definitions for 5GMM NAS messages payloads
 
-[openair3/NAS/NR_UE/5GS/5GMM/MSG/fgmm_lib.c](../../openair3/NAS/NR_UE/5GS/5GMM/MSG/fgmm_lib.c):
-[openair3/NAS/NR_UE/5GS/5GMM/MSG/fgmm_lib.h](../../openair3/NAS/NR_UE/5GS/5GMM/MSG/fgmm_lib.h):
+[openair3/NAS/NR_UE/5GS/5GMM/MSG/fgmm_lib.c](../openair3/NAS/NR_UE/5GS/5GMM/MSG/fgmm_lib.c):
+[openair3/NAS/NR_UE/5GS/5GMM/MSG/fgmm_lib.h](../openair3/NAS/NR_UE/5GS/5GMM/MSG/fgmm_lib.h):
 * encoding/decoding functions and definitions for common 5GMM IEs
 
-[openair3/NAS/NR_UE/5GS/5GSM](../../openair3/NAS/NR_UE/5GS/5GSM):
+[openair3/NAS/NR_UE/5GS/5GSM](../openair3/NAS/NR_UE/5GS/5GSM):
 * encoding and decoding functions for 5GSM NAS messages payloads
 
-## USIM Simulation
+# USIM Simulation
 
 OAI includes a simulated USIM implementation that reads its parameters from standard configuration files. This allows for rapid prototyping and testing without relying on a physical UICC card. The USIM-related configuration is handled via the `init_uicc()` function.
 
-### Configuration
+## Configuration
 
 The simulation reads values from a named section in the config file.
 
@@ -84,11 +84,11 @@ The simulation reads values from a named section in the config file.
 
 These are parsed and stored in the `uicc_t` structure.
 
-### Initialization
+## Initialization
 
 The UE calls `init_uicc` via `checkUicc` to allocate memory for the `uicc_t` structure member and load parameters using `config_get()` from the selected config section. Then the UICC structure is stored in the NAS context. `nr_ue_nas_t`, to be used to fill identity and security credentials when generating responses to 5GC messages such as `Identity Response`, `Authentication Response`, and `Security Mode Complete`.
 
-### Milenage Authentication and Key Derivation
+## Milenage Authentication and Key Derivation
 
 When the UE receives a **5GMM Authentication Request**, the function `generateAuthenticationResp` generates a valid `Authentication Response` with the necessary derived NAS and AS security keys. The function `derive_ue_keys` parses the Authentication Request and performs the entire 5G AKA key hierarchy:
 
@@ -97,11 +97,11 @@ When the UE receives a **5GMM Authentication Request**, the function `generateAu
 * Computes the `RES` using `transferRES()`
 * Derives the keys `KAUSF`, `KSEAF`, `KAMF`, `KNASenc`/`KNASint` via `derive_knas()` and `KGNB` for RRC ciphering (via `derive_kgnb()`)
 
-### Security Mode Complete
+## Security Mode Complete
 
 When the UE receives a **Security Mode Command** from the 5GC, it responds with a `Security Mode Complete` message. This message is protected with the newly established NAS security context and may carry additional payloads, including the UE’s identity and a nested NAS message (e.g., `Registration Request`) in the `FGSNasMessageContainer`. The function responsible for building and securing this response is `generateSecurityModeComplete`.
 
-#### IMEISV
+### IMEISV
 
 The **IMEISV**, is encoded using the `fill_imeisv()` helper. This function extracts each digit from the configured `imeisvStr` in the UICC context and populates the mobile identity structure.
 

doc/Aerial_FAPI_Split_Tutorial.md

@@ -1,10 +1,22 @@
-# OAI 7.2 Fronthaul Interface 5G SA Tutorial
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">OAI 7.2 Fronthaul Interface 5G SA Tutorial</font></b>
+    </td>
+  </tr>
+</table>
 
 **Table of Contents**
 
 [[_TOC_]]
 
-## Prerequisites
+# Prerequisites
 
 The hardware on which we have tried this tutorial:
 
@@ -49,7 +61,7 @@ The UEs that have been tested and confirmed working with Aerial are the followin
 | Samsung         | S23 Ultra                     |
 
 
-### Configure your server
+## Configure your server
 
 To set up the L1 and install the components manually refer to this [instructions page](https://docs.nvidia.com/aerial/cuda-accelerated-ran/index.html).
 
@@ -59,7 +71,7 @@ of the FAPI 10.04 version of the SRS PDU, and RX_Beamforming PDU.
 - To configure the Gigabyte server please refer to these [instructions](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/2025.w13/doc/Aerial_FAPI_Split_Tutorial.md)
 - The last release to support the Gigabyte server is **Aerial CUDA-Accelerated RAN 24-1**.
 
-#### CPU allocation
+### CPU allocation
 
 | Server brand     | Model         | Nº of CPU Cores | Isolated CPUs  |
 |------------------|---------------|:---------------:|:--------------:|
@@ -72,7 +84,7 @@ of the FAPI 10.04 version of the SRS PDU, and RX_Beamforming PDU.
 | PTP & PHC2SYS Services | 41             |
 | OAI `nr-softmodem`     | 13-14          |
 
-### PTP configuration
+## PTP configuration
 
 1. You need to install the `linuxptp` debian package. It will install both ptp4l and phc2sys.
 
@@ -132,7 +144,7 @@ WantedBy=multi-user.target
 
 ```
 
-## Build OAI gNB
+# Build OAI gNB
 
 If it's not already cloned, the first step is to clone OAI repository
 ```bash
@@ -140,7 +152,7 @@ git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git ~/openairinterfac
 cd ~/openairinterface5g/
 ```
 
-### Get nvIPC sources from the L1 container
+## Get nvIPC sources from the L1 container 
 
 The library used for communication between L1 and L2 components is called nvIPC, and is developed by NVIDIA. It is not open-source and can't be freely distributed.
 In order to achieve this communication, we need to obtain the nvIPC source files from the L1 container (cuBB) and place it in the gNB project directory `~/openairinterface5g`.
@@ -198,7 +210,7 @@ aerial@c_aerial_aerial:/opt/nvidia/cuBB/cuPHY-CP/gt_common_libs# exit
 
 With the nvIPC sources in the project directory, the docker image can be built.
 
-### Building OAI gNB docker image
+## Building OAI gNB docker image
 
 In order to build the target image (`oai-gnb-aerial`), first you should build a common shared image (`ran-base`)
 ```bash
@@ -208,12 +220,12 @@ In order to build the target image (`oai-gnb-aerial`), first you should build a
 ```
 
 
-## Running the setup
+# Running the setup
 
 In order to use Docker Compose to automatically start and stop the setup, we first need to create a pre-built image of L1 after compiling the L1 software and making the necessary adjustments to its configuration files.
 The process of preparing L1 is covered in NVIDIA's documentation and falls outside the scope of this document.
 
-### Prepare the L1 image
+## Prepare the L1 image
 After preparing the L1 software, the container needs to be committed to create an image where L1 is ready for execution, which can later be referenced by a `docker-compose.yaml` file.
 
 *Note:* The default L1 configuration file is `cuphycontroller_P5G_FXN_GH.yaml`, located in `/opt/nvidia/cuBB/cuPHY-CP/cuphycontroller/config/`.
@@ -227,7 +239,7 @@ cubb-build                                    25-2
 -..
 ```
 
-### Adapt the OAI-gNB configuration file to your system/workspace
+## Adapt the OAI-gNB configuration file to your system/workspace
 
 Edit the sample OAI gNB configuration file and check following parameters:
 
@@ -241,8 +253,8 @@ The default amf_ip_address:ipv4 value is 192.168.70.132, when installing the CN5
 Both 'GNB_IPV4_ADDRESS_FOR_NG_AMF' and 'GNB_IPV4_ADDRESS_FOR_NGU' need to be set to the IP address of the NIC referenced previously.
 
 
-### Running docker compose
-#### Aerial L1 entrypoint script
+## Running docker compose
+### Aerial L1 entrypoint script
 The `aerial_l1_entrypoint` script is used by the L1 container to start the L1 software and is called in the Docker Compose file.
 It begins by setting up environment variables, restarting NVIDIA MPS, and finally running `cuphycontroller_scf`.
 
@@ -263,7 +275,7 @@ The logs can be followed using these commands:
 docker logs -f oai-gnb-aerial
 docker logs -f nv-cubb
 ```
-#### Running with multiple L2s
+### Running with multiple L2s
 One L1 instance can support multiple L2 instances. See also the [aerial documentation](https://developer.nvidia.com/docs/gputelecom/aerial-sdk/text/cubb_quickstart/running_cubb-end-to-end.html#run-multiple-l2-instances-with-single-l1-instance) for more details.
 
 In OAI the shared memory prefix must be configured in the configuration file.
@@ -274,7 +286,7 @@ In OAI the shared memory prefix must be configured in the configuration file.
 ```
 
 
-### Stopping the setup
+## Stopping the setup
 
 Run the following command to stop and remove both containers, leaving the system ready to be restarted later:
 ```bash

doc/BUILD.md

@@ -1,14 +1,26 @@
-# OAI Build Procedures
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">OAI Build Procedures</font></b>
+    </td>
+  </tr>
+</table>
 
 [[_TOC_]]
 
 This page is valid on tags starting from **`2019.w09`**.
 
-## Overview
+# Overview
 
 The [OAI EPC](https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME_MAGMA_MME.md) and [OAI 5GC](https://gitlab.eurecom.fr/oai/cn5g/oai-cn5g-fed/-/blob/master/docs/DEPLOY_HOME.md) are developed in distinct projects with their own documentation and are not further described here.
 
-OAI softmodem sources, which aim to implement 3GPP compliant UEs, eNodeB and gNodeB can be downloaded from the Eurecom [gitlab repository](setup/GET_SOURCES.md).
+OAI softmodem sources, which aim to implement 3GPP compliant UEs, eNodeB and gNodeB can be downloaded from the Eurecom [gitlab repository](./GET_SOURCES.md).
 
 Sources come with a build script [build_oai](../cmake_targets/build_oai) located at the root of the `openairinterface5g/cmake_targets` directory. This script is developed to build the oai binaries (executables,shared libraries) for different hardware platforms, and use cases.
 
@@ -28,7 +40,7 @@ Running the  [build_oai](../cmake_targets/build_oai) script also generates some
 - `nvram`: a binary used to build (4G) UE (IMEI...) and EMM (IMSI, registered PLMN) non volatile data.
 - `genids` T Tracer utility, used at build time to generate `T_IDs.h` include file. This binary is located in the [T Tracer source file directory](../common/utils/T) .
 
-The build system for OAI uses [cmake](https://cmake.org/) which is a  tool to generate makefiles. The `build_oai` script is a wrapper using `cmake` and `make`/`ninja` to ease the oai build and use. It logs the `cmake` and `ninja`/`make` commands it executes. The file describing how to build the executables from source files is the [CMakeLists.txt](CMakeLists.txt), it is used as input by cmake to generate the makefiles.
+The build system for OAI uses [cmake](https://cmake.org/) which is a  tool to generate makefiles. The `build_oai` script is a wrapper using `cmake` and `make`/`ninja` to ease the oai build and use. It logs the `cmake` and `ninja`/`make` commands it executes. The file describing how to build the executables from source files is the [CMakeLists.txt](../CMakeLists.txt), it is used as input by cmake to generate the makefiles.
 
 cmake is further extended by using [CPM](https://github.com/cpm-cmake/CPM.cmake). CPM is a cmake script that handles external code dependencies. It is setup to cache downloaded code in `~/.cache/cpm`. While most external dependencies should be handled by system package managers, CPM has the advantage of using any code that is available in a public git repository.
 
@@ -37,9 +49,9 @@ The oai softmodem supports many use cases, and new ones are regularly added. Mos
 - s1, noS1
 - all simulators as the rfsimulator, the L2 simulator, with exception of PHY simulators, which are distinct executables. 
 
-## Running `build_oai`
+# Running `build_oai`
 
-### List of options
+## List of options
 
 Calling the `build_oai` script with the `-h` option gives the list of all available options. A number of important ones:
 
@@ -52,9 +64,9 @@ Calling the `build_oai` script with the `-h` option gives the list of all availa
 - `--ninja` is to use the `ninja` build tool, which speeds up compilation.
 - `-c` is to clean the workspace and force a complete rebuild.
 
-`build_oai` also provides various options to enable runtime error checkers, i.e. sanitizers in order to find various types of bugs in the codebase and eventually enhance the stability of the OAI softmodems. Refer to [sanitizers.md](dev_tools/sanitizers.md) for more details.
+`build_oai` also provides various options to enable runtime error checkers, i.e. sanitizers in order to find various types of bugs in the codebase and eventually enhance the stability of the OAI softmodems. Refer to [sanitizers.md](./dev_tools/sanitizers.md) for more details.
 
-### Installing dependencies
+## Installing dependencies
 
 Install all dependencies by issuing the `-I` option. To install furthermore libraries for optional libraries, use the `--install-optional-packages` option. The `-I` option will also install dependencies for an SDR when paired with `-w`. For instance, in order to install all dependencies and the ones for USRP, run:
 
@@ -65,7 +77,7 @@ cd openairinterface5g/cmake_targets/
 
 Note the section on installing UHD further down for more information.
 
-### Installing (new) asn1c from source
+## Installing (new) asn1c from source
 
 With tag 2023.w22, we switch from our [own
 `asn1c`](https://gitlab.eurecom.fr/oai/asn1c.git) to a [community-maintained
@@ -95,7 +107,7 @@ install elsewhere, using one of these two methods:
 cmake .. -GNinja -DASN1C_EXEC=/opt/asn1c/bin/asn1c
 ```
 
-### Installing UHD from source
+## Installing UHD from source
 
 Previously for Ubuntu distributions, when installing the pre-requisites, most of the packages are installed from PPA.
 
@@ -127,7 +139,7 @@ See:
 * `cmake_targets/tools/uhd-4.x-tdd-patch.diff`
 * `cmake_targets/tools/build_helper` --> function `install_usrp_uhd_driver_from_source`
 
-### Building PHY Simulators
+## Building PHY Simulators
 
 The PHY layer simulators (LTE and NR) can be built as follows:
 
@@ -138,9 +150,9 @@ cd openairinterface5g/cmake_targets/
 
 After completing the build, the binaries are available in the `cmake_targets/ran_build/build` directory.
 
-Detailed information about these simulators can be found [in the dedicated page](usage/physical-simulators.md)
+Detailed information about these simulators can be found [in the dedicated page](./physical-simulators.md)
 
-### Building UEs, eNodeB and gNodeB Executables
+## Building UEs, eNodeB and gNodeB Executables
 
 After downloading the source files, a single build command can be used to get the binaries supporting all the oai softmodem use cases (UE and [eg]NodeB):
 
@@ -153,7 +165,7 @@ You can build any oai softmodem executable separately, you may not need all of t
 
 After completing the build, the binaries are available in the `cmake_targets/ran_build/build` directory.
 
-### Building Optional Binaries
+## Building Optional Binaries
 
 There are a number of optional libraries that can be built in support of the
 RAN, such as telnetsrv, scopes, offloading libraries, etc.
@@ -175,7 +187,7 @@ Some libraries have further dependencies and might not build on every system:
 - `websrv`: npm and others
 - `ldpc_aal`: DPDK with patch
 
-## Running `cmake` directly
+# Running `cmake` directly
 
 `build_oai` is a wrapper on top of `cmake`. It is therefore possible to run `cmake` directly. An example using `ninja`: to build all "main targets" for 5G, excluding additional libraries:
 ```
@@ -205,9 +217,9 @@ cmake-gui ../../..
 ```
 You can of course use all standard cmake/ninja/make commands in this directory.
 
-### cmake presets
+## cmake presets
 
-CMake presets are common project configure options. See [here](https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html).
+CMake presets are common project configure options. See https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html
 
 Configure presets:
 
@@ -229,7 +241,7 @@ To build using a build preset:
 
     cmake --build --preset <preset_name>
 
-## Cross Compile
+# Cross Compile
 
-If you want to use cross-compiler on x86 platform for aarch64 version, please refer the [cross-compile.md](setup/cross-compile.md) for more information.
+If you want to use cross-compiler on x86 platform for aarch64 version, please refer the [cross-compile.md](./cross-compile.md) for more information.
 

doc/E1AP/e1ap_procedures.md

@@ -1,4 +1,16 @@
-# E1AP Procedures
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">E1AP Procedures</font></b>
+    </td>
+  </tr>
+</table>
 
 [[_TOC_]]
 

doc/F1AP/F1-design.md

@@ -1,4 +1,16 @@
-# F1 split design
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">F1 split design</font></b>
+    </td>
+  </tr>
+</table>
 
 [[_TOC_]]
 

doc/F1AP/F1AP-lib.md

@@ -1,4 +1,16 @@
-# F1AP Messages Encoding & Decoding Library
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">F1AP Messages Encoding & Decoding Library</font></b>
+    </td>
+  </tr>
+</table>
 
 [[_TOC_]]
 

doc/FEATURE_SET.md

@@ -2,7 +2,7 @@
 
 [[_TOC_]]
 
-## Functional Split Architecture
+# Functional Split Architecture #
 
 -  RCC: Radio-Cloud Center
 -  RAU: Radio-Access Unit
@@ -11,21 +11,21 @@
 -  FAPI (IF2)  : specified by Small Cell Forum (open-nFAPI implementation)
 -  IF1         : F1 in 3GPP Release 15
 
-![Functional Split Architecture](../images/oai_enb_func_split_arch.png)
+![Functional Split Architecture](./oai_enb_func_split_arch.png)
 
 
-## OpenAirInterface Block Diagram
+# OpenAirInterface Block Diagram #
 
-![Block Diagram](../images/oai_enb_block_diagram.png)
+![Block Diagram](./oai_enb_block_diagram.png)
 
-## OpenAirInterface 5G-NR Feature Set
+# OpenAirInterface 5G-NR Feature Set #
 
-### General Parameters
+## General Parameters
 
 The following features are valid for the gNB and the 5G-NR UE.
 
 *  Static TDD
-   - Multi TDD pattern supported refer [TDD Configuration](../MAC/mac-usage.md)
+   - Multi TDD pattern supported refer [TDD Configuration](NR_SA_Multi_TDD_Pattern.md)
 *  Static FDD
 *  Normal CP
 *  Subcarrier spacings: 15 and 30kHz (FR1), 120kHz (FR2)
@@ -58,7 +58,7 @@ These modes of operation are supported:
   - is unstable (only one UE connection)
 
 
-### gNB PHY
+## gNB PHY
 
 *  15kHz and 30kHz SCS for FR1 and 120kHz SCS for FR2
 *  Generation of NR-PSS/NR-SSS
@@ -101,7 +101,7 @@ These modes of operation are supported:
 *  Highly efficient 3GPP compliant polar encoder and decoder
 *  Encoder and decoder for short block
 
-### gNB MAC
+## gNB MAC
 
 - MAC -> PHY configuration using NR FAPI P5 interface
 - MAC <-> PHY data interface using FAPI P7 interface for BCH PDU, DCI PDU, PDSCH PDU
@@ -146,7 +146,7 @@ These modes of operation are supported:
 - Initial support for RedCap
 - Scheduling of SIBs (2, 19)
 
-### gNB RLC
+## gNB RLC
 
 - Send/Receive operations according to 38.322 Rel.16
   - Segmentation and reassembly procedures
@@ -157,7 +157,7 @@ These modes of operation are supported:
   - Interfaces with PDCP, MAC
   - Interfaces with gtp-u (data Tx/Rx over F1-U at the DU)
 
-### gNB PDCP
+## gNB PDCP
 
 - Send/Receive operations according to 38.323 Rel.16
   - Integrity protection and ciphering procedures
@@ -166,7 +166,7 @@ These modes of operation are supported:
   - Interfaces with RRC, RLC
   - Interfaces with gtp-u (data Tx/Rx over N3 and F1-U interfaces)
 
-### gNB SDAP
+## gNB SDAP
 
 - Send/Receive operations according to 37.324 Rel.15
   - Establishment/Handling of SDAP entities.
@@ -175,7 +175,7 @@ These modes of operation are supported:
   - Marking QoS flow ID in both DL and UL packets
   - Reflective QoS flow to DRB mapping for UL SDAP data PDUs
 
-### gNB RRC
+## gNB RRC
 
 - NR RRC (38.331) Rel 17 messages using new [asn1c](https://github.com/mouse07410/asn1c)
 - LTE RRC (36.331) also updated to Rel 15
@@ -193,13 +193,13 @@ These modes of operation are supported:
   - Periodic RRC measurements of serving cell (no A/B events)
 - Initial support for RedCap
 
-### gNB X2AP
+## gNB X2AP
 
 - Integration of X2AP messages and procedures for the exchanges with the eNB over X2 interface supporting the NSA setup according to 36.423 Rel. 15
   - X2 setup with eNB
   - Handling of SgNB Addition Request/Addition Request Acknowledge/Reconfiguration Complete
 
-### gNB NGAP
+## gNB NGAP
 
 - Integration of NGAP messages and procedures for the exchanges with the AMF over N2 interface according to 38.413 Rel. 15
   - NGAP Setup request/response
@@ -211,7 +211,7 @@ These modes of operation are supported:
   - NGAP PDU session resource setup request/response
 - Interface with RRC
 
-### gNB F1AP
+## gNB F1AP
 
 - Integration of F1AP messages and procedures for the control plane exchanges between the CU and DU entities according to 38.473 Rel. 16
   - F1 Interface Management:
@@ -232,7 +232,7 @@ These modes of operation are supported:
 - One CU(-CP) can handle multiple DUs
 - Support for intra-CU mobility (across DUs)
 
-### gNB E1AP
+## gNB E1AP
 
 - Integration of E1AP messages and procedures for exchange between CU-CP and CU-UP according to TS 38.463 Rel. 16
   - E1 Setup (gNB-CU-UP initiated)
@@ -248,21 +248,21 @@ These modes of operation are supported:
 - Interface with RRC and PDCP
 - One CU-CP can handle multiple CU-UPs
 
-### gNB GTP-U
+## gNB GTP-U
 
 - New GTP-U implementation supporting both N3 and F1-U interfaces according to 29.281 Rel.15
   - Interfaces with RRC, F1AP for tunnel creation
   - Interfaces with PDCP and RLC for data send/receive at the CU and DU respectively (F1-U interface)
   - Interface with SDAP for data send/receive, capture of GTP-U Optional Header, GTP-U Extension Header and PDU Session Container.
 
-### Number of supported UEs
+## Number of supported UEs
 
 * 16 by default (as defined in `MAX_MOBILES_PER_GNB`)
 * up to 64 if the configured bandwidth is sufficient (at leat 40 MHz)
 
-## OpenAirInterface 5G-NR UE Feature Set
+# OpenAirInterface 5G-NR UE Feature Set #
 
-###  NR UE PHY Layer
+##  NR UE PHY Layer ##
 
 *  Initial synchronization
    - non-blind synchronization (information required: carrier frequency, bandwidth, numerology)
@@ -317,15 +317,15 @@ These modes of operation are supported:
 *  Highly efficient 3GPP compliant polar encoder and decoder
 *  Encoder and decoder for short block
 
-### NR UE FAPI
+## NR UE FAPI ##
 
 *  MAC -> PHY configuration via UE FAPI P5 interface
 *  Basic MAC to control PHY via UE FAPI P7 interface
 *  PHY -> MAC indication
 
-### NR UE Higher Layers
+## NR UE Higher Layers ##
 
-### UE MAC
+## UE MAC
 
 * Minimum system information (MSI)
    - MIB processing
@@ -368,7 +368,7 @@ These modes of operation are supported:
    - Operation in configured dedicated BWP through RRCSetup or RRCReconfiguration
 
 
-### UE RLC
+## UE RLC
 
 * Tx/Rx operations according to 38.322 Rel.16
    - Segmentation and reassembly procedures
@@ -378,7 +378,7 @@ These modes of operation are supported:
    - Timers implementation
    - Interfaces with PDCP, MAC
 
-### UE PDCP
+## UE PDCP
 
 * Tx/Rx operations according to 38.323 Rel.16
    - Integrity protection and ciphering procedures
@@ -386,7 +386,7 @@ These modes of operation are supported:
    - Radio bearer establishment/handling and association with PDCP entities
    - Interfaces with RRC, RLC
 
-### UE SDAP
+## UE SDAP
 
 *  Tx/Rx operations operations according to 37.324 Rel.15
   - Establishment/Handling of SDAP entities.
@@ -394,7 +394,7 @@ These modes of operation are supported:
   - Reflective Mapping
   - RRC Signaling Mapping
 
-### UE RRC
+## UE RRC
 
 * Integration of RRC messages and procedures supporting UE 5G SA connection according to 38.331 Rel.16
    - RRCSetupRequest/RRCSetup/RRCSetupComplete
@@ -406,7 +406,7 @@ These modes of operation are supported:
 * Interface with PDCP: configuration, DCCH and CCCH message handling
 * Interface with RLC and MAC for configuration
 
-### UE NAS
+## UE NAS
 
 * Transfer of NAS messages between the AMF and the UE supporting the UE registration with the core network and the PDU session  establishment according to 24.501 Rel.16
   - Identity Request/Response
@@ -418,9 +418,9 @@ These modes of operation are supported:
 
 
 
-## OpenAirInterface 4G LTE eNB Feature Set
+# OpenAirInterface 4G LTE eNB Feature Set #
 
-### eNB PHY Layer
+## eNB PHY Layer ##
 
 The Physical layer implements **3GPP 36.211**, **36.212**, **36.213** and provides the following features:
 
@@ -438,7 +438,7 @@ The Physical layer implements **3GPP 36.211**, **36.212**, **36.213** and provid
 - Multi-RRU support: over the air synchro b/ multi RRU in TDD mode
 - Support for CE-modeA for LTE-M. Limited support for repeatition, single-LTE-M connection, legacy-LTE UE attach is disabled.
 
-#### Performances
+### Performances ###
 
 **Transmission Mode, Bandwidth** | **Expected Throughput** | **Measured Throughput** | **Measurement Conditions**
 -------------------------------- | ----------------------- | ------------------------| ----------------:
@@ -458,13 +458,13 @@ TDD UL: 5 MHz, 25 PRBS/ MCS **XX**   | 2.0 Mbit/s          | TM1: 3.31 Mbits/s
 TDD UL: 10 MHz, 50 PRBS/ MCS **XX**  | 2.0 Mbit/s          | TM1: 7.25 Mbits/s       | COTS-UE Cat 4 (150/50 Mbps)
 TDD UL: 20 MHz, 100 PRBS/ MCS **XX** | 3.0 Mbit/s          | TM1: 4.21 Mbits/s       | COTS-UE Cat 4 (150/50 Mbps)
 
-#### Number of supported UEs
+### Number of supported UEs ###
 
 * 16 by default
 * up to 256 when compiling with dedicated compile flag
 * was tested with 40 COTS-UE
 
-### eNB MAC Layer
+## eNB MAC Layer ##
 
 The MAC layer implements a subset of the **3GPP 36.321** release v8.6 in support of BCH, DLSCH, RACH, and ULSCH channels.
 
@@ -482,7 +482,7 @@ The MAC layer implements a subset of the **3GPP 36.321** release v8.6 in support
 - Link adaptation
 - Connected DRX (CDRX) support for FDD LTE UE. Compatible with R13 from 3GPP. Support for Cat-M1 UE comming soon.
 
-### eNB RLC Layer
+## eNB RLC Layer ##
 
 The RLC layer implements a full specification of the 3GPP 36.322 release v9.3.
 
@@ -502,7 +502,7 @@ The RLC layer implements a full specification of the 3GPP 36.322 release v9.3.
   * RLC PDU retransmission in support of error control and correction
   * Generation of data/control PDUs
 
-### eNB PDCP Layer
+## eNB PDCP Layer ##
 
 The current PDCP layer is header compliant with **3GPP 36.323** Rel 10.1.0 and implements the following functions:
 
@@ -512,7 +512,7 @@ The current PDCP layer is header compliant with **3GPP 36.323** Rel 10.1.0 and i
 - PDCP entity association with one or two RLC entities
 - Integrity check and encryption using the AES and Snow3G algorithms
 
-### eNB RRC Layer
+## eNB RRC Layer ##
 
 The RRC layer is based on **3GPP 36.331** v15.6 and implements the following functions:
 
@@ -528,7 +528,7 @@ The RRC layer is based on **3GPP 36.331** v15.6 and implements the following fun
 - Paging (soon)
 - RRC inactivity timer (release of UE after a period of data inactivity)
 
-### eNB X2AP
+## eNB X2AP ##
 
 The X2AP layer is based on **3GPP 36.423** v14.6.0 and implements the following functions:
 
@@ -546,7 +546,7 @@ The X2AP layer is based on **3GPP 36.423** v14.6.0 and implements the following
  - RRC  : Handling of RRC Connection Reconfiguration with 5G cell info, configuration of 5G-NR measurements
  - S1AP : Handling of E-RAB Modification Indication / Confirmation
 
-### eNB/MCE M2AP
+## eNB/MCE M2AP ##
 
 The M2AP layer is based on **3GPP 36.443** v14.0.1:
  - M2 Setup Request
@@ -557,7 +557,7 @@ The M2AP layer is based on **3GPP 36.443** v14.0.1:
  - M2 Session Start Request
  - M2 Session Start Response
 
-### MCE/MME M3AP
+## MCE/MME M3AP ##
 
 The M3AP layer is based on **3GPP 36.444** v14.0.1:
  - M3 Setup Request
@@ -567,9 +567,9 @@ The M3AP layer is based on **3GPP 36.444** v14.0.1:
  - M3 Session Start Response
 
 
-## OpenAirInterface 4G LTE UE Feature Set
+# OpenAirInterface 4G LTE UE Feature Set #
 
-### LTE UE PHY Layer
+## LTE UE PHY Layer ##
 
 The Physical layer implements **3GPP 36.211**, **36.212**, **36.213** and provides the following features:
 
@@ -586,7 +586,7 @@ The Physical layer implements **3GPP 36.211**, **36.212**, **36.213** and provid
 - LTE non-MBSFN subframe (feMBMS) Carrier Adquistion Subframe-CAS procedures (PSS/SSS/PBCH/PDSH) (experimental)
 - LTE MBSFN MBSFN subframe channel (feMBMS): PMCH (CS@1.25KHz) (channel estimation for 25MHz bandwidth) (experimental)
 
-### LTE UE MAC Layer
+## LTE UE MAC Layer ##
 
 The MAC layer implements a subset of the **3GPP 36.321** release v8.6 in support of BCH, DLSCH, RACH, and ULSCH channels.
 
@@ -599,15 +599,15 @@ The MAC layer implements a subset of the **3GPP 36.321** release v8.6 in support
 - MBMS-dedicated cell (feMBMS) RRC interface for BCCH
 - eMBMS and MBMS-dedicated cell (feMBMS) RRC interface for MCCH, MTCH
 
-### LTE UE RLC Layer
+## LTE UE RLC Layer ##
 
 The RLC layer implements a full specification of the 3GPP 36.322 release v9.3.
 
-### LTE UE PDCP Layer
+## LTE UE PDCP Layer ##
 
 The current PDCP layer is header compliant with **3GPP 36.323** Rel 10.1.0.
 
-### LTE UE RRC Layer
+## LTE UE RRC Layer ##
 
 The RRC layer is based on **3GPP 36.331** v14.3.0 and implements the following functions:
 
@@ -615,7 +615,7 @@ The RRC layer is based on **3GPP 36.331** v14.3.0 and implements the following f
 - RRC connection establishment
 - MBMS-dedicated cell (feMBMS) SI-MBMS/SIB1-MBMS management
 
-### LTE UE NAS Layer
+## LTE UE NAS Layer ##
 
 The NAS layer is based on **3GPP 24.301** and implements the following functions:
 
@@ -625,6 +625,6 @@ The NAS layer is based on **3GPP 24.301** and implements the following functions
 
 [OAI wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
 
-[OAI softmodem build procedure](../BUILD.md)
+[OAI softmodem build procedure](BUILD.md)
 
-[Running the OAI softmodem ](../usage/RUNMODEM.md)
+[Running the OAI softmodem ](RUNMODEM.md)

doc/GET_SOURCES.md

@@ -2,7 +2,7 @@ The OpenAirInterface software can be obtained from our gitLab server. You will
 need a git client to get the sources. The repository is used for main
 developments.
 
-## Prerequisites
+# Prerequisites
 
 You need to install `git` using the following commands:
 
@@ -11,12 +11,12 @@ sudo apt-get update
 sudo apt-get install git
 ```
 
-## Clone the Git repository (for OAI Users without login to gitlab server)
+# Clone the Git repository (for OAI Users without login to gitlab server)
 
 The [openairinterface5g repository](https://gitlab.eurecom.fr/oai/openairinterface5g.git)
 holds the source code for the RAN (4G and 5G).
 
-### All users, anonymous access
+## All users, anonymous access
 
 Clone the RAN repository:
 
@@ -24,7 +24,7 @@ Clone the RAN repository:
 git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git
 ```
 
-### For contributors
+## For contributors
 
 Configure git with your name/email address, important if you are developer and
 want to contribute by pushing code. Please put your full name and the e-mail
@@ -35,16 +35,17 @@ git config --global user.name "Your Name"
 git config --global user.email "Your email address"
 ```
 
-More information can be found in [the contributing page](../../CONTRIBUTING.md).
+More information can be found in [the contributing page](../CONTRIBUTING.md).
 
-## Which branch to checkout?
+# Which branch to checkout?
 
 - `develop`: contains recent commits that are tested on our CI test bench. The
   update frequency is about once a week. 5G is only in this branch. **It is the
   recommended and default branch.**
 - `master`: contains a known stable version.
 
-You can find the latest stable tag release [here](https://gitlab.eurecom.fr/oai/openairinterface5g/tags).
+You can find the latest stable tag release here:
+https://gitlab.eurecom.fr/oai/openairinterface5g/tags
 
 The tag naming conventions are:
 
@@ -54,4 +55,4 @@ The tag naming conventions are:
   * `xx` the week number within the year
 
 More information on work flow and policies can be found in [this
-document](code-style-contrib.md).
+document](./code-style-contrib.md).

doc/L1SIM.md

@@ -1,27 +1,38 @@
-# Open Air LTE Emulation
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">Open Air LTE Emulation</font></b>
+    </td>
+  </tr>
+</table>
 
-> **Note:**
-> **Unless you know what you are doing, you likely do not need this!
+**Note: unless you know what you are doing, you likely do not need this!
 Rather, you are probably looking for the
-[RFsimulator](../../radio/rfsimulator/README.md)!**
+[RFsimulator](../radio/rfsimulator/README.md)!**
 
 oaisim has been scraped and replaced by the same programs that are used for the
 real-time operation, `lte-softmodem` and `lte-uesoftmodem`. This uses the IF4p5
 fronthaul protocol to achieve the communication.
 
-> Context: oaisim used to be a simulation mode inside OAI to emulate an eNB and
+Context: oaisim used to be a simulation mode inside OAI to emulate an eNB and
 multiple UEs.
 
 [[_TOC_]]
 
-## Build
+# Build
 
-Build eNB/UE as normal, as also described in [How to build the eNB and the UE](../BUILD.md):
+Build eNB/UE as normal, as also described in [How to build the eNB and the UE](./BUILD.md):
 ```bash
 ./build_oai -c --ninja --eNB --UE
 ```
 
-## How to run an eNB with the noS1 option
+# How to run an eNB with the noS1 option
 
 The following paragraph(s) explains how to run the L1 simulator in noS1 mode and using the oai kernel modules.
 
@@ -37,7 +48,7 @@ $ cd ../ran_build/build
 $ sudo -E ./lte-softmodem -O YYY.conf --noS1
 ```
 
-## How to run a UE with the noS1 option
+# How to run a UE with the noS1 option
 
 Similarly modify the example configuration file in `/openairinterface5g/ci-scripts/conf_files/rru.band7.nos1.simulator.conf` and replace loopback interface and IP addresses. Copy your modifications to a new file, let's call XXX.conf the resulting configuration file.
 
@@ -53,7 +64,7 @@ $ sudo ./lte-uesoftmodem -O XXX.conf -r 25 --siml1 --noS1
 
 That should give you equivalent functionality to what you had with oaisim including noise and RF channel emulation (path loss / fading, etc.). You should also be able to run multiple UEs. 
 
-## How to ping an eNB from a UE and vice versa (with the noS1 option)
+# How to ping an eNB from a UE and vice versa (with the noS1 option)
 
 Once your eNB and UE (built with the noS1 option) are running and synchronised, you can ping the eNB from the UE with the following command:
 

doc/L2NFAPI.md

@@ -1,4 +1,16 @@
-# L2 nFAPI Simulator Usage
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">L2 nFAPI Simulator Usage</font></b>
+    </td>
+  </tr>
+</table>
 
 ## 4G L2 nFAPI simulator
 
@@ -6,11 +18,11 @@ This simulator allows to test L2 and above Layers using the nFAPI interface.
 
 The UE executable is able to "simulate" multiple UEs in order to stimulate the scheduler in the eNB.
 
-> **This simulator is available starting the `v1.0.0` release on the `master` branch.**
+**This simulator is available starting the `v1.0.0` release on the `master` branch.**
 
-> **2022/03/08: CAUTION, THIS TUTORIAL IS NO LONGER VALID on the `develop` branch after the `2022.w01` tag.**
+**2022/03/08: CAUTION, THIS TUTORIAL IS NO LONGER VALID on the `develop` branch after the `2022.w01` tag.**
 
-> **2022/03/08: CAUTION, THE LAST VALID TAG on `develop` branch is `2021.w51_c`.**
+**2022/03/08: CAUTION, THE LAST VALID TAG on `develop` branch is `2021.w51_c`.**
 
 Currently the Continuous Integration process is validating this simulator the following way:
 
@@ -26,12 +38,11 @@ Normally it should be fine to run both executables on the same host using the `l
 2. [No S1 -- eNB and UE on 2 hosts](L2NFAPI_NOS1.md)
 
 
-> **2022/03/08: Starting the `2022.w01` tag on the `develop` branch, the L2 nFAPI simulation is using a proxy.**
+**2022/03/08: Starting the `2022.w01` tag on the `develop` branch, the L2 nFAPI simulation is using a proxy.**
 
 ## 5G L2 nFAPI simulator
 
-> **Note:**
-> **L2 simulator does not work anymore.**
+**Note: L2 simulator does not work anymore.**
 
 ### Download and Build the Proxy Server (from EpiSci)
 

doc/L2NFAPI_NOS1.md

@@ -1,14 +1,26 @@
-# L2 nFAPI Simulator (no S1 Mode / 2-host deployment)
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">L2 nFAPI Simulator (no S1 Mode / 2-host deployment)</font></b>
+    </td>
+  </tr>
+</table>
 
-> **2022/03/08: CAUTION, THIS TUTORIAL IS NO LONGER VALID on the `develop` branch after the `2022.w01` tag.**
+**2022/03/08: CAUTION, THIS TUTORIAL IS NO LONGER VALID on the `develop` branch after the `2022.w01` tag.**
 
-> **2022/03/08: CAUTION, THE LAST VALID TAG on `develop` branch is `2021.w51_c`.**
+**2022/03/08: CAUTION, THE LAST VALID TAG on `develop` branch is `2021.w51_c`.**
 
 **Table of Contents**
 
 [[_TOC_]]
 
-## 1. Environment 
+# 1. Environment #
 
 You may not have access to an EPC or you don't want to hassle to deploy one.
 
@@ -19,11 +31,11 @@ You may not have access to an EPC or you don't want to hassle to deploy one.
 
 Example of L2 nFAPI Simulator testing environment:
 
-![L2-sim-noS1-2-host-deployment](../images/L2-sim-noS1-2-host-deployment.png)
+<img src="./images/L2-sim-noS1-2-host-deployment.png" alt="" border=3>
 
-> Note that the IP addresses are indicative and need to be adapted to your environment.
+Note that the IP addresses are indicative and need to be adapted to your environment.
 
-## 2. Retrieve the OAI eNB-UE source code 
+# 2. Retrieve the OAI eNB-UE source code #
 
 At the time of writing, the tag used in the `develop` branch to do this documentation was `2020.w16`.
 
@@ -45,7 +57,7 @@ cd ue_folder
 git checkout develop
 ```
 
-## 3. Setup of the USIM information in UE folder 
+# 3. Setup of the USIM information in UE folder #
 
 ```bash
 $ ssh sudousername@machineC
@@ -101,11 +113,11 @@ UE1: // <- Edit here
 
 You can repeat the operation for as many users you want to test with.
 
-## 4. Setup of the Configuration files 
+# 4. Setup of the Configuration files #
 
-> **CAUTION: both proposed configuration files resides in the ci-scripts realm. You can copy them but you CANNOT push any modification on these 2 files as part of an MR without informing the CI team.**
+**CAUTION: both proposed configuration files resides in the ci-scripts realm. You can copy them but you CANNOT push any modification on these 2 files as part of an MR without informing the CI team.**
 
-### 4.1. The eNB Configuration file 
+## 4.1. The eNB Configuration file ##
 
 ```bash
 $ ssh sudousername@machineB
@@ -131,8 +143,7 @@ MACRLCs = (
 );
 ```
 
-If you are testing more than 16 UEs, a proper setting on the RUs is necessary. 
-> **Note that this part is NOT present in the original configuration file**.
+If you are testing more than 16 UEs, a proper setting on the RUs is necessary. **Note that this part is NOT present in the original configuration file**.
 
 ```
 RUs = (
@@ -167,7 +178,7 @@ Last, the S1 interface shall be properly set.
     };
 ```
 
-### 4.2. The UE Configuration file 
+## 4.2. The UE Configuration file ##
 
 ```bash
 $ ssh sudousername@machineB
@@ -192,11 +203,11 @@ L1s = (
 );
 ```
 
-## 5. Build OAI UE and eNodeB 
+# 5. Build OAI UE and eNodeB #
 
-See [Build documentation](../BUILD.md).
+See [Build documentation](./BUILD.md).
 
-## 6. Start the eNB 
+# 6. Start the eNB #
 
 In the first terminal (the one you used to build the eNB):
 
@@ -218,7 +229,7 @@ If you don't use redirection, you can test but many logs are printed on the cons
 
 We do recommend the redirection in steady mode once your setup is correct.
 
-## 7. Start the UE 
+# 7. Start the UE #
 
 In the second terminal (the one you used to build the UE):
 
@@ -268,7 +279,7 @@ oaitun_uem1 Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-
 
 Having the 4 oaitun_ue tunnel interfaces up and with an allocated address means the connection with EPC went alright.
 
-## 8. Test with ping 
+# 8. Test with ping #
 
 In a third terminal, after around 10 seconds, the UE(s) shall be connected to the eNB: Check with ifconfig
 
@@ -308,15 +319,15 @@ $ ssh sudousername@machineC
 iperf -c 10.0.1.1 -u -t 30 -b 2M -i 1 -fm -B 10.0.1.2 -p 5002
 ```
 
-## 9. Limitations 
+# 9. Limitations #
 
 
 ----
 
 [oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
 
-[oai softmodem features](../setup/FEATURE_SET.md)
+[oai softmodem features](FEATURE_SET.md)
 
-[oai softmodem build procedure](../BUILD.md)
+[oai softmodem build procedure](BUILD.md)
 
 [L2 nfapi simulator](L2NFAPI.md)

doc/L2NFAPI_S1.md

@@ -1,14 +1,26 @@
-# L2 nFAPI Simulator (with S1 / 2-host deployment)
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">L2 nFAPI Simulator (with S1 / 2-host deployment)</font></b>
+    </td>
+  </tr>
+</table>
 
-> **2022/03/08: CAUTION, THIS TUTORIAL IS NO LONGER VALID on the `develop` branch after the `2022.w01` tag.**
+**2022/03/08: CAUTION, THIS TUTORIAL IS NO LONGER VALID on the `develop` branch after the `2022.w01` tag.**
 
-> **2022/03/08: CAUTION, THE LAST VALID TAG on `develop` branch is `2021.w51_c`.**
+**2022/03/08: CAUTION, THE LAST VALID TAG on `develop` branch is `2021.w51_c`.**
 
 **Table of Contents**
 
 [[_TOC_]]
 
-## 1. Environment 
+# 1. Environment #
 
 3 servers are used in this deployment. You can use Virtual Machines instead of each server; like it is done in the CI process.
 
@@ -18,17 +30,17 @@
 
 Example of L2 nFAPI Simulator testing environment:
 
-![L2-sim-S1-3-host-deployment](../images/L2-sim-S1-3-host-deployment.png)
+<img src="./images/L2-sim-S1-3-host-deployment.png" alt="" border=3>
 
-> Note that the IP addresses are indicative and need to be adapted to your environment.
+Note that the IP addresses are indicative and need to be adapted to your environment.
 
-## 2. Prepare the EPC 
+# 2. Prepare the EPC #
 
 Create the environment for the EPC and register all **USIM** information into the **HSS** database.
 
 If you are using OAI-EPC ([see on GitHub](https://github.com/OPENAIRINTERFACE/openair-epc-fed)), build **HSS/MME/SPGW** and create config files.
 
-## 3. Retrieve the OAI eNB-UE source code 
+# 3. Retrieve the OAI eNB-UE source code #
 
 At the time of writing, the tag used in the `develop` branch to do this documentation was `2020.w16`.
 
@@ -50,7 +62,7 @@ cd ue_folder
 git checkout develop
 ```
 
-## 4. Setup of the USIM information in UE folder 
+# 4. Setup of the USIM information in UE folder #
 
 ```bash
 $ ssh sudousername@machineC
@@ -106,11 +118,11 @@ UE1: // <- Edit here
 
 You can repeat the operation for as many users you want to test with.
 
-## 5. Setup of the Configuration files 
+# 5. Setup of the Configuration files #
 
-> **CAUTION: both proposed configuration files resides in the ci-scripts realm. You can copy them but you CANNOT push any modification on these 2 files as part of an MR without informing the CI team.**
+**CAUTION: both proposed configuration files resides in the ci-scripts realm. You can copy them but you CANNOT push any modification on these 2 files as part of an MR without informing the CI team.**
 
-### 5.1. The eNB Configuration file 
+## 5.1. The eNB Configuration file ##
 
 ```bash
 $ ssh sudousername@machineB
@@ -136,8 +148,7 @@ MACRLCs = (
 );
 ```
 
-If you are testing more than 16 UEs, a proper setting on the RUs is necessary. 
-> **Note that this part is NOT present in the original configuration file**.
+If you are testing more than 16 UEs, a proper setting on the RUs is necessary. **Note that this part is NOT present in the original configuration file**.
 
 ```
 RUs = (
@@ -172,7 +183,7 @@ Last, the S1 interface shall be properly set.
     };
 ```
 
-### 5.2. The UE Configuration file 
+## 5.2. The UE Configuration file ##
 
 ```bash
 $ ssh sudousername@machineB
@@ -197,11 +208,11 @@ L1s = (
 );
 ```
 
-## 6. Build OAI UE and eNodeB 
+# 6. Build OAI UE and eNodeB #
 
-See [Build documentation](../BUILD.md).
+See [Build documentation](./BUILD.md).
 
-## 7. Start EPC 
+# 7. Start EPC #
 
 Start the EPC on machine `A`.
 
@@ -210,7 +221,7 @@ $ ssh sudousername@machineA
 # Start the EPC
 ```
 
-## 8. Start the eNB 
+# 8. Start the eNB #
 
 In the first terminal (the one you used to build the eNB):
 
@@ -224,7 +235,7 @@ If you don't use redirection, you can test but many logs are printed on the cons
 
 We do recommend the redirection in steady mode once your setup is correct.
 
-## 9. Start the UE 
+# 9. Start the UE #
 
 In the second terminal (the one you used to build the UE):
 
@@ -274,7 +285,7 @@ oaitun_uem1 Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-
 
 Having the 4 oaitun_ue tunnel interfaces up and with an allocated address means the connection with EPC went alright.
 
-## 10. Test with ping 
+# 10. Test with ping #
 
 In a third terminal, after around 10 seconds, the UE(s) shall be connected to the eNB: Check with ifconfig
 
@@ -288,15 +299,15 @@ $ ping -c 20 192.172.0.5
 
 iperf operations can also be performed.
 
-## 11. Limitations 
+# 11. Limitations #
 
 
 ----
 
 [oai wiki home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
 
-[oai softmodem features](../setup/FEATURE_SET.md)
+[oai softmodem features](FEATURE_SET.md)
 
-[oai softmodem build procedure](../BUILD.md)
+[oai softmodem build procedure](BUILD.md)
 
 [L2 nfapi simulator](L2NFAPI.md)

doc/LDPC_OFFLOAD_SETUP.md

@@ -1,53 +1,65 @@
-# OAI LDPC offload (O-RAN AAL/DPDK BBDEV)
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">OAI LDPC offload (O-RAN AAL/DPDK BBDEV)</font></b>
+    </td>
+  </tr>
+</table>
 
 **Table of Contents**
 
 [[_TOC_]]
 
 This documentation describes the integration of LDPC coding for lookaside acceleration using O-RAN AAL/DPDK BBDEV in OAI, along with its usage.
-For details on the implementation, please consult the [developer notes](../../openair1/PHY/CODING/nrLDPC_coding/nrLDPC_coding_aal/README.md).
+For details on the implementation, please consult the [developer notes](../openair1/PHY/CODING/nrLDPC_coding/nrLDPC_coding_aal/README.md).
 
-## Requirements
+# Requirements
 
 In principle, any lookaside LDPC accelerator supporting the O-RAN AAL/DPDK BBDEV should work.
 However, the current implementation has only been validated for the Xilinx T2, Intel ACC100, and Intel ACC200 (VRB1).
 Therefore, your mileage may vary when using other BBDEV devices as there may be some hardware-specific changes required -- contributions are welcome!
 
-### DPDK Version Requirements
+## DPDK Version Requirements
 
 The following DPDK versions are supported:
 - For the Xilinx T2 card, DPDK20.11+ is supported.
 - As for the Intel ACC100/ACC200, only DPDK22.11+ is supported.
 
-### Tested Devices/ DPDK versions
+## Tested Devices/ DPDK versions
 
-#### Xilinx T2
+### Xilinx T2
 
 - DPDK20.11.9*.
 - DPDK22.11.7*.
 > Note: FPGA bitstream image and the corresponding patch file (e.g., `ACCL_BBDEV_DPDK20.11.3_ldpc_3.1.918.patch` for DPDK20.11) from Accelercomm required.
 
-#### Intel ACC100
+### Intel ACC100
 
 - DPDK22.11.7*.
 - DPDK23.11.3*.
 - DPDK24.11.2.
 > Note: [Patch]((https://github.com/DPDK/dpdk/commit/fdde63a1dfc129d0a510a831aa98253b36a2a1cd)) required for pre-DPDK24.11 versions when using the Intel ACC100.
 
-#### Intel ACC200 (also known as VRB1)
+### Intel ACC200 (also known as VRB1)
 - DPDK22.11.7.
 - DPDK23.11.3.
 - DPDK24.11.2.
 
-## System Setup
-### DPDK installation
+# System Setup
+## DPDK installation
 
 > Important: 
 > - If you are using the Xilinx T2 card, you will need to apply the vendor-supplied patches before compiling DPDK. 
 > - If you are using the Intel ACC100, you will need to [patch](https://github.com/DPDK/dpdk/commit/fdde63a1dfc129d0a510a831aa98253b36a2a1cd) the ACC100's driver if you are using DPDK22.11 or DPDK23.11. 
 
 
-Refer to the guide [here](ORAN_FHI7.2_Tutorial.md?ref_type=heads#dpdk-data-plane-development-kit) to install, and then validate your DPDK installation.
+Refer to the guide [here](./ORAN_FHI7.2_Tutorial.md?ref_type=heads#dpdk-data-plane-development-kit) to install, and then validate your DPDK installation.
 
 <details open> 
 <summary> Notes on DPDK patching/installation for Xilinx T2. </summary>
@@ -77,9 +89,9 @@ sudo ldconfig
 ```
 </details>
 
-### System configuration
+## System configuration
 
-#### Setting up Hugepages
+### Setting up Hugepages
 
 First, we must setup hugepages on the system.
 In our setup, we setup 16 of the 1G hugepages.
@@ -89,7 +101,7 @@ Apart from 1G, 2MB hugepages works too, but make sure to allocate a sufficient n
 # sudo dpdk-hugepages.py -p 1G --setup 16G
 ```
 
-#### Locating the Accelerator
+### Locating the Accelerator
 
 Next, we check whether our system can detect our accelerator using `dpdk-devbind.py`.
 You should see Baseband devices detected by DPDK, as follows:
@@ -105,14 +117,14 @@ Baseband devices using DPDK-compatible driver
 As you can see here, our Intel ACC200 has the address of `0000:f7:00.0`.
 Depending on the accelerator you are using, the address may vary.
 
-#### Loading VFIO-PCI and enabling SR-IOV
+### Loading VFIO-PCI and enabling SR-IOV
 Following, make sure to load the `vfio-pci` kernel modules and ensure that SR-IOV is enabled.
 
 ```
 # sudo modprobe vfio-pci enable_sriov=1 disable_idle_d3=1
 ```
 
-#### Binding the Accelerator with `vfio-pci`
+### Binding the Accelerator with `vfio-pci`
 
 Lastly, we bind our accelerator with the `vfio-pci` driver.
 ```
@@ -122,7 +134,7 @@ Lastly, we bind our accelerator with the `vfio-pci` driver.
 > Note: For the Xilinx T2, we can use this device directly.
 If you use an Intel vRAN accelerator, read on.
 
-#### Additional Steps for Intel vRAN Accelerators
+### Additional Steps for Intel vRAN Accelerators
 
 > IMPORTANT NOTE: 
 > - Currently, we only support using the Virtual Functions (VFs) of the Intel vRAN accelerators, but not the Physical Function (PF). 
@@ -130,7 +142,7 @@ If you use an Intel vRAN accelerator, read on.
 
 If you are using an Intel vRAN accelerator, you will need to use the [pf_bb_config](https://github.com/intel/pf-bb-config) tool to configure the accelerator beforehand. 
 
-##### pf_bb_config
+#### pf_bb_config
 For more details, please consult the `pf_bb_config` README.
 
 ```
@@ -152,7 +164,7 @@ VRB1 PF [0000:f7:00.0] configuration complete!
 Log file = /var/log/pf_bb_cfg_0000:f7:00.0.log
 ```
 
-##### Creating VFs
+#### Creating VFs
 
 Finally, we create the VF(s) for our accelerator. 
 In this example, we only create one SR-IOV VF.
@@ -178,7 +190,7 @@ Baseband devices using DPDK-compatible driver
 ...
 ```
 
-## Building OAI with ORAN-AAL
+# Building OAI with ORAN-AAL
 OTA deployment is precisely described in the following tutorial:
 - [NR_SA_Tutorial_COTS_UE](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop/doc/NR_SA_Tutorial_COTS_UE.md)
 Instead of section *3.2 Build OAI gNB* from the tutorial, run the following commands:
@@ -206,7 +218,7 @@ The selection of the library to compile is done using `--build-lib ldpc_aal`.
 
 > Note: The required DPDK poll mode driver has to be present on the host machine and required DPDK version has to be installed on the host, prior to building OAI.
 
-## O-RAN AAL DPDK EAL parameters
+# O-RAN AAL DPDK EAL parameters
 To configure O-RAN AAL/DPDK BBDEV, you can set the following parameters via the command line of PHY simulators or nr-softmodem:
 
 > Note: the group parameter name has been renamed from `nrLDPC_coding_t2` to
@@ -242,14 +254,14 @@ loader : {
 };
 ```
 
-## Running OAI with O-RAN AAL
+# Running OAI with O-RAN AAL
 
 In general, to offload of the channel coding to the LDPC accelerator, we use use the `--loader.ldpc.shlibversion _aal` option.
 Reminder, if you are using the Xilinx T2 card, make sure to set `--nrLDPC_coding_aal.is_t2 1`.
 
-### 5G PHY simulators
+## 5G PHY simulators
 
-#### nr_ulsim
+### nr_ulsim
 
 Example command:
 ```bash
@@ -258,7 +270,7 @@ source oaienv
 cd cmake_targets/ran_build/build
 sudo ./nr_ulsim -n100 -s20 -m20 -r273 -R273 --loader.ldpc.shlibversion _aal --nrLDPC_coding_aal.dpdk_dev 0000:f7:00.1 --nrLDPC_coding_aal.dpdk_core_list 0-1 --nrLDPC_coding_aal.vfio_vf_token 00112233-4455-6677-8899-aabbccddeeff
 ```
-#### nr_dlsim
+### nr_dlsim
 
 Example command:
 ```bash
@@ -268,9 +280,9 @@ cd cmake_targets/ran_build/build
 sudo ./nr_dlsim -n300 -s30 -R 106 -e 27 --loader.ldpc.shlibversion _aal --nrLDPC_coding_aal.dpdk_dev 0000:f7:00.1 --nrLDPC_coding_aal.dpdk_core_list 0-1 --nrLDPC_coding_aal.vfio_vf_token 00112233-4455-6677-8899-aabbccddeeff
 ```
 
-### OTA test
+## OTA test
 
-#### Running OAI gNB with USRP B210/FHI72
+### Running OAI gNB with USRP B210/FHI72
 
 When running the gNB **with FHI 7.2**, it is not necessary to provide the `--nrLDPC_coding_aal.dpdk_core_list` argument
 since the core list specified for FHI 7.2 will be used for DPDK.
@@ -284,9 +296,9 @@ cd cmake_targets/ran_build/build
 sudo ./nr-softmodem -O ~/gnb.conf --loader.ldpc.shlibversion _aal --nrLDPC_coding_aal.dpdk_dev 0000:f7:00.1 --nrLDPC_coding_aal.dpdk_core_list 14-15 --nrLDPC_coding_aal.vfio_vf_token 00112233-4455-6677-8899-aabbccddeeff
 ```
 
-## Known Issue(s)
+# Known Issue(s)
 
-### Potential Low Throughput
+## Potential Low Throughput
 
 The current implementation has been tested to work in an end-to-end setup and is functional. 
 However, depending on the accelerator in use,

doc/NR_NFAPI_archi.md

@@ -4,18 +4,18 @@ Their internal processing is broadly independent on which transport mechanism
 is responsible for exchanging data between the 2 components.
 
 To read more about the transport mechanisms available, and how to run the split, please refer to
-[this file](../L1_L2/nfapi.md).
+[this file](./nfapi.md).
 
 [[_TOC_]]
 
 # VNF/PNF Split
 
-The gNB is split into `VNF(L2+)` and `PNF(L1)`
+The gNB is split into VNF(L2+) and PNF(L1)
 
 These component are configured via the functions:
 
-- `configure_nr_nfapi_vnf()`
-- `configure_nr_nfapi_pnf()`
+- configure_nr_nfapi_vnf()
+- configure_nr_nfapi_pnf()
 
 These functions initialize the configuration appropriate for the transport mechanism selected ( setting the
 pack/unpack function pointers, as well as the appropriate send functions )
@@ -25,7 +25,7 @@ After this, a thread is created for the P5 receive loop, which initializes the t
 This created thread may be only for P5 messages, or P5 and P7, depending on the transport type
 
 - When using socket-based communication (which uses nFAPI encoding), the receiving loop for P7 messages is separate from
-  P5, it starts upon the `PNF_START` exchange
+  P5, it starts upon the PNF_START exchange
 - In the other transport mechanisms (WLS and nvIPC, which use FAPI encoding), the receiving loop is the same for P5 and
   P7 messages, the P7 configuration is done immediately after the P5 configuration.
 
@@ -40,8 +40,8 @@ them
 Upon the reception of a message (whether in its entirety or segmented in the case of nFAPI), the messages are sent to
 the appropriate handler:
 
-- `pnf_nr_handle_p5_message`
-- `vnf_nr_handle_p4_p5_message`
+- pnf_nr_handle_p5_message
+- vnf_nr_handle_p4_p5_message
 
 In each of these functions, there's a switch calling the appropriate handler according to the message ID, for example:
 
@@ -55,19 +55,18 @@ These loops are autonomous in their thread waiting incoming message.
 
 ## P7 interface main loop
 
-> Note
-> As explained before, the P7 reception loop is the same as the P5 messages when not using socket-based
+- Note: As explained before, the P7 reception loop is the same as the P5 messages when not using socket-based
   communication
 
 In this case, when the P5 interface receives appropriate message, it starts the p7 interface by launching a thread
 
-- On the PNF, this is done in the START.request handler ( `nr_start_request(...)` )
-- On the VNF, this is done in ( `configure_nr_p7_vnf(...)` )
+- On the PNF, this is done in the START.request handler ( nr_start_request(...) )
+- On the VNF, this is done in ( configure_nr_p7_vnf(...) )
 
 Much in the same way as when processing P5 messages, the following functions are called to unpack and process them:
 
-- `pnf_nr_handle_p7_message`
-- `vnf_nr_handle_p7_message`
+- pnf_nr_handle_p7_message
+- vnf_nr_handle_p7_message
 
 ```
 case NFAPI_NR_PHY_MSG_TYPE_SLOT_INDICATION:
@@ -78,11 +77,11 @@ case NFAPI_NR_PHY_MSG_TYPE_SLOT_INDICATION:
 ## P7 UL transmission by PNF
 
 RF samples are received, and decoding is done by the PNF using control data transmitted by the VNF to the PNF through
-downlink p7 messages (`UL_TTI.request` and `UL_DCI.request`).
+downlink p7 messages (UL_TTI.request and UL_DCI.request).
 
-After decoding, results are accumulated into the `gNB->UL_INFO` structure at the PNF.
+After decoding, results are accumulated into the gNB->UL_INFO structure at the PNF.
 
-The data in the UL_INFO struct is transmitted through the configured send function pointer (`send_p7_msg`), which packs 
+The data in the UL_INFO struct is transmitted through the configured send function pointer (send_p7_msg), which packs 
 the message into a buffer according to the encoding and sends it to the VNF
 
 ```
@@ -124,7 +123,7 @@ int nfapi_pnf_p7_nr_rach_ind(nfapi_pnf_p7_config_t* config, nfapi_nr_rach_indica
 Through the P7 reception loop, the VNF receives a buffer containing the messages, which it handles by the following
 process:
 
-- Unpack the header by use of the `hdr_unpack_func` function pointer
+- Unpack the header by use of the hdr_unpack_func function pointer
 - According to the Message ID in the header, send the buffer to the appropriate handler by use of a switch statement:
 
 ```
@@ -134,7 +133,7 @@ process:
 
 ```
 
-- In the handler function, unpack the entire message, by using the `unpack_func` function pointer.
+- In the handler function, unpack the entire message, by using the unpack_func function pointer.
 - If the unpack procedure is successful, call the previously configure callback for that message type:
 
 ```
@@ -156,20 +155,20 @@ process:
 
 ```
 
-`vnf_nr_dispatch_p7_message()` is the function that contains the switch on various message headers so that the appropriate
+vnf_nr_dispatch_p7_message() is the function that contains the switch on various message headers so that the appropriate
 unpack function is called.
 
 ## P7 DL Transmission by VNF
 
-DL messages are scheduled at the VNF, through `gNB_dlsch_ulsch_scheduler()`. `gNB_dlsch_ulsch_scheduler()` is called when
-handling a `SLOT.indication` message in `trigger_scheduler()`.
+DL messages are scheduled at the VNF, through gNB_dlsch_ulsch_scheduler(). gNB_dlsch_ulsch_scheduler() is called when
+handling a SLOT.indication message in trigger_scheduler().
 
-The function `trigger_scheduler(nfapi_nr_slot_indication_scf_t *slot_ind)` calls the functions `oai_nfapi_[DL P7 msg]_
-req()`, calling in turn call the `send_p7_msg` function pointer, which contain the logic to pack the message into a buffer
+The function trigger_scheduler(nfapi_nr_slot_indication_scf_t *slot_ind) calls the functions oai_nfapi_[DL P7 msg]_
+req(), calling in turn call the send_p7_msg function pointer, which contain the logic to pack the message into a buffer
 and send it to the PNF.
-Finally, `NR_UL_indication` is called to process the other P7 messages received from the PNF that were put in theire
+Finally, NR_UL_indication is called to process the other P7 messages received from the PNF that were put in theire
 respective queues.
-For example, the `TX_DATA.request` message is sent in the following manner:
+For example, the TX_DATA.request message is sent in the following manner:
 
 ```
   if (g_sched_resp.TX_req.Number_of_PDUs > 0)
@@ -224,13 +223,13 @@ graph TD
 
 ## P7 DL Reception at PNF
 
-Through the infinite loop `[while(pnf_p7->terminate == 0)]` running in `pnf_nr_p7_message_pump()`, the PNF receives and
+Through the infinite loop [while(pnf_p7->terminate == 0)] running in pnf_nr_p7_message_pump(), the PNF receives and
 unpacks the downlink P7 message received on its socket. Based on the unpacked message, the appropriate message
 structures are filled in the PNF, and these are used further down the pipeline for processing.
 Through the P7 reception loop, the PNF receives a buffer containing a P7 message from the VNF, which it processes the
 following way:
 
-- Unpack the header by use of the `hdr_unpack_func` function pointer
+- Unpack the header by use of the hdr_unpack_func function pointer
 - According to the Message ID in the header, send the buffer to the appropriate handler by use of a switch statement:
 
 ```
@@ -260,8 +259,8 @@ following way:
       
   ```
 
-- The messages are later processed in the `NR_slot_indication` function, which is called in the `tx_func function (
-  L1_tx_thread )`
+- The messages are later processed in the NR_slot_indication function, which is called in the tx_func function (
+  L1_tx_thread )
 
 ## PNF functional flowchart
 

doc/NR_SA_Tutorial_COTS_UE.md

@@ -1,10 +1,22 @@
-# OAI 5G NR SA tutorial with COTS UE
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">OAI 5G NR SA tutorial with COTS UE</font></b>
+    </td>
+  </tr>
+</table>
 
 **Table of Contents**
 
 [[_TOC_]]
 
-##  1. Scenario
+#  1. Scenario
 In this tutorial we describe how to configure and run a 5G end-to-end setup with OAI CN5G, OAI gNB and COTS UE.
 
 Minimum hardware requirements:
@@ -24,15 +36,15 @@ Minimum hardware requirements:
     - Firmware version of Quectel MUST be equal or higher than **RM500QGLABR11A06M4G**
 
 
-## 2. OAI CN5G
+# 2. OAI CN5G
 
-### 2.1 OAI CN5G pre-requisites
+## 2.1 OAI CN5G pre-requisites
 
 Please install and configure OAI CN5G as described here:
 [OAI CN5G](NR_SA_Tutorial_OAI_CN5G.md)
 
 
-### 2.2  SIM Card
+## 2.2  SIM Card
 Program UICC/SIM Card with [Open Cells Project](https://open-cells.com/) programming tool [uicc-v3.3](https://open-cells.com/d5138782a8739209ec5760865b1e53b0/uicc-v3.3.tgz).
 
 ```bash
@@ -40,11 +52,11 @@ sudo ./program_uicc --adm 12345678 --imsi 001010000000001 --isdn 00000001 --acc
 ```
 
 
-## 3. OAI gNB
+# 3. OAI gNB
 
-### 3.1 OAI gNB pre-requisites
+## 3.1 OAI gNB pre-requisites
 
-#### Build UHD from source
+### Build UHD from source
 ```bash
 # https://files.ettus.com/manual/page_build_guide.html
 sudo apt install -y autoconf automake build-essential ccache cmake cpufrequtils doxygen ethtool g++ git inetutils-tools libboost-all-dev libncurses-dev libusb-1.0-0 libusb-1.0-0-dev libusb-dev python3-dev python3-mako python3-numpy python3-requests python3-scipy python3-setuptools python3-ruamel.yaml
@@ -63,7 +75,7 @@ sudo ldconfig
 sudo uhd_images_downloader
 ```
 
-### 3.2 Build OAI gNB
+## 3.2 Build OAI gNB
 
 ```bash
 # Get openairinterface5g source code
@@ -80,42 +92,42 @@ cd ~/openairinterface5g/cmake_targets
 ./build_oai -w USRP --ninja --gNB -C
 ```
 
-## 4. Run OAI CN5G and OAI gNB
+# 4. Run OAI CN5G and OAI gNB
 
-### 4.1 Run OAI CN5G
+## 4.1 Run OAI CN5G
 
 ```bash
 cd ~/oai-cn5g
 docker compose up -d
 ```
 
-### 4.2 Run OAI gNB
+## 4.2 Run OAI gNB
 
 **Note:** From tag `2024.w45`, OAI gNB runs by default in standalone (SA) mode.  
 In earlier versions the default mode was non-standalone (NSA).  
 If you are using an earlier version than `2024.w45`, you should add the `--sa` argument to the sample commands below to obtain a correct behavior.
 
-#### USRP B210
+### USRP B210
 ```bash
 cd ~/openairinterface5g/cmake_targets/ran_build/build
 sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf -E --continuous-tx
 ```
-#### USRP N300
+### USRP N300
 ```bash
 cd ~/openairinterface5g/cmake_targets/ran_build/build
 sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band77.fr1.273PRB.2x2.usrpn300.conf --usrp-tx-thread-config 1
 ```
 
-#### USRP X300
+### USRP X300
 ```bash
 cd ~/openairinterface5g/cmake_targets/ran_build/build
 sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band77.fr1.273PRB.2x2.usrpn300.conf --usrp-tx-thread-config 1 -E --continuous-tx
 ```
 
-## 5. Run UE
-### 5.1 Testing with Quectel RM500Q
+# 5. Run UE
+## 5.1 Testing with Quectel RM500Q
 
-#### 5.1.1 Setup Quectel
+### 5.1.1 Setup Quectel
 With [PuTTY](https://the.earth.li/~sgtatham/putty/latest/w64/putty.exe), send the following AT commands to the module using a serial interface (ex: COM2) at 115200 bps:
 ```bash
 # MUST be sent at least once everytime there is a firmware upgrade!
@@ -129,7 +141,7 @@ AT+CGPADDR=1
 AT+QPING=1,"openairinterface.org"
 ```
 
-#### 5.1.2 Ping test
+### 5.1.2 Ping test
 - UE host
 ```bash
 ping 192.168.70.135 -t -S 12.1.1.2
@@ -139,7 +151,7 @@ ping 192.168.70.135 -t -S 12.1.1.2
 docker exec -it oai-ext-dn ping 12.1.1.2
 ```
 
-#### 5.1.3 Downlink iPerf test
+### 5.1.3 Downlink iPerf test
 - UE host
     - Download iPerf for Microsoft Windows from [here](https://iperf.fr/download/windows/iperf-2.0.9-win64.zip).
     - Extract to Desktop and run with Command Prompt:
@@ -153,11 +165,11 @@ iperf -s -u -i 1 -B 12.1.1.2
 docker exec -it oai-ext-dn iperf -u -t 86400 -i 1 -fk -B 192.168.70.135 -b 100M -c 12.1.1.2
 ```
 
-## 6. Advanced configurations (optional)
+# 6. Advanced configurations (optional)
 
-See also the [dedicated document on performance tuning](../testing/tuning_and_security.md).
+See also the [dedicated document on performance tuning](./tuning_and_security.md).
 
-### 6.1 USRP N300 and X300 Ethernet Tuning
+## 6.1 USRP N300 and X300 Ethernet Tuning
 
 Please also refer to the official [USRP Host Performance Tuning Tips and Tricks](https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks) tuning guide.
 
@@ -179,12 +191,12 @@ sudo sysctl -w net.core.rmem_default=62500000
 sudo ethtool -G enp1s0f0 tx 4096 rx 4096
 ```
 
-### 6.2 Real-time performance workarounds
+## 6.2 Real-time performance workarounds
 - Enable Performance Mode `sudo cpupower idle-set -D 0`
 - If you get real-time problems on heavy UL traffic, reduce the maximum UL MCS using an additional command-line switch: `--MACRLCs.[0].ul_max_mcs 14`.
 - You can also reduce the number of LDPC decoder iterations, which will make the LDPC decoder take less time: `--L1s.[0].max_ldpc_iterations 4`.
 
-### 6.3 Uplink issues related with noise on the DC carriers
+## 6.3 Uplink issues related with noise on the DC carriers
 
 With devices like the USRP N300 and especially the X300, there is noise in the DC carriers: this can cause uplink PRBs that overlap with the DC carrier to experience interference and increased noise.
 
@@ -204,7 +216,7 @@ There are two main points to keep in mind:
 
 The option `ul_prbblacklist` is more relevant when using high-bandwidth configurations (e.g., 100 MHz) with devices like the USRP N310 or X310: in this scenarios, `--tune-offset` could not be sufficient to get rid of the noisy PRBs in the center frequency entirely, because it is not possible to shift the DC carriers out of the bandwidth (tune offset shall be smaller than half the bandwidth of the board).
 
-### 6.3.1 Tune offset
+## 6.3.1 Tune offset
 
 The value passed to the command line option `--tune-offset <Hz>` will be calling an UHD API. It represents the LO offset frequency in Hz.
 The API (tune_request_t class) will send a frequency tuning request (`tx_tune_req`, `rx_tune_req`) to the USRP device, in order to configure the target baseband tx/rx frequency, therefore shifting the tx/rx signal spectrum.
@@ -213,11 +225,11 @@ The value passed to this option should be ideally equal to half the operational
 
 A visual representation of the impact of tune-offset with a 120 MHz bandwidth daughterboard:
 
-![Tune_Offset](../images/USRP_tune_offset.png)
+![Tune_Offset](./images/USRP_tune_offset.png)
 
-### 6.3.2 UL PRBs Blacklist
+## 6.3.2 UL PRBs Blacklist
 
 To use this option, in the configuration file, e.g. 100 MHz bandwidth setup: `ul_prbblacklist = "135,136,137,138"`.
 
-### 6.4 Lower latency on user plane
+## 6.4 Lower latency on user plane
 - To lower latency on the user plane, you can force the UE to be scheduled constantly in uplink: `--MACRLCs.[0].ulsch_max_frame_inactivity 0` .

doc/NR_SA_Tutorial_OAI_CN5G.md

@@ -1,10 +1,22 @@
-# OAI 5G NR SA tutorial: setting up OAI CN5G
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">OAI 5G NR SA tutorial: setting up OAI CN5G</font></b>
+    </td>
+  </tr>
+</table>
 
 **Table of Contents**
 
 [[_TOC_]]
 
-##  1. Scenario
+#  1. Scenario
 In this tutorial we describe how to configure and run a 5G end-to-end setup with OAI CN5G, OAI gNB and COTS UE.
 
 Minimum hardware requirements:
@@ -13,9 +25,9 @@ Minimum hardware requirements:
     - CPU: 8 cores x86_64 @ 3.5 GHz
     - RAM: 32 GB
 
-## 2. OAI CN5G
+# 2. OAI CN5G
 
-### 2.1 OAI CN5G pre-requisites
+## 2.1 OAI CN5G pre-requisites
 
 ```bash
 sudo apt install -y git net-tools putty
@@ -35,7 +47,7 @@ sudo usermod -a -G docker $(whoami)
 reboot
 ```
 
-### 2.2 OAI CN5G configuration files
+## 2.2 OAI CN5G configuration files
 Download and copy configuration files:
 ```bash
 wget -O ~/oai-cn5g.zip https://gitlab.eurecom.fr/oai/openairinterface5g/-/archive/develop/openairinterface5g-develop.zip?path=doc/tutorial_resources/oai-cn5g
@@ -44,31 +56,31 @@ mv ~/openairinterface5g-develop-doc-tutorial_resources-oai-cn5g/doc/tutorial_res
 rm -r ~/openairinterface5g-develop-doc-tutorial_resources-oai-cn5g ~/oai-cn5g.zip
 ```
 
-### 2.3 Pull OAI CN5G docker images
+## 2.3 Pull OAI CN5G docker images
 
 ```bash
 cd ~/oai-cn5g
 docker compose pull
 ```
 
-## 3. Run OAI CN5G
-### 3.1 Start OAI CN5G
+# 3. Run OAI CN5G
+## 3.1 Start OAI CN5G
 ```bash
 cd ~/oai-cn5g
 docker compose up -d
 ```
 
-### 3.2 Stop OAI CN5G
+## 3.2 Stop OAI CN5G
 ```bash
 cd ~/oai-cn5g
 docker compose down
 ```
 
-## 4. Run 5G NR SA end-to-end setup with OAI gNB
-### 4.1 Testing with COTS UE
+# 4. Run 5G NR SA end-to-end setup with OAI gNB
+## 4.1 Testing with COTS UE
 Please check this link:
 [Testing with OAI gNB and COTS UE](NR_SA_Tutorial_COTS_UE.md)
 
-### 4.2 Testing with OAI nrUE
+## 4.2 Testing with OAI nrUE
 Please check this link:
 [Testing with OAI gNB and OAI nrUE](NR_SA_Tutorial_OAI_nrUE.md)

doc/NR_SA_Tutorial_OAI_multi_UE.md

@@ -1,30 +1,42 @@
-# OAI 5G NR SA tutorial to deploy multiple OAI nrUE
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">OAI 5G NR SA tutorial to deploy multiple OAI nrUE</font></b>
+    </td>
+  </tr>
+</table>
 
 **Table of Contents**
 
 [[_TOC_]]
 
-## Scenario
+# Scenario
 This tutorial is about how to configure and run multiple OAI nrUE in the same end-to-end OAI 5G setup with RFsimulator.
 
-## Pre-requisites
+# Pre-requisites
 
 This tutorial is assuming that OAI CN5G and OAI RAN are already deployed. To learn how to deploy and run a basic setup with OAI nrUE, please refer to [NR_SA_Tutorial_OAI_nrUE.md](NR_SA_Tutorial_OAI_nrUE.md).
 
 Also, it is suggested to get some knowledge on how the channel simulation with OAI RFsimulator works. Please refer to the following documentation to learn about the relevant topics discussed:
 
-- RFsimulator tutorial [rfsimulator/README.md](../../radio/rfsimulator/README.md)
-- Channel simulation with OAI [channel_simulation.md](../../openair1/SIMULATION/TOOLS/DOC/channel_simulation.md)
-- Telnet server usage [telnetusage.md](../../common/utils/telnetsrv/DOC/telnetusage.md).
+- RFsimulator tutorial [rfsimulator/README.md](../radio/rfsimulator/README.md)
+- Channel simulation with OAI [channel_simulation.md](../openair1/SIMULATION/TOOLS/DOC/channel_simulation.md)
+- Telnet server usage [telnetusage.md](../common/utils/telnetsrv/DOC/telnetusage.md).
 
-## Run multiple UEs in RFsimulator
+# Run multiple UEs in RFsimulator
 
-### Multiple nrUEs with namespaces
+## Multiple nrUEs with namespaces
 
 Important notes:
 
 * This should be run on the same host as the OAI gNB
-* Use the script [multi_ue.sh](../../tools/scripts/multi-ue.sh) to make namespaces for multiple UEs.
+* Use the script [multi_ue.sh](../tools/scripts/multi-ue.sh) to make namespaces for multiple UEs.
 * For each UE, a namespace shall be created, each one has a different address that will be used as rfsim server address
 * Each UE shall have a different IMSI, which shall be present in the relevant tables of the MySQL database
 * Each UE shall run a telnet server on a different port, with command line option `--telnetsrv.listenport`
@@ -57,7 +69,7 @@ Important notes:
 
 in the command above, please note that the IMSI and the telnet port changed.
 
-### Running Multiple UEs with Docker
+## Running Multiple UEs with Docker
 
 1. Make sure OAI nrUE image is pulled:
 
@@ -65,7 +77,7 @@ in the command above, please note that the IMSI and the telnet port changed.
    docker pull oaisoftwarealliance/oai-nr-ue:latest
    ```
 
-2. Configure your setup by editing the Docker compose file e.g. in [docker-compose.yaml](../../ci-scripts/yaml_files/5g_rfsimulator/docker-compose.yaml).
+2. Configure your setup by editing the Docker compose file e.g. in [docker-compose.yaml](../ci-scripts/yaml_files/5g_rfsimulator/docker-compose.yaml).
 
 3. Deploy the UEs, e.g. for 3 UEs:
 
@@ -98,10 +110,10 @@ in the command above, please note that the IMSI and the telnet port changed.
    docker compose down -v
    ```
 
-## Further reading
+# Further reading
 
 For more details and scenarios, refer to the following files:
 
-* [RFSIM deployment in the CI](../../ci-scripts/yaml_files/5g_rfsimulator/README.md)
-* [E1 deployment in the CI](../../ci-scripts/yaml_files/5g_rfsimulator_e1/README.md)
-* [Docker documentation](../../docker/README.md)
+* [RFSIM deployment in the CI](../ci-scripts/yaml_files/5g_rfsimulator/README.md)
+* [E1 deployment in the CI](../ci-scripts/yaml_files/5g_rfsimulator_e1/README.md)
+* [Docker documentation](../docker/README.md)

doc/NR_SA_Tutorial_OAI_nrUE.md

@@ -1,10 +1,22 @@
-# OAI 5G NR SA tutorial with OAI nrUE
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">OAI 5G NR SA tutorial with OAI nrUE</font></b>
+    </td>
+  </tr>
+</table>
 
 **Table of Contents**
 
 [[_TOC_]]
 
-##  1. Scenario
+#  1. Scenario
 In this tutorial we describe how to configure and run a 5G end-to-end setup with OAI CN5G, OAI gNB and OAI nrUE.
 
 Minimum hardware requirements:
@@ -20,19 +32,19 @@ Minimum hardware requirements:
     - Please identify the network interface(s) on which the USRP is connected and update the gNB configuration file
 
 
-## 2. OAI CN5G
+# 2. OAI CN5G
 
-### 2.1 OAI CN5G pre-requisites
+## 2.1 OAI CN5G pre-requisites
 
 Please install and configure OAI CN5G as described here:
 [OAI CN5G](NR_SA_Tutorial_OAI_CN5G.md)
 
 
-## 3. OAI gNB and OAI nrUE
+# 3. OAI gNB and OAI nrUE
 
-### 3.1 OAI gNB and OAI nrUE pre-requisites
+## 3.1 OAI gNB and OAI nrUE pre-requisites
 
-#### Build UHD from source
+### Build UHD from source
 ```bash
 # https://files.ettus.com/manual/page_build_guide.html
 sudo apt install -y autoconf automake build-essential ccache cmake cpufrequtils doxygen ethtool g++ git inetutils-tools libboost-all-dev libncurses-dev libusb-1.0-0 libusb-1.0-0-dev libusb-dev python3-dev python3-mako python3-numpy python3-requests python3-scipy python3-setuptools python3-ruamel.yaml
@@ -51,7 +63,7 @@ sudo ldconfig
 sudo uhd_images_downloader
 ```
 
-### 3.2 Build OAI gNB and OAI nrUE
+## 3.2 Build OAI gNB and OAI nrUE
 
 ```bash
 # Get openairinterface5g source code
@@ -71,59 +83,59 @@ cd ~/openairinterface5g/cmake_targets
 ./build_oai -w USRP --ninja --nrUE --gNB --build-lib "nrscope" -C
 ```
 
-## 4. Run OAI CN5G and OAI gNB
+# 4. Run OAI CN5G and OAI gNB
 
-### 4.1 Run OAI CN5G
+## 4.1 Run OAI CN5G
 
 ```bash
 cd ~/oai-cn5g
 docker compose up -d
 ```
 
-### 4.2 Run OAI gNB
+## 4.2 Run OAI gNB
 
 **Note:** From tag `2024.w45`, OAI gNB runs by default in standalone (SA) mode.  
 In earlier versions the default mode was non-standalone (NSA).  
 If you are using an earlier version than `2024.w45`, you should add the `--sa` argument to the sample commands below to obtain a correct behavior.
 
-#### USRP B210
+### USRP B210
 ```bash
 cd ~/openairinterface5g/cmake_targets/ran_build/build
 sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf --gNBs.[0].min_rxtxtime 6 -E --continuous-tx
 ```
-#### USRP N300
+### USRP N300
 ```bash
 cd ~/openairinterface5g/cmake_targets/ran_build/build
 sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band77.fr1.273PRB.2x2.usrpn300.conf --gNBs.[0].min_rxtxtime 6 --usrp-tx-thread-config 1
 ```
 
-#### USRP X300
+### USRP X300
 ```bash
 cd ~/openairinterface5g/cmake_targets/ran_build/build
 sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band77.fr1.273PRB.2x2.usrpn300.conf --gNBs.[0].min_rxtxtime 6 --usrp-tx-thread-config 1 -E --continuous-tx
 ```
 
-#### RFsimulator
+### RFsimulator
 ```bash
 cd ~/openairinterface5g/cmake_targets/ran_build/build
 sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf --gNBs.[0].min_rxtxtime 6 --rfsim
 ```
 
-#### RFsimulator in FR2
+### RFsimulator in FR2
 ```bash
 cd ~/openairinterface5g/cmake_targets/ran_build/build
 sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band257.u3.32prb.usrpx410.conf --rfsim
 ```
 
-## 5. OAI UE
+# 5. OAI UE
 
-### 5.1 Run OAI nrUE
+## 5.1 Run OAI nrUE
 
 **Note:** From tag `2024.w45`, OAI nrUE runs by default in standalone (SA) mode.  
 In earlier versions the default mode was non-standalone (NSA).  
 If you are using an earlier version than `2024.w45`, you should add the `--sa` argument to the sample commands below to obtain a correct behavior.
 
-#### USRP B210
+### USRP B210
 Important notes:
 - This should be run in a second Ubuntu 22.04 host, other than gNB
 - It only applies when running OAI gNB with USRP B210
@@ -134,7 +146,7 @@ cd ~/openairinterface5g/cmake_targets/ran_build/build
 sudo ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3619200000 --ue-fo-compensation -E --uicc0.imsi 001010000000001
 ```
 
-#### RFsimulator
+### RFsimulator
 Important notes:
 - This should be run on the same host as the OAI gNB
 - It only applies when running OAI gNB with RFsimulator
@@ -145,7 +157,7 @@ cd ~/openairinterface5g/cmake_targets/ran_build/build
 sudo ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3619200000 --uicc0.imsi 001010000000001 --rfsim
 ```
 
-#### RFsimulator in FR2
+### RFsimulator in FR2
 Important notes:
 - This should be run on the same host as the OAI gNB
 - It only applies when running OAI gNB with RFsimulator in FR2
@@ -156,11 +168,11 @@ cd ~/openairinterface5g/cmake_targets/ran_build/build
 sudo ./nr-uesoftmodem -r 32 --numerology 3 --band 257 -C 27533280000 --uicc0.imsi 001010000000001 --ssb 72 --rfsim
 ```
 
-#### Connection to an NG-Core
+### Connection to an NG-Core
 
 A configuration file can be fed to the nrUE command line in order to connect to the local NGC.
 
-The nrUE configuration file (e.g. [ue.conf](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/ue.conf)) is structured in a key-value format and contains the relevant UICC parameters that are necessary to authenticate the UE to the local 5GC. E.g.:
+The nrUE configuration file (e.g. [ue.conf](../targets/PROJECTS/GENERIC-NR-5GC/CONF/ue.conf)) is structured in a key-value format and contains the relevant UICC parameters that are necessary to authenticate the UE to the local 5GC. E.g.:
 
 ```shell
 uicc0 = {
@@ -195,15 +207,15 @@ More details available at [ci-scripts/yaml_files/5g_rfsimulator/README.md](../ci
 In earlier versions the default mode was non-standalone (NSA).  
 If you are using an earlier version than `2024.w45`, you should add the `--sa` argument to the sample commands above to obtain a correct behavior.
 
-### 5.2 End-to-end connectivity test
+## 5.2 End-to-end connectivity test
 - Ping test from the UE host to the CN5G
 ```bash
 ping 192.168.70.135 -I oaitun_ue1
 ```
 
-## 6. Advanced configurations (optional)
+# 6. Advanced configurations (optional)
 
-### 6.1 USRP N300 and X300 Ethernet Tuning
+## 6.1 USRP N300 and X300 Ethernet Tuning
 
 Please also refer to the official [USRP Host Performance Tuning Tips and Tricks](https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks) tuning guide.
 
@@ -225,20 +237,20 @@ sudo sysctl -w net.core.rmem_default=62500000
 sudo ethtool -G enp1s0f0 tx 4096 rx 4096
 ```
 
-### 6.2 Real-time performance workarounds
+## 6.2 Real-time performance workarounds
 - Enable Performance Mode `sudo cpupower idle-set -D 0`
 - If you get real-time problems on heavy UL traffic, reduce the maximum UL MCS using an additional command-line switch: `--MACRLCs.[0].ul_max_mcs 14`.
 - You can also reduce the number of LDPC decoder iterations, which will make the LDPC decoder take less time: `--L1s.[0].max_ldpc_iterations 4`.
 
-### 6.3 Uplink issues related with noise on the DC carriers
+## 6.3 Uplink issues related with noise on the DC carriers
 - There is noise on the DC carriers on N300 and especially the X300 in UL. To avoid their use or shift them away from the center to use more UL spectrum, use the `--tune-offset <Hz>` command line switch, where `<Hz>` is ideally half the bandwidth, or possibly less.
 
-### 6.4 Timing-related Problems
+## 6.4 Timing-related Problems
 - Sometimes, the nrUE would keep repeating RA procedure because of Msg3 failure at the gNB. If it happens, add the `-A` option at the nrUE and/or gNB side, e.g., `-A 45`. This modifies the timing advance (in samples). Adjust +/-5 if the issue persists.
 - This can be necessary since certain USRPs have larger signal delays than others; it is therefore specific to the used USRP model.
 - The x310 and B210 are found to work with the default configuration; N310 and x410 can benefit from setting this timing advance.
-- For example if the OAI UE uses the X410 and the gNB based on [Nvidia Aerial and Foxconn](Aerial_FAPI_Split_Tutorial.md) a timing advance of 90 has been found to work well.
+- For example if the OAI UE uses the X410 and the gNB based on [Nvidia Aerial and Foxconn](./Aerial_FAPI_Split_Tutorial.md) a timing advance of 90 has been found to work well.  
 
 
-### 6.5 Lower latency on user plane
+## 6.5 Lower latency on user plane
 - To lower latency on the user plane, you can force the UE to be scheduled constantly in uplink: `--MACRLCs.[0].ulsch_max_frame_inactivity 0` .

doc/ORAN_FHI7.2_Tutorial.md

@@ -1,10 +1,22 @@
-# OAI 7.2 Fronthaul Interface 5G SA Tutorial
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">OAI 7.2 Fronthaul Interface 5G SA Tutorial</font></b>
+    </td>
+  </tr>
+</table>
 
 **Table of Contents**
 
 [[_TOC_]]
 
-## Prerequisites
+# Prerequisites
 
 The hardware on which we have tried this tutorial:
 
@@ -75,14 +87,14 @@ Tested libxran releases:
 
 **Note**: The libxran driver of OAI identifies the above E release version as "5.1.0" (E is fifth letter, then 1.0), and the above F release as "6.1.0".
 
-### Configure your server
+## Configure your server
 
 1. Disable Hyperthreading (HT) in your BIOS. In all our servers HT is always disabled.
 2. We recommend you to start with a fresh installation of OS (either RHEL or Ubuntu). You have to install realtime kernel on your OS (Operating System). Based on your OS you can search how to install realtime kernel.
 3. Install realtime kernel for your OS
 4. Change the boot commands based on the below section. They can be performed either via `tuned` or via manually building the kernel
 
-#### CPU allocation
+### CPU allocation
 
 **This section is important to read, regardless of the operating system you are using.**
 
@@ -125,7 +137,7 @@ tuned-adm profile realtime
 
 **Checkout anyway the examples below.**
 
-#### One NUMA Node
+### One NUMA Node
 
 Below is the output of `/proc/cmdline` of a single NUMA node server,
 
@@ -141,7 +153,7 @@ isolcpus=0-15 nohz_full=0-15 rcu_nocbs=0-15 kthread_cpus=16-31 rcu_nocb_poll nos
 
 Example taken for AMD EPYC 9374F 32-Core Processor
 
-#### Two NUMA Nodes
+### Two NUMA Nodes
 
 Below is the output of `/proc/cmdline` of a two NUMA node server,
 
@@ -158,7 +170,7 @@ mitigations=off usbcore.autosuspend=-1 intel_iommu=on intel_iommu=pt selinux=0 e
 
 Example taken for Intel(R) Xeon(R) Gold 6354 CPU @ 3.00GHz
 
-#### Common
+### Common
 
 Configure your servers to maximum performance mode either via OS or in BIOS. If you want to disable CPU sleep state via OS then use the below command:
 
@@ -175,7 +187,7 @@ The above information we have gathered either from O-RAN documents or via our ow
 2. [O-RAN Cloud Platform Reference Designs 2.0,O-RAN.WG6.CLOUD-REF-v02.00,February 2021](https://orandownloadsweb.azurewebsites.net/specifications)
 
 
-### PTP configuration
+## PTP configuration
 
 **Note**: You may run OAI with O-RAN 7.2 Fronthaul without a RU attached (e.g. for benchmarking).
 In such case, you can skip PTP configuration and go to DPDK section.
@@ -253,7 +265,7 @@ ExecStart=/usr/sbin/phc2sys $OPTIONS
 WantedBy=multi-user.target
 ```
 
-#### Debugging PTP issues
+### Debugging PTP issues
 
 You can see these steps in case your ptp logs have erorrs or `rms` reported in `ptp4l` logs is more than 100ms.
 Beware that PTP issues may show up only when running OAI and XRAN. If you are using the `ptp4l` service, have a look back in time in the journal: `journalctl -u ptp4l.service -S <hours>:<minutes>:<seconds>`
@@ -271,7 +283,7 @@ timedatectl | grep NTP
 timedatectl set-ntp false
 ```
 
-### DPDK (Data Plane Development Kit)
+## DPDK (Data Plane Development Kit)
 
 Download DPDK version 20.11.9.
 
@@ -284,7 +296,7 @@ cd
 wget http://fast.dpdk.org/rel/dpdk-20.11.9.tar.xz
 ```
 
-#### DPDK Compilation and Installation
+### DPDK Compilation and Installation
 
 ```bash
 # Installing meson : it should pull ninja-build and compiler packages
@@ -299,7 +311,7 @@ ninja -C build
 sudo ninja install -C build
 ```
 
-#### Verify the installation is complete
+### Verify the installation is complete
 
 Check if the LD cache contains the DPDK Shared Objects after update:
 
@@ -353,7 +365,7 @@ export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib64/pkgconfig/
 pkg-config --libs libdpdk --static
 ```
 
-#### If you want to de-install this version of DPDK
+### If you want to de-install this version of DPDK
 
 Go back to the version folder you used to build and install
 
@@ -362,7 +374,7 @@ cd ~/dpdk-stable-20.11.9
 sudo ninja deinstall -C build
 ```
 
-## Build OAI-FHI gNB
+# Build OAI-FHI gNB
 
 Clone OAI code base in a suitable repository, here we are cloning in `~/openairinterface5g` directory,
 
@@ -371,11 +383,11 @@ git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git ~/openairinterfac
 cd ~/openairinterface5g/
 ```
 
-### Build ORAN Fronthaul Interface Library
+## Build ORAN Fronthaul Interface Library
 
 Download ORAN FHI DU library, checkout the correct version, and apply the correct patch (available in `oai_folder/cmake_targets/tools/oran_fhi_integration_patches`).
 
-#### E release
+### E release
 ```bash
 git clone https://gerrit.o-ran-sc.org/r/o-du/phy.git ~/phy
 cd ~/phy
@@ -383,7 +395,7 @@ git checkout oran_e_maintenance_release_v1.0
 git apply ~/openairinterface5g/cmake_targets/tools/oran_fhi_integration_patches/E/oaioran_E.patch
 ```
 
-#### F release
+### F release
 ```bash
 git clone https://gerrit.o-ran-sc.org/r/o-du/phy.git ~/phy
 cd ~/phy
@@ -414,7 +426,7 @@ WIRELESS_SDK_TOOLCHAIN=gcc RTE_SDK=~/dpdk-stable-20.11.9/ XRAN_DIR=~/phy/fhi_lib
 The shared library object `~/phy/fhi_lib/lib/build/libxran.so` must be present
 before proceeding.
 
-### For Arm targets only: Install the Arm RAN Acceleration library
+## For Arm targets only: Install the Arm RAN Acceleration library
 
 DU execution on Arm systems is yet not functional.
 This feature is intended to enable experiments and future improvements on Arm systems.
@@ -439,7 +451,7 @@ Once ArmRAL is configured at your convenience and built, you can install it:
 ninja install
 ```
 
-### Build OAI gNB
+## Build OAI gNB
 
 You can now proceed building OAI. You build it the same way as for other
 radios, providing option `-t oran_fhlib_5g`. Additionally, you need to provide
@@ -508,20 +520,20 @@ or with `cmake` like so
     cmake .. -GNinja -DOAI_FHI72=ON -Dxran_LOCATION=$HOME/phy/fhi_lib/lib -DOAI_FHI72_USE_POLLING=ON
     ninja oran_fhlib_5g
 
-## Configuration
+# Configuration
 
 RU and DU configurations have a circular dependency: you have to configure DU MAC address in the RU configuration and the RU MAC address, VLAN and Timing advance parameters in the DU configuration.
 
 **Note**: You may run OAI with O-RAN 7.2 Fronthaul without a RU attached (e.g. for benchmarking).
 In such case, skip RU configuration and only configure Network Interfaces, DPDK VFs and OAI configuration by using arbitrary values for RU MAC addresses and VLAN tags.
 
-### Configure the RU
+## Configure the RU
 
 Contact the RU vendor and get the configuration manual to understand the below commands. The below configuration only corresponds to the RU firmware version indicated at the start of this document. If your firmware version does not correspond to the indicated version, then please don't try these commands.
 
 **NOTE**: Please understand all the changes you are doing at the RU, especially if you are manipulating anything related to output power. 
 
-#### Benetel 650
+### Benetel 650
 
 The OAI configuration file [`gnb-du.sa.band77.273prb.fhi72.4x4-benetel650.conf`](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb-du.sa.band77.273prb.fhi72.4x4-benetel650.conf) corresponds to:
 - TDD pattern `DDDSU`, 2.5ms
@@ -529,7 +541,7 @@ The OAI configuration file [`gnb-du.sa.band77.273prb.fhi72.4x4-benetel650.conf`]
 - MTU 9600
 - 4TX4R
 
-##### RU configuration
+#### RU configuration
 
 After switching on the radio or rebooting, wait for the radio bring up to complete, which you can follow using `tail -f  /tmp/logs/radio_status`. Once you will see `[INFO] Radio bringup complete`, you can configure the RU via editing `/etc/ru_config.cfg`
 
@@ -547,7 +559,7 @@ flexran_prach_workaround=disabled
 dl_ul_tuning_special_slot=0xfd00000
 ```
 
-#### Benetel 550
+### Benetel 550
 
 The OAI configuration file [`gnb.sa.band78.273prb.fhi72.4x4-benetel550.conf`](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.273prb.fhi72.4x4-benetel550.conf) corresponds to:
 - TDD pattern `DDDDDDDSUU`, 5ms
@@ -555,7 +567,7 @@ The OAI configuration file [`gnb.sa.band78.273prb.fhi72.4x4-benetel550.conf`](..
 - MTU 9600
 - 4TX4R
 
-##### RU configuration
+#### RU configuration
 
 After switching on the radio or rebooting, wait for the radio bring up to complete, which you can follow using `tail -f  /tmp/logs/radio_status`. Once you will see `[INFO] Radio bringup complete`, you can configure the RU via editing `/etc/ru_config.cfg`
 
@@ -573,15 +585,15 @@ flexran_prach_workaround=disabled
 dl_tuning_special_slot=0x13b6
 ```
 
-#### LITEON
+### LITEON
 
-The OAI configuration file [`gnb.sa.band78.273prb.fhi72.4x4-liteon.conf`](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.273prb.fhi72.4x4-liteon.conf) corresponds to:
+The OAI configuration file [`gnb.sa.band78.273prb.fhi72.4x4-liteon.conf`](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.273prb.fhi72.4x4-liteon.conf) corresponds to:
 - TDD pattern `DDDSU`, 2.5ms
 - Bandwidth 100MHz
 - MTU 1500
 - MTU 9600: v02.00.10
 
-##### RU configuration
+#### RU configuration
 
 SSH to the unit as user `user`. Write `enable` in the terminal to enter the configuration console; the password should be in the user guide. Use the command `show oru-status` to check the RU status. The output should be similar to:
 ```bash
@@ -611,16 +623,16 @@ jumboframe 1 # enable jumbo frame
 ...
 ```
 
-#### VVDN LPRU
+### VVDN LPRU
 
 **Version 3.x**
 
-The OAI configuration file [`gnb.sa.band77.273prb.fhi72.4x4-vvdn.conf`](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band77.273prb.fhi72.4x4-vvdn.conf) corresponds to:
+The OAI configuration file [`gnb.sa.band77.273prb.fhi72.4x4-vvdn.conf`](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band77.273prb.fhi72.4x4-vvdn.conf) corresponds to:
 - TDD pattern `DDDSU`, 2.5ms
 - Bandwidth 100MHz
 - MTU 9600
 
-##### RU configuration
+#### RU configuration
 
 Check in the RU user manual how to configure the center frequency. There are multiple ways to do it. We set the center frequency by editing `sysrepocfg` database. You can use `sysrepocfg --edit=vi -d running` to do the same. You can edit the `startup` database to make the center frequency change persistent. 
 
@@ -664,11 +676,11 @@ mw.l a0050010 <YOUR-RU-VLAN>3 # e.g. VLAN = 4 => `mw.l a0050010 43`
 sysrepocfg --edit=vi -d running
 ```
 
-#### Metanoia RU
+### Metanoia RU
 
 **Version 2.0.6**
 
-The OAI configuration file [`gnb.sa.band78.273prb.fhi72.4x4-metanoia.conf`](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.273prb.fhi72.4x4-metanoia.conf) corresponds to:
+The OAI configuration file [`gnb.sa.band78.273prb.fhi72.4x4-metanoia.conf`](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.273prb.fhi72.4x4-metanoia.conf) corresponds to:
 - TDD pattern `DDDSU`, 2.5ms (`DDDDDDDSUU`, 5ms, also supported)
 - Bandwidth 100MHz
 - 4TX4R
@@ -685,16 +697,16 @@ The RU configuration is stored in `/etc/rumanager.conf`. The required modificati
 
 At this stage, RU must be rebooted so the changes apply.
 
-#### Foxconn RPQN RU
+### Foxconn RPQN RU
 
 **Version v3.1.15q.551_rc10**
 
-The OAI configuration file [`gnb.sa.band78.273prb.fhi72.4X4-foxconn.conf`](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.273prb.fhi72.4X4-foxconn.conf) corresponds to:
+The OAI configuration file [`gnb.sa.band78.273prb.fhi72.4X4-foxconn.conf`](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.273prb.fhi72.4X4-foxconn.conf) corresponds to:
 - TDD pattern `DDDSU`, 2.5ms
 - Bandwidth 100MHz
 - MTU 9600
 
-##### RU configuration
+#### RU configuration
 
 After switching on or rebooting the RU, the `/home/root/test/init_rrh_config_enable_cuplane` script should be run.
 
@@ -719,7 +731,7 @@ RU must be rebooted so the changes apply.
 - The measured throughput was **520 Mbps DL** and **40 Mbps UL**.
 - With newer OAI versions, throughput degrades. This issue is currently under investigation.
 
-### Configure Network Interfaces and DPDK VFs
+## Configure Network Interfaces and DPDK VFs
 
 The 7.2 fronthaul uses the xran library, which requires DPDK. In this step, we
 need to configure network interfaces to send data to the RU, and configure DPDK
@@ -755,7 +767,7 @@ in the below command and configure VLAN on the switch as "access VLAN". In case
 the MTU is different than 1500, you have to update the MTU on the switch
 interface as well.
 
-#### Set maximum ring buffers:
+### Set maximum ring buffers:
 
 As a first step, please set up the maximum allowed buffer size to your desired interface. To check the maximum value, please execute the following command:
 ```bash
@@ -770,7 +782,7 @@ MAX_RING_BUFFER_SIZE=<YOUR_PHYSICAL_INTERFACE_MAX_BUFFER_SIZE>
 sudo ethtool -G $IF_NAME rx $MAX_RING_BUFFER_SIZE tx $MAX_RING_BUFFER_SIZE
 ```
 
-#### Set the maximum MTU in the physical interface:
+### Set the maximum MTU in the physical interface:
 ```bash
 set -x
 IF_NAME=<YOUR_PHYSICAL_INTERFACE_NAME>
@@ -779,9 +791,9 @@ MTU=<RU_MTU>
 sudo ip link set $IF_NAME mtu $MTU
 ```
 
-#### (Re-)create VF(s)
+### (Re-)create VF(s)
 
-##### one VF
+#### one VF
 
 ```bash
 set -x
@@ -796,7 +808,7 @@ sudo sh -c 'echo 1 > /sys/class/net/$IF_NAME/device/sriov_numvfs'
 sudo ip link set $IF_NAME vf 0 mac $DU_CU_PLANE_MAC_ADD vlan $VLAN mtu $MTU spoofchk off # set CU planes PCI address
 ```
 
-##### two VFs
+#### two VFs
 
 ```bash
 set -x
@@ -854,12 +866,12 @@ The hardware card `31:00.1` has two associated virtual functions `31:06.0` and
 `31:06.1`.
 </details>
 
-#### Bind VF(s)
+### Bind VF(s)
 
 Now, unbind any pre-existing DPDK devices, load the "Virtual Function I/O"
 driver `vfio_pci` or `mlx5_core`, and bind DPDK to these devices.
 
-##### Bind one VF
+#### Bind one VF
 
 ```bash
 set -x
@@ -871,7 +883,7 @@ sudo modprobe $DRIVER
 sudo /usr/local/bin/dpdk-devbind.py --bind $DRIVER $CU_PLANE_PCI_BUS_ADD
 ```
 
-##### Bind two VFs
+#### Bind two VFs
 
 ```bash
 set -x
@@ -921,24 +933,24 @@ sudo /usr/local/bin/dpdk-devbind.py --bind $DRIVER $C_PLANE_PCI_BUS_ADD
 
 
 
-### Configure OAI gNB
+## Configure OAI gNB
 
 **Beware in the following section to let in the range of isolated cores the parameters that should be (i.e. `L1s.L1_rx_thread_core`, `L1s.L1_tx_thread_core`, `RUs.ru_thread_core`, `fhi_72.io_core` and `fhi_72.worker_cores`)**
 
 Sample configuration files for OAI gNB, specific to the manufacturer of the radio unit, are available at:
 1. LITEON RU:
-[`gnb.sa.band78.273prb.fhi72.4x4-liteon.conf`](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.273prb.fhi72.4x4-liteon.conf)
+[`gnb.sa.band78.273prb.fhi72.4x4-liteon.conf`](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.273prb.fhi72.4x4-liteon.conf)
 2. VVDN RU:
-[`gnb.sa.band77.273prb.fhi72.4x4-vvdn.conf`](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band77.273prb.fhi72.4x4-vvdn.conf)
-[`gnb.sa.band77.106prb.fhi72.4x4-vvdn.conf`](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band77.106prb.fhi72.4x4-vvdn.conf)
-[`gnb.sa.band77.273prb.fhi72.2x2-vvdn.conf`](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band77.273prb.fhi72.2x2-vvdn.conf)
+[`gnb.sa.band77.273prb.fhi72.4x4-vvdn.conf`](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band77.273prb.fhi72.4x4-vvdn.conf)
+[`gnb.sa.band77.106prb.fhi72.4x4-vvdn.conf`](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band77.106prb.fhi72.4x4-vvdn.conf)
+[`gnb.sa.band77.273prb.fhi72.2x2-vvdn.conf`](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band77.273prb.fhi72.2x2-vvdn.conf)
 3. Benetel 650 RU:
-[`gnb-du.sa.band77.273prb.fhi72.4x4-benetel650.conf`](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb-du.sa.band77.273prb.fhi72.4x4-benetel650.conf)
+[`gnb-du.sa.band77.273prb.fhi72.4x4-benetel650.conf`](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb-du.sa.band77.273prb.fhi72.4x4-benetel650.conf)
 4. Benetel 550 RU:
-[`gnb.sa.band78.273prb.fhi72.4x4-benetel550.conf`](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.273prb.fhi72.4x4-benetel550.conf)
-[`gnb.sa.band78.273prb.fhi72.4x2-benetel550.conf`](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.273prb.fhi72.4x2-benetel550.conf)
+[`gnb.sa.band78.273prb.fhi72.4x4-benetel550.conf`](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.273prb.fhi72.4x4-benetel550.conf)
+[`gnb.sa.band78.273prb.fhi72.4x2-benetel550.conf`](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.273prb.fhi72.4x2-benetel550.conf)
 5. Metanoia RU:
-[`gnb.sa.band78.273prb.fhi72.4x4-metanoia.conf`](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.273prb.fhi72.4x4-metanoia.conf)
+[`gnb.sa.band78.273prb.fhi72.4x4-metanoia.conf`](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.273prb.fhi72.4x4-metanoia.conf)
 
 Edit the sample OAI gNB configuration file and check following parameters:
 
@@ -1014,7 +1026,7 @@ Layer mapping (eAxC offsets) happens as follows:
 - At the moment, OAI is compatible with CAT A O-RU only. Therefore, SRS is not supported.
 - XRAN retrieves DU MAC address with `rte_eth_macaddr_get()` function. Hence, `fhi_72.du_addr` parameter is not taken into account.
 
-## Start and Operation of OAI gNB
+# Start and Operation of OAI gNB
 
 Run the `nr-softmodem` from the build directory:
 ```bash
@@ -1102,7 +1114,7 @@ not working, and UEs might not be able to attach or reach good performance.
 Also, you can try to compile with polling (see [the build
 section](.#build-oai-gnb)) to see if it resolves the problem.
 
-## Operation with multiple RUs
+# Operation with multiple RUs
 
 It is possible to connect up to 4 RUs to one DU at the same time and operate
 them either with a single antenna array or a distributed antenna array.  This
@@ -1191,7 +1203,7 @@ fhi_72 = {
 </details>
 
 Compare also with the example (DU) configuration in
-[`gnb-du.sa.band77.273prb.fhi72.8x8-benetel650_650.conf`](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb-du.sa.band77.273prb.fhi72.8x8-benetel650_650.conf).
+[`gnb-du.sa.band77.273prb.fhi72.8x8-benetel650_650.conf`](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb-du.sa.band77.273prb.fhi72.8x8-benetel650_650.conf).
 
 Afterwards, start the gNB with the modified configuration file. If everything
 went well, you should see the RU counters for both RUs go up:
@@ -1222,7 +1234,7 @@ Note the eight entries after `avg_IO`.
 You should be able to connect a UE now.
 
 
-## OAI Management Plane
+# OAI Management Plane
 In OAI gNB, we support:
 * Configuration Management: interface(s) creation, configuration of RU CU-planes, Tx/Rx antennas, and Tx/Rx carriers.
 * Performance Management: activation/deactivation of available RU performance measurements and its notification reception with 10s periodicity:
@@ -1234,10 +1246,10 @@ The reference specifications:
 * `O-RAN.WG4.MP.0-v05.00`
 * `O-RAN.WG4.MP-YANGs-v04.00`
 
-### M-plane prerequisites
+## M-plane prerequisites
 Before proceeding, please make sure you have a support for 7.2 interface, as described in [Prerequisites](#prerequisites).
 
-#### DHCP server
+### DHCP server
 The M-plane requires a DHCP server, where the M-plane connection can be established over untagged or tagged VLAN. We tested with untagged (the default VLAN is 1).
 Please modify `/etc/dhcp/dhcpd.conf` configuration based on your testbed.
 
@@ -1284,7 +1296,7 @@ Please, configure the interface as:
 sudo ip address add 192.168.80.1/24 dev <interface>
 ```
 
-#### Mandatory packages
+### Mandatory packages
 * On Fedora (we haven't yet tested RHEL):
 ```bash
 sudo dnf install pcre-devel libssh-devel libxml2-devel libyang2-devel libnetconf2-devel
@@ -1353,10 +1365,10 @@ sudo ldconfig
 
 If you would like to install these libraries in the custom path, please replace `/usr/local` default path to e.g. `/opt/mplane-v2`.
 
-### Benetel O-RU
+## Benetel O-RU
 Note: Only v1.2.2 RAN550 and RAN650 have been successfully tested.
 
-#### One time steps
+### One time steps
 Connect to the RU as user `root`, enable the mplane service, and reboot:
 ```bash
 ssh root@<ru-ip-address>
@@ -1381,11 +1393,11 @@ echo "<DU-pub-key>" >>  ~/.ssh/authorized_keys
 ```
 
 
-### gNB configuration
+## gNB configuration
 The reference gNB configuration file for one Benetel RAN550:
-[`gnb.sa.band78.273prb.fhi72.4x4-benetel550-mplane.conf`](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.273prb.fhi72.4x4-benetel550-mplane.conf)
+[`gnb.sa.band78.273prb.fhi72.4x4-benetel550-mplane.conf`](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.273prb.fhi72.4x4-benetel550-mplane.conf)
 The reference DU configuration file for two Benetel RAN650:
-[gnb-du.sa.band77.273prb.fhi72.8x8-benetel650_650-mplane.conf](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb-du.sa.band77.273prb.fhi72.8x8-benetel650_650-mplane.conf)
+[gnb-du.sa.band77.273prb.fhi72.8x8-benetel650_650-mplane.conf](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb-du.sa.band77.273prb.fhi72.8x8-benetel650_650-mplane.conf)
 
 In order to run gNB/DU with M-plane, we need to modify Tx gain `att_tx` in RU section, as well as the `fhi_72` section in the configuration file.
 Example for one RU:
@@ -1462,7 +1474,7 @@ The following parameters are retrieved from the RU and forwarded to the xran:
 * `IQ compression`: if RU supports multiple, the first value in the list is taken; please note that the same value is used for PxSCH/PRACH
 * `PRACH offset`: hardcoded based on the RU vendor (i.e. for Benetel `max(Nrx,Ntx)`)
 
-### Build and compile gNB
+## Build and compile gNB
 The following cmake options are available:
 * `OAI_FHI72` = CUS support
 * `OAI_FHI72_MPLANE` = M support
@@ -1471,7 +1483,7 @@ Compiled libraries:
 * `OAI_FHI72` <=> `oran_fhlib_5g`
 * `OAI_FHI72` && `OAI_FHI72_MPLANE` <=> `oran_fhlib_5g` (CUS) && `oran_fhlib_5g_mplane` (CUSM)
 
-#### Using build_oai script
+### Using build_oai script
 ```bash
 git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git ~/openairinterface5g
 cd ~/openairinterface5g/cmake_targets/
@@ -1482,7 +1494,7 @@ cd ~/openairinterface5g/cmake_targets/
 PKG_CONFIG_PATH=/opt/mplane-v2/lib/pkgconfig ./build_oai --gNB --ninja -t oran_fhlib_5g_mplane --cmake-opt -Dxran_LOCATION=$HOME/phy/fhi_lib/lib
 ```
 
-#### Using cmake directly
+### Using cmake directly
 ```bash
 git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git ~/openairinterface5g
 cd ~/openairinterface5g/
@@ -1493,7 +1505,7 @@ PKG_CONFIG_PATH=/opt/mplane-v2/lib/pkgconfig cmake .. -GNinja -DOAI_FHI72=ON -DO
 ninja nr-softmodem oran_fhlib_5g_mplane params_libconfig
 ```
 
-### Start the gNB
+## Start the gNB
 Run the `nr-softmodem` from the build directory:
 ```bash
 cd ~/openairinterface5g/cmake_targets/ran_build/build
@@ -2222,7 +2234,7 @@ sudo ./nr-softmodem -O <without-mplane-configuration file> --thread-pool <list o
 ```
 
 
-## Contact in case of questions
+# Contact in case of questions
 
 You can ask your question on the [mailing lists](https://gitlab.eurecom.fr/oai/openairinterface5g/-/wikis/MailingList).
 

doc/README.md

@@ -1,4 +1,16 @@
-# OpenAirInterface documentation overview
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">OpenAirInterface documentation overview</font></b>
+    </td>
+  </tr>
+</table>
 
 This is the general overview page of the OpenAirInterface documentation.  
 This page groups links to general information, tutorials, design documents, radio integration, and special-purpose libraries.
@@ -11,81 +23,81 @@ Beware if you previously pulled the `develop` branch that your repository may be
 
 [[_TOC_]]
 
-## General
+# General
 
-- [FEATURE_SET.md](setup/FEATURE_SET.md): lists supported features
-- [GET_SOURCES.md](setup/GET_SOURCES.md): how to download the sources
-- [BUILD.md](BUILD.md): how to build the sources
-- [code-style-contrib.md](setup/code-style-contrib.md): overall working practices, code style, and review process
-- [cross-compile.md](setup/cross-compile.md): how to cross-compile OAI for ARM
-- [clang-format.md](setup/clang-format.md): how to format the code
-- [sanitizers.md](dev_tools/sanitizers.md): how to run with ASan/UBSan/MemSAN/TSan
-- [environment-variables.md](setup/environment-variables.md): the environment variables used by OAI
-- [tuning_and_security.md](testing/tuning_and_security.md): performance and security considerations
+- [FEATURE_SET.md](./FEATURE_SET.md): lists supported features
+- [GET_SOURCES.md](./GET_SOURCES.md): how to download the sources
+- [BUILD.md](./BUILD.md): how to build the sources
+- [code-style-contrib.md](./code-style-contrib.md): overall working practices, code style, and review process
+- [cross-compile.md](./cross-compile.md): how to cross-compile OAI for ARM
+- [clang-format.md](./clang-format.md): how to format the code
+- [sanitizers.md](./dev_tools/sanitizers.md): how to run with ASan/UBSan/MemSAN/TSan
+- [environment-variables.md](./environment-variables.md): the environment variables used by OAI
+- [tuning_and_security.md](./tuning_and_security.md): performance and security considerations
 
 There is some general information in the [OpenAirInterface Gitlab Wiki](https://gitlab.eurecom.fr/oai/openairinterface5g/-/wikis/home)
 
-## Tutorials
+# Tutorials
 
 - Step-by-step tutorials to set up 5G:
-  * [OAI 5GC](tutorials/NR_SA_Tutorial_OAI_CN5G.md)
-  * [OAI gNB with COTS UE](tutorials/NR_SA_Tutorial_COTS_UE.md)
-  * [OAI NR-UE](tutorials/NR_SA_Tutorial_OAI_nrUE.md)
-  * [Multiple OAI NR-UE with RFsimulator](tutorials/NR_SA_Tutorial_OAI_multi_UE.md)
-- [RUNMODEM.md](usage/RUNMODEM.md): Generic information on how to
+  * [OAI 5GC](./NR_SA_Tutorial_OAI_CN5G.md)
+  * [OAI gNB with COTS UE](./NR_SA_Tutorial_COTS_UE.md)
+  * [OAI NR-UE](./NR_SA_Tutorial_OAI_nrUE.md)
+  * [Multiple OAI NR-UE with RFsimulator](./NR_SA_Tutorial_OAI_multi_UE.md)
+- [RUNMODEM.md](./RUNMODEM.md): Generic information on how to
   * Run simulators
   * Run with hardware
   * Specific OAI modes (phy-test, do-ra, noS1)
   * (5G) Using SDAP and custom DRBs
   * IF setups and arbitrary frequencies
   * MIMO
-- [How to run OAI with O-RAN 7.2 FHI](tutorials/ORAN_FHI7.2_Tutorial.md)
-- [How to run a 5G-NSA setup](testing/TESTING_GNB_W_COTS_UE.md)
-- [How to run a 4G setup using L1 simulator](L1_L2/L1SIM.md) _Note: we recommend the RFsimulator_
-- [How to use the L2 simulator](L1_L2/L2NFAPI.md)
+- [How to run OAI with O-RAN 7.2 FHI](./ORAN_FHI7.2_Tutorial.md)
+- [How to run a 5G-NSA setup](./TESTING_GNB_W_COTS_UE.md)
+- [How to run a 4G setup using L1 simulator](./L1SIM.md) _Note: we recommend the RFsimulator_
+- [How to use the L2 simulator](./L2NFAPI.md)
 - [How to use the OAI channel simulator](../openair1/SIMULATION/TOOLS/DOC/channel_simulation.md)
-- [How to use multiple BWPs](usage/RUN_NR_multiple_BWPs.md)
-- [How to run OAI-VNF and OAI-PNF](L1_L2/nfapi.md): how to run the FAPI/nFAPI split,
+- [How to use multiple BWPs](./RUN_NR_multiple_BWPs.md)
+- [How to run OAI-VNF and OAI-PNF](./nfapi.md): how to run the FAPI/nFAPI split,
   including some general remarks on FAPI/nFAPI.
-- [How to use the positioning reference signal (PRS)](usage/RUN_NR_PRS.md)
-- [How to use device-to-device communication (D2D, 4G)](setup/d2d_emulator_setup.txt)
+- [How to use the positioning reference signal (PRS)](./RUN_NR_PRS.md)
+- [How to use device-to-device communication (D2D, 4G)](./d2d_emulator_setup.txt)
 - [How to run with E2 agent](../openair2/E2AP/README.md)
-- [How to run the physical simulators](usage/physical-simulators.md)
-- [How to setup OAI with Nvidia Aerial and Foxconn](tutorials/Aerial_FAPI_Split_Tutorial.md)
-- [How to setup OAI with LDPC accelerators (Xilinx T2/Intel ACCs)](tutorials/LDPC_OFFLOAD_SETUP.md)
-- [How to do a handover](tutorials/handover-tutorial.md)
-- [How to setup gNB frequency](setup/gNB_frequency_setup.md)
+- [How to run the physical simulators](./physical-simulators.md)
+- [How to setup OAI with Nvidia Aerial and Foxconn](./Aerial_FAPI_Split_Tutorial.md)
+- [How to setup OAI with LDPC accelerators (Xilinx T2/Intel ACCs)](./LDPC_OFFLOAD_SETUP.md)
+- [How to do a handover](./handover-tutorial.md)
+- [How to setup gNB frequency](./gNB_frequency_setup.md)
 
 Legacy unmaintained files:
-- [`L2NFAPI_NOS1.md`](L1_L2/L2NFAPI_NOS1.md), [`L2NFAPI_S1.md`](L1_L2/L2NFAPI_S1.md):
+- [`L2NFAPI_NOS1.md`](./L2NFAPI_NOS1.md), [`L2NFAPI_S1.md`](./L2NFAPI_S1.md):
   old L2simulator, not valid anymore
-- [`SystemX-tutorial-design.md`](architecture/SystemX-tutorial-design.md): old, high-level
+- [`SystemX-tutorial-design.md`](./SystemX-tutorial-design.md): old, high-level
   documentation
-- [`UL_MIMO.txt`](usage/UL_MIMO.txt): UL-MIMO specific notes
+- [`UL_MIMO.txt`](./UL_MIMO.txt): UL-MIMO specific notes
 
-## Designs
+# Designs
 
 - General software architecture notes: [SW_archi.md](./SW_archi.md)
-- [Information on E1](E1AP/E1-design.md)
-- [Information on F1](F1AP/F1-design.md)
-- [Information on how NR nFAPI works](architecture/NR_NFAPI_archi.md)
-- [Flow graph of the L1 in gNB](architecture/SW-archi-graph.md)
-- [L1 threads in NR-UE](architecture/nr-ue-design.md)
-- [Information on gNB MAC](MAC/mac-usage.md)
-- [Information on gNB RRC](RRC/rrc-usage.md)
-- [Information on analog beamforming implementation](tutorials/analog_beamforming.md)
-- [Information on the UE 5G NAS implementation](tutorials/5Gnas.md)
+- [Information on E1](./E1AP/E1-design.md)
+- [Information on F1](./F1AP/F1-design.md)
+- [Information on how NR nFAPI works](./NR_NFAPI_archi.md)
+- [Flow graph of the L1 in gNB](SW-archi-graph.md)
+- [L1 threads in NR-UE](./nr-ue-design.md)
+- [Information on gNB MAC](./MAC/mac-usage.md)
+- [Information on gNB RRC](./RRC/rrc-usage.md)
+- [Information on analog beamforming implementation](./analog_beamforming.md)
+- [Information on the UE 5G NAS implementation](./5Gnas.md)
 
-## Building and running from images
+# Building and running from images
 
 - [How to build images](../docker/README.md)
 - [How to run 5G with the RFsimulator from images](../ci-scripts/yaml_files/5g_rfsimulator/README.md)
 - [How to run 4G with the RFsimulator from images](../ci-scripts/yaml_files/4g_rfsimulator_fdd_05MHz/README.md)
 - [How to run physical simulators in OpenShift](../openshift/README.md)
 
-## Libraries
+# Libraries
 
-### General
+## General
 
 - The [T tracer](../common/utils/T/DOC/T.md): a generic tracing tool (VCD, Wireshark, GUI, to save for later, ...)
 - [OPT](../openair2/UTIL/OPT/README.txt): how to trace to wireshark
@@ -94,9 +106,9 @@ Legacy unmaintained files:
 - The [shared object loader](../common/utils/DOC/loader.md)
 - The [threadpool](../common/utils/threadPool/thread-pool.md) used in L1
 - The [LDPC implementation](../openair1/PHY/CODING/DOC/LDPCImplementation.md) is a shared library
-- The [time management](architecture/time_management.md) module
+- The [time management](time_management.md) module
 
-### Radios
+## Radios
 
 Some directories under `radio` contain READMEs:
 
@@ -110,22 +122,22 @@ Some directories under `radio` contain READMEs:
 
 The other SDRs (AW2S, LimeSDR, ...) have no READMEs.
 
-### Special-purpose libraries
+## Special-purpose libraries
 
 - OAI has two scopes: one based on Xforms and one based on imgui, described in [this README](../openair1/PHY/TOOLS/readme.md)
 - OAI comes with an integrated [telnet server](../common/utils/telnetsrv/DOC/telnethelp.md) to monitor and control
 - OAI comes with an integrated [web server](../common/utils/websrv/DOC/websrv.md)
 
-## Testing
+# Testing
 
-- [UnitTests.md](testing/UnitTests.md) explains the unit testing setup
+- [UnitTests.md](./UnitTests.md) explains the unit testing setup
 - Component tests are under `tests/`. Currently, there is a simple CU-UP
   tester, see the corresponding [README.md](../tests/nr-cuup/README.md).
-- [TESTBenches.md](testing/TESTBenches.md) lists the CI setup and links to pipelines
+- [TESTBenches.md](./TESTBenches.md) lists the CI setup and links to pipelines
 - The CI setup uses a [custom framework](../ci-scripts/README.md) to run
   end-to-end tests.
 
-## Developer tools
+# Developer tools
 
 - [formatting](../tools/formatting/README.md) is a clang-format error detection tool
 - [iwyu](../tools/iwyu/README.md) is a tool to detect `#include` errors

doc/RUNMODEM.md

@@ -1,8 +1,20 @@
-# Running OAI 5G Softmodems
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">Running OAI 5G Softmodems</font></b>
+    </td>
+  </tr>
+</table>
 
 This document explains some options for running 5G executables.
 
-After you have [built the softmodem executables](../BUILD.md) you can set your
+After you have [built the softmodem executables](BUILD.md) you can set your
 default directory  to the build directory `cmake_targets/ran_build/build/` and
 start testing some use cases. Below, the description of the different OAI
 functionalities should help you choose the OAI configuration that suits your
@@ -10,9 +22,9 @@ need.
 
 [[_TOC_]]
 
-## Simulators
+# Simulators
 
-### RFsimulator
+## RFsimulator
 
 The RFsimulator is an OAI device replacing the radio heads (for example the
 USRP device). It allows connecting the oai UE (LTE or 5G) and respectively the
@@ -25,41 +37,41 @@ It is planned to enhance this simulator with the following functionalities:
 
 - Support for multiple eNodeB's or gNodeB's for hand-over tests
 
-This is an easy use-case to setup and test, as no specific hardware is required. The [rfsimulator page](../../radio/rfsimulator/README.md) contains the detailed documentation.
+This is an easy use-case to setup and test, as no specific hardware is required. The [rfsimulator page](../radio/rfsimulator/README.md) contains the detailed documentation.
 
-### L2 nFAPI Simulator
+## L2 nFAPI Simulator
 
 This simulator connects an eNodeB and UEs through an nFAPI interface,
 short-cutting the L1 layer. The objective of this simulator is to allow multi
 UEs simulation, with a large number of UEs (ideally up to 255).
 
 As for the RFsimulator, no specific hardware is required. The [L2 nfapi
-simulator page](../L1_L2/nfapi.md) contains the detailed documentation.
+simulator page](./L2NFAPI.md) contains the detailed documentation.
 
-## Running with a true radio head
+# Running with a true radio head
 
 OAI supports different radio heads, the following are tested in the CI:
 
 1. [Monolithic eNodeB](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/HowToConnectCOTSUEwithOAIeNBNew) where the whole signal processing is performed in a single process
 2. IF4P5 mode, where frequency domain samples are carried over ethernet, from the RRU which implement part of L1(FFT,IFFT,part of PRACH),  to a RAU
-3. Monolithic gNodeB: see next section, or the [standalone tutorial](../tutorials/NR_SA_Tutorial_COTS_UE.md)
+3. Monolithic gNodeB: see next section, or the [standalone tutorial](NR_SA_Tutorial_COTS_UE.md)
 
 
-## 5G NR
+# 5G NR
 
-### NSA setup with COTS UE
+## NSA setup with COTS UE
 
 This setup requires an EPC, an OAI eNB and gNB, and a COTS Phone. A dedicated page describe the setup can be found [here](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home/gNB-COTS-UE-testing).
 The `--nsa` flag must be used to run gNB in non-standalone mode.
 
 
-#### Launch eNB
+### Launch eNB
 
 ```bash
 sudo ./lte-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.band7.tm1.50prb.usrpb210.conf
 ```
 
-#### Launch gNB
+### Launch gNB
 
 ```bash
 sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf --nsa
@@ -67,7 +79,7 @@ sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78
 
 You should see the X2 messages in Wireshark and at the eNB.
 
-### SA setup with OAI NR-UE
+## SA setup with OAI NR-UE
 
 The standalone mode is the default mode. 
 
@@ -111,11 +123,11 @@ sudo ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3619200000 --ssb 516
 
 With the **RFsimulator** (on the same machine), just add the option `--rfsim` to both gNB and NR UE command lines.
 
-UE capabilities can be passed according to the [UE Capabilities](#ue-capabilities) section.
+UE capabilities can be passed according to the [UE Capabilities](#UE-Capabilities) section.
 
-A detailed tutorial is provided at this page [NR_SA_Tutorial_OAI_nrUE.md](../tutorials/NR_SA_Tutorial_OAI_nrUE.md).
+A detailed tutorial is provided at this page [NR_SA_Tutorial_OAI_nrUE.md](./NR_SA_Tutorial_OAI_nrUE.md).
 
-### Optional NR-UE command line options
+## Optional NR-UE command line options
 
 Here are some useful command line options for the NR UE:
 
@@ -140,13 +152,13 @@ You can view all available options by typing:
 ```shell
 ./nr-uesoftmodem --help
 ```
-### Common gNB and NR UE command line options
+## Common gNB and NR UE command line options
 
-#### Three-quarter sampling
+### Three-quarter sampling
 
 The command line option `-E` can be used to enable three-quarter sampling for split 8 sample rate. Required for certain radios (e.g., 40MHz with B210). If used on the gNB, it is a good idea to use for the UE as well (and vice versa).
 
-#### UE Capabilities
+### UE Capabilities
 
 The `--uecap_file` option can be used to pass the UE Capabilities input file (path location + filename), e.g.`--uecap_file ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/uecap_ports1.xml` for 1 layer or e.g. `--uecap_file ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/uecap_ports2.xml` for 2 layers.
 
@@ -164,14 +176,14 @@ e.g.
 sudo ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3319680000 --ue-nb-ant-tx 2 --ue-nb-ant-rx 2 --uecap_file /opt/oai-nr-ue/etc/uecap.xml
 ```
 
-### How to run a NTN configuration
+## How to run a NTN configuration
 
-#### NTN channel
+### NTN channel
 
 A 5G NR NTN configuration only works in a non-terrestrial setup.
 Therefore either SDR boards and a dedicated NTN channel emulator are required, or RFsimulator has to be configured to simulate a NTN channel.
 
-As shown on the [rfsimulator page](../../radio/rfsimulator/README.md), RFsimulator provides different possibilities.
+As shown on the [rfsimulator page](../radio/rfsimulator/README.md), RFsimulator provides different possibilities.
 E.g. to perform a simple simulation of a satellite in geostationary orbit (GEO), these parameters should be added to both gNB and UE command lines:
 ```
 --rfsimulator.prop_delay 238.74
@@ -213,7 +225,7 @@ Or by providing this the the command line parameters:
 --rfsimulator.options chanmod
 ```
 
-#### gNB
+### gNB
 
 The main parameters to cope with the large NTN propagation delay are cellSpecificKoffset, ta-Common, ta-CommonDrift and the ephemeris data (satellite position and velocity vectors).
 
@@ -320,7 +332,7 @@ cd cmake_targets
 sudo ./ran_build/build/nr-softmodem -O ../ci-scripts/conf_files/gnb.sa.band254.u0.25prb.rfsim.ntn-leo.conf --rfsim
 ```
 
-#### NR UE
+### NR UE
 
 At UE side, only few parameters have to be provided, as the UE receives most relevant parameters via SIB19 from the gNB.
 But to calculate the UE specific TA, the UE position has to be provided in the `ue.conf` file.
@@ -358,9 +370,9 @@ cd cmake_targets
 sudo ./ran_build/build/nr-uesoftmodem -O ../targets/PROJECTS/GENERIC-NR-5GC/CONF/ue.conf --band 254 -C 2488400000 --CO -873500000 -r 25 --numerology 0 --ssb 60 --rfsim --rfsimulator.prop_delay 20 --rfsimulator.options chanmod --time-sync-I 0.1 --ntn-initial-time-drift -46 --autonomous-ta --initial-fo 57340 --cont-fo-comp 2
 ```
 
-## Specific OAI modes
+# Specific OAI modes
 
-### phy-test setup with OAI UE
+## phy-test setup with OAI UE
 
 The OAI UE can also be used in front of a OAI gNB without the support of eNB or EPC and circumventing random access. In this case both gNB and eNB need to be run with the `--phy-test` flag. At the gNB this flag does the following
  - it reads the RRC configuration from the configuration file
@@ -385,9 +397,9 @@ In summary:
   * `scp usera@machineA:/the/path/where/you/launched/nr-softmodem/r*config.raw userb@machineB:/the/path/where/you/will/launch/nr-uesoftmodem/`
   * Obviously this operation should be done before launching the `nr-uesoftmodem` executable.
 
-In phy-test mode it is possible to mimic the reception of UE Capabilities at gNB through the command line parameter `--uecap_file`. Refer to the [UE Capabilities](#ue-capabilities) section for more details.
+In phy-test mode it is possible to mimic the reception of UE Capabilities at gNB through the command line parameter `--uecap_file`. Refer to the [UE Capabilities](#UE-Capabilities) section for more details.
 
-### noS1 setup with OAI UE
+## noS1 setup with OAI UE
 
 Instead of randomly generated payload, in the phy-test mode we can also
 inject/receive user-plane traffic over a TUN interface. This is the so-called
@@ -406,7 +418,7 @@ iperf -uc 10.0.1.2 -B 10.0.1.1 -i1 -t10 -b1M
 ```
 to send data from the gNB down to the UE.
 
-> Note that this does not work if both interfaces are on the same host. We
+Note that this does not work if both interfaces are on the same host. We
 recommend to use two different hosts, or at least network namespaces, to route
 traffic through the gNB/UE tunnel.
 
@@ -415,13 +427,13 @@ which the UE does not connect to a core network. If the UE connects to a core
 network, it receives an IP address for which it automatically opens a network
 interface.
 
-### do-ra setup with OAI
+## do-ra setup with OAI
 
 The do-ra flag is used to ran the NR Random Access procedures in contention-free mode. Currently OAI implements the RACH process from Msg1 to Msg3. 
 
 In order to run the RA, the `--do-ra` flag is needed for both the gNB and the UE.
 
-In do-ra mode it is possible to mimic the reception of UE Capabilities at gNB through the command line parameter `--uecap_file`. Refer to the [UE Capabilities](#ue-capabilities) section for more details.
+In do-ra mode it is possible to mimic the reception of UE Capabilities at gNB through the command line parameter `--uecap_file`. Refer to the [UE Capabilities](#UE-Capabilities) section for more details.
 
 To run using the RFsimulator:
 
@@ -443,7 +455,7 @@ sudo ./nr-uesoftmodem --do-ra
 ```
 
 
-#### Run OAI with SDAP & Custom DRBs
+### Run OAI with SDAP & Custom DRBs
 
 To run OAI gNB with SDAP, simply include `--gNBs.[0].enable_sdap 1` to the binary's arguments.
 
@@ -454,7 +466,7 @@ The Non-GBR flows use a shared data radio bearer.
 To hardcode the DRBs for testing purposes, simply add `--gNBs.[0].drbs x` to the binary's arguements, where `x` is the number of DRBs, along with SDAP.
 The hardcoded DRBs will be treated like GBR Flows. Due to code limitations at this point the max. number of DRBs is 4. 
 
-### IF setup with OAI
+## IF setup with OAI
 
 OAI is also compatible with Intermediate Frequency (IF) equipment. This allows to use RF front-end that with arbitrary frequencies bands that do not comply with the standardised 3GPP NR bands. 
 
@@ -466,7 +478,7 @@ Accordingly, the following parameters must be configured in the RUs section of t
 - `if_freq`
 - `if_offset`
 
-#### Run OAI with custom DL/UL arbitrary frequencies
+### Run OAI with custom DL/UL arbitrary frequencies
 
 The following example uses DL frequency 2169.080 MHz and UL frequency offset -400 MHz, with a configuration file for band 66 (FDD) at gNB side.
 
@@ -477,13 +489,20 @@ sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band66
 sudo ./nr-uesoftmodem --if_freq 2169080000 --if_freq_off -400000000
 ```
 
-## 5G gNB MIMO configuration
+# 5G gNB MIMO configuration
 
 In order to enable DL-MIMO in OAI 5G softmodem, the prerequisite is to have `do_CSIRS = 1` in the configuration file. This allows the gNB to schedule CSI reference signal and to acquire from the UE CSI measurements to be able to schedule DLSCH with MIMO.
 
 The following step is to set the number of PDSCH logical antenna ports. These needs to be larger or equal to the maximum number of MIMO layers requested (for 2-layer MIMO it is necessary to have at least two logical antenna ports).
 
-![mimo_antenna_ports](../images/mimo_antenna_ports.png)
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+         <img src="./images/mimo_antenna_ports.png" alt="" border=3 height=100 width=300>
+         </img>
+    </td>
+  </tr>
+</table>
 
 This image shows an example of gNB 5G MIMO logical antenna port configuration. It has to be noted that logical antenna ports might not directly correspond to physical antenna ports and each logical antenna port might consist of a sub-array of antennas.
 

doc/RUN_NR_PRS.md

@@ -1,11 +1,23 @@
-# Running NR PRS with OAI gNB and nrUE
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "8">Running NR PRS with OAI gNB and nrUE</font></b>
+    </td>
+  </tr>
+</table>
 
 This page is valid on tags starting from **`2022.w37`**.
 
 
-After you have [built the softmodem executables](../BUILD.md), go to the build directory `openairinterface5g/cmake_targets/ran_build/build/` and start testing the Rel16 PRS usecases.
+After you have [built the softmodem executables](BUILD.md), go to the build directory `openairinterface5g/cmake_targets/ran_build/build/` and start testing the Rel16 PRS usecases.
 
-## PRS parameters and config files
+# PRS parameters and config files
 
 | **Mode** 	                    | **gNB config**                                                                          	  | **nrUE config**           	|
 |-----------------------------	|-------------------------------------------------------------------------------------------  |---------------------------	|
@@ -39,8 +51,8 @@ prs_config = (
 ```
 To TURN OFF PRS, set `NumPRSResources=0` in gNB `prs_config` section. nrUE config has `Active_gNBs` to specify number of active gNBs transmitting PRS signal simultaneously. Find the help string for PRS parameters in `openair2/COMMON/prs_nr_paramdef.h` <br><br>
 
-## gNB in `phy-test` mode
-> Note that `numactl` is only needed if you run on a NUMA architecture with more than 1 CPU. In this case it should be installed on Linux using command `sudo apt-get install -y numactl`
+# gNB in `phy-test` mode
+Note that `numactl` is only needed if you run on a NUMA architecture with more than 1 CPU. In this case it should be installed on Linux using command `sudo apt-get install -y numactl`
 
 Also check the numa nodes USRP’s are connected to, using the following command:
 
@@ -49,7 +61,7 @@ Also check the numa nodes USRP’s are connected to, using the following command
 Where `eth_if` has to be replaced with the name of the network interface the USRP is connected to. 
 In our case the output is 0 and hence we use `numactl --cpunodebind=0 --membind=0`
 
-### FR1 test
+## FR1 test
 Open a terminal on the host machine, and execute below command to launch gNB with **X310 USRPs**
 
 ```sudo numactl --cpunodebind=0 --membind=0 ./nr-softmodem -E -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb0.prs.band78.fr1.106PRB.usrpx310.conf --phy-test```
@@ -61,7 +73,7 @@ To run using **rfsimulator**, execute following command:
 
 ```sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb0.prs.band78.fr1.106PRB.usrpx310.conf --noS1 --rfsim --phy-test```
 
-### FR2 test
+## FR2 test
 In FR2 mode, we need RF beamforming module to transmit signal in mmWave frequency range. **X310 USRPs** can be used with BasicTx daughtercard to transmit baseband signal at **Intermediate Frequncy(IF)** and then RF beamforming module would perform beamforming and the upconversion to FR2 frequencies. IF can be specified using `if_freq` in the RU section of gNB config.
 
 If RF beamforming module is NOT present, gNB can still be launched with USRP alone; to transmit at supported `if_freq`.
@@ -73,7 +85,7 @@ To run using **rfsimulator**, execute following command:
 
 ```sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb0.prs.band261.fr2.64PRB.usrpx310.conf --noS1 --rfsim --phy-test```
 
-### Multiple gNB scenario
+## Multiple gNB scenario
 PRS is primarily used for positioning and localization of the UE with multiple gNBs transmitting simultaneously. OAI PRS implementation supports multiple gNB transmission provided all the gNBs are tightely synchronized using GPSDO clock. Therefore before running this scenario, make sure the USRPs has built-in GPSDO and the GPS antennas are connected with good satellite visibility. Also every time a gNB is launched, wait until `GPS LOCKED` is printed on the terminal during gNB startup. If USRP fails to lock with GPSDO, try again until its locked.
 
 To use GPSDO, make sure to change `clock_source` and `time_source` to `gpsdo` in RU section of gNB config.
@@ -83,14 +95,14 @@ To use GPSDO, make sure to change `clock_source` and `time_source` to `gpsdo` in
 ```sudo numactl --cpunodebind=1 --membind=1 ./nr-softmodem -E -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb1.band78.fr1.106PRB.prs.usrpx310.conf --phy-test```<br><br>
 
 
-## nrUE in `phy-test` mode
+# nrUE in `phy-test` mode
 While running gNB and nrUE on the same host machine, `reconfig.raw` and `rbconfig.raw` files would be generated with the launch of gNB and and then nrUE would automatically source it from build directory. However, if gNB and nrUE are running on two different host machines, then run gNB first with the corresponding config and exit after few seconds. This would generate `reconfig.raw` and `rbconfig.raw` files.
 
 After this, nrUE can be launched using one of the below commands depending on the test scenario. If UE is NOT able to connect to the gNB, then check the USRP connections or try increasing `--ue-rxgain` in steps of 10dB.  
 
 Also check the instructions on `numactl` in gNB test section as it applies for nrUE execution as well.
 
-### FR1 test
+## FR1 test
 Once gNB is up and running, open another terminal and execute below command to launch nrUE with **X310 USRPs**. Make sure to specify `IP_ADDR1` and `IP_ADDR2`(optional) correctly as per USRPs IP address
 
 ```sudo numactl --cpunodebind=0 --membind=0 ./nr-uesoftmodem -E --phy-test --usrp-args "addr=IP_ADDR1,second_addr=IP_ADDR2,time_source=internal,clock_source=internal" -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/ue.nr.prs.fr1.106prb.conf --ue-rxgain 80 --ue-fo-compensation --non-stop```  
@@ -104,7 +116,7 @@ To run using **rfsimulator** with local ETH IF `127.0.0.1`, execute following co
 sudo ./nr-uesoftmodem --rfsim --phy-test --noS1 -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/ue.nr.prs.fr1.106prb.conf --rfsimulator.serveraddr 127.0.0.1
 ```
 
-### FR2 test
+## FR2 test
 Like gNB, RF beamforming module is receiving at mmWave frequencies and then **X310 USRPs** with BasicRx daughtercard to receive the signal at intermediate frequncy(IF) from RF beamforming module. IF can be specified using `--if_freq` option in nrUE command line.
 
 If RF beamforming module is NOT present, nrUE can still be launched with USRP alone; to receive at `if_freq` and validation can be done. Make sure to specify `if_freq` in the range supported by USRP nrUE is running with.
@@ -118,7 +130,7 @@ To run using **rfsimulator** with local ETH IF `127.0.0.1`, execute following co
 sudo ./nr-uesoftmodem --rfsim --phy-test --noS1 -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/ue.nr.prs.fr2.64prb.conf --rfsimulator.serveraddr 127.0.0.1
 ```
 
-### Multiple gNB scenario
+## Multiple gNB scenario
 In nrUE prs config file, change `Active_gNBs` to the actual number of gNBs launched. Also verify the parameter in `prs_config` sections of nrUE config is matching with that of gNB config used. And launch nrUE using one of the above commands depending on FR1/FR2 test scenario.
 
 After successful connection, UE starts estimating channel based on the downlink PRS pilots using Least-Squares(LS) method. In the frequency domain, linear interpolation is used to reconstruct the channel over entire PRS bandwidth using LS estimates at pilot locations. UE also measures Time of Arrival(ToA) based on the time domain impulse response. On the console, ToA measurement is printed for each PRS resource.
@@ -132,7 +144,7 @@ After successful connection, UE starts estimating channel based on the downlink
 
 At UE side, T tracer is used to dump PRS channel estimates, both in time and frequency domain using `UE_PHY_DL_CHANNEL_ESTIMATE` and `UE_PHY_DL_CHANNEL_ESTIMATE_FREQ` respectively. These dumps can be enabled using options `--T_stdout 0` without console prints or `--T_stdout 2` with console prints; in above nrUE launch command.<br><br>
 
-## Recording T tracer dumps
+# Recording T tracer dumps
 Once nrUE is launched with `--T_stdout 0 or 2` option, open another terminal. Navigate to T tracer directory ```common/utils/T/tracer/``` and build the T tracer binary using ```make```
 
 Once the build is successful, execute following command to start recording the PRS channel estimates dumps
@@ -150,7 +162,7 @@ and textlog it on another terminal with following command:
 
 ```./textlog -d ../T_messages.txt -ON -no-gui```<br><br>
 
-## Extracting PRS channel estimates
+# Extracting PRS channel estimates
 Once T tracer dumps are recorded, PRS channel estimates can be extracted from .raw file using bash script `extract_prs_dumps.sh` in T tracer directory ```common/utils/T/tracer/```
 
 ```./extract_prs_dumps.sh -g <num_gnb> -n <num_resources> -f <recorded .raw file> -c <count>```
@@ -158,7 +170,7 @@ Once T tracer dumps are recorded, PRS channel estimates can be extracted from .r
 In the end, the script will zip all the extracted dumps to `prs_dumps.tgz`. Make sure to check help in running script using -h option: 
 ```./extract_prs_dumps.sh -h```<br><br>
 
-## Using Matlab/Octave script to visualize PRS channel estimates
+# Using Matlab/Octave script to visualize PRS channel estimates
 We have developed `plot_prs_Ttracer_dumps.m` script to visualize the extracted PRS dumps offline in Matlab/Octave. Location of the script is `openair1/PHY/NR_UE_ESTIMATION/plot_prs_Ttracer_dumps.m`
 
 Make sure to enter the parameters script asks as input like below:
@@ -170,7 +182,13 @@ Enter number of PRS respurces: <NumPRSResources>
 Enter number of active gNBs: <Active_gNBs>
 ```
 This script will read the IQ data from extracted PRS dumps(chF_gnbX_Y.raw and chT_gnbX_Y.raw) and plot them like below
-| ![PRS CFR FR2](../images/PRS_CFR_FR2_64PRB_8rsc.PNG) | ![PRS CIR FR2](../images/PRS_CIR_FR2_64PRB_8rsc.PNG) |
-|:----------------------------------------------------:|:----------------------------------------------------:|
-
-<p align="center"><b>Fig.1 - FR2 100MHz test</b></p>
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+         <img src="./images/PRS_CFR_FR2_64PRB_8rsc.PNG" alt="" border=1 height=400 width=500>
+         <img src="./images/PRS_CIR_FR2_64PRB_8rsc.PNG" alt="" border=1 height=400 width=500>
+         </img>
+         <figcaption align = "center"><b>Fig.1 - FR2 100MHz test</b></figcaption>
+    </td>
+  </tr>
+</table>

doc/RUN_NR_multiple_BWPs.md

@@ -4,22 +4,22 @@
 
 ### Developers: Abhijith A, Shruthi S
 
-## Terminology
+# Terminology #
 
-### Bandwidth part (BWP)
+## Bandwidth part (BWP) ##
 Bandwidth Part (BWP) is a set of contiguous Resource Blocks in the resource grid. 
 
 Parameters of a BWP are communicated to UE using RRC parameters: BWP-Downlink and BWP-Uplink. 
 
 A UE can be configured with a set of 4 BWPs in uplink (UL) and downlink (DL) direction (3GPP TS 38.331 Annex B.2 Description of BWP configuration options). But only 1 BWP can be active in UL and DL direction at a given time.
 
-## Procedure to run multiple dedicated BWPs
+# Procedure to run multiple dedicated BWPs #
 
 A maximum of 4 dedicated BWPs can be configured for a UE.
 
 To configure multiple BWPs, add the following parameters in the physical parameters section:
 
-### Setup of the Configuration files
+## Setup of the Configuration files ##
 
 In the configuration file you have the option to select the 1st active BWP, the RIV and SCS of each BWP in the following way (example with 3 additional BWPs):
 ```
@@ -31,14 +31,14 @@ In the configuration file you have the option to select the 1st active BWP, the
 
 This example configures 3 additional BWPs, with IDs from 1 to 3. Find these parameters in this configuration file: "ci-scripts/conf_files/gnb.sa.band78.106prb.rfsim.neighbour.conf"
      
-## Testing gNB and UE in RF simulator
+# Testing gNB and UE in RF simulator
 
-### gNB command:
+## gNB command:
 ```
     sudo ./nr-softmodem -O ../../../ci-scripts/conf_files/gnb.sa.band78.106prb.rfsim.neighbour.conf --rfsim --rfsimulator.serveraddr server
 ```
 
-### UE command:
+## UE command:
 ```
     sudo ./nr-uesoftmodem -C 3319680000 -r 106 --numerology 1 --ssb 516 --band 78  --rfsim --rfsimulator.serveraddr 127.0.0.1
 ```

doc/SW_archi.md

@@ -1,3 +1,21 @@
+<style type="text/css" rel="stylesheet">
+
+body {
+   font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
+   font-size: 13px;
+   line-height: 18px;
+   color: #fff;
+   background-color: #110F14;
+}
+  h2 { margin-left: 20px; }
+  h3 { margin-left: 40px; }
+  h4 { margin-left: 60px; }
+
+.func2 { margin-left: 20px; }
+.func3 { margin-left: 40px; }
+.func4 { margin-left: 60px; }
+
+</style>
 
 ```mermaid
 flowchart TB
@@ -65,10 +83,11 @@ end
 ```
 
 This tuto for 5G gNB design, with Open Cells main
+{: .text-center}
 
-## The main thread is in ru_thread()
+# The main thread is in ru_thread()
 The infinite loop:
-### rx_rf()
+## rx_rf()
   Collect radio signal samples from RF board  
     all SDR processing is triggered by I/Q sample reception and it's date (timestamp)  
     TX I/Q samples will have a date in the future, compared to RX timestamp  
@@ -78,11 +97,11 @@ The infinite loop:
     (each sample has a incremental number representing a very accurate timing)  
 raw incoming data is in buffer called "rxdata"  
     We derivate frame number, slot number, ... from the RX timestamp
-
-### gNB_top()
+{: .func2}
+## gNB_top()
 only compute frame numbre, slot number, ...
-
-### ocp_rxtx()
+{: .func3}
+## ocp_rxtx()
 main processing for both UL and DL  
 start by calling oai_subframe_ind() that trigger processing in pnf_p7_subframe_ind() purpose ???  
 all the context is in the passed structure UL_INFO  
@@ -91,92 +110,92 @@ but not actual coherency (see below handle_nr_rach() assumes data is up-to-date)
 The first part (in NR_UL_indication, uses the data computed by the lower part (phy_procedures_gNB_uespec_RX), but for the **previous** slot  
 Then, phy_procedures_gNB_uespec_RX will hereafter replace the data for the next run  
 This is very tricky and not thread safe at all.
+{: .func3}
 
-
-#### NR_UL_indication()
+### NR_UL_indication()  
 This block processes data already decoded and stored in structures behind UL_INFO
-
+{: .func4}
 
 * handle_nr_rach()  
 process data from RACH primary detection  
 if the input is a UE RACH detection
-
+{: .func4}
     * nr_schedule_msg2()
-
+{: .func4}
 * handle_nr_uci()  
 handles uplink control information, i.e., for the moment HARQ feedback.
-
+{: .func4}
 * handle_nr_ulsch()  
 handles ulsch data prepared by nr_fill_indication()
-
+{: .func4}
 * gNB_dlsch_ulsch_scheduler ()  
 the **scheduler** is called here, see dedicated chapter
-
+{: .func4}
 * NR_Schedule_response()  
 process as per the scheduler decided
+{: .func4}
 
-
-#### L1_nr_prach_procedures()  
+### L1_nr_prach_procedures()  
 ????
-
-#### phy_procedures_gNB_uespec_RX()
+{: .func4}
+### phy_procedures_gNB_uespec_RX()
 * nr_decode_pucch0()  
 actual CCH channel decoding form rxdataF (rx data in frequency domain)  
 populates UL_INFO.uci_ind, actual uci data is in gNB->pucch  
-
+{: .func4}
 * nr_rx_pusch()  
-
+{: .func4}
     * extracts data from rxdataF (frequency transformed received data)
-
+{: .func4}
     * nr_pusch_channel_estimation()
-
+{: .func4}
     * nr_ulsch_extract_rbs_single()
-
+{: .func4}
     * nr_ulsch_scale_channel()
-
+{: .func4}
     * nr_ulsch_channel_level()
-
+{: .func4}
     * nr_ulsch_channel_compensation()
-
+{: .func4}
     * nr_ulsch_compute_llr()  
 this function creates the "likelyhood ratios"  
-
+{: .func4}
 * nr_ulsch_procedures()
-
+{: .func4}
     * actual ULsch decoding
-
+{: .func4}
     * nr_ulsch_unscrambling()
- 
+ {: .func4}
    * nr_ulsch_decoding()
- 
+ {: .func4}
    * nr_fill_indication()   
 populate the data for the next call to "NR_UL_indication()"  
 it would be better to call **NR_UL_indication()** now instead of before (on previous slot)
+{: .func4}
 
-
-#### phy_procedures_gNB_TX()
+### phy_procedures_gNB_TX()
 * nr_common_signal_procedures()  
 generate common signals
-
+{: .func4}
 * nr_generate_dci_top()
 generate DCI: the scheduling informtion for each UE in both DL and UL
-
+{: .func4}
 * nr_generate_pdsch()  
 generate DL shared channel (user data)
+{: .func4}
 
-
-#### nr_feptx_prec()
+### nr_feptx_prec()
 tx precoding
-
-#### nr_feptx0
+{: .func3}
+### nr_feptx0
 do the inverse DFT
-
-#### tx_rf()
+{: .func3}
+### tx_rf()
 send radio signal samples to the RF board  
 the samples numbers are the future time for these samples emission on-air
+{: .func3}
 
-
-## Scheduler
+# Scheduler
 
 The main scheduler function  is called by the chain: nr_ul_indication()=>gNB_dlsch_ulsch_scheduler()
 It calls sub functions to process each physical channel (rach, ...)  
@@ -255,7 +274,7 @@ nr_preprocessor_phytest()], multiple users [nr_dlsch_preprocessor()].
   process information, and fill nFAPI structures (allocate a DCI and PDCCH
   messages, TX_req, ...)
 
-## RRC
+# RRC
 RRC is a regular thread with itti loop on queue: TASK_RRC_GNB
 it receives it's configuration in message NRRRC_CONFIGURATION_REQ, then real time mesages for all events: S1/NGAP events, X2AP messages and RRC_SUBFRAME_PROCESS  
   
@@ -264,7 +283,7 @@ RRC_SUBFRAME_PROCESS message is send each subframe
 how does it communicate to  scheduler ?  
 
 
-## RLC
+# RLC
 RLC code is new implementation, not using OAI mechanisms: it is implemented directly on pthreads, ignoring OAI common functions.  
 It is a library, running in thread RRC but also in PHY layer threads and some bits in pdcp running thread or F1 interface threads.
 
@@ -283,9 +302,9 @@ nr_rlc_ms_tick() must be called periodically to manage the internal timers
 
 successful_delivery() and max_retx_reached(): in ??? trigger, the RLC sends a itti message to RRC: RLC_SDU_INDICATION (neutralized by #if 0 right now)
 
-### RLC data flow
+## RLC data flow
 
-#### TX Flow
+### TX Flow
 
 Incoming data to be transmitted is forwarded to RLC by PDCP via `rlc_data_req()`.
 
@@ -296,11 +315,11 @@ At the transport layer, in downlink (DL) at the gNB and uplink (UL) at UE, the s
 
 Subsequently, the scheduler issues commands to lower layers.
 
-#### RX Flow
+### RX Flow
 
 In the RX chain, in downlink (DL) at the UE and uplink (UL) at gNB, the transport layer pushes data into RLC through `mac_rlc_data_ind()`. Following this, RLC forwards the data to PDCP by invoking `pdcp_data_ind()` via a complex internal callback mechanism (`deliver_sdu()`).
 
-## PDCP
+# PDCP
 
 The PDCP implementation is secured by a general mutex, akin to the design of the RLC layer. This setup ensures that PDCP data remains isolated and encapsulated.
 
@@ -308,19 +327,19 @@ Initialization of the PDCP layer follows a structure similar to that of the RLC
 
 To manage UE connections, `nr_pdcp_add_srbs()` is employed for adding UE SRBs in PDCP, while `nr_pdcp_remove_UE()` is used for their removal. Similarly, `nr_pdcp_add_drbs()` adds UE DRBs in PDCP, with `nr_pdcp_remove_UE()` handling their removal.
 
-### PDCP Tx flow
+## PDCP Tx flow
 
 On the Tx side (downlink in gNB), the entry functions `nr_pdcp_data_req_drb()` and `nr_pdcp_data_req_srb()` are called by the upper layer. The upper layer could be GTP or a PDCP internal thread like `gnb_tun_read_thread()`, which reads directly from the Linux socket if the 3GPP core implementation is skipped. The PDCP internals for `nr_pdcp_data_req_srb()` and `nr_pdcp_data_req_drb()` are thread-safe. Within these functions, the PDCP manager protects access to the SDU receiving function of PDCP (`recv_sdu()` callback, corresponding to `nr_pdcp_entity_recv_pdu()` for DRBs) using mutex. When necessary, the PDCP layer pushes this data to RLC by calling `rlc_data_req()`.
 
-### PDCP Rx flow
+## PDCP Rx flow
 
 At the Rx side, `pdcp_data_ind()` serves as the entry point for receiving data from RLC. Within `pdcp_data_ind()`, the PDCP manager mutex protects access to the PDU receiving function of PDCP (`recv_pdu()` callback corresponding to `nr_pdcp_entity_recv_pdu()` for DRBs). Following this, the `deliver_sdu_drb()` function dispatches the received data to the SDAP sublayer.
 
-### PDCP security
+## PDCP security
 
 nr_pdcp_config_set_security(): sets the keys for AS security of a UE
 
-## AM DRB traffic flow in OAI
+# AM DRB traffic flow in OAI
 
 A sequence diagram of the traffic flow across PDCP and RLC layers. By default, data traffic is directed towards AM DRBs.
 
@@ -411,46 +430,46 @@ and for uplink:
     SG->>GG: send to GTP-U
 ```
 
-## GTP
+# GTP
 Gtp + UDP are two twin threads performing the data plane interface to the core network
 The design is hybrid: thread and inside other threads calls. It should at least be protected by a mutex.
-### GTP thread
+## GTP thread
 Gtp thread has a itti interface: queue TASK_GTPV1_U  
 The interface is about full definition: control messages (create/delet GTP tunnels) and data messages (user plane UL and DL).  
 PDCP layer push to the GTP queue (outside UDP thread that do almost nothing and work only with GTP thread) is to push a UL packet.
 
 
-### GTP thread running code from other layers
+## GTP thread running code from other layers
 gtp thread calls directly nr_pdcp_data_req_drb(), so it runs inside it's context internal pdcp structures updates
 
-### inside other threads
+## inside other threads
 gtpv1u_create_s1u_tunnel(), delete tunnel, ... functions are called inside the other threads, without mutex.
 
-## New GTP
-### initialization
+# New GTP
+## initialization
 
 gtpv1uTask(): this creates only the thread, doesn't configure anything
 gtpv1Init(): creates a listening socket to Linux for a given reception and select a local IP address
 
-### newGtpuCreateTunnel()
+## newGtpuCreateTunnel()   
 this function will replace the xxx_create_tunnel_xxx() for various cases  
 The parameters are: 
 1. outgoing TEid, associated with outpoing pair(rnti, id)
 2. incoming packets callback, incoming pair(rnti,id) and a callback function for incoming data 
 
-### outgoing packets
+## outgoing packets 
 
 Each call to newGtpuCreateTunnel() creates a outgoing context for a teid (given as function input), a pair(rnti,outgoing id).  
  Each outgoing packet received on GTP-U ITTI queue must match one pair(rnti,id), so the gtp-u thread can lookup the related TEid and use it to encode the outpoing GTP-U tunneled packet.  
 
-### incoming packets
+## incoming packets   
 
 newGtpuCreateTunnel() computes and return the incoming teid that will be used for incoming packets.
 When a incoming packet arrives on this incoming teid, the GTP-U thread calls the defined callback, with the associated pair(rnti, incoming id).  
 
 stuff like enb_flag, mui and more important data are not given explicitly by any legacy function (gtpv1u_create_s1u_tunnel), but the legacy and the new interface to lower layer (like pdcp) require this data. We hardcode it in first version.
 
-### remaining work
+## remaining work 
 These teids and "instance", so in a Linux socket: same teid can co-exist for different sockets
  Remain here a lack to fill: the information given in the legacy funtions is not enough to fullfil the data needed by the callback  
 
@@ -459,10 +478,17 @@ cmake new option: NEW_GTPU to use the new implementation (it changes for the ent
 It is possible to use both old and new GTP in same executable because the itti task and all functions names are different 
 Current status of new implementation: not tested, X2 not developped, 5G new GTP option not developped, remain issues on data coming from void: muid, enb_flag, ...
 
-## NGAP
+# NGAP
 NGAP would be a itti thread as is S1AP (+twin thread SCTP that is almost void processing)?  
 About all messages are exchanged with RRC thread  
 
 
+<div class="panel panel-info">
+**Note**
+{: .panel-heading}
+<div class="panel-body">
 
 
+</div>
+</div>
+

doc/SystemX-tutorial-design.md

@@ -1,6 +1,6 @@
 # OpenAirInterface for SystemX
 
-## Terminology
+# Terminology
 
 ****This document use the 5G terminology****
 
@@ -16,37 +16,37 @@ gNB functions, depending on the functional split option. Its operation
 is controlled by the CU. Distributed Unit (DU) also known with other
 names like RRH/RRU/RE/RU/PNF.
 
-> In OpenAir code, the terminology is often RU and BBU.
+In OpenAir code, the terminology is often RU and BBU.
 
-## OpenAirUsage
+# OpenAirUsage
 
-### EPC and general environment
+## EPC and general environment
 
-#### OAI EPC
+### OAI EPC
 
 Use the stable OAI EPC, that can run in one machine (VM or standalone)
 
-[Draft description](https://open-cells.com/index.php/2017/08/22/all-in-one-openairinterface-august-22nd/)
+Draft description:
+<https://open-cells.com/index.php/2017/08/22/all-in-one-openairinterface-august-22nd/>
 
-### Standalone 4G
+## Standalone 4G
 
 EPC+eNB on one machine, the UE can be commercial or OAI UE.
 
-#### USRP B210
+### USRP B210
 
-> **Main current issue** 
-> Traffic is good only on coaxial link between UE and
+Main current issue: traffic is good only on coaxial link between UE and
 eNB (probably power management issue).
 
-#### Simulated RF
+### Simulated RF
 
 Running eNB+UE both OAI can be done over a virtual RF link.
 
 The UE current status is that threads synchronization is implicit in
-some cases. As the RF simulator is very quick, a `“sleep()”` is required
+some cases. As the RF simulator is very quick, a “sleep()” is required
 in the UE main loop
 
-> (line 1744, targets/RT/USER/lte-ue.c).
+(line 1744, targets/RT/USER/lte-ue.c).
 
 Running also the UE in the same machine is possible with simulated RF.
 
@@ -106,26 +106,27 @@ The traffic genenrator has to specify the interface:
 route add default oaitun_ue1
 ```
 
-or specify the outgoing route in the traffic generator (like option `“-I”`
+or specify the outgoing route in the traffic generator (like option “-I”
 in ping command).
 
-### 5G and F1
+## 5G and F1
 
-> Today 5G achievement is limited to physical layer.
+Today 5G achievement is limited to physical layer.
 
-The available modulation is `40MHz`, that require one `X310` or `N300` for the
-gNB and a `X310` or `N300` for the nrUE.
+The available modulation is 40MHz, that require one X310 or N300 for the
+gNB and a X310 or N300 for the nrUE.
 
-#### Usage with X310
+### Usage with X310
 
-[Linux configuration](https://files.ettus.com/manual/page_usrp_x3x0_config.html)
+Linux configuration:
+<https://files.ettus.com/manual/page_usrp_x3x0_config.html>
 
 We included most of this configuration included in OAI source code.
 
-Remain to set the NIC (network interface card) MTU to `9000` (jumbo
+Remain to set the NIC (network interface card) MTU to 9000 (jumbo
 frames).
 
-#### Running 5G
+### Running 5G
 
 Usage with RFsimulator:
 

doc/TESTBenches.md

@@ -25,8 +25,8 @@
 | gracehopper3-oai | Gracehopper3       | build                | --                                                    |
 | acamas        | Acamas                | 4G and 5G rfsimulator| --                                                    |
 
-> **Note:** The available resources, and their current usage, is indicated here:
-> - [Lockable resources of jenkins-oai](https://jenkins-oai.eurecom.fr/lockable-resources/):
+Note: The available resources, and their current usage, is indicated here:
+- [Lockable resources of jenkins-oai](https://jenkins-oai.eurecom.fr/lockable-resources/):
   "New" Jenkins, i.e., with RAN-Container-Parent
 
 ## Testbenches
@@ -35,42 +35,42 @@
 
 **Purpose**: Over-the-air 4G/5G (NSA/SA) tests, performance tests
 
-![5G OTA Testbench](../testbenches_doc_resources/5g-ota-bench.png)
+![5G OTA Testbench](testbenches_doc_resources/5g-ota-bench.png)
 
-[LaTeX/TikZ version](../testbenches_doc_resources/5g-ota-bench.tex) if you want to modify to reflect your setup
+[LaTeX/TikZ version](testbenches_doc_resources/5g-ota-bench.tex) if you want to modify to reflect your setup
 
 
 ### 5G NSA/Faraday Cage Testbench
 
 **Purpose**: Faraday cage 5G tests, functional tests
 
-![5G NSA/Faraday Cage Testbench](../testbenches_doc_resources/5g-nsa-faraday-bench.png)
+![5G NSA/Faraday Cage Testbench](testbenches_doc_resources/5g-nsa-faraday-bench.png)
 
-[PDF version](../testbenches_doc_resources/5g-nsa-faraday-bench.pdf) | [LaTeX/TikZ version](../testbenches_doc_resources/5g-nsa-faraday-bench.tex) if you want to modify to reflect your setup
+[PDF version](testbenches_doc_resources/5g-nsa-faraday-bench.pdf) | [LaTeX/TikZ version](testbenches_doc_resources/5g-nsa-faraday-bench.tex) if you want to modify to reflect your setup
 
 ### 5G AW2S Testbench
 
 **Purpose**: AW2S tests with Amarisoft UE simulator
 
-![5G AW2S Testbench](../testbenches_doc_resources/5g-aw2s-bench.png)
+![5G AW2S Testbench](testbenches_doc_resources/5g-aw2s-bench.png)
 
-[PDF version](../testbenches_doc_resources/5g-aw2s-bench.pdf) | [LaTeX/TikZ version](../testbenches_doc_resources/5g-aw2s-bench.tex) if you want to modify to reflect your setup
+[PDF version](testbenches_doc_resources/5g-aw2s-bench.pdf) | [LaTeX/TikZ version](testbenches_doc_resources/5g-aw2s-bench.tex) if you want to modify to reflect your setup
 
 ### 5G UE OTA Testbench
 
 **Purpose**: Over-the-air 5G tests with OAI UE
 
-![OAI UE Testbench](../testbenches_doc_resources/5g-nrue-bench.png)
+![OAI UE Testbench](testbenches_doc_resources/5g-nrue-bench.png)
 
-[PDF version](../testbenches_doc_resources/5g-nrue-bench.pdf) | [LaTeX/TikZ version](../testbenches_doc_resources/5g-nrue-bench.tex) if you want to modify to reflect your setup
+[PDF version](testbenches_doc_resources/5g-nrue-bench.pdf) | [LaTeX/TikZ version](testbenches_doc_resources/5g-nrue-bench.tex) if you want to modify to reflect your setup
 
 ### 4G Testbench(es)
 
 **Purpose**: 4G/LTE testbenches
 
-![4G Faraday Cage Testbench](../testbenches_doc_resources/4g-faraday-bench.png)
+![4G Faraday Cage Testbench](testbenches_doc_resources/4g-faraday-bench.png)
 
-[PDF version](../testbenches_doc_resources/4g-faraday-bench.pdf) | [LaTeX/TikZ version](../testbenches_doc_resources/4g-faraday-bench.tex) if you want to modify to reflect your setup
+[PDF version](testbenches_doc_resources/4g-faraday-bench.pdf) | [LaTeX/TikZ version](testbenches_doc_resources/4g-faraday-bench.tex) if you want to modify to reflect your setup
 
 ## Pipelines
 
@@ -80,7 +80,7 @@
 Webhook ~documentation ~BUILD-ONLY ~4G-LTE ~5G-NR ~nrUE
 
 This pipeline has basically two main stages, as follows. For the image build,
-please also refer to the [dedicated documentation](../../docker/README.md) for
+please also refer to the [dedicated documentation](../docker/README.md) for
 information on how the images are built.
 
 #### Image Build pipelines
@@ -183,15 +183,15 @@ information on how the images are built.
 - [RAN-PhySim-Cluster-4G](https://jenkins-oai.eurecom.fr/job/RAN-PhySim-Cluster-4G/)
   ~4G-LTE
   - tests 4G physical simulators (`nr_dlsim`, etc.) in OpenShift Cluster (x86)
-  - see [`../usage/physical-simulators.md`](../usage/physical-simulators.md) for an overview
+  - see [`./physical-simulators.md`](./physical-simulators.md) for an overview
 - [RAN-PhySim-Cluster-5G](https://jenkins-oai.eurecom.fr/job/RAN-PhySim-Cluster-5G/)
   ~5G-NR ~nrUE
   - tests 5G physical simulators (`nr_dlsim`, etc.) in OpenShift Cluster (x86)
-  - see [`../usage/physical-simulators.md`](../usage/physical-simulators.md) for an overview
+  - see [`./physical-simulators.md`](./physical-simulators.md) for an overview
 - [RAN-PhySim-GraceHopper-5G](https://jenkins-oai.eurecom.fr/job/RAN-PhySim-GraceHopper-5G/)
   ~5G-NR ~nrUE
   - tests 5G physical simulators (`nr_dlsim`, etc.) on Nvidia GraceHopper (ARMv9)
-  - see [`../usage/physical-simulators.md`](../usage/physical-simulators.md) for an overview
+  - see [`./physical-simulators.md`](./physical-simulators.md) for an overview
 - [RAN-RF-Sim-Test-4G](https://jenkins-oai.eurecom.fr/job/RAN-RF-Sim-Test-4G/)
   ~4G-LTE
   - acamas (eNB, lteUE, OAI EPC)
@@ -300,7 +300,7 @@ as of which the pipeline failed. Let's assume the coredump is stored at
 `/tmp/coredump.tar.xz`, and the image is in `/tmp/oai-nr-ue.tar.gz`. First, you
 should check out the corresponding branch (or directly the commit), let's say
 in `~/oai-branch-fail`. Now, unpack the core dump, load the image into docker,
-and use the script [`docker/debug_core_image.sh`](../../docker/debug_core_image.sh)
+and use the script [`docker/debug_core_image.sh`](../docker/debug_core_image.sh)
 to open gdb, as follows:
 
 ```
@@ -340,7 +340,7 @@ right image (Ubuntu or RHEL)!
 
 #### Core dump in a file
 
-> **This is not recommended, as files could pile up and fill the system disk
+**This is not recommended, as files could pile up and fill the system disk
 completely!** Prefer another method further down.
 
 If the core pattern is a path: it should at least include the time in the
@@ -363,7 +363,7 @@ sudo coredumpctl dump <PID> > /tmp/coredump
 
 #### Core dump via abrt (automatic bug reporting tool)
 
-> TBD: use the documentation page for the moment.
+TBD: use the documentation page for the moment.
 
 #### Core dump via apport
 

doc/TESTING_GNB_W_COTS_UE.md

@@ -6,11 +6,13 @@ STATUS 2020/10/15 : added External Resources section and links
 
 ## External Resources
 
-Additional Resources to this page can be found [here](https://docs.google.com/document/d/1pL8Szm0ocGxdl5ESVp12Ff71a4PbhCb9SpvbLZzwYbo/edit?usp=sharing) (special mention to Walter Maguire, [wmaguire@live.com](mailto:wmaguire@live.com)).
+Additional Resources to this page can be found here (special mention to Walter Maguire <wmaguire@live.com>) :  
+https://docs.google.com/document/d/1pL8Szm0ocGxdl5ESVp12Ff71a4PbhCb9SpvbLZzwYbo/edit?usp=sharing  
 At time of writing, the openairinterface5G Commit Tag is 2020.w39
 
 
-Faraday Cages can be found [here](http://www.saelig.com/MFR00066/ste2300.htm)
+Faraday Cages can be found here :  
+http://www.saelig.com/MFR00066/ste2300.htm
 
 
 ## Configuration Overview
@@ -35,27 +37,27 @@ Our code might not work with all 5G phones yet, but we are constantly improving
 *  Simcom SIMCOM8200EA 
 *  Quectel RM500Q-GL
 
-> **Note1:** In the version we have at Eurecom, you need to set the PLMN to 50501, and you also need to change the firmware to "11.0.0 (RD1A.201105.003.B1, Nov 2020, EU carriers)" (see [here](https://developers.google.com/android/images))
+Note1: In the version we have at Eurecom, you need to set the PLMN to 50501, and you also need to change the firmware to "11.0.0 (RD1A.201105.003.B1, Nov 2020, EU carriers)" (see https://developers.google.com/android/images)
 
 ## Repository
 
-[https://gitlab.eurecom.fr/oai/openairinterface5g/tree/develop](https://gitlab.eurecom.fr/oai/openairinterface5g/tree/develop)
+https://gitlab.eurecom.fr/oai/openairinterface5g/tree/develop
 
 ## Architecture Setup
 
 The scheme below depicts our typical setup:
 
-![image info](../testing_gnb_w_cots_ue_resources/oai_fr1_setup.jpg)
+![image info](./testing_gnb_w_cots_ue_resources/oai_fr1_setup.jpg)
 
 The photo depicts the FR1 setup part of the scheme above:  
 
 
-![image info](../testing_gnb_w_cots_ue_resources/oai_fr1_lab.jpg)
+![image info](./testing_gnb_w_cots_ue_resources/oai_fr1_lab.jpg)
 
 ## Build and Install
 
 General guidelines to build eNB and gNB :
-See [here](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/doc/BUILD.md#building-ues-enodeb-and-gnodeb-executables)
+See https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/doc/BUILD.md#building-ues-enodeb-and-gnodeb-executables
 
 
 - **eNB**
@@ -81,7 +83,7 @@ cd cmake_targets/
 - **EPC**
 
 for reference:
-[https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME.md](https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME.md)
+https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME.md
 
 
 
@@ -196,7 +198,7 @@ The test takes typically a few seconds, max 10-15 seconds. If it takes more than
 - **EPC** (on EPC host):
 
 for reference:
-[https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME.md](https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME.md)
+https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME.md
 
 
 
@@ -212,7 +214,7 @@ Execute:
 - **gNB** (on the gNB host)
 
 
-> **ATTENTION** : for the gNB execution,
+**ATTENTION** : for the gNB execution,    
 The **-E** option is required to enable the tri-quarter sampling rate when using a B2xx serie USRP  
 The **-E** option is **NOT supported** when using a a N300 USRP  
 
@@ -227,9 +229,9 @@ Execute:
 
 The test case corresponds to the UE attachement, that is the UE connection and its initial access in 5G, as depicted below:
 
-**Source** : [5G_LTE_Interworking.html](https://www.sharetechnote.com/html/5G/5G_LTE_Interworking.html)
+**Source** : https://www.sharetechnote.com/html/5G/5G_LTE_Interworking.html  
 
-![image info](../testing_gnb_w_cots_ue_resources/attach_signaling_scheme.jpg)
+![image info](./testing_gnb_w_cots_ue_resources/attach_signaling_scheme.jpg)
 
 The test reaches step **12. E-RAB modifcation confirmation** , eventhough not all the messages will appear in the log file. 
 

doc/UnitTests.md

@@ -12,7 +12,7 @@ GoogleTest is a C++ unit testing framework that has been added as an external de
 See [primer](http://google.github.io/googletest/primer.html) for a quick introduction. To add it to your test executable link against
 `GTest::gtest` or `GTest::gtest_main`.
 
-## How to compile tests
+# How to compile tests
 
 To compile only the tests, a special target `tests` is available. It has to be
 enabled with the special cmake variable `ENABLE_TESTS`:
@@ -26,7 +26,7 @@ ninja tests
 
 The user can use either `ninja` or `make`.
 
-## Run unit tests
+# Run unit tests
 
 Then, you can run `ctest` to run all tests:
 
@@ -75,7 +75,7 @@ if(ENABLE_TESTS)
 endif()
 ```
 
-> **Note** that this might get more complicated, e.g., typically you will have to
+Note that this might get more complicated, e.g., typically you will have to
 link some library into the executable with `target_link_libraries()`, or pass
 some option to the test program.
 
@@ -116,7 +116,7 @@ that directory directly, which you might also use to compare to the
    directly declare the executable in `add_test()`, and `ctest` will locate and
    run the executable properly.
 
-## Benchmarking
+# Benchmarking
 
 Google benchmark can be used to profile and benchmark small pieces of code. See
 `benchmark_rotate_vector` for reference implementation. To start benchmarking code,
@@ -147,7 +147,7 @@ BM_rotate_cpx_vector/16384       4220 ns         4220 ns       169070
 BM_rotate_cpx_vector/20000       5288 ns         5289 ns       136190
 ```
 
-### Comparing results
+## Comparing results
 
 Benchmark results can be output to json by using command line arguments, example below
 

doc/analog_beamforming.md

@@ -2,7 +2,7 @@ This document explains the implementation of analog beamforming in OAI codebase.
 
 [[_TOC_]]
 
-## Introduction to analog beamforming
+# Introduction to analog beamforming
 
 Beamforming is a technique applied to antenna arrays to create a directional radiation pattern. This often consists in providing a different phase shift to each element of the array such that signals with a different angle of arrival/departure experience a change in radiation pattern because of constructive or destructive interference.
 
@@ -12,9 +12,9 @@ The presence of a limited number of predefined beams at RU poses constraints to
 
 Analog beamforming implementation also allows to enable distributed antenna systems (DAS), where each beam corrisponds to one antenna (or a set of antennas) of the system. In this scenario, the scheduler constaint is alleviated because normally the number of concurrent beams allowed equals the total number of beams.
 
-## Configuration file fields for analog beamforming
+# Configuration file fields for analog beamforming
 
-A set of parameters in configuration files controls the implementation of analog beamforming and instructs the scheduler on how to behave in such scenarios. Since most notably this technique in 5G is employed in FR2, the configuration file example currently available is a RFsim one for band 261. [Config file example](../../ci-scripts/conf_files/gnb.sa.band261.u3.32prb.rfsim.conf)
+A set of parameters in configuration files controls the implementation of analog beamforming and instructs the scheduler on how to behave in such scenarios. Since most notably this technique in 5G is employed in FR2, the configuration file example currently available is a RFsim one for band 261. [Config file example](../ci-scripts/conf_files/gnb.sa.band261.u3.32prb.rfsim.conf)
 
 In the `MACRLC` section of configuration files, there are three new parameters: `set_analog_beamforming`, `beam_duration` and `beams_per_period`. The explanation of these parameters is here provided:
 - `set_analog_beamforming` can be set a value equal to 1 or 2 to activate or 0 to desactivate analog beamforming (default value is 0)
@@ -26,7 +26,7 @@ Setting analog beamforming to 1 or 2 changes the way FAPI beam index is treated.
 
 DAS is enabled by setting to 1 the parameter `enable_das` in the L1 section of the configuration file. In case of DAS enabled, the field `beam_weights` in `MACRLC` section can be omitted.
 
-## Implementation in OAI scheduler
+# Implementation in OAI scheduler
 
 A new MAC structure `NR_beam_info_t` controls the behavior of the scheduler in presence of analog beamforming. Besides the already mentioned parameters `beam_duration` and `beams_per_period`, the structure also holds a matrix `beam_allocation[i][j]`, whose indices `i` and `j` stands respectively for the number of beams in the period and the slot index (the size of the latter depends on the frame characteristics).
 This matrix contains the beams already allocated in a given slot, to flag the scheduler to use one of these to schedule a UE in one of these beams. If the matrix is full (all the beams in the given period, e.g. slot) are already allocated, the scheduler can't allocate a UE in a new beam.
@@ -34,7 +34,7 @@ To this goal, we extended the virtual resource block (VRB) map by one dimension
 
 It is important to note that in current implementation, there are several periodical channels, e.g. PRACH or PUCCH for CSI et cetera, that have the precendence in being assigned a beam, that is because the scheduling is automatic, set in RRC configuration, and not up to the scheduler. For these instances, we assume the beam is available (if not there are assertions to stop the process). For data channels, the currently implemented PF scheduler is used. The only modification is that a UE can be served only if there is a free beam available or the one of the beams already in use correspond to that UE beam.
 
-## FAPI implementation
+# FAPI implementation
 
 To be noted that in our implementation analog beamforming is only supported in non-split/monolithic mode because we don't support yet SCF P19 interface that would be needed to manage these procedure in a split scenario with SCF FAPI.
 
@@ -46,14 +46,14 @@ In `config_request` structure, a vendor extension (`nfapi_nr_analog_beamforming_
 
 Additionally, L2 provides in each channel FAPI message information about the beam index. Small Cell Forum (SCF) FAPI provides in its PHY API specifications for the channels only a field for digital beamforming as part of the `precoding_and_beamforming` stucture. Therefore without a better option, we are currently using that one to store the internal analog beamforming index. This is the index used internally by the code to progressively identify the beam with a value from 0 to `total_num_beams_vendor_ext`.
 
-## L1 implementation
+# L1 implementation
 
 To handle multiple concurrent beams, the buffers containing Tx and Rx data in frequency domain (`txdataF` and `rxdataF`) have been extended by one dimension to contain multiple concurrent beams to be transmitted/received.
 The function `beam_index_allocation`, called by every L1 channel, is responsible to match the FAPI analog beam index to the RU beam index and to store the latter `beam_id` structure, which allocates the beams per symbol, despite L2 only supporting beam change at slot level. At the same time, the function returns the concurrent beam index, to be used to store data in frequency domain buffers. While doing so, the function also checks if there is room for current beam in the list of concurrent beams, which should always be the case, if L2 properly allocated the channels.
 
 In case of DAS, since each beam corresponds to a specific antenna port, the `beam_index_allocation` function is simplified in the sense that the beam index corresponds to the antenna port index of the frequency domain buffers.
 
-## RU implementation
+# RU implementation
 
 The implementation is still work in progress.
 

doc/clang-format.md

@@ -1,15 +1,15 @@
 We use [clang-format](https://clang.llvm.org/docs/ClangFormat.html) to format our code.
 
-## Integration into editors
+# Integration into editors
 
 Integration into various editors (`vim`, `emacs`, `VSCode`, `CLion`) is on the
 [clang-format project page](https://clang.llvm.org/docs/ClangFormat.html).
 
 There is also an [eclipse plugin](https://github.com/wangzw/CppStyle).
 
-## Integration into git
+# Integration into git
 
-### Short version
+## Short version
 
 See below for a more detailed explanation. In short: Add this to `~/.gitconfig`:
 ```
@@ -24,7 +24,7 @@ diff`. To add modified lines to your commit, stage them as well, then commit.
 There is also a pre-commit hook that you can install.  To install it, copy it
 `pre-commit-clang` to `.git/hooks/pre-commit`, and make it executable.
 
-### Long version
+## Long version
 
 In order to integrate `clang-format` into `git`, follow these steps:
 
@@ -65,6 +65,6 @@ When this is done, you are set up. How to use:
 6) Commit. It won't work if code is not properly formatted due to the
    pre-commit hook. Force committing with `git commit --no-verify`
 
-## Checking errors introduced by a branch
+# Checking errors introduced by a branch
 
-Here is the script that can be used to detect any clang-format errors introduced by a branch [here](../../tools/formatting/README.md)
+Here is the script that can be used to detect any clang-format errors introduced by a branch [here](../tools/formatting/README.md)

doc/code-style-contrib.md

@@ -4,13 +4,13 @@ review is performed.
 
 [[_TOC_]]
 
-## General
+# General
 
 OpenAirInterface employs both human review and automated CI tests to judge
 whether a code contribution is ready to be merged.
 
 The contributor has to sign a contributor license agreement (CLA) as described
-in [`CONTRIBUTING.md`](../../CONTRIBUTING.md). After creating an account on the
+in [`CONTRIBUTING.md`](../CONTRIBUTING.md). After creating an account on the
 Eurecom Gitlab, the contributor can open a merge request: he becomes the
 "author" of such code contribution. A senior OAI member will review this work,
 and make suggestions for possible improvements. Each week, we discuss the
@@ -19,18 +19,18 @@ call](https://gitlab.eurecom.fr/oai/openairinterface5g/-/wikis/OpenAirDevMeeting
 and discuss which merge requests can be merged.
 
 The CI consists in various Jenkins pipelines that run on each merge request.
-See [`TESTBenches.md`](../testing/TESTBenches.md) for more details about the CI setup.
+See [`TESTBenches.md`](./TESTBenches.md) for more details about the CI setup.
 
 There is the official [Gitlab Help](https://docs.gitlab.com/) that can help you
 with any questions regarding Gitlab. We recommend reading the [Git
 Book](https://git-scm.com/book/en/v2) to use Git properly.
 
-## Basic coding rules
+# Basic coding rules
 
 You should respect the `.clang-format` file in the root of the repository. The
 `clang-format` tool will pick up this file when being applied to code in the
 repository. Please also refer to the [corresponding
-documentation](clang-format.md).
+documentation](./clang-format.md).
 
 A number of high-level comments:
 
@@ -64,9 +64,9 @@ document](https://gitlab.eurecom.fr/oai/openairinterface5g/-/wikis/documents/ope
 that might be useful; if this document and `.clang-format` contradict,
 `.clang-format` takes precedence.
 
-## Main Workflow and Versioning
+# Main Workflow and Versioning
 
-### Workflow
+## Workflow
 
 You should be familiar with git branching, merging, and rebasing.
 
@@ -113,7 +113,7 @@ After some time, we make a stable release. For this, we simply merge develop
 into master, and give a semantic versioning number, e.g., `v1.1`. We target to
 make releases bi-yearly.
 
-### How to manage your own branch
+## How to manage your own branch
 
 Before starting to work, please make sure to branch off the latest `develop`
 branch.  Make commits as appropriate.
@@ -153,7 +153,7 @@ Once you rebased, push the changes to the remote
 $ git push origin my-new-feature --force-with-lease # force with lease let's you only overwrite what you also have locally in origin/my-new-feature
 ```
 
-## Merge Requests
+# Merge Requests
 
 A merge request (MR) can be submitted as soon as the code is considered stable
 and reviewable. The idea is to start the review early enough so that the code
@@ -196,7 +196,7 @@ Failure to add a label will prevent the CI from running. You can add both
 CI posts the results in the comments section of the merge request. Both merge
 request authors and reviewers are responsible for manual inspection and
 pre-filtering of the CI results. An overview of the CI tests is in
-[`TESTBenches.md`](../testing/TESTBenches.md).
+[`TESTBenches.md`](./TESTBenches.md).
 
 To communicate the review progress both between author and reviewer, as well as
 to the outside world, we (ab-)use the milestones feature of Gitlab to track the
@@ -215,7 +215,7 @@ during its lifetime in the sidebar on the right. Following options:
 - %OK_TO_BE_MERGED: the OAI team plans to merge this; *do not push any changes
   anymore at this point*.
 
-## Review Form
+# Review Form
 
 The following is a check list that might be used by a reviewer to check that
 code contribution fulfils minimum standard w.r.t. formatting, data types,
@@ -244,9 +244,9 @@ Additional optional questions in case they apply:
 - Has a new tool/dependency been introduced? Needs to be discussed if to be added.
 - Is a new CI test necessary? Can it be done in simulators?
 
-## Reporting bugs
+# Reporting bugs
 
-Please report only true bugs in the [issue tracker](../../../issues). Do not
+Please report only true bugs in the [issue tracker](../../issues). Do not
 report general user problems; use the [mailing
 lists](https://gitlab.eurecom.fr/oai/openairinterface5g/-/wikis/MailingList)
 instead.  If in doubt, prefer the mailing lists and if needed and requested by

doc/cross-compile.md

@@ -3,7 +3,7 @@ OpenAirInterface Cross-Compiler User Guide: explains how to build OAI for ARM64
 
 [[_TOC_]]
 
-## Environment
+# Environment
 
 Tested on Ubuntu 22. Newer version of Ubuntu should work as well, please file a
 bug report if not (Gitlab Issues page).
@@ -15,7 +15,7 @@ install the dependencies, if not done already:
 cmake_targets/build_oai -I
 ```
 
-## Install ARM64 dependencies
+# Install ARM64 dependencies
 
 Set up for install the package for ARM64.
 
@@ -57,9 +57,9 @@ The above enables apt to download packages for arm64. It also installs
 gcc cross-compilers for ARM64 in version 11. This version needs to match the
 versions of gcc defined in the cmake cross-compilation file (`cross-arm.cmake`).
 
-## Build for ARM64
+# Build for ARM64
 
-### Build code generation tools for host
+## Build code generation tools for host
 
 Use the x86 compiler to build the `ldpc_generators` and generate the header
 file in the `ran_build/build` folder.  They are necessary during a build for
@@ -76,7 +76,7 @@ cmake ../../..
 make -j`nproc` ldpc_generators generate_T
 ```
 
-### Build executables for ARM64
+## Build executables for ARM64
 
 Switch to the `ran_build/build-cross` folder to build the target executables
 for ARM. The `cross-arm.cmake` file defines some ARM-specific build tools
@@ -94,7 +94,7 @@ ninja lte-softmodem nr-softmodem nr-cuup oairu lte-uesoftmodem nr-uesoftmodem
 ninja params_libconfig coding rfsimulator
 ```
 
-## Further information
+# Further information
 
 You can do the above steps using docker, see dockerfiles
 `docker/Dockerfile.base.ubuntu.cross-arm64` and

doc/data_recording.md

@@ -17,7 +17,7 @@ Regarding to the APIs between different services, they are such as the following
 
 The following figure shows OAI gNB and UE with the Data Recording App system architecture. 
 
-![OAI gNB and UE with the Data Recording App system architecture](../images/data_recording_arch.svg)
+<img src="images/data_recording_arch.svg" alt="OAI gNB and UE with the Data Recording App system architectur" width="1000">
 
 ## Required Packages
 Install all required system packages with the following commands:
@@ -38,11 +38,11 @@ python3 -m pip install -r common/utils/data_recording/requirements.txt
 
 ## Configuration Files
 ### Main Data Recording JSON Configuration File
-The Data Recording application provides configuration file in [JSON](http://www.json.org/) format. It is stored in [common/utils/data_recording/config/config_data_recording.json](../../common/utils/data_recording/config/config_data_recording.json) folder. The main parameters are:
+The Data Recording application provides configuration file in [JSON](http://www.json.org/) format. It is stored in [common/utils/data_recording/config/config_data_recording.json](../common/utils/data_recording/config/config_data_recording.json) folder. The main parameters are:
 - **data_storage_path**: Path to directory for data storage
 - **num_records**: Number of requested data records in slots
 - **t_tracer_message_definition_file**: T-Tracer message definition file
-- **parameter_map_file**: Parameter mapping dictionary (OAI parameters to standardized metadata). It is located here: [common/utils/data_recording/config/wireless_link_parameter_map.yaml](../../common/utils/data_recording/config/wireless_link_parameter_map.yaml) 
+- **parameter_map_file**: Parameter mapping dictionary (OAI parameters to standardized metadata). It is located here: [common/utils/data_recording/config/wireless_link_parameter_map.yaml](../common/utils/data_recording/config/wireless_link_parameter_map.yaml) 
 - **start_frame_number**: It can be used to start the recording from a specific frame, but it is not yet supported.
 - **base_station**:
     - requested_tracer_messages: Requested base station data traces. The supported messages are:
@@ -119,7 +119,7 @@ The figure below illustrates an example of a JSON Data Recording App configurati
 ```
 
 ### Wireless Link Parameter Map Dictionary
-Since every signal recorder has related configuration with different naming scheme, the [common/utils/data_recording/config/wireless_link_parameter_map.yaml](../../common/utils/data_recording/config/wireless_link_parameter_map.yaml) is a dictionary to do the parameters pair between the signal configuration and the SigMF metadata (e.g. OAI parameter name vs. SigMF metadata parameter name). It eases of adoption in case of adding new parameters. In case of changing the name of given parameters in OAI and we need to get those parameters in metadata, the required changes need to be done in the parameter map dictionary.
+Since every signal recorder has related configuration with different naming scheme, the [common/utils/data_recording/config/wireless_link_parameter_map.yaml](../common/utils/data_recording/config/wireless_link_parameter_map.yaml) is a dictionary to do the parameters pair between the signal configuration and the SigMF metadata (e.g. OAI parameter name vs. SigMF metadata parameter name). It eases of adoption in case of adding new parameters. In case of changing the name of given parameters in OAI and we need to get those parameters in metadata, the required changes need to be done in the parameter map dictionary.
 
 The following figure shows an example of Wireless Link Parameter Map Dictionary. For example, the frequency range is called in standardized  SigMF metadata `frequency_range` while it is called in OAI `freq_range` and it is called in NI 5G NR RFmx `frequency range`.
 
@@ -141,7 +141,7 @@ The following figure shows an example of Wireless Link Parameter Map Dictionary.
 
 ### Global Metadata
 There are some metadata parameters that the user may need to change only once. Those parameters have been hard coded in the Data Recording App header.
-[common/utils/data_recording/data_recording_app_v1.0.py](../../common/utils/data_recording/data_recording_app_v1.0.py). Those are:
+[common/utils/data_recording/data_recording_app_v1.0.py](../common/utils/data_recording/data_recording_app_v1.0.py). Those are:
 - The global metadata such as: author, description,  sigmf collection file prefix, datetime_offset, enable saving config Data Recording App in json file with recorded data, and name of signal generator (i.e. 5gnr_oai). The name of signal generator is used for parameter mapping dictionary (OAI parameters to standardized metadata).
 - The mapping between supported OAI messages and file_name_prefix, scope, and description.
 
@@ -230,7 +230,7 @@ Run NR gNB Softmodem in RF Simulation:
 ```
 sudo ./cmake_targets/ran_build/build/nr-softmodem -O ./targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.band78.sa.fr1.106PRB.1x1.usrpx410_3300MHz.conf --gNBs.[0].min_rxtxtime 6 --rfsim --rfsimulator.serveraddr server --phy-test -d --T_stdout 2 --T_nowait
 ```
-> **Note:** User needs to change the name of gNB config file to your gNB config file.
+Note: User needs to change the name of gNB config file to your gNB config file. 
 
 It is worth mentioning that the possible values for T-tracer control options
 - --T_stdout option:  default 1
@@ -285,7 +285,7 @@ python3 data_recording_app_v1.0.py
 The recorded data set will be stored in the configured path, assume `/home/user/workarea/oai_recorded_data/`. 
 The following figure shows an example of recorded data set.
 
-![Example from SigMF recorded data set](../images/sigmf_dataset.svg)
+<img src="images/sigmf_dataset.svg" alt="Example from SigMF recorded data set" width="600">
 
 ## Overview on Collected Data Set
 
@@ -482,7 +482,7 @@ For synchronization validation and to show how to read SigMF metadata, a simple
     - Number of OFDM symbols = 13
     - So, the valid number of bits in the transport block (slot) is: 3312 bits. If we will fill DMRS locations by zeros, the number of bits is: 3744 bits, but it is not done due to the real-timing issues. For Tx scrambled bits data de-serialization, the user can reconstruct the Tx Scrambled Bits Grid (2D Grid) by using the captured DMRS grid or Channel Estimates Grid as a reference and no need to derive the DMRS symbols locations based on 5G NR config parameters.
 
-![Data serialization](../images/data_serialization_tx_scrambled_bit_message.svg)
+<img src="images/data_serialization_tx_scrambled_bit_message.svg" alt="Data serialization " width="500">
 
 ### To Do List:
 - Provide an overview about the different services of the Data Recording App (Data Control Service, Data collection (T-Tracer) Service, Data Conversion Service) and the APIs definition between them.

doc/dev_tools/sanitizers.md

@@ -1,15 +1,27 @@
-# OAI Build Procedures
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./../images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">OAI Build Procedures</font></b>
+    </td>
+  </tr>
+</table>
 
 [[_TOC_]]
 
-## Sanitize options in `build_oai`
+# Sanitize options in `build_oai`
 
 The `build_oai` script provides various [Instrumentation Options](https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html) to add run-time instrumentation to the code and enable runtime error checkers, i.e. sanitizers, in order to help find various types of bugs in the codebase and eventually enhance the stability of the OAI softmodems.  The following sanitizers can be enabled using different build options:
 
-### Address Sanitizer (ASAN)
+## Address Sanitizer (ASAN)
 [Address Sanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizer) is enabled using the `--sanitize-address` option or its shorthand `-fsanitize=address`. It serves as a fast memory error detector and helps detect issues like out-of-bounds accesses, use-after-free bugs, and memory leaks.
 
-#### Run OAI Softmodem with ASAN on
+### Run OAI Softmodem with ASAN on
 
 It is necessary to add the envinronment variable `LD_LIBRARY_PATH` to the run command, e.g.:
 ```
@@ -17,7 +29,7 @@ cd cmake_targets/ran_build/build
 sudo LD_LIBRARY_PATH=. ./nr-softmodem ...
 ```
 
-#### Possible problems
+### Possible problems
 
 On some systems with specific ASan versions, executing a program compiled with
 ASan might fail with an error `DEADLYSIGNAL`, or simply a segmentation fault.
@@ -36,7 +48,7 @@ sudo sysctl vm.mmap_rnd_bits=30
 which reduces the number of bits for memory mappings used to randomize mmap
 base addresses. _This reduces the security of the system._
 
-### Undefined Behavior Sanitizer (UBSAN)
+## Undefined Behavior Sanitizer (UBSAN)
 [Undefined Behavior Sanitizer](https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html) (UBSAN) is a runtime undefined behavior checker. It uses compile-time instrumentation to catch undefined behavior by inserting code that performs specific checks before operations that may cause it. UBSAN can be activated with the `--sanitize-undefined` option or `-fsanitize=undefined`.
 
 UBSAN offers a range of suboptions that enable precise checks for various types of undefined behavior at runtime. These suboptions can be set by tweaking the [CMakeLists.txt](../../CMakeLists.txt) file. Here is an overview of some key suboptions:
@@ -50,7 +62,7 @@ UBSAN offers a range of suboptions that enable precise checks for various types
 * `-fsanitize=object-size`: Checks out-of-bounds pointer accesses.
 * `-fsanitize=float-divide-by-zero`: Detects floating-point division by zero.
 
-### Memory Sanitizer
+## Memory Sanitizer
 To enable [Memory Sanitizer](https://clang.llvm.org/docs/MemorySanitizer.html), use the `--sanitize-memory` option or `-fsanitize=memory`. It requires clang and is incompatible with ASAN and UBSAN. Building with this option helps catch issues related to uninitialized memory reads.
 
 To build with Memory Sanitizer, use the following command:
@@ -58,10 +70,10 @@ To build with Memory Sanitizer, use the following command:
 CC=/usr/bin/clang CXX=/usr/bin/clang++ ./build_oai ... --sanitize-memory
 ```
 
-### Thread Sanitizer
+## Thread Sanitizer
 [Thread Sanitizer](https://clang.llvm.org/docs/ThreadSanitizer.html) can be activated using the `--sanitize-thread` option or `-fsanitize=thread`. This sanitizer helps identify data races and other threading-related issues in the code.
 
-## Summary of Sanitizer Options
+# Summary of Sanitizer Options
 
 - `--sanitize`: Shortcut for using both ASAN and UBSAN.
 - `--sanitize-address` or `-fsanitize=address`: Enable ASAN on all targets.

doc/environment-variables.md

@@ -9,7 +9,7 @@ OAI uses/supports a number of environment variables, documented in the following
 - `OAI_CONFIGMODULE`: can be used to pass the configuration file instead of `-O`
 - `OAI_GDBSTACKS`: if defined when hitting an assertion (`DevAssert()`, `AssertFatal()`, ...), OAI will load `gdb` and provide a backtrace for every thread
 - `OAI_RNGSEED`: overwrites any seed for random number generators (RNG) in simulators
-- `OAI_THREADPOOLMEASUREMENTS`: path to a file to store thread pool debugging information, see the [thread pool documentation](../../common/utils/threadPool/thread-pool.md)
+- `OAI_THREADPOOLMEASUREMENTS`: path to a file to store thread pool debugging information, see the [thread pool documentation](..common/utils/threadPool/thread-pool.md)
 - `OPENAIR_DIR`: should point to the root directory of OpenAirInterface; some code relies on this to get a filename, e.g., BLER curves for L2sim channel emulation
 - `USIM_DIR`: directory to read/write USIM data in (4G) `usim` tool; if not defined, will use `PWD` (working directory)
 

doc/episys/lte_mode_l2_emulator/README.txt

@@ -3,39 +3,37 @@ user to run multiple UEs in separate Linux processes/machines/VMs/etc. They use
 entity between the UE(s) and eNB. The UEs use nFAPI to communicate with the eNB. The
 nFAPI interface allows us to run in an emulated layer 2 mode, meaning that we are bypassing
 the layer 1 (PHY) functionality. Because we are bypassing the PHY layer,
-channel modeling capabilties have been added in the LTE UE `phy_stub_ue.c` file. To understand
-the interfaces between the different components associated with LTE mode, the image is shown below.
-
-![functional_diagram_proxy_lte](../images/functional_diagram_proxy_lte.png)
+channel modeling capabilties have been added in the LTE UE phy_stub_ue.c file. To understand
+the interfaces between the different components associated with LTE mode, the image
+functional_diagram_proxy_lte.png has been provided.
 
 This functionality allows the user to plug in their own channel model and emulate the packet dropping procedure
 in real time. The channel modeling has not been provided by EpiSci, but the OAI code
 base already has some BLER curves available for use. The channel modeling functionality
-that is included in the `phy_stub_ue.c` file only includes the downlink channel modeling.
+that is included in the phy_stub_ue.c file only includes the downlink channel modeling.
 Any uplink channel modeling must be conducted in some sort of proxy, which would sit
-between the UEs and eNB. (A description of the downlink channel modeling is illustrated below).
-
-![Channel_Abstraction_UE_Handling_LTE](../images/Channel_Abstraction_UE_Handling_LTE.PNG)
+between the UEs and eNB. (A description of the downlink channel modeling is shown in the
+Channel_Abstraction_UE_Handling_LTE.PNG image).
 
 The updates to the OAI code base removed some latent bugs, added multi-UE scalability,
 and were tested with a standard bypass proxy between the UE(s) and eNB. The bypass proxy is
-publicly available on [GitHub](https://github.com/EpiSci/oai-lte-multi-ue-proxy). With this package,
+publicly available on GitHub (https://github.com/EpiSci/oai-lte-multi-ue-proxy). With this package,
 various multi-UE scenarios can be tested without the overhead of PHY-layer features
 of underlying radios. The features added in the L2 Emulator Mode for LTE are:
 
  - Ease of use of gprof and address sanitizer for debugging purposes
  - Updated json files to allow for GDB, real-time debugging capabilities
  - Updated logging features to minimally log only key connection milestones. This improves scalability of multiple UEs.
-The logging mechanism described here is located in the `log.c` and `log.h` files. The `LOG_MINIMAL`
-function allows us to remove most OAI logging and includes `LOG_A(...)` logs and above. The `LOG_A`
-logs were chosen as analysis logs to meet EpiSci's internal testing procedure. The `LOG_As`
+The logging mechanism described here is located in the log.c and log.h files. The LOG_MINIMAL
+function allows us to remove most OAI logging and includes LOG_A(...) logs and above. The LOG_A
+logs were chosen as analysis logs to meet EpiSci's internal testing procedure. The LOG_As
 only include logs that are considered to be milestones in a given test. For example, a
 log indicating that the RACH procedure has been completed for LTE. To select full logging, 
-set `LOG_MINIMAL = 0` in the `log.h` file.
+set LOG_MINIMAL = 0 in the log.h file.
  - Updated logging to include time stamp for timing analysis
  - Updated memory allocation procedures to correct size requirements
  - Added debugging features to handle signal terminations
- - `nfapi.c` pullarray8 fix invalid pointer math
+ - nfapi.c pullarray8 fix invalid pointer math
  - Overlapping destination and source memory in memcpy, so updated to memmove to check for this bug
  - Advanced error checking mechanisms in critical pack and unpack functions
  - Created option for CPU assignment to UE to improve scalability
@@ -43,8 +41,8 @@ set `LOG_MINIMAL = 0` in the `log.h` file.
  - Updated random value seeds to minimize probability of error in generation of random values
  - Enables capability round robin scheduler if desired
  - Enables capability real time scheduler if desired
- - Added new standalone functions to the UE phy-layer (`phy_stub_ue.c`) to incorporate individual UE entities
- - Updated sending and packing functions in UE (`lte_ue.c`) to incorporate new standalone changes
+ - Added new standalone functions to the UE phy-layer (phy_stub_ue.c) to incorporate individual UE entities
+ - Updated sending and packing functions in UE (lte_ue.c) to incorporate new standalone changes
  - Incorporated semaphores to control timing of incoming downlink packets
  - Implemented new queuing system to handle message exchange from UE to eNB and vice versa
  - Updated global value in nFAPI for size of subframe

doc/episys/nsa_mode_l2_emulator/README.txt

@@ -3,39 +3,37 @@ user to run multiple UEs in separate Linux processes/machines/VMs/etc. They use
 entity between the UE(s) and eNB/gNB. The UEs use nFAPI to communicate with the eNB/gNB. The
 nFAPI interface allows us to run in an emulated L2 mode, meaning that we are bypassing
 the layer 1 (PHY) layer functionality. Becasue we are bypassing the PHY layer, special
-channel modeling capabilty has been added in the LTE UE `phy_stub_ue.c` file. To understand
-the interfaces between the different components associated with NSA mode, the image is shown below.
-
-![functional_diagram_proxy_nsa](../images/functional_diagram_proxy_nsa.png)
+channel modeling capabilty has been added in the LTE UE phy_stub_ue.c file. To understand
+the interfaces between the different components associated with NSA mode, the image
+functional_diagram_proxy_nsa.png has been provided.
 
 This functionality allows the user to plug in their own channel model and emulate the packet dropping procedure
 in real time. The channel modeling has not been provided by EpiSci, but the OAI code
 base already has some BLER curves available for use. The chanel modeling functionality
-that is included in the `phy_stub_ue.c` file only includes the downlink channel modeling.
+that is included in the phy_stub_ue.c file only includes the downlink channel modeling.
 Any uplink channel modeling must be conducted in some sort of proxy, which would sit
-between the UEs and eNB/gNB. (A description of the downlink channel modeling is illustrated below).
-
-![Channel_Abstraction_UE_Handling_LTE](../images/Channel_Abstraction_UE_Handling_LTE.PNG)
+between the UEs and eNB/gNB. (A description of the downlink channel modeling is shown in the
+Channel_Abstraction_UE_Handling_LTE.PNG image).
 
 The updates to the OAI code base removed some latent bugs, added multi-UE scalability,
 and were tested with a standard bypass proxy between the UE(s) and eNB/gNB. The bypass proxy is
-publicly available on [GitHub](https://github.com/EpiSci/oai-lte-multi-ue-proxy). With this package,
+publicly available on GitHub (https://github.com/EpiSci/oai-lte-multi-ue-proxy). With this package,
 various multi-UE scenarios can be tested without the overhead of PHY-layer features
 of underlying radios. The added features to the OAI code base are listed below.
 
  - Ease of use of gprof and address sanitizer for debugging purposes
  - Updated json files to allow for GDB, real-time debugging capabilities
  - Updated logging features to minimally log only key connection milestones. This improves scalability of multiple UEs.
-The logging mechanism described here is located in the `log.c` and `log.h` files. The `LOG_MINIMAL`
-function allows us to remove most logs and include `LOG_A(...)` logs and above. The `LOG_A`
-logs were chosen as analysis logs to meet EpiSci's internal testing procedure. The `LOG_As`
+The logging mechanism described here is located in the log.c and log.h files. The LOG_MINIMAL
+function allows us to remove most logs and include LOG_A(...) logs and above. The LOG_A
+logs were chosen as analysis logs to meet EpiSci's internal testing procedure. The LOG_As
 only include logs that are considered to be milestones in a given test. For example, a
 log indicating that the CFRA procedure has been completed for NSA mode. To revert to full logging, 
-set `LOG_MINIMAL = 0` in the `log.h` file.
+set LOG_MINIMAL = 0 in the log.h file.
  - Updated logging to include time stamp for timing analysis
  - Updated memory allocation procedures to correct size requirements
  - Added debugging features to handle signal terminations
- - `nfapi.c` pullarray8 fix invalid pointer math
+ - nfapi.c pullarray8 fix invalid pointer math
  - Overlapping destination and source memory in memcpy, so updated to memmove to check for this bug
  - Advanced error checking mechanisms in critical pack and unpack functions
  - Created option for CPU assignment to UE to improve scalability
@@ -43,8 +41,8 @@ set `LOG_MINIMAL = 0` in the `log.h` file.
  - Updated random value seeds to minimize probability of error in generation of random values
  - Enables capability round robin scheduler if desired
  - Enables capability real time scheduler if desired
- - Added new standalone functions to the UE phy-layer (`phy_stub_ue.c`) to incorporate individual UE entities
- - Updated sending and packing functions in UE (`lte_ue.c`) to incorporate new standalone changes
+ - Added new standalone functions to the UE phy-layer (phy_stub_ue.c) to incorporate individual UE entities
+ - Updated sending and packing functions in UE (lte_ue.c) to incorporate new standalone changes
  - Incorporated semaphores to control timing of incoming downlink packets
  - Implemented new queuing system to handle message exchange from UE to eNB and vice versa
  - Updated global value in nFAPI for size of subframe
@@ -54,7 +52,7 @@ set `LOG_MINIMAL = 0` in the `log.h` file.
 Additionally, NSA mode includes the establishment between an NR UE and the gNB via the LTE UE and eNB
 connection. For NSA mode, the downlink channel abstraction has not been added to the feature set yet.
 NSA mode has been tested and is fully functional with EpiSci's public version of the nFAPI proxy
-located at [GitHub Repository](https://github.com/EpiSci/oai-lte-multi-ue-proxy)
+located at https://github.com/EpiSci/oai-lte-multi-ue-proxy
 NSA mode establishment includes the following steps:
 
  - First UE capability enquiry is sent to NR UE
@@ -76,23 +74,21 @@ NSA mode establishment includes the following steps:
  - Msg 3 is generated and sent to gNB
  - CFRA procedure is complete
 
-**Please note, the current status is:**
-
+Please note, the current status is:
  - A single NSA UE is able to ping an external source
  - Up to 4 NSA UEs can complete the CFRA procedure with a single gNB
  - UE-to-UE traffic is still in work (incomplete due to gNB crashing)
  - The gNB is crashing regularly and is still in work
 
-**Test Setup:**
-
+Test Setup:
 For launching the multi-UE for NSA mode, there is a provided test script in the
 public EpiSci GitHub multi-ue-proxy repository. However, a brief outline of the
 test set up is included below.
 
-If running multiple NSA UEs in a single machine, you will need to launch
-multiple LTE and NR UE processes. For example, to launch a 2 NSA UE scenario
-there will be a total of 7 processes running for this particular scenario.
-These processes are `LTE UE #1`, `LTE UE #2`, `NR UE #1`, `NR UE #2`, `eNB`, `gNB` and the
-`proxy`. A detailed description of the launch processes can be found at
-[GitHub Repository](https://github.com/EpiSci/oai-lte-multi-ue-proxy/blob/master/README.md)
+    If running multiple NSA UEs in a single machine, you will need to launch
+    multiple LTE and NR UE processes. For example, to launch a 2 NSA UE scenario
+    there will be a total of 7 processes running for this particular scenario.
+    These processes are LTE UE #1, LTE UE #2, NR UE #1, NR UE #2, eNB, gNB and the
+    proxy. A detailed description of the launch processes can be found at
+    https://github.com/EpiSci/oai-lte-multi-ue-proxy/blob/master/README.md
 

doc/handover-tutorial.md

@@ -3,7 +3,7 @@ handovers are supported.
 
 [[_TOC_]]
 
-## Considered setup for F1 handover
+# Considered setup for F1 handover
 
 We consider one CU and two DUs, connected over F1. The UE is initially
 connected over the radio interface ("Uu") to DU0. Via movement to a new
@@ -11,15 +11,15 @@ position ("new pos"), it will trigger an event such that the CU triggers a
 handover of the UE from DU0 to DU1. Alternatively, a manual trigger can do the
 same.
 
-![F1 Handover setup](../RRC/ho.png)
+![F1 Handover setup](./RRC/ho.png)
 
-## Steps to run F1 handover with OAI UE
+# Steps to run F1 handover with OAI UE
 
 Measurement reporting and processing of RRC Reconfiguration for Mobility are
 not completed at the UE. Nevertheless, it is possible to make simple handover
 tests without any radio setup, on a single PC, with the OAI UE, in RFsimulator.
 
-### Build with telnet support
+## Build with telnet support
 
 Since the UE does not support any measurement reporting, it cannot trigger a
 handover on its own; it has to be triggered manually through telnet. Thus,
@@ -27,17 +27,17 @@ build both gNB and UE as well as activate the build of telnet to that purpose:
 
     ./build_oai --ninja --nrUE --gNB --build-lib telnetsrv
 
-### Run the setup
+## Run the setup
 
 This tutorial assumes you have a core network running; [refer to the
 corresponding tutorial](./NR_SA_Tutorial_OAI_CN5G.md) if this is not the case
 yet.
 
 We will use the TDD configuration files in the repository for the
-[CU](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb-cu.sa.f1.conf) as well for
-[DU0](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb-du.sa.band78.106prb.rfsim.pci0.conf)
+[CU](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb-cu.sa.f1.conf) as well for
+[DU0](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb-du.sa.band78.106prb.rfsim.pci0.conf)
 and
-[DU1](../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb-du.sa.band78.106prb.rfsim.pci1.conf).
+[DU1](../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb-du.sa.band78.106prb.rfsim.pci1.conf).
 Note how the DUs differ in their DU ID (for identification at the CU), nr
 cellid (global identification), physical cell ID (identification through UE),
 frequency (limitation at OAI UE), and IP address.
@@ -94,7 +94,7 @@ A number of remarks:
 1. In some cases, if the RFsim server is at the UE, the whole system can block;
    in this case, stop UE and all DUs and restart (the CU can keep running).
 
-### Additional information to the manual HO trigger
+## Additional information to the manual HO trigger
 
 You can trigger the handover manually by logging in through telnet:
 
@@ -117,7 +117,7 @@ and you have to manually type the CU UE ID. You can see a list of all UEs in
 the file `nrRRC_stats.log` that is printed periodically in the working
 directory of the CU.
 
-## Steps to run F1 handover with COTS UE
+# Steps to run F1 handover with COTS UE
 
 You can do handover across DUs with a COTS UE. Note that these DUs should be
 separated by at least multiple meters to ensure that the UE will receive
@@ -130,7 +130,7 @@ For UEs, we verified Quectel modules and iPhones. Note, though, that not all
 phones might work; for instance, we did not achieve handovers with a OnePlus
 Nord, yet.
 
-### Steps
+## Steps
 
 First, make sure that you can run both DUs with the CU independently. Use the
 same radio hardware for both radios to ensure that both cells can be received
@@ -146,7 +146,7 @@ neighbour relation of the DUs at the CU. To do so, proceed as follows:
    ```
    cat nrRRC_stats.log
    ```
-1. Fill in the [`neighbour-config.conf`](../../ci-scripts/conf_files/neighbour-config.conf) configuration file as shown below, and
+1. Fill in the [`neighbour-config.conf`](../ci-scripts/conf_files/neighbour-config.conf) configuration file as shown below, and
    `@include` it in the CU file.
 1. Start the CU and both DUs.
 1. Bring the phone close to one cell, and leave flight mode. It should connect
@@ -171,7 +171,7 @@ through measurements telling the CU that one DU is stronger than others.
 Hence, "forcing" a handover just means that you manually trigger the handover,
 instead of waiting for UE measurement report.)
 
-### Example neighbour configuration
+## Example neighbour configuration
 
 Below is an example neighbour configuration. It is based on this DU information
 gathered from `nrRRC_stats.log` at the CU:
@@ -262,13 +262,13 @@ nr_measurement_configuration = {
 
 ```
 
-## Handovers triggers and NTN
+# Handovers triggers and NTN
 
 Typically, in terrestrial networks, channel measurements as well as criteria
 such as load in base stations, is used to determine when and where to handover
 a UE.
 
-### NTN
+## NTN
 
 Doppler spreading and time selectivity of the channel are already a challenge
 for conventional terrestrial networks. However, in the context of
@@ -323,7 +323,7 @@ are as follows:
   which sends the preamble. However, UEs with GNSS support are required to
   perform this method.
 
-### Simple location/time-based trigger
+## Simple location/time-based trigger
 
 A location-based handover trigger, somewhat aligned with 3GPP Rel.17, taking
 advantage of deterministic satellite movement, can be implemented whereby it is
@@ -343,9 +343,9 @@ while true; do
 done
 ```
 
-## N2 Handover
+# N2 Handover
 
-### Run the setup
+## Run the setup
 
 An N2 handover involves the transfer of a UE from one gNB to another via the 5G core network. Unlike F1 handover, where the CU handles the process internally between its DUs, N2 handover requires signaling through the AMF, making it a core-network-based handover.
 
@@ -355,7 +355,7 @@ We assume:
 * A UE initially connected to gNB-PCI0, which will be handed over to gNB-PCI1.
 * Handover is triggered by either by decision based measurement event (e.g. A3) or telnet command.
 
-### Steps to run N2 handover with OAI UE
+## Steps to run N2 handover with OAI UE
 
 1. Similarly to F1 handover, UE does not support any measurement reporting and handover is triggered by
 telnet command. Therefore, ensure that both gNBs and UE are built with telnet support:
@@ -364,7 +364,7 @@ telnet command. Therefore, ensure that both gNBs and UE are built with telnet su
 ./build_oai --ninja --nrUE --gNB --build-lib telnetsrv
 ```
 
-Run the 5G Core Network if not already running. See [OAI CN5G tutorial](NR_SA_Tutorial_OAI_CN5G.md).
+Run the 5G Core Network if not already running. See [OAI CN5G tutorial](./NR_SA_Tutorial_OAI_CN5G.md).
 
 2. Start the source gNB (gNB-PCI0) e.g.
 
@@ -397,7 +397,7 @@ where the input parameters correspond to the PCI of the neighbor call and the RR
 
 This will initiate the N2 handover on the source gNB.
 
-### Neighbour list and measurement configuration
+## Neighbour list and measurement configuration
 
 Make sure the configuration file contains a neighbour list and measurement configuration, e.g. [neighbour-config-rfsim.conf](../../ci-scripts/conf_files/neighbour-config.conf). This configuration can also be present in a different file and included in the gNB configuration file with `@include "neighbour-config-rfsim.conf"`.
 

doc/iqrecordplayer_usage.md

@@ -1,7 +1,8 @@
 # I/Q record-replay
 ## using the iq record-replay
 
-This feature provides I/Q record-replay as initially presented in the [4th OAI workshop for LTE](https://www.openairinterface.org/docs/workshop/4_OAI_Workshop_20171107/Talks/MONGAZON_Nokia-Bell-Labs-OAI-IQ.pdf)
+This feature provides I/Q record-replay as initially presented in the 4th OAI workshop for LTE
+(https://www.openairinterface.org/docs/workshop/4_OAI_Workshop_20171107/Talks/MONGAZON_Nokia-Bell-Labs-OAI-IQ.pdf)
 The current implementation has been temporarily disrupted for LTE and only works for 5G SA
 nr-uesoftmodem executable.
 

doc/nfapi.md

@@ -10,7 +10,7 @@ about nFAPI can be found in SCF 225.2.0.
 
 [[_TOC_]]
 
-## Quickstart
+# Quickstart
 
 Compile OAI as normal. Start the CN and make sure that the VNF configuration
 matches the PLMN/IP addresses. Then, run the VNF
@@ -29,7 +29,7 @@ VNF!)
 You should not observe a difference between nFAPI split and monolithic.
 
 
-## Status
+# Status
 
 All FAPI message can be transferred between VNF and PNF. This is because OAI
 uses FAPI with its corresponding messages internally, whether a split is in use
@@ -54,7 +54,7 @@ When using RFsim, the system might run slower than in monolithic. This is
 because the PNF needs to slow down the execution time of a specific slot,
 because it has to send a Slot.indication to the VNF for scheduling.
 
-## Configuration
+# Configuration
 
 Both PNF and VNF are run through the `nr-softmodem` executable. The type of
 mode is switched through the `--nfapi` switch, with options `MONOLITHIC`
@@ -70,7 +70,7 @@ If the type is `VNF`, you have to modify the `MACRLCs.tr_s_preference`
 - `MACRLCs.local_s_portd` (local south port for control): VNF's P5 local port
 - `MACRLCs.remote_s_portd` (remote south port for data): PNF's P7 remote port
 
-> Note that any L1-specific section (`L1s`, `RUs`,
+Note that any L1-specific section (`L1s`, `RUs`,
 RFsimulator-specific/IF7.2-specific configuration or other radios, if
 necessary) will be ignored and can be deleted.
 
@@ -84,7 +84,7 @@ If the type is `PNF`, you have to modify modify the `L1s.tr_n_preference`
 - `L1s.local_n_portd` (local north port for data): PNF's P7 local port
 - `L1s.remote_n_portd` (remote north port for data): VNF's P7 remote port
 
-> Note that this file should contain additional, L1-specific sections (`L1s`,
+Note that this file should contain additional, L1-specific sections (`L1s`,
 `RUs` RFsimulator-specific/IF7.2-specific configuration or other radios, if
 necessary).
 
@@ -109,10 +109,10 @@ can proceed as follows:
   `pnf.conf`, or provide them on the command line for the PNF.
 - to run, proceed as described in the quick start above.
 
-> Note: all L1-specific options have to be passed to the PNF, and remaining
+Note: all L1-specific options have to be passed to the PNF, and remaining
 options to the VNF.
 
-### Transport mechanisms between VNF and PNF
+## Transport mechanisms between VNF and PNF
 
 Currently, the VNF/PNF split supports three transport mechanisms between each
 other:
@@ -121,8 +121,7 @@ other:
 
    The socket type may be changed by editing `nfapi_pnf_config_create()` and
    `nfapi_vnf_config_create()`, in both of which `_this->sctp = <value, 0 or
-   1>;` indicate whether SCTP or regular sockets are to be used.  
-   > Note: The
+   1>;` indicate whether SCTP or regular sockets are to be used.  Note: The
    value of `_this->sctp` **must** be the same on the VNF and PNF.
 2. Intel WLS Lib, which uses DPDK to achieve a shared memory communication between components.
 3. nvIPC, which is used exclusively for the NVIDIA Aerial L1. Thus, it is only
@@ -132,15 +131,15 @@ The change between transport mechanisms is done at compilation time:
 - No changes to the `build_oai` call are required in order to select socket communication, as it is the default.
 - In order to select WLS as the transport mechanism between VNF and PNF, first install the WLS library, and afterwards use `-t WLS` as a parameter of `build_oai`:
 
-#### How to use nFAPI
+### How to use nFAPI
 
 nFAPI is used by default. Compile and configure as indicated above.
 
-#### How to use Aerial
+### How to use Aerial
 
-Refer to [this document](../tutorials/Aerial_FAPI_Split_Tutorial.md) for more information.
+Refer to [this document](./Aerial_FAPI_Split_Tutorial.md) for more information.
 
-#### How to use WLS lib
+### How to use WLS lib
 
 Before the first compilation with WLS support, the [WLS
 library](https://docs.o-ran-sc.org/projects/o-ran-sc-o-du-phy/en/latest/wls-lib.html)
@@ -153,7 +152,7 @@ The WLS library has a few dependencies:
 
 Additionally, a patch needs to be applied to the WLS lib Makefile in order for
 the shared library and headers to be installed into the system, the necessary
-patch is available [here](../../cmake_targets/tools/install_wls_lib.patch)
+patch is available [here](../cmake_targets/tools/install_wls_lib.patch)
 
 Clone the code and apply the patch
 
@@ -170,11 +169,11 @@ After installing WLS, you can run the build command as shown below:
 
     ./build_oai -t WLS -w USRP --gNB --nrUE --ninja -C
 
-##### How to run OAI PNF with OAI VNF
+#### How to run OAI PNF with OAI VNF
 
 Refer to the above steps in [Quickstart](#quickstart), but run the PNF first as it is the WLS "master".
 
-##### How to run OAI PNF with OSC/Radisys O-DU
+#### How to run OAI PNF with OSC/Radisys O-DU
 
 Set up the hugepages for DPDK (1GB page size, 6 pages; this only needs to be
 done once):
@@ -218,7 +217,7 @@ Run the O-DU over GDB
 
     sudo -E gdb -ex run --readnever --args  ./odu/odu
 
-> Note: If you see the following prompt in GDB
+Note: If you see the following prompt in GDB
 
     This GDB supports auto-downloading debuginfo from the following URLs:
       <https://debuginfod.ubuntu.com>
@@ -232,11 +231,11 @@ Run the OAI-UE
 
     sudo ./nr-uesoftmodem -r 273 --numerology 1 --band 78 -C 3400140000 --ssb 1518 --uicc0.imsi 001010000000001 --rfsim
 
-## nFAPI logging system
+# nFAPI logging system
 
 nFAPI has its own logging system, independent of OAI's. It can be activated by
 setting the `NFAPI_TRACE_LEVEL` environment variable to an appropriate value;
-see [the environment variables documentation](../setup/environment-variables.md) for
+see [the environment variables documentation](./environment-variables.md) for
 more info.
 
 To see the (any) periodical output at the PNF, define `NFAPI_TRACE_LEVEL=info`.

doc/nr-ue-design.md

@@ -1,4 +1,4 @@
-## PHY and MAC Interface
+# PHY and MAC Interface
 The PHY sends scheduling requests and data indication to MAC via `nr_ue_dl_indication` for DL path and `nr_ue_ul_indication()` for UL path and the MAC sends scheduling configuration to PHY via `nr_ue_scheduled_response()`. The following diagram shows the interaction for PDCCH and PDSCH reception.
 ```mermaid
 sequenceDiagram
@@ -8,16 +8,16 @@ sequenceDiagram
     MAC->>+PHY: Schedules PDSCH reception (via nr_ue_scheduled_response)
 ```
 
-## Multi-threading Design
+# Multi-threading Design
 The `UE_thread` function in `nr-ue.c` is the main top level thread that interacts with the radio unit. Once the thread spawns, it starts the 'Initial Synchronization'. Once its complete, the regular processing of slots commences.
 
 The UE exits when at any point in operation it gets out of synchronization. When the command line option `--non-stop` is used, the UE goes to 'Initial Synchronization' mode when it loses synchronization with gNB. However, this feature is not fully implemented and it is a work in progress at the time of writing this documentation. This will be the default behavior (not a command line option) when the feature is fully implemented.
 
 UE uses actors which are threads dedicated to particular activity. Sync Actor handles initial sync. DL Actors handle DLSCH PHY procedures. UL procedures are are run on the UL Actor
 
-![design](../images/nr-ue-threads.svg)
+![design](nr-ue-threads.svg)
 
-### Initial Synchronization Block
+## Initial Synchronization Block
 ```mermaid
 graph TD
     start(Start) -->|UE_thread| rxRu["RU read<br/>(Reads two frames)"]
@@ -26,7 +26,7 @@ graph TD
     sync --> |UE_thread| frameSync["Frame synchronization<br/>(Shift received samples to align with frame)"]
     rxRuDummy --> |UE_thread| frameSync
 ```
-#### Regular Slot Processing
+## Regular Slot Processing
 ```mermaid
 graph TD
     sync["Frame synchronization<br/>(Shift received samples to align with frame)"] -->|UE_thread| hw_read["RU read (slot n)"]

doc/physical-simulators.md

@@ -5,7 +5,7 @@ simulators** or simply **physims**, used in the OpenAirInterface (OAI) project f
 
 [[_TOC_]]
 
-## Introduction
+# Introduction
 
 **Unitary simulations** are standalone test programs designed to validate individual physical layer (L1) transport or
 control channels. These simulations are based on **Monte Carlo techniques**, enabling statistical evaluation of
@@ -25,7 +25,7 @@ pipelines:
 - [RAN-PhySim-Cluster-5G](https://jenkins-oai.eurecom.fr/job/RAN-PhySim-Cluster-5G/)
 - [RAN-PhySim-GraceHopper-5G](https://jenkins-oai.eurecom.fr/job/RAN-PhySim-GraceHopper-5G/)
 
-### Examples of Simulators
+## Examples of Simulators
 
 | Technology | Simulators                                | Description                      |
 |------------|-------------------------------------------|----------------------------------|
@@ -38,7 +38,7 @@ pipelines:
 |            | `nr_psbchsim`                             | Sidelink simulation              |
 | Coding     | `ldpctest`, `polartest`, `smallblocktest` | LDPC, Polar, and other FEC tests |
 
-### Source Locations
+## Source Locations
 
 * 4G PHY simulators: `openair1/SIMULATION/LTE_PHY/`
 * 5G PHY simulators: `openair1/SIMULATION/NR_PHY/`
@@ -51,9 +51,9 @@ Example:
 openair1/SIMULATION/NR_PHY/dlsim.c
 ```
 
-## How to Run Simulators Using `ctest`
+# How to Run Simulators Using `ctest`
 
-### Option 1: Using CMake
+## Option 1: Using CMake
 
 Build the simulators and tests using the dedicated cmake option, then run
 `ctest` which will run all registered tests.
@@ -66,7 +66,7 @@ ninja tests
 ctest
 ```
 
-### Option 2: Using the `build_oai` script
+## Option 2: Using the `build_oai` script
 
 This method simplifies the process by automatically building the simulators with ctest support.
 
@@ -77,7 +77,7 @@ cd ran_build/build
 ctest
 ```
 
-### `ctest` Usage Tips
+## `ctest` Usage Tips
 
 Use the following options to customize test execution:
 
@@ -99,7 +99,7 @@ parallel, type
 
     ctest -L nr_ulschsim -j 4
 
-## Adding a New Physim Test
+# Adding a New Physim Test
 
 To define a new test or modify existing ones, update the following file:
 
@@ -107,7 +107,7 @@ To define a new test or modify existing ones, update the following file:
 openair1/SIMULATION/tests/CMakeLists.txt
 ```
 
-### `add_physim_test()`
+## `add_physim_test()`
 
 Use the `add_physim_test()` macro with the following arguments:
 
@@ -125,7 +125,7 @@ For instance, a PRACHsim looks like this:
 
     add_physim_test(physim.5g.nr_prachsim.test8 "15kHz SCS, 25 PRBs" nr_prachsim -a -s -30 -n 300 -p 99 -R 25 -m 0)
 
-### `add_timed_physim_test()`
+## `add_timed_physim_test()`
 
 Use the `add_timed_physim_test()` macro to add a test the same way as with
 `add_physim_test()` above. Additionally, it allows to check for thresholds with
@@ -162,7 +162,7 @@ For instance, this could look like this:
     add_timed_physim_test(physim.5g.nr_dlsim.test3 "Some description" nr_dlsim -P)
     check_physim_threshold(physim.5g.nr_dlsim.test3 "DLSCH encoding time" "< 50")
 
-## How to rerun failed CI tests using `ctest`
+# How to rerun failed CI tests using `ctest`
 
 Ctest automatically logs the failed tests in LastTestsFailed.log. This log is archived in
 the CI artifacts and can be reused locally to rerun only those failed tests.
@@ -185,7 +185,7 @@ cp /path/to/test_logs_123/test_logs/LastTestsFailed.log ./Testing/Temporary/
 ctest --rerun-failed
 ```
 
-## Legacy Bash Autotest (Deprecated)
+# Legacy Bash Autotest (Deprecated)
 
 > **Note:** Autotest script, configuration, and documentation, are no longer maintained.
 
@@ -195,7 +195,7 @@ For legacy support or archival purposes, you can still find this implementation
 git checkout 2025.w18
 ```
 
-## Unmaintained tests
+# Unmaintained tests
 
 A few tests dedicated to 4G are unmaintained:
 

doc/system_requirements.md

@@ -1,5 +1,16 @@
-
-# System Requirements for Using OAI Stack
+<table style="border-collapse: collapse; border: none;">
+  <tr style="border-collapse: collapse; border: none;">
+    <td style="border-collapse: collapse; border: none;">
+      <a href="http://www.openairinterface.org/">
+         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         </img>
+      </a>
+    </td>
+    <td style="border-collapse: collapse; border: none; vertical-align: center;">
+      <b><font size = "5">System Requirements for Using OAI Stack</font></b>
+    </td>
+  </tr>
+</table>
 
 This document describes the minimal and performant system requirements for OpenAirInterface (OAI) 4G/5G software stack (UE and gNB stack). The information provided in this document is based on experimentation, if you have a feedback then open an issue or send an email on the mailing list. 
 
@@ -7,7 +18,7 @@ This document describes the minimal and performant system requirements for OpenA
 
 [[_TOC_]]
 
-## Supported CPU Architecture
+# Supported CPU Architecture
 
 |Architecture                               |
 |------------------------------------------ |
@@ -18,7 +29,7 @@ This document describes the minimal and performant system requirements for OpenA
 
 - On `x86_64` platform the CPU should support `avx2` instruction set (Minimum requirement).
 
-## Supported Operating System
+# Supported Operating System
 
 |Operating System |
 |-----------------|
@@ -29,17 +40,17 @@ This document describes the minimal and performant system requirements for OpenA
 |Rocky 9          |
 
 
-## Minimum Hardware Requirement for x86_64 Platforms
+# Minimum Hardware Requirement for x86_64 Platforms
 
 The minimum hardware requirements depends on the radio unit you would like to use or the test case that you would like to execute.  
 
-### Simulated Radio
+## Simulated Radio 
 
 OAI offers an inbuilt simulated radio, [RFSimulator](../radio/rfsimulator/README.md). It can be used to familiarize oneself with OAI, for development and debugging, and offers the possibility to use basic channel models. It is not designed to do high performance testing. The below requirements are valid for both 4G and 5G RAN and UE Stack. 
 
 The following requirements are minimum requirements for all use cases:
 
-#### Minimum requirements for gNB Stack
+### Minimum requirements for gNB Stack
 
 - CPU: 2
 - Minimum frequency > 2GHz
@@ -50,7 +61,7 @@ The following requirements are minimum requirements for all use cases:
 **NOTE**: We have not tested on Intel Atom or Celeron processors, and they
 likely won't work well.
 
-#### Minimum requirements for UE Stack
+### Minimum requirements for UE Stack
 
 - CPU: 2
 - Minimum frequency > 2GHz
@@ -59,13 +70,13 @@ likely won't work well.
 
 **NOTE**: We have not tested on Intel Atom or Celeron processors 
 
-### USRP B2XX or Blade RF
+## USRP B2XX or Blade RF
 
 USRP B2XX or Blade RF are USB based radios recommended to use with USB 3.0. You can choose a minimum hardware to do functional testing and performance hardware for performance testing. This hardware you can find in Mini-PCs or laptops.
 
-The minimum requirements stated in [simulated radio](#simulated-radio) apply.
+The minimum requirements stated in [simulated radio](.##simulated-radio) apply.
 
-#### Minimum requirements for both gNB and UE Stack
+### Minimum requirements for both gNB and UE Stack
 
 - CPU: 3
 - Memory: 5Gi
@@ -73,7 +84,7 @@ The minimum requirements stated in [simulated radio](#simulated-radio) apply.
 - USB 3.0
 - Intel i5, AMD Ryzen 5
 
-#### Recommended for performance for gNB and UE Stack
+### Recommended for performance for gNB and UE Stack
 
 - CPU: 4
 - Boost Frequency > 3GHz 
@@ -83,19 +94,21 @@ The minimum requirements stated in [simulated radio](#simulated-radio) apply.
 - DDR4 or DDR5 RAM, minimum 5Gi
 - USB 3.0
 
-Apart from this you should follow [tuning and security tips](tuning/tuning_and_security.md) to tune your system to get high performance.
+Apart from this you should follow [tuning and security tips](./tuning_and_security.md) to 
+tune your system to get high performance. 
 
-### USRP N3XX/X3XX/X4XX/AW2S
+## USRP N3XX/X3XX/X4XX/AW2S
 
 USRP N3XX/X3XX/X4XX requires two dedicated 10G SFP+ connections. For these radios we only recommend having performance hardware. This hardware you can find in Desktop servers or rack/blade servers. For the gNB, the same applies in case of using AW2S radios.
 
-The minimum requirements stated in [simulated radio](#simulated-radio) apply.
+The minimum requirements stated in [simulated radio](.##simulated-radio) apply.
 
-Apart from this you should follow [tuning and security tips](tuning/tuning_and_security.md) to tune your system to get high performance.
+Apart from this you should follow [tuning and security tips](./tuning_and_security.md) to 
+tune your system to get high performance. 
 
 **NOTE**: In case you are using Mellanox NIC cards then you have to download `mlnx-ofed` and configure your NIC for performance. 
 
-#### Recommended for performance for gNB Stack
+### Recommended for performance for gNB Stack
 
 - CPU: 8-10
 - Boost Frequency > 4GHz
@@ -105,7 +118,7 @@ Apart from this you should follow [tuning and security tips](tuning/tuning_and_s
 - (Optional) Realtime kernel to have better Jitter statistics
 - Intel x710/xx710/E-810 or Mellanox connect 5x or 6x
 
-#### Recommended for performance for UE Stack
+### Recommended for performance for UE Stack
 
 - CPU: 4
 - Boost Frequency > 4GHz 
@@ -115,8 +128,8 @@ Apart from this you should follow [tuning and security tips](tuning/tuning_and_s
 - (Optional) Realtime kernel to have better Jitter statistics
 - Intel x710/xx710/E-810 or Mellanox connect 5x or 6x
 
-### O-RAN Radio Units
+## O-RAN Radio Units
 
-We have dedicated documentation for O-RAN Radio Units. [Refer to 7.2 FH documentation](tutorials/ORAN_FHI7.2_Tutorial.md) before purchasing a Desktop server or rack/blade server.
+We have dedicated documentation for O-RAN Radio Units. [Refer to 7.2 FH documentation](./ORAN_FHI7.2_Tutorial.md) before purchasing a Desktop server or rack/blade server. 
 
-The minimum requirements stated in [simulated radio](#simulated-radio) apply.
+The minimum requirements stated in [simulated radio](.##simulated-radio) apply.

doc/time_management.md

@@ -96,8 +96,8 @@ time_management = {
 ```
 ### RF simulator CU/DU "IQ samples time"
 
-Let's suppose the CU runs on a machine with IP address `1.2.3.4` and the DU
-runs on a machine with IP address `10.11.12.13`.
+Let's suppose the CU runs on a machine with IP address 1.2.3.4 and the DU
+runs on a machine with IP address 10.11.12.13.
 
 The DU has the time source and so is the server. The CU acts as a client.
 
@@ -153,11 +153,11 @@ time_management = {
 }
 ```
 
-> **Note** that the time management module is flexible. It's possible to
+Note that the time management module is flexible. It's possible to
 configure more complex setups. For example the time source can be a gNB
 and several UEs can be connected as client.
 
-> One could also write a simple program acting as a time source and distributing
+One could also write a simple program acting as a time source and distributing
 time to everyone (one or several gNB, several UEs).
 
 ## Programming API

doc/tuning_and_security.md

@@ -6,13 +6,13 @@ without sudo.
 
 [TOC]
 
-## Performance Tuning
+# Performance Tuning
 
 Please also refer to the [advanced configuration in the
 tutorial](NR_SA_Tutorial_COTS_UE.md#6-advanced-configurations-optional), which
 groups many tips and tricks.
 
-### CPU
+## CPU
 
 OAI used to try to set the minimum CPU-DMA latency to 2 us by writing to
 `/dev/cpu_dma_latency`. However, it is unclear if this has a significant
@@ -46,7 +46,7 @@ You can disable KPTI Protections for Spectre/Meltdown for more performance.
 **This is a security risk.** Add `mitigations=off nosmt` in your grub config and
 update grub.
 
-### Ethernet-based Radios
+## Ethernet-based Radios
 
 For ethernet-based radios, such as AW2S, some USRPs, and 7.2 radios, increase
 the ringbuffers to a maximum. Read on interface `<fronthaul-interface-name>`
@@ -67,7 +67,7 @@ sudo sysctl -n -e -q -w net.core.wmem_default=134217728
 sudo sysctl -n -e -q -w net.core.wmem_max=134217728
 ```
 
-## Capabilities
+# Capabilities
 
 Historically, all softmodems are executed as `root`, typically using `sudo`.
 This remains a possibility, but we do not recommend it due to security
@@ -75,7 +75,7 @@ considerations. Rather, consider giving specific capabilities as outlined
 below. Read `capabilities(7)` (`man 7 capabilities`) for more information on
 each of the below capabilities.
 
-> **Note** that we tested this using 5G executables; 4G should work, but have not
+Note that we tested this using 5G executables; 4G should work, but have not
 been tested as extensively. If in doubt, run eNB/lteUE using `sudo`. The below
 comments on capabilities apply in general as well; however, 4G executable might
 not warn about missing capabilities or just fail.
@@ -111,7 +111,7 @@ cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore" --p
 `\`). To run with `SYS_NICE`, remove the first capability (`cap_sys_nice`)
 from the list of dropped capabilities.
 
-### General capabilities
+## General capabilities
 
 - `SYS_NICE`: required by all softmodems to assign a higher priority to
   threads to increase the likelihood that the Linux scheduler schedules a
@@ -137,7 +137,7 @@ from the list of dropped capabilities.
   run without this capability, but you cannot inject any traffic into the
   system. 4G executables might need this requirement, and possibly fail.
 
-### Capabilities with DPDK
+## Capabilities with DPDK
 
 Additionally to the "general capabilities" above, you need these capabilities
 when running with 7.2 fronthaul, which uses the xran library with a dependency
@@ -150,19 +150,19 @@ on DPDK:
    mode to read `/proc/self/pagemaps`. However, if DPDK EAL is configured to use
    IOVA VA (Virtual Address) mode, this capability is no longer required.
 
-### Capabilities with UHD
+## Capabilities with UHD
 
 You don't need any additional capabilities for UHD beyond the "general
 capabilities" for performance outlined above. Make sure that the USB device(s)
 are readable and writable by the current user (e.g., `uhd_usrp_probe` can be
 executed by a non-root user).
 
-### Capabilities with AW2S
+## Capabilities with AW2S
 
 You don't need any additional capabilities for AW2S beyond the "general
 capabilities" for performance outlined above.
 
-### Other radios
+## Other radios
 
 Other radios have not been tested. If they do not work without additional
 capabilities beyond the "general capabilities", please file a bug report.

docker/Dockerfile.gNB.aerial.ubuntu

@@ -48,7 +48,7 @@ RUN /bin/sh oaienv && \
     tar -xvzf nvipc_src.*.tar.gz  && \
     cd nvipc_src.* && \
     rm -rf build && mkdir build && cd build && \
-    cmake .. -DNVIPC_DPDK_ENABLE=OFF -DNVIPC_DOCA_ENABLE=OFF -DNVIPC_CUDA_ENABLE=OFF -DENABLE_SLT_RSP=ON && \
+    cmake .. -DNVIPC_DPDK_ENABLE=OFF -DNVIPC_DOCA_ENABLE=OFF -DNVIPC_CUDA_ENABLE=OFF -DENABLE_SLT_RSP=ON  -DSCF_FAPI_10_04_SRS=ON && \
     make -j && make install
 
 RUN /bin/sh oaienv && \