Aaron J. Swank and Casey J. Bakula

Glenn Research Center, Cleveland, Ohio

EVA Radio DRATS 2011 Report

NASA/TM—2012-217635

August 2012
NASA STI Program . . . in Profile

Since its founding, NASA has been dedicated to the 

advancement of aeronautics and space science. The 

NASA Scientific 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 Officer. 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 significant phase 

of research that present the results of NASA 

programs and include extensive data or theoretical 

analysis. Includes compilations of significant 

scientific 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. Scientific 

and technical findings 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. Scientific and 

technical findings by NASA-sponsored 

contractors and grantees.

• CONFERENCE PUBLICATION. Collected 

papers from scientific and technical 

conferences, symposia, seminars, or other 

meetings sponsored or cosponsored by NASA.

• SPECIAL PUBLICATION. Scientific, 

technical, or historical information from 

NASA programs, projects, and missions, often 

concerned with subjects having substantial 

public interest.

• TECHNICAL TRANSLATION. Englishlanguage translations of foreign scientific 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 to help@sti.nasa.gov

• Fax your question to the NASA STI 

Information Desk at 443–757–5803

• Phone the NASA STI Information Desk at

443–757–5802

• Write to:

 STI Information Desk

 NASA Center for AeroSpace Information

 7115 Standard Drive

 Hanover, MD 21076–1320
Aaron J. Swank and Casey J. Bakula

Glenn Research Center, Cleveland, Ohio

EVA Radio DRATS 2011 Report

NASA/TM—2012-217635

August 2012

National Aeronautics and

Space Administration

Glenn Research Center

Cleveland, Ohio 44135
Acknowledgments

Extravehicular Activity (EVA) Technology Development Power, Avionics, and Software (PAS) EVA Radio Team: 

Neil Adams, Casey Bakula, Larry Foore, Dave Pleva, Aaron J. Swank, and Dan Zeleznikar.

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 identification 

only. Their usage does not constitute an official endorsement, 

either expressed or implied, by the National Aeronautics and 

Space Administration.

Level of Review: This material has been technically reviewed by technical management. 
Abstract

In the Fall of 2011, National Aeronautics and Space Administration (NASA) Glenn Research Center (GRC) participated in the Desert

Research and Technology Studies (DRATS) field experiments held near

Flagstaff, Arizona. The objective of the DRATS outing is to provide

analog mission testing of candidate technologies for space exploration,

especially those technologies applicable to human exploration of extraterrestrial rocky bodies. These activities are performed at locations with

similarities to extra-terrestrial conditions.

This report describes the Extravehicular Activity (EVA) Dual-Band

Radio Communication System which was demonstrated during the 2011

outing. The EVA radio system is designed to transport both voice and

telemetry data through a mobile ad hoc wireless network and employs a

dual-band radio configuration. Some key characteristics of this system

include: 1. Dual-band radio configuration. 2. Intelligent switching between two different capability wireless networks. 3. Self-healing network.

4. Simultaneous data and voice communication.

NASA/TM—2012-217635 1
Contents

1 Executive Summary . . . . . . . . . . . . . . . . . . . . . . . 5

2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Radio Testbed . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Hardware Description . . . . . . . . . . . . . . . . . . . . 7

3.2 Radio Configuration . . . . . . . . . . . . . . . . . . . . . 9

3.2.1 2.4 GHz Wi-Fi Radio Configuration . . . . . . . . 9

3.2.2 900 MHz Contingency Radio Configuration . . . . 10

3.3 Software Implementation . . . . . . . . . . . . . . . . . . . 11

3.3.1 Wireless Mesh Routing . . . . . . . . . . . . . . . 11

3.3.2 Wireless Network Health Sensing & Network Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.3 Speech Acquisition & Encoding . . . . . . . . . . . 15

3.3.4 Telemetry & Sensor Data Distribution . . . . . . . 18

4 Experiment Test Description . . . . . . . . . . . . . . . . . 19

4.1 EVA Test Scenario . . . . . . . . . . . . . . . . . . . . . . 20

5 Early Assessment of Test Results . . . . . . . . . . . . . . 22

5.1 System Evaluation . . . . . . . . . . . . . . . . . . . . . . 22

5.1.1 Wireless Network Health Sensing & Network Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.2 Voice Data Distribution . . . . . . . . . . . . . . . 24

5.2 Test Subject Feedback . . . . . . . . . . . . . . . . . . . . 27

5.2.1 Voice Quality . . . . . . . . . . . . . . . . . . . . . 27

5.2.2 Switching Logic . . . . . . . . . . . . . . . . . . . . 28

5.2.3 User Interface . . . . . . . . . . . . . . . . . . . . . 29

6 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 29

6.1 Environment Implications . . . . . . . . . . . . . . . . . . 29

6.2 Network Configuration Drivers . . . . . . . . . . . . . . . 30

6.2.1 Network Data Traffic Control . . . . . . . . . . . . 30

6.2.2 Wireless Link Access Time . . . . . . . . . . . . . 32

6.2.3 Network Packet Characterization . . . . . . . . . . 32

6.3 DTN Rationale . . . . . . . . . . . . . . . . . . . . . . . . 33

7 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7.1 System Configuration . . . . . . . . . . . . . . . . . . . . 34

7.1.1 Switching Logic . . . . . . . . . . . . . . . . . . . . 34

7.1.2 OLSR Configuration . . . . . . . . . . . . . . . . . 36

7.1.3 OLSR Multicast Configuration . . . . . . . . . . . 36

7.1.4 Radio Configuration . . . . . . . . . . . . . . . . . 37

7.2 Localization . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.3 Operational Concepts . . . . . . . . . . . . . . . . . . . . 38

NASA/TM—2012-217635 2
7.4 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 38

8 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . 39

A Configuration Management . . . . . . . . . . . . . . . . . . 41

B Topographical Map Generation . . . . . . . . . . . . . . . 44

B.1 Detailed Instructions . . . . . . . . . . . . . . . . . . . . . 45

C Experimental Data Description . . . . . . . . . . . . . . . 47

D Acronyms and Abbreviations . . . . . . . . . . . . . . . . . 49

E References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

NASA/TM—2012-217635 3
List of Tables

1 Wideband Radio Configuration Settings . . . . . . . . . . 10

2 900 MHz Contingency Radio Configuration Settings . . . . 10

3 EVA Radio OLSR Configuration Settings . . . . . . . . . 13

4 EVA Radio Speex Configuration Settings . . . . . . . . . 16

5 Packet Sizes for OLSR and Voice Data. . . . . . . . . . . 33

List of Figures

1 EVA Radio Backpacks at DRATS . . . . . . . . . . . . . . 6

2 EVA Node Functional Diagram . . . . . . . . . . . . . . . 8

3 EVA Testbed Nodes . . . . . . . . . . . . . . . . . . . . . 9

4 EVA Radio Switch Points . . . . . . . . . . . . . . . . . . 14

5 Test Setup for Simulated EVA Sortie. . . . . . . . . . . . 19

6 Destinations for Walk Test . . . . . . . . . . . . . . . . . 20

7 Topo Map with Walk Test Destinations Near SP Crater . 21

8 Example Traverse Path . . . . . . . . . . . . . . . . . . . 22

9 ETX vs Time with Radio Switch Status . . . . . . . . . . 23

10 Observed Maximum Audio Packet Jitter . . . . . . . . . . 25

11 Cumulative Transmitted Audio Bytes . . . . . . . . . . . 27

12 ETX Versus Time with Radio Switch Status, Premature

Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

A1 Software Development Flow . . . . . . . . . . . . . . . . . 43

Listings

1 Debian Control File . . . . . . . . . . . . . . . . . . . . . 44

NASA/TM—2012-217635 4
1 Executive Summary

In the Fall of 2011, NASA GRC participated in the Desert Research

and Technology Studies (DRATS) field experiments held near Flagstaff,

Arizona. The objective of the DRATS outing is to provide analog mission

testing of candidate technologies for space exploration, especially those

technologies applicable to human exploration of extra-terrestrial rocky

bodies. These activities are performed at locations with similarities to

extra-terrestrial conditions.

This report describes the Extravehicular Activity (EVA) Dual-Band

Radio Communication System which was demonstrated during the 2011

outing. The EVA radio system is designed to transport both voice and

telemetry data through a mobile ad hoc wireless network and employs a

dual-band radio configuration. Some key characteristics of this system

include:

• Dual-band radio configuration. One 2.4 GHz radio is used for

high data rate communication and a 900 MHz radio is used for contingencies to provide improved coverage and extended operational

range.

• Intelligent switching between two different capability wireless networks. The switching algorithm utilizes the probability of

a successful packet transfer (expected transmission count) for the

wireless links in order to select the appropriate wireless network.

• Self-healing network. Alternative data paths are determined

either within the same network, or by transitioning to an alternative independent wireless network with different capabilities and

characteristics.

• Simultaneous data and voice communication. The wireless

communication system uses Media Access Control (MAC) layer

traffic control and open source Speex-based Voice over Internet

Protocol (VoIP) technology.

2 Introduction

Due to the often conflicting requirements of high data rates and reliable radio coverage, a dual-band radio architecture is proposed for future

EVA suit systems. This system uses a wideband, high data rate Radio

Frequency (RF) interface with enough throughput to handle simultaneous voice, telemetry, and video flows, as well as a lower data rate RF

interface that can carry mission essential voice and telemetry. The wideband interface is used amongst all radios while they are in range of each

other, and since the link range of wideband networks is relatively short,

the low-rate interface is used when the wideband interface fails. Lowpriority data flows originating from the suit are queued up locally on

NASA/TM—2012-217635 5
Figure 1. Test subjects with EVA Radio backpacks at DRATS 2011.

the suit and transmitted when the wideband network is available. This

concept allows for each of the two interfaces to be designed separately

according to each set of requirements for both coverage and high data

rates.

In order for a dual-band radio system to work reliably, the switching

between the two interfaces must be done gracefully to avoid dropouts

and loss of data. This is not a trivial problem, as it involves an accurate

assessment of the wideband link quality at all times. When the radio

perceives that the wideband link is about to fail, it must propagate

this information throughout the network so that all other radios can

switch over to the low-rate interface before any data loss can occur.

All of the nodes in the mesh must utilize the same network to avoid

asymmetries in throughput and to ensure all of the nodes are receiving

the same information. When the network is using the low-rate interface,

all radios must evaluate the link quality for each wideband link within

the network. Once all of the wideband links are established and stable,

the radio network then switches back to using the wideband interface.

The EVA Radio prototypes tested at DRATS 2011 (Figure 1), are

designed to implement the features described above using Commercial

Off-The-Shelf (COTS) radio interfaces and open-source networking software. The system consists of three backpacks replicating EVA suits, with

two being for crew members and the third as a backup. An additional

base station node simulates a stationary relay communications terminal

to an earth-based ground station. The DRATS test scenarios adhere to

a typical EVA sortie featuring two crew members venturing away from

NASA/TM—2012-217635 6
a base station. The objectives of these tests are to:

• Evaluate the performance of the RF interface switching logic

• Gather the crew members’ feedback about the concept of a dualband radio and the current implementation

• Evaluate the performance of the COTS radios in an environment

that more closely matches a lunar/Near-Earth Asteroid (NEA) setting

• Evaluate the performance of the open-source routing software

3 Radio Testbed

3.1 Hardware Description

In order to demonstrate the concept of a dual-band switching radio

system, a testbed was constructed. The testbed consists of two mobile

nodes representing EVA crew members and a fixed-node base station

connected to a ground station terminal, hereafter referred to as XCOMM.

The two mobile nodes and the single fixed node are constructed with

the same functional hardware components and utilize the same software

builds.

The components of the nodes are primarily COTS hardware, which

includes an i686-based General Purpose Processor (GPP), a 900 MHz

Orthogonal Frequency-Division Multiplexing (OFDM) radio, a 2.4 GHz

Wireless Fidelity (Wi-Fi) radio, an Internet Protocol (IP) video camera,

a pair of speakers, a microphone, and a Global Positioning System (GPS)

receiver. A functional sketch of the dual-band radio testbed is depicted

in Figure 2. The GPP runs the entire networking stack, handles the

interfaces for all of the other hardware components and processes all incoming and outgoing data. An i686-based GPP is chosen specifically to

run a full Debian Linux distribution. Linux is used to aid in rapid prototyping by leveraging the inherent software and hardware driver support

that comes with using an established operating system. An outdoor,

Access Point (AP)-class 900 MHz OFDM radio is selected as the contingency interface because of the favorable propagation characteristics and

the fact that it can be configured for high bandwidth at lower data rates,

which improves coverage by minimizing inter-symbol interference. The

2.4 GHz Wi-Fi radio is selected to evaluate the performance of 802.11 in

an EVA sortie scenario, as well as the fact that an 802.11n AP is under consideration for the International Space Station (ISS).1 Both the

900 MHz and 2.4 GHz radios are equipped with dipole antennas.

1The ISS External Wireless System described in Boeing’s draft document [1] proposes two COTS BelAir 802.11n APs to be installed inside the ISS with the antennas

mounted outside. Coverage would be available to payloads mounted at several of the

Express Logistics Carrier sites.

NASA/TM—2012-217635 7
2.4GHz Wideband Radio 900MHz Contingency Radio

IP

TCP UDP ICMP

BioNet

IP

Microphone/Speakers 

(Speex Codec)

Traffic Sources/Sinks

GPP Functions

COTS Radios

GPS

Video Camera

Legend

Figure 2. EVA Node Functional Diagram

Data is generated by the nodes via VoIP voice, video, GPS telemetry,

and network/radio messaging. Each node contains a push-to-talk microphone connected to a line-level audio input on the GPP. Audio data is

encoded, packetized and transmitted over the active RF interface. Incoming audio is decoded and output to a pair of speakers mounted near

the crew member’s head. The IP video camera, mounted over the shoulder of the crew member, generates an IP packet stream of video data

over a gigabit Ethernet interface to the GPP, which then routes the video

data to XCOMM if the Wi-Fi interface is available. If only the 900 MHz

interface is available, the video data is stored locally until the Wi-Fi interface is re-established. The GPS unit, connected via serial port to the

GPP, generates position information once per second. The location is

transmitted over the active RF interface back to XCOMM. The routing

protocol, described in further detail in Section 3.3.1, also generates its

own network traffic for the purpose of evaluating link quality and establishing routing tables. Finally, the radios themselves generate MAC

messages that are used to establish and maintain the wireless networks.

All of the hardware components are fixed to a plastic backing plate,

and for the mobile nodes, the plate is securely mounted to a rigid externalframe backpack via aluminum struts. Plastic masts for the radio antennas are also fixed to the plate so that the antennas can be mounted

safely above the crew member’s head. Figure 3 shows the constructed

dual-band radio testbed hardware.

NASA/TM—2012-217635 8
(a) EVA Base Station (b) EVA Testbed Backpack

Figure 3. EVA Testbed Nodes

3.2 Radio Configuration

Both 900 MHz and 2.4 GHz COTS radios used in the EVA radio

system are 802.11-based, although the system profiles are quite different.

The configuration of each radio is described in the following sections.

3.2.1 2.4 GHz Wi-Fi Radio Configuration

The high data-rate radio is configured as an 802.11b/g radio. Refer

to Table 1 for a summary of the configuration settings. The radio is

configured in ad hoc mode, as the system is intended to operate in an

environment where there is no pre-established infrastructure. Request

To Send (RTS)/Clear To Send (CTS) is enabled to mitigate the effects

of the classic hidden node problem, which was deliberately tested during

the outing. RTS/CTS is an optional handshaking protocol that ensures a

receiver is ready to receive a data frame before it is transmitted. A fragmentation threshold is also used so that large file transfers (i.e., stored

video) will not occupy the wireless channel for long periods of time,

preventing time-sensitive date from being transmitted during periods of

high congestion. All data frames that are larger than the fragmentation

threshold will be fragmented into smaller frames before transmission.

This is desirable in certain networks, since radios on the network must

wait for relatively long periods of time while large data frames are being

transmitted. A fragmentation threshold also improves performance in

the presence of RF interference. The 802.11 channel/frequency is chosen

to minimize interference with other transmitters observed in the spectrum, as identified during initial test site location evaluation.

NASA/TM—2012-217635 9
Configuration Setting

Mode ad hoc

Transmit Power 30 dBm (1W)

Frequency 2.412 GHz

(802.11 Channel 1)

Bandwidth 20 MHz

Modulation variable

Data Rate variable, 1-54 Mbps

(802.11 b/g)

Fragmentation Threshold 512 Bytes

RTS/CTS enabled

Table 1. Wideband Radio Configuration Settings

3.2.2 900 MHz Contingency Radio Configuration

Since the main design objective of the contingency radio is reliable

coverage, the radio’s 802.11 system profile is configured as such. It is

important to note here that this radio is not a true 802.11 radio, since

it operates outside of the 2.4 GHz Industrial, Science and Medical (ISM)

band. The manufacturer intended this radio to be as close as possible

to an 802.11 radio operating in the 900 MHz ISM band. To maximize

range and minimize the Bit Error Rate (BER), Binary Phase Shift Keying (BPSK) modulation is used. High data rates are not needed for

this interface, so the use of a higher order modulation scheme is unnecessary. To further mitigate the effects of multipath and inter-symbol

interference, OFDM is used with a 20 MHz bandwidth. Since the signal

is spread out over a large bandwidth, it is less susceptible to narrowband

fading. Configuration settings for the contingency radio are summarized

in Table 2.

Configuration Setting

Mode ad hoc

Transmit Power 30 dBm

Frequency 915 MHz

Bandwidth 20 MHz

Modulation BPSK w/ OFDM

Data Rate 6 Mbps

Fragmentation Threshold 512 Bytes

RTS/CTS disabled

Table 2. 900 MHz Contingency Radio Configuration Settings

NASA/TM—2012-217635 10
3.3 Software Implementation

Where possible, existing software projects are utilized and the development effort made extensive use of open source software. For newlydeveloped software, each core software capability is contained as a separate software program or library. The core software capabilities for the

EVA radio system fall into the following primary functional categories:

• Wireless Mesh Routing

• Wireless Network Health Sensing and Network Switching

• Speech Acquisition/Encoding for VoIP

• Sensor Acquisition and Distribution (Telemetry)

Each core software capability is described in the upcoming sections. All

of the system software are developed and deployed on the testbed using

a version control system. Additional information on the software development methodology and the software version control system is found in

Appendix A.

3.3.1 Wireless Mesh Routing

The Wi-Fi radio hardware is configured to operate in an ad hoc

mode as opposed to a traditional infrastructure mode. An ad hoc wireless network handles changes in the network topology in a distributed

fashion, as there is no central AP or pre-established infrastructure. The

ad hoc mode is primarily designed for peer-to-peer communication and

the network topology must be discovered by each of the nodes. Often

a peer-to-peer network is used to allow communication between nodes

which are within range of each other without the need for an AP. An

ad hoc wireless mesh network may also implement a routing protocol

which utilizes other nodes in the network to route and forward data. If

the destination node is not within direct range of the source node, the

data is relayed over other members within the network. A disadvantage

of such a network topology is that the data transmissions are susceptible

to potentially large network delays. The user does not necessarily have

control over the path that data takes to reach the intended destination.

As a result, the information may not route through the most optimal or

efficient path to the end point. In order to intelligently manage the routing of data throughout the wireless mesh on the Wi-Fi network, the EVA

radio system adopted the Optimal Link State Routing (OLSR) ad hoc

wireless mesh routing protocol [2]. Specifically, the open source OLSR

implementation from olsr.org was utilized [3], [4].

The use of OLSR in the network also allows a node to establish a

communication link to hidden nodes or to nodes which are unable to

maintain a reliable direct path connection. All members in the wireless mesh may communicate either via a direct link or a multi-hop route

depending on the optimal path as determined by OLSR. In order to

NASA/TM—2012-217635 11
determine the network routes, OLSR sends out HELLO and Topology

Control (TC) messages at regular fixed intervals. These messages determine the network topology and distribute the information to all of the

network nodes. Specifically, the HELLO messages are used to identify the

neighbors visible to a node and the quality of the corresponding link. The

TC messages are used to distribute the complete topology information to

the entire mesh. The interval of these control messages is important, as

the system must properly capture the mesh topology without consuming potentially limited bandwidth with redundant or unnecessary traffic.

The default settings for OLSR is intended for large wireless mesh networks with nodes that are typically fixed in location. In the EVA radio

system, OLSR is applied to a dynamic wireless mesh with mobile nodes.

The complete system is comprised of only a few nodes, with only one

stationary member. Therefore, for the EVA radio system, the default

values for the HELLO and TC packet interval and corresponding validity

times are reduced. While this results in a more frequent transmission

of packets, it allows for the network routing and health metrics to be

more rapidly determined for the system, which is necessary to properly

react to the system dynamics. In the EVA radio system, the motion of

a walking human presents changes in the system. The network packets

used to determine mesh metrics must be generated more frequently than

topology changes resulting from human motion. As a result, a modest

value of 0.5 sec or 2 Hz for the HELLO packets is selected, as test results

indicated walking speeds on the order of 2 m/s.

The essential OLSR configuration settings for the EVA radio system

are found in Table 3. Further information on the OLSR configuration

parameters can be found in the olsrd.conf manual page [5]. Note that

the table lists the OLSR configuration for both the wideband and the

low data-rate networks. Although OLSR is not required for routing

data on the narrowband wireless network, the software protocol was

used for analysis purposes to characterize the health of the network, as

will be further discussed in Section 3.3.2. The implementation of OLSR

on each network for the EVA radio system is independent and is not

intended to allow packet routing between the two networks. The use

of OLSR further provides an added redundancy, allowing for multi-hop

data routing through the low data-rate network if direct connectivity is

lost from the base station.

3.3.2 Wireless Network Health Sensing & Network Switching

A core component of the EVA radio system is the capability to perform intelligent switching between two different wireless networks to

reach the same destination node. If one wireless network is not available or exhibits a poor link quality, an alternative network will be used

entirely by the system. In order to perform the intelligent switching,

information pertaining to the health of each wireless network must be

NASA/TM—2012-217635 12
OLSR Configuration Setting

Hello Interval

Wideband: 0.5 sec

Narrowband: 2.0 sec

Hello Validity Time

Wideband: 5.0 sec

Narrowband: 20.0 sec

TC Interval 5.0 sec

Topology Validity Time 300.0 sec

TC Redundancy All Neighbors

Link Quality Level ETX enabled

Link Hysteresis disabled

Table 3. EVA Radio OLSR Configuration Settings

known to the switching algorithm. To generate the necessary wireless

link quality information, the EVA radio extracts information collected

by the OLSR software. The particular version of OLSR implemented by

the EVA radio system utilizes the link quality extension enhancement

described by De Couto [6], [7]. The original RFC-compliant OLSR protocol controls the ad hoc mesh routing by minimizing the total number

of hops between the source and destination nodes. One issue with the

simple hop-minimization scheme is that a single direct link with a poor

health may actually be preferred over a two-hop link with perfect link

quality. The enhancement to OLSR proposed by De Couto overcomes

this limitation and optimally routes network traffic through the wireless

mesh by utilizing the Expected Transmission Count (ETX) metric. The

ETX metric is the “expected total number of packet transmissions (including retransmissions) required to successfully deliver a packet along

that path” [6]. In mathematical terms, the ETX value is one over the

probability of a successful data transmission along the path. Therefore,

the ETX metric indicates the quality of the connection between two

nodes in a wireless network. The OLSR protocol utilizes this link quality information for optimally routing packets in the mesh. Furthermore,

the OLSR protocol also provides distribution of the network topology to

all of the nodes.

At each node the network topology and the corresponding quality of

the link is known. Therefore, the ETX information can be further exploited to provide “sensor” input information to the intelligent networkswitching algorithm. By knowing the probability of a successful transmission across the entire network, the primary network used for data

distribution may be switched. For the EVA radio testbed, the network

link switching is performed using a custom algorithm, with a hysteresisbased limit line, as shown in Figure 4. As the highest quality Wi-Fi link

NASA/TM—2012-217635 13
Switch Point ETX Threshold

a) Wideband to Narrowband 2.4

b) Narrowband to Wideband 1.8

Figure 4. EVA Radio Switch Points

metric to any of the required destination nodes in the network degrades

below a pre-set value, the switching algorithm triggers a switch to the

low data-rate network. Since OLSR distributes the topology and health

metrics throughout the mesh, all of the nodes sense the degradation and

perform the switch.

The switching parameters for the EVA radio system are setup to

allow degradation of the network health to a level where a multi-hop

situation will occur on the Wi-Fi network before a switch to the lower

bandwidth network. When OLSR routes data across the mobile ad hoc

Wi-Fi network, either a direct link or a multi-hop connection may be

used. In the EVA radio system, multiple hops across the various Wi-Fi

nodes often provides a higher throughput than utilizing the alternative

low data-rate link. Although the Ultra High Frequency (UHF) link has

a higher probability of maintaining the data flow, it is not adequate at

delivering the required bandwidth. In the EVA radio system, the high

data-rate video data is not transmitted when the system is operating on

the low data-rate link. The video data is buffered and re-transmitted

when the high data-rate network becomes available. Maintaining the

Wi-Fi network link is therefore more desirable than allowing the system

to switch to the low data-rate network. When a higher quality direct-link

connection on the Wi-Fi network becomes available, the OLSR protocol

will automatically update the routes to transition from the multi-hop

route to the direct link. This allows the system to maintain the data

flow on the Wi-Fi network as long as possible before switching to the

low data-rate network.

OLSR is fully capable of utilizing mixed bandwidth links comprising one complete wireless mesh. The ETX metric will result in OLSR

automatically preferring routes with the most efficient data transfer charNASA/TM—2012-217635 14
acteristics. As a result, one could utilize OLSR to route data across both

the low data-rate and Wi-Fi network interfaces. Yet, allowing OLSR to

fully handle the switching between the low data-rate and the Wi-Fi network is not desirable for the EVA radio system. By allowing OLSR to

manage both the UHF and the Wi-Fi links as one contiguous network,

the setup would allow a low data-rate link to be utilized as a portion of

the multi-hop route. This potentially allows high bandwidth data to be

sent over a much lower bandwidth network link, resulting in a bottleneck

for critical data that must be received in near real-time. In the EVA radio system, one would rather utilize a store and forward approach for

the non-critical data and provide high priority or sole usage of the low

bandwidth communications link for voice and mission critical data components. As a result, for the EVA radio testbed, OLSR was not allowed

to span the two different networks. The OLSR open source code was

slightly modified to allow multiple instances of the software daemon to

run concurrently and independently on the same host.

3.3.3 Speech Acquisition & Encoding

For voice transmissions, the EVA radio system utilizes VoIP technology. Although analog and non-IP digital voice radio systems are commonly used in practice, the use of VoIP technology is becoming more

frequent. Digital voice transmission via VoIP offers a number of appealing advantages. For example, a digital VoIP audio system shares the

same network as all of the other data flows, eliminating the need for

a separate network and/or wireless channel devoted strictly to audio.

Compared to a purely analog system, a wireless VoIP system may also

provide a better quality audio signal with increased clarity during periods of signal fading or marginal reception. By utilizing a digital encoded

speech format, the audio signal is less susceptible to noise on the wireless

channel, since phase and magnitude distortions cannot directly affect the

audio. A disadvantage of digital voice systems is the sensitivity to network latency and jitter. Voice packets can be delayed on a congested

network or even dropped. VoIP protocols have built-in mechanisms for

handling these issues, but the parameters of these mechanisms often need

to be optimized for a specific network to maximize the performance of

the system. These parameters are discussed in detail in this section.

For the EVA radio testbed, the audio data is acquired from a pushto-talk microphone on each node and then digitally encoded using Speex.

The Speex-encoded voice stream is encapsulated into a Real-time Transport Protocol (RTP) audio packet stream and then transmitted over the

wireless network. Speex is an open source/free software patent-free audio compression format specifically designed for speech [8]. The open

source aspect of the audio codec eliminated the need to acquire software licenses and therefore expedited software development. Speex is

also available in a floating point and fixed-point version [9], although the

NASA/TM—2012-217635 15
Speex Configuration Setting

VAD enabled

DTX enabled

AEC disabled

Sampling Rate 8 kHz, 20 ms/frame

(Narrowband Mode)

Jitter Buffer Size 8 Speex Frames

Table 4. EVA Radio Speex Configuration Settings

fixed-point implementation was not necessary for the initial EVA radio

proof of concept implementation. Speex is also well-suited for wireless

applications, as the signal is purposely degraded to reduce the required

bandwidth. A lossy format as such is quite appropriate for audio content

containing normal conversational speech. In addition, Speex provides the

capability to reduce the amount of data transmitted over the network

based on the audio being encoded. For example, Speex may be configured to operate in a Voice Activity Detection (VAD) mode. The VAD

mode is used to detect when the audio to be encoded contains actual

speech content or is merely background noise/silence [9]. The detected

non-speech periods may then be encoded with the minimal number of

bits required to generate a comfort noise. Alternatively, a Discontinuous Transmission (DTX) mode for Speex may be enabled to eliminate

the comfort noise completely. The DTX mode is an enhancement to

the VAD mode, where the encoded audio is not transmitted during periods of non-speech detection [9]. In DTX mode, the RTP audio stream

is maintained, yet only the minimum Ethernet packet size (46 bytes) is

transmitted. Utilization of the Speex VAD and DTX mode reduces the

total amount of network traffic for each node and thus allows for a more

efficient utilization of the wireless link. In the EVA radio testbed, the

DTX and VAD modes are enabled. A number of other configuration

options are available for the Speex codec. Table 4 provides a summary

of the Speex configuration options used for the EVA radio system.

A jitter buffer is used on the receiving end of a VoIP system to handle the variation in the RTP packet arrival times due to network delays.

A trade-off must be made between the acceptable latency of the audio

stream and the desired quality. Increasing the jitter buffer size results

in an improvement of the audio quality, but is made at the expense

of an increased latency of the audio stream. For real time operations,

voice data that is significantly delayed is considered unsatisfactory to

end users. The International Telecommunications Sector addresses the

acceptable delays for voice applications. The International Telecommunication Union (ITU) recommended one-way delay should not exceed

400 ms and indicates that callers usually notice round-trip voice delays

NASA/TM—2012-217635 16
of 250 ms or more [10]. For VoIP applications, a delay requirement of less

than 200 ms is typical [11]. The Speex library provides a jitter buffer,

which is specifically designed for Speex. The Speex jitter buffer provides

an adaptive trade-off between good quality audio stream and low latency

by varying the size of the jitter buffer. If a large network delay is encountered in the system, then the Speex adaptive jitter buffer size will

be increased to ensure good quality. The issue arises when streaming

RTP packets across a wireless link, where the signal may often fade in

and out. The unreliable wireless link will cause the adaptive jitter buffer

to select a large size for increased audio quality, but may be at a level

with a larger delay than what is acceptable. Although Speex provides

some configuration parameters to set the desired maximum latency, for

testing purposes in the EVA radio system, it was more desirable to have

a fixed, deterministic maximum allowed delay in the voice stream. As

a result, the Speex/VoIP implementation in the EVA radio system does

not utilize the built-in Speex adaptive jitter buffer provided by the Speex

software library. The EVA radio system uses a fixed jitter buffer size,

which is more deterministic and provides better control over the observed maximum delay in the voice stream than the adaptive technique.

The fixed buffer size is appropriate for the initial EVA radio test setup,

but other techniques should be considered for future development. In

addition, Reference [11] provides further insight into reducing the transmission delay for voice over multi-hop 802.11 wireless networks. Such

techniques should also be considered for future development of the EVA

radio system.

3.3.3.1 Voice Data Distribution

As already indicated, the voice data transmission builds upon VoIP

technology. The encoded speech must be received by all the nodes, and is

not simply a point-to-point VoIP stream. Each node in the wireless mesh

must distribute the VoIP traffic to all of the other nodes on the mesh, as

well as receive the VoIP traffic from the other nodes. In the EVA radio

testbed, the VoIP audio stream is distributed using a multicast destination address. All nodes in the mesh are then able to subscribe to the

audio stream if the multicast packet is received. In a non-OLSR-enabled

network, only the nodes with a direct link to the node broadcasting the

multicast information would be able to receive the information. In the

OLSR-enabled network, an additional mechanism is necessary to distribute the multicast data through the mobile ad hoc mesh, including

nodes which may not have a direct connection to the originating node

or to nodes which may have a limited connectivity. To handle the multicast data distribution and routing issue, the EVA radio system uses the

Basic Multicast Forwarding (BMF) OLSR plug-in. The BMF module

is designed to forward IP-multicast and IP-local-broadcast traffic over

the network. The multicast forwarding is achieved by encapsulating the

NASA/TM—2012-217635 17
original multicast packets and transporting them over a User Datagram

Protocol (UDP) socket. The BMF module will relay and forward multicast packets as necessary throughout the network. It is important to

note that although the voice data is originally distributed using a multicast address, the actual distribution throughout the network by OLSR

and the BMF plug-in is achieved in a unicast fashion. The unicast distribution of the multicast data is important because the wideband radio is

configured to implement a fragmentation of the Wi-Fi frames. An 802.11

source does not apply the fragmentation threshold setting to multicast

or broadcast frames [12]. Thus, an additional advantage of utilizing the

OLSR BMF plug-in is that all of the multicast traffic will also be subject

to the fragmentation threshold setting since all of the multicast data is

relayed using a unicast link.

3.3.4 Telemetry & Sensor Data Distribution

For distributing the sensor data throughout the network and for

the internal Command and Data Handling (C&DH) subsystem on each

node, the EVA radio system uses the BioNet framework [13]. BioNet is

available as open-source code and provides plug-and-play operation of

software/hardware. Control information and sensor data distribution is

achieved through a publish and subscribe method with a service discovery protocol. BioNet can also provide a CCSDS compliant data delivery

system by utilizing the Interplanetary Overlay Network (ION) software

package, which is also an implementation of the Delay-Tolerant Networking (DTN) architecture [14], [15]. The BioNet framework provides

a standardized interface to software applications, and can be configured

to either enable or disable the DTN capabilities as necessary without a

direct impact on the software interface.

For the EVA radio system, simulated telemetry data is collected from

an on-board GPS unit. The positional telemetry is passed through the

BioNet framework from each node on the EVA radio testbed to the base

station node. In addition to the positional information, the simulated

telemetry also includes sensor data from the switching algorithm and the

OLSR ETX metrics from each node. The switching algorithm parameters, including the ETX metrics, are distributed via BioNet throughout

the entire mesh in addition to the base station node. The real-time

voice data, as already described in Section 3.3.3, is not handled by the

BioNet framework in the EVA radio testbed. This design choice is necessary, as real-time voice data must be received with a minimal amount

of latency. A DTN-enabled BioNet middleware could increase the data

arrival latency by nature of the DTN store and forward architecture.

NASA/TM—2012-217635 18
Stationary Node

900 MHz

Radio

2.4 GHz

Radio

Ground Terminal

Figure 5. Test Setup for Simulated EVA Sortie.

4 Experiment Test Description

Performance testing of the EVA radio setup was performed in early

September 2011 at the NASA DRATS outing. The tests were in the

desert near Flagstaff, Arizona, which exhibits a terrain and environment similar to a potential extraterrestrial exploration activities on the

martian or lunar surface. For the EVA radio system tests, a scenario

representative of an EVA sortie is executed which is also specifically designed to test two conditions pertinent to the EVA radio communications

system:

• Nominal Traverse

• Hidden Node

For the simulated EVA sortie, the test setup includes a remote ground

station for visualization purposes, a stationary node and two remote mobile nodes. Figure 5 depicts the test configuration. The nominal traverse

includes conditions with direct and non-direct line-of-site communication

conditions on the high data-rate network to the base station via the stationary node. The traverse path is designed such that the high data-rate

communications link is established, lost, and then re-established.

The classic hidden node condition is designed to generate a two-hop

relay configuration for voice and data communications over the high data

rate wireless network. One mobile node is positioned with a direct lineof-site communications link via the high-data rate wireless link to the

base station and to the other mobile node. The other mobile nodes

are positioned such that direct line-of-site data communication to the

base station is not possible, yet a direct line-of-site link between the two

mobile nodes is maintained. The scenario either requires communication

via the 900 MHz contingency radio or for communication information to

NASA/TM—2012-217635 19
(a) Rock Pile (Dest. No. 1) (b) Rock Outcrop (Dest. No. 2)

Figure 6. Destinations for Walk Test

be relayed over the other remote node to the ground station. During

the test, it is assumed that the contingency radio network is always

accessible.

4.1 EVA Test Scenario

For the test scenario, two walking subjects representing EVA crew

members are used for the mobile nodes. During the test, the subjects are

to make notes and records of any interesting rock formations or sites of

interest via video captures and audio transmissions. The test subjects are

advised to maintain line-of-site distance to their companion walker and to

conduct all conversations over the push-to-talk voice system, consistent

with the characteristics of a normal EVA.

The test subjects are instructed to walk to two destinations of interest, simulating a geological science exploration EVA. Destination No. 1

is a volcanic rock pile near the base of SP Crater. Destination No. 2

consists of a volcanic rock outcropping near a dry creek bed. A photo of

the two test destinations is depicted in Figure 6.

The actual traverse path taken by the walking crew members is not

specifically marked. Yet, a large portion of the traverse route follows the

dry creek bed, which passes by the base of SP Crater and connects to

Destination No. 2. A topographical map of the testing area is depicted in

Figure 7. The test destinations are indicated in the figure and a potential

walking path is also depicted. During the walking test, the subjects

are led by a field guide between the destinations to ensure consistency

between test runs. The field guide also ensures the field operations are

efficient and safe, as the guide is already familiar with the test objectives

and intended traverse path. The route led by the field guide is designed

to always maintain connectivity on the low data-rate network, as the test

is designed to evaluate the radio switching performance characteristics

and not the COTS radio hardware.

To begin the test, the test subjects depart the base station location

by descending down a slight hill to the dry creek bed. The test subjects

then traverse from the base station to the rock pile (Destination No. 1)

NASA/TM—2012-217635 20
Rock Pile

Rover Vehicle

Rock Outcropping

300 m

Figure 7. Topo Map with Walk Test Destinations Near SP Crater. A

dry creek bed runs between the rock pile and the rock outcropping at

the base of SP Crater.

by means of the dry creek bed. The route of the dry creek bed passes

through locations where the direct line-of-site communication to the base

station via the high data rate network is lost and then re-established.

During this portion of the traverse, the EVA radio system will switch

between the high data rate communications link and the contingency

radio in order to maintain voice and data communications with the base

station. Once at the first destination, one crew member moves to higher

ground by carefully scaling the rock pile. This crew member maintains

the high ground as the traverse is continued back along the dry creek

bed. The crew members are instructed to always maintain line-of-site to

each other during the traverse. The objective here is to generate a twohop communications configuration for the EVA radio system. One crew

member maintains direct line-of-site connectivity with the base station,

while the other crew member following the dry creek bed. The path

following the dry creek bed passes through regions where loss of direct

connectivity occurs. At this point, the system may develop a two-hop

data link configuration. If the health of the single direct link is not

sufficient to maintain acceptable voice communications, the EVA radio

system will switch to the contingency communications radio.

After leaving the rock pile, the crew members rejoin in the dry creek

bed and proceed to the second destination. Destination No. 2 is designed

to break the direct line-of-site communications link for both of the EVA

crew members to the base station. At this point, the system should transition from the high data rate communications link to the contingency

NASA/TM—2012-217635 21
Rock Pile

Rover Vehicle

Rock Outcropping

Figure 8. Example Traverse Path. The traverse path for EV1 and EV2

is depicted using cyan and magenta respectively. The base station tower

is located at the Rover Vehicle.

radio. After operating for some time on the contingency radio link, the

test subjects then return up the hill back to the base station. Eventually

the EVA radio system will switch back to the high data rate network as

the link becomes available and stable link health metrics are observed.

5 Early Assessment of Test Results

5.1 System Evaluation

The traverse path depicted in Figure 8 is representative of a route

taken by the test subjects during the DRATS 2011 test experiments.

The path demonstrates both the normal traverse and the hidden node

(multi-hop) test conditions as described in Section 4. At the beginning

of the traverse, both test subjects start from the Rover Vehicle and walk

together to the rock pile. Once at the rock pile, one test subject, referred

to here as EV1, ascends the rock pile to higher elevation. The other test

subject, referred to here as EV2, stays within the confines of the dry

creek bed and proceeds to the rock outcropping. Both EV1 and EV2

maintain line-of-site to each other and join back in the dry creek bed

prior to reaching the rock outcropping. For this particular traverse, EV2

enters the rock outcropping, while EV1 stops short of the outcropping.

After investigating the rock outcropping, both test subjects return to

the Rover Vehicle.

NASA/TM—2012-217635 22
0 500 1000 1500 2000 2500 3000 3500

Seconds after: 2011-09-03 13:24:08

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

Wi-Fi Max ETX

SWITCH_ETX_1315070648.028451.csv.gz

Figure 9. ETX vs Time with Radio Switch Status. Shaded regions indicate radio switch periods on the low data rate network. An ETX value

of one indicates a node in the network is missing. The region centered

around the elapsed time of 3000 seconds on the high data rate network

is a multi-hop route configuration. At this portion of the experiment,

data for one test subject is routed through the other test subject back

to the base station.

5.1.1 Wireless Network Health Sensing & Network Switching

During the test, the ETX value for all of the links is monitored and

recorded by the EVA radio system. As the system switches between the

two networks, the timestamp of the switch is recorded. The maximum

recorded ETX value for all of the 2.4 GHz radio links is used for driving

the switching routines. Figure 9 shows the recorded ETX value and the

system behavior corresponding to the traverse depicted in Figure 8. The

shaded regions of the plot indicate time spans where the EVA radio is

utilizing the low data rate network. During the first portion of the traverse, with both test subjects walking together, the system maintains the

high data rate radio connection. After an elapsed time of approximately

550 seconds, the line-of-site connection to the base station is lost and the

system switches to the low data rate network. This is observed in the plot

by observing an ETX value of one. A number of ETX values above two

are also observed, indicating an unreliable connection. The system then

NASA/TM—2012-217635 23
regains connectivity using the Wi-Fi radio and switches from the low

data rate network around an elapsed time of approximately 750 seconds.

As the traverse continues, some fluctuation in the ETX metric is observed, yet connectivity via the high data rate network is maintained.

During some portions of the traverse, as EV1 maintains higher elevation

and EV2 walks the dry creek bed at lower elevation, the system momentarily sets up a multi-hop scenario as fading of the connections causes

one link to be preferred over another. Yet, the multi-hop condition is

not maintained for a substantial amount of time.

Near the end of the traverse with an elapsed time of approximately

2700 seconds, as the test subjects approach the rock outcropping, the

EVA radio system again transitions to the low data rate network. The

data depicted in Figure 9 indicates that one of the nodes is missing from

the network. The loss of connectivity via the Wi-Fi radio is achieved

as EV2 enters the rock outcropping, while EV1 stops short of the outcropping to perform a simulated science operation. At approximately

an elapsed time of 2800 seconds, the system re-establishes a connection

via the Wi-Fi radio. This region centered around 3000 seconds of elapsed

time actually corresponds to a multi-hop condition over the 2.4 GHz network. The data for EV2 is relayed over EV1 to reach the base station.

5.1.2 Voice Data Distribution

Although user feedback provides a good representation of the system

performance for distributing voice data between the nodes, a number

of metrics may also be evaluated. The Speex audio packet arrival jitter provides an indication of the system voice characteristics. Figure 10

shows the observed Speex packet arrival jitter, which are typical and

representative of the DRATS test runs. In order to ensure a continuous play of RTP voice data, the received Speex packets are buffered and

the maximum jitter that can be accommodated is equal to the buffering

delay. As indicated in Section 3.3.3, an end-to-end delay requirement

of less than 200 ms is typical for VoIP applications and users tend to

notice delays greater than 250 ms [10], [11]. As configured for these tests

(refer to Section 3.3.3, Table 4), the Speex packets contain 20 ms of voice

data per Speex frame. A one-packet jitter therefore corresponds to an

audio packet arrival time variation of 20 ms. As shown in Figure 10, the

maximum observed audio packet jitter is less than seven packets, corresponding to 140 ms of delay. Although the metric does not include the

decoding time, the observed value is below the desired levels for an acceptable two-way voice system. Further analysis of the total number of

lost or late Speex packets indicates that the jitter buffer size could potentially be increased slightly to accommodate the observed jitter variation

to improve voice quality during fade-outs in connectivity with a minimal

impact on the end-to-end delay time. In addition, if the built-in Speex

adaptive jitter buffer were utilized, the system would make use of the

NASA/TM—2012-217635 24
0 500 1000 1500 2000 2500 3000 3500

Seconds after: 2011-09-03 13:24:08

0

1

2

3

4

5

6

7

8

Max Audio Packet Jitter, [packets]

AUDIO_1315070645.607405.csv.gz

(a)

0 500 1000 1500 2000 2500 3000 3500

Seconds after: 2011-09-08 14:21:12

0

1

2

3

4

5

6

7

8

Max Audio Packet Jitter, [packets]

AUDIO_1315506069.628031.csv.gz

(b)

Figure 10. Observed Maximum Audio Packet Jitter. Two representative

data runs. Figure (a) corresponds to the traverse depicted in Figure 8.

Figure (b) more clearly shows the difference in the observed jitter values

between the two wireless networks during an extended period on the low

data rate network. Shaded regions indicate radio switch periods on the

low data rate network.

NASA/TM—2012-217635 25
packets provided by the DTX option to catch up, by reducing the length

between breaks in the voice data.

The recorded maximum audio packet jitter values also show a dependency on the underlying wireless network used. In Figure 10, the

shaded regions indicate periods of time where the system is utilizing

the 900 MHz communications radio. These timeframes exhibit a lower

observed maximum audio packet jitter value than those periods when

the 2.4 GHz radio is used. A number of factors could be attributed to

this result. Indeed, slightly more data is being transmitted over the

network when the wideband radio is in use, which could potentially generate an increased delay in packet delivery. However, the increased data

while on the 2.4 GHz wireless network is primarily due to video snapshots, which are sent periodically in the form of file transfers. The jitter

data does not exhibit these periodic variations, suggesting the increased

data flow, although perhaps a contributor, is not the primary culprit

for the increased jitter values on the wideband network. Instead, it is

believed that the variation in the maximum jitter value between the two

wireless networks is attributed to the underlying hardware and communications parameters. For example, both a variable modulation scheme

and a variable data rate setting are enabled on the 2.4 GHz radio. The

900 MHz contingency radio is configured at a fixed data rate below the

maximum data rate for the wideband radio. Yet, the lowest configurable

data rate for the contingency radio is still above the lowest two data

rates settings on the wideband radio when a variable modulation scheme

is enabled. Thus, in areas with poor connectivity, the contingency radio had a higher data rate than the wideband radio. In addition, the

900 MHz contingency radio is more appropriately suited for the outdoor

propagation environment than the wideband radio. The COTS 900 MHz

contingency radio is designed to be an outdoor access point, while the

wideband radio is an indoor radio designed for use in an office environment. The receive path design, especially the equalizer, is driven by the

environment in which the radio will operate. Therefore, it is expected

that the 900 MHz contingency radio will perform much better outdoors

with regard to multipath effects.

5.1.2.1 Audio Packet Data Rate

The Speex implementation in the EVA radio system is configured to

utilize the VAD and DTX features. The VAD and DTX settings are

beneficial, as the settings reduce the total number of bytes transmitted

over the wireless connection. This feature is especially desirable for low

bandwidth applications. The results clearly show a variation in the total

data rate when the VAD algorithms are enabled. Figure 11 shows the

results for the accumulated total number of transmitted audio bytes

during a test run. During an extended period of silence observed near an

elapsed time of approximately 1200 seconds in Figure 11, a clear variation

NASA/TM—2012-217635 26
0 500 1000 1500 2000 2500 3000 3500

Seconds after: 2011-09-03 13:24:08

0

200

400

600

800

1000

1200

Cumulative Transmitted Audio Bytes, [kB]

Reduced Rate

 Due to VAD

AUDIO_1315070645.607405.csv.gz

Figure 11. Cumulative Transmitted Audio Bytes. A reduction in the

transmit rate results from the Speex Voice Activity Detection (VAD)

and Discontinuous Transmission (DTX) mode. The effect is clearly seen

for an extended period after an elapsed time of 1000 seconds. Shaded

regions indicate radio switch periods on the low data rate network.

in the total data rate is observed. The results indicate a potential benefit

to wireless speech applications, especially when the data throughput rate

may be constrained or highly variable.

5.2 Test Subject Feedback

At the DRATS outing, a number of test subjects were used for evaluating the EVA radio technologies. The test subjects had a wide range

of background experience including astronauts, flight controllers, scientists, engineers, and students. The test subjects provided subjective

or personal perspectives on the EVA radio system and concept. These

comments are summarized in the following sections.

5.2.1 Voice Quality

Overall the test subjects reported the voice transmissions were clear

with excellent audio quality. One test subject indicated that the voice

transmissions had a slight metallic sound which is believed to be atNASA/TM—2012-217635 27
tributed to the small, low quality speakers and mounting strategy. 2

Other users did not note of any other discernible difference in the audio

quality. The user feedback indicates that the Speex codec as configured

is sufficient for audio transmissions from a speech intelligibility aspect.

In addition, the Speex codec was configured for narrowband mode (8 kHz

sampling rate) indicating that a higher quality signal is not necessary for

the EVA radio application.

During the DRATS experiment, a scenario was set up where one user

did not have a direct link to the base station via the Wi-Fi link, but was

able to receive voice communications over the Wi-Fi network using a

multi-hop route. The users indicated that the data multi-hop setup on

the Wi-Fi network worked well. The voice quality and throughput was

maintained at an acceptable level. The users were quick to point out

that a normal operational scenario would not utilize an astronaut for

long periods to act as a “communications relay”. Still, the users agreed

that the multi-hop option is a good capability to have for short durations

and could be used to extend the EVA operational range.

5.2.2 Switching Logic

The test subjects provided feedback on the switching of the system

between the two wireless networks. In general, the switching between

the two wireless networks was seamless and provided good voice quality

without interruption. The comments regarding the characteristics of the

EVA radio switching related to the viewpoint of either the direct end

user (astronaut) or the remote user (mission control). The astronaut just

wants the audio to work and doesn’t care about the added capability that

does not impact them directly. For instance, the astronaut is not going

to be concerned if mission control is not receiving real-time high data

rate video as long as the mission critical voice data flow is transmitted

and the video eventually gets transmitted. As a result, the astronaut

as an end user would prefer that the system switch immediately to the

low data-rate communications link and be very slow to return to the

more capable wideband network. The end user at mission control has

the opposite desire, where they need as much remote data as possible

and therefore would rather stay on the high data rate network as long as

possible. Although some further tweaking of the switching algorithm is

needed, it appears as though the current selected settings are reasonable.

A number of users also indicated that it would be nice to have a

switching override capability for contingencies. It is believed that this

user feedback may have been generated by the very nature of how the experiment was conducted. For example, the end user was provided with

audible tones every time the radio switched between networks. These

audible tones were utilized to help system designers verify system func2The speakers were crudely mounted to the backpack frame by directly drilling

through the speaker, which clearly modified the audio characteristics.

NASA/TM—2012-217635 28
tionality and to critique the system. The tones were also intended to

help the end user identify the network being used when evaluating the

quality of the voice provided by the communications subsystem. Under

nominal operations, these audible tones would not necessarily be generated and the switching between the networks would be transparent to

the end user. These tones, however, made it immediately apparent as

to the frequency of the switching between the networks, especially in an

environment where a loss of or fading of the wireless communications

link was common. Still, the capability to force the system to utilize one

network or the other could be useful for a contingency scenario, provided

that the manual override capability does not become a nominal operational procedure. As a result, both mission control and the astronaut

should have control over the manual override capability. In addition, the

end user needs some sort of feedback, either visual or audible, to indicate

the manual override is engaged.

5.2.3 User Interface

The user displays or human interface to the communications system

was not a target development effort or an intended evaluation criteria

for the DRATS EVA radio experiment. Still, the test subjects provided

feedback on a desired user interface to the system. The users indicated

a need for the health metric parameter conveyed to the user for each

network. This is consistent with common-day mobile communications

devices which indicate the number of bars for the wireless signal. During

the experiment, the ground station terminal did indeed have a continuous

feed for the health status of the wireless network for system evaluation

and diagnostics. The health of the wireless network was conveyed to the

user over the voice loops as desired or needed. During nominal operations, it is not expected that the user would require a continuous update

on the wireless network health status, but such information could be

useful. For instance, real-time evaluation of the signal quality may allow

the astronaut to select a different traverse path which would maintain

better signal connectivity. The information may also be necessary in a

contingency scenario. Regardless, the need for a health metric parameter

indicator (i.e., number of bars for each of the wireless communications

networks) generates a requirement for basic status information to be

provided from the communications system to the informatics system.

6 Recommendations

6.1 Environment Implications

The DRATS experiment was performed in the Arizona desert and is

a common test site for NASA analog studies. The location has historically been used due to the similarity in terrain and conditions that may

NASA/TM—2012-217635 29
be encountered at destinations beyond Earth. The landscape also has

limited man-made structures and has applicable science to perform. In

addition, for the EVA radio experiment, it presents a testing environment

where the RF spectrum is relatively under-utilized compared to urban

locations, with fewer concerns for interference with other spectrum users.

Indeed this was case for the EVA radio team when conducting the experiment. There was only one other signal in the spectrum range of interest

that needed to be avoided for possible interference.

There were, however, some difficulties encountered during the testing

that are attributed to the terrain at the Arizona test site. Debugging

and diagnostic work on the EVA radio testbed indicated symptoms of

a very high multipath environment. During one experiment, the orientation of the dipole antenna on the backpack was altered such that it

was positioned at 90 ◦to the source signal antenna. In this configuration, the radio signal strength increased and the ETX metric improved.

Such a response indicates the signal polarization had been altered or a

reflected signal was stronger than the direct path signal. The test site

landscape is free of man-made structures, which could be the source of

large signal reflections and multipath effects as commonly encountered

in an urban environment. The soil composition at the test site is primarily volcanic in nature and therefore contained a high iron concentration.

This high iron concentration in the soil generated much higher multipath

environment than anticipated. For the EVA radio testbed, the issue was

handled by changing the radio configuration parameters. The UHF radio utilized an OFDM modulation technique, which could be adjusted to

provide better multipath rejection. In order to help cope with the multipath environment, the UHF radio was configured to utilize a higher

bandwidth at the same data rate. This in turn extended the symbol

period to reduce the inter-symbol interference generated by the multipath environment. By extending the symbol period, without reducing

data rate, inter-symbol interference in a multipath environment is reduced. Therefore, for further surface radio communication development

efforts, consideration should be given to multipath effects in the radio

design. There are a number of common solutions available for multipath

mitigation and should therefore be considered for future design efforts.

For example, spread spectrum techniques may be used to aid in rejecting multipath effects or utilization of a rake receiver would enable the

system to identify and compensate for multipath signals.

6.2 Network Configuration Drivers

6.2.1 Network Data Traffic Control

During the EVA radio testing, it was determined that there is clearly

a need for data queue prioritization of different network data types.

There are a number of drivers for the data queue prioritization necessity.

NASA/TM—2012-217635 30
For example, some data types, such as voice transmissions, must be delivered with a low latency and in near real-time. Other data types, such as

archived data, will have an increased allowable latency and does not necessarily need to be delivered in real-time. In addition, bandwidth-hungry

network data, such as streaming high definition video, may swamp the

entire allocated bandwidth. Thus, the network applications must be capable of providing Quality of Service (QoS) capability in order to provide

different priority to different data flows.

For the EVA radio testbed, the need for a QoS capability was recognized during evaluation of the health metrics for the wireless network.

If the network becomes swamped with an application utilizing a large

portion of the total available bandwidth, the OLSR ETX metrics will

become blocked or delayed and therefore will not accurately describe the

health of the wireless links. Ideally, the ETX metric will represent the

quality of a route, independent of any network traffic. Indeed, De Couto

recognizes this limitation in the ETX implementation, indicating that

“[ETX] is highly sensitive to load because of the effects of unfairness

and interference on the probe broadcasts” [6]. A suggestion to solve the

issue is to implement a MAC data communication protocol sub-layer,

which supports priority traffic. The OLSR ETX messages can then be

isolated from the contending network traffic.

Recognizing the need for QoS capabilities on wireless networks for

multimedia applications, the IEEE 802.11 standard was amended in 2007

to provide such QoS enhancements to wireless networks [12], [16], [17].

Yet, hardware that supports the QoS enhancements are not readily available. As a result, an alternative method is implemented for the EVA

radio testbed. The design uses the Linux traffic control 3 utilities for

managing the transmission of packets [18]. Specifically, the EVA radio

testbed uses tc commands to manage “traffic control”. Tc is a binary

command line tool and is part of the iproute2 suite of utilities [19]. The

application is used to manipulate network configuration structures in the

Linux Kernel. Among many other uses, tc may be used to limit total

bandwidth, prefer latency sensitive traffic, or to simply prioritize the

data being sent to the network interface. For the EVA radio testbed, the

system is set up to generate Kernel traffic control parameters to handle

packet prioritization, rate limits and latency parameters. Yet, only the

capability for network data prioritization was enabled for the DRATS

experiments. The data prioritization is performed by establishing a priority queue map. Priority levels are set as follows:

1. BioNet traffic

2. OLSR messages (control messages and BMF packets)

3. VoIP audio packets

4. All other network packets (not specifically prioritized)

3Quality of Service (QoS) is often used as synonym for traffic control.

NASA/TM—2012-217635 31
Prioritization of BioNet traffic ensures that the radio switching algorithm

has all the necessary information in order to perform the switch between

radio networks. The BioNet packets handle the sensor data distribution

throughout the network. Prioritization of the OLSR messages ensures

that the network health statistics collected, or ETX parameters, are

representative of the underlying network. It is imperative that the OLSR

broadcast messages are not delayed or blocked by other packets within

the network. Finally, prioritization of the VoIP stream ensures that the

voice traffic will always take precedence over any other traffic, especially

resource-intensive traffic to help reduce the end-to-end latency. All other

network traffic has a lower priority and is not specifically prioritized by

the network configuration structures within the Linux Kernel.

6.2.2 Wireless Link Access Time

On the EVA radio system, the traffic originating from each node is

prioritized to help ensure essential near real-time data is received in a

timely manner. As discussed in Section 6.2.1, the network data QoS for

the EVA radio testbed is regulated at each network device. Yet, fundamentally, 802.11 is an access-driven network and not a time-driven

network access; the 802.11 standard does not provide a means for limiting the access time of network nodes [12]. Thus, despite the MAC layer

data prioritization, the EVA radio system as designed with the 802.11-

compliant COTS radios still has the issue where low priority data may

be delivered from one node before high priority data of another. For

example, if a large file is being transferred over the network, it may prevent other nodes from transmitting any data for an extended period. The

fragmentation configuration threshold does help to create more opportunities when another node may slip in a RTS request, but the setup does

not guarantee that one node will not utilize all the available transmit

time. The issue is further compounded when there is backlogged data,

which may be the case if all the nodes are attempting to transmit data

simultaneously. Thus, for an 802.11 EVA radio system, one needs to be

able to limit the link access time, or to provide a preemption method for

interrupting an existing link. A possible solution may be the 2007 QoS

enhancements to the IEEE 802.11 standard. Future development efforts

should evaluate the QoS enhancements as applicable to the EVA radio

design.

6.2.3 Network Packet Characterization

The OLSR algorithm determines the network topology and the expected transmission count in each direction of the link. For determining

the probability of a packet being received at the destination, the OLSR

ETX algorithm assumes constant packet sizes in the network. The ETX

predictions may be adjusted to more appropriately reflect a particular

NASA/TM—2012-217635 32
Packet Type Payload Size Notes

[bytes]

Voice:

Nominal 115 Speex VoIP data

VAD 46 “Silent Frames”

OLSR:

HELLO 44 - 48

TC 76 - 108 Variable.

Table 5. Packet Sizes for OLSR and Voice Data in the EVA Radio

System. The OLSR TC messages will increase in size as the number of

nodes in the mesh is increased. Note that an entire TC message also

includes HELLO message information.

packet size [6], but does not necessarily represent network traffic consisting of widely different packet sizes. When OLSR determines the ETX

metric, a different prediction error will be associated with different packet

sizes [6].

For the EVA radio system, the goal of the OLSR ETX metric is to

properly reflect the probability of voice data arriving at the destination.

This information is used for the radio switching algorithm. Since the

OLSR packets and the VoIP audio packets are similar in size, as shown in

Table 5, the ETX metrics accurately reflect the probability of a successful

audio packet transmission. Therefore, when using OLSR link metrics

for estimating the probability of a successful data transmission, some

consideration for the associated packet size should be given.

6.3 Delay Tolerant Networking Rationale

In the initial stages of the EVA radio design, it was assumed that

some sort of DTN implementation would be necessary for communicating with the ground station. Yet it was quickly discovered that a DTN

implementation of all the data flows was not necessary. DTN is designed

for and excels well in communication links with long delays and with links

having an approximate pre-determined range of expected transmission

delay values. DTN is not designed for or intended to be used to handle

communications links that are delayed due to the link fading in and out

as opposed to just having a constant delay associated with the packet

transmit time due to the distance between the transmitter and receiver.

As a result, DTN need not necessarily be utilized for handling traffic

flows between the nearly colocated nodes under nominal operations. For

communications between space suits, the DTN implementation is not

needed. To simplify the design, it would therefore make sense to implement DTN only on a relay station that would be handling the potentially

NASA/TM—2012-217635 33
long distance communications link to the ground station.

The initial implementation of the VoIP communication on the EVA

radio testbed was delivered using the DTN Bundle Protocol (BP). The

DTN BP is designed to be a store-and-forward overlay network. The BP

design is to help cope with intermittent connectivity and can take advantage of scheduled, predicted connectivity [20]. It was found difficult to

implement DTN with data packets associated with voice communication

information, such as VoIP traffic, due to the total latency added to the

signal by the protocol and associated overhead. It is essential that the

voice communication information be transmitted and delivered to the

other nodes in the network with as minimal delay as possible. For VoIP

applications, a delay requirement of less than 200 ms is typical [11]. During initial testing on the EVA radio testbed using the BP, delays on the

order of 250 ms could be achieved under ideal conditions, but it was not

unusual to observe latencies on the order of a few seconds. In addition,

if for some reason a disruption in the RF communication link occurs for

a prolonged period of time, an individual typically would not want old

voice data to be buffered up and transmitted. Instead, one would rather

just drop the content. The newly generated or current near real-time

voice communications data would take priority over any historical voice

data. Historical voice communications data is therefore most likely only

useful for individuals in the mission operations center for post-mission

analysis. As a result, only certain nodes (primarily only the mission control station) have a need or a use for real-time essential data, which is

deemed to be stale or has been buffered up for a long time.

Using a DTN implementation to transfer the VoIP traffic between

all the nodes, especially between two space suits, is not practical. On

the EVA radio system, the original BP implementation for the transfer

of voice data was dropped in favor of a multicast UDP connection. As

noted, a DTN implementation would be desirable for transferring the

data to a remotely-located ground station, but such a capability need

not necessarily be implemented on the space suit. For the ground station

link, one could provide those missing voice time segments as data files,

which can be downloaded/received at later times for post-mission review

and analysis. For the space suit data transfer portion of the link, the

proper solution is likely a simple intelligent buffering system to handle

the fade in/out of the wireless signal.

7 Future Work

7.1 System Configuration

7.1.1 Switching Logic

Prior to the DRATS EVA radio experiment, no effort had been devoted to properly filtering the sensor data. The health metric for the

NASA/TM—2012-217635 34
0 500 1000 1500 2000 2500 3000 3500 4000 4500

Seconds after: 2011-09-03 17:19:50

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

Wi-Fi Max ETX

SWITCH_ETX_1315084790.3949599.csv.gz

Figure 12. ETX Versus Time with Radio Switch Status, with Premature

Switching. Shaded regions indicate radio switch periods on the low data

rate network. Results indicate that filtering of the ETX values is needed.

wireless metric, the ETX value, is one such parameter that requires additional filtering. Some averaging of the ETX value is built into the

OLSR software, but adjustment of the configuration parameters also affects the performance of the OLSR system. A second stage of filtering

for use by the EVA radio switching logic is necessary to obtain the desired time-response characteristics. For system tuning of the EVA radio

switching logic, some additional damping is desired.

As indicated in Figure 4, the ETX threshold for the switch from narrowband to the wideband radio is at a value of 1.8. In Figure 12, the

shaded regions indicate that the EVA radio is utilizing the low data rate

communications link. A few of the transitions, for example at around

an elapsed time of 1250 seconds and 3200 seconds, indicate that the system returned to the wideband communications link prior to the system

achieving a stable ETX value below the required threshold. After the

transition, the ETX instability shows values well above the set threshold of 1.8. The system does indeed eventually stabilize at an acceptable

level below the 1.8 threshold, but a simple filter on the ETX parameter

for use in the switching logic would help to ensure the system does not

prematurely switch to the wideband communications link. Future work

should therefore include basic filtering of the network health metrics to

NASA/TM—2012-217635 35
reduce switchovers from transients.

7.1.2 OLSR Configuration

The ETX scheme of OLSR is not specifically intended to account for

mobility of the underlying mesh nodes. In fact, Reference [6] questions

if the ETX metric would perform well in a mobile network. For the EVA

radio testbed, the motion is slow compared to the update interval of the

HELLO and TC messages. Care was taken to ensure the topology control

and HELLO messages are updated at a rate faster than the system dynamics. The motion of a person walking occurs at only modest speed of

around 2 m/s, so it is possible to propagate the OLSR network metrics

faster than the system dynamics. As a result, the ETX metric can be

applied to the mobile mesh consisting of walking people. Still, the configuration values can be further modified to more accurately describe the

underlying system. During the DRATS experiments, it was observed

that the TC message interval most likely should have been modified.

These observed characteristics may be an artifact of the environment

due to the rate at which the radio signal is lost and re-established. To

maintain consistency between the test runs, the parameters were kept at

a fixed value throughout the DRATS experiments. Future tests should

consider increasing the update rate of the TC messages and perhaps reducing the corresponding validity time. In addition, future work with

OLSR-enabled mobile networks should consider inclusion of metrics provided by the 802.11 interface card, such as the number of retransmissions

per packet [6]. During the EVA radio DRATS experiments, the number of retry transmissions was logged. Unfortunately, the COTS Wi-Fi

device used in the testbed does not properly report the number of retransmissions and appears to be unsupported by the driver.

7.1.3 OLSR Multicast Configuration

The forwarding mechanism for the BMF plug-in may be set to use either a “Broadcast” or a “UnicastPromiscuous” mode. The configuration

of the BMF plug-in defaults to a “Broadcast” forwarding mechanism. On

the EVA radio testbed, the parameter was not specifically set, resulting

in the default configuration. According to the BMF documentation, the

parameter most likely should have been set to “UnicastPromiscuous” for

the wireless network [21]:

“In the ‘UnicastPromiscuous’ mode, packets are forwarded

(unicast) to the best candidate neighbor; other neighbors listen promiscuously. IP-local broadcast is not used. This saves

air time on 802.11 wireless networks, on which unicast packets are usually sent at a much higher bit rate than broadcast

packets (which are sent at a basic bit rate).”

NASA/TM—2012-217635 36
The retransmission of the received packet is handled by the forwarding

mechanism configuration parameter. Thus, for the EVA radio testbed,

retransmissions were sent in a broadcast fashion. The BMF plug-in

does send the original messages encapsulated into a UDP packet and

are therefore delivered using unicast. Thus, multi-hop links may benefit

from the “UnicastPromiscuous” setting for the BMF module. Although

the communications links during the EVA radio tests were primarily

direct, some performance increase may be achieved with the alternative

configuration and should therefore be evaluated.

7.1.4 Radio Configuration

The wireless packet fragmentation threshold configuration setting for

the Wi-Fi radio should be revisited in future EVA radio efforts. When

fragmentation is enabled, the source network interface device divides the

802.11 frames into smaller chunks or fragments. These fragments are

sent separately to the destination, with each fragment receiving a separate acknowledgment. Fragmentation generates additional overhead and

therefore decreases performance in an ideal environment. In a very noisy

environment, the fragmentation threshold setting increases performance

by allowing packets to get through interference bursts. The configuration value utilized on the EVA radio testbed was originally determined

and verified in an urban environment. During the DRATS tests in the

desert environment, verification of the fragmentation threshold value was

not performed. Future work to determine an appropriate value for the

expected environment should be performed. In addition, as already mentioned in Section 3.3.3, 802.11 does not apply fragmentation to multicast

or broadcast frames [12]. Also, the OLSR implementation encapsulates

multicast information into unicast packets. Further work is necessary

to properly characterize how fragmentation affects the link performance

and the associated added network overhead for multicast messages distributed by OLSR.

7.2 Localization

The use of OLSR may bring the additional benefit of localization information or supplement position information systems. Indeed, a number of individuals are attempting to use OLSR mesh connectivity information to determine position information using convex optimization

methods [22], [23]. These works attempt to estimate the unknown node

positions for dense mesh networks. For sparse networks, such as the few

node network expected for space exploration, additional information is

likely necessary. Range information or time difference of arrival, for example, may be used with trilateration methods to determine position.

Some research works utilize OLSR to distribute the routing and position

information for simultaneous routing and localization [24], [25], [26]. FuNASA/TM—2012-217635 37
ture work should therefore consider the additional benefits OLSR may

provide in terms of localization/position information.

If position or velocity information is available, there are additional

modifications to the OLSR implementation that may benefit a mobile

mesh. As discussed in Section 3.3.1, OLSR needs to exchange the topology control information and receive the HELLO messages faster than the

change in the layout of the mobile nodes in the mesh. This update

rate must be increased for a highly mobile mesh. Yet, knowledge of

the motion and the corresponding velocity could potentially be used to

adaptively change the rate at which messages are transmitted between

the nodes. Nodes which are in motion could send/receive HELLO messages at a higher rate than those with a near stationary average velocity.

An increased update rate for nodes that are in motion may improve the

link characterization. Reducing the update rate for stationary nodes will

also eliminate unnecessary packet transmissions and reduce the utilized

bandwidth. Future work should evaluate the potential increase in performance achieved when positional information is used for variable OLSR

packet update rates.

7.3 Operational Concepts

A number of operational concepts may be considered that are enabled

by the multi-hop ad hoc mesh routing capabilities described in this work.

These multi-hop scenarios may potentially extend the high data rate

operational range. For example the “data mule” or remote relay concept

could be envisioned. In one case, the multi-hop relay is achieved by a

mobile node containing a store-and-forward capability. In the remote

relay concept, a portable relay terminal or astronaut is used to relay

both high data rate information and voice communications data. As

already stated in Section 5.2.1, the use of an astronaut as a relay asset

for extended periods is not likely. Yet, other operational concepts may

be explored, such as for short durations or to “leap frog” across an area

with limited connectivity. Furthermore, with the addition of portable

communication terminals used for communications relay purposes, the

fixed positional nature of these nodes could also aid the localization

problem.

7.4 Data Analysis

During the DRATS EVA radio experiment, a number of parameters

were collected for debugging, performance analysis and research purposes. Currently, only a preliminary data analysis has been performed

on a small subset of the data collected during the experiment. Future

efforts should be directed at a more complete data analysis. Refer to

Appendix C for an explanation of the data collected during the experiment.

NASA/TM—2012-217635 38
8 Concluding Remarks

The EVA Radio Team designed and built a radio testbed that allowed for extensive field testing in Flagstaff, Arizona during the month of

September 2011. The primary goal of this testing was to exercise the performance of the dual-band radio design, while operating in a simulated

manned exploration environment. There were no major malfunctions or

events that prevented the team from fully completing the full battery of

tests over the two-week period. Multiple simulated exploration sorties

were performed by both the team itself and objective subjects, including

actual crew members from the astronaut corps.

Each wireless interface comprising the EVA radio system individually

worked well, even under these mobile test scenarios. External interference was never an issue, and the wireless coverage areas were consistent

throughout the two-week period. The 802.11 ad hoc network protocol performed quite well, even under the highly dynamic test scenarios,

which included many forced network dropouts and hidden node situations. The switching between the interfaces, guided by OLSR, generally

worked well, but there were a few occasions when the hand-off between

the interfaces produced a noticeable degradation in the voice quality just

prior to a transition to the contingency radio. The team attributes this

degradation to the switching algorithm, the OLSR configuration settings

and the lack of filtering on the health metrics used for the switching algorithm. In general, the Speex audio quality was excellent, and several

crew members commented that the voice quality was an upgrade to the

existing ISS radio system.

The switching criteria used to trigger a jump of the EVA radio system from one interface to the other is the primary target for system

improvement. The team used an appropriate set of OLSR link quality

thresholds to trigger a switch, but several tests indicated these metrics

were much more dynamic than originally expected. Several instances of

“chattering” between the two interfaces were initially observed, which

can be easily corrected by implementing standard sensor filtering techniques and by fine-tuning the OLSR configuration parameters. The data

collected during the field tests will prove to be essential for establishing

the system response characteristics for tuning these filters and for selecting additional switching criteria.

Although not an issue during the DRATS field tests, during system development efforts, the team had to experiment extensively with

the 802.11 adapter software drivers. The software drivers are especially

unpredictable when used in ad hoc mode. The team did generate a configuration suitable for the demonstrations, but this setup restricted the

team’s ability to operate the 802.11 radios in several different modes of

interest. A solution is to generate a set of in-house communication radios,

in which the developers have complete insight and control. The use of

custom radios for future tests would not only alleviate the driver issues,

NASA/TM—2012-217635 39
but it would further allow incorporating physical network layer metrics into the link switching criteria. Incorporation of the physical layer

metrics, which are not typically available when using COTS hardware,

should improve the performance of the wireless interface link switcher

algorithms. For example, physical layer hardware metrics may allow for

a more accurate assessment of the link quality.

In summary, this work has demonstrated a dual-band radio with intelligent switching capabilities can effectively be used to achieve high

data rates and extended operational range capabilities for mobile users.

Simultaneous voice and data can be effectively transferred over the same

limited bandwidth wireless connection and the OLSR ETX metrics can

be used as a metric for intelligent switching between two different capability wireless mobile networks.

NASA/TM—2012-217635 40
Appendix A

Configuration Management

Proper version control or configuration management is essential for

any project utilizing software, regardless of the project size. Version

control provides among many benefits a method for tracking and locking changes and greatly enhances parallel concurrent development. The

EVA radio development has utilized a complete configuration management system from the initial source code development through the actual

software deployment. In order to fully appreciate the software development and deployment system implemented, some background knowledge

is necessary. The EVA radio configuration management system consists

of the following core technologies:

• Version Control Server

• Debian Source and Binary Packages

• Debian Package Management System

• Advanced Packaging Tool

• Automated Builder

A version control server is a system that manages changes to files, maintains current and previous file revisions and allows collaborative modification of the same files by a team of developers. A version control system

typically provides the ability to revert to previous revisions, compare differences between revisions and may also merge different versions between

multiple developers. Typically, a version control system is used to handle

software source code, but is also readily applied to configuration files and

documentation. A number of open source systems exist. The EVA radio

system utilized the Bazaar (BZR) distributed version control system.

To promote modular software code development, each software daemon, library or configuration parameters for the EVA radio system is

distributed as a Debian package. A Debian source package is first created, from which a Debian binary package is then created for distribution

to the desired hardware platform. A Debian binary package (.deb file)

is simply a group of files, which is maintained as a single archive.A1

The package contains both the package data and the package metadata

and installation/removal information [27]. The binary Debian package

may contain for example the software executable (typically a compiled

binary) and any documentation or configuration files. A Debian source

package contains all the information necessary to build a binary package.

A1The archive file within a Debian package contains two tarball (.tar) files compressed with GNU zip utility, one containing the data and the other the corresponding

control and configuration information for the package.

NASA/TM—2012-217635 41
The source package consists of the original software source files and the

information required to build or compile the binary package. Although

a binary package is the most typical and convenient to the majority of

users, the source package format allows for a binary package to be created for a number of different operating system versions, architectures,

or even compiled/linked against other different library versions. Thus,

by starting first with a source package, the development method not only

allows for complete flexibility and control over the deployed software, but

additionally provides a further degree of version control and traceability,

as the original software source used to create the binary package is also

attached.

Once the Debian packages are generated, the Debian Package Management System, coupled with the Advanced Packaging Tool (APT), is

used for distribution and installation of the software. The Debian Package Management System (dpkg) is a utility to install and remove software packages. The package management system automates the process

of maintaining and installing software packages in a consistent manner.

The system controls dependencies, conflicts and package versions. In

addition, the system ensures proper installation and clean up from prior

software package installations. APT provides a front-end to dpkg with

further networking enhancements, including the retrieval and installation

of multiple Debian packages from a networked software package repository. For example, to install a hypothetical package called eva-example,

one would issue the command apt-get install eva-example. The

command instructs APT to query the software repository and download the software package for automated installation by dpkg. In addition, APT also performs the retrieval of additional software packages

from the networked software repository to satisfy package dependency requirements. During the installation process, if the package management

system determines that additional software dependencies must also be

installed, APT searches the software repository for the dependencies and

downloads the software packages as necessary for installation. The complete system allows for a complex system of modular software packages

to be installed, maintained and versioned in a robust fashion.

The final core technology utilized in the EVA radio software development flow is a networked automated builder. A networked software build

server ensures that all deployed software packages are compiled against

a consistent set of software libraries with a consistent set of development

tools. Furthermore, an automated builder simplifies the build/test/deployment process as the entire procedure is extracted away from the software developer. The automated builder system may for example, autogenerate the Debian source package, compile the architecture-dependent

binary Debian packages and then push the resulting packages to the

APT repository. For the EVA radio development, the open software

project “Buildbot” is used by the entire development team. Buildbot

is an open source “continuous integration system designed to automate

NASA/TM—2012-217635 42
Source Code Version Control

Server

APT Repository

Debian Source to

Binary .deb

Automated Builder

Testbed

Nodes

Development

Workstations

Figure A1. Software Development Flow

the build/test cycle” [28]. A master buildbot builder triggers from commits to the software version control system. Automated builds are then

distributed to a set of slave builders (either virtual or physical) for the

desired set of processor architectures and operating systems. For the

EVA radio development efforts, automated slave builders were setup for

the i686 and x86-64 platforms to accommodate flexibility in development

workstation and testbed platform hardware.

The software development flow process for the EVA radio system is

depicted in Figure A1. In the software development process, the developer first creates the desired software source files as is normally done with

any software development effort. The software files are then submitted

to a version control server for source code configuration management.

The source project is then further modified by the developer to allow

auto-generation of a Debian Source Package. In order to generate a

Debian Source Package, a simple description file must be created, which

describes the software package and necessary package build and run-time

dependencies. In the Debian nomenclature, the package description information is contained within a “debian/control” file.

An example Debian Control file is shown in Listing 1. The first block

describes the source package and the dependencies required to build the

binary package. The second block describes the binary package generated from the source package. A Debian source package may be used

to generate multiple binary packages. In the example, a single binary

package is listed and the corresponding required packages necessary for

run-time are also listed. Within the Debian Control file, a number of additional description fields may also be specified. The example provided

only contains a minimal representative set of control fields. Further information on the Debian package structure and additional control fields

is available in References [27], [29], [30].

NASA/TM—2012-217635 43
Source : eva - example

Section : net

Priority : extra

Maintainer : Software Developer < nospam@NASA . gov >

Build - Depends : debhelper ( >= 7) , cdbs , g ++ , python

Standards - Version : 3.8.3

Package : eva - example

Architecture : any

Depends : ${ shlibs : Depends }, ${ misc : Depends },

python ( >=2.6) , python - daemon , net - tools ,

speex

Description : Example software package for EVA .

This is an example Debian software package for EVA .

.

Listing 1. Example Debian Control File

Appendix B

Topographical Map Generation

The topographical maps used in the ground station visualization program are generated using Digital Elevation Map (DEM) information

available from the United States Geological Survey (USGS) in GeoTIFF

format. The topographical maps are only intended for visualization purposes and are not used for any portion of the algorithms implemented on

the EVA radio testbed. Described here is the procedure used to generate

the topographic map tiles used in the EVA radio visualization program.

First, data is obtained from the USGS. The National Elevation

Dataset (NED) 1/3 arc second data is downloaded by using the USGS

National Map Seamless Server Viewer at http://seamless.usgs.gov.

The web interface allows NED information to be obtained for a rectangular area described by a set of latitude and longitude coordinates. To

aid in automating the download process for multiple tiled regions, a custom C#.net utility was created. The utility program GetUsgsDrats.exe

takes as input parameters the latitude and longitude, the number of tiles

to download and the desired size for each tile. These parameters are then

passed to the Seamless Viewer to download each desired tile.

Once the DEM information has been obtained, topographic contour

lines and shading of the elevation levels is then generated into an image

file. Post-processing of the DEM files is obtained by using the open

source Mirone [31] software toolB1, which is a front-end interface to

the open source Geospatial Data Abstraction Library (GDAL). Using

Mirone, the GeoTIFF files are used to generate contours for all of the

B1Mirone may be obtained from http://w3.ualg.pt/~jluis/mirone

NASA/TM—2012-217635 44
tiled images at regular-spaced intervals and to generate a color shading

between the minimum and maximum elevation observed in the entire

set of downloaded tiles. Using Mirone, a set of image files are generated

which are representative of topographic information. The open source

ImageMagickB2 suite of utilities is then used to aid in cropping and resizing the resolution of the Mirone-generated image files.

B.1 Detailed Instructions

An abbreviated step-by-step set of instructions for generating the

topographic tile images is presented as follows:

1. Download USGS DEM files using GetUsgsDrats.exe

(a) Enter latitude/longitude, tile size and number of tiles.

(b) Start the program and select Download to save .zip file.

(c) Click Next to repeat the process.

2. Extract downloaded .zip files.

3. Start the Mirone software tool.

(a) Open the extracted GeoTIFF files.

(b) For each downloaded GeoTIFF file, note the maximum/minimum elevation to determine the limits for the given set of

tiles. Grid Tools — Contours — Contour Tool.

(c) Return to TIFF files, and for each:

i. Select Palette TB. Enter the maximum/minimum elevation values for the set to make color gradients consistent

throughout the entire set of tiles.

ii. Select Image — Illuminate — GMT GrdGradient. Accept the default values.

iii. Select Grid Tools — Contours — Contour Tool.

iv. Select Add Common Charting Intervals. Add any other

desired contour elevation value by typing in value in Single input form field.

v. Select Apply.

vi. Select File — Export. And save image as .png at the

maximum available resolution.

(d) Use ImageMagick to remove scale area from tiles:

convert -crop 6935x7271+490+73 INPUT.png OUTPUT.PNG

(e) Rename the images files to the format:

USGS LAT LON LAT-SPAN LONG-SPAN .PNG

where the latitude and longitude are for the center of the tile.

B2ImageMagick is available from http://www.imagemagick.org

NASA/TM—2012-217635 45
Note that the custom utility program RenamePngs.exe will

aid in the file renaming process.

(f) Use ImageMagick to scale the image files to desired size:

convert -scale 25% USGS xxx.PNG USGS yyy.PNG

NASA/TM—2012-217635 46
Appendix C

Experimental Data Description

During operation of the EVA radio testbed, a number of parameters

and sensor data is collected to aid in system development and performance analysis. A brief description of the data collected and file formats

is described here.

In general, file names are of format TYPE timestamp.ext. The timestamp format is in POSIX time, or the number of elapsed seconds since

epoch, 01 Jan. 1970. The timestamp is from the system time on the

device which the data was recorded. The system time of all the nodes

were synchronized at the start of the DRATS 2011 outing via network

time protocol, but were left free-running without updates throughout the

duration of all the tests. The offset in the system time can be determined

from the GPS log files, where both the system time and the time derived

from GPS is recorded. The file extension may be either .bin for raw

binary, or representative of the contents such as .csv for comma separated values or .mp4 for encoded video or .spx for Speex encoded audio.

All text files contain a header to indicate the format of the data within

the log file. All binary format files adhere to standardized formats.

Audio Data Files of type AUDIO contain Speex-encoded audio data as

it was received at the destination node. Playback of these files allows a

user to hear the audio as it was played to the test subject via the external

speakers during the system test.

Configuration Files Any of the configuration files that may have

been altered prior to a test are copied for documentation purposes. The

configuration files help to confirm settings utilized on a particular run.

The configuration files include parameters pertaining to the audio encoding, the link switcher settings, the OLSR configuration, and the network

interface configuration.

Position Data Files of type NMEA contain the raw GPS data in NMEA

format as transmitted by the GPS every second. Files of type GPS contain

an extracted set of positional information which was distributed across

the wireless network to the base station.

OLSR Data Files of type OLSR DOTx has output from the OLSR daemon. This data is the raw OLSR output from a text plug-in and contains

information on the network topology and the forward and neighbor link

quality from which the ETX metrics are derived. The information in this

file is parsed and then extracted to generate network health information

NASA/TM—2012-217635 47
to be used by the link switcher algorithm. Files of type OLSR SWITCH

contain the parsed OLSR information and is the information which is

distributed throughout the network for use by the link switcher algorithm on each node.

Radio Connectivity Information A number of data file log types

exist for determining the radio and network connectivity information.

Logs pertaining to radio connectivity and health information are found

in files of type: IFCONFIG, IWCONFIG, SNMP IFCONFIG and SNMP RSSI.

The IFCONFIG and IWCONFIG file types pertain to the 2.4 GHz radio.

These logs contain information as generated by the Unix ifconfig and

iwconfig commands. The SNMP X file types pertain to the 900 MHz

radio. These logs contain information similar to that generated by the

Unix ifconfig and iwconfig commands.

Raw Network Traffic Files of type TCPDUMP contain all of the raw

network data which was sent over the network interface. The data files

are generated with the tcpdump utility and may be read using libpcap

capable utilities such as wireshark. The data files contain a .bin extension to indicate they are of a binary format.

Switching Algorithm Status Files of type SWITCH and SWITCH ETX

contain information from the switching algorithm. Each time a switch

between the high data rate and low data rate networks is performed,

a timestamp and status information is logged to the SWITCH file. The

SWITCH ETX file type contains the network ETX information which the

switching algorithm uses on each cycle of the routine.

Video Files Files of type VIDEO are MPEG-4 video files as recorded on

the mobile nodes. The video files are approximately 10-second snapshots.

NASA/TM—2012-217635 48
Appendix D

Acronyms and Abbreviations

AP Access Point

APT Advanced Packaging Tool

AEC Acoustic Echo Cancellation

BER Bit Error Rate

BZR Bazaar

BMF Basic Multicast Forwarding

BP Bundle Protocol

BPSK Binary Phase Shift Keying

CCSDS Consultative Committee for Space Data Systems

COTS Commercial Off-The-Shelf

CTS Clear To Send

C&DH Command and Data Handling

DRATS Desert Research and Technology Studies

DTN Delay-Tolerant Networking

DTX Discontinuous Transmission

DEM Digital Elevation Map

ETX Expected Transmission Count

EVA Extravehicular Activity

GDAL Geospatial Data Abstraction Library

GPP General Purpose Processor

GPS Global Positioning System

GRC Glenn Research Center

IEEE Institute of Electrical and Electronics Engineers

ION Interplanetary Overlay Network

ISM Industrial, Science and Medical

ISS International Space Station

ITU International Telecommunication Union

IP Internet Protocol

MAC Media Access Control

NASA National Aeronautics and Space Administration

NEA Near-Earth Asteroid

NASA/TM—2012-217635 49
NED National Elevation Dataset

NMEA National Marine Electronics Association

OLSR Optimal Link State Routing

OFDM Orthogonal Frequency-Division Multiplexing

PAS Power, Avionics, and Software

QoS Quality of Service

RF Radio Frequency

RTP Real-time Transport Protocol

RTS Request To Send

TC Topology Control

UDP User Datagram Protocol

UHF Ultra High Frequency

USGS United States Geological Survey

VAD Voice Activity Detection

VoIP Voice over Internet Protocol

Wi-Fi Wireless Fidelity (IEEE 802.11 wireless networking)

NASA/TM—2012-217635 50
Appendix E

References

1. Concept of Operations for External Wireless Communication System. D684-14338-01, The Boeing Company, November 2010. Draft.

2. Clausen, T.; and Jacquet, P.: Optimized Link State Routing Protocol (OLSR). RFC 3626, INRIA, October 2003. URL

http://www.ietf.org/rfc/rfc3626.txt.

3. OLSR Development Team: OLSRD, An adhoc wireless mesh routing

daemon. URL http://www.olsr.org.

4. Tønnesen, A.: Implementing and extending the Optimized Link

State Routing Protocol. Master thesis, University of Oslo, 2004.

5. OLSR Development Team: olsrd.conf - Configuration file

for olsrd. Linux Manual Pages, December 2004. URL

http://www.olsr.org/docs/olsrd.conf.5.html.

6. De Couto, D. S. J.: High-Throughput Routing for Multi-Hop Wireless Networks. Ph.D. Thesis, 2004.

7. De Couto, D. S. J.; Aguayo, D.; Bicket, J.; and Morris,

R.: A High-Throughput Path Metric for Multi-Hop Wireless Routing. Proceedings of the 9th ACM International

Conference on Mobile Computing and Networking (MobiCom ’03), San Diego, California, September 2003. URL

http://pdos.csail.mit.edu/papers/grid:mobicom03.

8. Xiph.Org Foundation: Speex: A Free Codec For Free Speech. URL

http://www.speex.org.

9. Valin, J.-M.: The Speex Codec Manual. Xiph.Org Foundation, 2007.

URL http://www.speex.org/docs/manual/speex-manual.pdf.

10. ITU-T Recommendation G.114. , International Telecommunication

Union, 1993.

11. Ahson, S.; and Ilyas, M., eds.: VoIP Handbook: Applications, Technologies, Reliability, and Security. CRC Press, 2009.

12. IEEE 802.11 Working Group: IEEE Standard for Information

technology– Telecommunications and information exchange between systems– Local and metropolitan area networks– Specific

requirements– Part 11 Wireless Medium Access Control (MAC) and

Physical Layer (PHY) Specifications. IEEE Std 802.11-2007, IEEE,

New York, June 2007.

NASA/TM—2012-217635 51
13. BioServe Space Technologies: BioNet Software Framework. URL

http://www-bioserve.colorado.edu.

14. ION Development Team: Interplanetary Overlay Network. URL

http://www.openchannelsoftware.com/projects/ION.

15. Cerf, V.; Burleigh, S.; Hooke, A.; Torgerson, L.; Durst, R.; Scott,

K.; Fall, K.; and Weiss, H.: Delay-Tolerant Networking Architecture. RFC 4838, Jet Propulsion Laboratory, April 2007. URL

http://tools.ietf.org/pdf/rfc4838.pdf.

16. IEEE 802.11 Working Group: Unapproved Draft Amendment Standard for Information Technology– Telecommunications and Information Exchange Between Systems–LAN/MAN Specific Requirements–

Part 11 Wireless Medium Access Control (MAC) and Physical Layer

(PHY) specifications: Medium Access Control (MAC) Quality of

Service (QoS) Enhancements. P802.11e/D13.0, IEEE, January 2005.

Replaced by approved draft 802.11e/D13.0.

17. Mangold, S.; Choi, S.; Klein, O.; Hiertz, G.; and Stibor, L.: IEEE 802.11e Wireless LAN for Quality of Service. Florence, Italy, vol. 1, Feb 2002, pp. 32–39. URL

http://www2.ing.unipi.it/ew2002/proceedings/H2006.pdf.

18. Brown, M. A.: Traffic Control HOWTO. Online, October 2006. URL

http://linux-ip.net/articles/Traffic-Control-HOWTO.

19. iproute2. The Linux Foundation URL http://linuxfoundation.

org/collaborate/workgroups/networking/iproute2, November

2009.

20. Scott, K.; and Burleigh, S.: Bundle Protocol Specification. RFC

5050, The MITRE Corp. and the Jet Propulsion Laboratory, November 2007. URL http://tools.ietf.org/pdf/rfc5050.pdf.

21. Tromp, E.: Basic Multicast Forwarding Plugin for OLSRD. BMF

Plugin Readme File, Version 1.7.0.

22. Ermel, E.; and Muhlethaler, P.: Using OLSR Multipoint

Relays (MPRs) to estimate node positions in a Wireless

Mesh Network. Research Report RR-6072, INRIA, 2006. URL

http://hal.inria.fr/inria-00121425/en.

23. Doherty, L.; Pister, K. S. J.; and El Ghaoui, L.: Convex position

estimation in wireless sensor networks. INFOCOM 2001. Twentieth

Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, vol. 3, 2001, pp. 1655–1663.

24. Soga, K.; Takenaka, T.; Terashima, Y.; Mineno, H.; and Mizuno, T.:

OLSR-L: Optimized Link State Routing and Localization. CISIS’10,

2010, pp. 253–260.

NASA/TM—2012-217635 52
25. Takenaka, T.; Mineno, H.; Tokunaga, Y.; Miyauchi, N.; and Mizuno,

T.: Performance Evaluation of Optimized Link State Routing-based

Localization. IPCCC’07, 2007, pp. 150–159.

26. Mineno, H.; Soga, K.; Takenaka, T.; Terashima, Y.; and Mizuno, T.:

Integrated protocol for optimized link state routing and localization:

OLSR-L. Simulation Modelling Practice and Theory, 2011, pp. 1711–

1722.

27. Jackson, I.; Schwarz, C.; and Morris, D. A.: Debian Policy Manual.

URL http://www.debian.org/doc/devel-manuals#policy.

28. Buildbot Development Team: Buildbot: build/test automation.

URL http://buildbot.net.

29. Rodin, J.; and Aoki, O.: Debian New Maintainers’ Guide. URL

http://www.debian.org/doc/devel-manuals#maint-guide.

30. Nussbaum, L.: Introduction to Debian Packaging. URL

http://www.debian.org/doc/devel-manuals#packaging-tutorial.

31. Luis, J.: Mirone: A multi-purpose tool for exploring grid data. Computers and Geosciences, vol. 33, no. 1, 2007, pp. 31 – 41.

NASA/TM—2012-217635 53
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-08-2012 

2. REPORT TYPE

Technical Memorandum 

3. DATES COVERED (From - To)

4. TITLE AND SUBTITLE

EVA Radio DRATS 2011 Report 

5a. CONTRACT NUMBER

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S)

Swank, Aaron, J.; Bakula, Casey, J. 

5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

WBS 854319.04.03.02.02 

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-18280 

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-217635 

12. DISTRIBUTION/AVAILABILITY STATEMENT

Unclassified-Unlimited 

Subject Category: 32 

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

In the Fall of 2011, National Aeronautics and Space Administration (NASA) Glenn Research Center (GRC) participated in the Desert 

Research and Technology Studies (DRATS) field experiments held near Flagstaff, Arizona. The objective of the DRATS outing is to

provide analog mission testing of candidate technologies for space exploration, especially those technologies applicable to human 

exploration of extra- terrestrial rocky bodies. These activities are performed at locations with similarities to extra-terrestrial conditions. This 

report describes the Extravehicular Activity (EVA) Dual-Band Radio Communication System which was demonstrated during the 2011 

outing. The EVA radio system is designed to transport both voice and telemetry data through a mobile ad hoc wireless network and employs 

a dual-band radio configuration. Some key characteristics of this system include: 1. Dual-band radio configuration. 2. Intelligent switching 

between two different capability wireless networks. 3. Self-healing network. 4. Simultaneous data and voice communication.

15. SUBJECT TERMS

Wireless communication; Switching; Communication networks; Extravehicular activity 

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF

 ABSTRACT

UU 

18. NUMBER

 OF 

 PAGES

60 

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