Hi,
I'm currently looking into extending the libgtp interface to support Gn. Gn will be used between a SGSN and a MME to transfer UE state. This allows a UE to have mobility between 2G/3G network served by an SGSN and a 4G network served by an MME.
It is based on GTPv1 TS 29.060 and to simply contains 3 PDUs: - 7.5.3 SGSN Context Request, - 7.5.4 SGSN Context Response - 7.5.5 SGSN Context Ack
It can work in both direction for UE from 2G to 4G as well 4G to 2G. The SGSN Context Request creates its own GTP session by exchanging a TEID-C in the SGSN Req + Resp. E.g.:
MME -> SGSN: SGSN Context Request (TEID 0, new TEID A) MME <- SGSN: SGSN Context Response (TEID A, new TEID B) MME -> SGSN: SGSN Context Ack (TEID B)
But the API of libgtp is currently very high level, except for RAN Info Relay, a user doesn't interact with the GTP TLVs, instead it is using a struct and converts between each other. Libgtp was developed with GTPv0/v1 in mind to support requesting PDP Context for 2G (and later got extended to support 3G). Also the SGSN Context Response contains a very long list of optional TLVs (e.g. 27 in Rel 12), some of the TLVs also contain nested TLVs.
So what is the right direction?
Should I create a new high level API, parse only the 3-4 TLVs the SGSN will use into a `struct sgsn_response`? Also the state tracking of a request would be tracked then by GTP and passed as identifier to it.
Or it could pass it to the SGSN and the SGSN has to take care of everything (except general message and tlv validation, parsing)?
Best, lynxis
Hi,
On 10/22/24 3:22 PM, Alexander 'lynxis' Couzens wrote:
So what is the right direction?
IMHO the right direction is to have a libosmo-gtp.git repository which contains: libosmo-gtpv1c.so libosmo-gtpv2c.so
It should be pretty similar to what nowadays you can find in https://github.com/open5gs/open5gs/tree/main/lib/gtp/ .
As in there, I really really vote for generating the TLVs as it's done in there, parsing the 3GPP docx (I actually wrote the script to generate the v1 subdir structs there iirc). See https://github.com/open5gs/open5gs/tree/main/lib/gtp/v1/support/ .
Then, on top/aside of that add some APIs to have some data domain with some structs (private structs, public APIs!) to handle peers, retransmission state, etc. like done in path.c and xact.c. Also add some VTY to declare and configure nodes like done in eg. libosmo-sigtran.
There's already a ticket to do this btw, see https://osmocom.org/issues/6518 .
Should I create a new high level API, parse only the 3-4 TLVs the SGSN will use into a `struct sgsn_response`?
We should really end up dropping libgtp, that's really a dead end and will only cause us many many problems as we try to improve it imho. So I'm all in favour of a new libosmo-gtp as mentioned above.
I think it's fine for first develop the library inside a subdir of osmo-sgsn.git or osmo-ggsn.git as a independent static library and later on once used properly make it a public shared object inside its own git repository.
Start by taking the python script, putting it eg. in osmo-sgsn.git/libosmo-gtp/support/ and generating code using libosmocore dependencies.
Regards, Pau
osmocom-net-gprs@lists.osmocom.org
-
Alexander 'lynxis' Couzens -
Pau Espin Pedrol