Feature #6294


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

Support GN/Gp interoperation procedures between SGSN and MME

Added by daniel 3 months ago. Updated about 1 month ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:
24.401 Annex D 3.5/3.6


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 from the MME.
Similarly the MME needs to request the SGSN context from the SGSN if it receives a Tracking Area Update from an unknown UE.

If this succeeds then the PDP context at the pgw needs to be modified.
See diagrams TS 23.401 D 3.5-1 and D 3.6-1 for details.


202312-rat.pcapng 202312-rat.pcapng 582 KB pespin, 12/13/2023 05:07 PM

Related issues

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

Actions #1

Updated by pespin 3 months ago

  • Description updated (diff)
Actions #2

Updated by pespin 3 months ago

Quick access to related originating ticket:
(this ticket is set as subtask and hence it doesn't show in the the usual place for related tickets, so putting it here as a comment so I can quickly reference it).

Actions #3

Updated by pespin 3 months ago

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

Updated by pespin 3 months ago

Seems like we'll need some sort of "Mapping a GUTI to a P-TMSI and an RAI" specified in TS 23.003 and
I think I will start with implementing the EUTRAN->GERAN scenario in open5gs-mmed, since I already have MME_Tests testcase doing the RIM EUTRAN->GERAN, so I can probably extend that test to do the missing parts. The following is needed in open5gs-mmed:

  • Rx SGSN Context Request (TS 23.003 sec
    • Convert rx PTMSI+RAI to GUTI.
    • "The old SGSN validates the old P-TMSI Signature and responds with an appropriate error cause if it does not
      match the value stored in the old SGSN."
    • "The old 3G SGSN responds with an SGSN Context Response (MM Context, PDP Contexts) message." The MME (old SGSN in this step)
      maps EPS bearers one-to-one to PDP contexts and provides the Release 99 parameters of the bearer QoS
      profile to the new SGSN. (2b)
    • "The MME (old SGSN in this step) only transfers the PDP Context(s). [...] If the PDP Context(s) of a PDN connection has
      not been transferred, the MME shall consider all bearers of that PDN connection as failed and release that PDN
      connection by triggering the MME requested PDN disconnection procedure specified in clause 5.10.3."
    • If the old P-TMSI Signature was valid, the MME starts a timer.
  • Rx SGSN Context Acknowledge from SGSN:
    • "THe MME marks in its context that the information in the GWs and the HSS are
      invalid. This triggers the GWs, and the HSS to be updated if the UE initiates a Tracking Area Update procedure
      back to the old MME before completing the ongoing Routing Area Update procedure."
  • Timer expiration:
    • "When the timer started in step 2) expires the old MME releases any RAN and Serving GW resources."
    • "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."

So the context is released at MME and SGW nodes, but kept at the PGW by means of MME->SGW using the "operation Indication" flag. I need to check if open5gs-sgwc support properly that flag.

If the reselection to GERAN fails, presumably the UE attempts TAU again in EUTRAN and hence if we have the "timer" active, we deactive it to avoid freeing the contexts when it expires.

TODO: Analysis of what's needed GERAN->EUTRAN on open5gs, 3GPP TS 23.401 "D.3.6 Gn/Gp SGSN to MME Tracking Area Update".

Actions #5

Updated by pespin 3 months ago

WIP for open5gs-mmed can be followed in this branch:

Actions #6

Updated by pespin 2 months ago

Attached test from daniel showcasing actual status with the failed TAU and then a regular Attach.

Actions #7

Updated by pespin 2 months ago

3GPP TS 33.401 9.1.1 seems to explain how to fill in the MME Context IE in GTPv1C SGSN Context Request Response.

If the UE sends the RAU Request with the "old P-TMSI" Information Element including mapped GUTI it shall also
include the KSI equal to the value of the eKSI associated with the current EPS security context (cf. clause 3). The UE
shall include a truncated NAS-token, as defined in this clause further below, into the P-TMSI signature IE. The MME
shall transfer UE's UTRAN and GERAN security capabilities and CK' || IK' with KSI equal to the value of the eKSI
associated with the current EPS security context to SGSN with Context Response/SGSN Context Response message.
Actions #8

Updated by pespin 2 months ago

I submitted a patch with an initial basic test to trigger the related procedures on open5gs-mmed: mme: Introduce test TC_ue_cell_reselect_eutran_to_geran

With the current implementation, I can get the Req + Resp with a filled in "PDP Context" IE, though some values are still not properly populated. My plan is to continue giving a look at "MME Context" IE in the same message (see my last comment above in this ticket for reference). My idea is to try to implement first as few as possible details to get the full procedure succeeding, or at least going through, so it can be used and tested properly with real phones. Trying to implement 100%-right of these procedures right now is overkill imho.

Once the big chunks of code are added for the procedures (4G->2G and 2G->4G) we can start looking at specific parts which need improvement or fixing.

Actions #9

Updated by pespin about 2 months ago

I'm now working on the 2G->4G path, and I'm facing an ecoding/decoding problem in S1AP/NAS I haven't yet been able to figure out.

Tracking Area Update Complete (3GPP TS 24.301 8.2.27) is 2 bytes long:

type record PDU_NAS_EPS_TrackingAreaUpdateComplete
  BIT4                             securityHeaderType,
  BIT8                             messageType

According to emm_state_initial_context_setup() in open5gs-mmed, it expects the TAU Complete security Header type to be integrity protected and/or encrypted. According to several references it should be at least integrity protected AFAIU.

void emm_state_initial_context_setup(ogs_fsm_t *s, mme_event_t *e)
            ogs_debug("[%s] Tracking area update complete", mme_ue->imsi_bcd);

         * TS24.301
         * Section
         * Integrity checking of NAS signalling messages in the MME:
         * Once the secure exchange of NAS messages has been established
         * for the NAS signalling connection, the receiving EMM or ESM entity
         * in the MME shall not process any NAS signalling messages
         * unless they have been successfully integrity checked by the NAS.
         * If any NAS signalling message, having not successfully passed
         * the integrity check, is received, then the NAS in the MME shall
         * discard that message. If any NAS signalling message is received,
         * as not integrity protected even though the secure exchange
         * of NAS messages has been established, then the NAS shall discard
         * this message.
            h.type = e->nas_type;
            if (h.integrity_protected == 0) {
                ogs_error("[%s] No Integrity Protected", mme_ue->imsi_bcd);

So, if I send it without being integrity protected nor encrypted, open5gs-mmed refuses it as per the code above.

    /* 3GPP TS 23.401 D.3.6 step 23: */
    /* Integrity Protection: TS 24.301 Section*/

If I send it using integrity protection (c_EPS_SEC_IP), then wireshark fails to decode it fine (Malformed packet) while open5gs-mmed seems to be OK with it.

I had to modify wireshark to allow properly decoding it:

diff --git a/epan/dissectors/packet-nas_eps.c b/epan/dissectors/packet-nas_eps.c
index 119577bbc6..cdc499bc28 100644
--- a/epan/dissectors/packet-nas_eps.c
+++ b/epan/dissectors/packet-nas_eps.c
@@ -6777,7 +6777,7 @@ dissect_nas_eps_emm_msg(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, int
         proto_tree_add_item_ret_uint(tree, hf_nas_eps_security_header_type, tvb, offset, 1, ENC_BIG_ENDIAN, &security_header_type);
         proto_tree_add_item(tree, hf_gsm_a_L3_protocol_discriminator, tvb, offset, 1, ENC_BIG_ENDIAN);
-        if (security_header_type != 0) {
+        if (security_header_type != 0 && len > 2) {
             /* Message authentication code */
             proto_tree_add_item(tree, hf_nas_eps_msg_auth_code, tvb, offset, 4, ENC_BIG_ENDIAN);

And then wireshark shows:

S1 Application Protocol
    S1AP-PDU: initiatingMessage (0)
            procedureCode: id-uplinkNASTransport (13)
            criticality: ignore (1)
                    protocolIEs: 5 items
                        Item 0: id-MME-UE-S1AP-ID
                        Item 1: id-eNB-UE-S1AP-ID
                        Item 2: id-NAS-PDU
                                id: id-NAS-PDU (26)
                                criticality: reject (0)
                                    Non-Access-Stratum (NAS)PDU
                                        0001 .... = Security header type: Integrity protected (1)
                                        .... 0111 = Protocol discriminator: EPS mobility management messages (0x7)
                                        NAS EPS Mobility Management Message Type: Tracking area update complete (0x4a)

The problem is that if Integrity Protected != 0, then wireshark expects to decode the following fields at the end, which are not there since they are not part of TAU Complete:

                                    Non-Access-Stratum (NAS)PDU
                                        0001 .... = Security header type: Integrity protected (1)
                                        .... 0111 = Protocol discriminator: EPS mobility management messages (0x7)
                                        Message authentication code: 0x5cd8ff63
                                        Sequence number: 0
                                        NAS EPS Mobility Management Message Type: Tracking area update complete (0x4a)

I also tried applying a double header with both set as Integrity protected, but wireshark still doesn't like it.

So either TTCN3, wireshark or open5gs-mmed is wrong, but I'm still not sure who's wrong there.... I'm a bit confused with the double header each having IP and encryption stuff tbh.

If someone has a pcap containing a full TAU (with TAU Complete) that would be useful, to see what a regular UE would do there.

Actions #10

Updated by pespin about 1 month ago

daniel the initial implementation of idle mobility 2G->4G has already been merged in open5gs upstream in, so initial implementation of both sides is now available in open5gs-mmed. Let me know if you need any further development there when you do some first tests.


Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)