Subject: two concerns

From: nghia PHAM <[email-masked]>
Date: Tue, 31 Mar 1998 14:56:38 -0500

Sorry if some of you received this message twice.

This message is to contribute to the discussions about error
characteristics on satellite links.
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.

The US DSS standard uses a similar coding scheme.

2) Define Raw BER as BER before decoding by inner FEC (BER after
demodulation).
It can be shown  that:
Raw BER= 2E-2,
==> BER =2E-4 after inner FEC (with soft decision decoding)
==> BER<1E-11 after outer FEC decoding
This is less than one error event per hour, at 40Mbit/s user bit rate.
(I have checked that in my lab).

3) Furthermore, it can be shown that:
Raw BER =1.6E-2
==> BER=7E-5 after inner FEC decoding
==> BER<1E-15 after outer FEC decoding
That is less than one error event per  year.

4) Furthermore, it can be shown that when the RS cannot
decode it produces very large strings of errors. Usually, the block
code synchronisation fails as well. This occurs
at raw BER=5E-2 approximately.
This is why we prefer to talk about error events rather than
BER at the user bits level.

5) For digital TV broadcasting in the Ku-band (satellite frequencies
in 10.7-12.75 GHz) we at EUTELSAT dimension the satellite link so that the
raw
BER of 2E-2 is not exceeded more than 99.7% of the worst month
( the month of the year when it rains more than any others),
and for the worst-case interference scenario. 
Current statistics show that, for a properly installed consumer 
dish (60cm), there are no more than 5 signal
outages in the year, each lasting about 5 to 20 minutes. Higher dish
size offer less outages. Increasing by 40% the dish size gives an
additional
3 dB margin, resulting in 99.9% availability in the worst-month.
(the trade-off is between the aesthetic of your balcony/garden against
the last minutes of signal availability). 
Again, when the signal gets below threshold, even by a tiny 1 dB, the
link is completely corrupted. When the signal is 0.5 dB above threshold,
the link is error-free. There is no more soft failure in digital satellite 
transmissions!

6) The chips which implement the FEC decoding include as well
the demodulator (QPSK). They can handle user data rate of up to 60 Mbit/s.
They offer several inner FEC ratios: 1/2, 2/3,3/4,5/6,6/7,7/8,
automatically
detected.
They sell for less than 15$ thanks to the economy of scale of the consumer
market. Therefore there is no reason why, today, satellite links
cannot be designed to offer error free. Even in situations of jamming by
an intentional enemy, the satellite link when properly designed, exhibit
an on-off pattern exactly like fibers. 

7) Still some issues:
In my opinion, the real trouble comes when a satellite link (or a long
fiber) is
concatenated with an error prone network (such as a congested network with
paquet drop).
That's where you get the combined effect of long delay and unreliable
links.

If satellite gateways could check the BER of its incoming traffic (user TCP
checksum), it could deny corrupted packets to get into the long delay link.

There remain the case where the error-prone network is downstream the
satellite link.....May be a good rule of practice is to design the
inter-networking
so that the satellite link is always closest to the end point of use, if
that's ever
possible.....

Nghia PHAM
Digital System Engineer
EUTELSAT - European Telecommunications Satellite Organisation
70 rue Balard - PARIS, FRANCE
http:www.eutelsat.org
ph:33-1 53 98 47 21, fax: 33-1 53 98 47 98

---

From: "Adrian J. Hooke" <[email-masked]>
Date: Wed, 01 Apr 1998 11:11:47 -0800

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
--------------------------------------------