From 00217506c9897ee9b451a40d2a4442426a09327a Mon Sep 17 00:00:00 2001 From: Konrad Schaupp Date: Thu, 16 Jan 2025 10:33:23 +0000 Subject: [PATCH] Update TP_ideas_and_status.md --- TP_ideas_and_status.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/TP_ideas_and_status.md b/TP_ideas_and_status.md index 85ac552..8c87622 100644 --- a/TP_ideas_and_status.md +++ b/TP_ideas_and_status.md @@ -74,6 +74,7 @@ - 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. +[KSCH] PDU Session control is just one procedure using UL and DL TRANSFERs. Chapter 5.4.5.1 lists 9 different payload container types (a) to (i) most of them are not covered by the proposed TPs till now. ## Section 5.5.1.2.4: Initial registration accepted by the network (SINTESIO) @@ -108,6 +109,8 @@ ## 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. @@ -139,6 +142,7 @@ ## 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). @@ -195,6 +199,7 @@ TP_5GNAS_AMF_UPA_ABN_02 - 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. 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. - 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). @@ -210,16 +215,35 @@ TP_5GNAS_AMF_UPA_ABN_02 ## 6.3.3.2 Network-requested PDU session release procedure initiation (FF) Note: possible to test? In this case the IUT can't be triggered with a (interface) message. +[KSCH] Potential Tigger is also the UE originateed PDU SESSION RELEASE REQUEST, besides others e.g. O&M Disable SMF +[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. ## 6.4.2.4.1 UE-requested PDU session modification procedure not accepted by the network (FF) - TP_5GNAS_AMF_UPN_REJ_01 - 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). +[KSCH] should read as "Verify the IUT ..." - TP_5GNAS_AMF_UPN_REJ_02 - 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). +[KSCH] should read as "Verify the IUT ..." - TP_5GNAS_AMF_UPN_REJ_03 - 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). +[KSCH] should read as "Verify the IUT ..." - TP_5GNAS_AMF_UPN_REJ_04 - 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). +[KSCH] should read as "Verify the IUT ..." + +[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.6.2 Paging procedure +- 5.6.3 Notification procedure + +- 6.3.2 Network-requested PDU session modification +- 6.5 5GSM status procedure + +[KSCH] We should specifc what are the restrictions on test coverage and what will be covered in later phases. -- GitLab