Commit 5fb151e1 authored by Robert Schmidt's avatar Robert Schmidt

Rework E1 documentation

parent eb475f77
......@@ -2,38 +2,55 @@
# 1. Introduction
E1 is named for the interface that lies between the nodes CU Control Plane (CUCP) and CU User Plane (CUUP). Once the nodes are configured, all user plane traffic flows through CUUP.
E1 is the interface that lies between the nodes CU Control Plane (CUCP) and CU User Plane (CUUP). Once the nodes are configured, all user plane traffic flows through CUUP.
The E1 design in OAI follows the 3GPP specification in TS 38.460. The code design on E1 in OAI is very similar to
F1. The ITTI message passing mechanism is used to exchange messages between E1AP thread, SCTP thread and RRC thread.
The following sequence chart shows the current E1AP message flow.
The E1 design in OAI follows the 3GPP specification in TS 38.460/463. The code
design on E1 in OAI is very similar to F1: OAI uses E1 internally to set up
bearers, even in monolithic gNB, where the actual "way" the messages are passed
is abstracted through function pointers. More specifically, there are handlers
that handle the E1 messages as shown below, *which are the same* no matter if
the CU is integrated or separate in CU-CP/UP. The below sequence diagram lists
the handlers that are executed and the current E1AP message flow (SCTP
connection setup only in split-mode, the rest is the same for CU):
```mermaid
sequenceDiagram
participant c as CUCP
participant u as CUUP
u->>c: SCTP new association
c->>u: SCTP new association response
Note over u: Create UDP sockets for F1-U and N3
u->c: SCTP connection setup (in split mode)
u->>c: E1AP Setup Request
Note over c: Execute rrc_gNB_process_e1_setup_req()
c->>u: E1AP Setup Response
Note over c: Receives PDU session setup request from AMF
c->>u: Bearer Context Setup Request
Note over u: Configure DRBs and create GTP Tunnels for F1-U and N3
Note over u: Execute e1_bearer_context_setup()<br/>Configure DRBs and create GTP Tunnels for F1-U and N3
u->>c: Bearer Context Setup Response
Note over c: Sends F1-U UL TNL info to DU and receives DL TNL info
Note over c: Execute rrc_gNB_process_e1_setup_req()<br/>Sends F1-U UL TNL info to DU and receives DL TNL info
c->>u: Bearer Context Modification Request
Note over u: Updates GTP Tunnels with received info
Note over u: Execute e1_bearer_context_modif()<br/>Updates GTP Tunnels with received info
u->>c: Bearer Context Modification Response
Note over c: Execute rrc_gNB_process_e1_bearer_context_modif_resp()
Note over c: UE release triggered
c->>u: Bearer Context Release Request
Note over u: Execute e1_bearer_release_cmd()<br/>Frees GTP tunnels, PDCP data etc
u->>c: Bearer Context Release Complete
Note over c: Execute rrc_gNB_process_e1_bearer_context_release_cplt()
```
_Note that the E1 bearer release procedures are currently not implemented._
The files that implement the callback towards these handlers are in
- `cucp_cuup_direct.c`: integrated CU (for CP=>UP messages)
- `cucp_cuup_e1ap.c`: E1 split mode (for CP=>UP messages)
- `cuup_cucp_direct.c`: integrated CU (for UP=>CP messages)
- `cuup_cucp_e1ap.c`: E1 split mode (for UP=>CP messages)
# 2. Running the E1 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 `nr-softmodem` should be used to run a CU-CP. The type should be `up` and `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. 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.
For CUCP, a typical `E1_INTERFACE` config looks like
```
......@@ -62,7 +79,7 @@ One could take an existing CU configuration file and add the above parameters to
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.
Alternatively, you can use the config files `ci-scripts/conf_files/gnb-cucp.sa.conf` and `ci-scripts/conf_files/gnb-cuup.sa.conf` which are already in the repository.
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`.
## 2.2 Steps to Run the Split in rfsimulator with OAI UE
......@@ -73,7 +90,7 @@ Note: A 5G core must be running at this point. Steps to start the OAI 5G core ca
1. Start the CUCP first by running the following command
```
sudo ./nr-softmodem -O ../../../ci-scripts/conf_files/gnb-cucp.sa.conf --gNBs.[0].min_rxtxtime 6 --sa
sudo ./nr-softmodem -O ../../../ci-scripts/conf_files/gnb-cucp.sa.f1.conf --gNBs.[0].min_rxtxtime 6 --sa
```
Note that `min_rxtxtime` should be set to `6` only when you are connecting an OAI UE to the gNB.
......@@ -82,7 +99,7 @@ Note that `min_rxtxtime` should be set to `6` only when you are connecting an OA
CUUP (has its own executable):
```
sudo ./nr-cuup -O ../../../ci-scripts/conf_files/gnb-cuup.sa.conf --sa
sudo ./nr-cuup -O ../../../ci-scripts/conf_files/gnb-cuup.sa.f1.conf --sa
```
DU:
......@@ -106,3 +123,25 @@ You can also run the nodes on different machines. If you do so please change the
![E1/F1/NG parameters](images/e1-archi.png){width=1200}
[PDF version](images/e1-archi.pdf) | [LaTeX/TikZ version](img/e1-archi.tex) if you want to modify to reflect your setup
# 4. Multiple CU-UP
It is possible to connect multiple CU-UP to the same CU-CP. In the handler of
the E1 Setup Request, the CU-CP verifies that the PLMN(s) (MCC, MNC) between
both nodes match, and that no CU-UP with the same ID exists. Note that the
NSSAIs for the CU-UPs can be different.
During attach, the following rules are used to select a CU-UP at the CU-CP, in
order:
- Select a CU-UP based on slice identifiers:
- If both the SST and SD match exactly, that CU-UP is selected. (If multiple
have the same NSSAI, the first is always selected.)
- Otherwise, the first CU-UP with the same SST but different SD is selected.
- Round-robin across all CU-UPs.
- The first CU-UP.
- If no CU-UP is selected, the CU-CP asserts.
Note that CU-UPs are not released from CU-CP internal structures. That means
that you have to restart the CU-CP if you want to connect the CU-UP again
(e.g., after a crash). The CU-CP might also misfunction during attach if a
CU-UP was connected, but disconnected in the meantime.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment