From 6a2b312a866138f9a49e72ea9f54ad9e49fce6c4 Mon Sep 17 00:00:00 2001 From: Thomas Laurent Date: Tue, 3 Aug 2021 07:55:07 +0000 Subject: [PATCH] Update SW_archi.md --- doc/SW_archi.md | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/doc/SW_archi.md b/doc/SW_archi.md index e5856d63bc..1f7993950d 100644 --- a/doc/SW_archi.md +++ b/doc/SW_archi.md @@ -312,17 +312,20 @@ Current status of new implementation: not tested, X2 not developped, 5G new GTP 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() this function will replace the xxx_create_tunnel_xxx() for various cases -This creates a outgoing context for a teid (in input), it computes and return the incoming teid that will be used for incoming packets -These teids and in a "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 -stuff like enb_flag, but also 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. -The datamodel is still not fully understood, so this data source remain unknown -A new parameter is the callback function: will be pdpcp_data_req() and gtpv_data_req() (x2 case) for existing implementation and later other call backs like the F1-U implementation. +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 -incoming packets -the gtp layer retrieves the data, the teid, find out the related data: rnti, bearer and quite a lot of other parameters (not clear why, because it looks like all is statefull, so the lower layer should have the context) -if lower layers can be stateless, it is a good idea to keep the context in the gtp layer and pass it to the callback, but the design remain obfuscated. +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. + +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. + +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 # NGAP NGAP would be a itti thread as is S1AP (+twin thread SCTP that is almost void processing)?