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

Wolfgang.Hell at esa.int Wolfgang.Hell at esa.int
Wed Nov 14 05:25:16 EST 2007


Dear John,

Probably you missed that part of the discussion during our meeting at
Heppenheim due to your involvement in Service Management, but the point was
raised there and I believe that we reached consensus on how to update the
books.

Nonetheless, I would like to share with you my view on the matter just to
make sure that we have a common understanding. Strictly speaking, in RCF the
only thing we may want to talk about is how the production determines that a
frame is of good quality, as RCF only deals with those. In that context the
turbo code as any other maximum likelihood coding scheme is irrelevant as
there is no way to use the result of that decoding to determine the quality
of a frame. That is why the FCS has to be used and that is why the FCS is
mentioned in the RCF book. The other mechanism that allows determining if a
frame is of good quality is the Reed Solomon code. Only if after decoding the
frame consists of valid RS code words, the frame is of good quality. The
capability to check the frame quality on the basis of the decoding result is
the fundamental difference of the RS code and the others. And that is why RCF
mentions RS coding but not any other coding scheme. For that reason I think
that RCF can remain unchanged.

As far as the frame quality is concerned, the above discussion applies also
to RAF. However, as quite validly addressed by Michael Stoloff, as RAF can
also deliver bad frames, we presently are missing a clear specification of
what we actually deliver in case the frame is bad. We (ESA) had in fact some
discussion with Michael at an earlier stage and we revisited the point in the
context of the ESA implementation of turbo decoding at the stations. We
reached the same conclusions as JPL and our implementation will behave the
same way, i.e., the best guess as delivered by the decoder will be sent to
the user. No attempt will be made to deliver the encoded frame, let alone the
soft symbols. We reached consensus in the CSTS working group that the above
outline behaviour shall be documented in the updated version of the RAF book
and I have the action to come up with the revised text. With that addition in
place I believe that turbo coding is adequately covered. Do you agree or do
you see the need for further additions to the RAF book?

Best regards,

Wolfgang




                                                                             
             "John Pietras"                                                  
             <john.pietras at gst.                                              
             com>                                                         To 
             Sent by:                   <css-csts at mailman.ccsds.org>         
             css-csts-bounces at m                                           cc 
             ailman.ccsds.org                                                
                                                                     Subject 
                                        [Css-csts] Insufficient coverage of  
             13/11/2007 17:27           Turbo coding in RAF and RCF          
                                        specifications                       
                                                                             
                                                                             
                                                                             
                                                                             
                                                                             
                                                                             




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





More information about the Css-csts mailing list