Multi-Link Iridium Satellite Data Communication System

1
Multi-Link Iridium Satellite Data Communication
System

• Overview, Performance and Reliability from Summer
  2003 NGRIP, Greenland
• Field Experiments
• June 23-July 17, 2003
• Abdul Jabbar Mohammad, Graduate Research
  Assistant
• Dr.Victor Frost, Dan F. Servey Distinguished
  Professor
• (September 24, 2003)

2
Motivation

• Polar Radar for Ice Sheet Measurements (PRISM)
• The communication requirements of PRISM field
  experiments in Greenland and Antarctica include
• Data telemetry from the field to the University
• Access to University and web resources from field
• Public outreach to increase the interest of
  student community (K-12) in scientific research
  and enable the science community to virtually
  participate in polar expeditions
• Generic data communication for Remote field
  research
• Mainstream communication system for polar science
  expeditions, field camps in Arctic/Antarctic and
  other research purposes
• Government and security use

3
Introduction Commercial Satellite Systems

• Polar regions do not have conventional
  communication facilities (dial-up, DSL, Cable
  Modem, etc) and are not serviced by most of the
  major broadband satellite systems.

Inmarsat
Intelsat
Globalstar
4
Introduction Special Purpose Satellite Systems

• NASA satellites like ATS3, LES9, GOES, TDRS 1,and
  MARISAT2 provide broadband access to Polar
  Regions
• Geo-synchronous, they have a limited visibility
  window at Poles typically 10-13 hrs/day.
• High satellite altitude and low elevation angles
  (1-20) result in extremely large field equipment.
• May not be readily available

20 m diameter Marisat and GOES antenna at South
Pole
5
Introduction - Iridium Satellite System

• The only satellite system with true pole-to-pole
  coverage
• 66 low earth orbiting (LEO) satellites with 14
  spares
• It has onboard satellite switching technology
  which allows it to service large areas with fewer
  gateways
• Since it was originally designed as a voice only
  system, it provides a low data rate of 2.4Kbps
• Not practical to be used as a main stream/
  life-line communication system

6
Introduction Problem Statement

• Problem Statement
• A reliable, lightweight, portable and easily
  scalable data/Internet access system providing
  true Polar coverage.
• Solution
• Implement a multi-link point-to-point Iridium
  communication system to combine multiple
  satellite links to obtain a single logical
  channel of aggregate bandwidth.

7
Background - Iridium
Satellite Type LEO
Satellite altitude 780 km
Minimum elevation angle 8.20
Average satellite view time 9-10 minutes
Access scheme FDMA and TDMA
Maximum number of located users 80 users in a radius of 318 km
Theoretical throughput 2.4 3.45 Kbps
Type of data services Iridium-to-Iridium, Iridium-to-PSTN
8
Background - Inverse Multiplexing

• Traditional Multiplexing - Data from a multiple
  applications/users sent over a single high
  bandwidth link.
• Inverse Multiplexing - Data from a single
  application is fragmented and or distributed over
  multiple low bandwidth links.
• Increases the available bandwidth per application
  significantly
• Multi-link point-to-point protocol (MLPPP), an
  extension to the PPP is a packet based inverse
  multiplexing solution
• Overhead of 12 bytes
• Fragmentation of network layer protocol data
  units (PDUs) into smaller segments depending
  upon the PDU size, link MTUs and the number of
  available links.

Inverse multiplexing
9
Background - Multi-link point-to-point protocol

• Layer 2 protocol that implements inverse
  multiplexing on a packet by packet basis
• IP packets are encapsulated in to PPP frames with
  segment numbers 12 byte overhead
• Packet fragmentation depends on the number of
  available links and their capacity, packet size
  and MTU size

SH-Segment header PDF- packet data fragment
10
Multi-channel Iridium System Design

• The design requirements of the system are as
  follows.
• The multi-channel implementation should maximize
  the throughput.
• To support real-time interactions, the system
  should minimize the end-to-end delay.
• The overall system should be reliable and have
  autonomous operation so as to handle call drops
  and system/power failures in remote field
  deployment.

11
Multi-channel Iridium System Protocol Stack
Remote System
Local System
Application
HTTP, FTP, SSH
TCP
IP
PPP/MLPPP
Physical Modems
Application
HTTP, FTP, SSH
TCP
IP
PPP/MLPPP
Physical Modems
point-to-point satellite links
12
Multi-channel Iridium System Network
Architecture
13
4-Channel Iridium System Implementation
14
4-Channel System Implemented at KU
15
4-Channel System Implemented at KU
16
4-Channel System Software Overview

• Linux based system
• Open source PPP package
• Custom software developed at University of Kansas
• Chat scripts for Iridium modems
• PPP script to tune link parameters for Iridium
  satellite system
• Client-Server configuration
• Autonomous operation-connection setup, user
  authentication, detecting failures,
  reconnections, handling power failures/system
  resets, generating status information (text)

17
4-Channel System Modem Flow Control
18
Field Tests and Results Field implementation
19
Field Tests and Results Antenna Setup
3 FT
10 FT
20
Results Delay and Loss Measurement

• Ping tests between the two machines at the end of
  the of satellite link
• One way propagation delay (80080006000)Km /
  (3e6)Km/sec 49msec
• Transmission time for 64 bytes_at_2.4Kbps
  648/2400213msec
• Theoretically, the RTT delay 2(49213)
  524msecdelay at the gateway
• Test results show an average RTT delay of 1.8
  sec, which may be attributed to the
  inter-satellite switching and delay at the gateway

Packets sent Packets received Loss RTT (sec) RTT (sec) RTT (sec) RTT (sec)
Packets sent Packets received Loss Avg Min Max mdev
50 50 0 1.835 1.347 4.127 0.798
100 100 0 1.785 1.448 4.056 0.573
100 100 0 2.067 1.313 6.255 1.272
200 200 0 1.815 1.333 6.228 0.809
21
Results Delay Measurement

• Random variation of delay
• High mean deviation
• Delay increases linearly with packet size
• Normalized delay is almost constant for MTU sizes
  gt 800 bytes
• Changing distance between the user and satellite
  as well as between satellites themselves (ISLs)
• Non-uniform traffic distribution, varying delays
  on different routes

• 56 100 200 300 500
  800 1000
  1200 1500

22
Results Throughput
Method 1 Modem 2 Modems 3 Modems 4 Modems
Iperf 2.1 4.0 7.0 9.6
Iperf 1.9 3.9 7.0 9.3
Iperf 1.7 4.5 6.8 9.7
Ttcp 2.29 4.43 6.6 8.9
Ttcp 2.48 4.40 7.0 8.78
Average 2.1 4.25 6.88 9.26

• Tools used TTCP, IPERF
• Throughput varies to some extend due to RTT
  variation
• Efficiency gt 90

Effective throughputs during large file transfers
File Size (MB) Upload Time (min) Throughput (bits/sec)
0.75 11 9091
3.2 60 7111
1.6 23 9275
2.3 45 6815
1.5 28 7143
2.5 35 9524
(K b p s)
23
Results Reliability 10th July 24 hr test
Call drops on the first modem
Total 13 Call drops
Uptime
80.6 91.8 94.7 96.8
Time interval between call drops (minutes) 146 106 114 50 25 84 89 8 7 7 17 11 137 618
24
Results Reliability 12th July 24 hr test
Call drops on the first modem
Total 16 Call drops
Uptime
80 92 95 96
Time interval between call drops (minutes) 135 248 93 40 26 16 8 211 108 91 8 5 6 5 8 7 386
25
Results TCP performance of a single link

• TCP Version TCP SACK
• Throughput of a segment is defined as the size of
  the segment seen divided by the time since the
  last segment was seen (in this direction).
• RTT is defined as the time difference between the
  instance a TCP segment is transmitted (by the TCP
  layer) and the instance an acknowledgement of
  that segment is received.
• The average throughput of the connection is
  2.45Kbps.
• The average RTT was found to be 20 seconds
• Bandwidth Delay Product (BDP) 240020/8 6000
  bytes 4 segments.
• Due to low throughput, the BDP is small.

Throughput vs. Time
-------- avg. of last 10 segments -------- avg.
of all the segments up to that point
RTT vs. Time
26
Results TCP performance of a 4-channel system

• The average throughput obtained - 9.4 Kbps
• The average RTT observed - 16.6 seconds
• Factors affecting throughput and RTT
• TCP Slow start
• MLPPP fragmentation
• Random delay variation
• TCP cumulative acknowledgments

Throughput vs. Time
-------- avg. of last 10 segments -------- avg.
of all the segments up to that point
RTT vs. Time
Time Sequence Graph
------- Received Acknowledgements ------- TCP
segments transmitted ------- Received window
advertisement
27
Results TCP performance of a 4-channel system
Time Sequence Graph

• Outstanding Unacknowledged data and Congestion
  window

Time Sequence Graph
Outstanding Unacknowledged Data
------- Received Acknowledgements ------- TCP
segments transmitted ------- Received window
advertisement
------- Instantaneous outstanding data
samples ------- Average outstanding data -------
Weighted average of outstanding data
28
Results TCP performance degradation due to
packet loss

• Low packet loss, long time experiments needed to
  determine the performance degradation
• Two packet losses were observed in the FTP video
  upload resulting in packet retransmissions
• Packet losses usually occur during call hand-offs
• Retransmission time outs (RTO) is very large due
  to high RTT and high mean deviation

Time Sequence Graph
Time Sequence Graph
Retransmitted packet
Retransmitted packet
29
Results TCP performance degradation due to
packet loss
RTT vs. Time

• Effect on the TCP performance due to packet loss
• Decrease in the throughput following the packet
  loss
• RTT peaks around the packet loss
• The average throughput of the connection is
  observed to be 7.44 Kbps.

Throughput vs. Time
Outstanding Unacknowledged Data
30
Results TCP performance degradation due to call
drop
Time Sequence Graph

• Packet loss due to a call drop on one links of
  the multilink bundle
• A finite amount of time for the data link layer
  realize the link has failed
• Large RTO timer
• The entire window of packets (12 in this case)
  and acknowledgements that are in flight on that
  particular link are dropped.
• Throughput of the connection 7.6 Kbps.

------- Received Acknowledgements ------- TCP
segments transmitted ------- Received window
advertisement
Outstanding Unacknowledged Data
Time Sequence Graph
------- Instantaneous outstanding data
samples ------- Average outstanding data -------
Weighted average of outstanding data
31
Results Mobile tests
Test Location
32
Results Mobile Performance
Throughput vs. Time
Avg. Throughput 9 Kbps
33
Results Mobile Performance (cont.d)
Throughput vs. Time
Avg. Throughput 9.34 Kbps
34
Applications Uploads and Downloads

• The following files were downloaded from WEB and
  ITTC network. The size of these files, their
  importance (on a scale of 1-10, based on user
  survey) are shown

Title Downloaded/uploaded Size Imp
1 Spectrum Analyzer programmers Manual Download from Agilent.com 7.2MB 9
2 Matlab Programs Download from ITTC 500KB 7
3 Voltage regulator data sheet Download from Fairchild.com 226KB 9
4 GPS software Download 800KB 9
5 Proposal submission Upload 600KB 8
6 Access point manager software Download from Orinoco.com 4.66MB 7
7 Drawing of machine spares to order Upload to University of Copenhagen 1MB 9
8 Video of core, datasheet Upload for press release 2MB 8
9 Pictures, press release of longest core in Greenland Upload to Kangerlussauq for press release 500KB 6
35
Applications Internet at camp
36
Applications WI-FI setup integrated with Iridium
37
Applications - Wireless Internet

• Wireless Internet access was used by many NGRIP
  researchers
• Email access put the researchers in touch with
  their home institutions
• Scientist at NGRIP were able to send information
  back to their home institutions

• The system was also useful for general camp
  purpose sending drawings to order spares for a
  broken caterpillar, excel spreadsheet for food
  order, general press releases, downloading
  weather reports for planning C-130 landings

38
Applications Outreach

• Daily journal logs were uploaded to the
  University of Kansas and posted on
  www.ku-prism.org
• Two way video conference was held twice to test
  the real time audio/video
• The system not only helped PRISM group to
  download critical software, but also made it
  possible to obtain faculty guidance and expertise
  on the field
• It also helped the researchers back at the
  University of Kansas to virtually view the field
  experiments since the video clips of experiments
  being carried out were also uploaded to the
  University and posted on project website

Testing Video conference between the camp and the
University
Uploading daily field logs
39
Lessons Learned

• Multi-link PPP is relatively efficient over
  Iridium system. With 4-modems efficiency was
  observed to be gt90
• The RTT the system is significant 1.8 seconds,
  which is an impairment to real time interactions
• There is a large (random) variation in delay of
  the system
• The average up-time of the overall connection is
  good gt 95
• Mobile tests showed performance very similar to
  that of stationary system up to speeds of 20mph
• A call drop on the first modem, results in a
  complete loss of connection, a potential bug in
  the PPP networking code could be fixed in newer
  version of the PPP software
• Strong interference from a nearby source on the
  same frequency (1.6GHz) could cause little
  disturbance in the system leading to either
  connection failures or call drops. This was
  observed when a radar sweeping between
  500MHz-2GHz with an output of 20dBm was placed
  at distance less than 15 meters

40
Conclusions

• In order to provide data and Internet access to
  Polar Regions, we have developed a reliable,
  easily scalable, lightweight, and readily
  available multi-channel data communication system
  based on Iridium satellites that provide round
  the clock, pole-to-pole coverage.
• A link management software is developed that
  ensures fully autonomous and reliable operation
• An end-to-end network architecture providing
  Internet access to science expeditions in Polar
  Regions is demonstrated.
• This system provided for the first time, Internet
  access to NGRIP camp at Greenland and obtained
  the call drop pattern.
• The TCP performance and the reliability of the
  system is characterized

41
Future Work

• Modify the MLPPP code so that the interface is
  attached to the bundle and not to the primary
  link
• Additional research to determine the cause of
  delay and develop methods to overcome it.
• Evaluate the new data-after-voice (DAV) service
  from Iridium
• Evaluate different versions of TCP to determine
  the enhancements that can handle the random
  variation and value of RTT
• Improve the user friendliness of the system
• GUI for connection setup
• Self-test / diagnostic tools for troubleshooting
• Research into the spacing and sharing of antennas
  to reduce the antenna footprint