RE: Bit errors, is this really an issue ?

Heidi E Anderson <handerson@erac.com> Thu, 24 September 1998 16:55 UTC

X-Authentication-Warning: assateague.lerc.nasa.gov: listserv set sender to owner-tcpsat@lerc.nasa.gov using -f
Message-ID: <412BC5225625D211A1E30001FAD4D05B0876EC@EXCORP01>
From: Heidi E Anderson <handerson@erac.com>
Reply-To: "handerson@erac.com" <handerson@erac.com>
To: 'Jordi Nelissen - Alcatel Bell Research' <jordi.nelissen@alcatel.be>, tcpsat <tcpsat@lerc.nasa.gov>
Subject: RE: Bit errors, is this really an issue ?
Date: Thu, 24 Sep 1998 11:55:36 -0500
Organization: Enterprise Rent-A-Car
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-tcpsat@lerc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 5838
Lines: 111

Jordi,

While there is much information on BER and FEC's as they pertain to 
satellite links, I thought it might be helpful to explain the basic usage 
of BER in a satellite network.  BER is simply one measurand of satellite 
link performance and is typically the parameter chosen to represent this 
contractually.  Therefore, it is also usually provided as a user available 
statistic in "some form".

In designing a satellite link, the coding, power, receiver sensitivity, and 
expected link noise are all accounted for in configuring the channel for a 
certain availability.  The receiver sensitivity is a function of absolute 
power and gain of the signal over the noise floor referred to as 'energy 
per bit per noise energy normalized over 1 Hz' (Eb/No).  Of course, classic 
text book digital communication theory calculates error performance as a 
function of Eb/No and there are numerous sources on expected performance 
curves depending on modulation and coding.  At an earth station user level, 
the performance of the link is often represented as Eb/No or 'Signal 
Qualilty'.  This is useful as a referential measure but as an absolute 
measure, the calculation varies among satellite equipment providers.  Some 
calculate the actual BER of the data stream and then back out the Eb/No via 
calculation while others directly measure the energy in the signal to some 
given accuracy.

Either way, satellite channels are designed with a margin to overcome 
interference from a number of sources including rain to a certain level of 
required availability.  As the Eb/No decreases at the receiver, the BER 
will continue to increase until eventually accurate decoding is not 
possible.  Depending on the protocol, TCP or otherwise, this will typically 
result in slowed response time as the signal degrades.  Specifically in the 
case of rain fade, there are are rain rate models, such as Crane, that 
specify an experimentally derived expected rain rate and rain drop size for 
a particular geographic region.  These parameters are used to calculate an 
interference level to overcome for a region.  In addition, the rain affects 
the noise temperature of the sky as seen by the receiving station.  These 
two factors are considered in the total link budget to increase the 
probability of error-free transmission to a level as stated by the 
availability figure.  Even when transmission becomes impossible to decode, 
protocol can be configured maintaining the session link to resume 
transmission upon channel recovery.

Therefore, yes, BER can improve with the application of different coding 
and error-correction techniques.  However, the BER as it relates to 
availability, is part of a set of variables in the link budget equation 
that are adjusted according to need of the user and equipment provider. 
 For example, a better FEC may be implemented to reduce antenna size, 
reduce transmission power, or improve spectral efficiency by implementing 
higher-order modulation all while keeping the BER constant.  Of course, 
let's never forget the engineering vs. business game of design cost.

Due to the cost of satellite capacity and the desire to make end-user 
equipment more estecically pleasing to improve wide-spread usage, the above 
options are usually chosen and BER is maintained at 1 x 10^-6 or 1x 10^-7. 
 In a pure R&D environment, however, we can certainly consider BER as the 
variable keeping many other parameters constant and see where that leads. 
 Hopefully, this helps explain the current usage of these parameters in 
production digital satellite networks.

Heidi E. Anderson			Enterprise Rent-A-Car
WAN Engineering				600 Corporate Park Drive
314.512.2057				Clayton, MO 63105
314.512.4057 FAX
handerson@erac.com




On Thursday, September 24, 1998 7:56 AM, Jordi Nelissen - Alcatel Bell 
Research [SMTP:jordi.nelissen@alcatel.be] wrote:
> Dear tcpsat,
>
> I have a question with respect to the effect of BER on TCP performance
> on satellite links. From draft-ietf-tcpsat-stand-mech-06.txt, I read :
>
> 'Typical bit error rates (BER) for a satellite link today are on the
> order of 1 error per 10 million bits (1 x 10^-7) or less frequent.
> Advanced error control coding (e.g., Reed Solomon) can be added to
> existing satellite services and is currently being used by many
> services.  Satellite error performance approaching fiber will become
> more common as advanced error control coding is used in new systems.'
>
> As I understand this, in optimal operation, a modern satellite link can
> approach fiber BER, provided adequate FEC is used. Further on I also
> read :
>
> 'FEC should not be expected to fix all problems associated with noisy
> satellite links.  There are some situations where FEC cannot be expected
> to solve the noise problem (such as military jamming, deep space
> missions, noise caused by rain fade, etc.).'
>
> 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, ...)
>
> thanks, Jordi
> --
> _____________________________________________________________________
> Jordi Nelissen - jordi.nelissen@alcatel.be
>
> Alcatel Research - Network Architecture - Traffic Technology
> Francis Wellesplein 1, 2018 Antwerp, Belgium
> Phone: external: +32(0)3240 7192, alcanet: +6057192
> Fax:   external: +32(0)3240 9932, alcanet: +6059932
>
> Visit our webpage :
> http://www.rc.bel.alcatel.be/projects/networkarchitecture/traffic
> _____________________________________________________________________