MME: Add support for Gn interface

[pespin]

Open5GS Release, Revision, or Tag

v2.6.0

Components and subsystems

MME

Proposed functionality

I'm creating this ticket to announce and track the implementation of a Gn (GTPv1C) interface in open5gs-mmed.
This should allow improved inter-RAT mobility between open5gs and (pre-Rel8) SGSNs not supporting the S4 (GTPv2C) interface. This is the case of osmo-sgsn for instance.

Related osmocom ticket: https://osmocom.org/issues/5759

External dependencies

No response

[pespin]

The idea is to reuse what we already have in open5gs/lib/gtp/v1/ and is being used in open5gs-smfd, and add a similar Gn interface to open5gs-mmed + required upper logic to do the handover, pass RIM messages SGSN<->UE, etc.

@acetcom I'm expecting no problem from your side on us adding this kind of feature, since it's a well-specified interface which shows up in usual network diagrams and modes of operations, correct?

I'll be extending with more information as I compile more information and get a clearer picture on the whole setup.

[acetcom]

@pespin

I'm glad to add such a feature to open5gs.

Thank you so much for your contribution.
Sukchan Lee

[pespin]

It seems mainly only the MME needs updating to have GERAN<->EUTRAN mobility (SMF too, but we already support Gn there). SGW is kept using GTPv2C to the MME, so it should be transparent to it whether mobility happens from/to GERAN or EUTRAN.

Reminder: GTPv1C is specified in TS 29.060

There's 2 main topics here for the Gn interface in MME:

NACC/RIM support:

• 3GPP TS 23.401, sections "5.6 Network Assisted Cell Change" and "5.15 RAN Information Management (RIM) procedures".
• Gn (GTPv1C) Messages to be implemented in MME: "7.5.14 RAN Information Management Messages"
• In theory there's no RIM sent GERAN->EUTRAN, only EUTRAN->GERAN. Hence, MME basically takes request from eNodeB (S1AP), prepares a GTPv1C "RAN Information Relay" message and sends it to whatever SGSN is configured in the config file. Upon receival, it sends it back to the eNodeB, that's all.

InterRAT-handover:

• The idea behind this system is that the MME looks to SGSNs around it as if it was another SGSN, so most of inter-SGSN handover explained in TS 23.060 apply, with the specific details of MME<-SGSN using Gn interface being specified in TS 23.401 "Annex D"
• Gn (GTPv1C) Messages to be implemented in MME (aside from RIM):
  -- Forward Relocation Request (Rx, Tx)
  -- Forward Relocation Response (Rx, Tx)
  -- Forward Relocation Complete (Rx, Tx)
  -- Forward Relocation Complete Ack (Rx, Tx)
  -- SGSN Context Request (Rx, Tx)
  -- SGSN Context Response (Rx, Tx)
  -- SGSN Context Acknowledge (Rx, Tx)

MME config files needs to be extended probably with following sections:

• Add "gn:" section with:
  -- local-ip GTPv1C address (bind() + listen()) (actually, reuse the existing gtpvc (GTPv2C) server and handle GTPv1C there? I need to remember what I did for SMF).
• Add "sgsn:" section (list) with:
  -- remote-ip GTPv1C address
  -- list of routes "remote-address: {RAI + CI}"

I'll first work on having the RIM part working, since it's far easier. After that, we can look at adding interRAT-handover support. I guess it will be about looking what's currently done for EUTRAN<->EUTRAN handover in MME and attach the GTPv1C/GERAN specifics there.

[pespin]

WIP branch here, in case somebody wants to track progress or add early comments:
main...pespin:open5gs:pespin/gn

I already have all config parsing, Gn socket setup, and GTPv1C message parsing code path up to specific Rx function for message RAN Information Relay. I now need to look at which S1AP message triggers RIM resolution from the UE/ENB to transmit a RAN Information Relay over GTPv1C to the configured SGSN.

[pespin]

I have RIM/NACC forwarding MME<--S1AP->MME<-GTPv1C->SGSN implemented in my branch (shares above).

Only tested working ECHO REQ + RESP with TTCN3 so far, hopefully we'll have tests for the above procedure soon. At that point I'll submit the PR for review + merge.
https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-mme-test-ogs/

[pespin]

I'm currently implementing the MME Gn interface (GTPv1C) SGSN Context Request/Response procedure to get cell reselection 4G<->2G working, where SGSN interacts with MME to exchange the knowledge on the existing bearers/session/pdp contexts so that the sessions at the PGW can be preserved when the UE switches to the new cell.
Work can be found here: https://github.com/pespin/open5gs/tree/pespin/gn

Related ticket with more information: https://projects.osmocom.org/issues/6294

[pespin]

Related child tickets:
#3020
#3021