[Css-csts] effects of Repetitions on SLE F-CLTU and FSP services?

[John Pietras]

CSTSWG and SMWG colleagues ---

Version 2 of the TC Synchronization and Channel Coding Recommended
Standard (CCSDS 231.0-B-2, September 2010) "specifies an option for
repeated transmissions of Transfer

Frames". According to the normative Annex A of that Blue Book, the
repetition is specified as part of the ChanneAccess.request primitive,
which has two parameters, Frames and Repetitions. The Frames parameter
contains the transfer frames that are to be contained within a single
CLTU, and the Repetitions parameter specifies how many times that CLTU
is to be transmitted. The existence of this Repetition parameter is not
reflected in the SLE F-CLTU or FSP transfer service specifications, nor
is it currently reflected in the version 1 SCCS-SM Blue Book. This is a
concern to both the CSTSWG and SMWG: if it should have an effect on
F-CLTU, FSP (and the future Forward Frames service)then those books need
to be updated accordingly, and their management aspects will have to be
addressed in the ongoing Service Management work.

 

Repetition may or may not affect the F-CLTU service, depending on where
the repeated CLTUs are generated. If they are generated by the F-CLTU
service user, then there is no effect: the repeated CLTUs arrive in
separate CLTU-TRANSFER-DATA invocations and are treated by the F-CLTU
service provider the same way as non-repeated CLTUS would be treated.
This of course multiplies the traffic on the underlying communication
service, but that may not be an issue if that underlying service would
be otherwise idle. On the other hand, internalizing the repetition of
the CLTUs as part of F-CLTU service production would raise issues
regarding the interpretation of earliest and latest radiation times and
possibly the delay-time  parameter.

 

In the case of the FSP service, however, the generation of frames from
packets and CLTUs from frames is performed as part of FSP service
production, which technically internally includes the ChannelAccess
interface. Should each packet be accompanied by its own repetition
parameter in the FSP-TRANSFER-DATA invocation (allowing the decision to
repeat to vary on a packet-by-packet basis), or should it a be a managed
parameter of the Service Package? What would be the effect on earliest
and latest radiation times and the inter-CLTU delay times?

 

Alternatively, the repetition of frames (and subsequently CLTUs) could
be synthesized by having the FSP service user generate and send
multiple copies of the same packet in successive FSP-TRANSFER-DATA
invocations. This would also put the bounds on radiation time in
complete control of the user via the earliest and latest production
times and delay-time parameters of each successive FSP-TRANSFER-DATA
invocation. However, if this is the approach that is taken, one has to
wonder about the circumstances under which the Space Link Coding and
Synchronization Working Group envisioned that a single frame would be
repeated. Presumably they had  a use case that justified repetition at
the coding layer interface (as opposed to, for example, repetition at
the packet level). Is that use case undermined by the repeated packet
approach?

 

Finally, note that essentially the same issues will affect the TC mode
of the future Forward Frames service, namely; should the FF service take
in one frame and repeat it as part of the service production, or should
the repetition be performed be the user?

 

Best regards,

John 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120530/9aa0da83/attachment.html