maki/openairinterface5g
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Enhancement of E1 and F1 documentation

Browse Source 
- improved description of F1 and E1 operation on a local setup
This commit is contained in:
Guido Casati
2024-01-25 17:10:52 +01:00
committed by Robert Schmidt
parent c8103f2905
commit 60ca77f83f
2 changed files with 27 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/E1-design.md
+21 -3
View File
@@ -53,11 +53,29 @@ The files that implement the callback towards these handlers are in
# 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](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 ## 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.
For CUCP, a typical `E1_INTERFACE` config looks like 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:
``` ```
E1_INTERFACE = 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. 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`. 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
+6 -6
View File
@@ -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 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. 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. are supported. Mobility over F1 is not yet supported.
# Control plane status (F1-C) # Control plane status (F1-C)
## Implementation Status ## Implementation Status
Note that OAI uses F1 "internally". That means, that even if you run a 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 monolithic gNB, the internal information exchange uses F1**. You can therefore
expect that everything working in a monolithic deployment should also work in expect that everything working in a monolithic deployment should also work in
F1. The current implementation is based on R16.3. 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 The rules to decide if a config triggers a start of a DU, CU, or monolithic
gNB, are, in order: 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. (`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. (`tr_s_preference`), it is a CU.
3. It is a (monolithic) gNB. 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. 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, We assume that the CU will bind on `192.168.70.129` towards the core,