[MME] Gn: Introduce initial support for 4G->2G cell reselection #2817
Conversation
pespin
force-pushed
the
pespin/gn-pr
branch
2 times, most recently
from
43ff632
to
72379a6
Compare
In an Inter-RAT setup a UE could perform a RAU coming from a 4G network. In that case the UE/MS is unknown to the SGSN and it should request the SGSN context (MM, PDP) from the MME. This is done through the following GTPv1C message exchange on the Gn interface of SGSN and MME: SGSN -> MME: SGSN Context Request SGSN <- MME: SGSN Context Response SGSN -> MME: SGSN Context Acknowledge This commit doesn't aim to be a complete implementation of the mentioned procedure, since it's quite a complex one, with lots of fields and logic required. This so far only implements in general the minimally successful case by filling as much as possible the required set of fields. This will allow for a base onto which do incremental improvements and fixes while testing against UEs and SGSNs (such as osmo-sgsn, which doesn't yet support this procedure but will potentially earn it soon). This commit doesn't implement the reverse direction, aka UE issuing cell reselection 2G->4G. Initial support for this scenario will hopefully be added soon as a follow-up patch, similar to this one. Related: https://osmocom.org/issues/6294
| ogs_gtp_xact_t *xact, ogs_gtp1_sgsn_context_acknowledge_t *req) | ||
| { | ||
| /* FIXME: find out what to do here, 3GPP TS 23.401 D.3.5 | ||
| * Probably release the Session on the SGW (without releasing in the PGW) */ |
There was a problem hiding this comment.
@acetcom I plan to implement this part in a follow-up commit/PR, so that whoever implements SGSN side can already start interacting with open5gs once this PR is merged. in here I will need to implement the following below, any help/advice on how to accomplish it would be welcome. I don't know if there exists already some sort of FSM to tear down the entire bearer/session in both SGW and ENB:
"The old MME deletes the EPS bearer resources by sending Delete Session Request (Cause; Operation Indication,
Secondary RAT usage data) messages to the Serving GW". Set the "operation Indication" flag, which "indicates
to the old Serving GW that the old Serving GW shall not initiate a delete procedure towards the PDN GW."
Release session at the ENB: "If the old MME has an S1-MME association for the UE, the source MME sends a S1-U Release Command to the
source eNodeB when receiving the SGSN Context Acknowledge message from the new SGSN. The RRC
connection is released by the source eNodeB. The source eNodeB confirms the release of the RRC connection
and of the S1-U connection by sending a S1-U Release Complete message to the source MME."
FYI this comes from 3GPP TS 23.401 Annex D.3.5 "Routing Area Update"
|
@acetcom I submitted a bunch of preparation PRs fixing and improving several things in existing code. Once those are merged, I'll submit a new version of this PR. |
In an Inter-RAT setup a UE could perform a RAU coming from a 4G network. In that case the UE/MS is unknown to the SGSN and it should request the SGSN context (MM, PDP) from the MME. This is done through the following GTPv1C message exchange on the Gn interface of SGSN and MME: SGSN -> MME: SGSN Context Request
SGSN <- MME: SGSN Context Response
SGSN -> MME: SGSN Context Acknowledge
This commit doesn't aim to be a complete implementation of the mentioned procedure, since it's quite a complex one, with lots of fields and logic required. This so far only implements in general the minimally successful case by filling as much as possible the required set of fields.
This will allow for a base onto which do incremental improvements and fixes while testing against UEs and SGSNs (such as osmo-sgsn, which doesn't yet support this procedure but will potentially earn it soon).
This commit doesn't implement the reverse direction, aka UE issuing cell reselection 2G->4G. Initial support for this scenario will hopefully be added soon as a follow-up patch, similar to this one.
Related: https://osmocom.org/issues/6294