- 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,43 +69,149 @@
- 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.4.5: NAS transport procedure (FF) ( 8.2.10, 8.2.11)
- 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.
## 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.
- 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_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 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.
- 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). **NOTE:** explicit network deregistration triggered by O&M - deactivation of UE
- 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.
- 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
**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_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
- 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.
# TP objectives ideas
## Section 5.5.1.2.4: Initial registration accepted by the network (SINTESIO)
## 5.5.1.2.8 Abnormal cases on the network side - Initial Registration (SINTESIO)
[BPIN] Those TOs were identified but they may not be for the first round of implementation
- 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_ABN_01
- Verify that the IUT retransmits the REGISTRATION ACCEPT message and restarts timer T3550 upon the first four expirations.
- 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.
- TP_5GNAS_AMF_REG_ABN_02
- Verify that the IUT aborts the registration procedure for initial registration and enters the 5GMM-REGISTERED state on the fifth expiry. NOTE: 5GMM-REGISTERED state can be checked over O&M
- TP_5GNAS_AMF_REG_ABN_03
- Verify that the IUT aborts the registration procedure for initial registration and enters the 5GMM-REGISTERED state when a lower layer failure occurs before receiving the REGISTRATION COMPLETE message while timer T3550 is running. NOTE: 5GMM-REGISTERED state can be checked over O&M
- TP_5GNAS_AMF_REG_ABN_04 [BPIN: It shall be investigate what kind of message can be constructed to get proposed cause. Should be possible since 5G-NAS is not ASN1 and therefore type system fully controled by ttcn-3]
- Verify that the IUT responds to a REGISTRATION REQUEST message with a protocol error by sending a REGISTRATION REJECT message with appropriate 5GMM cause values:
#96: Invalid mandatory information
#99: Information element non-existent or not implemented
#100: Conditional IE error
#111: Protocol error, unspecified.
- 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_REG_ABN_05
- Verify that the IUT aborts the previous registration procedure and initiates a new registration procedure if the information elements in a second REGISTRATION REQUEST message differ from those in the first and if the REGISTRATION COMPLETE message has not been received for first registration.
- 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.
- TP_5GNAS_AMF_REG_ABN_06
- Verify that the IUT resends the REGISTRATION ACCEPT message and restarts T3550 if the information elements in the first and second REGISTRATION REQUEST message do not differ and if the REGISTRATION COMPLETE message has not been received for first registration. The retransmission counter related to T3550 is not incremented.
- Verify that the IUT aborts the registration procedure for initial registration and progresses the de-registration procedure as specified when a DEREGISTRATION REQUEST is received before the REGISTRATION COMPLETE message.
- 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).
- TP_5GNAS_AMF_REG_ABN_08
- Validate that the AMF rejects a REGISTRATION REQUEST message with invalid or unacceptable UE security capabilities by sending a REGISTRATION REJECT message.
- 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.
## 5.5.2.3.5 Abnormal cases in the network side (SINTESIO)
[BPIN] Those TOs were identified but they may not be for the first round of implementation
- 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_ABN_01
- Verify that the IUT retransmits DEREGISTRATION REQUEST message after timer T3522 expiration four times (i.e. on the fifth expiry of timer T3522, the de-registration procedure shall be aborted).
- 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.
- TP_5GNAS_AMF_DRG_ABN_02
- Verify that if IUT receives a DEREGISTRATION REQUEST message with "switch off" indication, before the network-initiated de-registration procedure has been completed, both procedures shall be considered completed.
- TP_5GNAS_AMF_DRG_ABN_03
- Verify that if IUT receives a DEREGISTRATION REQUEST message without "switch off" indication, before the network-initiated de-registration procedure has been completed, the IUT shall send a DEREGISTRATION ACCEPT message to the UE.
- TP_5GNAS_AMF_DRG_ABN_04
- Verify that if IUT receives a REGISTRATION REQUEST message indicating "initial registration" in the 5GS registration type IE before the network-initiated de-registration procedure has been completed, the IUT shall aborted the de-registration procedure and the registration procedure shall be progressed.
- TP_5GNAS_AMF_DRG_ABN_05
- Verify that if IUT sends a DEREGISTRATION REQUEST message without 5GMM cause value #11, #12, #13 or #15 and the IUT receives a REGISTRATION REQUEST message indicating either "mobility registration updating" or "periodic registration updating" in the 5GS registration type IE before the network-initiated de-registration procedure has been completed, the de-registration procedure shall be progressed, i.e. the REGISTRATION REQUEST message shall be ignored.
- TP_5GNAS_AMF_DRG_ABN_06
- Verify that if IUT sends a DEREGISTRATION REQUEST message with 5GMM cause value #11, #12, #13 or #15 and the IUT receives a REGISTRATION REQUEST message indicating either "mobility registration updating" or "periodic registration updating" in the 5GS registration type IE before the network-initiated de-registration procedure has been completed, the de-registration procedure shall be aborted and the registration procedure shall be progressed.
- TP_5GNAS_AMF_DRG_ABN_07
- Verify that if IUT receives a SERVICE REQUEST message or a CONTROL PLANE SERVICE REQUEST message before the network-initiated de-registration procedure has been completed (e.g. the DEREGISTRATION REQUEST message is pending to be sent to the UE), the network shall progress the de-registration procedure.
## 6.4.1.3 UE-requested PDU session establishment procedure accepted by the network (FF)
- Verify that the IUT, upon receiving the PDU SESSION ESTABLISHMENT REQUEST from the UE with correct data and with type initial request, sends PDU SESSION ESTABLISHMENT ACCEPT meesage
## 6.4.1.7 Abnormal cases on the network side (FF)
- Verify that the IUT sends a PDU SESSION ESTABLISHMENT REJECT with cause #31 (request rejected, unspecified), when the UE sends a PDU SESSION ESTABLISHMENT REQUEST with type initial emergency request and there is already a emergency PDU session for the UE.
Note: possible, that the IUT releases the existing emergency session and don't sends a REJECT. Maybe implementation-dependend?
- Verify that the IUT sends a PDU SESSION ESTABLISHMENT REJECT with cause #54 (PDU session does not exist), when the UE sends a PDU SESSION ESTABLISHMENT REQUEST with type existing PDU session and there is no PDU session with that ID.
- Verify that the IUT sends a PDU SESSION ESTABLISHMENT REJECT with cause #29 (user authentication or authorization failed), when the UE sends a PDU SESSION ESTABLISHMENT REQUEST with type initial request and the provided authentication and authorization data don't match local policy and user's subscription data.
## 6.3.1.1 (FF)
- Verify that the IUT, upon receiving the PDU SESSION AUTHENTICATION COMPLETE Message after completing the PDU session authentication and authorization procedure, successfully completes the process by sending PDU SESSION ESTABLISHMENT ACCEPT.
## 6.3.1.2.3 Abnormal cases on the network side (FF)
- Verify that the IUT retransmits PDU SESSION AUTHENTICATION COMMAND message after timer T3590 expiration first time.
- Verify that the IUT aborts the procedure after timer T3590 expiration four times.
## 6.4.3.2, 6.4.3.4 (FF)
- Verify that the IUT handles correctly a PDU SESSION RELEASE REQUEST after receiving a PDU SESSION RELEASE REQUEST by the UE.
Note: There is no message back to the UE after receiving the PDU SESSION RELEASE REJECT, the correct execution of Session Release can be tested with another message.
- Verify that the IUT sends correctly a PDU SESSION RELEASE REJECT after receiving a PDU SESSION RELEASE REQUEST by the UE and not accepts the session release with reason #35 (PTI already in use).
- Verify that the IUT sends correctly a PDU SESSION RELEASE REJECT after receiving a PDU SESSION RELEASE REQUEST by the UE and not accepts the session release with reason #43 (Invalid PDU session identity).
Note: there can be other protocol reasons for not accepting the PDU Session release
## 6.4.3.6 (FF)
- Verify that the IUT sends correctly a PDU SESSION RELEASE REJECT after receiving a PDU SESSION RELEASE REQUEST with a wrong PDU Sesiion ID by the UE and not accepts the session release with reason #43 (Invalid PDU session identity).
Note: possible to test? In this case the IUT can't be triggered with a (interface) message.
## 6.4.2.4.1 UE-requested PDU session modification procedure not accepted by the network (FF)
- Verify that the UE, upon receiving a PDU SESSION MODIFICATION REQUEST by the UE with a request of LADN modification and UE outside service area, sends a SESSION MODIFICATION REJECT with reason #46 (out of LADN service area).
- Verify that the UE, upon receiving a PDU SESSION MODIFICATION REQUEST by the UE with a request for a not supported service by the PLMN, sends a SESSION MODIFICATION REJECT with reason #32 (Service option not supported).
- Verify that the UE, upon receiving a PDU SESSION MODIFICATION REQUEST by the UE with a request including a PTI that is already in use, sends a SESSION MODIFICATION REJECT with reason #35 (PTI already in use).
- Verify that the UE, upon receiving a PDU SESSION MODIFICATION REQUEST by the UE with a request for a wrong 5QI, sends a SESSION MODIFICATION REJECT with reason #59 (Unsupported 5QI value).
