Enhancement of E1 and F1 documentation

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

doc/F1-design.md

@@ -20,15 +20,15 @@ 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
 standardized in TS 38.470 - 38.473 for 5G NR. No equivalent for 4G exists.
 
-We assume that each DU handles only one cell.  Multiple DUs connected to one CU
+We assume that each DU handles only one cell. Multiple DUs connected to one CU
 are supported. Mobility over F1 is not yet supported.
 
 # Control plane status (F1-C)
 
 ## 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,