[Css-csts] Return SLE services ignore Frame Header Error Control?

[John Pietras]

Wolfgang,
The AOS Space Data Link Protocol (SDLP) specification allows for an optional 2-octet Reed-Solomon Frame Header Error Control (FHEC) field in the Transfer Frame Primary Header. The purpose of the FHEC is to provide "just enough" error correction to be able to correct errors in the header of a frame where full-frame error correction (e.g., via Reed-Solomon) is not provided. As one who worked on the original AOS specification, my recollection is that there were at least two use cases for employing the FHEC: (1) for users that need "standard" VC (and perhaps MC) separation but who want to apply non-standard error correction on the data field (i.e., they would get Bitstream or VCA-SDU service); and (2) for users that need VC/MC separation but don't want and need to overhead of error correction on the full frame (e.g., video, again over Bitstream or VCA-SDU service).

However, neither the RAF nor RCF service specifications address the existence of the FHEC. According to the definition of frame quality for the RAF service, a frame without R-S, Turbo (or LDPC in the next version) full-frame coding that also fails Frame Error Control Field (FECF) decoding is declared to be in error, regardless of the existence and status of the FHEC. Regarding RCF, NOTE 1 under section 2.4.1 states
"The RCF service delivers only telemetry frames that are error-free. The determination that a frame is error-free is based on the frame quality annotation provided by the RAF service production: a frame is considered error-free if it was annotated by the RAF service production with a frame quality of 'good'. The RAF service production annotates a frame as 'good' if the frame contains only valid codewords of the Reed-Solomon code or-if the frame is not Reed-Solomon encoded-if the frame error control field (FECF) decodes successfully."*
[*The RCF service specification suffers from the same problem as RAF with respect to supported error detection/correction schemes - i.e., they only mention Reed-Solomon when they should also address Turbo and now LDPC, and in the future may have to address even more algorithms.]

To the extent that the presence of the FHEC in the AOS primary frame header represents one or more legitimate use cases, delivery of FHEC-corrected frames by the RCF service also represents legitimate use cases. Off the top of my head I can conceive of several ways to accomplish this. For example, one approach would be to add FHEC correction to be performed as part of RAF production processing, with a new value for delivered-frame-quality, 'erred with  corrected header'. Or the job could be pushed off to the RCF service, which would be allowed to accept 'erred' frames (valid only when AOS-only, FHEC-present RAF channels are consumed) as well as 'good' frames.

However, if the decision is to continue to *not* recognize the FHEC in the RAF and/or RCF, then its existence should probably be at least recognized in the RAF and RCF books and an explanation given as to why it is not supported. But ultimately, one has to wonder why, if the authors of the AOS SDLP think (or at least at one time thought) that this was a useful capability, the SLE suite of services should ignore this capability. Maybe the answer is that it is in fact *not* a useful capability, in which case perhaps it should be deprecated from the AOS SDLP.

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130430/fe42af8d/attachment.htm