[Css-csts] Insufficient coverage of Turbo coding in RAF and RCF specifications

[Michael Stoloff]

Substantively, the most critical omission is that the RAF service 
specification does not indicate what the provider should deliver to 
the user in the case of an erred frame.

By analogy with what the specification says about the Reed-Solomon 
case, one might assume that what should be delivered is the frame 
before decoding (that is, at the input to the turbo 
decoder).  However, that raises further questions.  Since the turbo 
decoder works in the symbol domain, that would require delivering 
digitized symbols, but should those be "hard" symbols or "soft" 
(quantized) symbols.  Hard symbols require less bandwidth but are far 
less useful than soft symbols, particularly in the case of an erred 
frame.  If soft symbols are to be delivered, how many bits of 
quantization are required?  In actual cases, either option may be 
undesirable or impractical due to the additional ground 
communications bandwidth between the provider and the user that would 
be required.

As a point of information, what the current DSN implementation 
delivers in the case of an erred frame is the turbo decoders best 
estimate of the "decoded frame" (that is, a sequence of bits, equal 
in length to what the turbo decoder outputs when a frame is decoded 
successfully, but which does not meet the decoder's criteria for a 
good frame).  Although this output is fairly useless, it does have 
the virtue of not placing an added burden (compared with the nominal 
case) on the provider's utilization of ground communications bandwidth.

--Regards,
   Michael

At 08:27 AM 11/13/2007, John Pietras wrote:
>Turbo coding is insufficiently covered in the RAF B-2 and RCF B-1
>specifications. Although Section 2.4.1 (d) of the RAF specification does
>recognize Turbo coding ("...performs convolutional decoding, removal of
>pseudo-randomization, error control field decoding, and/or Reed-Solomon
>or Turbo decoding as applicable..."), this section is only informative.
>The normative sections ignore Turbo coding and refer only to
>Reed-Solomon and error control field checks., e.g., section 3.6.2.6.1
>("The delivered-frame-quality parameter shall indicate the result of
>Reed-Solomon decoding or error control field decoding and shall contain
>one of the following values..."). Turbo coding should be added to the
>normative sections of the specification.
>
>The RCF B-1 spec ignores Turbo coding completely, speaking only of
>Reed-Solomon and error control field coding. Even though frame coding is
>addressed informatively in section 2 (because it is assumed to be
>performed as part of "RAF production"), it should be mentioned wherever
>Reed-Solomon coding is mentioned (and referenced, etc.).
>
>Best regards,
>John
>
>John Pietras
>Global Science & Technology, Inc. (GST)
>7855 Walker Drive
>Suite 200
>Greenbelt, Maryland, USA
>20770-3239
>Direct:   +1-240-542-1155
>GST Main: +1-301-474-9696
>Fax:      +1-301-474-5970
>
>
>_______________________________________________
>Css-csts mailing list
>Css-csts at mailman.ccsds.org
>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts