Feature #5759
openSupport for Mobility between SGSN (2G/3G) and S-GW (4G)
70%
Description
Develop the interface for mobility between 2G/3G and 4G on the S-GW/SGSN level, allowing subscribers to switch seamlessly between 2G/3G and 4G coverage areas with minimal interruption.
Files
Related issues
Updated by laforge about 1 year ago
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.
The S4 interface (GTPv2-C) based between SGSN and S-GW handles the PS-HO from and to LTE.- 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).
Updated by laforge about 1 year ago
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
Updated by dexter about 1 year ago
- File multi_rat_notes.txt multi_rat_notes.txt added
I have put the focus on CCO/NACC at first, since this is less complex than PS HO. I have worked through the various network components and crated an overview on what has to be done to support CCO/NACC. Essentially this would be about getting the RIM support in the various components complete. In open5gs we have no RIM support yet, but the message decoding/encoding functions seem to be there. For more details see my attached notes.
I would recommend to start working on osmo-pcu and the related TTCN3 testsuite. osmo-pcu already has some CCO/NACC support but it seems only to understand requests that target a GERAN cell. We would need to extend this to UTRAN/EUTRAN cells.
Updated by dexter 11 months ago
For NACC/CCO with Gn Connectivity we would use a Gn interface from the SGSN towards the MME. The Ran Information request would then travel from the PCU via the Gb interface to the SGSN, from there it would be routed via a dedicated Gn interface to the MME. The MME would then route the request via S1-MME to the ENB to retrieve the RAN information and then the response would travel the whole way back. I have attached an image (sgsn_and_epc_functions.jpg) of the network architecture as I understand it at the moment.
(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.)
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.
Updated by laforge 11 months ago
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.
Updated by pespin 11 months ago
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.
Updated by pespin 11 months ago
I created this ticket in open5gs upstream project in order to discuss integration of the feature there: https://github.com/open5gs/open5gs/issues/2410
Updated by pespin 11 months ago
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
Updated by pespin 10 months ago
Current status:
- 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
Updated by pespin 10 months ago
open5gs Gn RIM EUTRAN<->GERAN (MME<->SGSN) support submitted here: https://github.com/open5gs/open5gs/pull/2441
Updated by pespin 10 months ago
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.
Updated by dexter 9 months ago
- % Done changed from 0 to 70
So far we have reached the following:
- Gn interface in Open5GS MME, supporting NACC/RIM
- TTCN3 testcase for Open5GS NACC/RIM support (see also #5760)
- Extended PacketCellChangeNotification, so that EUTRAN cells can be proposed as target cell (see also #6055)
- TTCN3 testcase for OsmoPCU to test NACC/RIM support (see also #6044)
We now need to verify that everything works end to end on real hardware (see also #6139)
Also we still need to complete the testsuite for Open5GS MME (see also #5760). We also plan to add testsuites for Open5GS SGW (and SMF/UPF)
Updated by pespin 8 months ago
- Related to Feature #1585: Gn interface for inter-SGSN MM Context transfer added
Updated by laforge 5 months ago
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)