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

Update SW_archi.md

Browse Source
This commit is contained in:
Thomas Laurent
2021-08-03 07:59:42 +00:00
parent 6a2b312a86
commit 609ea60774
1 changed files with 17 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/SW_archi.md
+17 -9
View File
@@ -304,28 +304,36 @@ gtpv1u_create_s1u_tunnel(), delete tunnel, ... functions are called inside the o
# New GTP
## initialization
Coexistance until full merge with legacy GTP
cmake new option: NEW_GTPU to use the new implementation (it changes for the entire executable)
It is possible to use both old and new GTP in same executable because the itti task and all functions names are different
Current status of new implementation: not tested, X2 not developped, 5G new GTP option not developped, remain issues on data coming from void: muid, enb_flag, ...
ocp_gtpv1uTask(): this creates only the thread, doesn't configure anything
gtpv1Init(): creates a listening socket to Linux for a given reception and select a local IP address
newGtpuCreateTunnel()
## newGtpuCreateTunnel()
this function will replace the xxx_create_tunnel_xxx() for various cases
The parameters are:
1. outgoing TEid, associated with outpoing pair(rnti, id)
2. incoming packets callback, incoming pair(rnti,id) and a callback function for incoming data
This function creates a outgoing context for a teid (given as function input), a pair(rnti,outgoing id). Each outgoing packet received on GTP-U ITTI queue must match one pair(rnti,id), so the gtp-u thread can lookup the related TEid and use it to encode the outpoing GTP-U tunneled packet.
## outgoing packets
Each call to newGtpuCreateTunnel() creates a outgoing context for a teid (given as function input), a pair(rnti,outgoing id).
Each outgoing packet received on GTP-U ITTI queue must match one pair(rnti,id), so the gtp-u thread can lookup the related TEid and use it to encode the outpoing GTP-U tunneled packet.
## incoming packets
newGtpuCreateTunnel() computes and return the incoming teid that will be used for incoming packets.
When a incoming packet arrives on this incoming teid, the GTP-U thread calls the defined callback, with the associated pair(rnti, incoming id).
It also computes and return the incoming teid that will be used for incoming packets.
When a incoming packet arrives on this incoming teid, the GTP-U thread calls the defined callback, with the associated pair(rnti, incoming id).
stuff like enb_flag, mui and more important data are not given explicitly by any legacy function (gtpv1u_create_s1u_tunnel), but the legacy and the new interface to lower layer (like pdcp) require this data. We hardcode it in first version.
## remaining work
These teids and "instance", so in a Linux socket: same teid can co-exist for different sockets
Remain here a lack to fill: the information given in the legacy funtions is not enough to fullfil the data needed by the callback
Remain here a lack to fill: the information given in the legacy funtions is not enough to fullfil the data needed by the callback
Coexistance until full merge with legacy GTP
cmake new option: NEW_GTPU to use the new implementation (it changes for the entire executable)
It is possible to use both old and new GTP in same executable because the itti task and all functions names are different
Current status of new implementation: not tested, X2 not developped, 5G new GTP option not developped, remain issues on data coming from void: muid, enb_flag, ...
# NGAP
NGAP would be a itti thread as is S1AP (+twin thread SCTP that is almost void processing)?