Enhancement of E1 and F1 documentation

- improved description of F1 and E1 operation on a local setup

doc/E1-design.md

@@ -53,11 +53,29 @@ The files that implement the callback towards these handlers are in
 
 # 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](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop/doc/F1-design.md) for the mutual configuration of DU and the E1 CUCP-CUUP split.
+
 ## 2.1 Configuration File
 
-The gNB is started based on the node type that is specified in the configuration file. To start a gNB instance in CUCP or CUUP, the `tr_s_preference` should be set to "f1" and the config member `E1_INTERFACE` should be present in the config file. The `type` parameter within the `E1_INTERFACE` should be set to `cp`, and executable `nr-softmodem` should be used to run a CU-CP. The type should be `up` and executable `nr-cuup` should be used to run the CU-UP. Further, there are the parameters `ipv4_cucp` and `ipv4_cuup` to specify the IP addresses of the respective network functions.
+The gNB is started based on the node type that is specified in the configuration file. The following parameters must be configured accordingly.
+
+On either CUCP and CUUP:
+* The southbound transport preference `gNBs.[0].tr_s_preference` set to `f1`
+* config section `E1_INTERFACE` should be present
+
+On the CU-CP:
+* `type` parameter within the `E1_INTERFACE` should be set to `cp`
+
+On the CU-UP:
+* `type` parameter within the `E1_INTERFACE` should be set to `up`
+
+Executables:
+* executable `nr-softmodem` to run a CU-CP
+* executable `nr-cuup` to run the CU-UP
+
+In the `E1_INTERFACE` configuration section, the parameters `ipv4_cucp` and `ipv4_cuup` must be configured to specify the IP addresses of the respective network functions.
 
-For CUCP, a typical `E1_INTERFACE` config looks like
+For CUCP, a typical `E1_INTERFACE` config looks like:
 ```
 E1_INTERFACE =
 (
@@ -82,7 +100,7 @@ E1_INTERFACE =
 ```
 One could take an existing CU configuration file and add the above parameters to run the gNB as CUCP or CUUP.
 
-The CUUP uses the IP address specified in `local_s_address` for F1-U and `GNB_IPV4_ADDRESS_FOR_NGU` for N3 links. Note that `local_s_address` is under `gNBs` and `GNB_IPV4_ADDRESS_FOR_NGU` is part of the `NETWORK_INTERFACES` config member.  
+The CUUP uses the IP address specified in `gNBs.[0].local_s_address` for F1-U and `GNB_IPV4_ADDRESS_FOR_NGU` for N3 links. Note that `local_s_address` is under `gNBs` and `GNB_IPV4_ADDRESS_FOR_NGU` is part of the `NETWORK_INTERFACES` config member.
 
 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`.
 

doc/F1-design.md

@@ -27,8 +27,8 @@ are supported. Mobility over F1 is not yet supported.
 
 ## Implementation Status
 
-Note that OAI uses F1 "internally". That means, that even if you run a
-monolithic gNB, the internal information exchange uses F1. You can therefore
+Note that OAI uses F1 "internally". That means, that even **if you run a
+monolithic gNB, the internal information exchange uses F1**. You can therefore
 expect that everything working in a monolithic deployment should also work in
 F1.  The current implementation is based on R16.3.
 
@@ -118,13 +118,13 @@ see [this `docker-compose` file](../ci-scripts/yaml_files/5g_f1_rfsimulator/dock
 
 The rules to decide if a config triggers a start of a DU, CU, or monolithic
 gNB, are, in order:
-1. If the `MACRLCs` section lists `f1` as northbound transport preference
+1. If the `MACRLCs` section lists `f1` as **northbound transport preference**
    (`tr_n_preference`), it is a DU.
-2. If the `gNBs` section lists `f1` as a southound transport preference
+2. If the `gNBs` section lists `f1` as a **southound transport preference**
    (`tr_s_preference`), it is a CU.
 3. It is a (monolithic) gNB.
 
-## Configuration of F1 IP/port information
+## Local network deployment of F1
 
 For a local deployment, you should update the following fields.
 We assume that the CU will bind on `192.168.70.129` towards the core,