Project

General

Profile

Actions

Feature #5759

open

Support for Mobility between SGSN (2G/3G) and S-GW (4G)

Added by laforge about 1 year ago. Updated 4 days ago.

Status:
Stalled
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
11/09/2022
Due date:
% Done:

70%

Spec Reference:

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

multi_rat_notes.txt multi_rat_notes.txt 8.92 KB dexter, 05/17/2023 12:21 PM
sgsn_and_epc_functions.jpg View sgsn_and_epc_functions.jpg 5.99 MB dexter, 06/13/2023 09:45 AM

Subtasks 5 (2 open3 closed)

OsmoPCU - Feature #6044: Extend osmo-pcu and related TTCN3 tests so that PacketCellChangeNotification is tested with 3G/4G cellsResolveddexter05/25/2023

Actions
Feature #6050: Add missing testcase to test GERAN originated RIM RAN information request towards a 4G cell (EUTRAN)Closeddexter06/02/2023

Actions
Feature #6095: osmo-sgsn: Use/validate RIM Routing Address (Discriminator) IE from RAN Information Relay msgResolveddexter07/12/2023

Actions
Feature #6139: test mobility between GERAN (OsmoPCU) and EUTRAN (Open5GS) end to end on real hardwareNewdexter08/22/2023

Actions
Feature #6294: Support GN/Gp interoperation procedures between SGSN and MMENewdaniel12/07/2023

Actions

Related issues

Related to OsmoSGSN - Feature #1585: Gn interface for inter-SGSN MM Context transferNew02/23/2016

Actions
Actions #1

Updated by laforge 9 months 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).

Actions #2

Updated by laforge 9 months 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

Actions #3

Updated by laforge 9 months ago

  • Assignee set to dexter
Actions #4

Updated by dexter 7 months ago

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.

Actions #5

Updated by dexter 6 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.

Actions #6

Updated by laforge 6 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.

Actions #7

Updated by pespin 6 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.

Actions #8

Updated by pespin 5 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

Actions #9

Updated by pespin 5 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

Actions #10

Updated by pespin 5 months ago

I have been working on GTPv1C/Gn/RIM support in open5gs-mmed here: https://github.com/open5gs/open5gs/compare/main...pespin:open5gs:pespin/gn
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

Actions #11

Updated by pespin 5 months ago

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

Actions #12

Updated by pespin 5 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.

Actions #13

Updated by laforge 5 months ago

  • Status changed from New to In Progress

this ticket should have been set to "in progress" months ago when the work on it started.

Actions #14

Updated by dexter 4 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)

Actions #15

Updated by pespin 3 months ago

  • Related to Feature #1585: Gn interface for inter-SGSN MM Context transfer added
Actions #16

Updated by dexter 2 months ago

  • Status changed from In Progress to Stalled
Actions #17

Updated by laforge 4 days 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)

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)