Merge remote-tracking branch 'origin/update_documentation' into integration_2025_w40 (!3628)

Update documentation

common/utils/mem/memory.c

@@ -25,52 +25,6 @@
 #include "common/utils/mem/oai_memory.h"
 #include "common/utils/LOG/log.h"
 
-/****************************************************************************
- **                                                                        **
- ** Name:  memory_get_path()                                         **
- **                                                                        **
- ** Description: Gets the absolute path of the file where non-volatile     **
- **    data are located                                          **
- **                                                                        **
- ** Inputs:  dirname: The directory where data file is located   **
- **    filename:  The name of the data file                  **
- **    Others:  None                                       **
- **                                                                        **
- ** Outputs:   None                                                      **
- **    Return:  The absolute path of the non-volatile data **
- **       file. The returned value is a dynamically  **
- **       allocated octet string that needs to be    **
- **       freed after usage.                         **
- **    Others:  None                                       **
- **                                                                        **
- ***************************************************************************/
-char* memory_get_path(const char* dirname, const char* filename)
-{
-  /* Get non-volatile data directory */
-  const char* path = getenv(dirname);
-
-  if (path == NULL) {
-    path = getenv(DEFAULT_NAS_PATH);
-  }
-
-  if (path == NULL) {
-    path = ".";
-  }
-
-  /* Append non-volatile data file name */
-  size_t size = strlen(path) + strlen(filename) + 1;
-  char* data_filename = (char*)malloc(size + 1);
-
-  if (data_filename != NULL) {
-    if (size != sprintf(data_filename, "%s/%s", path, filename)) {
-      free(data_filename);
-      return NULL;
-    }
-  }
-
-  return data_filename;
-}
-
 char* memory_get_path_from_ueid(const char* dirname, const char* filename, int ueid)
 {
   /* Get non-volatile data directory */

common/utils/mem/oai_memory.h

@@ -35,8 +35,6 @@ typedef unsigned char uint8_t;
 
 //-----------------------------------------------------------------------------
 
-char* memory_get_path(const char* dirname, const char* filename);
-
 char* memory_get_path_from_ueid(const char* dirname, const char* filename, int ueid);
 
 int memory_read(const char* datafile, void* data, size_t size);

doc/Doxyfile

@@ -51,7 +51,7 @@ PROJECT_BRIEF          = "Full experimental OpenSource LTE and NR implementation
 # pixels and the maximum width should not exceed 200 pixels. Doxygen will copy
 # the logo to the output directory.
 
-PROJECT_LOGO           = @CMAKE_SOURCE_DIR@/doc/oai_logo.png
+PROJECT_LOGO           = @CMAKE_SOURCE_DIR@/doc/images/oai_logo.png
 
 # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path
 # into which the generated documentation will be written. If a relative path is

doc/E1AP/E1-design.md

 [[_TOC_]]
 
-# 1. Introduction
+## 1. Introduction
 
 E1 is the interface that lies between the nodes CU Control Plane (CUCP) and CU User Plane (CUUP). Once the nodes are configured, all user plane traffic flows through CUUP.
 
@@ -77,11 +77,11 @@ sequenceDiagram
 ```
 More details about the E1AP procedures in OAI are available in this document: [E1 Procedures](./e1ap_procedures.md).
 
-# 2. Running the E1 Split
+## 2. Running the E1 Split
 
 The setup is assuming that all modules are running on the same machine. The user can refer to the [F1 design document](./../F1AP/F1-design.md) for local deployment of the DU.
 
-## 2.1 Configuration File
+### 2.1 Configuration File
 
 The gNB is started based on the node type that is specified in the configuration file. The following parameters must be configured accordingly.
 
@@ -130,9 +130,9 @@ The CUUP uses the IP address specified in `gNBs.[0].local_s_address` for F1-U an
 
 Alternatively, you can use the config files `ci-scripts/conf_files/gnb-cucp.sa.f1.conf` and `ci-scripts/conf_files/gnb-cuup.sa.f1.conf`.
 
-## 2.2 Steps to Run the Split in rfsimulator with OAI UE
+### 2.2 Steps to Run the Split in rfsimulator with OAI UE
 
-Note: A 5G core must be running at this point. Steps to start the OAI 5G core can be found [in the oai-cn5g-fed repository](https://gitlab.eurecom.fr/oai/cn5g/oai-cn5g-fed/-/blob/master/docs/DEPLOY_HOME.md) or [here](NR_SA_CN5G_gNB_USRP_COTS_UE_Tutorial.md).
+Note: A 5G core must be running at this point. Steps to start the OAI 5G core can be found [in the oai-cn5g-fed repository](https://gitlab.eurecom.fr/oai/cn5g/oai-cn5g-fed/-/blob/master/docs/DEPLOY_HOME.md) or [here](../NR_SA_Tutorial_OAI_CN5G.md).
 
 0. Open wireshark to capture the E1AP messages. You might set the capture filter
    to `sctp` to limit the number of captured packages.
@@ -165,7 +165,7 @@ OAI UE:
 sudo ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3619200000 --rfsim --rfsimulator.serveraddr 127.0.0.1
 ```
 
-# 3. Configuration file IP addresses of network functions
+## 3. Configuration file IP addresses of network functions
 
 You can also run the nodes on different machines. If you do so please change the interface parameters accordingly and make sure the interfaces are reachable. Please refer to the following figure for an overview of all parameters.
 
@@ -173,7 +173,7 @@ You can also run the nodes on different machines. If you do so please change the
 
 [PDF version](./images/e1-archi.pdf) | [LaTeX/TikZ version](./images/e1-archi.tex) if you want to modify to reflect your setup
 
-# 4. Multiple CU-UP
+## 4. Multiple CU-UP
 
 It is possible to connect multiple CU-UP to the same CU-CP. In the handler of
 the E1 Setup Request, the CU-CP verifies that the PLMN(s) (MCC, MNC) between
@@ -195,6 +195,6 @@ that you have to restart the CU-CP if you want to connect the CU-UP again
 (e.g., after a crash). The CU-CP might also misfunction during attach if a
 CU-UP was connected, but disconnected in the meantime.
 
-# 5. Abnormal conditions
+## 5. Abnormal conditions
 
 * The CU-UP goes offline during normal operation (e.g. UEs have a valid PDU Session and are exchanging data on the UP): after restarting the CU-UP, the UP is not restored and the user will notice GTP errors. In this case the UEs have to reconnect.

doc/F1AP/F1-design.md

@@ -2,7 +2,7 @@
   <tr style="border-collapse: collapse; border: none;">
     <td style="border-collapse: collapse; border: none;">
       <a href="http://www.openairinterface.org/">
-         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         <img src="../images/oai_final_logo.png" alt="" border=3 height=50 width=150>
          </img>
       </a>
     </td>
@@ -14,7 +14,7 @@
 
 [[_TOC_]]
 
-# Introduction
+## Introduction
 
 The F1 interface is the functional split of 3GPP between the CU (centralized
 unit: PDCP, RRC, SDAP) and the DU (distributed unit: RLC, MAC, PHY). It is
@@ -33,17 +33,17 @@ F1-U:
 
 No equivalent for 4G exists.
 
-## Control plane (F1-C)
+### Control plane (F1-C)
 
 The interface F1-C is designed for the exchange of signalling messages between the
 Radio Network Layer (RNL) and the Transport Network Layer (TNL). It
 consists of F1 Application Protocol messages (F1-AP) exchanged over SCTP.
 
-## Data plane (F1-U)
+### Data plane (F1-U)
 
 F1-U uses GTP-U for information exchange.
 
-# OAI Implementation Status
+## OAI Implementation Status
 
 The implementation of F1AP messages is seamlessly integrated into OAI, supporting both Monolithic SA
 and CU/DU functional split modes. The F1 code is therefore always compiled with nr-softmodem.
@@ -63,13 +63,13 @@ This is the current status:
 - Not supported:
   * NSA
 
-## F1-C
+### F1-C
 
-### F1AP messages
+#### F1AP messages
 
-Refer to [FEATURE_SET.md](FEATURE_SET.md#gNB-F1AP) to learn about the current F1AP implementation status.
+Refer to [FEATURE_SET.md](../FEATURE_SET.md#gnb-f1ap) to learn about the current F1AP implementation status.
 
-### High-level F1-C code structure
+#### High-level F1-C code structure
 
 The F1 interface is used internally between CU (mostly RRC) and DU (mostly MAC)
 to exchange information. In DL, the CU sends messages as defined by the
@@ -170,7 +170,7 @@ sequenceDiagram
     TASK_MAC_GNB->>+TASK_RRC_GNB: raw F1AP message (ITTI)
 ```
 
-## F1-U
+### F1-U
 
 Current status:
 
@@ -178,7 +178,7 @@ Current status:
 * Each packet is acknowledged individually
 * Support of multiple DUs per CU
 
-# How to run
+## How to run
 
 As mentioned earlier, OAI uses F1 internally. It is always compiled in.
 To start CU/DU, you use `./nr-softmodem` with the appropriate configuration
@@ -190,7 +190,7 @@ sudo cmake_targets/ran_build/build/nr-softmodem -O ci-scripts/conf_files/gnb-du.
 ```
 
 These files are tested in the CI, and are configured for use in docker,
-see [this `docker-compose` file](../ci-scripts/yaml_files/5g_f1_rfsimulator/docker-compose.yaml).
+see [this `docker-compose` file](../../ci-scripts/yaml_files/5g_f1_rfsimulator/docker-compose.yaml).
 
 The rules to decide if a config triggers a start of a DU, CU, or monolithic
 gNB, are, in order:
@@ -200,7 +200,7 @@ gNB, are, in order:
    (`tr_s_preference`), it is a CU.
 3. It is a (monolithic) gNB.
 
-## F1 IP configuration for Local network deployment of F1
+### F1 IP configuration for Local network deployment of F1
 
 The following paragraphs explain the IP configuration for F1 in the OAI config
 files on the example of a a local deployment.  We assume that the CU will bind
@@ -242,7 +242,7 @@ the options `MACRLCs.[0].local_n_address` and
 `MACRLCs.[0].local_n_address_f1u`, respectively. Note that this is not foreseen
 for the CU; in the case of the CU, please use separate CU-UP and CU-CP.
 
-## Configuration of multiple DUs
+### Configuration of multiple DUs
 
 Upon F1 Setup Request of a new DU, the CU cross-checks that
 
@@ -260,9 +260,9 @@ You have to of course make sure that the local interface of the DU
 Assuming you use RFsim, you should make the RFsimulator server side (typically
 the gNB) bind on different hosts (`rfsimulator.serverport`).
 
-# Code documentation
+## Code documentation
 
-## Common multi-threading architecture
+### Common multi-threading architecture
 
 The CU and DU interfaces are based on ITTI threads (see `common/utils/ocp_itti/itti.md`)
 adopted by all OAI upper layers to run isolated threads dedicated to one feature.
@@ -301,7 +301,7 @@ All GTP-U tunnels are managed in a Linux Thread, that have partially ITTI design
 3. incoming packets are sent to the tunnel creator using a C callback (the callback function is given in tunnel creation order). The callback should not block
 
 
-## F1-C messages towards the CU
+### F1-C messages towards the CU
 
 The CU thread starts when the CU starts. It opens listening socket on the
 configuration-specified IP/port by sending the appropriate message to
@@ -332,7 +332,7 @@ You might also want to consult TS 38.401 regarding the message exchange.
 | UE Context Release Request | `F1AP_UE_CONTEXT_RELEASE_REQ` | `rrc_CU_process_ue_context_release_request()` | RRC will trigger UE release |
 | UE Context Release Complete | `F1AP_UE_CONTEXT_RELEASE_COMPLETE` | `rrc_CU_process_ue_context_release_complete()` | frees UE Context, signals to NGAP |
 
-## F1-C Messages towards the DU
+### F1-C Messages towards the DU
 
 The task "gNB app", after reading the configuration file, sends a message
 `F1AP_DU_REGISTER_REQ` to the DU task. This message contains network
@@ -371,9 +371,9 @@ You might also want to consult TS 38.401 regarding the message exchange.
   a reconfiguration has to be triggered if the CU receives a CellGroupConfig,
   originating at the DU. See also flag `expect_reconfiguration`.
 
-## F1-U messages
+### F1-U messages
 
-### General
+#### General
 
 In the DU in UL, RLC checks in `deliver_sdu()` if we are operating in split
 mode, and either (direct) calls `pdcp_data_ind` (DRB) or (f1ap) sends a GTP
@@ -390,7 +390,7 @@ In the DU in DL, assuming the GTP-U tunnel exists, GTP decapsulates the packet
 and calls the reception call back `nr_rlc_data_req()`, which enqueues the
 packet into the UE's RLC buffer.
 
-## Tunnel Setup
+### Tunnel Setup
 
 In GTP-U, TS 29.281 specifies a optional header (NR RAN Container). This
 extension header may be transmitted in a G-PDU over the X2-U, Xn-U and F1-U user

doc/F1AP/F1AP-lib.md

@@ -2,7 +2,7 @@
   <tr style="border-collapse: collapse; border: none;">
     <td style="border-collapse: collapse; border: none;">
       <a href="http://www.openairinterface.org/">
-         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
+         <img src="../images/oai_final_logo.png" alt="" border=3 height=50 width=150>
          </img>
       </a>
     </td>

doc/FEATURE_SET.md

@@ -11,12 +11,12 @@
 -  FAPI (IF2)  : specified by Small Cell Forum (open-nFAPI implementation)
 -  IF1         : F1 in 3GPP Release 15
 
-![Functional Split Architecture](./oai_enb_func_split_arch.png)
+![Functional Split Architecture](./images/oai_enb_func_split_arch.png)
 
 
 # OpenAirInterface Block Diagram #
 
-![Block Diagram](./oai_enb_block_diagram.png)
+![Block Diagram](./images/oai_enb_block_diagram.png)
 
 # OpenAirInterface 5G-NR Feature Set #
 
@@ -25,7 +25,7 @@
 The following features are valid for the gNB and the 5G-NR UE.
 
 *  Static TDD
-   - Multi TDD pattern supported refer [TDD Configuration](NR_SA_Multi_TDD_Pattern.md)
+   - Multi TDD pattern supported refer [TDD Configuration](MAC/mac-usage.md)
 *  Static FDD
 *  Normal CP
 *  Subcarrier spacings: 15 and 30kHz (FR1), 120kHz (FR2)

doc/MAC/mac-usage.md

@@ -183,7 +183,7 @@ See [nFAPI documentation](../nfapi.md) or [Aerial
 tutorial](../Aerial_FAPI_Split_Tutorial.md) for information about the (n)FAPI
 split.
 
-See [F1 documentation](../F1-design.md) for information about the F1 split.
+See [F1 documentation](../F1AP/F1-design.md) for information about the F1 split.
 
 ## MAC scheduler-related configuration options
 

doc/README.md

@@ -52,7 +52,7 @@ There is some general information in the [OpenAirInterface Gitlab Wiki](https://
   * 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_GNB_W_COTS_UE.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_
 - [How to use the L2 simulator](./L2NFAPI.md)
 - [How to use the OAI channel simulator](../openair1/SIMULATION/TOOLS/DOC/channel_simulation.md)
@@ -60,7 +60,7 @@ There is some general information in the [OpenAirInterface Gitlab Wiki](https://
 - [How to run OAI-VNF and OAI-PNF](./nfapi.md): how to run the FAPI/nFAPI split,
   including some general remarks on FAPI/nFAPI.
 - [How to use the positioning reference signal (PRS)](./RUN_NR_PRS.md)
-- [How to use device-to-device communication (D2D, 4G)](./d2d_emulator_setup.txt)
+- [How to use device-to-device communication (D2D, 4G)](./d2d_emulator_setup.md)
 - [How to run with E2 agent](../openair2/E2AP/README.md)
 - [How to run the physical simulators](./physical-simulators.md)
 - [How to setup OAI with Nvidia Aerial and Foxconn](./Aerial_FAPI_Split_Tutorial.md)
@@ -71,8 +71,6 @@ There is some general information in the [OpenAirInterface Gitlab Wiki](https://
 Legacy unmaintained files:
 - [`L2NFAPI_NOS1.md`](./L2NFAPI_NOS1.md), [`L2NFAPI_S1.md`](./L2NFAPI_S1.md):
   old L2simulator, not valid anymore
-- [`SystemX-tutorial-design.md`](./SystemX-tutorial-design.md): old, high-level
-  documentation
 - [`UL_MIMO.txt`](./UL_MIMO.txt): UL-MIMO specific notes
 
 # Designs

doc/RRC/rrc-usage.md

@@ -12,7 +12,7 @@ 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
 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](../F1-design.md) and [E1AP page](../E1AP/E1-design.md).
+respective [F1AP page](../F1AP/F1-design.md) and [E1AP page](../E1AP/E1-design.md).
 
 # Periodic output and interpretation
 
@@ -57,7 +57,7 @@ As of now, it does not print information about connected CU-UPs or AMFs.
 
 ## Split-related options (when running in a CU or CU-CP)
 
-See [F1 documentation](../F1-design.md) for information about the F1 split.
+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

doc/SystemX-tutorial-design.md

-# OpenAirInterface for SystemX
-
-# Terminology
-
-****This document use the 5G terminology****
-
-**Central Unit (CU):** It is a logical node that includes the gNB
-functions like Transfer of user data, Mobility control, Radio access
-network sharing, Positioning, Session Management etc., except those
-functions allocated exclusively to the DU. CU controls the operation of
-DUs over front-haul (Fs) interface. A central unit (CU) may also be
-known as BBU/REC/RCC/C-RAN/V-RAN/VNF
-
-**Distributed Unit (DU):** This logical node includes a subset of the
-gNB functions, depending on the functional split option. Its operation
-is controlled by the CU. Distributed Unit (DU) also known with other
-names like RRH/RRU/RE/RU/PNF.
-
-In OpenAir code, the terminology is often RU and BBU.
-
-# OpenAirUsage
-
-## EPC and general environment
-
-### OAI EPC
-
-Use the stable OAI EPC, that can run in one machine (VM or standalone)
-
-Draft description:
-<https://open-cells.com/index.php/2017/08/22/all-in-one-openairinterface-august-22nd/>
-
-## Standalone 4G
-
-EPC+eNB on one machine, the UE can be commercial or OAI UE.
-
-### USRP B210
-
-Main current issue: traffic is good only on coaxial link between UE and
-eNB (probably power management issue).
-
-### Simulated RF
-
-Running eNB+UE both OAI can be done over a virtual RF link.
-
-The UE current status is that threads synchronization is implicit in
-some cases. As the RF simulator is very quick, a “sleep()” is required
-in the UE main loop
-
-(line 1744, targets/RT/USER/lte-ue.c).
-
-Running also the UE in the same machine is possible with simulated RF.
-
-Running in same machine is simpler, offers about infinite speed for
-virtual RF samples transmission.
-
-A specific configuration is required because the EPC Sgi interface has
-the same IP tunnel end point as the UE.
-
-So, we have to create a network namespace for the UE and to route data
-in/out of the namespace.
-
-```bash
-ip netns delete aNameSpace 2&gt; /dev/null
-
-ip link delete v-eth1 2&gt; /dev/null
-
-ip netns add aNameSpace
-
-ip link add v-eth1 type veth peer name v-peer1
-
-ip link set v-peer1 netns aNameSpace
-
-ip addr add 10.200.1.1/24 dev v-eth1
-
-ip link set v-eth1 up
-
-iptables -t nat -A POSTROUTING -s 10.200.1.0/255.255.255.0 -o enp0s31f6 \
--j MASQUERADE
-
-iptables -A FORWARD -i enp0s31f6 -o v-eth1 -j ACCEPT
-
-iptables -A FORWARD -o enp0s31f6 -i v-eth1 -j ACCEPT
-
-ip netns exec aNameSpace ip link set dev lo up
-
-ip netns exec aNameSpace ip addr add 10.200.1.2/24 dev v-peer1
-
-ip netns exec aNameSpace ip link set v-peer1 up
-
-ip netns exec aNameSpace bash
-```
-
-After the last command, the Linux shell is in the new namespace, ready
-to run the UE.
-
-To make user plan traffic, the traffic generator has to run in the same
-namespace
-
-```bash
-ip netns exec aNameSpace bash
-```
-
-The traffic genenrator has to specify the interface:
-
-```bash
-route add default oaitun_ue1
-```
-
-or specify the outgoing route in the traffic generator (like option “-I”
-in ping command).
-
-## 5G and F1
-
-Today 5G achievement is limited to physical layer.
-
-The available modulation is 40MHz, that require one X310 or N300 for the
-gNB and a X310 or N300 for the nrUE.
-
-### Usage with X310
-
-Linux configuration:
-<https://files.ettus.com/manual/page_usrp_x3x0_config.html>
-
-We included most of this configuration included in OAI source code.
-
-Remain to set the NIC (network interface card) MTU to 9000 (jumbo
-frames).
-
-### Running 5G
-
-Usage with RFsimulator:
-
-**gNB**
-
-```bash
-sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band78.tm1.106PRB.usrpn300.conf
-```
-
-**nrUE**
-
-```bash
-sudo ./nr-uesoftmodem --numerology 1 -r 106 -C 3510000000 -d --rfsimulator.serveraddr 127.0.0.1
-```

doc/TESTING_GNB_W_COTS_UE.md → doc/TESTING_OAI_NSA_COTS_UE.md

@@ -7,12 +7,12 @@ STATUS 2020/10/15 : added External Resources section and links
 ## External Resources
 
 Additional Resources to this page can be found here (special mention to Walter Maguire <wmaguire@live.com>) :  
-https://docs.google.com/document/d/1pL8Szm0ocGxdl5ESVp12Ff71a4PbhCb9SpvbLZzwYbo/edit?usp=sharing  
+[Additional Notes Supporting the OAI COTS NSA](https://docs.google.com/document/d/1pL8Szm0ocGxdl5ESVp12Ff71a4PbhCb9SpvbLZzwYbo/edit?usp=sharing)
 At time of writing, the openairinterface5G Commit Tag is 2020.w39
 
 
 Faraday Cages can be found here :  
-http://www.saelig.com/MFR00066/ste2300.htm
+[Faraday Cage](http://www.saelig.com/MFR00066/ste2300.htm)
 
 
 ## Configuration Overview
@@ -37,32 +37,32 @@ Our code might not work with all 5G phones yet, but we are constantly improving
 *  Simcom SIMCOM8200EA 
 *  Quectel RM500Q-GL
 
-Note1: In the version we have at Eurecom, you need to set the PLMN to 50501, and you also need to change the firmware to "11.0.0 (RD1A.201105.003.B1, Nov 2020, EU carriers)" (see https://developers.google.com/android/images)
+Note1: In the version we have at Eurecom, you need to set the PLMN to 50501, and you also need to change the firmware to "11.0.0 (RD1A.201105.003.B1, Nov 2020, EU carriers)" (see [Factory Images for Nexus and Pixel Devices](https://developers.google.com/android/images))
 
 ## Repository
 
-https://gitlab.eurecom.fr/oai/openairinterface5g/tree/develop
+[OAI](https://gitlab.eurecom.fr/oai/openairinterface5g/tree/develop)
 
 ## Architecture Setup
 
 The scheme below depicts our typical setup:
 
-![image info](./testing_gnb_w_cots_ue_resources/oai_fr1_setup.jpg)
+![image info](./images/oai_fr1_setup.jpg)
 
 The photo depicts the FR1 setup part of the scheme above:  
 
 
-![image info](./testing_gnb_w_cots_ue_resources/oai_fr1_lab.jpg)
+![image info](./images/oai_fr1_lab.jpg)
 
 ## Build and Install
 
 General guidelines to build eNB and gNB :
-See https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/doc/BUILD.md#building-ues-enodeb-and-gnodeb-executables
+See [Building UE, eNB and gNb executables](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/doc/BUILD.md#building-ues-enodeb-and-gnodeb-executables)
 
 
 - **eNB**
 
-```
+```bash
 cd <your oai installation directory>/openairinterface5g/
 source oaienv
 cd cmake_targets/
@@ -72,7 +72,7 @@ cd cmake_targets/
 
 - **gNB**
 
-```
+```bash
 cd <your oai installation directory>/openairinterface5g/
 source oaienv
 cd cmake_targets/
@@ -83,8 +83,7 @@ cd cmake_targets/
 - **EPC**
 
 for reference:
-https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME.md
-
+[DEPLOY_HOME_MAGMA_MME](https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME_MAGMA_MME.md)
 
 
 ## Configuration Files
@@ -93,15 +92,17 @@ Each component (EPC, eNB, gNB) has its own configuration file.
 These config files are passed as arguments of the run command line, using the option -O \<conf file\>
 
 The **REFERENCE** files for eNB and gNB, **used by the CI**, can be found here:  
-[enb conf file](../ci-scripts/conf_files/enb.band7.tm1.fr1.25PRB.usrpb210.conf)
-[gnb conf file](../ci-scripts/conf_files/gnb.band78.tm1.fr1.106PRB.usrpb210.conf)
+* [enb conf file](../ci-scripts/conf_files/enb.band7.25prb.usrpb200.tm1.conf)
+* [gnb conf file](../ci-scripts/conf_files/gnb-du.sa.band78.106prb.usrpb200.conf)
 
 These files have to be updated manually to set the IP addresses and frequency.  
 
-
-**ATTENTION** : an **EXTERNAL** clock is used to sync the eNB and gNB,  
-whether the clock is internal or external is defined in the configuration files (!! details needed !!)   
-
+---
+>**⚠️ ATTENTION ⚠️**
+>
+>An **EXTERNAL** clock is used to sync the eNB and gNB, whether the clock is internal or external is defined in the configuration files (!! details needed !!)   
+>
+---
 
 1- In the **eNB configuration file** :
 - look for MME IP address, and update the **ipv4 field** with the IP address of the **EPC** server
@@ -198,14 +199,13 @@ The test takes typically a few seconds, max 10-15 seconds. If it takes more than
 - **EPC** (on EPC host):
 
 for reference:
-https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME.md
-
+[DEPLOY_HOME_MAGMA_MME](https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME_MAGMA_MME.md)
 
 
 - **eNB** (on the eNB host):
 
 Execute: 
-```
+```bash
 ~/openairinterface5g/cmake_targets/ran_build/build$ sudo ./lte-softmodem -O **YOUR_ENB_CONF_FILE** | tee **YOUR_LOG_FILE**
 
 ```
@@ -213,13 +213,16 @@ Execute:
 
 - **gNB** (on the gNB host)
 
-
-**ATTENTION** : for the gNB execution,    
-The **-E** option is required to enable the tri-quarter sampling rate when using a B2xx serie USRP  
-The **-E** option is **NOT supported** when using a a N300 USRP  
+---
+>**⚠️ ATTENTION ⚠️**
+>
+> For the gNB execution:    
+> - The **-E** option is required to enable the tri-quarter sampling rate when using a B2xx serie USRP  
+> - The **-E** option is **NOT supported** when using a a N300 USRP  
+---
 
 Execute: 
-```
+```bash
 ~/openairinterface5g/cmake_targets/ran_build/build$ sudo ./nr-softmodem -O **YOUR_GNB_CONF_FILE** -E --nsa | tee **YOUR_LOG_FILE**
 
 ```
@@ -229,9 +232,9 @@ Execute:
 
 The test case corresponds to the UE attachement, that is the UE connection and its initial access in 5G, as depicted below:
 
-**Source** : https://www.sharetechnote.com/html/5G/5G_LTE_Interworking.html  
+**Source** : [5G/LTE interworking](https://www.sharetechnote.com/html/5G/5G_LTE_Interworking.html )
 
-![image info](./testing_gnb_w_cots_ue_resources/attach_signaling_scheme.jpg)
+![image info](./images/attach_signaling_scheme.jpg)
 
 The test reaches step **12. E-RAB modifcation confirmation** , eventhough not all the messages will appear in the log file. 
 
@@ -239,8 +242,8 @@ The test reaches step **12. E-RAB modifcation confirmation** , eventhough not al
 
 From the log file that is generated, we can monitor several important steps, to assess that the test was successful.  
 Log files examples can be found here:  
-[enb log file](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/rh_doc_update_3/doc/testing_gnb_w_cots_ue_resources/oai_enb.log)  
-[gnb log file](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/rh_doc_update_3/doc/testing_gnb_w_cots_ue_resources/oai_gnb.log)
+* [enb log file](./testing_oai_nsa_w_cots_ue_resources/oai_enb.log)  
+* [gnb log file](./testing_oai_nsa_w_cots_ue_resources/oai_gnb.log)
 
 
 - eNB receives UE capabilities information, including its NR capabilites, and triggers sGNB Addition Request message:

doc/UL_MIMO.md

+# UpLink Multiple Input Multiple Output (UL MIMO)
+## What is UL MIMO ?
+
+UpLink MIMO refers to the use of multiple antennas at both the UE (User Equipment) as transmitter and the base station as receiver. They are used to send multiple data streams simultaneously from the user to the network.
+
+## How to use it ?
+
+## Step 1: build phy sim
+
+```bash
+cd cmake_targets/
+sudo ./build_oai --phy_simulators -c
+cd phy_simulators/build/
+```
+
+## Step 2: Use the sim
+
+### Option 1: launch ULSCH sim  
+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 |
+
+
+```bash
+sudo ./nr_ulschsim -R 106 -m9 -s13 -n100 -y4 -z4 -W4
+```
+
+### Option 2: launch UL sim
+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
+- No cross-path connection, which means no signal leakage or interference are present
+- PMI = 0  is only unitary precoding matrix
+
+The same parameters are used.
+
+```bash
+sudo ./nr_ulsim -n100 -m9 -r106 -s13 -W4 -y4 -z4   
+```
+### Option 3: Use RFSIM
+
+#### Build
+
+RF simulator allows to test OAI without an RF board. It replaces an actual RF board driver.
+
+```bash
+sudo ./build_oai -c --gNB --nrUE -w SIMU
+```
+
+#### Run
+##### 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 |
+
+```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
+sudo ./nr-uesoftmodem  --rfsim --phy-test --ue-nb-ant-rx 4 --ue-nb-ant-tx 4
+```
+
+##### 4x4 RANK 2
+
+The same parameters are used excepted uplink number of layers set to 2.
+
+```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 2
+sudo ./nr-uesoftmodem  --rfsim --phy-test --ue-nb-ant-rx 4 --ue-nb-ant-tx 4
+```
+
+

doc/UL_MIMO.txt

-# how to build phy sim
-cd cmake_targets/
-sudo ./build_oai --phy_simulators -c
-
-cd phy_simulators/build/
-# ULSCH sim  
-# bit level validation                   
-# PUSCH encoding and decoding for 4 layers   2 CMD without data
-sudo ./nr_ulschsim -R 106 -m9 -s13 -n100 -y4 -z4 -W4
-
-# UL sim
-# Uplink chain validation  
-# PUSCH on UE side and gNB side,whole chain for PUSCH
-# No channel model on data domain signal
-# No cross-path connection
-# PMI = 0  is only unitary prcoding matrix
-sudo ./nr_ulsim -n100 -m9 -r106 -s13 -W4 -y4 -z4   
-
-# How to build rfsim
-sudo ./build_oai -c --gNB --nrUE -w SIMU
-
-# How to run with rfsim
-# 4x4 RANK 4
-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
-sudo ./nr-uesoftmodem  --rfsim --phy-test --ue-nb-ant-rx 4 --ue-nb-ant-tx 4
-# 4x4 RANK 2
-sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.4layer.conf --rfsim --phy-test --l 2  --L 2
-sudo ./nr-uesoftmodem  --rfsim --phy-test --ue-nb-ant-rx 4 --ue-nb-ant-tx 4
-
-
-

doc/d2d_emulator_setup.md

+# How to use device-to-device communication (D2D, 4G)
+
+---
+>**⚠️ ATTENTION ⚠️**
+> 
+>D2D is currently unfinished, the following documentation steps are likely not enough to make it work.
+---
+
+## Scenario 1 : **Off-network UE2UE link**
+SynchREF UE (UE1)
+
+```mermaid
+graph LR
+    UE1[UE1<br/>eth0: 10.10.10.1] --- UE2[UE2<br/>eno1: 10.10.10.2]
+```
+
+### Example of /etc/network/interfaces configuration for UE1
+```text
+auto eth0 
+   iface eth0 inet static 
+   address 10.10.10.1 
+   netmask 255.255.255.0 
+   gateway 10.10.10.1 
+```
+
+### Prepare the environment:
+```bash
+git clone https://gitlab.eurecom.fr/matzakos/LTE-D2D.git
+cd LTE-D2D
+git checkout master
+```  
+
+This branch contains all the current development for **DDPS**, including:
+ - **UE MAC <-> UE MAC** for **Scenario 1** (off-network communication)
+ - **eNB MAC <-> UE MAC** using **NFAPI Transport** (on-network communication)
+ - **RRC Extensions** to support on-network cases
+ 
+### NFAPI configuration (required even for Scenario 1 target)
+```bash
+git clone https://github.com/cisco/open-nFAPI.git
+cd open-nfapi
+patch -p1 --dry-run < $OPENAIR_HOME/open-nfapi.oai.patch
+```
+Validate that there are no errors: 
+
+```patch -p1 < $OPENAIR_HOME/open-nfapi.oai.patch```
+ 
+### OAI build/execute
+```bash
+export NFAPI_DIR=XXX (place where NFAPI was installed)
+cd cmake_targets
+./build_oai --UE --ninja #If necessary, use ./build_oai -I --UE to install required packages
+cd ran_build/build/
+```
+
+### UE1
+``` bash
+sudo ifconfig oip0 10.0.0.1
+sudo iptables -A POSTROUTING  -t mangle -o oip0 -d 224.0.0.3 -j MARK --set-mark 3
+```
+---
+>**NOTE**
+>
+>If necessary, add a default gateway: 
+>
+>```sudo route add default gw 10.10.10.1 eth0```
+---
+
+
+### UE2
+```bash
+sudo ifconfig oip0 10.0.0.2
+sudo iptables -A POSTROUTING  -t mangle -o oip0 -d 224.0.0.3 -j MARK --set-mark 3
+```
+---
+>**NOTE**
+>
+>If necessary, add a default gateway: 
+>
+>```sudo route add default gw 10.10.10.1 eno1```
+---
+
+
+### UE1 and UE2: Get and build `vencore_app` from `d2d-l3-stub` (branch: `l3_stub`)
+```bash
+gcc -I . vencore_app.c -o vencore_app -lpthread
+```
+ 
+
+## TEST ONE-TO-MANY
+
+### Run UE1 then UE2, for example:
+- UE1: 
+```bash
+sudo ./lte-softmodem-stub -U --emul-iface eth0
+```
+- UE2: 
+```bash
+sudo ./lte-softmodem-stub -U --emul-iface eno1
+```
+
+### Test with Ping
+- Sender - UE1: 
+```bash
+ping -I oip0 224.0.0.3
+```
+- Receiver - UE2: *using wireshark*
+
+### Test with Iperf
+- Sender - UE1: 
+```bash
+iperf -c 224.0.0.3 -u -b 0.1M --bind 10.0.0.1 -t 100
+```
+
+- Receiver - UE2: 
+```bash
+sudo ./mcreceive 224.0.0.3 5001
+``` 
+
+Filter the incoming packets according to GroupL2Id: receiver (one-to-many) can discard the packets if it doesn't belong to this group. 
+For the moment, both sender and receiver use the same set of Ids (hardcoded)  
+
+- UE1 (sender):
+  ```bash
+  sudo ./lte-softmodem-stub -U --emul-iface eth0
+  ./vencore_app  #send the sourceL2Id, groupL2Id to OAI
+  ping -I oip0 224.0.0.3
+  ```
+
+- UE2(receiver)
+  ```bash
+  sudo ./lte-softmodem-stub -U --emul-iface eno1 
+  #we can see the incomming packets from OAI log, however, cannot see from Wireshark -> they are discarded at MAC layer
+  ./vencore_app  #we can see the packets appearing in Wireshark
+  ```
+
+
+## TEST PC5-S (UE1 -sender, UE2 - receiver) and PC5-U for ONE-TO-ONE scenario
+### Configure UE1/UE2
+
+Configure ports and routing table for UE1 and UE2
+
+**UE1:** 
+  ```bash
+  sudo ifconfig oip0 10.0.0.1
+  sudo iptables -A POSTROUTING  -t mangle -o oip0 -d 10.0.0.2 -j MARK --set-mark 3
+  sudo route add default gw 10.10.10.1 eth0
+  ```
+**UE2:**
+  ```bash
+  sudo ifconfig oip0 10.0.0.2
+  sudo iptables -A POSTROUTING  -t mangle -o oip0 -d 10.0.0.1 -j MARK --set-mark 3
+  sudo route add default gw 10.10.10.1 eno1
+  ```
+  
+#### Step 1:
+Run the traffic emulated over Ethernet on UE1 using lte-softmodem-stub to test the behaviour without RF board.
+
+**UE1:**
+```bash
+sudo ./lte-softmodem-stub -U --emul-iface eth0
+```
+
+#### Step 2:
+Run the traffic emulated over Ethernet on UE2 and set it as listening to incoming messages from PC5-S
+
+**UE2:** 
+```bash
+sudo ./lte-softmodem-stub -U --emul-iface eno1
+./vencore_app -r #listen to incomming message from PC5-S
+``` 
+
+#### Step 3: 
+Send a message from UE1 to UE2
+
+**UE1:** 
+```bash
+./vencore_app -s #send a message via PC5-S (e.g., DirectCommunicationRequest)
+```
+
+#### Generate unicast traffic
+**UE1:**
+```bash
+ping -I oip0 10.0.0.2
+```
+ 
+ 
+## TEST PC5-D
+
+#### Step 1:
+Run the traffic emulated over Ethernet on UE1 and send a discovery message via PC5-D 
+
+**UE1:**
+```bash
+sudo ./lte-softmodem-stub -U --emul-iface eth0
+./vencore_app -d #send a PC5-Discovery-Announcement via PC5D
+```
+
+#### Step 2:
+Run the traffic emulated over Ethernet on UE2 and send a discovery message via PC5-D
+
+**UE2:** 
+```bash
+sudo ./lte-softmodem-stub -U --emul-iface eno1
+./vencore_app -d #send a PC5-Discovery-Announcement via PC5D
+```
+

doc/d2d_emulator_setup.txt

-Scenario 1 : Off-network UE2UE link
-SynchREF UE (UE1)
-
-UE1(eth0 - 10.10.10.1)--------UE2(eno1 - 10.10.10.2)
-
-Here's an example of /etc/network/interfaces configuration for UE1
-auto eth0
-   iface eth0 inet static
-   address 10.10.10.1
-   netmask 255.255.255.0
-   gateway 10.10.10.1
-
-Prepare the environment:
- - git clone https://gitlab.eurecom.fr/matzakos/LTE-D2D.git  #branch: master
-This branch contains all the current development for DDPS
- - UE MAC<-> UE MAC for Scenario 1
- - eNB MAC<->UE MAC (NFAPI Transport)
- - RRC Extensions for “on-network” cases
- 
-NFAPI configuration (required even for Scenario 1 target)
- - git clone https://github.com/cisco/open-nFAPI.git
- - cd open-nfapi
- - patch -p1 --dry-run < $OPENAIR_HOME/open-nfapi.oai.patch
-Validate that there are no errors
- - patch -p1 < $OPENAIR_HOME/open-nfapi.oai.patch
- 
-OAI build/execute
- - export NFAPI_DIR=XXX (place where NFAPI was installed)
- - cd cmake_targets
- - ./build_oai --UE --ninja
- (if necessary, use ./build_oai -I --UE to install required packages)
- - cd ran_build/build/
-
-UE1: 
- - sudo ifconfig oip0 10.0.0.1
- - sudo iptables -A POSTROUTING  -t mangle -o oip0 -d 224.0.0.3 -j MARK --set-mark 3
- - (if necessary) sudo route add default gw 10.10.10.1 eth0
-UE2:
- - sudo ifconfig oip0 10.0.0.2
- - sudo iptables -A POSTROUTING  -t mangle -o oip0 -d 224.0.0.3 -j MARK --set-mark 3
- - (if necessary) sudo route add default gw 10.10.10.1 eno1
-
-UE1 and UE2: Get and build vencore_app from d2d-l3-stub (branch: l3_stub)
- - gcc -I . vencore_app.c -o vencore_app -lpthread
- 
---------------------------------
-TEST ONE-TO-MANY
-Run UE1 then UE2, for example:
-UE1: sudo ./lte-softmodem-stub -U --emul-iface eth0
-UE2: sudo ./lte-softmodem-stub -U --emul-iface eno1
-
-Test with Ping
-- Sender - UE1: ping -I oip0 224.0.0.3
-- Receiver - UE2: using wireshark
-
-Test with Iperf
-- Sender - UE1: iperf -c 224.0.0.3 -u -b 0.1M --bind 10.0.0.1 -t 100
-- Receiver - UE2: sudo ./mcreceive 224.0.0.3 5001 
-
-Filter the incomming packets according to GroupL2Id: receiver (one-to-many) can discard the packets if it doesn't belong to this group. 
-For the moment, both sender and receiver use the same set of Ids (hardcoded)  
-
-UE1 (sender)
- - sudo ./lte-softmodem-stub -U --emul-iface eth0
- - ./vencore_app  #send the sourceL2Id, groupL2Id to OAI
- - ping -I oip0 224.0.0.3
- UE2(receiver)
-  - sudo ./lte-softmodem-stub -U --emul-iface eno1 
-  #we can see the incomming packets from OAI log, however, cannot see from Wireshark -> they are discarded at MAC layer
-  - ./vencore_app  #we can see the packets appearing in Wireshark
- 
- --------------------------------------
-TEST PC5-S (UE1 -sender, UE2 - receiver) and PC5-U for ONE-TO-ONE scenario
-Configure UE1/UE2
-UE1: 
- - sudo ifconfig oip0 10.0.0.1
- - sudo iptables -A POSTROUTING  -t mangle -o oip0 -d 10.0.0.2 -j MARK --set-mark 3
- - sudo route add default gw 10.10.10.1 eth0
-UE2:
- - sudo ifconfig oip0 10.0.0.2
- - sudo iptables -A POSTROUTING  -t mangle -o oip0 -d 10.0.0.1 -j MARK --set-mark 3
- - sudo route add default gw 10.10.10.1 eno1
- 
-step 1:
-- UE1: sudo ./lte-softmodem-stub -U --emul-iface eth0
-step 2:
-- UE2: sudo ./lte-softmodem-stub -U --emul-iface eno1
-- UE2: ./vencore_app -r #listen to incomming message from PC5-S 
-step 3: 
-- UE1: ./vencore_app -s #send a message via PC5-S (e.g., DirectCommunicationRequest)
-
-Generate unicast traffic
-UE1: ping -I oip0 10.0.0.2
- 
- 
-  --------------------------------------
-TEST PC5-D
-step 1:
-- UE1: sudo ./lte-softmodem-stub -U --emul-iface eth0
-- UE1: ./vencore_app -d #send a PC5-Discovery-Announcement via PC5D
-step 2:
-- UE2: sudo ./lte-softmodem-stub -U --emul-iface eno1
-- UE2: ./vencore_app -d #send a PC5-Discovery-Announcement via PC5D
-

doc/environment-variables.md

@@ -3,14 +3,13 @@
 OAI uses/supports a number of environment variables, documented in the following:
 
 - `NFAPI_TRACE_LEVEL`: set the nfapi custom logging framework's log level; can be one of `error`, `warn`, `note`, `info`, `debug`. Default is `warn`.
-- `NR_AWGN_RESULTS_DIR`: directory containing BLER curves for L2simulator channel modelling in SISO case
-- `NR_MIMO2x2_AWGN_RESULTS_DIR`: directory containing BLER curves for L2simulator channel modelling in 2x2 MIMO case
+- `NR_AWGN_RESULTS_DIR`: directory containing BLER curves for NR L2simulator channel modelling in SISO case
+- `NR_MIMO2x2_AWGN_RESULTS_DIR`: directory containing BLER curves for NR L2simulator channel modelling in 2x2 MIMO case
+- `OPENAIR_DIR`: should point to the root directory of OpenAirInterface; BLER curves for LTE L2sim channel emulation 
 - `NVRAM_DIR`: directory to read/write NVRAM data in (5G) `nvram` tool; if not defined, will use `PWD` (working directory)
 - `OAI_CONFIGMODULE`: can be used to pass the configuration file instead of `-O`
 - `OAI_GDBSTACKS`: if defined when hitting an assertion (`DevAssert()`, `AssertFatal()`, ...), OAI will load `gdb` and provide a backtrace for every thread
 - `OAI_RNGSEED`: overwrites any seed for random number generators (RNG) in simulators
-- `OAI_THREADPOOLMEASUREMENTS`: path to a file to store thread pool debugging information, see the [thread pool documentation](..common/utils/threadPool/thread-pool.md)
-- `OPENAIR_DIR`: should point to the root directory of OpenAirInterface; some code relies on this to get a filename, e.g., BLER curves for L2sim channel emulation
 - `USIM_DIR`: directory to read/write USIM data in (4G) `usim` tool; if not defined, will use `PWD` (working directory)
 
 Furthermore, these variables appear in code that is not maintained and maybe not even compiled anywhere:
@@ -19,3 +18,5 @@ Furthermore, these variables appear in code that is not maintained and maybe not
 - `SSH_CLIENT`: alternative host to connect to, for CLI, if `REMADDR` is not defined
 - `USER`: user name in the command-line interface
 - `rftestInputFile`: input file for the `calibration_test` tool
+- `OPENAIR2_DIR` : OMV and OMG modules, obsolete
+- `TITLE`: OTG module, obsolete

doc/nr-ue-design.md

@@ -15,7 +15,7 @@ The UE exits when at any point in operation it gets out of synchronization. When
 
 UE uses actors which are threads dedicated to particular activity. Sync Actor handles initial sync. DL Actors handle DLSCH PHY procedures. UL procedures are are run on the UL Actor
 
-![design](nr-ue-threads.svg)
+![design](images/nr-ue-threads.svg)
 
 ## Initial Synchronization Block
 ```mermaid

radio/rfsimulator/simulator.c

@@ -358,14 +358,6 @@ static void rfsimulator_readconfig(rfsimulator_state_t *rfsimulator) {
     }
   }
 
-  /* for compatibility keep environment variable usage */
-  if (getenv("RFSIMULATOR") != NULL) {
-    rfsimulator->ip = getenv("RFSIMULATOR");
-    LOG_W(HW, "The RFSIMULATOR environment variable is deprecated and support will be removed in the future. Instead, add parameter --rfsimulator.serveraddr %s to set the server address. Note: the default is \"server\"; for the gNB/eNB, you don't have to set any configuration.\n", rfsimulator->ip);
-    LOG_I(HW, "Remove RFSIMULATOR environment variable to get rid of this message and the sleep.\n");
-    sleep(10);
-  }
-
   if ( strncasecmp(rfsimulator->ip,"enb",3) == 0 ||
        strncasecmp(rfsimulator->ip,"server",3) == 0 )
     rfsimulator->role = SIMU_ROLE_SERVER;