Cellular Network Infrastructure » Core Network (CN) » OsmoGGSN (former OpenGGSN)

See TS 29.060 and grep for "Direct Tunnel Flags", " EI ", and "DTI".

If the Direct Tunnel Flags IE is included and if the DTI bit of the Direct Tunnel Flags IE is set to 1, this indicates to the
GGSN that for this PDP Context the SGSN is invoking a direct tunnel. In this case, the GGSN shall not change the
allocated userplane Tunnel Endpoint Identifier Data and IP address in the corresponding Update PDP Context Response
message.If the DTI bit of the Direct Tunnel Flags IE is set to 0 or the Direct Tunnel Flags IE is absent, this indicates to
the GGSN that for this PDP Context the SGSN is not invoking a direct tunnel. All other fields of the Direct Tunnel
Flags IE shall be ignored.

This information element [Tunnel Endpoint Identifier Data] shall be included if the Cause contains the value
"Request accepted" and may contain a new Tunnel Endpoint Identifier Data only if DTI bit of the Direct Tunnel Flags
IE is set to 0 or the Direct Tunnel Flags IE is absent in the corresponding Update PDP Context Request.

An Update PDP Context Request may also be sent from a GGSN to an SGSN:
...
- when a direct tunnel is used and the GGSN receives an Error Indication message from the RNC. In such a case,
the GGSN shall include the NSAPI IE and the Direct Tunnel Flags IE with the EI bit set; orNOTE 2: SGSN
and GGSN behaviour for RNC failure and recovery is defined in 3GPP TS 23.007 [3]

My understanding so far is that "Direct Tunnel" is "an optional extension/feature" to 2-tunnel (2g-like) approach, since under some circumstances traffic can still flow SGSN<->GGSN:

• Immediately after context creation (between CreatePdpContext and UpdatePdpContext once the RAB GTP side has been confirmed), see https://i0.wp.com/mobilepacketcore.com/wp-content/uploads/2018/11/teid-dt.png?w=1011&ssl=1
• After RAB context destroyed in RAN: 3GPP TR 23.919 6.1 SGSN:
  

  Further, when a Direct Tunnel was in use and the RAB assigned for a PDP context is released
  (i.e. the PDP context is preserved) the GTP-U tunnel is (re)established between the GGSN and SGSN in order to be
  able to handle the downlink packets.
  

In summary the Direct Tunnel works:

• SGSN -> GGSN: Create PDP Context Request (using SGSN's addr+localTEI)
• (SGSN does assignment towards RAN, get RAN GTPU addr+TEI)
• SGSN -> GGSN: UpdatePDPContext REquest (with RAN's GTPU addr+TEI, with "Direct Tunnel Flags" DTI=1). This way GGSN knows/differentiates SGSN and RNC addr+TEI.
• RNC -> GGSN: Error Indication. GGSN knows it's from RNC, hence it sends an UpdatePDPContext Request to SGSN address with NSAPI and "Direct Tunnel Flags" EI=1. This way SGSN knows it needs to recreate the tunnel towards RAN. See also 3GPP TS 23.007 15.2 "RNC/BSC Failure (Iu mode)".

libgtp didn't even decode those yet.
I submitted initial encoding/decoding of "Direct Tunnel Flags" in UpdatePDPContextReq/Resp here:
remote: https://gerrit.osmocom.org/c/osmo-ggsn/+/37594 gtp: Allow tx Direct Tunnel Flags in UpdatePDPCtx{Req,Resp} [NEW]
remote: https://gerrit.osmocom.org/c/osmo-ggsn/+/37595 gtp: Store rx Direct Tunnel Flags in UpdatePDPCtx{Req,Resp} [NEW]

OsmoSGSN was not setting the "Direct Tunnel Flags" DTI=1 during UpdatePDPContextReq until recent patches I submitted here:
https://gerrit.osmocom.org/c/osmo-sgsn/+/37596 gtp: Set Direct Tunnel Flags DTI during UpdatePDPCtx

1. Update TTCN3 GGSN_Tests to properly set DTI=1 when needed during UpdatePDPCtxReq. Investigate how osmo-ggsn behaves once it receives it (gaining knowledge about RNC IP address, etc. MAKE SURE GGSN DOESN'T CHANGE LOCAL IP_ADDR+TEID IN THIS SCENARIO!)
2. Write TTCN3 GGSN_Tests test: send ErrorIndication from RNC GTPU to GGSN. Then GGSN should send UpdatePDPContextReq "Direct Tunnel Flags" DTI=1 EI=1 to SGSN.

We probably need the same fixes/implementations in open5gs-smfd+upfd.