Multi-Link Iridium Satellite Data Communication System - PowerPoint PPT Presentation

About This Presentation
Title:

Multi-Link Iridium Satellite Data Communication System

Description:

Multi-Link Iridium Satellite Data Communication System Overview, Performance and Reliability from Summer 2003 NGRIP, Greenland Field Experiments – PowerPoint PPT presentation

Number of Views:197
Avg rating:3.0/5.0
Slides: 42
Provided by: abd794
Learn more at: http://www.ittc.ku.edu
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com