Merge branch 'TTF_T041' of https://forge.etsi.org/rep/int/5g-core/nas into TTF_T041

## Section 5.4.1.3.7 (FF)

- TP_5GNAS_AMF_AUT_ABN_01

    - 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)

    - Verify that the IUT sends a new AUTHENTICATION 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.

        - Please check Note 2: "... the network may also terminate the 5G AKA based primary authentication ..." Depends on ID used in Initial NAS message

## 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

[KSCH] How does "the first round of implementation" correspond to the roadmap distributed?

[KSCH] What is the guideline/rule to assign TPs to the different implementation rounds? Maybe we should give potentail users a chance to know what could be expected by when.

 - TP_5GNAS_AMF_REG_ABN_01

    - Verify that the IUT retransmits the REGISTRATION ACCEPT message and restarts timer T3550 upon the first four expirations.

    - Validate that the AMF rejects a REGISTRATION REQUEST message with invalid or unacceptable UE security capabilities by sending a REGISTRATION REJECT message.

## 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

[KSCH] see above.

- 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).

## 6.4.2.4.1 UE-requested PDU session modification procedure not accepted by the network (FF)

- TP_5GNAS_AMF_UPN_REJ_01

    - Verify 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 the IUT, 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).

- TP_5GNAS_AMF_UPN_REJ_02

    - Verify 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 the IUT, 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). 

- TP_5GNAS_AMF_UPN_REJ_03

    - Verify 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 the IUT, 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).

- TP_5GNAS_AMF_UPN_REJ_04

    - Verify 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).

    - Verify the IUT, 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).

## 6.4.3.2, 6.4.3.4 (FF)

- TP_5GNAS_AMF_UPR_REJ_01

    - 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).

- TP_5GNAS_AMF_UPR_REJ_02

    - 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 Abnormal cases on the network side (FF)

- TP_5GNAS_AMF_UPR_ABN_01

    - 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).

# TP objectives ideas

## 5.6.1.1

- TP_5GNAS_AMF_SRP_ACC_01

    - Verify that the IUT sends a SERVICE ACCEPT message after receiving a SERVICE REQUEST message by the UE, that was initated by a paging request to the UE in 5GMM-IDLE mode over 3GPP access.

- TP_5GNAS_AMF_SRP_ACC_02

    - Verify that the IUT sends a SERVICE ACCEPT message after receiving a SERVICE REQUEST message by the UE, that was initated by a notification with access type indicating non-3GPP access to the UE while in 5GMM-CONNECTED mode over 3GPP access.

- TP_5GNAS_AMF_SRP_ACC_03

    - Verify that the IUT sends a SERVICE ACCEPT message after receiving a SERVICE REQUEST message by the UE due to having uplink signalling pending while in 5GMM-CONNECTED mode over 3GPP access.

- TP_5GNAS_AMF_SRP_ACC_04

    - Verify that the IUT sends a SERVICE ACCEPT message after receiving a SERVICE REQUEST message by the UE due to having uplink user data pending while in 5GMM-CONNECTED mode over 3GPP access.

- TP_5GNAS_AMF_SRP_ACC_05

    - Verify that the IUT sends a SERVICE ACCEPT message after receiving a SERVICE REQUEST message by the UE due to having user data pending due to no user-plane resources established for PDU session(s) used for user data transport while in 5GMM-CONNECTED mode.

- TP_5GNAS_AMF_SRP_ACC_06

    - Verify that the IUT sends a SERVICE ACCEPT message after receiving a SERVICE REQUEST message by the UE due to having user data pending due to no user-plane resources established for PDU session(s) used for user data transport while in 5GMM-CONNECTED mode with RRC inactive indication.

- TP_5GNAS_AMF_SRP_ACC_07

    - Verify that the IUT sends a SERVICE ACCEPT message after receiving a SERVICE REQUEST message by the UE due to receiving a request from the upper layers to perform emergency service fallback while in 5GMM-IDLE mode.

- TP_5GNAS_AMF_SRP_ACC_08

    - Verify that the IUT sends a SERVICE ACCEPT message after receiving a SERVICE REQUEST message by the UE due to receiving a request from the upper layers to perform emergency service fallback while in  5GMM-CONNECTED mode over 3GPP access.

- TP_5GNAS_AMF_SRP_ACC_09

    - Verify that the IUT sends a SERVICE ACCEPT message after receiving a SERVICE REQUEST message by the UE due to receiving a request from the upper layers to perform emergency service fallback while in 5GMM-CONNECTED mode with RRC inactive indication.

- TP_5GNAS_AMF_SRP_ACC_10

    - Verify that the IUT sends a SERVICE ACCEPT message after receiving a SERVICE REQUEST message by the UE due to using 5GS services with control plane CIoT 5GS optimization and has pending user data to be sent via user-plane resources while in 5GMM-CONNECTED mode and has a NAS signalling connection only.

- TP_5GNAS_AMF_SRP_ACC_11

    - Verify that the IUT sends a SERVICE ACCEPT message after receiving a SERVICE REQUEST message by the UE due to requesting resources for V2X communication over PC5 while in 5GMM-IDLE mode over 3GPP access.

## 6.4.3.2, 6.4.3.4 (FF)

- TP_5GNAS_AMF_UPR_ACC_01

    - Verify that the IUT handles correctly a PDU SESSION RELEASE REQUEST after receiving a PDU SESSION RELEASE REQUEST by the UE.

    - Verify that the IUT handles correctly a PDU session release 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.

[KSCH] Hard to understand. Do you mean the fact that there is no "PDU SESSION RELEASE CONFIRM" to acknowledge a UE Initialted "PDU SESSION RELEASE REQUEST". Think SMF has to send PDU SESSION RELEASE COMMAND after reception of UE Initiated Release Request to complete the release procedure. 

[stl] Answer: As far as i understand the PDU SESSION RELEASE COMMAND is only used in cases where the SMF initiates the PDU session release. This testcase deals with a UE initiated session release. My understanding from the base spec is: SMF will release the session without any further interaction with the UE. It should be possible to verify the correct session release by using another message that try to use this not longer existing PDU session. But I left that out on purpose for the TO (only as note) because i think the real check in the end should not be part of the TO.

[KSCH] What do you think about figure 6.4.3.2.1 or chapter 6.4.3.3 or the fact we have timer T3585 defined? All this are important hints that network has to initiate PDU Session Release commmand ater reception of PDU Session Release Request from the UE. Maybe you should check some real line logs for correct handling.   

- TP_5GNAS_AMF_UPR_REJ_01

    - 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).

- TP_5GNAS_AMF_UPR_REJ_02

    - 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.3.3.2 Network-requested PDU session release procedure initiation (FF)

[KSCH] There are several procedures, which can't be triggered with an interfce message. We should not restrict the environment in that way, as the overall test coverage would be reduced drastically. As mentioned above an O&M Interface has to be supported for other reasons as well. 

## 5.4.6 5GMM status procedure (SINTESIO)

## 5.4.6.2 5GMM status received in the UE

- TP_5GNAS_AMF_EST_STA_01

    - Verify that IUT is able to trigger 5GMM STATUS message with all mandatory IEs. 

## 5.4.6.3 5GMM status received in the network

- TP_5GNAS_AMF_EST_STA_02

    - Verify that IUT is able to receive 5GMM STATUS message from UE and no state transition and no specific action shall be taken.

## 6.5 5GSM status procedure  (SINTESIO)

## 6.5.2 5GSM status received in the UE

- TP_5GNAS_AMF_SST_STA_01

    - Verify that IUT is able to trigger 5GSM STATUS message with all mandatory IEs. 

## 6.5.3 5GSM status received in the SMF

- TP_5GNAS_AMF_SST_STA_02

    - Verify that IUT is able to receive 5GSM STATUS message from UE and no state transition and no specific action shall be taken.

## 5.4.4.2 Generic UE configuration update procedure initiated by the network (SINTESIO)

- TP_5GNAS_AMF_CNF_COM_01

    - Verify that the IUT initiates the generic UE configuration update procedure by sending the CONFIGURATION UPDATE COMMAND message and not contains Acknowledgment requested bit in the Configuration update indication IE when only the Network Identity and Time Zone (NITZ) parameter is included.

- TP_5GNAS_AMF_CNF_COM_02

    - Verify that the IUT initiates the generic UE configuration update procedure by sending the CONFIGURATION UPDATE COMMAND message containing one or more parameters (e.g., 5G-GUTI, TAI list,...) and containing Configuration update indication IE with Acknowledgement bit set to "acknowledgement requested"

- TP_5GNAS_AMF_CNF_COM_03

    - Verify that the IUT initiates the generic UE configuration update procedure only due to changes to the allowed NSSAI and

these changes require the UE to initiate a registration procedure then IUT sends the CONFIGURATION UPDATE COMMAND message not containing any other parameters except Configuration update indication IE with the Registration requested bit set to "registration requested" and Acknowledgement bit set to "acknowledgement requested" and

## 5.4.4.4 Generic UE configuration update completion by the network (SINTESIO)

- TP_5GNAS_AMF_CNF_REL_01

    - Verify that the IUT initiates the generic UE configuration update procedure by sending the CONFIGURATION UPDATE COMMAND message containing an allowed NSSAI, a configured NSSAI or both and Configuration update indication IE with the Registration requested bit set to "registration requested" and Acknowledgement bit set to "acknowledgement requested".

and then the IUT initiates the release of the N1 NAS signalling connection.

## 5.4.4.6 Abnormal cases on the network side (SINTESIO)

- TP_5GNAS_AMF_CNF_ABN_01

    - Verify that the IUT retransmits the CONFIGURATION UPDATE COMMAND message and restarts timer T3555 upon the first four expirations. (i.e. on

the fifth expiry of timer T3555, the procedure shall be aborted.)

- TP_5GNAS_AMF_CNF_ABN_02

    - Verify that IUT aborts the generic UE configuration update procedure

and progress the de-registration procedure in case if the network receives a DEREGISTRATION REQUEST message before the ongoing generic UE configuration

update procedure has been completed

- TP_5GNAS_AMF_CNF_ABN_03

    - Verify that IUT aborts the generic UE configuration update procedure

and progress the registration procedure for mobility and periodic registration update procedure in case if the network receives a REGISTRATION REQUEST message before the ongoing generic UE configuration

update procedure has been completed

- TP_5GNAS_AMF_CNF_ABN_04

    - Verify that IUT proceeds with both procedures in case if the network receives a SERVICE REQUEST message before the ongoing generic UE configuration update

procedure has been completed

[KSCH] General Remark on Test Coverage

Potential Proedures to be tested - for the sake of total test coverage

- 5.4.4 Generic UE configuration update procedure

- 5.4.6 5GMM status procedure

- 5.6.1 Service request procedure (a) to l) 12 different types - some are covered)

- 5.4.4 Generic UE configuration update procedure [BPIN Done]

- 5.4.6 5GMM status procedure  [BPIN Done]

- 5.6.1 Service request procedure (a) to l) 12 different types - some are covered) [BPIN 5.6.1.1 Done]

- 5.6.2 Paging procedure

- 5.6.3 Notification procedure

- 6.3.2 Network-requested PDU session modification

- 6.5   5GSM status procedure

- 6.5   5GSM status procedure [BPIN Done]

[KSCH] We should specifc what are the restrictions on test coverage and what will be covered in later phases. 

#NAS_Pics.PICS_NAS_AMF_IUT := true

NG_NAS_Pics.PICS_NGNAS := true

# 5GRegAuthSec_deReg.pcap

LibNGAP_Pixits.PX_AMF_NAME       := "Kontron5G-amf"

LibNGAP_Pixits.PX_RAN_UE_NGAP_ID := 0

LibNGAP_Pixits.PX_AMF_UE_NGAP_ID := 22

[LOGGING]

# In this section you can specify the name of the log file and the classes of events

# you want to log into the file or display on console (standard error).

[TESTPORT_PARAMETERS]

# In this section you can specify parameters that are passed to Test Ports.

system.NGAP_gNB_1.params := "NGAP/SCTP_FILE/IP_OFFLINE/PCAP_FILE(file=../captures/TP_5GNAS_AMF_REG_REJ_01.pcapng)"

system.N2_gNBaMF_P.params := "NGAP/SCTP_FILE/IP_OFFLINE/PCAP_FILE(file=../captures/TP_5GNAS_AMF_REG_REJ_01.pcapng)"

system.NGAP_gNB_1.params := "NGAP/SCTP_FILE/IP_OFFLINE/ETH(mac_src=8c554ac1eee0,mac_dst=8c554ac1eee1)/PCAP_FILE(file=../captures/5GRegAuthSec_deReg.pcap)"

system.N2_gNBaMF_P.params := "NGAP/SCTP_FILE/IP_OFFLINE/ETH(mac_src=8c554ac1eee0,mac_dst=8c554ac1eee1)/PCAP_FILE(file=../captures/5GRegAuthSec_deReg.pcap)"

#aMFNASComponent.N2_gNBaMF_P.params := "NAS/SCTP_FILE/IP_FILE/ETH/PCAP_FILE(file=../captures/free5gc.pcap)"

[DEFINE]

#NG_NAS_TestCases.TC_5GNAS_AMF_AUT_REQ_03

#NG_NAS_TestCases.TC_5GNAS_AMF_AUT_REQ_04

#NG_NAS_TestCases.TC_5GNAS_AMF_AUT_REQ_05

#NG_NAS_TestCases.TC_NGNAS_AMF_AUT_SEQ_01

#NG_NAS_TestCases.TC_5GNAS_AMF_AUT_ABN_01

NG_NAS_TestCases.TC_NGNAS_AMF_AUT_SEQ_01

#NG_NAS_TestCases.TC_5GNAS_AMF_SEC_ACC_01

#NG_NAS_TestCases.TC_5GNAS_AMF_SEC_REJ_01

#NG_NAS_TestCases.TC_5GNAS_AMF_DLN_ACC_01

#NG_NAS_TestCases.TC_5GNAS_AMF_REG_ACC_01

#NG_NAS_TestCases.TC_5GNAS_AMF_REG_ACC_02

#NG_NAS_TestCases.TC_5GNAS_AMF_REG_ACC_03

NG_NAS_TestCases.TC_5GNAS_AMF_REG_REJ_01

#NG_NAS_TestCases.TC_5GNAS_AMF_REG_ACC_04

#NG_NAS_TestCases.TC_5GNAS_AMF_REG_ACC_05

#NG_NAS_TestCases.TC_5GNAS_AMF_REG_REJ_01

#NG_NAS_TestCases.TC_5GNAS_AMF_REG_REJ_02

#NG_NAS_TestCases.TC_5GNAS_AMF_DRG_ACC_01

#NG_NAS_TestCases.TC_5GNAS_AMF_DRG_ACC_02

#NG_NAS_TestCases.TC_5GNAS_AMF_DRG_REQ_01

#NG_NAS_TestCases.TC_5GNAS_AMF_DRG_REQ_02

#NG_NAS_TestCases.TC_5GNAS_AMF_DRG_REQ_03

[GROUPS]

# In this section you can specify groups of hosts. These groups can be used inside the

            - isAttachingToNetwork

            - hasDoneSubscription

            - indicate

            - trigger

            - isCMIDLE

            - isCMCONNECTED

            - alreadyPreparedHandover

        NgapMessage UPLINK_RAN_EARLY_STATUS_TRANSFER;

        NgapMessage DOWNLINK_RAN_EARLY_STATUS_TRANSFER;

        NgapMessage SECURITY_MODE_COMPLETE;

        NgapMessage SECURITY_MODE_REJECT;

        //Table 8.2

        NgapMessage AUTHENTICATION_REQUEST;

        NgapMessage AUTHENTICATION_RESPONSE;