[Sls-ngu] Consideration of data compression as a topic for discussion in NGU meeting

[Kazz, Greg J (313B)]

Gilles,

D'accord. In particular your last suggestion.
I am working with Aaron Kiely to examine how we can move this forward before the London meeting.
By the way, I can provide a representative flight software load binary file from the MSL mission for evaluation.
Can you provide some representative uplink data sets from CNES for this evaluation?

Thanks,

Greg

From: Moury Gilles [mailto:gilles.moury at cnes.fr]
Sent: Wednesday, June 30, 2010 9:33 AM
To: Kazz, Greg J (313B); sls-ngu at mailman.ccsds.org; sls-hru at mailman.ccsds.org
Cc: Gian.Paolo.Calzolari at esa.int; jean-luc.gerner at esa.int
Subject: RE: [Sls-ngu] Consideration of data compression as a topic for discussion in NGU meeting

Greg,

Indeed compression is being used on the uplink when data rate / pass duration are not sufficient to upload a work plan (for example). On our LEO earth observation spacecrafts, we often use what we call "macrocommands" to actually encode the daily work plan so that it can be uploaded in one single pass at 2 or 4 kbps. This macrocommand syntax is a way of compressing work plans or sequences of commands by encoding with one single macrocommand a complete Operational Control Procedure. This type of compression is of course highly mission dependent and cannot be subject to standardization. Nevertheless, it is very efficient.

On the contrary, a generic standard lossless compression for S/C uploads could be envisaged derived from a mainstream universal lossless compression algorithm like LZ (deflate RFC). This approach is interesting if a single algorithm (with reasonable decoding complexity) provides significant  and consistent performances (2:1 compression ratio on average at least) for a wide range of uploads types (work plans, software uploads, FPGA configuration uploads, parameter tables uploads (e.g. star catalogues), ...).

The first step would be to assemble a set of representative uploads covering the whole range of type of traffic on TC links, and then perform performance test with LZ. This initial step is necessary to decide on agency interest for such a TC compression CCSDS standard.

Discussion with MHDC WG before next meeting could be beneficial to assess their capability to support this first step, and to gather their technical opinion on the opportunity/feasibility of such a standardization.

Best regards,

Gilles


Gilles MOURY
CNES Toulouse


________________________________
De : sls-ngu-bounces at mailman.ccsds.org [mailto:sls-ngu-bounces at mailman.ccsds.org] De la part de Kazz, Greg J (313B)
Envoyé : mardi 29 juin 2010 00:57
À : sls-ngu at mailman.ccsds.org; sls-hru at mailman.ccsds.org
Cc : Gian.Paolo.Calzolari at esa.int
Objet : [Sls-ngu] Consideration of data compression as a topic for discussion in NGU meeting
All,

Please let me know if you would be interested in having a discussion on the use of data compression as a technique towards conserving bandwidth on the uplink.
In other words, do you think compression is likely to be a big payoff and manageable, and worthy of inclusion in a CCSDS NGU standard, etc. ?

A current example of using compression on the uplink is the NASA Mars Science Laboratory Project which is tentatively planning to use one of the Lempel Ziv (LZ) encoders for compressing flight software loads.

Data compression could be another technique that the NGU WG should consider for standardization for NGU applications. Considering that the CCSDS Convolutional Code can approximately provide about a 5 db gain, and the LDPC about 7 db.  if we can get 3+ db from compression  it might be a worthwhile contender for consideration.

So this additional work could manifest itself by involving agency collaboration on studying the various compression candidates for use on the uplink. If that is the case, then NGU would need support from the MHDC WG in supporting such a study.

Some of the question we could consider asking ourselves are:

(1) Can we come up with uplink data sets that are good examples of the type of uplink data that requires compression and that compresses well?
(2) How much improvement might we get from different variations of compression algorithms on the data types that are worth studying ?
(3) Have we convinced ourselves that the NGU data volume problem is significant enough in the first place to warrant compression ?
(4) Is 2:1 lossless compression our goal ?
(5) What are the candidate compression algorithms and what are the metrics to judge them by ?
(6) I don't know how much interest there is from other CCSDS member agencies on this topic - please let me know.

If I get positive feedback from member agencies on this survey, then I will pass this along to the MHDC WG to see if we can start up an email dialog with them before the London meeting and also schedule some time in London if necessary to meet with them.

Best regards,

Greg Kazz
Chairman CCSDS NGU WG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sls-ngu/attachments/20100630/c394827d/attachment-0001.html