DRAFT
Appendix C
METHODOLOGY FOR COMPUTING AND PARTITIONING
AVAILABILITY
AND CONTINUITY OF SERVICE
(NORMATIVE)
©RTCA, Inc. (does not apply to draft material)
DRAFT
This page intentionally left blank.
©RTCA, Inc. (does not apply to draft material)
DRAFT
Appendix C TABLE OF CONTENTS
C.1 INTRODUCTION ................................................................................................................................................1
C.2 KEY ANALYSIS EQUATIONS .............................................................................................................................3
C.2.1 Availability Analysis Equations .............................................................................................................3
C.2.1.1
C.2.1.2
C.2.1.3
C.2.1.4
C.2.1.5
C.2.1.6
C.2.1.7
C.2.1.8
C.2.2
Outage Duration ................................................................................................................................................ 3
Outage Rate/Mean Time Between Outage ........................................................................................................ 3
Outage Restoration Rate/Mean Restoration Time ............................................................................................. 4
Availability Ratio .............................................................................................................................................. 5
Geographically Dependent Availability Ratio ................................................................................................... 5
Availability Calculation Using Independent Elements ...................................................................................... 7
Availability Effects of Traffic Loading ............................................................................................................. 8
Effect of Redundancy on Availability Calculations ........................................................................................ 10
Continuity of Service Analysis Equations ........................................................................................... 11
C.2.2.1
C.2.2.2
C.2.2.3
C.2.2.4
Rate of Continuity of Service Events .............................................................................................................. 12
Geographically Dependent Continuity of Service Event Rate ......................................................................... 13
Estimating the Rate from the Probability ........................................................................................................ 13
Estimating the Continuity of Service .............................................................................................................. 14
C.3 AMS(R)S AVAILABILITY MODEL .................................................................................................................. 15
C.3.1 Fault-Free Rare Events ....................................................................................................................... 16
C.3.1.1
C.3.1.2
C.3.1.3
C.3.1.4
C.3.2
System Component Failure Events ...................................................................................................... 19
C.3.2.1
C.3.2.2
C.3.2.3
C.3.2.4
C.3.3
RF Link Events ............................................................................................................................................... 16
Scintillation Events ......................................................................................................................................... 18
Interference Events.......................................................................................................................................... 18
Capacity Overload Events ............................................................................................................................... 19
GES Failure Events ......................................................................................................................................... 21
Satellite Failure Events.................................................................................................................................... 22
NCS Failure Events ......................................................................................................................................... 22
AES Failure Events ......................................................................................................................................... 23
Multi-User vs. Single User Availability ............................................................................................... 23
C.3.3.1
C.3.3.2
Multi-User Availability ................................................................................................................................... 23
Single-User Availability .................................................................................................................................. 24
C.4 AMS(R)S AVAILABILITY EXAMPLE .............................................................................................................. 27
C.4.1 Example System Parameters ................................................................................................................ 27
C.4.2 Fault-Free Rare Events ....................................................................................................................... 27
C.4.2.1
C.4.2.2
C.4.2.3
C.4.2.4
C.4.2.5
C.4.3
RF Link Events ............................................................................................................................................... 27
Scintillation ..................................................................................................................................................... 28
Interference ..................................................................................................................................................... 30
Capacity Overload ........................................................................................................................................... 30
Fault Free Rare Event Summary ..................................................................................................................... 33
System Component Failures ................................................................................................................ 33
C.4.3.1
C.4.3.2
C.4.3.3
C.4.3.4
C.4.3.5
GES Failure Events ......................................................................................................................................... 34
Satellite Failure Events.................................................................................................................................... 34
NCS Failure Events ......................................................................................................................................... 35
AES ................................................................................................................................................................. 36
System Element Failures ................................................................................................................................. 36
C.4.4 System Availability Estimate ................................................................................................................ 36
C.5 AMS(R)S CONTINUITY OF SERVICE MODEL.................................................................................................. 37
C.5.1 Fault-Free Rare Events ....................................................................................................................... 37
C.5.1.1
C.5.1.2
C.5.1.3
C.5.1.4
RF Events ........................................................................................................................................................ 37
Scintillation Events ......................................................................................................................................... 38
Interference Events.......................................................................................................................................... 38
Capacity Overload Events ............................................................................................................................... 38
C.5.2 System Component Failures ................................................................................................................ 39
C.5.3 Multi-User vs. Single User Continuity of Service ................................................................................ 39
C.6 AMS(R)S CONTINUITY OF SERVICE EXAMPLE .............................................................................................. 41
C.6.1 Fault-Free Rare Events ....................................................................................................................... 41
C.6.1.1
C.6.1.2
C.6.1.3
C.6.1.4
C.6.1.5
C.6.2
RF Link ........................................................................................................................................................... 41
Scintillation ..................................................................................................................................................... 41
Interference ..................................................................................................................................................... 43
Capacity Overload ........................................................................................................................................... 43
Fault Free Rare Event Summary ..................................................................................................................... 45
System Component Failures ................................................................................................................ 46
C.6.2.1
GES ................................................................................................................................................................. 46
©RTCA, Inc. (does not apply to draft material)
C.6.3
DRAFT
C.6.2.2
C.6.2.3
C.6.2.4
C.6.2.5
Satellites .......................................................................................................................................................... 46
NCS ................................................................................................................................................................. 47
AES ................................................................................................................................................................. 47
System Element Failures ................................................................................................................................. 47
System Availability Estimate ................................................................................................................ 47
Appendix C TABLE OF FIGURES
Figure C-1: Timing of Outage Duration Events ............................................................................. 3
Figure C-2: Example of Non-Delivery that Does Not Result in Outage ........................................ 4
Figure C-3: "Availability Tree" Methodology .............................................................................. 15
Figure C-4: Examples of Fading Rate Effects on Signal Interruptions ....................................... 17
Figure C-5: Examples of External and Internal Networking Between GES Sites ....................... 21
Figure C-6: Example Probability of Outage Given a Known Satellite Failure ............................ 35
Appedix C TABLE OF TABLES
Table C-1: Declared and Derived Parameters for Traffic Load Analysis ..................................... 9
Table C-2: Parameters for Example Computation of Traffic Overload Effect ............................ 32
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-1
DRAFT
C.1
Introduction
Availability and Continuity of Service are two of the four key parameters defining the
Installed Communications Performance (ICP) of the AMS(R)S subnetwork. The MASPS
defines minimum performance levels for Multi-User and Single-User Availability and
Multi-User and Single-User Continuity of Service.
The purpose of this appendix is to provide a standard methodology for partitioning the
system level Availability and Continuity of Service performance to major subsystems.
This methodology is more complex than the typical computation of system availability
due to two factors:
1. AMS(R)S subnetworks are expected to provide service over broad regional or global
coverage volumes.
Conventional calculation of availability will produce
inappropriately low estimates of the system availability, due to the wide-ranging
coverage of the AMS(R)S systems. That is, under conventional estimates, an outage
in any limited region is treated as an outage of the entire coverage volume.
2. The specifications of certain AMS(R)S subnetwork performance parameters, such as
RF performance and traffic capacity, are given in statistical terms. This introduces
the possibility that users may experience service interruptions or outages due to
normal statistical fluctuations in the subnetwork performance, even when all
components of the subnetwork are operating within their specifications. Such faultfree rare events, which must be considered in the AMS(R)S performance, are not
included in the usual computation of availability.
This appendix is organized in several sections.
Section C.2 summarizes definitions of key parameters used in the computations and
provides the important equations used in the methodology. The derivation and rationale
for these equations is too extensive for the scope of this appendix. Interested readers are
urged to consult [1] for additional details.
Section C.3 builds the availability models for single and multiple user availability,
considering both fault-free rare events and normal subsystem failures.
Section C.4 works out an extended example of the availability computation, assuming the
same hypothetical AMS(R)S system used in the extended example in Appendix B.
Section C.5 repeats the work of Section C.3 for the Continuity of Service Model.
Finally, Section C.6 extends the example to Continuity of Service computations.
This appendix utilizes the term Network Control System (NCS) to refer to the hardware, software, and RF
control links, if any, associated with Network Control Coordination Function that do not reside in any
other element of the AMS(R)S system. That is, the NCS is treated as an entity separate from the AES,
GES, and satellites. In addition to the NCS, it is possible that a satellite system may use elements of the
GES and/or AES and/or satellites to implement the NCCF. The availability effects of such elements are
included in the GES, AES and satellite effects.
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-2
DRAFT
This page intentionally left blank.
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-3
DRAFT
C.2
Key Analysis Equations
This section defines certain key parameters and equations that are required in the proforma analyses described in Section C.3 and Section C.6.
C.2.1
C.2.1.1
Availability Analysis Equations
Outage Duration
This MASPS defines an outage as an interruption of service having a duration that
exceeds 10 times the 95th percentile transfer delay. For the purpose of the availability
computation, the outage is assumed to have started at the time when service was
requested. The outage ends when any data block is delivered to the destination system.
This block may be an administrative block transmitted within the subnetwork. The
outage duration timing is illustrated in Figure C-1. The outage duration is denoted by the
variable TOUT .
Data block presented
for transmission
Outage Declared
Data block
presented
Data block delivered
Outage known over
No data of any kind
delivered in this direction
Outage Duration (Tout)k
tmean
t95
Figure C-1: Timing of Outage Duration Events
The failure to deliver an individual block of information does not by itself constitute an
outage. It is possible that a single block is not delivered, and yet other blocks, submitted
later, are delivered. In this case, there is no outage. This situation is clarified in Figure
C-2.
C.2.1.2
Outage Rate/Mean Time Between Outage
Computation of several of the availability factors require an estimate of the average
outage rate, OUT , or, equivalently, the mean time between outages, TBO . The average
outage rate is the average number of outages occurring in a unit of time. Once the system
is operational, it is possible to estimate OUT by counting the number of outages N OUT ,
in an observation time, TOBS . The variables OUT , TBO , N OUT and TOBS are related as
shown in [C-1].
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-4
DRAFT
Data block, D, presented
for transmission
Subsequent block
presented
for transmission
No Outage Declared, but
block D has been lost
Subsequent block
delivered
t95
tmean
Time
Figure C-2: Example of Non-Delivery that Does Not Result in Outage
OUT
TBO
N OUT
1
TOBS
TBO
T
1
OBS
N OUT OUT
[C-1]
An implicit assumption in the analysis that follows is that the time between two
consecutive outages is an independent random variable that is exponentially distributed
with mean TBO .
C.2.1.3
Outage Restoration Rate/Mean Restoration Time
Computation of several of the availability factors also requires an estimate of the mean
restoration time, TR . Associated with TR is the outage restoration rate, OUT . The
"excess outage duration", TR , as a random variable whose value is independent between
outages, the relationship between the number of outages N OUT , the duration of the
individual outages, {(TOUT )k : k 1, 2, ... N OUT } , TR and is given by
tR TOUT TOD
TR E [TR ] E [TOUT TOD ]
OUT
1
1
N OUT
N OUT
(T
OUT ) k
TOD
k 1
[C-2]
OUT
1
TR
Equation [C-2] introduces a new constant TOD , which is the service outage time
threshold declared in the system-specific material. This value is kept as a variable to
permit flexibility in matching system performance to the desired operational RCP, subject
to the MASPS constraint: TOD 10T95 .
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-5
DRAFT
In most of the cases where computations depend on TR , it is only the average value that
is important, and no assumptions about the distribution of the outages times need be
made. When it is necessary to assume a distribution, assume that the outage restoration
times are described by an exponential density function given by
e OUT tOUT
p(tOUT ) OUT
0
C.2.1.4
Availability Ratio
tOUT 0
elsewhere
[C-3]
RTCA DO-215A, Change 1, and RTCA DO-264 follow traditional practice and define
system availability in terms of a computed value called the Availability Ratio. The
Availability Ratio is defined over an observation interval, TOBS , as:
Ao
where
(T
TOBS
N OUT
(T
k 1
)
OUT k
TOBS
1
N OUT TOUT
TOBS
[C-4]
) is the total interval of time within the observation interval when the
OUT k
system is not available for use. In this context, "available for use" means that the system
is capable of providing data communications with the specified level of integrity while
meeting the maximum transfer delay permitted by the operational application. The
approach given in [C-4], which is widely recognized in the engineering community,
describes the availability of a specific system to a specific user at a specific point or over
a limited region in space.
C.2.1.5
Geographically Dependent Availability Ratio
This section further develops [C-4] to account for systems that cover large regions of
airspace over a significant portion of the Earth's surface. Such systems may be subject to
partial outages that affect users in specific areas at specific times while providing
uninterrupted service to users in other coverage volumes. Such transient outages must be
carefully factored in to an expression of overall subnetwork availability.
The question of determining the outage durations must now be addressed. It is obvious
that a different set of outages Tkj will be observed at each of j points in space. If the
points are close together, the outages are likely to be the same. Outage durations
measured at widely spaced points, however, are likely to be significantly different.
This concept can be expressed mathematically by assigning a three-dimensional vector,
x , to each element of a set of observation locations, which we call
x j : j 1, 2, 3, ... . Thus, if availability is computed as given in [C-4], a different
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-6
DRAFT
answer can be expected for each observation location. This means that the availability is
a function of both the observation time and the observation locations.
# outages in TOBS at location x j
A(x j ; TOBS ) 1
T
OUT
k 1
(x j )
k
TOBS
[C-5]
Now let the set of locations, , be the coverage volume declared in the system-specific
material.
The average availability over the entire coverage volume is:
A(TOBS ) A(x; TOBS ) px (x)dx
[C-6]
where px (x) is the probability density function of users over the coverage volume, .
Equation [C-6] is an explicit function of the observation location, x . Equation [C-6] can
be viewed as the availability seen by an average user of the subnetwork infrastructure.
Substituting [C-5] into [C-6]:
(TOUT ( x )) k
A(TOBS ) 1 k
px ( x ) d x
TOBS
1 px ( x )dx
1
(T
OUT
1
TOBS
(T
OUT
k
( x )) k
k
TOBS
px ( x ) d x
[C-7]
( x )) k px ( x )dx
In simple language, Equation [C-7] says that the average availability, A(TOBS ) , is
affected not only by the total outage duration at each location in coverage, but also by the
probability that an aircraft is at that location. This means that outages in high traffic
areas, such as New York, Los Angeles, Chicago, and Dallas-Ft. Worth, have a greater
impact on overall average system availability than outages in remote areas, such as
Kodiak, AK. Thus, given an approximate distribution of aircraft, [C-7] provides a
framework for both bottom up computation of system availability by accumulating the
outage times at many locations and top down partitioning into the availability
requirements within specific regions. In the partitioning process, the specific regions can
be identified as subsets of the coverage volume, .
In real world applications, a continuous probability density function of aircraft as a
function of position, px ( x ) will not be available. Instead, it is expected that the density
function will be approximated as a constant over regions of various size. For example, a
constant density might be assumed over the Mid-Atlantic states, or over the North
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-7
DRAFT
Atlantic track system. When this "area constant" density assumption is made, the
continuous integral shown in [C-7] will become a discrete sum over the different areas.
Denote the various regions as m , and the area of those regions as S ( m ) , and the
average probability density over that region as p m , then rewrite [C-7] as the following
discrete sum:
1
1
TOBS
1
(T
OUT
1
TOBS
k
1
( x )) k px ( x )dx 1
TOBS
P (T
m
m
OUT
S (
m
m
) pm (TOUT ( m )) k
k
[C-8]
( m )) k
k
where Pm is the percentage of all aircraft that are in the region m .
In [C-7] and [C-8], the probability density function is not shown as a function of time.
On a time scale ranging from hours to weeks, the probability density functions are
certainly a function of time: air traffic in any region ebbs and flows with flight
schedules. But [C-7] and [C-8] anticipate an availability observation time of at least
several months, and the MASPS defines an observation time of 365 days. Over these
observation times, the diurnal changes in aircraft density average out, leaving a constant
average aircraft density for each region or position. Therefore, the time-dependence of
the density functions is not considered in this formulation.
Note:
C.2.1.6
Inclusion of time dependence can be added, if necessary, by making the
probability density functions depend on two variables – position and time – and
integrating over the observation time.
Availability Calculation Using Independent Elements
When the subsystem consists of independent serial elements, the overall availability of a
complex system is equal to the product of the availability ratios for the individual
elements; that is:
AoSYS Ao1 Ao 2 Ao 3
AoN
[C-9]
where N is the number of elements.
The various terms in [C-9] could, in turn, be computed by applying [C-7] to each domain
or source of unavailability. This suggests that perhaps [C-7] could be applied directly,
and the contributions of the various domains could be partitioned by means of a simple
summation, rather than the product shown in[C-9]. It is a simple matter to show that such
a summation-based partitioning using [C-7] forms a lower bound for the multiplicative
partitioning of [C-9], and that this bound is quite tight when the unavailability in each
1
domain is significantly less that
. That is, the summation methodology and the
N
product methodology give the same answer under the condition:
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-8
N
(1
k
k
k
DRAFT
1
k)
whenever 0 k
k
(TOUT )k
TOBS
1
N
1
[C-10]
In some cases, it is easier to compute the probability that a service outage occurs directly,
rather than by summing the outages. In these cases, [C-9] is a more appropriate method
for computing the availability effects. In other cases, it is simpler to estimate or measure
the outage durations, and [C-7] is more appropriate. From the viewpoint of this
methodology, either method is acceptable. Outages that have significant spatial as well as
temporal variation should use [C-7].
C.2.1.7
Availability Effects of Traffic Loading
The availability of a communications system with limited resources is typically computed
by means of either the Erlang-B or Erlang-C formulas. The Erlang-B formula assumes
that a request for service must either be served immediately or dropped immediately.
There is no queueing for service in the Erlang-B model. The Erlang-C model assumes
that a request for service is either served immediately or placed at the end of a (possibly
infinite) queue for service on a "first-in-first-out" basis. Depending on the specific
AMS(R)S architecture, either or both, or some intermediate form of these formulas might
be appropriate.
Regardless of AMS(R)S architecture, use of the Erlang-B formula provides a pessimistic
estimate of availability. Therefore, it is permissible to use an Erlang-B analysis to
estimate the availability effects due to traffic loading. The Erlang-B formula, B(c,a), is
given by:
ac
B ( c, a ) c c ! n
a
n 0 n !
[C-11]
where the parameters are given in Table C-1.
For some architectures, especially those that provide queueing or buffering of the
AMS(R)S messages, the Erlang-B result may be unacceptably pessimistic. A more
accurate, but more computationally intense, model requires identification of the
parameters shown in Table C-1.
The parameters used in the computations shall be consistent with the values declared in
Table 2-1 of the MASPS, the values declared in Appendix B, and with the overall
AMS(R)S traffic declared in the Traffic Model required by MASPS Section 2.2.5.1.1.
For the purposes of this computation, distinctions between AMS(R)S priority levels are
ignored, and it is assumed that AMS(R)S demand of any priority experiences at most an
insignificant delay due to the implementation of the priority, precedence, and preemption
mechanisms required by the MASPS.
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-9
DRAFT
Table C-1: Declared and Derived Parameters for Traffic Load Analysis
average AMS(R)S service
demand rate
blocks/second
average AMS(R)S block
length defined at Pt B or Pt C
user bits/block
nominal user data rate through
the AMS(R)S system viewed
at Pt. B or Pt. C
user bits/second
number of servers (channels)
available for AMS(R)S
unitless
size of queue or buffering
supporting AMS(R)S service
blocks
outage definition time
seconds
RD / N BLOCKS
average block service rate
blocks/sec
a N BLOCK / RD
average traffic intensity
Erlangs
a / c c
N BLOCK ) /(cRD )
average traffic intensity per
server
Erlangs per
server
K c NQ
maximum system user
population
blocks
N BLOCK
RD
c
NQ
TOD
Using the values declared in Table C-1, the unavailability due to random traffic
overloading is computed using [C-12], [C-13], and [C-14]. The values used in the
analysis may differ for the computation of single user and multi-user effects.
BK [c, a ] Pr{new data block is denied service}
aK
K c
c 1c ! cn
a
ac
k 0 n ! c !
[C-12]
CK [c, a ] Pr{new block is placed in queue}
ac
c!
1 c 1 a n a c
K c 1
k 0 n ! c !
1
[C-13]
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-10
DRAFT
U LOAD (TOD ) Pr{system service time is greater than TOD }
K c 1
m
C K [ c, a ] K c
cTOD
K c m ( a TOD )
(1
e
(1
)
BK [c, a ]
m!
1 K c 1
m 0
[C-14]
ALOAD 1 U LOAD
Note:
Users are cautioned that BK (c, a ) and C K ( c, a ) should not be confused with the
standard B(c,a) (Erlang-B) and C(c,a) (Erlang-C) notation, and must be
computed by [C-12] and [C-13], respectively.
Users desiring additional detail are referred to Reference 1.
C.2.1.8
Effect of Redundancy on Availability Calculations
An effective design option for increasing both availability and continuity of service is the
inclusion of redundant elements, such as "satellite", "AES", "antenna", "GES". The
effect of such redundant elements on availability depends on the service outage rate, the
number of redundant paths provided, the observation time, the mission time, and the
service restoration rate. The restoration rate is particularly important in the availability
computation, but plays little or no role in the continuity of service analysis.
C.2.1.8.1
K-redundancy with common repair
In this model, there are K identical elements, of which only one is needed to maintain
AMS(R)S service. Failed units are repaired through a common repair facility with a
fixed limited capacity. The average failure rate is OUT , as defined in Section C.2.1.2,
and the average restoration rate is OUT , as defined in Section C.2.1.3. The model
assumes that the service times and restoration times are exponentially distributed. The
availability of service through the K elements with common repair is given by [C-15].
pK
Pr{ All K units are simultaneously under repair}
K
AKC
K ! OUT B ( K , OUT
OUT
OUT
1 pK
[C-15]
This model is appropriate for use with multiple AES installations on the same aircraft. In
general, this is not the appropriate model for failures of redundant GES stations serving
the same coverage volume unless the same maintenance resources serve both of the
affected stations.
C.2.1.8.2
K-redundancy with independent repair
In this model there are again K identical elements, but the repair processes are
independent of each other. In this case, the availability is
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-11
DRAFT
AKI 1 (1 Ao ) K
1 OUT
OUT
K
[C-16]
This model may be appropriate for stations that provide redundant service, but are served
by independent maintenance crews. It is not appropriate for installations with multiple
AES stations.
C.2.1.8.3
K-redundancy without repair
In this model, there are K identical independent units which are allowed to fail without
replacement.
AKN 1 1 e OUT TOBS
K
1 ( OUT TOBS ) K for OUT TOBS
C.2.2
[C-17]
1.
Continuity of Service Analysis Equations
Continuity of service is frequently thought about as merely a "short term availability".
While simple enough for a very high-level discussion, this view is flawed and does not
always give the correct interpretation to more detailed questions.
Availability is an instantaneous probability that AMS(R)S is usable in a given location at
any time. There is no "time" associated with the experiment of sampling the availability:
the service can be used or it cannot. An estimate of the true availability by is obtained
from the availability ratio. [C-4] indicates that the availability ratio is computed by
recording the total duration of all outages over some observation interval. Nevertheless,
the appearance of time into the availability equations is generally for the purpose of
estimation only.
On the other hand, continuity of service is directly associated with a specific time
interval, known as the continuity of service interval, TCOS , which is declared in Table 2-1
of the MASPS. Continuity of service is defined as the conditional probability that a
service will continue to be available over that period of time, given that it was available
at the start of that time. An continuity of service event is any disruption or disruptions of
service over the specific continuity of service interval, such that the interruption lasts for
at least a time interval of TSI . Continuity of service may also be estimated by measuring
the number and duration of outages over some observation interval and extrapolating the
curve backwards to interruptions of duration TSI .
Continuity, therefore, is not just the short-term availability, but depends on the number
and frequency of service interruptions.
For example, consider an AMS(R)S system that offers service over the North Atlantic air
routes. Assume that over a particular year of operation, there were 12 outages due to all
causes measured in this region, for a total of 8.76 hours. Then by application of [C-4],
the availability ratio for the system is:
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-12
DRAFT
8.76 hours
8760 hours
1 1 103
Ao 1
[C-18]
0.999000
Now consider a second AMS(R)S system offering the same service, and assume that it
experienced 240 outages of average 2 minutes each, for a total of 480 minutes. Again
applying [C-4]:
8 hours
8760 hours
1 9.13 104
Ao 1
[C-19]
0.999087
So the second system, having less total outage time, has better availability.
But the average rate of outages is much higher for the second system.
12 outages
0.0014 / hour
8760 hours
240 outages
0.0274 / hour
8760 hours
OUT 1
OUT 2
[C-20]
Ignoring, for the moment, the distinction that the between service outage time, TOD and
service interruption time TSI , the entire AMS(R)S subnetwork can be viewed as a single
server and [C-17] applied with K 1 and TCOS 15 min = 0.25 hour :
COS 1 1 e OUT TCOS
1
1 ( OUT TCOS )
COS1 1 0.0014TCOS 0.99965 for TCOS 0.25 hour
[C-21]
COS2 1 0.0274TCOS 0.99315 for TCOS 0.25 hour
So the second system, with more frequent, but shorter, outages has slightly better
availability but significantly worse continuity of service.
Computing the continuity of service requires an estimate of the appropriate rate, COS , of
Continuity of Service events, where the events are defined defined in Section 2.2.5.4.1 of
MASPS. In a manner analogous to the Availability Ratio defined in Section C.2.1.4. This
rate can be estimated by counting these events over an observation interval:
C.2.2.1
Rate of Continuity of Service Events
In a direct analogy to Section C.2.1.2, the average rate of Continuity of Service events
can be estimated by observing the number of events, N COS , over an observation time,
TOBS . The rate is estimated in the same manner as in [C-1]:
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-13
DRAFT
NCOS
TOBS
COS
C.2.2.2
[C-22]
Geographically Dependent Continuity of Service Event Rate
Just as the number and duration of outages varies with aircraft location as discussed in
Section C.2.1.5, the number of continuity of service events may also vary. Thus, the
geographically averaged rate of Continuity of Service events, COS , is given by
COS
1
TOBS
N
COS ( x ) px ( x ) dx
,
[C-23]
where N COS ( x ) is the number of continuity of service events occurring at the location x ,
and the other terms are as defined in the discussions accompanying [C-7]. Simplification
of [C-23] by a finite sum of area-wise constant probability functions, as described in
[C-8] is appropriate. The corresponding simplification is:
COS
C.2.2.3
1
TOBS
1
TOBS
N
COS k
N
p (x)dx
x
k
COS k
[C-24]
p( k )
k
Estimating the Rate from the Probability
For some systems, it may be easier to estimate the probability of a Continuity of Service
event than to count the number of occurances. One example of this situation will be
given in Section C.6.1 during the discussion of RF Link Events. In such situations, the
analysis should assume that time between Continuity of Service events is exponentially
distributed. Under this assumption, the probability of a Continuity of Service Event, that
is, the probability that service interruption duration, t , exceeds TSI can be used to
estimate the rate of Continuity of Service events, COS :
Pr{t TSI }
COS TCOS pCOS
COS
pCOS
,
[C-25]
pCOS
TCOS
The approximations very good when the product COS TSI is much less than unity, that is,
when pCOS is small. Because pCOS 1 COS and because (since) MASPS 2.2.5.4.3
requires COS 0.999 , the approximation of [C-25] is appropriate for use in developing
the continuity of service performance.
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-14
DRAFT
C.2.2.4
Estimating the Continuity of Service
The Continuity of Service for any individual class of events can be estimated by:
3
2
Ck 1
,k TCOS
,k TCOS
,k TCOS ...
,k TCOS
M
2
3
M
[C-26]
where m is the subset of the total coverage volume, , that has visibility to m satellites,
M is the maximum number of satellites visible to any single user, and ,k is the average
rate of Continuity of Service events due to cause k occurring in sub-region, . The
number of terms in [C-26] can be minimized by combining all regions with more than
two visible satellites into the m=2 term.
As was the case in availability, the continuity of service can be estimated by a product
methodology analogous to [C-9].
COS CFFRE CSCF
CFFRE CRF CSCIN CCAP CINT
[C-27]
CSCF CGES CSAT CNCS C AES
where the enumerated subscripts correspond to the various sources of Continuity of
Service Events.
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-15
DRAFT
C.3
AMS(R)S Availability Model
This section will discuss the availability model applied to AMS(R)S communications.
Figure C-3 illustrates an "Availability Tree" method similar to that used in the
development of the Required Navigation Performance concept. Contributions to
unavailability are partitioned into mutually independent classes. The first class consists
of communications outages due to statistically unlikely events. These "fault free rare
occurrences" are not associated with any system failure mode, but with the statistical
methodologies used in assessing RF performance, traffic loading, and interference
effects. The second class, which corresponds to the classical reliability-based definition
of availability, consists of outages caused by failures of the various system components.
Point B-to-Point C
Communications
Unavailable
for >TOD seconds
OR
RF
Link
Events
Fault-free
Rare
Event
System
Component
Failure
OR
OR
Capacity
Overload
Events
Scintillation
Events
GES
Failure
Events
Interference
Events
Others...
Satellite
Failure
Events
AES
Failure
Events
NCS
Failure
Events
Others...
Figure C-3: "Availability Tree" Methodology
The structure of Figure C-3 suggests that the "product" and "sum" methodologies can be
applied at several points during the overall availability analysis. If the "product"
methodology is used throughout, then:
AAMS ( R ) S AFFRE ASCF
AFFRE ARF ASCIN AINT ACAP
[C-28]
ASCF AGES AAES ANCS ASAT
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-16
DRAFT
where the subscript acronyms are obvious by reference to Figure C-3.
C.3.1
Fault-Free Rare Events
The link budget methodology of Appendix B and the integrity computation methodology
of Appendix D permit the system design to allow for events that have a very low
probability. These events are not precluded by elements of the system design, and will
occasionally occur even when the system is operating within its specifications.
For example, the Appendix B permits a RF link System Performance Level (see Item 43
of Table B-1 in Appendix B) of . This means that at any observation time there is a
probability of 1 that the RF link will not satisfy the link budget. Assume that the
performance is observed by sampling the RF link, and call each sample an event. Then
some fraction, 1 , of all events will not satisfy the link budget. Of these events, some
different fraction, , will have sufficient duration to cause outages, as defined above.
Thus, even when the link is functioning as designed, there is a probability of
that an outage will occur due to an RF event. This probability must be included in the
availability computation.
Such events, which occur with low probability even when the subnetwork is operating
within its design parameters, are called Fault-Free Rare Events. The major sources of
such events are various anomalies in the RF path and statistical variations in the loading
of the subnetwork.
At a minimum, the availability impact of the factors discussed in the following
subparagraphs should be included in the overall availability analysis. Additional FaultFree Rare Events specific to the subnetwork architecture should be included as
appropriate.
C.3.1.1
RF Link Events
An example of a fault-free rare event involving the RF link was given in the previous
subsection. Note that the RF link System Performance, , of Appendix B, is not
necessarily a direct indicator of the RF Link Availability. As noted in Appendix B, the
value of does not take into account the temporal characteristics of the random
variations of the link.
For example, a value of 0.99 means that the RF Link meets link budget 99% of the
time. Such performance could result in many short "dropouts" that persist for a small
percentage of the permissible transfer delay.1 Thus, an RF System Performance Level of
0.99 may have negligible effect on availability. In this case,
(TOUT ( x )) k may
RF Link
Events
be near zero, and the availability ratio may be near unity.
1
Depending on the system architecture and satellite protocols, it is possible that such dropouts will result in
retransmission of the information. While retransmission may cause a slight increase in transfer delay, there is no
service outage if the delay does not exceed the time defined in the MASPS.
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-17
DRAFT
An example of this type of effect is shown in Figure C-4. The first sub-figure illustrates
the amplitude history of a Rician channel with relatively high fading rate. The high
fading rate results in many short-duration excursions below the threshold established by
the link budgets. These excursions may cause the data to be corrupted to the point that a
retransmission is required, but it is very likely that the fade condition will not exist during
the retransmission interval. In the third subfigure, the same carrier-multipath ratio yields
multiple lost signal intervals of a significant length that could cause outages. Thus,
although the two systems are designed with the same RF link performance, the actual
effects on availability are significantly different. In terms of the parameters under
discussion, in the first subfigure is near zero.
Nothing in the examples of Figure C-4 is intended to imply significance about the
fading parameters or duration of the low signal intervals to a specific SATCOM
system. This figure is intended solely for the purpose of illustrating the point that
both the fading level and the fading rate need to be considered when estimating
the total duration of RF link outages.
Signal (dB)
Note:
5
0
-5
Outages
2
1
Signal (dB)
0
5
0
-5
Outages
2
1
0
Time
Figure C-4: Examples of Fading Rate Effects on Signal Interruptions
The system-specific material shall discuss the effects of RF Link Performance on system
outages, and shall use the result of that discussion in the computation of overall
availability. It is expected that outages due to RF link performance may vary
significantly over the coverage area. Therefore, availability should be computed in
accordance with [C-7].
The value of is very dependent on the terms in the random losses portion of the link
budget, the satellite orbital parameters, and the assumed aircraft motion. This analysis
should be based on aircraft in normal straight and level flight at minimum cruise speed.
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-18
DRAFT
The availability component due to an RF-link fault-free rare event is thus given by:
ARF 1
C.3.1.2
Scintillation Events
[C-29]
Ionospheric scintillation is a phenomenon involving the effects of the sun and the earth's
magnetic field, which produces random variations in electromagnetic waves traversing
the ionosphere. The phenomenon is manifested in satellite-earth station RF links as
scintillation fading, which can be significant at the L-band and S-Band frequencies
anticipated for use by satellite-to-AES links. In essence, scintillation is an extreme version
of a RF link parameter that occurs rarely when examined over the ensemble of potential
aircraft locations. Thus, scintillation-induced outages are classified as Fault-Free Rare
Events.
Scintillation is discussed in some detail in Appendix B, which notes that scintillation
effects can cause major disruption of the RF link and are "highly correlated with the
position and local time of the aircraft". Appendix B further notes that "Scintillation
events also exhibit a seasonal influence, peaking during the vernal and autumnal
equinoxes". Finally, Appendix B requires that "Satellite systems seeking approval for
AMS(R)S operations shall either provide a link budget entry in their analysis, with
supporting rationale, or shall include specific consideration of scintillation effects in their
assessment of system availability."
To the extent that scintillation effects are not accounted for in the RF link analysis, they
must be accounted for in the availability computations. This is done by estimating the
duration of scintillation effects over the observation time as a function of aircraft location,
and completing the computation of [C-7].
C.3.1.3
Interference Events
MASPS Section 3.3.1.2 establishes the requirement that the system provide adequate
performance in the presence of aggregate interference from external sources equivalent to
25% of the total noise power in the received RF channel. In the real-world environment,
however, there are occasionally instances where substantially higher levels of
interference are experienced. Because these higher levels of interference exceed the
design requirements placed upon the system, it is reasonable to expect that these
instances will cause service outages. Such outages, which may occur even when the
AMS(R)S system is operating within its design parameters, must be included in the
availability computation as Fault-Free Rare Events.
The interference experienced by an AES will be a strong function of other navigation,
communications, and surveillance systems operating on the same aircraft, of emissions
from other aircraft in the surrounding airspace, and of emissions from ground facilities.
Appendix G gives a methodology for assessing interference between aircraft in the same
airspace. This methodology should be used to bound the unavailability due to
interference. The resultant lower bound on availability should then be combined with the
other terms using the multiplicative model given by [C-28].
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-19
DRAFT
Unavailability due to "same aircraft" interference is highly dependent on the specific
aircraft installation. As such, it should be considered as part of the installation
certification or approval process. A response related to these issues is not required as part
of the system-specific material submitted in response to this MASPS.
C.3.1.4
Capacity Overload Events
Regardless of the system architecture, there is a probability that the capacity can be
overloaded by aeronautical services. Although this probability is likely to be very small,
it should be estimated and included in the availability computation.
For the purposes of conservatively estimating the effects of overload conditions, the
following assumptions should be used:
1. Assume that the system complies with the Priority-Precedence-Preemption
requirements of MASPS Section 2.2.4.
2. Assume that the average service demand rate is the total per-aircraft demand for all
levels of AMS(R)S service, as given by the Traffic Model defined in response to
MASPS Section 2.2.5.1.1 and Appendix E, multiplied by the maximum number of
aircraft in the smallest resolvable subset of the coverage volume (e.g., spot beam).
That is:
N AIRCRAFT TRAFFIC _ MODEL
[C-30]
3. Use the nominal message service rate derived from the declared user data rate per
channel as given in Table 2-1 of the MASPS.
4. Assume that any blocking at Point B or Point C is a service outage.
5. Set the "number of servers", c, to the minimum number of communications channels
available for AMS(R)S at any point within the subnetwork, as declared in the System
Model required by the MASPS.
Under these assumptions, complete Table C-1 and the computations of [C-12], [C-13],
and [C-14] for both the to-aircraft (uplink) and from-aircraft (downlink) message loads.
Compute the overall availability for loading as the product of the availabilities for the
uplink and downlink. The overall availability value due to system overloading may now
be combined with the other fault-free rare event factors by means of [C-9].
C.3.2
System Component Failure Events
The second class of events that adversely affect system availability consists of equipment
failures typically included in conventional availability analysis. Depending on the
satellite system architecture, this analysis could be complicated by redundant paths for
satellites (i.e. two or more visible to the AES), network control (i.e. redundant command
and control paths), and GES functionality (i.e. more than one GES capable of sustaining
the connectivity with the aircraft). AES installations may also be redundant, but the main
body of this MASPS specifically excludes AES effects from the required computation.
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-20
DRAFT
Note:
Although inclusion of AES installation effects on the overall availability of
communications is not required for the purpose of compliance with this MASPS,
it is expected that an explicit accounting of these effects will be required prior to
obtaining operating authority for specific aircraft. Therefore, a suggested
methodology for such accounting is included below.
Despite the complex nature of an availability analysis involving multiple redundancies, it
should be possible to base the AMS(R)S availability analysis on similar non-safety and/or
commercial availability analyses performed by the constellation operator. Use of such
analyses as a baseline for AMS(R)S performance is encouraged.
Maintenance and replacement practices are inextricably linked to any availability
analysis. The standard practices for the constellation operation, along with any
AMS(R)S-specific enhancements, should be disclosed in the system-specific material.
The issues of repair/replacement of failed satellites and repair/restoration of failed GES
equipment are of particular concern. This disclosure and analysis may be conducted at
the GES, AES, NCS, and satellite level. It is not necessary that the analysis be extended
into the specific on-board or on-site redundancy architectures.
For the purposes of the process defined in this appendix, the analysis shall use the
following standard assumptions.
1. Outages due to NCS failures are assumed to affect the entire declared coverage
volume. Redundant NCS functionality should be modeled as "redundant with
independent repair" per [C-16].
2. Depending on the system architecture, outages due to GES failures may be limited to
specific subsets of the declared coverage volume. GES failures should usually be
modeled as "redundant with independent repair" per [C-16]
3. Outages due to individual satellite failures may be limited to some subset of the
declared coverage volume, and may be limited in time duration, as well, depending
on the constellation dynamics and orbital parameters. Redundant coverage volumes
should be modeled as "redundant with common repair", per [C-15], where K is the
number of satellites providing redundant service at the measurement point x .
4. Because of the sensitivity of AES availability to installation configuration, AES
failure effects are excluded from this analysis. That is, for the purpose of this
analysis, assume AAES 1 . Nevertheless, Section C.3.2.4 gives the methodology for a
simple K-redundant AES model, in the expectation that such computations will be
required before operating authority is granted. Redundant AES failures should be
modeled as "redundant with common repair", per [C-15], where the average repair
time includes 50% of the average flight duration.
Under these assumptions, the System Component Failure availability model becomes:
ASCF (x) ANCS (x) AGES (x) ASAT (x) AAES
ANCS (x) AGES (x) ASAT (x) 1
ANCS (x) AGES (x) ASAT (x)
where [C-7] is used for each of the NCS, GES and satellite sub-elements of [C-31].
©RTCA, Inc. (does not apply to draft material)
[C-31]
Appendix C Final
C-21
GES Failure Events
DRAFT
C.3.2.1
For the purpose of estimating the AMS(R)S system availability, the analysis of GES
failure events need not extend below the effects of a GES outage affecting all or part of
the declared service volume. Internal redundancies within the design of the GES should
be considered in determining the average outage rate of the GES as a whole.
It is possible that some part, or parts, of the coverage volume may be served by multiple
GESs. In this case, the benefits of GES-level redundancy may be taken only when the
networking between GES sites occurs within the GES boundary. That is, once a user has
connected to a specific Point C of the subnetwork, availability computations must assume
that the connection point does not change during the duration of the outage.
Representative external and internal networking block diagrams are shown in Figure C-5.
ATN
User
GES
A
External networking
uses either A or B
Satellite(s)
AES
GES
B
(a)
ATN
User
GES
A
Networking internal
to subnetwork
Satellite(s)
AES
GES
B
(b)
Figure C-5: Examples of External and Internal Networking Between GES Sites
It is possible that the internal networking indicated Figure C-5(b) may occur through the
satellite constellation. Such an architecture is a specific implementation of inter-GES
networking, and may take appropriate benefit.
If the system architecture provides GES-level redundancy in a manner equivalent to
Figure C-5(b), the availability computations should follow the "redundant with
independent repair" model per [C-16].
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-22
DRAFT
In any case, the GES availability should be computed using the formulation of [C-7] for
each AMS(R)S-capable GES.
C.3.2.2
Satellite Failure Events
The effects of satellite failures in LEO and MEO systems are the primary motivation for
the expression of availability ratio as a function of AES location given in [C-5] through
[C-7]. A failure of a geosynchronous satellite may cause a widespread service outage
and the affected portion of the coverage volume will remain relatively fixed over time
until the satellite is repaired, restored or replaced. Failure of a LEO or MEO satellite, on
the other hand, will result in a smaller affected area, but the affected area will follow the
orbital motion of the satellite. Thus, many different geographic locations may see service
outages, but these outages will tend to be of limited duration. Depending on the orbital
and constellation parameters and other performance quantified in the system-specific
attachments, it is possible that satellite failure events might have a minimal effect on
overall availability.
For the purpose of estimating the availability impacts of an satellite failure, the satellite
system operator should perform the following analyses and report the results in the
system-specific appendix.
1. Assuming a complete failure of a single satellite, compute the availability of the
AMS(R)S subnetwork using [C-7] and taking into account the satellite network
architecture, orbital parameters, and constellation. Provide plots indicating the
sensitivity (if any) of the availability as a function of latitude and longitude. Provide
plots indicating the maximum outage as a function of latitude and longitude. Provide
plots of the distribution of time between consecutive outages due to the same failed
satellite as a function latitude and longitude.
2. Incorporate the effect of satellite restoration times in the analysis.
3. Incorporate the satellite reliability and service life factors into the analysis and
determine the overall degradation of availability due to the satellites.
Because this analysis is intended to provide a worst-case assessment of satellite
availability effects, it assumes the total failure of an individual satellite. Once this worstcase assessment has been performed, the same methodology may be repeated for more
limited failure modes, if desired. For example, a significant failure mode for the satellite
may be the failure of an individual spot beam covering only a fraction of the total area
covered by the satellite. In this case, all of the references to the "satellite" can be
replaced by the "spot beam".
C.3.2.3
NCS Failure Events
For the purpose of estimating AMS(R)S system availability, analysis of failure events of
the NCS must consider those events that affect AMS(R)S communications capability in
all or part of the declared service volume. Internal redundancies within the design of the
NCS may be considered in determining the average outage rate of the NCS function as a
whole. For NCS failure modes that affect only a portion of the coverage volume, the
methodology of [C-7] should be used.
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-23
AES Failure Events
DRAFT
C.3.2.4
For the purpose of estimating the AMS(R)S system availability as required by this
MASPS, the AES installation is assigned an availability of 1.0, as explained in the notes
that follow.
Notes:
1.
Of course, the AES implementations will not be failure-free. The assumption
made in this MASPS is a recognition that the availability effects of a particular
AES installation will be tailored to particular requirements of individual aircraft.
The specific installation details, including the effects of any redundant equipage,
will then be used to establish the ICP for that aircraft.
Because of the configuration details that are required, the ICP availability for a
specific AES installation is not required in this document. When performing ICP
availability computations regarding multiple AES equipment on the same
aircraft, all redundant components should be analyzed with the "redundant with
common repair" model of [C-15]. The availability of the redundant and nonredundant elements of the AES installation should then be combined using [C-9].
In this model, the outage rate, OUT , should be the failure rate of the individual
redundant elements. The restoration rate, OUT should be computed using the
2.
on-aircraft mean-time-to-repair, TREPAIR and the average duration of the flight
anticipated for the particular aircraft, TFLIGHT , as follows:
OUT AES
1
TREPAIR 12 TFLIGHT
[C-32]
This accounts for the fact that failures during flight can be compensated by
redundancy, but that the repair process does not begin until the aircraft lands
and the equipment is replaced.
C.3.3
Multi-User vs. Single User Availability
The MASPS defines two types of availability. A separate analysis is required for each.
This subsection discusses recommended modifications to the availability model of Figure
C-3 for computing Multi-User and Single User Availability.
C.3.3.1
Multi-User Availability
The computation of Multiuser Availability is a special case of the generic availability
computations discussed in Section C.3.1 and Section C.3.2. Multi-User availability is
computed based on Satellite Network Infrastructure effects only. As discussed above, the
effects of AES component failures are specifically excluded from MASPS availability
computations. All other sources indicated in Figure C-3 are included in the Multi-User
Availability computations:
Fault Free Rare Events
RF Link Performance – see the discussions of Section C.3.1.1.
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-24
DRAFT
Ionospheric Scintillation – see the discussion of Section C.3.1.2.
System Traffic Overload – the overload analysis should be based on the average
load given in the traffic model times the number of aircraft in the smallest
resolvable subset of the coverage volume (e.g.,. spot beam), see Section C.2.1.7
and Section C.3.1.4.
Interference Effects – for the purpose of computing Multi-User availability, the
worst-case unavailability, (i.e., the peak of the "multi-aircraft unavailability
curve" of Appendix G) should be used.
System Component Failures
GES Failures – see Section C.3.2.1.
NCS Failures – see Section C.3.2.3.
Satellite Failures – see Section C.3.2.2.
AES Failures – in accordance with the assumptions of Section C.3.2.4, the
compuation should assume that the AES is always available.
When the individual terms have been computed, the Multi-User availability is computed
using [C-28].
Note:
C.3.3.2
The Multi-User availability requirement (MASPS Section 2.2.5.3.3)) is
significantly more stringent than the Single-User availability requirement
(MASPS Section 2.2.5.3.4). This comes about under the assumption that the
impact of a single-aircraft whose communications are unavailable can be
mitigated by communicating with one or more of that aircraft's nearest
neighbors.
Single-User Availability
Single-User Availability is computed in the same manner as Multi-User availability, with
some variations in which type of outages must be counted in the various categories
described in Section C.3.1 through Section C.3.2.4.
As discussed above, the effects of AES component failures are specifically excluded
from MASPS availability computations. All other sources indicated in Figure C-3 are
included in the Multi-User Availability computations:
Fault Free Rare Events
System Traffic Overload – the overload analysis should be based on the average
load for a single aircraft given in the traffic model. The number of servers should
be the smaller of the number of AMS(R)S channels available to a single user, or
the number of AMS(R)S channels accessible by the minimum capability
AMS(R)S. See Section C.2.1.7 and Section C.3.1.4 for additional methodology.
This "single-user" overload availability should be used in lieu of the "multi-user"
overload availability described in Section C.3.3.1.
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-25
DRAFT
Interference Effects – For the purpose of computing Single-User Availability,
only one-to-many interference effects, computed by means of the methodology
described in Appendix G, should be included. This interference availability
factor should be used in lieu of the "multi-aircraft unavailability" factor described
in Section C.3.3.1.
For all other Fault-Free Rare Occurrences, including Scintillation and other RF
Link effects, the computation of SingleUser unavailability should include all
factors included in the Multi-User availability plus any additional factors that
could affect one and only one aircraft. To assess if a given rare event falls in the
single-user or multi-user consideration, perform the following tests:
1. compute the minimum volume covered by the rare event;
2. assuming the maximum aircraft density described in the volumetric model of
Appendix G, estimate the number of aircraft operational in the minimum
volume;
3. if the maximum number of aircraft is less than two, treat this rare event as a
single-user event, but not as a multi-user event; and
4. if the maximum number of aircraft is greater than or equal to 2, treat this rare
event as a multi-user event.
System Component Failures – For outages caused by component failures, include
those effects already indicated in the multi-user analysis plus any effects that can
affect a single aircraft operating in an airspace otherwise populated at the maximum
density computed in Appendix G. The same four- step process noted above can be
used for this determination.
For example, assume that a LEO AMS(R)S system has a minimum spot beam
diameter of 500 miles, and that the volumetric aircraft density computed in Appendix
G is one aircraft per 430 cubic miles. Finally, assume that aircraft fly between sea
level and 5 nautical miles in altitude. Then the number of aircraft in a spot beam is:
500
nmi)2 (5 nmi)
2
2280 aircraft
430 nmi3 / aircraft
(
[C-33]
The result given in [C-33] is obviously too large for a real-world scenario, but does
indicate that a spot beam failure will affect far too large a volume to be restricted to a
single aircraft. Therefore, no additional consideration need be given to spot beam or
satellite failures, beyond that included in the computation of multi-user availability.
GES Failures – see Section C.3.2.1.
NCS Failures – see Section C.3.2.3.
Satellite Failures – see Section C.3.2.2.
AES Failures – in accordance with the assumptions of Section C.3.2.4, the
computation should assume that the AES is always available.
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-26
DRAFT
When the individual terms have been computed, the Single-User availability is computed
using [C-28].
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-27
DRAFT
C.4
AMS(R)S Availability Example
The following subsections contain an example computation of the availability of a
hypothetical AMS(R)S system. The example has been devised to illustrate several issues
involved in the computations required by Section 3, but is not intended to represent any
specific active or planned AMS(R)S example. No part of the example should be taken as
representative of the performance or design of a specific AMS(R)S system.
C.4.1
Example System Parameters
For the purpose of this example, assume that the service being evaluated is provided by a
LEO constellation of 66 satellites in near polar orbit. This is the same constellation used
for the example in Appendix B and Appendix G, and the results for those appendices will
be used in the availability computations. Assume that the system offers one 2400 bps
channel in the ground-to-air direction for each spot beam2. AMS(R)S inputs to this
channel are buffered to a depth of at least eight messages. In the air-to-ground direction,
the baseline system operates with four 2400 bps AMS(R)S channels in each spot beam,
but there is no buffering of input messages. Service is provided through multiple spot
beams, each of which has an average diameter of 500 nautical miles.
This example constellation experiences six satellite failures per year, and has sufficient
on-orbit spares available to allow a mean restoration time of 10.5 days.
There are six GES locations, each covering approximately one-sixth of the Earth's
surface. Fifty percent of the air traffic is served by one GES; the other 5 GES locations
each serve 10% of the air traffic. By design, the GESs supporting the system have builtin redundancy with fail-soft features. Multiple GESs are not connected "inside of point
C", so no "GES-level" redundancy can be assumed. Each example GES has a predicted
average failure rate (total failure) of once every 3 years. Such an occurrence is very
important, and results in massive restoration activity. Assume that the GES can be
restored to service in 12 hours, on average.
For this example assume that the satellite-to-aircraft and aircraft-to-satellite user links
operate in the mid-L-band, so that the scintillation effects discussed in Appendix B are
applicable.
C.4.2
C.4.2.1
Fault-Free Rare Events
RF Link Events
The example system operates in accordance with the example link budget given in
Appendix B. Appendix B supports a value of . The fade rate will be rapid,
due to the rapid apparent motion of the LEO satellites relative to the aircraft. Assume
2
Throughout this appendix, references to a 2400 bps channel or server mean that the net average user throughput
from Point B to Point C is 2400 bps. The channel modulation rate necessary to achieve this is not discussed in this
Appendix, as it does not influence the availability computations. The channel modulation rate for the example
system is significantly higher than the effective 2400 bps user rate.
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-28
DRAFT
that less than 1% of the RF link service interruptions persist for longer than TOD . Then
, and 1 105 .
approximately
The RF Link Events availability term is
ARF 1 105 0.999990 .
C.4.2.2
Scintillation
[C-34]
Scintillation is not accounted for in the example in Appendix B, therefore it must be
accounted for in the availability analysis. Assume that the worst-case scintillation
example of Figure B-3 of Appendix B applies.3 Assume further that the equatorial
scintillation region covers an area 15 latitude by 30 in longitude . The availability
computation of [C-7] is:
A(TOBS | x 1
1
TOBS
(T
OUT ) k
p(x )dx
[C-35]
k
For the purpose of this example, assume that the average density of aircraft in this
equatorial region is 2% of the density that would be obtained if the entire population of
aircraft was uniformly distributed over the US and Europe4. The total area of the US and
Europe is 2.02 1013 m 2 . So a uniform aircraft density in US and Europe is the number
of aircraft in those regions, NUSEU , divided by the area, or
NUSEU
4.96 1014 NUSEU aircraft/m2
13 2
2.02 10 m
[C-36]
A uniform probability density function for the US and Europe can be estimated by
dividing the aircraft density by the total population of aircraft, N . But our assumption is
that NUSEU N , so
4.96 1014 m-2
pUSEU ( x )
0
x in US or Europe
elsewhere
[C-37]
Finally, invoke the assumption that the average uniform density in the equatorial regions
is 2% of this worst case, or pEQ (x) 9.92 1016 m-2 .
From the assumed size of the scintillation region, it is simple to compute an average
30 long
2 hrs. One such outage occurs each day
outage duration of TOUT k
360 long/24 hrs
for each surface position in the equatorial region, so that k 365 .
3
Note that the size and shape of the scintillation region depends on the frequency of operation, among other things.
For a detailed explanation, see, for example, Basu [2] .
4
Applicant services must determine this density based on their specific services. This assumption is for the
purposes of this computation only.
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-29
DRAFT
Applying all of this to the availability equation:
A(TOBS | x equatorial scintillation region
1
=1-
1
TOBS
(T
OUT ) k
p(x )dx
k
1
(365 2 hours) pEQ (x )dx
8760 hours
1-
1
(365 2 hours) pEQ dx
8760 hours
[C-38]
15
1-
1
(365 2 hours) pEQ r 2 cos d
8760 hours
15
730
9.92 1016 m-2 2r 2 sin 15
8760
730
1
9.92 1016 m-2 2.13 1013 m 2
8760
AEQUATOR 1 .001740 0.998259
1
Now consider the effect of the high latitude scintillation effects. Assume that there are
six patches in the high latitude. Assume each patch is 1 (latitude) 5 (longitude) and
that the patches occur at 65 N and 65 S. Then there are 12 such patches. The patches at
65 N will experience a higher traffic density, say 10% of the worst case, "North America
plus Europe" value assumed, but the patches at 65 S will see virtually nothing. The
analysis will use 5% as an average value for patches at 65 N and 65 S:
p65 0.05 pUSEUA 2.48 1015 m-2
A(TOBS | x polar scintillation regions 1
=1-
1
TOBS
(T
OUT ) k
p(x) dx
k
1
5 /outage
(365 days 12 outages/day
24 hours/day)
8760 hours
360 /day
66
p65
r
2
cos d
[C-39]
64
66
r
64
2
cos d r 2 sin(66
) sin(64
) 6.00 1011 m 2
180
180
APOLAR 1
1460
2.48 1014 m 2 6.00 1011 m 2 0.999752
8760
The overall scintillation effects on availability are then:
ASCIN AEQUATOR APOLAR
0.998259 0.999752 0.998012
[C-40]
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-30
Interference
DRAFT
C.4.2.3
For the purpose of interference analysis, this example refers to the interference example
worked in Appendix G. Under the conditions given in that example, the maximum multiuser unavailability due to interference is
AINT 1 U MULTI AIRCRAFT 1 2.6 104 0.99974
C.4.2.4
Capacity Overload
[C-41]
To be consistent with the interference analyis just discussed, assume that all 300 aircraft
are in a single spot beam. Using the traffic model described in Appendix E, in the FANS
1/A environment, estimate the traffic load placed upon the system by the total uplink
message
traffic
to
all
300
aircraft
as
4
UP 8.95 10 messages/sec/aircraft 300 aircraft = 0.2685 messages/sec
With an assumed average data throughput of 2400 bps for each AMS(R)S channel server,
consistent with Appendix B, and a mean uplink message length of 184 octets, the average
uplink message service rate is
UP
2400 bits/sec
1.63 messages/second/server .
184 octets/message 8 bits/octet
For the downlink, the equivalent computations give
DN 2.85 103 messages/sec/aircraft 300 aircraft = 0.855 messages/sec
DN
2400 bits/second
2.206 messages/second/server
136 octets/message 8 bits/octet
For the purpose of this example, and to remain consistent with the traditional loading
analysis use of the term "server", we use the term "server" to mean all of the subnetwork
infrastructure required to support a single 2400 bps throughput communications channel.
By assumption, the candidate system dedicates a single such 2400 bps server with an
input buffer sufficient for eight uplink messages to AMS(R)S in the the uplink direction,
and four un-buffered 2400 bps channel ins the downlink direction. First, compute the
lower bounds implied by the simple Erlang B model.
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-31
DRAFT
ac
B ( c, a ) B ( c , ) c c ! n
a
n 0 n !
Uplink, c 1, a
UP
0.1647
UP
ACAP UP 1 B ( c, a ) 1 0.1414 0.8586
Downlink, c 4, a
[C-42]
DN
0.4012
DN
ACAP DN 1 B ( c, a ) 1 6.383 10 4 0.999362
For the uplink, the lower bound availability of 0.8586 is obviously insufficient for
AMS(R)S service, so the more complex form expressed in [C-14] must be used. For the
downlink, however, the lower bound is sufficient for typical AMS(R)S applications.
Note that this is a weak lower bound and that the actual performance may be significantly
better.
The uplink computations in accordance with [C-12], [C-13], [C-14] and Table C-1 are
completed as follows.
a K c
B ( c, a ) K c B ( c, a )
c K c
0.164791 B (1,0.1647) 7.656 108
BK ( c, a )
C K ( c, a )
[C-43]
ac
c!
1 c 1 a n a c
K c 1
k 0 n ! c !
1
a1
1!
1 0.1647 a 0 a1
9 11
0! 1!
1 0.1647
0.1647
0.1647
0.8353 0.1647
[C-44]
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-32
DRAFT
Table C-2: Parameters for Example Computation of Traffic Overload Effect
0.2685
average AMS(R)S service
demand rate
blocks/second
N BLOCK 184 octets=1472 bits average AMS(R)S block
length defined at Pt B or Pt C
user bits/block
RD 2400
nominal user data rate through
the AMS(R)S system viewed
at Pt. B or Pt. C
user bits/second
number of servers (channels)
available for AMS(R)S
unitless
size of queue or buffering
supporting AMS(R)S service
blocks
outage definition time
seconds
RD / N BLOCKS 1.63
average block service rate
blocks/sec
a 0.1647
average traffic intensity
Erlangs
a / c c 0.1647
average traffic intensity per
server
Erlangs per server
K c NQ 1 8 9
maximum system user
population
blocks
c 1
NQ 8
TOD 900
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-33
DRAFT
U LOAD (TOD ) Pr{q TOD }
=1-Pr{q TOD }
=1-Wq [t ]
K c 1
m
C K ( c, a ) K c
c t
K c m ( a t )
(1
e
(1
)
BK ( c, a )
m!
1 K c 1
m 0
9 1
0.1647 (1 0.1647
0.1647
1 0.16479
9 11
m
11.603900
9 1 m (0.1647 1.603 900)
(1 0.1647
)
e
m!
m 0
[C-45]
7.656 108
0.1647 4.518 107 O (0) 7.656 108
1.509 107
So the multi-user availability component due to overloading of the AMS(R)S capacity is
given by:
ACAP ACAP DN ACAP UP
(1 6.383 104 ) (1 1.509 10 7 )
0.999361
C.4.2.5
[C-46]
Fault Free Rare Event Summary
The overall availability effect of the Fault Free Rare Events for this example may now be
computed using [C-28].
AFFRE ARF ASCIN AINT ACAP
0.999990 0.998012 0.999740 0.999361
[C-47]
0.997105
C.4.3
System Component Failures
The treatment of system component failures is more in lines with traditional availability
analyses.
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-34
GES Failure Events
DRAFT
C.4.3.1
By assumption in Section C.4.1, the GES has built-in redundancy, fail-soft, etc., and
multiple GESs are not connected "inside of point C". The example GES has predicted
average failure rate (total failure) of once every 3 years or 26,280 hours, as assumed in
Section C.4.1. The distribution of aircraft among the six GES stations is as given in
Section C.4.1.
Since we do not have a "redundant" GES, by the definition in the MASPS, K=1.
Equation [C-48] breaks the computation into
AGES A(TOBS ) 1
1
TOBS
N OUT
(T
OUT ) k
p ( x ) dx
k 1
1 GES failure 50% ac/GES + 5 GES failures 10% ac/GES
3 years 8760 hrs/year 1 observation interval/8760 hours
1
1
8760 hours
24 outage hours
failure
[C-48]
1
8 outage hours
8760 hours observation interval
1 0.000913
1
0.999087
C.4.3.2
Satellite Failure Events
Based on an analysis of the orbital dynamics of the constellation and the coverage of the
various spot beams, the service provider has developed the conditional probability that a
user experiences a signal outage as a function of the user latitude. This conditional
probability is shown in Figure C-6. Notice that users in latitudes above 60 N or 60 S
experience no outages due to single satellite failures. This example will upper bound the
unavailability by taking the largest value in the Figure C-6, 0.0125. Equation [C-49]
applies [C-7] with these assumptions. As stated in the assumptions of Section C.4.1, the
average time to restore a failed satellite from on-orbit spares is 10.5 days (232 hours). To
allow computation of the geographic effects assume that 10% of all aircraft operate at
latitudes greater than 60 N, and that, on average, there are an insignificant number of
aircraft operating at latitudes south of 60 S.
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-35
DRAFT
Elevation Mask Angle: 8.2 deg, tmin = [0 60 100]
Pr[Service Outage | Known Outage, Known Latitude
0.014
0.012
0.01
0.008
0.006
0.004
0.002
0
0
10
20
30
40
50
60
Observer Latitude (deg)
70
80
90
Figure C-6: Example Probability of Outage Given a Known Satellite Failure
ASAT A(TOBS ) 1
1
TOBS
N
(T
OUT ) k
p ( x ) dx
k
(6 outages/year 0.0125 10.5 days/outage
24
hours/day)
(90%
aircraft)
1
1
+ (6 outages/year 0.000 10.5 days/outage
8760 hours
24 hours/day) (10% aircraft)
17 outage hours
1
8760 hours
1 0.001941
0.998059
C.4.3.3
NCS Failure Events
[C-49]
For the NCS, assume the same failure rate and restoration rate as a GES, but assume that
a separately maintained backup system is available and invisible to the user. So this is
K=2 redundancy, requiring use of [C-15] with common repair.
K
ANCS 1 K ! B (2,
24 hours 2
24
) B(2,
)
26280 hours
26280
1 2 8.34 107 4.1662 107 1 6.9 1013
[C-50]
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-36
AES
DRAFT
C.4.3.4
The availability contribution of the AES is installation dependent and is not included in
the MASPS computation. By direction (see Section C.3.2.4, MASPS Section 2.2.5.3.1,
and MASPS Section 3.1.4.2), the AES is assumed to be fault-free.
AAES 1
C.4.3.5
[C-51]
System Element Failures
The total availability effect of system element failures can now be aggregated using
[C-28]
ASEF AGES ANCS AAES ASAT
0.999087 (1 6.9 1013 1 0.998059
0.997148
C.4.4
[C-52]
System Availability Estimate
The overall system availability can be computed by aggregating [C-47] and [C-52] using
[C-28]. The result, as shown in [C-53], exceeds the requirements of MASPS Section
2.2.5.3.3.
AAMS ( R ) S AFFRE ASEF
0.997105 0.997148
0.994261 0.993
©RTCA, Inc. (does not apply to draft material)
[C-53]
Appendix C Final
C-37
DRAFT
C.5
AMS(R)S Continuity of Service Model
The remainder of this appendix develops a methodology for computing continuity of
service, based on discussions of Section C.3.
The basic model for computation of continuity of service is the same used for
computation of availability and illustrated in Figure C-3. Once again, the analysis
considers events as fault-free rare events or system failures.
C.5.1
C.5.1.1
Fault-Free Rare Events
RF Events
The discussions of Section C.3.1.1 apply to continuity of service analysis as well as to
availability, but the time interval of interest is likely to be substantially shorter. Section
3.1.1 was concerned with , the fraction of events where the RF Link budget is not
satisfied for a period at least as long as that defined for a service outage, TOD 10T95 .
The continuity analysis is interested in a similar ratio, , defined as the fraction of events
where the RF link budget is not satisfied for a period of TSI 0.1TCOS or longer. In
addition, an estimate of the rate at which such service interruption events occur, RF , is
also needed. The values of and RF are very dependent on the terms in the random
losses portion of the link budget, the satellite orbital parameters, and the assumed aircraft
motion. This analysis should be based on aircraft in normal straight and level flight at
their minimum cruise speed. When is known, [C-25] can be used to estimate the
desired rate.
The system-specific material shall discuss the effects of RF Link Performance on service
interruptions, and shall use the result of that discussion in the computation of continuity
of service. It is expected that service interruptions due to RF link performance may vary
significantly over the coverage area. Therefore, the estimate of the rate parameter, RF ,
should be computed in accordance with [C-23].
Once the value of RF has been estimated, the continuity of service should be estimated
by modifying equation [C-17] as follows:
COS RF 1 1 e RF TCOS
1 ( RF TCOS ) K
K
[C-54]
For the purpose of this computation, K should be set to the number of RF links to
different satellites that can be accessed simultaneously from an aircraft at a position given
by x . The assumption that RF Link events on the user link to two different satellites are
independent is implicit in this methodology.
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-38
Scintillation Events
DRAFT
C.5.1.2
The estimated number of scintillation events over the observation interval should be used
to estimate the average rate of occurrence of Continuity of Service events due to
scintillation. The average rate, SCIN , should be used instead of RF in [C-54] to
estimate the continuity of service effects. For this computation, K should be set equal to
the number of RF links to different satellites that can be accessed simultaneously from
an aircraft at a position given by x . The assumption that scintillation fades on the user
link to two different satellites are independent is implicit in this methodology.
C.5.1.3
Interference Events
The estimated number and duration of interference events should be used to estimate the
average rate of occurrence of a service interruption due to interference events. The
average rate, INT , should be used instead of RF in [C-54] to estimate the continuity of
service effects. For this computation, assume that an interference event effectively
eliminates all operating frequencies; therefore, K should be set equal to unity.
C.5.1.4
Capacity Overload Events
A surge in demand that overloads system capacity can cause a Continuity of Service
event by consuming the available AMS(R)S resources within the system such that new
AMS(R)S communications cannot be served for a period of TSI or longer. The capacity
overload estimate for availability was based on application of the modified Erlang-B,
modified Erlang-C, and unavailability equations given in formulas given in [C-12],
[C-13], and [C-14], respectively. In this case, the demand rate, , must not be confused
with the rate of Continuity of Service Events due to traffic loading, LOAD . The latter rate
is estimated as follows:
2. Compute CK ( c, ).
1. Compute BK ( c, ).
3. pCOS
m
K c 1
C K [ c, a ] K c
cTSI
K c m ( a TSI )
(1
e
(1
)
BK [c, a ]
m!
1 K c 1
m 0
4. LOAD
[C-55]
pCOS
TCOS
5. CLOAD 1 LOAD TCOS 1 pCOS
As in the availability case, use of the simpler unmodified Erlang-B formula given in
[C-11] may be used as a worst case estimate. To use the Erlang-B estimate, let
pCOS B( c, ) and then apply [C-25].
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-39
DRAFT
C.5.2
System Component Failures
For system component failures, the given failure rates for each major system level
component are used in [C-17], with the value of K determined by the hot-standby
elements that can be substituted within the service interruption time, if any. The service
restoration rate or mean-time-to-restore is generally not a factor in continuity of service
computations, due to the very short times.
C.5.3
Multi-User vs. Single User Continuity of Service
The same considerations discussed in Section C.3.3.1 and Section C.3.3.2 apply to the
computation of continuity of service, as well.
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-40
DRAFT
This page intentionally left blank.
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-41
DRAFT
C.6
AMS(R)S Continuity of Service Example
C.6.1
Fault-Free Rare Events
C.6.1.1
RF Link
Under the same conditions used in Section C.4.2.1, assume that that 10% of the RF link
service interruptions persist for longer than TSI . Then 1 and 1 104 .
Applying [C-22], we can compute the rate of RF Continuity of Service Events:
RF
pCOS
TCOS
TCOS
[C-56]
104
300 sec
3.33 107 / sec
The assumed near-polar orbits make it reasonable to assume that two satellites are always
visible for latitudes greater than 60 N/60 S. For the purpose of this example, assume that
only 20% of all aircraft are in this region. Then applying [C-26] with M=2:
CRF 1 (0.8 RF TCOS )1 0.2 RF TCOS
2
1 (0.8 3.333 10 7 sec -1 300 sec) (0.2 3.333 10 7 sec -1 300 sec) 2 [C-57]
1 8 10 5 4 10 10
0.999920
C.6.1.2
Scintillation
Scintillation is accounted for in the example of Section 4. That example assumes that the
service is unavailable for the entire duration of the interval. This leads to lesser
availability, but greater COS because there are fewer, but longer, service interruptions.
In keeping with the example in Section 4, this sample computation of Continuity of
Service must perform separate computations for both the equatorial and high-latitude
scintillation regions.
C.6.1.2.1
Equatorial Region
Use [C-23] with the assumptions stated in Section C.4.2.2:
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-42
1
TOBS
1
TOBS
N
DRAFT
EQ
COS ( x ) px ( x ) dx
N COS pEQ dx
[C-58]
1
365 9.92 1016 m-2 2.13 1013 m2
(8760 hrs 3600 sec/hr)
2.455 107 sec-1
where N COS =365 and the numerical values of pEQ and
dx are as computed in Section
C.4.2.2. Because the availability example of Section C.4 assumes that service is
completely lost for aircraft within the scintillation region, there is only a single, extended,
service outage each 24-hour period.
C.6.1.2.2
High Latitude Regions
Use [C-23] with the assumptions stated in Section C.4.2.2:
65
1
TOBS
1
TOBS
N
COS ( x ) px ( x ) dx
N COS p65 dx
[C-59]
1
(365 6) 2.48 10 14 m -2 6.00 1011 m 2
(8760 hrs 3600 sec/hr)
1.03 106 sec-1
where N COS 365 6 (six patches per day at affected latitudes) and the numerical values
of p65 and
C.6.1.2.3
dx are as computed in Section C.4.2.2 .
Continuity of Service
The computation of scintillation effects on Continuity of Service takes account of the fact
that, with our assumed constellation, satellites at a latitude of more than 60 N or 60 S
always see redundant satellites. Then applying [C-26] with M=2:
CSCIN CEQ C65
(1 EQ TCOS ) (1 ( 65TCOS ) 2 )
1 EQ TCOS ( 65TCOS ) 2
1 1.62 10
7
sec 300 sec (1.03 10
-1
0.999951
©RTCA, Inc. (does not apply to draft material)
6
sec 300 sec)
-1
[C-60]
2
Appendix C Final
C-43
Interference
DRAFT
C.6.1.3
The volumetric interference model presented in Appendix G has a maximum multi-user
unavailability of 2.6 10 4 . Consistent with Appendix G, we assume that this
unavailability is computed on the basis of an eight-hour flight segment. Then we can use
[C-25] to estimate
INT
U INT
T
2.6 104
8 hrs 3600 sec/hr
9.202 109 sec-1
[C-61]
This approximation is an upper bound, because it takes no account of the duration of
interference events and therefore includes many short-duration service interruptions of
duration less than TSI .
As a worst case, assume that the interference is wideband and affects all available
AMS(R)S channels equally, so that line of sight to two or more satellites does not
improve the continuity of service. Then, applying [C-26], with M=1:
CINT 1 INT TCOS
1 9.202 109 sec-1 300 sec
=0.999997
C.6.1.4
Capacity Overload
[C-62]
As with the computation of availability, we will consider the uplink and downlink
separately. The same assumptions made in Section C.4.2.4 apply to this analysis as well.
As in Section C.4.2.4, the first step is to compute the (unmodified) Erlang B blocking
probabilities as:
Uplink: B ( c, a ) 0.1414
Downlink: B ( c, a ) 6.383 104
[C-63]
Using these values and the AMS(R)S load from the minimum traffic model of Appendix
E, we can compute the rate of failed communications due to capacity overload:
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-44
DRAFT
CAP UP BUP ( c, a )
0.268 msg/sec 0.1414
0.038 msg/sec
1 0.999
300 sec
CAP DN BDN ( c, a )
[C-64]
0.788 msg/sec 6.383 104
=5.02 104
1 0.999
300 sec
The inequalities in each equation indicate that the rates estimated by means of the simple
Erlang-B model are too high to support the MASPS Continuity of Service requirement.
Therefore, additional analysis is required in both the uplink and downlink cases.
C.6.1.4.1
Uplink
The uplink calculation can be improved by using the more complete computations of
[C-12], [C-13], and [C-14] in the same manner as in Section C.4.2.4. In this case, the
probability of a Continuity of Service event is computed based on a service interruption
of 30 seconds. The effective rate of blocked messages is then given by the product of the
message rate by the probability of a failed message:
CAP UP UPU LOAD (30 sec)
=0.268 sec -1 1.509 10 7
4.052 108 sec -1
[C-65]
CCAP UP 1 CAP UP TCOS
1 4.052 108 sec -1 300 sec
0.999988
C.6.1.4.2
Downlink
For the downlink, Section C.4.2.4 assumes that there are 4 AMS(R)S servers, but no
buffering. Because input messages are not buffered within the AMS(R)S subnetwork, the
analysis can continue to use the Erlang-B formula. With 4 servers, the probability of a
blockage computed in [C-63] is 6.383 104 . The resulting Continuity of Service is then
given by:
CAP DN DN U LOAD (30 sec)
=0.788 sec-1 6.383 104
5.030 10
and
©RTCA, Inc. (does not apply to draft material)
4
sec
-1
[C-66]
Appendix C Final
C-45
DRAFT
CCAP DN 1 CAP DN TCOS
1 5.030 104 sec-1 300 sec
0.8491
[C-67]
which is obviously insufficient. This means that the subnetwork design needs to be
expanded by offering more servers or by including buffering. Assume that the design is
modified to dedicate 8 servers (channels) to AMS(R)S. Repeating the computations of
[C-66] and [C-67]:
CAP DN B ( c, a )
0.788 sec -1 B(8,0.3876)
0.788 sec -1 8.575 10 9
6.757 10 9 sec -1
[C-68]
CCAP DN 1 CAP DN TCOS
1 6.767 10 9 sec -1 300 sec
0.999998
Note that this increase in the number of servers will affect the availability computation as
well. To be completely correct, Equation [C-42] should be re-evaluated. However, since
the Erlang-B coefficient is monotonically decreasing with an increasing number of
servers, the value computed by [C-42] can still be associated with a lower bound on
system performance and need not be recomputed.
C.6.1.4.3
Total COS effect of capacity overload:
The total effect on Continuity of Service due to overload of either the uplink or downlink
is:
CCAP CCAP UP CCAP DN
0.999988 0.999998 0.999986
C.6.1.5
[C-69]
Fault Free Rare Event Summary
The Continuity of Service effects of Fault Free Rare events can now be computed by
means of [C-27]:
CFFRE CRF CSCIN CINT CCAP
0.999910 0.999951 0.999997 0.999986
[C-70]
0.999844
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-46
DRAFT
C.6.2
System Component Failures
The rate system component failures can be analyzed using conventional reliability
techniques, and the resultant rates used to estimate the Continuity of Service by means of
[C-26].
C.6.2.1
GES
In the example of Section C.4, the GES was assumed to possess internal redundancies
that made a complete failure unlikely. For the purpose of this Continuity of Service
example, assume that this internal switchover mechanism does not occur instantaneously,
but requires a finite time interval slightly greater than TSI to complete. Then every time
the GES experiences an internal failure, all aircraft being served will experience a
Continuity of Service event. Assume that these internal events occur, on average, once
every 2000 hours of operation.
The rate of Continuity of Service Events is then:
1 failure
2000 hrs 3600 sec/hr
,
6 1.389 107 sec 1
GES N GES
7
8.333 10 sec
[C-71]
1
and the corresponding Continuity of Service is5:
CGES 1 GES TCOS
1 8.333 107 sec 1 300 sec
=0.999750
C.6.2.2
Satellites
[C-72]
Under the assumptions given in Section C.4.1, a series Continuity of Service events
always occur when a satellite fails. The associated service interruption moves with the
satellite around its orbit, so that each user only loses service for a brief period. However,
the orbital motion makes the service interruption repetitive. Using the assumed nearpolar orbits, there is an 80% chance that any user aircraft will not use the same satellite
for another 12 hours, due to Earth rotation. Assuming the same 10.5 day restoration
period assumed in Section 4, then we could potentially see 2 outages a day for 10.5 days,
or 21 outages over the entire availability observation interval of 1 year for each failure.
The other 20% of the users see twice as many outages, because they experience a service
interruption on two consecutive orbits. So for each failed satellite, the number of outages
is:
5
To keep the example simple, the computations of [C-71] and [C-72] assume that all GESs have the same
probability of affecting a user aircraft. In Section 4, the assumption was that one GES served 50% of the air traffic.
To account for this, [C-71] should be modified to use the effective number of GESs: 0.5 x 1 + 0.5 x 5 = 3. This
decreases the GES failure rate ([C-71]) to 4.166 x 10-7, and increases the Continuity of Service ([C-72]) to
0.999875, but the changes do not materially affect the results of this example.
©RTCA, Inc. (does not apply to draft material)
Appendix C Final
C-47
DRAFT
N 0.8 21 0.2 42 25.2 outages/satellite failure
N 25.2 6 failures/year = 151.2 failures/year
SAT
[C-73]
151.2 failures
4.795 106 COS events/year
8760 hrs 3600 sec/hr
In fact, the rate is significantly lower, because Figure C-6 shows that the average user has
a probability of less than 0.0125 of being affected by any given failure. So the rate of
Continuity of Service events seen by an average user is:
SAT 0.0125 SAT 5.993 108 sec-1
[C-74]
and the associate Continuity of Service effect is:
CSAT 1 SAT TCOS
1 5.993 108 sec-1 300 sec
[C-75]
=0.999982
C.6.2.3
NCS
Section C.4.3.3 assumes that the NCS is protected by internal redundancy, and that only a
negligible percentage of NCS failures cause a loss of communications. Making the same
assumption for Continuity of Service events:
C NCS 1
C.6.2.4
AES
[C-76]
The AES is installation dependent and is not included in the MASPS computation. By
direction (see Section C.3.2.4 and MASPS Section 3.1.5.1), the AES is assumed to be
fault-free.
C AES 1
C.6.2.5
[C-77]
System Element Failures
The overall Continuity of Service effects of system element failures are computed using
[C-27]:
CSEF CGES CSAT CNCS C AES
0.999750 0.999982 (1 ) 1
[C-78]
0.999732
C.6.3
System Availability Estimate
The total AMS(R)S system Continuity of Service is computed using [C-27]:
©RTCA, Inc. (does not apply to draft material)
Appendix C
C-48
DRAFT
C AMS ( R ) S CFFRE CSEF
0.999844 0.999732
0.999576 0.999
[C-79]
The final inequality verifies that the Continuity of Service computed using this
methodology and the assumptions of these examples meets the requirements established
in the MASPS, given that the number of downlink AMS(R)S service channels is
increased to 8, as noted in Section C.6.1.4.2
This completes the Multi-User Continuity of Service example.
References for Appendix C:
[1] A. O. Allen, Probability, Statistics and Queueing Theory with Computer
Science Applications, Boston: Academic Press, 1990
[2] S. Basu, et al.,"250 MHz/GHz Scintillation parameters in the Equatorial, Polar, and
Auroral Environments," IEEE Journal on Selected Areas in Communications, Vol 5.
SAC-5, No. 2, Feb. 1987, pp. 102-115.
©RTCA, Inc. (does not apply to draft material)
© Copyright 2026 Paperzz