diff --git a/doc/F1AP/F1-design.md b/doc/F1AP/F1-design.md
index 34c48a640c..5290426ea3 100644
--- a/doc/F1AP/F1-design.md
+++ b/doc/F1AP/F1-design.md
@@ -2,7 +2,7 @@
-
+
|
@@ -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