In modern systems (i.e. Ka-band), forward error correction (FEC), such
as Reed-Soloman coding, is used to correct link errors including those
caused by rain fading. The nature of the code is that it has a rapid
"fall off" meaning that either the link is completely clean (BER
around 10E-12 or better) or no bits are getting through.
So, of course, the question is: what is the threshold where the link
dissapears in a rain fade. It is not possible to answer this question
in general since it depends on the parameters of the link coding
(FEC), data rate, transmit and receive antennas, transmitted power,
etc.
My understanding (which is rather rudimentary) is that link outages
are on the time scale of rain storms (or rain cells, as the link
engineers call them). As the rain cell moves into the beam, the
received power drops and (correctable) errors are injected into the
bit stream. Once the errors reach a certain density the link FEC
cannot correct them and the link is down until the rain cell moves out
of the beam area and the power increases.
So, to answer your question, I don't think you will find many
corrupted packets emerging from a link in rain fade.
However, these satellite systems are designed to minimize rain fade
(while also minimizing transmitted power which drives terminal cost).
The NASA ACTS program has supported considerable study of propagation
characteristics at Ka band and system developers are using this data
to engineer their links.
Hope this helps,
--aaron
______________________________ Reply Separator _________________________________
Subject: Bit errors, is this really an issue ?
Author: [email protected] at mime
Date: 9/24/98 5:55 AM
Let us take the most common situation, i.e. rain fade. Can someone
explain to me its quantitative impact on BER. Is the satellite link
completely out of order when it rains or can we still find rescue in
methods like ARQ or some TCP which is able to distinguish corruption
from congestion ? Is there information available on the noise
characteristics on modern satellite links ? (BER, distribution of bit
errors, ...)
RFC-822-headers:
Received: from CONVERSION-DAEMON by mail.hac.com (PMDF V5.1-12 #D3246)
id <[email protected]>; Thu, 24 Sep 1998 06:11:28 -0700 (PDT)
Received: from PROCESS-DAEMON by mail.hac.com (PMDF V5.1-12 #D3246)
id <[email protected]>; Thu, 24 Sep 1998 06:11:27 -0700 (PDT)
Received: from fw-es05.hac.com by mail.hac.com (PMDF V5.1-12 #D3246)
with ESMTP id <[email protected]>; Thu,
24 Sep 1998 06:11:26 -0700 (PDT)
Received: from assateague.lerc.nasa.gov ([139.88.112.23])
by fw-es05.hac.com (8.9.0/8.9.0) with ESMTP id GAA24876; Thu,
24 Sep 1998 06:11:10 -0700 (PDT)
Received: (listserv@localhost) by assateague.lerc.nasa.gov
(NASA LeRC 8.7.4.1/2.01-main) id IAA10570; Thu,
24 Sep 1998 08:57:13 -0400 (EDT)
Received: from btmplq.god.bel.alcatel.be (fw01.lerc.nasa.gov [139.88.145.14])
by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main)
id IAA10559; Thu, 24 Sep 1998 08:57:10 -0400 (EDT)
Received: from rc.bel.alcatel.be (btmq9s.rc.bel.alcatel.be [138.203.65.182])
by btmplq.god.bel.alcatel.be (8.9.1a/8.9.1) with SMTP id OAA19396 for
<[email protected]>; Thu, 24 Sep 1998 14:55:02 +0200 (MET DST)
Received: from alcatel.be by rc.bel.alcatel.be id OAA08132; Thu,
24 Sep 1998 14:59:21 +0200
Date: Thu, 24 Sep 1998 14:55:58 +0200
From: Jordi Nelissen - Alcatel Bell Research <[email protected]>
Subject: Bit errors, is this really an issue ?
Sender: [email protected]
Message-id: <[email protected]>
Organization: http://www.alcatel.com
MIME-version: 1.0
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
Content-transfer-encoding: 7BIT
Precedence: bulk
X-Authentication-warning: assateague.lerc.nasa.gov: listserv set sender to
[email protected] using -f
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:47 EST