[Css-csts] Another CLCW-PLOP-production status issue

[John Pietras]

Wolfgang,
Shortly after sending my previous message today, I received another message from a colleague working on the NASA SGSS Project. Many of the questions that I've raised about the interrelationships among the CLCW flags, CMMs, and production status have been triggered by inquiries from SGSS personnel. This latest one has to do with what my colleague perceived to be the inability to recover from a production interruption due to loss of bit lock in PLOP-1. His concern is that if bit-lock is required, if it is ever lost, production status -> 'interrupted' and receipt of CLTUs is inhibited. If no CLTUs can be received, there will be no CLTUs to trigger the transmission of the acquisition sequence  that would re-establish bit lock to clear the interrupted status.

My response to him was that by invoking the STOP operation the blocking of CLTU transfer would be removed. However, I realized that I was also assuming that the source of the interrupted status would be cleared, thus enabling a subsequent START to be successful and CLTU-TRANSFER-DATA invocations to flow. However, there's nothing that explicitly states that. The closest thing to addressing this situation is the NOTE under 3.7.2.3 (c) of FCLTU B-3 , "The user can unblock the service instance by invoking a CLTU-STOP operation.  After the condition causing the 'production interrupted' event is corrected, the provider notifies the user by means of a 'production operational' notification.  The user can resume the transfer and radiation of CLTUs after successfully invoking CLTU-START." Strictly speaking, FCLTU production/provision can't "know" that the condition causing the interruption has been cleared because the means of ascertaining that (sending bits on the uplink and seeing the resultant bit lock in the CLCW) is inhibited.

If the intent is to have loss of bit lock interrupt service only long enough to force blocking of the CLTU-TRANSFER-DATA operations, maybe we don't in fact want to call this an interruption of production - maybe we just want to state that TRANSFER-DATA is blocked.  Or maybe we can treat it as an impulse interruption that occurs and clears almost immediately, just for the sake of generating the appropriate notifications.

How should this work?

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130222/40c34729/attachment.htm