9.3 Inter-system mobility
38.523-13GPP5GSPart 1: ProtocolRelease 17TSUser Equipment (UE) conformance specification
9.3.1 5GS-EPC Inter-system mobility
9.3.1.1 Inter-system mobility registration update / Single-registration mode with N26 / 5GMM-IDLE / 5GC to EPC
9.3.1.1.1 Test Purpose (TP)
(1)
with { UE in state 5GMM-REGISTERED and 5GMM-IDLE on a 5GC NR cell and has been previously registered on EPC as well, UE supporting S1 and N1 and operating in single-registration mode, NWK supporting Single-registration mode with N26 interface }
ensure that {
when { UE detects a suitable EPC E-UTRA cell after the serving NGC cell becomes not suitable }
then { UE performs a Inter-system change from N1 mode to S1 mode by initiating and successfully completing a TAU procedure, mapped EPC context used }
}
9.3.1.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 24.501 [22], subclause 5.1.4.2; TS 24.301 [21], subclause 4.4.2.3. Unless otherwise stated these are Rel-15 requirements.
[TS 24.501, subclause 5.1.4.2]
At Inter-system change from N1 mode to S1 mode when there is at least one active PDU session for which interworking with EPS is supported as specified in subclause 6.1.4.1, the UE shall enter sub states EMM-REGISTERED.NORMAL-SERVICE and 5GMM-REGISTERED.NO-CELL-AVAILABLE and initiate a tracking area updating procedure (see 3GPP TS 24.301 [15]).
[TS 24.301, subclause 4.4.2.3]
During Inter-system change from N1 mode to S1 mode in 5GMM-IDLE mode, if the UE is operating in the single-registration mode and:
1) if the tracking area updating procedure is initiated as specified in 3GPP TS 24.501 [54], the UE shall transmit a TRACKING AREA UPDATE REQUEST message integrity protected with the current 5G NAS security context and the UE shall derive a mapped EPS security context (see subclause 8.6.1 of 3GPP TS 33.501 [56]). The UE shall include the eKSI indicating the 5G NAS security context value in the TRACKING AREA UPDATE REQUEST message.
After receiving the TRACKING AREA UPDATE REQUEST message including the eKSI, the MME forwards the TRACKING AREA UPDATE REQUEST message to the source AMF, if possible, to obtain the mapped EPS security context from the AMF as specified in 3GPP TS 33.501 [56]. The MME re-establishes the secure exchange of NAS messages by either:
– replying with a TRACKING AREA UPDATE ACCEPT message that is integrity protected and ciphered using the mapped EPS NAS security context. From this time onward, all NAS messages exchanged between the UE and the MME are sent integrity protected and except for the messages specified in subclause 4.4.5, all NAS messages exchanged between the UE and the MME are sent ciphered; or
9.3.1.1.3 Test description
9.3.1.1.3.1 Pre test conditions
System Simulator:
– 2 cells
– NGC Cell A as defined in TS 38.508-1 [4] Table 6.3.2.2-1. System information combination NR-6 as defined in TS 38.508-1 [4], subclause 4.4.3.1.2.
– E-UTRA Cell A as defined in TS 36.508 [7] Table 6.3.2.2-1. System information combination 31 as defined in TS 36.508 [7], subclause 4.4.3.1.1.
UE:
– None.
Preamble:
– With E-UTRA Cell A "Serving cell" and NGC Cell A "Non-suitable "Off" cell", the UE is brought to state RRC_IDLE using generic procedure parameters Connectivity (E-UTRA/EPC) and Unrestricted nr PDN (On) in accordance with the procedure described in TS 38.508-1 [4], clause 4.5.2. 4G GUTI and eKSI are assigned and security context established
– the UE is switched-off
– With NGC Cell A "Serving cell" and E-UTRA Cell A "Non-suitable "Off" cell", the UE is brought to state 1N-A, RRC_IDLE Connectivity (NR), in accordance with the procedure described in TS 38.508-1 [4], Table 4.5.2.2-2. 5G-GUTI and ngKSI are assigned and security context established.
9.3.1.1.2 Test procedure sequence
Table 9.3.1.1.3.2-1: Main behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
1 |
The SS configures: – E-UTRA Cell A as "Serving cell" – NGC Cell A as "Non-suitable "off" cell". |
– |
– |
– |
– |
|
2 |
Check: Does the UE perform on the E-UTRA Cell A the TAU procedure for Inter-system change from N1 mode to S1 mode in 5GMM/EMM-IDLE mode as described in TS 38.508-1 [4], Table 4.9.7.2.2-1, ‘connected without release’? |
– |
– |
1 |
– |
|
3 |
At the end of this test procedure sequence, the UE is in end state E-UTRA connected (E2_T3440) according to TS 36.508 [7]. |
– |
– |
– |
– |
9.3.1.1.3.3 Specific message contents
None.
9.3.1.2 Inter-system mobility registration update / Single-registration mode with N26 / 5GMM-IDLE / EPC to 5GC
9.3.1.2.1 Test Purpose (TP)
(1)
with { UE in state EMM-REGISTERED and EMM-IDLE on an E-UTRA cell and has been previously registered on 5GC, UE supporting S1 and N1 and operating in single-registration mode, NWK supporting Single-registration mode with N26 interface }
ensure that {
when { UE detects a suitable NGC cell after the serving E-UTRA cell becomes not suitable }
then { UE performs a Inter-system change from S1 mode to N1 mode by initiating and successfully completing a mobility and periodic registration update procedure, mapped 5GC context used }
}
9.3.1.2.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 24.501 [22], subclauses 4.4.2.1, 4.4.2.5, 5.1.4.2, 5.5.1.3.2; TS 24.301 [21], subclause 5.5.5. Unless otherwise stated these are Rel-15 requirements.
[TS 24.501, subclause 4.4.2.1]
Before security can be activated, the AMF and the UE need to establish a 5G NAS security context. Usually, the 5G NAS security context is created as the result of a primary authentication and key agreement procedure between the AMF and the UE. A new 5G NAS security context may also be created during an N1 mode to N1 mode handover. Alternatively, during inter-system change from S1 mode to N1 mode, the AMF not supporting interworking without N26 and the UE operating in single-registration mode may derive a mapped 5G NAS security context from an EPS security context that has been established while the UE was in S1 mode.
…
The key set identifier ngKSI is assigned by the AMF either during the primary authentication and key agreement procedure or, for the mapped 5G NAS security context, during the inter-system change. The ngKSI consists of a value and a type of security context parameter indicating whether a 5G NAS security context is a native 5G NAS security context or a mapped 5G NAS security context. When the 5G NAS security context is a native 5G NAS security context, the ngKSI has the value of KSIAMF, and when the current 5G NAS security context is of type mapped, the ngKSI has the value of KSIASME.
The 5G NAS security context which is indicated by an ngKSI can be taken into use to establish the secure exchange of NAS messages when a new N1 NAS signalling connection is established without executing a new primary authentication and key agreement procedure (see subclause 5.4.1) or when the AMF initiates a security mode control procedure. For this purpose, the initial NAS messages (i.e. REGISTRATION REQUEST, DEREGISTRATION REQUEST, SERVICE REQUEST and CONTROL PLANE SERVICE REQUEST) and the SECURITY MODE COMMAND message contain an ngKSI in the NAS key set identifier IE indicating the current 5G NAS security context used to integrity protect the NAS message.
[TS 24.501, subclause 4.4.2.5]
Secure exchange of NAS messages via a NAS signalling connection is usually established by the AMF during the registration procedure by initiating a security mode control procedure. After successful completion of the security mode control procedure, all NAS messages exchanged between the UE and the AMF are sent integrity protected using the current 5G security algorithms, and except for the messages specified in subclause 4.4.5, all NAS messages exchanged between the UE and the AMF are sent ciphered using the current 5G security algorithms.
…
During inter-system change from S1 mode to N1 mode in 5GMM-IDLE mode, if the UE is operating in single-registration mode and:
…b) if the UE has no valid native 5G NAS security context, the UE shall send the REGISTRATION REQUEST message without integrity protection and encryption.
After receiving the REGISTRATION REQUEST message without integrity protection and encryption:
1) if N26 interface is supported:
i) if an EPS security context received from the source MME does not include the NAS security algorithms set to EIA0 and EEA0, the AMF shall either create a fresh mapped 5G NAS security context (see subclause 8.6.2 of 3GPP TS 33.501 [24]) or trigger a primary authentication and key agreement procedure to create a fresh native 5G NAS security context; or
…
The newly created 5G NAS security context is taken into use by initiating a security mode control procedure and this context becomes the current 5G NAS security context in both the UE and the AMF. This re-establishes the secure exchange of NAS messages.
[TS 24.501, subclause 5.1.4.2]
At inter-system change from S1 mode to N1 mode, the UE shall enter sub states 5GMM-REGISTERED.NORMAL-SERVICE and EMM-REGISTERED.NO-CELL-AVAILABLE and initiate a registration procedure for mobility and periodic registration update indicating "mobility registration updating" in the 5GS registration type IE of the REGISTRATION REQUEST message (see subclause 5.5.1.3).
[TS 24.501, subclause 5.5.1.3.2]
The UE in state 5GMM-REGISTERED shall initiate the registration procedure for mobility and periodic registration update by sending a REGISTRATION REQUEST message to the AMF,
…
e) upon Inter-system change from S1 mode to N1 mode;
…
If case b) is the only reason for initiating the registration procedure for mobility and periodic registration update, the UE shall indicate "periodic registration updating" in the 5GS registration type IE; otherwise the UE shall indicate "mobility registration updating".
If the UE indicates "mobility registration updating" in the 5GS registration type IE and the UE supports S1 mode, the UE shall:
– set the S1 mode bit to "S1 mode supported" in the 5GMM capability IE of the REGISTRATION REQUEST message;
– include the S1 UE network capability IE in the REGISTRATION REQUEST message; and
– if the UE supports sending an ATTACH REQUEST message containing a PDN CONNECTIVITY REQUEST message with request type set to "handover" to transfer a PDU session from N1 mode to S1 mode, set the HO attach bit to "attach request message containing PDN connectivity request with request type set to handover to transfer PDU session from N1 mode to S1 mode supported" in the 5GMM capability IE of the REGISTRATION REQUEST message.
…
If the last visited registered TAI is available, the UE shall include the last visited registered TAI in the REGISTRATION REQUEST message.
The UE shall handle the 5GS mobility identity IE in the REGISTRATION REQUEST message as follows:
a) if the UE is operating in the single-registration mode, performs Inter-system change from S1 mode to N1 mode, and the UE holds a valid 4G-GUTI, the UE shall include the 5G-GUTI mapped from the 4G-GUTI as specified in 3GPP TS 23.003 [4] in the 5GS mobility identity IE. Additionally, if the UE holds a valid 5G‑GUTI, the UE shall include the 5G-GUTI in the Additional GUTI IE in the REGISTRATION REQUEST message in the following order:
1) a valid 5G-GUTI that was previously assigned by the same PLMN with which the UE is performing the registration, if available;
2) a valid 5G-GUTI that was previously assigned by an equivalent PLMN, if available; and
3) a valid 5G-GUTI that was previously assigned by any other PLMN, if available; and
…
If the UE operating in the single-registration mode performs Inter-system change from S1 mode to N1 mode, the UE:
a) shall include the UE status IE with the EMM registration status set to "UE is in EMM-REGISTERED state" in the REGISTRATION REQUEST message;
NOTE 1: Inclusion of the UE status IE with this setting corresponds to the indication that the UE is "moving from EPC" as specified in 3GPP TS 23.502 [9], subclause 4.11.1.3.3 and 4.11.2.3.
b) may include the PDU session status IE in the REGISTRATION REQUEST message indicating the status of the PDU session(s) mapped during the Inter-system change from S1 mode to N1 mode from the PDN connection(s) for which the EPS indicated that interworking to 5GS is supported, if any (see subclause 6.1.4.1); and
c) shall include a TRACKING AREA UPDATE REQUEST message as specified in 3GPP TS 24.301 [15] in the IE in the REGISTRATION REQUEST message.
…
The UE shall send the REGISTRATION REQUEST message including the NAS message container IE as described in subclause 4.4.6:
…
b) when the UE is sending the message after an Inter-system change from S1 mode to N1 mode in 5GMM-IDLE mode and the UE has a valid 5G NAS security context and needs to send non-cleartext IEs.
[TS 24.301, subclause 5.5.5]
The tracking area updating procedure is used to construct a TRACKING AREA UPDATE REQUEST message for the inter-system change from S1 mode to N1 mode for further security verification by the MME.
The TRACKING AREA UPDATE REQUEST message is created by EMM by request of 5GMM which further includes the message in the REGISTRATION REQUEST message as described in 3GPP TS 24.501 [54].
The TRACKING AREA UPDATE REQUEST message shall contain only mandatory information elements.
The UE shall set the EPS update type IE in the TRACKING AREA UPDATE REQUEST message to "TA updating".
If the UE has a current EPS security context, the UE shall include the eKSI (either KSIASME or KSISGSN) in the NAS Key Set Identifier IE in the TRACKING AREA UPDATE REQUEST message. Otherwise, the UE shall set the NAS Key Set Identifier IE to the value "no key is available". If the UE has a current EPS security context, the UE shall integrity protect the TRACKING AREA UPDATE REQUEST message with the current EPS security context and increase the uplink NAS COUNT by one. Otherwise the UE shall not integrity protect the TRACKING AREA UPDATE REQUEST message. The UE shall set associated GUTI in the Old GUTI IE.
When the UE is in EMM-REGISTERED.NO-CELL-AVAILABLE substate and needs to construct the TRACKING AREA UPDATE REQUEST message for inter-system change from S1 mode to N1 mode, the UE shall consider that the tracking area updating procedure is not initiated and the UE shall remain in EMM-REGISTERED.NO-CELL-AVAILABLE state.
9.3.1.2.3 Test description
9.3.1.2.3.1 Pre test conditions
System Simulator:
– 2 cells
– NGC Cell A as defined in TS 38.508-1 [4] Table 6.3.2.2-1. System information combination NR-6 as defined in TS 38.508-1 [4], subclause 4.4.3.1.2.
– E-UTRA Cell A as defined in TS 36.508 [7] Table 6.3.2.2-1. System information combination 31 as defined in TS 36.508 [7], subclause 4.4.3.1.1.
UE:
None.
Preamble:
– With NGC Cell A "Serving cell" and E-UTRA Cell A "Non-suitable "Off" cell", the UE is switched on and when it intiates the inital registration procedure then it is rejected as specified in subclause 4.9.8 Procedure for Registration Reject.This is made to ensure that the UE does not have a valid native 5G NAS security context for the rest of the test case.
– the UE is switched-off.
– With E-UTRA Cell A "Serving cell" and NGC Cell A "Non-suitable "Off" cell", the UE is brought to state RRC_IDLE using generic procedure parameters Connectivity (E-UTRA/EPC) and Unrestricted nr PDN (On)in accordance with the procedure described in TS 38.508-1 [4], clause 4.5.2. 4G GUTI and eKSI are assigned and security context established.
9.3.1.2.3.2 Test procedure sequence
Table 9.3.1.2.3.2-1: Main behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
1 |
The SS configures: – NGC Cell A as "Serving cell" – E-UTRA Cell A as "Non-suitable "off" cell". |
– |
– |
– |
– |
|
2 |
Check: Does the UE perform on the NGC Cell A the Test procedure for UE Tracking area updating for Inter-system change from S1 mode to N1 mode in 5GMM/EMM-IDLE mode as described in TS 38.508-1 [4], Table 4.9.9.2.2-1 with the exception that the SS does not intiate the primary authentication and key agreement procedure described in steps 4-5 (NOTE 1), ‘connected without release‘? |
– |
– |
1 |
– |
|
NOTE 1: This is required to allow for the verification of the UE using mapped 5GC context as per TP1. |
|||||
9.3.1.2.3.3 Specific message contents
Table 9.3.1.2.3.3-1: REGISTRATION REQUEST (Preamble; TS 38.508-1 [4], Table 4.5.2.2-2)
|
Derivation Path: TS 38.508-1 [4], Table 4.7.1-6 |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
5GMM capability |
|||
|
S1 mode (octet 3, bit 1) |
‘1’B |
S1 mode supported |
|
|
S1 UE network capability |
|||
|
All octets with the exception of octet 9, bit 6 |
Not checked |
||
|
N1 mode supported (N1mode) (octet 9, bit 6) |
‘1’B |
N1 mode supported |
|
Table 9.3.1.2.3.3-2: REGISTRATION REJECT (Preamble; step 8, TS 38.508-1 [4], Table 4.9.8.2.2-1)
|
Derivation path: TS 38.508-1 [4], Table 4.9.8.2.3-1 |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
5GMM cause |
‘0000 0011’B |
Illegal UE |
|
Table 9.3.1.2.3.3-3: Message ATTACH REQUEST (Preamble; step 4, TS 38.508-1 [4], Table 4.5.2.2-5)
|
Derivation Path: TS 36.508 [7], Table 4.7.2-4 with condition NR |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
NAS key set identifier |
|||
|
NAS key set identifier |
‘111’B |
no key is available |
|
|
TSC |
Any allowed value |
TSC does not apply for NAS key set identifier value "111". |
|
|
Old GUTI or IMSI |
IMSI1 |
||
|
Last visited registered TAI |
Not present |
||
Table 9.3.1.2.3.3-4: REGISTRATION REQUEST (step 2, Table 9.3.1.2.3.2-1; step 1, TS 38.508-1 [4] Table 4.9.9.2.2-1)
|
Derivation Path: TS 38.508-1 [4], Table 4.7.1-6 with condition NOT NON_CLEARTEXT_IE |
Table 9.3.1.2.3.3-5: TRACKING AREA UPDATE REQUEST (9.3.1.2.3.3-4)
|
Derivation path: TS 38.508-1 [4], Table 4.9.9.2.3-2 |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
NAS key set identifier |
|||
|
NAS key set identifier |
the eKSI for the current EPS security context |
||
|
TSC |
‘0’B |
native (current) EPS security context |
|
Table 9.3.1.2.3.3-6: SECURITY MODE COMMAND (step 2, Table 9.3.1.2.3.2-1; step 6, TS 38.508-1 [4] Table 4.9.9.2.2-1)
|
Derivation Path: TS 38.508-1 [4], Table 4.7.1-25. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
ngKSI |
|||
|
NAS key set identifier |
KSIASME that was created when the UE last registered to EPS |
||
|
TSC |
‘1’B |
mapped security context (for KSIASME) |
|
9.3.1.3 Inter-system mobility and periodic registration update / Rejected / Single-registration mode with N26 / Handling of EPC relevant parameters
9.3.1.3.1 Test Purpose (TP)
(1)
with { UE in state 5GMM-REGISTERED on an NGC cell, UE supporting S1 and N1 and operating in single-registration mode, NWK supporting Single-registration mode with N26 interface }
ensure that {
when { UE initiates a Mobility and periodic registration procedure on an NGC cell and receives a REGISTRATION REJECT message including 5GMM cause value #9 (UE identity cannot be derived by the network) }
then { UE deletes the EPS relevant parameters 4G-GUTI, last visited registered TAI and eKSI and enters the state EMM-DEREGISTERED, and, subsequently, when it finds a suitable E-UTRA cell it moves to it and automatically initiates an attach procedure }
}
9.3.1.3.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 24.501 [22], subclause 5.5.1.3.5, TS 24.301 [21], clause 5.5.3.2.5. Unless otherwise stated these are Rel-15 requirements.
[TS 24.501, subclause 5.5.1.3.5]
If the mobility and periodic registration update request cannot be accepted by the network, the AMF shall send a REGISTRATION REJECT message to the UE including an appropriate 5GMM cause value.
The UE shall take the following actions depending on the 5GMM cause value received in the REGISTRATION REJECT message.
…
#9 (UE identity cannot be derived by the network).
…
If the UE is operating in single-registration mode, the UE shall handle the EMM parameters EMM state, EPS update status, 4G-GUTI, last visited registered TAI, TAI list and eKSI as specified in 3GPP TS 24.301 [15] for the case when the normal tracking area updating procedure is rejected with the EMM cause with the same value.
[TS 24.301, subclause 5.5.3.2.5]
If the tracking area updating cannot be accepted by the network, the MME sends a TRACKING AREA UPDATE REJECT message to the UE including an appropriate EMM cause value.
…
#9 (UE identity cannot be derived by the network);
The UE shall set the EPS update status to EU2 NOT UPDATED (and shall store it according to subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI list and eKSI. The UE shall enter the state EMM-DEREGISTERED.
If the rejected request was not for initiating a PDN connection for emergency bearer services, the UE shall subsequently, automatically initiate the attach procedure.
9.3.1.3.3 Test description
9.3.1.3.3.1 Pre test conditions
System Simulator:
– 2 cells
– NGC Cell A as defined in TS 38.508-1 [4] Table 6.3.2.2-1. System information combination NR-6 as defined in TS 38.508-1 [4], subclause 4.4.3.1.2.
– E-UTRA Cell A as defined in TS 36.508 [7] Table 6.3.2.2-1. System information combination 31 as defined in TS 36.508 [7], subclause 4.4.3.1.1.
UE:
None.
Preamble:
– With E-UTRA Cell A "Serving cell" and NGC Cell A "Non-suitable "Off" cell", the UE is brought to state RRC_IDLE using generic procedure parameters Connectivity (E-UTRA/EPC) and Unrestricted nr PDN (On) in accordance with the procedure described in TS 38.508-1 [4], clause 4.5.2. 4G GUTI and eKSI are assigned and security context established
– the UE is switched-off
– With NGC Cell A "Serving cell" and E-UTRA Cell A "Non-suitable "Off" cell", the UE is brought to state 1N-A, RRC_IDLE Connectivity (NR), in accordance with the procedure described in TS 38.508-1 [4], Table 4.5.2.2-2. 5G-GUTI and ngKSI are assigned and security context established.
9.3.1.3.3.2 Test procedure sequence
Table 9.3.1.3.3.2-1: Main behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
1 |
Wait for 25 seconds (expiry of T3512 periodic registration update timer, the value of 30 sec is provided during the initial registration in the Preamble). |
– |
– |
– |
– |
|
2 |
The UE transmit a REGISTRATION REQUEST message with the 5GS registration type IE indicating "periodic registration updating". |
–> |
REGISTRATION REQUEST |
– |
– |
|
3 |
The SS configures: – E-UTRA Cell A "Suitable neighbour inter-frequency cell". |
– |
– |
– |
– |
|
4 |
The SS transmits a REGISTRATION REJECT message including 5GMM cause value #9 (UE identity cannot be derived by the network). |
<– |
REGISTRATION REJECT |
– |
– |
|
4A |
The SS configures: – NGC Cell A as "Non-Suitable "Off" cell". |
– |
– |
– |
– |
|
5 |
Check: Does the UE perform on the E-UTRA Cell A an attach procedure as described in TS 38.508-1 [4], Table 4.5.2.2-1? The UE does not provide 4G-GUTI or 4G eKSI; nor last visited registered TAI. |
– |
– |
1 |
– |
9.3.1.3.3.3 Specific message contents
Table 9.3.1.3.3.3-1: REGISTRATION ACCEPT (Preamble; TS 38.508-1 [4] Table 4.5.2.2-2)
|
Derivation path: TS 38.508-1 [4], Table 4.7.1-7. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
T3512 value |
|||
|
Unit |
‘100’B |
value is incremented in multiples of 30 seconds |
|
|
Timer value |
‘0 0001’B |
30 seconds |
|
Table 9.3.1.3.3.3-2: REGISTRATION REQUEST (step 2, Table 9.3.1.3.3.2-1)
|
Derivation Path: TS 38.508-1 [4], Table 4.7.1-6. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
5GS registration type |
’00xxx011′ |
periodic registration updating x – not checked |
|
|
ngKSI |
Active ngKSI assigned in the Preamble |
||
|
5GS mobile identity |
Active 5G-GUTI assigned in the Preamble |
||
|
Last visited registered TAI |
The TAI of the NGC Cell A, see TS 38.508-1 [4] Table 6.3.2.2-1 |
||
Table 9.3.1.3.3.3-3: REGISTRATION REJECT (step 4, Table 9.3.1.3.3.2-1)
|
Derivation Path: TS 38.508-1 [4], Table 4.7.1-9. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
5GMM cause |
‘0000 1001’B |
#9 – UE identity cannot be derived by the network |
|
Table 9.3.1.3.3.3-4: ATTACH REQUEST (step 5, Table 9.3.1.3.3.2-1; step 5, TS 38.508-1 [4] Table 4.5.2.2-1)
|
Derivation Path: TS 36.508 [7], Table 4.7.2-4. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
NAS key set identifier |
‘111’ |
no key is available |
|
|
EPS mobile identity |
IMSI |
||
|
Old P-TMSI signature |
Not present |
||
|
Last visited registered TAI |
Not present |
||
|
Old location area identification |
Not checked |
||
|
Old GUTI type |
Not present |
||