[Css-csts] FW: New EFCLTU Orang Book Available on CCSDS CWE
John Pietras
john.pietras at gst.com
Fri Apr 16 12:35:20 EDT 2010
CSTSWG colleagues ---
The latest draft version of the Enhanced FCLTU SLE Transfer Service
Orange Book is posted on the CCSDS CWE at
http://cwe.ccsds.org/css/docs/CSS-CSTS/Draft%20Documents/Enhanced%20FCLT
U%20Orange%20Book%20drafts/EnhancedFCLTU-912_1-O-101_4.zip
<http://cwe.ccsds.org/css/docs/CSS-CSTS/Draft%20Documents/Enhanced%20FCL
TU%20Orange%20Book%20drafts/EnhancedFCLTU-912_1-O-101_4.zip>
or http://tinyurl.com/EFCLTU-v-0-4 <http://tinyurl.com/EFCLTU-v-0-4>
Althought this Orange Book has been incrementally derived over the
course of the past year or so, it is useful to summarize the differences
from the CCSDS-standard FCLTU service upon which it is based.
The differences between the EFCLTU Orange Book and the FCLTU Blue Book
are all driven by the addition of support for the CCSDS synchronous data
link protocol. This now mode is collectively dubbed "PLOP-3", even
though it encompasses more than tradition PLOPs (Physical Layer
Operations Procedures) defined for the asynchronous Telecommand space
link protocol that is the basis for the original FCLTU SLE service. The
major differences between the EFCLTU Orange Book and the FCLTU Blue Book
are all associated with operating in PLOP-3 mode:
* The transfer service can transfer Advanded Orbiting System
(AOS) transfer frames or Channdel Access Data Units (CADUs). The
transfer frames/CADUs can be packed into CLTU-TRANSFER-DATA invocations
singly or multiple frames/CADUs per invocation
* If the CLTU-TRANSFER-DATA invocations carry transfer frames,
they are converted into CADUs by (a) either Reed-Solomon or Low Density
Parity Check (LDPC) block encoding the frame, (b) optionally randomizing
the resulting codeblock, and (c) prepending a synchronization to the
(randomized) codeblock to form a CADU.
* The stream of CADUs (either as-received from the user of the
transfer service or as produced locally from transfer frames) may be
convolutionally encoded prior to being put of the uplink (forward link).
* When the lack of user-supplied frames/CADUs would otherwise
cause a lack of data to be available for uplinking, a complete "idle
space link protocol data unit" (i.e., idle transfer frame or idle CADU)
is to be injected into the uplink.
* If a "CLTU" is discarded because its latest-radiation-time is
reached before the CLTU has been radiated, the CLTU-ASYNC-NOTIFY is
invoked with notification-type = 'sldu expired'), but the service
continues to operate (in contrast to blocking until restarted, as is the
case with PLOPs 1 & 2).
* The value of the cltu-identification parameter in the
CLTU-TRANSFER-DATA invocation is ignored for the purposes of the
invocation being accepted (in contrast to rejecting the CLTU if the
value of the cltu-identification parameter in the CLTU-TRANSFER-DATA
invocation is not what the provider is expecting, as is the case with
PLOPs 1 & 2).
* The value of the cltu-identification parameter in the
CLTU-TRANSFER-DATA return is equal to the cltu-identification parameter
in the corresponding CLTU-TRANSFER-DATA invocation (in contrast to
returning the ID number of the next expected CLTU, as is the case with
PLOPs 1 & 2. Since the PLOP-3 mode ignores the sequence number for the
purposes of the invocation being accepted (see above), this parameter is
more useful as a confirmation of receipt of the CLTU).
* The large majority of the specification of PLOP-3-related
processing is in the normative Anned D of the Orange Book. However, in
order to differentiate between "CLTU" as the entity that is transferred
by the transfer service, and "CLTU" as the Telecommand asynchronous
space link protocol data unit, the terminology has been modified
throughout the main body of the specification. Specifically, the
distinction has been made between "SLE-CLTU" (the content of the data
parameter of the CLTU-TRANSFER-DATA invocation, which could be AOS
transfer frame(s), CADU(s), or a TC CLTU) and "PL-CLTU" (a CLTU as used
in the context of Telecommand PLOPs 1 & 2). However, the ASN.1 remains
unchanged (Note that the ASN.1 "CLTUs" correspond to "SLE-CLTUs").
I look forward to discussing this Orange Book at the meeting in
Protsmouth.
Best regard,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20100416/8dd7d868/attachment.html
More information about the Css-csts
mailing list