doc(testbench resources): arrange in proper sub-folders and fix corresponding references

- create separate sub-folders for images, pdfs, and tex files
- Fix their respective references in TESTBenches doc

CMakeLists.txt

@@ -19,8 +19,6 @@
 # *      contact@openairinterface.org
 # */
 
-# Author: laurent THOMAS, Lionel GAUTHIER
-
 cmake_minimum_required (VERSION 3.16)
 project (OpenAirInterface LANGUAGES C CXX)
 set(CMAKE_CXX_STANDARD 17)
@@ -173,9 +171,6 @@ else ()
   set(C_FLAGS_PROCESSOR "${C_FLAGS_PROCESSOR} -march=armv8.2-a")
 endif()
 
-# add autotools definitions that were maybe used!
-add_definitions(-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_FCNTL_H=1 -DHAVE_ARPA_INET_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_SOCKET_H=1 -DHAVE_STRERROR=1 -DHAVE_SOCKET=1 -DHAVE_MEMSET=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -DHAVE_LIBSCTP)
-
 # we need -rdynamic to incorporate all symbols in shared objects, see man page
 set(commonOpts "-pipe -fPIC -Wall -fno-strict-aliasing -rdynamic")
 # GNU C/C++ Compiler might throw many warnings without packed-bitfield-compat, see man page
@@ -469,9 +464,6 @@ target_include_directories(f1ap PUBLIC F1AP_DIR)
 target_link_libraries(f1ap PUBLIC asn1_f1ap GTPV1U)
 target_link_libraries(f1ap PRIVATE ngap nr_rrc HASHTABLE f1ap_lib)
 target_include_directories(f1ap PRIVATE ${F1AP_DIR}/lib)
-if(E2_AGENT)
-  target_compile_definitions(f1ap PRIVATE E2_AGENT)
-endif()
 
 # LPP
 ##############
@@ -549,7 +541,6 @@ include_directories(${CMAKE_CURRENT_BINARY_DIR})
 include_directories("${OPENAIR_DIR}/executables")
 include_directories("${OPENAIR2_DIR}/COMMON")
 include_directories("${OPENAIR2_DIR}/UTIL")
-include_directories("${OPENAIR2_DIR}/UTIL/LOG")
 include_directories("${OPENAIR3_DIR}/COMMON")
 include_directories("${OPENAIR3_DIR}/UTILS")
 include_directories("${NFAPI_DIR}/nfapi/public_inc")
@@ -590,12 +581,7 @@ include_directories("${OPENAIR3_DIR}/ocp-gtpu")
 include_directories("${OPENAIR3_DIR}/M3AP")
 include_directories("${OPENAIR3_DIR}/MME_APP")
 include_directories("${OPENAIR_DIR}/radio/COMMON")
-include_directories("${OPENAIR2_DIR}/UTIL/OSA")
-include_directories("${OPENAIR2_DIR}/UTIL/MEM")
-include_directories("${OPENAIR2_DIR}/UTIL/LISTS")
-include_directories("${OPENAIR2_DIR}/UTIL/FIFO")
 include_directories("${OPENAIR2_DIR}/UTIL/MATH")
-include_directories("${OPENAIR2_DIR}/UTIL/TIMER")
 include_directories("${OPENAIR2_DIR}/UTIL/OTG")
 include_directories("${OPENAIR2_DIR}/UTIL/OPT")
 include_directories("${OPENAIR_DIR}")
@@ -623,11 +609,6 @@ add_library(UTIL
   ${OPENAIR_DIR}/common/utils/LOG/vcd_signal_dumper.c
   ${OPENAIR2_DIR}/UTIL/OPT/probe.c
 )
-if (ENABLE_LTTNG)
-  find_package(LTTngUST 2.3.8 EXACT REQUIRED)
-else()
-  message(STATUS "LTTNG support disabled")
-endif()
 
 pkg_check_modules(cap libcap)
 if (cap_FOUND)
@@ -1318,12 +1299,6 @@ add_library(L2
 target_link_libraries(L2 PRIVATE x2ap s1ap lte_rrc m2ap)
 target_link_libraries(L2 PRIVATE asn1_lte_rrc_hdrs asn1_nr_rrc_hdrs)
 
-if(E2_AGENT)
-  target_link_libraries(L2 PUBLIC e2_agent e2_agent_arg e2_ran_func_du_cucp_cuup)
-  target_compile_definitions(L2 PRIVATE ${E2AP_VERSION} ${KPM_VERSION} E2_AGENT)
-endif()
-
-
 add_library(MAC_UE_NR ${MAC_NR_SRC_UE})
 target_link_libraries(MAC_UE_NR PRIVATE asn1_lte_rrc_hdrs asn1_nr_rrc_hdrs PUBLIC nr_ue_power_procedures nr_ue_ra_procedures)
 
@@ -1350,10 +1325,6 @@ target_link_libraries(L2_NR PRIVATE f1ap x2ap s1ap ngap nr_rrc e1ap nr_rlc nr_co
 if(OAI_AERIAL)
     target_compile_definitions(L2_NR PRIVATE ENABLE_AERIAL)
 endif()
-if(E2_AGENT)
-  target_link_libraries(L2_NR PUBLIC e2_agent e2_agent_arg e2_ran_func_du_cucp_cuup)
-  target_compile_definitions(L2_NR PRIVATE ${E2AP_VERSION} ${KPM_VERSION} E2_AGENT)
-endif()
 
 add_library(L2_LTE_NR
   # temporary solution until 4G/5G code completely untangled (as evidenced by deletion of the following file)
@@ -1683,13 +1654,6 @@ include_directories(${NAS_SRC}UE/EMM/SAP)
 include_directories(${NAS_SRC}UE/ESM)
 include_directories(${NAS_SRC}UE/ESM/SAP)
 
-# nbiot
-add_definitions("-DNUMBER_OF_UE_MAX_NB_IoT=16")
-set (NBIOT_SOURCES
-  ${OPENAIR2_DIR}/ENB_APP/NB_IoT_config.c
-  )
-add_library(NB_IoT MODULE ${NBIOT_SOURCES} )
-
 # Simulation library
 ##########################
 set (SIMUSRC
@@ -1715,9 +1679,8 @@ include_directories("${NFAPI_DIR}/nfapi/inc")
 include_directories("${NFAPI_DIR}/sim_common/inc")
 include_directories("${NFAPI_DIR}/pnf_sim/inc")
 
-add_library(oai_iqplayer MODULE
-	${OPENAIR_DIR}/radio/iqplayer/iqplayer_lib.c
-	)
+add_library(oai_iqplayer MODULE ${OPENAIR_DIR}/radio/iqplayer/iqplayer_lib.c)
+target_link_libraries(oai_iqplayer PRIVATE log_headers)
 
 #################################
 # add executables for operation
@@ -1727,10 +1690,6 @@ add_library(minimal_lib
   )
 target_link_libraries(minimal_lib PUBLIC pthread dl ${T_LIB} LOG)
 
-add_executable(nfapi_test
-  ${OPENAIR_DIR}/openair2/NR_PHY_INTERFACE/nfapi_5g_test.c
-  )
-
 add_executable(measurement_display
   ${OPENAIR_DIR}/common/utils/threadPool/measurement_display.c)
 target_link_libraries (measurement_display minimal_lib)
@@ -1770,6 +1729,7 @@ target_link_libraries(lte-softmodem PRIVATE asn1_nr_rrc_hdrs asn1_lte_rrc_hdrs)
 target_link_libraries(lte-softmodem PRIVATE ${blas_LIBRARIES} ${cblas_LIBRARIES} ${lapacke_LIBRARIES} ${lapack_LIBRARIES})
 
 if(E2_AGENT)
+  target_link_libraries(lte-softmodem PUBLIC e2_agent e2_agent_arg e2_ran_func_du_cucp_cuup)
   target_compile_definitions(lte-softmodem PRIVATE ${E2AP_VERSION} ${KPM_VERSION} E2_AGENT)
 endif()
 
@@ -1873,6 +1833,7 @@ if (OAI_AERIAL)
   target_link_libraries(nr-softmodem PUBLIC aerial_lib)
 endif()
 if(E2_AGENT)
+  target_link_libraries(nr-softmodem PUBLIC e2_agent e2_agent_arg e2_ran_func_du_cucp_cuup)
   target_compile_definitions(nr-softmodem PRIVATE ${E2AP_VERSION} ${KPM_VERSION} E2_AGENT)
 endif()
 
@@ -1947,14 +1908,14 @@ target_link_libraries(nr-uesoftmodem PRIVATE
 #####################################
 
 #special case for dlim TM4, which uses its own version of phy_scope code
-add_executable(dlsim_tm4
-  ${OPENAIR1_DIR}/SIMULATION/LTE_PHY/dlsim_tm4.c
-  ${OPENAIR1_DIR}/PHY/TOOLS/lte_phy_scope_tm4.c
-  )
-target_link_libraries (dlsim_tm4
-  -Wl,--start-group SIMU UTIL SCHED_LIB SCHED_RU_LIB PHY ITTI -Wl,--end-group
-  pthread m rt CONFIG_LIB ${T_LIB}
-  )
+#add_executable(dlsim_tm4
+#  ${OPENAIR1_DIR}/SIMULATION/LTE_PHY/dlsim_tm4.c
+#  ${OPENAIR1_DIR}/PHY/TOOLS/lte_phy_scope_tm4.c
+#  )
+#target_link_libraries (dlsim_tm4
+#  -Wl,--start-group SIMU UTIL SCHED_LIB SCHED_RU_LIB PHY ITTI -Wl,--end-group
+#  pthread m rt CONFIG_LIB ${T_LIB}
+#  )
 
 add_executable(rftest
   ${OPENAIR_DIR}/openair1/PHY/TOOLS/calibration_test.c
@@ -2079,7 +2040,9 @@ target_link_libraries(nr_ulsim PRIVATE
   )
 target_link_libraries(nr_ulsim PRIVATE asn1_nr_rrc_hdrs asn1_lte_rrc_hdrs)
 
-foreach(myExe dlsim dlsim_tm7 ulsim pbchsim scansim mbmssim pdcchsim pucchsim prachsim syncsim)
+# these simulators do not compile:
+# dlsim_tm7 pbchsim scansim mbmssim pdcchsim pucchsim prachsim syncsim
+foreach(myExe dlsim ulsim)
 
   add_executable(${myExe}
     ${OPENAIR1_DIR}/SIMULATION/LTE_PHY/${myExe}.c
@@ -2099,22 +2062,23 @@ endforeach(myExe)
 
 #unitary tests for Core NEtwork pieces
 #################################
-foreach(myExe s1ap
-    secu_knas_encrypt_eia1
-    secu_kenb
-    aes128_ctr
-    secu_knas_encrypt_eea2
-    secu_knas secu_knas_encrypt_eea1
-    kdf
-    aes128_cmac_encrypt
-    secu_knas_encrypt_eia2)
-  add_executable(test_${myExe}
-    ${OPENAIR3_DIR}/TEST/test_${myExe}.c
-    )
-  target_link_libraries (test_${myExe}
-    -Wl,--start-group SECURITY UTIL -Wl,--end-group m rt CONFIG_LIB
-    )
-endforeach(myExe)
+#foreach(myExe
+#    s1ap
+#    secu_knas_encrypt_eia1
+#    secu_kenb
+#    aes128_ctr
+#    secu_knas_encrypt_eea2
+#    secu_knas secu_knas_encrypt_eea1
+#    kdf
+#    aes128_cmac_encrypt
+#    secu_knas_encrypt_eia2)
+#  add_executable(test_${myExe}
+#    ${OPENAIR3_DIR}/TEST/test_${myExe}.c
+#    )
+#  target_link_libraries (test_${myExe}
+#    -Wl,--start-group SECURITY UTIL -Wl,--end-group m rt CONFIG_LIB
+#    )
+#endforeach(myExe)
 
 #ensure that the T header files are generated before targets depending on them
 if (${T_TRACER})
@@ -2124,17 +2088,17 @@ if (${T_TRACER})
         nr-uesoftmodem dlsim dlsim_tm4 dlsim_tm7
         ulsim pbchsim scansim mbmssim pdcchsim pucchsim prachsim
         syncsim nr_ulsim nr_dlsim nr_dlschsim nr_pbchsim nr_pucchsim
-        nr_ulschsim ldpctest polartest smallblocktest cu_test du_test
+        nr_ulschsim ldpctest polartest smallblocktest
         #all "add_library" definitions
         ITTI lte_rrc nr_rrc s1ap x2ap m2ap m3ap f1ap
-        params_libconfig oai_usrpdevif oai_bladerfdevif oai_lmssdrdevif oai_iqplayer
-        oai_eth_transpro oai_mobipass HASHTABLE UTIL OMG_SUMO
-        SECURITY SCHED_LIB SCHED_NR_LIB SCHED_RU_LIB SCHED_UE_LIB SCHED_NR_UE_LIB default_sched remote_sched RAL
+        params_libconfig
+        oai_eth_transpro HASHTABLE UTIL
+        SECURITY SCHED_LIB SCHED_NR_LIB SCHED_RU_LIB SCHED_UE_LIB SCHED_NR_UE_LIB
         NFAPI_LIB NFAPI_PNF_LIB NFAPI_VNF_LIB NFAPI_USER_LIB
         MISC_NFAPI_LTE_LIB MISC_NFAPI_NR_LIB
         PHY_COMMON PHY PHY_UE PHY_NR PHY_NR_COMMON PHY_NR_UE PHY_RU
         L2 L2_LTE L2_NR L2_LTE_NR L2_UE NR_L2_UE MAC_NR_COMMON MAC_UE_NR ngap
-        CN_UTILS GTPV1U SCTP_CLIENT MME_APP LIB_NAS_UE NB_IoT SIMU OPENAIR0_LIB
+        GTPV1U SCTP_CLIENT MME_APP LIB_NAS_UE SIMU
         dfts config_internals nr_common crc_byte)
     if (TARGET ${i})
       add_dependencies(${i} generate_T)
@@ -2142,8 +2106,6 @@ if (${T_TRACER})
   endforeach(i)
 endif (${T_TRACER})
 
-include(${OPENAIR1_DIR}/PHY/CODING/nrLDPC_decoder/nrLDPC_tools/CMakeLists.txt)
-
 set(ENABLE_TESTS OFF CACHE STRING "Activate build of tests")
 set_property(CACHE ENABLE_TESTS PROPERTY TYPE BOOL)
 set(ENABLE_PHYSIM_TESTS OFF CACHE STRING "Activate build of physim tests")

ci-scripts/as_ue/config.cfg

@@ -44,4 +44,4 @@ rf_driver: {
 #endif
 
 tx_gain: 75.0, /* TX gain (in dB) */
-rx_gain: 55.0, /* RX gain (in dB) */
+rx_gain: 52.0, /* RX gain (in dB) */

ci-scripts/conf_files/gnb-du.sa.band78.51prb.usrpb210.ho-pci0.conf

@@ -26,11 +26,11 @@ gNBs =
 
 #  downlinkConfigCommon
     #frequencyInfoDL
-      # 4.01 GHz
-      absoluteFrequencySSB                                          = 629376;
-      dl_frequencyBand                                              = 78;
-      # 4 GHz
-      dl_absoluteFrequencyPointA                                    = 628720;
+      # 4186.56 MHz
+      absoluteFrequencySSB                                          = 679104;
+      dl_frequencyBand                                              = 77;
+      # 4175.82 MHz
+      dl_absoluteFrequencyPointA                                    = 678388;
       #scs-SpecificCarrierList
         dl_offstToCarrier                                           = 0;
 # subcarrierSpacing
@@ -50,7 +50,7 @@ gNBs =
 
   #uplinkConfigCommon
      #frequencyInfoUL
-      ul_frequencyBand                                              = 78;
+      ul_frequencyBand                                              = 77;
       #scs-SpecificCarrierList
       ul_offstToCarrier                                             = 0;
 # subcarrierSpacing
@@ -188,7 +188,7 @@ RUs = (
   nb_rx            = 1
   att_tx           = 0;
   att_rx           = 0;
-  bands            = [78];
+  bands            = [77];
   max_pdschReferenceSignalPower = -27;
   max_rxgain       = 114;
   eNB_instances    = [0];

ci-scripts/conf_files/gnb-du.sa.band78.51prb.usrpb210.ho-pci1.conf

@@ -26,11 +26,11 @@ gNBs =
 
 #  downlinkConfigCommon
     #frequencyInfoDL
-      # 4.01 GHz
-      absoluteFrequencySSB                                          = 629376;
-      dl_frequencyBand                                              = 78;
-      # 4 GHz
-      dl_absoluteFrequencyPointA                                    = 628720;
+      # 4186.56 MHz
+      absoluteFrequencySSB                                          = 679104;
+      dl_frequencyBand                                              = 77;
+      # 4175.82 MHz
+      dl_absoluteFrequencyPointA                                    = 678388;
       #scs-SpecificCarrierList
         dl_offstToCarrier                                           = 0;
 # subcarrierSpacing
@@ -50,7 +50,7 @@ gNBs =
 
   #uplinkConfigCommon
      #frequencyInfoUL
-      ul_frequencyBand                                              = 78;
+      ul_frequencyBand                                              = 77;
       #scs-SpecificCarrierList
       ul_offstToCarrier                                             = 0;
 # subcarrierSpacing
@@ -188,7 +188,7 @@ RUs = (
   nb_rx            = 1
   att_tx           = 0;
   att_rx           = 0;
-  bands            = [78];
+  bands            = [77];
   max_pdschReferenceSignalPower = -27;
   max_rxgain       = 114;
   eNB_instances    = [0];

ci-scripts/conf_files/gnb.sa.band78.106prb.n310.7ds2u.conf

@@ -184,7 +184,7 @@ L1s = (
 {
   num_cc = 1;
   tr_n_preference = "local_mac";
-  prach_dtx_threshold = 130;
+  prach_dtx_threshold = 150;
   #pucch0_dtx_threshold = 150;
 }
 );

ci-scripts/conf_files/neighbour-config-ho.conf

@@ -6,9 +6,9 @@ neighbour_list = (
         gNB_ID = 0xe01;
         nr_cellid = 11111111;
         physical_cellId = 1;
-        absoluteFrequencySSB = 629376;
+        absoluteFrequencySSB = 679104;
         subcarrierSpacing = 1; #30 KHz
-        band = 78;
+        band = 77;
         plmn = { mcc = 001; mnc = 03; mnc_length = 2};
         tracking_area_code = 1;
       }
@@ -21,9 +21,9 @@ neighbour_list = (
         gNB_ID = 0xe00;
         nr_cellid = 12345678;
         physical_cellId = 0;
-        absoluteFrequencySSB = 629376;
+        absoluteFrequencySSB = 679104;
         subcarrierSpacing = 1; #30 KHz
-        band = 78;
+        band = 77;
         plmn = { mcc = 001; mnc = 03; mnc_length = 2};
         tracking_area_code = 1;
       }

ci-scripts/scripts/create_workspace.sh

@@ -22,5 +22,5 @@ git config user.name "OAI Jenkins"
 git config advice.detachedHead false
 mkdir -p cmake_targets/log
 git checkout -f ${ref}
-[ -n "${merge}" ] && git merge --ff ${merge} -m "Temporary merge for CI"
+[ -n "${merge}" ] && git fetch origin ${merge} && git merge --ff FETCH_HEAD -m "Temporary merge for CI"
 exit 0

ci-scripts/scripts/oc-deploy-physims.sh

@@ -15,7 +15,7 @@ oc project ${OC_NS} > /dev/null
 oc tag oaicicd-ran/oai-physim:${IMG_TAG} ${OC_NS}/oai-physim:${IMG_TAG}
 helm install ${OC_RELEASE} ${OAI_DIR}/charts/${OC_RELEASE} --set global.image.version=${IMG_TAG} --wait --timeout 120s
 POD_ID=$(oc get pods | grep oai-${OC_RELEASE} | awk '{print $1}')
-sleep 10
+sleep 30
 echo "Monitoring logs for 'FINISHED' in pod '$POD_ID'"
 oc logs -f -n ${OC_NS} "$POD_ID" | while read -r line; do
   if [[ "$line" == *"FINISHED"* ]]; then

ci-scripts/xml_files/container_5g_rfsim_n2_ho.xml

@@ -31,9 +31,6 @@
  000002
  000003
  020001
- 020002
- 030001
- 030002
  000004
  040001
  050001
@@ -110,7 +107,7 @@
                 <nodes>acamas</nodes>
                 <svr_id>rfsim5g_ue</svr_id>
                 <svr_node>acamas</svr_node>
-                <ping_args>-c 100 -i 0.25</ping_args>
+                <ping_args>-c 50 -i 0.25</ping_args>
                 <ping_packetloss_threshold>5</ping_packetloss_threshold>
         </testCase>
 
@@ -121,7 +118,7 @@
                 <nodes>acamas</nodes>
                 <svr_id>rfsim5g_ext_dn</svr_id>
                 <svr_node>acamas</svr_node>
-                <ping_args>-c 100 -i 0.25</ping_args>
+                <ping_args>-c 50 -i 0.25</ping_args>
                 <ping_packetloss_threshold>10</ping_packetloss_threshold>
         </testCase>
 

ci-scripts/xml_files/container_sa_aw2s_asue.xml

@@ -36,18 +36,6 @@
     102002
     302002
     102003
-    102004
-    102005
-    102006
-    102007
-    102008
-    102009
-    102010
-    102011
-    102012
-    102013
-    102014
-    102015
     100100
     100010
     100020
@@ -118,80 +106,8 @@
 
   <testCase id="102003">
     <class>Attach_UE</class>
-    <desc>Attach UE 3</desc>
-    <id>amarisoft_ue_3</id>
-  </testCase>
-
-  <testCase id="102004">
-    <class>Attach_UE</class>
-    <desc>Attach UE 4</desc>
-    <id>amarisoft_ue_4</id>
-  </testCase>
-
-  <testCase id="102005">
-    <class>Attach_UE</class>
-    <desc>Attach (RedCap) UE 5</desc>
-    <id>amarisoft_ue_5</id>
-  </testCase>
-
-  <testCase id="102006">
-    <class>Attach_UE</class>
-    <desc>Attach (RedCap) UE 6</desc>
-    <id>amarisoft_ue_6</id>
-  </testCase>
-
-  <testCase id="102007">
-    <class>Attach_UE</class>
-    <desc>Attach UE 7</desc>
-    <id>amarisoft_ue_7</id>
-  </testCase>
-
-  <testCase id="102008">
-    <class>Attach_UE</class>
-    <desc>Attach UE 8</desc>
-    <id>amarisoft_ue_8</id>
-  </testCase>
-
-  <testCase id="102009">
-    <class>Attach_UE</class>
-    <desc>Attach UE 9</desc>
-    <id>amarisoft_ue_9</id>
-  </testCase>
-
-  <testCase id="102010">
-    <class>Attach_UE</class>
-    <desc>Attach (RedCap) UE 10</desc>
-    <id>amarisoft_ue_10</id>
-  </testCase>
-
-  <testCase id="102011">
-    <class>Attach_UE</class>
-    <desc>Attach (RedCap) UE 11</desc>
-    <id>amarisoft_ue_11</id>
-  </testCase>
-
-  <testCase id="102012">
-    <class>Attach_UE</class>
-    <desc>Attach (RedCap) UE 12</desc>
-    <id>amarisoft_ue_12</id>
-  </testCase>
-
-  <testCase id="102013">
-    <class>Attach_UE</class>
-    <desc>Attach UE 13</desc>
-    <id>amarisoft_ue_13</id>
-  </testCase>
-
-  <testCase id="102014">
-    <class>Attach_UE</class>
-    <desc>Attach UE 14</desc>
-    <id>amarisoft_ue_14</id>
-  </testCase>
-
-  <testCase id="102015">
-    <class>Attach_UE</class>
-    <desc>Attach (RedCap) UE 15</desc>
-    <id>amarisoft_ue_15</id>
+    <desc>Attach UE 3 - 15</desc>
+    <id>amarisoft_ue_3 amarisoft_ue_4 amarisoft_ue_5 amarisoft_ue_6 amarisoft_ue_7 amarisoft_ue_8 amarisoft_ue_9 amarisoft_ue_10 amarisoft_ue_11 amarisoft_ue_12 amarisoft_ue_13 amarisoft_ue_14 amarisoft_ue_15</id>
   </testCase>
 
   <testCase id="100010">

ci-scripts/xml_files/container_sa_n310_nrue_longrun.xml

@@ -0,0 +1,179 @@
+<!--
+
+ Licensed to the OpenAirInterface (OAI) Software Alliance under one or more
+ contributor license agreements.  See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The OpenAirInterface Software Alliance licenses this file to You under
+ the OAI Public License, Version 1.1  (the "License"); you may not use this file
+ except in compliance with the License.
+ You may obtain a copy of the License at
+
+      http://www.openairinterface.org/?page_id=698
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+
+ For more information about the OpenAirInterface (OAI) Software Alliance:
+      contact@openairinterface.org
+
+-->
+<testCaseList>
+  <htmlTabRef>LONGRUN-5G-NRUE</htmlTabRef>
+  <htmlTabName>Longrun 40 MHz TDD SA</htmlTabName>
+  <htmlTabIcon>tasks</htmlTabIcon>
+  <TestCaseRequestedList>
+    060000
+    010000 010001
+    800813
+    020000
+    800814
+    020001
+    000001
+    001000
+    000100
+    001000
+    000100
+    001000
+    000100
+    001000
+    000200
+    001000
+    000200
+    001000
+    000200
+    040001 040000
+    333333
+    444444
+    060001
+  </TestCaseRequestedList>
+  <TestCaseExclusionList></TestCaseExclusionList>
+
+  <testCase id="060000">
+    <class>DeployCoreNetwork</class>
+    <desc>Initialize 5G Core</desc>
+    <cn_id>oc-cn5g</cn_id>
+  </testCase>
+
+  <testCase id="010000">
+    <class>Pull_Cluster_Image</class>
+    <desc>Pull Images from Cluster</desc>
+    <images>oai-gnb</images>
+    <node>avra</node>
+  </testCase>
+
+  <testCase id="010001">
+    <class>Pull_Cluster_Image</class>
+    <desc>Pull Images from Cluster</desc>
+    <images>oai-nr-ue</images>
+    <node>caracal</node>
+  </testCase>
+
+  <testCase id="800813">
+    <class>Create_Workspace</class>
+    <desc>Create new Workspace</desc>
+    <node>avra</node>
+  </testCase>
+
+  <testCase id="020000">
+    <class>Deploy_Object</class>
+    <desc>Deploy gNB (TDD/Band78/40MHz/N310) in a container</desc>
+    <node>avra</node>
+    <yaml_path>ci-scripts/yaml_files/5g_sa_n310_gnb</yaml_path>
+    <num_attempts>3</num_attempts>
+  </testCase>
+
+  <testCase id="800814">
+    <class>Create_Workspace</class>
+    <desc>Create new Workspace</desc>
+    <node>caracal</node>
+  </testCase>
+
+  <testCase id="020001">
+    <class>Deploy_Object</class>
+    <desc>Deploy nrUE (TDD/Band78/40MHz/N310) in a container</desc>
+    <yaml_path>ci-scripts/yaml_files/5g_sa_n310_nrue</yaml_path>
+    <node>caracal</node>
+    <num_attempts>3</num_attempts>
+  </testCase>
+
+  <testCase id="000001">
+    <class>Attach_UE</class>
+    <desc>Attach OAIUE</desc>
+    <id>oai_ue_caracal</id>
+  </testCase>
+
+  <testCase id="000100">
+    <class>Iperf</class>
+    <desc>iperf (DL/10Mbps/UDP)(10 min)</desc>
+    <iperf_args>-u -b 10M -t 600 -i 1 -R</iperf_args>
+    <id>oai_ue_caracal</id>
+    <svr_id>oc-cn5g</svr_id>
+    <iperf_packetloss_threshold>25</iperf_packetloss_threshold>
+    <iperf_bitrate_threshold>80</iperf_bitrate_threshold>
+  </testCase>
+
+  <testCase id="000200">
+    <class>Iperf</class>
+    <desc>iperf (UL/2Mbps/UDP)(10 min)</desc>
+    <iperf_args>-u -b 2M -t 600 -i 1 </iperf_args>
+    <id>oai_ue_caracal</id>
+    <svr_id>oc-cn5g</svr_id>
+    <iperf_packetloss_threshold>25</iperf_packetloss_threshold>
+    <iperf_bitrate_threshold>80</iperf_bitrate_threshold>
+  </testCase>
+
+  <testCase id="001000">
+    <class>Ping</class>
+    <desc>Ping: 20pings in 20sec</desc>
+    <id>oai_ue_caracal</id>
+    <svr_id>oc-cn5g</svr_id>
+    <ping_args>-c 20</ping_args>
+    <ping_packetloss_threshold>1</ping_packetloss_threshold>
+    <ping_rttavg_threshold>25</ping_rttavg_threshold>
+  </testCase>
+
+  <testCase id="040000">
+    <class>Undeploy_Object</class>
+    <always_exec>true</always_exec>
+    <desc>Undeploy gNB</desc>
+    <node>avra</node>
+    <yaml_path>ci-scripts/yaml_files/5g_sa_n310_gnb</yaml_path>
+    <d_retx_th>20,100,100,100</d_retx_th>
+    <u_retx_th>20,100,100,100</u_retx_th>
+  </testCase>
+
+  <testCase id="040001">
+    <class>Undeploy_Object</class>
+    <always_exec>true</always_exec>
+    <desc>Undeploy nr UE</desc>
+    <node>caracal</node>
+    <yaml_path>ci-scripts/yaml_files/5g_sa_n310_nrue</yaml_path>
+  </testCase>
+
+  <testCase id="333333">
+    <class>Clean_Test_Server_Images</class>
+    <always_exec>true</always_exec>
+    <desc>Clean Test Images on Test Server</desc>
+    <node>avra</node>
+    <images>oai-gnb</images>
+  </testCase>
+
+  <testCase id="444444">
+    <class>Clean_Test_Server_Images</class>
+    <always_exec>true</always_exec>
+    <desc>Clean Test Images on Test Server</desc>
+    <node>caracal</node>
+    <images>oai-nr-ue</images>
+  </testCase>
+
+  <testCase id="060001">
+    <class>UndeployCoreNetwork</class>
+    <desc>Terminate 5G Core</desc>
+    <always_exec>true</always_exec>
+    <cn_id>oc-cn5g</cn_id>
+  </testCase>
+
+</testCaseList>

common/config/config_load_configmodule.h

@@ -39,7 +39,6 @@
 #include <stdint.h>
 #include <stdbool.h>
 #include "common/config/config_paramdesc.h"
-#include "common/utils/T/T.h"
 #define CONFIG_MAX_OOPT_PARAMS    10     // maximum number of parameters in the -O option (-O <cfgmode>:P1:P2...
 #define CONFIG_MAX_ALLOCATEDPTRS  32768   // maximum number of parameters that can be dynamicaly allocated in the config module
 

common/config/yaml/CMakeLists.txt

@@ -8,11 +8,11 @@ else()
 endif()
 
 add_library(params_yaml_static config_yaml.cpp)
-target_link_libraries(params_yaml_static PUBLIC UTIL yaml-cpp::yaml-cpp)
+target_link_libraries(params_yaml_static PUBLIC yaml-cpp::yaml-cpp)
 if (ENABLE_TESTS)
   add_subdirectory(tests)
 endif()
 
 add_library(params_yaml MODULE config_yaml.cpp)
-target_link_libraries(params_yaml PUBLIC UTIL yaml-cpp::yaml-cpp)
+target_link_libraries(params_yaml PUBLIC yaml-cpp::yaml-cpp)
 set_target_properties(params_yaml PROPERTIES LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})

common/config/yaml/tests/CMakeLists.txt

@@ -1,5 +1,5 @@
 add_executable(test_yaml_config test_yaml_config.cpp)
-target_link_libraries(test_yaml_config PRIVATE params_yaml_static GTest::gtest)
+target_link_libraries(test_yaml_config PRIVATE params_yaml_static GTest::gtest CONFIG_LIB)
 add_dependencies(tests test_yaml_config)
 add_test(NAME test_yaml_config
   COMMAND ./test_yaml_config)

common/utils/LOG/CMakeLists.txt

@@ -4,10 +4,12 @@ target_link_libraries(log_headers INTERFACE T_headers)
 
 set(log_sources log.c)
 if (ENABLE_LTTNG)
+  find_package(LTTngUST 2.3.8 EXACT REQUIRED)
   set(log_sources ${log_sources} lttng-tp.c)
+else()
+  message(STATUS "LTTNG support disabled")
 endif()
 add_library(LOG ${log_sources})
-target_include_directories(LOG PUBLIC .)
 target_link_libraries(LOG PRIVATE CONFIG_LIB)
 target_link_libraries(LOG PUBLIC log_headers)
 if (ENABLE_LTTNG)

common/utils/LOG/log.h

@@ -52,6 +52,7 @@
 #endif
 #include <pthread.h>
 #include <common/utils/utils.h>
+#include "common/utils/T/T.h"
 #if ENABLE_LTTNG
 #include "lttng-log.h"
 #endif

common/utils/T/CMakeLists.txt

@@ -47,7 +47,7 @@ add_custom_target(generate_T DEPENDS T_IDs.h check_vcd)
 # even if T is off, we need the headers as many targets depend on it
 # for this, create an INTERFACE (header-only) library T_headers. To ensure the
 # headers have really been created, we make this headers library explicitly
-# depend on the generated headers.
+# depend on the generate_T target.
 add_library(T_headers INTERFACE)
 add_dependencies(T_headers T_IDs.h generate_T)
 target_include_directories(T_headers INTERFACE ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_SOURCE_DIR})

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

common/utils/telnetsrv/CMakeLists.txt

@@ -44,7 +44,7 @@ add_library(telnetsrv_enb MODULE
             telnetsrv_enb_phycmd.c
 )
 add_dependencies(telnetsrv telnetsrv_enb)
-target_link_libraries(telnetsrv_enb PRIVATE asn1_nr_rrc_hdrs asn1_lte_rrc_hdrs)
+target_link_libraries(telnetsrv_enb PRIVATE asn1_nr_rrc_hdrs asn1_lte_rrc_hdrs log_headers)
 
 message(STATUS "No specific telnet functions for gnb")
 

common/utils/threadPool/measurement_display.c

@@ -52,7 +52,7 @@ int main(int argc, char *argv[]) {
 
   while ( 1 ) {
     if ( read(fd,&doneRequest, sizeof(doneRequest)) ==  sizeof(doneRequest)) {
-      printf("%lu" SEP "%lu" SEP "%lu" SEP "%lu" "\n",
+      printf("%lu" SEP "%llu" SEP "%llu" SEP "%llu" "\n",
              doneRequest.key,
              (doneRequest.startProcessingTime-doneRequest.creationTime)/cpuCyclesMicroSec,
              (doneRequest.endProcessingTime-doneRequest.startProcessingTime)/cpuCyclesMicroSec,

common/utils/time_manager/CMakeLists.txt

@@ -7,7 +7,7 @@ add_library(time_management_core OBJECT
             time_client.c)
 
 target_link_libraries(time_management PUBLIC time_management_core)
-target_link_libraries(time_management_core PRIVATE ${T_LIB})
+target_link_libraries(time_management_core PRIVATE log_headers)
 
 if(ENABLE_TESTS)
   add_subdirectory(tests)

doc/BUILD.md

@@ -1,26 +1,14 @@
-<table style="border-collapse: collapse; border: none;">
-  <tr style="border-collapse: collapse; border: none;">
-    <td style="border-collapse: collapse; border: none;">
-      <a href="http://www.openairinterface.org/">
-         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
-         </img>
-      </a>
-    </td>
-    <td style="border-collapse: collapse; border: none; vertical-align: center;">
-      <b><font size = "5">OAI Build Procedures</font></b>
-    </td>
-  </tr>
-</table>
+# OAI Build Procedures
 
 [[_TOC_]]
 
 This page is valid on tags starting from **`2019.w09`**.
 
-# Overview
+## Overview
 
 The [OAI EPC](https://github.com/OPENAIRINTERFACE/openair-epc-fed/blob/master/docs/DEPLOY_HOME_MAGMA_MME.md) and [OAI 5GC](https://gitlab.eurecom.fr/oai/cn5g/oai-cn5g-fed/-/blob/master/docs/DEPLOY_HOME.md) are developed in distinct projects with their own documentation and are not further described here.
 
-OAI softmodem sources, which aim to implement 3GPP compliant UEs, eNodeB and gNodeB can be downloaded from the Eurecom [gitlab repository](./GET_SOURCES.md).
+OAI softmodem sources, which aim to implement 3GPP compliant UEs, eNodeB and gNodeB can be downloaded from the Eurecom [gitlab repository](setup/GET_SOURCES.md).
 
 Sources come with a build script [build_oai](../cmake_targets/build_oai) located at the root of the `openairinterface5g/cmake_targets` directory. This script is developed to build the oai binaries (executables,shared libraries) for different hardware platforms, and use cases.
 
@@ -40,7 +28,7 @@ Running the  [build_oai](../cmake_targets/build_oai) script also generates some
 - `nvram`: a binary used to build (4G) UE (IMEI...) and EMM (IMSI, registered PLMN) non volatile data.
 - `genids` T Tracer utility, used at build time to generate `T_IDs.h` include file. This binary is located in the [T Tracer source file directory](../common/utils/T) .
 
-The build system for OAI uses [cmake](https://cmake.org/) which is a  tool to generate makefiles. The `build_oai` script is a wrapper using `cmake` and `make`/`ninja` to ease the oai build and use. It logs the `cmake` and `ninja`/`make` commands it executes. The file describing how to build the executables from source files is the [CMakeLists.txt](../CMakeLists.txt), it is used as input by cmake to generate the makefiles.
+The build system for OAI uses [cmake](https://cmake.org/) which is a  tool to generate makefiles. The `build_oai` script is a wrapper using `cmake` and `make`/`ninja` to ease the oai build and use. It logs the `cmake` and `ninja`/`make` commands it executes. The file describing how to build the executables from source files is the [CMakeLists.txt](CMakeLists.txt), it is used as input by cmake to generate the makefiles.
 
 cmake is further extended by using [CPM](https://github.com/cpm-cmake/CPM.cmake). CPM is a cmake script that handles external code dependencies. It is setup to cache downloaded code in `~/.cache/cpm`. While most external dependencies should be handled by system package managers, CPM has the advantage of using any code that is available in a public git repository.
 
@@ -49,9 +37,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:
 
@@ -64,9 +52,9 @@ Calling the `build_oai` script with the `-h` option gives the list of all availa
 - `--ninja` is to use the `ninja` build tool, which speeds up compilation.
 - `-c` is to clean the workspace and force a complete rebuild.
 
-`build_oai` also provides various options to enable runtime error checkers, i.e. sanitizers in order to find various types of bugs in the codebase and eventually enhance the stability of the OAI softmodems. Refer to [sanitizers.md](./dev_tools/sanitizers.md) for more details.
+`build_oai` also provides various options to enable runtime error checkers, i.e. sanitizers in order to find various types of bugs in the codebase and eventually enhance the stability of the OAI softmodems. Refer to [sanitizers.md](dev_tools/sanitizers.md) for more details.
 
-## Installing dependencies
+### Installing dependencies
 
 Install all dependencies by issuing the `-I` option. To install furthermore libraries for optional libraries, use the `--install-optional-packages` option. The `-I` option will also install dependencies for an SDR when paired with `-w`. For instance, in order to install all dependencies and the ones for USRP, run:
 
@@ -77,7 +65,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 +95,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 +127,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:
 
@@ -150,9 +138,9 @@ cd openairinterface5g/cmake_targets/
 
 After completing the build, the binaries are available in the `cmake_targets/ran_build/build` directory.
 
-Detailed information about these simulators can be found [in the dedicated page](./physical-simulators.md)
+Detailed information about these simulators can be found [in the dedicated page](usage/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 +153,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 +175,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,9 +205,9 @@ cmake-gui ../../..
 ```
 You can of course use all standard cmake/ninja/make commands in this directory.
 
-## cmake presets
+### cmake presets
 
-CMake presets are common project configure options. See https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html
+CMake presets are common project configure options. See [here](https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html).
 
 Configure presets:
 
@@ -241,7 +229,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.
+If you want to use cross-compiler on x86 platform for aarch64 version, please refer the [cross-compile.md](setup/cross-compile.md) for more information.
 

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

@@ -1,6 +1,6 @@
 [[_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.
 
@@ -75,13 +75,13 @@ sequenceDiagram
   Note over u: E1AP_CUUP_task (SCTP Handler)
   Note over u: ASN1 decoder
 ```
-More details about the E1AP procedures in OAI are available in this document: [E1 Procedures](./e1ap_procedures.md).
+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.
+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](../tutorials/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,15 +165,15 @@ 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.
 
-![E1/F1/NG parameters](./images/e1-archi.png){width=1200}
+![E1/F1/NG parameters](images/e1-archi.png){width=1200}
 
-[PDF version](./images/e1-archi.pdf) | [LaTeX/TikZ version](./images/e1-archi.tex) if you want to modify to reflect your setup
+[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/E1AP/e1ap_procedures.md

@@ -1,20 +1,8 @@
-<table style="border-collapse: collapse; border: none;">
-  <tr style="border-collapse: collapse; border: none;">
-    <td style="border-collapse: collapse; border: none;">
-      <a href="http://www.openairinterface.org/">
-         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
-         </img>
-      </a>
-    </td>
-    <td style="border-collapse: collapse; border: none; vertical-align: center;">
-      <b><font size = "5">E1AP Procedures</font></b>
-    </td>
-  </tr>
-</table>
+# E1AP Procedures
 
 [[_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)
 * 3GPP TS 38.460 - E1 general aspects and principles
@@ -26,18 +14,18 @@ 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).
 * 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.
 * 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.
+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:
 

doc/F1AP/F1-design.md

@@ -1,20 +1,8 @@
-<table style="border-collapse: collapse; border: none;">
-  <tr style="border-collapse: collapse; border: none;">
-    <td style="border-collapse: collapse; border: none;">
-      <a href="http://www.openairinterface.org/">
-         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
-         </img>
-      </a>
-    </td>
-    <td style="border-collapse: collapse; border: none; vertical-align: center;">
-      <b><font size = "5">F1 split design</font></b>
-    </td>
-  </tr>
-</table>
+# F1 split design
 
 [[_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 +21,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.
@@ -59,17 +47,17 @@ This is the current status:
   * 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)
+  * [Mobility between DUs connected to a single CU](../tutorials/handover-tutorial.md)
 - 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](../setup/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 +158,7 @@ sequenceDiagram
     TASK_MAC_GNB->>+TASK_RRC_GNB: raw F1AP message (ITTI)
 ```
 
-## F1-U
+### F1-U
 
 Current status:
 
@@ -178,7 +166,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 +178,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 +188,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 +230,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 +248,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 +289,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 +320,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 +359,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 +378,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

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

doc/L1_L2/L1SIM.md

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

doc/L1_L2/L2NFAPI.md

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

doc/L1_L2/L2NFAPI_NOS1.md

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

doc/L1_L2/L2NFAPI_S1.md

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

doc/L1_L2/nfapi.md

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

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)
@@ -179,11 +179,10 @@ In the last lines:
 
 ## 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
+See [nFAPI documentation](../L1_L2/nfapi.md) or [Aerial tutorial](../tutorials/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
 
@@ -226,7 +225,7 @@ In the `MACRLCs` section of the gNB/DU configuration file:
 * `identity_precoding_matrix` (default 0=false): flag to enable to use only
   the identity precoding matrix in DL precoding
 * `set_analog_beamforming` (default 0=false): flag to enable analog
-  beamforming (for more information [`analog_beamforming.md`](../analog_beamforming.md))
+  beamforming (for more information [`analog_beamforming.md`](../tutorials/analog_beamforming.md))
 * `beam_duration` (default 1): duration/number of consecutive slots for a given set of
   beams, depending on hardware switching performance
 * `beams_per_period` (default 1): set of beams that can be simultaneously allocated in a
@@ -244,11 +243,11 @@ SIBs are configured at the DU and some at the CU; please consult the [RRC
 configuration](../RRC/rrc-usage.md) as well for SIB configuration.
 
 * `pdsch_AntennaPorts_XP` (default 1): number of XP logical antenna
-  ports in PDSCH (see also [`RUNMODEM.md`](../RUNMODEM.md))
+  ports in PDSCH (see also [`RUNMODEM.md`](../usage/RUNMODEM.md))
 * `pdsch_AntennaPorts_N1` (default 1): number of horizontal logical antenna
-  ports in PDSCH (see also [`RUNMODEM.md`](../RUNMODEM.md))
+  ports in PDSCH (see also [`RUNMODEM.md`](../usage/RUNMODEM.md))
 * `pdsch_AntennaPorts_N2` (default 1): number of vertical logical antenna
-  ports in PDSCH (see also [`RUNMODEM.md`](../RUNMODEM.md))
+  ports in PDSCH (see also [`RUNMODEM.md`](../usage/RUNMODEM.md))
 * `pusch_AntennaPorts` (default 1): number of antenna ports in PUSCH
 * `maxMIMO_layers` (default -1=unlimited): maximum number of MIMO layers to use
   in downlink
@@ -269,7 +268,7 @@ configuration](../RRC/rrc-usage.md) as well for SIB configuration.
 * `force_UL256qam_off` (default 0=false): flag whether to disable 256QAM (limit to
   64QAM) in DL
 * `disable_harq` (default 0=false): flag whether to disable HARQ completely
-  (useful for NTN operation, see <../RUNMODEM.md>). **this is a Rel-17 feature
+  (useful for NTN operation, see <../usage/RUNMODEM.md>). **this is a Rel-17 feature
   and you need to have a capable UE for this**
 * `use_deltaMCS` (default 0=false): flag whether to enable deltaMCS (**this is not fully tested
   and might not work** and you might need to adjust other parameters such as
@@ -291,7 +290,7 @@ configuration](../RRC/rrc-usage.md) as well for SIB configuration.
 
 DL-MIMO is configured using following parameters:
 `pdsch_AntennaPorts_XP` , `pdsch_AntennaPorts_N1` , `pdsch_AntennaPorts_N2`, `maxMIMO_layers`
-(see also [`RUNMODEM.md`](../RUNMODEM.md))
+(see also [`RUNMODEM.md`](../usage/RUNMODEM.md))
 
 ## ServingCellConfigCommon parameters
 
@@ -308,7 +307,7 @@ Below is a description of some of these parameters.
 
 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).
+[corresponding document](../setup/gNB_frequency_setup.md).
 
 ### TDD pattern configuration
 
@@ -336,7 +335,7 @@ Configure the TDD pattern through these options:
 As an example, the below figure shows a single TDD pattern, consisting of 3 DL
 slots, 1 mixed slots (with 10 DL, 2 guard, 2 UL symbols), and 1 UL slot.
 
-![TDD Frame Structure](TDD_Frame_Structure.png)
+![TDD Frame Structure](images/TDD_Frame_Structure.png)
 
 To configure this pattern in the configuration file, use
 

doc/README.md

@@ -1,16 +1,4 @@
-<table style="border-collapse: collapse; border: none;">
-  <tr style="border-collapse: collapse; border: none;">
-    <td style="border-collapse: collapse; border: none;">
-      <a href="http://www.openairinterface.org/">
-         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
-         </img>
-      </a>
-    </td>
-    <td style="border-collapse: collapse; border: none; vertical-align: center;">
-      <b><font size = "5">OpenAirInterface documentation overview</font></b>
-    </td>
-  </tr>
-</table>
+# OpenAirInterface documentation overview
 
 This is the general overview page of the OpenAirInterface documentation.  
 This page groups links to general information, tutorials, design documents, radio integration, and special-purpose libraries.
@@ -23,81 +11,79 @@ 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
-- [BUILD.md](./BUILD.md): how to build the sources
-- [code-style-contrib.md](./code-style-contrib.md): overall working practices, code style, and review process
-- [cross-compile.md](./cross-compile.md): how to cross-compile OAI for ARM
-- [clang-format.md](./clang-format.md): how to format the code
-- [sanitizers.md](./dev_tools/sanitizers.md): how to run with ASan/UBSan/MemSAN/TSan
-- [environment-variables.md](./environment-variables.md): the environment variables used by OAI
-- [tuning_and_security.md](./tuning_and_security.md): performance and security considerations
+- [FEATURE_SET.md](setup/FEATURE_SET.md): lists supported features
+- [GET_SOURCES.md](setup/GET_SOURCES.md): how to download the sources
+- [BUILD.md](BUILD.md): how to build the sources
+- [code-style-contrib.md](setup/code-style-contrib.md): overall working practices, code style, and review process
+- [cross-compile.md](setup/cross-compile.md): how to cross-compile OAI for ARM
+- [clang-format.md](setup/clang-format.md): how to format the code
+- [sanitizers.md](dev_tools/sanitizers.md): how to run with ASan/UBSan/MemSAN/TSan
+- [environment-variables.md](setup/environment-variables.md): the environment variables used by OAI
+- [tuning_and_security.md](testing/tuning_and_security.md): performance and security considerations
 
 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)
-  * [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
+  * [OAI 5GC](tutorials/NR_SA_Tutorial_OAI_CN5G.md)
+  * [OAI gNB with COTS UE](tutorials/NR_SA_Tutorial_COTS_UE.md)
+  * [OAI NR-UE](tutorials/NR_SA_Tutorial_OAI_nrUE.md)
+  * [Multiple OAI NR-UE with RFsimulator](tutorials/NR_SA_Tutorial_OAI_multi_UE.md)
+- [RUNMODEM.md](usage/RUNMODEM.md): Generic information on how to
   * 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_GNB_W_COTS_UE.md)
-- [How to run a 4G setup using L1 simulator](./L1SIM.md) _Note: we recommend the RFsimulator_
-- [How to use the L2 simulator](./L2NFAPI.md)
+- [How to run OAI with O-RAN 7.2 FHI](tutorials/ORAN_FHI7.2_Tutorial.md)
+- [How to run a 5G-NSA setup](testing/TESTING_OAI_NSA_COTS_UE.md)
+- [How to run a 4G setup using L1 simulator](L1_L2/L1SIM.md) _Note: we recommend the RFsimulator_
+- [How to use the L2 simulator](L1_L2/L2NFAPI.md)
 - [How to use the OAI channel simulator](../openair1/SIMULATION/TOOLS/DOC/channel_simulation.md)
-- [How to use multiple BWPs](./RUN_NR_multiple_BWPs.md)
-- [How to run OAI-VNF and OAI-PNF](./nfapi.md): how to run the FAPI/nFAPI split,
+- [How to use multiple BWPs](usage/RUN_NR_multiple_BWPs.md)
+- [How to run OAI-VNF and OAI-PNF](L1_L2/nfapi.md): how to run the FAPI/nFAPI split,
   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 the positioning reference signal (PRS)](usage/RUN_NR_PRS.md)
+- [How to use device-to-device communication (D2D, 4G)](setup/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)
-- [How to setup OAI with LDPC accelerators (Xilinx T2/Intel ACCs)](./LDPC_OFFLOAD_SETUP.md)
-- [How to do a handover](./handover-tutorial.md)
-- [How to setup gNB frequency](./gNB_frequency_setup.md)
+- [How to run the physical simulators](usage/physical-simulators.md)
+- [How to setup OAI with Nvidia Aerial and Foxconn](tutorials/Aerial_FAPI_Split_Tutorial.md)
+- [How to setup OAI with LDPC accelerators (Xilinx T2/Intel ACCs)](tutorials/LDPC_OFFLOAD_SETUP.md)
+- [How to do a handover](tutorials/handover-tutorial.md)
+- [How to setup gNB frequency](setup/gNB_frequency_setup.md)
 
 Legacy unmaintained files:
-- [`L2NFAPI_NOS1.md`](./L2NFAPI_NOS1.md), [`L2NFAPI_S1.md`](./L2NFAPI_S1.md):
+- [`L2NFAPI_NOS1.md`](L1_L2/L2NFAPI_NOS1.md), [`L2NFAPI_S1.md`](L1_L2/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
+- [`UL_MIMO.md`](usage/UL_MIMO.md): UL-MIMO specific notes
 
-# Designs
+## Designs
 
-- General software architecture notes: [SW_archi.md](./SW_archi.md)
-- [Information on E1](./E1AP/E1-design.md)
-- [Information on F1](./F1AP/F1-design.md)
-- [Information on how NR nFAPI works](./NR_NFAPI_archi.md)
-- [Flow graph of the L1 in gNB](SW-archi-graph.md)
-- [L1 threads in NR-UE](./nr-ue-design.md)
-- [Information on gNB MAC](./MAC/mac-usage.md)
-- [Information on gNB RRC](./RRC/rrc-usage.md)
-- [Information on analog beamforming implementation](./analog_beamforming.md)
-- [Information on the UE 5G NAS implementation](./5Gnas.md)
+- General software architecture notes: [SW_archi.md](architecture/SW_archi.md)
+- [Information on E1](E1AP/E1-design.md)
+- [Information on F1](F1AP/F1-design.md)
+- [Information on how NR nFAPI works](architecture/NR_NFAPI_archi.md)
+- [Flow graph of the L1 in gNB](architecture/SW-archi-graph.md)
+- [L1 threads in NR-UE](architecture/nr-ue-design.md)
+- [Information on gNB MAC](MAC/mac-usage.md)
+- [Information on gNB RRC](RRC/rrc-usage.md)
+- [Information on analog beamforming implementation](tutorials/analog_beamforming.md)
+- [Information on the UE 5G NAS implementation](tutorials/5Gnas.md)
 
-# 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
@@ -106,38 +92,38 @@ Legacy unmaintained files:
 - The [shared object loader](../common/utils/DOC/loader.md)
 - The [threadpool](../common/utils/threadPool/thread-pool.md) used in L1
 - The [LDPC implementation](../openair1/PHY/CODING/DOC/LDPCImplementation.md) is a shared library
-- The [time management](time_management.md) module
+- The [time management](architecture/time_management.md) module
 
-## Radios
+### Radios
 
 Some directories under `radio` contain READMEs:
 
 - [RFsimulator](../radio/rfsimulator/README.md)
 - [USRP](../radio/USRP/README.md)
 - [BladeRF](../radio/BLADERF/README)
-- [IQPlayer](../radio/iqplayer/DOC/iqrecordplayer_usage.md), and [general documentation](./iqrecordplayer_usage.md)
+- [IQPlayer](../radio/iqplayer/DOC/iqrecordplayer_usage.md), and [general documentation](usage/iqrecordplayer_usage.md)
 - [fhi_72](../radio/fhi_72/README.md)
 - [vrtsim](../radio/vrtsim/README.md)
 - [rf_emulator](../radio/emulator/README.md)
 
 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
+- [UnitTests.md](testing/UnitTests.md) explains the unit testing setup
 - Component tests are under `tests/`. Currently, there is a simple CU-UP
   tester, see the corresponding [README.md](../tests/nr-cuup/README.md).
-- [TESTBenches.md](./TESTBenches.md) lists the CI setup and links to pipelines
+- [TESTBenches.md](testing/TESTBenches.md) lists the CI setup and links to pipelines
 - The CI setup uses a [custom framework](../ci-scripts/README.md) to run
   end-to-end tests.
 
-# Developer tools
+## Developer tools
 
 - [formatting](../tools/formatting/README.md) is a clang-format error detection tool
 - [iwyu](../tools/iwyu/README.md) is a tool to detect `#include` errors

doc/RRC/rrc-dev.md

@@ -4,11 +4,11 @@ schemes (connection, reestablishment, handover) including their interworking
 with other layers.
 
 User documentation, such as general configuration options, are described in [a
-separate page](./rrc-usage.md).
+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

doc/RRC/rrc-usage.md

@@ -2,19 +2,19 @@ This document describes the basic functioning of the 5G RRC layer, describes
 the periodic output, and explains the various configuration options that
 influence its behavior.
 
-Developer documentation, such as UE connection control flow, reestablishment, or handover, are described in [a separate page](./rrc-dev.md).
+Developer documentation, such as UE connection control flow, reestablishment, or handover, are described in [a separate page](rrc-dev.md).
 
 [[_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
 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
+## 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](../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
+### 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,35 +90,52 @@ 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
 
-#### What is a gNB neighbor?
+Refer to the [handover tutorial](../tutorials/handover-tutorial.md) for detailed information about gNB neighbors and handover procedures.
 
-Network continuity is a key aspect of 5G. In the 5G architecture, gNB neighbors play a central role in maintaining service continuity through mechanisms such as handover and load balancing.  By definition, a gNB neighbor is another gNB that can be measured and linked by the UE. If the current serving gNB is no longer optimal, the UE may connect to a neighbor gNB.
+##### Required configuration parameters
 
-To support this behavior, the network configuration specifies additional frequencies and cells that the UE should measure. The UE reports these measurements to the network, which then decides whether or not to initiate a handover.
+To define a neighbor cell in the configuration file, the following parameters are required:
 
-Neighbor types include:
-- **Intra-gNB neighbors** - cells belonging to the same gNB
-- **Inter-gNB neighbors** - cells belonging to different gNBs
-- **Inter-RAT neighbors** - cells belonging to another RAT (e.g., LTE)
+- `gNB_ID` - identifier of the neighbor gNB (e.g., `0xe01`)
+- `nr_cellid` - cell identifier of the neighbor cell (e.g., `11111111`)
+- `physical_cellId` - physical cell ID for radio identification (e.g., `1`)
+- `absoluteFrequencySSB` - SSB frequency in ARFCN notation (e.g., `643296`)
+- `subcarrierSpacing` - numerology index: 0=15kHz, 1=30kHz, 2=60kHz, 3=120kHz
+- `band` - 3GPP frequency band number (e.g., `78` for 3.5GHz)
+- `plmn` - PLMN configuration object with:
+  - `mcc` - mobile country code (3 digits, e.g., `001`)
+  - `mnc` - mobile network code (2-3 digits, e.g., `01`)
+  - `mnc_length` - number of digits in MNC (must be `2` or `3`)
+- `tracking_area_code` - tracking area identifier (e.g., `1`)
 
-#### Required configuration parameters
+Example configuration structure:
+```
+neighbour_list = (
+  {
+    nr_cellid = 12345678;
+    neighbour_cell_configuration = (
+      {
+        gNB_ID = 0xe01;
+        nr_cellid = 11111111;
+        physical_cellId = 1;
+        absoluteFrequencySSB = 643296;
+        subcarrierSpacing = 1; # 30 kHz
+        band = 78;
+        plmn = { mcc = 001; mnc = 01; mnc_length = 2 };
+        tracking_area_code = 1;
+      }
+    );
+  }
+);
+```
 
-To define a neighbor cell in the configuration file, the following parameters are typically needed:
-- **gNB ID** - unique identifier of the gNB
-- **Cell ID** - identifier of the cell within the gNB
-- **Physical Cell ID** - identifier of the cell’s synchronization signal (PCI)
-- **Absolute Frequency** - frequency used by the SSB (absoluteFrequencySSB)
-- **Subcarrier Spacing** - numerology (e.g., 15 kHz, 30 kHz)
-- **PLMN configuration** - MCC, MNC, and MNC length
-- **Tracking Area Code (TAC)** - identifier of the tracking area
-
-Refer to the [handover tutorial](../handover-tutorial.md) for more information.
+Refer to the [handover tutorial](../tutorials/handover-tutorial.md) for complete examples and detailed setup instructions.

doc/SystemX-tutorial-design.md

@@ -1,143 +0,0 @@
-# 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/UL_MIMO.txt

@@ -1,31 +0,0 @@
-# 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/architecture/NR_NFAPI_archi.md

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

doc/architecture/SW_archi.md

@@ -1,21 +1,3 @@
-<style type="text/css" rel="stylesheet">
-
-body {
-   font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
-   font-size: 13px;
-   line-height: 18px;
-   color: #fff;
-   background-color: #110F14;
-}
-  h2 { margin-left: 20px; }
-  h3 { margin-left: 40px; }
-  h4 { margin-left: 60px; }
-
-.func2 { margin-left: 20px; }
-.func3 { margin-left: 40px; }
-.func4 { margin-left: 60px; }
-
-</style>
 
 ```mermaid
 flowchart TB
@@ -83,11 +65,10 @@ end
 ```
 
 This tuto for 5G gNB design, with Open Cells main
-{: .text-center}
 
-# The main thread is in ru_thread()
+## The main thread is in ru_thread()
 The infinite loop:
-## rx_rf()
+### rx_rf()
   Collect radio signal samples from RF board  
     all SDR processing is triggered by I/Q sample reception and it's date (timestamp)  
     TX I/Q samples will have a date in the future, compared to RX timestamp  
@@ -97,11 +78,11 @@ The infinite loop:
     (each sample has a incremental number representing a very accurate timing)  
 raw incoming data is in buffer called "rxdata"  
     We derivate frame number, slot number, ... from the RX timestamp
-{: .func2}
-## gNB_top()
+
+### gNB_top()
 only compute frame numbre, slot number, ...
-{: .func3}
-## 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  
@@ -110,92 +91,92 @@ but not actual coherency (see below handle_nr_rach() assumes data is up-to-date)
 The first part (in NR_UL_indication, uses the data computed by the lower part (phy_procedures_gNB_uespec_RX), but for the **previous** slot  
 Then, phy_procedures_gNB_uespec_RX will hereafter replace the data for the next run  
 This is very tricky and not thread safe at all.
-{: .func3}
 
-### NR_UL_indication()  
+
+#### NR_UL_indication()
 This block processes data already decoded and stored in structures behind UL_INFO
-{: .func4}
+
 
 * handle_nr_rach()  
 process data from RACH primary detection  
 if the input is a UE RACH detection
-{: .func4}
+
     * nr_schedule_msg2()
-{: .func4}
+
 * handle_nr_uci()  
 handles uplink control information, i.e., for the moment HARQ feedback.
-{: .func4}
+
 * handle_nr_ulsch()  
 handles ulsch data prepared by nr_fill_indication()
-{: .func4}
+
 * gNB_dlsch_ulsch_scheduler ()  
 the **scheduler** is called here, see dedicated chapter
-{: .func4}
+
 * NR_Schedule_response()  
 process as per the scheduler decided
-{: .func4}
 
-### L1_nr_prach_procedures()  
+
+#### L1_nr_prach_procedures()  
 ????
-{: .func4}
-### 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  
-{: .func4}
+
 * nr_rx_pusch()  
-{: .func4}
+
     * extracts data from rxdataF (frequency transformed received data)
-{: .func4}
+
     * nr_pusch_channel_estimation()
-{: .func4}
+
     * nr_ulsch_extract_rbs_single()
-{: .func4}
+
     * nr_ulsch_scale_channel()
-{: .func4}
+
     * nr_ulsch_channel_level()
-{: .func4}
+
     * nr_ulsch_channel_compensation()
-{: .func4}
+
     * nr_ulsch_compute_llr()  
 this function creates the "likelyhood ratios"  
-{: .func4}
+
 * nr_ulsch_procedures()
-{: .func4}
+
     * actual ULsch decoding
-{: .func4}
+
     * nr_ulsch_unscrambling()
- {: .func4}
+ 
    * nr_ulsch_decoding()
- {: .func4}
+ 
    * nr_fill_indication()   
 populate the data for the next call to "NR_UL_indication()"  
 it would be better to call **NR_UL_indication()** now instead of before (on previous slot)
-{: .func4}
 
-### phy_procedures_gNB_TX()
+
+#### phy_procedures_gNB_TX()
 * nr_common_signal_procedures()  
 generate common signals
-{: .func4}
+
 * nr_generate_dci_top()
 generate DCI: the scheduling informtion for each UE in both DL and UL
-{: .func4}
+
 * nr_generate_pdsch()  
 generate DL shared channel (user data)
-{: .func4}
 
-### nr_feptx_prec()
+
+#### nr_feptx_prec()
 tx precoding
-{: .func3}
-### nr_feptx0
+
+#### nr_feptx0
 do the inverse DFT
-{: .func3}
-### tx_rf()
+
+#### tx_rf()
 send radio signal samples to the RF board  
 the samples numbers are the future time for these samples emission on-air
-{: .func3}
 
-# Scheduler
+
+## Scheduler
 
 The main scheduler function  is called by the chain: nr_ul_indication()=>gNB_dlsch_ulsch_scheduler()
 It calls sub functions to process each physical channel (rach, ...)  
@@ -274,7 +255,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  
   
@@ -283,7 +264,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.
 
@@ -302,9 +283,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()`.
 
@@ -315,11 +296,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.
 
@@ -327,19 +308,19 @@ Initialization of the PDCP layer follows a structure similar to that of the RLC
 
 To manage UE connections, `nr_pdcp_add_srbs()` is employed for adding UE SRBs in PDCP, while `nr_pdcp_remove_UE()` is used for their removal. Similarly, `nr_pdcp_add_drbs()` adds UE DRBs in PDCP, with `nr_pdcp_remove_UE()` handling their removal.
 
-## PDCP Tx flow
+### PDCP Tx flow
 
 On the Tx side (downlink in gNB), the entry functions `nr_pdcp_data_req_drb()` and `nr_pdcp_data_req_srb()` are called by the upper layer. The upper layer could be GTP or a PDCP internal thread like `gnb_tun_read_thread()`, which reads directly from the Linux socket if the 3GPP core implementation is skipped. The PDCP internals for `nr_pdcp_data_req_srb()` and `nr_pdcp_data_req_drb()` are thread-safe. Within these functions, the PDCP manager protects access to the SDU receiving function of PDCP (`recv_sdu()` callback, corresponding to `nr_pdcp_entity_recv_pdu()` for DRBs) using mutex. When necessary, the PDCP layer pushes this data to RLC by calling `rlc_data_req()`.
 
-## PDCP Rx flow
+### PDCP Rx flow
 
 At the Rx side, `pdcp_data_ind()` serves as the entry point for receiving data from RLC. Within `pdcp_data_ind()`, the PDCP manager mutex protects access to the PDU receiving function of PDCP (`recv_pdu()` callback corresponding to `nr_pdcp_entity_recv_pdu()` for DRBs). Following this, the `deliver_sdu_drb()` function dispatches the received data to the SDAP sublayer.
 
-## PDCP security
+### PDCP security
 
 nr_pdcp_config_set_security(): sets the keys for AS security of a UE
 
-# AM DRB traffic flow in OAI
+## AM DRB traffic flow in OAI
 
 A sequence diagram of the traffic flow across PDCP and RLC layers. By default, data traffic is directed towards AM DRBs.
 
@@ -430,46 +411,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  
 
@@ -478,17 +459,10 @@ cmake new option: NEW_GTPU to use the new implementation (it changes for the ent
 It is possible to use both old and new GTP in same executable because the itti task and all functions names are different 
 Current status of new implementation: not tested, X2 not developped, 5G new GTP option not developped, remain issues on data coming from void: muid, enb_flag, ...
 
-# NGAP
+## NGAP
 NGAP would be a itti thread as is S1AP (+twin thread SCTP that is almost void processing)?  
 About all messages are exchanged with RRC thread  
 
 
-<div class="panel panel-info">
-**Note**
-{: .panel-heading}
-<div class="panel-body">
 
 
-</div>
-</div>
-

doc/architecture/nr-ue-design.md

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

doc/architecture/time_management.md

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

doc/d2d_emulator_setup.txt

@@ -1,104 +0,0 @@
-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/dev_tools/sanitizers.md

@@ -1,27 +1,15 @@
-<table style="border-collapse: collapse; border: none;">
-  <tr style="border-collapse: collapse; border: none;">
-    <td style="border-collapse: collapse; border: none;">
-      <a href="http://www.openairinterface.org/">
-         <img src="./../images/oai_final_logo.png" alt="" border=3 height=50 width=150>
-         </img>
-      </a>
-    </td>
-    <td style="border-collapse: collapse; border: none; vertical-align: center;">
-      <b><font size = "5">OAI Build Procedures</font></b>
-    </td>
-  </tr>
-</table>
+# OAI Build Procedures
 
 [[_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 +17,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 +36,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 +50,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 +58,10 @@ To build with Memory Sanitizer, use the following command:
 CC=/usr/bin/clang CXX=/usr/bin/clang++ ./build_oai ... --sanitize-memory
 ```
 
-## Thread Sanitizer
+### Thread Sanitizer
 [Thread Sanitizer](https://clang.llvm.org/docs/ThreadSanitizer.html) can be activated using the `--sanitize-thread` option or `-fsanitize=thread`. This sanitizer helps identify data races and other threading-related issues in the code.
 
-# Summary of Sanitizer Options
+## Summary of Sanitizer Options
 
 - `--sanitize`: Shortcut for using both ASAN and UBSAN.
 - `--sanitize-address` or `-fsanitize=address`: Enable ASAN on all targets.

doc/episys/lte_mode_l2_emulator/README.md

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

doc/episys/nsa_mode_l2_emulator/README.md

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

doc/setup/FEATURE_SET.md

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

doc/setup/GET_SOURCES.md

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

doc/setup/clang-format.md

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

doc/setup/code-style-contrib.md

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

doc/setup/cross-compile.md

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

doc/setup/d2d_emulator_setup.md

@@ -0,0 +1,207 @@
+# 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/setup/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/system_requirements.md

@@ -1,16 +1,5 @@
-<table style="border-collapse: collapse; border: none;">
-  <tr style="border-collapse: collapse; border: none;">
-    <td style="border-collapse: collapse; border: none;">
-      <a href="http://www.openairinterface.org/">
-         <img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
-         </img>
-      </a>
-    </td>
-    <td style="border-collapse: collapse; border: none; vertical-align: center;">
-      <b><font size = "5">System Requirements for Using OAI Stack</font></b>
-    </td>
-  </tr>
-</table>
+
+# System Requirements for Using OAI Stack
 
 This document describes the minimal and performant system requirements for OpenAirInterface (OAI) 4G/5G software stack (UE and gNB stack). The information provided in this document is based on experimentation, if you have a feedback then open an issue or send an email on the mailing list. 
 
@@ -18,7 +7,7 @@ This document describes the minimal and performant system requirements for OpenA
 
 [[_TOC_]]
 
-# Supported CPU Architecture
+## Supported CPU Architecture
 
 |Architecture                               |
 |------------------------------------------ |
@@ -29,7 +18,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 +29,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 +50,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 +59,13 @@ likely won't work well.
 
 **NOTE**: We have not tested on Intel Atom or Celeron processors 
 
-## USRP B2XX or Blade RF
+### USRP B2XX or Blade RF
 
 USRP B2XX or Blade RF are USB based radios recommended to use with USB 3.0. You can choose a minimum hardware to do functional testing and performance hardware for performance testing. This hardware you can find in Mini-PCs or laptops.
 
-The minimum requirements stated in [simulated radio](.##simulated-radio) apply.
+The minimum requirements stated in [simulated radio](#simulated-radio) apply.
 
-### Minimum requirements for both gNB and UE Stack
+#### Minimum requirements for both gNB and UE Stack
 
 - CPU: 3
 - Memory: 5Gi
@@ -84,7 +73,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 
@@ -94,21 +83,19 @@ The minimum requirements stated in [simulated radio](.##simulated-radio) apply.
 - DDR4 or DDR5 RAM, minimum 5Gi
 - USB 3.0
 
-Apart from this you should follow [tuning and security tips](./tuning_and_security.md) to 
-tune your system to get high performance. 
+Apart from this you should follow [tuning and security tips](testing/tuning_and_security.md) to tune your system to get high performance.
 
-## USRP N3XX/X3XX/X4XX/AW2S
+### USRP N3XX/X3XX/X4XX/AW2S
 
 USRP N3XX/X3XX/X4XX requires two dedicated 10G SFP+ connections. For these radios we only recommend having performance hardware. This hardware you can find in Desktop servers or rack/blade servers. For the gNB, the same applies in case of using AW2S radios.
 
-The minimum requirements stated in [simulated radio](.##simulated-radio) apply.
+The minimum requirements stated in [simulated radio](#simulated-radio) apply.
 
-Apart from this you should follow [tuning and security tips](./tuning_and_security.md) to 
-tune your system to get high performance. 
+Apart from this you should follow [tuning and security tips](testing/tuning_and_security.md) to tune your system to get high performance.
 
 **NOTE**: In case you are using Mellanox NIC cards then you have to download `mlnx-ofed` and configure your NIC for performance. 
 
-### Recommended for performance for gNB Stack
+#### Recommended for performance for gNB Stack
 
 - CPU: 8-10
 - Boost Frequency > 4GHz
@@ -118,7 +105,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,8 +115,8 @@ 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. 
+We have dedicated documentation for O-RAN Radio Units. [Refer to 7.2 FH documentation](tutorials/ORAN_FHI7.2_Tutorial.md) before purchasing a Desktop server or rack/blade server.
 
-The minimum requirements stated in [simulated radio](.##simulated-radio) apply.
+The minimum requirements stated in [simulated radio](#simulated-radio) apply.

doc/testing/TESTBenches.md

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

doc/testing/TESTING_OAI_NSA_COTS_UE.md

@@ -6,13 +6,11 @@ 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 Resources to this page can be found [here](https://docs.google.com/document/d/1pL8Szm0ocGxdl5ESVp12Ff71a4PbhCb9SpvbLZzwYbo/edit?usp=sharing) (special mention to Walter Maguire, [wmaguire@live.com](mailto:wmaguire@live.com)).
 At time of writing, the openairinterface5G Commit Tag is 2020.w39
 
 
-Faraday Cages can be found here :  
-http://www.saelig.com/MFR00066/ste2300.htm
+Faraday Cages can be found [here](http://www.saelig.com/MFR00066/ste2300.htm)
 
 
 ## Configuration Overview
@@ -37,32 +35,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 +70,7 @@ cd cmake_targets/
 
 - **gNB**
 
-```
+```bash
 cd <your oai installation directory>/openairinterface5g/
 source oaienv
 cd cmake_targets/
@@ -83,8 +81,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 +90,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 +197,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 +211,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 +230,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 +240,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/testing/UnitTests.md

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

doc/testing/tuning_and_security.md

@@ -6,13 +6,12 @@ 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
+Please also refer to the [advanced configuration in the tutorial](../tutorials/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 +45,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 +66,7 @@ sudo sysctl -n -e -q -w net.core.wmem_default=134217728
 sudo sysctl -n -e -q -w net.core.wmem_max=134217728
 ```
 
-# Capabilities
+## Capabilities
 
 Historically, all softmodems are executed as `root`, typically using `sudo`.
 This remains a possibility, but we do not recommend it due to security
@@ -75,7 +74,7 @@ considerations. Rather, consider giving specific capabilities as outlined
 below. Read `capabilities(7)` (`man 7 capabilities`) for more information on
 each of the below capabilities.
 
-Note that we tested this using 5G executables; 4G should work, but have not
+> **Note** that we tested this using 5G executables; 4G should work, but have not
 been tested as extensively. If in doubt, run eNB/lteUE using `sudo`. The below
 comments on capabilities apply in general as well; however, 4G executable might
 not warn about missing capabilities or just fail.
@@ -111,7 +110,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 +136,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 +149,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.