diff --git a/TP_ideas_and_status.md b/TP_ideas_and_status.md
index dccbe087058524903f6e8ae720077bba41b8fba4..a03d6f8152d6508deb99073f0747f650494444c2 100644
--- a/TP_ideas_and_status.md
+++ b/TP_ideas_and_status.md
@@ -81,6 +81,7 @@
 - TP_5GNAS_AMF_DLN_ACC_01
     - 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)
@@ -115,6 +116,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.
@@ -146,6 +149,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).
@@ -202,6 +206,7 @@
 - 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).
@@ -217,16 +222,35 @@
 
 ## 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.