Bug #5154
openOsmoSGSN doesn't trigger 3G paging if downlink GTP traffic arrives after long break
0%
Description
[unfortuantely this was in the sysmocom internal issue tracker, where it really didn't belong].
[16:43:57] <pespin> laforge: I really don't see how the GTP-U thing can ever work properly without the SGSN proxing the RNC<->GGSN conn
[16:44:06] <pespin> but reworking all that is probably a lot of work
[16:45:02] <pespin> there's no real way of having MT traffic working properly without proxying
[16:46:26] <pespin> at least when the mmctx MM_State_Iu goes into Idle state (RNC conn closed)
[16:48:15] <pespin> because then the only possibility is to send GTP-U data GGSN->SGSN (SGSN did PDpCtxUpdate beforehand to update the GSN addr to point to itself). And then either page and drop that packet and connect directly to the GGSN (so really shity link is established where 1st packet is always dropped), or keep proxying everything through the SGSN.
[16:48:49] <pespin> so in the end, for easiness and to avoid packet drops, it makes sense to ALWAYS proxy GTP-U traffic through SGSN
[16:49:40] <pespin> at least if one wants to support MT traffic after the RNC closed the conn
[16:50:20] <pespin> which is fine for usual cases where MS is submitting MO traffic usually, but fails for the specific case of receiving downlink data after a long idle period
So in order to be able to start paging the UE and create a new RAB, the SGSN will need to be aware of the first downlink GTP-U frame. And the only way to do that is to somehow insert itself [or a dedicated GTP-U proxy] into the user plane.
Related issues
Updated by laforge almost 3 years ago
- Related to Feature #5153: support hnbgw co-located GTP-U proxy (UPF) added
Updated by laforge almost 3 years ago
As I pointed out in #5153, this could be solved by a "SGW-U" or "UPF" network element, whcih is controlled via PFCP. One can think of it as a "MGW controlled by MGCP", which translates to "a SGW-U/UPF controlled by PFCP".
The SGSN would (all via PFCP)- create a session for each GTP-U tunnel that is established
- modify the session every time the RAB disappears, switchin the SGW-U/UPF into "queueing with notification of first DL packet"
- receive that notification from the SGW-U/UPF, triggering it to perform paging + RAB activation
- modify the session agian into forwarding mode once a RAB exists again
- using a standardized protocol that people understand
- using a wireshark dissector for analysis/debugging
- using the existing PFCP encoder/decoder in TITAN for TTCN-3 tests
- possibly interoperating with third-party SGW-U/UPF as there might be a need
- potential to use our SGW-U/UPF also in other use cases later on
There's also the theoretical option of just implementing PFCP and relying on a third-party SGW-U/UPF out there. For example, one could try to use the upf from open5gs, free5gc or OMEC. One would have to do an extensive analysis of its capabilities and performance to see if one of them can be used.
