doc: Fix formatting for mkdocs parsing

- Give a line in between bullet points to reflect bullet points correctly - Split long statement into bullet points for readability - Format the document for proper rendering - Fix table formatting - Use standard TOC syntax in 5GNAS
2026-01-22 10:50:50 +01:00
parent 57f8e69c13
commit 1aa13e4f23
13 changed files with 115 additions and 45 deletions
@@ -2,7 +2,7 @@

 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]
+[[_TOC_]]

 # About 5GS NAS

@@ -42,21 +42,28 @@ The following tables lists implemented NAS messages and whether there is an enco
 * Handles 5GMM state and mode

 [openair3/NAS/NR_UE/5GS/fgs_nas_lib.c](../openair3/NAS/NR_UE/5GS/fgs_nas_lib.c):
+
 [openair3/NAS/NR_UE/5GS/NR_NAS_defs.h](../openair3/NAS/NR_UE/5GS/NR_NAS_defs.h):
+
 * encoding and decoding functions for 5G NAS message headers and payloads
 * relies on 5GMM/5GSM messages libs for payload encoding

 [openair3/NAS/NR_UE/5GS/fgs_nas_utils.h](../openair3/NAS/NR_UE/5GS/fgs_nas_utils.h):
+
 * NAS helpers, macros

 [openair3/NAS/NR_UE/5GS/5GMM](../openair3/NAS/NR_UE/5GS/5GMM):
+
 * encoding/decoding functions and definitions for 5GMM NAS messages payloads

 [openair3/NAS/NR_UE/5GS/5GMM/MSG/fgmm_lib.c](../openair3/NAS/NR_UE/5GS/5GMM/MSG/fgmm_lib.c):
+
 [openair3/NAS/NR_UE/5GS/5GMM/MSG/fgmm_lib.h](../openair3/NAS/NR_UE/5GS/5GMM/MSG/fgmm_lib.h):
+
 * encoding/decoding functions and definitions for common 5GMM IEs

 [openair3/NAS/NR_UE/5GS/5GSM](../openair3/NAS/NR_UE/5GS/5GSM):
+
 * encoding and decoding functions for 5GSM NAS messages payloads

 # USIM Simulation
@@ -16,18 +16,21 @@

 # 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)
 * 3GPP TS 38.460 - E1 general aspects and principles
 * 3GPP TS 38.461 - E1 interface: layer 1 
 * 3GPP TS 38.462 - E1 interface: signaling transport

 The E1AP protocol consists of the following sets of functions:
+
 * E1 Interface Management functions
 * E1 Bearer Context Management functions
 * TEID allocation 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).
 * E1 Bearer Context Modification: can be initiated by either gNB-CU-CP or gNB-CU-UP, with the receiving node having the authority to accept or reject the modification.
 * Release of Bearer Context: can be triggered either directly by gNB-CU-CP or following a request from gNB-CU-UP.
@@ -21,14 +21,17 @@ unit: PDCP, RRC, SDAP) and the DU (distributed unit: RLC, MAC, PHY). It is
 standardized in TS 38.470 - 38.473 for 5G NR.

 F1 specs:
+
 * 3GPP TS 38.470 F1 general aspects and principles
 * 3GPP TS 38.471 F1 layer 1

 F1-C:
+
 * 3GPP TS 38.472 F1 signalling transport
 * 3GPP TS 38.473 F1 Application Protocol (F1AP)

 F1-U:
+
 * 3GPP TS 38.474 F1 Data Transport

 No equivalent for 4G exists.
@@ -56,12 +59,14 @@ This is the current status:

 - gNB-CU/gNB-DU split
 - Supported deployments:
-  * SA
-  * Single cell per DU
-  * Multiple DUs connected to one CU (both CP and UP)
-  * [Mobility between DUs connected to a single CU](../handover-tutorial.md)
+
+    * SA
+    * Single cell per DU
+    * Multiple DUs connected to one CU (both CP and UP)
+    * [Mobility between DUs connected to a single CU](../handover-tutorial.md)
 - Not supported:
-  * NSA
+
+    * NSA

 ### F1-C

@@ -194,6 +199,7 @@ see [this `docker-compose` file](../../ci-scripts/yaml_files/5g_f1_rfsimulator/d

 The rules to decide if a config triggers a start of a DU, CU, or monolithic
 gNB, are, in order:
+
 1. If the `MACRLCs` section lists `f1` as **northbound transport preference**
   (`tr_n_preference`), it is a DU.
 2. If the `gNBs` section lists `f1` as a **southound transport preference**
@@ -208,12 +214,13 @@ on `192.168.70.129` towards the core, `127.0.0.3` towards the DU, and the DU
 `127.0.0.4` towards the CU.

 In the CU file:
+
 - Update the `gNBs.[0].amf_ip_address` and `gNBs.[0].NETWORK_INTERFACES`
  section towards the core (typically, OAI CN is configured to provide a docker
  bridge on `192.168.70.129` and the AMF is on `192.168.70.132`):
-  - `gNBs.[0].amf_ip_address.[0].ipv4 192.168.70.132`
-  - `gNBs.[0].NETWORK_INTERFACES.GNB_IPV4_ADDRESS_FOR_NG_AMF 192.168.70.129`
-  - `gNBs.[0].NETWORK_INTERFACES.GNB_IPV4_ADDRESS_FOR_NGU 192.168.70.132`
+    - `gNBs.[0].amf_ip_address.[0].ipv4 192.168.70.132`
+    - `gNBs.[0].NETWORK_INTERFACES.GNB_IPV4_ADDRESS_FOR_NG_AMF 192.168.70.129`
+    - `gNBs.[0].NETWORK_INTERFACES.GNB_IPV4_ADDRESS_FOR_NGU 192.168.70.132`
 - Set `gNBs.[0].tr_s_preference` (transport south-bound) to `f1`
 - Update the `gNBs.[0].local_s_address` (CU-local south address) for the
  F1-C/SCTP and F1-U/GTP/UDP south-bound interfaces: `127.0.0.3`
@@ -221,10 +228,11 @@ In the CU file:
  ignored, but we recommend to put `0.0.0.0` ("any")
 - Ports should match the ones in the DU config, but for simplicity and
  standards-conformity, simply set all to 2152:
-  - `local_s_portd` in CU should match `remote_n_portd` in DU
-  - `remote_s_portd` in CU should match `local_n_portd` in DU
+    - `local_s_portd` in CU should match `remote_n_portd` in DU
+    - `remote_s_portd` in CU should match `local_n_portd` in DU

 In the DU file:
+
 - Set `MACRLCs.[0].tr_n_preference` to `f1`
 - Update `MACRLCs.[0].local_n_address` (local north-bound address of the DU) to
  `127.0.0.4`. This IP address is used to bind the F1-C/SCTP and F1-U/GTP/UDP
@@ -90,6 +90,7 @@ UE 2460: LCID 4: TX     1526169592 RX          16152 bytes
 ```

 In the first line,
+
 * `UE RNTI` (here `2460`): this is also used as the DU UE ID over F1; each line
  is prepended with the RNTI
 * `CU UE ID` (`2`): separate identifier from the RNTI to handle multiple
@@ -109,6 +110,7 @@ In the first line,
 The second and third line reflect channel state information (CSI) as
 reported by the UE, and only appear if CSI-RS/SRS are enabled and _received_
 (for some bands, they cannot be enabled):
+
 * `CQI` (`15`): the channel quality indicator is a number between 0 and 15. It
  indicates the achievable spectral efficiency of the UE. 15 means highest, 0
  is lowest. This corresponds to a 4-bit table in 38.214 with actual spectral
@@ -121,6 +123,7 @@ reported by the UE, and only appear if CSI-RS/SRS are enabled and _received_
 * `UL-RI`, `TPMI`: same as DL.

 The fourth and fifth line show HARQ-related information:
+
 * `dlsch_rounds A/B/C/D` (`32917/5113/1504/560`). This is the number of
  transmissions by the gNB for each round of the HARQ protocol. `A` is the first
  round, B is the second, etc. If `A` is high and `B` is low, `C` is lower and `D` is
@@ -168,6 +171,7 @@ The fourth and fifth line show HARQ-related information:
  but could not allocate the DCI.

 In the last lines:
+
 * `MAC` shows the amount of MAC PDU bytes scheduled in transmit (`TX`,
  `1530943191`) and receive (`RX`, `194148`) directions
 * `LCID X` shows the amount of MAC SDU/RLC PDU data for Logical Channel ID with
@@ -321,6 +325,7 @@ The TDD configuration parameters allow to use one or two TDD patterns.
 #### Single TDD pattern

 Configure the TDD pattern through these options:
+
 - `dl_UL_TransmissionPeriodicity`: Refers to the UL/DL slots periodicity for
  the TDD pattern. See below for valid numbers.
 - `nrofDownlinkSlots`: Refers to the number of consecutive DL slots in the TDD
@@ -20,18 +20,26 @@
 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:
+
 - Laptop/Desktop/Server for OAI CN5G and OAI gNB
+
    - Operating System: [Ubuntu 24.04 LTS](https://releases.ubuntu.com/24.04/ubuntu-24.04.2-desktop-amd64.iso)
    - CPU: 8 cores x86_64 @ 3.5 GHz
    - RAM: 32 GB
+
 - Laptop for UE
+
    - Operating System: Microsoft Windows 10 x64
    - CPU: 4 cores x86_64
    - RAM: 8 GB
    - Windows driver for Quectel MUST be equal or higher than version **2.4.6**
+
 - [USRP B210](https://www.ettus.com/all-products/ub210-kit/), [USRP N300](https://www.ettus.com/all-products/USRP-N300/) or [USRP X300](https://www.ettus.com/all-products/x300-kit/)
+
    - Please identify the network interface(s) on which the USRP is connected and update the gNB configuration file
+
 - Quectel RM500Q
+
    - Module, M.2 to USB adapter, antennas and SIM card
    - Firmware version of Quectel MUST be equal or higher than **RM500QGLABR11A06M4G**

@@ -20,7 +20,9 @@
 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:
+
 - Laptop/Desktop/Server for OAI CN5G and OAI gNB
+
    - Operating System: [Ubuntu 24.04 LTS](https://releases.ubuntu.com/24.04/ubuntu-24.04.2-desktop-amd64.iso)
    - CPU: 8 cores x86_64 @ 3.5 GHz
    - RAM: 32 GB
@@ -20,15 +20,21 @@
 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:
+
 - Laptop/Desktop/Server for OAI CN5G and OAI gNB
+
    - Operating System: [Ubuntu 24.04 LTS](https://releases.ubuntu.com/24.04/ubuntu-24.04.2-desktop-amd64.iso)
    - CPU: 8 cores x86_64 @ 3.5 GHz
    - RAM: 32 GB
+
 - Laptop for UE
+
    - Operating System: [Ubuntu 24.04 LTS](https://releases.ubuntu.com/24.04/ubuntu-24.04.2-desktop-amd64.iso)
    - CPU: 8 cores x86_64 @ 3.5 GHz
    - RAM: 8 GB
+
 - [USRP B210](https://www.ettus.com/all-products/ub210-kit/), [USRP N300](https://www.ettus.com/all-products/USRP-N300/) or [USRP X300](https://www.ettus.com/all-products/x300-kit/)
+
    - Please identify the network interface(s) on which the USRP is connected and update the gNB configuration file


@@ -40,17 +40,17 @@ There is some general information in the [OpenAirInterface Gitlab Wiki](https://
 # Tutorials

 - Step-by-step tutorials to set up 5G:
-  * [OAI 5GC](./NR_SA_Tutorial_OAI_CN5G.md)
-  * [OAI gNB with COTS UE](./NR_SA_Tutorial_COTS_UE.md)
-  * [OAI NR-UE](./NR_SA_Tutorial_OAI_nrUE.md)
-  * [Multiple OAI NR-UE with RFsimulator](./NR_SA_Tutorial_OAI_multi_UE.md)
+    * [OAI 5GC](./NR_SA_Tutorial_OAI_CN5G.md)
+    * [OAI gNB with COTS UE](./NR_SA_Tutorial_COTS_UE.md)
+    * [OAI NR-UE](./NR_SA_Tutorial_OAI_nrUE.md)
+    * [Multiple OAI NR-UE with RFsimulator](./NR_SA_Tutorial_OAI_multi_UE.md)
 - [RUNMODEM.md](./RUNMODEM.md): Generic information on how to
-  * Run simulators
-  * Run with hardware
-  * Specific OAI modes (phy-test, do-ra, noS1)
-  * (5G) Using SDAP and custom DRBs
-  * IF setups and arbitrary frequencies
-  * MIMO
+    * Run simulators
+    * Run with hardware
+    * Specific OAI modes (phy-test, do-ra, noS1)
+    * (5G) Using SDAP and custom DRBs
+    * IF setups and arbitrary frequencies
+    * MIMO
 - [How to run OAI with O-RAN 7.2 FHI](./ORAN_FHI7.2_Tutorial.md)
 - [How to run a 5G-NSA setup](./TESTING_OAI_NSA_COTS_UE.md)
 - [How to run a 4G setup using L1 simulator](./L1SIM.md) _Note: we recommend the RFsimulator_
@@ -394,14 +394,17 @@ operation. This data structure has in turn two pointers, one to the source CU
 both are present. In N2 and Xn, only one pointer is supposed to be set at the
 corresponding CU.

-`nr_ho_source_cu_t` contains notably a function pointer `ho_cancel` for
-handover cancel.  `nr_ho_target_cu_t` contains function pointers `ho_req_ack`
+- `nr_ho_source_cu_t` contains notably a function pointer `ho_cancel` for
+handover cancel.  
+- `nr_ho_target_cu_t` contains function pointers `ho_req_ack`
 for handover request acknowledge, `ho_success` for handover success,
 `ho_failure` for handover failure (N2 only).
 be seen in the sequence diagram above, either the "target CU" or "source CU"
 needs to do an operation, and a "switch" from target to source CU is done using
-these function pointers. For instance, in F1, the handover request acknowledge
+these function pointers. 
+- For instance, in F1, the handover request acknowledge
 function pointers merely calls another (RRC) function which triggers a
-reconfiguration. In the case of N2, the handover request acknowledge function
+reconfiguration. 
+- In the case of N2, the handover request acknowledge function
 pointer should trigger the NGAP Handover Request Acknowledge, and the handover
 success function pointer should trigger the NGAP Handover Success message.
@@ -19,15 +19,17 @@ cd phy_simulators/build/
 On UpLink Shared CHannel(ULSCH), multiple users share the same radio resources (time and frequency slots), the base station schedules and assigns the resources dynamically. The goal here is to simulate the sending of data from an UE to a base station. 

 Example:
-| Parameter | Value | Description |
-|--- |:-: |--: |
-| R | 106 | R_NB_UL=106|
-| m | 9 | MCS=9 |
-| s | 13 | Start SNR |
-| n | 100 | Will simulate 100 frames |
-| y | 4 | 4 antennas used in eNB |
-| z | 4 | 4 antennas used in UE |
-| W | 4 | Will use 4 layers |
+
+| Parameter | Value | Description              |
+|-----------|:-----:|--------------------------|
+| R         |  106  | R_NB_UL = 106            |
+| m         |   9   | MCS = 9                  |
+| s         |  13   | Start SNR                |
+| n         | 100   | Will simulate 100 frames |
+| y         |   4   | 4 antennas used in eNB   |
+| z         |   4   | 4 antennas used in UE    |
+| W         |   4   | Will use 4 layers        |
+


 ```bash
@@ -38,6 +40,7 @@ sudo ./nr_ulschsim -R 106 -m9 -s13 -n100 -y4 -z4 -W4
 On UpLink Channel, a single user is dealing with a single base station. The goal is here to simulate the sending of the data from an UE to a base station.

 It's focusing on: 
+
 - UpLink chain validation  
 - PUSCH (whole chain) on UE side and gNB side
 - No channel model on data domain signal, which means an ideal scenario is used
@@ -63,13 +66,15 @@ sudo ./build_oai -c --gNB --nrUE -w SIMU
 ##### 4x4 RANK 4

 Example:
-| Parameter | Value | Description |
-|--- |:-: |--: |
-| O | [...] | Use a configuration file |
-| l | 2 | Set the number of layers for downlink to 2 for PHY test mode |
-| L | 4 | Set the number of layers for uplink to 4 for PHY test mode |
-| ue-nb-ant-rx | 4 | Set UE number of rx antennas to 4 |
-| ue-nb-ant-tx | 4 | Set UE number of tx antennas to 4 |
+
+| Parameter     | Value | Description                                              |
+|---------------|:-----:|----------------------------------------------------------|
+| O             | [...] | Use a configuration file                                 |
+| l             |   2   | Set the number of layers for downlink to 2 for PHY test mode |
+| L             |   4   | Set the number of layers for uplink to 4 for PHY test mode   |
+| ue-nb-ant-rx  |   4   | Set UE number of rx antennas to 4                         |
+| ue-nb-ant-tx  |   4   | Set UE number of tx antennas to 4                         |
+

 ```bash
 sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.4layer.conf --rfsim --phy-test --l 2  --L 4
@@ -5,12 +5,14 @@ In addition, it synchronizes and combines data traces and control information (m

 ## Data Recording Application Architecture 

-Data Recording Application designed to have multiple services in different simulation environments: 
+Data Recording Application designed to have multiple services in different simulation environments:
+
 - Data Control Service (Python)
 - Data collection (T-Tracer) Service (C)
 - Data Conversion Service (Python)

-Regarding to the APIs between different services, they are such as the following: 
+Regarding to the APIs between different services, they are such as the following:
+
 - Data Control Service -> Data Collection (T–Tracer) Service: The API is based on a shared memory.
 - Data Collection (T–Tracer) Service -> 5G NR Stack: T-Tracer Framework, ethernet connection.
 - Data Collection (T–Tracer) Service -> Data Conversion Service: The API is based on a shared memory.
@@ -21,30 +23,37 @@ The following figure shows OAI gNB and UE with the Data Recording App system arc

 ## Required Packages
 Install all required system packages with the following commands:
+
 ```bash
 sudo apt-get update
 sudo apt-get install -y python3-sysv-ipc libxft-dev
 ```

 Then, install all required python packages with the following commands:
+
 ```bash
 python3 -m pip install sigmf==1.2.1 termcolor bitarray pandas numpy==1.23
 ```

 User can install all required python packages also using the `requirements.txt` file:
+
 ```bash
 python3 -m pip install -r common/utils/data_recording/requirements.txt
 ```

 ## Configuration Files
+
 ### Main Data Recording JSON Configuration File
+
 The Data Recording application provides configuration file in [JSON](http://www.json.org/) format. It is stored in [common/utils/data_recording/config/config_data_recording.json](../common/utils/data_recording/config/config_data_recording.json) folder. The main parameters are:
+
 - **data_storage_path**: Path to directory for data storage
 - **num_records**: Number of requested data records in slots
 - **t_tracer_message_definition_file**: T-Tracer message definition file
 - **parameter_map_file**: Parameter mapping dictionary (OAI parameters to standardized metadata). It is located here: [common/utils/data_recording/config/wireless_link_parameter_map.yaml](../common/utils/data_recording/config/wireless_link_parameter_map.yaml) 
 - **start_frame_number**: It can be used to start the recording from a specific frame, but it is not yet supported.
 - **base_station**:
+
    - requested_tracer_messages: Requested base station data traces. The supported messages are:
        - GNB_PHY_UL_FD_PUSCH_IQ
        - GNB_PHY_UL_FD_DMRS
@@ -53,6 +62,7 @@ The Data Recording application provides configuration file in [JSON](http://www.
        - GNB_PHY_UL_PAYLOAD_RX_BITS
    - meta_data: Additional base station metadata (additional fixed base station parameters that cannot be read from the system yet, but shall be included into the SigMF metadata)
 - **user_equipment** 
+
    - requested_tracer_messages: Requested user equipment data traces. The supported messages are:
        - UE_PHY_UL_SCRAMBLED_TX_BITS
        - UE_PHY_UL_PAYLOAD_TX_BITS
@@ -142,6 +152,7 @@ The following figure shows an example of Wireless Link Parameter Map Dictionary.
 ### Global Metadata
 There are some metadata parameters that the user may need to change only once. Those parameters have been hard coded in the Data Recording App header.
 [common/utils/data_recording/data_recording_app_v1.0.py](../common/utils/data_recording/data_recording_app_v1.0.py). Those are:
+
 - The global metadata such as: author, description,  sigmf collection file prefix, datetime_offset, enable saving config Data Recording App in json file with recorded data, and name of signal generator (i.e. 5gnr_oai). The name of signal generator is used for parameter mapping dictionary (OAI parameters to standardized metadata).
 - The mapping between supported OAI messages and file_name_prefix, scope, and description.

@@ -233,6 +244,7 @@ sudo ./cmake_targets/ran_build/build/nr-softmodem -O ./targets/PROJECTS/GENERIC-
 > **Note:** User needs to change the name of gNB config file to your gNB config file.

 It is worth mentioning that the possible values for T-tracer control options
+
 - --T_stdout option:  default 1
    - --T_stdout = 0: Disable output on the terminal and only use the T tracer
    - --T_stdout = 1: Disable the T tracer and only output on the terminal
@@ -258,6 +270,7 @@ sudo ./cmake_targets/ran_build/build/nr-uesoftmodem --rfsim --rfsimulator.server

 ### Step3: Run Data Recording Application Services
 First, compile the Data Collection (T-Tracer) Services:
+
 - Go to: `common/utils/T/tracer`
 - Compile gNB and UE Data Collection Services (T-Tracer Apps)
 ```
@@ -346,6 +359,7 @@ The following figure shows an example of SigMF collection file and how it bundle
 ```

 Each SigMF metadata has three sections:
+
 - global: The standardized global parameters are presented here to understand and read the binary data.
 - captures: The standardized capture parameters provide details about the capture process.
 - annotations: It provides details about the recording scenario.
@@ -485,4 +499,5 @@ For synchronization validation and to show how to read SigMF metadata, a simple
 <img src="images/data_serialization_tx_scrambled_bit_message.svg" alt="Data serialization " width="500">

 ### To Do List:
+
 - Provide an overview about the different services of the Data Recording App (Data Control Service, Data collection (T-Tracer) Service, Data Conversion Service) and the APIs definition between them.
@@ -14,6 +14,7 @@ OAI uses/supports a number of environment variables, documented in the following
 - `USIM_DIR`: directory to read/write USIM data in (4G) `usim` tool; if not defined, will use `PWD` (working directory)

 Furthermore, these variables appear in code that is not maintained and maybe not even compiled anywhere:
+
 - `HOST`: alternative host to connect to, for CLI, if neither `REMADDR` nor `SSH_CLIENT` are defined
 - `REMADDR`: host to connect to, for CLI client
 - `SSH_CLIENT`: alternative host to connect to, for CLI, if `REMADDR` is not defined
@@ -6,6 +6,7 @@ The current implementation has been temporarily disrupted for LTE and only works
 nr-uesoftmodem executable.

 The I/Q record-replay feature is briefly described hereafter, it allows you to:
+
 * record slots received by the USRP board in a file while the system is operating.
  For example you can record a full nrUE connection/traffic/disconnection sequence.
  Today the OAI USRP device is the only one supporting the recording feature. 
@@ -16,6 +17,7 @@ The record-replay features are activated and configured using OAI configuration

 ### Record mode
 options for record mode are:
+
 * `subframes-record` Activate record mode
 * `subframes-file`   Path of the file used for slots recording (default is `/tmp/iqfile`)
 * `subframes-max`    Maximum count of slots to be recorded in a file (default is 120000)
@@ -30,7 +32,8 @@ At that time, up to the value of `--subframes-max` slots will be written on disk
 The nr-uesoftmodem will indicate the exact count of slots written to disk, which may be less (but not higher)
 than the value of `--subframes-max` parameter.

->Recording session example:
+**Recording session example:**
+
 ```bash
 ./nr-uesoftmodem -O /home/oaitests/mediatek_sim.conf --numerology 1 -r 106 -C 3649440000 --band 78 -E --ue-fo-compensation --device.recplay.subframes-record 1 --device.recplay.subframes-file /home/iqs/oai-nrUE-17042023.dat --device.recplay.use-mmap 1 --device.recplay.subframes-max 30000
 ............................................
@@ -41,17 +44,20 @@ than the value of `--subframes-max` parameter.
 [HW]   Writing 4565 subframes to /home/iqs/oai-nrUE-17042023.dat 
 [HW]   File /home/iqs/oai-nrUE-17042023.dat closed
 [HW]   releasing USRP
+```

 ### Replay mode
 Replaying I/Q works only for nr-uesoftmodem at 40MHz bandwidth 3/4 sampling.
 Mismatch between file content and run time parameters might lead to unpredictable results.
 options for replay mode are:
+
 * `subframes-replay` Activate replay mode
 * `subframes-file`   Path of the file used for slots replay (default is `/tmp/iqfile`)
 * `subframes-loops`  Number of iterations to replay the entire slots file (default is 5)
 * `use-mmap`         Boolean, set to 1 (true) by default, iq file is map to memory if true, otherwise iq's are read from file. 

->Replay mode session example:
+**Replay mode session example:**
+
 ```bash
 ./nr-uesoftmodem -O /home/oaitests/mediatek_sim.conf --numerology 1 -r 106 -C 3649440000 --band 78 -E --ue-fo-compensation --device.recplay.subframes-replay 1 --device.recplay.subframes-file /home/iqs/oai-nrUE-17042023.dat --device.recplay.use-mmap 1 --device.recplay.subframes-loops 1
 ..................................
@@ -61,5 +67,6 @@ options for replay mode are:
 [HW]   iqplayer device initialized, replay /home/iqs/oai-nrUE-17042023.dat for 1 iteration(s)
 ..................................
 ..................................
+```

 [OAI Wikis home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)