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)
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
- Mainstream communication system for polar science expeditions, field camps in Arctic/Antarctic and other research purposes
- Government and security use
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.
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
Introduction - Iridium Satellite System 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
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.
Background - Iridium
Background - Inverse Multiplexing
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
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.
Multi-channel Iridium System – Protocol Stack
Multi-channel Iridium System – Network Architecture
4-Channel Iridium System Implementation
4-Channel System – Implemented at KU
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)
4-Channel System – Modem Flow Control
Field Tests and Results – Field implementation
Field Tests and Results – Antenna Setup
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
Results – Delay Measurement
Results – Reliability: 10th July 24 hr test
Results – Reliability: 12th July 24 hr test
Results – TCP performance of a single link
Results – TCP performance of a 4-channel system
Results – TCP performance of a 4-channel system
Results – TCP performance degradation due to packet loss
Results – TCP performance degradation due to packet loss
Results – TCP performance degradation due to call drop
Results – Mobile tests
Results – Mobile Performance
Results – Mobile Performance (cont.d)
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
Applications –WI-FI setup integrated with Iridium
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
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
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
Conclusions
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 Research into the spacing and sharing of antennas to reduce the antenna footprint
Dostları ilə paylaş: |