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