docs: Standardize documentation headings (remove multiple # H1)

- Remove multiple single top-level (# H1) headings per file - Use (# H2 and ###### H6) sub-headings for consistency - Remove any trailing # in the headings - This ensures proper table of contents rendering in MkDocs. - Also removed RUN_NR_multiple_BWPs.md as it is moved to MAC usage
2026-07-17 14:40:31 +00:00 · 2026-01-21 08:33:25 +01:00
parent a9ba6290b9
commit 5c480ffd50
36 changed files with 489 additions and 482 deletions
--- a/doc/5Gnas.md
+++ b/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,7 +33,7 @@ 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):
 * NAS procedures and message handlers/callbacks
@@ -66,11 +66,11 @@ The following tables lists implemented NAS messages and whether there is an enco

 * 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.

@@ -91,11 +91,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:

@@ -104,11 +104,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.

--- a/doc/Aerial_FAPI_Split_Tutorial.md
+++ b/doc/Aerial_FAPI_Split_Tutorial.md
@@ -16,7 +16,7 @@

 [[_TOC_]]

-# Prerequisites
+## Prerequisites

 The hardware on which we have tried this tutorial:

@@ -61,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).

@@ -71,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  |
 |------------------|---------------|:---------------:|:--------------:|
@@ -84,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-16          |

-## PTP configuration
+### PTP configuration

 1. You need to install the `linuxptp` debian package. It will install both ptp4l and phc2sys.

@@ -144,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
@@ -152,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`.
@@ -210,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
@@ -220,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/`.
@@ -239,7 +239,7 @@ cubb-build                                    25-2.1
 -..
 ```

-## 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:

@@ -253,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`.

@@ -275,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.
@@ -286,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
--- a/doc/BUILD.md
+++ b/doc/BUILD.md
@@ -16,7 +16,7 @@

 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.

@@ -49,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:

@@ -66,7 +66,7 @@ Calling the `build_oai` script with the `-h` option gives the list of all availa

 `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:

@@ -77,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
@@ -107,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.

@@ -139,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:

@@ -152,7 +152,7 @@ After completing the build, the binaries are available in the `cmake_targets/ran

 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):

@@ -165,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.
@@ -187,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:
 ```
@@ -217,7 +217,7 @@ 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).

@@ -241,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](./cross-compile.md) for more information.

--- a/doc/E1AP/e1ap_procedures.md
+++ b/doc/E1AP/e1ap_procedures.md
@@ -14,7 +14,7 @@

 [[_TOC_]]

-# Introduction
+## Introduction
 The E1 interface is between the gNB-CU-CP (Central Unit - Control Plane) and gNB-CU-UP (Central Unit - User Plane) nodes. This interface is governed by the E1 Application Protocol (E1AP) outlined in the 3GPP release 16 specifications, specifically in the documents:

 * 3GPP TS 38.463 - E1 Application Protocol (E1AP)
@@ -28,7 +28,7 @@ The E1AP protocol consists of the following sets of functions:
 * E1 Bearer Context Management functions
 * TEID allocation function

-## E1 Bearer Context Management function
+### E1 Bearer Context Management function
 This function handles the establishment, modification, and release of E1 bearer contexts.

 * E1 Bearer Context Establishment: initiation of E1 bearer context is by gNB-CU-CP and acceptance or rejection is determined by gNB-CU-UP based on admission control criteria (e.g., resource availability).
@@ -36,11 +36,11 @@ This function handles the establishment, modification, and release of E1 bearer
 * Release of Bearer Context: can be triggered either directly by gNB-CU-CP or following a request from gNB-CU-UP.
 * QoS-Flow to DRB Mapping Configuration: responsible for setting up and modifying the QoS-flow to DRB mapping configuration. gNB-CU-CP decides the flow-to-DRB mapping, generates SDAP and PDCP configurations, and provides them to gNB-CU-UP.

-# OAI implementation
+## OAI implementation

 For the E1AP design in OAI, please refer to the [E1 Design](./E1-design.md) document.

-## E1 re-establishment
+### E1 re-establishment

 The purpose of this procedure is to follow-up the re-establishment of RRC connection over the E1 interface. For all activated DRBs a Bearer Context Modification from CU-CP to CU-UP is necessary, according to clause 9.2.2.4 of 3GPP TS 38.463. If any modification to the bearer context is required, the CU-CP informs the CU-UP with the relevant IEs (e.g. in case of PDCP re-establishment, PDCP Configuration IE clause 9.3.1.38), Current implementation in OAI:

--- a/doc/F1AP/F1AP-lib.md
+++ b/doc/F1AP/F1AP-lib.md
@@ -15,11 +15,11 @@
 [[_TOC_]]


-# Intro
+## Intro

 This library is for the encoding, decoding and testing of F1AP (F1 Application Protocol) messages.

-# Implementation Details
+## Implementation Details

 The library includes the following components:

@@ -40,7 +40,7 @@ e.g. The following module contains functions that performs the encoding/decoding

 * [f1ap_rrc_message_transfer.c](../../openair2/F1AP/lib/f1ap_rrc_message_transfer.c)

-# Testing
+## Testing

 The functions in the file [f1ap_lib_common.c](../../openair2/F1AP/tests/f1ap_lib_test.c) are used to test F1AP message encoding and decoding functionalities, according to the following steps:

--- a/doc/FEATURE_SET.md
+++ b/doc/FEATURE_SET.md
@@ -2,7 +2,7 @@

 [[_TOC_]]

-# Functional Split Architecture #
+## Functional Split Architecture

 -  RCC: Radio-Cloud Center
 -  RAU: Radio-Access Unit
@@ -14,13 +14,13 @@
 ![Functional Split Architecture](./images/oai_enb_func_split_arch.png)


-# OpenAirInterface Block Diagram #
+## OpenAirInterface Block Diagram

 ![Block Diagram](./images/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.

@@ -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 DL_TTI.request,
@@ -157,7 +157,7 @@ These modes of operation are supported:
  - Consider ntn-Config-r17.cellSpecificKoffset-r17 in scheduling
  - Function-based interface for ntn-Config-r17 updates (used by NTN-LEO RFsimulator)

-## gNB RLC
+### gNB RLC

 - Send/Receive operations according to 38.322 Rel.16
  - Segmentation and reassembly procedures
@@ -168,7 +168,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
@@ -177,7 +177,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.
@@ -186,7 +186,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
@@ -213,13 +213,13 @@ These modes of operation are supported:
  - Support for handover decision triggers (A3 events, manual triggers)
 - Initial support for RedCap (see MAC)

-## 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
@@ -241,7 +241,7 @@ These modes of operation are supported:
    * NGAP Downlink RAN Status Transfer
 - 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:
@@ -265,7 +265,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)
@@ -282,21 +282,21 @@ These modes of operation are supported:
 - Interface with RRC and PDCP/SDAP
 - 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)
@@ -361,15 +361,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
@@ -418,7 +418,7 @@ These modes of operation are supported:
   - Consider ntn-Config-r17.cellSpecificKoffset-r17 in scheduling


-## UE RLC
+### UE RLC

 * Tx/Rx operations according to 38.322 Rel.16
   - Segmentation and reassembly procedures
@@ -428,7 +428,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
@@ -436,7 +436,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.
@@ -444,7 +444,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
@@ -462,7 +462,7 @@ These modes of operation are supported:
 * Interface with PDCP: configuration, DCCH and CCCH message handling
 * Interface with RLC and MAC for configuration

-## UE 5G NAS
+### UE 5G 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
 * 5GMM (5G Mobility Management) messages:
@@ -484,9 +484,9 @@ These modes of operation are supported:

 For detailed implementation status, encoding/decoding support, and unit test coverage, see [5G NAS Implementation Documentation](5Gnas.md).

-# 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:

@@ -504,7 +504,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**
 -------------------------------- | ----------------------- | ------------------------| ----------------:
@@ -524,13 +524,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.

@@ -548,7 +548,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.

@@ -568,7 +568,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:

@@ -578,7 +578,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:

@@ -594,7 +594,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:

@@ -612,7 +612,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
@@ -623,7 +623,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
@@ -633,9 +633,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:

@@ -652,7 +652,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.

@@ -665,15 +665,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:

@@ -681,7 +681,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:

--- a/doc/GET_SOURCES.md
+++ b/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
@@ -37,7 +37,7 @@ git config --global user.email "Your email address"

 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
--- a/doc/L1SIM.md
+++ b/doc/L1SIM.md
@@ -25,14 +25,14 @@ multiple UEs.

 [[_TOC_]]

-# Build
+## Build

 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.

@@ -48,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.

@@ -64,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:

--- a/doc/L2NFAPI_NOS1.md
+++ b/doc/L2NFAPI_NOS1.md
@@ -20,7 +20,7 @@

 [[_TOC_]]

-# 1. Environment #
+## 1. Environment 

 You may not have access to an EPC or you don't want to hassle to deploy one.

@@ -35,7 +35,7 @@ Example of L2 nFAPI Simulator testing 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`.

@@ -57,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
@@ -113,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.**

-## 4.1. The eNB Configuration file ##
+### 4.1. The eNB Configuration file 

 ```bash
 $ ssh sudousername@machineB
@@ -179,7 +179,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
@@ -204,11 +204,11 @@ L1s = (
 );
 ```

-# 5. Build OAI UE and eNodeB #
+## 5. Build OAI UE and eNodeB 

 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):

@@ -230,7 +230,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):

@@ -280,7 +280,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

@@ -320,7 +320,7 @@ $ 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 


 ----
--- a/doc/L2NFAPI_S1.md
+++ b/doc/L2NFAPI_S1.md
@@ -20,7 +20,7 @@

 [[_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.

@@ -34,13 +34,13 @@ Example of L2 nFAPI Simulator testing 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`.

@@ -62,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
@@ -118,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.**

-## 5.1. The eNB Configuration file ##
+### 5.1. The eNB Configuration file 

 ```bash
 $ ssh sudousername@machineB
@@ -184,7 +184,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
@@ -209,11 +209,11 @@ L1s = (
 );
 ```

-# 6. Build OAI UE and eNodeB #
+## 6. Build OAI UE and eNodeB 

 See [Build documentation](./BUILD.md).

-# 7. Start EPC #
+## 7. Start EPC 

 Start the EPC on machine `A`.

@@ -222,7 +222,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):

@@ -236,7 +236,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):

@@ -286,7 +286,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

@@ -300,7 +300,7 @@ $ ping -c 20 192.172.0.5

 iperf operations can also be performed.

-# 11. Limitations #
+## 11. Limitations 


 ----
--- a/doc/LDPC_OFFLOAD_SETUP.md
+++ b/doc/LDPC_OFFLOAD_SETUP.md
@@ -19,40 +19,40 @@
 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).

-# 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. 
@@ -89,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.
@@ -101,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:
@@ -117,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.
 ```
@@ -134,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). 
@@ -142,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.

 ```
@@ -164,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.
@@ -190,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:
@@ -218,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
@@ -254,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
@@ -270,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
@@ -280,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.
@@ -296,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,
--- a/doc/MAC/mac-usage.md
+++ b/doc/MAC/mac-usage.md
@@ -4,7 +4,7 @@ out the various configuration options that influence its behavior.

 [[_TOC_]]

-# General
+## General

 The 5G MAC scheduler is a proportional fair (PF) scheduler, "approximating
 wide-band CQI" (for lack of a better term, but CQI is typically used for PF)
@@ -67,7 +67,7 @@ happen.
 Say we have 0% PDCCH success rate (radio link failure scenario) but `pdcch_cl_adjust` is 0 indicating
 perfect PDCCH channel. it would take ~18 PDCCH failures to reach maximum aggregation level.

-# Periodic output and interpretation
+## Periodic output and interpretation

 The scheduler periodically outputs statistics that can help you judge the radio
 channel quality, i.e., why a UE does not perform as you would expect. The
@@ -179,9 +179,9 @@ In the last lines:
  and 2. LCIDs 4 and onward are mapped to DRBs 1 onward. If you have an LCID 4,
  it means you have a PDU session.

-# Configuration of the MAC
+## Configuration of the MAC

-## Split-related options (running in a DU)
+### Split-related options (running in a DU)

 See [nFAPI documentation](../nfapi.md) or [Aerial
 tutorial](../Aerial_FAPI_Split_Tutorial.md) for information about the (n)FAPI
@@ -189,7 +189,7 @@ split.

 See [F1 documentation](../F1AP/F1-design.md) for information about the F1 split.

-## MAC scheduler-related configuration options
+### MAC scheduler-related configuration options

 The following options have an influence on the MAC scheduler operation (for all
 UEs, if applicable), either on the MAC scheduler operation directly or how a UE
@@ -301,7 +301,7 @@ DL-MIMO is configured using following parameters:
 `pdsch_AntennaPorts_XP` , `pdsch_AntennaPorts_N1` , `pdsch_AntennaPorts_N2`, `maxMIMO_layers`
 (see also [`RUNMODEM.md`](../RUNMODEM.md))

-## ServingCellConfigCommon parameters
+### ServingCellConfigCommon parameters

 The `gNBs` configuration section has a big structure `servingCellConfigCommon`
 that has an influence on the overall behavior of MAC and L1. As the name says,
@@ -312,17 +312,17 @@ TS 38.331, section 6.3.2 "Radio resource control information elements".

 Below is a description of some of these parameters.

-### Frequency configuration
+#### Frequency configuration

 There are many parameters, such as `absoluteFrequencySSB`, etc., that have an
 impact on the frequency used by the gNB. For more information, please check the
 [corresponding document](../gNB_frequency_setup.md).

-### TDD pattern configuration
+#### TDD pattern configuration

 The TDD configuration parameters allow to use one or two TDD patterns.

-#### Single TDD pattern
+##### Single TDD pattern

 Configure the TDD pattern through these options:

@@ -363,7 +363,7 @@ The `dl_UL_TransmissionPeriodicity` is set to `5` (2.5ms). The above figure
 shows two TDD periods over 5ms. The 10 ms frame period must be strictly
 divisible by the sum of the TDD pattern periods.

-#### Two TDD patterns
+##### Two TDD patterns

 An optional `pattern2` structure is used to signal a TDD pattern 2.
 In this case, the TDD pattern may have two extended values of 3 ms and 4 ms.
@@ -414,7 +414,7 @@ pattern2: {
 };
 ```

-#### UL-heavy TDD patterns
+##### UL-heavy TDD patterns

 "UL-heavy TDD patterns", i.e., TDD patterns that have many UL slots are
 supported. Examples for such patterns would be DSUUU or DDDSUUUUUU.
--- a/doc/NR_NFAPI_archi.md
+++ b/doc/NR_NFAPI_archi.md
@@ -8,7 +8,7 @@ To read more about the transport mechanisms available, and how to run the split,

 [[_TOC_]]

-# VNF/PNF Split
+## VNF/PNF Split

 The gNB is split into VNF (L2+) and PNF (L1)

--- a/doc/NR_SA_Tutorial_COTS_UE.md
+++ b/doc/NR_SA_Tutorial_COTS_UE.md
@@ -16,7 +16,7 @@

 [[_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:
@@ -44,15 +44,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
@@ -60,11 +60,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
@@ -83,7 +83,7 @@ sudo ldconfig
 sudo uhd_images_downloader
 ```

-## 3.2 Build OAI gNB
+### 3.2 Build OAI gNB

 ```bash
 # Get openairinterface5g source code
@@ -100,42 +100,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!
@@ -149,7 +149,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
@@ -159,7 +159,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:
@@ -173,11 +173,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](./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.

@@ -199,12 +199,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.

@@ -224,7 +224,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.
@@ -235,9 +235,9 @@ A visual representation of the impact of tune-offset with a 120 MHz bandwidth da

 ![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` .
--- a/doc/NR_SA_Tutorial_OAI_CN5G.md
+++ b/doc/NR_SA_Tutorial_OAI_CN5G.md
@@ -16,7 +16,7 @@

 [[_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:
@@ -27,9 +27,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
@@ -49,7 +49,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
@@ -58,31 +58,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)
--- a/doc/NR_SA_Tutorial_OAI_multi_UE.md
+++ b/doc/NR_SA_Tutorial_OAI_multi_UE.md
@@ -16,10 +16,10 @@

 [[_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).

@@ -29,9 +29,9 @@ Also, it is suggested to get some knowledge on how the channel simulation with O
 - 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:

@@ -69,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:

@@ -110,7 +110,7 @@ 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:

--- a/doc/NR_SA_Tutorial_OAI_nrUE.md
+++ b/doc/NR_SA_Tutorial_OAI_nrUE.md
@@ -16,7 +16,7 @@

 [[_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:
@@ -38,19 +38,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
@@ -69,7 +69,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
@@ -89,59 +89,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
@@ -152,7 +152,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
@@ -163,7 +163,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
@@ -174,7 +174,7 @@ 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.

@@ -213,15 +213,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.

@@ -243,20 +243,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.  


-## 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` .
--- a/doc/ORAN_FHI7.2_Tutorial.md
+++ b/doc/ORAN_FHI7.2_Tutorial.md
@@ -16,7 +16,7 @@

 [[_TOC_]]

-# Prerequisites
+## Prerequisites

 The hardware on which we have tried this tutorial:

@@ -87,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.**

@@ -137,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,

@@ -153,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,

@@ -170,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:

@@ -187,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.
@@ -265,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>`
@@ -283,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.

@@ -296,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
@@ -311,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:

@@ -365,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

@@ -374,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,

@@ -383,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
@@ -395,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
@@ -426,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.
@@ -451,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
@@ -520,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
@@ -541,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`

@@ -559,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
@@ -567,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`

@@ -585,7 +585,7 @@ 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:
 - TDD pattern `DDDSU`, 2.5ms
@@ -593,7 +593,7 @@ The OAI configuration file [`gnb.sa.band78.273prb.fhi72.4x4-liteon.conf`](../tar
 - 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
@@ -623,7 +623,7 @@ jumboframe 1 # enable jumbo frame
 ...
 ```

-### VVDN LPRU
+#### VVDN LPRU

 **Version 3.x**

@@ -632,7 +632,7 @@ The OAI configuration file [`gnb.sa.band77.273prb.fhi72.4x4-vvdn.conf`](../targe
 - 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. 

@@ -676,7 +676,7 @@ 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**

@@ -697,7 +697,7 @@ 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**

@@ -706,7 +706,7 @@ The OAI configuration file [`gnb.sa.band78.273prb.fhi72.4X4-foxconn.conf`](../ta
 - 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.

@@ -731,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
@@ -767,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
@@ -782,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>
@@ -791,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
@@ -808,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
@@ -866,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
@@ -883,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
@@ -933,7 +933,7 @@ 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`)**

@@ -1026,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
@@ -1114,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
@@ -1239,7 +1239,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:
@@ -1251,10 +1251,10 @@ The reference specifications:
 * `O-RAN.WG4.MP.0-R004-v16.01`
 * `O-RAN.WG4.MP-YANGs-R004-v16.01`

-## 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.

@@ -1301,7 +1301,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
@@ -1373,7 +1373,7 @@ If you would like to install these libraries in the custom path, please replace
 ## Benetel O-RU
 Note: RAN550/650 v1.2.2 and v1.4.1 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>
@@ -1398,7 +1398,7 @@ 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)
 The reference DU configuration file for two Benetel RAN650:
@@ -1481,7 +1481,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
@@ -1490,7 +1490,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/
@@ -1501,7 +1501,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/
@@ -1512,7 +1512,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
@@ -3096,7 +3096,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).

--- a/doc/README.md
+++ b/doc/README.md
@@ -23,7 +23,7 @@ Beware if you previously pulled the `develop` branch that your repository may be

 [[_TOC_]]

-# General
+## General

 - [FEATURE_SET.md](./FEATURE_SET.md): lists supported features
 - [GET_SOURCES.md](./GET_SOURCES.md): how to download the sources
@@ -37,7 +37,7 @@ Beware if you previously pulled the `develop` branch that your repository may be

 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](./NR_SA_Tutorial_OAI_CN5G.md)
@@ -74,7 +74,7 @@ Legacy unmaintained files:
 - [`L2NFAPI_NOS1.md`](./L2NFAPI_NOS1.md), [`L2NFAPI_S1.md`](./L2NFAPI_S1.md):
  old L2simulator, not valid anymore

-# Designs
+## Designs

 - General software architecture notes: [SW_archi.md](./SW_archi.md)
 - [Information on E1](./E1AP/E1-design.md)
@@ -88,16 +88,16 @@ Legacy unmaintained files:
 - [Information on the UE 5G NAS implementation](./5Gnas.md)
 - [Information on UL-MIMO](./UL_MIMO.md): UL-MIMO specific notes

-# 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
@@ -108,7 +108,7 @@ Legacy unmaintained files:
 - The [LDPC implementation](../openair1/PHY/CODING/DOC/LDPCImplementation.md) is a shared library
 - The [time management](time_management.md) module

-## Radios
+### Radios

 Some directories under `radio` contain READMEs:

@@ -122,13 +122,13 @@ 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](./UnitTests.md) explains the unit testing setup
 - Component tests are under `tests/`. Currently, there is a simple CU-UP
@@ -137,7 +137,7 @@ The other SDRs (AW2S, LimeSDR, ...) have no READMEs.
 - 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
--- a/doc/RRC/rrc-dev.md
+++ b/doc/RRC/rrc-dev.md
@@ -8,7 +8,7 @@ separate page](./rrc-usage.md).

 [[_TOC_]]

-# General
+## General

 5G RRC is basically an ITTI message queue with associated handlers. It
 sequentially reads received ITTI messages and handles them through the function
@@ -26,7 +26,7 @@ possible to find the message in the switch based on a message name in the spec.
 Note that RRC is inherently single-threaded, and processes messages in a FIFO
 order.

-# Sequence Diagrams of UE procedures
+## Sequence Diagrams of UE procedures

 The following section presents a number of common UE procedures for connection
 establishment&control, bearer establishment, etc. The intention is to help
@@ -66,7 +66,7 @@ sequenceDiagram
  ue->>cucp: F1AP UL RRC Msg Transfer (RRC Message Answer)
 ```

-## Initial connection setup/Registration
+### Initial connection setup/Registration

 This sequence diagram shows the principal steps for an initial UE connection.
 This can either happen through a _Registration Request_ (e.g., UE connects
@@ -164,7 +164,7 @@ sequenceDiagram
  cucp->>amf: NGAP PDU Session Resource Setup Resp
 ```

-## Reestablishment
+### Reestablishment

 The following sequence diagram shows the principal steps during a
 reestablishment request. When handling the RRC Reestablishment Request at the
@@ -210,7 +210,7 @@ sequenceDiagram
  end
 ```

-## Inter-DU Handover (F1)
+### Inter-DU Handover (F1)

 The basic handover (HO) structure is as follows. In order to support various
 handover "message passing implementation" (F1AP, NGAP, XnAP), RRC employs
@@ -264,7 +264,7 @@ sequenceDiagram
  sdu->>cucp: F1AP UE Context Release Complete
  Note over ue,tdu: UE active on target DU
 ```
-## Inter-gNB Handover (N2)
+### Inter-gNB Handover (N2)

 This is an inter-NG-RAN procedure. The N2 handover specification is defined in the following documents:

@@ -278,7 +278,7 @@ This is an inter-NG-RAN procedure. The N2 handover specification is defined in t
  - Includes messages like Handover Request, Handover Command, and Handover Preparation.
 * 3GPP TS 38.331 (RRC): details the UE-level RRC procedures involved during handovers

-### End-to-end flow
+#### End-to-end flow

 ```mermaid
 sequenceDiagram
@@ -353,9 +353,9 @@ sequenceDiagram
  Note over ue,tdu: UE active on target DU
 ```

-# Structures
+## Structures

-## Cells
+### Cells

 OAI 5G RRC does not actually handle multiple cells as of now, but multiple DUs,
 each being limited to one cell.
@@ -363,12 +363,12 @@ each being limited to one cell.
 Cell-related data is stored in `nr_rrc_du_container_t`, and kept in a tree
 indexed by the SCTP association ID.

-## CU-UPs
+### CU-UPs

 CU-UP information is stored in `nr_rrc_cuup_container_t`, and kept in a tree
 indexed by the SCTP association ID.

-## Transactions
+### Transactions

 The RRC keeps track of ongoing transaction (RRC procedures) through a per-UE
 array `xids`, which is indexed with a transaction ID `xid` in `[0,3]` to keep
@@ -385,7 +385,7 @@ However, it might be possible to trigger a procedure while another is ongoing.
 As of now, no queueing mechanims exists to ensure only one operation is
 ongoing, which would likely also simplify the code.

-## Handover
+### Handover

 Handover-related data is stored in a per-UE structure of type
 `nr_handover_context_t`. It is a pointer and only set during handover
--- a/doc/RRC/rrc-usage.md
+++ b/doc/RRC/rrc-usage.md
@@ -6,7 +6,7 @@ Developer documentation, such as UE connection control flow, reestablishment, or

 [[_TOC_]]

-# General
+## General

 The RRC layer controls the basic connection setup of UEs as well as additional
 procedures. It is the fundamental building block of OAI's CU-CP, and interacts
@@ -14,7 +14,7 @@ with lower layers (DU, basically MAC and RLC) through F1AP messages, and with
 the CU-UP through E1AP messages. More information can be found in the
 respective [F1AP page](../F1AP/F1-design.md) and [E1AP page](../E1AP/E1-design.md).

-# Periodic output and interpretation
+## Periodic output and interpretation

 Similarly to the scheduler, the RRC periodically prints information about
 connected UEs and DUs into file `nrRRC_stats.log` in the current working
@@ -53,19 +53,19 @@ blocks/PRB). Only one cell per DU is supported.

 As of now, it does not print information about connected CU-UPs or AMFs.

-# Configuration of the RRC
+## Configuration of the RRC

-## Split-related options (when running in a CU or CU-CP)
+### Split-related options (when running in a CU or CU-CP)

 See [F1 documentation](../F1AP/F1-design.md) for information about the F1 split.
 See [E1 documentation](../E1AP/E1-design.md) for information about the E1 split.

-## RRC-specific configuration options
+### RRC-specific configuration options

 In the `gNBs` section of the gNB/CU/CU-CP configuration file is the
 RRC-specific configuration

-### cell-specific options
+#### cell-specific options

 Note that some SIBS are configured at the CU and some at the DU; please consult
 the [MAC configuration](../MAC/mac-usage.md) as well for SIB configuration.
@@ -90,18 +90,18 @@ the [MAC configuration](../MAC/mac-usage.md) as well for SIB configuration.
 - `cu_sibs` (default: `[]`) list of SIBs to give to the DU for transmission.
  Currently, SIB2 is supported.

-### UE-specific configuration
+#### UE-specific configuration

 - `um_on_default_drb` (default: false): use RLC UM instead of RLC AM on default
  bearers
 - `drbs` (default: 0): the number of DRBs to allocate for a UE, only useful for
  do-ra or phy-test testing

-### Neighbor-gNB configuration
+#### Neighbor-gNB configuration

 Refer to the [handover tutorial](../handover-tutorial.md) for detailed information about gNB neighbors and handover procedures.

-#### Required configuration parameters
+##### Required configuration parameters

 To define a neighbor cell in the configuration file, the following parameters are required:

--- a/doc/RUNMODEM.md
+++ b/doc/RUNMODEM.md
@@ -22,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
@@ -39,7 +39,7 @@ It is planned to enhance this simulator with the following functionalities:

 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
@@ -48,7 +48,7 @@ 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](./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:

@@ -57,21 +57,21 @@ OAI supports different radio heads, the following are tested in the CI:
 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
@@ -79,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. 

@@ -127,7 +127,7 @@ UE capabilities can be passed according to the [UE Capabilities](#UE-Capabilitie

 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:

@@ -152,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.

@@ -176,9 +176,9 @@ 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.
@@ -225,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).

@@ -331,7 +331,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.
@@ -371,9 +371,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 --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
@@ -400,7 +400,7 @@ In summary:

 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
@@ -428,7 +428,7 @@ 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. 

@@ -456,7 +456,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.

@@ -467,7 +467,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, allowing the
 use of RF front-ends operating on arbitrary frequency bands that do not conform
@@ -489,7 +489,7 @@ the configuration file:
 > `if_freq` numeric value is suffixed with "L" so it is correctly parsed as
 > 64-bit integer.

-### 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.
@@ -501,7 +501,7 @@ 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.

--- a/doc/RUN_NR_PRS.md
+++ b/doc/RUN_NR_PRS.md
@@ -17,7 +17,7 @@ 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.

-# PRS parameters and config files
+## PRS parameters and config files

 | **Mode** 	                    | **gNB config**                                                                          	  | **nrUE config**           	|
 |-----------------------------	|-------------------------------------------------------------------------------------------  |---------------------------	|
@@ -51,7 +51,7 @@ 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
+## 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:
@@ -61,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```
@@ -73,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`.
@@ -85,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.
@@ -95,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```  
@@ -116,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.
@@ -130,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.
@@ -144,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
@@ -162,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>```
@@ -170,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:
--- a/doc/SW_archi.md
+++ b/doc/SW_archi.md
@@ -66,9 +66,9 @@ end

 This tuto for 5G gNB design, with Open Cells main

-# 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  
@@ -79,10 +79,10 @@ The infinite loop:
 raw incoming data is in buffer called "rxdata"  
    We derivate frame number, slot number, ... from the RX timestamp

-## gNB_top()
+### gNB_top()
 only compute frame number, slot number, ...

-## ocp_rxtx()
+### 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  
@@ -93,7 +93,7 @@ Then, phy_procedures_gNB_uespec_RX will hereafter replace the data for the next
 This is very tricky and not thread safe at all.


-### NR_UL_indication()  
+#### NR_UL_indication()
 This block processes data already decoded and stored in structures behind UL_INFO


@@ -116,9 +116,10 @@ the **scheduler** is called here, see dedicated chapter
 process as per the scheduler decided


-### L1_nr_prach_procedures()  
+#### L1_nr_prach_procedures()  
 ????
-### phy_procedures_gNB_uespec_RX()
+
+#### 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  
@@ -153,7 +154,7 @@ 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)


-### phy_procedures_gNB_TX()
+#### phy_procedures_gNB_TX()
 * nr_common_signal_procedures()  
 generate common signals

@@ -164,16 +165,22 @@ generate DCI: the scheduling informtion for each UE in both DL and UL
 generate DL shared channel (user data)


-### nr_feptx_prec()
+#### nr_feptx_prec()
 tx precoding
-### nr_feptx0
+<<<<<<< HEAD:doc/SW_archi.md
+
+#### nr_feptx0
 do the inverse DFT
-### tx_rf()
+
+#### nr_feptx0
+do the inverse DFT
+
+#### tx_rf()
 send radio signal samples to the RF board  
 the samples numbers are the future time for these samples emission on-air


-# 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, ...)  
@@ -252,7 +259,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  
  
@@ -261,7 +268,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.

@@ -280,9 +287,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()`.

@@ -293,11 +300,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.

@@ -305,19 +312,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_drb()` adds UE DRB 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.

@@ -408,46 +415,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  

@@ -456,7 +463,7 @@ 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  

--- a/doc/UnitTests.md
+++ b/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:

@@ -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

--- a/doc/analog_beamforming.md
+++ b/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,7 +12,7 @@ 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)

@@ -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 and the number of beams per period equals the total number of beams.

-# 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.
@@ -43,7 +43,7 @@ In phy-test mode, beams are assigned to PDSCH slots in the same manner as SSB sl

 The DL slots in every TDD period will have beams 10,11,12,13,0,0,0

-# FAPI implementation
+## FAPI implementation

 To be noted that in our implementation analog beamforming is only partially supported in split mode.
 The index based beamforming relies on the Tx precoding and beamforming PDU definition of beam-ID, where MSB is used to signal if the ID can be directly used or is it a pointer to a pre-stored vector of weights.
@@ -55,14 +55,14 @@ In addition to that, a `config_request` structure defined as vendor extension (`

 Therefore, in case of analog beamforming, L2 provides in each channel FAPI message information about the beam index via the beam-ID parameter with MSB set to 1.

-# 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.

--- a/doc/clang-format.md
+++ b/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)
--- a/doc/code-style-contrib.md
+++ b/doc/code-style-contrib.md
@@ -4,7 +4,7 @@ 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.
@@ -25,7 +25,7 @@ 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
@@ -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
@@ -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,7 +244,7 @@ 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
 report general user problems; use the [mailing
--- a/doc/cross-compile.md
+++ b/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
--- a/doc/dev_tools/sanitizers.md
+++ b/doc/dev_tools/sanitizers.md
@@ -14,14 +14,14 @@

 [[_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.:
 ```
@@ -29,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.
@@ -48,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:
@@ -62,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:
@@ -70,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.
--- a/doc/handover-tutorial.md
+++ b/doc/handover-tutorial.md
@@ -12,7 +12,7 @@ the CU and the associated DUs.

 [[_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
@@ -22,7 +22,7 @@ same.

 ![F1 Handover setup](./RRC/ho.png)

-# gNB neighbour definition
+## What is a gNB neighbor?

 Network continuity is a key aspect of 5G. In the 5G architecture, gNB neighbours
 play a central role in maintaining service continuity through mechanisms such
@@ -39,13 +39,13 @@ Neighbour types include:
 - **Inter-gNB neighbours** - cells belonging to different gNBs
 - **Inter-RAT neighbours** - cells belonging to another RAT (e.g., LTE)

-# 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,
@@ -53,7 +53,7 @@ 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

 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
@@ -116,7 +116,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:

@@ -139,7 +139,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
@@ -156,7 +156,7 @@ For UEs, we verified Quectel modules, iPhones and Samsung S23 Ultra. 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
@@ -217,7 +217,7 @@ Our CI setup consists of:
 To run the setup using Docker:
 - We consider 2 synchronized servers. One for each DU.

-## 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:
@@ -339,13 +339,13 @@ below.

 ```

-# 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
@@ -400,7 +400,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
@@ -420,9 +420,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
@@ -436,7 +436,7 @@ We assume:
 * Handover is triggered by either a 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

 **Note for same-machine setup:** When running both gNBs on the same machine,
 you need to assign a unique IP address to the second gNB to avoid network
@@ -496,7 +496,7 @@ RRC ID of the UE.

 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).
--- a/doc/nfapi.md
+++ b/doc/nfapi.md
@@ -114,7 +114,7 @@ can proceed as follows:
 > **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:
@@ -133,15 +133,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](./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)
@@ -171,7 +171,7 @@ 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".

@@ -195,7 +195,7 @@ Run VNF

    sudo NFAPI_TRACE_LEVEL=info ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb-vnf.sa.band78.106prb.nfapi.conf --nfapi VNF

-#### 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):
--- a/doc/nr-ue-design.md
+++ b/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,7 +8,7 @@ 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.
@@ -17,7 +17,7 @@ UE uses actors which are threads dedicated to particular activity. Sync Actor ha

 ![design](images/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)"]
--- a/doc/physical-simulators.md
+++ b/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                      |
 |------------|-------------------------------------------|----------------------------------|
@@ -39,7 +39,7 @@ pipelines:
 |            | `nr_srssim`                               | SRS 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/`
@@ -52,9 +52,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.
@@ -67,7 +67,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.

@@ -78,7 +78,7 @@ cd ran_build/build
 ctest
 ```

-## `ctest` Usage Tips
+### `ctest` Usage Tips

 Use the following options to customize test execution:

@@ -100,7 +100,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:

@@ -108,7 +108,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:

@@ -126,7 +126,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
@@ -163,7 +163,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.
@@ -186,7 +186,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.

@@ -196,7 +196,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:

--- a/doc/system_requirements.md
+++ b/doc/system_requirements.md
@@ -18,7 +18,7 @@ This document describes the minimal and performant system requirements for OpenA

 [[_TOC_]]

-# Supported CPU Architecture
+## Supported CPU Architecture

 |Architecture                               |
 |------------------------------------------ |
@@ -29,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 |
 |-----------------|
@@ -40,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
@@ -61,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
@@ -70,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.

-### Minimum requirements for both gNB and UE Stack
+#### Minimum requirements for both gNB and UE Stack

 - CPU: 3
 - Memory: 5Gi
@@ -84,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 
@@ -97,7 +97,7 @@ The minimum requirements stated in [simulated radio](.##simulated-radio) apply.
 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.

@@ -108,7 +108,7 @@ 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
@@ -118,7 +118,7 @@ tune your system to get high performance.
 - (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 
@@ -128,7 +128,7 @@ tune your system to get high performance.
 - (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](./ORAN_FHI7.2_Tutorial.md) before purchasing a Desktop server or rack/blade server. 

--- a/doc/tuning_and_security.md
+++ b/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
@@ -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.