Commit c53666c8 authored by Bostjan Pintar's avatar Bostjan Pintar
Browse files

Resolved comments removed

parent 35215b07
Loading
Loading
Loading
Loading
+1 −10
Original line number Diff line number Diff line
@@ -261,11 +261,6 @@
- TP_5GNAS_AMF_UPR_ACC_01
    - Verify that the IUT handles correctly a PDU session release by sending a PDU SESSION RELEASE COMAND with cause #36 (regular deactivation) after receiving a PDU SESSION RELEASE REQUEST by the UE with cause #36 (regular deactivation).

[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.   
[stl] thank you for the input and the call. Reworked the TO and removed the note.


## 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.
@@ -328,13 +323,9 @@ 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 [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 [BPIN Done]

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