Enhancement of E1 and F1 documentation
- improved description of F1 and E1 operation on a local setup
This commit is contained in:
committed by
Robert Schmidt
parent
c8103f2905
commit
60ca77f83f
+21
-3
@@ -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.
|
||||
|
||||
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 =
|
||||
(
|
||||
@@ -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`.
|
||||
|
||||
|
||||
+6
-6
@@ -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,
|
||||
|
||||
Reference in New Issue
Block a user