first draft of code design documentation
This commit is contained in:
Laurent THOMAS
@@ -0,0 +1,168 @@
|
|||||||
|
<table style="border-collapse: collapse; border: none;">
|
||||||
|
<tr style="border-collapse: collapse; border: none;">
|
||||||
|
<td style="border-collapse: collapse; border: none;">
|
||||||
|
<a href="http://www.openairinterface.org/">
|
||||||
|
<img src="./images/oai_final_logo.png" alt="" border=3 height=50 width=150>
|
||||||
|
</img>
|
||||||
|
</a>
|
||||||
|
</td>
|
||||||
|
<td style="border-collapse: collapse; border: none; vertical-align: center;">
|
||||||
|
<b><font size = "5">F1 split design</font></b>
|
||||||
|
</td>
|
||||||
|
</tr>
|
||||||
|
</table>
|
||||||
|
# 1. Introduction
|
||||||
|
|
||||||
|
We use OpenAirInterface source code, and it's regular deployment scheme.
|
||||||
|
|
||||||
|
F1 specification is in 3GPP documents: TS 38.470 header document and all documents listed in chapter 2 References of TS 38.470.
|
||||||
|
|
||||||
|
This document explains how the source code works.
|
||||||
|
|
||||||
|
Offered features and deployment instructions are described in:
|
||||||
|
https://gitlab.eurecom.fr/oai/openairinterface5g/-/wikis/f1-interface
|
||||||
|
|
||||||
|
# 2. Common multi-threading architecture #
|
||||||
|
|
||||||
|
The CU and DU interfaces are based on ITTI threads (see oai/common/utils/ocp_itti/itti.md when it will be written, draft available: https://docbox.etsi.org/Workshop/2018/201812_ETSI_OAI/TRAINING/OPENCELLS_THOMAS.pdf)
|
||||||
|
|
||||||
|
All OAI upper layers use the ITTI framework to run isolated threads dedicated to one feature.
|
||||||
|
The lower layers adopt case by case specific software architecture.
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph TD
|
||||||
|
Linux[configuration file] --> APP[gNB_app_task]
|
||||||
|
Socks[Linux UDP] --> GTP[nr_gtpv1u_gNB_task]
|
||||||
|
APP --> CU
|
||||||
|
APP --> DU
|
||||||
|
A[Linux SCTP] -->|sockets| SCTP(OAI itti thread TASK_SCTP)
|
||||||
|
SCTP-->|TASK_NGAP| NG[ngap_gNB_task]
|
||||||
|
NG-->|TASK_SCTP| SCTP
|
||||||
|
SCTP-->|TASK_DU_F1| DU[F1AP_DU_task]
|
||||||
|
SCTP-->|TASK_CU_F1| CU[F1AP_CU_task]
|
||||||
|
CU-->|TASK_RRC_GNB| RRC
|
||||||
|
RRC -->|non ITTI| PHY[OAI L1+L2]
|
||||||
|
RRC -->|API calls to create tunnels| GTP
|
||||||
|
PHY --> |user plane| GTP
|
||||||
|
CU --> |TASK_GTPV1_U| GTP
|
||||||
|
DU --> |TASK_GTPV1_U| GTP
|
||||||
|
```
|
||||||
|
A "task" is a Linux thread running infinite waiting loop on one ITTI queue
|
||||||
|
|
||||||
|
app task manages the initial configuration
|
||||||
|
|
||||||
|
sctp task mamanges the SCTP Linux sockets
|
||||||
|
|
||||||
|
CU code runs in the task F1AP_CU_task. It stores it's private data context in a static variable. No mutex is used, as the single interface to CU ITTI tast in incoming ITTI messages. CU task is a single ITTI queue, but multiple CU could exist in one Linux process, using the "instance id" (called "module id" also) to create separate contextual information for each CU instance.
|
||||||
|
|
||||||
|
DU code runs in the task F1AP_DU_task. The design is similar to CU task
|
||||||
|
|
||||||
|
All GTP-U tunnels are managed in a Linux Thread, that have partially ITTI design:
|
||||||
|
|
||||||
|
1. tunnel creation/deletion is by C API functions direct calls (a mutex protects it)
|
||||||
|
2. outgoing packets are pushed in a ITTI queue to the gtp thread
|
||||||
|
3. incoming packets are sent to the tunnel creator using a C callback (the callback function is given in tunnel creation order). The callback should not block
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
# 3. CU F1AP messages #
|
||||||
|
|
||||||
|
## startup
|
||||||
|
|
||||||
|
CU thread starts when the CU starts. It opens listening socket on F1AP_PORT_NUMBER by sending the appropriate message to TASK_SCTP.
|
||||||
|
|
||||||
|
It will accept the first incoming connection on this port
|
||||||
|
|
||||||
|
## F1 SETUP
|
||||||
|
|
||||||
|
DU has connected, and sent this message.
|
||||||
|
|
||||||
|
The CU receives, decode it and send relevant information to RRC thread by message F1AP_SETUP_REQ
|
||||||
|
|
||||||
|
## F1 SETUP response
|
||||||
|
|
||||||
|
RRC sends two messages to CU F1 task: the information to encode the F1 setup response and a second message to encode F1AP_GNB_CU_CONFIGURATION_UPDATE
|
||||||
|
|
||||||
|
Upon reception of these two messages the CU task encodes and sends the messages to the DU
|
||||||
|
|
||||||
|
## UE entry
|
||||||
|
|
||||||
|
When CCH channel decoding finds a new UE identity, it call rrc_gNB_generate_RRCSetup() that will send F1AP_DL_RRC_MESSAGE to the CU task.
|
||||||
|
|
||||||
|
The CU encodes and sends to DU DLRRCMessageTransfer
|
||||||
|
|
||||||
|
## UE attach/detach
|
||||||
|
|
||||||
|
When rrc_gNB_process_RRCReconfigurationComplete() occurs, the RRC sends to CU task the message F1AP_UE_CONTEXT_SETUP_REQ. The CU task encodes the F1 message UEContextSetup and send it to the DU over F1AP.
|
||||||
|
|
||||||
|
This function rrc_gNB_process_RRCReconfigurationComplete() also creates the GTP-U user plane bearers.
|
||||||
|
|
||||||
|
## F1AP incoming messages
|
||||||
|
|
||||||
|
SCTP tasks sends a ITTI message SCTP_DATA_IND to the CU task.
|
||||||
|
|
||||||
|
A array of functions pointers and the F1AP standard identifier "procedureCode", the CU calls the appropriate function
|
||||||
|
|
||||||
|
Hereafter the most significant messages processing
|
||||||
|
|
||||||
|
### CU_handle_F1_SETUP_REQUEST
|
||||||
|
|
||||||
|
Transcodes information to the same message toward RRC (F1AP_SETUP_REQ)
|
||||||
|
|
||||||
|
### CU_handle_INITIAL_UL_RRC_MESSAGE_TRANSFER
|
||||||
|
|
||||||
|
Transcodes information to the same message toward RRC (NR_RRC_MAC_CCCH_DATA_IND)
|
||||||
|
|
||||||
|
### CU_handle_UL_RRC_MESSAGE_TRANSFER
|
||||||
|
|
||||||
|
Encode and send data to PDCP (calling pdcp_data_ind ()) for processing UL data.
|
||||||
|
|
||||||
|
# DU F1 Messages
|
||||||
|
|
||||||
|
## Startup
|
||||||
|
|
||||||
|
The task "gNB app" after rzading the configuration file, sends a first message F1AP_SETUP_REQ to DU task
|
||||||
|
|
||||||
|
Using this message, the uniq DU task (Linux Thread) creates a DU instance context memory space, calls SCTP task to create a socket to the CU.
|
||||||
|
|
||||||
|
When it receives from the SCTP task the socket creation success, the DU task encodes+sends the F1 setup message to the CU.
|
||||||
|
|
||||||
|
## F1AP_INITIAL_UL_RRC_MESSAGE
|
||||||
|
|
||||||
|
When MAC layer push UL data to DU task, the DU sends to CU the message InitialULRRCMessageTransfer
|
||||||
|
|
||||||
|
## F1AP_UL_RRC_MESSAGE
|
||||||
|
|
||||||
|
In case of SRB bearer, the RLC layer use this message to push rlc bearer payload to DU task, that forward to CU
|
||||||
|
|
||||||
|
## pdcp_data_ind
|
||||||
|
|
||||||
|
This function call in RLC, when it is a DRB will be replaced by F1-U transport to CU
|
||||||
|
|
||||||
|
## F1AP incoming messages
|
||||||
|
|
||||||
|
SCTP tasks sends a ITTI message SCTP_DATA_IND to the DU task.
|
||||||
|
|
||||||
|
A array of functions pointers and the F1AP standard identifier "procedureCode", the DU calls the appropriate function
|
||||||
|
|
||||||
|
Hereafter the most significant messages processing
|
||||||
|
|
||||||
|
### DU_send_F1_SETUP_RESPONSE
|
||||||
|
|
||||||
|
Decode the CU message, then encode a message to TASK_GNB_APP. The thread "APP" extracts the system information block and reconfigure the DU with: du_extract_and_decode_SI(), configure_gnb_du_mac()
|
||||||
|
|
||||||
|
### DU_handle_gNB_CU_CONFIGURATION_UPDATE
|
||||||
|
|
||||||
|
No developped
|
||||||
|
|
||||||
|
### DU_handle_UE_CONTEXT_SETUP_REQUEST
|
||||||
|
|
||||||
|
Push data to RLC layer for transmisstion in DL (to the UE) by calling enqueue_rlc_data_req()
|
||||||
|
|
||||||
|
### DU_handle_DL_RRC_MESSAGE_TRANSFER
|
||||||
|
|
||||||
|
Depending on the content, adds UE context in DU low layers and/or send data to the UE with rlc_data_req()
|
||||||
|
|
||||||
|
# F1-U messages
|
||||||
|
|
||||||
|
To be completed
|
||||||
Reference in New Issue
Block a user