Iridium Multiplexing and Inverse Multiplexing KU-NSF-Iridium-Experience-latest

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)
University of Kansas
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
2
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 3
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

4
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
5
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.
6
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
7
Background - Inverse Multiplexing
  Traditional Multiplexing - Data from a multiple
applications/users sent over a single high bandwidth link. App 1
High Bandwidth Link
Mux
  Inverse Multiplexing - Data from a single application is App 2
fragmented and or distributed over multiple low
App 3
bandwidth links.
Multiplexing
  Increases the available bandwidth per application
significantly
  Multi-link point-to-point protocol (MLPPP), an extension Low Bandwidth Links

to the PPP is a packet based inverse multiplexing
Inv-Mux
solution App 1
  Overhead of 12 bytes
  Fragmentation of network layer protocol data units

(PDU’s) into smaller segments depending upon the PDU Inverse multiplexing
size, link MTUs and the number of available links.
8
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
Not Fragmented Fragmented
IP Packet IP Packet
SH IP Packet SH PDF SH PDF SH PDF SH PDF
Modem i Modem 1 Modem 2 Modem 3 Modem 4
SH-Segment header; PDF- packet data fragment

9
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.
10
Multi-channel Iridium System – Protocol Stack
Remote System Local System
Application Application
HTTP, FTP, SSH HTTP, FTP, SSH
TCP TCP
IP IP
PPP/MLPPP point-to-point satellite links PPP/MLPPP
Physical Modems Physical Modems
11
Multi-channel Iridium System – Network Architecture
World Wide Web

NGRIP Camp, Greenland
100 Mbps
Ethernet
(Default gateway) (Default gateway)
Guser 4
PPP Server PPP Client
ITTC Default Router
P-T-P Satellite link

eth0 ppp0 ppp0 eth0
User 2
100 Mbps
User 1
Ethernet Guser 3
User 3
Camp Guser 2
G`user 1
WI-FI
ITTC Network, University of Kansas
12
4-Channel Iridium System Implementation
Remote I. Modem 1
USB-SERIAL
Antenna
System I. Modem 2 Iridium
Grid
I. Modem 3 Gateway
PPP client
I. Modem 4
Remote Subsystem
Multi-port
Local
PCI card
Modem
System PSTN
Pool
PPP Server
Local Subsystem
13
4-Channel System – Implemented at KU
14
4-Channel System – Implemented at KU
15
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)
16
4-Channel System – Modem Flow Control
Check if any Connect

NO
START modem is
Modem 1 FAIL
alive
OK
YES
Terminate OK
Monitor
All
Status
FAIL
FAIL
Connect FAIL FAIL
Modem 2 Connect Connect
Modem 3 Modem 4
OK
OK OK
FAILED
OK
FAILED FAILED
Monitor OK OK
Status Monitor Monitor
Status Status
17
Field Tests and Results – Field implementation
System with
control software
USB In
USB Out
Antenna
Connectors
Dimensions: 24x19x5
18
Field Tests and Results – Antenna Setup
3 FT
10 FT
19
Results – Delay and Loss Measurement
  Ping tests between the two machines at the end of the of satellite link
  One way propagation delay = (800+8000+6000)Km / (3e6)Km/sec= 49msec

  Transmission time for 64 bytes@2.4Kbps = 64*8/2400=213msec
  Theoretically, the RTT delay =2*(49+213)= 524msec+delay 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
RTT (sec)
Packets Packets %
sent 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
20
Results – Delay Measurement
  Random variation of delay
  High mean deviation
  Delay increases linearly with

packet size
  Normalized delay is almost
constant for MTU sizes > 800
bytes
  Changing distance between the

user and satellite as well as
between satellites themselves
(ISLs)
  Non-uniform traffic distribution,

  56 100 200 300 500 800 1000 1200 1500
varying delays on different routes
21
Results – Throughput
Method 1 Modem 2 Modems 3 Modems 4 Modems
  Tools used – TTCP, IPERF Iperf 2.1 4.0 7.0 9.6

Iperf 1.9 3.9 7.0 9.3
  Throughput varies to some Iperf 1.7 4.5 6.8 9.7
extend due to RTT variation Ttcp 2.29 4.43 6.6 8.9
Ttcp 2.48 4.40 7.0 8.78
  Efficiency > 90%
Average 2.1 4.25 6.88 9.26
Effective throughputs during large file transfers
Upload Time Throughput

File Size (MB)
(K b p s)
(min) (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
22
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 146 106 114 50 25 84 89 8 7 7 17 11 137 618
(minutes)
23
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 135 248 93 40 26 16 8 211 108 91 8 5 6 5 8 7 386
(minutes)
24
Results – TCP performance of a single link
Throughput vs. Time
  TCP Version – TCP SACK -------- avg. of last 10 segments
-------- avg. of all the segments up
  Throughput of a segment is defined as the size to that point
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.
RTT vs. Time
  The average throughput of the connection is
2.45Kbps.
  The average RTT was found to be 20 seconds
  Bandwidth Delay Product (BDP) = 2400*20/8 =

6000 bytes = 4 segments.
  Due to low throughput, the BDP is small.
25
Results – TCP performance of a 4-channel system
Throughput vs. Time
  The average throughput obtained - 9.4 Kbps -------- avg. of last 10 segments
-------- avg. of all the segments up
  The average RTT observed - 16.6 seconds to that point
  Factors affecting throughput and RTT
  TCP Slow start
  MLPPP fragmentation
  Random delay variation
  TCP cumulative acknowledgments

Time Sequence Graph RTT vs. Time
------- Received Acknowledgements

------- TCP segments transmitted
------- Received window advertisement
26
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 ------- Instantaneous outstanding data samples

------- TCP segments transmitted ------- Average outstanding data
------- Received window advertisement ------- Weighted average of outstanding data
27
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
28
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
29
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 ------- Received Acknowledgements
that particular link are dropped. ------- TCP segments transmitted
------- Received window advertisement
  Throughput of the connection – 7.6 Kbps.
Time Sequence Graph
------- Instantaneous outstanding data samples

------- Average outstanding data
------- Weighted average of outstanding data
30
Results – Mobile tests
Test Location
31
Results – Mobile Performance
START
Throughput vs. Time
STOP
Avg. Throughput = 9 Kbps
32
Results – Mobile Performance (cont.d)
START
Throughput vs. Time
STOP
Avg. Throughput = 9.34 Kbps
33
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 Download from Agilent.com 7.2MB 9
Manual
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 Upload to University of Copenhagen 1MB 9

order
8 Video of core, datasheet Upload for press release 2MB 8
9 Pictures, press release of longest Upload to Kangerlussauq for press 500KB 6

core in Greenland release
34
Applications – Internet at camp
35
Applications –WI-FI setup integrated with Iridium
36
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
37
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
Testing Video conference between the camp and the University
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
Uploading daily field logs

38
Lessons Learned
  Multi-link PPP is relatively efficient over Iridium system. With 4-modems efficiency was observed to
be >90%
  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 > 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
39
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
40
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
41

Iridium Multiplexing and Inverse Multiplexing KU-NSF-Iridium-Experience-latest

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Iridium Multiplexing and Inverse Multiplexing KU-NSF-Iridium-Experience-latest

Hochgeladen von

Copyright:

Verfügbare Formate

Multi-Link Iridium Satellite Data

Overview, Performance and Reliability

 Generic data communication for Remote field research

 Government and security use

 NASA satellites like ATS3, LES9,

 Geo-synchronous, they have a limited

 May not be readily available

20 m diameter Marisat and GOES antenna at South Pole

 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

 Since it was originally designed as a voice only system, it provides a low

 Not practical to be used as a main stream/ life-line communication system

A reliable, lightweight, portable and easily scalable data/Internet

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

 Multi-link point-to-point protocol (MLPPP), an extension Low Bandwidth Links

 Fragmentation of network layer protocol data units

 Layer 2 protocol that implements inverse multiplexing on a packet by packet basis

Not Fragmented Fragmented

SH IP Packet SH PDF SH PDF SH PDF SH PDF

Modem i Modem 1 Modem 2 Modem 3 Modem 4

SH-Segment header; PDF- packet data fragment

The design requirements of the system are as follows.

 The multi-channel implementation should maximize the throughput.

Remote System Local System

HTTP, FTP, SSH HTTP, FTP, SSH

PPP/MLPPP point-to-point satellite links PPP/MLPPP

Physical Modems Physical Modems

World Wide Web

P-T-P Satellite link

ITTC Network, University of Kansas

 Linux based system

Check if any Connect

 One way propagation delay = (800+8000+6000)Km / (3e6)Km/sec= 49msec

 Theoretically, the RTT delay =2*(49+213)= 524msec+delay at the gateway

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

 High mean deviation

 Delay increases linearly with

 Changing distance between the

 Non-uniform traffic distribution,

varying delays on different routes

 Tools used – TTCP, IPERF Iperf 2.1 4.0 7.0 9.6

Upload Time Throughput

Call drops on the first modem

of the segment seen divided by the time since

 RTT is defined as the time difference between

 The average RTT was found to be 20 seconds

 Bandwidth Delay Product (BDP) = 2400*20/8 =

 Due to low throughput, the BDP is small.

 Factors affecting throughput and RTT

 TCP Slow start

 TCP cumulative acknowledgments

------- Received Acknowledgements

Time Sequence Graph

  Generic data communication for Remote field research

  Government and security use

  NASA satellites like ATS3, LES9,

  Geo-synchronous, they have a limited

  May not be readily available

  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

  Since it was originally designed as a voice only system, it provides a low

  Not practical to be used as a main stream/ life-line communication system

  Multi-link point-to-point protocol (MLPPP), an extension Low Bandwidth Links

  Fragmentation of network layer protocol data units

  Layer 2 protocol that implements inverse multiplexing on a packet by packet basis

  The multi-channel implementation should maximize the throughput.

  Linux based system

  One way propagation delay = (800+8000+6000)Km / (3e6)Km/sec= 49msec

  Theoretically, the RTT delay =2*(49+213)= 524msec+delay at the gateway

  High mean deviation

  Delay increases linearly with

  Changing distance between the

  Non-uniform traffic distribution,

  Tools used – TTCP, IPERF Iperf 2.1 4.0 7.0 9.6

  RTT is defined as the time difference between

  The average RTT was found to be 20 seconds

  Bandwidth Delay Product (BDP) = 2400*20/8 =

  Due to low throughput, the BDP is small.

  Factors affecting throughput and RTT

  TCP Slow start

  TCP cumulative acknowledgments

  Packet losses usually occur during call hand-offs

  Decrease in the throughput following the packet

  RTT peaks around the packet loss

  The average throughput of the connection is

  Wireless Internet access was used

  Email access put the researchers in

  Scientist at NGRIP were able to

  Daily journal logs were uploaded to the University

  Two way video conference was held twice to test

  The system not only helped PRISM group to

  It also helped the researchers back at the

  There is a large (random) variation in delay of the system

  The average up-time of the overall connection is good > 95%

  An end-to-end network architecture providing Internet access to science expeditions in

  The TCP performance and the reliability of the system is characterized

  Additional research to determine the cause of delay and develop methods to

  Evaluate the new data-after-voice (DAV) service from Iridium

  Improve the user friendliness of the system

  GUI for connection setup