This responds Nghia Pham's comments about the DVB standard. In the
international space exploration community, we also use a concatenated
convolutional/Reed-Solomon coding scheme. (If you are interested, you can
find out more at http://www.ccsds.org/blue_books.html by taking a peek at
CCSDS 101.0-B-3, Telemetry Channel Coding.) This mechanism uses a
convolutional inner code to bootstrap a really crummy channel up to the
fair-quality region, and a Reed-Solomon outer code to then correct any
residual random or burst errors; if the channel is already fair, the outer
Reed-Solomon can be used by itself. The resulting space channel output then
exhibits on-off characteristics; either 'zero' bit errors, or a complete
data outage. (As an aside, I spent a good chunk of the 1980's "marketing"
this coding scheme to the space mission community with the claim that they
would never again see a bit error; hence my perceived license to tweak my
fellow "marketeers".)
In our case, when Reed-Solomon goes pear-shaped the resulting data outage
consists or one or more (fairly long) Link layer frames potentially
containing several Network layer packets that could be associated with
multiple Transport layer connections. When we are using our "space" version
of TCP at the Transport layer (the "SCPS-TP", see http://www.scps.org/scps)
we can use inter-layer signalling to inform Transport that any detected
packet loss was caused by the Link layer, and not by congestion.
While this Reed-Solomon based coding scheme is widely used across the
international space mission community, it is not ubiquitous. Our missions
(in common, perhaps, with the terrestrial wireless and mobile communities)
tend to be spectrum-constrained, or power-constrained, or both.
Spectrum-constrained missions may not want the bandwidth penalty of coding,
and power-constrained missions often seek to approach the Shannon limit via
new, state of the art coding mechanisms. Some of the latest mechanisms
(e.g., Turbo Codes) don't necessarily display the nice 'on-off"
characteristics of Reed-Solomon, and put us back into the regime of having
to deal with good old fashioned bit errors.
The point - as others have recently stated - is that it is highly unlikely
that there will be a "one size fits all" solution to the problem of space
link errors. I'd drink to Ian McEachern's recommendation: "if you are going
to fix TCP for satellite, you might as well fix it very well - because by
the time it gets widely distributed, most of the people using TCP over
satellite, will be using services and technologies that are not available
today".
Best regards,
Adrian J. Hooke
Telecommunications and Mission Operations Directorate
NASA Jet Propulsion Laboratory
Pasadena, California, USA
+1.818.354.3063 voice; +1.818.354.9068 fax
--------------------------------------------
At 02:56 PM 98/03/31 -0500, nghia PHAM wrote:
>It supports the statement that, if properly engineered, satellite
>links do exhibit an on-off characteristic similar to fibers.
>
>1) The DVB standard (www.dvb.org) for Direct Video Broadcasting
>uses concatenated FEC to sensure quasi-error-free satellite link
>transmission.
>Basically, the FEC is composed of two codes:
>- the outer code is a block code of Reed-Solomon type (204,188,t=8)
>meaning that it can correct 8 erroneous bytes in a block of 204 bytes
>(188 useful + 16 parity)
>- the inner code is convolutional code of constraint length 7
>(state-of-the-art).
>The most commonly used ratio for the inner code is 3/4, meaning one
>parity every 3 useful bits.
>
>Schematically (simplified):
>User bytes->RS outer code->Conv. inner code->satellite link (add noise)
>-->Conv. inner decode ->RS outer decode->reconstructed user bytes.
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:38 EST