Cellular Network Infrastructure » Core Network (CN) » OsmoSGSN

Side-note: I am not sure if this is related to the originally optional, but widely deployed Gs interface between the MSC and SGSN in 2G/3G networks. Osmocom not having this interface already caused some difficulty in the past, as far as I recall. SGs (which we do have) is basically a MME-derivative of that Gs interface.

There are multiple different options in the 3GPP architecture.

The classic approach is the Gn connectivity, where the SGSN differntiate s LTE-capable UE from non-LTE capable UE. The LTE-capable UEs PDP contexts must always be handed to the PGW, while the non-LTE-capale UEs PDP contexts can still be terminated in the GGSN. As a cheap version, one could of course simply terminate all PDP contexts in the PGW. At this point, the Gn (GTPv1C) capable PGW looks identical to a GGSN to the SGSN, and the SGSN remains unchanged.

The alterenative to the Gn-connectivity is to implement the S3 + S4 interface.

• provides control plane interface between SGSN and MME
• provides user plane interface between SGSN and S-GW
• enables ISR (Idle mode Signaling Reduction)

A true S4-SGSN is also replacing the MAP based interface to the HLR with a DIAMETeR based S6d interface to the HSS.

There's also the optional S12 interface (can be added to S3/S4), which is GTPv1-U passed directly from RNC to S-GW. S12 can be used with SThis is similar to our current approach of 3G support where the hNodeB or HNBGW (replacing the RNC) are feeding GTPv1-U directly to the GGSN (direct tunneling).

In terms of inter-RAT mobility between UTRAN, E-UTRAN and GERAN, there is

• E-UTRAN vs GERAN
  • HO SRVCC (CS) from E-UTRAN to GERAN (E-UTRA RRC connected to GSM connected state; out of scope here)
  • PS HO from E-UTRAN (RRC connected) to GERAN (GPRS packet transfer)
  • PS HO from GERAN (GPRS packet transfer) to E-UTRAN (RRC connected)
  • CCO + NACC from E-UTRAN (connected/DRX) to GERAN (packet_idle)
  • CCO + NACC rom GERAN (GPRS packet transfer) to E-UTRAN (RRC idle)
  • Cell Reselection from GRPS (Packet transfer mode or packet_idle) to E-UTRA (RRC idle)
  • Cell Reselection from E-UTRA (any state) to GERAN (packet_idle)

See also Section 3.1.3 of Inacon LTE Multi-RAT with 2G/3G inteworking

In general, the question is whether we want to add old GERAN/UTRAN interfaces to the modern EPC/5GC core, or whether we rather add new (EPC-style) interfaces to our GERAN/UTRAN core (which would be the S4-SGSN, AFAIR).

In general I would argue in favor of the latter (more future compatible, as over time it is more likely that smaller CN implementations will not have legacy interfaces). However, given that osmo-sgsn is suffering from a significant lack of resources for many years and has a variety of known internal problems, I'm not sure how realistic it would be in this specific instance. So Gn is likely the more realistic approach :/

dexter wrote in #note-5:

(One thing I find very confusing in general is that in the docs sometimes the architecture is described with network components (as we know them from 2G/3G) and sometimes the architecture is described using functions, which seems to be a completely different point of view. Also open5gs seems to be more or less function oriented.)

That's the difference if you look at a pre-rel-15(?) i.e. pre-5G-SA core network (classic EPC) or at a 5G SA network (service based architecture with functions)

Unfortunately the MME in open5gs does not have a Gn interface yet. We have to add that, which should not be all that difficult since pespin already has added a Gn interface to the open5gs SMF, so I have something that I can orient myself on. To test the Gn interface after we added it we can use the already existing MME tests osmo-ttcn3-hacks as a base to develop some testcases.

As discussed with dexter , the Gn interface SGSN<->MME is GTPv1C. The S3 interface SGSN<->MME is GTPv2c, and that's used in a so-called "S4-SGSN" afaiu, which we don't implement so far (that would mean implementing GTPv2C in osmo-sgsn).

Furthermore, in open5gs, we already have "full" Gn (GTPv1C) support in SMF, we only lack adding support for it in MME which should be a lot easier now since all message enc/dec is already there, plus required architectural changes to the project. One can have a look at my patches adding support to SMF which were merged a few months ago as a reference.

In osmo-sgsn, we already have a "mme" node and we have already a "remote-ip" defined for each, so I guess we are already connecting to them, hence not much work may be needed there.

I created this ticket in open5gs upstream project in order to discuss integration of the feature there: https://github.com/open5gs/open5gs/issues/2410

3GPP TS 23.401 "Annex D (normative): Interoperation with Gn/Gp SGSN"
https://www.etsi.org/deliver/etsi_ts/123400_123499/123401/16.13.00_60/ts_123401v161300p.pdf

See also sections from spec above:
- "5.5.2 Inter RAT handover", specially 5.5.2.3 and 5.5.2.4
- "5.6 Network Assisted Cell Change"
- "5.15 RAN Information Management (RIM) procedures"

Also interesting/related (2G<->3G): https://www.etsi.org/deliver/etsi_ts/123000_123099/123060/16.00.00_60/ts_123060v160000p.pdf

Also interesting/related(2g<->2g handover): https://www.etsi.org/deliver/etsi_ts/143100_143199/143129/16.00.00_60/ts_143129v160000p.pdf

• GTPv1C/Gn Rx Echo Req + Tx Echo Resp: Working, tested by ttcn3
• RIM/NACC forwarding EUTRAN->GERAN (and back): Implemented, not yet tested (dexter working on TTCN3 tests now).

Once the RIM side is tested, I'll submit the PR upstream to get it merged.

I also opened a bug report in wireshark since it lacks decoding the contents of GTPv1C "RIM Routing Address" IE due to existing dissector limitations:
https://gitlab.com/wireshark/wireshark/-/issues/19202

open5gs Gn RIM EUTRAN<->GERAN (MME<->SGSN) support submitted here: https://github.com/open5gs/open5gs/pull/2441

pespin wrote in #note-11:

open5gs Gn RIM EUTRAN<->GERAN (MME<->SGSN) support submitted here: https://github.com/open5gs/open5gs/pull/2441

Merged in open5gs.git 84ed7352042d2cc6d21a931476bdf3e7c360ae16..5c0c8ec4f288b3393482cd92235b0fc74fda7eda

I also started adding some bits for EUTRAN->GERAN interRAT handover in branch "pespin/gn" of open5gs.git.

Looking at this again today, it seems the minimal feature set for mobility between SGSN and MME we need is what is described in 3GPP TS 23.401 Annex D (normative): Interoperation with Gn/Gp SGSN as pespin pointed out in #5759#note-9

The specific case of a 2G/3G subscriber moving to LTE coverage is handled in D.3.6 Gn/Gp SGSN to MME Tracking Area Update. As can be seen, the MME needs to perform SGSN Context Request to the SGSN, the SGSN sends SGSN Context Response and the MME acknowledges that wtih SGSN Context Acknowledge.

The inverse procedure is D.3.5 Routing Area Update which is what happens if a UE moves from LTE to GSM/UMTS (also needed)