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

Merge remote-tracking branch 'origin/gtpv1u-data-no-itti' into integration_2024_w50 (!3158)

Browse Source 
GTP: use direct call instead of ITTI

Using ITTI calls for user plane implies (1) a memory allocation, (2)
mutexes, and (3) queueing messages for each user plane packet, which is
heavy. Use a direct API call instead to reduce overhead.
This commit is contained in:
Robert Schmidt
2024-12-16 15:25:18 +01:00
parent 61849adf8b 27f1c0db65
commit 85440e2d4e
11 changed files with 71 additions and 101 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/F1AP/F1-design.md
+4 -4
View File
@@ -378,15 +378,15 @@ You might also want to consult TS 38.401 regarding the message exchange.
### General
In the DU in UL, RLC checks in `deliver_sdu()` if we are operating in split
mode, and either (direct) calls `pdcp_data_ind` (DRB) or (f1ap) sends an
`GTPV1U_TUNNEL_DATA_REQ` ITTI message to the GTP task.
mode, and either (direct) calls `pdcp_data_ind` (DRB) or (f1ap) sends a GTP
message through the GTP API.
In the CU in UL, assuming the tunnel is in place, GTP decapsulates the packet
and calls the callback `cu_f1u_data_req()`, which calls `pdcp_data_ind()` in CU.
In the CU in DL, the PDCP function `deliver_pdu_drb_gnb()` either (direct) calls
into the RLC via `enqueue_rlc_data_req()`, or (f1ap) sends a
`GTPV1U_TUNNEL_DATA_REQ` ITTI message to the GTP task.
into the RLC via `enqueue_rlc_data_req()`, or (f1ap) sends a GTP message
through the GTP API.
In the DU in DL, assuming the GTP-U tunnel exists, GTP decapsulates the packet
and calls the reception call back `du_rlc_data_req()`, which calls
doc/SW_archi.md
+1 -1
View File
@@ -338,7 +338,7 @@ On the Tx side (downlink in gNB), the entry functions `nr_pdcp_data_req_drb()` a
## PDCP Rx flow
At the Rx side, `pdcp_data_ind()` serves as the entry point for receiving data from RLC. Within `pdcp_data_ind()`, the PDCP manager mutex protects access to the PDU receiving function of PDCP (`recv_pdu()` callback corresponding to `nr_pdcp_entity_recv_pdu()` for DRBs). Following this, the `deliver_sdu_drb()` function dispatches the received data to the GTP thread via an ITTI message (`GTPV1U_TUNNEL_DATA_REQ`).
At the Rx side, `pdcp_data_ind()` serves as the entry point for receiving data from RLC. Within `pdcp_data_ind()`, the PDCP manager mutex protects access to the PDU receiving function of PDCP (`recv_pdu()` callback corresponding to `nr_pdcp_entity_recv_pdu()` for DRBs). Following this, the `deliver_sdu_drb()` function dispatches the received data to the SDAP sublayer.
## PDCP security