Feature #5153


support hnbgw co-located GTP-U proxy (UPF)

Added by laforge over 1 year ago. Updated 19 days ago.

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


Spec Reference:


In the current osmo-hnbgw implementation, we simply configure the hNB GTP-U data to go directly to the GGSN. This requires IP-level routing between the RAN and the CN, which is possible in most lab situations, but not possible in real operator networks.

So we'd need to add support for a GTP-U proxy to control a co-located osmo-mgw. That proxy would translate GTP flows on the RAN side to GTP flows on the CN side (each with their own IPs/TEIDs).

The problem faced here is a 1:1 identical situation to what we're facing in OsmoSGSN in #5154. So both should then be able to use that same GTP-U proxy component.

Further brainstorming about this problem revealed that we're actualy talking about the same as the "SGW-U" network element described in 3GPP TS 23.214, which is what 3GPP invented when they introduced the control/user plane separation into the 4G EPC.

The SGW-U is exactly a GTP-U proxy between the RAN and the CN side, and it even includes functions for buffering GTP-U packets during mobility related GTP-U tunnel modification. It also includes functions for notifying the control plane entity of the first downlink packet received (so it can trigger paging). The SGW-U is controlled by the PFCP protocol. Only very few features of PFCP are required (PFCP is also used for he PGW-U which is much more complex).

So in fact, what we'd have to implement is
  • a minimalistic SGW-U with PFCP suport
  • functionality in osmo-hnbgw to control that SGW-U via PFCP

Related issues

Related to OsmoSGSN - Bug #5154: OsmoSGSN doesn't trigger 3G paging if downlink GTP traffic arrives after long breakNew05/13/2021

Related to OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyingResolveddaniel05/13/2021


Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)