Feature #5153

Updated by neels 8 months ago

In the current osmo-hnbgw implementation, we simply configure the hNB GTP-U data to go directly to the GGSN. SGSN. 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 


Add picture from clipboard (Maximum size: 48.8 MB)