Iridium Satellite Communications System, Tsunami Warning System

Iridium Satellite Communications System

As Utilized by

The Deep-‐Ocean Assessment & Reporting of Tsunami Project Warning System

May 3, 2015

David Regan EN.635.411.81.SP15 Principles of Network Engineering Professor John Romano Johns Hopkins University

Iridium-‐DART Network

| P a g e

1

Introduction & Approach ............................................................................................ 2

Scope Limits ................................................................................................................ 2

Terrestrial Components Overview ............................................................................... 2

Space-‐Based Components Overview ........................................................................... 4

Network Links ............................................................................................................. 6 Tsunameter < -‐-‐ > Buoy ........................................................................................................................................... 6 Narrative & Technical Details ............................................................................................................................... 6

Buoy < -‐-‐ > Iridium Satellite ............................................................................................................................... 11 Narrative & Technical Details ............................................................................................................................ 11

Iridium < -‐-‐ > Iridium Inter-‐Satellite Links (ISL) ...................................................................................... 12 Narrative ..................................................................................................................................................................... 12

Iridium < -‐-‐ > Ground Station ............................................................................................................................ 13 Discussion .................................................................................................................................................................... 13

Routing ...................................................................................................................... 13

Latency Calculations ................................................................................................... 15

Total Transfer Time .................................................................................................... 16

Conclusions and Further Research .............................................................................. 16

References ................................................................................................................. 18

APPENDIX A – X-‐Modem Protocol Structure ............................................................... 19

APPENDIX B -‐ Images ................................................................................................. 20


| P a g e

2

Abstract This paper analyzes how the Iridium Satellite Communications System is used by The National Oceanic and Atmospheric Administration’s (NOAA) Tsunami Warning System. Each network link is evaluated providing a basis for understanding the overall system that yields a robust and trustworthy tsunami warning system.

Introduction & Approach This paper is organized as follows; first, a general overview of both the space and

terrestrial based components of The Deep-‐Ocean Assessment and Reporting of

Tsunamis (DART) Version II project will been made, then we will delve into

individual network links, including those provided by Iridium. A focus on the

acoustic link is made, since it is relatively unusual. This will provide a clear and

logical context from which to understand the entire networked warning system. As

each link is analyzed, end-‐to-‐end networking achievements are revealed.

Scope Limits This paper is focused on the DART and Iridium network links and uses publically

available information in the process. Some detail related to the Iridium system are

proprietary, therefore extrapolation from

known systems is used to make the best

approximation of missing detail.

Terrestrial Components Overview For more than 30 years, NOAA researched

the causes and impacts of tsunamis and in

response to a massive tsunami on March 28,

1964 in Alaska, NOAA began development of

the first Tsunami Warning Center. The

foundation of the warning system is DART,

whose buoys and bottom-‐sensor

components are shown in (Figure 1). Figure 1: DART System Components


| P a g e

3

By 2008, there were 36 buoys installed in DART’s Pacific Ocean zone providing

detailed sea level, temperature, barometric pressure, GPS coordinates, timing and

other buoy-‐specific information [1]. The secret of DART’s success is the use of global

communication links provided by the Iridium Satellite Constellation (Iridium).

Each buoy is installed with a companion tsunameter, as depicted in (Figure 2) (also

known as a bottom pressure recorder)[1], a that collectively constitutes the

transmission system for the water-‐based link for DART. Buoy’s have GPS receivers

to maintain geo-‐location for servicing, and for tsunami calculations.

Messaging Path DART uses Iridium as the backbone for transmitting tsunami data from buoys that

are sited in the open ocean. An RS232C interface with AT commands is used for

accessing satellites and PPP is the LLC layer protocol used. Messages destined for

the tsunami-‐warning center are triggered by tsunami waves passing over a buoy

a The tsunameter’s data storage: “The FLASH memory provides four years continuous backup of the entire raw pressure record, at a 15-‐second sample period. Preserving the entire time series in memory allows post-‐deployment engineering review of the instrument’s performance, as well as scientific analysis of the entire deployment record”. For more information, refer to: Sea-‐Bird Electronics. http://www.seabird.com/sbe54-‐tsunami-‐pressure-‐sensor

Figure 2: DART System Boundaries


| P a g e

4

(or from seismograph-‐driven auto generated commands) that activates a real-‐time

data feed from the tsunameter to the surface buoy. Data received at the surface buoy

from the tsunameter and is then forwarded to an Iridium Satellite, which transmits

the data either to a ground station (GS), or to an adjacent satellite via inter-‐satellite

links (ISLs), which is then forwarded to the nearest GS for appropriate distribution.

A typical GS is shown in (Figure 3) (gateway) – there are

two b of them -‐ with the primary being in Tempe, AZ, and

each has uplinks/downlinks using the Ka band over ranges

29.1-‐29.3 GHz and 19.1-‐19.6 GHz respectively. The

gateway interfaces with the PSTN and ISPs.

Space-‐Based Components Overview Iridium consists of 66 low Earth orbit (LEO)

satellites c distributed over 6 polar orbital planes

that are approximately 31.6 degrees apart

longitudinally at 86.4 degrees inclination[2] that

co-‐rotate. A seam develops between plane 1 & 6

where the satellites are counter-‐rotating. As shown

in (Figure 4), each Iridium satellite produces a

footprint that overlaps adjacent satellites’

footprints providing seamless ground coverage.

Also note that as satellites approach the poles, they overlap progressively – this is

important due to an obvious contention issue that will be discussed later.

“In space, each Iridium satellite is linked to four others — two in the same orbital

plane and one in each adjacent plane — creating a dynamic network that routes

traffic among satellites to ensure a continuous connection, everywhere [2]”.

Iridium’s routing algorithms are proprietary, but the mostly likely approach is Ad-‐ b After contacting Iridium Communications, and an exhaustive Internet search, it appears that there are 2 ground stations left out of the original 13. c Additional in-‐orbit spares are held at a lower orbit and are moved up to operational height as needed. All of the spares have been used presently, but the new Iridium NEXT is to be launched this year (2015) in October on the current timeline. This will include all new satellites with higher capacity, although it is beyond the scope of this paper to analyze the new system.

Figure 3: Iridium Ground Station

Figure 4: Iridium Satellite Footprints


| P a g e

5

hoc On-‐Demand Distance Vector (AODV)[3] routing, which considers the

complexity, transmission overhead, dynamic update convergence and infinite loop

issues related to not only a routed environment, but also one that is continually in

flux. Select aspects of AODV are considered and described later in the routing

section.

Each satellite has three antennas with 16 spot

beams (48 spot beams per satellite) and 240

channels for user communications utilizing L-‐

band (1-‐2 GHz) over the range 1616-‐1626.5

MHz for a bandwidth of 10.5 MHz [4] . Within

each satellite’s footprint (Figure 5), 48

separate spot-‐beams (cells) are identified

alphabetically A-‐L in a pattern that repeats

four times). As noted, since the space vehicles

converge near the poles, footprint-‐overlap becomes an issue – to maintain a uniform

loading on the SVs, outer cells in the overall footprint (Figure 4) are selectively

turned off at SV convergence latitudes. Similar to cellular systems, Iridium reuses

frequency bands; specifically with a reuse factor of 12 as reflected in (Figure 5).

Reuse allows limited spectrum to be repetitively provisioned provided sufficient

spatial isolation between duplicated frequency ranges. The ability to employ this

reuse capability is a function of the attenuation characteristics of the specific

frequencies [5] i.e. as the power density of a given frequency attenuates, it becomes

so weak that it can be ignored, and the frequency can be “re-‐amplified” and used

once more for a different unique channel.

The 240 available channels per satellite are divided among the spot beams yielding

20 channels per spot beam. Each satellite’s 10.5 MHz user-‐bandwidth is evenly

distributed over 240 channels using FDMA, where each channel is provided with

41.67 kHz (minus guard-‐bands) of bandwidth as visualized in (Figure 6). The

remaining 500 kHz is used to provide approximately 2 kHz of guard band between

channels. This arrangement facilitates managing many unique user channels.

Figure 5: Iridium Spot Beams (Cells)


| P a g e

6

TDMA is also utilized, but specific

details are not published by Iridium

except that the frame is 90 ms long

as depicted in (Figure 7) and

contains 4 full-‐duplex user-‐channels

with a frame burst rate of 50 kbps.

Time slots effectively multiply the 20 frequency channels into 80 after time division

slotting into the 90-‐millisecond TDMA frame. A maximum bit rate for a single user

channel is 2.4 kbps, although if multilink point to point protocol is used, channels

may be bonded for higher effective bandwidth and capacity [6]. The link between

the tsunameter and buoy is not

as sophisticated as Iridium’s,

yet it has unique

characteristics – particularly its

carrier and media.

Network Links

Tsunameter < -‐-‐ > Buoy

Narrative & Technical Details The tsunameter and buoy both use acoustic transducers to transmit digital data

over analog carrier up to a distance of 6,000 meters in unguided media (seawater).

Modulation of the digital data is accomplished by use of multilevel frequency shift

keying (MFSK), which is highly amplified at the transducer (dB 193) as it produces

the acoustic signal in waterd.

The tsunami-‐messaging channel opens when the tsunameter sends a transmission to

the buoy (or buoy to tsunameter) via acoustic modem every six hours in standard

d There is an entire field of study dedicated to underwater acoustic networking. See https://seagrant.mit.edu/publications/MITSG_08-‐37J.pdf “Underwater Acoustic Communications and Networking: Recent Advances and Future Challenges”

Figure 7: User Channels

Figure 6: TDMA User Slots


| P a g e

7

mode. The tsunameter always records readings every 15 seconds from its sensors

and saves the data to flash memory. If the tsunameter detects a pressure variation

determined to be a tsunami, (determined by detection algorithm)[7], or if an

automated remote command is received, the tsunameter goes into an event-‐mode

where a file with 120, one-‐minute average readings are sent to the buoy

immediately vs. the six hour interval in standard mode. Whether standard or event

mode, the transmissions are forwarded to

the tsunami warning center using Iridium.

(Figure 8) shows basic blocks of the

tsunameter’s computer system.

The message payload is a small (2 KB +/-‐) xml file containing key data including

water pressure

(leads to wave

height), date-‐time,

system-‐status, and

temperature. A more

detailed diagram of

internal flow appears

in (Figure 9).

Figure 8: Tsunameter Computer Block Diagram

Figure 9: Tsunameter Logic Diagram


| P a g e

8

The tsunameter <-‐-‐> water <-‐-‐> buoy communication channel is a clear instance of

the basic communications system model, which is repeated throughout the DART

system with varying degrees of complexity.

The communication model maps to the tsunameter/transducer (source system),

seawater (transmission system) and the buoy/transceiver (destination system)

assuming we are sending signal from the bottom up as depicted in (Figure 10).

“The acoustic modems on the DART II systems are configured to operate in the 9-‐

14kHz frequency band at 600 baud, using MFSK modulation and error-‐correcting

coding [8]”. X-‐modem protocol is used and its packet structure is described in

Appendix A. Maximum throughput is controlled by the maximum receive rate of the

acoustic modems, fade and noise, which is theoretically 2400 bps [9]. The actual

throughput from NOAA is shown at 600 baud and it is assumed that r = (1 data

element / 1 signal element) for 600 bps. A complete latency chart will be presented

after all the links are defined. To clarify, we have digital data stored for analog

transmission on the tsunameter, therefore, we need to modulate the data for analog

transmission, which is done with a multilevel frequency shift-‐keying (MFSK)

approach at the physical layer.

From the surface buoy, data is transmitted to the switched Iridium satellite network,

then to a GS that forwards to the Tsunami Warning Center e. It takes 30.16 seconds

for a 2KB message to arrive complete at the buoy as will be shown. For analysis, a

e Ground stations have 9-‐foot diameter dishes and link users to Internet/PSTN.

Figure 10: Tsunameter-‐Buoy Communication Model


| P a g e

9

depth of 3000 meters is chosen (approximate average) and speed of sound in water

is defined to be 1500 m/s. Further, a single data file size of 2KB is used for

transmission calculation. First, sound propagation in water over distance 3000

meters.

𝑇𝑝 =𝑑𝑟 =

3000𝑚1500𝑚/𝑠 = 2 𝑠𝑒𝑐𝑜𝑛𝑑𝑠

Secondly, our 2 KB file is processed by x-‐modem protocol, which has a 128-‐byte

payload per 132-‐byte packet, requires this many packets:

16000 𝑏𝑖𝑡 𝑓𝑖𝑙𝑒

128 𝑏𝑦𝑡𝑒𝑠/𝑝𝑎𝑐𝑘𝑒𝑡 𝑥 (8𝑏𝑖𝑡𝑠𝑏𝑦𝑡𝑒𝑠) = 15.625 𝑝𝑎𝑐𝑘𝑒𝑡𝑠 𝑟𝑜𝑢𝑛𝑑𝑒𝑑 𝑡𝑜 16

Total transmit size for 16 packets:

16 𝑝𝑎𝑐𝑘𝑒𝑡𝑠 132 𝑏𝑦𝑡𝑒𝑠𝑝𝑎𝑐𝑘𝑒𝑡 = 2112 𝑏𝑦𝑡𝑒𝑠

Transmission Time for a 2KB file over 600 bps channel:

2112 𝑏𝑦𝑡𝑒𝑠 8𝑏𝑖𝑡𝑠𝑏𝑦𝑡𝑒 1

𝑠𝑒𝑐𝑜𝑛𝑑600 𝑏𝑖𝑡𝑠 = 28.16 𝑠𝑒𝑐𝑜𝑛𝑑𝑠

Considering that data is being transmitted through 3000 meters of seawater, an efficiency of 94.7% is impressive (2KB/2.112KB).

In summary, it takes two seconds for the setup notice to arrive at the buoy. Ignoring

actual setup processing delay and queuing at buoy, it takes 28.16 seconds to

complete the data transfer for a total of 30.16 seconds. Time for resend of bad

packets not factored. Table 1 contains summary details and short narratives to

complete the review of the tsunameter to buoy link.

Table 1: Communication Links Overview – Tsunameter -‐-‐ > Buoy


| P a g e

10

Link Features @ given OSI Layer

Tsunameter -‐-‐> Buoy

Application Data collected from pressure, temperature and other sensors and written to a space-‐delimited text file by C application

Presentation XML data file – space delimited text

Session Half Duplex operation due to open water medium, manages link

Transport Checksums and X-‐modem protocol – no port addressing entire packets of data with many blocks are sent without requesting an acknowledgement from the receiver after each block. When blocks are missing or erroneous, receiver requests resend of individual blocks.

Network: X-‐modem protocol packetizes data file bit-‐stream

DLL:LLC/MAC Physical Sea Water Media:

Characteristics: pressure, temperature, salinity, density Speed of Sound in water taken as 1500 m/s Bi-‐directional Acoustic Telemetry in Water (Media); Benthos ATM-‐880 Telesonar modem/AT Multiplexing Multilevel Frequency Shift Keying approach is used to modulate the binary stream into an analog for transport via media. The source level is at 193 dB re 1ųPa @ 1 m with a 40 VDC supply.

Bandwidth 9-‐14kHz = 5kHz Throughput Ranges

Trans Rate Tx = 150 -‐ 15360 bps Receive Rate Rx = 150 – 2400 bps (see signaling rate for actual)

Signaling Rate Actual -‐ 600 baud (signal elements/second) assumed 1/1=r Propagation T Sound in water – taken as 1500 m/s; T (propagation) t=d/r Latency Sum of Propagation times: signal propagation and message

transfer time included; queuing and processing times at each node ignored for this analysis

Attenuation Not addressed Distortion (fading from multipath)

UW sound propagation is characterized as either vertical or horizontal. Horizontal calculations have to consider seafloor reflections, while not in vertical; issues with multi-‐path reflections confusing the receiver – handled algorithmically


| P a g e

11

Noise (Whale Song)

Straight SNR= Signal/Noise; SNRdB =10log10SNR Not evaluated in this analysis

Data Rate Limits – Noiseless Channel

Nyquist Bit Rate: Not evaluated on this link in this analysis. 2 x bandwidth x log2 L, where L is number of signal level

Data Rate Limits -‐ Noisy

Shannon Capacity: Not evaluated on this link Bandwidth x log2 (1+SNR)

Bandwidth Delay Product

(600-‐bit/s)(2 s) = 1200 bits

Buoy < -‐-‐ > Iridium Satellite

Narrative & Technical Details As shown previously, data arrives at the buoy and is queued and or stored. Then, the

Iridium transceiver is activated and the file is transmitted via the uplink to Iridium

for switching to the Tsunami Warning Center. As will be shown in the next section,

propagation time is 2.60 ms and file transmission time is 6.67 seconds for the 2 KB

data file. Iridium uses FDMA and TDMA, both at the media access sub-‐layer of the

DLL for channelization, and time division duplexing (TDD) at the physical layer.

Channels are comprised of a frequency band and time slot. Multilink Point to Point

Protocol (MPPP), at the DLC layer [5] controls establishing, maintaining, configuring

and terminating endpoint connections as well as data transfer[5].

Table 2: Communication Link Overview – Buoy -‐-‐ > Iridium Link Features @ given OSI Layer

Buoy -‐-‐> Iridium

Application Proprietary

Presentation Not defined -‐ proprietary Session Not defined -‐ proprietary

Transport Checksums and X-‐modem protocol – no port addressing Network: Defined in section entitled “routing” DLL:DLC/MAC Muiltilink PPP at LLC and FDMA/TDMA at MAC

Physical

The radio frequency transmission in the 1565 MHz to 1626.5 MHz range and the data transmission rates are at 2.4 kilobits per second.

Bandwidth 5kHz


| P a g e

12

Throughput 2.4 kbps constrained at ground-‐user modem, although can be upgraded to higher rate based on channel bonding via inverse multiplexing or MLPPP

Signaling Rate See section titled “Space-‐based components overview”

Propagation T See latency calculations above Latency See latency calculations above Attenuation(db) Db=10log10(P2/P1)

Not addressed – data not published

Distortion (fading from multipath)

Not addressed -‐ data not published

Noise Not addressed -‐ data not published Data Rate Limits – Noiseless Channel

Nyquist Bit Rate: Not addressed 2 x bandwidth x log2 L, where L is number of signal level

Data Rate Limits -‐ Noisy

Shannon Capacity: Not addressed – data not published Bandwidth x log2 (1+SNR)

Delay Product Time to fill channel with data/bits: 2400bps x 1s/1000ms x 2.05 ms = 4.92 ms

Iridium < -‐-‐ > Iridium Inter-‐Satellite Links (ISL)

Narrative Data delivered to Iridium cross its nodes over inter-‐satellite links (ISL) that operate

at 22.55 – 23.55 GHz at 25 Mbps using the slotted TDMA, which is transmitted with

QPSK. Maximum user throughput is not known due to absence of data on ISL

overhead, data compression and factors. Frequency conversion of received signal

allows the Iridium to receive and transmit without interference, since frequencies

utilized for inter-‐satellite, uplink, downlink and user links are different. Crosslink

delay is shown to be 13.33 ms over an average distance between satellites of 4000

meters.

An interesting issue arises as the satellites converge at the poles remembering that

each orbit is in a polar plane. The 48 spot beams begin to increasingly overlap

creating a situation where the spot beams need to be managed to avoid interference.


| P a g e

13

It is assumed that this is done dynamically by algorithm where selected spot beams

are progressively shutdown at the periphery of the main footprint [3]. As defined in

the space-‐based components section, there are six orbital planes with 11 satellites

each. They all rotate in the same direction, which gives rise to a “seam” orbit -‐-‐orbits

that are in counter rotation relative to each other. This is managed by blocking

communication between the “seams” [10], since Doppler effects would create

unacceptable delay and overhead based on frequency-‐shifting transcriptions.

Iridium < -‐-‐ > Ground Station

Discussion From a networking perspective, the Iridium nodes are in two planes: the orbital and

terrestrial [11]. The Iridium network is similar to a cellular network in that static

base-‐stations communicate with moving devices and orders handoffs as signal

strength drops; in our case, the cells are moving. Another difference is that cellular

base stations switch directly into a terrestrially based network, not to other cellular

base stations using wireless transmissions. This is an important distinction since the

ground-‐based network has more capacity, while the space-‐based Iridium is

constrained by available RF throughput and signaling overhead.

There appears to be two ground station gateways (Hawaii and Arizona) and 21

antennas distributed geographically, yet this is difficult to verify as Iridium

Communications Inc. does not respond to questions related to details of its system

(warnings manifest if enough research is done). Gateways ensure space to ground

link availability, no matter whether a satellite is passing immediately overhead, or

not given that traffic is routed to the closest GS by the constellation. Routing is

examined in the next section.

Routing Iridium does not advertise its routing algorithm, and speculation abounds about it

in the aerospace industry, yet researchers’ models reveal that a modified Bellman-‐

Ford (mBF) algorithm is likely [3], which is no mean feat given such a highly


| P a g e

14

dynamic system, especially if we are relying on distance vector updates

propagating through the system. Given that system details are scarce, the next

section covers a macro-‐view of a potential configuration.

If we consider the Iridium system as two elements acting on two separate planes,

that of the Iridium constellation, and that of ground nodes, updating routing tables

based on node-‐to-‐node-‐propagated updates seems unnecessary (if we could rapidly

and autonomously calculate each node’s position). From that perspective, consider the

following; inter-‐satellite distances can be determined instantaneously based on GPS

calculations on each node, and while the speed of the satellites quickly negates

coordinate calculation, the routing tables should be able to update themselves faster

using an application specific integrated circuit (ASIC) existing as a separate

subsystem.

Node awareness of instantaneous relative position would allow the mBF algorithm

to determine least-‐cost distances by the node for itself, rather than having rapid and

ongoing route updates broadcast everywhere. Said another way, this would allow

distance vectors, for the constellation, to be maintained by calculation internally on

each satellite using an ASIC. This would eliminate convergence time and route

update traffic.

Uplinking user-‐access devices always connects with the nearest satellite based on

signal strength (and in consideration of the seam), and if the constellation already

knows the least-‐cost path through the constellation, then knowing the correct exit

node will complete the path.

Handoffs could be made on the same basis by having ground stations feeding the

nearest satellite a flag saying “you are closest to me”; this distance-‐vector (for the

two ground stations) would propagate through the constellation every few seconds,

creating system-‐wide awareness of exit points relative to the constellation’s nodes.

System-‐wide latency is considered next using our original 2KB source file from the

tsunameter.


| P a g e

15

Latency Calculations Tfile(2 kilobyte) = T(tsunameter-‐>buoy) + T (transmission) +T (uplink) + (N-‐1)T (cross) + T(downlink)

Where,

T(tsunameter-‐>buoy) = propagation delay and transmission time for file on the tsunameter-‐>buoy link

T (transmission) = transmission time for the file (2 kilo-‐byte)

T (uplink) = propagation delay from buoy to the satellite

T (cross) = propagation delay on satellites cross links

T(downlink) = propagation delay satellite to the ground; (processing/queuing delays per satellite ignored for this analysis)

N = number of satellites in overall link

T (uplink) = T(downlink) = !"#$%%&#$ !"#$#%&'!"##$ !" !"#!!= !"#!"

!.!!"!!!"!!"!"#

= 2.60 𝑚𝑠 [10]

Distance between satellites averages 4000 km[12]. So,

T (cross) = !"#$$%&'( !"#$%&'(!"##$ !" !"#!!

= 4000 !"!.!!"!!!"!!"

!"#

= 13.34 𝑚𝑠 [10]

T (transmission) = !"#$ !"#$!"#$%&'()'" !!!"#$!!"#

= 2 !"#$%&!.! !"#$

= 6667 𝑚𝑠 [10]

Therefore, the Total time to move a 2KB file over the system is:

T (Total) = ([30.15𝑠 𝑥 !"""!"!]+ 6667 𝑚𝑠 + 2 2.60 𝑚𝑠 + 13.34 𝑚𝑠) = 36.85 𝑠

To simplify this analysis, overhead/padding to frames not included in calculations

except in the case of the tsunameter to buoy.


| P a g e

16

Total Transfer Time

Figure 11: End-‐to-‐End Latency

Conclusions and Further Research The Tsunami Warning System is a masterwork of technology and it has been proven

to give warning to those in the path of incoming tsunamis saving lives. This was

demonstrated in Japan in 2011, and while the scale of a tsunami’s potential

devastation is terrifying, systems can be improved to provide better resolution of

expected wave-‐height saving as many as possible [13]. The Iridium Constellation is

integral to the success of the warning system, and its networking is a major factor in

this success.

Given the complexity of routing in a dynamic system of nodes, such as Iridium’s,

more research should be undertaken to improve dynamic routing in rapidly


| P a g e

17

changing RF networks. This has implications well beyond satellite constellations in

our ever-‐expanding mobility-‐oriented world.


| P a g e

18

References

[1] C. Meinig, S. E. Stalin, A. I. Nakamura, and H. B. Milburn. (2005, March 29). Real-‐Time Deep-‐Ocean Tsunami Measuring, Monitoring, and Reporting System: The NOAA DART II Description and Disclosure [Article]. Available: http://www.ndbc.noaa.gov/dart/dart_ii_description_6_4_05.pdf

[2] Iridium. (2015, March 30). Ground Infrastructure. Available: https://www.iridium.com//About/IridiumGlobalNetwork/GroundInfrastructure.aspx

[3] L. Xiangdong, G. Dilip, M. Tim, and S. Peter, "Analysis of IP Routing Approaches for LEO/MEO Satellite Networks," in 28th AIAA International Communications Satellite Systems Conference (ICSSC-‐2010), ed: American Institute of Aeronautics and Astronautics, 2010.

[4] S. R. Pratt, R. A. Raines, C. E. Fossa, and M. A. Temple, "An operational and performance overview of the IRIDIUM low earth orbit satellite system," Communications Surveys, IEEE, vol. 2, pp. 2-‐10, 1999.

[5] B. A. Forouzan, Data Communications AND Networking, 5th ed. New York, NY: McGraw Hill, 2013.

[6] A. M. Jabbar, "Multi-‐Link Satellite Data Communication System," Master of Science, Engineering, Electrical, Osamia University University of Kanas, 2001.

[7] NOAA. (n.d., April 20). Tsunami Detection Algorithm. Available: http://nctr.pmel.noaa.gov/tda_documentation.html

[8] NOAA, "DART II System," ed, 2015. [9] Benthos. (2014, April 30). Benthos Modems [PDF Files]. [10] S. R. Pratt, R. A. Raines, C. E. Fossa, and M. A. Temple, "An Operational and

Performance Overview of the Iridium Low Earth Orbit Satellite System," ed, 1999.

[11] Staff. (2015, March 30). Available: https://www.iridium.com/About/IridiumGlobalNetwork/SatelliteConstellation.aspx

[12] I. C. Inc., "Ground Station," ed: Iridium Communications Inc., 2015. [13] D. Demetriou. (2013). Tsunami two years on: Japan finally gets warning

system that would have saved hundreds of lives. Available: http://www.telegraph.co.uk/news/worldnews/asia/japan/9920042/Tsunami-‐two-‐years-‐on-‐Japan-‐finally-‐gets-‐warning-‐system-‐that-‐would-‐have-‐saved-‐hundreds-‐of-‐lives.html

[14] Wikipedia. (2015). XMODEM. Available: http://en.wikipedia.org/wiki/XMODEM


| P a g e

19

APPENDIX A – X-‐Modem Protocol Structure X-‐Modem uses a 132-‐byte packet structure with 128 bytes reserved for data. A 3-‐

byte header that included a <SOH> control character, a block number from 0-‐255,

and the inverse of the block number (-‐255) minus the block number with block

numbers starting at 1 and incrementing by 1 for subsequent blocks.

The packet trailer is a checksum of 1-‐byte. The checksum is the sum of all bytes in

the packet module 256. Only the eight least significant are retained, ignoring

overflow keeping the continuity of the 1-‐byte check. Once a file transmission was

complete, a special <EOT> character was sent, which was not part of the block [14].


| P a g e

20

APPENDIX B -‐ Images

Figure 12: DART II Image


| P a g e

21

Figure 13: DART Buoy -‐ Open Ocean

Figure 14: Tsunameter Awaits Deployment


| P a g e

22

Figure 15: Iridium Satellite

Iridium Satellite Communications System, Tsunami Warning System

Engineering

Transcript of Iridium Satellite Communications System, Tsunami Warning System