Cellular Network Infrastructure » Core Network (CN) » OsmoSGSN

Quick access to related originating ticket: https://osmocom.org/issues/5759
(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).

Seems like we'll need some sort of "Mapping a GUTI to a P-TMSI and an RAI" specified in TS 23.003 2.8.2.1 and 2.8.2.2.
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 2.8.2.1.3):
  • 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".

WIP for open5gs-mmed can be followed in this branch:
https://github.com/pespin/open5gs/commits/pespin/gn

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.

I submitted a patch with an initial basic test to trigger the related procedures on open5gs-mmed:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/35386 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.

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)
{
        case OGS_NAS_EPS_TRACKING_AREA_UPDATE_COMPLETE:
            ogs_debug("[%s] Tracking area update complete", mme_ue->imsi_bcd);

        /*
         * TS24.301
         * Section 4.4.4.3
         * 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);
                break;
            }

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 4.4.4.3*/
    S1AP.send(ts_PDU_NAS_EPS_TrackingAreaUpdateComplete(c_EPS_SEC_NONE));

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);
         offset++;
-        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);
             offset+=4;

And then wireshark shows:

S1 Application Protocol
    S1AP-PDU: initiatingMessage (0)
        initiatingMessage
            procedureCode: id-uplinkNASTransport (13)
            criticality: ignore (1)
            value
                UplinkNASTransport
                    protocolIEs: 5 items
                        Item 0: id-MME-UE-S1AP-ID
                        Item 1: id-eNB-UE-S1AP-ID
                        Item 2: id-NAS-PDU
                            ProtocolIE-Field
                                id: id-NAS-PDU (26)
                                criticality: reject (0)
                                value
                                    NAS-PDU:
                                    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.

daniel the initial implementation of idle mobility 2G->4G has already been merged in open5gs upstream in https://github.com/open5gs/open5gs/pull/2888, 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.

fixeria wrote in #note-13:

Both testcases are currently failing:

• SGSN_Tests.TC_sgsn_context_req_in -- missing PDP Context IE
• SGSN_Tests.TC_sgsn_context_req_out -- sending of SGSN Context Request is not implemented in osmo-sgsn

I got SGSN_Tests.TC_sgsn_context_req_in passing:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36601/5..6/sgsn/SGSN_Tests.ttcn

The problem was that f_pdp_ctx_act() in SGSN_Tests does not assign any address to the MS by default.

Hi daniel , from reading Table 7.2.2-1 field "PDN Address Allocation (PAA)" I'd say it's not mandatory. It makes sense it isn't mandatory in that scenario since the PAA is already known by the MME (and the full point of the handover is to keep stuff like the IP address, anchored at the PGW).

Please, give a try again using a branch of mine containing a potential fix: https://github.com/sysmocom/open5gs/tree/pespin/mme

I meanwhile submitted it as a PR upstream but marked it as Draft wiating for your validation: https://github.com/open5gs/open5gs/pull/3167