- Verify that the IUT rejects initial registration request because all the S-NSSAI(s) included in the requested NSSAI are either rejected for current PLMN, rejected for the current registration area or rejected due to failed or revoked NSSAIs.
## Section 5.5.1.2.4: Initial registration accepted by the network (SINTESIO)
- TP_5GNAS_AMF_REG_ACC_01
- Verify that the IUT sends a REGISTRATION ACCEPT message containing the 5GS registration result, TAI list, 5G-GUTI and T3512 when initial registration is accepted by the network.
- TP_5GNAS_AMF_REG_ACC_02
- Verify that the IUT sends a REGISTRATION ACCEPT message indicating SMS over NAS allowed when initial registration with SMS over NAS is requested and network allows SMS service.
- TP_5GNAS_AMF_REG_ACC_03
- Verify that the IUT sends a REGISTRATION ACCEPT message indicating SMS over NAS not allowed when initial registration with SMS over NAS is requested and network does not support SMS service.
# TP objective ideas reviewed
## Section 5.4.1.3.7
## Section 5.4.1.3.7 (FF)
- Verify that the IUT sends a new IDENTIFICATION REQUEST message to obtain the SUCI from the UE upon receipt of an AUTHENTICATION FAILURE message indicating a 5GMM cause value #26 - non-5G authentication unacceptable. (FF)
- This case is also valid in cases where the UE send Auth Response, but the response parameters do not match.
@@ -41,7 +49,7 @@
- Verify that the IUT sends a new AUTHENTICATION REQUEST message after a successful re-synchronisation procedure upon receipt of an AUTHENTICATION FAILURE message indicating a 5GMM cause value #21 (Synch failure) and including the AUTS parameter. (FF)
## Section 5.4.2: Security mode control procedure
## Section 5.4.2: Security mode control procedure (FF)
- Verify that the IUT, upon receiving the NAS Security Mode Complete Message after completing the NAS Authentication and Security procedure, successfully completes the registration process by accepting the registration.
@@ -50,7 +58,7 @@
- Verify that the IUT sends a new AUTHENTICATION REQUEST message to re-initiate the 5G AKA based primary authentication upon receipt of an AUTHENTICATION FAILURE message indicating a 5GMM cause value #71 (ngKSI already in use). (FF) See above in Section 5.4.1.3.7
- Verify that the IUT sends an IDENTITY REQUEST message correctly upon receipt of an AUTHENTICATION FAILURE message indicating a 5GMM cause value #20. (already implemented as: TP_5GNAS_AMF_AUT_REQ_04)
@@ -61,49 +69,47 @@
- Verify that the IUT stops re-sending an Identity REQUEST message if no Identity RESPONSE message is received on the fifth expiry of timer T3519.
## Section 5.5.1.2.4: Initial registration accepted by the network (SINTESIO)
- Verify that the IUT sends a REGISTRATION ACCEPT message containing the 5GS registration result, TAI list, 5G-GUTI and T3512 when initial registration is accepted by the network.
- Verify that the IUT sends a REGISTRATION ACCEPT message indicating SMS over NAS allowed when initial registration with SMS over NAS is requested and network allows SMS service.
- Verify that the IUT sends a REGISTRATION ACCEPT message indicating SMS over NAS not allowed when initial registration with SMS over NAS is requested and network does not support SMS service.
## Section 8.2.10, 8.2.11
## Section 8.2.10, 8.2.11 (FF)
- Verify that the IUT correctly handles a UL NAS transport message containing a PDU SESSION ESTABLISHMENT REQUEST from the UE and responds with a DL NAS transport message containing a PDU SESSION ESTABLISHMENT ACCEPT.
**Note:** This test idea could be unnecessary. Since the messages DL and UL NAS transport are intrinsically linked to PDU Sessions, their functionality is already verified within the scope of sections 6.3 and 6.4.
# TP objectives ideas
## Section 5.5.1.2.4: Initial registration accepted by the network (SINTESIO)
- TP_5GNAS_AMF_REG_ACC_04
- Verify that the IUT includes the allowed NSSAI in the REGISTRATION ACCEPT message when the UE includes a requested NSSAI in the REGISTRATION REQUEST message and the network allows one or more S-NSSAIs from the requested NSSAI.
- TP_5GNAS_AMF_REG_ACC_05
- Verify that the IUT optionally includes rejected NSSAI in the REGISTRATION ACCEPT message when the network rejects one or more S-NSSAIs from the requested NSSAI.
- Verify that the IUT, upon receiving a DEREGISTRATION REQUEST message containing the De-registration type IE with "Normal de-registration" from the UE, sends a DEREGISTRATION ACCEPT message.
- TP_5GNAS_AMF_DRG_ACC_02
- Verify that the IUT, upon receiving a DEREGISTRATION REQUEST message containing the De-registration type IE with "Switch off" from the UE, does not send a DEREGISTRATION ACCEPT message and IUT completes de-registration procedure.
- Verify that the IUT initiates network de-registration by sending a DEREGISTRATION REQUEST message containing De-registration type IE with re-registration not required and the access type based on the UE’s registration status (3GPP access only).
- Verify that the IUT initiates network de-registration by sending a DEREGISTRATION REQUEST message containing De-registration type IE with re-registration not required and the access type based on the UE’s registration status (3GPP access only). NOTE: explicit network deregistration triggered by O&M - deactivation of UE
[KSCH]:Trigger for NW Initiated De-Registration missing. Chapter 5.5.2.3.1 mentions some triggers to perform NW-Initiation De-Registraton e.g. network slice-specific authentication and authorization failure or revocation as specified in subclause 4.6.2.4
- Verify that the IUT initiates network de-registration by sending a DEREGISTRATION REQUEST message and if UE does not send DEREGISTRATION ACCEPT then IUT retransmits DEREGISTRATION REQUEST message after timer T3522 expiration.
- TP_5GNAS_AMF_DRG_REQ_02
- Verify that the IUT initiates network de-registration by sending a DEREGISTRATION REQUEST message and if UE does not send DEREGISTRATION ACCEPT then IUT retransmits DEREGISTRATION REQUEST message after timer T3522 expiration. NOTE: explicit network deregistration triggered by O&M - UE deregistration
[KSCH]:See above or rephrase to "Verify the in case of T3522 Timeout the IUT re-sends DEREGISTRATION REQUEST" More appropriate reference would be 5.5.2.3.5 Abnormal cases in the network side case a) T3522 time-out
- Verify that the IUT initiates network de-registration by sending DEREGISTRATION REQUEST message containing De-registration type IE with re-registration required and the access type based on the UE’s registration status (3GPP access only). NOTE: UE sends DEREGISTRATION ACCEPT and starts with re-registration procedure.(also used ref 5.5.2.3.2 1st paragraph)
- TP_5GNAS_AMF_DRG_REQ_03
- Verify that the IUT initiates network de-registration by sending DEREGISTRATION REQUEST message containing De-registration type IE with re-registration required and the access type based on the UE’s registration status (3GPP access only). NOTE 1: UE sends DEREGISTRATION ACCEPT and starts with re-registration procedure.(also used ref 5.5.2.3.2 1st paragraph) NOTE 2: explicit network deregistration triggered by O&M - UE deregistration
[KSCH]:Trigger for NW Initiated De-Registration missing. Under what circumstances the IUT has to trigger De-Registration and has to include Re-Registration Required and Access Type.
[BPIN]:NOTE's to all above 3 TOs are added to clarify triggering of network de-registration. Triggering of network de-registration is related to O&M.
- TP_5GNAS_AMF_DRG_REQ_04
- Verify that if de-registration is triggered due to IUT slice-specific authentication and authorization failure or revocation, the network sets the 5GMM cause value to #62 "No network slices available" and includes the rejected NSSAI IE in the DEREGISTRATION REQUEST message.
