[Css-csts] FW: 'cltu radiated' CLTU-ASYNC-NOTIFY messages

[John Pietras]

Wolfgang, Fabienne, and CSTSWG colleagues ---

I've been asked several questions related to timeliness and ordering of
CLTU-ASYNC-NOTIFY invocation. Below are the questions and my responses
in red. I would very much like any corrections, confirmations, or
additional insights that you might provide.

 

Thank you.

 

Best regards,

John

 

 

*         Are there expectations as to the timeliness of the
asynchronous notification, i.e. the latency from the completion of
radiation until the notification is transmitted?

There are no latency requirements that I know of. 

 

*         Is this latency permitted to be negative, i.e. can the
notification be transmitted before the radiation is actually completed,
but with anticipated times in the future for radiation-start-time and/or
radiation-stop-time?  In general, my read here is that one can't
determine whether the cltu-status should be 'radiated,' 'radiation not
started,' or 'interrupted' until the anticipated value of
radiation-stop-time has passed and one learns whether any interruptions
(or halts) of the production-status occurred prior to that time.

My understanding is that there are implementations where the radiation
time is indeed estimated, using a pre-defined delay from a point in the
processing chain capable of actually "seeing" the CLTU (e.g., where the
CLTU is injected into the PLOP). I agree that to be completely correct
the F-CLTU service provider should wait to determine that nothing
failed/halted while the CLTU traverses the remaining distance to the
antenna. In a ground-antenna-based system,  this distance is measured in
perhaps a few hundred meters and the additional delay to confirm no
interruption of transmission is on the order of microseconds. However,
if the SN/SGSS uses the TDRS antenna as the point of radiation, large
fractions of a second would be consumed to account for the delay in
getting from the SGLT to the TDRS. and even if that delay were accounted
for in the radiation calculation, is there any practical way for the
ground segment to be able to recognize that fault in the link occurred
with sufficient accuracy to determine which CLTUs are interrupted?  In
reality, it might be necessary for SN to consider the time of radiation
using the ground antenna as the reference point, and have SGSS declare
successful radiation if a CLTU is judged to have reached that point
without an interruption in the link to that point of radiation.

*         Is there an expectation that the asynchronous notifications
will be transmitted in the same order that the underlying events
occurred (with a possible exception resulting from delayed notification
of service interruption if this implementation option is chosen),
similar to ordering rules for synchronous notifications in the return
service providers, or is such an expectation absent because the
notification is asynchronous rather than synchronous?  (Synchronous or
asynchronous with respect to what?  Is the return notification
synchronous with the return data stream, while the forward notification
is asynchronous with the forward data stream - which moves in the
opposite direction from the notifications - but still ordered?)

I believe that the expectation is that the notifications will follow the
same sequence as that of the occurrence of the events that triggered
them. "Asynchronous" as used here refers to asynchrony with respect to
the TRANSFER-DAA invocations being transferred in the ground-to-space
direction.

If the production-status transitions to 'interrupted' in the middle of
radiation (and assuming that notification-mode is 'immediate'), is the
'cltu radiated' or the 'production interrupted' notification transmitted
first?  

The CLTU-ASYNC-NOTIFY invocation always carries cltu-status and
production-status. I would assume that upon detection of a production
interruption, the system would conclude that the CLTU-in-progress would
also have been interrupted and send a CLTU-ASYNC-NOTIFY invocation with
notification-type = 'production interrupted', cltu-status =
'interrupted', and production-status = 'interrupted' (or am I
misunderstanding the question?). 

 

In the case that there is no actual collision between the interruption
and the radiation, but the interruption occurs after radiation is
complete, are there expectations as to the ordering of notifications'
transmission (in both 'immediate' and 'deferred' notification modes)?

I believe that the expectation is that a CLTU-ASYNC-NOTIFY invocation
would be sent with notification-type = 'cltu radiated',
cltu-last-processed = <ID of the radiated CLTU>, cltu-last-OK = <ID of
the radiated CLTU>, cltu-status = 'radiated', and production-status =
'operational'. 

-          If the production interruption occurred when no subsequent
CLTU was attempting to be radiated, a CLTU-ASYNC-NOTIFY invocation would
be sent with notification-type = 'production interrupted',
cltu-last-processed = <ID of the previously radiated CLTU>, cltu-last-OK
= <ID of the previously radiated CLTU>, cltu-status = 'radiated', and
production-status = 'interrupted'.

-          If the production interruption occurred when a subsequent
CLTU was attempting to be radiated, a CLTU-ASYNC-NOTIFY invocation would
be sent with notification-type = 'production interrupted',
cltu-last-processed = <ID of the interrupted CLTU>, cltu-last-OK = <ID
of the previously radiated CLTU>, cltu-status = 'interrupted', and
production-status = 'interrupted'.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20121119/67163f90/attachment.html