Bug #5154


OsmoSGSN doesn't trigger 3G paging if downlink GTP traffic arrives after long break

Added by laforge almost 3 years ago. Updated almost 3 years ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


[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

Related to OsmoHNBGW - Feature #5153: support hnbgw co-located GTP-U proxy (UPF)In Progressneels05/13/2021

Actions #1

Updated by laforge almost 3 years ago

  • Related to Feature #5153: support hnbgw co-located GTP-U proxy (UPF) added
Actions #2

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
By using PFCP instead of some custom ad-hoc protocol, we'd gain
  • 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.


Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)