William D. Ivancic

Glenn Research Center, Cleveland, Ohio

David E. Stewart

Verizon Federal Systems, Cleveland, Ohio

Donald V. Sullivan and Patrick E. Finch

Ames Research Center, Moffett Field, California

An Evaluation of Protocols for

UAV Science Applications

NASA/TM—2012-217276

April 2012
NASA STI Program . . . in Profi le

Since its founding, NASA has been dedicated to the 

advancement of aeronautics and space science. The 

NASA Scientifi c and Technical Information (STI) 

program plays a key part in helping NASA maintain 

this important role.

The NASA STI Program operates under the auspices 

of the Agency Chief Information Offi cer. It collects, 

organizes, provides for archiving, and disseminates 

NASA’s STI. The NASA STI program provides access 

to the NASA Aeronautics and Space Database and 

its public interface, the NASA Technical Reports 

Server, thus providing one of the largest collections 

of aeronautical and space science STI in the world. 

Results are published in both non-NASA channels 

and by NASA in the NASA STI Report Series, which 

includes the following report types:

• TECHNICAL PUBLICATION. Reports of 

completed research or a major signifi cant phase 

of research that present the results of NASA 

programs and include extensive data or theoretical 

analysis. Includes compilations of signifi cant 

scientifi c and technical data and information 

deemed to be of continuing reference value. 

NASA counterpart of peer-reviewed formal 

professional papers but has less stringent 

limitations on manuscript length and extent of 

graphic presentations.

• TECHNICAL MEMORANDUM. Scientifi c 

and technical fi ndings that are preliminary or 

of specialized interest, e.g., quick release 

reports, working papers, and bibliographies that 

contain minimal annotation. Does not contain 

extensive analysis.

• CONTRACTOR REPORT. Scientifi c and 

technical fi ndings by NASA-sponsored 

contractors and grantees.

• CONFERENCE PUBLICATION. Collected 

papers from scientifi c and technical 

conferences, symposia, seminars, or other 

meetings sponsored or cosponsored by NASA.

• SPECIAL PUBLICATION. Scientifi c, 

technical, or historical information from 

NASA programs, projects, and missions, often 

concerned with subjects having substantial 

public interest.

• TECHNICAL TRANSLATION. Englishlanguage translations of foreign scientifi c and 

technical material pertinent to NASA’s mission.

Specialized services also include creating custom 

thesauri, building customized databases, organizing 

and publishing research results.

For more information about the NASA STI 

program, see the following:

• Access the NASA STI program home page at 

http://www.sti.nasa.gov

• E-mail your question via the Internet to help@

sti.nasa.gov

• Fax your question to the NASA STI Help Desk 

at 443–757–5803

• Telephone the NASA STI Help Desk at

 443–757–5802

• Write to:

 NASA Center for AeroSpace Information (CASI)

 7115 Standard Drive

 Hanover, MD 21076–1320
William D. Ivancic

Glenn Research Center, Cleveland, Ohio

David E. Stewart

Verizon Federal Systems, Cleveland, Ohio

Donald V. Sullivan and Patrick E. Finch

Ames Research Center, Moffett Field, California

An Evaluation of Protocols for

UAV Science Applications

NASA/TM—2012-217276

April 2012

National Aeronautics and

Space Administration

Glenn Research Center

Cleveland, Ohio 44135

Prepared for the

2011 Earth Science Technology Forum (ESTF2011)

sponsored by the NASA Earth Science Technology Offi ce (ESTO)

Pasadena, California, June 21–23, 2011
Available from

NASA Center for Aerospace Information

7115 Standard Drive

Hanover, MD 21076–1320

National Technical Information Service

5301 Shawnee Road

Alexandria, VA 22312

Available electronically at http://www.sti.nasa.gov

Trade names and trademarks are used in this report for identifi cation 

only. Their usage does not constitute an offi cial endorsement, 

either expressed or implied, by the National Aeronautics and 

Space Administration.

Level of Review: This material has been technically reviewed by technical management. 
NASA/TM—2012-217276 1 

An Evaluation of Protocols for UAV Science Applications 

William D. Ivancic 

National Aeronautics and Space Administration 

Glenn Research Center 

Cleveland, Ohio 44135 

David E. Stewart 

Verizon Federal Systems 

Cleveland, Ohio 44135 

Donald V. Sullivan and Patrick E. Finch 

National Aeronautics and Space Administration 

Ames Research Center 

Moffett Field, California 94035 

Abstract 

This paper identifies data transport needs for current and 

future science payloads deployed on the NASA Global Hawk 

Unmanned Aeronautical Vehicle (UAV). The NASA Global 

Hawk communication system and operational constrains are 

presented. The Genesis and Rapid Intensification Processes 

(GRIP) mission is used to provide the baseline communication 

requirements as a variety of payloads were utilized in this 

mission. User needs and desires are addressed. Protocols are 

matched to the payload needs and an evaluation of various 

techniques and tradeoffs are presented. Such techniques 

include utilization rate-base selective negative acknowledgement protocols and possible use of protocol enhancing 

proxies. Tradeoffs of communication architectures that 

address ease-of-use and security considerations are also 

presented. 

Background 

NASA has acquired two Global Hawk Unmanned Aerial 

Vehicles (UAVs) to enhance upper atmospheric science in 

support of the Earth Science Project Office (ESPO). There is a 

potential to acquire an additional 3 to 5 Global Hawks 

resulting in a fleet of 5 to 7 aircraft. The Global Hawks 

currently reside at the Dryden Research Center (DRC). DRC 

is located on Edwards Air Force Base. Edward’s has one of 

the largest military “special use” areas in the United States 

covering almost 16,000 square miles. “Special Use” airspace 

is required to get the Global Hawks from ground to 

evaluations above commercial air traffic. 

The Global Hawk has a maximum endurance of 42 hr with 

an on-station endurance of 24 hr at 3,000 Nm from point of 

departure. It can loiter at 343 knots and has a maximum 

altitude of 65,000 ft, which is above the weather and above the 

commercial air space. Such capabilities allow the Global 

Hawk to take unique measurements at a fixed area over a full 

solar day. As such, the Global Hawk measurements are 

complimentary to satellite data. 

Communication Architecture 

Security 

For the NASA operated Global Hawks, the aircraft 

operation’s command and control communications is 

completely separate from the experimental payloads’ 

command and control. This enables different security 

methodologies to be deployed for each system. Aircraft 

control is critical for safety of flight and safety of life. 

Furthermore, hijacking a UAV basically puts a missile in the 

hands of the hijacker. By separating the command of the 

payload from the command of the aircraft, the security 

required for payload operations becomes much less stringent 

and enables greater flexibility of payload deployment and 

direct real-time access to payload instrumentation by the 

various principle investigators. 

To date, securing the payload has been accomplished using 

standard computer access techniques. User accounts are 

established for each Principal Investigator that needs payload 

access. Login is via Secure Shell (SSH) or telnet. There is 

currently no requirement in the payload communication chain 

to secure the RF link or for network layer security, Internet 

Protocol Security (IPsec). If network layer security is required 

in future missions, IPsec could be easily enabled. 

Satellite Communications 

Communication with the experimental payload is by a KuBand satellite link. Initial deployments used a 2 Mbps 

bidirectional link. Future flights are expected to use up to 

8 Mbps links. The system is capable of approximately 

50 Mbps but the cost to operate at such rates is prohibitive. 

Furthermore, there currently is not a requirement to move the 

volume of data that would require a 50 Mbps link although 

there may be in the future. 

During the Global Hawk Pacific (GloPac) mission, KuBand connectivity was demonstrated to approximately 75° 

north latitude (approximated 3° elevation angle). Thus, any 
NASA/TM—2012-217276 2 

missions with flight profiles below 75° (north or south) have 

continuous connectivity. 

In addition to the Ku-band satellite link, four Iridium LBand modems have been multiplexed together to provide 

some low-rate (kbps) communication to the experimental 

payloads for simple commanding and status (telemetry). 

Deployment Scenarios 

The vast majority of payload communication and control 

available to the principle investigators is via the Ku-band 

satellite links. The Ku-band satellite links are the only links 

with sufficient bandwidth to warrant any protocol related data 

transport optimization. Therefore, the remainder of this paper 

will only be concerned with high-bandwidth geostationary 

satellite links when considering communication between the 

Global Hawk payloads and the Principle Investigators. 

Figures 1(a), (b), and (c) illustrate three possible 

deployment scenarios for Ku-Band satellite communication. 

Figure 1(a) is the current communication deployment. A Kuband terminal is located at Dryden Research Center (DRC) 

with a fiber optic run between the ground station and the 

control center. Communication from PI to Payload is 

effectively a direct link resulting in a single communication 

control loop. This was the scenario used in the GloPac and 

Genesis and Rapid Intensification Processes (GRIP) missions. 

For GloPac, RF communication over the Ku-band link was 

lost over the North Pole region at which point only Iridium 

links could be use to check payload status. No large volumes 

of data could be downloaded through the Iridium links due to 

extremely small bandwidths. For GRIP, RF communication 

over the Ku-band link was continuous as the mission was over 

the tropics with the satellite in constant contact with the 

Global Hawk. 

The only difference between scenario 1(a) and (b) is that a 

transportable ground station will be deployed in close enough 

proximity to the mission rendezvous point to enable constant 

contact between the Global Hawk, the Ku-band satellite and 

the transportable ground station. Since the Principle 

Investigators will be collocated at the transportable ground 

station site, the optimal communication protocol choice is 

identical for scenarios 1(a) and (b). 

Future deployments may utilize the scenario presented in 

Figure 1(c). There is even a possibility that such a scenario 

may be used for the Earth Venture Mission—Hurricane and 

Severe Storm Sentinel (HS3) campaign (Ref. 1). Here, the RF 

modem and networking equipment would be located at the 

remote ground station with the Principle Investigators located 

at, and performing operations from DRC. In such a scenario, 

two major architectural deployments are possible. The first 

architecture would have the initial mission data-storage taking 

place directly at the ground station. In this case, there is only 

one control loop and everything is identical to scenarios 1(a) 

and (b). The PIs could login to the remote data storage 

computer to execute payload commanding. The second 

architecture would have the initial mission data storage at 

DRC. That would result in either a single long control loop 

over both the space/ground link and the ground/ground link or 

a situation where one would break the control loops between 

the space/ground link and the ground/ground link. The latter 

would lend itself to deployment of store and forward 

techniques such as delay tolerant networking (DTN), a 

network overlay, or other much simpler store and forward 

techniques. 

Communication Network Characteristics 

In all three scenarios, there is a single ground station and a 

single communication path from PI to payload. Therefore, 

from a networking perspective, the Global Hawk is stationary 

and solutions to address network mobility are not required. 

The Ku-band geostationary satellites have approximately 

500 ms of route trip time (RTT) delay. Allowing for additional 

processing and queuing may result in up to 600 ms of RTT 

delay. 

The current modems and antennas used on the Global 

Hawks provide near-error-free links—particularly at the data 

rates used (less than 10 Mbps). 

Figure 1(a).—Current communication deployment. 

Figure 1(b).—Venture mission (Atlantic Campaign). 

Figure 1(c).—Future deployment possibilities. 
NASA/TM—2012-217276 3 

Requirements 

Protocol Requirements 

The primary requirement of the protocols is to provide a 

good user experience while remaining as indistinguishable as 

possible from existing Internet protocols. Part of a good user 

experience is getting the required science data down in a 

timely manner. This has to be done while operating over nearerror-free links with 600 ms RTT delays. 

User Requirements 

The users of this system are the scientists (i.e., the Principal 

Investigators and their collaborators). This group is interested 

in ease of use and maximum delivery of science data. Their 

preference is to use as many existing Internet protocols as 

possible. Doing so allows the scientists to test their 

instruments and data collecting in the lab, on the ground, and 

in flight using the same protocols, commands, and scripts. The 

PIs desire to use the exact same Internet tools used in the lab 

while operating on the DC-8 research aircraft or while 

controlling instrumentation onboard the Global Hawk. Note: 

on the DC-8 the scientist is collocated with the payload 

effectively making the RTT delay a few milliseconds, 

whereas, when controlling instrumentation on the Global 

Hawk, the RTT is approximately 600 ms. 

The protocols currently used are all based on the 

Transmission Control Protocol (TCP). They include: Telnet, 

Secure Shell (SSH), and file transfer protocols (i.e., File 

Transfer Protocol (FTP), Secure Copy Protocol (SCP), Secure 

File Transfer Protocol (SFTP), RSYNC, WGET, etc.). Often 

the file transfer protocols are run in an SSH tunnel. 

Research Data Requirements 

The Lightning Instrumentation Package (LIP) measures 

lightning, electric fields, electric field changes, and air 

conductivity. The amount of data produce is relatively small. 

The data throughput requirement is kbps. Such low telemetry 

needs can be met by Iridium. 

The High Altitude MMIC Sounding Radiometer (HAMSR) 

was developed by JPL. It operates using 25 spectral channels 

in 3 bands and provides measurements that can be used to 

infer the 3-D distribution of temperature, water vapor, and 

cloud liquid water in the atmosphere. The data requirements 

are approximately 200 Mb over duration of mission (24 hr) 

with instantaneous throughputs of 10 to 100 s of kbps. The 

current system uses RSYNC over TCP to synchronize the 

ground database with payload database. RSYNC is run 

periodically during periods when the Global Hawk is in 

contact with the ground station. This is a very simple and 

effective store and forward technique that works well for the 

operational scenarios presented. Telnet or SSH are used to 

login and periodically check the instrument status. 

The High-Altitude Imaging Wind and Rain Airborne 

Profiler (HIWRAP) is a dual-frequency radar (Ka- and Kuband), dual-beam (300 and 400 incidence angle), conical scan, 

solid-state transmitter-based system, designed for operation on 

the high-altitude (20 km). By combining measurements at Kuand Ka-band, HIWRAP is able to image winds by measuring 

volume backscattering from clouds and precipitation. 

Operators use telnet or SSH to check payload status. 

For the GRIP flights, the digital receiver was functioning 

and obtaining raw data by recording in-phase and quadraturephase (I and Q) of the return signal. This resulted in a data rate 

of about 1 GB per minute (approximately 130 Mbps), which 

exceeds the available links even at continuous operation. A 

1 TB disk was filled during flight. This data was then 

offloaded after the Global Hawk landed. During GRIP, there 

was no processing that averaged, compressed, and produced 

science parameters. By deploying such onboard processing on 

future flights, the data-rate should be reduced by a factor of 

about 15, or 66 Mb per minute (8.8 Mbps link requirement). 

Another approach being considered is to produce real-time 

data products by using FPGA-based processing. Quicklook 

products such as images would be produced rather than 

sending back raw data. These techniques would greatly reduce 

the data downlink requirements to well within the current 

bandwidth of the Ku-band communication system. 

Transport Protocols 

TCP vs. UDP Rate-Based 

There are two basic types of transport protocols: the 

Transmission Control Protocol (TCP) and transmission 

protocols built at the application layer using the User 

Datagram Protocol (UDP) as the network transport 

mechanism. 

TCP Operations 

Most Internet applications use TCP as the underlying 

transport protocol. TCP is a reliable transport protocol built 

into the kernel of computer operating systems. It guarantees 

reliable, ordered delivery of a stream of bytes from a program 

on one computer to another program on another. TCP is 

designed to operate over shared networks. It includes flow 

control and congestion control algorithms that work well in 

the terrestrial Internet. The congestion control algorithm 

design is such that operation over noisy and long delay links is 

problematic. TCP will guarantee data delivery, but the link 

will not be used efficiently as TCP assumes any loss to be 

caused by congestion. 

TCP initially aggressively probes the network via an 

exponential increase in data-rate. TCP will double its data-rate 

each round trip time (RTT) by doubling the amount of packets 

sent (e.g., 4, 8, 16, 33) until it senses network congestion. As 

soon as TCP senses a packet loss (network congestion), it cuts 
NASA/TM—2012-217276 4 

Figure 2.—TCP vs. UDP rate-base performance. 

its data-rate in half and then conservatively probes the network 

by increasing its transmission rate one packet per round trip 

time (RTT). This conservative probing is called “linear 

increase”. This combination of algorithms is excellent for a 

shared network and relatively low delays. However, for a 

private link where no congestion is present and where errors 

may be present, these algorithms have problems reaching and 

maintaining maximum link capacity. Furthermore, unless one 

manually tunes the flow control sliding-window parameters, 

TCP will eventually self-congest and cut its data-rate in half 

resulting in the saw-tooth transmission pattern illustrated in 

Figure 2. Note: tuning protocols is non-trivial. 

UDP Rate-Base Operations 

UDP rate-base protocols operate at line-rate or at some set 

rate-limit. How one determines the rate-limit is deployment 

and implementation specific. UDP rate-based protocols 

generally assume no congestion and thus deploy no congestion 

control algorithms. Thus there is no need to probe the system 

to determine available bandwidth or to reduce data-rates when 

losses occur as all losses are assumed to be due to errors rather 

than congestion. UDP-based transport protocols utilize a 

negative acknowledgement algorithm (NACK) to notify the 

sender when errors occur. Here, the receiver explicitly notifies 

the sender of which packets, messages, or segments were 

received incorrectly and thus may need to be retransmitted. 

Figure 2 illustrates that UDP-based transport protocols provide 

throughput near the line-rate of the transmission media (minus 

the protocol overhead). Figure 3 shows the throughput of a 

rate-base NACK protocol verses TCP for large file transfers. 

This graph is for a packet size of 1024 B and assumes a 

binomial error distribution. The TCP portion of the graph is 

derived from a well-documented TCP performance equation 

(Ref. 2). Note: data throughput for a rate-based protocol is 

independent of propagation delay (RTT) whereas TCP 

performance is heavily affected by RTT. 

A non-comprehensive list of UDP-based transport protocols 

includes: Saratoga, Negative Acknowledgement (NACK) - 

Oriented Reliable Multicast (NORM), Licklider Transmission 

Figure 3.—Theoretical throughput of TCP vs. rate-based 

protocols for 1024 B packets. 

Protocol (LTP), and the Consultative Committee for Space 

Data Systems (CCSDS) File Delivery Protocol (CFDP). All of 

these use a selective, negative acknowledgment mechanism 

for transport reliability. 

“Saratoga is a simple, lightweight, content dissemination 

protocol that builds on UDP, and optionally uses UDP-Lite. 

Saratoga is intended for use when moving files or streaming 

data between peers, which may have permanent, sporadic or 

intermittent connectivity, and is capable of transferring very 

large amounts of data reliably under adverse conditions.” 

Surrey Satellite Technology Limited (SSTL) originally 

implemented Saratoga to efficiently transfer remote-sensing 

image from a low-Earth-orbiting satellite to ground over 

highly asymmetric links. It has been used in SSTL’s Disaster 

Monitoring Constellation satellites since 2004 (Ref. 3). 

“Saratoga also has a beacon that can be activated. The 

beacon is used to announce the presence of the node to 

potential peers (e.g., satellites, ground stations) as well as to 

provide automatic service discovery, and to confirm the 

activity or presence of the peer.” 

“The primary design goals of NORM are to provide 

efficient, scalable, and robust bulk data (e.g., computer files, 

transmission of persistent data) transfer across possibly 

heterogeneous IP networks and topologies. The NORM 

protocol design provides support for distributed multicast 

session participation with minimal coordination among 

senders and receivers. NORM allows senders and receivers to 

dynamically join and leave multicast sessions at will.” NORM 

leverages the use of forward error correction (FEC) repair and 

other IETF Reliable Multicast Transport (RMT) building 

blocks. NORM also has a congestion control scheme to fairly 

share available network bandwidth with other transport 

protocols such as TCP (Ref. 4). In addition, NORM can 

operate in unicast mode as had been demonstrated on the 

Naval Research Lab’s MidStar-1 Satellite for unidirectional 

link file transfer (Ref. 5). 

“LTP and CFDP are designed to provide retransmissionbased reliability over links characterized by extremely long 

message round-trip times (RTTs) and/or frequent interruptions 

in connectivity such as found in deep-space communications.” 
NASA/TM—2012-217276 5 

LTP and CFDP are based in part on a notion of massive state 

retention, which is necessary over extremely long delays in 

order to keep track of acknowledgments for data sent. LPT 

and CFDP have retransmission timers that must be suspended 

during periods of disconnection. This can be done either via 

per-configuration on know link outages due to orbital 

dynamics and/or by passing information on the link status to 

the LTP protocol engine (link state queues) (Refs. 6, 7, and 8). 

NORM, LTP, and CFDP are rather complex protocols with 

capabilities that are not required in the Global Hawk payload 

system. NORM is intended for multicast enabled systems and 

large groups of receivers. In addition, NORM has FEC 

capability that is not necessary for our near-error-free 

communication links. LTP and CFDP are designed for 

extremely long delays and disconnection – neither which are 

found in our communication system. LTP and CFDP also 

require configuration of many parameters in order to tune the 

protocol to the particular environment it is being used in. 

Saratoga has its roots in CFDP and is actually a scaled-down, 

simplified version of CFDP. We anticipate Saratoga to be the 

protocol of choice for large file transfers due to its simplicity, 

ease of use, and built-in discovery features. 

Protocol Enhancing Proxies 

Protocol Enhancing Proxies (PEPs) are used to improve 

TCP performance over long delays. The basic idea is to break 

the end-to-end control loop into multiple control loops such 

that one can utilize a protocol that performs well over longdelay, error prone links without modifications to the end users 

system (protocols). In this manner, the end users can use 

standard TCP-based Internet protocols without experiencing 

performance degradations. However, PEPs have known 

problems. They require a reasonable amount of additional 

processing, often require special configuration and tuning – 

particularly with regard to the available bandwidth and RTT 

delay – and require special care in deployment when used in 

conjunction with IPsec (Ref. 9). 

In the case of the Global Hawk, the delay is approximately 

600 ms with near-error-free performance. The PEP would 

utilize a rate-base protocol between the ground station and 

Global Hawk (control loop 2) while standard TCP would be 

run at on the Principal Investigators’ systems and on the 

Payload Control system (control loops 1 and 3) (Fig. 4). 

By deploying PEPs, one should expect improvements in 

large file transfers assuming standard File Transfer Protocol 

(FTP) or Secure Copy Protocol (SCP) are used. Such data 

delivery improvements should be comparable to UDP ratebased file transfer protocols such as Saratoga or NORM. For 

very small files or command and control messages, one should 

experience very little improvement, with a PEP compared to 

having no PEP in the system. Note: PEPs will not help 

interactive communications, as PEPs cannot remove the 

propagation delay. 

Figure 4.—Protocol enhancing proxy deployments. 

Conclusions 

During the GloPac and GRIP missions, the Global Hawk 

payloads were directly accessible to the Principle Investigators 

using standard Internet protocols with no PEPs deployed. The 

user experience was positive even without PEPs. This is 

primarily because the users only accessed their payloads to 

obtain status or to configure their systems. Such 

communication requires very small file transfers or simple 

message exchanges. Larger file transfers for GRIP and GloPac 

were performed in the background using RSYNCH for remote 

synchronization. As such, any TCP inefficiencies were not 

apparent to the user. 

In the future deployments, real-time delivery of larger data 

will be required and efficient use of the communication links 

will be necessary. At that time, either PEPs or an efficient, 

rate-based protocol such as Saratoga or both will be installed 

depending on the performance needs are architectural 

deployment.1

 Use of only a rate-based protocol is preferred 

over deployment of PEPs in order to keep the communication 

system as simple as possible. 

References 

1. “Hurricane and Severe Storm Sentinel,” Earth System 

Science Pathfinder Mission 

http://science.nasa.gov/missions/hs3/ 

2. Mathis, M. et al., “The Macroscopic Behavior of the 

Congestion Avoidance Algorithm,” Computer 

Communications Review, volume 27, number 3, July 

1997. 

3. L. Wood, W. Eddy, C. Smith, W. Ivancic, C. Jackson: 

“Saratoga: A Scalable File Transfer Protocol,” draftwood-tsvwg-saratoga-08, December 23, 2010 (Work in 

Progress). 

4. C. Bormann, M. Handley, J. Macker: “Naval Research 

Laboratory NACK-Oriented Reliable Multicast (NORM) 

Transport Protocol,” IETF RFC 5740, November 2009. 

5. K. Hogie, “NORM with requeue now operational on 

MidSTAR-1,” email to IETF norm-dev mail list, 

December 17, 2008. 

http://pf.itd.nrl.navy.mil/pipermail/norm-dev/2008-

December/000554.html 

1

 At the time of publication, performance tests were being performed to 

evaluate the CCSDS Space Communication Protocol Suit (SCPS) PEP 

relative to UDP-based file transfer protocols. The results of that testing are 

expected for be formally published in a follow-on document. 
NASA/TM—2012-217276 6 

6. S. Burleigh et al., Licklider Transmission Protocol - 

Motivation, IETF RFC 5325, informational September 

2008. 

7. M. Ramadas et al., Licklider Transmission Protocol - 

Specification, IETF RFC 5326, experimental, September 

2008. 

8. CCSDS File Delivery Protocol, Issue 2, CCSDS 727.0-B2, October 2002. 

9. J. Border, M. Kojo, J. Griner, G. Montenegro, Z. Shelby: 

“Performance Enhancing Proxies Intended to Mitigate 

Link-Related Degradations,” IETF RFC 3135, June 2001. 
REPORT DOCUMENTATION PAGE Form Approved 

OMB No. 0704-0188 

The public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the 

data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this 

burden, to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302. 

Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB 

control number. 

PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS. 

1. REPORT DATE (DD-MM-YYYY)

01-04-2012 

2. REPORT TYPE

Technical Memorandum 

3. DATES COVERED (From - To)

4. TITLE AND SUBTITLE

An Evaluation of Protocols for UAV Science Applications 

5a. CONTRACT NUMBER

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S)

Ivancic, William, D.; Stewart, David, E.; Sullivan, Donald, V.; Finch, Patrick, E. 

5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

WBS 430728.02.05.05.01 

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

National Aeronautics and Space Administration 

John H. Glenn Research Center at Lewis Field 

Cleveland, Ohio 44135-3191 

8. PERFORMING ORGANIZATION

 REPORT NUMBER

E-18031 

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

National Aeronautics and Space Administration 

Washington, DC 20546-0001 

10. SPONSORING/MONITOR'S

 ACRONYM(S)

NASA 

11. SPONSORING/MONITORING

 REPORT NUMBER

NASA/TM-2012-217276 

12. DISTRIBUTION/AVAILABILITY STATEMENT

Unclassified-Unlimited 

Subject Categories: 04, 43, and 62 

Available electronically at http://www.sti.nasa.gov 

This publication is available from the NASA Center for AeroSpace Information, 443-757-5802

13. SUPPLEMENTARY NOTES

14. ABSTRACT

This paper identifies data transport needs for current and future science payloads deployed on the NASA Global Hawk Unmanned 

Aeronautical Vehicle (UAV). The NASA Global Hawk communication system and operational constrains are presented. The Genesis and

Rapid Intensification Processes (GRIP) mission is used to provide the baseline communication requirements as a variety of payloads were 

utilized in this mission. User needs and desires are addressed. Protocols are matched to the payload needs and an evaluation of various 

techniques and tradeoffs are presented. Such techniques include utilization rate-base selective negative acknowledgment protocols and 

possible use of protocol enhancing proxies. Tradeoffs of communication architectures that address ease-of-use and security considerations 

are also presented. 

15. SUBJECT TERMS

Remote sensing; Satellite communication; Protocol (Computers) 

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF

 ABSTRACT

UU 

18. NUMBER

 OF 

 PAGES

12 

19a. NAME OF RESPONSIBLE PERSON

STI Help Desk (email:help@sti.nasa.gov) 

a. REPORT

U 

b. ABSTRACT

U 

c. THIS 

PAGE

U 

19b. TELEPHONE NUMBER (include area code)

443-757-5802 

Standard Form 298 (Rev. 8-98)

Prescribed by ANSI Std. Z39-18