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

Fri May 3 10:10:51 EDT 2013

John,

I came across this optional Frame Header Error Control as well - in that case
it was in the context of SAR raw data. This is a scenario where one needs to
be able to demultiplex the TM stream into MCs and/or VCs, but due to the
specific algorithm applied to the raw SAR data for calculating the SAR image,
the bit error rate for the raw data does not matter too much as the final
image is insensitive to errors in the raw data. So yes, there are
applications where this AOS feature might be useful, but taking my example,
the rate and very special processing imply that the data are actually
directly ingested into a mission specific processing chain. Therefore in the
world of cross-support we can probably disregard this case.

I believe that there is a good reason that RAF does not deal with this AOS
feature, as it is a service that delivers frames as per annex A of CCSDS
131.0-B-2 and not headers. Note that this annex A does not make any
provisions for dealing with the AOS FEFH feature. The specification mandates
that together with the frame a quality indicator is provided that flags if
the frame (not the header) contains uncorrectable errors.

As regards the way this quality indicator is determined, CCSDS 131.0-B-2 is
unfortunately in my view that completely clean. On the one hand we have
section 2.2.3 that states that except for RS or LDPC encoded frames, the FECF
shall be used to determine the frame quality. On the other hand, as per CCSDS
132.0-B-1 the presence of the FECF is unconditionally optinal, i.e. the
dependency on the coding is disregarded. In this context please note that
turbo is also a form of maximum likelihood decoding and therefore the FECF is
required to determine the frame quality. That is not the case for LDPC as
there one can find out if after correction the result is a valid codeword
(same as for RS). So in that respect the only change to be made (as discussed
within CSTS) to RAF is to mention that also for LDPC the frame quality is
determined by the decoding process proper and the FECF if present will be
ignored.

Given the above considerations, my preference would be to leave RAF alone
except for adding a note that states that FHEC is not supported. Given that
this AOS feature is so specific and not even recognized by the frame service
defined in CCSDS 131.0-B-2, if there is a need for cross-supporting
demultiplexing of frames of unknown quality, one should create a dedicated
service. I do not have sufficient information on the extent to which this AOS
feature is used in practice and therefore no solid grounds for proposing that
it should be deprecated.

Best regards,

Wolfgang

|------------>
| From:      |
|------------>
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
  |John Pietras <john.pietras at gst.com>                                                                                                                   |
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
  |"Wolfgang.Hell at esa.int" <Wolfgang.Hell at esa.int>                                                                                                       |
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
  |"CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" <css-csts at mailman.ccsds.org>                                                                              |
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
  |30/04/2013 17:31                                                                                                                                      |
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
  |Return SLE services ignore Frame Header Error Control?                                                                                                |
  >------------------------------------------------------------------------------------------------------------------------------------------------------|

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

This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.