Presentation is loading. Please wait.

Presentation is loading. Please wait.

University of Kansas Multi-Link Iridium Satellite Data Communication System Overview, Performance and Reliability from Summer 2003 NGRIP, Greenland Field.

Similar presentations

Presentation on theme: "University of Kansas Multi-Link Iridium Satellite Data Communication System Overview, Performance and Reliability from Summer 2003 NGRIP, Greenland Field."— Presentation transcript:

1 University of Kansas 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 University of Kansas 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 University of Kansas 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. Intelsat Inmarsat Globalstar

4 University of Kansas 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-2 0 ) result in extremely large field equipment. May not be readily available 20 m diameter Marisat and GOES antenna at South Pole

5 University of Kansas 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 University of Kansas 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 University of Kansas 7 Background - Iridium Satellite TypeLEO Satellite altitude780 km Minimum elevation angle8.2 0 Average satellite view time9-10 minutes Access schemeFDMA and TDMA Maximum number of located users80 users in a radius of 318 km Theoretical throughput2.4 – 3.45 Kbps Type of data servicesIridium-to-Iridium, Iridium-to-PSTN

8 University of Kansas 8 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 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 (PDU’s) into smaller segments depending upon the PDU size, link MTUs and the number of available links. Inverse multiplexing

9 University of Kansas 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 IP Packet Modem i Modem 1 Modem 2Modem 3Modem 4 Not Fragmented Fragmented IP Packet SH PDF SH-Segment header; PDF- packet data fragment

10 University of Kansas 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 University of Kansas 11 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 SystemLocal System point-to-point satellite links

12 University of Kansas 12 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) Guser 4 Guser 3 Guser 2 G`user 1 Camp WI-FI 100 Mbps Ethernet

13 University of Kansas 13 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 Local System PPP Server Modem Pool Remote Subsystem Local Subsystem

14 University of Kansas 14 4-Channel System – Implemented at KU

15 University of Kansas 15 4-Channel System – Implemented at KU

16 University of Kansas 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 University of Kansas 17 4-Channel System – Modem Flow Control Check if any modem is alive Monitor Status OK FAILED FAIL Connect Modem 2 OK Monitor Status OK FAILED FAIL Connect Modem 3 OK Monitor Status OK FAILED FAIL Connect Modem 4 OK START Connect Modem 1 Terminate All Monitor Status OK FAIL OK FAIL YES NO

18 University of Kansas 18 Field Tests and Results – Field implementation Dimensions: 24x19x5 Antenna Connectors USB Out USB In System with control software

19 University of Kansas 19 Field Tests and Results – Antenna Setup 10 FT 3 FT

20 University of Kansas 20 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 Packet s sent Packets received % Loss RTT (sec) AvgMinMaxmdev 50 01.8351.3474.1270.798 100 01.7851.4484.0560.573 100 02.0671.3136.2551.272 200 01.8151.3336.2280.809

21 University of Kansas 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 > 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 University of Kansas 22 Results – Throughput Method1 Modem2 Modems3 Modems4 Modems Iperf2. Iperf1. Iperf1. Ttcp2.294.436.68.9 Ttcp2.484.407.08.78 Average2.14.256.889.26 Tools used – TTCP, IPERF Throughput varies to some extend due to RTT variation Efficiency > 90% File Size (MB) Upload Time (min) Throughput (bits/sec) 0.75119091 3.2607111 1.6239275 2.3456815 1.5287143 2.5359524 Effective throughputs during large file transfers (K b p s)

23 University of Kansas 23 Results – Reliability: 10 th July 24 hr test Time interval between call drops (minutes) 146106114502584898771711137618 Total : 13 Call drops 80.6 91.8 94.7 96.8 Uptime % Call drops on the first modem

24 University of Kansas 24 Results – Reliability: 12 th July 24 hr test Time interval between call drops (minutes) 13524893402616821110891856587386 80 92 95 96 Uptime % Total : 16 Call drops Call drops on the first modem

25 University of Kansas 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) = 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 up to that point Throughput vs. Time RTT vs. Time

26 University of Kansas 26 Results – TCP performance of a 4-channel system -------- avg. of last 10 segments -------- avg. of all the segments up to 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 University of Kansas 27 Results – TCP performance of a 4-channel system ------- Instantaneous outstanding data samples ------- Average outstanding data ------- Weighted average of outstanding data ------- Received Acknowledgements ------- TCP segments transmitted ------- Received window advertisement Outstanding Unacknowledged data and Congestion window Time Sequence Graph Outstanding Unacknowledged Data

28 University of Kansas 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 Retransmitted packet Time Sequence Graph

29 University of Kansas 29 Results – TCP performance degradation due to packet loss 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. Outstanding Unacknowledged Data Throughput vs. Time RTT vs. Time

30 University of Kansas 30 Results – TCP performance degradation due to call drop 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 ------- Instantaneous outstanding data samples ------- Average outstanding data ------- Weighted average of outstanding data Time Sequence Graph Outstanding Unacknowledged Data

31 University of Kansas 31 Results – Mobile tests Test Location

32 University of Kansas 32 Results – Mobile Performance STOP START Avg. Throughput = 9 Kbps Throughput vs. Time

33 University of Kansas 33 Results – Mobile Performance (cont.d) START STOP Avg. Throughput = 9.34 Kbps Throughput vs. Time

34 University of Kansas 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 TitleDownloaded/uploadedSizeImp 1Spectrum Analyzer programmers Manual Download from Agilent.com7.2MB9 2Matlab ProgramsDownload from ITTC500KB7 3Voltage regulator data sheetDownload from Fairchild.com226KB9 4GPS softwareDownload800KB9 5Proposal submissionUpload600KB8 6Access point manager softwareDownload from Orinoco.com4.66MB7 7Drawing of machine spares to order Upload to University of Copenhagen1MB9 8Video of core, datasheetUpload for press release2MB8 9Pictures, press release of longest core in Greenland Upload to Kangerlussauq for press release 500KB6

35 University of Kansas 35 Applications – Internet at camp

36 University of Kansas 36 Applications –WI-FI setup integrated with Iridium

37 University of Kansas 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 University of Kansas 38 Applications – Outreach  Daily journal logs were uploaded to the University of Kansas and posted on  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 University of Kansas 39 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

40 University of Kansas 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 University of Kansas 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

Download ppt "University of Kansas Multi-Link Iridium Satellite Data Communication System Overview, Performance and Reliability from Summer 2003 NGRIP, Greenland Field."

Similar presentations

Ads by Google