Update F1-design.md

doc/F1AP/F1-design.md

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