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

8/14/2019 Iridium Multiplexing and Inverse Multiplexing KU-NSF-Iridium-Experience-latest

1/41

University of Kansas

Multi-Link Iridium Satellite Data

Communication System

Overview, Performance and Reliabilityfrom Summer 2003 NGRIP, Greenland

Field ExperimentsJune 23-July 17, 2003

Abdul Jabbar Mohammad,Graduate Research AssistantDr.Victor Frost,Dan F . Servey Distinguished Professor(September 24, 2003)


2/41

University of Kansas2

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 scientificresearch 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/41


Introduction Commercial Satellite Systems

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

Intelsat

Inmarsat

Globalstar


4/41


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 limitedvisibility window at Poles typically

10-13 hrs/day.

High satellite altitude and low elevationangles (1-20) result in extremely large

field equipment. May not be readily available

20 m diameter Marisat and GOES antenna at South Pole


5/41


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 largeareas with fewer gateways

Since it was originally designed as a voice only system, it provides a lowdata rate of 2.4Kbps

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


6/41


Introduction Problem Statement

Problem Statement

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

access system providing true Polar coverage.

SolutionImplement a multi-link point-to-point Iridium communication system

to combine multiple satellite links to obtain a single logical channel

of aggregate bandwidth.


7/41


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/41


Background - Inverse Multiplexing

App 3

App 2

App 1

Mux

High Bandwidth Link

Multiplexing

App 1

Inv-Mux

Low Bandwidth Links

Traditional Multiplexing - Data from a multipleapplications/users sent over a single high bandwidth link.

Inverse Multiplexing - Data from a single application isfragmented and or distributed over multiple low

bandwidth links.

Increases the available bandwidth per applicationsignificantly

Multi-link point-to-point protocol (MLPPP), an extensionto 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/41


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, packetsize and MTU size

IP Packet

Modem i Modem 1 Modem 2 Modem 3 Modem 4

Not Fragmented Fragmented

IP Packet

IP PacketSH SH SH SH SHPDF PDF PDF PDF

SH-Segment header; PDF- packet data fragment


10/41


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 handlecall drops and system/power failures in remote field deployment.


11/41


Multi-channel Iridium System Protocol Stack

Application

HTTP, FTP, SSH

TCP

IP

PPP/MLPPP

Physical Modems

Application

HTTP, FTP, SSH

TCP

IP

PPP/MLPPP

Physical Modems

Remote System Local System

point-to-point satellite links


12/41


Multi-channel Iridium System Network Architecture

NGRIP Camp, Greenland

ITTC Network, University of Kansas

World Wide Web

User 2

User 3

User 1

ppp0eth0

PPP Server

ppp0 eth0

PPP Client

P-T-P Satellite link

ITTC Default Router

(Default gateway)(Default gateway)Guser 4

Guser 3

Guser 2

G`user 1Camp

WI-FI

100 Mbps

Ethernet

100 Mbps

Ethernet


13/41


4-Channel Iridium System Implementation

Iridium

Gateway

PSTN

USB-SERIAL

I. Modem 3

I. Modem 4

I. Modem 2

I. Modem 1 Antenna

Grid

Multi-port

PCI

card

Remote

System

PPP client

LocalSystem

PPP Server

Modem

Pool

Remote Subsystem

Local Subsystem


14/41


4-Channel System Implemented at KU


15/41


4-Channel System Implemented at KU


16/41


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, detectingfailures, reconnections, handling power failures/system resets, generating

status information (text)


17/41


4-Channel System Modem Flow Control

Check if any

modem isalive

MonitorStatus

OKFAILED

FAILConnectModem 2

OK

MonitorStatus

OKFAILED

FAILConnectModem 3

OK

MonitorStatus

OKFAILED

FAILConnectModem 4

OK

STARTConnectModem 1

Terminate

All

Monitor

Status

OK

FAIL

OK

FAIL

YES

NO


18/41


Field Tests and Results Field implementation

Dimensions: 24x19x5

Antenna

Connectors

USB Out

USB In

System withcontrol software


19/41


Field Tests and Results Antenna Setup

10 FT

3 FT


20/41


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 [email protected] = 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

Packets

sent

Packets

received

%

Loss

RTT (sec)

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/41


Results Delay Measurement

Random variation of delay

High mean deviation

Delay increases linearly withpacket size

Normalized delay is almost

constant for MTU sizes > 800

bytes

Changing distance between theuser 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/41


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 someextend due to RTT variation

Efficiency > 90%

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

Effective throughputs during large file transfers

(Kb

ps)


23/41


Results Reliability: 10th July 24 hr test

Time intervalbetween call drops

(minutes)

146 106 114 50 25 84 89 8 7 7 17 11 137 618

Total :

13 Call drops

80.6

91.8

94.7

96.8

Uptime %

Call drops on the first modem


24/41


Results Reliability: 12th July 24 hr test

Time interval

between call drops(minutes)

135 248 93 40 26 16 8 211 108 91 8 5 6 5 8 7 386

80

92

95

96

Uptime %

Total :

16 Call drops

Call drops on the first modem


25/41


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 betweenthe 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 is2.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.

-------- avg. of last 10 segments

-------- avg. of all the segments upto that point

Throughput vs. Time

RTT vs. Time


26/41


Results TCP performance of a 4-channel system

-------- avg. of last 10 segments

-------- avg. of all the segments upto that point

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

------- Received Acknowledgements

------- TCP segments transmitted

------- Received window advertisement

RTT vs. Time

Throughput vs. Time

Time Sequence Graph


27/41


Results TCP performance of a 4-channel system

------- Instantaneous outstanding data samples

------- Average outstanding data

------- Weighted average of outstanding data




Outstanding Unacknowledgeddata and Congestion window

Time Sequence Graph

Time Sequence Graph

Outstanding Unacknowledged Data


28/41


29/41


Results TCP performance degradation due to packet loss

Effect on the TCP performance due to packetloss

Decrease in the throughput following the packetloss

RTT peaks around the packet loss

The average throughput of the connection isobserved to be 7.44 Kbps.

Outstanding Unacknowledged DataThroughput vs. Time

RTT vs. Time


30/41


Results TCP performance degradation due to call drop

Packet loss due to a call drop on one links ofthe multilink bundle

A finite amount of time for the data link layerrealize 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.




------- Instantaneous outstanding data samples

------- Average outstanding data

------- Weighted average of outstanding data

Time Sequence Graph

Time Sequence Graph

Outstanding Unacknowledged Data


31/41


Results Mobile tests

Test Location


32/41


Results Mobile Performance

STOP

START

Avg. Throughput = 9 Kbps

Throughput vs. Time


33/41


Results Mobile Performance (cont.d)

START

STOP

Avg. Throughput = 9.34 Kbps

Throughput vs. Time


34/41


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/41


Applications Internet at camp


36/41


Applications WI-FI setup integrated with Iridium


37/41


Applications - Wireless Internet

Wireless Internet access was usedby many NGRIP researchers

Email access put the researchers intouch with their home institutions

Scientist at NGRIP were able tosend information back to their home

institutions

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


38/41


Applications Outreach

Daily journal logs were uploaded to the Universityof Kansas and posted on www.ku-prism.org

Two way video conference was held twice to testthe real time audio/video

The system not only helped PRISM group todownload critical software, but also made

it possible to obtain faculty guidance and expertise

on the field

It also helped the researchers back at theUniversity 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/41


Lessons Learned

Multi-link PPP is relatively efficient over Iridium system. With 4-modems efficiency was observed tobe >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 PPPnetworking 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 littledisturbance 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/41


Conclusions

In order to provide data and Internet access to Polar Regions, we have developed areliable, 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 reliableoperation

An end-to-end network architecture providing Internet access to science expeditions inPolar Regions is demonstrated.

This system provided for the first time, Internet access to NGRIP camp at Greenland andobtained the call drop pattern.

The TCP performance and the reliability of the system is characterized


41/41


Future Work

Modify the MLPPP code so that the interface is attached to the bundle and not to theprimary link

Additional research to determine the cause of delay and develop methods toovercome it.

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

Evaluate different versions of TCP to determine the enhancements that can handlethe 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

Documents

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