THE PENNSYLVANIA STATE UNIVERSITY

SCHREYER HONORS COLLEGE

DEPARTMENT OF ELECTRICAL ENGINEERING

GEOPEBBLE WIRELESS SEISMIC SENSOR WEB

WIRELESS NETWORK DEVELOPMENT

RICHARD SCOTT TEAL

SPRING 2012

A thesis submitted in partial fulfillment

of the requirements for a baccalaureate degree

in Electrical Engineering with honors in Electrical Engineering

Reviewed and approved* by the following:

Sven G. Bilén Associate Professor of Engineering Design, Electrical Engineering, and Aerospace Engineering Thesis Supervisor

John D. Mitchell Professor of Electrical Engineering Honors Adviser

* Signatures are on file in the Schreyer Honors College.

Page i

Abstract This thesis covers the development of the wireless sensor network that will be used by the

GeoPebble Wireless Seismic Sensor Network. The NSF-funded GeoPebble project requires a

wireless network capable of sending large amounts of seismic data from as many as 150

separate geophysical sensing nodes scattered across a physically large area. A wireless network

must be specially designed to meet the requirements of this system. In this thesis, the system

requirements are defined, hardware and network type are specified from the requirements,

and a networking protocol is specified to enable communication between the nodes and a

central computer. Of particular interest is the use of time-division multiple-access techniques to

achieve high data throughput during periods of fast seismic sampling. Finally, the specified

network is simulated, and the results of the simulation are presented and evaluated on how

well they meet the specified requirements.

Page ii

I. Contents Abstract ............................................................................................................................................ i

I. Contents....................................................................................................................................ii

II. List of Figures ........................................................................................................................... iv

III. List of Tables ......................................................................................................................... v

1 Introduction ............................................................................................................................. 1

1.1 GeoPebble Project Background ....................................................................................... 1

1.2 Goals ................................................................................................................................. 2

1.3 Driving Requirements ....................................................................................................... 2

1.4 Simulation Goals ............................................................................................................... 3

1.5 Deliverables ...................................................................................................................... 3

2 Background .............................................................................................................................. 5

2.1 Network Technologies...................................................................................................... 5

2.2 Reason for Moving to Wireless ........................................................................................ 5

2.3 Wireless Technology Selection Metrics ........................................................................... 5

2.4 Wireless Technology Options ........................................................................................... 7

2.5 Potential Technologies ..................................................................................................... 7

2.5.1 ZigBee ........................................................................................................................ 7

2.5.2 UWB .......................................................................................................................... 8

2.5.3 WiMax ....................................................................................................................... 8

2.5.4 Wi-Fi .......................................................................................................................... 8

3 Solution .................................................................................................................................... 9

3.1 Wireless Technology Choice............................................................................................. 9

3.2 Network Topology Definition ........................................................................................... 9

3.3 Network Protocol Definition .......................................................................................... 10

3.4 Operation States ............................................................................................................ 10

3.4.1 Network Set Up ....................................................................................................... 10

3.4.2 Continuous Sampling Mode .................................................................................... 11

3.4.3 Burst Sampling Mode .............................................................................................. 11

3.5 Extension to Transport Layer: Using TDMA over Wi-Fi .................................................. 11

3.6 Application Layer: Packet Types and Specifications ...................................................... 11

3.6.1 General Packet Specification .................................................................................. 12

3.6.2 Introduction and Welcome Packets........................................................................ 13

3.6.3 Burst Mode Data Packet ......................................................................................... 14

3.6.4 Continuous Mode Data Packet ............................................................................... 14

3.6.5 Status Packets ......................................................................................................... 15

3.6.6 Command Packet .................................................................................................... 16

Page iii

3.7 Selection of Hardware .................................................................................................... 16

3.7.1 Hardware Selection Metrics ................................................................................... 17

3.7.2 Hardware Options ................................................................................................... 18

3.7.3 Hardware Selection ................................................................................................. 19

3.7.4 Relevant Specifications for Simulation ................................................................... 20

4 Results and Evaluation........................................................................................................... 21

4.1 Wi-Fi Radio Physical Testing ........................................................................................... 21

4.1.1 Preparation ............................................................................................................. 21

4.1.2 Experimental Setup and Procedure ........................................................................ 22

4.1.3 Results ..................................................................................................................... 23

4.2 Selection of Simulation Environment............................................................................. 28

4.2.1 Simulation Environment Options ............................................................................ 28

4.2.2 Simulation Environment Choice ............................................................................. 28

4.3 Simulator Code ............................................................................................................... 29

4.3.1 Creation of the Basic Model ................................................................................... 29

4.3.2 Implementing the Model in Various States ............................................................ 29

4.4 Simulation Results .......................................................................................................... 30

4.4.1 Simulation of Burst Mode ....................................................................................... 30

4.4.2 Simulation of Bulk TCP Transfers ............................................................................ 34

5 Conclusions and Future Work ............................................................................................... 34

5.1 Conclusions for UDP Testing .......................................................................................... 34

5.2 Conclusions for Simulation Testing ................................................................................ 35

5.3 Final Conclusions ............................................................................................................ 36

5.4 Future Work ................................................................................................................... 36

6 References ............................................................................................................................. 37

7 Code Appendix ....................................................................................................................... 38

7.1 Python XBee Library ....................................................................................................... 38

7.2 Burst Test Simulation Code ............................................................................................ 41

7.3 TCP Bulk Test Code (no rate limiting) ............................................................................. 47

7.4 TCP Bulk Test Code (rate limiting) .................................................................................. 52

Page iv

II. List of Figures Figure 1: Geode Wired Distributed Sensor Network ...................................................................... 1

Figure 2: Comparison of Wireless Technologies, chart from [3] .................................................... 7

Figure 3: Extended-Star Topology ................................................................................................... 9

Figure 4: OSI Model ....................................................................................................................... 10

Figure 5: 10,000-packet UDP Test w/ 98.38% success, transmission every 100 ms, 10 sec per tick

shown ............................................................................................................................................ 23

Figure 6: 10,000-packet UDP Test w/ 98.38% success, transmission every 100 ms, 1 sec per tick

shown ............................................................................................................................................ 23

Figure 7: 10,000-packet UDP Test w/ 98.38% success, transmission every 100 ms, 100 ms per

tick shown ..................................................................................................................................... 24

Figure 8: 1000-packet UDP Test w/ 99.9% success, transmission every 50 ms, 1 sec per tick

shown ............................................................................................................................................ 24

Figure 9: 1000-packet UDP Test w/ 99.9% success, transmission every 50 ms, 100 ms per tick

shown ............................................................................................................................................ 25

Figure 10: 1000-packet UDP Test w/ 99.9% success, transmission every 20 ms, 1 sec per tick

shown ............................................................................................................................................ 25

Figure 11: 1000-packet UDP Test w/ 99.9% success, transmission every 20 ms, 100 ms per tick

shown ............................................................................................................................................ 26

Figure 12: Histogram of time between received packets, as measured by Wireshark ................ 27

Figure 13: Sensor Node Simulated Layout .................................................................................... 29

Figure 14: Initial Network ............................................................................................................. 31

Figure 15: Building Routing Tables ............................................................................................... 31

Figure 16: Fully Active Burst Mode ............................................................................................... 31

Figure 17: Partial Snapshot of Burst Mode ................................................................................... 31

Figure 18: Burst Mode, UDP transmission every 100 ms, 10 ms per tick..................................... 32

Figure 19: Burst Mode, UDP transmission every 100 ms, 100 ms per tick .................................. 32

Figure 20: Burst Mode, UDP transmission every 100 ms, 100 ms per tick, all packets from all

nodes shown ................................................................................................................................. 33

Figure 21: Burst mode, UDP transmission every 10 ms, 100 ms per tick ..................................... 33

Figure 22: Non-limited Bulk Transfer of 2.7 MB ........................................................................... 34

Page v

III. List of Tables Table 1: Wireless Technology Pair-Wise Comparison Matrix ......................................................... 7

Table 2: Wireless Technology Pugh Comparison Matrix ................................................................ 9

Table 3: General Packet Layout .................................................................................................... 12

Table 4: Introduction Packet Layout ............................................................................................. 13

Table 5: Welcome Packet Layout .................................................................................................. 13

Table 6: Burst Mode Data Packet Layout ..................................................................................... 14

Table 7: Status Packet Layout ....................................................................................................... 15

Table 8: Command Listing ............................................................................................................. 16

Table 9: Pair-Wise Comparison for Wi-Fi Device Metrics ............................................................. 18

Table 10: Pugh Comparison Matrix for Hardware Selection ........................................................ 19

Table 11: XBee Wi-Fi Specifications .............................................................................................. 20

Table 12: UDP Successful Transmission Percentages ................................................................... 27

Table 13: Bulk Data Transfer Times .............................................................................................. 34

Page 1 of 56

1 Introduction

1.1 GeoPebble Project Background

If all 33 million cubic kilometers of ice bound up in the ice sheets of Antarctica and Greenland

were to melt, the global sea level would rise by nearly 70 meters, causing massive coastal

flooding and sweeping climate change. Although there are estimates on how this will occur

over large timescales, it is well known that the ice flow in Antarctica and Greenland can vary

widely over much shorter time periods [1].

Although this variation over short timescales is well known, it is not well understood. In their

2007 report, the Intergovernmental Panel on Climate Change (IPCC) predicted an approximately

half meter rise in average sea level by 2100. This does not, however, take into account the rapid

variations of ice sheet flow that have been observed. In fact, the Summary for Policy Makers in

the 2007 Working Group I report states:

“Models used to date do not include … the full effects of changes in ice sheet

flow, because a basis in published literature is lacking. The projections include a

contribution due to increased ice flow from Greenland and Antarctica at the rates

observed for 1993 to 2003, but these flow rates could increase or decrease in the

future.”[2]

The report continues, noting that, although the observed rates from 1993 to 2003 have been

taken into account, it is practically impossible to predict future ice sheet behavior. It is so

unpredictable, in fact, that they cannot even place an upper bound on their estimate of sea

level rise due to future ice sheet behavior.

Seismic data can be used to model the structure of an ice sheet by sending shockwaves through

the sheet and measuring the response with geophones. By modeling the structure more

accurately, a better model for ice sheet behavior could be developed.

Current methods of gathering seismic data

are limited by the equipment in use. The

current system, known as Geode (Figure 1),

uses multiple sensor nodes spaced along a cable

in order to gather data. This greatly limits possible configurations of the system, and carries a

high cost per channel of data. The system is hard to scale, and setup is extremely taxing, as it

has to be done in harsh Antarctic conditions. Most pieces of the system will be buried under

snow after a few days. The cable can also be extremely costly, as it is an additional piece of

equipment that must survive the harsh conditions. In fact, “the excess weight of the cables

alone may account for up to 20% of the operational cost of a typical land survey” [3].

Figure 1: Geode Wired Distributed Sensor Network

Page 2 of 56

1.2 Goals

The GeoPebble system currently under development at Penn State provides a solution to the

wired connection issues of Geode by employing a wireless networking setup. This makes it

possible for the arrangement of nodes to be structured without regard to the limits of a

physical cable, making grid arrangements and other 2-dimensional formations possible. Setup

and teardown is also greatly simplified, as only the nodes need to be extracted from the

Antarctic snow.

The goal of this work is to define the wireless network that will be used in GeoPebble, as well as

to provide supporting data showing that the system is viable. It should meet all the

expectations of the current Geode system, while providing the advantages already outlined.

1.3 Driving Requirements

The relevant driving requirements of the GeoPebble system are as follows:

1. Must set up a wireless network between a central computer and up to 150 sensor

nodes.

2. Must provide GPS data and other status information every 20 minutes.

3. Must be capable of sampling from 3 geophones, each with 24-bit sample resolution.

4. Will compress data at an approximate rate of 2:1.

5. Must provide continuous sample data from the geophones at a rate of 1,000 samples

per second.

6. Must provide a burst sample mode, in which the geophones are sampled at a rate of

10,000 samples per second over a period of 30 seconds.

7. Some data from burst mode must be available immediately, and all data from a burst

mode sample set must be available before burst mode is entered again.

8. Must be able to enter burst mode every 3 minutes.

9. Wireless subsystem must consume less than 1 watt of power while in full activity.

Other requirements, such as GPS accuracy, sensor signal-to-noise ratio, temperature tolerance,

battery life, and so on are not listed, as they do not directly affect the development of the

wireless subsystem. The above requirements are the only hard requirements that must be met

by the wireless subsystem.

With these requirements in mind, a set of simulation goals and deliverables can be laid out. The

primary operating modes are essentially given in the driving requirements: continuous sample

mode and burst sample mode. The other operating modes are standby mode, startup mode,

and idle mode.

Page 3 of 56

1.4 Simulation Goals

To prove the viability of the defined wireless subsystem, a set of simulation goals must be laid

out. The functionality of standby, startup, and idle mode are taken to be givens, as they have

very gentle throughput requirements on the wireless network compared to the primary

sampling modes. The sampling modes are of primary concern, as they have time requirements

on them and deal with getting a large amount of data distributed throughout the network to a

single point. Thus, the continuous sampling mode and the burst sampling mode will be

simulated. The specific simulations should be:

Bulk data transmission of a full burst mode sample period.

Burst mode sampling over a period of 30 seconds

The resulting simulations should provide the packets received, the total amount of data

received from each node, and a way of determining how many packets were dropped, if any.

The metrics will then be compared against the ideal goals of each mode:

1. Continuous mode

a. To compare to continuous mode, must provide 72 kbps × “time to complete

bulk transmission” × “number of nodes” bits of data (1 ksps × 24 bits/sample

× 3 geophones). This will ensure that continuous mode can be satisfied

through the use of bulk transmissions.

b. Lose no data.

2. Burst mode

a. Maintain data rate of 720 kbps from each node.

b. Acceptable loss of up to half of all transmitted packets during actual burst

mode.

c. Must be able to receive all data (including data dropped) reliably within 3

minutes of starting burst mode.

To elaborate on goal 2c, the burst mode simulation will not actually simulate transmission of

data after exiting burst mode. Rather, the burst data simulation will be used to attempt to

transmit the total amount of data lost during burst mode over a period of 2.5 minutes.

1.5 Deliverables

The wireless subsystem must be well-defined in order to be implemented and, as such, all

documentation needed to implement the system could be considered a deliverable. Rather

than include deliverables as separate items to this thesis, they will be included within it and will

later be available as separate reports.

Page 4 of 56

Including the documentation and simulation results, the deliverables that will be provided to

the rest of the GeoPebble project are as follows:

Definition of hardware to be used

Definition of wireless network topology to be used

Definition of the operating modes and transitions between them

Definition of transport layer functionality

Definition of session layer functionality

Simulation code and results of continuous mode

Simulation code and results of burst mode

All definitions will be given in the “Solution” section. All simulation code and results will be

given in the “Results” section.

Page 5 of 56

2 Background

2.1 Network Technologies

Before hardware and network topologies can even be discussed, the wireless technology must

be selected. As was given in the Goals section, GeoPebble will be a wireless system, but that

still leaves open a great deal of options. There are a wide variety of wireless technologies

available, each with its own distinct advantages and disadvantages. Obviously, not all options

could be considered, as many are designed with very specific purposes in mind. Instead, only

the wireless options that fell within the broad requirements outlined in the “Driving

Requirements” were considered.

2.2 Reason for Moving to Wireless

Before delving into the specifics of each wireless networking option available, it is instructive to

review why there is a need to transition to wireless in the first place. The GeoPebble network

distinguishes itself by being able to take on a variety of different 2-dimensional deployments.

The physical distribution of nodes can vary quite a bit as a result, although the network is

expected ultimately to follow a grid distribution or something similar. This still provides a great

improvement over the linear nature of a physical cable with nodes interspaced along its length.

By making the networking wireless, the system is also more easily extendable and can be easily

set up and taken down. This was a problem with wired networks, which have longer setup

times due to a need to lay out cable, and are less easily extended due to the need for additional

cable for each additional node. Wireless nodes can just be dropped down and turned on in

order to connect to the system.

2.3 Wireless Technology Selection Metrics

Based on the rationale for moving to wireless, along with the requirements listed in the

“Driving Requirements” section, metrics for choosing the wireless networking technology can

be laid down.

First is the distance over which the wireless link must operate. The longer the distance, the

greater an area that can be covered by a single portion of the network. This enables wider node

spacing and can mean that fewer repeaters or network gateways would be required.

Second is the data rate the wireless technology can achieve. As GeoPebble requires data links

of close to 1 Mbps per node during burst mode (assuming no compression), this is an extremely

important metric. The higher the data rate is, the better the system can handle keeping up with

the data sample rate specified for burst mode. If it cannot meet 1 Mbps per node, then it is

highly likely that it will be unable to meet the minimum requirement of having all data from a

burst mode transferred in no more than 3 minutes after burst mode starts. Going beyond the

Page 6 of 56

individual node, keep in mind that the central computer is ultimately seeing 54 Mbps on

average when in burst mode (720 kbps from each node, compression ratio of 2:1, with up to

150 nodes; see “Driving Requirements”). Many technologies cannot handle this kind of

throughput, so it absolutely must be kept in mind.

Third is the power consumption of the network technology. While there is variation in power

consumption due to a variety of different devices being available, some technologies will

consume more power on average than others. For a wireless sensor network like this, power

consumption must be taken into account, although for GeoPebble, it is the least important

factor here, as the system has a fairly generous power budget.

Fourth is the flexibility of node layouts. Part of the reason for moving to wireless is the ability to

deploy the nodes in a wider variety of physical topologies. A grid layout, or a large cross could

both be viable options. There is also talk of randomized high-density layouts, such as the one

briefly discussed in the opening of [3]. The more robust a wireless technology is to different

layouts, the better. Most wireless technologies have a fair amount of robustness to different

layouts, so this is more of a measure of how well the network can handle extreme situations,

such as a single long line or a set of failing nodes. Such cases are expected to be outliers for this

system, as a grid or a similarly shaped layout is expected to be the primary setup.

Finally, ease of use is also an important metric. This metric encompasses both the ease of use in

setting up the network, as well as how easy it is to design and build a network based on the

chosen technology. Ease of use thus determines how long it will take to implement the physical

hardware and the software stack to drive the network.

All of these metrics have been entered into a pair-wise comparison matrix (Table 1) in order to

get an idea of what metrics are the most important to the system. The resulting weighted

values will be used when comparing the wireless technologies in a Pugh Decision Matrix (See

“Solution

Wireless Technology Choice”). Note that data rate is considered the most important, followed

by distance and ease of use. Layout flexibility is in last because most technologies are expected

to meet the absolute base requirements for that metric, and additional flexibility is not as

important for the GeoPebble network.

Page 7 of 56

Table 1: Wireless Technology Pair-Wise Comparison Matrix

Dis

tan

ce

Dat

a R

ate

Po

wer

Co

nsu

mp

tio

n

Layo

ut

Fle

xib

ility

Ease

of

Use

Weighted Value

Distance 1 0 1 2 1 0.2

Data Rate 2 1 2 2 2 0.36

Power Consumption 1 0 1 1 1 0.16

Layout Flexibility 0 0 1 1 0 0.08

Ease of Use 1 0 1 2 1 0.2

2.4 Wireless Technology Options

An important chart to consider when

going over wireless networking

options is Figure 3 from [3],

reproduced here as Figure 2. This

chart succinctly describes the major

wireless technologies in use today,

and gives an estimation of their range

and data rate. The chart also outlines

approximately what is required for a

technology to satisfy the normal

requirements of a seismic acquisition

system, such as the one used in

GeoPebble. With one exception, only technologies that intersect the network requirements are

considered.

2.5 Potential Technologies

2.5.1 ZigBee

ZigBee was briefly considered as a wireless networking option, as it makes setting up a mesh

network very easy, and has been used extensively in low-speed wireless sensor networks. The

group developing the GeoPebble hardware also has more experience with the ZigBee protocol.

Unfortunately, as indicated by the chart, and later by the Pugh Matrix, ZigBee just cannot

achieve the required throughput. Due to working on top of the 802.15.4 standard, ZigBee is

Figure 2: Comparison of Wireless Technologies, chart from [3]

Page 8 of 56

limited to 250 kbps[4], and the mesh network setup of ZigBee means that trunking systems are

hard to setup, meaning the data rate limit cannot be worked around easily.

2.5.2 UWB

Ultra-wideband is a set of new technologies enabling the use of wide bands of spectrum for

high-bandwidth communications. While this group of technologies does enable extremely high

data rates, it only works over very short distances and is primarily meant as a personal area

networking technology. There are also very few radios available for ultra-wideband

specifications, making it a very difficult technology to implement.

2.5.3 WiMax

WiMax is the opposite of UWB technology, in that it is meant to work over very large distances.

It can, however, still meet the high data rates required by the GeoPebble system. WiMax

suffers the same ease of use issues that UWB technologies have; there is not as much support

for it, and WiMax radios require additional design, as there are no all-in-one WiMax modules

available with the kind of interface GeoPebble can use.

2.5.4 Wi-Fi

Wi-Fi is one of the most ubiquitous wireless technologies in the world right now, second only to

the wireless technologies used by cell phones. The various Wi-Fi standards are generally

supported all at once and complete radio modules marked 802.11a/b/g/n are not uncommon.

This gives Wi-Fi a broad range of flexibility, enabling a data rate/distance tradeoff. Overall, it

can provide high data rates, with 802.11g providing speeds of up to 54 Mbps, and 802.11n

providing even higher rates, depending on configuration.

Page 9 of 56

3 Solution

3.1 Wireless Technology Choice

After researching the technologies listed above, along with how easy it would be to implement

them, the Pugh Comparison Matrix shown in Table 2 was constructed. Technologies were

graded from 0 to 4 in each metric, and their weighted sums were then compared. Somewhat

unsurprisingly, Wi-Fi came out on top, thanks to its good performance in both data rates and in

distance. WiMax was a fairly close second, indicating that a future system based on GeoPebble

might perform well with a WiMax wireless technology solution, once WiMax becomes easier to

implement.

Table 2: Wireless Technology Pugh Comparison Matrix

ZigBee UWB WiMax Wi-Fi

un

we

igh

ted

we

igh

ted

un

we

igh

ted

we

igh

ted

un

we

igh

ted

we

igh

ted

un

we

igh

ted

we

igh

ted

Distance 1 0.2 0 0 4 0.8 3 0.6

Data Rate 0 0 4 1.44 3 1.08 3 1.08

Power Consumption 4 0.64 1 0.16 2 0.32 2 0.32

Layout Flexibility 4 0.32 0 0 4 0.32 4 0.32

Ease of Use 3 0.6 0 0 0 0 2 0.4

Totals 1.76 1.6 2.52 2.72

Rank 3 4 2 1

Wireless Technology Choice: Wi-Fi

3.2 Network Topology Definition

With the wireless technology and hardware chosen, the

network topology can now be described. The GeoPebble

system will use what is known as an “extended-star”

topology (Figure 3). In this topology, there is a central

node that other gateway nodes connect to. Here, the

GeoPebble sensor nodes are the end nodes, and wireless

access points function as the gateway nodes. The central

computer that receives all data from the network and

sends commands throughout the network is the central

node.

Figure 3: Extended-Star Topology

Page 10 of 56

Because this is a network built on Wi-Fi and uses Wi-Fi modules with a built-in network stack,

the system can take care of routing between the sensor nodes and the central computer

automatically, without the need to implement routing tables or any other additional network

setup code. This particular setup is called “infrastructure” mode in Wi-Fi networks, as it uses an

existing infrastructure in the form of the gateway nodes.

Extended-star networks are highly extensible, so long as additional access points can be added.

For the purposes of the GeoPebble system, the connections between the access points and the

central node can be considered the “backhaul”, where all of the data is funneled from access

points into a single device. This backhaul network is defined by a separate team on GeoPebble,

and makes use of gateway access points that have secondary radios for the backhaul

connection. The Engenius EOA7535 access point is one of the potential access points that works

like this.

For the sake of simulation, the extended star network will be set up so that there are 4 access

points, each providing wireless links to 25 sensor nodes. The access points will be considered to

be communicating with the central computer over an ideal link.

3.3 Network Protocol Definition

In the OSI model for networks (Figure 4), there are seven layers in a

network stack. For the GeoPebble system defined so far, the Physical,

Data Link, and Network layers are all taken care of by the XBee Wi-Fi

module, which takes care of talking to the access point and

implementing the physical wireless scheme (802.11). The Transport

layer is where this section’s discussion will start.

To keep the system easy to implement, the XBee Wi-Fi module

implements TCP/IP and UDP/IP, making the issue of the transport and

session layer an easy to resolve one. TCP guarantees delivery of

packets, whereas UDP merely makes a “best attempt”. Whether TCP

or UDP is used is defined by the current operation state of the system.

3.4 Operation States

There are three possible states a sensor node can be in when it is transmitting data: network

setup, continuous sampling mode, and burst sampling mode. In general, the entire GeoPebble

network will share the same state across all nodes (i.e., when a burst sample occurs, all nodes

will go into burst sample mode at the same time, as a group).

3.4.1 Network Set Up

In the network setup state, a sensor node is connecting to the network and announcing itself to

the central computer. Once the node has connected, been assigned an address, and been given

Network

Transport

Session

Application

Presentation

Physical

Data Link

Figure 4: OSI Model

Page 11 of 56

a welcome packet by the central computer, it will enter into a standby mode or into continuous

sampling mode. In this state, all communications will occur using TCP in order to guarantee

receipt of the announcement and welcome packets.

3.4.2 Continuous Sampling Mode

In continuous sampling mode, the sensor node is continuously sampling the geophones (or

other sensor input) at a reduced rate of 1,000 samples per second. This data is temporarily

stored and is transmitted to the central computer upon request. All communications will occur

using TCP in order to achieve high bulk data transfer rates with reliable reception.

3.4.3 Burst Sampling Mode

In burst sampling mode, the sensor node samples the geophones at the burst sample rate of

10,000 samples per second. As per the Driving Requirements, at least some of the data must

arrive in (near) real time from all nodes. To ensure that all nodes are able to communicate at

once, UDP will be used. The exact reasoning for UDP is explained in the next section.

3.5 Extension to Transport Layer: Using TDMA over Wi-Fi

Because burst sample mode creates a high-speed stream of data from each node, the network

would ordinarily rapidly become clogged due to over-the-air packet collisions. To solve this

problem, the high accuracy of each sensor node’s GPS clock will be put to use. The timing from

the GPS device on each node can be used to set what time each node will transmit data. By

having each node transmit at different times, packet collisions can be avoided. This method of

channel sharing is called Time-Division Multiple Access, or TDMA. By using UDP as the protocol,

there will not be any acknowledgement packets or other stream control packets, which would

come back down the network at unknowable times due to the nature of the access point. Thus

packet collisions due to return packets are avoided.

This TDMA system over Wi-Fi is normally something that cannot be implemented, as accurate

shared time data is usually not available to the radio system. By manually controlling when

packets are sent, using TDMA should be possible. This is the primary unknown in the system, as

there is little research into running a Wi-Fi network in such a manner.

3.6 Application Layer: Packet Types and Specifications

The presentation and application layer are often combined in network stacks, and the

GeoPebble network is no different. The application layer defines the data being carried by each

UDP and TCP packet, and defines the data in the form of packets. GeoPebble will use six

different packet types to communicate between sensor nodes and the central computer.

Page 12 of 56

3.6.1 General Packet Specification

All packets have some common characteristics: a type identifier and a sequence number. The

type identifier lets an application determine which of the six packet types this particular packet

is. The sequence number is used when the packet is one of a series, such as when there is a

large data series being transmitted. The remainder of the packet is devoted to the packet’s

type-unique contents. The resulting packet structure is shown in Table 3.

Table 3: General Packet Layout

Type (1 byte) Sequence Number (2 bytes) Type-Unique Contents

The type of packet. 1=Introduction 2=Welcome 3=Burst mode UDP 4=Burst mode TCP 5=Continuous mode 6=Status 7=Command

If the packet is part of a

sequence (ex. the burst

mode packets), then this

will indicate what packet

number it is in the data

sequence.

Contents unique to the

type of packet this is.

Page 13 of 56

3.6.2 Introduction and Welcome Packets

When each node starts up, it needs to send an “introduction” packet to the central computer,

which will respond with a “welcome” packet. This exchange is necessary for the central

computer to know that the node is online, as well as its location and current status. It is also

necessary so that the node will know what slot it will use when using TDMA during the burst

mode sampling. The Introduction and Welcome packets will be structured as follows (Table 4

and Table 5):

Table 4: Introduction Packet Layout

UUID (6 bytes) RSSI (1 byte) GPS Data (64 bytes)

This field contains the UUID

of the node’s radio. It is

different for each XBee

Wi-Fi radio, and can be

used to identify the

individual node.

The Received Signal

Strength Indicator value

from the XBee radio. Can

be used to estimate the

maximum data rate

possible.

The GPS location data from

the GPS module. Used to

identify the location of the

node in the mesh.

Table 5: Welcome Packet Layout

Assigned Node ID (2 bytes) Total Number of TDMA

slots (1 byte)

Assigned TDMA slots

(1 byte / slot)

The Node ID that the node

should identify itself as

throughout the time it is

active. This will be much

shorter than the UUID of

the node.

The total number of TDMA

slots that will exist in a 100

ms time frame. This is used

to determine the time

intervals of each slot.

The TDMA slot numbers

that the node has been

assigned to for when it

needs to transmit data in

burst mode using UDP. This

part of the message can be

of arbitrary length, as it is

at the end of the message.

Any number of slots can

therefore be assigned,

although each slot number

may only be one byte long.

Page 14 of 56

3.6.3 Burst Mode Data Packet

When the sensor system enters burst mode, data from each node must be rapidly transmitted

back to the central computer. Some losses are acceptable during the 30-second sample period,

but all data must eventually make it back to the central computer. During the 30-second sample

period, UDP packets will be used, with each node in the network transmitting at a specific time

slot. After the 30-second period ends, we can return to TCP for reliable transfer, and request

any missing packets. In both cases, the data packets will use the same formatting, shown as

Table 6.

Table 6: Burst Mode Data Packet Layout

Time Stamp

(12 bytes) Node ID (2 bytes)

Burst Sample

Number (1 byte) Sample Data

The time when the

first sample in this

packet was taken.

The assigned node

ID. Used to

associate the packet

with a node, as an

IP address may

potentially change

over the life of the

system.

Which burst sample

period this packet is

associated with. The

command to set up

for burst mode will

include a reference

number to use.

The sampled data in

a raw format. Might

be compressed.

3.6.4 Continuous Mode Data Packet

When not in burst mode, the system is sampling in continuous mode, which is a lower sample

rate. The packet is functionally identical to a burst mode packet, but without the burst sample

number. This is because the continuous mode provides the same data, but at a slower rate.

These continuous mode packets can be sent over TCP in response to a command packet, and

cannot be tied to a specific command, as it should be constantly happening when not in burst

mode. The burst sample number will thus always be 0.

Page 15 of 56

3.6.5 Status Packets

A status packet should be periodically gathered, and should encapsulate the current state of

the node as a whole. Any relevant housekeeping data should thus be included. The packet

structure will look as follows (Table 7), with some modifications depending on the

housekeeping data available.

Table 7: Status Packet Layout

UUID (6 bytes) RSSI (1 byte) GPS Data

(64 bytes)

Temperature

(2 bytes)

Battery Charge

(1 byte)

The UUID of

the system.

This can be

used to identify

if a node has

been assigned

a new IP

address.

The Received

Signal Strength

Indicator from

the radio.

GPS data string.

Current

temperature of

system, in

degrees

Celsius.

Current charge

of the system,

in percent.

Page 16 of 56

3.6.6 Command Packet

Command packets can actually have many different formats, depending on the command being

sent. These commands always come from the central computer, and are sent throughout the

network. The general format is the 1-byte command ID, followed by the command-specific

data, if there is any. The possible commands are listed in Table 8, with command ID followed by

a description.

Table 8: Command Listing

0 Empty command. Does nothing. Can serve as a test for receipt of command

packet, like a ping.

1 Request for Status packet: contains no data. This is used to make a node

generate a status packet.

2

Schedule burst mode: Tells the node to prepare to enter burst mode at a set

time. First byte is the identifier for the burst mode. The remainder is the time at

which sampling should begin.

3

Forget burst mode: Tells the node to forget a burst mode instance. If the burst

mode already finished, then the data associated with it can be deleted. If the

burst mode has not yet happened, it can be used to cancel the scheduled burst

mode sample period.

4

Request burst mode packets: Requests missing burst mode packets from a node.

First byte is the burst mode identifier, second byte is the total number of packets

received, and the remainder is a list of which packets are missing.

5 Request continuous mode packets: Requests continuous mode packets from a

node. This command requires no additional data.

6 Reassign: Reassigns a node to a new node ID and slot number. The data is

identical to the welcome packet specified earlier.

7 Shutdown: Tells the node to shut down for a specified length of time. The data is

the time stamp for when shutdown should end.

3.7 Selection of Hardware

With Wi-Fi selected as the wireless technology of choice, there are still a lot of decisions to be

made with regards to hardware. First and foremost, it should be noted that only the node

hardware will be focused on, as the access point hardware selection was relegated to another

member of the GeoPebble team after selecting Wi-Fi. The access point and any other

intermediate technology, such as wireless bridges, are considered to be the system’s

“backhaul”, taking care of the routing of data from large groups of sensor nodes. To learn more

about the network topology used, please refer to the Network Topology Definition section.

Page 17 of 56

3.7.1 Hardware Selection Metrics

When selecting the hardware, four metrics were considered: cost, receive sensitivity, power

consumption, and ease of use.

The first, cost, is important to consider, as the Wi-Fi radio used is a huge driving point in the

overall cost per sensor node in the GeoPebble network. As the current system is still considered

a low-volume prototype, cost is less of an issue compared to expected development time.

Receive sensitivity is also important, as it determines how far a sensor node can be from the

nearest wireless access point. Sensitivity is somewhat harder to judge, as the Wi-Fi standards

are designed to switch to different speeds, each offering different sensitivities. This is what

makes Wi-Fi capable of offering a data rate/distance tradeoff. In practice, the change in

sensitivity between different Wi-Fi modes is determined almost entirely by the Wi-Fi

specification[5], rather than the individual radio implementation. Because of this, only the

lowest rate Wi-Fi configuration sensitivity was considered. All other sensitivities were assumed

to be derived from these.

Power consumption is another relevant metric, as a lower power consumption radio will enable

nodes to stay active for longer periods of time. The drawback is generally a limitation on

distance, as lower powers often mean lower sensitivity and transmit power. To take this into

consideration, power consumption at a transmit power of +0 dBm was considered when

scoring this metric.

Finally, the most important metric is ease of use. This metric is harder to score, and greatly

depends on the skill set of those implementing the radio. Mostly, the radios were rated based

on how many communication interfaces were provided (e.g., SPI, UART), along with how easy it

was to decipher the communication protocol laid out in the relevant datasheets. The ease of

interaction with access points was also considered, as a radio that supports both 802.11b and

802.11g will be easier to work with in the long run than one that is limited to just one standard.

These metrics were compared to one another in a pair-wise comparison matrix, as seen in

Table 9. The most important metric was ease of use, followed by receive sensitivity, with power

consumption and cost tied at the bottom. The weighted values for these metrics will be used in

the Pugh Comparison Matrix discussed in the “Hardware Selection” section.

Page 18 of 56

Table 9: Pair-Wise Comparison for Wi-Fi Device Metrics

Co

st

Re

ceiv

e Se

nsi

tivi

ty

Po

wer

Co

nsu

mp

tio

n

Ease

of

Use

Weighted Value

Cost 1 1 1 0 0.1875

Receive Sensitivity 1 1 2 0 0.25

Power Consumption 1 0 1 1 0.1875

Ease of Use 2 2 1 1 0.375

3.7.2 Hardware Options

The hardware options were limited to all-in-one radios (radios that implement the network

stack, include all analog front-end parts, and provide an easy way of talking to a

microcontroller) only, as those provided the shortest development times in order to be used.

The radios considered were the Digi XBee Wi-Fi, the Gainspan GS1011M, and the Microchip

MRF24WB0MB.

3.7.2.1 Digi XBee Wi-Fi

The XBee Wi-Fi radio is an all-in-one radio that uses a design and implementation very similar to

other XBee radios, which include radios using the ZigBee specification and a generic

implementation of the IEEE 802.15.4 specification. It provides good receive sensitivity at

−97dBm for 802.11b at 1 Mbps [6]. Broadcast power maxes out at 16 dBm for the same, with

transmit current going up to 260 mA at 3.3V for that transmit power. The primary

microcontroller programmer for the GeoPebble project also has experience with XBee-type

radios. These specifications come at cost, however, as the XBee Wi-Fi is the most expensive of

the radios considered.

3.7.2.2 Gainspan GS1011M

The Gainspan GS1011M is an all-in-one radio constructed from the Gainspan GS1011

system-on-chip, which internally implements two ARM7 CPUs: one for implementing the Wi-Fi

stack, and one for the user application. Use of the ARM7 CPU is restricted, however, and

requires both the signing of a non-disclosure agreement and the purchase of a software

development kit. The radio does come with a preinstalled firmware image that provides an

interface between the Wi-Fi stack and an external microcontroller, which is what will likely be

used by GeoPebble, at least for the current revision.

In addition to the CPU setup, the Gainspan module features a receive sensitivity of −92 dBm for

802.11b at 1 Mbps, a maximum broadcast power of 18 dBm, and transmit current of 250 mA at

Page 19 of 56

3.3V while in this state [7]. This is weaker sensitivity than the XBee Wi-Fi, although it does

feature a higher transmit power. There is some knowledge of how to use the GS1011M, thanks

to hobbyist documentation and some practice with the module.

3.7.2.3 Microchip MRF24WB0MB

The Microchip MRF24WB0MB is another all-in-one radio and is designed and sold by Microchip.

The MRF24WB0MB has an interface somewhat similar to the XBee Wi-Fi, and supports only the

802.11b protocol. The radio features a receive sensitivity of −91 dBm for 802.11b at 1 Mbps, a

maximum broadcast power of 10 dBm, and a transmit current of 154 mA at 3.3V [8]. This is the

weakest sensitivity by 1 dBm, and is also the lowest power consumption/transmit power. As

none of the GeoPebble programmers have worked with Microchip products, let alone this one

in particular, it is also the device with the highest learning curve.

3.7.3 Hardware Selection

Ultimately, the Digi XBee Wi-Fi module was selected. While it is the most expensive, it also has

the best receive sensitivity and is the best understood module. The Gainspan module came in

second, thanks to the documentation and experience with the module, and the Microchip

module came in third, as it had the weakest specs and the highest learning curve. This is all

shown in the relevant Pugh Comparison Matrix (Table 10).

Table 10: Pugh Comparison Matrix for Hardware Selection

Digi XBee

W-Fi Gainspan GS1011M

Microchip MRF24WB0MB

un

we

igh

ted

we

igh

ted

un

we

igh

ted

we

igh

ted

un

we

igh

ted

we

igh

ted

Cost 0 0 2 0.375 3 0.5625

Receive Sensitivity 4 1 2 0.5 2 0.5

Power Consumption 2 0.375 2 0.375 2 0.375

Ease of Use 3 1.125 2 0.75 1 0.375

Totals 2.5 2 1.8125

Rank

Wi-Fi Radio Choice: Digi XBee Wi-Fi

Page 20 of 56

3.7.4 Relevant Specifications for Simulation

With the Digi Wi-Fi module selected, the key specifications for the module could be specified.

The TX power, RX sensitivity, TX gain, RX gain, and noise figure were all considered to be

important, as they are the primary specifications for any communications system front-end. The

specifications were taken from the datasheet [6] and are shown in Table 11.

Table 11: XBee Wi-Fi Specifications

TX Power +16 dBm

RX Sensitivity −97 dBm for 802.11b @ 1 Mbps

TX gain −0.5 dBi with built-in antenna, +9 dBi with directional antenna

RX gain −0.5 dBi with built-in antenna, +9 dBi with directional antenna

Noise Figure Not available

Page 21 of 56

4 Results and Evaluation

4.1 Wi-Fi Radio Physical Testing

Before delving into the simulation environment, some physical testing was done to determine

what data rates were achievable with UDP, along with how reliable “best effort” UDP packets

would be when implemented. The test was to use the XBee Wi-Fi radio, a potential gateway

node, and a laptop to observe the XBee transmitting UDP data to the laptop.

4.1.1 Preparation

In order to test the XBee Wi-Fi radio, an application interface was needed in order to configure

the radio and automatically generate UDP packets. Python was selected as the language for

making the interface because it works across platforms and is easy for rapid development. The

radio has an associated development board that can be used to interface with it from a

computer through a serial port. To take advantage of this for testing, the pySerial library was

used to provide serial interface commands in Python. With pySerial, a small library of functions

was created in Python to make interfacing with the radio easy. Functions for sending

commands, receiving responses, transmitting data, and acting like a very basic terminal were all

written. The resulting Python library code is available in the Appendix.

Page 22 of 56

4.1.2 Experimental Setup and Procedure

With the XBee Python library built, UDP testing can be accomplished. To set up the physical test

environment, these instructions should be followed:

1. Plug the XBee Wi-Fi radio into the XBee development board.

2. Connect the development board to a computer running Linux.

3. Turn on an unsecured wireless access point within range of the XBee.

With the physical setup complete, the XBee can then be configured with the help of the XBee

Python library. Once in Python, the following commands are executed to configure the XBee:

fromXBee_Test_Lib import all from time import sleep ser = Init(‘/dev/ttyUSB0’) Command(‘BD\x07’,ser) ser.close() ser.baudrate = 115200 ser.open() Receive(ser) Commmand(‘AS’,ser) Receive(ser) Commmand(‘IDgeopebble’,ser) Receive(ser)

These commands configure the XBee for communication at 115200 bps and connect it to the

access point. Once this is done, the rest of the system can be set up. These instructions are

followed in order to set up the test environment on the computer:

1. Install Wireshark.

2. Connect the laptop to the access point.

3. Run “sudo wireshark” and set it up to capture from the wireless card.

4. Run the command “nc –ul 4545 > output.txt”

5. Generate a 1000-character string in Python and store it as “data”, then run the following

Python commands:

for i in range(1000): Short_Xmit(data, ’192.168.1.101’, 4545, ser) sleep(0.1)

Wireshark will capture the 1000 packets sent by the XBee, and nc will send all the incoming

data to the file output.txt. Checking the length of output.txt will give the total number

of bytes received. Wireshark’s captured packet data can be used to generate a variety of graphs

and statistics. To test different numbers of packets, “range(1000)” was modified. To test

different transmission rates, “sleep(0.1)” was modified.

Page 23 of 56

4.1.3 Results

Tests were conducted with 10,000 packets with 100 ms between transmissions, 1,000 packets

with 50 ms between transmissions, and 1,000 packets with 20 ms between transmissions. For

the 10,000 packets sent with 100 ms between UDP transmissions, an RSSI of −74 dBm was

measured by the XBee radio. All others were conducted when an RSSI of −72 dBm was

measured. The resulting packet capture files were used to create the Figures 5–11. For all

figures, the y axis measures number of packets received per tick, and the x axis measures time

from start:

Figure 5: 10,000-packet UDP Test w/ 98.38% success, transmission every 100 ms, 10 sec per tick shown

Figure 6: 10,000-packet UDP Test w/ 98.38% success, transmission every 100 ms, 1 sec per tick shown

Page 24 of 56

Figure 7: 10,000-packet UDP Test w/ 98.38% success, transmission every 100 ms, 100 ms per tick shown

Figure 8: 1000-packet UDP Test w/ 99.9% success, transmission every 50 ms, 1 sec per tick shown

Page 25 of 56

Figure 9: 1000-packet UDP Test w/ 99.9% success, transmission every 50 ms, 100 ms per tick shown

Figure 10: 1000-packet UDP Test w/ 99.9% success, transmission every 20 ms, 1 sec per tick shown

Page 26 of 56

Figure 11: 1000-packet UDP Test w/ 99.9% success, transmission every 20 ms, 100 ms per tick shown

Page 27 of 56

The percentage of UDP packets that made it during each test are summarized in Table 12.

Table 12: UDP Successful Transmission Percentages

10,000 packets, 100ms between transmissions 98.38%

1,000 packets, 50 ms between transmissions 99.9%

1,000 packets, 20 ms between transmissions 99.9%

The 10,000-packet test was also used to generate additional statistics about the time between

received packets. The mean time between packets was 102.71 ms, and the standard deviation

was 0.1353 s. Additionally, 22.4% of packets were within 20 ms of a 100 ms time between

transmissions. A histogram showing the number of packets that came “t” seconds after the last

packet was is shown in Figure 12.

Figure 12: Histogram of time between received packets, as measured by Wireshark

Page 28 of 56

4.2 Selection of Simulation Environment

Before beginning to write the simulation of burst mode and a bulk transmission occurrence, a

simulation environment first must be chosen.

4.2.1 Simulation Environment Options

There are not many options available for network simulation. Familiarity with MATLAB and its

use in simulation made it an option, and NS2 and NS3 are open network simulator suites. All

other simulators are closed and cost more money than is available for testing, so they were not

considered.

4.2.1.1 MATLAB

MATLAB is a powerful system for working with large matrices and performing complex

mathematics. It is often used for writing very specific simulations. As simulations grow larger

and more complex, the time to code often grows exponentially. It is also a very generic coding

environment, and does not have any built-in functions for making network simulation easier.

4.2.1.2 NS2

Network Simulator 2, or ns2, is an open-source simulation environment built using a

combination of C++ code and Tcl code. Tcl makes it possible to write simulation scripts. NS2

features a wide variety of network simulation classes and methods, making it possible to

simulate a wide variety of networks.

4.2.1.3 NS3

Network Simulator 3, or ns3, is the successor to ns2. It is still growing to accomplish everything

that ns2 could do, but it already has extra functionality and features a vastly improved interface

and system for building simulations. It is built using C++, with some additional python

interfacing available. Generating pcap files, the standard for packet capture logs, is also

extremely easy.

4.2.2 Simulation Environment Choice

Network Simulator 3 was chosen after extensive experimentation with ns2. MATLAB was

decided against almost immediately, as the time it would take to write good simulation code in

MATLAB would be vastly greater than using already implemented network simulation libraries.

After working with ns2, then giving ns3 a try, it was discovered that ns3 has a much easier to

work with set of classes and methods. The tutorial and examples for it are much more helpful

as well, and overall ns3 is easier to work with in almost every fashion.

Simulation Environment Choice: Network Simulator 3

Page 29 of 56

Figure 13: Sensor Node Simulated Layout

4.3 Simulator Code

With the simulator environment chosen, the simulation code for bulk transmissions and burst

mode can now be run.

4.3.1 Creation of the Basic Model

To define the simulation in various modes, the basic

network model first had to be made. The layout for the

sensor nodes was chosen to be a 1-km square grid of 100

nodes, lined up so the grid is 10 × 10 equally spaced

nodes. The access points were then placed at local centers

of 25 nodes. The resulting layout can be seen in Figure 13.

The wireless connections were then built, and ideal

point-to-point connections were used to connect the

access points to the central computer. This was done to

act as an abstraction of the backhaul discussed in the

“Network Topology Definition” section.

Finally, the wireless nodes and access point were made to

have the characteristics of the hardware they emulate. The

wireless nodes use the specifications laid out in the “Relevant Specifications for Simulation”

section, and the access point uses specifications for the EOA7535 access point [9]. The resulting

model can be used in any simulation for the grid network; only changes to the applications

running on the network are required. The code for the model can be seen in any of the

simulation code, found in the appendix.

4.3.2 Implementing the Model in Various States

To put the model into the desired states, applications had to be installed onto the nodes. For

Burst mode, UDP client applications set to transmit at certain times were installed onto each

wireless node. A UDP server for receiving the data was set up at the central computer.

For bulk transmission mode, two different simulation models were made. The first one,

bulk_TCP_test.cc, doesn’t use any rate limiting and runs a bulk transmit application from one

wireless node over TCP. The second one rate limits to 2.8 Mbps by running a switched bulk

transmit application over TCP. The rate of 2.8 Mbps was chosen because the maximum possible

communication speed with the XBee radio is over SPI at 3.5 MHz, and it is expected that it will

take 10 clock cycles to read out a single byte, on average. Multiplying 3.5 MHz by 8 bits/cycle

gives 2.8 Mbps, the speed used.

Page 30 of 56

All models feature some amount of parameterization. The packet size can be changed on all of

them, the burst mode allows one to define the transmission rate, and the bulk transmission

simulation allows one to change the amount to transmit.

4.4 Simulation Results

With the simulation code written, the code was run in all of its states. The resulting graphs of

the packet capture files are all included below, as are the times it takes for bulk transmission to

run.

4.4.1 Simulation of Burst Mode

For the simulation of burst mode, a few graphical representations of the network were made to

illustrate the process of burst mode. In Figure 14, the initial network, before any traffic occurs,

is shown. In Figure 15, communication is just starting, so WHOIS requests are being sent

everywhere to build each node’s personal routing table. In Figure 16 and Figure 17, burst mode

is shown in its fully active state, with the latter figure showing a snapshot at a smaller portion in

time, showing that nodes transmit in sequence.

Page 31 of 56

In the next set of graphs, burst mode simulation results are graphed, with packets per tick as the y axis and time from start as the x axis. In all except for Figure 20, only the UDP packets received at one access point are shown. Figure 20 shows packets from the entire network.

Figure 14: Initial Network Figure 15: Building Routing Tables

Figure 16: Fully Active Burst Mode Figure 17: Partial Snapshot of Burst Mode

Page 32 of 56

Figure 18: Burst Mode, UDP transmission every 100 ms, 10 ms per tick

Figure 19: Burst Mode, UDP transmission every 100 ms, 100 ms per tick

Page 33 of 56

Figure 20: Burst Mode, UDP transmission every 100 ms, 100 ms per tick, all packets from all nodes shown

Figure 21: Burst mode, UDP transmission every 10 ms, 100 ms per tick

Page 34 of 56

4.4.2 Simulation of Bulk TCP Transfers

There is only one graph generated for the Bulk TCP transfer test, Figure 22. Rate limiting shows

a similar graph, but with it cut up into on/off slices.

Figure 22: Non-limited Bulk Transfer of 2.7 MB

The important part is how long it takes to transmit a given amount of data. With no rate

limiting, it takes 3.055 seconds to transmit 2.7 MB of data. By rate limiting to 2.8 Mbps, the

transfer times and sizes in Table 13 were generated.

Table 13: Bulk Data Transfer Times

Amount of Data Transfer Time

1.35 MB (1/2 of all burst data) 7.86 s

2.4 MB (8/9 of all burst data) 13.86 s

2.7 MB (complete burst data) 15.72 s

5 Conclusions and Future Work

5.1 Conclusions for UDP Testing

After testing at various transmission rates, it was determined that the lowest reliable

transmission rate is around 100 ms between transmissions. Attempting to go higher than that

Page 35 of 56

shows there is a limit at around 11 packets per second (Figure 8 and Figure 10), or 88 kbps.

Time between transmissions becomes less reliable too, as can be seen in the graphs for 50 ms

(Figure 9) and 20 ms (Figure 11). Backing off to 80 kbps is more reliable, and in general is

centered around 100 ms between transmissions. It may be even more accurate than what is

implied by Figure 12, as the access point, laptop, and software packet capture no doubt

introduces some amount of error into the measurement. Additional testing, preferably with a

dedicated packet capture system, would have to be conducted in order to have a more

accurate guess of the variation in transmission separation time.

Testing and analysis of the results show that it is likely that 80 kbps is the maximum achievable

data rate, at least with a serial connection set to 115.2 kbps. Moving to SPI as the interface

protocol for the final product will hopefully give higher possible speeds. The current rate limit

of 80 kbps is a potential problem, as the data stream is 720 kbps uncompressed, thus requiring

a compression ratio of 9:1. This will have to be taken into consideration. Future testing in the

same format should be done with the SPI interface, to determine if such a ratio is actually

necessary. Testing should also be done with a dedicated capture system, in order to gain more

accurate separation time measurements.

5.2 Conclusions for Simulation Testing

In burst mode, when the time between UDP transmissions is set to 100 ms, everything flows

very smoothly, with no lost packets. Trying to speed up the rate to transmitting every 10 ms

shows there is a limit on the simulated system: in Figure 21, about 60 packets per 100 ms is

shown, meaning that there are, on average, 2.4 packets being transmitted from each node

every 100 ms. This is far short of the expected 10, indicating that the network cannot handle

much more than transmissions every 50 ms, even in the somewhat idealistic environment of

the simulation.

For bulk transmit mode, sending complete burst data takes 15.72 s, indicating that if no data is

transmitted and there is no compression, then it will take 15.72 seconds/node × 25 nodes = 393

seconds, or about 6.5 minutes to transmit all data. Compression will improve this transfer time.

Note that in continuous mode, an access point will see 25 nodes × 9 B/sample × 1000 samples /

sec = 225 kB per second generated. Bulk transmit will not work for this, as the rate limiting will

prove too great an issue. To see this, note that in the time it takes to transmit 2.7 MB over the

link, continuous mode will have generated 225 kB/s × 15.72 s = 3.54 MB of data.

Page 36 of 56

5.3 Final Conclusions

After running the simulations and hardware evaluations, it is apparent that there are some

potential issues with the current specification. The current specification will work, but only if

there is data compression; otherwise the data rates will outpace the rate at which data can be

collected. A compression ratio of 9:1 would be needed for reception of all burst mode data in

real time. A lower ratio could be viable, with 3:1 just barely meeting the time restraint on

reception of all data for a burst mode.

Continuous mode over TCP will not prove viable, simply because of the rate limit set by using

SPI for communication. Faster rates just are not possible with the current hardware. Using

TDMA for continuous mode would prove more viable, and a large time period could be left

open in the TDMA slot setup for the central computer to still send out commands.

Although hardware testing and simulation both showed that the GeoPebble system cannot go

much faster than transmitting every 100 ms, higher gain directional antennas would likely fix

the limit found in simulation, as that was derived from the channel having to rate-limit to

maintain the connection to all nodes. Hardware testing with SPI may also allow the 100 ms to

be surpassed.

Overall, while the wireless network originally proposed in this paper will not satisfy all

requirements perfectly, it may be able to meet them in the long term through improved

hardware. TDMA is also the only way it even comes close, as the data rate would likely be

abysmal without TDMA to help avoid packet collisions. Compare bulk TCP transmit rates to

overall data rates with burst mode TDMA for proof of this.

5.4 Future Work

To help confirm these conclusions, further testing should be done in all areas, once better test

equipment is available and SPI protocol is successfully implemented. UDP testing should be

redone with the higher data rates that SPI provides, and times between when packets are sent

should be tested with dedicated capture equipment.

The simulation provided makes some assumptions on the transmission model, which will not be

as accurate as the actual transmission conditions in the Antarctic. The simulation should be

redone in the future once a more accurate model has been made.

Finally, the simulation assumes that the backhaul network is an ideal communications line to

the central system. Once the backhaul network has been selected for sure, the backhaul

network should also be simulated, in order to have a more complete simulation of the final

wireless network.

Page 37 of 56

6 References

[1] H. Jay Zwally et al., "Surface Melt-Induced Acceleration of Greenland Ice-Sheet Flow,"

Science, pp. 218-222, 2002.

[2] S. Solomon et al., "Summary for Policymakers. In: Climate Change 2007: The Physical

Science Basis. Contribution of Working Group I to the Fourth Assessment Report of the

Intergovernmental Panel on Climate Change," IPCC, Cambridge, United Kingdom and New

York, NY, USA, 2007.

[3] S. Savazzi and U. Spagnolini, "Wireless geophone networks for high-density land

acquisition: Technologies and Future Potential," The Leading Edge, vol. 27, no. 7, 2008.

[4] IEEE, "802.15.4-2011 - IEEE Standard for Local and Metropolitan Area Networks--Part 15.4:

Low-Rate Wireless Personal Area Networks (LR-WPANs)," New York, NY, 2011.

[5] IEEE Computer Society, "Wireless LAN Medium Access Control (MAC) and Physical Layer

(PHY) Specifications," New York, NY, 802.11-2007, 2007.

[6] Digi, "XBee Wi-Fi RF Module," 90002124_D, 2011.

[7] Gainspan, "GS1011M Low Power Wireless System-On-Chip Wi-Fi Module Data Sheet," San

Jose, CA, GS1011M-DS, 2011.

[8] Microchip, "MRF24WB0MA/MRF24WB0MB Data Sheet," USA, DS70632B, 2011.

[9] EnGenius, "Business Class 802.11a/b/g Outdoor Dual Radio Concurrent

AP/Bridge/Repeater with Industrial IP68 Enclosure," Costa Mesa, CA,.

[10] ns-3 Project Team. (2010) ns-3 Tutorial. [Online].

http://www.nsnam.org/docs/release/3.12/tutorial/singlehtml/index.html

[11] ns-3 Project Team. (2012) ns-3. [Online]. http://www.nsnam.org/

[12] Mark Greis and VINT Group. Tutorial for Network Simulator "ns". [Online].

http://www.isi.edu/nsnam/ns/tutorial/

Page 38 of 56

7 Code Appendix All code used for testing and simulation is provided here.

7.1 Python XBee Library #!/usr/bin/env python import serial import math from time import sleep import sys # Initialize Serial Port and Turn on API Mode def Init(ser_port): # Takes in a string ser = serial.Serial() ser.port = ser_port ser.timeout = 1 try: # Open if it isn't already ser.open() except: # It was already open print "Opened Port..." ser.write('+++') sleep(1.5) ser.write('ATAP1\r') sleep(3) print ser.read(ser.inWaiting()) return ser # Calculate checksum def Checksum(data): # Assumes data is a string value = 0 for i in data: value = (value + ord(i)) % 256 return 255 - value # Packetize and transmit data in API mode # data - data to transmit (less than 65000 bytes...for now) # ip_addr - destination IP address # port - both destination and source port # ser - the serial port object to send to (set to 'ser' for now) def Short_Xmit(data, ip_addr, port, ser): # Put the IP transmission parameters into bytes addr = serial.to_bytes( [int(x) for x in ip_addr.split('.')]) port = serial.to_bytes([port/256, port%256]) # Find final packet length and total number of packets to send pkt_length = len(data)+12 length = serial.to_bytes([pkt_length / 256, pkt_length % 256]) packet = '\x20\x01' + addr+port+port+'\x00'+'\x00'+data # Begin transmission ser.write('\x7E'); #API Start marker ser.write(length) ser.write(packet) ser.write(serial.to_bytes([Checksum(packet)])) # Run to receive and process packets def Receive(ser): ser.timeout = 1 if (ser.inWaiting() != 0): data = ser.read(ser.inWaiting()) else: return []

Page 39 of 56

packets = data[1:].split('\x7E') # Split into packets by looking for start delimiter #print packets if len(packets) == 0: return packets if len(packets) != 0: for packet in packets: length = ord(packet[0]) * 256 + ord(packet[1]) API_code = packet[2]; if (API_code == '\x88'): print "Command Packet" print "Command= "+packet[4:6] print "Result= "+repr(packet[6:-1]) elif (API_code == '\x89'): print "Transmission Status Packet" print "Frame ID= "+packet[3] if (packet[4]=='\x00'): print "Success" elif (packet[4]=='\x03'): print "Purged because stack was not up yet" elif (packet[4]=='\x04'): print "Physical error on transceiver" elif (packet[4]=='\x21'): print "TX64 transmission timed out awaiting acknowledgement" elif (packet[4]=='\x32'): print "Resource Error" elif (packet[4]=='\x74'): print "Message too long" elif (packet[4]=='\x76'): print "Attempt to create client socket failed" else: print "Unknown Error" elif (API_code == '\x80'): addr = '' for i in packet[8:12]: addr = addr + i + '.' print "IP Address= " + addr[:-1] print "RSSI= " + packet[12] print "Data= " + repr(packet[14:-1]) else: print "Output= "+repr(packet[4:-1]) print "" return packets # Run to trasmit a small AT command def Command(cmd, ser): pkt_length = serial.to_bytes([len(cmd)+2]) ser.write('\x7E\x00') ser.write(pkt_length) packet = '\x08\x01' + cmd ser.write(packet) check = Checksum(packet) check = serial.to_bytes([check]) ser.write(serial.to_bytes(check)) def Terminal(ip, port, ser): while(True): data = str(raw_input()) if (data != ''): Short_Xmit(data, ip, port,ser) if (ser.inWaiting()): received = ser.read(ser.inWaiting())

Page 40 of 56

received = received[1:].split('\x7E') # Split into packets by looking for API start delimiter for packet in received: if (packet[2] == '\x80'): print repr(packet[14:-1]) if __name__ == "__main__": # Set up serial port ser = Init(str(sys.argv[1])) # Get IP address and port while True: try: ip = raw_input("IP Address of computer to talk to? ") addr = serial.to_bytes( [int(x) for x in ip.split('.')]) if len(addr) != 4: raise ValueError break except: print "Invalid IP Address" while True: try: port = int(raw_input("Port to use? ")) if port > 65535: raise ValueError break except: print "Invalid Port" # Configure XBee with access point answer = raw_input("Configure XBee (y/n)? ") if answer in ['Y', 'y', 'yes', 'Yes', 'YES']: Command('AS', ser) sleep(2) Receive(ser) access_point = raw_input("Enter SSID of Access Point: ") Command('ID'+access_point, ser) sleep(2) Receive(ser) else: print "Fine, assuming it's already configured." # Enter commands in command mode answer = raw_input("Enter in Commands? (y/n)? ") if answer in ['Y', 'y', 'yes', 'Yes', 'YES']: while(True): command = str(raw_input("Command (n to exit) = ")) if (command == 'n'): break Command(command, ser) sleep(1) Receive(ser) # Enter terminal mode answer = raw_input("Go to Terminal Mode? (y/n)? ") if answer in ['Y', 'y', 'yes', 'Yes', 'YES']: Terminal(ip, port, ser)

Page 41 of 56

7.2 Burst Test Simulation Code /* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */ /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation; * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ /* Burst_test.cc * Simulates Burst mode UDP transmissions for the GeoPebble wireless net. * Use the --PrintHelp switch to show all options and console variables. * * Written by Scott Teal * Last updated April 5, 2012 * * Compiled and tested with "Waf" build system for network simulator 3. * NS3 Version Used: ns-3.13 */ #include <sstream> #include "ns3/core-module.h" #include "ns3/point-to-point-module.h" #include "ns3/point-to-point-star.h" #include "ns3/network-module.h" #include "ns3/applications-module.h" #include "ns3/wifi-module.h" #include "ns3/mobility-module.h" #include "ns3/csma-module.h" #include "ns3/internet-module.h" // GeoPebble WiFi Topology // // Wifi 10.1.2.0 // AP // * * * * // | | | | 10.1.1.0 // n5 ... n30 n1 ---------------- // point-to-point | // | // Wifi 10.1.3.0 | // AP | // * * * * | // | | | | 10.1.1.0 | // n31 ... n55 n2 ---------------- // point-to-point | // | // Wifi 10.1.4.0 |-------n0 // AP | // * * * * | // | | | | 10.1.1.0 | // n56 ... n80 n3 ---------------- // point-to-point | // | // Wifi 10.1.5.0 |

Page 42 of 56

// AP | // * * * * | // | | | | 10.1.1.0 | // n81 ... n105 n4 ---------------- // point-to-point using namespace ns3; NS_LOG_COMPONENT_DEFINE ("UDP_Script"); int main (int argc, char *argv[]) { // ========================================================= // Set up Command Line Parser and its parameters // ========================================================= bool verbose = false; uint32_t nWifi = 25; uint32_t pktSize = 1000; double xmitTime = 0.1; CommandLine cmd; cmd.AddValue ("verbose", "Tell applications to log if true", verbose); cmd.AddValue ("pktSize", "The size, in bytes, of each data packet", pktSize); cmd.AddValue ("xmitTime","The between UDP transmissions from each node", xmitTime); cmd.Parse (argc,argv); pktSize = (pktSize < 64) ? 64 : pktSize; // Minimum of 64 bytes per packet xmitTime = (xmitTime < 0.001) ? 0.001 : xmitTime; // At least 0.001 seconds between sends NS_LOG_COMPONENT_DEFINE("geopebble"); if (verbose) { LogComponentEnable ("UdpClient", LOG_LEVEL_INFO); LogComponentEnable ("UdpServer", LOG_LEVEL_INFO); } // Run Checksums for all packets (makes nicer pcap files) GlobalValue::Bind ("ChecksumEnabled", BooleanValue (true)); // ========================================================= // Create Point-to-Point Network // ========================================================= NS_LOG_INFO ("Creating Point-to-Point Network"); // Point-to-Point Helper Setup PointToPointHelper pointToPoint; pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("100Mbps")); pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms")); // Make Point-to-Point Star helper // Helper creates p2p star network on initialization. PointToPointStarHelper p2pStar (4, pointToPoint); // Place hub in center of network with mobility model. MobilityHelper hubMobility; hubMobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel"); hubMobility.SetPositionAllocator ("ns3::GridPositionAllocator", "MinX", DoubleValue (0),

Page 43 of 56

"MinY", DoubleValue (0), "DeltaX", DoubleValue (10.0), "DeltaY", DoubleValue (10.0), "GridWidth", UintegerValue (5), "LayoutType", StringValue ("RowFirst")); hubMobility.Install (p2pStar.GetHub ()); // ========================================================= // Create Wi-Fi Networks // ========================================================= NS_LOG_INFO ("Creating Wi-fi Networks"); // Define Node and NetDevice Containers for each Wi-Fi net NodeContainer wifiStaNodes[4]; NodeContainer wifiApNode[4]; NetDeviceContainer staDevices[4]; NetDeviceContainer apDevices[4]; Ssid ssid[4]; // Define Channel and Phy helpers, unique for each net YansWifiChannelHelper channel[4]; YansWifiPhyHelper phy[4]; // Wifi Helper Object. Works independant of networks. WifiHelper wifi = WifiHelper::Default (); wifi.SetRemoteStationManager ("ns3::AarfWifiManager"); // Moility helper. Can be reset with each net assignment. MobilityHelper mobility; mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel"); // Assigns MAC addresses for each net. NqosWifiMacHelper mac[4]; // Set up each net. for (int i=0; i<4; i++) { // Set up nodes wifiStaNodes[i].Create (nWifi); wifiApNode[i] = p2pStar.GetSpokeNode(i); // Set up Channel and PHY Helpers with node characteristics channel[i] = YansWifiChannelHelper::Default (); phy[i] = YansWifiPhyHelper::Default (); phy[i].SetChannel (channel[i].Create ()); phy[i].Set("TxPowerStart", DoubleValue (16)); phy[i].Set("TxPowerEnd", DoubleValue (16)); phy[i].Set("TxGain", DoubleValue (12)); phy[i].Set("RxGain", DoubleValue (12)); phy[i].Set("EnergyDetectionThreshold", DoubleValue (-97)); // Set MAC address helper mac[i] = NqosWifiMacHelper::Default (); // Create SSID stringstream ss; ss<< "geopebble" << i; ssid[i] = Ssid (ss.str()); // Finish setting up MAC address helper mac[i].SetType ("ns3::StaWifiMac", "Ssid", SsidValue (ssid[i]), "ActiveProbing", BooleanValue (false)); // Install wifi to each node

Page 44 of 56

staDevices[i] = wifi.Install (phy[i], mac[i], wifiStaNodes[i]); // Now set up AP for the network. // Set MAC type for the AP mac[i].SetType ("ns3::ApWifiMac", "Ssid", SsidValue (ssid[i])); // Change PHY helper to reflect AP characteristics phy[i].Set("TxPowerStart", DoubleValue (28)); phy[i].Set("TxPowerEnd", DoubleValue (28)); phy[i].Set("TxGain", DoubleValue (5)); phy[i].Set("RxGain", DoubleValue (5)); phy[i].Set("EnergyDetectionThreshold", DoubleValue (-97)); apDevices[i] = wifi.Install (phy[i], mac[i], wifiApNode[i]); // Take care of WiFi mobility system double size = 555.5; mobility.SetPositionAllocator ("ns3::GridPositionAllocator", "MinX", DoubleValue (-size+(i/2)*size+size/10), "MinY", DoubleValue (-size+(i%2)*size+size/10), "DeltaX", DoubleValue (size/5), "DeltaY", DoubleValue (size/5), "GridWidth", UintegerValue (5), "LayoutType", StringValue ("RowFirst")); mobility.Install (wifiStaNodes[i]); mobility.SetPositionAllocator ("ns3::GridPositionAllocator", "MinX", DoubleValue (-size/2+(i/2)*size), "MinY", DoubleValue (-size/2+(i%2)*size), "DeltaX", DoubleValue (10.0), "DeltaY", DoubleValue (10.0), "GridWidth", UintegerValue (5), "LayoutType", StringValue ("RowFirst")); mobility.Install (wifiApNode[i]); } // ========================================================= // Set up the IP Stack and addressing // ========================================================= NS_LOG_INFO ("Setting up the IP stack and addressing"); // Create the IP stack and install it to all nodes. InternetStackHelper stack; p2pStar.InstallStack(stack); for (int i=0; i<4; i++) { stack.Install (wifiStaNodes[i]); } // Helper to assign IPv4 addresses Ipv4AddressHelper address; // Assign addresses for p2p star network address.SetBase ("10.1.10.0", "255.255.255.0"); p2pStar.AssignIpv4Addresses (address); // Assign addresses for Wi-Fi net 1 Ipv4AddressHelper addressWifi; addressWifi.SetBase ("10.1.1.0", "255.255.255.0"); addressWifi.Assign (staDevices[0]); addressWifi.Assign (apDevices[0]);

Page 45 of 56

// Assign addresses for Wi-Fi net 2 addressWifi.SetBase ("10.1.2.0", "255.255.255.0"); addressWifi.Assign (staDevices[1]); addressWifi.Assign (apDevices[1]); // Assign addresses for Wi-Fi net 3 addressWifi.SetBase ("10.1.3.0", "255.255.255.0"); addressWifi.Assign (staDevices[2]); addressWifi.Assign (apDevices[2]); // Assign addresses for Wi-Fi net 4 addressWifi.SetBase ("10.1.4.0", "255.255.255.0"); addressWifi.Assign (staDevices[3]); addressWifi.Assign (apDevices[3]); // Initialize routing tables. Ipv4GlobalRoutingHelper::PopulateRoutingTables (); // ========================================================= // Set up Applications // ========================================================= NS_LOG_INFO ("Setting up applications"); // UDP server to receive all UDP data. UdpServerHelper udpServer (9); // Install UDP server to central hub. ApplicationContainer serverApps = udpServer.Install (p2pStar.GetHub ()); serverApps.Start (Seconds (0.0)); serverApps.Stop (Seconds (35.0)); // UDP client to send UDP data from each sensor node UdpClientHelper udpClient (p2pStar.GetHubIpv4Address (1), 9); udpClient.SetAttribute ("MaxPackets", UintegerValue (1000000)); udpClient.SetAttribute ("Interval", TimeValue (Seconds (xmitTime))); udpClient.SetAttribute ("PacketSize", UintegerValue (pktSize)); // Create container to hold all client apps. ApplicationContainer clientApps; ApplicationContainer clientApp; // Install to all wi-fi nets. for (int i=0; i<4; i++) { // Install to all sensor nodes on net. for (uint32_t j=0; j<25; j++) { clientApp = udpClient.Install (wifiStaNodes[i].Get (j)); clientApp.Start(Seconds (1.0+(xmitTime/25)*j)); clientApp.Stop(Seconds (32.0)); clientApps.Add(clientApp); } } // ========================================================= // Setup final misc. bits, then run simulator // ========================================================= NS_LOG_INFO ("Prepping simulation and logging"); // Force Simulator stop after certain time. Simulator::Stop (Seconds (40.0)); // Set up pcap for central nodes. pointToPoint.EnablePcapAll ("burst");

Page 46 of 56

Node durr = *(p2pStar.GetHub ()); pointToPoint.EnablePcap ("burst", durr.GetDevice(0), true); // Run the simulator Simulator::Run (); Simulator::Destroy (); return 0; }

Page 47 of 56

7.3 TCP Bulk Test Code (no rate limiting) /* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */ /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation; * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ /* Bulk_TCP_test.cc * Simulates a bulk TCP transmission for the GeoPebble wireless net. * Use the --PrintHelp switch to show all options and console variables. * * Written by Scott Teal * Last updated April 5, 2012 * * Compiled and tested with "Waf" build system for network simulator 3. * NS3 Version Used: ns-3.13 */ #include <sstream> #include "ns3/core-module.h" #include "ns3/point-to-point-module.h" #include "ns3/point-to-point-star.h" #include "ns3/network-module.h" #include "ns3/applications-module.h" #include "ns3/wifi-module.h" #include "ns3/mobility-module.h" #include "ns3/csma-module.h" #include "ns3/internet-module.h" // GeoPebble WiFi Topology // // Wifi 10.1.2.0 // AP // * * * * // | | | | 10.1.1.0 // n5 ... n30 n1 ---------------- // point-to-point | // | // Wifi 10.1.3.0 | // AP | // * * * * | // | | | | 10.1.1.0 | // n31 ... n55 n2 ---------------- // point-to-point | // | // Wifi 10.1.4.0 |-------n0 // AP | // * * * * | // | | | | 10.1.1.0 | // n56 ... n80 n3 ---------------- // point-to-point | // | // Wifi 10.1.5.0 |

Page 48 of 56

// AP | // * * * * | // | | | | 10.1.1.0 | // n81 ... n105 n4 ---------------- // point-to-point using namespace ns3; NS_LOG_COMPONENT_DEFINE ("UDP_Script"); int main (int argc, char *argv[]) { // ========================================================= // Set up Command Line Parser and its parameters // ========================================================= bool verbose = true; uint32_t nWifi = 25; uint32_t pktSize = 500; uint32_t maxBytes = 2700000; // 2.7MB of data per burst sample. CommandLine cmd; cmd.AddValue ("verbose", "Tell applications to log if true", verbose); cmd.AddValue ("pktSize", "The size, in bytes, of each data packet", pktSize); cmd.AddValue ("maxBytes","The total number of bytes to send over TCP", maxBytes); cmd.Parse (argc,argv); pktSize = (pktSize < 64) ? 64 : pktSize; // Minimum of 64 bytes per packet NS_LOG_COMPONENT_DEFINE("geopebble"); if (verbose) { LogComponentEnable ("PacketSink", LOG_LEVEL_INFO); LogComponentEnable ("BulkSendApplication", LOG_LEVEL_INFO); } // Run Checksums for all packets (makes nicer pcap files) GlobalValue::Bind ("ChecksumEnabled", BooleanValue (true)); // ========================================================= // Create Point-to-Point Network // ========================================================= NS_LOG_INFO ("Creating Point-to-Point Network"); // Point-to-Point Helper Setup PointToPointHelper pointToPoint; pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("100Mbps")); pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms")); // Make Point-to-Point Star helper // Helper creates p2p star network on initialization. PointToPointStarHelper p2pStar (4, pointToPoint); // Place hub in center of network with mobility model. MobilityHelper hubMobility; hubMobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel"); hubMobility.SetPositionAllocator ("ns3::GridPositionAllocator", "MinX", DoubleValue (0), "MinY", DoubleValue (0), "DeltaX", DoubleValue (10.0),

Page 49 of 56

"DeltaY", DoubleValue (10.0), "GridWidth", UintegerValue (5), "LayoutType", StringValue ("RowFirst")); hubMobility.Install (p2pStar.GetHub ()); // ========================================================= // Create Wi-Fi Networks // ========================================================= NS_LOG_INFO ("Creating Wi-fi Networks"); // Define Node and NetDevice Containers for each Wi-Fi net NodeContainer wifiStaNodes[4]; NodeContainer wifiApNode[4]; NetDeviceContainer staDevices[4]; NetDeviceContainer apDevices[4]; Ssid ssid[4]; // Define Channel and Phy helpers, unique for each net YansWifiChannelHelper channel[4]; YansWifiPhyHelper phy[4]; // Wifi Helper Object. Works independant of networks. WifiHelper wifi = WifiHelper::Default (); wifi.SetRemoteStationManager ("ns3::AarfWifiManager"); // Moility helper. Can be reset with each net assignment. MobilityHelper mobility; mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel"); // Assigns MAC addresses for each net. NqosWifiMacHelper mac[4]; // Set up each net. for (int i=0; i<4; i++) { // Set up nodes wifiStaNodes[i].Create (nWifi); wifiApNode[i] = p2pStar.GetSpokeNode(i); // Set up Channel and PHY Helpers with node characteristics channel[i] = YansWifiChannelHelper::Default (); phy[i] = YansWifiPhyHelper::Default (); phy[i].SetChannel (channel[i].Create ()); phy[i].Set("TxPowerStart", DoubleValue (16)); phy[i].Set("TxPowerEnd", DoubleValue (16)); phy[i].Set("TxGain", DoubleValue (12)); phy[i].Set("RxGain", DoubleValue (12)); phy[i].Set("EnergyDetectionThreshold", DoubleValue (-97)); // Set MAC address helper mac[i] = NqosWifiMacHelper::Default (); // Create SSID stringstream ss; ss<< "geopebble" << i; ssid[i] = Ssid (ss.str()); // Finish setting up MAC address helper mac[i].SetType ("ns3::StaWifiMac", "Ssid", SsidValue (ssid[i]), "ActiveProbing", BooleanValue (false)); // Install wifi to each node staDevices[i] = wifi.Install (phy[i], mac[i], wifiStaNodes[i]);

Page 50 of 56

// Now set up AP for the network. // Set MAC type for the AP mac[i].SetType ("ns3::ApWifiMac", "Ssid", SsidValue (ssid[i])); // Change PHY helper to reflect AP characteristics phy[i].Set("TxPowerStart", DoubleValue (28)); phy[i].Set("TxPowerEnd", DoubleValue (28)); phy[i].Set("TxGain", DoubleValue (5)); phy[i].Set("RxGain", DoubleValue (5)); phy[i].Set("EnergyDetectionThreshold", DoubleValue (-97)); apDevices[i] = wifi.Install (phy[i], mac[i], wifiApNode[i]); // Take care of WiFi mobility system double size = 555.5; mobility.SetPositionAllocator ("ns3::GridPositionAllocator", "MinX", DoubleValue (-size+(i/2)*size+size/10), "MinY", DoubleValue (-size+(i%2)*size+size/10), "DeltaX", DoubleValue (size/5), "DeltaY", DoubleValue (size/5), "GridWidth", UintegerValue (5), "LayoutType", StringValue ("RowFirst")); mobility.Install (wifiStaNodes[i]); mobility.SetPositionAllocator ("ns3::GridPositionAllocator", "MinX", DoubleValue (-size/2+(i/2)*size), "MinY", DoubleValue (-size/2+(i%2)*size), "DeltaX", DoubleValue (10.0), "DeltaY", DoubleValue (10.0), "GridWidth", UintegerValue (5), "LayoutType", StringValue ("RowFirst")); mobility.Install (wifiApNode[i]); } // ========================================================= // Set up the IP Stack and addressing // ========================================================= NS_LOG_INFO ("Setting up the IP stack and addressing"); // Create the IP stack and install it to all nodes. InternetStackHelper stack; p2pStar.InstallStack(stack); for (int i=0; i<4; i++) { stack.Install (wifiStaNodes[i]); } // Helper to assign IPv4 addresses Ipv4AddressHelper address; // Assign addresses for p2p star network address.SetBase ("10.1.10.0", "255.255.255.0"); p2pStar.AssignIpv4Addresses (address); // Assign addresses for Wi-Fi net 1 Ipv4AddressHelper addressWifi; addressWifi.SetBase ("10.1.1.0", "255.255.255.0"); addressWifi.Assign (staDevices[0]); addressWifi.Assign (apDevices[0]); // Assign addresses for Wi-Fi net 2 addressWifi.SetBase ("10.1.2.0", "255.255.255.0");

Page 51 of 56

addressWifi.Assign (staDevices[1]); addressWifi.Assign (apDevices[1]); // Assign addresses for Wi-Fi net 3 addressWifi.SetBase ("10.1.3.0", "255.255.255.0"); addressWifi.Assign (staDevices[2]); addressWifi.Assign (apDevices[2]); // Assign addresses for Wi-Fi net 4 addressWifi.SetBase ("10.1.4.0", "255.255.255.0"); addressWifi.Assign (staDevices[3]); addressWifi.Assign (apDevices[3]); // Initialize routing tables. Ipv4GlobalRoutingHelper::PopulateRoutingTables (); // ========================================================= // Set up Applications // ========================================================= NS_LOG_INFO ("Setting up applications"); // TCP Packet Sink to receive all bulk data. PacketSinkHelper sink ("ns3::TcpSocketFactory", InetSocketAddress (p2pStar.GetHubIpv4Address (1), 80)); ApplicationContainer sinkApps = sink.Install (p2pStar.GetHub ()); sinkApps.Start (Seconds (0.0)); sinkApps.Stop (Seconds (100.0)); // TCP Bulk Sender to send all TCP data. BulkSendHelper source ("ns3::TcpSocketFactory", InetSocketAddress (p2pStar.GetHubIpv4Address (1), 80)); // Set the amount of data to send in bytes. Zero is unlimited. source.SetAttribute ("MaxBytes", UintegerValue (maxBytes)); source.SetAttribute ("SendSize", UintegerValue (pktSize)); ApplicationContainer clientApps = source.Install (wifiStaNodes[0].Get(2)); clientApps.Start (Seconds (1.0)); // ========================================================= // Setup final misc. bits, then run simulator // ========================================================= NS_LOG_INFO ("Prepping simulation and logging"); // Force Simulator stop after certain time. Simulator::Stop (Seconds (100.0)); // Set up pcap for central nodes. pointToPoint.EnablePcapAll ("bulk"); Node durr = *(p2pStar.GetHub ()); pointToPoint.EnablePcap ("bulk", durr.GetDevice(0), true); // Run the simulator Simulator::Run (); Simulator::Destroy (); return 0; }

Page 52 of 56

7.4 TCP Bulk Test Code (rate limiting) /* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */ /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation; * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ /* Bulk_TCP_test_limit.cc * Simulates a bulk TCP transmission for the GeoPebble wireless net. * Rate-limits to 2.8 Mbps (Digi Wi-Fi SPI is limited to 3.5MHz, get about * 8 bits for 10 cycles due to rest time between bytes) * Use the --PrintHelp switch to show all options and console variables. * * Written by Scott Teal * Last updated April 5, 2012 * * Compiled and tested with "Waf" build system for network simulator 3. * NS3 Version Used: ns-3.13 */ #include <sstream> #include "ns3/core-module.h" #include "ns3/point-to-point-module.h" #include "ns3/point-to-point-star.h" #include "ns3/network-module.h" #include "ns3/applications-module.h" #include "ns3/wifi-module.h" #include "ns3/mobility-module.h" #include "ns3/csma-module.h" #include "ns3/internet-module.h" // GeoPebble WiFi Topology // // Wifi 10.1.2.0 // AP // * * * * // | | | | 10.1.1.0 // n5 ... n30 n1 ---------------- // point-to-point | // | // Wifi 10.1.3.0 | // AP | // * * * * | // | | | | 10.1.1.0 | // n31 ... n55 n2 ---------------- // point-to-point | // | // Wifi 10.1.4.0 |-------n0 // AP | // * * * * | // | | | | 10.1.1.0 | // n56 ... n80 n3 ----------------

Page 53 of 56

// point-to-point | // | // Wifi 10.1.5.0 | // AP | // * * * * | // | | | | 10.1.1.0 | // n81 ... n105 n4 ---------------- // point-to-point using namespace ns3; NS_LOG_COMPONENT_DEFINE ("UDP_Script"); int main (int argc, char *argv[]) { // ========================================================= // Set up Command Line Parser and its parameters // ========================================================= bool verbose = true; uint32_t nWifi = 25; uint32_t pktSize = 1000; uint32_t maxBytes = 2700000; // 2.7MB of data per burst sample. CommandLine cmd; cmd.AddValue ("verbose", "Tell applications to log if true", verbose); cmd.AddValue ("pktSize", "The size, in bytes, of each data packet", pktSize); cmd.AddValue ("maxBytes","The total number of bytes to send over TCP", maxBytes); cmd.Parse (argc,argv); pktSize = (pktSize < 64) ? 64 : pktSize; // Minimum of 64 bytes per packet NS_LOG_COMPONENT_DEFINE("geopebble"); if (verbose) { LogComponentEnable ("PacketSink", LOG_LEVEL_INFO); LogComponentEnable ("BulkSendApplication", LOG_LEVEL_INFO); } // Run Checksums for all packets (makes nicer pcap files) GlobalValue::Bind ("ChecksumEnabled", BooleanValue (true)); // ========================================================= // Create Point-to-Point Network // ========================================================= NS_LOG_INFO ("Creating Point-to-Point Network"); // Point-to-Point Helper Setup PointToPointHelper pointToPoint; pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("100Mbps")); pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms")); // Make Point-to-Point Star helper // Helper creates p2p star network on initialization. PointToPointStarHelper p2pStar (4, pointToPoint); // Place hub in center of network with mobility model. MobilityHelper hubMobility; hubMobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel"); hubMobility.SetPositionAllocator ("ns3::GridPositionAllocator",

Page 54 of 56

"MinX", DoubleValue (0), "MinY", DoubleValue (0), "DeltaX", DoubleValue (10.0), "DeltaY", DoubleValue (10.0), "GridWidth", UintegerValue (5), "LayoutType", StringValue ("RowFirst")); hubMobility.Install (p2pStar.GetHub ()); // ========================================================= // Create Wi-Fi Networks // ========================================================= NS_LOG_INFO ("Creating Wi-fi Networks"); // Define Node and NetDevice Containers for each Wi-Fi net NodeContainer wifiStaNodes[4]; NodeContainer wifiApNode[4]; NetDeviceContainer staDevices[4]; NetDeviceContainer apDevices[4]; Ssid ssid[4]; // Define Channel and Phy helpers, unique for each net YansWifiChannelHelper channel[4]; YansWifiPhyHelper phy[4]; // Wifi Helper Object. Works independant of networks. WifiHelper wifi = WifiHelper::Default (); wifi.SetRemoteStationManager ("ns3::AarfWifiManager"); // Moility helper. Can be reset with each net assignment. MobilityHelper mobility; mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel"); // Assigns MAC addresses for each net. NqosWifiMacHelper mac[4]; // Set up each net. for (int i=0; i<4; i++) { // Set up nodes wifiStaNodes[i].Create (nWifi); wifiApNode[i] = p2pStar.GetSpokeNode(i); // Set up Channel and PHY Helpers with node characteristics channel[i] = YansWifiChannelHelper::Default (); phy[i] = YansWifiPhyHelper::Default (); phy[i].SetChannel (channel[i].Create ()); phy[i].Set("TxPowerStart", DoubleValue (16)); phy[i].Set("TxPowerEnd", DoubleValue (16)); phy[i].Set("TxGain", DoubleValue (12)); phy[i].Set("RxGain", DoubleValue (12)); phy[i].Set("EnergyDetectionThreshold", DoubleValue (-97)); // Set MAC address helper mac[i] = NqosWifiMacHelper::Default (); // Create SSID stringstream ss; ss<< "geopebble" << i; ssid[i] = Ssid (ss.str()); // Finish setting up MAC address helper mac[i].SetType ("ns3::StaWifiMac", "Ssid", SsidValue (ssid[i]), "ActiveProbing", BooleanValue (false));

Page 55 of 56

// Install wifi to each node staDevices[i] = wifi.Install (phy[i], mac[i], wifiStaNodes[i]); // Now set up AP for the network. // Set MAC type for the AP mac[i].SetType ("ns3::ApWifiMac", "Ssid", SsidValue (ssid[i])); // Change PHY helper to reflect AP characteristics phy[i].Set("TxPowerStart", DoubleValue (28)); phy[i].Set("TxPowerEnd", DoubleValue (28)); phy[i].Set("TxGain", DoubleValue (5)); phy[i].Set("RxGain", DoubleValue (5)); phy[i].Set("EnergyDetectionThreshold", DoubleValue (-97)); apDevices[i] = wifi.Install (phy[i], mac[i], wifiApNode[i]); // Take care of WiFi mobility system double size = 555.5; mobility.SetPositionAllocator ("ns3::GridPositionAllocator", "MinX", DoubleValue (-size+(i/2)*size+size/10), "MinY", DoubleValue (-size+(i%2)*size+size/10), "DeltaX", DoubleValue (size/5), "DeltaY", DoubleValue (size/5), "GridWidth", UintegerValue (5), "LayoutType", StringValue ("RowFirst")); mobility.Install (wifiStaNodes[i]); mobility.SetPositionAllocator ("ns3::GridPositionAllocator", "MinX", DoubleValue (-size/2+(i/2)*size), "MinY", DoubleValue (-size/2+(i%2)*size), "DeltaX", DoubleValue (10.0), "DeltaY", DoubleValue (10.0), "GridWidth", UintegerValue (5), "LayoutType", StringValue ("RowFirst")); mobility.Install (wifiApNode[i]); } // ========================================================= // Set up the IP Stack and addressing // ========================================================= NS_LOG_INFO ("Setting up the IP stack and addressing"); // Create the IP stack and install it to all nodes. InternetStackHelper stack; p2pStar.InstallStack(stack); for (int i=0; i<4; i++) { stack.Install (wifiStaNodes[i]); } // Helper to assign IPv4 addresses Ipv4AddressHelper address; // Assign addresses for p2p star network address.SetBase ("10.1.10.0", "255.255.255.0"); p2pStar.AssignIpv4Addresses (address); // Assign addresses for Wi-Fi net 1 Ipv4AddressHelper addressWifi; addressWifi.SetBase ("10.1.1.0", "255.255.255.0"); addressWifi.Assign (staDevices[0]); addressWifi.Assign (apDevices[0]);

Page 56 of 56

// Assign addresses for Wi-Fi net 2 addressWifi.SetBase ("10.1.2.0", "255.255.255.0"); addressWifi.Assign (staDevices[1]); addressWifi.Assign (apDevices[1]); // Assign addresses for Wi-Fi net 3 addressWifi.SetBase ("10.1.3.0", "255.255.255.0"); addressWifi.Assign (staDevices[2]); addressWifi.Assign (apDevices[2]); // Assign addresses for Wi-Fi net 4 addressWifi.SetBase ("10.1.4.0", "255.255.255.0"); addressWifi.Assign (staDevices[3]); addressWifi.Assign (apDevices[3]); // Initialize routing tables. Ipv4GlobalRoutingHelper::PopulateRoutingTables (); // ========================================================= // Set up Applications // ========================================================= NS_LOG_INFO ("Setting up applications"); // TCP Packet Sink to receive all bulk data. PacketSinkHelper sink ("ns3::TcpSocketFactory", InetSocketAddress (p2pStar.GetHubIpv4Address (1), 80)); ApplicationContainer sinkApps = sink.Install (p2pStar.GetHub ()); sinkApps.Start (Seconds (0.0)); sinkApps.Stop (Seconds (100.0)); // TCP Bulk Sender to send all TCP data. OnOffHelper source ("ns3::TcpSocketFactory", InetSocketAddress (p2pStar.GetHubIpv4Address (1), 80)); // Set the amount of data to send in bytes. Zero is unlimited. source.SetAttribute ("MaxBytes", UintegerValue (maxBytes)); source.SetAttribute ("PacketSize", UintegerValue (pktSize)); source.SetAttribute ("DataRate", DataRateValue (2800000)); ApplicationContainer clientApps = source.Install (wifiStaNodes[0].Get(2)); clientApps.Start (Seconds (1.0)); // ========================================================= // Setup final misc. bits, then run simulator // ========================================================= NS_LOG_INFO ("Prepping simulation and logging"); // Force Simulator stop after certain time. Simulator::Stop (Seconds (100.0)); // Set up pcap for central nodes. pointToPoint.EnablePcapAll ("bulk_limit"); Node durr = *(p2pStar.GetHub ()); pointToPoint.EnablePcap ("bulk_limit", durr.GetDevice(0), true); // Run the simulator Simulator::Run (); Simulator::Destroy (); return 0; }

Vita

Richard Scott Teal

Richard Scott Teal

46 Cedar Hill Lane

Media, PA 19063

Scott@Teals.org

Education:

Bachelor of Science in Electrical Engineering, Pennsylvania State Univ., May 2012

Schreyer Honors Scholar, all years

Lockheed Martin Scholar, Junior Year

Frank Gabron Scholar, all years

Thesis Title: GeoPebble Wireless Seismic Sensor Web – Wireless Network Development

Thesis Advisor: Professor Sven G. Bilén

Related Experience:

Undergraduate research at the Student Space Programs Laboratory at Penn State

Sun Sensor Research and Development

Satellite Communications Subsystem Research and Development

Undergraduate research at the Systems Design Lab at Penn State

Awards:

Deans List, all semesters except Fall 2010

Memberships:

National Society of Collegiate Scholars

Institute of Electrical and Electronics Engineers (IEEE)

Activities:

Penn State Anime Organization (PSAO) – Treasurer, Game Night Manager

Setsucon, a 1000+ person anime convention run by PSAO - treasurer

Game Design Club – Secretary, Webmaster