| |
PA2AGA > TCPDIG 26.10.96 03:11l 136 Lines 5552 Bytes #-10843 (0) @ EU
BID : TCP_96_225A
Read: DG7DAH GUEST
Subj: TCP-Group Digest 96/225A
Path: DB0AAB<DB0MWS<DB0ZKA<DB0LX<DB0RBS<DB0SEL<DB0ZDF<DB0AIS<DB0NDK<DB0ACH<
DB0ACC<PI8DRS<PI8DAZ<PI8GCB<PI8MBQ<PI8VNW
Sent: 961025/1949Z @:PI8VNW.#ZH2.NLD.EU #:29506 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA19188 ; Fri, 25 Oct 96 19:36:00 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.62/7.1) with SMTP
id AA00006789 ; Fri, 25 Oct 96 21:30:37 MET
Received: from pa2aga-1 by pa2aga with SMTP
id AA00006777 ; Fri, 25 Oct 96 21:22:39 MET
Received: from pa2aga-1 by pa2aga-1 (NET/Mac 2.3.62/7.5.5) with SMTP
id AA00008244 ; Fri, 25 Oct 96 21:22:37 MET
Date: Fri, 25 Oct 96 11:11:10 MET
Message-Id: <tcp_96_225A>
From: pa2aga
To: tcp_broadcast@pa2aga-1
Subject: TCP-Group Digest 96/225A
X-BBS-Msg-Type: B
TCP-Group Digest Wed, 23 Oct 96 Volume 96 : Issue 225
Today's Topics:
2300 MHz band reallocated
wampes on FreeSCO (3 msgs)
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from ftp.UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Tue, 22 Oct 1996 17:48:37 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Subject: 2300 MHz band reallocated
Phase-5 is Mars-Probe!
We would really be pushing the envelope -- and TCP/IP on it :-)
Ah, now I understand. I would not run TCP/IP on an interplanetary probe.
I stand corrected -- which details at the system design
you consider bad ?
The modulation and coding (or lack thereof). Coherent PSK is hard to
make work well at low data rates, especially on fading signals and the
high doppler rate of a low earth orbit. At low data rates,
differentially coherent PSK (DPSK) or FSK would have been a better
choice. Yet the Microsat links are so strong that, ironically, a high
speed coherent PSK link probably would have worked better (gotten more
bits through per pass) than the present low speed PSK link.
I am at least partly to blame for the decision to use CPSK on
Microsat, as I heavily promoted it in the early 1980s for the Pacsat
project (that eventually became Microsat). But in my defense, I had
envisioned much higher data rates than 1200 bps.
The lack of FEC implies an inefficient use of downlink power,
especially when there is fading caused by spacecraft motion. Good FEC
with sufficient interleaving can work wonders on a fading
channel.
Coding would be particularly effective for the broadcast
protocol. Instead of taking repeat requests from the ground, the
satellite could compute "parity packets" from a Reed-Solomon code that
the ground stations use to fill in the missing packets without
requesting a fill.
Here's an example of how this might work. I'll pick some arbitrary
numbers just as an example; I do not claim that they're optimal
choices for a real satellite.
The satellite divides up its transmitted data stream into blocks of
256 x 32 = 8192 bytes. It then transmits the block as 32 256-byte data
frames, each with a mod 36 sequence number and a CRC.
After the data frames are sent, the satellite generates 4 256-byte
"parity frames", also with a sequence number and CRC. These parity
frames are generated by a shortened (36,32) Reed-Solomon code over
GF(256) (i.e., 8-bit symbols), with the data field of each RS codeword
taking one byte from each of the 32 data frames:
255 (36,32) RS codewords (downwards)
| | |
v v v
Data frame 0: D000 D001 ... D255 (across)
Data frame 1: D256 D257 ... D511
....
Parity frame 0: P000 P001 ... P255
Parity frame 1: P256 P257 ... P511
....
Now if the receiver gets all of the data frames 0-31 without any CRC
errors, it can just ignore the four parity frames 32-35 and wait for
frame 0 from the next block. But if one or more of the data frames
fail the CRC, they can be reconstructed from the parity frames using
an erasure- correcting RS decoder. An RS code can fill in as many
erased symbols in a codeword as there are parity symbols, so in this
case the receiver can fill in up to four missing data frames assuming
it gets all of the parity frames.
The beauty of this scheme is that the same four parity frames can
reconstruct *any* combination of up to four erased data frames, so
each ground station can use the same parity frames to fill in whatever
combination of data frames (up to 4 max) that it is missing, without
requesting any retransmissions. This is clearly a major benefit when
there are many ground stations listening, as to a beacon transmission.
As presented, each frame carries a CRC and is either received
correctly or not at all. A further refinement would add a code to each
frame capable of correcting some errors within each frame. A
convolutional code would be a good choice here, as that would buy some
gain against gaussian noise. Interleaving here would also buy some
fade resistance.
If the frame CRC were eliminated, then the RS code might be able to
salvage slightly errored frames that would otherwise be entirely
erased. In this case we'd probably want to add some more RS parity
frames using the bits saved from the frame CRC. Again, a careful
study would indicate the tradeoffs for a particular link.
I have published several FEC encoder/decoder routines on my web page,
To be continued in digest: tcp_96_225B
Read previous mail | Read next mail
| |
